UAC | Skripte unter Windows

Veröffentlicht am Mai 1, 2024 von b!

Einleitung

Die Benutzerkontensteuerung (User Account Control, UAC) ist ein wichtiger Bestandteil der Windows-Sicherheit. UAC reduziert das Risiko von Malware, indem es die Fähigkeit von bösartigem Code einschränkt, mit Administratorrechten ausgeführt zu werden.

Mit UAC muss jede Anwendung, die das Administrator-Zugriffstoken benötigt, die Zustimmung des Endbenutzers einholen. Die einzige Ausnahme ist die Beziehung zwischen übergeordneten und untergeordneten Prozessen. Untergeordnete Prozesse erben das Zugriffstoken des Benutzers vom übergeordneten Prozess. Der übergeordnete und der untergeordnete Prozess müssen jedoch die gleiche Integritätsstufe haben.

UAC in Skripten unter Windows

Gelegentlich, aber dann wirklich problematisch, wird während der Ausführung eines Skripts eine Bestätigung für die Ausführung eines Befehls oder einer Anwendung angefordert. Als Beispiele seien hier cmd.exe, diskpart.exe und regedit.exe genannt.

Befindet man sich im interaktiven Modus, bestätigt man den Dialog und die Verarbeitung wird fortgesetzt.

Will man das Skript aber ohne Interaktionen (zum Beispiel remote) ausführen, muss man irgendwie um diese Dialog herumkommen.

PowerShell und die Eingabeaufforderung

Wenn wir über Skripting unter Windows reden, gibt es hauptsächlich Powershell und die Eingabeaufforderung, da beide in neueren Windows Versionen vorhanden sind und nicht zusätzlich installiert werden müssen.

Es gibt eine Reihe von meist freien Utilities und auch Workarounds um mit dem Problem umzugehen, soweit ich das aber vermeiden kann will ich keine 3rd-Party Utilities einsetzen (zumal diese dann im Netzwerk verteilt und auch gewartet werden müssen) und eine Deaktivierung der UAC kommt für mich nicht in Frage.

Microsoft hat hier in Windows selbst eine Lösung eingebaut, die bei mir sowohl in der Eingabeaufforderung (cmd.exe) als auch in der PowerShell sehr gut funktioniert.

Es gibt nämlich die Möglichkeit über eine Umgebungsvariable einen RunAsInvoker zu konfigurieren.

Um beispielsweise regedit.exe ohne UAC-Abfrage zu starten, verwendet man in der PowerShell folgenden Code:

:: Setzen des RunAsInvoker in PowerShell
[Environment]::SetEnvironmentVariable("__COMPAT_LAYER", "RunAsInvoker")

In der Eingabeaufforderung kann dagegen dieser Code verwendet werden.

:: Setzen des RunAsInvoker in der Eingabeaufforderung
set __COMPAT_LAYER=RunAsInvoker

Happy Skripting und Enjoy it, b!

DxO PureRaw4 Windows Shell-Erweiterungen

Veröffentlicht am April 3, 2024 von b!

Antwort

DxO PureRaw4 ist ein RAW-Konverter, den ich sehr schätze. Was mir an der Version 4 weniger gefällt, ist die tiefe Integration von PureRaw in das Betriebssystem. Ich brauche keine Erweiterungen im Windows Explorer, keinen ständig im Hintergrund laufenden PureRaw-Prozess und auch keinen automatischen Start von PureRaw zusammen mit Windows.

(FUJIFILM, X-E4 mit Carl Zeiss Touit 1.8/32 @32.0mm, 1/180s, f/2.8 und ISO250)

Irgendwie konnte ich in den Einstellungen von PureRaw keine Möglichkeit finden, die obigen Punkte zu konfigurieren.

Der Autostart von PureRaw bedeutet nicht nur, dass sich dort ein Icon in der Taskleiste von Windows logiert, sondern auch, dass Kapazitäten meines Rechners unnötig belegt werden.

Also musste mal wieder die PowerShell für eine Lösung herhalten.

Das Skript muss in einer PowerShell-Sitzung mit erweiterten Rechten (elevated) ausgeführt werden und kann hier heruntergeladen werden.

Eine Prüfung ob PowerShell wirklich mit erweiterten Rechten läuft, erfolgt gleich zu Beginn des Skriptes.

#Requires -RunAsAdministrator

Darüber hinaus will ich noch auf die Verwendung von -LiteralPath hinweisen.

