Jump to content
noone

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

Recommended Posts

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ß

Share this post


Link to post
Share on other sites

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

 

Edited by NilsK
so nicht richtig, siehe unten

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites

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.

Edited by NilsK

Share this post


Link to post
Share on other sites

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ß

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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ß

Share this post


Link to post
Share on other sites

Moin,

 

von mir aus nicht. :lol3:

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

 

Gruß, Nils

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


Werbepartner:



×
×
  • Create New...