Verwaltungsfehler am Active Directory vermeiden

Der Schutz vor versehentlichem Löschen von Objekten im Active Directory (AD) gehört zu den wichtigen Aufgaben des Administrators. Eine Absicherung dafür ist das gegenseitige Überprüfen von Änderungen durch einen anderen Administrator. Zudem bieten Dritthersteller dazu auch komplette Werkzeuge, die das Durchführen von Changes weitgehend automatisieren und dokumentieren.

Ab Windows Server 2003 gibt es aber auch im Rahmen dieser Plattform auch den Ansatz  der „ausgewählten Authentifizierung“ (Selective Authentication). Es sind dazu zwar einige Aktionen nötig, um diese Funktion ans Laufen zu bringen, doch dann hat man eine sehr effektive Lösung vorliegen, um Änderungen am AD zu überwachen.

Der Albtraum eines Admins: Als Organisationsadministrator für eine Active Directory-Umgebung mit mehreren Domänen will er an einer Präsentation des CIO seines Unternehmens teilnehmen, in der der oberste ITler den Aktionären erklären will, warum das IT-Budget im nächsten Jahr um zehn Prozent steigen muss. Dieses Meeting soll in zehn Minuten beginnen—doch leider kann der CIO nicht auf seine Powerpoint-Präsentation zugreifen, die im Speichernetzwerk des Unternehmens liegt. In seiner Not wendet er sich an den Organisationsadministrator – was kann man da tun?

Der Organisationsadministrator schaut sich das Benutzerkonto des CIO – sein Name sei Günther Hoffmann – an, um zu überprüfen, ob er über die notwendigen Zugriffsberechtigungen verfügt. Doch schnell wird klar: Das komplette Benutzerkonto von Günther Hoffmann (g_Hoffmann) ist gelöscht. Im entsprechenden Änderungsprotokoll ist zu sehen, dass der neu eingestellte Administrator vor kurzer Zeit den Fehler begangen hat: Er sollte das Benutzerkonto von Günther Hofmann (g_Hofmann) löschen, der bereits letztes Monat in Rente gegangen ist. Aufgrund des einen fehlenden Buchstabens ist dieser Fehler entstanden, denn gelöscht hat er das Benutzerkonto g_Hoffmann.

Gottseidank ist der CIO abgeklärt genug und kann mit einigen Anekdoten etwas Zeit vor seinem Vortrag gewinnen. In der Zwischenzeit wird sein gelöschtes Benutzerkonto reanimiert, er bekommt ein neues Kennwort und dann wird er allen Gruppen in den anderen Domänen hinzugefügt, damit er auf seine Präsentation und alle zusätzlichen Materialien wieder Zugriff bekommt. Die Präsentation läuft dann auch gut ab und der CIO hat großes Verständnis, dass Fehler nun mal passieren. Doch der Organisationsadministrator wünscht sich, das alles wäre nie passiert.

Die meisten Administratoren standen bereits vor dem Problem, dass Benutzerkonten versehentlich gelöscht oder von Gruppen entfernt wurden, oder aber dass Benutzer Zugriff auf Ressourcen bekommen haben, die sie nichts angehen. Mit teuren Sicherungsprogrammen für das Active Directory (AD) oder mit Hilfe von komplexen Skripting-Ansätzen lassen sich gelöschte Objekte binnen kurzer Zeit wiederherstellen. Doch es wäre doch sicher eine bessere Lösung, wenn es gar nicht zu dem Problem käme.

Das Schützen der Objekte im AD vor Verwaltungsfehlern ist aber eine große Herausforderung. Es ist daher in vielen Unternehmen üblich, dass ein zweiter Administrator nochmals alle Änderungen kontrolliert, ehe sie ausgeführt werden. Zudem gibt es Werkzeuge von Drittherstellern, die eine Automatisierung der Change-Prozesse erlauben und dabei auch eine entsprechende Überprüfungsaktion ausführen.

Ausgewählte Authentifizierung löst das Problem

Eine dritte Lösung, die gar nicht so viele Administratoren kennen, ist der Einsatz der „ausgewählten Authentifizierung“ (Selective Authentication). Sie ist seit dem Windows Server 2003 verfügbar und verwendet dazu eine externe Vertrauensstellung. Dabei muss der Administrator anfangs etwas Aufwand betreiben, doch dafür bekommt er dann eine effektive Methode, um Änderungen am AD zu überwachen.

Wenn die ausgewählte Authentifizierung aktiviert ist, bekommen Benutzer – im konkreten Fall sind das die Administratoren – aus einer vertrauenswürdigen Domäne explizit Rechte auf spezifischen Computern in der vertrauenden Domäne eingeräumt. Damit lässt sich dann kontrollieren, auf welche Ressourcen sie zugreifen dürfen.

In fünf Schritten kann der Admin seine AD-Umgebung für den Einsatz der ausgewählten Authentifizierung vorbereiten:

• Im Produktivbereich der AD-Gesamtstruktur muss er einen zusätzlichen Standort anlegen, in dem sich nur ein Domänencontroller (DC) befindet. Dabei dürfen keine zugeordneten Subnetze angelegt sein. Mit einem sehr strikten Replikations-Plan sollte man die Replikation nur zu bestimmten festgelegten Zeitspannen erlauben oder sogar vorsehen, dass die Replikation händisch angestoßen werden muss. Das Abschalten von allen zeitgesteuerten Replikationen auf einer Standortverknüpfung wird allerdings eine Spanning-Tree-Fehlermeldung auf den anderen DCs zur Folge haben. Die Replikationseinschränkung lässt sich über die Zeitpläne für die Standortverknüpfung kontrollieren.
• Danach ist eine zweite Gesamtstruktur (sprich eine Verwaltungs-Gesamtstruktur) einzurichten. Sie sollte aufgrund von Redundanzvorgaben über zwei oder mehr DCs verfügen. Alle Administratorkonten, für die man die Changes prüfen möchte, sollen in dieser Gesamtstruktur liegen.
• Anschließend ist eine externe Vertrauensstellung für diese beiden Gesamtstrukturen einzurichten. Diese Vertrauensstellungen können auf Basis der Domänen oder der Gesamtstrukturen eingerichtet werden, doch sie müssen als Einweg-Vertrauensstellung angelegt sein. Dabei ist die vertrauenswürdige Domäne die Verwaltungs-Domäne (bzw. -Gesamtstruktur) und der vertrauende Part fällt der Domäne mit dem Produktivbetrieb zu. Anstelle die standardmäßige Authentifizierungsmethode zu wählen, ist die „ausgewählte Authentifizierung“ angeben.
• Danach sind die Authentifizierungs-Berechtigungen zuzuweisen. Nun liegt eine Gruppe von Administrator-Konten in der Verwaltungs-Gesamtstruktur, die zwar die Vertrauensstellung zur Gesamtstruktur mit der Produktivumgebung sehen, doch sie können sich an keiner der dort liegenden Ressourcen authentifizieren. Daher muss man das Recht „Authentifizierung zulassen“ (Allowed to authenticate) für die Administratoren-Gruppe auf dem DC im zusätzlichen Standort gewähren.
• Abschließend geht es an das Gewähren der notwendigen Berechtigungen. Dabei ist die übliche Delegierungs-Prozedur einzuhalten und so bekommen dann alle Administratoren die Rechte zugewiesen, die sie für das Ausführen ihrer Aufgaben brauchen. Dazu zählen Aktionen wie das Hinzufügen oder Löschen von Objekten, das Ändern der DNS-Eigenschaften und das Erstellen von Gruppenrichtlinienobjekten (GPOs Group Policy Objects).

Die ausgewählte Authentifizierung in Kombination mit dem Recht „Authentifizierung zulassen“ auf einem einzigen DC erzwingt, dass alle Änderungen nur auf diesem einem System erfolgen. Mit einer derartigen Einstellung können die Administratoren zunächst alle Aktionen ausführen. Sollten dabei Fehler ins Spiel kommen, bleiben diese nur auf den einen DC in dem Standort begrenzt, der zudem keinerlei Aufgaben für die Benutzer-Authentifizierung übernimmt.

Alle Änderungen bleiben auf diesem System, erst wenn die Replikation ins Spiel kommt, werden sie an die anderen DCs im Verbund weiter gegeben. Ist aber der Zeitplan für die Replikation auf manuell gestellt (sprich es findet keine automatische Replikation statt), dann werden die Änderungen erst dann weitergereicht, wenn sie freigegeben werden.

Damit wird auch schon klar, wie diese Lösung eingesetzt werden soll. Im Unternehmen gilt es die Administratoren auf zwei Gruppen zu verteilen. Die eine Gruppe führt die anstehenden AD-Änderungen am isolierten DC durch, und Systembetreuer aus der zweiten Gruppe prüfen regelmäßig die Änderungen an diesem DC.

Sind sie perfekt ausgeführt, erfolgt die Freigabe für die Produktiv-Umgebung. Sollten dagegen Modifikationen fehlerhaft sein oder gegen die Vorgaben des Unternehmens verstoßen, kann der Administrator diese Änderungen verbessern lassen und so dieses Problem lösen, ehe es sich in der gesamten Umgebung auswirkt.

Das Überprüfen der Änderungen auf dem isolierten DC lässt sich mit dem Bordwerkzeug von Windows Server 2003 (und den Vorgängerversionen) erledigen. Dabei braucht der Administrator nur in den Überwachungsrichtlinien für den DC angeben, dass alle Änderungen am Verzeichnisdienst protokolliert werden. Damit werden alle Modifikationen am DC im Sicherheitsprotokoll eingetragen. Da aber alle Änderungen nur an dem einen isolierten DC erfolgen, braucht der für die Überprüfung zuständige Administrator ein Protokoll durchsuchen und dort nach allen Änderungen Ausschau halten, die seit der letzten Replikation aufgetreten sind.

