Partage SMB « Accès refusé » : la permission que tout le monde oublie

La permission que tout le monde oublie : les droits de partage

L’accès SMB est l’intersection de plusieurs portails. Vous n’« avez pas accès » parce qu’une ACL le dit ; vous avez accès parce que chaque portail le permet.

Windows : Permissions de partage + Permissions NTFS

Sur les serveurs de fichiers Windows, il y a deux systèmes de permission distincts impliqués lorsque vous accédez à un partage :

• Permissions de partage (l’objet de partage). Historiquement configurées en Lecture/Modification/Contrôle total sur le partage.
• Permissions NTFS (l’ACL du système de fichiers) sur l’arborescence de dossiers sous-jacente.

L’accès effectif est la combinaison la plus restrictive. Si NTFS accorde Modifier mais que le partage n’accorde que Lecture, vous obtenez Lecture. Si le partage refuse un groupe, vous êtes refusé même si NTFS est très permissif.

Samba : contraintes de la définition du partage + permissions du système de fichiers

Sur Samba, l’idée est la même même si les réglages semblent différents. Votre accès est contraint par :

• Contrôles au niveau du partage Samba : valid users, write list, read list, hosts allow, veto files, force user, guest ok, et leurs amis.
• Permissions du système de fichiers : bits POSIX, ACLs (ACL NFSv4 sur ZFS, ACL POSIX sur ext4/xfs), plus toute couche MAC (SELinux/AppArmor).
• Mapping d’identité : si Samba vous identifie avec un UID/GID différent de celui attendu par le système de fichiers, c’est un refus par calcul.

Si vous voulez une vérité opérationnelle en une ligne : SMB n’est jamais « juste des permissions ». C’est des permissions plus de la traduction.

Blague #1 : Les permissions SMB sont comme la sécurité aéroportuaire : vous pouvez être autorisé au contrôle et quand même être arrêté parce que vous transportez une bouteille d’eau appelée « ACE Deny ».

Un modèle mental qui arrête le ping-pong

Quand quelqu’un dit « J’ai les permissions », il veut généralement dire « Je fais partie du groupe AD ». Quand quelqu’un d’autre dit « l’ACL est correcte », il veut dire « le système de fichiers semble correct ». Les deux peuvent être vrais. Vous êtes quand même refusé.

Pensez en portails, pas en listes

Pour l’accès SMB, parcourez les portails dans cet ordre :

1. Résolution de nom et atteignabilité : connectez-vous au serveur que vous pensez toucher ?
2. Authentification : vous êtes-vous connecté avec l’identité que vous pensez utiliser ?
3. Autorisation au niveau du partage : l’objet de partage vous autorise-t-il ?
4. Autorisation au niveau du système de fichiers : l’ACL du répertoire vous autorise-t-elle (et avez-vous des droits de traversée le long du chemin) ?
5. Couches de politique : exigences de chiffrement/signature, incompatibilité de dialecte SMB, « Network access: Sharing and security model », « map to guest » de Samba, etc.
6. Mise en cache des jetons/identifiants : Windows met en cache les identifiants SMB de façon agressive. Les humains aussi.

Pourquoi les permissions de partage importent plus qu’elles ne « devraient »

Dans de nombreux environnements Windows matures, les administrateurs définissent les permissions de partage sur « Everyone: Full Control » et s’appuient sur les ACL NTFS. C’est une norme défendable : un plan de contrôle (NTFS), moins de dérive, moins de confusion. Mais dès que quelqu’un dévie—souvent pendant un « durcissement rapide » ou une « restriction temporaire »—vous obtenez un second plan de contrôle et la dérive commence.

Dans les environnements Samba, les portails de niveau partage sont inévitables : valid users et consorts constituent le modèle de permission du partage. Si une définition de partage restreint l’accès, vous pouvez faire chmod 777 jusqu’à en avoir mal aux doigts ; ça ne changera rien.

La permission que tout le monde oublie, explicitement

Le mode d’échec récurrent est le suivant :

• Windows : l’onglet Sécurité/Permissions du partage n’inclut pas le groupe de l’utilisateur, ou l’inclut en Lecture alors que NTFS attend Écriture, ou contient un Deny explicite.
• Samba : le partage a valid users = @somegroup mais l’utilisateur n’appartient pas réellement à ce groupe tel que Samba le voit (mismatch idmap), ou le partage a read only = yes, ou une write list l’exclut.

