NAMING_VIOLATION Fehler 0x2099 beim Anlegen von OUs in AD LDS

Nach der Installation einer AD LDS Instanz und der Konfiguration einer Partition bin ich auf ein Problem gestoßen, dass ich innerhalb der Struktur keine OUs anlegen konnte. Ein Anlegen der OU per ldp.exe ist mit folgendem Fehlerbild fehlgeschlagen (im folgenden Beispiel lautet der Distinguished Name meiner Partition CN=external,DC=company,DC=local):

Error: Add: Naming Violation. <64>
Server error: 00002099: NameErr: DSID-030510C6, problem 2005 (NAMING_VIOLATION), data 0, best macht of:
   'CN=external,DC=company,DC=local'

Error 0x2099 The object cannot be added because the parent is not on the list of possible superiors.

Der Import einer LDF Datei gibt einen ähnlich lautenden Fehler aus.

Wie der Fehler schon sagt, ist es nicht erlaubt, OUs innerhalb von Containern anzulegen. Ursache hierfür sind die Structure Rules in AD LDS. Sie definieren, welche Parent-Child Beziehungen zwischen classSchema Objekten in AD LDS Instanzen möglich sind. Structure Rules werden definiert durch die Attribute possSuperiors und systemPossSuperiors des jeweiligen classSchema Objekts. Das Standard-Schema classSchema für Organisationseinheiten (OUs) in AD LDS sieht wie folgt aus:

cn: Organizational-Unit
ldapDisplayName: organizationalUnit
governsId: 2.5.6.5
objectClassCategory: 1
rdnAttId: ou
subClassOf: top
systemMustContain: ou
systemMayContain: x121Address, userPassword, uPNSuffixes, co, 
  telexNumber, teletexTerminalIdentifier, telephoneNumber, street, st, 
  seeAlso, searchGuide, registeredAddress, preferredDeliveryMethod, 
  postalCode, postalAddress, postOfficeBox, 
  physicalDeliveryOfficeName, managedBy, thumbnailLogo, l, 
  internationalISDNNumber, facsimileTelephoneNumber, 
  destinationIndicator, desktopProfile, defaultGroup, countryCode, c, 
  businessCategory
systemPossSuperiors: country, organization, organizationalUnit,
  domainDNS
schemaIdGuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
defaultSecurityDescriptor: D:S:
defaultHidingValue: FALSE
systemOnly: FALSE
defaultObjectCategory: CN=Organizational-Unit,<SchemaNCDN>
systemFlags: FLAG_SCHEMA_BASE_OBJECT

Wie daran zu erkennen ist, ist Container kein möglicher übergeordneter Objekt-Typ für OUs, d.h. im Umkehrschluss: OUs können nicht unterhalb von Containern angelegt werden. Glücklicherweise können Structural Rules geändert werden, indem das possSuperiors Attribut (nicht das systemPossSuperiors Attribut – dieses ist ein Systemattribut und kann daher nur bei der initialen Anlage des classSchema Objekts spezifiziert werden) für ein classSchema Objekt angepasst wird. Somit können Container als möglicher übergeordneter Objekt-Typ für OUs hinzugefügt werden.

Die Anpassung wird in folgendem Beispiel durch den Import einer LDF-Datei durchgeführt. Der erste Eintrag fügt den Objekt-Typ Container zum Attribut possSuperiors des Objekt-Typ Organizational-Unit hinzu. Der zweite Eintrag führt mittels der RootDSE Modify Operation schemaUpdateNow ein sofortiges Schema Update durch, damit die erste Änderung sofort verwendet werden kann.

# C:\Temp\OrgUnit-possSuperiors.ldf
-
dn: cn=Organizational-Unit,cn=Schema,cn=Configuration,dc=company,dc=local
changetype: modify
add: possSuperiors
possSuperiors: container
–
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

Der Befehl zum Import der LDF Datei lautet wie folgt:

C:\Windows\system32>ldifde -i -f C:\Temp\OrgUnit-possSuperiors.ldf -s localhost:389 -c "cn=Schema,cn=Configuration,dc=company,dc=local" #schemaNamingContext

Connecting to "localhost:389"
Logging in as current user using SSPI
Importing directory from file "C:\Temp\OrgUnit-possSuperiors.ldf"
Loading entries…
2 entries modified successfully.

Ist das Schema angepasst, lassen sich nun OUs innerhalb von Containern anlegen.

Ein ähnliches Problem tritt gelegentlich in Kombination mit ADAM-Sync auf, also wenn Objekte vom Active Directory in eine AD LDS Instanz synchronisiert werden.

Beipiel:
Ich möchte meine AD Domain DC=company,DC=com in meine AD LDS Partition CN=external,DC=company,DC=local synchronisieren. Dabei wird das builtinDomain Objekt angelegt. Dies schlägt fehl, weil die builtinDomain Objekt-Klasse nur über die Objekt-Klasse domainDNS als possSuperior Attribut verfügt. Damit ADAM-Sync funktioniert, muss auch hierfür der Objekt-Typ container als possSuperior konfiguriert werden:

# C:\Temp\BuiltinDomain-possSuperiors.ldf
-
dn: cn=Builtin-Domain,cn=Schema,cn=Configuration,dc=company,dc=local
changetype: modify
add: possSuperiors
possSuperiors: container
–
dn: 
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1