joeware - never stop exploring... :)

You may have read my other post on using the SID/GUID alternate formats for DNs for queries and my post last year on using alternate DN formats for binding and searching as well… Here is something else I recently learned that I thought was interesting.

There are actually more alternate DN formats…

All of these formats can be used for the bind string…

http://msdn.microsoft.com/en-us/library/ms676245(VS.85).aspx

 

Dmitri posted them to AD Org as such

ACTIVE DIRECTORY FORMATS

DS_FQDN_1779_NAME,
DS_USER_PRINCIPAL_NAME,
DS_NT4_ACCOUNT_NAME,
DS_CANONICAL_NAME,
DS_UNIQUE_ID_NAME,
DS_DISPLAY_NAME,
DS_SERVICE_PRINCIPAL_NAME,
DS_SID_OR_SID_HISTORY_NAME,
DS_CANONICAL_NAME_EX

and

ADAM FORMATS

DS_FQDN_1779_NAME,
DS_CANONICAL_NAME,
DS_UNIQUE_ID_NAME,
DS_DISPLAY_NAME,
DS_SERVICE_PRINCIPAL_NAME,
DS_SID_OR_SID_HISTORY_NAME,
DS_CANONICAL_NAME_EX,
DS_USER_PRINCIPAL_NAME

So yes… You can even use displayname as the bind DN string but man I would recommend being careful there because there is NOTHING implementing uniqueness and obviously if AD can’t uniquely identify the bind DN it won’t let you authenticate with it.

    joe

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.

I received an email a couple of months ago from someone looking to remove SIDs from a specific domain from the sIDHistory attribute of all of their users. Here is the response I sent

 

So the ability to remove SID’s from sIDHistory is very simple and basic, you basically have to supply the specific SIDs you want removed. The -sc csh shortcut in AdMod relies on the SIDs to be cleared being passed to it from AdFind. So all you need to do is to filter the output from AdFind to the specific SIDs you want cleared versus all SIDs. You do that with the -mvfilter switch… You would specify the domain portion of the SID of the domain that you want to clean the SIDs out for… So say you have a user with a SID of S-1-5-21-1757981266-299502267-1801674531-19235, the domain portion of that SID is S-1-5-21-1757981266-299502267-1801674531. So to filter and just output objects with that SID you will want to add -mvfilter sidhistory=S-1-5-21-1757981266-299502267-1801674531 combined with -recmute to filter out objects that had a sIDHistory value but not from that domain.

You send that info across to AdMod with -adcsv and specify -sc csh and you should be good. I would recommend just running the AdFind command initially to output the objects and the SIDs so you can validate the info prior to clearing it.

Note that clearing the values from sIDHistory is basically one way… Once cleared, the only way to get it back is auth restore of the objects. So be sure you want to clear them. There is no way to arbitrarily stick values in that attribute.

So the whole adfind command for users would look something like

adfind -b search_base -f "&(objectcategory=person)(sidhistory=*)" sidhistory -adcsv -mvfilter sidhistory=domainSID

then combined with AdMod

adfind -b search_base -f "&(objectcategory=person)(sidhistory=*)" sidhistory -adcsv -mvfilter sidhistory=domainSID | admod -sc csh -unsafe

   joe