Procédure de diagnostic rapide (premier/deuxième/troisième)

Ceci est la routine « arrêtez de vous disputer et trouvez le goulet d’étranglement ». Utilisez-la quand un utilisateur échoue, un autre réussit, et que tout le monde a des théories.

Premier : prouvez quel serveur et quelles informations d’identification

• Confirmez que le client se connecte au bon hôte (DFS peut vous rediriger ailleurs ; le DNS peut mentir ; de vieilles IP persistent).
• Confirmez quel nom d’utilisateur est utilisé (credential manager, sessions en cache, domaine implicite).
• Confirmez que la session SMB est établie (ou échoue à l’auth).

Second : vérifiez l’accès au niveau du partage (la porte oubliée)

• Windows : Get-SmbShareAccess sur le serveur pour le partage.
• Samba : inspectez smb.conf et la vue runtime (testparm -s), vérifiez valid users, write list, read list, hosts allow.

Troisième : vérifiez l’accès au niveau du système de fichiers et la traversée

• Windows : ACL NTFS plus traversée du chemin du partage. Utilisez icacls et les contrôles d’accès effectifs.
• Linux : bits POSIX, ACLs (getfacl), plus les refus SELinux (ausearch).

Condition d’arrêt

Dès que vous trouvez un portail qui refuse, arrêtez. Ne « corrigez » pas trois autres choses « au cas où ». C’est ainsi que vous transformez un bug de permission en incident.

Faits intéressants & histoire (pourquoi c’est devenu confus)

1. SMB a commencé chez IBM dans les années 1980, puis Microsoft l’a adopté et étendu. Cette filiation explique pourquoi vous retrouvez encore des concepts anciens intégrés dans le comportement moderne du partage Windows.
2. Les permissions de partage précèdent les ACL NTFS telles que la plupart des gens les comprennent aujourd’hui. Les contrôles au niveau du partage étaient une porte réseau précoce ; NTFS a évolué vers un modèle local de sécurité plus fin.
3. Le sens de « Everyone » a changé au fil du temps. Dans les anciennes versions de Windows, « Everyone » pouvait inclure l’anonyme ; des durcissements ultérieurs ont séparé « Everyone » de « Anonymous Logon », mais les vieilles hypothèses persistent dans les scripts et le savoir tribal.
4. La longue dépréciation de SMB1 a créé des habitudes de « hardening par compatibilité » : les admins ont basculé des paramètres pour réparer d’anciens appareils, parfois en cassant accidentellement l’auth moderne ou en resserrant l’accès de façon inattendue.
5. DFS peut masquer la cible réelle. Les utilisateurs disent « le partage est en panne », mais ils atteignent une redirection vers un autre serveur avec des permissions de partage différentes.
6. Idmap de Samba est un monde de douleur car il fait le pont entre les SIDs Windows et les UIDs/GIDs Unix. Un groupe AD parfaitement correct peut devenir insignifiant si le backend de mapping change ou si les plages se chevauchent.
7. Les jetons d’accès Windows sont des instantanés. Les changements de membership de groupe ne s’appliquent pas toujours avant une nouvelle connexion/logon, ce qui fait de « je viens de l’ajouter au groupe » un piège.
8. Les ACE Deny explicites gagnent (généralement). Elles existent pour une raison, mais elles sont aussi le moyen le plus rapide de créer des énigmes du type « ça marche pour les admins mais pas pour la finance ».
9. Les exigences de signature/chiffrement SMB peuvent ressembler à des problèmes d’accès. Certains clients échouent avec des erreurs trompeuses quand la politique bloque la connexion avant même l’autorisation.

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

Ce sont des actions opérationnelles réelles. Exécutez-les depuis le bon endroit (client vs serveur) et lisez la sortie comme si elle vous racontait une histoire. Parce que c’en est une.

Task 1 (Windows client): list current SMB connections

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Format-Table -AutoSize"
ServerName ShareName UserName Credential Dialect NumOpens
---------- --------- -------- ----------- ------- --------
FS01       Finance$  CONTOSO\jdoe          3.1.1   4

Ce que cela signifie : Vous êtes déjà connecté à FS01 en tant que CONTOSO\jdoe sur le partage Finance$. Si l’utilisateur a « testé » avec d’autres identifiants, il peut mentir sans le vouloir.

Décision : Si le nom d’utilisateur est incorrect, déconnectez et reconnectez explicitement avec le compte voulu (voir Task 2).

