Durcissement SMB : résoudre « Accès refusé » sans réactiver SMB1

Ce que « Accès refusé » signifie réellement (ce n’est pas un seul problème)

SMB est une pile de décisions. « Accès refusé » est le résumé visible par l’utilisateur quand l’une de ces décisions joue contre vous :

• Négociation de protocole : le client et le serveur se mettent d’accord sur les dialectes SMB (SMB2/SMB3) et les capacités (signature, chiffrement, multichannel). S’ils n’y parviennent pas, vous pouvez voir « Accès refusé », « The specified network name is no longer available » ou un comportement de repli silencieux selon le client.
• Authentification : le client prouve son identité via Kerberos, NTLMv2 ou des comptes locaux. Les échecs apparaissent comme accès refusé, demandes de mot de passe ou « Logon failure ».
• Autorisation : une fois authentifié, le jeton est vérifié contre les permissions du partage et les ACL du système de fichiers. C’est le classique « vous êtes bien vous, mais vous n’êtes pas autorisé ».
• Politiques et réglages de durcissement : le serveur exige la signature SMB ; le client ne la réalise pas. Le serveur exige le chiffrement ; le partage n’est pas configuré ; le client est trop ancien. Le domaine interdit NTLM. Tout cela ressemble à un accès refusé parce que le serveur refuse d’aller plus loin.
• Résolution de nom / ciblage SPN : Kerberos est pointilleux. Nom incorrect, alias sans SPN, ou dérive de l’horloge peuvent provoquer un repli d’authentification ou un refus pur et simple.

Voici l’état d’esprit opérationnel utile : « Accès refusé » est un problème de classification. Vous ne « réparez » pas SMB de façon globale. Vous trouvez quelle porte se ferme.

Contexte historique et faits intéressants (court et utile)

1. SMB a commencé à l’époque de DOS comme protocole de partage de fichiers, puis est devenu « CIFS » à l’époque de Windows NT/2000 — même famille, ensembles de capacités différents.
2. SMB2 (Vista/Server 2008) a été une réécriture majeure qui a réduit le bavardage et amélioré les performances sur les liens à forte latence.
3. SMB3 (Windows 8/Server 2012) a introduit le chiffrement au niveau du protocole — pas besoin de VPN pour la confidentialité en transit.
4. La signature SMB existait bien avant que la plupart des organisations ne l’utilisent ; c’est de l’intégrité, pas du chiffrement, et c’est souvent imposé par une politique de domaine pour de bonnes raisons.
5. La campagne « SMB1 est legacy » s’est accélérée après des vers majeurs qui exploitaient les faiblesses de SMB1 et des habitudes de patching laxistes. Les équipes sécurité s’en souviennent ; elles ont une longue mémoire.
6. Le rôle de Samba est la traduction : permissions Unix, sémantique des ACL Windows, mapping d’identité et authentification réseau se rencontrent dans un seul démon. La traduction est là où naissent bugs et mauvaises configurations.
7. « Accès refusé » peut être une posture de sécurité délibérée : le durcissement moderne préfère fermer l’accès quand la politique ne correspond pas (par ex. refuser NTLM) plutôt que de rétrograder silencieusement.
8. Kerberos est sensible au temps par conception ; quelques minutes de dérive d’horloge peuvent transformer un partage sain en usine à « Accès refusé ».

Playbook de diagnostic rapide (premier/deuxième/troisième)

Premier : s’agit-il d’authentification, d’autorisation ou de négociation de protocole ?

• Essayez d’énumérer les partages anonymement puis authentifié : si l’anonyme échoue mais l’authentification réussit, vous avez un changement de politique invité (souvent voulu). Si l’auth échoue, c’est l’identité ou la politique. Si l’énumération fonctionne mais l’ouverture d’un dossier échoue, c’est l’autorisation (permission du partage vs ACL du système de fichiers).
• Vérifiez le dialecte et l’état de la signature : si le client négocie SMB1 ou n’arrive pas à négocier SMB2/3, vous êtes face à un problème de compatibilité/politique, pas de « permissions ».

Deuxième : validez le mapping d’identité et l’appartenance aux groupes

• Sur des serveurs membres AD/Samba : si l’utilisateur est mappé sur « nobody » ou un UID/GID inattendu, les contrôles du système de fichiers vont refuser même si les permissions du partage semblent correctes.
• Sur des clients Windows : les identifiants mis en cache et les sessions « mauvais utilisateur » sont fréquents. Une connexion obsolète peut empoisonner toutes les tentatives vers le même nom de serveur.

Troisième : vérifiez les incompatibilités de politique (restrictions NTLM, signature, chiffrement)

• Domaine interdit NTLM : un client Linux utilisant NTLM sera refusé jusqu’à ce que vous le basculiez sur Kerberos (ou que vous ajustiez la politique, ce qui n’est probablement pas souhaitable).
• Signature requise : les clients plus anciens ou les montages mal configurés échouent.
• Chiffrement requis : le client doit supporter le chiffrement SMB3 et le négocier.

Idée paraphrasée, attribuée : Werner Vogels a dit que l’on construit des systèmes fiables en supposant que les choses échouent et en les concevant pour cela. Traitez l’auth et la politique SMB comme un domaine de défaillance que vous pouvez instrumenter, pas comme une poignée mystique.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les vérifications que j’exécute quand quelqu’un signale « SMB access denied » et attend un miracle. Chaque tâche inclut : la commande, un exemple de sortie et la décision qu’elle entraîne.

Task 1: Confirm the server is actually listening on 445

cr0x@server:~$ sudo ss -lntp | egrep ':445|:139'
LISTEN 0      128          0.0.0.0:445        0.0.0.0:*    users:(("smbd",pid=1223,fd=52))
LISTEN 0      128             [::]:445           [::]:*    users:(("smbd",pid=1223,fd=54))

Ce que cela signifie : SMB est joignable au niveau TCP. Si vous ne voyez pas 445, ce n’est pas encore un problème de permissions.

Décision : Si 445 n’écoute pas, réparez le service (smbd non démarré, lié à la mauvaise interface, réseau de conteneur) avant de toucher aux ACL.

Task 2: Check firewall rules for 445/tcp

cr0x@server:~$ sudo nft list ruleset | sed -n '1,140p'
table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 accept
    tcp dport 445 ip saddr 10.20.0.0/16 accept
  }
}

Ce que cela signifie : Seul 10.20.0.0/16 peut atteindre SMB. Tous les autres échoueront de façon intéressante.

Décision : Si les clients sont hors de ce CIDR, corrigez la politique réseau. Ne « debuggez SMB » pas pendant que des paquets sont intentionnellement bloqués.

Task 3: See which SMB dialects Samba will negotiate

cr0x@server:~$ testparm -sv 2>/dev/null | egrep -i 'server min protocol|server max protocol'
	server min protocol = SMB2_10
	server max protocol = SMB3_11

Ce que cela signifie : SMB1 est déjà désactivé. Bien. Cela fixe aussi les attentes pour les clients plus anciens.

Décision : Si vous voyez SMB1 autorisé, resserrez-le. Si un client critique d’héritage ne supporte pas SMB2, migrez le client ; ne baissez pas la sécurité du serveur.

Task 4: Validate share definition and effective browseability

cr0x@server:~$ testparm -s 2>/dev/null
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)

Server role: ROLE_MEMBER_SERVER

[global]
	workgroup = EXAMPLE
	security = ADS

[finance]
	path = /srv/samba/finance
	read only = No

Ce que cela signifie : Le partage existe et pointe vers un emplacement réel (nous le vérifierons ensuite). « Weak crypto allowed » n’est pas un crime, mais c’est un indice sur les modes d’authentification en jeu.

Décision : Si le partage n’existe pas ou pointe vers le mauvais chemin, corrigez-le. Si le mode de sécurité n’est pas celui attendu (ADS vs user), arrêtez-vous et revérifiez la conception.

Task 5: Verify filesystem path, ownership, and mode bits

cr0x@server:~$ sudo ls -ld /srv/samba/finance
drwxrwx--- 3 root "EXAMPLE\\finance-rw" 4096 Jan 12 09:40 /srv/samba/finance

Ce que cela signifie : Les bits de mode permettent l’accès au groupe, mais seulement si le mapping d’identité place les utilisateurs dans ce groupe.

Décision : Si les permissions sont 700 ou appartenant au mauvais groupe, vous aurez un accès refusé même avec « valid users » correctement réglé. Corrigez d’abord les permissions POSIX ou les ACL.

Task 6: Check SELinux/AppArmor blocking (the silent bouncer)

cr0x@server:~$ sudo getenforce
Enforcing

cr0x@server:~$ sudo ausearch -m avc -ts recent | tail -n 5
type=AVC msg=audit(1739201151.441:812): avc:  denied  { read } for  pid=1223 comm="smbd" name="finance" dev="sda2" ino=393220 scontext=system_u:system_r:smbd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir permissive=0

Ce que cela signifie : Le noyau refuse smbd indépendamment de votre configuration Samba. Cela ressemble souvent à un problème de permissions mais ça n’en est pas un.

Décision : Corrigez le étiquetage (par ex. définissez le contexte approprié) au lieu d’élargir les permissions du partage.

Task 7: Prove identity mapping works (AD user → UID/GID)

cr0x@server:~$ id "EXAMPLE\\alice"
uid=220110(EXAMPLE\alice) gid=220051(EXAMPLE\domain users) groups=220051(EXAMPLE\domain users),220220(EXAMPLE\finance-rw)

Ce que cela signifie : L’utilisateur se résout et appartient au groupe attendu.

Décision : Si id échoue ou que des groupes manquent, corrigez winbind/sssd/idmap avant de toucher aux ACL. Des IDs incorrects équivalent à de mauvaises décisions d’accès.

Task 8: Confirm the server can talk to AD and sees the domain

cr0x@server:~$ wbinfo -t
checking the trust secret for domain EXAMPLE via RPC calls succeeded

Ce que cela signifie : L’adhésion est suffisamment saine pour RPC trust. Ce n’est pas une garantie, mais une bonne base.

Décision : Si cela échoue, « Accès refusé » peut venir du serveur qui n’arrive pas à valider les identifiants. Corrigez l’adhésion au domaine, le DNS, l’heure et les keytabs.

Task 9: Check Kerberos health and time (the boring culprit)

cr0x@server:~$ timedatectl | sed -n '1,8p'
Local time: Wed 2026-02-05 14:31:10 UTC
Universal time: Wed 2026-02-05 14:31:10 UTC
RTC time: Wed 2026-02-05 14:31:10
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active

cr0x@server:~$ kinit alice@EXAMPLE.COM
Password for alice@EXAMPLE.COM:

cr0x@server:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: alice@EXAMPLE.COM

Valid starting     Expires            Service principal
02/05/26 14:31:25  02/06/26 00:31:25  krbtgt/EXAMPLE.COM@EXAMPLE.COM

Ce que cela signifie : L’heure est synchronisée et Kerberos fonctionne. Si l’heure est déréglée, Kerberos échoue et les clients basculent en repli — ou échouent — selon la politique.

Décision : Si NTP n’est pas actif ou si kinit échoue, corrigez le temps/DNS/accessibilité KDC. Ne commencez pas à relaxer les politiques NTLM comme solution de contournement.

Task 10: Reproduce from the server side with smbclient (cuts out Windows UX)

cr0x@server:~$ smbclient -m SMB3 -L //files01 -U 'EXAMPLE\alice'
Password for [EXAMPLE\alice]:
	Sharename       Type      Comment
	---------       ----      -------
	finance         Disk
	IPC$            IPC       IPC Service (Samba)
SMB1 disabled -- no workgroup available

Ce que cela signifie : L’utilisateur peut énumérer les partages via SMB3. La ligne « SMB1 disabled » est informative et normale.

Décision : Si l’énumération échoue avec NT_STATUS_ACCESS_DENIED, c’est auth/politique. Si l’énumération fonctionne mais que les opérations sur fichiers échouent, c’est les ACL ou les modules VFS.

Task 11: Attempt access to the share and a file operation

cr0x@server:~$ smbclient -m SMB3 //files01/finance -U 'EXAMPLE\alice' -c 'ls; mkdir _diag_test; rmdir _diag_test'
Password for [EXAMPLE\alice]:
  .                                   D        0  Wed Feb  5 14:22:01 2026
  ..                                  D        0  Wed Feb  5 13:59:11 2026
  budgets                             D        0  Tue Feb  4 18:04:41 2026

Ce que cela signifie : L’affichage du répertoire et la création/suppression ont réussi. Ce n’est pas un problème d’autorisation pour cet utilisateur.

Décision : Si mkdir échoue avec ACCESS_DENIED, inspectez « write list » au niveau du partage et les ACL du système de fichiers ; si ls échoue, inspectez la permission execute/search sur les répertoires.

Task 12: Inspect Samba logs for the real reason (not the Windows dialog)

cr0x@server:~$ sudo tail -n 30 /var/log/samba/log.smbd
[2026/02/05 14:24:33.112233,  1] smbd/service.c:1234(make_connection_snum)
  create_connection_session_info: guest user (from session setup) not permitted to access this share (finance)
[2026/02/05 14:24:33.112544,  1] smbd/service.c:987(make_connection_snum)
  files01 (ipv4:10.20.5.44:51022) connect to service finance initially as user nobody (uid=65534, gid=65534) (pid 1422)

Ce que cela signifie : Le client arrive en tant que guest/nobody. Voilà pourquoi l’accès est refusé — même si « alice » a tapé un mot de passe quelque part.

Décision : Corrigez la négociation d’auth (NTLM/Kerberos), le gestionnaire d’identifiants Windows, ou le comportement Samba « map to guest ». N’élargissez pas les ACL pour laisser « nobody » entrer.

Task 13: Detect “map to guest” and guest access settings

cr0x@server:~$ testparm -sv 2>/dev/null | egrep -i 'map to guest|guest ok|restrict anonymous'
	map to guest = Bad User
	restrict anonymous = 2

Ce que cela signifie : Les utilisateurs inconnus sont mappés sur guest. Combiné avec « restrict anonymous », cela peut donner des refus déroutants.

Décision : Dans les environnements durcis, préférez échouer l’authentification plutôt que de mapper sur guest. Envisagez map to guest = Never sauf cas d’usage invité spécifique et contrôlé.

Task 14: Check Windows has a stale session to the server under a different user

cr0x@server:~$ smbstatus -b
Samba version 4.18.6
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
--------------------------------------------------------------------------------------------------------------------------------------------
2311    bob          domain users  10.20.5.44 (ipv4:10.20.5.44:51210)        SMB3_11           -                    partial(AES-128-CMAC)

Ce que cela signifie : Ce client a déjà une session SMB en tant que bob. Windows réutilise souvent des sessions par nom de serveur, d’où « Accès refusé » quand vous attendiez alice.

Décision : Côté client, déconnectez les mappings existants et reconnectez-vous avec l’identité voulue. Serveur-side, ne « corrigez » pas les permissions pour le mauvais utilisateur.

Task 15: Validate share-level access controls (“valid users”, “write list”)

cr0x@server:~$ grep -nE '^\[finance\]|valid users|write list|read only' /etc/samba/smb.conf
42:[finance]
45:	valid users = @EXAMPLE\finance-rw
46:	read only = no

Ce que cela signifie : Seuls les membres du groupe finance-rw peuvent se connecter. C’est raisonnable. Mais la résolution de groupe doit fonctionner.

Décision : Si vous voyez une faute de frappe dans le nom de groupe, ou un préfixe de domaine erroné, corrigez-le. Si vous voulez un accès lecture seule pour d’autres, créez un groupe séparé et spécifiez-le explicitement — ne comptez pas sur l’appartenance générale à « Domain Users ».

Task 16: Check whether SMB signing is required and what the server is doing

cr0x@server:~$ testparm -sv 2>/dev/null | egrep -i 'server signing|client signing'
	server signing = mandatory
	client signing = mandatory

Ce que cela signifie : Ce serveur exige des paquets SMB signés. Certains clients/options de montage ne s’en accommodent pas, et ils échoueront de façons ressemblant à des problèmes d’accès.

Décision : Gardez la signature obligatoire dans la plupart des réseaux d’entreprise. Si un client ne supporte pas la signature SMB, le problème vient du client. Mettez-le à niveau ou isolez-le.

Petite plaisanterie #1 : SMB1, c’est comme un téléphone à clapet : nostalgique, étonnamment robuste, et absolument pas ce que vous voulez pour protéger la paie.

Durcissement sans casser l’accès

Arrêtez de considérer SMB1 comme béquille de compatibilité

Réactiver SMB1 pour « réparer l’accès » masque généralement l’un de ces points :

• Un appareil ancien ne supporte que SMB1 (les multifonctions sont souvent concernés).
• Le client est mal configuré pour SMB2/3 (mauvaises options de montage, DNS cassé, mauvais nom d’hôte).
• Incompatibilité de politique d’auth (restrictions NTLM, Kerberos échouant à cause du temps ou du SPN).

SMB1 cache le problème sous-jacent en changeant le chemin de négociation. Ce n’est pas résoudre ; c’est détourner l’alarme vers un autre haut-parleur.

Utilisez SMB2/3 délibérément : dialectes, signature, chiffrement

Durcir SMB n’est pas « activer tous les boutons ». C’est choisir les bons boutons selon votre modèle de menace et votre parc client.

• Dialects : Définissez server min protocol = SMB2_10 (ou plus élevé). SMB2_10 est un plancher pragmatique pour Windows moderne et la plupart des clients Linux.
• Signature : Gardez server signing = mandatory sur les serveurs membres dans des environnements de domaine, sauf raison mesurée de performance. La signature empêche la falsification. Elle empêche aussi certains jeux de rétrogradation.
• Chiffrement : Utilisez le chiffrement SMB3 pour les partages qui traversent des réseaux non fiables ou contiennent des données sensibles. Mais comprenez les coûts opérationnels : surcharge CPU, complexité de dépannage et compatibilité client.

Rendez l’autorisation sans surprise : ACLs du partage + ACLs système + mapping d’identité

La façon la plus rapide de générer des tickets « Accès refusé » est de laisser les permissions du partage et les ACL du système de fichiers diverger. Choisissez un modèle :

• Modèle A (recommandé) : Utilisez les groupes AD comme source de vérité. Contrôlez l’accès au partage avec valid users et appliquez sur disque avec des ACL. Gardez les bits POSIX minimaux mais non trompeurs.
• Modèle B : Utilisez des groupes POSIX locaux (pas AD) et mappez-les soigneusement. Ça fonctionne, mais il est facile de dériver entre serveurs.

Dans Samba, la couche de « traduction » est le mapping d’identité. Si idmap est instable, vous verrez des utilisateurs perdre l’accès au hasard après des reboots, mises à jour ou changements de domaine.

Ne cassez pas Kerberos avec des alias

Les tickets Kerberos sont émis pour des principals de service. Si les utilisateurs se connectent à \\files-alias\share mais que vos SPN couvrent seulement files01, les clients peuvent retomber sur NTLM ou échouer si NTLM est bloqué. Cela peut apparaître comme « Accès refusé » alors que le mot de passe est correct.

Gardez l’accès invité explicite, pas accidentel

L’accès invité est soit un besoin produit délibéré soit une mauvaise configuration. Il n’y a pas beaucoup de zone grise. La version dangereuse est « c’est invité parce que quelque chose d’autre a échoué ». Si vous n’avez pas besoin de partages invités, définissez map to guest = Never, désactivez les partages invités et laissez les échecs d’authentification être bruyants.

Trois micro-récits d’entreprise (ce qui se passe réellement)

Micro-récit 1 : L’incident causé par une mauvaise hypothèse

Ils ont migré un serveur de fichiers d’une VM Windows vieillissante vers une belle machine Linux avec Samba. Le plan de projet avait l’optimisme habituel : « mêmes noms de partages, mêmes permissions, bascule après les heures. » L’équipe a testé avec un compte administrateur, est entrée, a créé un dossier et déclaré victoire.

Lundi matin, la finance ne pouvait rien ouvrir. Les RH pouvaient parcourir mais pas sauvegarder. L’ingénierie allait bien, car leur groupe bénéficiait de larges permissions Unix héritées. Les tickets se sont accumulés avec la même capture : « Accès refusé. » L’ingénieur d’astreinte a fait ce que font les humains sous pression : il a cherché le levier le plus rapide. Quelqu’un a dit, « Peut-être que l’ancien serveur utilisait SMB1 ? »

Ce n’était pas le cas. La mauvaise hypothèse était plus subtile : ils ont supposé que les permissions Windows suffisaient. Côté Linux, l’arborescence avait des bits POSIX trop restrictifs sur un répertoire parent. Les tests d’admin avaient réussi parce que les admins étaient mappés à un groupe privilégié. Les utilisateurs réguliers butaient sur un « no execute/search » sur un répertoire intermédiaire et se faisaient refuser l’accès. L’UI Windows présentait cela comme si le fichier leur en voulait personnellement.

Ils ont corrigé en alignant les modèles : groupes AD mappés correctement, ACLs appliquées sur tout le chemin, et ils ont arrêté d’utiliser « ça marche pour moi » comme plan de test. Le postmortem a été sans concession : le contrôle d’accès n’est pas un bouton unique, c’est une chaîne. Si vous ne testez qu’avec des coupe-boulons, toutes les portes paraissent déverrouillées.

Micro-récit 2 : L’optimisation qui a mal tourné

Une autre entreprise avait des problèmes de performances sur un partage très sollicité. Les utilisateurs se plaignaient de listes de répertoires lentes et d’ouvertures de fichiers lentes. Un ingénieur a constaté que la signature SMB avait un coût. Il a modifié la config Samba pour rendre la signature « auto » et a célébré quand les benchmarks synthétiques se sont améliorés.

Deux semaines plus tard, la sécurité a déployé une mise à jour de politique de domaine exigeant la signature SMB pour certains clients et serveurs. Soudain, un sous-ensemble de clients Windows a commencé à échouer d’accéder au partage. Pas de façon consistante. Pas bruyamment. Juste des « Accès refusé » intermittents et « The request is not supported », selon la version du client et ce qu’il avait négocié.

Le retour de bâton n’était pas seulement le changement de config — c’était l’absence d’un contrat explicite. Quand vous laissez la signature dépendre de la négociation, vous externalisez la posture de sécurité à ce que le client décide ce jour-là. Ajoutez la politique et vous obtenez du chaos déguisé en compatibilité.

Ils sont revenus à server signing = mandatory, puis ont corrigé le vrai problème de performance : trop de petits fichiers sur le système de fichiers de backing qui nécessitait un réglage, plus un point chaud dans l’antivirus côté client. La leçon : une « optimisation » qui affaiblit la correction n’est que de la dette technique avec un meilleur marketing.

Micro-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation globale faisait tourner des serveurs membres Samba sur plusieurs sites. Rien de fancy : auth AD, partages serrés, SMB3. La pratique ennuyeuse : chaque changement de config SMB nécessitait un test canari depuis trois types de clients (Windows, montage CIFS Linux, et un compte de service utilisant smbclient), plus revue des logs pour les repli d’auth.

Un trimestre, une mise à jour OS a introduit une mise à jour Samba avec des valeurs par défaut légèrement différentes autour de NTLM et du mapping invité. La plupart des équipes l’auraient déployée et attendu les plaintes utilisateurs comme QA gratuite. Cette équipe a exécuté le canari. Le montage CIFS Linux a commencé à échouer avec « permission denied » tandis que Windows fonctionnait.

Le test canari a pointé directement le problème : le montage utilisait NTLM alors que l’environnement attendait Kerberos, et la nouvelle version de Samba était moins indulgente. Ils ont mis à jour le montage pour utiliser correctement Kerberos et ajusté l’approche du compte de service où nécessaire. Les utilisateurs n’ont rien remarqué. C’est le but.

Petite plaisanterie #2 : Le système le plus fiable est celui dont personne ne parle en réunion de statut — parce qu’il a refusé de devenir « une opportunité d’apprentissage excitante ».

Erreurs fréquentes : symptôme → cause racine → correction

1) Symptom: Windows prompts for credentials repeatedly, then “Access Denied”

Cause racine : Mauvaise identité utilisée (identifiants en cache), ou le serveur refuse la méthode d’auth (NTLM désactivé, Kerberos qui échoue).

Correction : Effacez les sessions existantes vers ce nom de serveur, assurez-vous du SPN/nom d’hôte correct, vérifiez que Kerberos fonctionne (kinit sur Linux, connexion domaine correcte sur Windows), et consultez les logs Samba pour « mapped to guest » ou blocages NTLM.

2) Symptom: Can list the share, but can’t open subfolders

Cause racine : Permission « execute/search » manquante sur un répertoire du chemin, ou incompatibilité d’héritage entre ACL Windows et POSIX.

Correction : Inspectez toute la chaîne de répertoires et les ACL ; ne regardez pas seulement le dossier feuille. Sur Samba, envisagez une gestion cohérente des ACL (par ex. vfs objects appropriés) et assurez-vous que le mapping d’identité est stable.

3) Symptom: Linux mount -t cifs returns “Permission denied”, Windows works