[string]$RegPath = 'HKLM:\SOFTWARE\Classes\*\shellex\ContextMenuHandlers\{7E6AAE52-1F6D-4BCA-A844-CD8273F428CE}'
Remove-Item -LiteralPath $RegPath -Force

Das ist nötig, da in der Variable $RegPath ein * vorhanden ist und die Befehle Get-ChildItem und Remove-Item mehr oder weniger „hängen“ bleibt und mit CTRL+C abgebrochen werden müssen.

Windows | Keine Anmeldung beim Konto möglich

Veröffentlicht am März 22, 2024 von b!

Antwort

Es gibt Fehler, die man sich nicht wünscht, die aber trotzdem passieren.

Eine Mitarbeiterin konnte sich nicht mehr an ihrem PC anmelden und wurde mit folgender Meldung konfrontiert.

Das Abmelden funktionierte und ein Blick in die Eingabeaufforderung zeigte, dass ihr Profil unter C:\Users\<Benutzername> nicht mehr existierte.

Offensichtlich oder wahrscheinlich wurde ihr Profil (aus welchen Gründen auch immer) gelöscht. Der Löschvorgang wurde jedoch nur auf Dateisystemebene durchgeführt. Benutzerprofile sollten immer über den folgenden Dialog gelöscht werden.

Systemeigenschaften / Erweitert/ Benutzerprofile/ Einstellungen …

Alternativ kann zur Automatisierung auch DelProf2 von Helge Klein verwendet werden. Das ist zwar kein offizielles Microsoft-Tool, hat aber bei mir in den letzten 15 Jahren problemlos funktioniert.

Wird das Profil nur im Dateisystem gelöscht, bleibt der entsprechende Eintrag in der Registry erhalten und verhindert das Anlegen eines neuen Profils bei der Anmeldung. Windows legt dann ein temporäres Profil an. Der eigentliche Eintrag, der angelegt werden soll, existiert bereits und hat die Endung .bak

:: Profil-Pfad in der Registry
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Falls dort ein Eintrag mit der Endung .bak vorhanden ist, sollte dieser mit allen Unterverzeichnissen gelöscht werden.

:: Profil-Pfad in der Registry mit der Erweiterung .bak
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-1234567890-1234567890-1234567890-1112.bak

Nach dem Löschen des Eintrages funktioniert die Anmeldung problemlos und das Profil kann neu erstellt und konfiguriert werden. Wohl dem, der seine Ordner entweder mit OneDrive for Business gesichert hat oder den Dateiversionsverlauf nutzt. Wir kennen ja die Neigung der Nutzer alles auf dem Desktop zu speichern

Enjoy it, b!

Adobe Creative Cloud Windows Explorer Erweiterung

Veröffentlicht am Oktober 11, 2023 von b!

Antwort

Für alle, denen die Erweiterung des Windows Explorer um den Ordner “Creative Cloud Files” auf den Sa… geht, hier ein kleines Skript, was den Spuk wieder rückgängig macht.

Das Skript im Kontext des Benutzer ausführen, der die Erweiterung als störend empfindet. Es handelt sich ja um einen Eintrag unter HKEY_CURRENT_USER und damit brauchen wir keine Admin-Berechtigungen.

Enjoy Adobe, b!

Synology L2TP-VPN mit Windows

Veröffentlicht am Oktober 1, 2023 von b!

Antwort

Der Synology VPN Server bietet eine einfache und vor allem kostenlose Möglichkeit gesicherte Zugänge ins lokale Netzwerk herzustellen.

Der größte Vorteil ist, dass auf einem Windows-System keine zusätzliche Software installiert werden muss, es genügen ein oder zwei Einstellungen in der Registry und die Konfiguration des VPN-Tunnels per PowerShell. Vor allem wird die Geschwindigkeit des Windows Systems nicht beeinflusst, wie das zum Beispiel bei einem Lancom Advanced VPN-Client der Fall ist, mit dem sich der Startvorgang von Windows deutlich verlängert.

In diesem Blog geht es um die Einrichtung des VPN unter Windows. Damit der VPN-Server funktioniert, müssen die folgenden Punkte berücksichtigt werden:

Öffentliche IPv4-Adresse des Routers muss über einen DynDNS-Dienst erreichbar sein. Auch wenn eine feste IP-Adresse vom Provider vorhanden ist, empfehle ich deren Maskierung über einen DNS-Namen!
Der VPN-Server muss auf dem Synology NAS installiert und konfiguriert sein
Die Ports 500, 4500 und 1701 müssen für UDP vom Router auf das Synology NAS weitergeleitet werden

