Info: Ganz unten, im Update vom 02.11.2022 ist die Lösung für das Problem beschrieben. Wen die Hintergründe des Problems nicht interessieren, einfach gleich nach unten scrollen.

Der ursprüngliche Blogbeitrag

Nach dem Update auf Windows 11 22H2 konnte ich mich nicht mehr auf meine NAS-Laufwerke (Synology) verbinden. Zum Beispiel lieferte die Anzeige des Temp-Verzeichnisses mit dem DIR-Befehl die Meldung zurück, dass der Benutzername nicht korrekt ist und das war auch bei der Anzeige des Home-Verzeichnisses der Fall.

C:\Temp> dir \\nasbp.home.local\temp
Der Benutzername oder das Kennwort ist falsch.

Obwohl die Credentials mit cmdkey im System gespeichert sind, habe ich es nochmals mit dem Parameter /u:home\bernd probiert und abermals den Hinweis bekommen, dass mein Passwort nicht korrekt wäre.

Zuerst hatte ich das Windows 11 22H2 Update generell verdächtigt, aber auf allen Systemen bis auf zwei funktionierte der Zugriff nach wie vor.

Um das hier vorne weg zu nehmen, funktioniert hat der Zugriff von der Professional Edition aus und lediglich Clients mit der Windows 11 22H2 Enterprise Edition hatten Zugriffsprobleme.

Die Umgebung

Die Daten liegen auf einem Synology NAS (DSM 7.1x). Ich verwende aber nicht die Benutzer-Verwaltung von Synology, sondern den Synology Directory Server (was nix anderes als Samba ist) um den Zugriff auf die Laufwerke (Shares / Freigaben) auf dem NAS zu regeln. Die Anmeldung erfolgt damit gegen eine Samba-Domain, die über den Synology Directory Server bereitgestellt wird. Neben einigen Windows Systemen die in der Domain Mitglied sind, gibt es eine Reihe von Geräten die ihre Heimat woanders haben und lediglich über Benutzer / Passwort (was wiederum im Synology Directory Server liegt und per cmdkey auf dem Gerät gespeichert ist) auf das NAS zugreifen.

Das Problem und ein erster Workaround

Die Symptome zeigen sich auf zwei Wegen.

1. Die Ansicht vom Verzeichnissen per Dir und dem FQDN / UNC-Pfad funktioniert nicht mehr (siehe Bild oben), egal ob das in der Eingabeaufforderung (cmd), PowerShell oder im Windows Explorer probiert wird
2. Ein net use wie zum Beispiel net use t: \\nasbp.home.local\temp schlägt mit einem Fehler 86 fehl

Was aber immer geht, ist die Verwendung der IP des NAS und nicht des FQDN, also \\92.168.178.11\temp und damit habe ich hier auch gleich den Workaround beschrieben. Natürlich ist der Workaround nicht schön, aber erst einmal besser als nichts.

Die Ursache – The good case –

Um der Sache in Stück weit auf den Grund zu gehen, habe ich mich entschlossen einen Trace im Netzwerk zu ziehen. Wireshark und netsh sind hier die Mittel der Wahl. Bevor man sich dem eigentlichen Problem zuwendet, ist es sinnvoll mit einem Trace einen funktionierenden Zugriff mitzuschneiden.

Der Trace zeigt alle Schritte die erfolgen müssen um erfolgreich den Inhalt von \\nasbp.home.local\temp mit dem Benutzer home\bernd angezeigt zu bekommen.

Wichtig hier ist das Paket 479, in dem die Anforderung für home\bernd an den Server gesendet wird und die Bestätigung über Paket 481.

Zu sehen ist dabei auch, dass Domain, Account und Hostname des Clients korrekt angezeigt und übertragen werden.

In Paket 488 sieht man dann auch die finale Anfrage nach \\nasbp.home.local\temp und die erfolgreiche Bestätigung in Palet 490.

Die erfolgreiche Kommunikation basiert vollständig auf NTLM und verwendet kein Kerberos. Als Client war Windows 11 22H2 Professional Edition im Einsatz.

Die Ursache – The bad case –

