Archiv der Kategorie: Troubleshooting

DxO PureRaw4 Windows Shell-Erweiterungen

Veröffentlicht am von
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.

Streetphotography

(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.

image

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.

image

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

image

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.
 

M365 | Outlook kann nicht aus einem geteiltem Postfach senden

Veröffentlicht am von
Antwort

Bei einem Kunden sollte der Mail-Verteiler service@domain.de in ein geteiltes Postfach umgestellt werden. Wie inzwischen alle Kunden, war auch dieser in M365 unterwegs. Eigentlich keine große Sache, aber nach der Einrichtung funktionierte das Versenden von Mails aus dem Postfach nicht.

Der Fehler lautet [0x80070005-0x000004dc-0x00000524]

Ein NDR mit der folgenden Meldung wurde dem Absender zugestellt.

image

Ich hatte die Sache getestet, aber nur mit OWA und da hatte es funktioniert, also musste das Problem mit dem auf dem PC installierten Outlook zusammenhängen. Aus Sicht von Outlook hatte sich die Mailadresse service@domain.de nicht geändert, aber in M365 wurde sie gelöscht und über ein freigegebenes Postfach wieder zur Verfügung gestellt. Meine Idee war, dass möglicherweise die Offline-Adressbücher auf den PCs nicht aktuell waren.

Nachdem alle Offline-Adressbücher auf dem PCs gelöscht waren, funktionierten auch die geteilten Postfächer ohne Probleme. Zum Löschen muss Outlook beendet werden, beim Neustart werden die Adressbücher dann automatisch neu geladen.

:: Löschen der Offline-Adressbücher lokal auf dem PC
rd "%userprofile%\AppData\Local\Microsoft\Outlook\Offline Address Books" /s /q

Das geht natürlich bei geschlossenem Outlook auch remote.

image

Beide oben gezeigten Wege zeigen die Holzhammer-Methode, lassen sich dafür aber umso besser automatisieren.

Ein Paar Informationen rund um die Verwendung von geteilten Postfächern liefert Microsoft in diesem Artikel.

Ein weiterer Artikel, falls die Mails in den verteilten Postfächern nicht im Ordner gesendete Elemente landen ist auf WindowsPro zu finden.

Enjoy it, b!

Windows | Keine Anmeldung beim Konto möglich

Veröffentlicht am von
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.

image

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 …

image

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

image

:: 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 Winking smile

Enjoy it, b!

Netzwerkprobleme nach FRITZ!Box Update

Veröffentlicht am von
Antwort

Lässt man eine FRITZ!Box lange genug ohne Update, so erfolgt die Installation oftmals durch den Provider oder die FRITZ!Box selbst. Ist dazu keine Benachrichtigung eingestellt, steht man oft vor ungeahnten Problemen im Netzwerk.

Die FRITZ!Box 7580 bekam so ein Update, genau genommen die Version 07.30 des FRITZ!OS und dabei wurde in den IPv6-Einstellungen des Router Advertisement im LAN wieder aktiviert, welches ursprünglich abgeschaltet war.

image

Was ist danach genau passiert?

  • Die FRITZ!Box propagiert sich als Router und DNS im Netzwerk
  • Alle Windows-Systeme bekommen dadurch zusätzlich einen IPv6-DNS zugewiesen und arbeiten auch vorrangig mit diesem
  • Als erster DNS in der Liste der DNS-Server steht dann die FRITZ!Box mit ihrer IPv6-Adresse
  • Anfragen der Windows-Systeme für das lokale Netz laufen damit ins Leere, da sie an die FRITZ!Box per IPv6 gehen und diese vom lokalen Netzwerk keine oder ungenügend Informationen hat
  • Es kommt zu Problemen beim Zugriff auf SMB-Freigaben und so weiter

Dem Spuk beendet man, indem man den Haken wie unten im Bild wieder raus nimmt.

image

Wenn man die Ursache kennt, ist das Problem schnell gelöst. Ohne kontrollierte Installation von Updates bzw. einer Notifikation, dass es hier ein automatisches Update gegeben hat, stochert man einige Zeit im Dunkeln. Fragt man, ob es in der letzten Zeit irgendwelche Veränderungen gab, so ist die Antwort nein.

Könnte sich AVM endlich dazu durchringen eine bedingte-Weiterleitung (Conditional Forwarder) in die FRITZ!Box einzubauen, könnten alle Anfragen mit *.domain.local von der FRITZ!Box an einen der Domänen-Controller geschickt werden. Eine saubere Konfiguration von IPv6 im LAN ist nicht schwierig und würde in Verbindung mit dem Forwarder die Namensauflösung gegen solche (unter anderem nicht in den Release-Notes) beschriebenen Konfigurationsänderungen (ok, es war mehr ein Rücksetzen) unempfindlich machen.

Andere Hersteller bieten so eine Möglichkeit und eine Reihe weiterer Optionen zur Konfiguration des DNS auf dem Router an.

Möglicher Weise kommt im neuen Jahr noch der eine oder andere “FRITZ!Box-Networking” Blog, da diese Geräte viel häufiger in gewerblichen Umgebungen anzutreffen sind, als man glaubt. Was genau genommen auch nichts ausmacht, wenn man sich der Einschränkungen und Eigenarten bewusst ist.

Ich wünsche Euch ein entspanntes und wenig stressbehaftetes Jahr 2024 in der IT!

Enjoy it, b!

LSA 40970 | Fehlende SPNs im Synology Directory

Veröffentlicht am von
Antwort

Hier geht es nicht nur um den Synology Directory Server, sondern auch um ein Problem in einer Samba-Domain allgemein. Letztendlich basiert der Synology Directory Server auf Samba und damit kann für eine Fehleranalyse und Behebung auf die Informationen im Samba-Wiki zurück gegriffen werden und natürlich auch (mit einer gewissen Vorsicht) die RSAT-Active Directory Tools vom Microsoft zum Einsatz kommen.

Hier noch ein Hinweis in eigener Sache:
Es handelt sich hier um eine Test/Labor-Umgebung, allerdings aus einem Kundenumfeld, darum habe ich die Namen entsprechend ersetzt.

Nach einer Reihe von Reparaturen in der Labor-Domain dslab.local, zeigte ein Computer die folgende Warnung im Ereignissprotokoll.

image

Da die Domain zwei DCs hat, war es kein großes Ding die SPNs beider Systeme miteinander zu vergleichen und tatsächlich fehlten dem nc-nas-11 eine Vielzahl von SPNs, die auf dem nc-ncs-14 zu finden waren.

image

Gegenüber den Einträgen des nc-nas-14 ist das recht spärlich Smile

image

Nachdem die fehlenden SPNs, analog zu den Einträgen des nc-nas-14 mit setspn registriert waren, verschwand auch der LSA 40970 im Ereignisprotokoll.

Enjoy it, b!

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

Veröffentlicht am von
3

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)

  1. 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)


    image

  2. Die Anmeldung an einem Windows-System über Remote Desktop und konfigurierter NLA, funktioniert nur noch im lokalem Netz aber nicht mehr über das Internet

    image

  3. 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

    image
    Die Option –Repair funktioniert übrigens auch nicht

    image

  4. 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!

