AD Synchronisation fails

[Idan Bidani]

Hi,

We are having issues with syncing are AD server.

It seems like the some entries have the special char "\0A" in cn (new line i guess) which causes the following exception, part1cn(before new line) part2cn(after new line).

I understand that this entry is bad but I expect Stash/Crowed to ignore this entry and continue the sync.

Does this exception causes the sync to halt?

if it does is it possible to ignore this entry and continue the sync

if it doesn't, maybe "Synchronisation failed" should be rephrased to "Synchronisation completed with errors" ?

Looking forward for your reply

Thanks in advance

2014-12-22 15:40:47,007 ERROR [clusterScheduler_Worker-2] c.a.c.d.DbCachingDirectoryPoller Error occurred while refreshing the cache for directory [ 1572865 ].
org.springframework.ldap.InvalidNameException: cn=part1cn
part2cn,ou=groups,ou=someou,ou=cci,dc=corp,dc=bla,dc=com: [LDAP: error code 34 - 0000208F: NameErr: DSID-031001BA, problem 2006 (BAD_NAME), data 8349, best match of:
'cn=part1cn
part2cn,ou=groups,ou=someou,ou=cci,dc=corp,dc=bla,dc=com'
^@]; nested exception is javax.naming.InvalidNameException: cn=part1cn
part2cn,ou=groups,ou=someou,ou=cci,dc=corp,dc=bla,dc=com: [LDAP: error code 34 - 0000208F: NameErr: DSID-031001BA, problem 2006 (BAD_NAME), data 8349, best match of:
'cn=part1cn
part2cn,ou=groups,ou=someou,ou=cci,dc=corp,dc=bla,dc=com'
^@]; remaining name 'cn=part1cn
part2cn,ou=groups,ou=someou,ou=cci,dc=corp,dc=bla,dc=com'
at org.springframework.ldap.support.LdapUtils.convertLdapException(LdapUtils.java:136) ~[LdapUtils.class:2.0.2.RELEASE]
at org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:820) ~[LdapTemplate.class:2.0.2.RELEASE]
at org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:803) ~[LdapTemplate.class:2.0.2.RELEASE]
at org.springframework.ldap.core.LdapTemplate.lookup(LdapTemplate.java:935) ~[LdapTemplate.class:2.0.2.RELEASE]
at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper$9.timedCall(SpringLdapTemplateWrapper.java:286) ~[SpringLdapTemplateWrapper$9.class:na]
at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper$TimedCallable.call(SpringLdapTemplateWrapper.java:124) ~[SpringLdapTemplateWrapper$TimedCallable.class:na]
at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper.invokeWithContextClassLoader(SpringLdapTemplateWrapper.java:87) ~[SpringLdapTemplateWrapper.class:na]
at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper.lookup(SpringLdapTemplateWrapper.java:282) ~[SpringLdapTemplateWrapper.class:na]
at com.atlassian.crowd.directory.RFC4519Directory.findDirectMembersOfGroup(RFC4519Directory.java:959) ~[RFC4519Directory.class:na]
at com.atlassian.crowd.directory.MicrosoftActiveDirectory.findDirectMembersOfGroup(MicrosoftActiveDirectory.java:516) ~[MicrosoftActiveDirectory.class:na]
at com.atlassian.crowd.directory.RFC4519DirectoryMembershipsIterable$2.apply(RFC4519DirectoryMembershipsIterable.java:78) ~[RFC4519DirectoryMembershipsIterable$2.class:na]
at com.atlassian.crowd.directory.RFC4519DirectoryMembershipsIterable$2.apply(RFC4519DirectoryMembershipsIterable.java:70) ~[RFC4519DirectoryMembershipsIterable$2.class:na]
at com.google.common.collect.Iterators$8.next(Iterators.java:812) ~[Iterators$8.class:na]
at com.atlassian.crowd.directory.ldap.cache.AbstractCacheRefresher.synchroniseMemberships(AbstractCacheRefresher.java:196) ~[AbstractCacheRefresher.class:na]
at com.atlassian.crowd.directory.ldap.cache.AbstractCacheRefresher.synchroniseAll(AbstractCacheRefresher.java:98) ~[AbstractCacheRefresher.class:na]
at com.atlassian.crowd.directory.ldap.cache.UsnChangedCacheRefresher.synchroniseAll(UsnChangedCacheRefresher.java:161) ~[UsnChangedCacheRefresher.class:na]
at com.atlassian.crowd.directory.DbCachingRemoteDirectory.synchroniseCache(DbCachingRemoteDirectory.java:1122) ~[DbCachingRemoteDirectory.class:na]
at com.atlassian.crowd.manager.directory.DirectorySynchroniserImpl.synchronise(DirectorySynchroniserImpl.java:76) ~[DirectorySynchroniserImpl.class:na]
at com.atlassian.crowd.directory.DbCachingDirectoryPoller.pollChanges(DbCachingDirectoryPoller.java:50) ~[DbCachingDirectoryPoller.class:na]
at com.atlassian.crowd.manager.directory.monitor.poller.DirectoryPollerJobRunner.runJob(DirectoryPollerJobRunner.java:93) [DirectoryPollerJobRunner.class:na]
at com.atlassian.scheduler.core.JobLauncher.runJob(JobLauncher.java:135) [JobLauncher.class:na]
at com.atlassian.scheduler.core.JobLauncher.launchAndBuildResponse(JobLauncher.java:101) [JobLauncher.class:na]
at com.atlassian.scheduler.core.JobLauncher.launch(JobLauncher.java:80) [JobLauncher.class:na]
at com.atlassian.scheduler.quartz2.Quartz2Job.execute(Quartz2Job.java:32) [Quartz2Job.class:na]
at org.quartz.core.JobRunShell.run(JobRunShell.java:202) [JobRunShell.class:na]
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573) [SimpleThreadPool$WorkerThread.class:na]
... 12 frames trimmed
Caused by: javax.naming.InvalidNameException: cn=part1cn

