Windows 11 - Kerberos - Login SQL-Server

[wznutzer 32]

Guten Tag,

 

irgendeine Info scheint an mir vorbeigegangen zu sein.

 

W2K22 mit 2 SQL-Server Instanzen

Nur eine Domäne, Windows-Authentifizierung

 

Windows 10 und Windows 11 vor 23H2 können sich problemlos mit beiden Instanzen verbinden. Windows 11 23H2 meldet:

Zitat

Anmeldefehler. Die Anmeldung stammt aus einer nicht vertrauenswürdigen Domäne und kann mit der integrierten Authentifizierung nicht verwendet werden. (Microsoft SQL Server, Fehler: 18452)

 

SQL-Log:

SSPI handshake failed with error code 0x8009030c...

 

Es liegt am fehlenden SPN und für das gibt es ja auch auch den "Microsoft® Kerberos Configuration Manager for SQL Server®".

 

Ich kapiere aber nicht warum? Hat sich mit Windows 11 23H2 irgendwas verändert das Kerberos erzwingt?

 

Ahnungslose Grüße

[zahni 521]

Eventuell ein anderer SQL-Client, der kein NTLM mehr macht?

[wznutzer 32]

Seltsamerweise wird beim Zugriff per NTLM folgendes am SQL-Server protokolliert:

Zitat

 

Fehlerinformationen:

Fehlerursache:        Unbekannter Benutzername oder ungültiges Kennwort.
Status:            0xC000006D
Unterstatus::        0xC000006A

 

Gleicher Account an verschiedenen anderen Rechnern funktioniert?

[zahni 521]

Bei mir hatte das komische Kerberos-Tool von MS beim SQL 2022 bei mir nicht mehr funktioniert. Das sollte man händisch machen. 

Läuft der SQL mit einem Domain-Konto? Da müssen die SPN's rein. Prüfe auch, ob Du nicht irgendwo Dopplungen hast.

[NilsK 2.785]

Moin,

 

soweit war der TO im ersten Post doch schon, oder? Die Frage scheint doch eher zu sein, ob Windows 11 seit 23H1 Kerberos erzwingt.

 

Gruß, Nils

 

[zahni 521]

vor 9 Minuten schrieb NilsK:

Moin,

 

soweit war der TO im ersten Post doch schon, oder? Die Frage scheint doch eher zu sein, ob Windows 11 seit 23H1 Kerberos erzwingt.

 

Gruß, Nils

 

Ich vermute hier, dass NTLM genutzt wurde. Daher die Klärung.

 

PS: https://learn.microsoft.com/de-de/troubleshoot/sql/database-engine/connect/cannot-generate-sspi-context-error

bearbeitet 9. April von zahni

[wznutzer 32]

Vielen Dank für eure Mühe. Der SQL-Server hat noch kein MSA und läuft tatsächlich noch mit einen "normalen" Domänenaccount. Der fehlende SPN ist nicht aufgefallen, weil einfach NTLM gemacht wurde. Aber nun schlägt NTLM fehl, weil lt. Log der Benutzername oder das Kennwort falsch ist.

 

Mit W11 23H2 scheint es nichts zu tun zu haben, eher Zufall. Der gleiche Account kann sich an verschiedenen PCs mit W11 23H2 problemlos mit dem SQL auch per NTLM verbinden.

 

nltest /sc_query:domäne ==> alles in Ordnung

\\domäne.local ==> Sysvol usw. wird nicht angezeigt, Anmeldedialog erscheint

\\irgendeinDC ==> Sysvol wird angezeigt, alles prima

 

Ich forsche mal weiter...

 

 

 

 

bearbeitet 9. April von wznutzer
Schreibfehler

[MurdocX 904]

Rein zufällig den aktuellen Patch auf den DCs installiert, ohne den OOB-Patch?

[daabm 1.185]

vor 4 Stunden schrieb wznutzer:

Unterstatus::        0xC000006A

Der ist eigentlich nicht zweideutig...

 

# for hex 0xc000006a / decimal -1073741718 :
  STATUS_WRONG_PASSWORD                                         ntstatus.h

[wznutzer 32]

vor 21 Stunden schrieb MurdocX:

Rein zufällig den aktuellen Patch auf den DCs installiert, ohne den OOB-Patch?

Ja, ich dachte mich betrifft das nicht und ich konnte auch keinen übermäßigen Speicherverbrauch feststellen.

 

Der OOB-Patch sollte doch im aktuellen April-Patch mit drin sein oder? Den installiere ich sowieso heute Nacht, ich werde dann berichten.

 

vor 20 Stunden schrieb daabm:

Der ist eigentlich nicht zweideutig...

 

# for hex 0xc000006a / decimal -1073741718 :
  STATUS_WRONG_PASSWORD                                         ntstatus.h