Bleiben Sie nicht zurück!

Veröffentlicht am von
Antwort

Bitten Sie Ihren Administrator, Microsoft Teams für … zu aktivieren

Gerade mehren sich bei einigen Kunden die Meldungen, dass Microsoft Teams nicht mehr aktiviert wäre.

image

Seltsam bei der Sache ist, dass sich die Deaktivierung aus welchem Grund auch immer automatisch vollzogen hat.

Das Problem lässt sich recht beheben indem man Teams einfach wieder aktiviert.

  • Anmeldung im M365-Portal bei Microsoft https://portal.office.com 
  • Dort nun auf Admin klicken und im nun sich öffnenden Microsoft 365 admin center auf Benutzer / Aktive Benutzer klicken
  • Beim betroffenen Benutzer selbst auf die “drei vertikalen Punkte” und dort auf Produktlizenzen verwalten 

    image
  • Im sich nun auf der rechten Seite öffnenden Menü auf Apps und dort den Haken bei Microsoft Teams (wieder) setzen

    image
  • Natürlich die Änderungen speichern, nicht vergessen

Enjoy it, auch wenn man nicht immer versteht was warum wie passiert.

b!

The file name is too long – Löschen langer Pfade mit der Windows API

Veröffentlicht am von
Antwort

Lange Dateinamen und Pfade sind unter Windows eigentlich kein Thema mehr. Dennoch tauchen sie wie ein schlechter Traum, immer wieder auf und stellen einen vor das Problem, wie kann ich diesen langen Dateinamen oder Pfad nun löschen?