Hier der Screenshot einer FRITZ!Box mit den Weiterleitungen für L2TP, auf die interne IP-Adresse des Synology NAS (und damit dem VPN-Server) mit 172.16.16.13

Einmalig zu konfigurierende Einstellungen für das L2TP-VPN unter Windows

Microsoft beschreibt in diesem Artikel, mögliche Werte für die Konfiguration. Nach meiner Erfahrung befinden sich fast immer, sowohl der VPN-Client (also das Windows System) als auch das Synology NAS (und damit der VPN-Server) hinter einer mit NAT umgesetzten Umgebung. Darum habe ich den Wert 2 als Default in meinem Skript verwendet.

Auszuführen ist der Code mit erweiterten Rechten in einer PowerShell-Sitzung (elevated), was aber im Skript ebenfalls abgeprüft wird. Nach dem Setzen des Wertes ist ein Neustart von Windows sinnvoll. Danach können von jedem Benutzer eigene, auf L2TP basierende VPN-Tunnels erstellt werden.

Erstellen eines L2TP basierten VPN-Tunnels

Der VPN-Zugang kann natürlich in den VPN-Einstellungen von Windows “durchgeklickt” werden, vor allem bei mehreren Benutzern und einfacher, ist die Verwendung der PowerShell und des folgenden Skriptes.

Zur Ausführung des Skriptes sind die folgenden Punkte zu beachten.

Das Skript wird im Benutzer-Kontext ausgeführt und ist individuell für jeden Benutzer anzupassen
Dafür sind ist die Variabel $User entweder mit einem Benutzer aus der Domäne zu belegen oder mit einem lokalen Benutzer auf dem Synology NAS. Ist ein AD / Domäne vorhanden, empfiehlt es sich diese zu verwenden, da dann das gleiche Passwort wie zur Anmeldung verwendet werden kann. Darüber hinaus bitte immer nur den Benutzernamen eintragen, die Domäne ist nicht notwendig

Generell sind für alle Benutzer die einen Zugang per VPN erhalten sollen, die folgenden Einstellungen zu treffen:

$ServerAddress = Ein über DNS (DynDNS) auflösbarer Name der vom Provider zugewiesenen IPv4 Adresse, die Konfiguration des DyDns-Providers kann man auf dem Router, dem Synology NAS oder einem anderen Endgerät durchführen
$L2tpPsk = Der im Synology VPN-Server hinterlegte Pre-Shared Key

Der Pre-Shared Key ist auf dem VPN-Server hinterlegt und muss auch in allen Konfigurationen auf den Endgeräten verwendet werden, er ist also immer gleich. Wer bei der Einrichtung einen hinreichend langen Key erstellen will, kann sich der auskommentierten Zeile 13 und PowerShell bedienen.

Damit ist die Konfiguration auch schon fertig, nun stellt sich nur die Frage was tun, wenn der Zugang nicht funktioniert?

Update 01.05.2024

Will man ein L2TP-VPN von einem Apple IOS Device nutzen (iPad Pro), dann darf der Pre-Shared Key nicht länger als 128 Zeichen sein. Thanks Apple for this unnecessary limitation. Sonst klappt die Verbindung nicht!

Das hat übrigens nichts mit diesen Support-Artikel von Apple zu tun. Dieser besagt lediglich, dass die Option Enable SHA-254 compatible mode (96Bit) nicht aktiviert werden darf.

Troubleshooting, Allgemeine Checks (DNS und Ports)

Ein korrekt über das Skript angelegter VPN-Zugang taucht als zusätzlicher WAN Miniport (L2TP) Adapter in den Netzwerkverbindungen auf, konfiguriert man mehrere Zugänge, dann gibt es auch mehrere Netzwerkverbindungen.

Prüfen ob von Windows aus der Synology VPN Server per nslookup auflösbar ist.

Nochmalige Prüfung on die drei UDP-Ports wirklich auf das NAS zeigen und ob auch wirklich UDP und nicht TCP verwendet wurde. Die Portnummern sind, nochmals zur Vollständigkeit 500, 4500 und 1701

Troubleshooting, Fehler 787