Ich kapiere nicht warum. Der User meldet sich lokal an, nutzt Netzwerkfreigaben, RDP, Fileserver und der SQL-Server meint dann, dass das Passwort falsch ist?

 

*weitergrübelnd*

[zahni 521]

vor 36 Minuten schrieb wznutzer:

Ich kapiere nicht warum. Der User meldet sich lokal an, nutzt Netzwerkfreigaben, RDP, Fileserver und der SQL-Server meint dann, dass das Passwort falsch ist?

Wie meldet er sich denn am SQL-Server an? Also mit welcher Anwendung? Wenn Kerberos nicht korrekt konfiguriert ist, klappt das SSO u.U. nicht. Dann kommt User /Password. Ich hatte schon Fälle, wo die GUI schlicht bestimmte Sonderzeichen im Passwort falsch übertragen hatte, speziell Umlaute und das Paragraphenzeichen. Ob der User vom gewünschten Server ein Kerberos-Ticket bekommen hat, kann man einfach mit "KLIST" abfragen. Da kann man dann auch prüfen ob die Verschlüsselung auf AES-256-CTS-HMAC-SHA1-96 konfiguriert ist. BTW, da fällt mir ein: Vielleicht hat Microsoft in der Windows-Version RC4 und DES deaktiviert, die sind nämlich unsicher. 

Hier muss man prüfen, ob das Konto mit den SPNs die Option  angehakt hat. Ist mir auch vor einiger Zeit bei neueren Java-Versionen auf die Füße gefallen, weil die dort RC4/DES schon entfernt haben.

[daabm 1.185]

Am 8.4.2024 um 11:12 schrieb wznutzer:

Windows 10 und Windows 11 vor 23H2 können sich problemlos mit beiden Instanzen verbinden. Windows 11 23H2 meldet:

 

Fällt mir grad noch so ein - Windows verbindet sich nicht "einfach so" mit einer Datenbank. Was für eine Anwendung steckt dahinter? Fuschelt die irgendwie mit Credentials rum? Oder wie prüfst Du, ob der Zugriff funktioniert - SSMS?

[wznutzer 32]

Am 10.4.2024 um 16:34 schrieb zahni:

Wie meldet er sich denn am SQL-Server an? Also mit welcher Anwendung?

Am 10.4.2024 um 19:17 schrieb daabm:

Was für eine Anwendung steckt dahinter?

Die User verwenden das SQL-Management Studio, aber auch eigen entwickelte Software die per ODBC (SQL Native Client) zugreift hat das Problem. Selbst ein kleines Testprogramm mit der MFC (CDatabase) oder C# funktioniert nicht.

 

Es ist kein Kerberos-Problem. Wenn der SPN da ist, funktioniert es. Es ist aber auch kein spezielles SQL Problem, weil der Zugriff auf \\domain.local auch zu einer Meldung mit falschen Anmeldedaten führt. Es ist evtl. mein Problem, dass ich mich noch nicht getraut habe NTLM komplett abzuschalten .

• Nur User mit Umlaut im Anmeldenamen sind betroffen.
• Windows 10 nicht, Windows 11 22H2 mit allen Updates auch nicht. Sobald dann der gleiche PC auf W11 23H2 angehoben wird, tritt der Fehler auf.
• Windows 11 23H2 mit dem März 2024 ISO installiert hat den Fehler auch nicht.
• Windows 11 23H2 mit dem November 2023 ISO installiert und dann bis zum Patchday 03/2024 aktualisiert führt zum gleichen Problem.
• Das Problem kann in einer Testumgebung (hat noch nie das Produktivnetz gesehen) nachvollzogen werden.

kleine Bitte

Falls jemand einen W11 23H2 PC (oder VM) hat, der vor März 2024 installiert wurde und vielleicht auch von 22H2 angehoben wurde, wäre prima da einfach mal \\[FQDN der lokalen Domäne] im Explorer eingeben (User mit Umlaut). Normalerweise sollte da ja dann Netlogon und SysVol (und evtl. ein Freigabeordner vom dc auf dem man gerade gelandet ist) angezeigt werden.

 

Vielen Dank für die Kommentare, ich werde berichten...

 

bearbeitet 12. April von wznutzer
Schreibfehler

[zahni 521]

Unabhängig von der Rückmeldung der Anderen: Jetzt weist Du, warum man keine Umlaute in Benutzernamen, OU's, Gruppen und anderen (LDAP)-Objekten benutzt. Selbst wenn es sich hier um einen Bug im Windows handelt, könntest Du zukünftig Anwendungen haben, die irgendwas mit LDAP machen und das auch nicht mögen.

[NorbertFe 1.805]

vor 44 Minuten schrieb wznutzer:

• Nur User mit Umlaut im Anmeldenamen sind betroffen.
•  

Wer macht denn sowas? :)