Cause racine : Le montage Linux utilise NTLM par défaut alors que le serveur attend Kerberos ou refuse NTLM. Ou le client Linux négocie un dialecte plus ancien.

Correction : Montez avec Kerberos (sec=krb5) et spécifiez vers=3.1.1 (ou au moins SMB3). Assurez-vous que la machine possède des tickets Kerberos valides et que le DNS est correct.

4) Symptom: Everything broke after “disabling SMB1”

Cause racine : Un appareil legacy (scanner, NAS, OS embarqué ancien) ne supporte que SMB1, ou comptait sur un comportement anonyme/invité.

Correction : Remplacez ou mettez à jour l’appareil, ou isolez-le sur un serveur/VLAN legacy dédié avec contrôles compensatoires. Ne réactivez pas SMB1 sur vos serveurs de fichiers principaux.

5) Symptom: Access works via \\server\share but fails via \\alias\share

Cause racine : Incompatibilité SPN Kerberos ; alias non enregistré, menant à un repli NTLM ou un échec quand NTLM est bloqué.

Correction : Utilisez le nom canonique, enregistrez les SPN appropriés pour l’alias, ou configurez DFS correctement. Traitez l’architecture de noms comme faisant partie du design d’auth, pas comme du cosmétique.

6) Symptom: Some users in the right AD group still get denied

Cause racine : L’appartenance au groupe n’est pas visible à cause de la taille du token, limites de résolution de groupes imbriqués, ou inconsistances idmap entre serveurs.

Correction : Réduisez l’imbrication excessive, validez le mapping d’identité, et vérifiez la liste de groupes effective sur le serveur avec id / getent group. Stabilisez les plages idmap et le backend.

7) Symptom: Samba logs show user becomes “nobody”

Cause racine : Échec d’auth mappé en invité (map to guest = Bad User), ou winbind/sssd incapable de résoudre l’identité.

Correction : Désactivez le mapping invité sauf si requis, corrigez la résolution NSS, réparez l’adhésion au domaine, et confirmez wbinfo -t et id DOMAIN\\user fonctionnent.

8) Symptom: “Access Denied” only for writes, reads are fine

Cause racine : read only du partage ou mismatch write list ; ACL du système de fichiers interdit la création/suppression ; ou un produit antivirus/EDR bloque les écritures via une politique SMB.

Correction : Confirmez les options du partage Samba et testez avec smbclient mkdir/rmdir ; puis inspectez les ACL du système de fichiers. Si des politiques interviennent, coordonnez-vous avec les équipes endpoint/sécurité en fournissant des preuves.

Listes de contrôle / plan étape par étape

Étape par étape : réparer « Accès refusé » sans affaiblir SMB

1. Prouvez la connectivité : le serveur écoute sur 445, le pare-feu l’autorise pour le sous-réseau client.
2. Confirmez la politique de dialecte : SMB1 désactivé ; SMB2/3 activés. Assurez-vous que le client les supporte.
3. Reproduisez avec smbclient : testez l’énumération des partages et des opérations simples en utilisant les mêmes identifiants.
4. Lisez les logs serveur : identifiez si l’utilisateur est authentifié, mappé sur guest, ou bloqué par une politique.
5. Validez le mapping d’identité : id DOMAIN\\user et l’appartenance aux groupes correspondent à l’accès attendu.
6. Vérifiez les règles au niveau du partage : valid users, read only, write list, force user/force group.
7. Vérifiez les ACLs système bout en bout : assurez l’exécution/recherche le long du chemin et les bonnes règles d’héritage.
8. Vérifiez les boutons de sécurité obligatoires : signature requise ? chiffrement requis ? NTLM restreint ?
9. Corrigez la divergence, pas le symptôme : mettez à jour les paramètres du client, corrigez les SPN, synchronisez l’heure, réparez idmap, ajustez les ACL.
10. Verrouillez : ajoutez un test canari et une alerte basée sur les logs pour le mapping invité/échecs d’auth.

Checklist de durcissement qui ne devrait pas provoquer d’incidents d’accès

