Read-only Domänencontroller und Passwörter – Teil 2

Hi! Hier ist wieder Florian, wie versprochen mit dem zweiten Teil des Gastbeitrags (*) für den deds-Blog. Nachdem wir uns im ersten Teil um das Präpopulieren der Passwörter und die Password Replication Policy gekümmert haben, soll es in diesem zweiten Teil um Änderungen an den Passwörtern gehen und wie RODCs mit abgelaufenen Geheimnissen und Benutzern umgehen, die ihr Passwort ändern möchten.

Ein Passwort zurücksetzen

Ein RODC erfährt – wie alle anderen Domänencontroller – nur von Änderungen, wenn er sich über die Replikation von einem Server 2008-DC im Hauptstandort auf den neuesten Stand bringt. Passwörter werden jedoch speziell kommuniziert: Anstatt das Passwort nach einer Änderung vollständig zu replizieren, holt sich der RODC nur die Information, dass das Passwort geändert wurde. Der bisherige, gecachete Passwordhash des Benutzers wird auf dem RODC als „absent“, also „nicht vorliegend“, kennzeichnet. Faktisch wird die Information, in welchem Speicherblock das Passwort des Benutzers abgelegt ist, überschrieben. Somit ist das bisherige, nun veraltete Passwort nicht mehr erreichbar. Das neue Passwort wird, obwohl die Password Replication Policy es vielleicht erlaubt, vorerst nicht auf dem RODC geändert. Der RODC besitzt zu diesem Zeitpunkt kein gültiges Passwort des Benutzers in seinem Cache.

Beim Versuch der Authentifizierung mit dem neuen Passwort muss der RODC Kontakt mit dem Domänencontroller im Hauptstandort aufnehmen und ihn die Authentifzierung durchführen lassen. Erst wenn eingegebener Benutzername und Passwort korrekt eingegeben wurden und die Authentifizierung vollzogen wurde, repliziert der RODC das Passwort des Benutzers und cacht es – vorausgesetzt die PRP erlaubt dies.

Dieses Verhalten ist identisch mit einer normalen Benutzerauthentifizierung, die wir im ersten Teil kennengelernt haben. Dort wird das Benutzerpasswort (oder Computerpasswort) auch noch nicht auf dem RODC zwischengespeichert. Der RODC muss Kontakt zum Hauptstandort-DC aufnehmen und von ihm die Authentifizierung durchführen lassen.

Erst zu diesem Zeitpunkt versucht der RODC, das Passwort vom Hauptstandort-Domänencontroller zu replizieren und zwischenzuspeichern. Wie bereits bekannt, wird hierfür ebenfalls die Single Object Replication angewandt.

Das Passwort läuft ab

Benutzerkennwörter laufen nach dem in der Passwortrichtlinie bestimmten maximalen Kennwortalter ab. Dann müssen Benutzer ihre Passwörter ändern.

Versucht ein Benutzer sich an einem RODC anzumelden, obwohl sein Passwort abgelaufen ist, leitet der RODC die Anmeldeanfrage an seinen Hauptstandort-DC weiter, der die Authentifizierung analysieren soll. Obwohl der RODC die Evaluation und den Prompt nach Passwortänderung selbst durchführen könnte, rückversichert er sich:

Mit der Antwort „STATUS_PASSWORD_EXPIRED“ wird folgend die Meldung angezeigt, dass das Passwort abgelaufen ist und es geändert werden muss. Die Passwortänderung besteht aus dem aktuellen Passwort und der Eingabe des neuen Passworts in doppelter Form, um Tippfehler auszuschließen. Der Client benötigt für die Passwortänderung ein Kerberos-Ticket für den kadmin/passwd-Dienst, das der Hauptstandort-DC, über den RODC geleitet, vermittelt. Mit dem Ticket für den KPASSWD-Dienst steht der Passwordänderung nichts mehr im Weg – die Pakete finden ihr Ziel abermals über den RODC am Hauptstandort.

Konnte das Passwort erfolgreich geändert werden, wird am Client nun die „Das Passwort wurde erfolgreich geändert“-Meldung zu sehen. Gleichzeitig versucht der RODC, das neu erstellte Passwort vom Domänencontroller zu replizieren – schließlich hat es sich geändert und der Cache ist nicht mehr aktuell. Auch hier kommt die Single Object Replication für das Einspielen der Änderung zum Einsatz. Findet die SOR  erfolgreich statt, kann sich der Benutzer wie gehabt anmelden. Scheitert die Passwortreplikation auf den RODC, weil gerade in diesem Moment die Verbindung zwischen den Standorten zusammenbricht, wird die Passwortreplikation nicht abgeschlossen. Die Folge: das Passwort muss bei der nächsten Authentifizierung wieder über den schreibbaren Domänencontroller im Hauptstandort verifiziert werden, um eine erneute SOR zu versuchen.

