Recently my friend wrote simple app which is querying AD for some data, and he sent me LDAP filter to check – this filter was completely OK, but not very straightforward to read. Yesterday I came across similar usage of objectCategory attribute in LDAP filter, and I don't think it was used in this way intentionally, so I decided to give this topic some space on this blog.
What's this all about. Lets look at following LDAP filter string:
Question: What category will be object returned by this filter? At first glance the answer may seems to be obvious – Contact. But lets look at ADFind statistics:
Surprised? Probably most of You isn't really surprised. If we will check definition of objectCategory in schema we will see that it is DN, and in correct format for LDAP filter we should use full DN for object class we are willing to use. Active Directory search engine simplifies this task a little and it allows usage of LDAP display name of class in such filter. If we will use only display name, it will go to this class definition and will pick up its defaultObjectCategory as filter value. For Contact class this means CN=Person,CN=Schema,CN=Configuration,… . So everything about example presented above should be clear now.
Using class display name in filter is OK, but I think it is even better if we are using it and we are aware what is under the hood of such query. That's why this post was created.