Notes on IT (mainly Microsoft)

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

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: