RODC - Vertrauensstellung - PRP Policy

[notimportant 0]

Hallo in die Runde,

ich bräuchte eine zündende Idee, da ich momentan nicht weiterkomme. Unser AD besteht aus einer sternförmigen Netzwerkstruktur mit zentralen beschreibbaren DCs und RODCs in der Fläche (RODC, da keine 24/7 Anwesenheit in den Zweigstellen).
Wir haben seit einiger Zeit das klassische Problem, dass Rechner die Vertrauensstellung zur Domäne verlieren. Bei einer 5-stelligen Anzahl an Rechnern ist es zwar lediglich ein kleines Grundrauschen, aber doch immer wieder nervig, da man sich an das jeweilige System lokal hinsetzen muss.
Ich habe versucht das Problem so weit es geht einzugrenzen (Es sind keine Spezialfälle wie Klone, Snapshots usw. dabei) und sehe einen Zusammenhang mit unserer PRP-Policy auf den RODCs, da ich das Problem folgendermaßen reproduzieren kann:

 

• Ein Rechner ist im normalen 30-Tages-Turnus an der Reihe sein Maschinenpasswort zu erneuern.
• Auf den RODCs des jeweiligen Bereiches sind User und Computer in der jeweiligen PRP-Policy eingetragen.
• Entferne ich den Rechner aus der PRP-Policy und lasse ihn in den automatischen PW-Wechsel laufen verliert er nachvollziehbar die Vertrauensstellung zur Domäne.
• Der LastPasswordSet-Wert beim Computerobjekt im AD bleibt auf dem „alten“ Datum.
• Im Pfad HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\$MACHINE.ACC sehe ich, dass die Werte CupdTime und OupdTime angefasst wurden mit dem Zeitstempel des Vertrauensstellungsverlustes, daher gehe ich davon aus, dass der Mismatch zwischen dem im AD gespeicherte Computerpasswort und dem lokal gesetzten Passwort auf dem Client daher rührt, dass das Passwort auf dem Client geändert wurde, nicht aber im AD.

 

Vielleicht ist das ja alles normal, aber ich bekomme den Hintergrund nicht ganz zusammen. Soweit ich es verstanden habe funktioniert die initiale Anmeldung wie folgt (MS Docs):

 

1. Client etabliert Netlogon SecureChannel zum RODC
2. RODC forwarded das zum DC
3. DC gibt die Kerberos Authentification zurück an den RODC
4. RODC repliziert das PW (wenn er denn darf)
5. RODC gibt die Authentifizierung an den Client

 

Das sollte doch bei der PW-Erneuerung ähnlich ablaufen:

 

1. Client etabliert SecureChannel zum RODC und will sein PW erneuern
2. RODC gibt das an den DC weiter
3. DC sagt OK und gibt die Bestätigung an den RODC
4. RODC gibt die Bestätigung an den Client
5. FALLS der Client in der PRP steht repliziert der RODC das PAsswort von einem DC in seine lokale Datenbank. (Wenn nicht dann eben nicht. Ansonsten besteht dch kein Unterschied?)
6. Client macht jetzt erst den Haken an sein Passwort

 

Und der Client ändert doch sein Passwort lokal nur auf den von ihm neu generierten Wert, wenn er von einem DC das OK dazu bekommen hat. Ansonsten verwirft er die Änderung. Mir ist nicht klar, wie mein Bild oben zustande kommt. Auch wenn ein Client nicht mehr in der PRP-Policy eingetragen ist, sollte doch ein PW-Wechsel keine Probleme bereiten, da er dann mit einem beschreibbaren DC reden sollte. Oder gibt es eine Abhängigkeit, wenn er bereits eingetragen _war_, dass der RODC das Passwort noch hat und Probleme bereitet?

 

Die Probleme die bspw. hier (adsecurity.org) beschrieben werden...

Zitat

The computer account has to have the password cached on the local RODC for the password change to be successful. Once the RODC updates its local database with the new computer account password, it replicates the updated password to a writable DC. If the password is not cached on the RODC (or is not allowed to be cached), the request is forwarded to the writable DC nearby (2008 or newer).

sind doch so nicht korrekt? Das Konstrukt funktioniert doch auch mit DC+RODC+keine PRP. Vor allem Satz 2 ist doch Käse. Der RODC holt sich doch das upgedatet AD-Objekt vom schreibbaren DC per RSO?

 

Auch hier (active-directory-faq.de)

Zitat

Read Only Domain Controller: Der Client hat einen RODC zum abgleich des Passwortes kontaktiert, der Client ist aber nicht in der Password Replication Policy eingetragen.

Das sollte doch grundsätzlich nicht das Problem sein.

 

Vielleicht kann jemand Licht ins Dunkel bringen : )

 

Grüße

bearbeitet 7. Juli 2020 von notimportant

[NilsK 2.930]

Moin,

 

Warum überhaupt RODC?

 

Gruß, Nils

[notimportant 0]