Windows Server 2008 erleichtert das Überprüfen

Mit den neueren Versionen von Windows Server (2008 und 2008 Release 2) stehen bessere Tools zur Verfügung, um Änderungen am AD zu überwachen. Ein Vertreter davon ist Dsmain. Mit diesem Werkzeug kann man eine LDAP-Datenbank mounten (die zuvor mit Hilfe einer Sicherung oder durch den Einsatz des Werkzeugs Ntdsutil erzeugt wurde) und dann mit einem Skript alle Objekte aus der LDAP-Datenbank mit dem AD des isolierten DC vergleichen.

Auf diese Art werden alle Änderungen ersichtlich, ehe man sie für den Produktivbetrieb freigibt. Des weiteren gibt es seit Windows Server 2008 eine verbesserte Überwachung für die Ereignisse – es werden mehr Informationen über die Änderungen geliefert und zudem lassen sich spezifische Sichtweisen erstellen, um nur die Änderungen anzuzeigen.

Es eignen sich aber auch Produkte von Drittherstellern. Diese Überwachungs-Tools fragen die Änderungen in Echtzeit ab und vergleichen verschiedene Datenbanken von unterschiedlichen DCs. Auch so wird schnell ersichtlich, was sich geändert hat.

Einsatzfelder für die Lösung

Wer sich auf die hier geschilderte Lösung einlässt, der sollte aber auch die Einschränkungen kennen. Generell ist die Wahrscheinlichkeit, dass Fehler im AD sich in die Produktivumgebung durchsetzen, nur reduziert worden. Es besteht immer noch die Möglichkeit, dass der für die Überprüfung und Freigabe der AD-Änderungen zuständige Systembetreuer etwas übersieht und somit einen Fehler durchschlüpfen lässt. Das wird mit steigender Anzahl von Änderungen, die er zu überprüfen hat, wahrscheinlicher sein.

Eine weitere Schwachstelle sind die Domänen- und Organisations-Administratoren. Diese Konten existieren immer noch in der Gesamtstruktur, die für den Produktivbetrieb zuständig ist. Wenn jemand die Absicht hat, hier Unfug anzustellen, können diese Administratoren diese Vorkehrungen umgehen und die Änderungen direkt an einem DC in der Produktivumgebung ausführen.
Trotzdem dürften in den meisten Aufgabenstellungen die Vorteile der gezeigten Lösung überwiegen. Neben der höheren Sicherheit bei Änderungen am AD wird generell das Überwachen und das Reporting von Objekt-Änderungen vereinfacht, da alles nur auf einem DC vorgenommen wird.

Zudem wird die gesamte Konstruktion auch etwas sicherer: Angenommen ein Administrator-Konto wird kompromittiert, dann betrifft das ja zunächst nur den isolierten DC. Im Falle eines Falles muss man dann nur den isolierten DC und die zugehörige Gesamtstruktur säubern. Das ist weitaus weniger Aufwand als das komplette Neuaufsetzen und Wiederherstellen des AD mit all seinen Daten.

Für extrem große Gesamtstrukturen, die womöglich sogar sich über mehrere Länder und Kontinente erstrecken, wird sich aber bei diesem gezeigten Ansatz eine enorme Welle von Überprüfungen ergeben. Aber auch in Bereichen wie typischen Helpdesk-Umgebungen, bei denen die Hauptaufgabe das Zurücksetzen von Kennwörtern ist, ergibt sich ein Nachteil: Die Kennwörter müssen immer sofort zurückgesetzt werden, damit die Benutzer schnell wieder weiterarbeiten können.

Besonders gut eignet sich dieses Konzept dagegen, wenn man Organisationseinheiten mit „besonderen“ Objekten schützen will – wie etwa die Geschäftsleitung. Auch bei kleineren Umgebungen, bei denen in vielen Fällen weniger qualifiziertes Personal für die AD-Verwaltung herangezogen wird, ist ein derartiges Überprüfen sinnvoll. Aber auch wenn bei kleineren Umgebungen ein Fehler am AD eine Katastrophe nach sich ziehen kann, sollte man diese Lösung einsetzen.

Wer einen neu eingestellten Administrator das Arbeiten am AD erlaubt, der kann in einer abgesicherten Umgebung schnell sehen, wie qualifiziert er ist. Aber auch Admin-Profis können profitieren: Wer einen kritischen Dienst überwachen muss – wie etwa das DNS (Domain Name System) – oder wer für unternehmenskritische Applikationen zuständig ist, die Daten im AD ablegen, sollte darauf zurückgreifen.

Der Einsatz der ausgewählten Authentifizierung im Zusammenspiel mit einer externen Vertrauensstellung erweist sich als eine gute Lösung, wenn man Objekte im AD gegen Verwaltungsfehler schützen möchte. Trotz der anfänglichen Vorleistungen profitiert das gesamte System von diesem Ansatz. Zudem wird die Sicherheit der IT-Umgebung weiter erhöht.

James R. Day/rhh