Warum eine Windows-Dateifreigabe mal funktioniert und mal nicht — Kerberos, NTLM und Anmeldeinformationen eingrenzen

„Gestern ging es noch.“ „Der Explorer kann es öffnen, die Anwendung nicht.“ „Ein Neustart hat es behoben.“ Probleme mit Dateifreigaben werden schwerer zu untersuchen, wenn die Versuche identisch aussehen.

Selbst wenn Sie glauben, dieselbe Freigabe zu öffnen, führt Windows womöglich andere Vorgänge aus, wenn sich Zielname, ausführendes Konto oder bestehende Verbindungen unterscheiden. Diese Unterschiede zu finden ist der Ausgangspunkt der Untersuchung.

Dieser Diagnoseleitfaden bringt auszuführende Befehle, die Deutung ihrer Ergebnisse und die nächste Untersuchungsstelle zusammen, statt aus dem Symptom allein eine Ursache abzuleiten. Zu den Protokollen selbst siehe NTLM und Kerberos erklärt. Zum Anwendungsentwurf siehe Netzlaufwerke und Fallstricke bei UNC-Pfaden.

1. Hier beginnen: Fazit und Symptomverzeichnis

Untersuchen Sie in dieser Reihenfolge: Ist es erreichbar? → Welche Identität hat sich verbunden? → Welche Authentifizierungs- und Schutzanforderungen gelten? → Darf diese Identität den Vorgang ausführen? Halten Sie diese Bedingungen für erfolgreiche und gescheiterte Versuche im selben Format fest. Ein Symptom ist ein Ausgangspunkt, keine bestätigte Ursache.

flowchart TB
    accTitle: Vom Symptom zum Beleg
    accDescr: Wählen Sie anhand des Symptoms Kandidaten aus, vergleichen Sie Belege aus erfolgreichen und gescheiterten Versuchen und wählen Sie dann eine Korrektur.
    symptom["Das Symptom auswählen"] --> compare["Erfolg und Fehlschlag vergleichen"]
    compare --> evidence["Kandidaten mit Protokollen eingrenzen"]
    evidence --> fix["Eine Sache ändern und erneut testen"]

Abbildung 1: Nutzen Sie Symptome als Einstieg in die Untersuchung und wählen Sie Korrekturen erst nach Prüfung der Belege.

Der Betrachtungsbereich sind SMB-2/3-Freigaben unter Windows 11 und Windows Server über gewöhnliche TCP-445-Verbindungen. Die PowerShell-Beispiele zielen auf Windows PowerShell 5.1. Dies ist ein fortgeschrittener Leitfaden für Administration und Entwicklung, aber auch ohne Serveradministrationszugriff können Sie mit dem Sammeln clientseitiger Informationen beginnen.

Unterscheiden Sie AD-Domänen, Windows-Freigaben in einer Arbeitsgruppe und NAS-eigene Konten. Dieser Artikel behandelt gewöhnliches AD-Kerberos und herkömmliche Konfigurationen mit lokalen Konten; SMB over QUIC, Azure-Files-spezifische Authentifizierung sowie einzelne IAKerb- oder LocalKDC-Konfigurationen liegen außerhalb. Bei DFS halten Sie zusätzlich den endgültigen Zielserver fest. Einstellungen und Standardwerte beruhen auf offizieller Dokumentation, geprüft am 8. September 2026; die tatsächliche Konfiguration hat Vorrang vor Annahmen aus dem Betriebssystemnamen.

Klären Sie zuerst, welche Konten die Freigabe laut Konfiguration annimmt. AD verwaltet Konten für eine Organisation zentral, während lokale Konten zu einzelnen PCs gehören. Ein NAS kann eigene Konten nutzen oder AD beitreten. Schließen Sie nicht aus einem Firmen-LAN auf Kerberos oder aus einem NAS auf NTLM; fragen Sie die Administration nach der Authentifizierungskonfiguration.¹²³

