Yesterday, Martin Vogel from sirius-net GmbH sent me an email and asked for help with HCL Domino DirSync.
He had an issue with the filter syntax and also encountered some strange error messages when trying to sync from an Active Directory to Domino Directory.
Let’s first see, what the problem with the filter is. By default, DirSync syncs all person and group objects under the given SearchBase.
If you only want to get a subset of the possible results, you can use a filter in the DirSync Configuration document. Here is the filter.
(&(objectClass=person)(memberOf=CN=DistributionGroup,CN=Services & Accounts,CN=Sync,DC=ad,DC=fritz,DC=box))
We checked the filter syntax by running a search from LDAPAdmin. The search returned the expected result.
But when we try to apply the filter to the DirSync configuration, the following error message occurs when trying to save the document.
Apparently there is a problem with the ‘&‘ in the ‘CN=Services & Accounts‘ part of the filter.
My first guess was that the ‘&’ character is not allowed in the filter string. But why is it possible to create an OU with this character in Active Directory?
And also, why does LDAPAdmin not complain about bad syntax?
The “Naming conventions in Active Directory for computers, domains, sites, and OUs” documentation does not mention any disallowed characters for OU names.
I took a closer look at the DirSyncUtil class in names.nsf. The error message is displayed during validation of the filter string. The code assumes that a “&” or “|” can only occur right after a “(“.
Else
state = State_inpar ' if we see an operator after this it's a problem.
End If
lastChar = ch
Next
If depth <> 0 Then
crunch:
LDAPValidate = i
End If
Exit Function
If “&” or “|” occur after any other char, it is assumed an error. So the filter string is syntactically ok. But it is not validated as error-free.
Next, we needed to find a way to work around this limitation. One option would be to disable validation. Not a good idea. Or, we could set the filter string using Ytria ScanEZ.
This works, but in a productive environment this is certainly not the correct procedure.
Google to the rescue, we found another option to apply the filter string and validate it on document save & close.
Simply replace the ‘&’ char by it’s escape sequence ‘\26’. Our filter string will look like this then.
(&(objectClass=person)(memberOf=CN=DistributionGroup,CN=Services \26 Accounts,CN=Sync,DC=ad,DC=fritz,DC=box))
Now you can save & close the document without the error message. We then enabled the DirSync configuration. When DirSync tried to sync, we saw an error message on the server console.
"<ct sq="00003128" ti="0039C81D-C12585DF" ex="ndirsync" pi="17F0" tr="0004-0FB8" co="7">[17F0:0004-0FB8] DirSync> CSyncFromAD::SyncSpan( - 84: Decoding error)@syncfromad.cpp:2866 - 13171:DirSync encounterred LDAP error ./ct>"
We cross-checked the configuration on another machine and with another Active Directory.
Here the sync ran without any issues and the expected person records were synced into the Domino Directory.
We repeated the test without any filter string applied and even in this case, an error occurs. But the error has changed.
[17F0:0005-0324] DirSync ResyncAll by CheckBox: 0 [17F0:0005-0324] DirSync Preview: 0 [17F0:0005-0324] DirSync Level: 16 [17F0:0005-0324] DirSync SyncFlows: 2 [17F0:0005-0324] DirSync OnPremCookie: [17F0:0005-0324] DirSync UserDirCookie: 54247270 [17F0:0005-0324] DirSync ResyncAll by Request: 1 [17F0:0005-0324] DirSync Sync all request calling SyncFromLDAPToNAB. [17F0:0005-0324] DirSync SyncFromLDAPToNAB The parms were: [17F0:0005-0324] DirSync base: [17F0:0005-0324] DirSync scope: subtree [17F0:0005-0324] DirSync filter: (&(|(objectClass=Group)(objectClass=Person))(uSNChanged>=0)) [17F0:0005-0324] DirSync attributes: co , company , department , description , facsimileTelephoneNumber , givenName , mail , homephone , initials , l, manager , mobile , pager , physicaldeliveryofficename , postalcode , sn , st , streetaddress , telephonenumber , title , uid , wWWHomePage , memberOf , objectClass , objectGUID , groupType , member , uSNChanged [17F0:0005-0324] DirSync page size: 5000 [17F0:0005-0324] SyncFromLDAPToNAB ldap err: 54
Error code 54 stands for LDAP_LOOP_DETECTED. The documentation says that the error …
Indicates that the client discovered an alias or referral loop, and is thus unable to complete this request.
I am not an Active Directory expert. So I have no clue, why this errors occur on one machine, but not on the other. I’ve asked Mike O’Brien from HCL Development.
Odd. The error 84 (0x54) is an LDAP_DECODING_ERROR. This means that there was an issue decoding a server result. The 54 which is (0x36) is a LDAP_LOOP_DETECT which indicates a service issue.
Mike O’Brien, HCL
The fact that he is seeing this with the default filter leads me to believe it is something service related.
Apparently, the errors are related to the Active Directory configuration. Anyone any thoughts on this?
Have you tried to escape the & sign ?
It could be that you are chasing referrals which should be turned off. You could turn off “Maximum number of referrals” in the Domino LDAP configuration. Or you could turn off returning referrals in the Active Directory. But changing Domino might be safer.
We will investigate both the Template and Dirsync decoding error.
Thank you, Michael for the hint.
We set the value of the field “Maximum number of referrals” from 1 to 0 and it works as designed.