Confluence LDAP directory config - LDAP filter

Question

Hi,

Running Confluence 6.2 on Centos6, connecting via LDAP to a Active Directory domain.

We have an issue with Confluence (JIRA also seems affected by this as well) where we are unable to mention (i.e. '@<username>' in comments section) a certain newly created domain user. Normally when typing '@' and then other characters it suggests users from the domain. New users do not seem to appear as any of the suggestions, although older users do. When you go to Users>Find a User (user mgmt) the new user does not appear. If the new user logs in to Confluence (using AD account) the account then appears in 'find users' but when the LDAP directory is synchronised, it is removed from the cache and searches once again are unable to find it.

What I've noticed is if I restrict the LDAP directory to a specific OU in 'Additional User DN' field (the one that actually contains the new user account) and resync LDAP, it clears ~19500 users from cache (and adds others), after which the new user's account appears in the list of users. Also, after this, mentioning using '@' works as expected.

It seems the LDAP directory is hitting a some sort of limit and not returning all users in the entire directory. Is there a limit to the number of users LDAP will return? I've found no obvious way of configuring this. The options appear to be:

- Enable the Confluence LDAP user directory to find all users in Active Directory by changing limit

- create some sort of filter so it restricts the returned users to a paricular group or OUs (unfortunately users could be in multiple OUs)

I'm looking at https://confluence.atlassian.com/kb/how-to-write-ldap-search-filters-792496933.html but I'm not entirely sure where to define these filters.

Cheers,

Tim

tim wilkinson · Answer

Thanks Davin.

That's helped me figure out how to add the filter. I noticed a lot of the 'users' returned by the LDAP query were actually devices and had a '$' symbol at the end of the name, so I added a filter to exclude anythin where sAMAccountName contained '$' (as no user accounts will). This removed >16000 entries from the cache and all expected users now appear in user list.

I can probably refine this a bit more along your lines but I've got it behaving as I want it to for now.

Davin Studer · Answer

This is how I have our's setup ...

Make sure the that everyone who should be a Confluence user is hierarchically under the "Additional User DN:". So, keep working your way up the OU tree until you get to the point that everyone is under the "Additional User DN:" (don't worry we will filter later on).

For the "Additional Group DN:" make sure that your groups all fall under that as well (we will filter this too).

Then in the Group Schema Settings use an LDAP filter to only include the groups you want. Here is how mine is setup.

Group Object Class: group
Group Object Filter: (&(objectCategory=Group)(|(sAMAccountName=confluence*)(sAMAccountName=ASecondGroup)(sAMAccountName=AThirdGroup)))
Group Name Attribute: cn
Group Description Attribute: description

This says that it will look for objects that have the class of group and category of group. Also, it will only pull in groups that have the sAMAccountName starting with "confluence" or are the second or third group. Those are the groups that will be created in Confluence.

For the User Schema Settings I set it up like this ...

User Object Class: user
User Object Filter: (&(objectCategory=Person)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(|(memberOf=CN=confluence-users,OU=Confluence,OU=Managed Groups,DC=company,DC=dom)))
User Name Attribute: sAMAccountName
User Name RDN Attribute: cn
User First Name Attribute: givenName
User Last Name Attribute: sn
User Display Name Attribute: displayName
User Email Attribute: mail
User Password Attribute: unicodePwd
User Unique ID Attribute: objectGUID

This says that it will add as users to the system people who have a class of user and category of Person. Also, they must not be disabled (userAccountControl:1.2.840.113556.1.4.803:=2). And they must be a member of the confluence-users group (memberOf=CN=confluence-users,OU=Confluence,OU=Managed Groups,DC=company,DC=dom).

If you set it up this way you can add people to Confluence not by the OU that they are a part of but by the fact that they are in the confluence-users group. This is much better as you could have some people in an OU that you want to have access and others that you don't. Or if they are in different OU's then you have work your way up the OU chain and could add people that you don't want in the system (such as vendors, service accounts, etc.) So, handling by OU is not a good way to do it. The user filter tied to a group that grants access is the best way to handle users.