Ob der PC zu einer Domäne gehört und welche Anmeldeinformationen diese Verbindung genutzt hat, sind ebenfalls verschiedene Fragen. In den folgenden Beispielen ist CORP\alice ein Domänenkonto, während FILESRV01\alice ein lokales Konto auf dem Dateiserver ist. Einen gleichnamigen Benutzer auf dem eigenen PC zu haben verleiht diesem Benutzer nicht zwangsläufig dieselben Berechtigungen auf dem Server.⁴⁵

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (19 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Trennen Sie die Stufen, die sich hinter „keine Verbindung“ verbergen

Eine Datei zu öffnen umfasst den Aufbau der Kommunikation, das Aushandeln der SMB-Anforderungen, die Authentifizierung einer Sitzung, die Verbindung zur Freigabe und den Dateivorgang. Eine erfolgreiche Authentifizierung gewährt keinen Zugriff auf Freigabe oder Datei. Eine Meldung, der Netzwerkpfad sei nicht gefunden worden, kann sogar mit abgelehntem Gastzugriff zusammenhängen. Schließen Sie aus dieser Meldung allein nicht auf einen DNS-Fehler.⁶⁷

flowchart TB
    accTitle: Stufen, bevor sich eine freigegebene Datei öffnet
    accDescr: Erreichbarkeit, SMB-Aushandlung, Authentifizierung, Freigabeverbindung und Dateivorgänge können getrennt scheitern.
    net["Namensauflösung und TCP"] --> negotiation["Aushandlung der SMB-Anforderungen"]
    negotiation --> session["SESSION_SETUP: Authentifizierung"]
    session --> tree["TREE_CONNECT: Freigabe"]
    tree --> file["CREATE und andere Dateivorgänge"]

Abbildung 2: Erfolg auf einer Stufe belegt keinen Erfolg auf der nächsten.

Erfolg heißt hier, den beabsichtigten Vorgang an der beabsichtigten Datei auszuführen. Einen PC unter „Netzwerk“ im Explorer zu sehen, eine Freigabeliste zu sehen und eine bestimmte Datei zu lesen sind nicht gleichwertig. Halten Sie den tatsächlich scheiternden UNC-Pfad und Vorgang fest, nicht nur, ob eine Auflistung sichtbar ist.

3. Sammeln Sie Belege, bevor Sie neu starten oder Einstellungen ändern

Verbindungen oder Tickets gleich zu Beginn zu löschen entfernt den Zustand, den Sie vergleichen wollten. Halten Sie zuerst Zeit, UNC-Pfad, Benutzer, Betriebssystem und bestehende Verbindungen auf dem Client fest. Die folgenden Befehle lesen den Zustand. Behandeln Sie bei der Untersuchung eines Dienstfehlers die Ergebnisse aus diesem interaktiven Terminal nicht als Ergebnisse des Dienstes selbst.⁴⁸⁹

Get-Date -Format o
whoami /user
whoami /groups
Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber
net use
cmdkey /list
klist

Erfassen Sie außerdem Folgendes, sofern Sie SMB-Verbindungen abfragen dürfen. Ein Zugriffsverweigerungsergebnis bedeutet „die Abfrage konnte nicht ausgeführt werden“, nicht „es gibt keine Verbindungen“. Kennzeichnen Sie erneut als Administrator gesammelte Ergebnisse mit diesem Ausführungskontext. Die gesamte Untersuchung still zu erhöhen kann die verglichene Anmeldesitzung verändern.⁴¹⁰

Get-SmbConnection | Format-List *

Prüfen Sie bei Get-SmbConnection neben UserName auch Credential. Die lokale Anmeldeidentität und die für die Freigabeverbindung genutzten Anmeldeinformationen können sich unterscheiden. ServerName, ShareName, UserName und Credential über erfolgreiche und gescheiterte Versuche hinweg zu vergleichen hilft festzustellen, ob Sie dieselbe Verbindung vergleichen.⁴

flowchart TB
    accTitle: Gespeicherte Informationen gegenüber aktivem Zustand
    accDescr: Prüfen Sie gespeicherte Anmeldeinformationen, SMB-Verbindungen und Kerberos-Tickets getrennt.
    snapshot["Zur selben Zeit erfassen"] --> stored["Gespeicherte Anmeldeinformationen"]
    snapshot --> connection["Aufgebaute SMB-Verbindungen"]
    snapshot --> ticket["Ticketcache"]
    stored -.-> verify["Tatsächliche Nutzung mit Protokollen abgleichen"]
    connection --> verify
    ticket -.-> verify

Abbildung 3: Unterscheiden Sie, was gespeichert ist, von dem, was die untersuchte Verbindung tatsächlich genutzt hat.

Diese Ausgaben enthalten Benutzernamen, interne Servernamen, IP-Adressen und Ähnliches. Beschränken Sie den Zugriff auf die gesammelten Aufzeichnungen. Anonymisieren Sie sie vor einer Weitergabe nach außen, bewahren Sie dabei aber die für den Vergleich nötigen Zusammenhänge. Kennwörter, Hashes oder die Tickets selbst müssen nicht veröffentlicht werden.

4. Prüfen Sie zuerst Namensauflösung und TCP 445

Das Folgende ist ein aktiver Erreichbarkeitstest auf dem Client. Ersetzen Sie den Servernamen durch den tatsächlichen Verbindungsnamen. Halten Sie Namensauflösung und TCP-Erreichbarkeit getrennt fest.¹¹

$Server = 'filesrv01.corp.example.com'
Resolve-DnsName -Name $Server
Test-NetConnection -ComputerName $Server -Port 445 -InformationLevel Detailed

Ist TcpTestSucceeded gleich False, untersuchen Sie an dieser Stelle die Erreichbarkeit vor der Authentifizierung. Prüfen Sie Ziel-IP, VPN und Routing, Client- und Server-Firewalls sowie den lauschenden Endpunkt des Servers. Ein erfolgreicher oder gescheiterter Ping ist keine erfolgreiche oder gescheiterte TCP-445-Verbindung. Umgekehrt lässt erfolgreiche TCP-Erreichbarkeit Freigabename, Authentifizierung, Signierung und Berechtigungen ungeprüft.¹¹

flowchart TB
    accTitle: Einen TCP-Verbindungstest deuten
    accDescr: Ein gescheiterter TCP-445-Test führt zur Erreichbarkeitsuntersuchung; ein erfolgreicher führt zu SMB und den späteren Stufen.
    tcp["TCP 445 testen"] --> result{"War es erfolgreich?"}
    result -->|"Nein"| route["Ziel, Route, Sperrung prüfen"]
    result -->|"Ja"| smb["SMB, Authentifizierung, Zugriff prüfen"]

Abbildung 4: TCP-Erfolg belegt, dass Sie zur nächsten Stufe übergehen können, nicht dass die Authentifizierung gelungen ist.

Verhalten sich ein Name und eine IP-Adresse unterschiedlich, vergleichen Sie RemoteAddress und die Ergebnisse der Namensauflösung. Kurzname, FQDN und Alias erreichen nicht zwangsläufig dieselbe IP. Selbst wenn doch, bleiben die Authentifizierungsanforderungen des nächsten Abschnitts eine eigene Frage. Scheint das Ändern des Namens das Problem zu beheben, halten Sie fest, was sich geändert hat.

5. Prüfen Sie die Kerberos-Voraussetzungen, wenn Name und IP abweichen

5.1. Dieselbe IP bedeutet nicht dieselbe Authentifizierung

Standardmäßig versucht Windows kein Kerberos, wenn der Zielname eine IP-Adresse ist. Ausnahmen lassen sich mit TryIPSPN und IP-basierten SPNs einrichten, aber das Standardvorgehen in diesem Leitfaden ist, den richtigen DNS-Namen und die richtige Dienstidentität herzustellen. Erfolg mit einer IP-Adresse ist ein Beleg zum Vergleich von Namensauflösung, Authentifizierung und bestehenden Verbindungen; er zeigt keine dauerhafte Lösung.¹²

flowchart TB
    accTitle: Authentifizierungsanforderungen hängen vom Verbindungsnamen ab
    accDescr: Prüfen Sie bei Hostnamenzielen die namensbasierten Kerberos-Anforderungen und berücksichtigen Sie das Standardverhalten, bei IP-Adresszielen kein Kerberos zu versuchen.
    unc["Zielschreibweise im UNC-Pfad"] --> name["Hostname oder FQDN"]
    unc --> ip["IP-Adresse"]
    name --> spn["Den SPN für diesen Namen prüfen"]
    ip --> fallback["Standardmäßig kein Kerberos-Versuch"]

Abbildung 5: Auch wenn zwei Namen dasselbe Gerät bezeichnen, ändert ein anderer Verbindungsname die Authentifizierungsbedingungen.

Kerberos fordert Tickets über eine Dienstkennung namens SPN an. Einen DNS-Alias aufzulösen und den Dienst unter diesem Alias korrekt zu authentifizieren sind verschiedene Dinge. Außerdem führt nicht jeder Kerberos-Fehlschlag zu einem NTLM-Rückfall. Nutzen Sie tatsächliche Protokolle, um zu unterscheiden, ob ein Rückfall möglich ist, ob die Authentifizierung gescheitert ist und ob NTLM eingeschränkt ist.¹³¹

5.2. Trennen Sie Ticketbeschaffung von Serverannahme

In einer AD-Umgebung sollte die Administration die SPN-Registrierung für den zur Verbindung genutzten Namen prüfen. Die folgenden rein lesenden Abfragen sind für einen Verwaltungsrechner gedacht, der AD abfragen kann. Stellen Sie sicher, dass die nötigen Werkzeuge und Verzeichnisleserechte vorhanden sind.¹⁴

setspn -Q cifs/filesrv01.corp.example.com
setspn -Q HOST/filesrv01.corp.example.com

Das Fehlen einer ausdrücklichen cifs/...-Registrierung beweist für sich genommen keinen fehlenden SPN. Bei Computerkonten kann ein HOST-SPN Dienstklassen wie cifs vertreten. Umgekehrt schließt eine gefundene Registrierung Probleme wie den Besitz durch ein anderes als das tatsächliche Dienstkonto oder doppelte Registrierungen nicht aus. AD-Administratoren sollten den Besitz prüfen, bevor sie Registrierungen ändern; fügen Sie keinen SPN mechanisch hinzu, nur weil eine Abfrage nichts gefunden hat.¹⁴

flowchart TB
    accTitle: Was SPN- und Ticketprüfungen belegen
    accDescr: SPN-Auflösung, Ticketbeschaffung und Annahme durch den Dateiserver sind getrennte Prüfungen.
    lookup["SPN-Besitz und HOST-Vertretung"] --> issue["Lässt sich ein Ticket beschaffen?"]
    issue --> accept["Wird es für die tatsächliche SMB-Authentifizierung angenommen?"]
    accept --> logs["Mit serverseitigen Protokollen abgleichen"]

Abbildung 6: Ein Ticket zu beschaffen garantiert nicht, dass der Dateiserver es annimmt.

Nachdem Sie den ursprünglichen Zustand gesichert haben, müssen Sie womöglich klist get cifs/filesrv01.corp.example.com versuchen. Das ist ein aktiver Test, der ein Ticket anfordert und den Cache ändert. Scheitert er, untersuchen Sie DC-Erreichbarkeit, Zeitsynchronisierung, Namen und SPNs. Gelingt er, ist SMB-Zugriff dennoch nicht gewährleistet. Übertragen Sie die Ticketergebnisse eines interaktiven Benutzers nicht auf ein Problem, das in einem Dienst auftritt.⁸¹

Prüfen Sie bei einem NAS ohne Domäne oder bei Authentifizierung mit lokalen Konten zuerst die von der Freigabe unterstützten Authentifizierungsverfahren und Kontoeinstellungen, statt mit AD-SPN-Reparaturen zu beginnen. Ziehen Sie auch in Umgebungen mit neueren Authentifizierungsfunktionen Verbindungsaufzeichnungen Annahmen aus Produktnamen vor.

6. Der Explorer hat Erfolg, die Anwendung scheitert

6.1. Ein übereinstimmender Benutzername genügt nicht

Vergleichen Sie ausführendes Konto, Anmeldesitzung, Rechteerweiterung, UNC-Pfad und Vorgang. Ein Dienst läuft in einer anderen Sitzung als eine interaktive Anmeldung, selbst wenn er mit demselben Benutzerkonto eingerichtet ist. Auch Laufwerkzuordnungen gelten je Anmeldesitzung, unterscheiden Sie also zuerst Z:\data von \\server\share\data. Auf einen UNC-Pfad zu wechseln behebt das Laufwerkbuchstabenproblem; es verleiht nicht zusätzlich Authentifizierung oder Berechtigungen.¹⁰

flowchart TB
    accTitle: Explorer und Dienst nutzen verschiedene Kontexte
    accDescr: Vergleichen Sie auch auf demselben PC interaktive und Dienstanmeldungen als getrennte Sitzungen mit eigenen Anmeldeinformationen.
    pc["Derselbe PC"] --> explorer["Interaktive Anmeldung"]
    pc --> service["Dienstanmeldung"]
    explorer --> a["Verbindungen und Zugriff in dieser Sitzung"]
    service --> b["Verbindungen und Zugriff in einer anderen Sitzung"]

Abbildung 7: Derselbe PC und derselbe Benutzername teilen nicht zwangsläufig denselben Verbindungszustand.

Lassen Sie die scheiternde Anwendung Prozess-ID, ausführende Identität, Rechtestatus, tatsächlichen Pfad, Vorgangsnamen, ursprüngliche Ausnahme und Fehlercode festhalten. Nutzt sie Identitätswechsel, erfassen Sie auch die effektive Identität des ausführenden Threads. Schließen Sie eine Dienstuntersuchung nicht ab, nur weil eine PowerShell-Sitzung einer Administratorin die Freigabe öffnen konnte.

6.2. Dienstkonten und Anmeldetypen von Aufgaben

Nutzt ein Dienst seine Standardanmeldeinformationen, präsentiert LocalSystem im Netzwerk die Anmeldeinformationen des Computers, während LocalService anonyme Anmeldeinformationen präsentiert. Für den LocalSystem-Zugriff auf eine Domänenfreigabe gehören die maßgeblichen Berechtigungen zur tatsächlich genutzten Identität, etwa dem Computerkonto, nicht zum interaktiven Benutzer. Implementierungen mit ausdrücklichen Anmeldeinformationen oder Identitätswechsel erfordern eigene Prüfungen.¹⁵¹⁶

flowchart TB
    accTitle: Lokale Rechte gegenüber der Remote-Identität
    accDescr: Mit Standard-Netzwerkanmeldeinformationen präsentieren LocalSystem und LocalService verschiedene Identitäten.
    service["Standardanmeldeinformationen des Dienstes"] --> system["LocalSystem"]
    service --> local["LocalService"]
    system --> machine["Computeranmeldeinformationen"]
    local --> anonymous["Anonyme Anmeldeinformationen"]

Abbildung 8: Weitreichende lokale Rechte machen den Dienst auf der Remotefreigabe nicht zum interaktiven Benutzer.

Prüfen Sie in der Aufgabenplanung neben dem Kontonamen auch den Anmeldetyp. TASK_LOGON_S4U speichert kein Kennwort und bietet keinen Zugriff auf das Netzwerk oder verschlüsselte Dateien. Nehmen Sie nicht an, dass eine Aufgabe ohne gespeichertes Kennwort dieselben Bedingungen hat wie eine normale interaktive Anmeldung. Richten Sie Geschäftsprozesse mit einem geeigneten Dienstkonto, Anmeldetyp und minimalen Berechtigungen ein, statt darauf zu bauen, dass jemand die Freigabe zuvor im Explorer öffnet.¹⁷

7. Unterscheiden Sie vier Bedeutungen von „kein Kennwort nötig“

Das Ausbleiben einer Abfrage belegt keinen unauthentifizierten Zugriff. Es können die aktuellen Anmeldeinformationen, gespeicherte Anmeldeinformationen oder eine bestehende SMB-Sitzung genutzt werden. Ein Eintrag in cmdkey /list allein belegt nicht, dass die Verbindung ihn genutzt hat.⁴⁹

flowchart TB
    accTitle: Was das Ausbleiben einer Kennwortabfrage bedeutet
    accDescr: Schließen Sie aus der Oberfläche nicht auf unauthentifizierten Zugriff; unterscheiden Sie Anmeldeinformationen, bestehende Sitzung, leeres Kennwort und Gastzugriff.
    prompt["Es erscheint keine Kennwortabfrage"] --> identity["Die tatsächlich angenommene Identität prüfen"]
    identity --> authenticated["Anmeldeinformationen oder bestehende Sitzung"]
    identity --> blank["Konto mit leerem Kennwort"]
    identity --> guest["Gast"]

Abbildung 9: Gleich aussehende Oberflächen können verschiedene Authentifizierungsmechanismen verbergen.

Läuft der Dateiserver unter Windows und ist dessen Richtlinie aktiviert, die lokale Konten mit leerem Kennwort auf die Konsolenanmeldung beschränkt, sind gewöhnliche Netzwerkanmeldungen mit diesen Konten eingeschränkt. Das ist getrennt von der Einstellung, die Gastzugriff erlaubt. Sagt jemand, ein Benutzer mit leerem Kennwort habe sich zuvor verbunden, prüfen Sie zuerst auf dem Server, ob dieses Konto die frühere Verbindung tatsächlich authentifiziert hat. Statt die Einschränkung als erste Reaktion abzuschalten, erwägen Sie ein geeignetes Konto mit Kennwort für den Freigabezugriff.²³

Wenn Sie den Windows-Dateiserver administrieren, führen Sie Folgendes in einer Administrator-PowerShell-Sitzung auf diesem Server aus, während der Zugriff funktioniert. Verwechseln Sie Get-SmbConnection, das auf dem Client läuft, nicht mit Get-SmbSession, das auf dem annehmenden Server läuft.¹⁸

Get-SmbSession |
    Select-Object SessionId, ClientComputerName, ClientUserName, NumOpens

Nutzen Sie ClientComputerName und die Zeit des Versuchs, um die betreffende Sitzung zu finden, und prüfen Sie dann ClientUserName. Das beschreibt derzeit aufgebaute SMB-Sitzungen; es erklärt keine frühere gescheiterte Verbindung und entscheidet nicht, ob Kerberos oder NTLM genutzt wurde. Hat derselbe Client mehrere Sitzungen, gleichen Sie zusätzlich Vorgangszeiten der Anwendung und SMB-spezifische Aufzeichnungen ab. Ist die Verbindung bereits geschlossen, gehen Sie zu den Protokollen in Abschnitt 12.¹⁸

8. Fehler 1219 und Fehlschläge beim Benutzerwechsel

Fehler 1219 zeigt einen Konflikt mehrerer Verbindungen zu demselben Server unter verschiedenen Benutzernamen an. Bestehende Verbindungen zu diesem Server sind auch dann von Belang, wenn die Freigabenamen abweichen. Prüfen Sie zuerst mit net use und Get-SmbConnection die Verbindungen zum Zielserver. Ermitteln Sie vor dem Ändern von Anmeldeinformationen die offenen Dateien und Anwendungen, die diese Verbindungen nutzen.¹⁹²⁰

flowchart TB
    accTitle: Anmeldeinformationen können über verschiedene Freigaben hinweg kollidieren
    accDescr: Aus demselben Verbindungskontext eine weitere Verbindung als anderer Benutzer zu demselben Server aufzubauen kann auch bei abweichendem Freigabenamen kollidieren.
    existing["Bereits als Benutzer A mit dem Server verbunden"] --> new["Als Benutzer B mit einer anderen Freigabe verbinden"]
    new --> conflict["Konflikt der Anmeldeinformationen: 1219"]
    conflict --> inspect["Bestehende Verbindungen je Server prüfen"]

Abbildung 10: Betrachten Sie Server und Anmeldeinformationen gemeinsam, nicht nur den Freigabenamen.

Das Folgende ändert den Verbindungszustand. Trennen und verbinden Sie die ermittelte Verbindung erst neu, nachdem die Nutzung des Ziels eingestellt und die Auswirkung genehmigt ist. Ersetzen Sie die Beispielnamen für Server, Freigabe und Konto. * fordert eine interaktive Kennwortabfrage an; schreiben Sie das Kennwort nicht direkt in die Befehlszeile.⁵

net use "\\filesrv01.corp.example.com\data" /delete
net use "\\filesrv01.corp.example.com\data" /user:CORP\alice * /persistent:no

Eine Freigabe zu trennen kann Verbindungen zu anderen Freigaben oder Nutzungen auf demselben Server bestehen lassen. Prüfen Sie die Liste erneut und lösen Sie nur die nötigen Verbindungen zum Zielserver. Machen Sie weder net use * /delete noch das dauerhafte Umgehen von Konflikten mit Aliasen und IP-Adressen zur Standardlösung. Bestätigen Sie danach, dass die eigentliche Anwendung mit den beabsichtigten Anmeldeinformationen verbindet.

9. Wenn ein Neustart es behebt, fragen Sie, was sich geändert hat

Da ein Neustart mehrere Bedingungen ändert, kann eine Verbesserung allein keine einzelne Ursache benennen. Die folgende Tabelle liefert Vergleichsdimensionen, keine Garantie, dass eine Maßnahme genau und nur den genannten Bereich zurücksetzt.⁴⁸⁹

flowchart TB
    accTitle: Einen erfolgreichen Neustart-Behelf deuten
    accDescr: Ein Neustart ändert mehrere Bedingungen, eine Verbesserung allein kann daher keine Ursache benennen.
    reboot["Ein Neustart stellte den Zugriff wieder her"] --> app["Anwendungszustand"]
    reboot --> session["Verbindungs- und Anmeldezustand"]
    reboot --> network["Netzwerk- und weiterer Zustand"]
    app --> evidence["Belege von vorher und nachher nötig"]
    session --> evidence
    network --> evidence

Abbildung 11: Ein Neustart kann den Betrieb wiederherstellen, ohne die Ursache zu belegen.

Betrachten Sie ein hypothetisches Beispiel, in dem der erfolgreiche Versuch eine SMB-Verbindung unter einem anderen Konto wiederverwendete, während der gescheiterte eine neue Authentifizierung erforderte. Die Untersuchung sollte auf die unbeabsichtigten Anmeldeinformationen und den Grund des Scheiterns der neuen Authentifizierung zielen, nicht auf den Neustart selbst. Zeitstempel, Verbindungsnamen, Ausführungskontexte und angenommene Konten über beide Ausgänge hinweg abzugleichen macht den nächsten Schritt konkret.

Auch wenn ein Neustart zur schnellen Wiederherstellung dringend ist, sichern Sie nach Möglichkeit zuerst die Ausgaben aus Abschnitt 3 und den ursprünglichen Fehler. Versuchen Sie nach dem Neustart denselben Vorgang in der ursprünglichen Anwendung, bevor Sie die Freigabe im Explorer öffnen. Zwischengeschaltete Vorgänge erschweren die Unterscheidung, ob der Neustart den Zugriff wiederhergestellt hat oder ein anderer Vorgang die Verbindungsbedingungen geändert hat. Das ist kein Verbot von Neustarts; es ist ein Aufzeichnungsverfahren, das Wiederherstellung und Diagnose zugleich unterstützt.

klist purge ändert den Zustand, indem es Tickets löscht. Es zielt nicht auf eine Verbindung, die kein Kerberos nutzt, und kann andere Dienste in derselben Anmeldesitzung beeinträchtigen. Vermeiden Sie „einfach mal leeren“, bevor Belege gesichert sind.⁸

10. Fehlschläge nach Updates oder nur auf manchen PCs

10.1. Vermengen Sie Signierung, Gastzugriff und NTLM-Sperrung nicht

Die SMB-Signierung schützt vor Manipulation von Nachrichten; sie ist eine von der Frage, ob per Kerberos oder NTLM authentifiziert wird, getrennte Einstellung. Microsofts eigener Leitfaden zur SMB-Signierung besagt, dass Windows 11 24H2 in den Editionen Pro, Enterprise und Education standardmäßig ein- und ausgehende Signierung verlangt, während Windows Server 2025 ausgehende Signierung verlangt. Prüfen Sie Edition und wirksame Konfiguration, nicht nur den Betriebssystemnamen.⁷

Für Home besagt dieser Leitfaden, dass Signierung nicht verlangt wird, während die Änderungsliste zu Windows 11 24H2 Home unter den Editionen führt, die standardmäßig Signierung verlangen. Die Dokumente weichen also voneinander ab. Statt Signierung unter Home für unerheblich zu halten, prüfen Sie den untersuchten Computer mit den folgenden Befehlen.⁷²¹

flowchart TB
    accTitle: Getrennt zu prüfende SMB-Schutzanforderungen
    accDescr: Authentifizierungsprotokolle, SMB-Signierung und Gastzugriff sind verschiedene Einstellungen, die jeweils geprüft werden müssen.
    policy["Wirksame Richtlinie prüfen"] --> auth["Kerberos- und NTLM-Erlaubnisse"]
    policy --> signing["Anforderung der SMB-Signierung"]
    policy --> guest["Erlaubnis für Gastzugriff"]

Abbildung 12: Eine Einstellung zu prüfen belegt nicht, dass die übrigen Anforderungen erfüllt sind.

Gastzugriff unterstützt weder gewöhnliche SMB-Signierung noch Verschlüsselung. Gäste allein zuzulassen löst das Problem daher womöglich nicht, wenn Signierung weiterhin verlangt wird. Richten Sie auf dem NAS besser authentifizierte Konten und Signierung ein. Behandeln Sie das Abschalten der Signierung oder das Installieren von SMB1 nicht als bequemen Behelf.³

10.2. Lesen Sie die tatsächliche Konfiguration, nicht nur die Standardwerte

Erfassen Sie Folgendes in einer Administrator-PowerShell-Sitzung auf dem Client. Das liest die Konfiguration; unterscheiden Sie es vom Erfassen des Verbindungszustands eines interaktiven Benutzers.⁷²²

$config = Get-SmbClientConfiguration
$config | Format-List RequireSecuritySignature, EnableInsecureGuestLogons
if ($config.PSObject.Properties['BlockNTLM']) {
    $config | Format-List BlockNTLM
} else {
    'Die Eigenschaft BlockNTLM wird auf diesem System nicht bereitgestellt.'
}

RequireSecuritySignature: False bedeutet, dass Signierung nicht verlangt wird; es beweist nicht, dass jede Verbindung unsigniert ist. Fehlt BlockNTLM auf einem älteren System, beweist das nicht das Fehlen anderer NTLM-Einschränkungsrichtlinien. Die NTLM-Sperrung des SMB-Clients steht ab Windows 11 24H2 und Windows Server 2025 zur Verfügung und lässt sich auch für einzelne Freigabeverbindungen angeben. Prüfen Sie neben globalen Einstellungen auch die Verbindungsoptionen der Anwendung und die Organisationsrichtlinien.⁷²²

flowchart TB
    accTitle: Globale Einstellungen bestimmen nicht die gesamte Verbindung
    accDescr: Prüfen Sie neben den Standardwerten des Betriebssystems auch Organisationsrichtlinien, Verbindungsoptionen und Serveranforderungen.
    defaults["Standardwerte von Betriebssystem und Edition"] --> effective["Tatsächliche Verbindungsanforderungen"]
    organization["Organisationsrichtlinie und Verbindungsoptionen"] --> effective
    server["Serverfähigkeiten und -anforderungen"] --> effective
    effective --> log["Protokolle auf den Ablehnungsgrund prüfen"]

Abbildung 13: Ein zeitliches Zusammentreffen mit einem Update ist ein Anhaltspunkt; ziehen Sie den Schluss aus wirksamen Einstellungen und Ablehnungsprotokollen.

NTLM-Abkündigung, die Entfernung von NTLMv1 und eine Richtlinie, die NTLM ablehnt, sind nicht dasselbe Thema. Zur Protokollmigration und organisationsweiten Prüfung siehe Auditierung und Migration zur NTLM-Abschaltung. Konzentrieren Sie sich hier auf die Anforderung, die diese Verbindung abgelehnt hat.

11. Die Authentifizierung gelingt, aber Öffnen oder Speichern scheitert

Prüfen Sie bei einer Windows-Freigabe sowohl die Freigabeberechtigungen als auch die Berechtigungen der zugrunde liegenden Ordner und Dateien. Beide müssen denselben Vorgang für dieselbe Identität erlauben. Prüfen Sie Gruppenmitgliedschaften, Verweigerungseinträge und Vererbung; „Jeder“ hinzuzufügen heißt nicht, dass jeder Zugriff gelingen muss. Prüfen Sie den effektiven Zugriff anhand des tatsächlichen Ablagepfads auf dem Server und der vom Server tatsächlich angenommenen Identität.²³

flowchart TB
    accTitle: Authentifizierung unterscheidet sich von Autorisierung
    accDescr: Auch nach erfolgreicher Authentifizierung müssen Freigabe- und Dateiberechtigungen den angeforderten Vorgang erlauben.
    identity["Authentifizierte Identität"] --> share["Freigabeberechtigungen"]
    share --> file["Berechtigungen der zugrunde liegenden Datei"]
    file --> operation["Den beabsichtigten Vorgang ausführen"]

Abbildung 14: Die Identität festzustellen und zu entscheiden, was diese Identität darf, sind getrennte Schritte.

Einen Ordner aufzulisten, eine Datei zu lesen, zu erstellen, zu überschreiben, umzubenennen und zu löschen sind verschiedene Vorgänge. Bei einer Anwendung, die über eine temporäre Datei speichert und das Original ersetzt, genügt erfolgreiches Lesen nicht. Untersuchen Sie über Authentifizierung und Berechtigungen hinaus mit dem ursprünglichen Fehler auch Freigabeverletzungen, Kapazität, Pfade oder verschwundene Dateien.²⁴

Auch File.Exists in .NET gibt bei Bedingungen wie unzureichenden Berechtigungen false zurück. Prüfen Sie, ob die Meldung „Datei existiert nicht“ der Anwendung allein auf diesem Rückgabewert beruht. Diagnosecode sollte Ausnahmen des Vorgangs festhalten, den Sie tatsächlich ausführen müssen.²⁵

$Path = '\\filesrv01.corp.example.com\data\sample.txt'
try {
    Get-Item -LiteralPath $Path -ErrorAction Stop |
        Select-Object FullName, Length, LastWriteTime
} catch {
    $_.Exception.GetType().FullName
    'HRESULT=0x{0:X8}' -f $_.Exception.HResult
    $_.Exception.Message
}

Das prüft das Abrufen von Metadaten, nicht das erfolgreiche Lesen oder Schreiben der Inhalte. Um tatsächliche E/A zu testen, reproduzieren Sie den beabsichtigten Vorgang an einer Testdatei, nachdem Sie Autorisierung und Auswirkung geprüft haben. Fehler zu bewahren, statt sie alle in „Datei nicht gefunden“ zu verwandeln, erleichtert zudem die nächste Untersuchung.

12. Gleichen Sie Protokolle ab, um die Ursache einzugrenzen

12.1. Unterscheiden Sie Client, Dateiserver und DC

Prüfen Sie auf dem Client in der Ereignisanzeige Microsoft-Windows-SMBClient/Connectivity und Microsoft-Windows-SMBClient/Security. Auf einem Windows-Dateiserver helfen die Sicherheitsereignisse 4624 für erfolgreiche und 4625 für gescheiterte Anmeldung, sofern die Überwachung aktiviert ist. Prüfen Sie bei SMB-Netzwerkanmeldungen den Anmeldetyp 3. Nutzen Sie bei einem NAS dessen produktspezifische Authentifizierungs- und Freigabeprotokolle.²⁶²⁷²⁸

Anmeldetyp 3 in Ereignis 4624 ist nicht SMB-spezifisch. Selbst wenn Zeit, Quelle und Konto übereinstimmen, bestimmt das Ereignis allein keine Freigabe und keine SMB-Sitzung. Gleichen Sie es mit Get-SmbConnection, SMB-spezifischen Protokollen und bei Bedarf einer Ablaufverfolgung ab.²⁷⁴²⁶

flowchart TB
    accTitle: Protokolle von drei Orten abgleichen
    accDescr: Gleichen Sie Client-, Dateiserver- und bei Bedarf DC-Protokolle über Zeit und Verbindungsinformationen ab.
    client["Client: SMBClient-Protokolle"] --> match["Zeit, Quelle und Konto abgleichen"]
    server["Dateiserver: Authentifizierungsprotokolle"] --> match
    dc["DC: Tickets und Prüfung von Anmeldeinformationen"] --> match
    match --> result["Als Beleg für denselben Versuch lesen"]

Abbildung 15: Ohne Übereinstimmung von Ort und Zeit können Sie Protokolle einer unbeteiligten Verbindung für die Ursache halten.

Führen Sie Folgendes auf dem Windows-Dateiserver aus, mit der Berechtigung, das Sicherheitsprotokoll zu lesen. Halten Sie die Zeit unmittelbar vor dem untersuchten Versuch fest und lassen Sie sich von der Administration bestätigen, dass die nötige Erfolgs- und Fehlerüberwachung aktiviert ist. Dieses Beispiel entnimmt die letzten zehn Minuten und nutzt XML-Feldnamen statt lokalisierter Meldungstexte oder Feldpositionen.²⁷²⁸

$Start = (Get-Date).AddMinutes(-10)
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'; Id = 4624, 4625; StartTime = $Start
} -ErrorAction Stop | ForEach-Object {
    $event = $_
    $xml = [xml]$event.ToXml()
    $fields = @{}
    foreach ($item in $xml.Event.EventData.Data) {
        $fields[$item.Name] = [string]$item.'#text'
    }
    if ($fields['LogonType'] -eq '3') {
        [pscustomobject]@{
            Time = $event.TimeCreated
            EventId = $event.Id
            User = $fields['TargetUserName']
            Domain = $fields['TargetDomainName']
            SourceIp = $fields['IpAddress']
            Authentication = $fields['AuthenticationPackageName']
            Status = $fields['Status']
            SubStatus = $fields['SubStatus']
            LogonId = $fields['TargetLogonId']
        }
    }
} | Format-List

