-
Suggestion
-
Resolution: Unresolved
-
None
-
43
-
Crowd throws an error when syncing with LDAP directories containing CNF attributes.
[atlassian.crowd.directory.DbCachingDirectoryPoller] Error occurred while refreshing the cache for directory [ XXXXX ]. org.springframework.ldap.InvalidNameException: cn=XXXXXXXXXXXXX cnf:XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX,ou=XXXXX,ou=XXXX,dc=XXXXX,dc=XXXXXX: [LDAP: error code 34 - 0000208F: NameErr: DSID-031001F7, problem 2006 (BAD_NAME), data 8349
According to this Microsoft KB:
Active Directory supports multimaster replication of directory objects between all domain controllers in the domain. When replication of objects results in name conflicts (two objects have the same name within the same container), the system automatically renames one of these accounts to a unique name. For example, object ABC is renamed to be CNF:guid, where "" represents a reserved character, "CNF" is a constant that indicates a conflict resolution, and "guid" represents a printable representation of the objectGuid attribute value.
So the CNF is created when there is a conflict in the replication of the domain controllers and there are duplicated objects.
Crowd should gracefully handle this error.
NOTE this also propagates to other Atlassian Apps that uses Crowd embedded such as JIRA and Confluence.
Workaround
I can see two options in this situation:
1) Ask the LDAP administrator to remove the duplicated groups or users from the LDAP and make sure there are no other conflicts before syncing.
2) Create a filter for the users and groups objects to avoid syncing with objects that have cnf attributes.
Should become something like: (&(objectClass=group)(!(cnf:*))) OR (&(objectCategory=Group)(!(cn=*cnf:*)))
Check here for additional details on LDAP filters.
- is related to
-
BSERV-6948 Gracefully handle errors when syncing with LDAP directories containing CNF attributes
-
- Closed
-
- relates to
-
- Closed
-
- Closed
![[Extranet] Page](/images/icons/generic_link_16.png "[Extranet] Page"){kind=icon}
[CWD-4174] Gracefully handle errors when syncing with LDAP directories containing CNF attributes
We ran into this issue with Confluence 5.9 and 5.10. We recently made a change from a delegated LDAP to have the AD synced. We have a massive AD/LDAP directory and we are bound to run into this again.
We ran into this after the Confluence update from 5.5.3 to 5.8.9 at one of our enterprise clients. This is the second big hurdle we had with the Crowd sync (first was JRA-43495). The workaround with the filter worked for us.
Just ran into this issue with JIRA and JIRA Service Desk. Luckily the log showed me this was problem. Please bump priority and use this workaround. We'd never know this occurred unless we proactively went to the User Management and saw the sync errors. This would lead to a horrible customer experience for our users.
2) Create a filter for the users and groups objects to avoid syncing with objects that have cnf attributes.
Deleted Account (Inactive)
added a comment - FWIW, The second workaround is safer, since new conflict objects can be created after any existing ones are removed from the directory.
Deleted Account (Inactive)
added a comment - FWIW, The second workaround is safer, since new conflict objects can be created after any existing ones are removed from the directory.
Hello,
I just faced this issue and tried to understand it by myself (before thinking that maybe it's a know issue from Atlassian), and for me, the main issue here is that the CN actually contains a line feed character (\0a), which is forbidden by LDAP syntax (the CNF string is on a new line !!)
Then, I design a filter, which is very close to the one from the 2nd workaround, but even more generic if by chance any other LDAP engine allow LF in their CN: