Notes on IT (mainly Microsoft)

Adding BUILTIN\Administrators to AD LDS (ADAM) Administrators

leave a comment »

It’s often a good fall back to have BUILTIN\Administrators (BA) as a member of the Administrators role in an AD LDS or ADAM installation. A use case for this was in ADAM releases prior to AD LDS when you wanted to take a copy of an ADAM instance to a test server, and having BA in the Administrators role made that backup portable (i.e. not dependent on whatever local account had been used as the ADAM Administrator on the machine from which the backup was taken); in AD LDS spinning up a test copy is best done by taking a snapshot.

What does adding a member to a group look like? Well using LDIF the import file would look like:

dn: cn=group1,OU=Groups,O=something,DC=company,DC=com
changetype: modify
add: member
member: cn=fred,OU=people,O=something,DC=company,DC=com

To add BUILTIN\Administrators using an LDIF file, call it AddBA.ldf, we need:

dn: CN=Administrators,CN=Roles,CN=Configuration,DC=X
changetype: modify
add: member
member:: PFNJRD1TLTEtNS0zMi01NDQ+

(avoiding any trailing whitespace at line ends).

The first line in each of the above is just the group object we are adding  a member to but the last lines look very different. The reason for the difference is that in the first (more usual) case we are adding the member we are adding to the group is an object within the directory tree that also contains the group but in the second case we are adding a “foreign” object; the BA group is a native Windows security principal which does not exist within the directory tree rather it is an external construct from the point of view of the directory service (it’s not even an object in another directory tree).

The string PFNJRD1TLTEtNS0zMi01NDQ+ is the Base64 encoding of <SID=S-1-5-32-544> where S-1-5-32-544 is the string SID for the BA group. What’s going on under the hood here is that the member attribute is an “FPO enabled” attribute and when an add operation is made against such an attribute using the form <SID=string SID>, for what would be a distinguishedName, the directory service creates a Foreign Security Principal (FSP) in the FSP container for the directory service and adds a reference to that FSP in the attribute (member in this case). Why the Base64 encoding? It’s to avoid a clash with LDIF  syntax as a line starting “member:<” would be interpreted as an external input URL .

The LDIF above  can be imported using an account that is an ADAM Administrator (into an instance running on port 50002) using:

ldifde -i -f AddBA.ldf -s localhost:50002 -c "CN=Configuration,DC=X" #configurationNamingContext

Performing an ldifde export to the console ( -f con) we can see the result of our work:

ldifde -f con -d "cn=administrators,cn=roles,"#configurationNamingContext -l member -s localhost:50002

Connecting to “localhost:50002”
Logging in as current user using SSPI
Exporting directory to file con
Searching for entries…
Writing out entries.

dn: CN=Administrators,CN=Roles,CN=Configuration,CN={53509D21-E875-451F-9CAF-E52B38D8F666}
changetype: add
member:  CN=S-1-5-32-544,CN=ForeignSecurityPrincipals,CN=Configuration,CN={53509D21-E875-451F-9CAF-E52B38D8F666}


Written by adamsync

May 11, 2012 at 23:16

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: