Pourquoi un partage de fichiers Windows fonctionne parfois et échoue à d'autres moments — Diagnostiquer Kerberos, NTLM et les identifiants

« Hier ça marchait. » « L’Explorateur de fichiers peut l’ouvrir, mais pas l’application. » « Un redémarrage a réglé le problème. » Les incidents de partage de fichiers deviennent plus difficiles à examiner quand les tentatives semblent identiques.

Même lorsque vous croyez ouvrir le même partage, Windows peut effectuer des opérations différentes si le nom de destination, le compte d’exécution ou les connexions existantes diffèrent. Trouver ces différences est le point de départ de l’investigation.

Ce guide de diagnostic rassemble les commandes à exécuter, la façon d’interpréter leurs résultats et l’endroit où chercher ensuite, plutôt que d’attribuer une cause à partir du seul symptôme. Pour les protocoles eux-mêmes, voir NTLM et Kerberos expliqués. Pour la conception applicative, voir Lecteurs réseau et pièges des chemins UNC.

1. Commencez ici : conclusion et index des symptômes

Examinez dans cet ordre : Est-ce joignable ? → Quelle identité s’est connectée ? → Quelles exigences d’authentification et de protection s’appliquent ? → Cette identité a-t-elle le droit d’effectuer l’opération ? Consignez ces conditions dans le même format pour les tentatives réussies et échouées. Un symptôme est un point de départ, pas une cause avérée.

flowchart TB
    accTitle: Du symptôme aux preuves
    accDescr: Sélectionnez des pistes à partir du symptôme, comparez les preuves des tentatives réussies et échouées, puis choisissez une correction.
    symptom["Sélectionner le symptôme"] --> compare["Comparer réussite et échec"]
    compare --> evidence["Réduire les pistes avec les journaux"]
    evidence --> fix["Changer une chose et retester"]

Figure 1 : Utilisez les symptômes pour amorcer l’investigation et ne choisissez une correction qu’après avoir examiné les preuves.

Le périmètre couvre les partages SMB 2/3 sous Windows 11 et Windows Server via des connexions TCP 445 ordinaires. Les exemples PowerShell visent Windows PowerShell 5.1. C’est un guide de niveau intermédiaire pour l’administration et le développement, mais des lecteurs sans accès d’administration au serveur peuvent tout de même commencer par collecter les informations côté client.

Distinguez les domaines AD, les partages Windows en groupe de travail et les comptes propres à un NAS. Cet article couvre le Kerberos AD ordinaire et les configurations classiques à comptes locaux ; SMB over QUIC, l’authentification propre à Azure Files et les configurations particulières IAKerb ou LocalKDC en sont exclus. Avec DFS, consignez aussi le serveur cible final. Réglages et valeurs par défaut s’appuient sur la documentation officielle vérifiée le 8 septembre 2026 ; la configuration réelle prime sur les suppositions tirées du nom du système.

Établissez d’abord quels comptes le partage est configuré pour accepter. AD gère les comptes d’une organisation de façon centralisée, tandis que les comptes locaux appartiennent à des PC particuliers. Un NAS peut utiliser ses propres comptes ou rejoindre AD. Ne déduisez pas Kerberos d’un réseau d’entreprise ni NTLM du fait que le serveur soit un NAS ; interrogez l’administrateur sur la configuration d’authentification.¹²³

Que le PC appartienne ou non à un domaine et quels identifiants cette connexion a utilisés sont également deux questions distinctes. Dans les exemples ci-dessous, CORP\alice est un compte de domaine, tandis que FILESRV01\alice est un compte local sur le serveur de fichiers. Avoir un utilisateur du même nom sur votre propre PC ne donne pas nécessairement à cet utilisateur les mêmes autorisations sur le serveur.⁴⁵

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (19 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Séparez les étapes cachées derrière « impossible de se connecter »

Ouvrir un fichier suppose d’établir la communication, de négocier les exigences SMB, d’authentifier une session, de se connecter à un partage et d’effectuer une opération sur un fichier. Une authentification réussie n’accorde pas l’accès au partage ni au fichier. Un message indiquant que le chemin réseau est introuvable peut même être associé à un accès invité refusé. Ne diagnostiquez pas une panne DNS à partir de ce seul message.⁶⁷

flowchart TB
    accTitle: Étapes avant l'ouverture d'un fichier partagé
    accDescr: Joignabilité, négociation SMB, authentification, connexion au partage et opérations de fichier peuvent échouer séparément.
    net["Résolution de noms et TCP"] --> negotiation["Négociation des exigences SMB"]
    negotiation --> session["SESSION_SETUP : authentification"]
    session --> tree["TREE_CONNECT : partage"]
    tree --> file["CREATE et autres opérations de fichier"]

Figure 2 : La réussite d’une étape ne prouve pas la réussite de la suivante.

Ici, réussir signifie effectuer l’opération voulue sur le fichier voulu. Voir un PC sous « Réseau » dans l’Explorateur de fichiers, voir une liste de partages et lire un fichier précis ne sont pas équivalents. Consignez le chemin UNC et l’opération qui échouent réellement, pas seulement si une liste est visible.

3. Collectez les preuves avant de redémarrer ou de modifier des réglages

Supprimer d’emblée des connexions ou des tickets efface l’état que vous vouliez comparer. Consignez d’abord l’heure, le chemin UNC, l’utilisateur, le système et les connexions existantes sur le client. Les commandes suivantes lisent l’état. Lors de l’examen d’un échec dans un service, ne traitez pas les résultats de ce terminal interactif comme des résultats du service lui-même.⁴⁸⁹

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

Collectez également ce qui suit si vous avez le droit d’interroger les connexions SMB. Un résultat d’accès refusé signifie « l’interrogation n’a pas pu être effectuée », non « il n’y a pas de connexions ». Étiquetez tout résultat recollecté en tant qu’administrateur avec ce contexte d’exécution. Élever discrètement toute l’investigation peut modifier la session d’ouverture comparée.⁴¹⁰

Get-SmbConnection | Format-List *

Dans Get-SmbConnection, examinez Credential en plus de UserName. L’identité de la session locale et les identifiants utilisés pour la connexion au partage peuvent différer. Comparer ServerName, ShareName, UserName et Credential entre tentatives réussies et échouées aide à établir que vous comparez bien la même connexion.⁴

flowchart TB
    accTitle: Informations enregistrées contre état actif
    accDescr: Examinez séparément les identifiants enregistrés, les connexions SMB et les tickets Kerberos.
    snapshot["Capturer au même moment"] --> stored["Identifiants enregistrés"]
    snapshot --> connection["Connexions SMB établies"]
    snapshot --> ticket["Cache de tickets"]
    stored -.-> verify["Mettre l'usage réel en regard des journaux"]
    connection --> verify
    ticket -.-> verify

Figure 3 : Distinguez ce qui est enregistré de ce que la connexion examinée a réellement utilisé.

Ces sorties contiennent des noms d’utilisateur, des noms de serveurs internes, des adresses IP et des informations analogues. Restreignez l’accès aux enregistrements collectés. Avant de les partager à l’extérieur, anonymisez-les tout en préservant les correspondances nécessaires à la comparaison. Il n’est pas nécessaire de publier des mots de passe, des empreintes ou les tickets eux-mêmes.

4. Vérifiez d’abord la résolution de noms et TCP 445

Ce qui suit est un test actif de joignabilité exécuté sur le client. Remplacez le nom du serveur par le nom de connexion réel. Consignez séparément la résolution de noms et la joignabilité TCP.¹¹

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

Si TcpTestSucceeded vaut False, examinez à ce stade la joignabilité avant l’authentification. Vérifiez l’IP de destination, le VPN et le routage, les pare-feu client et serveur, ainsi que le point d’écoute du serveur. Un ping réussi ou échoué n’est pas une connexion TCP 445 réussie ou échouée. Inversement, une joignabilité TCP réussie laisse le nom du partage, l’authentification, la signature et les autorisations non vérifiés.¹¹

flowchart TB
    accTitle: Interpréter un test de connexion TCP
    accDescr: Un test TCP 445 échoué conduit à examiner la joignabilité ; un test réussi conduit à SMB et aux étapes suivantes.
    tcp["Tester TCP 445"] --> result{"A-t-il réussi ?"}
    result -->|"Non"| route["Vérifier destination, route, blocage"]
    result -->|"Oui"| smb["Vérifier SMB, authentification, accès"]

Figure 4 : La réussite TCP prouve que vous pouvez passer à l’étape suivante, pas que l’authentification a réussi.

Lorsqu’un nom et une adresse IP se comportent différemment, comparez RemoteAddress et les résultats de la résolution de noms. Nom court, FQDN et alias n’atteignent pas nécessairement la même IP. Même s’ils le font, les exigences d’authentification de la section suivante restent distinctes. Si changer le nom semble régler le problème, consignez ce qui a changé.

5. Vérifiez les prérequis Kerberos quand nom et IP diffèrent

5.1. Une même IP n’implique pas une même authentification

Par défaut, Windows ne tente pas Kerberos lorsque le nom cible est une adresse IP. Des exceptions peuvent être configurées à l’aide de TryIPSPN et de SPN fondés sur l’IP, mais l’approche de référence de ce guide est d’établir le nom DNS et l’identité de service corrects. Réussir avec une adresse IP est une preuve utile pour comparer résolution de noms, authentification et connexions existantes ; ce n’est pas la démonstration d’une correction durable.¹²

flowchart TB
    accTitle: Les exigences d'authentification dépendent du nom de connexion
    accDescr: Vérifiez les exigences Kerberos liées au nom pour les cibles par nom d'hôte et tenez compte du comportement par défaut consistant à ne pas tenter Kerberos pour les cibles par adresse IP.
    unc["Notation de la cible dans le chemin UNC"] --> name["Nom d'hôte ou FQDN"]
    unc --> ip["Adresse IP"]
    name --> spn["Vérifier le SPN de ce nom"]
    ip --> fallback["Aucune tentative Kerberos par défaut"]

Figure 5 : Même lorsque deux noms désignent le même appareil, changer le nom de connexion change les conditions d’authentification.

Kerberos demande des tickets à l’aide d’un identifiant de service appelé SPN. Résoudre un alias DNS et authentifier correctement le service sous cet alias sont deux choses différentes. De plus, tout échec Kerberos n’entraîne pas un repli sur NTLM. Servez-vous des journaux réels pour distinguer si un repli est possible, si l’authentification a échoué et si NTLM est restreint.¹³¹

5.2. Séparez l’obtention d’un ticket de son acceptation par le serveur

Dans un environnement AD, l’administration doit examiner l’enregistrement du SPN pour le nom utilisé lors de la connexion. Les requêtes en lecture seule ci-dessous s’adressent à une machine d’administration capable d’interroger AD. Assurez-vous de disposer des outils nécessaires et des droits de lecture de l’annuaire.¹⁴

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

L’absence d’enregistrement explicite cifs/... ne prouve pas à elle seule qu’un SPN manque. Pour les comptes d’ordinateur, un SPN HOST peut se substituer à des classes de service comme cifs. Inversement, trouver un enregistrement n’écarte pas des problèmes tels que l’appartenance à un compte autre que le compte de service réel ou des enregistrements en double. Les administrateurs AD doivent vérifier l’appartenance avant de modifier des enregistrements ; n’ajoutez pas un SPN machinalement au seul motif qu’une requête n’a rien renvoyé.¹⁴

flowchart TB
    accTitle: Ce qu'établissent les vérifications de SPN et de ticket
    accDescr: La résolution du SPN, l'obtention du ticket et l'acceptation par le serveur de fichiers sont des vérifications distinctes.
    lookup["Propriétaire du SPN et substitution HOST"] --> issue["Un ticket peut-il être obtenu ?"]
    issue --> accept["Est-il accepté pour l'authentification SMB réelle ?"]
    accept --> logs["Mettre en regard des journaux côté serveur"]

Figure 6 : Obtenir un ticket ne garantit pas que le serveur de fichiers l’acceptera.

Après avoir préservé l’état initial, vous devrez peut-être essayer klist get cifs/filesrv01.corp.example.com. C’est un test actif qui demande un ticket et modifie le cache. S’il échoue, examinez la joignabilité du DC, la synchronisation horaire, les noms et les SPN. S’il réussit, l’accès SMB n’est pas pour autant garanti. N’appliquez pas les résultats de tickets d’un utilisateur interactif à un problème survenant dans un service.⁸¹

Pour un NAS sans domaine ou une authentification par comptes locaux, vérifiez d’abord les méthodes d’authentification et les réglages de comptes que le partage prend en charge, plutôt que de commencer par des réparations de SPN AD. Même dans des environnements dotés de fonctions d’authentification récentes, préférez les enregistrements de connexion aux suppositions tirées des noms de produits.

6. L’Explorateur de fichiers réussit, mais l’application échoue

6.1. Un nom d’utilisateur identique ne suffit pas

Comparez le compte d’exécution, la session d’ouverture, l’élévation, le chemin UNC et l’opération. Un service s’exécute dans une session distincte d’une ouverture interactive, même lorsqu’il est configuré avec le même compte utilisateur. Les mappages de lettres de lecteur sont eux aussi limités aux sessions d’ouverture : distinguez donc d’abord Z:\data de \\server\share\data. Passer à un chemin UNC règle le problème de lettre de lecteur ; cela n’accorde pas en plus l’authentification ni les autorisations.¹⁰

flowchart TB
    accTitle: L'Explorateur de fichiers et un service utilisent des contextes différents
    accDescr: Même sur le même PC, comparez les ouvertures interactives et de service comme des sessions distinctes ayant leurs propres identifiants.
    pc["Même PC"] --> explorer["Ouverture interactive"]
    pc --> service["Ouverture de service"]
    explorer --> a["Connexions et accès dans cette session"]
    service --> b["Connexions et accès dans une autre session"]

Figure 7 : Le même PC et le même nom d’utilisateur ne partagent pas nécessairement le même état de connexion.

Faites consigner par l’application défaillante son identifiant de processus, son identité d’exécution, son état d’élévation, le chemin réel, le nom de l’opération, l’exception d’origine et le code d’erreur. Si elle utilise l’emprunt d’identité, capturez aussi l’identité effective du thread effectuant l’opération. Ne clôturez pas une investigation sur un service au seul motif qu’une session PowerShell d’administrateur a pu ouvrir le partage.

6.2. Comptes de service et types d’ouverture des tâches

Lorsqu’un service utilise ses identifiants par défaut, LocalSystem présente sur le réseau les identifiants de l’ordinateur, tandis que LocalService présente des identifiants anonymes. Pour un accès LocalSystem à un partage de domaine, les autorisations qui comptent appartiennent à l’identité réellement utilisée, comme le compte d’ordinateur, et non à l’utilisateur interactif. Les implémentations recourant à des identifiants explicites ou à l’emprunt d’identité exigent leurs propres vérifications.¹⁵¹⁶

flowchart TB
    accTitle: Privilèges locaux contre identité distante
    accDescr: Avec les identifiants réseau par défaut, LocalSystem et LocalService présentent des identités différentes.
    service["Identifiants par défaut du service"] --> system["LocalSystem"]
    service --> local["LocalService"]
    system --> machine["Identifiants de l'ordinateur"]
    local --> anonymous["Identifiants anonymes"]

Figure 8 : De larges privilèges locaux ne font pas du service l’utilisateur interactif sur le partage distant.

Dans le Planificateur de tâches, examinez le type d’ouverture en plus du nom de compte. TASK_LOGON_S4U n’enregistre aucun mot de passe et n’offre aucun accès au réseau ni aux fichiers chiffrés. Ne supposez pas qu’une tâche configurée sans mot de passe enregistré présente les mêmes conditions qu’une ouverture interactive normale. Configurez les traitements métier avec un compte de service adapté, un type d’ouverture approprié et des autorisations minimales, plutôt que de dépendre du fait que quelqu’un ouvre d’abord le partage dans l’Explorateur de fichiers.¹⁷

7. Distinguez quatre sens de « aucun mot de passe requis »

L’absence d’invite ne prouve pas un accès non authentifié. Les identifiants de la session ouverte, des identifiants enregistrés ou une session SMB établie peuvent être en usage. Une entrée dans cmdkey /list n’établit pas à elle seule que la connexion l’a utilisée.⁴⁹

flowchart TB
    accTitle: Ce que signifie l'absence d'invite de mot de passe
    accDescr: Ne déduisez pas de l'interface un accès non authentifié ; distinguez identifiants, session existante, mot de passe vide et accès invité.
    prompt["Aucune invite de mot de passe n'apparaît"] --> identity["Vérifier l'identité réellement acceptée"]
    identity --> authenticated["Identifiants ou session existante"]
    identity --> blank["Compte avec mot de passe vide"]
    identity --> guest["Invité"]

Figure 9 : Des interfaces d’apparence identique peuvent masquer des mécanismes d’authentification différents.

Lorsque le serveur de fichiers tourne sous Windows et que sa stratégie limitant les comptes locaux à mot de passe vide à l’ouverture de session sur la console est activée, les ouvertures de session réseau ordinaires avec ces comptes sont restreintes. C’est distinct du réglage autorisant l’accès invité. Si quelqu’un affirme qu’un utilisateur à mot de passe vide s’est connecté auparavant, vérifiez d’abord sur le serveur si ce compte a réellement authentifié la connexion antérieure. Plutôt que de désactiver la restriction en première réponse, envisagez un compte approprié doté d’un mot de passe pour l’accès au partage.²³

Si vous administrez le serveur de fichiers Windows, exécutez ce qui suit dans une session PowerShell d’administrateur sur ce serveur pendant que l’accès fonctionne. Ne confondez pas Get-SmbConnection, exécuté sur le client, avec Get-SmbSession, exécuté sur le serveur qui accepte la connexion.¹⁸

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

Utilisez ClientComputerName et l’heure de la tentative pour localiser la session concernée, puis examinez ClientUserName. Cela décrit les sessions SMB actuellement établies ; cela n’explique pas une connexion antérieure échouée et ne détermine pas si Kerberos ou NTLM a été utilisé. Si le même client a plusieurs sessions, mettez aussi en regard les heures des opérations de l’application et les enregistrements propres à SMB. Si la connexion est déjà fermée, passez aux journaux de la section 12.¹⁸

8. Erreur 1219 et échecs lors du changement d’utilisateur

L’erreur 1219 signale un conflit impliquant plusieurs connexions au même serveur sous des noms d’utilisateur différents. Les connexions existantes vers ce serveur comptent même quand les noms de partage diffèrent. Utilisez d’abord net use et Get-SmbConnection pour examiner les connexions vers le serveur cible. Avant de changer d’identifiants, repérez les fichiers ouverts et les applications qui utilisent ces connexions.¹⁹²⁰

flowchart TB
    accTitle: Les identifiants peuvent entrer en conflit entre partages différents
    accDescr: Ajouter depuis le même contexte de connexion une connexion sous un autre utilisateur vers le même serveur peut créer un conflit même si le nom du partage diffère.
    existing["Déjà connecté au serveur en tant qu'utilisateur A"] --> new["Se connecter à un autre partage en tant qu'utilisateur B"]
    new --> conflict["Conflit d'identifiants : 1219"]
    conflict --> inspect["Examiner les connexions existantes par serveur"]

Figure 10 : Examinez ensemble le serveur et les identifiants, pas seulement le nom du partage.

Ce qui suit modifie l’état des connexions. Ce n’est qu’après avoir cessé d’utiliser la cible et obtenu l’accord sur l’impact que vous devez déconnecter puis reconnecter la connexion précise que vous avez identifiée. Remplacez les noms d’exemple de serveur, de partage et de compte. * demande une invite de mot de passe interactive ; ne placez pas le mot de passe directement sur la ligne de commande.⁵

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

Déconnecter un partage peut laisser subsister des connexions vers d’autres partages ou usages sur le même serveur. Réexaminez la liste et ne libérez que les connexions nécessaires vers le serveur cible. Ne faites pas de net use * /delete ni du contournement indéfini des conflits par des alias et des adresses IP la correction de référence. Vérifiez ensuite que l’application réelle se connecte avec les identifiants prévus.

9. Quand un redémarrage règle le problème, demandez ce qui a changé

Parce qu’un redémarrage modifie plusieurs conditions, une amélioration à elle seule ne peut pas désigner une cause unique. Le tableau suivant fournit des axes de comparaison, non la garantie qu’une action réinitialise exactement et uniquement le périmètre indiqué.⁴⁸⁹

flowchart TB
    accTitle: Interpréter un contournement par redémarrage qui a réussi
    accDescr: Un redémarrage modifie plusieurs conditions, l'amélioration seule ne peut donc pas désigner une cause.
    reboot["Le redémarrage a rétabli l'accès"] --> app["État de l'application"]
    reboot --> session["État des connexions et des ouvertures de session"]
    reboot --> network["Réseau et autres états"]
    app --> evidence["Preuves avant-après nécessaires"]
    session --> evidence
    network --> evidence

Figure 11 : Un redémarrage peut rétablir le service sans prouver la cause.

Considérez un exemple hypothétique où la tentative réussie réutilisait une connexion SMB sous un autre compte, tandis que la tentative échouée exigeait une nouvelle authentification. L’investigation doit viser les identifiants non prévus et la raison de l’échec de la nouvelle authentification, non le redémarrage lui-même. Aligner horodatages, noms de connexion, contextes d’exécution et comptes acceptés pour les deux issues rend l’étape suivante concrète.

Même lorsque redémarrer est urgent pour rétablir le service, préservez si possible d’abord les sorties de la section 3 et l’erreur d’origine. Après le redémarrage, retentez la même opération dans l’application d’origine avant d’ouvrir le partage dans l’Explorateur de fichiers. Des opérations intercalées rendent plus difficile de distinguer si le redémarrage a rétabli l’accès ou si une autre opération a changé les conditions de connexion. Ce n’est pas une interdiction de redémarrer ; c’est une procédure d’enregistrement qui sert à la fois la remise en service et le diagnostic.

klist purge modifie l’état en supprimant des tickets. Cela ne vise pas une connexion qui n’utilise pas Kerberos et peut affecter d’autres services dans la même session d’ouverture. Évitez le « on vide et on verra » avant d’avoir préservé les preuves.⁸

10. Échecs après des mises à jour ou sur certains PC seulement

10.1. Ne confondez pas signature, accès invité et blocage NTLM

La signature SMB protège contre l’altération des messages ; c’est un réglage distinct de la question de savoir si l’authentification utilise Kerberos ou NTLM. Le guide dédié de Microsoft sur la signature SMB indique que Windows 11 24H2 Pro, Entreprise et Éducation exigent par défaut la signature entrante et sortante, tandis que Windows Server 2025 exige la signature sortante. Vérifiez l’édition et la configuration effective, pas seulement le nom du système.⁷

Pour Famille, ce guide indique que la signature n’est pas exigée, alors que la liste des changements de Windows 11 24H2 inclut Famille parmi les éditions qui l’exigent par défaut. Les documents divergent donc. Plutôt que d’écarter la signature comme non pertinente sous Famille, examinez l’ordinateur concerné à l’aide des commandes ci-dessous.⁷²¹

flowchart TB
    accTitle: Exigences de protection SMB à examiner séparément
    accDescr: Protocoles d'authentification, signature SMB et accès invité sont des réglages différents qui doivent chacun être vérifiés.
    policy["Examiner la stratégie effective"] --> auth["Autorisations Kerberos et NTLM"]
    policy --> signing["Exigence de signature SMB"]
    policy --> guest["Autorisation d'accès invité"]

Figure 12 : Vérifier un réglage n’établit pas que les autres exigences sont satisfaites.

L’accès invité ne prend en charge ni la signature SMB ordinaire ni le chiffrement. Par conséquent, autoriser les invités seul peut ne pas résoudre le problème si la signature reste exigée. Préférez configurer sur le NAS des comptes authentifiés et la signature. Ne traitez pas la désactivation de la signature ou l’installation de SMB1 comme un contournement commode.³

10.2. Lisez la configuration réelle, pas seulement les valeurs par défaut

Collectez ce qui suit dans une session PowerShell d’administrateur sur le client. Cela lit la configuration ; distinguez-le de la capture de l’état des connexions d’un utilisateur interactif.⁷²²

$config = Get-SmbClientConfiguration
$config | Format-List RequireSecuritySignature, EnableInsecureGuestLogons
if ($config.PSObject.Properties['BlockNTLM']) {
    $config | Format-List BlockNTLM
} else {
    'La propriété BlockNTLM n''est pas exposée sur ce système.'
}

RequireSecuritySignature: False signifie que la signature n’est pas exigée ; cela ne prouve pas que toutes les connexions sont non signées. Si BlockNTLM est absent sur un système plus ancien, cela ne prouve pas l’absence d’autres stratégies de restriction NTLM. Le blocage NTLM côté client SMB est disponible à partir de Windows 11 24H2 et de Windows Server 2025, et il peut aussi être précisé pour des connexions de partage individuelles. Examinez les options de connexion de l’application et les stratégies de l’organisation en plus des réglages globaux.⁷²²

flowchart TB
    accTitle: Les réglages globaux ne déterminent pas toute la connexion
    accDescr: Vérifiez les stratégies de l'organisation, les options de connexion et les exigences du serveur en plus des valeurs par défaut du système.
    defaults["Valeurs par défaut du système et de l'édition"] --> effective["Exigences réelles de la connexion"]
    organization["Stratégie d'organisation et options de connexion"] --> effective
    server["Capacités et exigences du serveur"] --> effective
    effective --> log["Chercher la raison du refus dans les journaux"]

Figure 13 : Une coïncidence de calendrier avec une mise à jour est un indice ; concluez à partir des réglages effectifs et des journaux de refus.

L’abandon de NTLM, le retrait de NTLMv1 et une stratégie qui refuse NTLM ne sont pas le même sujet. Pour la migration de protocole et l’audit à l’échelle de l’organisation, voir Audit et migration pour la fin de NTLM. Ici, concentrez-vous sur l’exigence qui a refusé cette connexion.

11. L’authentification réussit, mais l’ouverture ou l’enregistrement échoue

Pour un partage Windows, vérifiez à la fois les autorisations de partage et celles des dossiers et fichiers sous-jacents. Les deux doivent autoriser la même opération pour la même identité. Examinez les appartenances aux groupes, les entrées de refus et l’héritage ; ajouter Tout le monde ne signifie pas que tous les accès doivent réussir. Vérifiez l’accès effectif à partir du chemin de stockage réel sur le serveur et de l’identité réellement acceptée par le serveur.²³

flowchart TB
    accTitle: L'authentification diffère de l'autorisation
    accDescr: Même après une authentification réussie, les autorisations de partage et de fichier doivent toutes deux permettre l'opération demandée.
    identity["Identité authentifiée"] --> share["Autorisations de partage"]
    share --> file["Autorisations du fichier sous-jacent"]
    file --> operation["Effectuer l'opération voulue"]

Figure 14 : Établir l’identité et décider ce que cette identité peut faire sont deux étapes distinctes.

Lister un dossier, lire un fichier, créer, écraser, renommer et supprimer sont des opérations différentes. Pour une application qui enregistre en créant un fichier temporaire puis en remplaçant l’original, une lecture réussie ne suffit pas. Au-delà de l’authentification et des autorisations, examinez à l’aide de l’erreur d’origine les violations de partage, la capacité, les chemins ou les fichiers disparus.²⁴

File.Exists de .NET renvoie également false pour des conditions telles que des autorisations insuffisantes. Vérifiez si le message « le fichier n’existe pas » de l’application se fonde uniquement sur cette valeur de retour. Le code de diagnostic doit consigner les exceptions de l’opération que vous devez réellement effectuer.²⁵

$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
}

Cela vérifie la récupération de métadonnées, pas la lecture ou l’écriture réussie du contenu. Pour tester les E/S réelles, reproduisez l’opération voulue sur un fichier de test après avoir vérifié l’autorisation et l’impact. Préserver les erreurs au lieu de toutes les convertir en « fichier introuvable » facilite aussi l’investigation suivante.

12. Mettez les journaux en regard pour circonscrire la cause

12.1. Distinguez le client, le serveur de fichiers et le DC

Sur le client, examinez Microsoft-Windows-SMBClient/Connectivity et Microsoft-Windows-SMBClient/Security dans l’Observateur d’événements. Sur un serveur de fichiers Windows, les événements de sécurité 4624 pour une ouverture réussie et 4625 pour une ouverture échouée sont utiles lorsque l’audit est activé. Pour les ouvertures de session réseau SMB, vérifiez le type d’ouverture 3. Sur un NAS, utilisez ses journaux d’authentification et de partage propres au produit.²⁶²⁷²⁸

Le type d’ouverture 3 dans l’événement 4624 n’est pas propre à SMB. Même quand l’heure, la source et le compte concordent, l’événement seul n’identifie ni un partage ni une session SMB. Mettez-le en regard de Get-SmbConnection, des journaux propres à SMB et, si nécessaire, d’une trace.²⁷⁴²⁶

flowchart TB
    accTitle: Mettre en regard les journaux de trois emplacements
    accDescr: Mettez en regard les journaux du client, du serveur de fichiers et, si besoin, du DC à l'aide de l'heure et des informations de connexion.
    client["Client : journaux SMBClient"] --> match["Faire concorder heure, source et compte"]
    server["Serveur de fichiers : journaux d'authentification"] --> match
    dc["DC : tickets et validation des identifiants"] --> match
    match --> result["Lire comme preuves d'une même tentative"]

Figure 15 : Sans concordance d’emplacement et d’heure, vous pouvez prendre les journaux d’une connexion sans rapport pour la cause.

Exécutez ce qui suit sur le serveur de fichiers Windows, avec le droit de lire le journal Sécurité. Notez l’heure immédiatement avant la tentative examinée et demandez à l’administrateur de confirmer que l’audit des réussites et des échecs nécessaire est activé. Cet exemple extrait les dix dernières minutes et utilise des noms de champs XML plutôt que des textes de message localisés ou des positions de champs.²⁷²⁸

$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

Pour 4624, lisez le compte cible de la nouvelle ouverture de session, et non le Subject qui a signalé l’événement. Dans 4625, le nom d’utilisateur cible est le nom qui a été tenté, pas une identité acceptée. Lisez Status et SubStatus ensemble pour la raison de l’échec. Si AuthenticationPackageName n’indique que Negotiate, cela n’établit pas à soi seul si Kerberos ou NTLM a été utilisé.²⁷²⁸