Task 2 (Windows client): clear cached SMB session to a server

cr0x@server:~$ powershell -NoProfile -Command "net use \\FS01\Finance$ /delete"
\\FS01\Finance$ was deleted successfully.

Ce que cela signifie : Cette session SMB est supprimée. Votre prochaine tentative d’accès demandera/renégociera des identifiants.

Décision : Retestez immédiatement. Si cela fonctionne maintenant, votre problème de « permissions » était la mise en cache des identifiants.

Task 3 (Windows client): confirm DNS is pointing you where you think

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName FS01 | Select-Object -First 3 | Format-Table -AutoSize"
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
FS01  A   60  Answer  10.10.5.21

Ce que cela signifie : Le client résout FS01 en 10.10.5.21.

Décision : Si cette IP n’est pas le serveur de fichiers prévu (fréquent lors de migrations), vous dépannez la mauvaise machine. Corrigez DNS/DFS avant de toucher aux ACL.

Task 4 (Windows server): inspect share-level permissions (the missing gate)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShareAccess -Name Finance$ | Format-Table -AutoSize"
Name     ScopeName AccountName        AccessControlType AccessRight
----     --------- -----------        ----------------- -----------
Finance$ *         BUILTIN\Administrators Allow          Full
Finance$ *         CONTOSO\FinanceRW      Allow          Change
Finance$ *         CONTOSO\FinanceRO      Allow          Read
Finance$ *         CONTOSO\Interns        Deny           Full

Ce que cela signifie : Il y a un Deny explicite pour CONTOSO\Interns. Si votre utilisateur fait partie de ce groupe (directement ou par inclusion), il perd, indépendamment de NTFS.

Décision : Confirmez l’appartenance aux groupes et supprimez/remplacez le Deny par un modèle plus propre. Deny devrait être un dernier recours, pas l’instinct initial.

Task 5 (Windows server): show the physical path behind a share

cr0x@server:~$ powershell -NoProfile -Command "(Get-SmbShare -Name Finance$).Path"
D:\Shares\Finance

Ce que cela signifie : Le partage pointe vers D:\Shares\Finance.

Décision : Vous savez maintenant exactement quelle ACL de répertoire inspecter. Plus de suppositions.

Task 6 (Windows server): inspect NTFS ACLs quickly

cr0x@server:~$ powershell -NoProfile -Command "icacls D:\Shares\Finance"
D:\Shares\Finance CONTOSO\FinanceRW:(OI)(CI)(M)
                 CONTOSO\FinanceRO:(OI)(CI)(RX)
                 BUILTIN\Administrators:(OI)(CI)(F)
                 NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                 Successfully processed 1 files; Failed processing 0 files

Ce que cela signifie : Au niveau du système de fichiers, le modèle semble sain : RW a Modify, RO a Read/Execute.

Décision : Si l’utilisateur est dans FinanceRW et est toujours refusé, la porte au niveau du partage (Task 4) ou des problèmes d’identité/jeton sont plus probables que NTFS.

Task 7 (Windows server): check effective access (spot nested group surprises)

cr0x@server:~$ powershell -NoProfile -Command "Get-Acl D:\Shares\Finance | Select-Object -ExpandProperty Access | Select-Object -First 6 | Format-Table -AutoSize"
FileSystemRights AccessControlType IdentityReference          IsInherited InheritanceFlags PropagationFlags
---------------- ----------------- -----------------          ----------- ---------------- ---------------
Modify           Allow             CONTOSO\FinanceRW          False       ContainerInherit ObjectInherit None
ReadAndExecute   Allow             CONTOSO\FinanceRO          False       ContainerInherit ObjectInherit None
FullControl      Allow             BUILTIN\Administrators     False       ContainerInherit ObjectInherit None
FullControl      Allow             NT AUTHORITY\SYSTEM        False       ContainerInherit ObjectInherit None

Ce que cela signifie : Vous regardez les ACE brutes. Cela ne calcule pas directement « effectif » pour un utilisateur spécifique, mais révèle si un Deny se cache ou si l’héritage est cassé.

Décision : Si vous voyez des entrées explicites inattendues ou un héritage cassé, corrigez cela avant de toucher aux permissions de partage.

Task 8 (Windows server): confirm the user’s group membership as the server sees it