• Mettre SMB1 off par politique (server min protocol à SMB2_10 ou plus).
• Exiger la signature SMB en environnements de domaine sauf exception mesurée.
• Utiliser le chiffrement SMB pour les partages sensibles traversant des réseaux moins fiables ; ne pas l’activer à tout va sans calcul CPU.
• Privilégier Kerberos pour les clients de domaine ; restreindre NTLM de manière réfléchie et tester les clients Linux/service.
• Garder la synchro horaire saine sur clients et serveurs.
• Rendre le mapping d’identité stable (même backend idmap et plages cohérentes sur tous les serveurs).
• Auditer le mapping invité et supprimer les accès invités accidentels.
• Utiliser un accès explicite basé sur des groupes et garder les ACL cohérentes entre les couches.
• Activer des logs suffisants pour distinguer échecs d’auth vs ACL vs politique.

FAQ

1) Pourquoi « Accès refusé » survient-il juste après avoir désactivé SMB1 ?

Parce qu’un client/appareil dépendait silencieusement de SMB1 (ou d’un comportement invité/anon propre à SMB1). Désactiver SMB1 supprime le chemin de repli et révèle l’incompatibilité réelle.

2) La signature SMB est-elle la même chose que le chiffrement SMB ?

Non. La signature protège l’intégrité (empêche la falsification). Le chiffrement protège la confidentialité (empêche l’écoute). Vous pouvez avoir la signature sans chiffrement, et souvent c’est souhaitable.

3) Si Windows peut accéder au partage, pourquoi le montage CIFS Linux obtient-il « permission denied » ?

Windows en domaine utilise souvent Kerberos automatiquement. Les montages Linux peuvent par défaut utiliser NTLM. Si le serveur ou la politique du domaine bloque NTLM, Linux échoue tandis que Windows fonctionne.

4) Dois-je définir « map to guest = Bad User » ?

Uniquement si vous avez un cas d’usage invité bien défini. Dans les environnements d’entreprise durcis, il est plus sûr d’échouer l’authentification bruyamment que de mapper silencieusement en invité et créer des refus déroutants.

5) Le chiffrement SMB peut-il causer « Accès refusé » ?

Oui, indirectement. Si le chiffrement est requis et que le client ne peut pas le négocier (OS ancien, firmware NAS ancien, client mal configuré), la configuration de session peut échouer et se manifester par des problèmes d’accès.

6) Quelle est la façon la plus rapide de savoir si c’est des ACLs ou l’authentification ?

Si smbclient -L échoue pour un utilisateur, c’est auth/politique. Si l’énumération fonctionne mais que mkdir échoue, c’est de l’autorisation (règles du partage ou ACLs système). Les logs confirment.

7) Dois-je activer SMB1 pour des scanners anciens ?

Privilégiez leur remplacement ou mise à jour. Si vous devez absolument supporter des appareils uniquement SMB1, isolez-les sur un endpoint legacy dédié avec contrôles réseau stricts — jamais sur vos serveurs de fichiers principaux.

8) Pourquoi l’accès marche via l’adresse IP du serveur mais pas via le nom d’hôte ?

Parce que Kerberos dépend du nom d’hôte (SPN). L’utilisation d’une IP force souvent NTLM ou ne respecte pas la politique. Corrigez DNS/SPN et utilisez des noms d’hôte appropriés.

9) Comment éviter de futures vagues « Accès refusé » après des mises à jour ?

Exécutez des tests canaris depuis plusieurs types de clients, surveillez les logs Samba pour les repli d’auth/mapping invité, et gardez votre mapping d’identité et votre synchronisation horaire constants et ennuyeux.

Conclusion : prochaines étapes à faire aujourd’hui

Si vous ne retenez qu’une règle opérationnelle : ne « corrigez » jamais un Accès refusé en abaissant le plancher de protocole. Désactiver SMB1 est la base ; vous dépannez au-dessus, pas autour.

Faites ceci ensuite :

1. Exécutez le playbook de diagnostic rapide : déterminez si vous échouez à la négociation, à l’authentification ou à l’autorisation.
2. Utilisez smbclient et les logs serveur pour reproduire et classifier la panne — ne discutez pas avec une boîte de dialogue Windows.
3. Stabilisez le mapping d’identité et la résolution des groupes, puis alignez les règles de partage avec les ACLs du système de fichiers.
4. Faites appliquer la signature, utilisez le chiffrement là où il est justifié et testez les clients avant de changer la politique.
5. Ajoutez un canari et maintenez-le : un client Windows, un montage Linux, un compte de service. L’ennui sauve les weekends.