Ich wusste, dass diese Frage kommt : )

 

Ja, wir haben Interesse daran, dass ein ggf. kompromittierter RODC nicht die Passwörter der ganzen Umgebung preisgibt.

Und das Design stammt im Prinzip aus der Feder von MS selbst : )

 

Die RODCs in der Fläche stehen nun nicht in 24/7 betreuten Rechenzentren wie es die beschreibbaren DCs tun. Oberste Priorität beim Design war, dass bei Ausfall der WAN-Leitungen ein Arbeiten in den Zweigstellen weiterhin gewährleistet ist, bei gleichzeitigem Schutz des kompletten Unternehmens-ADs.

 

Dazu werden die PRPs mit den Benutzer- und Computerkonten befüllt und teilweise sogar vorab gecachet (wichtige Service Accounts beispielsweise). Das funktioniert soweit alles prächtig. Aus historischen Gründen wurden die Gruppen mit den Benutzern und Computern in der PRP-Liste der RODCs turnusmäßig geleert und neu befüllt, was nicht ideal geskriptet wurde und in einem Gap resultierte, in der die Clients temporär nicht in der PRP-Liste stehen. Meine Vermutung ist, dass Clients zu genau diesem Zeitpunkt die Vertrauensstellung verlieren, wenn die PRP-Gruppen geleert und neu befüllt werden und ein Client in den turnusmäßigen 30-Tage-PW-Account-Erneuerungsmodus rutscht. Was ja ein Aufeinandertreffen von vielen Zufällen bedingt.

 

Genau dieses Verhalten kann ich reproduzieren, indem ich einen Client, der bereits dem RODC bekannt ist ( = er ist in einer Gruppe im Reiter Password Repl. Policy eingetragen, meinetwegen seit Monaten) absichtlich aus der PRP-Liste lösche, wenn er in den 30-Tage-Turnus läuft. Das Verhalten der Befüllung PRP-Gruppen zu ändern ist nicht das Problem. Mich würde der Grund für das Verhalten der Clients interessieren, ob es sich evtl. um einen Fall handelt, den Microsoft nicht im Design bedacht hat.

 

Ich sehe drei Fälle im Konstrukt DC (Site A) -> RODC (Site B) -> Client (Site B). [Site B hat nur RODCs]

Fall A: Client + User stehen nicht in der PRP

• jegliche Authentifizierung läuft über den beschreibbaren DC

 

Fall B: Client + User stehen in der PRP

• bis auf die initiale Authentifizierung läuft die normale Authentifizierung über den RODC

 

Fall C: User steht in der PRP + Client steht nicht mehr in der PRP

-> gibt es hier irgendeine Konstellation, die den PW-Renewal-Prozess bricht? Nach 10-maligen Lesen von Desmonds AD komme ich für den Spezialfall auf keine befriedigende Lösung:

1. Ich lösche den Client aus der PRP-Liste
2. Innerhalb der normalen AD-Replikation "löscht" der RODC die lokale Kopie des Passworts. (Ja?)
3. Der Client kontaktiert den RODC (Tut er das noch? Oder kann er mit dem RODC keinen Secure Channel mehr aufbauen, da der RODC den PW-Hash als null markiert?)
4. Egal, was bei (3) passiert, entweder über den RODC oder direkt durch den Client erreicht der Request mMn den beschreibbaren DC. Der beschreibbare DC updatet das Computerobjekt und schickt das OK an den Client direkt oder über den RODC.
5. Das "OK" müsste am Client ankommen und das neue Computerpasswort als aktiv gesetzt werden.

 

Ob der RODC jetzt das Passwort repliziert (RWDC checkt PRP mit Ja) oder nicht (RWDC checkt PRP mit Nein) sollte doch keine Rolle spielen... Irgendwo muss in der "Provokation" des Falles die Erklärung liegen.

 

Vielleicht ist das alles einfach zu speziell. In dem Fall wäre mein nächster Schritt den o.g. Spezialfall zu reproduzieren und auf dem Client mal einen Netzwerktrace mitlaufen zu lassen...

 

Grüße

 

 

 

 

bearbeitet 7. Juli 2020 von notimportant

[NilsK 2.930]

Moin,

 

Nur weil jemand von Microsoft beteiligt war, ist so ein Design ja nicht außerhalb der Diskussion. Ich habe noch nie (!) ein Design gesehen, in dem RODCs wirklich sinnvoll gewesen wären.

 

Also direkt gefragt: könnte man nicht einfach auf die RODCs verzichten?

 

Gruß, Nils

 

[notimportant 0]

Verzichten in dem Sinne von "Tausch durch beschreibbare DCs" würde ich jetzt persönlich verneinen, da ich es durchaus als legitimen Grund sehe bei unserer Zweigstellendichte im dreistelligen Bereich Read Only Replikas zu nutzen. Ob man jetzt einen DC unbedingt überall haben möchte aus Gründen der Ausfallsicherheit... Darüber kann - und wird - man sicherlich diskutieren.

 