Lesen Sie bei 4624 das Zielkonto der neuen Anmeldung, nicht den Subject, der das Ereignis gemeldet hat. Bei 4625 ist der Zielbenutzername der versuchte Name, keine angenommene Identität. Lesen Sie Status und SubStatus gemeinsam als Fehlergrund. Steht in AuthenticationPackageName nur Negotiate, belegt das allein nicht, ob Kerberos oder NTLM genutzt wurde.²⁷²⁸

12.2. Wenn es keine Protokolle gibt oder nur ein Ticket

Kein Ereignis zu finden beweist nicht, dass keine Authentifizierung stattfand. Prüfen Sie Überwachung, Leserechte, Zeitabweichungen, ob Sie den richtigen Server prüfen, die Wiederverwendung einer bestehenden Sitzung und ein Scheitern vor der Authentifizierung. Die Wiederverwendung einer bestehenden SMB-Verbindung erzeugt nicht bei jedem Öffnen einer Datei ein neues 4624.²⁷⁴

flowchart TB
    accTitle: Fehlende Protokollereignisse deuten
    accDescr: Prüfen Sie bei einem fehlenden Ereignis die Erfassungsbedingungen und bestehende Sitzungen, statt sofort zu schließen, es habe keine Authentifizierung gegeben.
    absent["Kein passendes Ereignis"] --> collection["Überwachung, Rechte, Zeit, Ziel"]
    absent --> reuse["Wiederverwendung einer bestehenden Sitzung"]
    absent --> before["Scheitern vor der Authentifizierung"]