Für den Fall, dass der Aufbau des VPNs mit einem Fehler 787 fehlschlägt, ist ebenfalls in einer PowerShell-Sitzung mit erweiterten Rechten der unten stehende Code zur Ausführung zu bringen. Die dort beschriebene Änderung hat Microsoft ebenfalls in einem Artikel dokumentiert.

Bisher musste ich diesen Wert nur 2x setzen, darum habe ich ihn im als Download verfügbaren Skript deaktiviert.

Troubleshooting, die Namensauflösung durch den Tunnel funktioniert nicht

Bei einem aufgebauten VPN-Tunnel funktioniert die Auflösung der dahinter liegenden DNS-Namen nicht. Der Grund dafür ist relativ einfach, Windows verwendet den DNS-Server mit dem Netzwerkadapter mit der kleinsten InterfaceMetric.

Wird nun der VPN-Verbindung die niedrigste InterfaceMetric zugewiesen, dann gehen die Abfragen des DNS durch den Tunnel.

Abfragen und ändern der InterfaceMetric kann man über die folgenden beiden PowerShell-Befehle erreichen.

Damit wird der, auf dem VPN-Server konfigurierte DNS verwendet und eine Verwendung und Abfrage von Namen als FQDN ist möglich.

Die niedrige InterfaceMetric für den VPN-Netzwerkadapter spielt im Betrieb ohne VPN keine Rolle, da dann der Netzwerkadapter deaktiviert ist.

Für und wider dem Synology VPN Server

Der Synology VPN Server hat eine Reihe von Eigenschaften die bekannt sein sollten, bevor man sich für diese Lösung entscheidet.

Es ist nicht möglich ein Site-2-Site VPN zu erstellen, dass behält Synology seinen Routern vor
Die Verwendung von DNS-Splittunneling ist nicht möglich, auch das geht nur mit Synology Routern (oder natürlich alternativen VPN-Lösungen)
Wireguard ist schneller

Warum verwende ich dann trotzdem den Synology VPN Server?

Er ist kostenlos
Windows ist als VPN-Client einfach per PowerShell zu konfiguieren und es muss kein Agent installiert werden. Damit entfallen Updates und es werden Sicherheitsrisiken reduziert

Enjoy it, b!

Synology SMB | Probleme mit Windows Juli-Updates (07/2023) | SecureChannel

Veröffentlicht am Juli 21, 2023 von b!

Mit den Juli-Updates für Windows (10, 11 und Windows Server 2012R2 bis 2022), gibt es Probleme mit der Authentifizierung an einem Synology-NAS. Die sich wie im Folgenden beschrieben, äußern können.

Fehlerbilder (zumindest jene, die mir untergekommen sind)