Die Verwirrung um das aktuelle Phänomen behebt das allerdings nicht. Wie gesagt, das ist nicht mal im Ansatz ein Deal-Breaker für das aktuelle Design. Eher mal wieder die Neugierde eine fachliche Kuriosität aufzuklären : )

[MurdocX 949]

vor 5 Stunden schrieb notimportant:

Fall A: Client + User stehen nicht in der PRP

• jegliche Authentifizierung läuft über den beschreibbaren DC

Würde ich jetzt, nachdem ich es nachgelesen habe, deine Aussage verneinen. Der RODC dient dann als eine Art Authentifizierungsproxy. 

Quelle: Active Directory: Designing, Deploying, and Running Active Directory

 

Habt ihr in den Außenstandorten, bei denen das Problem auftritt, zufällig mehr als ein RODC?

[notimportant 0]

vor 7 Stunden schrieb MurdocX:

Würde ich jetzt, nachdem ich es nachgelesen habe, deine Aussage verneinen. Der RODC dient dann als eine Art Authentifizierungsproxy. 

Quelle: Active Directory: Designing, Deploying, and Running Active Directory

Stimmt. Die Tickets wären aber immer mit dem Domain-krbtgt-Account signiert, wenn ich es richtig verstehe. Der RODC guckt sich den Request immer an und prüft, ob er das Passwort in seiner lokalen Datenbank hat. (Und frägt auch jedes mal nach, ob er das PW nicht repliziert bekommt? Und ein beschreibbarer DC prüft die PRP jedes mal?) Und ich frage mich, ob genau an diesem Punkt vielleicht etwas schiefgeht, wenn der Rechner kurzfristig aus der PRP fliegt.

 

Wir haben strikt einen RODC pro Site. Dadurch, dass das Problem über einen längeren Zeitraum sehr sporadisch auftritt, verteilt über alle Standorte, schließe ich die üblichen Verdächtigen wie Zeitabweichung usw. aus. Der Dreh mit den PRP-Gruppen war eher Zufall, lässt sich aber wunderbar reproduzieren : )

[MurdocX 949]

Ich glaube das Thema ist zu detailliert und intensiv für ein Forum, auch wenn meine Neugier geweckt wurde  

 

Was würde denn eigentlich gegen die PRP bei Clients vor Ort sprechen? Wenn ich so meine Gedanken schweifen lasse und den Fall einer Kompromittierung oder Diebstahl des RODC durchgehe, dann wäre die logische Konsequenz das Rücksetzen der Computer und Benutzerpasswörter. 
 

Ergo, könnte man die PRP für die Clients und Benutzer eingeschaltet lassen. Wäre sicher auch im Sinne des RODCs.  

[notimportant 0]

Genauso wollen wir das auch im Fall des Falles handhaben. Das tägliche Leeren und Neubefüllen der Gruppen hat(te) historische Gründe in der Organisationsstruktur. Das stellen wir gerade ab, die Clients und Nutzer bleiben nun dauerhaft (also ohne temporären Ausfall, dauherhaft war das vorher auch) in der PRP-Allow drinnen.

 

Hier techcommunity.microsoft.com wird in einem Nebensatz aber immerhin genau mein Problem erwähnt:

Zitat

However, we have seen some issues in the past if there was ‘intermittent’ connectivity, and a DC is resolved/found, but something blocks unfettered communications to the DC (such as a firewall rule or some other connectivity issue).  In that case, the client password change process may not bail-out.  The local device’s registry may get updated with a new password - but the DC won’t be updated.  This is rare, and not normal, but if it happens, you may be on the road to secure channel issues.

Das beschreibt zumindest genau das Bild, das ich sehe. Warum ich das durch das Löschen PRP-Mitgliedschaft provozieren kann erschließt sich mir aber noch nicht.

 

PrtQry-Log gegen den RWDC sieht m.E. sauber aus. Vielleicht sollte ich mich auf Firewall/Netzwerk/AV konzentrieren.

 

Ist wohl aber wirklich zu speziell für ein Forum.

 

Danke

Grüße

PortQryLog.txt

[NilsK 2.930]

Moin,

 

also, ohne mit dem Fuß aufstampfen zu wollen - aber für mich klingt das nach einem Gesamtkonstrukt, das ich wirklich noch mal kritisch hinterfragen würde. Ja, ich weiß, Microsoft war daran beteiligt, aber wie gesagt - dadurch wird das Konstrukt ja nicht automatisch gut. 

 

Aber nix für ein Forum, da hat Jan schon recht.

 

Gruß, Nils

[daabm 1.348]

Ich werf meine 2 Cent denen von Nils noch dazu: Auch ich kenne kein Szenario, in dem ein RODC wirklich sinnvoll wäre. Auch wenn das (wurde ja schon geschrieben) zum eigentlichen Thema nichts beiträgt Aber vielleicht hilft's bei der Überdenkung der Strategie.