Jump to content

KRBTGT - Anleitung für Kennwort ändern gesucht (RODC)


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Wir hatten das schon mit dem Script ausprobiert, das bricht aber im Testmodus ab weil es angeblich kein Domänenfunktionslevel größer als 2008 findet, wir sind aber auf 2016.

Bevor wir da jetzt tagelang in die Fehleranalyse gehen machen wir das lieber manuel.

 

Wie verhält sich das jetzt mit den Rodc`s , muss da kein Kennwort geändert werden und die bekommen das von den normalen Dc`s ?

 

Gruß,

 

 

Link zu diesem Kommentar

Moin,

 

also, richtig ist:

  • in einem AD ohne RODCs macht man das einmalig für die Domäne, nicht pro DC.
  • in einem AD mit RODCs gibt es den "echten" krbtgt und je einen pro RODC. Falls das so ist, muss man die Kennwörter von allen diesen Accounts ändern. Man tut dies auf einem normalen DC.
  • zum Ändern setzt man ein neues Kennwort, das zunächst den Kennwortrichtlinien genügen muss, wie bei jedem anderen Account auch. ABER: Das Kennwort bleibt nicht, sondern das AD setzt dann automatisch einen neuen, geheimen Wert.
  • einmal ändern reicht nicht. Man muss die Replikation abwarten und dann das Kennwort ein zweites Mal ändern. Das liegt daran, dass das AD sowohl das aktuelle als auch das vorhergehende Kennwort akzeptiert. Das ist nur bei diesem Account so.

Das TechNet-Skript macht all dies von selbst und prüft vorher genau, was es tun muss. Dass das Skript manchmal abbricht, liegt i.d.R. daran, dass Jorge die Lokalisierung nicht richtig hinbekommen hat.

Man braucht das Skript aber nicht, sondern kann das wie beschrieben einfach manuell machen. Wichtig ist nur, dass man zwischendurch die Replikation abwartet, was bei einer weltweit verteilten Umgebung schon mal Stunden dauern kann.

 

Gruß, Nils

PS. sorry für die Verwirrung durch meine vorherige, nicht ganz korrekte Antwort.

bearbeitet von NilsK
Link zu diesem Kommentar

Moin,

 

technisch ist das egal. Nur in einer großen, geografisch verteilten Struktur mit großen Replikationslatenzen würde man dafür den PDC-Emulator vorziehen, weil man dann (in manchen Topologien) evtl. Replikations-Hops spart und so die Wartezeit zwischen den beiden Kennwortwechseln verzögert. Das dürfte allerdings heutzutage in fast allen Umgebungen keine ernsthafte Rolle spielen.

 

In einer Multi-Site-Umgebung könnte man sich die konfigurierten Latenzen ansehen und ein wenig Puffer draufrechnen. Oder einfach zwischen den beiden Wechseln zu Mittag gehen.

 

Gruß, Nils

 

Link zu diesem Kommentar

Moin,

 

habt ihr denn mehrere Sites, sodass ihr überhaupt warten müsstet? Wenn ja, wie lang sind dort die konfigurierten Intervalle?

 

Ein zu langer Abstand zwischen den Kennwortwechseln ist im Zweifel kontraproduktiv. Falls man so einen Wechsel durchführt, um mögliche Golden-Ticket-Angriffe zu beenden, möchte man den effektiven Kennwortwechsel (also beide Einzelschritte) so schnell wie möglich durch haben. Sonst könnte es passieren, dass der Angreifer das bemerkt (was er durch Abfrage des AD sehr einfach könnte) und nach dem ersten Kennwortwechsel sich ein neues Golden Ticket erzeugt. Das könnte er, weil er den Hash des Vorgängerkennworts noch hätte. Den zweiten Kennwortwechsel würde dieses Golden Ticket dann überstehen, weil es zu den Eigenheiten der ganzen Mechanik gehört, dass sowohl das aktuelle Kennwort als auch dessen direkter Vorgänger akzeptiert werden.

 

Man muss also aufpassen, dass man sich nicht durch scheinbare Vorsichtsmaßnahmen ein Fußpilzproblem erzeugt. Genau deshalb macht das Skript von Jorge recht viel Aufwand und versucht die tatsächliche Replikationslatenz zu messen.

 

Gruß, Nils

 

Link zu diesem Kommentar

Moin,

 

ich verstehe nicht, warum ihr zehn Stunden Puffer einbauen wollt. Kann man machen, wenn es einen Grund gibt, aber ich wüsste keinen.

 

Hier ist ein simples Toolset, um die Replikationslatenz zu testen:

[ADRepCheckLatency: AD-Replikationslatenz messen | faq-o-matic.net]
https://www.faq-o-matic.net/2009/09/30/adrepchecklatency-ad-replikationslatenz-messen/

 

Und hier ein anderes:

[(2010-10-24) Testing Active Directory Replication Latency/Convergence Through PowerShell « Jorge's Quest For Knowledge!]
https://jorgequestforknowledge.wordpress.com/2010/10/24/testing-active-directory-replication-latency-convergence-through-powershell/


Gruß, Nils

 

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...