der angeforderte Verschlüsselungstyp wird vom Kerberos-Domänencontroller nicht unterstützt

[cj_berlin 1.329]

vor 8 Minuten schrieb micha42:

Das GPRESULT beim Client bekämpfe ich jetzt umsonst.

Umsonst oder nur vergebens?

Was ich vermute, ist, dass dort Einstellungen wirken, die sich mit denen auf den DCs nicht überschneiden. Somit kann kein EType ausgehandelt werden, nach dem das Passwort gehasht werden soll.

 

Du kannst die effektive Einstellung auf dem Client auch in der Registry sehen: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters SupportedEncryptionTypes

bearbeitet 4. Mai 2022 von cj_berlin

[micha42 29]

 hm 

GPresult auf Remoterechner kämpfe ich halt gerade:

gpresult /S FQDN-Client /H c:\temp\gpresult2.html

INFO: The user does not have RSoP data.

 

Den Verdacht hatte ich ja auch, aber aktuell sehe ich dafür keine Gründe. Ja, ich weiß, ich sehe die Gründe nicht, weil ich nicht gucken kann, aber ich bin halt dran

am Client steht auch im AD:

msDS-SupportedEncryptionTypes= AES256 (usw)

[cj_berlin 1.329]

Was passiert denn, wenn Du bei einem betroffenen User das Häkchen setzt bei "Account supports AES256 encryption" bzw. msDS-SupportedEncryptionTypes auf 0x10? 

[micha42 29]

vor 13 Minuten schrieb cj_berlin:

Du kannst die effektive Einstellung auf dem Client auch in der Registry sehen: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters SupportedEncryptionTypes

Super-Tip

Aber damit kann ich leider nix anfangen 7ffffff0 bzw 2147483632

 

ich google mal

vor 1 Minute schrieb cj_berlin:

Was passiert denn, wenn Du bei einem betroffenen User das Häkchen setzt bei "Account supports AES256 encryption" bzw. msDS-SupportedEncryptionTypes auf 0x10? 

