I have mentioned the term, “real-world example”, a few times on my site now. I feel that it is important to provide these examples because they are the ones that provide the highest opportunity for learning. Do not misread me here for I am not saying book examples are not helpful; book examples are helpful, but only take you so far. I prefer these real-world examples to help round out the experience quotient.
This real-world example relates to LDAP search filters in Active Directory. In a number of the installations I do for the product I support, just about every AD environment has a need to get group membership. Unfortunately, there is a number of these environments that would benefit greatly from the ability to simply find users based upon the OU (organizational unit) in which they reside. Unfortunately, the latter is not possible within Active Directory within the confines of an LDAP search filter.
Within Active Directory, I can search any group ”memberOf” attribute for a list of the users within. You would think the same would be possible (easily possible, I might add) with OU affiliation. I found out the hard way that this is not possible. Just imagine sitting with a customer and saying, “OU-based search…should not be a problem at all. I will whip up the search filter in no time.” Fast forward an hour and I was still sitting there trying to Jedi-force Google to give me something more than, “No, you silly man, you cannot do this.”
To not belabor the point any further and potentially bore you to bloody tears, I shall impart my knowledge about why it simply will not work.
If you look at a user object in Active Directory (ADSI Edit on 2003 or the Attribute Editor in 2008), you will notice that there is no attribute pointing to the OU in which he/she/it resides apart from distinguishedName. Unfortunately, distinguishedName will only give you the full path of where the user resides in AD and nothing that would be remotely usable in an LDAP search filter. With this information in mind, you can see how it would be frustratingly impossible to do a simple search for users in an OU.
What do you do about this, you ask? Well, you can always tell Microsoft to simply add a possible, single-valued attribute for “memberOfOU”. Additionally, if the application you are using supports more than just your standard LDAP search filter (think scripts and code), then you could always get the OU membership for users. Unfortunately, I like standards and being able to find things with LDAP search filters (so does the product I support). Finally, you can attempt to find a common attribute value that is populated for only the users in the OU to aid you in your LDAP search filter efforts. Again, I would much rather forgo a workaround in lieu of the solution I had intended.
Note: Caveat in this scenario is that I am using the base dn of the domain controller for a large search scope. Limiting the search scope to the OU would most certainly work, but also exclude a number of users who should also be found in other areas of my product.