12.2. Quand il n’y a pas de journaux, ou seulement un ticket

Ne trouver aucun événement ne prouve pas qu’aucune authentification n’a eu lieu. Vérifiez l’audit, les droits de lecture, les écarts d’horloge, si vous examinez le bon serveur, la réutilisation d’une session existante et un échec antérieur à l’authentification. Réutiliser une connexion SMB existante ne génère pas un nouveau 4624 à chaque ouverture de fichier.²⁷⁴

flowchart TB
    accTitle: Interpréter des événements de journal manquants
    accDescr: Quand un événement manque, vérifiez les conditions de collecte et les sessions existantes plutôt que de conclure aussitôt qu'aucune authentification n'a eu lieu.
    absent["Aucun événement correspondant"] --> collection["Audit, droits, heure, cible"]
    absent --> reuse["Réutilisation d'une session existante"]
    absent --> before["Échec avant l'authentification"]

Figure 16 : Un enregistrement manquant n’équivaut pas à une opération qui n’aurait jamais eu lieu.

Dans les environnements AD, l’événement 4769 du DC aide à repérer les demandes de tickets de service Kerberos, tandis que 4776 aide à repérer la validation d’identifiants NTLM. L’émission d’un ticket ne prouve à elle seule ni son usage ni son acceptation par le serveur de fichiers, et 4776 seul n’identifie pas SMB comme service visé. Combinez heure, source, compte cible et enregistrements côté serveur. S’il subsiste une ambiguïté, faites collecter par un administrateur une trace au périmètre restreint.²⁹³⁰

13. Vérifiez le bon fonctionnement après la correction

Appliquez une correction à la fois et conservez la justification ainsi que les preuves avant-après. Si le nom était erroné, corrigez le nom et la destination. Si les identifiants différaient, uniformisez sur le compte prévu. Si la signature n’était pas prise en charge, traitez sa prise en charge sur le serveur. Désactiver ensemble des fonctions de protection sans comprendre la cause n’est pas une conception pour un fonctionnement fiable.

flowchart TB
    accTitle: D'une tentative réussie au test de récurrence
    accDescr: Après avoir effectué un changement, retestez les conditions d'échec d'origine et les conditions de reconnexion.
    evidence["Preuves identifiant la cause"] --> change["Une correction ciblée"]
    change --> original["Tester l'application et l'opération d'origine"]
    original --> reconnect["Retester après reconnexion ou redémarrage"]
    reconnect --> record["Consigner les différences et les résultats"]

Figure 17 : Vérifiez la réussite dans les conditions d’échec d’origine, pas seulement une tentative réussie dans l’Explorateur de fichiers.

Cet article ne peut pas désigner de façon unique la cause pour toute implémentation et toute configuration réseau. Néanmoins, savoir quelle étape a échoué, quelles conditions différaient de la réussite et ce qui reste non vérifié rend l’investigation suivante concrète. Ne vous arrêtez pas à « un redémarrage règle le problème ». Vérifiez que l’identité prévue se connecte par le chemin prévu.

Liens de référence

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Si un redémarrage rétablit l'accès à un partage de fichiers, cela prouve-t-il qu'un cache était en cause ?

Non. Un redémarrage modifie ensemble l'application, les sessions d'ouverture, les connexions SMB, l'état du réseau et d'autres conditions. Avant de redémarrer, consignez la destination, l'identité d'exécution, les connexions existantes, les tickets et les erreurs, puis comparez-les à une tentative réussie. Les identifiants enregistrés et les connexions SMB établies sont deux choses différentes.

Pourquoi puis-je ouvrir un partage par adresse IP mais pas par nom de serveur ?

Vérifiez d'abord si les deux formes atteignent la même adresse IP de destination. Même dans ce cas, leurs conditions d'authentification diffèrent : Windows ne tente pas Kerberos par défaut pour une cible exprimée en adresse IP. Examinez la résolution de noms séparément des SPN et de l'authentification. Réussir avec une adresse IP n'est pas à soi seul une correction durable.

Pourquoi l'Explorateur de fichiers accède-t-il à un partage que mon application n'atteint pas ?

Le compte d'exécution, la session d'ouverture, l'élévation, les identifiants ou l'opération demandée peuvent différer. Un service s'exécute dans une session distincte d'une ouverture interactive. Des noms d'utilisateur identiques n'établissent pas des conditions équivalentes : examinez le processus qui échoue et les enregistrements d'authentification côté serveur.

Se connecter sans invite de mot de passe signifie-t-il que la connexion utilise l'accès invité ?

L'absence d'invite ne suffit pas à le déterminer. La connexion peut utiliser les identifiants de la session ouverte, des identifiants enregistrés ou une connexion SMB existante. Un compte local sans mot de passe et une connexion invité sont également deux choses différentes. Vérifiez quel compte le serveur a réellement accepté.

Si klist montre un ticket cifs, SMB est-il connecté via Kerberos ?

Détenir un ticket et l'utiliser pour la connexion SMB examinée sont deux faits distincts. Mettez en regard les journaux côté serveur avec l'heure de connexion, la source et le compte. klist get demande un ticket ; ce n'est pas une observation passive de l'état initial.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.