none
LDAP Query - Using an Either statement with a NOT statement

    Question

  • Hello,

    Just a quick question this time!

    I'm trying to refine a search string I setup a while ago, to exclude members of an OU, the issue is that my LDAP search string already uses an EITHER statement.

    The current code:

    (&(objectCategory=person)(objectClass=user)(|(employeenumber=*)(info=*contractor*)))

    So it grabs all users with an employee number or 'contractor' in their info field.

    Now, I'd like to exclude users from a Quest OU. However everything I've tried doesn't seem to work... The closest I've gotten:

    (&(objectCategory=person)(objectClass=user)(!(OU=*Quest*)(|(employeenumber=*)(info=*contractor*))))Any input would be highly appreciated!


    • Edited by Dyspare Saturday, July 20, 2013 6:40 AM
    Saturday, July 20, 2013 6:39 AM

Answers

  • The issue is that the wildcard character, "*", is not allowed in DN attributes, like distinguishedName. As noted, there is no OU attribute for users (there is for OU objects). The clause (!distinguishedName=*,OU=Quest,*) is what you are looking for, but this results in nothing being returned. This issue has come up many times, but there is not solution. You should be able to specify the "base" of the query, but then you cannot exclude any child OU's in the base.


    Richard Mueller - MVP Directory Services

    Saturday, July 20, 2013 12:02 PM
    Moderator

All replies

  • You cannot match on OU.  OU is not an attribute.


    ¯\_(ツ)_/¯

    Saturday, July 20, 2013 7:04 AM
  • The issue is that the wildcard character, "*", is not allowed in DN attributes, like distinguishedName. As noted, there is no OU attribute for users (there is for OU objects). The clause (!distinguishedName=*,OU=Quest,*) is what you are looking for, but this results in nothing being returned. This issue has come up many times, but there is not solution. You should be able to specify the "base" of the query, but then you cannot exclude any child OU's in the base.


    Richard Mueller - MVP Directory Services

    Saturday, July 20, 2013 12:02 PM
    Moderator
  • You can, of course, filter the results yourself after the query returns objects which may or may not be in the Quest OU.  It would be better to filter on the AD side, if it were possible, but the end result is the same (just a bit slower).
    Saturday, July 20, 2013 1:35 PM
  • How to eliminate an OU from a search:

    ([adsisearcher]'(&(objectclass=organizationalunit)(!name=testou))').FindAll()

    Note that this will return all OUs not name 'testou'.  You can add a list to include or to exclude.  Feed this into a search one out at a time.  This will save bringing back all objects to filter out some.  Say an OU has 5000 users in its subtree.  Filtering this on the client might take some time.  By just retrieving the OUs you want you will avoid this.

    It is not as selective as an 'either' style of statement but this information can be leveraged in a number of ways.

    Also this method works:

    ([adsisearcher]'(!OU=SBSServers)').FindAll()

    ([adsisearcher]'objectclass=organizationalunit').FindAll()|%{$_.Properties['ou']}

    The issue is that it will select all OUs with that name.  This may be an issue since OUs on different paths can have the same name if that is what your company has decided on.

    In other versions of LDAP the use of parent references is allowed which is what you really want to do here:

    (!parentOU=OU=some,dc=dom,dc-com)

    Read I like this: [   (! parentOU="OU=some,dc=dom,dc-com)"   ]

    The quotes are for showing where the  assignment works.  It threw me at first until I found a test Unix box where that syntax worked and realized that everything after the first equal sign was taken as the value even though there are multiple equal signs.

    MS syntax does not yet allow that although it is part of the latest version of the RFC. (don't hold me to the parentOU part.  The structure is correct but I forgot what the containment reference was)


    ¯\_(ツ)_/¯

    Saturday, July 20, 2013 2:25 PM