AD-Schemaerweiterung: Ein paar Hinweise

Viele komplexe Applikationen integrieren sich in Active Directory (AD). Einige davon legen dort auch Konfigurationsdaten ab, beispielsweise Exchange oder Ciscos Call Manager. Zu diesem Zweck erweitern sie das Schema des AD, also die Definition der Datenbank: Sie legen neue Attribute (Datenfelder) und meist auch neue Objektklassen an, die den Aufbau bestimmter Objekte beschreiben. Doch auch Windows selbst ändert bisweilen das AD-Schema, vor allem bei der Aufnahme von Domänencontrollern mit neuen Betriebssystemversionen (etwa Windows Server 2003, 2008 oder die jeweiligen R2-Versionen). Selbst WIndows Vista kann eine Schemaergänzung erfordern, wenn man die Schlüssel für die Festplattenverschlüsselung BitLocker in AD ablegen möchte.

Derartige Manipulationen des Schemas haben eins gemeinsam: Sie sind von ihren Herstellern sorgfältig entworfen und entwickelt worden, und natürlich hat es intensive Tests gegeben. In solchen Fällen darf der geneigte Admin also darauf vertrauen, dass die Schemaerweiterung selbst in Ordnung ist. Anders kann es aussehen, wenn ein Anwenderunternehmen selbst Ergänzungen am AD-Schema ausführen möchte. Solche Anforderungen lassen sich sinnvoll umsetzen, wenn man sich intensiv mit der Materie beschäftigt und die passende Sorgfalt bei Entwurf und Entwicklung walten lässt. Hintergründe dazu finden sich verstreut, aber durchaus umfassend auf Microsofts Webseiten.

Im Folgenden geht es um “fertige” Schema-Änderungen, also im Regelfall solche der erstgenannten kommerziellen Art. Trotz der sorgfältigen Entwicklung sollte man einige Dinge berücksichtigen, damit das Upgrade sauber und sicher funktioniert.

Wie kritisch ist eine Schemaerweiterung?

Allenthalben ist die Warnung zu lesen: Das Schema ist das Rückgrat des Active Directory. Eine fehlerhafte Änderung kann den Verzeichnisdienst empfindlich stören. Daher wird zu größter Sorgfalt geraten. Was ist dran?

Generell gesprochen, sind die Einordnung und die Warnung richtig. Das Schema legt über Attribute und Objektklassen fest, welche Daten wie im Verzeichnis abgelegt werden. Ein beschädigtes Schema kann daher durchaus das ganze AD lahmlegen. Ein Beispiel: Ein Unternehmen erweitert das Schema, um bei allen Benutzern die Schuhgröße zu speichern. Für die meisten “User”-Objekte wird die Schuhgröße dann auch gepflegt. Später entfällt der Bedarf für diese Daten, und ein Admin entschließt sich kurzerhand, die Erweiterung “Schuhgröße” zu deaktivieren (denn: Löschen kann man Attribute und Klassen nicht). Was passiert? Fast alle “User”-Objekte enthalten nun Daten für ein Attribut, das gar nicht aktiv ist. Diese Objekte sind also fehlerhaft. Eine solche Änderung am Schema hätte man also anders durchführen müssen: Erst das Löschen aller betroffenen Attributwerte, dann das Deaktivieren des Attributs.

Ein anderes Beispiel: Ein Unternehmen beschließt, bestimmte Daten in AD abzulegen. Dazu erzeugt es einige Attribute und Klassen, übersieht aber die Notwendigkeit, dies auf eine bestimmte strukturierte Weise zu tun. Die “Object ID”, die das Unternehmen verwendet, hat es nicht vorher registriert und auch nicht geprüft. Eigentlich gehört diese ID einem anderen Unternehmen, das Software herstellt. Später entschließt das erste Unternehmen, eine Software des zweiten Unternehmens einzusetzen. Leider bricht die dafür nötige Schemaerweiterung ab: Die vorgesehene Object ID ist bereits in Benutzung – durch die eigenmächtige Erweiterung des Anwenderunternehmens.

