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

Hi! Heute schreibt Florian, ein MVP-Award-Träger aus dem süddeutschen Raum nahe der Grenze zur Schweiz. Diesmal soll es in einem zweiteiligen Gastbeitrag (*) für den Blog des deutschen AD-Teams um Passwörter und deren Speicherung und Verarbeitung auf Read-Only Domänencontrollern gehen.

Read-Only-Domänencontroller, wir werden sie im folgenden mit RODC abkürzen, wurden mit Windows Server 2008 eingeführt. Entgegen der Meinung einiger Mitglieder diverser Internetforen sind RODCs nicht die Reinkarnation von Backup-Domänencontrollern (BDC) aus den „guten, alten“ NT-Zeiten. Vielmehr sind RODCs die Antwort auf Szenarien mit problematischen Standorten – physikalischer sowie topologischer Natur. Einen Überblick über RODCs gibt der folgende TechNet-Artikel: https://technet.microsoft.com/en-us/library/cc732801(WS.10).aspx sowie das RODC-Deployment Guide: https://technet.microsoft.com/en-us/library/cc771744(WS.10).aspx.

In diesem und einem folgenden Beitrag wollen wir uns speziell mit Passwörtern auf RODCs beschäftigen. Per Voreinstellung werden nämlich keine Passwörter auf RODCs gespeichert – das entspricht auch der Haltung, dass RODCs per se auf Grund ihrer Einsatzszenarien erstmal als „unsicher“ eingestuft werden. Anmeldungen werden stets an einen Windows Server 2008-Domänencontroller weitergeleitet, der daraufhin die Authentifizierung vornimmt und die entsprechenden Kerberos-Tickets für die Authentifizierung und den Zugriff auf weitere Dienste ausstellt. Der RODC spielt hierbei maximal „Proxy“ zwischen dem DC in der Hauptstelle und dem Client. Die Authentifizierungsanfragen werden somit „gechained“.

Um Passwörter auf einem RODC zwischenzuspeichern, gibt es zwei Möglichkeiten: das Präpolulieren der Passwörter, sodass der RODC die Passwörter einiger Benutzer und Computer bereits gespeichert hat und Authentifizierungen selbstständig übernehmen kann, sowie das Erlauben des Zwischenspeicherns von Passwörtern nach erfolgreicher Anmeldung unter Verwendung der Password Replication Policy (PRP).

Soll ein RODC Passwörter von Benutzer oder Computern zwischenspeichern, damit sie bei späteren Anmeldungen lokal verifiziert werden können und somit den WAN-Link schonen, muss die Password Replication Policy angepasst werden. Die PRP besteht prinzipiell aus zwei Gruppen, die das Cache-Verhalten von RODCs mitbestimmen: die „Allowed RODC Password Replication Group“ und die „Denied RODC Password Replication Group“. Die Mitgliedschaft in einer dieser beiden Gruppen signalisiert dem Domänencontroller im Hauptstandort, ob ein Benutzerpasswort auf Anfrage per Single Object Replication an einen RODC gesendet werden darf. Passwörter von Mitgliedern der „Denied RODC Password Replication Group“, dies sind meist administrative Konten und Gruppen wie Domänen-Admins, Enterprise-Admins oder Schema-Admins, werden nie zum RODC repliziert. Passwörter von „Allowed RODC Password Replication-Group“-Mitgliedern werden auf Anfrage zum zum RODC repliziert – per Vorgabe ist diese Gruppe allerdings leer.

Die Anfrage wird erzeugt, wenn Benutzer oder Computer unter anderem mit der Hilfe des schreibbaren Domänencontrollers im Hauptstandort authentifiziert wurden.

Um die Authentifizierung an einem RODC zu verstehen, benötigen wir einige Grundlagen zu Kerberos – und einen Netzwerksniffer wie Wireshark oder Netmon. Die beiden Tools können frei aus dem Internet heruntergeladen werden, für die Kerberos-Grundlagen sorgt  https://technet.microsoft.com/en-us/library/bb742516.aspx.

Benutzer und Computer richten ihre Anmeldeanfrage und den damit verbundenen Request nach einem Kerberos-Ticket-Granting-Ticket (TGT) an den RODC, der sich im selben Standort befindet und ihnen vom DCLocator-Prozess zugewiesen wurde.

Möchte ein Benutzer sich authentifizieren und für einige in der Site verfügbare Dienste ein Dienst-Ticket erhalten, wendet er sich zuerst an den RODC. Der RODC, hemdsärmelig, wie er eben gerade ist, kann die erhaltene Anfrage (das AS-REQ-Paket) des Client nicht selbstständig auswerten, da das Passwort vom Benutzer bisher nicht gecacht wird. Die Anfrage wird kurzerhand an einen schreibbaren Server 2008-DC im Hauptstandort weitergeleitet (gechained):

Wird die Anfrage korrekt beantwortet und der RODC erhält die Antwort des schreibbaren DCs, sendet er die Antwort an den Client zurück. Gleichzeitig versucht er, das Passwort des gerade authentifizierten Benutzers zwischenzuspeichern. Er sendet eine Single-Object-Replication (SOR)-Anfrage an den 2008-DC, der daraufhin die PRP prüft, ob das Geheimnis des Accounts auf dem RODC zwischengespeichert werden darf. Ist die Zwischenspeicherung erlaubt, wird das Geheimnis repliziert – außerhalb der normalen Replikation:

