Details
-
Suggestion
-
Resolution: Unresolved
-
None
-
None
Description
Problem summary
Currently a user directory can only be configured to accept one base DN for users, and one base DN for users. If users or groups (that are relevant to Crowd) exist in multiple containers/OUs of the LDAP structure, then the base DN has to be set wide enough so that both OUs are in scope of the search. This can cause too many irrelevant groups to be pulled into Crowd, which in turn leads to performance issues or complexity in maintaining user management.
Example
For example: consider the case where we have the following LDAP structure, for simplicity's sake we're only looking for groups right now and not users:
DC=company,DC=com +--- OU=all_groups +--- OU=amer_groups +--- OU=apac_groups +--- OU=50k_other_irrelevant_groups
If we want to pull in the groups under amer_groups and apac_groups, then the group base DN must be set to "OU=all_groups,DC=company,DC=com" since both of of them are under that common OU.
The problem is, doing so will also pull the other 50k groups we don't care about into Crowd, because that's also within the search scope. For some LDAP implementations, this is not a problem because you can exclude those irrelevant groups by using Extensible Matching in a search filter to target groups that are within specific OUs. However some LDAP implementations, most notably Microsoft Active Directory, do not support this type of filtering, and therefore Crowd will have no choice but to pull in all of the groups.
Workarounds and limitations
In current versions of Crowd, administrators can somewhat work around this by using multiple user directories. For example, one directory will have the group base DN set to "OU=amer_groups,OU=all_groups,DC=example,DC=com", and another set to "OU=apac_groups,OU=all_groups,DC=example,DC=com". However, this is not ideal, as both of these directories will still need to pull in all users so that their group memberships can be aggregated across user directories. The work to pull in users is duplicated.
Proposed solution
It would be ideal if Crowd itself can allow a single directory to search for users/groups from multiple DNs, regardless of the AD/LDAP implementation.