Das sind zwei Szenarien, die sich durch Planung verhindern lassen. Es gibt aber auch technische Ausfälle – etwa dass eine Schemaerweiterung mittendrin abbricht. Ist nun das Schema unbrauchbar?

Nein, sehr wahrscheinlich ist das nicht der Fall. Active Directory arbeitet transaktional: Eine Änderung an Daten wird immer vollständig oder gar nicht ausgeführt. Fällt also der Strom aus, während AD gerade dabei ist, ein neues Attribut zu definieren, so wird beim nächsten Serverstart diese begonnene Änderung widerrufen. Aber: Das betrifft immer nur die laufende Transaktion, im Beispiel also dieses eine Attribut. Die anderen Attribute, die dieselbe Schemaerweiterung vorher bereits definiert hatte, bleiben im AD-Schema.

Was nun? AD enthält einige, aber nicht alle Erweiterungen, die für die jeweilige Applikation nötig sind. Die Applikation wird also wohl nicht laufen. Das AD selbst ist in seiner Funktion aber ziemlich sicher nicht eingeschränkt, denn es gibt nur einige Daten mehr als sonst, die aber andere Applikationen nicht stören. Günstigenfalls lässt sich die Schemaerweiterung der neuen Applikation einfach neu starten (siehe unten) und läuft dann zum Ende durch. Aber: Eine Garantie dafür gibt es nicht!

Zu diesem Fall gibt es aber natürlich auch Ausnahmen: Man kann das Schema nämlich nicht nur um neue Einträge erweitern, sondern auch vorhandene Einträge modifizieren. Hängt eine solche Modifikation von anderen Einträgen ab, die aufgrund eines Abbruchs gar nicht vorhanden sind, wird es vermutlich Probleme geben. In solch einem Fall ist der Support des Herstellers einzuschalten.

Die Grenzen

Es gibt zwei faktisch unverrückbare Grenzen, die man bei der Manipulation des AD-Schema kennen sollte:

• Eine Erweiterung lässt sich nicht rückgängig machen. Vorhandene Attribute und Klassen kann man nicht löschen.
  Zwar kann man Klassen oder Attribute deaktivieren, sodass sie künftig nicht nutzbar sind. Entfernen kann man sie aber nicht.
• Es gibt kein Rollback und kein “Authoritative Restore” des Schema.
  Die Methoden, mit denen man “normale” AD-Einträge aus einem Backup wiederherstellen kann, greifen beim Schema nicht.

Bedarf klären

Auch beim Einsatz einer kommerziellen Applikation sollten die Zuständigen genau prüfen, ob sie das Programm und seine Schema-Manipulation wirklich benötigen. Stellt sich nach dem Update heraus, dass man die Applikation doch nicht nutzen will, hat man unnötige “Altlasten” im System. Diese sind zwar normalerweise nicht kritisch, können sich aber in Einzelfällen als Problem auswirken (siehe obige Diskussion).

Eine Warnung in diesem Zusammenhang vor Beta-Software: Entwicklungsversionen einer Software haben in einem produktiven Netzwerk nichts zu suchen. Eine Schemaerweiterung lässt sich nicht rückgängig machen. Neben dem “Altlast”-Problem können auch handfeste Schwierigkeiten entstehen, wenn man etwa eine überholte Fassung des Schemas betreibt, die vielleicht mit der Endversion inkompatibel ist.

Eingangsuntersuchung

Für Anwendungen mit eingeschränktem Support – also etwa Individualsoftware oder Eigenentwicklungen – gilt, dass man die Änderungen am Schema zunächst im Quelltext überprüfen sollte, sofern das möglich ist. Eine Empfehlung für solche Änderungen ist, dass sie im LDIF-Format (LDAP Interchange Format) vorliegen und über das Windows-eigene Werkzeug ldifde.exe importiert werden sollten. Hat sich der Entwickler daran gehalten, so liegen die nötigen Definitionen also als Textdateien vor, die man einer Inspektion unterziehen kann (bei Exchange etwa ist das der Fall).

