7
Krbtgt Passwort reset Fehler
Hallo Zusammen,
ich habe gesehen es gibt zwei Möglichkeiten das krbtgt Passwort zurückzusetzen.
1. Ganz einfach über die GUI
https://learn.microsoft.com/de-de/windows-server/identity/ad-ds/manage/f ...
2. Über das MS Powershell Script
New-CtmADKrbtgtKeys-de.ps1
Das hat leider nicht funktioniert, alles war passed doch dann kamen die zwei Meldungen.
Deswegen kann Schritt 2 & 3 nicht durchgeführt werden.
Ich habe nachgeschaut:
repadmin /synall
Wurde alles erfolgreich ausgeführt, keine Fehlermeldungen.
Aber nach dcdiag gab es Beschwerden:
Ich verstehe nicht, warum der NTDS-Dienst nicht geöffnet werden konnte, der Befehl wurde mit den höchsten Privilegien in der Powershell-Konsole ausgeführt.
und keine Ahnung ob diese Fehlermeldungen was damit zutun haben, beide DC's sind auf jeden Fall erreichbar und per DNS korrekt eingetragen.
Theoretisch benötige ich das Powershell Script nicht, ich konnte es gerade auch über das GUI einfach zwei mal nacheinander zurücksetzen und die DC's neustarten, das Anmelden funktioniert und der Parameter pwdlastSet zeigt mir auch bei beiden Domain Controllern an das der timestamp identisch ist und auch aktualisiert wurde.
Da es aber, wie oben erwähnt, nicht weiter geht, möchte ich an dieser Stelle der Sache auf den Grund gehen.
Hat jemand damit schon Erfahrungen gesammelt und kann hier weiterhelfen?!
Danke.
ich habe gesehen es gibt zwei Möglichkeiten das krbtgt Passwort zurückzusetzen.
1. Ganz einfach über die GUI
https://learn.microsoft.com/de-de/windows-server/identity/ad-ds/manage/f ...
2. Über das MS Powershell Script
New-CtmADKrbtgtKeys-de.ps1
Das hat leider nicht funktioniert, alles war passed doch dann kamen die zwei Meldungen.
Deswegen kann Schritt 2 & 3 nicht durchgeführt werden.
Ich habe nachgeschaut:
repadmin /synall
Wurde alles erfolgreich ausgeführt, keine Fehlermeldungen.
Aber nach dcdiag gab es Beschwerden:
Starting test: Services
Der Dienst NTDS auf DC konnte nicht geöffnet werden. Fehler: 0x5 "Zugriff verweigert"
Starting test: NCSecDesc
Fehler: NT-AUTORITÄT\DOMÄNENCONTROLLER DER ORGANISATION besitzt keine
Replicating Directory Changes In Filtered Set
Zugriffsrechte für den Namenskontext:
DC=TEST.DOMAIN
......................... Der Test NCSecDesc für DC ist fehlgeschlagen.Ich verstehe nicht, warum der NTDS-Dienst nicht geöffnet werden konnte, der Befehl wurde mit den höchsten Privilegien in der Powershell-Konsole ausgeführt.
und keine Ahnung ob diese Fehlermeldungen was damit zutun haben, beide DC's sind auf jeden Fall erreichbar und per DNS korrekt eingetragen.
Theoretisch benötige ich das Powershell Script nicht, ich konnte es gerade auch über das GUI einfach zwei mal nacheinander zurücksetzen und die DC's neustarten, das Anmelden funktioniert und der Parameter pwdlastSet zeigt mir auch bei beiden Domain Controllern an das der timestamp identisch ist und auch aktualisiert wurde.
Da es aber, wie oben erwähnt, nicht weiter geht, möchte ich an dieser Stelle der Sache auf den Grund gehen.
Hat jemand damit schon Erfahrungen gesammelt und kann hier weiterhelfen?!
Danke.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 24185681328
Url: https://administrator.de/contentid/24185681328
Printed on: May 6, 2024 at 03:05 o'clock
7 Comments
Latest comment
mal ins blaue geraten.. evtl. Berechtigung Gruppe Schemaadmin o.ä.
Hi.
Ich habe auch soeben (rein zufällig) das krbtgt Passwort neu gesetzt.
Ich weiß nicht genau, welches PS Script Du nutzt:
github.com/zjorz/Public-AD-Scripts/blob/master/Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1
Das funktioniert und hat einige Prüfungen sowie Simulationen eingebaut. Würde ich Dir ans Herz legen.
Beim zweimaligen Zurücksetzen des Schlüsselverteilungscenter-Dienstkontokennworts ist eine Wartezeit von 10 Stunden zwischen den Zurücksetzungen erforderlich. 10 Stunden sind die Standardrichtlinieneinstellungen für die Maximale Lebensdauer für Benutzertickets und die Maximale Lebensdauer für Diensttickets. In einem Fall, in dem die maximale Lebensdauer geändert wurde, sollte daher die minimale Wartezeit zwischen Zurücksetzungen größer als der konfigurierte Wert sein.
Gruß
Ich habe auch soeben (rein zufällig) das krbtgt Passwort neu gesetzt.
Ich weiß nicht genau, welches PS Script Du nutzt:
github.com/zjorz/Public-AD-Scripts/blob/master/Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1
Das funktioniert und hat einige Prüfungen sowie Simulationen eingebaut. Würde ich Dir ans Herz legen.
einfach zwei mal nacheinander zurücksetzen
Nicht gut - immer erst die Replizierung abwarten und/oder gegenprüfen ob auf allen DCs das PW gesetzt ist.Beim zweimaligen Zurücksetzen des Schlüsselverteilungscenter-Dienstkontokennworts ist eine Wartezeit von 10 Stunden zwischen den Zurücksetzungen erforderlich. 10 Stunden sind die Standardrichtlinieneinstellungen für die Maximale Lebensdauer für Benutzertickets und die Maximale Lebensdauer für Diensttickets. In einem Fall, in dem die maximale Lebensdauer geändert wurde, sollte daher die minimale Wartezeit zwischen Zurücksetzungen größer als der konfigurierte Wert sein.
Gruß
evtl. Berechtigung Gruppe Schemaadmin o.ä.
Gar nicht nötig für diesen Vorgang. Der adminuser muss nicht als SchemaAdmin (in der Gruppe sein)hinterlegt sein. Man ändert ja nichts am Schema, schlicht ein PW wird neugesetzt.Der Dienst NTDS auf DC konnte nicht geöffnet werden. Fehler: 0x5 "Zugriff verweigert"
Powershell/CMD privilegiert ausgeführt?
@accessViolation
Ich habe gerade das andere Skript ausprobiert und zumindest in der Test Hyper-V Umgebung scheint es zu funktionieren. Vorher habe ich nur diese Fehlermeldung bekommen:
Das Passwort aber selber wurde erfolgreich durchgeführt
Das heißt jetzt 10 Stunden warten, danach nochmal durchführen und dann sollte das gewesen sein?
Sollte man den zweiten DC danach auch neustarten, oder ist das nicht nötig?
Und wie oft wird in diesem Fall ein Reset empfohlen bzw. wie oft macht ihr das, alle 6 Monate?
Ich habe gerade das andere Skript ausprobiert und zumindest in der Test Hyper-V Umgebung scheint es zu funktionieren. Vorher habe ich nur diese Fehlermeldung bekommen:
GATHERING TARGETED AD DOMAIN INFORMATION...
Could not lookup 'MaxTicketAge' (default 10 hours) and 'MaxClockSkew' (default 5 minutes) from the resultant GPO, Das Passwort aber selber wurde erfolgreich durchgeführt
The new password for [CN=krbtgt,CN=Users,DC=die.Domain] HAS BEEN SET ...Das heißt jetzt 10 Stunden warten, danach nochmal durchführen und dann sollte das gewesen sein?
Sollte man den zweiten DC danach auch neustarten, oder ist das nicht nötig?
Und wie oft wird in diesem Fall ein Reset empfohlen bzw. wie oft macht ihr das, alle 6 Monate?
Moin,
Neustarten brauchst du nicht.
Empfehlung ist zwischen 1-6 Monate. Irgendetwas dazwischen passt.
Ich mache es alle 3 Monate (jedes Quartal)
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ ...
Das genannte Script vom Kollegen @accessViolation nutze ich auch.
V1 hat damals Jared Poeppelman (Microsoft Mitarbeiter) veröffentlicht.
Jorge de Almeida Pinto [MVP Enterprise Mobility And Security, EMS] hat es dann in die V2 gebracht und viele Features hinzugefügt. Mittlerweise sind die schon bei V3.
Der Try-Catch startet bei Zeile 6355
Dein genannter Fehler tritt im Script in Zeile 6612 auf --> das ist der Catch, wenn der Try einen Fehler wirft.
Der Try gibt einen Fehler, weil er die MaxTicketAge und MaxClockSkew nicht auslesen konnte. Grund dafür solltest du im Log finden.
Kannst ja sonst mal bei den lokalen Gruppenrichtlinien eines DCs schauen, was der MaxTicketAge für einen Wert hat bspw.:
https://learn.microsoft.com/en-us/windows/security/threat-protection/sec ...
Wenn der wirklich auf 10 Stunden steht dann am besten nach 11 Stunden das Passwort erneut ändern 👍
Bisschen Puffer schadet nie ^^
Bzgl Berechtigung:
Wenn es nur ein Forest ist dann reicht der Domain-Admin.
Ist der Scope größer brauchst du den Enterprise-Admin.
Korrigiert mich hier aber gerne
VG
Neustarten brauchst du nicht.
Empfehlung ist zwischen 1-6 Monate. Irgendetwas dazwischen passt.
Ich mache es alle 3 Monate (jedes Quartal)
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ ...
Das genannte Script vom Kollegen @accessViolation nutze ich auch.
V1 hat damals Jared Poeppelman (Microsoft Mitarbeiter) veröffentlicht.
Jorge de Almeida Pinto [MVP Enterprise Mobility And Security, EMS] hat es dann in die V2 gebracht und viele Features hinzugefügt. Mittlerweise sind die schon bei V3.
Der Try-Catch startet bei Zeile 6355
Dein genannter Fehler tritt im Script in Zeile 6612 auf --> das ist der Catch, wenn der Try einen Fehler wirft.
Der Try gibt einen Fehler, weil er die MaxTicketAge und MaxClockSkew nicht auslesen konnte. Grund dafür solltest du im Log finden.
Kannst ja sonst mal bei den lokalen Gruppenrichtlinien eines DCs schauen, was der MaxTicketAge für einen Wert hat bspw.:
https://learn.microsoft.com/en-us/windows/security/threat-protection/sec ...
Wenn der wirklich auf 10 Stunden steht dann am besten nach 11 Stunden das Passwort erneut ändern 👍
Bisschen Puffer schadet nie ^^
Bzgl Berechtigung:
Wenn es nur ein Forest ist dann reicht der Domain-Admin.
Ist der Scope größer brauchst du den Enterprise-Admin.
Korrigiert mich hier aber gerne
VG
1
Moin
@Celiko
Das mit dem Gültigkeitsdauer des Benutzertickets habe ich noch nicht ganz verstanden.
ist das Beispiel was Du geschrieben hast mit den "11" Stunden nur für den krbtgt reset Interessant wenn man das durch hat kann man das nach paar Tagen wieder auf 10 oder drunter stellen?
Bei mir sind diese gar nicht definiert, also liegt dann der default Wert bei 10.
Gibt es hier eine Empfehlung, welche Dauer eingestellt werden sollte?
MS Schreibt Lebensdauert zwischen 4-10 Stunden...
Verletzlichkeit
Wenn Sie den Wert für die Einstellung „Maximale Lebensdauer für Benutzertickets“ zu hoch konfigurieren, können Benutzer möglicherweise außerhalb ihrer Anmeldezeiten auf Netzwerkressourcen zugreifen. Außerdem haben Benutzer, deren Konten deaktiviert wurden, möglicherweise weiterhin Zugriff auf Netzwerkdienste mit gültigen Benutzertickets, die vor der Deaktivierung ihrer Konten ausgestellt wurden. Wenn Sie diesen Wert zu niedrig konfigurieren, können Ticketanfragen an das KDC die Leistung Ihres KDC beeinträchtigen und eine Möglichkeit für einen DoS-Angriff darstellen.
Gegenmaßnahme
Konfigurieren Sie die Einstellung „Maximale Lebensdauer für Benutzertickets“ mit einem Wert zwischen 4 und 10 Stunden.
@Celiko
Das mit dem Gültigkeitsdauer des Benutzertickets habe ich noch nicht ganz verstanden.
ist das Beispiel was Du geschrieben hast mit den "11" Stunden nur für den krbtgt reset Interessant wenn man das durch hat kann man das nach paar Tagen wieder auf 10 oder drunter stellen?
Bei mir sind diese gar nicht definiert, also liegt dann der default Wert bei 10.
Gibt es hier eine Empfehlung, welche Dauer eingestellt werden sollte?
MS Schreibt Lebensdauert zwischen 4-10 Stunden...
Verletzlichkeit
Wenn Sie den Wert für die Einstellung „Maximale Lebensdauer für Benutzertickets“ zu hoch konfigurieren, können Benutzer möglicherweise außerhalb ihrer Anmeldezeiten auf Netzwerkressourcen zugreifen. Außerdem haben Benutzer, deren Konten deaktiviert wurden, möglicherweise weiterhin Zugriff auf Netzwerkdienste mit gültigen Benutzertickets, die vor der Deaktivierung ihrer Konten ausgestellt wurden. Wenn Sie diesen Wert zu niedrig konfigurieren, können Ticketanfragen an das KDC die Leistung Ihres KDC beeinträchtigen und eine Möglichkeit für einen DoS-Angriff darstellen.
Gegenmaßnahme
Konfigurieren Sie die Einstellung „Maximale Lebensdauer für Benutzertickets“ mit einem Wert zwischen 4 und 10 Stunden.
Moin,
Da musst du dich tiefer mit Kerberos beschäftigen.
Ein User der sich anmeldet erhält ein TGT Ticket.
Ticket granting ticket *, Das mit dem krbtgt User verschlüsselt wird.
Das ist quasi ein Ausweis vom DC, dass du wirklich du bist. Mit diesem Ausweis kannst du dich bei anderen Services authentifizieren. Für jeden Service erhältst du ein weiteres Ticket.
Gib mal in der Konsole klist ein, evtl verstehst du es dann besser.
Der Ausweis hat im default eine Gültigkeit von 10 Stunden. Das TGT muss also vom User alle 10 Stunden neu beantragt werden.
Evtl ist jetzt auch klar warum das Passwort vom krbtgt niemals im fremde Hände kommen darf bzw es aus Sicherheitsgründen gelegentlich erneuert werden sollte.
Lass es im default.
Vg
Da musst du dich tiefer mit Kerberos beschäftigen.
Ein User der sich anmeldet erhält ein TGT Ticket.
Ticket granting ticket *, Das mit dem krbtgt User verschlüsselt wird.
Das ist quasi ein Ausweis vom DC, dass du wirklich du bist. Mit diesem Ausweis kannst du dich bei anderen Services authentifizieren. Für jeden Service erhältst du ein weiteres Ticket.
Gib mal in der Konsole klist ein, evtl verstehst du es dann besser.
Der Ausweis hat im default eine Gültigkeit von 10 Stunden. Das TGT muss also vom User alle 10 Stunden neu beantragt werden.
Evtl ist jetzt auch klar warum das Passwort vom krbtgt niemals im fremde Hände kommen darf bzw es aus Sicherheitsgründen gelegentlich erneuert werden sollte.
Lass es im default.
Vg
3Zitat von @accessViolation:
Beim zweimaligen Zurücksetzen des Schlüsselverteilungscenter-Dienstkontokennworts ist eine Wartezeit von 10 Stunden zwischen den Zurücksetzungen erforderlich. 10 Stunden sind die Standardrichtlinieneinstellungen für die Maximale Lebensdauer für Benutzertickets und die Maximale Lebensdauer für Diensttickets. In einem Fall, in dem die maximale Lebensdauer geändert wurde, sollte daher die minimale Wartezeit zwischen Zurücksetzungen größer als der konfigurierte Wert sein.
Beim zweimaligen Zurücksetzen des Schlüsselverteilungscenter-Dienstkontokennworts ist eine Wartezeit von 10 Stunden zwischen den Zurücksetzungen erforderlich. 10 Stunden sind die Standardrichtlinieneinstellungen für die Maximale Lebensdauer für Benutzertickets und die Maximale Lebensdauer für Diensttickets. In einem Fall, in dem die maximale Lebensdauer geändert wurde, sollte daher die minimale Wartezeit zwischen Zurücksetzungen größer als der konfigurierte Wert sein.
Bezüglich deiner Frage:
Fasse die GPO garnicht erst an. Ändere nicht die Gültigkeitsdauer.
Mit den 11 Stunden ist das gemeint, was bereits accessviolation geschrieben hat.
...sollte daher die minimale Wartezeit zwischen Zurücksetzungen größer als der konfigurierte Wert sein
11 ist großer als 10. Deshalb lieber 11 Stunden warten und anschließend das zweite Mal das Passwort ändern.
VG
1