CODEWITHSUNDEEP
active-directoryldap
DrStalker
DrStalker

Reputation: 9571

How to use a filter to avoid a sub OU in Active Directory?

I have an application that pulls user information from an OU in Active Directory. The parameters it takes are a base for the search and a filter string.

I have an OU I want to pull information from, but there is a sub OU I want to avoid:

Wanted

users from OU=People,DC=mydomain,DC=com

Not Wanted

users from OU=Evil,OU=People,DC=mydomain,DC=com

I know that this could be done by rewriting the application performing teh import to stop it searching sub-OUs, but is there any way to do this with an LDAP filter on the search? Something like (DistinguishedName !contains "Evil") or similar that will let me exclude users based on the path to the user, rather than filtering on a property of the user.

Upvotes: 21

Views: 122825

Answers (5)

esk
esk

Reputation: 196

AFAICT, this cannot be done with an LDAP filter in active directory. Many other LDAP implementations support extensible matching, but AD does not.

Users recommending filters containing (ou:dn:=Evil) or wildcards on distinguishedName have not tested against Active Directory.

Upvotes: 14

Per Noalt
Per Noalt

Reputation: 5102

If you're using System.DirectoryServices(.Protocols) in .NET you could set the SearchScope to OneLevel to only search in the People-OU (and no child-OUs). But that won't work if you have any OU=Good,OU=People,DC=mydomain,DC=com...

The second option would be to query the People-OU for all sub-OU:s (objectClass=organizationalUnit) and then issue multiple search requests; one for each of them (except the "Evil" one).

Edit: @geoffc - that will be really difficult to implement. By default all authenticated users have read access to all objects in Active Directory. Just setting a "Deny Read" on the Evil OU won't do the trick because the read right for authenticated users is set on the individual user object (in this case) and thus has precedence over the Deny ACL set on the OU. You will essentially have to set the Deny Read ACL on each of the objects in the Evil-OU and always make sure new objects added to the directory get the same Deny rights set. You could edit the Active Directory schema and remove the rights for Authenticated Users but that will break a lot of other things (including Exchange) and is not supported by Microsoft.

Upvotes: 14

Louis Reedijk
Louis Reedijk

Reputation: 79

The following will do the trick:

(&(objectClass=user)(!(distinguishedName:=%Evil%)))

I ran into a similar problem while building an address book for scan to e-mail. I tried (&(objectClass=user)(!(distinguishedName:=*Evil*))) but it seems that some MFP's don't accept * as a wildcard, but they do accept %

Upvotes: 7

Ben Klang
Ben Klang

Reputation: 306

According to http://www.zytrax.com/books/ldap/apa/component.html, it's possible to get what you want using LDAP Component Filters. Here's an example that would match what you describe:

(&(objectClass=organizationalUnit)(!(ou:dn:=Evil)))

This matches all objects who have an objectClass of organizationUnit, but rejects anything whose DN contains a component that matches ou=Evil.

Upvotes: 3

Terry Gardner
Terry Gardner

Reputation: 11134

The objectClasses organizationalUnit and its descendant inetOrgPerson allow the attribute ou to be present in an entry. Add an ou attribute with value evil to the objects subordinate to the ou=evil branch and include the assertion (!(ou=evil)) to the search filter to limit responses from the candidate list to those that do not contain an attribute ou with the value evil. Alternatively, the LDAP Assertion Control could be used on requests in the same fashion to ensure that requests that contain an ou with the value evil are not processed. Professional quality directory servers that are LDAP compliant will support both of these methods.

Upvotes: 1

Related Questions