[Idan Bidani]

Looks like this is how Active directory is handling duplicate entries http://social.technet.microsoft.com/wiki/contents/articles/15435.active-directory-duplicate-object-name-resolution.aspx#When_a_Duplicate_RDN_in_an_OU_or_Container_is_Detected

I find it weird that SonarQube, Subversion Edge and Jenkins can handle this bad entries perfectly fine and Atlassian products have trouble with it.

[Idan Bidani]

created https://jira.atlassian.com/browse/STASH-6948

[IshanL]

There is already an improvement ticket.

https://jira.atlassian.com/browse/CWD-4174

[rrudnicki]

Hi Idam, 

The error code 34 means a bad DN as you can see on this link.

Looking into your error message, it looks like your LDAP URL is wrong:

NameErr: DSID-031001BA, problem 2006 (BAD_NAME), data 8349, best match of:
'cn=part1cn
part2cn,ou=groups,ou=someou,ou=cci,dc=corp,dc=bla,dc=com'

I could see your LDAP path should be:

'cn=part1,cn=part2,ou=groups,ou=someou,ou=cci,dc=corp,dc=bla,dc=com'

and not

'cn=part1cnpart2cn,ou=groups,ou=someou,ou=cci,dc=corp,dc=bla,dc=com'

If it isn't the problem, could you confirm your correct LDAP base?

Regards, 

Renato Rudnicki

[Idan Bidani]

Thank you for the reply Renato. The LDAP configuration is working perfectly and in 3 other Java web applications, the other web apps just ignoring the bad names (this case is due to the new line char "\0A")

[Boris Berenberg]

The sync will fail and should not be trusted. I would exclude the affected objects explicitly via the LDAP filters.

[Idan Bidani]

Thanks for the quick reply Boris. The affected objects are all around the LDAP(different OUs) I tried using How to Write LDAP Search Filters but it didn't work for me maybe due to the newline in the middle of the cn or I didn't write it well.