none
Using LDAP to search attribute bit flags using attribute OID values

    Question

  • Hello everyone,

    My question stems from trying to understand the OID and syntax behind this classic LDAP search to find disabled users:

    "(useraccountcontrol:1.2.840.113556.1.4.803:=2)"

    What I am interested in is the value 1.2.840.113556.1.4.803, specifically how it differentiates from the value 1.2.840.113556.1.4.8, which is the OID of the useraccountcontrol attribute:

    http://msdn.microsoft.com/en-us/library/ms680832(v=vs.85).aspx

    Now, this website below says that the 03 and 04 are designators of the AND and OR operations, respectively, and are added on to the end of the OID:

    https://www.appliedtrust.com/blog/2011/04/keeping-your-active-directory-pantry-order

    However, using this logic, I can't get these 03 and 04 operators to work with other attribute OID's that use flags as values, such as the "searchflags" attribute, e.g. a LDAP search of "(searchflags:=1.2.840.113556.1.2.33404:=0) returns nothing, using the OR (04) operation at the end of the "searchflags" OID of 1.2.840.113556.1.2.334.

    So back to my original question, for the useraccountcontrol OID of 1.2.840.113556.1.4.8, is this OID at all related to the bitwise AND extensible match of 1.2.840.113556.1.4.803 (like just adding a 03 to designate an AND operation), or is this extensible match value of 1.2.840.113556.1.4.803 completely separate from the useraccountcontrol OID of 1.2.840.113556.1.4.8?

    If I have my terms mixed up, please feel free to correct me on what the proper terms are.

    Thanks!


    • Edited by KentYeabower Monday, June 09, 2014 8:53 PM adding hyperlink
    Monday, June 09, 2014 8:50 PM

Answers

  • Those are hardcoded OIDs as peer:

    Capability name

    OID

    LDAP_MATCHING_RULE_BIT_AND

    1.2.840.113556.1.4.803

    LDAP_MATCHING_RULE_BIT_OR

    1.2.840.113556.1.4.804

    LDAP_MATCHING_RULE_TRANSITIVE_EVAL

    1.2.840.113556.1.4.1941

    LDAP_MATCHING_RULE_DN_WITH_DATA

    1.2.840.113556.1.4.2253

    See the following article for more information:
    http://msdn.microsoft.com/en-us/library/cc223367.aspx

    For example if you want to bitwise AND query the searchFlags it would be like:

    searchflags:1.2.840.113556.1.4.803:=512

    The syntax is attr:oneoftheaboveOIDs:=value


    Enfo Zipper
    Christoffer Andersson – Principal Advisor
    http://blogs.chrisse.se - Directory Services Blog

    • Marked as answer by KentYeabower Tuesday, June 17, 2014 7:45 PM
    Wednesday, June 11, 2014 12:52 AM

All replies

  • Bump
    Tuesday, June 10, 2014 9:57 PM
  • Those are hardcoded OIDs as peer:

    Capability name

    OID

    LDAP_MATCHING_RULE_BIT_AND

    1.2.840.113556.1.4.803

    LDAP_MATCHING_RULE_BIT_OR

    1.2.840.113556.1.4.804

    LDAP_MATCHING_RULE_TRANSITIVE_EVAL

    1.2.840.113556.1.4.1941

    LDAP_MATCHING_RULE_DN_WITH_DATA

    1.2.840.113556.1.4.2253

    See the following article for more information:
    http://msdn.microsoft.com/en-us/library/cc223367.aspx

    For example if you want to bitwise AND query the searchFlags it would be like:

    searchflags:1.2.840.113556.1.4.803:=512

    The syntax is attr:oneoftheaboveOIDs:=value


    Enfo Zipper
    Christoffer Andersson – Principal Advisor
    http://blogs.chrisse.se - Directory Services Blog

    • Marked as answer by KentYeabower Tuesday, June 17, 2014 7:45 PM
    Wednesday, June 11, 2014 12:52 AM
  • Hmm yeah I posted that link above in my OP as well, and I was hoping that the OID values of these bitwise filters were somehow related to the shorter OID of the "useraccountcontrol" attribute, but it looks like it's just a coincidence.

    So I wonder if the "useraccountcontrol" section of this article from my OP is a little misleading when it says:

    To make a comparison, we either need to use the LDAP_MATCHING_RULE_BIT_AND rule (1.2.840.113556.1.4.803), or the LDAP_MATCHING_RULE_BIT_OR rule (1.2.840.113556.1.4.804) for our attribute OID (the AND rule adds a 03 suffix to denote the AND operation, and the OR rule adds a 04 suffix).

    Following this logic, I should be able to use the "03" and "04" in other bitwise operations with different OID's to search "AND" or "OR", but as I pointed out in my OP above, I can't seem to make this work with adding the 
    "03" and "04" onto the end of other OID's. So I will go with Christoffer that these bitwise OID's (1.2.840.113556.1.4.803 and 1.2.840.113556.1.4.804) are unique in themselves, and the fact that they are 2 characters away from the OID of the "useraccountcontrol" attribute (1.2.840.113556.1.4.8) is just coincidence.

    This does seem strange however, and it seems like there should be some correlation here....

    If anyone has any more info, I would love to hear it!

    Tuesday, June 17, 2014 7:37 PM
  • OIDs form a hierarchical namespace.  1.2.840.113556 is Microsoft's OID, so anything defined by Microsoft will be under that.  1.2.840.113556.1.4 is an OID allocated to the Active Directory group inside Microsoft, so things that group defined will often end up there, as did useraccountcontrol(8) and the matching rules (803 and 804).  No deep mystery.

    DonH

    Thursday, March 17, 2016 2:20 PM