Nun benötigt man für eine solche Analyse sehr tiefgehende Kenntnisse von der Materie und meist auch von der neuen Applikation. Nur selten werden Admins darüber verfügen. Was man aber bei der Durchsicht tun kann:

• Prüfen, ob die Dateien vollständig sind. Fehlen etwa Dateien bei fortlaufender Nummerierung der Dateinamen? Sind Dateien korrupt und unvollständig? In solchen Fällen ist natürlich Ersatz anzufordern.
• Notieren einiger Änderungen und Ergänzungen. Meist definieren Applikationen neue Attribute und Objekte. Hier kann man stichprobenartig einige Definitionen herauskopieren, damit man nach dem Update vergleichen kann, ob alles da ist. Oft gibt es aber auch Änderungen an bestehenden Definitionen (erkennbar im LDIF-Text an dem Schlüsselwort “modify”). Auch hier lohnen Ist-Soll-Vergleiche.
• Nachprüfen, ob die Erweiterungen evtl. schon vorhanden sind. Gerade bei “älteren” AD-Umgebungen, in denen vielleicht die Admins gewechselt haben, besteht oft keine Klarheit darüber, in welchem Zustand sich das Schema befindet. Die folgenden Artikel können bei der Identifikation helfen:

[faq-o-matic.net » José Active-Directory-Dokumentation: Version 2.0 ist fertig]
http://www.faq-o-matic.net/2008/10/29/jos-active-directory-dokumentation-version-20-ist-fertig/

[faq-o-matic.net » Schema-Versionen vergleichen]
http://www.faq-o-matic.net/2007/10/21/schema-versionen-vergleichen/

Test

Ein Schema-Upgrade sollte man immer erst testen, bevor man es in der Produktionsumgebung ausführt. Hierzu eignen sich virtuelle Umgebungen. Meist reicht eine einzelne VM aus, nämlich ein Domänencontroller (DC), dessen Schema auf demselben Stand ist wie in der realen Welt – vor dem Upgrade natürlich.

In speziellen Fällen kann es sinnvoll sein, wichtige Applikationen mit in die Testwelt zu holen, um deren Reaktion auf die Änderung zu prüfen. Da allerdings eine Schemaerweiterung als solche die AD-Definition nur erweitert, ist sie Applikationen in der Regel egal, denn sie ignorieren die Objekte und Attribute einfach, die sie nicht interessieren. Anders sieht es aber bei Änderungen (modify) bestehender Attribute oder Klassen aus. Hier können durchaus Abhängigkeiten bestehen. Normalerweise sollte der Applikationshersteller darüber aber Auskunft geben können.

Der Test selbst erfolgt im Wesentlichen nach demselben Verfahren wie die “echte” Änderung – siehe also unten. Der Testvorgang bezieht sich hauptsächlich auf den Upgradeprozess: Welches Tool nutzt man und wie arbeitet es? Läuft es klaglos durch? Ein erweiterter Test könnte darin bestehen, den Upgradevorgang mutwillig zu unterbrechen. Dann ist die spannende Frage: Kann man das Upgrade durch erneute Ausführung fortsetzen? Die meisten Upgrade-Tools können das, einzelne aber nicht (das ADModify von Windows Server 2003/R2/2008/R2 etwa sollte man auf keinen Fall unterbrechen). Vielleicht lässt sich der Vorgang aber durch ein anderes Werkzeug wie ldifde.exe fortsetzen. Das ist dann gegeben, wenn die Änderungen selbst durch .ldf-Dateien ausgeführt werden. Mit dem Schalter –k weist man ldifde.exe an, seinen Import im Falle bereits bestehender Objekte fortzusetzen.

Um solche Teste mehrfach ausführen zu können, empfiehlt sich die Snapshot-Funktion der virtuellen Umgebung.

Vorbereitung

Waren Analyse und Test erfolgreich, geht es an die tatsächliche Durchführung in der Produktionsumgebung. Vorbereitend sollte man einige Dinge vollziehen:

