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

[micha42 29]

Moin, die im Betreff stehende Fehlermeldung bekommen mehrere user bei uns.

Kurz zum Hintergrund. Wir wollen hier eine neue Passwortrichtlinie ausrollen und dann auch mal (endlich) den VIPs den Haken "Passwort läuft nie ab" wegnehmen.

Da wir das Max-Alter deutlich reduzieren (auf ein Jahr) haben wir alle user angeschrieben, die ein älteres PW haben.

Die haben dann alle (ok, fast alle) brav ihr PW geändert.

 

 

Einige bekommen leider Fehlermeldungen

Die haben teilweise ihr Passwort seit 2015 nicht geändert.

Wenn ich nun aber mit den usern das Passwort ändern will, bekomme ich die Meldung, mit der ich nichts anfangen kann.

Ich vermute es liegt an der Kommunikation zwischen Client und DC.

Client ist Win10, DC ist Win2016, keine Firewall dazwischen.

Leider sind das nun auch nicht die Konten von irgendwelchen usern mit denen ich das Stundenlang durchtesten kann, bis es geht.

Was ich schon probiert habe:

Passwort zurückgesetzt (mit und ohne den Haken für "muss PW bei der nächsten Anmeldung ändern")

Eventlog durchsucht (nix zu sehen)

 

Ich stehe auf dem Schlauch, hat Jemand eine Idee?

 

Michael

[zahni 521]

Was sind das für DC's und welche Funktionsebene?  Neue Passwörter werden nur noch mit AES verschlüsselt. Dazu muss die Funktionsebene angehoben werden, ich glaube auf mindestens 2008R2

[micha42 29]

Funktionsebene ist 2012R2

Server haben Win 2016 (ein 2012R2 ist noch dabei)

bearbeitet 4. Mai 2022 von micha42

[zahni 521]

Hast Du Domain und Forrest hochgestuft? Leider hat MS das geschickt in verschiedenen GUI's versteckt. 

 

Siehe auch https://niedhorn.de/2015/12/02/replikationsfehler-zum-standort-der-angeforderte-verschlsselungstyp-wird-vom-kerberos-domnencontroller-nicht-untersttzt/

 

PS: Wenn Du (korrekte) FM in Englisch googelst, hat Du sicher noch mehr Treffer. Ich installiere schon ewig Server nur noch ein Englisch, damit bei Fehlern immer die korrekte englische FM bekomme... 

[micha42 29]

ja, beide sind auf 2012R2

(by the way, das hab nicht ich hochgestuft, ich bin hier erst seit Kurzem)

 

Die Fehlermeldung habe ich von einem Screenshot von einem Client, die installieren wir der Einfachheit halber dann doch in D.

Ja, Du hast Recht und der Tip ist goldrichtig, aber die DCs sind tatsächlich alle mit englischem OS installiert. In der Ereignisanzeige habe ich nichts gefunden. 

Den Artikel, den Du verlinkt hast, (danke dafür) hatte ich auch gefunden, aber das hat -glaube ich- nichts mit meinem Problem zu tun.

Die Server sind ja auch nicht erst seit gestern im auf der Funktionsebene, daher haben die alle schon diverse Neustarts gehabt. 

[NilsK 2.781]

Moin,

 

möglicherweise ist auf den jeweiligen Clients etwas verkonfiguriert. Prüf mal, ob diese Clients von GPOs betroffen sind, in denen etwas in der Art konfiguriert ist.

 

vor 1 Stunde schrieb micha42:

Da wir das Max-Alter deutlich reduzieren (auf ein Jahr)

Einen regelmäßigen Kennwortwechsel erzwingt man heute eigentlich nicht mehr. Die Erkenntnis ist, dass man damit das Sicherheitsniveau absenkt, statt es zu heben. Ein so langer Zyklus ist auch ziemlich unsinnig. Kennwörter ändert man, wenn es den Verdacht gibt, dass sie kompromittiert sind - und dann sofort.

 

Gruß, Nils

 

[micha42 29]

moin, mit dem Durcharbeiten der GPOs hab ich auch schon angefangen, aber die 172 GPOs sind teilweise etwas unübersichtlich und ich brauche da noch etwas. (wie gesagt - neu hier)

Das mit dem Kennwortwechsel sehen hier alle genau so, aber der externe Sicherheitsberater nicht. und nun rate mal wem der CISO gefolgt ist...

[cj_berlin 1.133]