Abbildung 16: Eine fehlende Aufzeichnung ist nicht gleichbedeutend damit, dass ein Vorgang nie stattfand.

In AD-Umgebungen hilft das DC-Ereignis 4769, Kerberos-Diensttickets zu erkennen, während 4776 bei der NTLM-Prüfung von Anmeldeinformationen hilft. Die Ausstellung eines Tickets allein beweist weder Nutzung noch Annahme durch den Dateiserver, und 4776 allein bestimmt SMB nicht als Zieldienst. Verbinden Sie Zeit, Quelle, Zielkonto und serverseitige Aufzeichnungen. Bleiben Unklarheiten, lassen Sie die Administration eine eng abgegrenzte Ablaufverfolgung erfassen.²⁹³⁰

13. Prüfen Sie nach der Korrektur den zuverlässigen Betrieb

Wenden Sie eine Korrektur nach der anderen an und bewahren Sie Begründung sowie Belege von vorher und nachher. War der Name falsch, korrigieren Sie Name und Ziel. Wichen die Anmeldeinformationen ab, vereinheitlichen Sie auf das beabsichtigte Konto. Wurde Signierung nicht unterstützt, kümmern Sie sich um die Unterstützung auf dem Server. Schutzfunktionen ohne Verständnis der Ursache gemeinsam abzuschalten ist kein Entwurf für zuverlässigen Betrieb.

