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

[noone 10]

Moin zusammen,

 

wir wollen das Kennwort unseres KRBTGT manuell ändern. 

 

Vier normale Dc`s und Drei Rodc`s. 

 

Auf den normalen Dc`s kann ich das Kennwort ganz normal resetten, aber wie funktioniert das auf einem Rodc?

 

Danke für Eure Gedanke!

 

Gruß

[NorbertFe 2.027]

Manuell im Sinne von "nicht per Skript"? Denn das wär ja sonst zu einfach: https://gallery.technet.microsoft.com/Reset-The-KrbTgt-Account-5f45a414

[NilsK 2.930]

Moin,

 

das macht man einmalig für die Domäne, nicht pro DC. Und auf den RODCs sowieso nicht, die sind Read-only und können keine Daten ändern.

 

Im übrigen hilft eine Websuche nach "krbtgt change password" durchaus weiter.

 

Gruß, Nils

 

bearbeitet 6. Februar 2020 von NilsK
so nicht richtig, siehe unten

[noone 10]

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ß,

 

 

[NilsK 2.930]

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 6. Februar 2020 von NilsK

[noone 10]

Moin,

 

Danke für die Erklärung. Auf welchem DCc sollte ich das Kennwort der krbtgt-Accounts ändern, auf dem PDC oder ist das egal?

 

Gruß

[NilsK 2.930]

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

 

[noone 10]

Moin, Danke.

 

Wir hatten geplant das Kennwort z.B. Dienstag Abend das Erste Mal zu ändern und dann Mittwoch Abend das zweite Mal. Spricht was dagegen?

 

Gruß

[NilsK 2.930]

Moin,

 

von mir aus nicht. 

Aber ich glaube eigentlich nicht, dass eure Umgebung so hohe Replikationslatenz hat.

 

Gruß, Nils

[noone 10]

Moin,

 

wir wollten nach dem ersten Wechsel abwarten bis das TGT abgelaufen ist + zwei Stunden Puffer für die Replikation.

 Mal sehen, vielleicht verkürzen wir das auf 12 Stunden.

 

Danke Nils!

 

VG

 

 

[NilsK 2.930]

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

 

[noone 10]

Moin,

 

wir haben drei Standorte in DE und einen in UK. Replikation steht momentan auf 60 Minuten. 60 Minuten + 600 Minuten für TGT sind wären dann elf Stunden. Wir werden das dann wohl einmal morgens und einmal abends ändern.

 

VG

[NilsK 2.930]

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

 

[daabm 1.348]

..man könnte auch auf die Idee kommen, die Replikation instant anzustoßen und gar nicht zu warten. ym2c...