cr0x@server:~$ powershell -NoProfile -Command "whoami /groups | Select-String -Pattern 'Finance|Interns' -CaseSensitive"
BUILTIN\Administrators                                 Alias            S-1-5-32-544  Enabled
CONTOSO\FinanceRW                                      Group            S-1-5-21-...   Enabled
CONTOSO\Interns                                        Group            S-1-5-21-...   Enabled

Ce que cela signifie : Le jeton d’accès inclut à la fois FinanceRW et Interns. Si le partage refuse Interns, ce Deny l’emporte.

Décision : Retirez l’utilisateur du groupe refusé, ou repensez les permissions du partage pour éviter l’usage de Deny.

Task 9 (Windows server): verify SMB server config isn’t blocking auth

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object RejectUnencryptedAccess,RequireSecuritySignature,EnableSMB1Protocol | Format-List"
RejectUnencryptedAccess : True
RequireSecuritySignature : True
EnableSMB1Protocol : False

Ce que cela signifie : Ce serveur exige la signature et rejette l’accès non chiffré (selon la négociation client). Certains clients plus anciens ou des appliances peuvent échouer et rapporter cela de façon peu claire.

Décision : Si le client en échec est ancien ou non-Windows, vérifiez le dialecte/signature/chiffrement avant de courir après les permissions.

Task 10 (Linux client): test share listing with explicit credentials

cr0x@server:~$ smbclient -L //fs01 -U 'CONTOSO\jdoe'
Password for [CONTOSO\jdoe]:
        Sharename       Type      Comment
        ---------       ----      -------
        Finance$        Disk      Finance data
        IPC$            IPC       Remote IPC
SMB1 disabled -- no workgroup available

Ce que cela signifie : L’authentification a réussi et le serveur a listé les partages. La ligne « SMB1 disabled » est informative dans de nombreux cas.

Décision : Si la liste échoue avec NT_STATUS_LOGON_FAILURE, vous n’en êtes pas encore au stade des permissions. Corrigez l’auth ou le format du realm.

Task 11 (Linux client): attempt to access the share and observe the exact error

cr0x@server:~$ smbclient //fs01/Finance$ -U 'CONTOSO\jdoe' -c 'ls'
Password for [CONTOSO\jdoe]:
NT_STATUS_ACCESS_DENIED listing \*

Ce que cela signifie : L’auth a réussi, mais l’autorisation a échoué. Cela pointe vers les permissions de partage, les ACL du système de fichiers, ou une couche de politique (moins fréquent).

Décision : Passez aux vérifications côté serveur : ACL du partage (Windows) ou valid users/write list (Samba), puis ACL du système de fichiers.

Task 12 (Linux server running Samba): print the effective Samba config for the share

cr0x@server:~$ testparm -s
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_ACTIVE_DIRECTORY_MEMBER

[Finance$]
	path = /srv/shares/finance
	read only = no
	valid users = @FINANCE_RW @FINANCE_RO
	write list = @FINANCE_RW

Ce que cela signifie : Seuls les membres de FINANCE_RW ou FINANCE_RO peuvent accéder du tout. Les écritures sont restreintes à FINANCE_RW.

Décision : Si l’utilisateur est dans AD mais que l’hôte Samba ne le reconnaît pas comme membre de ces groupes, enquêtez sur idmap et la résolution des groupes NSS.

Task 13 (Linux server): confirm the user identity and group mapping

cr0x@server:~$ id 'jdoe'
uid=123450110(jdoe) gid=123450513(domain users) groups=123450513(domain users),123450988(finance_ro),123450999(interns)

Ce que cela signifie : Du point de vue Unix, jdoe est dans finance_ro et interns. Si le partage attend finance_rw, il n’obtiendra pas l’écriture. Si le partage bloque interns via invalid users ou similaire, il peut être totalement refusé.

Décision : Alignez les noms de groupes de la configuration Samba avec ce que le système résout réellement, et évitez les noms de groupes ambigus entre domaines.

Task 14 (Linux server): check filesystem ACLs on the share path

cr0x@server:~$ getfacl -p /srv/shares/finance | sed -n '1,25p'
# file: /srv/shares/finance
# owner: root
# group: finance_rw
user::rwx
group::rwx
group:finance_ro:r-x
mask::rwx
other::---

Ce que cela signifie : Les permissions du système de fichiers permettent à finance_ro de lire, finance_rw d’écrire, et aux autres de n’avoir rien.

Décision : Si Samba permet mais que le système de fichiers refuse, corrigez les ACL (ou utilisez force group/create mask). Si le système de fichiers permet mais que Samba refuse, corrigez la configuration du partage.

Task 15 (Linux server with SELinux): check for SELinux denials affecting Samba

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

Ce que cela signifie : SELinux a bloqué smbd pour la lecture du répertoire labellisé default_t.

Décision : Étiquetez correctement le répertoire pour Samba (ou configurez un boolean/policy SELinux). Ne résolvez pas cela en faisant un chmod aveugle sur la couche MAC.

Task 16 (Windows server): verify share permissions didn’t drift from the standard

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare | Where-Object Name -like '*$' | Select-Object Name,Path | Sort-Object Name | Format-Table -AutoSize"
Name      Path
----      ----
Finance$  D:\Shares\Finance
HR$       D:\Shares\HR
Legal$    D:\Shares\Legal

Ce que cela signifie : Vous avez plusieurs partages de type administratif cachés. La dérive se produit souvent partages par partages, pas serveur par serveur.

Décision : Comparez les ACL des partages entre eux. Si Finance$ est le seul avec un Deny ou une ACL de partage personnalisée, vous avez probablement trouvé le coupable.

Trois mini-histoires du monde de l’entreprise

1) Incident causé par une mauvaise hypothèse : « NTFS suffit »

La société avait un modèle de serveur de fichiers propre : les permissions de partage étaient « Everyone: Full Control », et NTFS faisait le vrai boulot. C’est une pratique courante. Cela réduit le nombre de pièces mobiles et facilite les audits parce qu’un système est autoritaire.

Puis un changement imposé par la conformité est arrivé pendant un trimestre chargé. Quelqu’un a resserré les permissions de partage « temporairement » sur un partage sensible. Ils ont ajouté un Deny pour un grand groupe qui « ne devrait pas » avoir accès de toute façon. Sur le papier, cela semblait propre : enlever une grande population avec une règle.

Le lundi matin, un analyste senior n’a pas pu ouvrir les fichiers de fin de mois. Son manager a escaladé, puis la finance a escaladé, puis le support a transformé cela en « panne du serveur de fichiers » parce que c’est la seule catégorie à laquelle on accorde de l’urgence. Taxonomie classique en entreprise : si c’est cassé, c’est l’infra.

Le SRE de garde a vérifié la santé du stockage. Ok. Le réseau. Ok. L’ACL NTFS. Ok. L’analyste était dans le bon groupe FinanceRW. Tout le monde s’est détendu—jusqu’à ce que quelqu’un regarde réellement Get-SmbShareAccess et remarque un Deny sur un groupe imbriqué incluant l’analyste à cause d’un bundle d’onboarding hérité.

La correction était simple : supprimer le Deny et le remplacer par un modèle allow-list sur NTFS. L’apprentissage, lui, ne l’était pas. Le postmortem a noté la cause racine réelle : une hypothèse ancrée dans l’organisation (« les perms de partage sont sans importance ») qui a heurté un changement ponctuel que personne n’a révisé parce qu’il semblait « mineur ».

2) Optimisation qui s’est retournée contre eux : « Accélérons avec DFS et consolidation »

Autre endroit, autre saveur de douleur. Ils ont consolidé des serveurs de fichiers et introduit des namespaces DFS pour que les utilisateurs continuent d’utiliser \\corp\files\... pendant que le stockage bougeait en dessous. C’est du travail normal de modernisation. C’est aussi un excellent moyen de déboguer la mauvaise machine pendant des jours.

Pour « optimiser », ils ont redirigé un partage très sollicité vers un nouveau serveur backend avec des disques plus rapides et un meilleur monitoring. Ça a fonctionné pour la plupart. Pour un sous-groupe, l’accès a commencé à échouer de façon intermittente avec « Accès refusé ». Intermittent veut dire « personne ne vous croit jusqu’à ce que cela arrive en partage d’écran ».

Il s’est avéré que les referrals DFS envoyaient certains clients vers la nouvelle cible et d’autres vers l’ancienne en fonction du costing site et des referrals en cache. Les deux cibles avaient des permissions NTFS identiques. Les ACL de partage, non. Donc le même chemin réussissait ou échouait selon le serveur où vous aboutissiez.