Ey das ist der GF! mit dem spiele ich nicht rum. (gezuckt hatte ich ja auch, aber der Haken ist bei keinem drin. 

Ich bin unsicher, was das auslöst. Kann ich den Haken gefahrlos setzten?

[cj_berlin 1.329]

Das ist auch AES256 + future enctypes.

vor 13 Minuten schrieb micha42:

Ey das ist der GF! mit dem spiele ich nicht rum. (gezuckt hatte ich ja auch, aber der Haken ist bei keinem drin. 

Ich bin unsicher, was das auslöst. Kann ich den Haken gefahrlos setzten?

Das löst aus, dass für das Account alles, was nicht angekreuzt ist, nicht verwendet wird. Und da offenbar sowohl die DCs als auch die Clients nur AES256 erlaubt haben, sollte da theoretisch gar nichts passieren. Lass Dir eine Audienz geben, er soll alle wichtigen Dateien schließen und alle wichtigen Programme beenden, und dann probierst Du es halt.

Kannst die Session damit anfangen, dass Du in seinem Benutzer-Kontext die CMD aufmachst (was bei euch natürlich deaktiviert ist  ) und

klist tickets

sagst. Da kannst Du dann sehen, welche Verschlüsselung die derzeit angemeldete Sitzung verwendet.

bearbeitet 4. Mai 2022 von cj_berlin

[micha42 29]

Erst mal vielen Dank für Deine Hilfe!

 

Das werde ich morgen so machen.

[daabm 1.366]

Für Security Settings "Quickcheck" braucht man keinen gpresult, da reicht secpol.msc. Alles, was aus GPOs kommt, wird da so angezeigt wie es die GPOs setzen, ist dann aber nicht änderbar. Und genau da würde ich mal schauen, ob die gleichen E-Types für Kerberos konfiguriert sind wie für die DCs.

[micha42 29]

Am 4.5.2022 um 16:42 schrieb cj_berlin:

Was passiert denn, wenn Du bei einem betroffenen User das Häkchen setzt bei "Account supports AES256 encryption" bzw. msDS-SupportedEncryptionTypes auf 0x10? 

Das konnte ich heute testen, ohne Erfolg.

 

 

Ende vom Lied: "Sie setzen mir jetzt das folgende Passwort: diktier,diktier"

Ich hab also in genau 365 Tagen das Problem nochmal.

Naja ich hab noch weitere 2 Konten mit dem Problem.

Jetzt aber Feierabend und langes Wochenende. Montag geht s weiter.

 

Das mit 

klist tickets

werde ich dann testen wenn ich beim zweiten die Audienz habe.

Auch die Anregung von daabm wenn ich dann da an das Keyboard darf. 

[MurdocX 953]

Kleine Randnotiz: Ab Server 2019 wird jedes Kerberos-Ticket mit AES 265 ausgeliefert und die Haken sind obsolet. Ab 2016 ist das noch nicht der Fall. 

 

Wurde sich mal an einem anderen Computer mit dem Account angemeldet und versucht dort das Passwort zu wechseln?

Was steht den im Benutzer in dem Attribut "userAccountControl"?

[cj_berlin 1.329]

vor einer Stunde schrieb MurdocX:

Kleine Randnotiz: Ab Server 2019 wird jedes Kerberos-Ticket mit AES 265 ausgeliefert und die Haken sind obsolet. Ab 2016 ist das noch nicht der Fall. 

Huch? Wo steht das? 2019er und 2022er DCs speichern weiterhin RC4_HMAC_MD5-Hashes, wenn es nicht wegkonfiguriert wurde. Und der erste DC einer Domäne, egal in welcher Version, muss RC4 unterstützen, sonst kann er ja die lokalen Accounts nicht in Domain-Accounts konvertieren.

[MurdocX 953]

vor 13 Minuten schrieb cj_berlin:

Huch? Wo steht das?

Offiziell? Ich konnte nichts finden. Einige Sicherheitsforscher hatten festgestellt, das die Kerberos.dll zwischen 2016 und 2019 undokumentiert verändert worden ist. In deren Teststellungen konnte nachgestellt werden, dass die Einstellungen im Benutzerobjekt zu AES128 und AES256 ignoriert werden und immer AES256 ausgeliefert wird. Sie hatten sich dazu auf Twitter ausgetauscht. Leider finde ich den Artikel nicht mehr. AFAIK war es eine Unterhaltung mit David Weston.

[cj_berlin 1.329]

OK, der Sachverhalt ist folgender: 2019 und höher erlaubt kein Downgrade der Verschlüsselung für das Service-Ticket, d.h. selbst wenn Client und User nur RC4 können, der Service-Account jedoch *auch* AES, wird das Service-Ticket mit AES verschlüsselt. Das ist funktional ja auch in Ordnung, denn nur der Service muss das Ticket entschlüsseln, der Client reicht es ja nur im Auftrag des Users beim Service ein.

 

Ich habe das gestern nachvollzogen (Server 2003 als Member in einer Server 2022-Domäne und ja, dafür musste ich SMB1 nachträglich installieren  ). Prä-Auth geht mit RC4, TGT und Service-Ticket ist mit dem verschlüsselt, was KRBTGT respektive der Service-Account als höchstes können. Somit ist der Haken nicht wirkungslos, aber die Einsatzszenarien für den Haken sind etwas weniger geworden. 

 

EDIT: Vermutlich ist es deswegen auch nicht explizit irgendwo dokumentiert, denn es ist ja keine "Verhaltensänderung" im eigentlichen Sinne (sowohl das alte als auch das neue Verhalten bewegen sich innerhalb der RFCs), sondern erschwert einfach nur das Kerberoasting.

bearbeitet 7. Mai 2022 von cj_berlin

[micha42 29]

Am 6.5.2022 um 19:44 schrieb MurdocX:

Wurde sich mal an einem anderen Computer mit dem Account angemeldet und versucht dort das Passwort zu wechseln?

Was steht den im Benutzer in dem Attribut "userAccountControl"?

Hallo MurdocX,

Das Ändern des PW an einem anderen Rechner konnte ich nicht testen (nicht soo willig der user)

In UserAccountControll steht: 0x200 = Normal_Account