6

We are seeing an odd issue with Active Directory LDAP querying.

The situation is: We have a security group in a given OU. That security group needs to move to a totally different OU.

We have an application that uses LDAP to authenticate against AD, and it queries using the Active Directory LDAP_MATCHING_RULE_IN_CHAIN, so that it supports embedded groups:

(memberOf:1.2.840.113556.1.4.1941:=CN=SystemAdministrators,OU=SA Users,OU=System Administrators,OU=Departments,DC=ds,DC=example,DC=com)

An example query would be:

ldapsearch -LLL -x -W -H 'ldap://ny-dc02.ds.example.com:389' -D '[binding account details]' -b 'OU=Departments,DC=ds,DC=example,DC=com' '(memberOf:1.2.840.113556.1.4.1941:=CN=SystemAdministrators,OU=SA Users,OU=System Administrators,OU=Departments,DC=ds,DC=example,DC=com)' dn

It returns a full list of users that belong to the requested OU - as expected.

However, if we move that group out of Departments\System Administrators and into Security Groups\System Administration (and update the query appropriately):

(memberOf:1.2.840.113556.1.4.1941:=CN=SystemAdministrators,OU=System Administration,OU=Security Groups,DC=ds,DC=example,DC=com)

for example:

ldapsearch -LLL -x -W -H 'ldap://ny-dc02.ds.example.com:389' -D '[binding account details]' -b 'OU=Security Groups,DC=ds,DC=example,DC=com' '(memberOf:1.2.840.113556.1.4.1941:=CN=SystemAdministrators,OU=System Administration,OU=Security Groups,DC=ds,DC=example,DC=com)' dn

We get no results returned at all from LDAP Search.

Our first thought was "Oh, it's probably caching something". But we left the security group in its new OU for several hours and we still saw the same results.

Has anyone seen anything like this before? Any suggestions on where to troubleshoot next?

11
  • I'd check what is really queried / answered by sniffing the packets. Also: are the GUIDs (+ the rest of the AD attributes) updated in AD? Or are they staying the same? Are you able to query a newly created user in the new OU?
    – Lenniey
    Jul 5, 2017 at 14:31
  • @Lenniey Packet capture confirms the request is as expected. Also, creating a new user and assigning them to that group does not show up in the query either (I can confirm that they show up if I remove the LDAP_MATCHING_RULE_IN_CHAIN parameter though). Jul 5, 2017 at 14:40
  • So, it works as expected without the LDAP_MATCHING_RULE_IN_CHAIN parameter? Well...this is strange. Any differences in the query to the "old" OU besides the OU-name, of course?
    – Lenniey
    Jul 5, 2017 at 15:01
  • @Lenniey correct. As for differences, I honestly couldn't say - they're very old OUs so there's potentially a few differences. Jul 5, 2017 at 15:02
  • 1
    was there any LDAP error code returned? First thing in my mind was that you probably have wrong DN in your query, but then you said it worked if removed the chain option. //// EDIT: so I google the usage of the chain option, noted that the search base is supposed to set to where the USER is located, rather than where the group is (location of group is included already in the option). So regardless where the group is, your search base should remain same (if user wasn't moved).
    – strongline
    Jul 5, 2017 at 18:21

2 Answers 2

5

The search base is supposed to set to where the USER is located, rather than where the group is (location of group is included already in the option). So regardless where the group is, your search base should remain same (if user wasn't moved).

3
  • Hm. Maybe I'm wrong, but as I tested the AD query by moving the group (not the user/s or anything, just the group) my results were exactly the ones I would have expected, like @MarkHenderson. Or maybe the AD/DC included command just behaves differently.
    – Lenniey
    Jul 5, 2017 at 19:27
  • @Lenniey my two OUs are disconnected from each other and thus the search base. Did the search base include both of the OUs you tested with? Jul 5, 2017 at 19:58
  • @MarkHenderson Yeah, that's why I'm so confused :)
    – Lenniey
    Jul 5, 2017 at 20:10
0

What about permissions. Does the application have permission to search in the new OU? I would look at the effective rights on the old and new OUs.

Also, i would confirm that the new location is actually an OU. it is possible to create "Container" objects in AD, much like the "Users" container is not an OU. As such the DN would change from: CN=SystemAdministrators,OU=System Administration,OU=Security Groups,DC=ds,DC=example,DC=com to: CN=SystemAdministrators,CN=System Administration,OU=Security Groups,DC=ds,DC=example,DC=com

1
  • Permissions were correct. The moment I changed the search root, the query worked exactly as it should. It looks like it was a bug in the application code that assumed the users would live in the same OU tree as the group. Jul 6, 2017 at 19:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .