I have a number of groups in AD all prefixed with the word “eramba_”. They are all in the same OU in the AD. The filter for groups is set to
(&(objectCategory=group)(cn=eramba))
so that it only shows eramba groups. I tried setting the base DN to the “groups for application permission” OU but it failed on retrieving users, I’m assuming that this is because those users are in a different page of the AD tree.
When I test the LDAP connector that is my group connector and click the “Test getting members of a group” and put in the dn of eramba_users and it returns all the users. When I put in the full dn for “eramba_ITServices” it returns empty despite the group having 2 members and those two members showing up in the eramba_users members list. I’ve copied the query out into 2rd party software and that does list them as members of the group. Only eramba doesn’t appear to find them. I can create the users manually for now but I’d like to create them through an LDAP Account Sync but, despite that working for all other departments it doesn’t work for the group I have called eramba_ITServices returning the error : Error
LDAP Synchronization test failed. We couldn’t retrieve any valid user from selected LDAP group and authenticator.
I fought with this a bit myself a month or two ago. Please note I’m not a LDAP wizard by any means and my memory on this is fuzzy (I also don’t want to undo what I had fixed to remember exact steps).
But - to hopefully point you in the right direction, first, the Group LDAP connector needs to be pulling the full dn of the group and not the cn, the LDAP filter for group membership needs to include the %GROUP% variable as well.
Here’s the settings I have working:
“LDAP Filter: List of Groups” - (objectCategory=group)
“LDAP Attribute: Group Name” - distinguishedName
“LDAP Filter: Group membership” - (&(userAccountControl=66048)(objectCategory=user)(memberOf=%GROUP%))
Basically - you will have ONE group connector and the Sync tool will pass the dn variable to it in order to query. For initial testing, I’d suggest not filtering at the “LDAP: List of Groups” level and see if it works, then layer in that filter.
yes, i think as mentioned earlier by david, the filter is passing a variable (the DN -not cn- of the group you are after) that is not shown on your filter , perhaps that is the issue here.
“LDAP Filter: List of Groups” - (&(objectCategory=group)(cn=eramba))
“LDAP Attribute: Group Name” - cn
“LDAP Filter: Group membership” - (&(objectCategory=Person)(memberOf:1.2.840.113556.1.4.1941:=%GROUP%))
I changed it to :
“LDAP Filter: List of Groups” - (&(objectCategory=group)(cn=eramba))
“LDAP Attribute: Group Name” - distinguishedName
“LDAP Filter: Group membership” - (&(objectCategory=Person)(memberOf:1.2.840.113556.1.4.1941:=%GROUP%))
and it now works thank you!
For those that are interested in AD the part that says memberOf:1.2.840.113556.1.4.1941:
should fetch members of nested groups as well.
For example if the group companyDirectors is a member of the group erambaDirectors then when people get added to the companyDirectors they will automatically become erambaDirectors too
It works in the LDAP browser software but not in eramba which still only returns the directly added users despite using the same filter…
I was going to look at making the LDAP Filter :Group membership: (&(objectCategory=Person)(memberOf:1.2.840.113556.1.4.1941:=%GROUP%)(!userAccountControl:1.2.840.113556.1.4.803:=2))
where userAccountControl part will eliminate AD disabled accounts. But, although it does eliminate disabled accounts in my LDAP browser the disabled accounts didn’t show in the list of users pulled by eramba even before that bit was added.
So…
One problem fixed (thank you)
and 2 new ones found to take its place
One more thing I’ve found is that when I removed an account from a group in AD that account remained in the returned list of group members in eramba for more than 30 minutes (and it still showing) despite not showing as a member in AD, my LDAP browser or dsget group output. I confirmed that the LDAP browser connection and eramba were both pointing to the same DC so it should not be a replication delay issue. I’ve logged out or eramba and logged back in again but still the user I removed is being displayed in the array of users returned by eramba .
It was returning correct values before I got to clear the cache. I’ll remember to try that next time.
This appears to work well
“LDAP Filter: List of Groups” - (&(objectCategory=group)(cn=eramba))
“LDAP Attribute: Group Name” - distinguishedName
“LDAP Filter: Group membership” - (&(objectCategory=Person)(memberOf:1.2.840.113556.1.4.1941:=%GROUP%)(userAccountControl=66048))
It returns only groups that contain eramba in their cn (didn’t work with wildcards on the dn). This means I don’t have to search through all the other groups relating to file permissions etc
It returns direct members of a group and members of subgroups
It filters out disabled users (eramba didn’t like the (!userAccountControl:1.2.840.113556.1.4.803:=2) throwing an invalid filter error despite it working elsewhere)