L’« optimisation » n’était pas DFS ; DFS faisait exactement ce pour quoi il avait été conçu. Le problème était d’avoir supposé que les permissions de partage seraient « identiques partout » sans les appliquer comme du code. Une fois qu’ils ont standardisé des templates d’ACL de partage et validé lors des changements, les échecs intermittents ont disparu.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : « Un seul plan de contrôle, et test depuis le client »

Dans une organisation de santé, l’équipe des services fichiers évitait la malice. Ils avaient une politique : les permissions de partage sont toujours permissives, NTFS est autoritaire, et les entrées Deny nécessitent une revue par les pairs. Ils exigeaient aussi que chaque ticket de changement inclue un test côté client avec l’identité réelle de l’utilisateur, pas un compte admin « parce que c’est plus simple ».

Un après-midi, une application clinique a commencé à échouer à écrire des rapports sur un partage. L’équipe applicative a dit « le stockage est plein » (faux). Le réseau a dit « SMB est en panne » (faux). L’équipe fileservices a demandé les champs du template de ticket : nom du partage, chemin, utilisateur, nom d’hôte client, erreur exacte, et un test avec le compte de service.

Ils ont découvert que le compte de service avait été renouvelé et que le nouveau compte n’avait pas été ajouté au groupe NTFS. Les permissions de partage étaient permissives, donc il n’y avait pas de seconde porte pour embrouiller les choses. La correction de l’ACL a pris des minutes, pas des heures.

Rien d’héroïque. Pas de war room. Pas de restauration à minuit. La pratique correcte—ennuyeuse, cohérente, documentée—a rendu la défaillance évidente. Voilà à quoi ressemble la fiabilité : moins d’histoires intéressantes.

Erreurs courantes : symptôme → cause racine → correction

1) « J’y accède localement mais pas via \\server\share » → refus par la permission de partage

Symptôme : L’utilisateur peut ouvrir le dossier en étant connecté sur le serveur (RDP/console) mais obtient « Accès refusé » via SMB.

Cause racine : L’accès local utilise NTFS ; l’accès SMB utilise permissions de partage + NTFS. La porte du partage les bloque.

Correction : Sur Windows, exécutez Get-SmbShareAccess et corrigez l’ACL du partage. Sur Samba, vérifiez valid users/write list.

2) « Seulement cet utilisateur est refusé » → il est dans un groupe refusé (souvent imbriqué)

Symptôme : Même rôle, même équipe, un seul utilisateur échoue. Tout le monde soupçonne « profil corrompu » ou « Windows qui fait Windows ».

Cause racine : Un Deny explicite s’applique via un groupe imbriqué, ou leur jeton inclut un groupe héritage.

Correction : Vérifiez whoami /groups (Windows) ou id (Linux). Retirez l’utilisateur du groupe refusé ou supprimez l’entrée Deny en repensant le modèle d’autorisation.

3) « Ça marche après reboot/logoff » → jeton d’accès obsolète ou identifiants en cache

Symptôme : Vous ajoutez l’utilisateur à un groupe, rien ne change, puis plus tard ça marche comme par magie.

Cause racine : Les jetons Windows sont créés au logon ; les changements de groupe ne sont pas reflétés tant qu’un nouveau jeton n’est pas créé. Les sessions SMB mettent aussi en cache des identifiants par serveur.

Correction : Déconnectez/reconnectez (ou redémarrez la session de service pour les comptes de service). Effacez les sessions SMB avec net use ... /delete et retestez avec des identifiants explicites.

4) « Lecture fonctionne, écriture refusée » → partage en Lecture seule ou write list Samba exclut

Symptôme : L’utilisateur peut parcourir et ouvrir des fichiers mais ne peut pas créer/renommer/supprimer.

Cause racine : Le niveau du partage est en Lecture seule, ou la write list Samba ne les inclut pas, ou NTFS n’accorde que RX.

Correction : Comparez les droits d’accès du partage (Read/Change) vs NTFS Modify. Sur Samba, assurez-vous que read only = no et que write list correspond au groupe prévu.

5) « Accès refusé intermittent » → referrals DFS ou cibles multiples avec ACLs de partage dépareillées

Symptôme : Le même chemin marche parfois, parfois non, souvent selon l’emplacement ou le moment.

Cause racine : DFS envoie les clients sur des serveurs différents ; les permissions de partage diffèrent entre cibles.

Correction : Standardisez les permissions de partage sur toutes les cibles. Vérifiez sur quel serveur un client est connecté avant de dépanner.