• Datensicherung des AD: Um auf einen zwar unwahrscheinlichen, aber möglichen Katastrophenfall reagieren zu können, führt man für alle Domänen des AD-Forest eine Datensicherung aus. Dabei ist auf jeden Fall der bordeigene “System State” zu nutzen, weil dies den gemeinsamen Nenner bei einem eventuellen Einsatz des Microsoft-Supports darstellt. Wer andere Werkzeuge zur AD-Datensicherung einsetzt, nutzt diese ergänzend.
• Aufbau eines Plans zum Forest Recovery: Auch dies gehört zur Kategorie “unwahrscheinlich, aber unverzichtbar”. Geht die Sache wirklich schief, kann man gezwungen sein, aus den Datensicherungen den ganzen AD-Forest wieder aufzubauen. Das Konzept ist netzwerkspezifisch, eine allgemeine Anleitung kann man also kaum geben. Gute Orientierung bietet das Microsoft-Whitepaper:

[Download details: Forest Recovery]
http://www.microsoft.com/downloads/details.aspx?familyid=afe436fa-8e8a-443a-9027-c522dee35d85&displaylang=en

• Identifizieren des Schema-Masters und der berechtigten Konten: Das Schema-Upgrade kann nur über den DC erfolgen, der die Schema-Master-Rolle hält. Zudem muss das ausführende Benutzerkonto Mitglied der Gruppe “Schema-Admins” sein.
• Sicherstellen, dass die Replikation des AD ordnungsgemäß funktioniert. Einen ersten Anhalt geben die Ereignisprotokolle der DCs. Weiteren Aufschluss geben der Replication Monitor (aus den Support Tools) sowie repadmin.exe (ebenfalls Support Tools).
• Auswahl des Zeitpunkts: Zwar kann das Schema-Upgrade im laufenden Betrieb geschehen. Es ist aber meist sinnvoll, zumindest eine lastärmere Zeit dafür auszuwählen. Vorsicht aber: Freitagabend ist meist keine gute Wahl, weil man dann bei einer Katastrophe am Wochenende wohl kaum schnell auf externen Support zurückgreifen kann.
• Replikation: Wer eine Windows-2000-Domäne aktualisiert, muss wissen, dass eine Schemaänderung zu einer Komplettreplikation des ganzen AD über alle Domänencontroller führt. Hier sollte man also laststarke Zeiten vermeiden. Ab Windows Server 2003 passiert dies aber nicht mehr, sondern es wird nur repliziert, was sich wirklich geändert hat.

Jetzt wird’s ernst!

Sind alle Vorbereitungen getroffen, kann es losgehen. Wichtig: Es ist zwar technisch möglich, das Schema-Upgrade remote auszuführen, also von einem DC aus, der selbst gar nicht Schema-Master ist, oder gar von einem Client aus. Um aber zu verhindern, dass ein Netzwerkproblem zum Abbruch führt, sollte man das Upgrade nur direkt auf dem Schema-Master ausführen.

Isolation des Schema-Masters – auf eigene Gefahr!

Achtung, das folgende Verfahren wird von Microsoft ausdrücklich nicht empfohlen! Es befindet sich allerdings nicht im Status „unsupported“. Trotzdem weisen wir auf diesen Umstand hin. Näheres findet sich hier, und zwar in der dritten Frage:

[Friday Mail Sack – I live again edition – Ask the Directory Services Team – Site Home – TechNet Blogs]
http://blogs.technet.com/b/askds/archive/2010/04/16/friday-mail-sack-i-live-again-edition.aspx

Es ist technisch möglich, den Schema-Master während des Upgrade-Vorgangs von der Replikation zu isolieren. Siehe dazu aber den Hinweis direkt über diesem Absatz! Die Isolation ermöglicht ein schnelles und einfaches Fallback, falls der Upgradeprozess selbst scheitern sollte. In den meisten Fällen ist es allerdings unproblematisch, das Upgrade an der laufenden Umgebung auszuführen – insbesondere, wenn der vorherige Test ergeben hat, dass man ein abgebrochenes Upgrade neu starten und zu Ende führen kann.

