Adding BUILTIN\Administrators to AD LDS (ADAM) Administrators
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:
To add BUILTIN\Administrators using an LDIF file, call it AddBA.ldf, we need:
(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.