:: der normale Ansatz mit rd und dem Verzeichnis
E:\Shares\Projekte-2018> rd 20-old /s /q

Lieferte wie zu erwarten das folgende Ergebnis, mit einer Menge von nicht gelöschten Verzeichnissen und Dateien.

image

“The file name is too long.”

In diesem Beitrag aus dem Jahr 2011 hatte ich schon mal ein Skript mit Robocopy vorgestellt, welches das Problem bei mir zumindest, immer lösen konnte. Allerdings gab es auch einen Kommentar, der die Funktion des Skriptes nicht bestätigen konnte, zumindest nicht für sein Problem mit NetBeans. Eine genaue Validierung des Problems blieb aber aus.

Nun, knapp 12 Jahre danach habe ich mir, aufgrund einer aktuellen Aufgabenstellung darüber wieder Gedanken gemacht und dazu die Windows API verwendet.

:: der Ansatz mit rd über die Windows API
rd \\?\e:\Shares\Projekte-2018\20-old /s /q

Was wiederum nicht funktioniert hat, und mit dem gleichen Ergebnis “The file name is too long.” endete.

Nun besteht seit Windows 10 Version 1607 (und damit auch für den Windows Server 2016) die Möglichkeit “Enable Long Paths” in der Registry oder per GPO zu aktivieren.

image

Maximum Path Length Limitation – Win32 apps | Microsoft Learn

Die Einstellung hatte ich per GPO und einem entsprechendem gpupdate schon auf den Servern bereitgestellt.

Den Artikel sollte man sorgfältig lesen, denn dort werden Dateiverwaltungsfunktionen aufgelistet, welche nach dem Setzen des Registrierungsschlüssel NICHT mehr der MAX_PATH-Einschränkung unterliegen. Was mich wiederum auf die Idee gebracht hat die Sache mit PowerShell und .Net (Directory Class) zu versuchen.

# PowerShell mit .Net Directory Class
[System.IO.Directory]::Delete("E:\Shares\Projekte-2018\20-old", $true)

Damit der Aufruf funktioniert, muss man zwei Dinge beachten.

  1. Der Verzeichnisname muss vollständig übergeben werden, also nicht 20-old sondern E:\Shares\Projekte-2018\20-old
  2. Die Verzeichnisse sind nicht leer und darum benötigen wir noch ein $true um diese ohne Nachfrage zu löschen

Und den dritten Punkt hätte ich beinahe vergessen, Geduld! Das Löschen von ~500GB hat mehrere Stunden gedauert und kam mit der folgenden Meldung zu einem Ende.image

Es war am Ende eine Datei, die das vollständige Löschen verhindert hat. Auf dieser waren, aus welchem Grund auch immer, die ACL verbogen. Also nochmals icacls, wie in diesem Beitrag beschrieben drüber laufen lassen und der erneute Aufruf von [System.IO …] konnte alle restlichen Artefakte entfernen.

So, eigentlich wollte ich nur ein Verzeichnis löschen …

Enjoy it, b!

SBE: Howto fix Client Computer Backup

Veröffentlicht am von
2

Die Annahme, dass das Laufwerk mit den Client Computer Backups auf dem SBE (Windows Server 2012R2 oder 2016 mit der Small Business Essentials Role) nicht wichtig ist, hat sich in meinem letzten Support-Fall als nicht korrekt herausgestellt.

Die Geschichte hat natürlich einen Anfang. Wird eine hinreichend große Anzahl von Clients (PCs im SBE Netzwerk) gesichert, kann das Laufwerk das den Sicherungsordner Client Computer Backup bereitstellt schon mal auf 1TB anwachsen. Der Kunde (oder dessen Administrator) dachte nun, dass er sich einiges an Platz sparen kann wenn er das Laufwerk nicht sichert und auch nicht in die Hyper-V Replikation mit aufnimmt. Durch einen Defekt der Server-Hardware musste auf einen anderen Hyper-V Host umgeschaltet werden und der SBE “erwachte” aus der Replika ohne sein Client Computer Backups, beziehungsweise ohne das passende Laufwerk.