6) « Samba refuse mais le système de fichiers semble ouvert » → SELinux/AppArmor bloque

Symptôme : Les bits/mode ACL montrent l’accès autorisé, mais SMB renvoie quand même accès refusé.

Cause racine : Le contrôle d’accès obligatoire (MAC) refuse smbd.

Correction : Inspectez les denials AVC et étiquetez correctement les chemins ; ne traitez pas SELinux comme une rumeur.

7) « Tout le monde a accès sauf les machines non-domaine » → incompatibilité du modèle d’auth

Symptôme : Les machines jointes au domaine fonctionnent ; les clients non-domaine échouent avec des erreurs « refusées » confuses.

Cause racine : Le serveur exige Kerberos, signature, ou des politiques d’auth spécifiques ; ou Samba mappe les utilisateurs inconnus vers guest et guest est bloqué.

Correction : Confirmez la méthode d’auth ; pour Samba vérifiez map to guest et les droits guest ; sur Windows vérifiez les politiques du serveur SMB.

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

Étape par étape : diagnostiquer un utilisateur qui n’accède pas à un partage

1. Identifiez le chemin UNC exact que l’utilisateur utilise. Si c’est un namespace DFS, notez-le.
2. Depuis le client, listez les connexions SMB actives (Task 1). Confirmez le nom d’utilisateur.
3. Effacez les sessions obsolètes vers le serveur cible (Task 2). Reconnectez avec des identifiants explicites.
4. Vérifiez la résolution de nom (Task 3). Confirmez que vous touchez le bon serveur/IP.
5. Prouvez auth vs authz avec smbclient (Tasks 10–11) ou des tentatives de mapping Windows. Si l’auth échoue, arrêtez et corrigez l’auth.
6. Sur le serveur, dumppez les permissions du partage (Task 4). Cherchez les allows manquants et les denies explicites.
7. Confirmez le chemin du partage (Task 5). Assurez-vous de vérifier le bon dossier.
8. Vérifiez les ACL du système de fichiers (Task 6). Assurez-vous que le bon groupe a Modify/Write et que l’héritage est cohérent.
9. Vérifiez le token/l’appartenance aux groupes (Task 8 / Task 13). Confirmez la vue du serveur, pas celle du système RH.
10. Si Samba, validez la configuration runtime (Task 12) et la résolution idmap/groupes (Task 13).
11. Si Linux, vérifiez la couche MAC (Task 15) si les permissions semblent correctes mais l’accès échoue.
12. Changez une seule chose, retestez immédiatement, puis documentez quel portail a échoué et pourquoi.

Une norme sûre qui prévient la plupart des incidents de permission SMB

• Windows : Configurez les permissions de partage largement (souvent « Authenticated Users: Full » ou l’équivalent approuvé par la politique), puis appliquez l’accès réel avec des groupes NTFS. Gardez les entrées Deny rares et revues.
• Samba : Soyez explicite et cohérent : définissez valid users et write list en utilisant un schéma de nommage de groupe prévisible. Évitez les exceptions créatives par partage à moins d’aimer les réveils de pager.
• Partout : Traitez le mapping d’identité comme une infrastructure de production. Si vous changez les backends idmap ou les plages, vous changez « qui est qui » sur le disque.

Checklist opérationnelle pour les changements (permissions, partages, migrations)

• Enregistrez l’ACL actuelle du partage et l’ACL du système de fichiers avant les changements (les captures d’écran ne sont pas un système de contrôle).
• Testez avec un vrai utilisateur non-admin ainsi que le compte de service utilisé par les automatisations/applications.
• Pour DFS : testez chaque cible directement (\\server\share) et via le namespace.
• Après des changements d’appartenance à un groupe : assurez-vous que les utilisateurs rafraîchissent leurs jetons (logoff/logon) pour validation.
• Notez le modèle de permission intentionnel : « partage permissif, NTFS restrictif » ou « partage restrictif, système de fichiers aligné ». Ne le laissez pas être accidentel.

Blague #2 : Le Deny ACE « temporaire » a le même cycle de vie qu’une base de données de staging : c’est pour toujours, juste avec pire documentation.

FAQ

1) Quelle est la « permission que tout le monde oublie » ?

La porte au niveau du partage : les permissions de partage Windows ou les restrictions de définition de partage Samba. Les gens s’obsèdent sur les ACL NTFS/POSIX et oublient que le partage peut bloquer l’accès en premier.