vor 18 Minuten schrieb NilsK:

Einen regelmäßigen Kennwortwechsel erzwingt man heute eigentlich nicht mehr. Die Erkenntnis ist, dass man damit das Sicherheitsniveau absenkt, statt es zu heben. Ein so langer Zyklus ist auch ziemlich unsinnig. Kennwörter ändert man, wenn es den Verdacht gibt, dass sie kompromittiert sind - und dann sofort.

Das ist jetzt vielleicht philosophisch, aber diese Argumentation gilt ausschließlich für Umgebungen, in denen Mittel (Technik *und* Manpower) vorhanden sind, um den Verdacht überhaupt erst schöpfen zu können, dass ein Account kompromittiert worden ist. Solange diese Mittel nicht am Start sind und NTLM + RC4 in der Umgebung aktiv ist, ist der regelmäßige Kennwortwechsel immer noch das einzige, was hilft, einen bereits erbeuteten NTLM-Hash nutzlos zu machen.

 

Wenn der User selber merkt, dass mit seinem Account Schindluder getrieben wird, ist das Kind vermutlich aus dem Brunnen wieder herausgeklettert und fällt bereits in den nächsten Brunnen.

[micha42 29]

nein bitte keine philosophischen Diskussionen.

[cj_berlin 1.133]

Dann eben nicht philosophisch, sondern ganz konkret: Habt ihr ein lückenloses und vor allem wirklich gelebtes SIEM? Falls nein, hat der externe Sicherheitsberater recht, und ihr seht es alle falsch.

 

Und in der Sache:

• Was steht bei den betroffenen Usern im Attribut msDS-SupportedEncryptionTypes?
• Was steht bei den Domain Controllern in diesem Attribut?
• Was steht in der effektiv auf die Clients wirkenden Policy (GPRESULT hilft übrigens, nicht 172 GPOs durchuschen zu müssen  ) unter 
• 
• ...und das gleiche für Domain Controller?

 

[NilsK 2.781]

Moin,

 

vor 50 Minuten schrieb cj_berlin:

Das ist jetzt vielleicht philosophisch, aber diese Argumentation gilt ausschließlich für Umgebungen, in denen Mittel (Technik *und* Manpower) vorhanden sind, um den Verdacht überhaupt erst schöpfen zu können, dass ein Account kompromittiert worden ist.

der Teil mit dem Wechseln bei Verdacht - ja, vielleicht (aber auch eher nein). Der Teil mit dem herabgesetzten Sicherheitsniveau bleibt in jeder Umgebung bestehen. Leute, die leicht knackbare Kennwörter verwenden, tun dies auch und gerade dann, wenn sie regelmäßig zum Wechsel gezwungen werden. Aus Leckmich2022-04 wird dann Leckmich2022-05. 

 

vor 50 Minuten schrieb cj_berlin:

ist der regelmäßige Kennwortwechsel immer noch das einzige, was hilft, einen bereits erbeuteten NTLM-Hash nutzlos zu machen

Was aber völlig nutzlos ist, wenn der regelmäßige Kennwortwechsel nach sechs Wochen - oder wie hier: nach einem Jahr! - stattfindet.

 

Gruß, Nils

 

bearbeitet 4. Mai 2022 von NilsK

[micha42 29]

GPresult. stimmt natürlich

 

Also auf den DCs

 

Client gucke ich gerade noch, kommt gleich

[cj_berlin 1.133]

Oh, AES128 ist auch nicht mehr sicher genug? Wow, das ist schon hart. 

Andererseits wüßte ich auf Anhieb kein System, das AES128 könnte und AES256 nicht...

[NorbertFe 1.799]

vor 2 Stunden schrieb cj_berlin:

Wenn der User selber merkt, dass mit seinem Account Schindluder getrieben wird, ist das Kind vermutlich aus dem Brunnen wieder herausgeklettert und fällt bereits in den nächsten Brunnen.

Den muss ich mir merken. 

[micha42 29]

Das GPRESULT beim Client bekämpfe ich jetzt umsonst.

 

Aber Du fragtest

• Was steht bei den betroffenen Usern im Attribut msDS-SupportedEncryptionTypes?
• Was steht bei den Domain Controllern in diesem Attribut?

Bei den usern steht 0 (bei allen usern, auch die, die keinen Fehler erzeugen)

Bei den DCs steht 0x10 = AES256_CTS_HMAC_SHA1_96 (wie n der GPO gefordert