joeware - never stop exploring... :)

About a year ago I wrote a popular blog post about DN formats available in Active Directory. The article is here –> http://blog.joeware.net/2008/05/03/1226/. Great article if I can believe the feedback because it helps people set up their environment and apps in a more generic way that avoids some of the pitfalls of hardcoding DNs which is an evil UNIXy kind of thing to do… <eg>

In that article I talk about how you can use the various DN formats available in Active Directory for the bind string (obviously for Binding) and for the search base (just as obviously for searching). What I had no idea about that I recently learned after a discussion with a user who emailed me and another discussion with a friend of mine at MSFT is that the special SID/GUID methods of specifying a DN can also be used in the LDAP query filters (need I say also obviously for searching)…

You may be thinking… ah yeah… so? Big deal? How about posting some more pictures of your house and what you have gotten done in the last year or so ya git???

Well it can be a big deal for some folks… Think of the following scenario… You have some application or device that needs to locate people based on some group membership or possibly the manager or some other DN based field (specifically attribute syntaxes 2.5.5.1, 2.5.5.7, and 2.5.5.14) but the first part of the query is pretty much hardcoded … For example… They tell you the query is

(&(objectcategory=person)(objectclass=user)(memberof=%GROUPDN%))[1]

so you have to specify a group DN like cn=somegroup,cn=users,dc=test,dc=local and then think, crap, I can never change that group DN now without fixing this hardcoded piece… Or worse, you are specifying a DN for a user… Or even worse, later on down the road your predecessor changes it and all hell breaks loose and they haven’t the foggiest clue how to fix it and tell everyone the previous admin was an idiot… or maybe the idio… err person you replaced did it and you change it and bam you break! That sucks… Seriously.

So how can you get around that… By specifying the group (or person or whatever) by its GUID… You could also do it by its SID, but if you specify by GUID, you can even move the group/user to another domain without keeping sIDHistory and you will be good…

So instead of

(memberof=cn=somegroup,cn=users,dc=test,dc=local)

or would instead specify

(memberof=<GUID=ADCC0217-5535-4E17-85CB-67DAD4635C3F>)

Or maybe your app is looking for everyone under a certain manager…

(manager=<GUID=ADCC0217-5535-4E17-85CB-67DAD4635C3F>)

So for a full blown example with all of the DN coolness in Active Directory used…

So you have to bind with some user X to search some ou Y for all users with manager Z and the application has been kind enough to make it so you only enter the bind DN, the bind password, the search Base DN, and the manager’s DN and it does the rest… This would normally look like

• Bind DN: cn=sillyapp,ou=serviceids,dc=test,dc=local
• Bind Password: ThisAppDoesNotRock011235813213455
• Search Base DN: ou=mi,ou=us,ou=grunts,dc=test,dc=local
• Manager DN: ou=fatexec,ou=easystreet,dc=test,dc=local

So then you have multiple ways this can break and require reconfiguration, some of which include…

• The sillyapp ID gets renamed
• The sillyapp ID gets moved to ou=legacycrap,ou=appids,dc=test,dc=local
• The search base gets changed to ou=mi,ou=us,ou=cherishedpartners,dc=test,dc=local[2]
• The fatexec ID parent DN gets changed to ou=wereallydowork,dc=test,dc=local
• The domain gets renamed
• And others…

So how could you configure this…

• Bind DN: <GUID=AB9C4D61-8F4E-4257-B46E-733CCA31EA4C>
• Bind Password: ThisAppDoesNotRock011235813213455
• Search Base DN: <GUID=79EBB6AE-A181-4D44-9E23-8A941E4117C8>
• Manager DN: <GUID=4EC2E83C-DEFD-4C57-B8D0-4725B3790088>

Now not a single one of the events above or others of a similar vein can break that configuration.

The things that could break you… someone deleting one or more of the IDs or the OU and then recreating with the same name.

     joe

[1] Ok more realistically and what I have seen more than once is if the developers don’t let you modify the entire query it is unfortunately likely that the query looks like (&(objectclass=user)(memberof=%GROUPDN%)) though now with Windows Server 2008 objectclass is indexed so it doesn’t matter.

[2] This would be after the economy gets better and companies realize they may not have been as nice as they could have been with the people who produce, ship, or sell their goods.