DC upgedated, Anmeldeprobleme von Linux
Servus Kollegen.
Die Frage richtet sich nur an Admins, die
Öffnet bitte auf einem dieser DCs den Eventviewer und geht ins Log "System".
Filtert das Log nach EventID 14
->bei uns treten seit den Novemberpatches mehr als stündlich solche Events auf:
Frage
Ist das bei Euch auch so?
Edit
Dies tritt nebenbei nur bei Konten auf, die folgendes Flag gesetzt haben:
Die Frage richtet sich nur an Admins, die
- mindestens einen 2016er DC haben
- diesen schon mit den Novemberupdates versorgt haben
Öffnet bitte auf einem dieser DCs den Eventviewer und geht ins Log "System".
Filtert das Log nach EventID 14
->bei uns treten seit den Novemberpatches mehr als stündlich solche Events auf:
While processing an AS request for target service krbtgt, the account Mustermann did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18 17 23 24 -135 3. The accounts available etypes : 23 18 17. Changing or resetting the password of Mustermann will generate a proper key.
->das hat auf Windowsclients keine spürbaren Nachteile. Auf Linuxclients, die der Domäne angehören, wird jedoch die Anmeldung verweigert. Probieren es die Linuxuser mehrfach, kommen sie irgendwann an den anderen DC, welcher noch ungepatcht ist und kein einziges Event 14 zeigt, und dort läuft die Anmeldung problemlos.Frage
Ist das bei Euch auch so?
Edit
Dies tritt nebenbei nur bei Konten auf, die folgendes Flag gesetzt haben:

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4558832373
Url: https://administrator.de/forum/dc-upgedated-anmeldeprobleme-von-linux-4558832373.html
Ausgedruckt am: 02.04.2025 um 22:04 Uhr
15 Kommentare
Neuester Kommentar
Kann ich bestätigen mit Ubuntu/sssd: Domain-weit gilt AES256, keine Haken, und damit funktioniert alles.
Setze ich im Konto aber den Haken:
[map_krb5_error] (0x0020): 1833: [-1765328370][KDC has no support for encryption type]
bzw. in der Antwort vom DC:
error-code: eRR-ETYPE-NOSUPP (14)
Lasse ich auf dem DC RC4 zu und behalte den Haken, funktioniert es. Verwendet wird bei der Anmeldung mit dem Konto trotzdem nur AES256.
Setze ich im Konto aber den Haken:
[map_krb5_error] (0x0020): 1833: [-1765328370][KDC has no support for encryption type]
bzw. in der Antwort vom DC:
error-code: eRR-ETYPE-NOSUPP (14)
Lasse ich auf dem DC RC4 zu und behalte den Haken, funktioniert es. Verwendet wird bei der Anmeldung mit dem Konto trotzdem nur AES256.
Für den speziellen Fall gibt es noch eine weitere Info Seite von MS:
https://support.microsoft.com/de-de/topic/kb5021131-how-to-manage-the-ke ...
Vielleicht hilft dir das weiter.
Gruß
Edit
Wir sind selber hier nicht betroffen von dem Thema, wollte nur helfen. Hab mich jetzt aber ein bisschen durchgelesen und anscheinend haben noch andere Leute die selben Probleme trotz Einhaltung der Empfehlungen von MS...
https://support.microsoft.com/de-de/topic/kb5021131-how-to-manage-the-ke ...
Vielleicht hilft dir das weiter.
Gruß
Edit
Wir sind selber hier nicht betroffen von dem Thema, wollte nur helfen. Hab mich jetzt aber ein bisschen durchgelesen und anscheinend haben noch andere Leute die selben Probleme trotz Einhaltung der Empfehlungen von MS...
Zitat von @c.r.s.:
Lasse ich auf dem DC RC4 zu und behalte den Haken, funktioniert es. Verwendet wird bei der Anmeldung mit dem Konto trotzdem nur AES256.
Lasse ich auf dem DC RC4 zu und behalte den Haken, funktioniert es. Verwendet wird bei der Anmeldung mit dem Konto trotzdem nur AES256.
Jetzt habe ich noch an meiner nachlässigen Linux-Konfiguration gefeilt und sichergestellt, dass auch Linux-Clients dem DC ausschließlich aes256-cts-hmac-sha1-96 anbieten.
Es bleibt dabei: Ohne RC4 auf dem DC und mit Haken im Konto wird der Verschlüsselungstyp abgelehnt.
Zitat von @c.r.s.:
Kann ich bestätigen mit Ubuntu/sssd: Domain-weit gilt AES256, keine Haken, und damit funktioniert alles.
Kann ich bestätigen mit Ubuntu/sssd: Domain-weit gilt AES256, keine Haken, und damit funktioniert alles.
Korrektur: Ich hatte zunächst nur Linux getestet. In einer Umgebung mit ausschließlich AES256 und Windows 2019 verlieren die Computerkonten durch das Update den Domainkontakt. Könnte daran liegen, dass msDS-SupportedEncryptionTypes auch für Computerkonten gesetzt ist. Es lässt sich aber nicht durch Anpassung dieses Wertes beheben. Es hilft das Aufheben der AES-Policy und die Löschung der Policy aus der Registry des Members (das ja keine GPOs mehr zieht).
Ich habe das nicht allzu systematisch getestet, aber denke, dass es von RC4 abhängt. Mit RC4, AES128 und AES256 habe ich zumindest die Updates nun weitgehend verteilt.
Wenn ein Windows-Rechner (Member, alle DCs schon aktualisiert) noch mit AES256 konfiguriert ist, ist keine Passwort-Anmeldung möglich (remote: Kerberos-Verschlüsselungstyp nicht unterstützt; lokal: Falsches Passwort). Die Policy muss ich dementsprechend auch an der GPO vorbei zusätzlich per Remote-Management setzen. Allerdings bei Linux-Clients, die nur AES256 zulassen, funktioniert die Anmeldung noch.
Da msDS-SupportedEncryptionTypes bei den Computerkonten automatisch aktualisiert wird und ich bei Nutzern keinen Haken setze, mache ich mir über das Attribut vorerst keine Gedanken.
Wenn ein Windows-Rechner (Member, alle DCs schon aktualisiert) noch mit AES256 konfiguriert ist, ist keine Passwort-Anmeldung möglich (remote: Kerberos-Verschlüsselungstyp nicht unterstützt; lokal: Falsches Passwort). Die Policy muss ich dementsprechend auch an der GPO vorbei zusätzlich per Remote-Management setzen. Allerdings bei Linux-Clients, die nur AES256 zulassen, funktioniert die Anmeldung noch.
Da msDS-SupportedEncryptionTypes bei den Computerkonten automatisch aktualisiert wird und ich bei Nutzern keinen Haken setze, mache ich mir über das Attribut vorerst keine Gedanken.