flowchart TB
    accTitle: Von einem erfolgreichen Versuch zum Wiederholungstest
    accDescr: Testen Sie nach einer Änderung die ursprünglichen Fehlerbedingungen und die Bedingungen beim erneuten Verbinden.
    evidence["Belege, die die Ursache benennen"] --> change["Eine gezielte Korrektur"]
    change --> original["Ursprüngliche Anwendung und Vorgang testen"]
    original --> reconnect["Nach Neuverbinden oder Neustart erneut testen"]
    reconnect --> record["Unterschiede und Ergebnisse festhalten"]

Abbildung 17: Prüfen Sie den Erfolg unter den ursprünglichen Fehlerbedingungen, nicht nur einen einzelnen erfolgreichen Versuch im Explorer.

Dieser Artikel kann nicht für jede Implementierung und Netzwerkkonfiguration die Ursache eindeutig benennen. Dennoch macht es die nächste Untersuchung konkret, zu wissen, welche Stufe gescheitert ist, welche Bedingungen sich vom Erfolg unterschieden und was ungeprüft bleibt. Bleiben Sie nicht bei „ein Neustart behebt es“ stehen. Prüfen Sie, dass die beabsichtigte Identität über den beabsichtigten Weg verbindet.

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wenn ein Neustart den Zugriff auf eine Dateifreigabe wiederherstellt, beweist das, dass ein Cache das Problem verursacht hat?