Windows meldet einen 3210, Netlogon Fehler mit dem Hinweis das die Authentifizierung mit dem “Windows Domain Controller” fehl geschlagen ist. In diesem Falle ist der “Windows Domain Controller” ein Synology NAS mit dem dem Synology Directory Server (Samba)
Die Anmeldung an einem Windows-System über Remote Desktop und konfigurierter NLA, funktioniert nur noch im lokalem Netz aber nicht mehr über das Internet
PowerShell meldet einen Fehler beim Test des SecureChannels zwischen dem Windows System und dem Synology NAS (das durch den Synology Directory Server als Domain Controller arbeitet
Test-ComputerSecureChannel (Rückgabe = False), korrekt wäre hier True

Die Option –Repair funktioniert übrigens auch nicht
Der Zugriff auf Freigaben der Synology-NAS über den FQDN schlägt fehl oder ist nicht stabil

Ein Workaround aber keine Lösung, stellt die Deinstallation des Updates dar.

:: Deinstallation Juli-Update Windows 10 21H2/22H2

wusa /uninstall /kb:5028168

(für andere Windows Betriebssysteme, oben die entsprechende KB-Nummer einsetzen)

Hintergrund

Zum einen verwenden Synology und andere NAS-Hersteller Samba für die Implementierung des Dateidienstes (Fileservices) auf ihren NAS-Geräten. Da wird in der Regel nur angepasst, aber die Basis ist immer Samba. Dort ist das Problem in Form eines Bugs (15418) schon bekannt.

Genau genommen ist das aber kein Bug bzw. Fehler im eigentlichen Sinne, sondern eine noch nicht erfolgte Anpassung an die Strategie von Microsoft die Verwendung des Kerberos-Protokolls in Windows abzusichern. Dieses Ansinnen tut Microsoft aber nicht in dem entsprechenden KB-Artikeln zum Juli-Update kund, sondern erläutert die Roadmap explizit in KB5020805: How to manage Kerberos changes related to CVE-2022-37969

Samba als sagen wir mal Server-Komponente auf den NAS-Systemen, muss das neue verhalten der Windows-Systeme und des Kerberos interpretieren können. Was zumindest bis heute, noch keine offizielle Implementierung im SMB-Packet von Synology zur Folge hatte.

Die Lösung

Im Rahmen eines Support-Calls bei Synology war aber das Problem schon bekannt und man konnte mir mit einem “Private-Fix” des SMB-Services (SMB-Packets) weiterhelfen. Dieses Paket ist inzwischen auch zum Download über die englisch-sprachige Synology-Community erhältlich.

https://community.synology.com/enu/forum/1/post/161649

Ich bitte darum den Artikel dort ausführlich zu lesen und ggf. doch einen Support-Call bei Synology zu öffnen. Einfach aus dem Grund, da es für unterschiedliche DSM-Versionen und Prozessor-Architekturen der NAS-Systeme verschiedene Antworten gibt.

Bei mir hat das bereitgestellte und manuell installierte Paket die Probleme gelöst. Eine positive Rückmeldung an den Support von Synology ist ebenfalls erfolgt und darum hoffe ich, dass ein offizielles Update nicht zulange auf sich warten lässt.

Enjoy it, b!

Windows Remotehilfe | STRG+WIN+Q

Veröffentlicht am Februar 2, 2023 von b!

Antwort

Die in Windows enthaltene Remotehilfe (Quick Assist), scheint eines der am wenigsten bekannten Tools unter Windows zu sein. Schon in das Betriebssystem integriert, bietet sie für Windows 10 (seit Version 1607) und 11 eine einfache Möglichkeit, einem anderen Windows Benutzer zu helfen.

Start und Verwendung der Remotehilfe

Starten lässt sich die Remotehilfe mit der Tastenkombination STRG+WIN+Q oder durch Eingabe von Remotehilfe (oder einfach nur remote) im Startmenü.

Um die Remotehilfe zu verwenden, muss der Benutzer der die Unterstützung gewähren soll ein Microsoft-Konto besitzen, was wiederum bei den meisten Windows Benutzern der Fall sein dürfte.

Lässt sich die Remotehilfe auf dem Windows PC nicht finden, dann kann sie über den Microsoft Store installiert oder aktualisiert werden (was eigentlich automatisch geschehen sollte). Den entsprechenden Artikel dazu liefert Microsoft auf seiner Support-Seite.

Nach dem sich der “Assistent”, der Benutzer der die Unterstützung leisten soll an mit seinem Microsoft-Konto an der Remotehilfe angemeldet hat, erstellt diese einen Code.

Der erstellte Code muss nun an den Hilfesuchenden übermittelt werden. Das kann mündlich per Telefon oder aber durch ein Kopieren des Codes über die Zwischenablage per Mail oder einen installierten Messenger erfolgen. Auf jedem Fall, muss der Code innerhalb von 10min bei der Gegenstelle landen. Danach erfolgt die Generierung eines neuen Codes.

Neben der Möglichkeit die Kontrolle über den Bildschirm zu erlangen besteht auch die Option nur zu schauen und Abläufe auf dem Bildschirm zu verfolgen. Der Assistent fordert eine der beiden Optionen an, dieser muss vom hilfesuchendem Benutzer zugestimmt (zulassen) werden.

Funktionen

Nach dem Aufbau der Verbindung können die folgenden Optionen genutzt werden. Zusätzlich wird auf der Linken seite darauf hingewiesen, ob der Benutzer administrative Rechte besitzt.

Auswahl des Monitors bei mehreren Monitoren
Ein Stift (Pen) um Anmerkungen durchzuführen
Skalierung der Sitzung auf die beim Benutzer eingestellte Größe
Chat zum Austausch von Text
Neustart des Computers
Start des Taskmanager
Pausieren und Beenden der Sitzung

Eine Sitzung mit der Remotehilfe, könnte dann wie folgt aussehen.

Was mit der Remotehilfe nicht geht

Natürlich liegt der Funktionsumfang der Remotehilfe hinter Tools wie Teamviewer zurück. Für die Übertragung von Dateien verwende ich OneDrive oder Mail, eine zentrale Verwaltung ist auch nicht vorhanden und eine unbeaufsichtigter Zugriff ebenfalls nicht möglich.

Es muss ja auch Gründe geben, wieso man für einen vermeindlich besseren Service/Anwendung, Geld bezahlen soll. Was mich zum Ende dieses Artikels bringt.

Mein Fazit, Teamviewer und Co

Teamviewer und diverse Mitbewerber können vieles besser als die Remotehilfe, aber diese kostet nichts und ist im Betriebssystem vorhanden. Für einen Einzelbenutzer kostet Teamviewer aktuell 32,90€ im Monat, was nicht günstig ist, wenn man nur gelegentlich kommerziellen Support leisten will. Dazu kommt ein fetter Teamviewer-Client der erst einmal geladen werden muss.

Wer das aber alles nicht benötigt und nur in der Windows-Welt unterwegs ist, der ist mit der Remotehilfe gut bedient.

Enjoy it, b!

Windows 11 2022 Enterprise Edition | Zugriffsprobleme auf das NAS

Veröffentlicht am November 4, 2022 von b!

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.

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
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 Smile (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!

Fix: Windows 10 und 11 Update und der Essentials Connector

Veröffentlicht am Oktober 3, 2022 von b!

142

Info: Bitte die Update Historie unten lesen, ursprünglich wurde das Script für Windows 10 Version 1903 entwickelt und seitdem immer wieder getestet und aktualisiert. Für alle die nicht lesen wollen, die aktuelle Version des Scripts befindet sich hier. Darüber hinaus funktioniert dieser Workaround ebenfalls mit Windows 11, wenn man ein Windows 10 System über das ISO aktualisiert.

For the english version, please follow this Link.

Zumindest aus Sicht des Windows Server Essentials Connector ist jedes Update von Windows 10 spannend. Die seit gestern offiziell verfügbaren Version 1903 für Windows 10 versäumt es beim Upgrade, die für die Ausführung des Windows Server Essentials Connectors notwendigen Dienste (Services) zu migrieren. Die sind nach dem Update nicht mehr vorhanden.

Damit ist der Windows 10 Client nicht mehr in der Lage sich am Windows Server Essentials an zu melden um seinen Status zu kommunizieren oder eine Sicherung durch zu führen. Im Dashboard des Server erscheint der Client Offline.

Damit das wieder klappt, müssen die Services hergestellt werden. Das geht am einfachsten durch das folgende Script, welches die Services in Form von REG-Dateien in die Registry importiert. Im Anschluss, nach einem Neustart funktioniert der Connector ohne Probleme.

Das Script und die dazu notwendigen REG-Dateien sind in der ZIP Datei als Download verfügbar. Für eventuelle Schäden lehne ich jegliche Haftung ab.

Die Ausführung des Scripts muss in einer PowerShell-Session als Administrator erfolgen
Script und REG-Dateien müssen zwingend im gleichen Verzeichnis liegen
Das Script prüft ob es sich um den Version 1903 oder höher handelt. Nur dann werden die REG-Dateien in die lokale Registry des Windows 10 Clients eingetragen

Möglicher Weise können Probleme mit der PowerShell Execution-Policy auftreten, dazu wende ich den folgenden Workaround an.

Get-Content -Path .\Fix-WSeLaunchpad-1903.ps1 | PowerShell.exe -NoProfile -

Update 30.05.2019

Inzwischen ist es mir gelungen, dass Microsoft dieses Problem als Bug (Fehler) betrachtet und an einem Fix arbeitet. Wie schnell damit zu rechnen ist, kann ich nicht sagen melde mich aber wenn ich weiteres weiß.

Update 15.07.2019

Das Script, und damit der Workaround funktionieren mit dem WSE 2016 und dem WSE 2012R2, dass mag im Blog nicht richtig rüber gekommen sein. Für die anderen Versionen (WSE 2011 und 2012) müsste man die Registry-Einträge des Connectors vergleichen.

Update 21.07.2019

Ich hatte nun die Gelegenheit Windows 10 Clients an einem SBE 2012 (ohne R2) um zu stellen und muss gestehen, dass das Script hier definitiv nicht funktioniert. Der Clientconnector dort verwendet wohl andere Einträge in der Registry als unter Windows Server 2012R2/2016.

Update 18.11.2019

Mit dem Update auf Windows 10 1909 gibt es keine Probleme, dass liegt an der von Microsoft geänderten Bereitstellung. Dazu werden vornehmlich nur Features freigeschaltet, die schon in früheren Versionen vorhanden waren.

Update 11.12.2019

Wird ein ISO mit Windows 10 1909 für einen Upgrade, zum Beispiel von Windows 7 auf Windows 10 verwendet. Schlägt der Bug wieder zu und das bisherige Script funktioniert leider nicht. Darum habe ich eine kleine Änderung durchgeführt und eine Version erstellt (steht nun auch in der History), die mit 1903 und neuer funktioniert.

Update 15.05.2020

Auch mit Windows 10 2004 tritt dieses Problem auf und kann über das Script behoben werden. Ich habe an diesem eine Reihe kleinerer Korrekturen durchgeführt und hier zum Download bereitgestellt.

Update 23.10.2020

Seit dem letzten Jahr, oder denken wir in Updates, seit Windows 10 Version 1909, liefert Microsoft das Herbstupdate als normales Windows Update aus, dass Features die im Verlauf der letzten Monate durch Updates (in 2004) installiert wurden aktiviert. Damit funktioniert das Update auf diesem Weg ohne Probleme und das Script ist nicht notwendig. Erfolgt aber ein Upgrade, zum Beispiel der Version 1909, durch das Windows 10 20H2 ISO, kann das Script im Anschluss den Connector reparieren.

Update 05.06.2021

Mit dem Windows 10 21H1 Update funktioniert das Script in der aktuellen Version ohne Änderungen. Wird das Update über den WSUS oder Windows Update installiert, dann funktioniert der Windows Essentials Connector ohne Probleme und das Script ist nicht notwendig. Erfolgt das Update hingegen über eine ISO Datei, die es als Download bei Microsoft gibt, kann der Essential Connector im Anschuss über das Script repariert werden.

Update 05.10.2021

Heute wurde Windows 11 released und ich habe gleich das Update probiert. Klappt mit den gleichen Problemen wie auch schon unter Windows 10. Genau genommen ist Windows 11 auch nur Windows 10 Build 22000 …

Das Script funktioniert auch hier ohne Probleme, ich habe aber die Ausgaben und Meldungen an das neue Windows angepasst.

Update 13.08.2022 – Notes from the field

Hier ein Hinweis zum Thema Windows 11 Insider-Preview. sbsland-w11-insider-preview

Update 03.10.2022 – Windows 11 22H2

Ob man das Windows 11 22H2 Update nun als sinnvoll betrachtet oder nicht. Microsoft sieht es als die aktuellste Version von Windows 11 und bietet es darum neben dem WSUS auch zum direkten Download per ISO an. Führt man das Update durch, funktioniert der Essentials Connector nicht mehr, erhält aber durch das hier bereitgestellte Script seine Funktion zurück.

Enjoy it,b!

Fix: Windows 10 and 11 Update and Small Business Essentials Connector

Veröffentlicht am Oktober 3, 2022 von b!

Informationen in deutscher Sprache sind unter dem folgenden Link verfügbar.

While this blog is held in German, one article requires an addition written in English language.

For Windows 10 and 11, Microsoft provides every 6 months (since 2022 every year) a major version update to add new features to it’s client operating system.

This update, if done by an ISO or with a package from WSUS may break the Windows Server Small Business Essentials Connector by forgot to migrate the connector services registry keys.

Windows SBE services

While these five services are displayed in the services.msc they are, without corresponding registry keys, no longer functional.

Additionally the Windows 10/11 client seems to offline from Windows SBE dashboard.

Windows 10 clients offline in dashboard

To get the connector back working, I’ve written a script adding the missing registry keys from a PowerShell session. The ZIP-file contains beside the PowerShell code the REG-files containing the missing keys.

To run the script, follow the steps described bellow:

Download the script and extract the content to a dedicated directory
Open a PowerShell session as Administrator and jump to the directory with the PowerShell-script and the REG-files. Note, script and REG-files must live in the same directory
Execute the script by running the following line of PowerShell (to workaround PowerShell Execution-Policies) and don’t miss the “-“ at the end of the script.

# Workaround some obscure PowerShell Execution-policies 😉
# don't miss the "-" at the end of the line!
Get-Content -Path .\Fix-WSeLaunchpad-1903.ps1 | PowerShell.exe -NoProfile -

A successful execution looks, like the following picture shows.

Note: Don’t forget to reboot your Windows 10 client, to make the connector work again.

Update October 3th, 2022

To make it short, Windows 11 22H2 Update also breaks the connector but the script will fix it.

Enjoy it, b!