Active 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.
-
Teil Eins: Ausfall eines DNS-Servers und eines Domänencontrollers
-
Teil Zwei: Ausfall eines FSMO-Rollenmasters
-
Teil Drei: Ausfall von zentralen Replikationskomponenten wie Brückenkopf-Server, ISTGs und WAN-Leitungen
-
Teil Vier: Pflege und Wartung der Datenbank
-
Teil Fünf: Active Directory wiederherstellen
Die Artikelserie basiert auf Kapitel Zehn des Standardwerks „Windows Server 2003 für Insider“ von William Boswell aus dem Verlag Markt + Technik. Sie können dieses über 1300 Seiten starke Buch auch in unserem Buchshop bestellen oder als eBook herunterladen.
|
Teil 1: Ausfall eines DNS-Servers und eines Domänencontrollers |
|
Teil 2: Ausfall eines FSMO-Rollenmasters |
|
Teil 4: Active Directory-Pflege |
|
Teil 5: Active Directory wiederherstellen |
Neue Features von Windows Server 2003
Das 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-Servers
Der 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 vermeiden
Wenn 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-Clients
Ohne 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änencontrollers
Wenn 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 anmelden
Normalerweise 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 aktivieren
Sie sollten das Cachen von Mitgliedschaften in universellen Gruppen an jedem Standort aktivieren, wo kein GC-Server steht.
1. Öffnen Sie die Konsole ACTIVE DIECTORY-STANDORTE UND -DIENSTE.
2. Markieren Sie den Standort, den Sie konfigurieren wollen.
3. Im rechten Teil öffnen Sie das Fenster Eigenschaften des Objekts NTDS SITE SETTINGS (siehe Bild 1).
4. Wählen Sie die Option ZWISCHENSPEICHERN DER UNIVERSELLEN GRUPPENMITGLIEDSCHAFT AKTIVIEREN. Ändern Sie CACHE AKTUALISIEREN VON nicht. Der KCC findet den nächsten Standort mit einem GC-Server.
5. Klicken Sie auf OK, um die Änderung zu speichern und das Fenster zu schließen.
Metadaten für einen verlorenen Domänencontroller löschen
Wenn 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 Entfernen der Metadaten ist ein Kommandozeilentool namens Ntdsutil. Das Löschen erfolgt im laufenden Betrieb von Active Directory. Verwenden Sie dazu diese Schrittfolge:
1. Starten Sie Ntdsutil.
2. Geben Sie an der Eingabeaufforderung Ntdsutil: den Befehl metadata cleanup ein, um die gleichnamige Eingabeaufforderung zu öffnen.
3. Geben Sie ? ein, um die Liste der Optionen anzuzeigen:
|
Ntdsutil-Optionen |
|
|
? |
Zeigt diese Hilfeinformationen an |
|
Connections |
Verbindung mit einem bestimmten Dömänencontroller herstellen |
|
Help |
Zeigt diese Hilfeinformationen an |
|
Quit |
Zum vorherigen Menü wechseln |
|
Remove selected domain |
DS-Objekte für die gewählte Domäne entfernen |
|
Remove selected Naming Context |
Entfernen Sie die DS-Objekte für den gewählten Namenskontext |
|
Select operation target |
Standorte, Server, Domänen, Funktionen und Namenskontexte wählen |
4. Geben Sie connections und dann ? für eine Liste der Optionen ein.
|
Ntdsutil-Optionen |
|
|
Clear creds |
Frühere Verbindungsinformationen löschen |
|
Connect to domain %s |
Verbindung mit Server, DNS-Namen oder IP-Adresse herstellen |
|
Connect to server %s |
Verbindung mit Server, DNS-Namen oder IP-Adresse herstellen |
|
Help |
Zeigt diese Hilfeinformationen an |
|
Info |
Verbindungsinformationen anzeigen |
|
Quit |
Zum vorherigen Menü wechseln |
|
Set creds %s %s %s |
Verbindungsinformationen als Domäne, Benutzer und Kennwort festlegen (Verwenden Sie "NULL" für ein Null-Kennwort, * um das Kennwort von der Konsole einzugeben) |
5. Wenn Sie an einem Mitgliedsserver arbeiten und nicht mit Administratordaten angemeldet sind, verwenden Sie den Befehl set creds, um Ihre Verbindungsinformationen angeben zu können.
6. Geben Sie connect to server <dsa> ein, um sich mit einem Server zu verbinden. Hierbei ist <dsa> der vollqualifizierte DNS-Name des DC, auf dem Sie die Verzeichnisveränderung vornehmen wollen. Das geht bei jedem funktionsfähigen Domänencontroller. Die Einträge und Transaktionsergebnisse sehen bis zu dieser Stelle wie folgt aus:
server connections: set creds firma.de administrator passwort
server connections: connect to server srv01.firma.de
Bindung mit "srv01.firma.de" als firma.de\administrator...
Verbindung mit "srv01.firma.de" als firma.de\administrator.
7. Geben Sie erst quit, dann select operation target ein, um die gleichnamige Eingabeaufforderung zu öffnen. Rufen Sie über ? die Optionsliste auf:
|
Optionen |
|
|
Connections |
Verbindung mit einem bestimmten Domänencontroller herstellen |
|
Help |
Zeigt diese Hilfeinformation an. |
|
List current selections |
Listet den aktuellen Standort, Server, Namenskontext sowie die aktuelle Domäne auf |
|
List domains |
Listet alle Domänen auf, die Querverweise haben |
|
List domains in site |
Listet die Domänen im gewählten Standort auf |
|
List naming contexts |
Führt die bekannten Namenskontexte auf |
|
List roles for connected server |
Listet die Funktionen auf, die dem verbundenen Server bekannt sind |
|
List servers for domain in site |
Listet die Server für die gewählte Domäne und den Standort auf. |
|
List servers in site |
Listet die Server im gewählten Standort auf |
|
List sites |
Listet die Standorte im Unternehmen auf |
|
Quit |
Zum vorherigen Menü wechseln |
|
Select domain %d |
Domäne %d zur gewählten Domäne machen |
|
Select naming context %d |
Namenskontext %d zum gewählten Namenskontext machen |
|
Select server %d |
Server %d zum gewählten Server machen |
|
Select site %d |
Standort %d zum gewählten Standort machen |
8. Geben Sie List Sites ein. Die Ausgabe könnte etwa so aussehen:
select operation target: list sites
4 Standort(e) gefunden
0 - CN=Frankfurt,CN=Sites,CN=Configuration,DC=firma,DC=de
1 - CN=Hamburg,CN=Sites,CN=Configuration,DC=firma,DC=de
2 - CN=Bonn,CN=Sites,CN=Configuration,DC=firma,DC=de
3 - CN=Wiesbaden,CN=Sites,CN=Configuration,DC=firma,DC=de
9. Geben Sie select site <#> ein, wobei <#> die Nummer des Standorts ist, der den zu entfernenden Server enthält.
select operation target: select site 1
Standort - CN=Hamburg,CN=Sites,CN=Configuration,DC=firma,DC=de
Keine aktuelle Domäne
Kein aktueller Server
Kein aktueller Namenskontext
Metadaten löschen, Fortsetzung
10. Geben Sie list domains in site ein. Die Beispielausgabe sieht wie folgt aus:
select operation target: list domains in site
1 Domäne(n) gefunden
0 - DC=firma,DC=de
11. Geben Sie Select Domain <#> ein, wobei <#> die Nummer der Domäne ist, die den zu entfernenden Server enthält.
select operation target: select domain 0
Standort - CN=Hamburg,CN=Sites,CN=Configuration,DC=firma,DC=de
Domain - DC=firma,DC=de
Kein aktueller Server
Kein aktueller Namenskontext
12. Geben Sie list servers for domain in site ein. Die Beispielausgabe sieht wie folgt aus:
select operation target: list servers for domain in site
2 Server gefunden
0 - CN=SRV01,CN=Servers,CN=Hamburg,CN=Sites,CN=Configuration,DC=firma,DC=de
0 - CN=SRV02,CN=Servers,CN=Hamburg,CN=Sites,CN=Configuration,DC=firma,DC=de
13. Geben Sie Select Server <#> ein, wobei <#> die Nummer des zu entfernenden Servers ist.
select operation target: select server 0
Standort - CN=Hamburg,CN=Sites,CN=Configuration,DC=firma,DC=de
Domäne- DC=firma,DC=de
Server - CN=SRV02,CN=Servers,CN=Hamburg,CN=Sites,CN=Configuration,DC=firma,DC=de
DSA-Objekt - CN=NTDS Settings,CN=SRV02,CN=Servers,CN=Hamburg,CN=Sites,
CN=Configuration,DC=firma,DC=de
Computerobjekt - CN=SRV02,OU=Domain Controllers,DC=firma,DC=de
14. Jetzt haben wir das zu löschende Serverobjekt endlich ins Visier genommen. Geben Sie q ein, um wieder zur Eingabeaufforderung metadata cleanup: zu gelangen.
15. Geben Sie remove selected server ein. Ein Fenster mit der Bitte um Bestätigung des Vorgangs wird angezeigt.
16. Klicken Sie auf JA – nun ist es vollbracht. Die Beispielausgabe sieht so aus:
Metadata cleanup: remove selected server
"CN=SRV02,CN=Servers,CN=Hamburg,CN=Sites,CN=Configuration,DC=firma,DC=de"
von Server "srv01.firma.de" entfernt.
17. Verlassen Sie Ntdsutil und warten Sie, bis die Änderung repliziert ist.
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.
Ausblick
Im nächsten Teil der Artikelserie geht es um den Ausfall eines FSMO-Rolemasters und die entsprechenden Gegenmaßnahmen.
Die Artikelserie basiert auf Kapitel Zehn des Standardwerks „Windows Server 2003 für Insider“ von William Boswell aus dem Verlag Markt + Technik. Sie können dieses über 1300 Seiten starke Buch auch in unserem Buchshop bestellen oder als eBook herunterladen. (mja)
|
Teil 1: Ausfall eines DNS-Servers und eines Domänencontrollers |
|
Teil 2: Ausfall eines FSMO-Rollenmasters |
|
Teil 4: Active Directory-Pflege |
|
Teil 5: Active Directory wiederherstellen |