Hinweis: die USN des Benutzerobjektes für den RODC wird bei der Single Object Replication nicht geändert, sodass das geänderte Benutzerpasswort bei der nächsten, geplanten Replikation nochmals übertragen wird und dann „offiziell“ repliziert wird.

Im nächsten Schritt wird der Client ein Dienstticket anfordern, um beispielsweise einen Webserver in seinem Standort erreichen zu können. Per TGS-REQ versucht er erneut, beim RODC ein entsprechendes Ticket zu erhalten. Der RODC muss wieder passen, obwohl er das Benutzerpasswort zwischengespeichert hat. Der Grund ist, dass das TGT, das zuvor vom Hauptstandort-DC ausgestellt wurde, mit seinem Passwort verschlüsselt wurde. Das Verschlüsselungspasswort ist das des krbtgt-Accounts, das sich zwischen schreibbaren- und RODCs unterscheidet. Um also an ein gültiges Dienstticket zu kommen, muss der RODC die Anfrage also erneut „chainen“.

Bei der (erfolgreichen) Antwort des Standort-DCs wendet der RODC einen pfiffigen Trick an: Anstatt dem Benutzer das Dienstticket einfach auszustellen, gaukelt er ihm vor, dass sein TGT zurückgezogen wurde (KRB5KDC_ERR_TGT_REVOKED). Der Client muss daraufhin sein TGT und anschließend sein Dienstticket erneut anfordern. Dies ist die Chance des RODC! Nun kann er den Client, da er das Geheimnis kennt, selbstständig authentifizieren und ihm anschließend ein Dienstticket für den Webserver ausstellen – ohne den schreibbaren DC jenseits der WAN-Strecke zu bemühen. Den Client freut’s!

 

Die zweite Möglichkeit, das Präpopulieren von Passwörtern, ist über mehrere Wege möglich. Ziemlich versteckt befindet sich ein entsprechender Dialog in „Active Directory Benutzer und Computer“. In den Eigenschaften des Computerobjektes des RODCs befindet sich ein Reiter „Password Replication Policy“, über den per Klick auf „Advanced“ der Dialog „Advanced Password Replication Policy for <RODC-Name>“ aufgerufen wird. In diesem Dialog lassen sich per Dropdown-Menü Accounts anzeigen, deren Passwörter auf dem RODC zwischengespeichert werden – oder Accounts, die sich schonmal an diesem RODC angemeldet haben. Unser Augenmerk gilt aber nun dem Button „Prepopulate Passwords...“. Es können nur Passwörter von Accounts vorgespeichert werden, die auch per PRP für das Cachen auf einem RODC zugelassen sind – Mitglieder der „Deny RODC Password Replication Group“ können nicht vorgespeichert werden.

Wurde der entsprechende Benutzer ausgewählt, warnt das System mit folgendem Dialog:

Für eine erfolgreiche Anmeldung reicht das Populieren von BenutzerPasswörtern nicht aus. Computer müssen sich beim Start ebenfalls an Active Directory authentifizieren, um einen sicheren Kanal zum Domänencontroller aufbauen zu können. Kommt dieser sichere Kanal nicht zu stande, können keine Benutzer authentifiziert werden. Es ist also notwendig, dass auch die Computerkonten der Maschinen, an denen Benutzer offline arbeiten sollen, ebenfalls vorgespeichert werden.

Wer Wartungs- und Provisioningskripte anpassen will, kann das mit Hilfe von repadmin tun – repadmin lässt mit dem Schalter /rodcpwdrepl Passwort von der Kommandozeile aus auf RODCs speichern. Der Befehl

repadmin /rodcpwdrepl rodcr2 2008r2 „CN=Tina Maier,OU=Stuttgart,DC=contoso,DC=com“

populiert Tinas Passwort automatisch auf den RODC.

Der Unterschied der beiden Methoden sollte klar geworden sein: Während das Präpopulieren der Passwörter das Passwort direkt auf den RODC repliziert, sodass das Geheimnis dort gespeichert wird, sorgt die PRP nur dafür, dass, sollte sich der Benutzer irgendwann tatsächlich am RODC anmelden wollen, das Passwort zwischengespeichert wird, wenn der Authentifizierungsprozess vom schreibbaren Domänencontroller in der Hauptstelle durchgeführt wurde. Im ersten Fall ist das Passwort sofort auf dem RODC in gecachter Form verfügbar, im zweiten Fall wird es nach der ersten Authentifzierung zwischengespeichert.

Nun, da die Geheimnisse von Benutzern und Computern auf dem RODC liegen, müssen wir uns die Frage stellen, wie sich der RODC bei Passwortänderungen oder dem Zurücksetzen von Passwörtern verhält. Um dem Verhalten auf die Spur zu gehen, werden wir auch im zweiten Teil den Netzwerkverkehr auf dem RODC protokollieren. Der zweite Teil erscheint nächste Woche auf diesem Blog.

Bis dann!
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.

Comments

• Anonymous
  January 01, 2003
  Hi Thorsten, danke für die Blumen. Freut mich, dass der Artikel ankommt. Die Passwörter werden niemals in Klartext zwischen Domänencontrollern repliziert - auch nicht zu RODCs. Sie werden als Hash bzw. in bestimmten Fällen als verschlüsselte Werte in einem verschlüsselten Blob übertragen. Viele Grüße, Florian

• Anonymous
  January 06, 2010
  Hallo Florian, dies ist eine super Beschreibung für den RODC. Hierzu habe ich nur noch eine Verständnisfrage: Werden den auf den RODC wirklich die Passwörter repliziert oder nur die Hashwerte der Passwörter? Gruß Thorsten