Potentielle Gefährdung des Schemas durch manuellen LDIF Import
Hallo, es meldet sich mal wieder der Herbert!
Man passt darauf auf wie auf seinen Augapfel, und steckt doch unbedacht einen Balken rein...
Diese Aussage frei nach dem neuen Testament ist uns bei mittlerweile vier Kunden in den Sinn gekommen.
Es ist ja hinlänglich bekannt, dass das Schema einer der wichtigsten Grundlagen für das Active Directory darstellt und daher sehr vorsichtig mit entsprechenden Änderungen umgegangen werden muss.
Dennoch gibt es scheinbar immer wieder Situationen bei denen ein Administrator dazu verleitet wird, anstatt über ADPREP /FORESTPREP oder /DOMAINPREP zu verwenden, die Schema LDIF Dateien komplett oder teilweise manuell zu importieren. Dabei findet jedoch nicht die Vorbereitung und Fehler/Konsistenzprüfung statt wie durch ADPREP. Der manuelle Import an sich mag dann erfolgreich gelaufen sein - das bedeutet aber nicht gleichzeitig, dass der Import auch als Schema Upgrade korrekt abgeschlossen ist.
Oft vergehen dann bis zu Jahren zwischen diesem Schema Update und dem Einsatz des ersten Domänen Controllers, der das neue Schema Level auch wirklich benötigt. Erst dann zeigt sich, ob das Schema ordnungsgemäß erweitert worden ist – oder eben nicht. Im Hinblick auf die sinnvolle Möglichkeit eine Forest Restores ist das schon mall eine ganz schlechte Ausgangsposition – wer hat schon Backup aus dieser Zeit und wenn ja, wer kann sich erlauben die Änderungen seither zu verwerfen?!
Bei der Schema Erweiterung mit ADPREP /FORESTPREP wird zunächst der Schema Master in den „System Schema Update Mode“ gesetzt. Das erlaubt das Ändern und Erstellen von „Category 1“ Objekten. Ist das nicht der Fall, so können auch keine relevanten System-Kritischen Attribute gesetzt werden.
Für diese Category 1 Objekte ist das Schema Attribut SystemFlags Bit mit Wert 16 enthalten.
Referenz: System-Flags Attribute (Windows);
https://msdn.microsoft.com/en-us/library/ms680022(VS.85).aspx
16 (0x00000010) When set, indicates the object is a category 1 object. A category 1 object is a class or attribute that is included in the base schema included with the system.
Hierzu noch weitere Schema Regeln, wenn der Import nicht im Kontext von ADPREP abläuft:
- SystemFlags bitfield 16 (0x10) cannot be set or cleared.
- SystemMayContain and SystemMustContain attributes cannot be changed.
- SystemPossSuperiors attribute cannot be changed.
- schemaFlagsEx is not set on new schema objects.
- msDS-IntId will be given to new attributes as the column number. System attributes are bound to pre-defined column numbers.
Wenn das durch den manuellen LDIF Import nicht sauber umgesetzt ist, kann das zu unerwarteten Ergebnissen führen. Die besten Indikatoren sind, dass SystemFlags den Wert 0 hat und der Wert msDS-IntId gesetzt ist, wie für eine 3rd Party Erweiterung. Ein Category 1 Objekt mit SystemFlags Bit 16 hat msDS-IntId nicht gesetzt.
Hier haben wir zwei Beispiele wie sowas richtig in die Hose gehen kann und was die Seiteneffekte sein können. Nach dem manuellen LDIF Import der Windows Server 2008 Schema Dateien war in beiden Fällen mit Windows 2003 DCs erst mal kein Fehler zu sehen. Replikation und alle Domänen Dienste liefen fehlerfrei – und zwar über einen sehr langen Zeitraum. Kaum bringt man aber nun die ersten neuen Domänen Controller in die Umgebung, die auf den korrekten Schema Upgrade angewiesen sind, gehen die Probleme los…
1) Bei DCPRO0MO von Windows Server 2008 kommt der Fehler sobald die Replikation für den Konfiguration Container anläuft.
DCPromo.log:
[INFO] Error - Active Directory Domain Services could not replicate the directory partition CN=Configuration,DC=contoso,DC=com from the remote Active Directory Domain Controller W2k3_DC.contoso.com. (8451)
(Fehlercode 8451 = ERROR_DS_DRA_DB_ERROR „The replication operation encountered a database error.”)
Die hard-coded interne columnID war nicht vorhanden. Ein Windows Server 2008 DC kann dann gar nicht erst promotet werden. Indikator ist hier „systemFlags: 0“, bei einem validen ADPREP wäre es „systemFlags: 17“ gewesen, als auch ein Wert für msDS-IntId.
LDIFDE Ausgabe vom Fehlerfall:
dn: CN=ms-DS-NC-Type,CN=Schema,CN=Configuration,DC=contoso,DC=com
attributeID: 1.2.840.113556.1.4.2024
searchFlags: 0
lDAPDisplayName: msDS-NcType
systemOnly: TRUE
systemFlags: 0
msDS-IntId: -1888730076
richtig wäre jedoch:
dn: CN=ms-DS-NC-Type,CN=Schema,CN=Configuration,DC=contoso,DC=com
attributeID: 1.2.840.113556.1.4.2024
searchFlags: 0
lDAPDisplayName: msDS-NcType
systemOnly: TRUE
systemFlags: 17
2) Das DCPROMO läuft zwar durch, jedoch startet der KDC nicht.
Service Control Manager Error 7023:
"The Kerberos Key Distribution Center service terminated with the following error: 1450"
(Fehlercode 1450 = ERROR_NO_SYSTEM_RESOURCES „Insufficient system resources exist to complete the requested service”.)
Der Fehlercode ist dann leider auch noch generisch und führt dann erst mal zur Suche nach einem Memory Engpass.
Es gibt auch ein KDC Fehler Event 7 mit dem Text:
"The Security Account Manager failed a KDC request in an unexpected way. The error is in the data field. The account name was krbtgt and lookup type 0x8."
Den genauen Fehler kann man auch nur im Debug erkennen, er ist STATUS_DS_ATTRIBUTE_TYPE_UNDEFINED „The attribute type specified to the directory service is not defined“. Es passiert beim Lesen des krbtgt Kontos.
Ausschlaggebend war hier folgendes Schema Attribut:
dn: CN=ms-DS-Supported-Encryption-Types,CN=Schema,CN=Configuration,DC=contoso,DC=com
attributeID: 1.2.840.113556.1.4.1963
searchFlags: 0
systemOnly: FALSE
systemFlags: 0msDS-IntId: -1883143034
Also auch hier das gleiche Bild.
Manchmal kann man im Schema Upgrade Log schupgr.log auch sehen, dass zumindest der Schema Upgrade über APDREP versucht wurde, jedoch nicht erfolgreich:
Current Schema Version is 31
Upgrading schema to version 47
The command line passed to ldifde is C:\WINNT\system32\ldifde -i -f C:\WINNT\system32\sch32.ldf -s DC2 -c DC=X DC=contoso,DC=com -j .
ERROR: Waiting for ldifde to complete failed: 6
Um nun um diesen Fehler herum zu arbeiten, wurde dann der manuelle LDIF vorgenommen – nachweislich keine gute Idee.
Wie kommt man nun aus der Situation wieder heraus? Hier gibt es diese Optionen:
- Forest Disaster Recovery - nur sinnvoll, wenn zwischen den Backups vor dem Schema Upgrade nicht zu viel Zeit vergangen ist UND Backups von DCs aus allen Domänen verfügbar sind.
- Forest Migration - Überführung der alten Umgebung in einen Forest mit gesundem Schema.
Wir haben nicht unsere Service-Umsätze im Kopf, wenn wir sagen, dass das eine Situation ist, bei der man sich von den Experten des Microsoft technischen Kundensupport beraten lassen sollte.
Man klar also klar erkennen, dass die Lösungen allesamt enorm aufwändig sind! Also besser von Anfang an – Hände weg von System Schema Upgrades durch manuelles Importieren.
Also das Schema lieber bewachen wie die Kronjuwelen...
Schöne Grüße,
Herbert Mauerer
Comments
Anonymous
October 29, 2010
Ohne Frage, Herbert ist der unangefochtene AD Guru. Viele Grüße aus ShanghaiAnonymous
November 22, 2010
Großartiger Artikel - mit sehr vielen Zusatzinformationen, an die man sonst nicht "so einfach" herankommt. Danke!