Unentbehrliches Netzwerk-Know-how (tecCHANNEL COMPACT)
Katastrophenszenarien bei Active Directory - Teil 1
Bei Active Directory handelt es sich um eine komplexe Software, deren Ausfall einen Administrator gehörig ins Schwitzen bringt. In unserer fünfteiligen Serie wollen wir Ihnen einige Katastrophenszenarien inklusive Lösung aufzeigen.
Auf dieser SeiteActive Directory ist auf eine Reihe von Diensten und Features angewiesen, um korrekt funktionieren zu können. Wenn einer dieser Dienste ausfällt, erleben Sie ungewöhnliches oder unkontrollierbares Verhalten. Unsere Serie stellt Ihnen die häufigsten Szenarien samt Lösung vor. Neue Features von Windows Server 2003Das einzige neue Feature von Windows Server 2003, das sich auf Active-Directory-Ausfälle und -Korrektur auswirkt, ist die neue Fähigkeit von Domänencontrollern, die keine GC-Server sind, Mitgliedschaften in universellen Gruppen zu cachen. Der Global Catalog (GC) speichert die Mitgliedschaftslisten für universelle Gruppen, und ohne diese Information verweigert ein Domänencontroller Benutzern die Authentifizierung. Normalerweise würde ein Zusammenbruch der Verbindung zu GC-Servern (beispielsweise nach dem Ausfall einer Standleitung) dazu führen, dass Benutzer sich nicht mehr an der Domäne anmelden können. Da nun Mitgliedschaft in universellen Gruppen auf normalen Domänencontrollern gecacht wird, würde der Ausfall der Verbindung zu den Global Catalogs nicht mehr zum Abschneiden von der Domäne führen. Ausfall eines DNS-ServersDer Ausfall eines DNS-Servers wirkt sich in mehrerlei Hinsicht auf Active Directory aus. Erstens muss ein Domänencontroller in der Lage sein, Hostnamen und Server-Einträge aufzulösen, um mit den anderen Domänencontrollern kommunizieren und replizieren zu können. Wenn der DNS-Server ausfällt, den ein Domänencontroller benutzt, dann kann der DC seine Funktionalität nicht mehr lange voll aufrechterhalten. Sie müssen Ihre DNS-Infrastruktur so gestalten, dass der Ausfall eines einzelnen DNS-Serves nicht zu einer Betriebsunterbrechung führt. Sie sollten stets mindestens zwei DNS-Server betreiben, die für eine Zone autoritativ sind, und die Clients sollten auf beide Server verweisen, auf den einen als primären, den anderen als sekundären DNS-Server. Windows-Clients wenden sich an ihren sekundären DNS-Server, wenn sie vom primären DNS-Server keine Antwort erhalten. Inseleffekt vermeidenWenn Sie einen Domänencontroller, der ein DNS-Server mit AD-integrierten Zonen ist, für die Namensauflösung auf sich selbst verweisen lassen, könnten Sie einem subtilen Teufelskreis zum Opfer fallen, den Microsoft als Inseleffekt bezeichnet. Bei einer AD-integrierten DNS-Zone aktualisiert ein Domänencontroller seine DNS-Einträge, indem er von einem anderen Domänencontroller repliziert. Der Domänencontroller findet seine Replikationspartner, indem er einen DNS-Lookup durchführt. Wenn sich IP-Adressen ändern, findet der Domänencontroller seinen Replikationspartner nicht und kann DNS nicht aktualisieren, weil er nicht von ihm replizieren kann. Sie können diesen Inseleffekt vermeiden, indem Sie die TCP/IP-Eigenschaften eines Domänencontrollers so konfigurieren, dass ein anderer Domänencontroller der primäre DNS-Server ist. Die DNS-Einstellungen in den TCP/IP-Einstellungen des Domänencontrollers können auf den Domänencontroller selbst als sekundären DNS-Server verweisen, denn schließlich sollte der sekundäre Eintrag nur kurzfristig im Ausnahmefall gebraucht werden. Folgen eines DNS-Ausfalls für Windows-ClientsOhne DNS können Active Directory Clients keine SRV-Einträge finden, die sie für das Auffinden der Domänencontroller benötigen. Die Clients können sich ohne diese Einträge nicht authentifizieren oder LDAP-Abfragen durchführen. Nach dem Verlust der DNS-Server funktionieren die Clients zunächst weiter, indem sie gecachte DNS-Einträge verwenden. Der SOA-Eintrag für die DNS-Domäne legt fest, wie lange die Standardgültigkeit (TTL, Time-To-Live) für DNS-Einträge ist, die von den Nameservern der Zone kamen. Die voreingestellte TTL für Windows-DNS ist 1 Stunde (3600 Sekunden). Wenn die SRV-Einträge abgelaufen und die DNS-Server immer noch nicht verfügbar sind, finden die Clients ihre Domänencontroller nicht mehr. Sie können Ihre Kerberos-Sitzungstickets nicht mehr erneuern und können sich daher nicht mehr mit Mitgliedsservern verbinden. Bei der Planung Ihrer DNS-Infrastruktur sollten Sie stets einen Ersatz-DNS-Server an jeder Niederlassung einplanen. Das kann ein normaler sekundärer Nameserver oder ein Domänencontroller mit Active-Directory-integrierter Zone sein. Ausfall eines DomänencontrollersWenn ein Domänencontroller ausfällt, merkt dies der Kerberos-Dienst auf den Clients, wenn die lokal gecachten Kerberos-Tickets ablaufen und der Kerberos-Dienst versucht, sie zu erneuern. Sobald der Client merkt, dass sein Anmeldeserver nicht antwortet, fragt er DNS nach anderen Domänencontrollern und benutzt einen von ihnen für die erneute Authentifizierung. Der Benutzer merkt nichts davon. Falls der ausgefallene Domänencontroller (DC) der einzige Controller am Standort war, müssen sich die Clients über WAN neu authentifizieren. Das verlangsamt die Authentifizierung je nach Geschwindigkeit der Anbindung. Während der lokale DC nicht verfügbar ist, dauern LDAP-Anfragen wie eine Suche nach Druckern oder die Verwendung von Outlook in einer Exchange 2000-Umgebung wegen der WAN-Leitungslatenz länger. Sollten keine anderen DCs zur Reauthentifizierung zur Verfügung stehen, verfallen irgendwann die Kerberos-Tickets des Clients, und er verliert die Verbindung zu Mitgliedsservern. Wenn sich die Clients abmelden, können sie sich mit gecachten Anmeldedaten wieder anmelden, doch die gecachten Anmeldedaten erlauben keinen Zugriff auf Mitgliedsserver. Merken Sie sich also, dass eine unterbrochene WAN-Leitung den Zugriff auf lokale Windows-Server beendet, falls es keine lokalen Domänencontroller gibt. Sie könnten eine Ersatz-WAN-Anbindung einrichten, beispielsweise eine ISDN-Leitung, die nur anspringt, wenn die Hauptanbindung unterbrochen ist. Alternativ können Sie einen lokalen Domänencontroller installieren. Der muss dann, wie wir im nächsten Abschnitt sehen werden, entweder ein GC-Server oder aber so konfiguriert sein, dass er Global Catalog Einträge cacht. Ohne Global Catalog anmeldenNormalerweise können sich Benutzer nicht an einer Domäne anmelden, wenn kein Domänencontroller verfügbar ist, der eine Kopie des Global Catalog besitzt. Der Grund hierfür ist, dass der GC die Mitgliedschaftsliste für universelle Gruppen hostet. Außerdem: Wenn sich Benutzer mit dem UPN anmelden (Benutzer@Firma.de), dann wird ein GC benötigt, um den UPN in seine Bestandteile zu zerlegen. Windows XP cacht den zerlegten Namen nach dem ersten Anmelden, doch Windows 2000 braucht bei jedem Anmeldevorgang per UPN einen GC. Bei Windows Server 2003 können nun normale Domänencontroller die Mitgliedschaft in universellen Gruppen cachen. Das erlaubt solchen Domänencontrollern, Benutzer zu authentifizieren, wenn der GC nicht erreicht werden kann. Der Cache für die Mitgliedschaft in universellen Listen macht einen Domänencontroller nicht zum GC-Server. Der cachende Domänencontroller lauscht nicht auf LDAP-Anfragen auf Port 3268, und er hostet keine Objekte aus anderen Domänen, wenn man von Mitgliedschaft in universellen Gruppen absieht. Das Cachen universeller Gruppen erfordert keine zusätzlichen Prozessoren oder mehr RAM bei den Domänencontrollern am Standort. Wenn aktiv, wird dieser Cache alle acht Stunden aktualisiert. Wurde ein Benutzer nach der letzten Aktualisierung einer universellen Gruppe hinzugefügt, werden die Berechtigungen, die zu dieser Gruppe (und allen Gruppen, denen diese Gruppe angehört) gehören, nicht in das PAC des Benutzers geschrieben. Sie sind daher auch nicht Bestandteil lokaler Zugriffstoken, die für den Benutzer auf Mitgliedsservern erzeugt werden. Der Cache für Mitgliedschaften in universellen Gruppen kann ungefähr 500 Gruppen speichern. Cachen von Mitgliedschaften universeller Gruppen aktivierenSie sollten das Cachen von Mitgliedschaften in universellen Gruppen an jedem Standort aktivieren, wo kein GC-Server steht.
Metadaten für einen verlorenen Domänencontroller löschenWenn Sie einen ausgefallenen Domänencontroller überhaupt nicht mehr zum Laufen bekommen, müssen Sie die Referenzen auf ihn aus Active Directory löschen. Diese so genannten Metadaten müssen gelöscht werden, ehe Sie einen anderen Server mit demselben Namen zu einem Domänencontroller hochstufen können. Sollten Sie gar eine ganze Domäne verlieren, so müssen Sie gleichfalls die Metadaten-Information für die Domäne entfernen, bevor Sie eine gleichnamige Domäne neu erstellen können. Das Werkzeug für das Entfernen der Metadaten ist ein Kommandozeilentool namens Ntdsutil. Das Löschen erfolgt im laufenden Betrieb von Active Directory. Verwenden Sie dazu diese Schrittfolge:
Sie können die gleiche Vorgehensweise verwenden, um eine Domäne zu entfernen, die nicht vollständig gelöscht wurde, als der letzte Domänencontroller außer Dienst gestellt wurde. Es muss nicht extra erwähnt werden, dass Sie größte Vorsicht walten lassen sollten, um nicht versehentlich funktionierende Domänen zu löschen. AusblickIm nächsten Teil der Artikelserie geht es um den Ausfall eines FSMO-Rolemasters und die entsprechenden Gegenmaßnahmen.
|
In diesem Beitrag
|