Nein. Ein Neustart ändert Anwendung, Anmeldesitzungen, SMB-Verbindungen, Netzwerkzustand und weitere Bedingungen gemeinsam. Halten Sie vor dem Neustart Ziel, ausführende Identität, bestehende Verbindungen, Tickets und Fehler fest und vergleichen Sie sie mit einem erfolgreichen Versuch. Gespeicherte Anmeldeinformationen und aufgebaute SMB-Verbindungen sind verschiedene Dinge.

Warum lässt sich eine Freigabe über die IP-Adresse öffnen, über den Servernamen aber nicht?

Prüfen Sie zuerst, ob beide Formen dieselbe Ziel-IP-Adresse erreichen. Selbst dann unterscheiden sich ihre Authentifizierungsbedingungen: Windows versucht für ein IP-Adressziel standardmäßig kein Kerberos. Untersuchen Sie Namensauflösung getrennt von SPNs und Authentifizierung. Ein Erfolg mit der IP-Adresse allein ist keine dauerhafte Lösung.

Warum kann der Explorer auf eine Freigabe zugreifen, die meine Anwendung nicht erreicht?

Ausführendes Konto, Anmeldesitzung, Rechteerweiterung, Anmeldeinformationen oder angeforderter Vorgang können sich unterscheiden. Ein Dienst läuft in einer anderen Sitzung als eine interaktive Anmeldung. Gleiche Benutzernamen belegen keine gleichwertigen Bedingungen; untersuchen Sie den scheiternden Prozess selbst und die serverseitigen Authentifizierungsaufzeichnungen.

Bedeutet eine Verbindung ohne Kennwortabfrage, dass sie Gastzugriff nutzt?

Das Ausbleiben der Abfrage genügt nicht, um das zu erkennen. Die Verbindung kann die aktuellen Anmeldeinformationen, gespeicherte Anmeldeinformationen oder eine bestehende SMB-Verbindung nutzen. Auch ein lokales Konto mit leerem Kennwort und eine Gastverbindung sind Verschiedenes. Prüfen Sie, welches Konto der Server tatsächlich angenommen hat.

Wenn klist ein cifs-Ticket zeigt, ist SMB dann per Kerberos verbunden?

Ein Ticket zu besitzen und es für die untersuchte SMB-Verbindung zu nutzen sind verschiedene Tatsachen. Gleichen Sie serverseitige Protokolle mit Verbindungszeit, Quelle und Konto ab. klist get fordert ein Ticket an; es ist keine passive Beobachtung des ursprünglichen Zustands.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.