Notes on IT (mainly Microsoft)

Archive for the ‘ldifde’ Category

Structure Rules! NAMING_VIOLATION and Error 0x2099 (The object cannot be added because the parent is not on the list of possible superiors)

leave a comment »

In AD, structure rules determine which parent child relationships are possible amongst instances of classSchema objects and the structure rules are defined by the possSuperiors and systemPossSuperiors attributes of the classSchema objects. Let’s look at the default schema classSchema for an organizationalUnit (OU) in AD LDS:

We should find ourselves unable to create an organizationalUnit with an object that is not listed in systemPossSuperiors as its parent so e.g. we should not be able to create an organizationalUnit beneath a “container” object. Let’s try:

We would see the same if we tried using ldf, the ldf file (ou.ldf) to create the OU would be

dn: ou=test,cn=roles,o=msft
changetype: add
objectClass: organizationalUnit

It’s possible to modify structural rules by modifying possSuperiors for a classSchema object (it has to be possSuperiors rather than systemPossSuperiors as the latter is owned by the system and so can only be specified when the classSchema object is first created), so in our example to add the  container class as possible parent of an OU we could use an ldf (mod-posssuperiors.ldf):

dn: cn=Organizational-Unit,cn=Schema,cn=Configuration,dc=X
changetype: modify
add: possSuperiors
possSuperiors: container

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

The first modify operation is to add container to possSuperiors of Organizational-Unit.
The second modify operation uses a RootDSE modify operation schemaUpdateNow to tell the directory service to update the cached version of the schema so that the first modification can be used immediately.

If we now import this schema modification:

C:\Windows\system32>ldifde -i -f c:\Local\mod-posssuperiors.ldf -s localhost:389 -c “cn=Schema,cn=Configuration,dc=X” #schemaNamingContext

Connecting to “localhost:389”
Logging in as current user using SSPI
Importing directory from file “c:\Local\mod-posssuperiors.ldf”
Loading entries…
2 entries modified successfully.

and now re-run our attempt to create an OU beneath a container:

C:\Windows\system32>ldifde -i -f c:\local\ou.ldf -s localhost:389
Connecting to “localhost:389”
Logging in as current user using SSPI
Importing directory from file “c:\local\ou.ldf”
Loading entries..
1 entry modified successfully.

The same problem is sometimes seen with adamsync where the AD DS objectClass builtinDomain has only domainDNS as a possSuperior, if that objectClass is imported into the AD LDS schema (using ADSchemaAnalyzer) then if an AD LDS partition is created as, say, cn=mysync,o=msoft the attempt to adamsync from the AD DS will fail as it attempts to create a builtinDomain object with a Container as a superior. The fix is as above:

dn: cn=Builtin-Domain,cn=Schema,cn=Configuration,dc=X
changetype: modify
add: possSuperiors
possSuperiors: container

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

Advertisements

Written by adamsync

June 22, 2012 at 00:51

How to find out which naming contexts and application partitions are hosted by an AD LDS instance

leave a comment »

Suppose we have an AD LDS instance running on localhost port 389. What naming contexts does it hold?

The naming contexts can be enumerated by retrieving namingContexts attribute of the RootDSE of the AD LDS instance:

 

Powershell:

PS C:\Users\Administrator> (Get-ADRootDSE -Server localhost:389).namingContexts

CN=Configuration,CN={0FF76061-6F79-4DF9-AA3F-58239ED6EEA2}
CN=Schema,CN=Configuration,CN={0FF76061-6F79-4DF9-AA3F-58239ED6EEA2}
O=msft

or

ldifde:

C:\Windows\system32>ldifde -f con -s localhost:389 -d “” -p base -l namingContexts

Connecting to “localhost:389”
Logging in as current user using SSPI
Exporting directory to file con
Searching for entries…
Writing out entries.dn:
changetype: add
namingContexts: CN=Configuration,CN={0FF76061-6F79-4DF9-AA3F-58239ED6EEA2}
namingContexts:
CN=Schema,CN=Configuration,CN={0FF76061-6F79-4DF9-AA3F-58239ED6EEA2}
namingContexts: O=msft

1 entries exported

The command has completed successfully

To see the namingContexts in a GUI tool run:

ldp.exe localhost:389

and look for the namingContexts attribute in the right hand pane:

Written by adamsync

June 21, 2012 at 22:57

How to determine AD Schema Version from the command line using PowerShell, ldifde or repadmin

leave a comment »

The version of the Schema in use by AD DS and AD LDS (ADAM) is to be found in the objectVersion attribute of the Schema Naming context and as such can be determined by navigating to the Schema Naming context using say ADSIedit or ldp.exe. From the command line we can use the Active Directory powershell module or ldifde or repadmin:

The commands above were run on a DC hence localhost:389, substitute the DC name as required. Repadmin and ldifde were run in the PowerShell window but could just be run from the command line on any device with AD DS tools installed.

Written by adamsync

May 27, 2012 at 18:09

Adding Users to AD LDS (ADAM) Readers Role

leave a comment »

There are three default Roles (groups) in an application partition in an AD LDS (ADAM) instance:

  • Administrators
  • Readers
  • Users

Let’s look the permissions of the Readers role (the application partition here is o=msft) using the Security UI in ldp.exe:

or using dsacls.exe:

The Readers role is empty by default, individual users or groups within AD LDS can be added by distinguishedName to the member attribute of the group.

The following ldf adds (nests) the Users role in AD LDS into the Readers role:

dn: CN=Readers,CN=Roles,O=msft
changetype: modify
add: member
member: CN=Users,CN=Roles,O=msft

placed in a file UserstoReaders.ldf and imported with

ldifde -i -f UserstoReaders.ldf -s localhost:389

from a command prompt on the AD LDS instance with the instance running on port 389.
As a result all AD LDS users would have Readers permission on the instance.

If we want to allow Windows/Domain users that can authenticate to the AD LDS instance to have Readers permissions then we can add the security identifier for Authenticated Users (SID: S-1-5-11) to the group as with the following ldf

dn: CN=Readers,CN=Roles,O=msft
changetype: modify
add: member
member:: PFNJRD1TLTEtNS0xMT4=

The Base64 encoding of the member attribute is explained here.

Written by adamsync

May 23, 2012 at 22:27

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