2) Sous Windows, dois-je mettre les permissions de partage sur Everyone: Full Control ?

Dans de nombreuses entreprises, la variante moderne plus sûre est « Authenticated Users » (selon la politique) avec Contrôle total au partage, puis appliquer le vrai contrôle d’accès avec des groupes NTFS. L’important est la cohérence : un point unique d’autorité pour les restrictions.

3) Pourquoi Deny cause-t-il tant de bugs étranges ?

Parce que c’est brutal et que ça l’emporte. Les utilisateurs accumulent des memberships de groupe dans le temps (groupes projets, bundles d’onboarding, groupes imbriqués). Un seul Deny peut annuler plusieurs allows d’une manière qui n’est pas évidente à un coup d’œil.

4) J’ai ajouté l’utilisateur au bon groupe AD. Pourquoi est-il toujours refusé ?

Ils peuvent utiliser des identifiants SMB en cache, ou leur jeton d’accès n’inclut pas encore le nouveau groupe. Effacez les sessions SMB et faites-les se déconnecter/reconnecter (ou redémarrez la session de service pour les comptes de service).

5) Pourquoi un admin peut accéder au partage alors que l’utilisateur ne peut pas ?

Les admins ont souvent des droits élevés, des memberships de groupe différentes, ou des effets de contournement (comme l’accès local admin) qui ne reflètent pas l’autorisation SMB normale. Testez toujours avec l’identité réelle de l’utilisateur ou un compte de test équivalent.

6) Comment savoir si l’échec est d’authentification ou d’autorisation ?

Si vous pouvez lister les partages mais pas les répertoires à l’intérieur du partage, l’auth a réussi et l’autorisation a échoué. Des outils comme smbclient rendent cela visible : NT_STATUS_LOGON_FAILURE vs NT_STATUS_ACCESS_DENIED.

7) Les politiques de signature/chiffrement SMB peuvent-elles ressembler à « Accès refusé » ?

Oui. Selon le client et la gestion des erreurs, l’application de politiques peut se manifester par des erreurs d’accès génériques. Vérifiez la configuration du serveur (et les capacités du client) avant de réécrire des ACL.

8) Sur Samba, j’ai correctement défini les permissions du système de fichiers. Pourquoi Samba refuse-t-il encore ?

Parce que Samba peut restreindre le partage via valid users, read list, write list, ou des restrictions d’hôtes, ou mapper votre utilisateur au mauvais UID/GID. Inspectez testparm -s et vérifiez la sortie de id pour l’utilisateur.

9) Quelle est la commande serveur la plus rapide pour les problèmes de permission de partage Windows ?

Get-SmbShareAccess -Name <share>. Si le groupe prévu n’apparaît pas avec le bon accès, ou si un Deny existe, vous avez probablement trouvé le problème.

10) Quelle citation résume bien tout ce bazar ?

Werner Vogels (idée paraphrasée) : tout finit par échouer, donc concevez et administrez en supposant l’échec—et faites en sorte que le diagnostic soit rapide.

Conclusion : étapes suivantes qui tiennent réellement

Quand SMB dit « Accès refusé », ne commencez pas par réécrire les ACL NTFS comme si vous pratiquiez un exorcisme. Prouvez les basiques : bon serveur, bonne identité, auth vs authz. Puis vérifiez la porte du partage—parce que c’est celle que tout le monde oublie.

Faites ceci ensuite :

1. Standardisez votre modèle : soit « partage permissif, système de fichiers restrictif » (commun sur Windows), soit une allow-list explicite de partage Samba soutenue par un mapping d’identité cohérent.
2. Interdisez les entrées Deny occasionnelles : exigez une revue par les pairs et une raison documentée. Deny est un scalpel que les gens utilisent comme une pelle.
3. Transformez la procédure de diagnostic en réflexe : vérification des sessions client, permissions de partage, ACL du système de fichiers, mapping d’identité/rafraîchissement de jeton, couches de politique.
4. Automatisez la détection de dérive : si vous exécutez plusieurs serveurs de fichiers ou cibles DFS, assurez-vous que les permissions de partage sont cohérentes et auditables.

Si vous ne faites rien d’autre, faites ceci : quand quelqu’un dit « mais NTFS est correct », répondez « montrez-moi les permissions du partage ». Puis profitez du silence soudain dans la salle—le genre productif.