We lost remotewebaccess.com again …

Seit dem letztem Samstag (12.11.2022) häufen sich die Berichte, dass ein Zugriff auf https://<hostname>.remotewebaccess.com nicht mehr möglich ist.

Update 19.11.2022.
Seit dem 19.11. ist der Service wieder funktional. Damit hatten wir eine Woche Ausfall, wie man sowas bewerten muss bleibt jedem selber überlassen. Die Konfiguration eines DynDns-Service mit eigenem Zertifikat würde das Problem lösen, bis der SBE außer Dienst geht.

Das Problem hatten wir schon einmal und zwar im Mai in diesem Jahr, damals wurde es nach knapp 14 Tagen !!! behoben.

image

Im Vergleich zur Situation im Mai, habe ich zum Glück nicht mehr den hohen Druck das Problem analysieren zu müssen. Inzwischen sind nur noch zwei meiner vielen (ehemals 11) Windows SBE Server aktiv und einer davon läuft mit eigenem Zertifikat und Domain, beim anderen ist der Zugriff über remotewebaccess.com zwar konfiguriert, wird aber nicht genutzt.

Ich schau trotzdem ob ich hier nochmals hilfreiche Informationen zusammentragen kann. Für Erkenntnisse aus dem Feld bin ich jederzeit dankbar, schreibt es einfach unten in die Kommentare rein.

Enjoy it, b!

(enjoy = auch wenn einem nachmal nicht danach ist)

Windows 11 2022 Enterprise Edition | Zugriffsprobleme auf das NAS

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.

image

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.

image

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.

image

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

image

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.

image

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.

image

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

image

In Paket 161 antwortet der Server mit SMB2 *

image

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

image

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

image

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

image

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

image

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

image

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

image

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

KRB Error: KRB5KRB_AP_ERR_BAD_INTEGRITY

image

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.

image

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.

image

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.

image

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”

image

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!

Excel–Öffnen in geschützter Ansicht

Nach einer Migration des Servers in eine DFS-Struktur, meldete sich Excel (aber auch andere Office Programme) mit der Meldung das Dateien nur in der “geschützten Ansicht” geöffnet werden können.

image

Der Hinweis rührt daher, dass sich der Name des Servers, der die Dateien bereitstellt geändert hat und die Office Anwendungen diesen nicht mehr als vertrauenswürdig einstufen.

Während der bisherige Zugriff über \\server\freigabe seit Jahren problemlos funktioniert hat, kommt beim Zugriff über \\dfs-fqdn\dfs\freigabe die oben gezeigte Meldung.

Beheben lässt sich das Problem an mehreren Stellen, am einfachsten aber über eine GPO welche dfs-fqdn als vertrauenswürdig einstuft.

image

In die Site to Zone Assignment List kann man mehrere Werte, IP-Bereiche usw. eintragen. Denkbar wäre zusätzlich nur “finance” falls es jemanden gibt der mit \\finance\dfs\freigabe anstatt \\finance.local\dfs\freigabe arbeitet, was zwar nicht sinnvoll aber möglich ist.

Der Wert 1 definiert die Domain (finance.local) als (1) Intranet zone und damit als vertrauenswürdig ein.

image

Definiert habe ich den Wert sowohl in der Computer Configuration als auch in der User Configuration der Policies / Richtlinen.

Im Internet kursieren eine Reihe alternativer Workarounds, wie zum Beispiel das Aufweichen der Sicherheitseinstellungen in Excel / Office wie im folgendem Screenshot zu sehen ist.

image

Davon halte ich nichts, Life is dangerous … und da muss man nicht zusätzlich die Anzahl der Angriffsvektoren erhöhen.

Enjoy it, b!