Der Benutzer ändert sein Passwort

Ändern Benutzer auf freiwilliger Basis ihre Passwörter (löst dieses Statement nicht bei allen von uns ein kleines Kichern aus?), können die beiden Szenarien unterschieden werden:

a.    Passwortänderung im Hauptstandort

Das Passwort wird an einem schreibbaren Domänencontroller geändert und dann per normaler Replikation vom RODC repliziert. Der RODC setzt daraufhin das lokal zwischengespeicherte Passwort auf „nicht vorliegend“ und muss, sollte sich der Benutzer das nächste Mal anmelden, die Anmeldeanfrage an den RWDC leiten. Bei Erfolg versucht der RODC dann das Passwort per SOR vom Domänencontroller zu replizieren und es in seinen Cache aufzunehmen.

b.    Passwortänderung in der Zweigestelle am RODC

Für die Passwortänderung von Benutzern an Zweigstellen muss eine Unterscheidung getroffen werden: verschiedene Versionen von Windows verhalten sich hier unterschiedlich. Windows XP-Clientcomputer versuchen stets, Passwortänderungsanfragen direkt an einen schreibbaren Domänencontroller zu senden. Eine erfolgreiche Passwortänderung an Hauptstandort-DC wird dann per geplanter Replikation zum RODC getragen.

Neuere Clients, wie etwa Windows Vista oder Windows 7 wenden sich vertrauensvoll an den RODC im eigenen Standort, der auch diese Anfrage an den schreibbaren DC chained. Über die Kette gelangt der Client an das Passwort – woraufhin auch in diesem Fall der RODC per SOR das neue Passwort anfordert.

Ist die WAN-Verbindung nicht verfügbar, scheitert das Vorhaben in beiden Fällen direkt.

Zusammenfassung

In Kurzform nochmals die Erkenntnisse dieses zweiteiligen Artikels:

• Ein RODC cacht Passwörter, wenn es die PRP zulässt
• Werden Passwort erneuert oder geändert und ein RODC erfährt davon per Replikation, wird er, falls das betreffende Passwort zuvor gecacht war, die gecachte Kopie auf den Status „nicht vorliegend“ setzen.
• Um mit RODCs Erfolg zu haben, sollte man bei der für die Zwischenspeicherung erlaubten Konten unbedingt auch an Computer, nicht nur an Benutzer denken. Zwischengespeicherte Benutzerpasswörter allein reichen für eine Authentifizierung (ohne WAN-Verbindung) nicht aus.
• Passwortänderungen (egal ob durch ein Zurücksetzen oder vom Benutzer initiiert), die vom RODC zu einem schreibbaren DC gechained werden, versucht der RODC bei Erfolg per Single Object Replication zu replizieren und in seinem Cache abzulegen.
• Geänderte Passwörter landen nur erneut im Cache des RODCs, wenn sich der Benutzer mit dem neuen Passwort anmeldet.
• Für Passwort-Änderungen ist stets eine Verbindung zwischen RODC und RWDC notwendig – zum Zeitpunkt des Anmeldens des Benutzers oder bei der eigentlichen Passwortänderung (jeweils aus dem RODC-Standort heraus).
• Auf dem RODC zuvor populierte Passwörter werden nicht automatisch erneut in den Cache des RODCs geschrieben – dies muss manuell oder über die hier beschriebenen Methoden geschehen (Replikation der Änderung, SOR).

Abschließend bleibt nur noch ein Hyperlink zu einem TechNet-Artikel, den jeder, der sich mit RODCs beschäftigt, unbedingt durchlesen sollte: „Appendix A: RODC Technical Reference Topics“, https://technet.microsoft.com/en-us/library/cc754218(WS.10).aspx

Cheerio!
Florian

* Rechtlicher Hinweis: Bei den hier als "Gastbeitrag" markierten Artikeln handelt es sich um Blogs, die von nicht-Microsoft Mitarbeitern verfaßt wurden. Diese Beiträge geben ausschließlich die Meinung des jeweiligen Autors wieder und stimmen nicht unbedingt mit der Meinung von Microsoft überein. Microsoft macht sich diese Beiträge ausdrücklich nicht zu eigen. Eine Vorabkontrolle der Beiträge findet nicht statt. Dementsprechend kann Microsoft keine Verantwortung oder Gewähr für die Beiträge übernehmen.