15
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:
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: 4558832373
Url: https://administrator.de/contentid/4558832373
Printed on: May 9, 2024 at 14:05 o'clock
15 Comments
Latest comment
Hi @preysa
Ja, das wird's sein, besten Dank!
Ja, das wird's sein, besten Dank!
Ich nehme die Markierung als Lösung mal zurück, da das Thema doch noch nicht geschlossen werden soll:
Durch die zu setzenden Registrykeys konnte KEINE Besserung erzielt werden, egal, wie lasch man die einstellt.
Die einzige Lösung: den Haken bei "This account supports Kerberos AES 256 bit encryption" entfernen.
Wenn man nun überlegt, dass dieser Haken defaultmäßig nicht gesetzt ist und weiß, wie schlecht Microsoft testet, wundert man sich nicht mehr...
Ich warte also einmal ab, ob sich auf Linuxseite (SuSe) oder bei MS hier noch was tut und hoffe auf weitere Erfahrungen auch von Euch!
Durch die zu setzenden Registrykeys konnte KEINE Besserung erzielt werden, egal, wie lasch man die einstellt.
Die einzige Lösung: den Haken bei "This account supports Kerberos AES 256 bit encryption" entfernen.
Wenn man nun überlegt, dass dieser Haken defaultmäßig nicht gesetzt ist und weiß, wie schlecht Microsoft testet, wundert man sich nicht mehr...
Ich warte also einmal ab, ob sich auf Linuxseite (SuSe) oder bei MS hier noch was tut und hoffe auf weitere Erfahrungen auch von Euch!
Oh-oh...
Nicht nur Linux ist betroffen, auch Win10 21H2.
Auch hier muss der Haken aus meinem obigen Screenshot entfernt werden, damit Kerberisierte Verbindungen funktionieren.
Nicht nur Linux ist betroffen, auch Win10 21H2.
Auch hier muss der Haken aus meinem obigen Screenshot entfernt werden, damit Kerberisierte Verbindungen funktionieren.
Hallo,
bedeutet das umgekert, dass ihr Kerberos nicht global auf AES256 einschränkt? Dann teste ich das Update lieber unter einer Ausnahme davon bei mir.
Grüße
Richard
bedeutet das umgekert, dass ihr Kerberos nicht global auf AES256 einschränkt? Dann teste ich das Update lieber unter einer Ausnahme davon bei mir.
Grüße
Richard
bedeutet das umgekert, dass ihr Kerberos nicht global auf AES256 einschränkt?
Wir hatten es noch nicht für alle umgesetzt. Testerkreis war IT-intern und sollte witzigerweise jetzt auf global erweitert werden, wo wir allen die SmartCards in die Hand drücken. Es fiel bei den IT-lern auch nicht sofort auf, da es eben mehrere DCs gibt und erst einer gepatcht war. Und anmelden konnten sie sich auf Windows trotzdem, nur auf SuSe scheiterte bereits die Anmeldung.
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).
Passwort zurücksetzen wie im Event beschrieben bringt keine Besserung?
Habe selbst ein paar AES-256 aktivierte Konten und leider jat das hier noch niemand erwähnt.
Habe selbst ein paar AES-256 aktivierte Konten und leider jat das hier noch niemand erwähnt.
Passwort zurücksetzen wie im Event beschrieben bringt keine Besserung?
Nein.@c.r.s.
Danke für die Tests. Ich kann bestätigen, dass ich die GPO nutzen kann und es läuft auf Win10 21H2 (PC neu starten!). Jedoch fällt dann auf, dass, wenn man ausschließlich AES256 oder höher ("future encryption standards") erlaubt, KEINE RDP-Verbindung zu Server 2016 (1607) mehr möglich ist. Erlaube ich hingegen zusätzlich AES128, dann läuft es wieder.
Spannend.
Moin @c.r.s:
Ich habe mich noch am Freitag sehr über meinen eigenen Client geärgert, denn er startete nur noch im Public Profile, nicht mehr im Domänenprofil und eine Anmeldung via Smartcard war nicht mehr möglich ("Revocation Server kann nicht erreicht werden"). (Anmeldung per Kennwort blieb möglich, will ich aber nicht)
- woran lag's? An diesem Patch. Ich hatte nach dem Setzen besagter GPO, die das Setzen per Haken im Nutzerobjekt ersetzen sollte, erst 1x neu gestartet - nach einem weiteren Neustart gehen dann die Probleme los. Nun ist die GPO auf Defaults und alles läuft.
Ich warte ab, was MS als nächstes tut.
Ich habe mich noch am Freitag sehr über meinen eigenen Client geärgert, denn er startete nur noch im Public Profile, nicht mehr im Domänenprofil und eine Anmeldung via Smartcard war nicht mehr möglich ("Revocation Server kann nicht erreicht werden"). (Anmeldung per Kennwort blieb möglich, will ich aber nicht)
- woran lag's? An diesem Patch. Ich hatte nach dem Setzen besagter GPO, die das Setzen per Haken im Nutzerobjekt ersetzen sollte, erst 1x neu gestartet - nach einem weiteren Neustart gehen dann die Probleme los. Nun ist die GPO auf Defaults und alles läuft.
Ich warte ab, was MS als nächstes tut.
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.
So ist es. RC4, Kerb128+256 erlauben - alles läuft.
