Active Directory Schemaerweiterungen

Schemaerweiterungen für Active Directory sind eine heikle Sache. Gerade wenn man sich vorstellt, dass diese Änderungen des AD Schemas die komplette Logik des Active Directorys beeinflussen und möglicherweise auch zum Stillstand von Applikationen führen können.

Ob es nun eine Migration auf eine neue Windows Version der Domaincontroller, Installation von Applikationen wie z.B. Microsoft Exchange oder eigene Schemaerweiterungen sind, im „Worst-Case“ Szenario funktioniert die komplette Authentifizierung, Zugriff und Datenbank inkl. aller angelehnten Applikationen (z.B. Exchange, Lync) nicht mehr. In diesem Fall gibt es nur einen Rollback Plan und dieser wäre ein kompletter authoritativen Restore des Forest. Dieses Vorgehen ist auch bestimmt nicht innerhalb weniger Stunden beendet. Deshalb versuchen wir mit diesem Artikel Klarheit sowie Tips in der Vorgehensweise einer Schemaerweiterung in Active Directory zu bringen.

Vorbereitung:

Datensicherung des kompletten Forests inkl. aller Domains: Dies kann über Windows Boardmitteln über VSS Full Backup geleistet werden. Hierbei sind auch Backups aus mehreren vergangenen Zeitstempeln sowie mehreren Domaincontrollern(GCs) aus verschiedenen Zeitzonen empfohlen
Sicherstellung einer funktionierenden AD Replikation: Prüfen Sie die Active Directory Replikation vorab, sodass nach der Erweiterungen alle Domaincontroller im Forest sauber repliziert werden
Wahl des richtigen Domaincontrollers: Führen Sie die Schemaerweiterung nur auf Domaincontroller aus, auf der die FSMO Rolle „Schema Master“ aktiv funktioniert
Bereitstellen der Berechtigungen: Um eine Schemaerweiterung durchzuführen benötigen Sie Mitglietschaft in der Gruppe der „Schema-Admins“ und „Enterprise-Admins“ für den Account, mit dem sie die Erweiterung durchführen
Zeitpunkt der Schemaerweiterung: Suchen Sie einen Zeitpunkt für die Erweiterung aus, zu der der ausgewählte Schema Master unter weniger Last liegt
Testumgebung: Testen Sie den Vorgang zu aller erst in einer Testumgebung. Bestenfalls mit einem wiederhergestellen Backup aus dem Produktiv-Forest.

Vorgang:

Um nun letztendlich die eigene Schemaerweiterung durchzuführen, benötigt es weniger Schritte. In den meisten Fällen bedarf es nur einer Ausfürhung von CMD-lets oder Auführung eines Wizards. Der eigentliche Prozess dahinter ist sehr komplex. Schemaerweiterung werden im Best Practice auf dem sog. Schema Master, einer FSMO Rolle im Active Directory und nur auf einem Domaincontroller pro Forest aktiv. Nachdem der Befehl der Schemaerweiterung ausgeführt wird, werden die Definitionen im Schema als erstes auf der Schemapartition des Schemamasters vorgenommen. Nachdem diese abgeschlossen sind, werden sie durch die bekannte Active Directory Replikation propagiert.

Hier ist ein erster Eingriff nötig um Fehlerquellen zu erkennen und ein mögliches Rollback vorzunehmen. Dies kann auf folgende Art und Weise adressiert werden:

Methode 1 – Nutzung des Attributs msDSReplicationEpoch:

Dieses Attribut enthält den Wert der aktuelle Replikationsepoche unter der sich Domainconroller mit dem gleichen msDSReplicationEpoch-Wert replizieren. Es befindet sich in den NTDS Settings (AD Sites and Services) eines jeden Domaincontroller. Hier kann z.B. der Integer Wert für den Schemamaster Domaincontroller auf 10 gesetzt werden und repliziert fortan mit keinem anderen Domaincontroller. Der Wert sollte dann nach erfolgreicher Schemaerweiterung auf den Ursprungswert umgestellt werden.

Hinweis: Dieses Attribut wird erst nach Änderung eines Namespaces im AD aktiviert und ist bestimmt denjenigen bekannt, der solchen Vorgang bereits vorgenommen hat. Stichwort: RENDOM.

Methode 2 – Stoppen der ausgehenden AD Replikation:

Deaktivierung der ausgehenden AD Replikation am Schemamaster: repadmin /options +DISABLE_OUTBOUND_REPL

Aktivierung der ausgehenden AD Replikation wenn die Schemaerweiterung erfolgreich vorgenommen wurde: repadmin /options -DISABLE_OUTBOUND_REPL

Vorgehensweise bei fehlgeschlagener Erweiterung:

Sollte der Vorgang aus irgendeinem Grund unterbrochen worden sein, stellt sich natürlich die Frage: Ist das Schema jetzt unbrauchbar ?

In den meisten Fällen kann man sagen: Nein, denn Active Directory arbeitet transaktional. Das heißt, eine Änderung an Daten wird immer vollständig oder gar nicht ausgeführt. Wird der Vorgang also unterbrochen, während AD gerade dabei ist, ein neues Attribut zu definieren, so wird die Änderung widerrufen. Das betrifft immer nur die laufende Transaktion, also ein einziges Attribut. Wird ein ganzes Attributset definiert, wie es üblicherweise der Fall ist, bleibt ein Teil davon im AD-Schema und ist demnach inkonsitent oder ohne eigentliche Funktion.

Da die Änderungen auf dem Schemamaster vorgenommen wurde können diese logischerweise nicht mehr bzw. supported rückgängig gemacht werden. Somit bleibt es hier nur bei einer manuellen Entfernung des entsprechenden DCs mit Schemamaster und dem „seize“ der Schemamaster-Rolle auf einen anderen Domaincontroller im Forest.

Fazit

Mit diesen beiden Methoden kann unterbunden werden, dass nach fehlerhafter Schemaerweiterung ein kompletter Forest Restore vorgenommen werden muss. Somit muss „nur“ ein Domaincontroller unter einem Fehlversuch leiden und kann auch an diesen Vorgang mit einer „gewissen“ Ruhe vorgegannen werden.