Schaut man sich dagegen einen Trace an, in dem die Verbindung nicht zustande kommt, passieren hier andere interessante Dinge. Dazu müssen wir aber ein wenig ausholen und nicht nur den SMB Verkehr betrachten, der ist nämlich ein “Oper” von Dingen die davor passiert sind.

Die DNS Abfragen sehen hier noch wie erwartet aus.

Der Client (dieses Mal die IP 192.168.178.141, fragt den Server / das NAS 192.168.178.11 und .21 nach dem A (IPv4) und dem AAAA (IPv6) Eintrag ab und bekommt auch die korrekten Werte geliefert. Auch SMB scheint noch am Anfang korrekt zu arbeiten.

In Paket 159 fragt der Client den Server nach dem zu verwendenden SMB Dialect an.

In Paket 161 antwortet der Server mit SMB2 *

Daraufhin versucht der Client in Paket 162 auf eine nochmals höhere Version zu gehen.

Wo der Server auch gerne mitgeht (irgendwie ist das wie beim Reizen im Skat).

In Paket 165, wurde letztendlich der höchste der angebotenen Dialekte SMB 3.1.1 verhandelt und angenommen.

Jetzt schickt der Client in Paket 171 (KRB5) einen AS-REQ an den Server.

Hier eine Abbildung der unter etype angebotenen Verschlüsselungsarten (Paket 171).

Die Anfrage wird vom Server abgelehnt (Paket 173), da er eine PRE-Authentification fordert, dazu wird aber auch gleich die notwendige Verschlüsselungsart mitgeteilt.

Die Kommunikation endet immer mit einem Fehler, nachdem insgesamt 6 Pakete ausgetauscht wurden.

KRB Error: KRB5KRB_AP_ERR_BAD_INTEGRITY

Das passiert wiederum 4x und danach erscheint die Meldung, dass der Benutzer oder das Passwort nicht korrekt ist und das nur, wenn als Client Windows 11 22H2 Enterprise Edition verwendet wird.

Ein zweiter (schmutziger) Workaround

Ich selber bin kein Freund von IP-Adressen in dem Sinne, dass sie für Verbindungen zu anderen Systemen genutzt oder gar hart verdrahtet werden. Wieso gibt es denn eigentlich DNS und den will ich auch verwenden?!

Einen Fall-Back von Kerberos auf NTLM lässt sich damit erzwingen, dass wir seitens des SMB-Servers (dem NAS) die DES-Encryption erzwingen.

Das ist an sich keine schöne Sachen, da DES als “weak” gilt und nicht mehr verwendet werden sollte.

Wie in den Paketen 95 und 97 im folgenden Trace zu sehen ist, können sich Server und Client nicht auf DES einigen und es erfolgt ein Fall-Backup auf NTLM.

Damit zwingt man die Enterprise Edition zum gleichen Verhalten wie die Windows 11 22H2 Professional Edition.

Zum Schluss

Es stellt sich nun die Frage, wieso verhält sich die Enterprise Edition eigentlich so, während Windows 11 22H2 Professional gleich mit NTLM ins Rennen geht.

Eine mögliche und für mich die einzige Erklärung die ich gefunden habe ist, dass mit Windows 11 22H2 bei der Enterprise Edition der Windows Defender Credential Guard aktiviert wurde.

Ich bin gespannt, wie die Sache weiter geht und werde es Euch wissen lassen wenn neue Erkenntnisse vorliegen. Falls hier jemand weitere Infos hat, bitte in die Kommentare unten reinschreiben.

Update 02.11.2022

Das Problem scheint nur Synology NAS Systeme und den Directory Server zu betreffen, ansonsten ist es recht ruhig zu dem Thema im Internet. Zumal, wenn der Zugriff über eine IP-Adresse anstatt des FQDN erfolgt, es ohnehin nicht auftritt.

Nun hat Synology Anfang November ein Update für den SMB Service bereitgestellt, welches das folgende Problem löst.

“Fixed an issue where users could not joind their computers to Synology Directory Server after updating OS to Windows 11 22H2”

Seitdem ist das Problem bei mir nicht mehr aufgetreten. Nach der Installation des Updates auf dem NAS habe ich die DES encryption für den Account wieder rückgängig gemacht und alles läuft und funktioniert wieder wie gehabt.

Enjoy it, b!