Gleiches kann natürlich auch passieren, wenn das Laufwerk versehentlich gelöscht wird, oder auf einem anderen Wege kaputt geht.

Die Ausgangssituation

Vollständiger Verlust der Client Computer Backups mit samt des bereitstellenden Laufwerks. Damit werden die Client Computer nicht mehr gesichert und der SBE zeigt eine Reihe von Fehlermeldungen im Dashboard und auch in der Ereignisanzeige.

image

Nun stellt sich die Frage, wie diese Funktionalität wieder hergestellt werden kann und ob sich das überhaupt reparieren lässt?

Die Wiederherstellung der Client Computer Backup Funktionalität

Damit das nochmals klar wird, es geht hier nicht darum die Backups selbst wiederherzustellen, sondern die Funktionalität des SBE.

In einem ersten Schritt wird dem SBE wieder ein passendes Laufwerk bereitgestellt. Das geschieht in virtuellen Umgebungen durch Anhängen einer neuen VHD oder auf einem physikalischen Server durch Einbau einer neuen Platte.

Das neue Laufwerk erscheint unter dem Laufwerksbuchstaben I: und wird mit NTFS formatiert. Nun dachte ich, dass es ausreichen würde die Funktion Repair backups zu verwenden und der Rest passiert dazu im Hintergrund, dass war aber eine falsche Annahme. Es ist nämlich so, dass die Client Computer durch die Installation des Client Connector in die Datenbank des Client Computer Backups eingetragen werden. Die existiert aber nicht mehr und muss darum neu angelegt werden und danach noch die Client Computer zugeordnet werden.

image

Ein Repair now … meldet zwar Erfolg, aber funktionieren tut hinterher das Client Computer Backup nicht.

Eine erfolgreiche Reparatur erfolgt mit den folgenden Schritten:

Bereitstellen eines hinreichend großen Laufwerks, das einen Bezeichner besitzt und mit NTFS formatiert ist.

# Stopping Windows Server Essentials Computer Backup
Stop-Service -Name WseComputerBackupSvc -Force
# Create missing directories
New-Item -Type Directory -Path 'I:\ServerFolders\Client Computer Backups\'
# Starting Windows Server Essentials Computer Backup
Start-Service -Name WseComputerBackupSvc

image

Eigentlich legt der Windows Server Essentials Computer Backup Service beim Start, falls noch nicht vorhanden, seine Datenbank an. Ich habe aber schon gesehen, dass das nicht passiert ist. Darum lohnt sich nochmals das Ausführen einer Reparatur.

image

Nun sollten die drei folgenden Dateien im Verzeichnis vorhanden sein.

image

  • Commit.dat
  • ConsistencyInfo.cc
  • DatabaseInfo.dat

Seitens des Servers ist nun alles eingerichtet, nun müssen wir noch die Clients zurückbringen.

Update 15.03.2023:
Die Integration oder Wiederaufnahme der Clients in das Backup, ist ohne eine Re-Installation des Client Connector möglich.

Wie im Folgenden zu sehen ist, zeigt das Dashboard die Windows Clients im Zustand Unknown.

image

Nun muss das Launchpad des Client Connector auf dem Windows Computer gestartet und die Option Backup ausgewählt werden.

image

Der Backup status am Client erscheint dann wie folgt, aber es wurde ein Verbindung zum SBE hergestellt was zu einer Änderung des Status führt.

image

Das Herstellen der Verbindung über das Launchpad ist ein einfacher Reconnect, der den Backup status von Unknown auf Not set up ändert und im Anschluss die Konfiguration des Backups vom SBE aus ermöglicht.

image

Ab jetzt läuft das Backup wieder, kein Reboot und vor allem auch keine Neuinstallation (des Connectors) waren dafür notwendig.

Ursprünglicher Beitrag:
Das habe ich bisher nur über eine De-Installation und Neu-Installation des Client Connectors hinbekommen. Zwischen den beiden Schritten, ist kein Neustart notwendig. Einfach den Connector deinstallieren und im Anschluss sofort wieder installieren und fertig.

image

Danach läuft das Backup wieder ohne Probleme.

image

Die drei oben genannten Dateien würde ich darum auch in die Datensicherung des SBE aufnehmen.

Enjoy it, b!

Windows 11 2022 Enterprise Edition | Zugriffsprobleme auf das NAS

Veröffentlicht am von
1

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!