• Sofern der DC, der die Schema-Master-Rolle hält, noch weitere Dienste ausführt, ist es sinnvoll, übergangsweise einen zusätzlichen DC für den Vorgang zu installieren. Im Fall des Falles muss man diesen DC nämlich opfern – und es wäre kaum sinnvoll, dies mit einer Maschine zu tun, die anderweitig benötigt wird.
• Den Schema-DC isoliert man nun von der AD-Replikation. Zwar ist es grundsätzlich möglich, ihn einfach vom Netzwerk zu trennen, doch führt dies bisweilen zu unerwünschten Effekten. Besser ist es also, die Replikation abzuschalten („server.dom.tld“ steht im Folgenden für den DNS-Namen des DCs):
  repadmin /options server.dom.tld +DISABLE_OUTBOUND_REPL
• Ausführen der Schema-Erweiterung.
• Nun gibt es im Wesentlichen zwei Möglichkeiten:
  • Die erwünschte, wahrscheinliche und einfache: Alles ist gutgegangen. In diesem Fall schaltet man die Replikation des Schema-Masters wieder an mit:
    repadmin /options server.dom.tld -DISABLE_OUTBOUND_REPL
    Dann ist der Prozess beendet.
    Besonders wichtig: Auf keinen Fall nach dem Abschluss des Vorgangs diesen Schritt vergessen!
  • Die unerwünschte, weniger wahrscheinliche und leider nicht so einfache: Beim Schema-Update ist etwas schiefgegangen. Je nachdem, was passiert ist, gibt es mehrere mögliche Reaktionen.
    • Ist der Update-Prozess abgebrochen, kann man – insbesondere wenn man das vorher positiv getestet hat – versuchen, ihn einfach erneut auszuführen.
    • Gab es beim ADPrep Probleme, kann evtl. dieser Artikel helfen:

    [Ask the Directory Services Team : Troubleshooting ADPREP Errors]
    http://blogs.technet.com/askds/archive/2008/12/15/troubleshooting-adprep-errors.aspx

    • Gab es andere Probleme, ist eine Web-Recherche auf jeden Fall eine gute Idee.
    • Sollten diese Methoden nicht helfen, kann man den Schema-Master aus dem AD entfernen und neu installieren. Grundsätzlich könnte man dafür zwar dcpromo ausführen, doch wenn der Server tatsächlich nur Domänencontroller ist, ist es vermutlich einfacher, ihn komplett neu aufzusetzen. Bevor man ihn dann wieder ans Netz bringt, entfernt man die zugehörigen Objekte aus dem AD, z.B. nach folgender Anleitung:

    [Entfernen von Daten aus Active Directory nach fehlgeschlagener Domänencontroller-Herabstufung]
    http://support.microsoft.com/default.aspx/kb/216498

    • In diesem Fall muss man dann den Schema-Master auf einen anderen DC verlagern.

    [faq-o-matic.net » Wie kann ich Betriebsmasterrollen offline übertragen?]
    http://www.faq-o-matic.net/2004/11/12/wie-kann-ich-betriebsmasterrollen-offlineuebertragen/

Weitere Artikel

[Aktives Verzeichnis Blog : So kann beim Schema Upgrade für Windows 2008 (fast) nichts schiefgehen]
http://blogs.technet.com/deds/archive/2009/03/30/so-kann-beim-schema-upgrade-fuer-windows-2008-fast-nichts-schiefgehen.aspx

[Aktives Verzeichnis Blog : Schema Erweiterungen – Riskant oder unkritisch?]
http://blogs.technet.com/deds/archive/2008/08/05/schema-erweiterungen-riskant-oder-unkritisch.aspx

[So You Want to Upgrade to Windows 2008 Domain Controllers (ADPREP) – Ask the Directory Services Team – Site Home – TechNet Blogs]
http://blogs.technet.com/b/askds/archive/2008/11/11/so-you-want-to-upgrade-to-windows-2008-domain-controllers-adprep.aspx