22
Alte DC-Tickets Verschlüsselungen abschalten
Schönen Sonntag allen Zusammen,
ich würde gerne überprüfen ob noch das unsichere Verbindungsprotokoll RC4_HMAC_MD5 in der Domäne zum Einsatz kommt.
Über die EventID: 4769 kann man das über die Ticketverschlüsselungstyp selber herausfinden, soweit so gut.
Nun habe ich über die Gruppenrichtlinien die Art der Verschlüsselung abgeändert auf AES und seitdem kann ich mich am DC nicht mehr Anmelden... nehme ich diese Einstellung raus bzw. deaktiviere diese Gruppenrichtlinie dann geht es wieder.
Was kann hier das Problem sein?
Danke
ich würde gerne überprüfen ob noch das unsichere Verbindungsprotokoll RC4_HMAC_MD5 in der Domäne zum Einsatz kommt.
Über die EventID: 4769 kann man das über die Ticketverschlüsselungstyp selber herausfinden, soweit so gut.
Nun habe ich über die Gruppenrichtlinien die Art der Verschlüsselung abgeändert auf AES und seitdem kann ich mich am DC nicht mehr Anmelden... nehme ich diese Einstellung raus bzw. deaktiviere diese Gruppenrichtlinie dann geht es wieder.
Was kann hier das Problem sein?
Danke
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5008347291
Url: https://administrator.de/forum/alte-dc-tickets-verschluesselungen-abschalten-5008347291.html
Ausgedruckt am: 22.12.2024 um 12:12 Uhr
22 Kommentare
Neuester Kommentar
und seitdem kann ich mich am DC nicht mehr Anmelden.
Haken hier bei den gew.Methoden aktivieren
Gruß s.
3
Lass mich raten, du hast die Dezemberupdates an denDCs noch nicht installiert, oder? Daran liegt es, die Novemberupdates brachten genau diesen Bug mit sich.
2
Was heißt nicht mehr am DC anmelden und was landet dabei im Log?
Zitat von @DerWoWusste:
Lass mich raten, du hast die Dezemberupdates an denDCs noch nicht installiert, oder? Daran liegt es, die Novemberupdates brachten genau diesen Bug mit sich.
Lass mich raten, du hast die Dezemberupdates an denDCs noch nicht installiert, oder? Daran liegt es, die Novemberupdates brachten genau diesen Bug mit sich.
Doch ist installiert!
Schlepper hatte die Lösung.
Und worin besteht nun die Lösung? Was du über deine GPO forderst, wird davon nicht berührt/uberstimmt. Die GPO wirkt auf den Computer, die von Schlepper abgebildeten Haken auf den Nutzer, aber was die GPO setzt, hat Vorrang.
2
Seitdem ich die Haken gesetzt habe funktioniert es, das ist die Hauptsache.
Zitat von @DerWoWusste:
Und worin besteht nun die Lösung? Was du über deine GPO forderst, wird davon nicht berührt/uberstimmt. Die GPO wirkt auf den Computer, die von Schlepper abgebildeten Haken auf den Nutzer, aber was die GPO setzt, hat Vorrang.
Und worin besteht nun die Lösung? Was du über deine GPO forderst, wird davon nicht berührt/uberstimmt. Die GPO wirkt auf den Computer, die von Schlepper abgebildeten Haken auf den Nutzer, aber was die GPO setzt, hat Vorrang.
Hi
wie meldest du dich am DC an ?
Via RDP ? Wenn ja mal FQDN probieren.
Weiter dem Konto krbtgt die AES128 und AES256 Haken setzten- siehe Screenshot oben.
Dann im Abstand von mehr als 10 Stunden dem Konto zweimal ein neues Passwort verpassen.
Das Passwort Ist egal, das wird bei dem Konto random erzeugt.
Ohne den Passwortreset ist ein AES 128 bzw 256 sprechen so nicht möglich im Kerberos.
Dann über die Ereignisanzeige schauen was, noch alles RC4 spricht. Das eliminieren.
Dann in der Policy auf AES128 / 256 und Future hochsetzen.
Mit freundlichen Grüßen Nemesis
wie meldest du dich am DC an ?
Via RDP ? Wenn ja mal FQDN probieren.
Weiter dem Konto krbtgt die AES128 und AES256 Haken setzten- siehe Screenshot oben.
Dann im Abstand von mehr als 10 Stunden dem Konto zweimal ein neues Passwort verpassen.
Das Passwort Ist egal, das wird bei dem Konto random erzeugt.
Ohne den Passwortreset ist ein AES 128 bzw 256 sprechen so nicht möglich im Kerberos.
Dann über die Ereignisanzeige schauen was, noch alles RC4 spricht. Das eliminieren.
Dann in der Policy auf AES128 / 256 und Future hochsetzen.
Mit freundlichen Grüßen Nemesis
1Zitat von @DerWoWusste:
Die GPO wirkt auf den Computer, die von Schlepper abgebildeten Haken auf den Nutzer, aber was die GPO setzt, hat Vorrang.
Die GPO sagt das nur diese Verfahren für Kerberos erlaubt sind. Wenn aber der Account nicht für das Verfahren aktiviert ist wirst du dich trotzdem damit nicht authentifieren können ... Das sind eben zwei unterschiedliche paar Schuhe.Die GPO wirkt auf den Computer, die von Schlepper abgebildeten Haken auf den Nutzer, aber was die GPO setzt, hat Vorrang.
1
@4863114660
Das ist richtig. Nur erreicht er sein eigentliches Ziel so nicht. Er zieht sich an den Haaren aus dem Sumpf, aber es bleibt unsicher konfiguriert.
Das ist richtig. Nur erreicht er sein eigentliches Ziel so nicht. Er zieht sich an den Haaren aus dem Sumpf, aber es bleibt unsicher konfiguriert.
Hallo,
Grüße
lcer
Zitat von @watIsLos:
Nun habe ich über die Gruppenrichtlinien die Art der Verschlüsselung abgeändert auf AES und seitdem kann ich mich am DC nicht mehr Anmelden... nehme ich diese Einstellung raus bzw. deaktiviere diese Gruppenrichtlinie dann geht es wieder.
Kurze Frage - wie korrigiert man eine GPO, wenn man sich nicht am DC anmelden kann?Nun habe ich über die Gruppenrichtlinien die Art der Verschlüsselung abgeändert auf AES und seitdem kann ich mich am DC nicht mehr Anmelden... nehme ich diese Einstellung raus bzw. deaktiviere diese Gruppenrichtlinie dann geht es wieder.
Grüße
lcer
Wieso nicht? Genau das, dass der User sich dann auch per Kerberos mit AES anmelden kann wenn alle unsicheren Verfahren deaktiviert sind, mehr war laut seinem Post nicht gefordert.
Er zieht sich an den Haaren aus dem Sumpf, aber es bleibt unsicher konfiguriert.
Was ist unsicher an einer restriktiveren Verschlüsselungs-Policy wenn man die Nutzung der alten Verfahren im Vorfeld ausschließen kann ??
In dem man es vorher z.B. über eine VM mit DC Kopie testet.
Also in dem Fall habe ich zwei DC's im Hyper-V und teste vorher das ganze!
Das heißt auf dem einen habe ich mich damit ausgesperrt, konnte es aber dann über den anderen DC noch korrigieren.
Also in dem Fall habe ich zwei DC's im Hyper-V und teste vorher das ganze!
Das heißt auf dem einen habe ich mich damit ausgesperrt, konnte es aber dann über den anderen DC noch korrigieren.
Zitat von @lcer00:
Hallo,
Grüße
lcer
Hallo,
Zitat von @watIsLos:
Nun habe ich über die Gruppenrichtlinien die Art der Verschlüsselung abgeändert auf AES und seitdem kann ich mich am DC nicht mehr Anmelden... nehme ich diese Einstellung raus bzw. deaktiviere diese Gruppenrichtlinie dann geht es wieder.
Kurze Frage - wie korrigiert man eine GPO, wenn man sich nicht am DC anmelden kann?Nun habe ich über die Gruppenrichtlinien die Art der Verschlüsselung abgeändert auf AES und seitdem kann ich mich am DC nicht mehr Anmelden... nehme ich diese Einstellung raus bzw. deaktiviere diese Gruppenrichtlinie dann geht es wieder.
Grüße
lcer
Hi @4863114660.
Er hat die Haken doch gesetzt. Er schreibt
Er hat die Haken doch gesetzt. Er schreibt
Seitdem ich die Haken gesetzt habe funktioniert es, das ist die Hauptsache.
Sprich: auch der oberste, der DES/RC4 ermöglicht, ist gesetzt.Zitat von @DerWoWusste:
Hi @4863114660.
Er hat die Haken doch gesetzt. Er schreibt
Hi @4863114660.
Er hat die Haken doch gesetzt. Er schreibt
Seitdem ich die Haken gesetzt habe funktioniert es, das ist die Hauptsache.
Nein er hat den Haken im User-Account für AES gesetzt 🙂
Das ist deine Vermutung. Wenn Du 3 Haken in deiner Zeichnung umrandest, denke ich, er wird auch diese 3 gesetzt haben. Aber das muss @watIsLos aufklären.
Naja er wollte ja AES aktivieren und RC4 loswerden, da liegt das nahe das er den Haken für AES im User-Account gesetzt hat und nicht bei RC4 in der GPO.
Das "USE Kerberos DES encryption..." habe ich nicht gesetzt, nur die zwei AES Einträge im Benutzer.
Zitat von @DerWoWusste:
Hi @4863114660.
Er hat die Haken doch gesetzt. Er schreibt
Hi @4863114660.
Er hat die Haken doch gesetzt. Er schreibt
Seitdem ich die Haken gesetzt habe funktioniert es, das ist die Hauptsache.
Sprich: auch der oberste, der DES/RC4 ermöglicht, ist gesetzt.
Dann ist ja gut.
Tja, warum macht es dann einen Unterschied, ob dort gesetzt oder per GPO gesetzt. Hier macht es keinen Unterschied.
Tja, warum macht es dann einen Unterschied, ob dort gesetzt oder per GPO gesetzt. Hier macht es keinen Unterschied.
Das kann ich dir leider nicht sagen.
Ich habe mich schon vor vielen Jahren aufgehört zu Fragen wieso das bei Windows so ist... ich werde immer wieder vom neuen Überrascht...
Gruß
psyduck
Ich habe mich schon vor vielen Jahren aufgehört zu Fragen wieso das bei Windows so ist... ich werde immer wieder vom neuen Überrascht...
Gruß
psyduck
Zitat von @DerWoWusste:
Dann ist ja gut.
Tja, warum macht es dann einen Unterschied, ob dort gesetzt oder per GPO gesetzt. Hier macht es keinen Unterschied.
Dann ist ja gut.
Tja, warum macht es dann einen Unterschied, ob dort gesetzt oder per GPO gesetzt. Hier macht es keinen Unterschied.
Hallo,
vielleicht hilft folgendes beim Verstehen der Häkchen:
Die Häkchen modifizieren das Attribut "msDS-SupportedEncryptionTypes" des Benutzers. Diese sind hier dokumentiert: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/6c ... und https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b3 ...
Die GPO ändert das Benutzer-Attribut nicht sondern legt für den Computer fest, was erlaubt ist: https://learn.microsoft.com/de-de/windows/security/threat-protection/sec ...
Somit kann es zu Inkompatibiltäten zwischen Benutzer und Computer kommen.
Besser man schränkt die Gültigkeit der GPO zunächst auf einzelne Rechner (z.B. DC1) und Benutzer (z.B. TestAdmin) ein und sorgt dafür, dass man an einem Rechner mit einem Benutzer (AndererAdmin) angemeldet ist, auf den die GPO nicht greift.
Grundsätzlich sollte man sich auch angewöhnen, die GPO zunächst zuerst zu erstellen und bevor man irgendetwas in diese GPO hineinschreibt, diese Deaktivieren. Dann alles fertigbasteln und im erst, nachdem man die Einstellungen überprüft hat - aktivieren.
Grüße
lcer
vielleicht hilft folgendes beim Verstehen der Häkchen:
Die Häkchen modifizieren das Attribut "msDS-SupportedEncryptionTypes" des Benutzers. Diese sind hier dokumentiert: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/6c ... und https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b3 ...
Die GPO ändert das Benutzer-Attribut nicht sondern legt für den Computer fest, was erlaubt ist: https://learn.microsoft.com/de-de/windows/security/threat-protection/sec ...
Somit kann es zu Inkompatibiltäten zwischen Benutzer und Computer kommen.
In dem man es vorher z.B. über eine VM mit DC Kopie testet.
Also in dem Fall habe ich zwei DC's im Hyper-V und teste vorher das ganze!
Das heißt auf dem einen habe ich mich damit ausgesperrt, konnte es aber dann über den anderen DC noch korrigieren.
Nein, so macht man das nicht. Also in dem Fall habe ich zwei DC's im Hyper-V und teste vorher das ganze!
Das heißt auf dem einen habe ich mich damit ausgesperrt, konnte es aber dann über den anderen DC noch korrigieren.
Besser man schränkt die Gültigkeit der GPO zunächst auf einzelne Rechner (z.B. DC1) und Benutzer (z.B. TestAdmin) ein und sorgt dafür, dass man an einem Rechner mit einem Benutzer (AndererAdmin) angemeldet ist, auf den die GPO nicht greift.Grundsätzlich sollte man sich auch angewöhnen, die GPO zunächst zuerst zu erstellen und bevor man irgendetwas in diese GPO hineinschreibt, diese Deaktivieren. Dann alles fertigbasteln und im erst, nachdem man die Einstellungen überprüft hat - aktivieren.
Grüße
lcer
Hi Icer,
ich teste das Ganze lieber mit Kopien, bevor ich das Ganze produktiv aktiviere, trotzdem ist deine Vorgehensweise richtig.
Was ist denn jetzt der richtige Weg um die veraltete Ticketverschlüsselung durch AES zu ersetzten?!
Im Grunde muss doch sowohl über GPO als auch über Benutzer AES aktiviert werden, danach sollte doch die Kompatibilität gewährleistet sein?!
ich teste das Ganze lieber mit Kopien, bevor ich das Ganze produktiv aktiviere, trotzdem ist deine Vorgehensweise richtig.
Was ist denn jetzt der richtige Weg um die veraltete Ticketverschlüsselung durch AES zu ersetzten?!
Im Grunde muss doch sowohl über GPO als auch über Benutzer AES aktiviert werden, danach sollte doch die Kompatibilität gewährleistet sein?!
Zitat von @lcer00:
Hallo,
vielleicht hilft folgendes beim Verstehen der Häkchen:
Die Häkchen modifizieren das Attribut "msDS-SupportedEncryptionTypes" des Benutzers. Diese sind hier dokumentiert: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/6c ... und https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b3 ...
Die GPO ändert das Benutzer-Attribut nicht sondern legt für den Computer fest, was erlaubt ist: https://learn.microsoft.com/de-de/windows/security/threat-protection/sec ...
Somit kann es zu Inkompatibiltäten zwischen Benutzer und Computer kommen.
Besser man schränkt die Gültigkeit der GPO zunächst auf einzelne Rechner (z.B. DC1) und Benutzer (z.B. TestAdmin) ein und sorgt dafür, dass man an einem Rechner mit einem Benutzer (AndererAdmin) angemeldet ist, auf den die GPO nicht greift.
Grundsätzlich sollte man sich auch angewöhnen, die GPO zunächst zuerst zu erstellen und bevor man irgendetwas in diese GPO hineinschreibt, diese Deaktivieren. Dann alles fertigbasteln und im erst, nachdem man die Einstellungen überprüft hat - aktivieren.
Grüße
lcer
Hallo,
vielleicht hilft folgendes beim Verstehen der Häkchen:
Die Häkchen modifizieren das Attribut "msDS-SupportedEncryptionTypes" des Benutzers. Diese sind hier dokumentiert: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/6c ... und https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b3 ...
Die GPO ändert das Benutzer-Attribut nicht sondern legt für den Computer fest, was erlaubt ist: https://learn.microsoft.com/de-de/windows/security/threat-protection/sec ...
Somit kann es zu Inkompatibiltäten zwischen Benutzer und Computer kommen.
In dem man es vorher z.B. über eine VM mit DC Kopie testet.
Also in dem Fall habe ich zwei DC's im Hyper-V und teste vorher das ganze!
Das heißt auf dem einen habe ich mich damit ausgesperrt, konnte es aber dann über den anderen DC noch korrigieren.
Nein, so macht man das nicht. Also in dem Fall habe ich zwei DC's im Hyper-V und teste vorher das ganze!
Das heißt auf dem einen habe ich mich damit ausgesperrt, konnte es aber dann über den anderen DC noch korrigieren.
Besser man schränkt die Gültigkeit der GPO zunächst auf einzelne Rechner (z.B. DC1) und Benutzer (z.B. TestAdmin) ein und sorgt dafür, dass man an einem Rechner mit einem Benutzer (AndererAdmin) angemeldet ist, auf den die GPO nicht greift.Grundsätzlich sollte man sich auch angewöhnen, die GPO zunächst zuerst zu erstellen und bevor man irgendetwas in diese GPO hineinschreibt, diese Deaktivieren. Dann alles fertigbasteln und im erst, nachdem man die Einstellungen überprüft hat - aktivieren.
Grüße
lcer
Zitat von @watIsLos:
Im Grunde muss doch sowohl über GPO als auch über Benutzer AES aktiviert werden, danach sollte doch die Kompatibilität gewährleistet sein?!
Ja. Kompatibel aber eben nur noch mit AES128/AES256 Kerberos Tickets wenn du beide Häkchen im User-Account setzt.Im Grunde muss doch sowohl über GPO als auch über Benutzer AES aktiviert werden, danach sollte doch die Kompatibilität gewährleistet sein?!
Wenn die Häkchen im User Account nicht gesetzt sind gilt RC4_HMAC_MD5 als Default
Sobald beide Häkchen gesetzt sind gilt für diesen User nur noch AES 128 und AES 256 für Kerberos Tickets (Wert 0x18 = 24 im Attribut)
Die verschiedenen Kombinationen die du im Attribut setzen kannst findest du hier
Decrypting the Selection of Supported Kerberos Encryption Types
Beachte dort auch den wichtigen Hinweis für den KRBTGT Account
If you enable AES on the KRBTGT account and find your TGTs are still issued with RC4 encryption you may need to manually reset the password of the KRBTGT account. That is due to the fact that the KRBTGT password does not automatically rotate. As a result, the current password may have been set back in the 2003 days when AES key generation was not supported. If you need to update your password I recommend you leverage this script. In fact, it is recommended to reset it a second time after waiting a minimum of 10 hours (default TGT lifetime) so there is an AES key in the password history attribute.
Wenn Trusted Domains zum Einsatz kommen bitte auch diesen Artikel lesen bevor man RC4 deaktiviert:
"Unsupported etype" error when accessing a resource in a trusted domain
1
