Permissions NTFS : comprendre ACL, héritage et droits effectifs

Sous Windows, afficher l’onglet :

Propriétés
→ Sécurité

donne l’impression que les permissions d’un fichier sont une affaire relativement simple.

Quelques utilisateurs.

Quelques cases :

Lecture
Écriture
Modification
Contrôle total

et tout devrait bien se passer.

Puis arrive le jour où :

• un utilisateur appartient à trois groupes différents ;
• une permission est héritée du dossier parent ;
• une autre est définie explicitement ;
• un refus apparaît quelque part ;
• le partage SMB ajoute sa propre couche ;
• le fichier a été déplacé depuis un autre dossier ;
• l’utilisateur affirme qu’il peut créer un fichier mais pas le supprimer ;
• et l’administrateur possède le contrôle total sur absolument tout, sauf précisément le dossier qu’il doit réparer.

Bienvenue dans les permissions NTFS.

Le système de permissions Windows est extrêmement puissant. Le problème n’est pas qu’il manque de logique : c’est qu’il possède beaucoup plus de logique que les six cases visibles au premier écran.

Qu’est-ce que NTFS ?

NTFS — New Technology File System est le système de fichiers historiquement associé aux versions modernes de Windows et reste notamment utilisé pour les volumes système Windows.

Il fournit de nombreuses fonctions :

• fichiers et répertoires ;
• journalisation ;
• quotas ;
• liens ;
• flux de données alternatifs ;
• compression ;
• chiffrement EFS ;
• et surtout, pour notre sujet, des descripteurs de sécurité permettant un contrôle d’accès très précis.

Grâce à ces mécanismes, Windows peut déterminer :

Qui ?
↓
demande quoi ?
↓
sur quel objet ?
↓
avec quels droits ?
↓
Autorisé ou refusé ?

Authentification et autorisation : deux choses différentes

Avant de parler de permissions, distinguons :

Authentification
≠
Autorisation

Authentification

Elle répond à :

« Qui êtes-vous ? »

Par exemple :

CONTOSO\alice

Autorisation

Elle répond ensuite à :

« Maintenant que je sais qui vous êtes, avez-vous le droit de faire cette opération ? »

Par exemple :

Lire rapport.xlsx ?
Modifier rapport.xlsx ?
Supprimer rapport.xlsx ?
Changer les permissions de rapport.xlsx ?

NTFS intervient principalement dans cette seconde étape.

Le descripteur de sécurité

Un fichier ou dossier sécurisé par Windows possède un :

Security Descriptor

qui contient notamment :

• un propriétaire ;
• une DACL ;
• éventuellement une SACL ;
• d’autres informations de contrôle.

Pour comprendre les permissions NTFS correctement, il faut donc apprendre trois acronymes :

SID
ACL
ACE

Après quoi vous gagnerez le droit d’en apprendre une dizaine d’autres.

SID : Windows préfère les identifiants aux noms

Les comptes et groupes sont identifiés en interne par un :

SID
Security Identifier

Par exemple :

S-1-5-21-...

Le nom :

alice

est surtout une représentation humaine.

Pour Windows, l’identité durable est le SID.

C’est pourquoi vous pouvez parfois voir dans une ACL :

S-1-5-21-123456789-...

à la place d’un nom.

Cela arrive notamment lorsque Windows ne parvient plus à résoudre le SID vers le compte correspondant.

Par exemple après :

• suppression d’un utilisateur ;
• suppression d’un groupe ;
• migration de domaine ;
• restauration incomplète.

Ce SID solitaire dans l’ACL est généralement le fantôme administratif d’une identité disparue.

ACL : Access Control List

Une :

ACL
Access Control List

est une liste d’entrées de contrôle d’accès.

Chaque entrée individuelle est une :

ACE
Access Control Entry

On peut imaginer :

Dossier Projets
│
├── ACE : Groupe Développeurs → Autoriser Modification
├── ACE : Groupe Auditeurs    → Autoriser Lecture
├── ACE : Alice               → Autoriser Contrôle total
└── ACE : Kevin               → Refuser Écriture

DACL et SACL

Windows distingue principalement deux types d’ACL.

ACL	Fonction
DACL	Détermine qui est autorisé ou refusé
SACL	Détermine quelles opérations doivent être auditées

La :

DACL
Discretionary Access Control List

est donc celle que l’on manipule principalement pour les permissions NTFS.

DACL absente et DACL vide : énorme différence

Deux situations qui semblent proches sont en réalité opposées.

Aucune DACL

Si un objet ne possède réellement aucune DACL :

NULL DACL

l’accès est extrêmement permissif.

DACL présente mais vide

Si une DACL existe mais ne possède aucune ACE autorisant l’accès :

Empty DACL

personne n’obtient d’accès par cette DACL.

Autrement dit :

Pas de liste
≠
Liste vide

Une nuance discrète capable de produire des différences de sécurité assez peu discrètes.

Les permissions NTFS de base

L’interface graphique présente plusieurs ensembles de permissions standards.

Permission	Idée générale
Contrôle total	Tous les droits, y compris gestion des permissions et de la propriété
Modification	Lire, écrire, exécuter et supprimer
Lecture et exécution	Lire et exécuter les fichiers appropriés
Liste du contenu du dossier	Énumérer le contenu d’un dossier
Lecture	Lire données, attributs et certaines informations
Écriture	Créer ou modifier certaines données et attributs

Contrôle total

Contrôle total ne signifie pas seulement :

« Peut modifier les fichiers. »

Il comprend également des capacités sensibles comme :

• supprimer ;
• modifier les permissions ;
• changer le propriétaire ;
• et effectuer les opérations couvertes par les autres droits.

C’est pourquoi donner :

Contrôle total

aux utilisateurs ordinaires uniquement parce qu’ils doivent modifier des documents est généralement excessif.

Dans beaucoup de cas :

Modification

est plus approprié.

Modification

La permission :

Modification
Modify

permet généralement :

• lecture ;
• écriture ;
• exécution ;
• création ;
• suppression.

Mais elle n’accorde pas les droits administratifs complets permettant notamment de modifier librement la DACL ou de prendre la propriété.

Pour des utilisateurs devant travailler normalement dans un dossier partagé, Modify est souvent beaucoup plus approprié que Full Control.

Lecture et exécution

La permission :

Read & Execute
RX

autorise notamment la lecture et l’exécution lorsque le type de fichier et le contexte le permettent.

Pour un dépôt de logiciels ou un dossier contenant des scripts accessibles en lecture, elle est souvent plus adaptée qu’un simple :

Read

Liste du contenu du dossier

Cette permission concerne principalement les répertoires.

Elle autorise l’énumération du contenu du dossier selon les autres règles applicables.

Elle ne signifie pas automatiquement que tous les fichiers listés seront lisibles.

Voir :

rapport-secret.xlsx

et pouvoir ouvrir :

rapport-secret.xlsx

sont deux contrôles distincts.

Les permissions avancées

Derrière :

Propriétés
→ Sécurité
→ Avancé

on trouve des droits plus granulaires.

Parmi eux :

• parcourir le dossier / exécuter le fichier ;
• répertorier le dossier / lire les données ;
• lire les attributs ;
• lire les attributs étendus ;
• créer des fichiers / écrire des données ;
• créer des dossiers / ajouter des données ;
• écrire les attributs ;
• écrire les attributs étendus ;
• supprimer ;
• supprimer les sous-dossiers et fichiers ;
• lire les autorisations ;
• modifier les autorisations ;
• prendre possession.

C’est ici que l’on comprend que :

Modification

n’est pas un droit élémentaire unique.

C’est essentiellement un ensemble pratique de droits plus fins.

Permissions sur les fichiers et permissions sur les dossiers

Certains bits de permission prennent un sens légèrement différent selon l’objet.

Par exemple, un même droit peut correspondre à :

Lire les données

sur un fichier et :

Lister le répertoire

sur un dossier.

De même :

Écrire des données

sur un fichier correspond à une logique proche de :

Créer un fichier

lorsqu’il s’applique à un répertoire.

C’est pourquoi la fenêtre des permissions avancées adapte certains intitulés selon le type d’objet.

Les utilisateurs n’accèdent pas seuls : ils arrivent avec leurs groupes

Lorsqu’un utilisateur ouvre une session, Windows construit un :

Access Token

contenant notamment :

• son SID ;
• les SID de ses groupes ;
• différents privilèges ;
• des informations liées à la session et à la sécurité.

Lorsqu’Alice tente d’ouvrir :

D:\Projets\budget.xlsx

Windows ne demande donc pas seulement :

« Y a-t-il une ACE pour Alice ? »

Il examine aussi les ACE applicables aux groupes présents dans son jeton.

Les permissions autorisées sont généralement cumulatives

Supposons :

Alice
│
├── GG_Comptabilite → Lecture
└── GG_Projet        → Écriture

Si aucune règle de refus applicable ne vient bloquer ces opérations, Alice peut généralement bénéficier des droits cumulés :

Lecture + Écriture

C’est pourquoi l’utilisation de groupes simplifie énormément l’administration.

Utilisez des groupes plutôt que des utilisateurs individuels

Au lieu de :

Alice  → Modify
Bob    → Modify
Chloe  → Modify
David  → Modify
Emma   → Modify

préférez :

Groupe Projet-Modification
    ├── Alice
    ├── Bob
    ├── Chloe
    ├── David
    └── Emma

ACL :
Projet-Modification → Modify

Lorsque Bob quitte le projet :

retirer Bob du groupe

est beaucoup plus propre que rechercher son nom dans quatre millions de fichiers.

Dans Active Directory : pensez en groupes de rôle

Une organisation classique peut ressembler à :

Utilisateurs
↓
Groupes métier
↓
Groupes donnant accès aux ressources
↓
ACL NTFS

Dans un domaine Active Directory, on rencontre notamment le principe :

AGDLP

que l’on peut résumer :

Accounts
→ Global Groups
→ Domain Local Groups
→ Permissions

Par exemple :

Alice
↓
GG_Comptabilite
↓
DL_Finance_Modification
↓
D:\Partages\Finance → Modify

Cette architecture évite de transformer chaque ACL en annuaire des ressources humaines.

Attention : l’appartenance aux groupes est dans le jeton

Vous ajoutez Alice à :

GG_Projet

et elle répond :

« Ça ne marche toujours pas. »

Selon le contexte, son jeton de connexion actuel peut encore refléter l’ancienne appartenance.

On peut examiner les groupes présents avec :

whoami /groups

Une nouvelle ouverture de session peut être nécessaire pour obtenir un nouveau jeton contenant les nouvelles appartenances.

Redémarrer le serveur n’est normalement pas la première étape.

Le serveur n’est pas obligé de subir les conséquences du jeton vieillissant d’Alice.

Allow et Deny

Une ACE peut principalement :

ALLOW
ou
DENY

c’est-à-dire :

• autoriser certains droits ;
• refuser certains droits.

Une erreur pédagogique très fréquente consiste à résumer :

« Deny gagne toujours. »

La réalité est plus précise.

L’ordre canonique des ACE

Dans une DACL canonique, les ACE sont généralement organisées ainsi :

1. Refus explicites
2. Autorisations explicites
3. Refus hérités
4. Autorisations héritées

Les ACE héritées sont également classées selon leur niveau d’héritage.

Windows traite ces entrées dans leur ordre pour déterminer si l’accès demandé peut être accordé.

Explicite et hérité : distinction essentielle

Une permission :

explicite

est définie directement sur l’objet.

Une permission :

héritée

provient d’un parent.

Supposons :

D:\Entreprise
└── Finance
    └── Secret

Une ACE définie sur :

D:\Entreprise

peut être héritée par :

Finance

puis par :

Secret

si ses indicateurs d’héritage le permettent.

Pourquoi « Deny gagne toujours » est trop simplifié

Supposons qu’un parent possède un :

DENY hérité

mais que le fichier possède directement une :

ALLOW explicite

Les entrées explicites sont traitées avant les entrées héritées dans l’ordre canonique.

Il est donc plus juste de retenir :

Les refus explicites sont très prioritaires, mais le résultat dépend de l’ordre canonique, de l’héritage et des droits précis demandés.

Évitez Deny lorsque Allow suffit

Dans la majorité des architectures, il est plus simple de :

ne pas accorder un droit

que de :

l'accorder largement
puis ajouter des Deny partout

Le principe d’une DACL est déjà :

ce qui n’est pas autorisé est implicitement refusé.

Il n’est donc pas nécessaire d’ajouter :

Deny Everyone Full Control

sur chaque dossier sensible pour prouver que vous prenez la sécurité au sérieux.

Vous risquez surtout de prouver que vous aimez résoudre les ACL à la main le vendredi soir.

Quand un Deny explicite est utile

Un refus peut cependant être pertinent lorsqu’un utilisateur doit être exclu d’un droit accordé à un groupe plus large.

Par exemple :

GG_Employes → Lecture
Kevin       → Refus Lecture

si Kevin doit réellement constituer une exception.

Mais avant de faire cela, demandez-vous s’il ne serait pas préférable de construire un groupe :

GG_Employes_Autorises

ne contenant tout simplement pas Kevin.

Le refus explicite est un scalpel.

Pas un rouleau de ruban adhésif.

L’héritage

Un dossier parent peut transmettre certaines ACE à ses enfants.

Exemple :

D:\Partages\Projets
│
│  GG_Projets_Modification → Modify
│
├── ProjetA
│   ├── cahier-des-charges.docx
│   └── budget.xlsx
│
└── ProjetB
    └── planning.xlsx

Si l’ACE est correctement définie comme héritée par les sous-dossiers et fichiers, les enfants recevront automatiquement cette règle.

Pourquoi l’héritage est indispensable

Sans héritage, il faudrait configurer individuellement :

500 dossiers
12 000 fichiers
47 groupes

et répéter l’opération chaque fois qu’un fichier est créé.

Ce serait techniquement possible.

Ce serait également une manière spectaculaire de justifier l’embauche d’une équipe entière uniquement chargée de cliquer sur :

Sécurité → Avancé

Désactiver l’héritage

Windows permet de désactiver l’héritage sur un objet.

Deux stratégies apparaissent généralement :

Convertir les permissions héritées

Les ACE héritées deviennent des ACE explicites sur l’objet.

Vous pouvez ensuite les modifier indépendamment.

Supprimer les permissions héritées

Les ACE héritées disparaissent.

Vous devez alors construire la DACL nécessaire vous-même.

Cette deuxième option mérite une attention particulière.

Une DACL minimaliste devient très vite une DACL minimaliste au point d’exclure précisément son administrateur.

Les indicateurs d’héritage dans icacls

icacls utilise notamment :

Code	Signification
(OI)	Object inherit : les fichiers héritent de l’ACE
(CI)	Container inherit : les sous-dossiers héritent de l’ACE
(IO)	Inherit only : ACE destinée aux descendants, pas à l’objet courant
(NP)	No propagate : l’héritage ne continue pas au-delà du niveau prévu
(I)	Indique dans l’affichage qu’une ACE a été héritée

Exemple classique d’héritage

Pour accorder Modification au dossier, à ses sous-dossiers et à ses fichiers :

icacls "D:\Partages\Projets" /grant "CONTOSO\DL_Projets_Modification:(OI)(CI)(M)"

Le :

(OI)(CI)

est essentiel si l’objectif est de transmettre la règle aux enfants.

Sans lui, vous pouvez parfaitement accorder une permission uniquement sur le dossier lui-même et découvrir ensuite que les fichiers ont une vision différente de votre projet.

Activer ou désactiver l’héritage avec icacls

Activer :

icacls "D:\Partages\Projets" /inheritance:e

Désactiver tout en copiant les ACE héritées en ACE explicites :

icacls "D:\Partages\Projets" /inheritance:d

Désactiver en supprimant les ACE héritées :

icacls "D:\Partages\Projets" /inheritance:r

La dernière commande est nettement plus agressive.

Le :

r

n’est pas là pour :

« rendre le dossier plus robuste ».

Il retire les ACE héritées.

icacls : l’outil principal en ligne de commande

icacls permet notamment de :

• afficher les DACL ;
• ajouter des permissions ;
• retirer des permissions ;
• ajouter des refus ;
• gérer l’héritage ;
• changer le propriétaire ;
• sauvegarder des DACL ;
• restaurer des DACL ;
• vérifier leur forme canonique.

Il remplace l’ancien outil :

cacls

qui reste connu de nombreuses documentations historiques mais est déprécié.

Afficher les permissions

icacls "D:\Partages\Projets"

Exemple conceptuel :

D:\Partages\Projets
    CONTOSO\DL_Projets_Modification:(OI)(CI)(M)
    CONTOSO\DL_Projets_Lecture:(OI)(CI)(RX)
    BUILTIN\Administrators:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)

Les codes de permissions icacls

Code	Droit
F	Full Control
M	Modify
RX	Read & Execute
R	Read
W	Write
D	Delete

Accorder une permission

Pour Modification :

icacls "D:\Partages\Projets" /grant "CONTOSO\DL_Projets_Modification:(OI)(CI)(M)"

Pour Lecture et exécution :

icacls "D:\Partages\Projets" /grant "CONTOSO\DL_Projets_Lecture:(OI)(CI)(RX)"

/grant et /grant:r

Cette distinction est importante.

Avec :

/grant

les permissions accordées sont ajoutées aux autorisations explicites déjà présentes pour ce SID.

Avec :

/grant:r

les autorisations explicites précédentes correspondant au SID sont remplacées par celles indiquées.

Par exemple :

icacls "D:\Partages\Projets" /grant:r "CONTOSO\DL_Projets_Lecture:(OI)(CI)(RX)"

est très utile dans un script destiné à obtenir un état déterminé.

Sinon chaque passage de l’automatisation peut finir par ajouter une nouvelle strate géologique de permissions.

Ajouter un refus

Par exemple :

icacls "D:\Secret" /deny "CONTOSO\Kevin:(R)"

ajoute un refus explicite du droit correspondant.

Mais utilisez ce mécanisme avec parcimonie.

icacls place les ACE dans l’ordre canonique, ce qui donne aux refus explicites une position très importante dans l’évaluation.

Retirer les ACE d’un compte

Pour retirer toutes les ACE correspondant à un SID :

icacls "D:\Partages\Projets" /remove "CONTOSO\Kevin"

Pour retirer uniquement les ACE d’autorisation :

icacls "D:\Partages\Projets" /remove:g "CONTOSO\Kevin"

Pour retirer uniquement les refus :

icacls "D:\Partages\Projets" /remove:d "CONTOSO\Kevin"

/reset ne signifie pas « supprimer tout le monde »

La commande :

icacls "D:\Temp" /reset

remplace la DACL par les permissions héritées par défaut appropriées.

Elle ne signifie pas :

« Supprimer toutes les permissions et ne laisser que moi. »

Si le parent accorde :

Users → Modify

un :

/reset

peut précisément ramener ce droit.

Réinitialisation récursive

icacls "D:\Partages\Projets\*" /reset /T /C

avec :

• /T pour récursion ;
• /C pour continuer malgré certaines erreurs.

Cette commande peut toucher une énorme quantité d’objets.

Le nombre de caractères est faible.

Le rayon d’explosion, beaucoup moins.

Sauvegarder les DACL

Avant une opération importante :

icacls "D:\Partages\Projets\*" /save "C:\Backup\Projets-acl.txt" /T /C

Cette opération sauvegarde les informations de DACL correspondantes pour permettre une restauration ultérieure.

Ce fichier n’est pas une sauvegarde des données.

Vous aurez une merveilleuse copie des permissions d’un document disparu.

Ce qui reste moins utile que le document.

Restaurer les DACL

La restauration se fait depuis le répertoire de base approprié :

icacls "D:\Partages\Projets" /restore "C:\Backup\Projets-acl.txt" /C

Testez cette procédure avant d’en avoir besoin à 3 heures du matin.

Les sauvegardes non testées sont des manifestations de foi.

Vérifier les ACL

icacls peut détecter certaines ACL non canoniques ou incohérentes :

icacls "D:\Partages\Projets" /verify /T

Ce n’est pas un audit complet de votre politique de sécurité.

Mais cela peut signaler certaines structures problématiques.

Les permissions avancées avec icacls

Parmi les codes avancés :

Code	Droit
DE	Delete
RC	Read Control / lire les permissions
WDAC	Write DAC / modifier la DACL
WO	Write Owner
RD	Read Data / List Directory
WD	Write Data / Add File
AD	Append Data / Add Subdirectory
X	Execute / Traverse
DC	Delete Child
RA	Read Attributes
WA	Write Attributes

Supprimer un fichier : le piège de DELETE_CHILD

Le droit de suppression sous Windows possède une subtilité importante.

Pour supprimer ou renommer un fichier, il peut suffire de posséder :

DELETE sur le fichier

ou :

DELETE_CHILD sur son dossier parent

Par conséquent, cette recette :

icacls "D:\Docs" /grant "Toto:(M)"
icacls "D:\Docs" /deny "Toto:(D)"

ne constitue pas une garantie générale que Toto pourra tout modifier sans jamais supprimer.

Le droit :

Delete subfolders and files
DELETE_CHILD

du parent doit également être pris en compte.

« Modifier sans supprimer » est un cas avancé

Si votre besoin est :

« L’utilisateur doit pouvoir créer et modifier les fichiers, mais ne jamais les supprimer. »

il faut concevoir précisément les droits avancés concernant :

• écriture ;
• création ;
• DELETE ;
• DELETE_CHILD ;
• héritage ;
• application aux fichiers et dossiers.

Et tester :

• création ;
• modification ;
• renommage ;
• suppression ;
• création de sous-dossiers ;
• déplacement.

Ce cas est beaucoup moins simple que :

Modify - Delete = magique

Pourquoi le renommage peut également être affecté

Renommer un fichier implique des contrôles proches de ceux nécessaires à son déplacement ou à sa suppression de l’ancien nom.

Une ACL destinée à empêcher :

Delete

peut donc aussi avoir des conséquences sur :

Rename

selon les droits exacts.

Encore une raison de ne pas déployer ce type de politique sans test.

Le propriétaire

Chaque objet possède également un :

Owner

ou propriétaire.

Le propriétaire possède un rôle particulier :

il peut modifier la DACL de l’objet.

Cela ne signifie pas nécessairement qu’il possède automatiquement tous les droits de lecture ou d’écriture sur le contenu.

Mais il peut modifier les permissions et donc se donner les accès nécessaires.

Changer le propriétaire avec icacls

icacls "D:\Donnees\Secret" /setowner "CONTOSO\File-Admins"

Pour appliquer récursivement :

icacls "D:\Donnees\Secret" /setowner "CONTOSO\File-Admins" /T /C

takeown

Windows fournit également :

takeown

pour permettre notamment à un administrateur de reprendre la propriété d’un fichier ou dossier auquel il n’a plus accès.

Par exemple :

takeown /F "D:\Donnees\AncienDossier"

Pour une arborescence :

takeown /F "D:\Donnees\AncienDossier" /R /D Y

Et avec :

/A

la propriété peut être attribuée au groupe Administrateurs plutôt qu’au compte courant.

Prendre possession ne signifie pas automatiquement lire le contenu

takeown change la propriété.

Il peut ensuite être nécessaire d’ajuster la DACL avec :

icacls

pour obtenir les droits de lecture ou modification nécessaires.

Conceptuellement :

takeown
→ je peux administrer la sécurité

icacls
→ je définis ensuite qui peut réellement faire quoi

Administrateur ne signifie pas « contourne toutes les ACL »

Un membre du groupe Administrateurs peut lui aussi recevoir :

Access Denied

sur certains fichiers.

Les administrateurs disposent de privilèges permettant notamment de récupérer le contrôle de nombreuses ressources, mais Windows ne traite pas chaque accès à un fichier comme :

« Ah, c’est un admin, ignore tout. »

Selon le contexte, l’administrateur devra :

• élever sa console ;
• prendre possession ;
• corriger la DACL ;
• puis effectuer l’opération souhaitée.

UAC entre également dans la conversation

Avec le contrôle de compte utilisateur :

UAC

un compte membre des Administrateurs peut fonctionner couramment avec un jeton filtré.

Une console :

CMD

ordinaire et une console :

CMD → Exécuter en tant qu'administrateur

ne possèdent donc pas toujours le même contexte de privilèges.

Droits effectifs

Le simple affichage d’une ACL ne répond pas toujours à :

« Que peut réellement faire Alice ? »

Il faut tenir compte de :

• ses ACE directes ;
• ses groupes ;
• les groupes imbriqués ;
• les autorisations héritées ;
• les refus ;
• l’ordre des ACE ;
• et éventuellement d’autres mécanismes de sécurité.

Windows fournit donc dans :

Propriétés
→ Sécurité
→ Avancé
→ Accès effectif

un mécanisme destiné à évaluer les droits d’un principal donné.

icacls n’affiche pas directement « la vérité effective » d’un utilisateur

Cette commande :

icacls "D:\Partages\Finance"

affiche la DACL.

Elle ne calcule pas nécessairement en une ligne :

« Alice appartient à A, B et C, donc voici exactement ses capacités finales dans tous les contextes. »

Pour les diagnostics complexes, utilisez :

• l’onglet Accès effectif ;
• whoami /groups ;
• les outils Sysinternals adaptés ;
• ou une analyse détaillée des ACL.

AccessChk

L’outil Sysinternals :

AccessChk

peut aider à examiner les droits effectifs d’un compte sur différents objets Windows.

Par exemple, selon l’installation :

accesschk "CONTOSO\alice" "D:\Partages\Finance"

Il peut être particulièrement intéressant lorsqu’il faut analyser de nombreuses ressources ou vérifier des accès autrement qu’à travers l’interface graphique.

NTFS et permissions de partage SMB

Lorsqu’un dossier NTFS est partagé sur le réseau, deux contrôles peuvent intervenir :

Permissions du partage SMB
+
Permissions NTFS

Ce sont deux couches différentes.

Permission de partage

Elle contrôle l’accès via :

\\serveur\partage

Permission NTFS

Elle contrôle l’accès au fichier ou dossier lui-même.

Pour un accès réseau, les deux doivent permettre l’opération

Supposons :

Partage SMB :
Alice → Read

NTFS :
Alice → Modify

Via :

\\serveur\documents

Alice ne pourra pas modifier les fichiers puisque la couche partage ne l’autorise qu’en lecture.

Exemple inverse

Partage SMB :
Alice → Full

NTFS :
Alice → Read

Via le réseau, Alice reste limitée à la lecture.

On peut résumer :

Accès réseau effectif = ce que le partage autorise ET ce que NTFS autorise.

Le mot :

intersection

est souvent plus précis que :

la permission la plus restrictive

car les droits peuvent être constitués de plusieurs bits indépendants.

En local, les permissions de partage n’interviennent pas

Si Alice ouvre directement :

D:\Partages\Documents

sur le serveur lui-même, la permission SMB du partage :

\\serveur\Documents

n’est pas la couche qui contrôle cet accès local.

NTFS reste applicable.

C’est important pour comprendre pourquoi :

« Ça fonctionne quand je me connecte sur le serveur, mais pas depuis mon PC. »

peut être parfaitement cohérent.

Les permissions de partage sont moins granulaires

Les permissions SMB classiques se présentent essentiellement sous les niveaux :

• Read ;
• Change ;
• Full.

NTFS permet une granularité beaucoup plus importante.

Une architecture courante consiste donc à rendre la permission de partage suffisamment permissive pour la population prévue puis à utiliser NTFS pour le détail.

Mais cela ne signifie pas :

« Mettez Everyone Full Control partout sans réfléchir. »

Le principe du moindre privilège reste valable aux deux couches.

Voir les permissions d’un partage avec PowerShell

Get-SmbShareAccess -Name "Documents"

Pour accorder un droit :

Grant-SmbShareAccess -Name "Documents" `
    -AccountName "CONTOSO\DL_Documents_Modification" `
    -AccessRight Change

Pour retirer les ACE d’autorisation d’un principal :

Revoke-SmbShareAccess -Name "Documents" `
    -AccountName "CONTOSO\AncienGroupe"

Un modèle propre pour un partage

Imaginons :

D:\Partages\Projets

publié comme :

\\SRV-FICHIERS\Projets

On peut créer :

DL_Projets_Lecture
DL_Projets_Modification
DL_Projets_Admin

Puis définir les ACL NTFS :

DL_Projets_Lecture      → Read & Execute
DL_Projets_Modification → Modify
DL_Projets_Admin        → Full Control
SYSTEM                   → Full Control
Administrators           → Full Control

Les utilisateurs sont ensuite ajoutés aux groupes appropriés.

Cas pratique : dossier Projets

Créons :

D:\Partages\Projets

avec :

• un groupe de lecteurs ;
• un groupe pouvant modifier ;
• des administrateurs conservant le contrôle.

Après avoir vérifié l’héritage provenant du parent, on peut notamment ajouter :

icacls "D:\Partages\Projets" /grant:r "CONTOSO\DL_Projets_Lecture:(OI)(CI)(RX)"

icacls "D:\Partages\Projets" /grant:r "CONTOSO\DL_Projets_Modification:(OI)(CI)(M)"

Le :

/grant:r

permet ici de remplacer les autorisations explicites existantes de ces groupes par la définition souhaitée.

Mais cela ne retire pas les autres groupes

Ajouter :

DL_Projets_Lecture

et :

DL_Projets_Modification

ne signifie pas que :

Users
Authenticated Users
Everyone
ancien groupe

ont automatiquement disparu.

Vous devez inspecter :

icacls "D:\Partages\Projets"

et comprendre les ACE héritées.

Cas pratique : isoler un sous-dossier confidentiel

Supposons :

D:\Partages\Projets\Direction

qui ne doit pas hériter des droits généraux des utilisateurs du projet.

Une stratégie possible consiste d’abord à désactiver l’héritage en copiant les ACE :

icacls "D:\Partages\Projets\Direction" /inheritance:d

Puis examiner :

icacls "D:\Partages\Projets\Direction"

et supprimer ou remplacer explicitement les groupes qui ne doivent plus être présents.

Cette approche est plus prudente que :

/inheritance:r

suivi immédiatement d’une série de commandes dont vous espérez avoir correctement orthographié les noms de groupes.

Cas pratique : repartir d’une ACL contrôlée

Dans un environnement de laboratoire ou avec une procédure de récupération clairement définie, on peut vouloir supprimer les ACE héritées :

icacls "D:\Secret" /inheritance:r

Puis définir explicitement les groupes nécessaires.

Par exemple :

icacls "D:\Secret" /grant:r "CONTOSO\DL_Secret_Admin:(OI)(CI)(F)"

icacls "D:\Secret" /grant:r "CONTOSO\DL_Secret_Lecture:(OI)(CI)(RX)"

Mais avant de faire cela, vérifiez également les besoins de :

• SYSTEM ;
• Administrators ;
• services ;
• sauvegardes ;
• antivirus ;
• applications utilisant ce dossier.

« Seul mon compte doit avoir accès » est une phrase qui semble élégante jusqu’au moment où le service censé utiliser les fichiers n’est pas votre compte.

Ne retirez pas SYSTEM aveuglément

Le compte :

NT AUTHORITY\SYSTEM

est utilisé par Windows et différents services.

Retirer systématiquement SYSTEM de chaque dossier :

« parce que personne ne se connecte avec ce compte »

démontre surtout une compréhension très littérale du mot utilisateur.

Ne modifiez pas les ACL du système pour « simplifier »

Évitez les grandes commandes récursives sur :

C:\
C:\Windows
C:\Program Files
C:\ProgramData

comme :

icacls "C:\" /reset /T

ou :

icacls "C:\Windows" /grant Everyone:(F) /T

Ces arborescences possèdent des ACL spécialement conçues pour le fonctionnement et la sécurité du système.

Les « normaliser » en :

Tout le monde
Contrôle total

ne les simplifie pas.

Cela simplifie surtout le travail d’un attaquant.

Les ACL lors d’une copie

Les permissions peuvent également changer lorsque l’on déplace ou copie des fichiers.

Par défaut, lors d’une copie, le nouvel objet est créé dans le dossier de destination et reçoit généralement les permissions héritables de cette destination.

Par exemple :

D:\Source\rapport.xlsx
↓ COPIE
D:\Finance\rapport.xlsx

la nouvelle copie peut hériter de :

D:\Finance

Déplacement dans le même volume NTFS

Un déplacement à l’intérieur d’un même volume possède historiquement une différence importante :

D:\Source\rapport.xlsx
↓ MOVE
D:\Finance\rapport.xlsx

l’objet peut conserver ses permissions existantes plutôt que devenir un nouvel objet héritant simplement de la destination.

C’est particulièrement important sur les serveurs de fichiers.

Un document déplacé dans :

D:\Finance

peut donc conserver des ACL qui viennent de :

D:\Commun

si l’opération et le contexte suivent cette sémantique.

Déplacement vers un autre volume

Un déplacement vers un autre volume ressemble davantage à :

copie
+
suppression de l'original

Le nouvel objet reçoit alors normalement le comportement de permissions associé à la destination.

Pourquoi c’est important en production

Supposons :

D:\Public
→ GG_Employes : Modify

et :

D:\Direction
→ GG_Direction : Modify

Un fichier déplacé de Public vers Direction en conservant une ACL trop large pourrait rester accessible à des utilisateurs qui ne devraient plus le voir.

Déplacer un fichier dans un dossier sécurisé ne garantit donc pas toujours que ses permissions ont automatiquement adopté la politique de destination.

Vérifiez les ACL après les migrations

Après :

• migration de serveur ;
• réorganisation de partages ;
• déplacement massif ;
• restauration de sauvegarde ;
• utilisation de robocopy ;

vérifiez les permissions.

Une migration réussie sur le plan des fichiers peut être un échec complet sur le plan de l’autorisation.

Robocopy et les permissions

robocopy possède plusieurs options permettant de contrôler les métadonnées copiées.

Par exemple :

/COPY:DAT

concerne classiquement :

D = Data
A = Attributes
T = Timestamps

Alors que d’autres options permettent de conserver davantage d’informations de sécurité.

On rencontre notamment :

/COPYALL

pour demander la copie d’un ensemble très large de métadonnées.

Avant une migration de serveur de fichiers, décidez explicitement :

« Est-ce que je veux conserver les anciennes ACL ou appliquer celles de la nouvelle arborescence ? »

Ne laissez pas cette question être résolue accidentellement par l’option copiée depuis un script de 2013.

PowerShell : Get-Acl

PowerShell peut lire un descripteur de sécurité avec :

Get-Acl "D:\Partages\Projets"

Pour examiner les ACE :

(Get-Acl "D:\Partages\Projets").Access

Vous pouvez obtenir des propriétés comme :

• IdentityReference ;
• FileSystemRights ;
• AccessControlType ;
• IsInherited ;
• InheritanceFlags ;
• PropagationFlags.

Exemple PowerShell d’inventaire

Get-Acl "D:\Partages\Projets" |
    Select-Object -ExpandProperty Access |
    Format-Table IdentityReference,
                 FileSystemRights,
                 AccessControlType,
                 IsInherited

Cette approche est particulièrement utile pour les audits.

Set-Acl

PowerShell propose également :

Set-Acl

pour appliquer un descripteur de sécurité.

Par exemple, copier la sécurité d’un objet vers un autre :

$Acl = Get-Acl "D:\Modele"

Set-Acl -Path "D:\Destination" -AclObject $Acl

Attention :

copier un descripteur complet n’est pas la même chose que simplement ajouter un droit.

Vérifiez exactement quelles informations doivent être reproduites.

PowerShell est puissant, mais icacls reste souvent plus simple

Pour :

ajouter Modify à un groupe

icacls est souvent plus lisible.

Pour :

• inventorier des milliers de dossiers ;
• filtrer les ACE ;
• produire des rapports ;
• construire des ACL complexes ;
• automatiser selon des données structurées ;

PowerShell devient particulièrement intéressant.

La SACL et l’audit

La :

SACL
System Access Control List

ne décide pas principalement si l’accès est autorisé.

Elle permet de demander l’audit de certaines opérations.

Par exemple :

Auditer les suppressions réussies
Auditer les tentatives de modification refusées

Les événements correspondants peuvent ensuite apparaître dans le journal de sécurité si la politique d’audit appropriée est activée.

Audit réussi et audit échoué

Une ACE d’audit peut demander de journaliser :

• les succès ;
• les échecs ;
• ou les deux.

Mais attention à ne pas activer :

Auditer tout
sur tout
succès + échecs

sur un serveur de fichiers très sollicité.

Vous découvrirez alors que le journal de sécurité sait écrire énormément de lignes avec une efficacité remarquable.

Audit n’est pas sauvegarde

Savoir :

« Kevin a supprimé le fichier à 14:32. »

est très intéressant.

Cela ne ramène pas le fichier.

Permissions, audit et sauvegardes répondent à trois besoins différents :

Permissions
→ empêcher certaines opérations

Audit
→ savoir quelles opérations se sont produites

Sauvegarde
→ récupérer les données après le désastre

NTFS n’est pas une protection contre le ransomware avec identifiants valides

Si Alice possède :

Modify

sur :

\\serveur\Projets

un malware exécuté dans son contexte peut potentiellement disposer des mêmes capacités sur les fichiers accessibles à Alice.

Les ACL réduisent donc l’exposition selon le principe du moindre privilège.

Elles ne remplacent pas :

• les sauvegardes hors ligne ou immuables ;
• la supervision ;
• la sécurité des postes ;
• la segmentation ;
• la détection d’incidents.

Le principe du moindre privilège

La règle fondamentale est :

donner uniquement les droits nécessaires à la fonction.

Pour consulter :

Read

Pour travailler normalement sur des documents :

Modify

Pour administrer les permissions :

Full Control

Attribuer systématiquement :

Full Control

parce que :

« Sinon ça marche pas. »

est à l’administration Windows ce que :

chmod -R 777

est à Linux.

Le problème de permissions disparaît parfois.

Le modèle de sécurité également.

Les ACL trop complexes deviennent elles-mêmes un risque

Imaginez :

Alice Allow Read
GG_Projet Allow Modify
GG_Externes Deny Write
GG_Employes Allow Read
Parent Deny Delete
Grand-parent Allow Full
AncienGroupe Allow Modify
Kevin Deny Full
SYSTEM Full
Administrators Full

sur plusieurs niveaux d’héritage.

Il est peut-être possible de déterminer les droits effectifs.

Mais si chaque modification exige trente minutes de reconstruction mentale, la politique est devenue difficile à maintenir.

Une ACL simple est souvent une meilleure ACL

Essayez de construire :

quelques groupes fonctionnels
+
peu d'ACE
+
héritage cohérent
+
peu de Deny
+
exceptions rares

plutôt que :

une ACE par utilisateur
+
exceptions individuelles
+
héritage cassé partout
+
trois couches de Deny

Les dossiers de haut niveau

Sur un serveur, une structure propre peut être :

D:\Partages
├── Commun
├── Direction
├── Finance
├── RH
└── Projets

Chaque grande branche possède ses groupes :

DL_Commun_Modification

DL_Direction_Lecture
DL_Direction_Modification

DL_Finance_Lecture
DL_Finance_Modification

DL_RH_Lecture
DL_RH_Modification

Les exceptions sont alors créées uniquement lorsque le besoin métier le justifie.

Ne cassez pas l’héritage à tous les niveaux

Une arborescence comme :

Dossier A
  héritage désactivé

  Dossier B
    héritage désactivé

    Dossier C
      héritage désactivé

      Dossier D
        héritage désactivé

est parfaitement possible.

Elle est également parfaite pour obtenir :

« Je ne comprends pas pourquoi ce dossier n’a pas reçu le nouveau groupe. »

Si l’héritage doit être interrompu, faites-le à des frontières fonctionnelles claires.

Permissions « Ce dossier uniquement »

Les ACE peuvent aussi s’appliquer seulement :

à ce dossier

sans être transmises aux descendants.

C’est particulièrement utile pour créer des modèles comme :

« Les utilisateurs peuvent traverser le dossier racine mais seuls leurs sous-dossiers leur donnent réellement des droits. »

Cela exige cependant de bien comprendre :

• Apply to ;
• Object Inherit ;
• Container Inherit ;
• Inherit Only ;
• Traverse.

Le droit Traverse

Un répertoire possède notamment un droit :

Traverse Folder

Mais Windows accorde généralement aux utilisateurs le privilège :

Bypass Traverse Checking

qui permet de traverser certains dossiers sans nécessairement pouvoir en lister le contenu, tant que l’objet final est accessible.

C’est une autre raison pour laquelle :

« Il n’a pas accès au dossier parent, donc il ne peut absolument pas atteindre le sous-dossier. »

peut être une analyse incomplète sous Windows.

Access-Based Enumeration

Sur un partage SMB, l’:

Access-Based Enumeration
ABE

peut permettre de masquer à l’utilisateur les fichiers ou dossiers auxquels il n’a pas accès.

Cela améliore :

• la lisibilité ;
• l’expérience utilisateur ;
• la discrétion des noms de ressources.

Mais :

masquer un dossier n’est pas ce qui le sécurise.

Les ACL doivent toujours être correctement configurées.

ABE retire surtout de l’écran les portes auxquelles l’utilisateur n’a pas les clés.

Permissions et chiffrement sont deux sujets différents

Une ACL répond à :

« Qui peut demander à Windows d’accéder à ce fichier ? »

Le chiffrement répond à une autre question :

« Les données sont-elles intelligibles sans les clés cryptographiques nécessaires ? »

NTFS peut notamment travailler avec :

EFS

et Windows utilise également :

BitLocker

au niveau des volumes.

Un disque correctement chiffré protège contre certains scénarios physiques.

Une ACL correctement configurée protège contre certains accès logiques.

Les deux ne sont pas interchangeables.

Cas pratique : utilisateurs en lecture, développeurs en modification

Supposons :

D:\Projets

avec deux groupes :

CONTOSO\DL_Projets_Lecture
CONTOSO\DL_Projets_Modification

On peut ajouter :

icacls "D:\Projets" /grant:r "CONTOSO\DL_Projets_Lecture:(OI)(CI)(RX)"

icacls "D:\Projets" /grant:r "CONTOSO\DL_Projets_Modification:(OI)(CI)(M)"

Puis vérifier :

icacls "D:\Projets"

Mais cette configuration n’est correcte que si aucune autre ACE héritée ou explicite ne donne des droits excessifs.

Cas pratique : retirer un ancien groupe

icacls "D:\Projets" /remove "CONTOSO\AncienProjet"

Pour toute l’arborescence si cela est réellement nécessaire :

icacls "D:\Projets" /remove "CONTOSO\AncienProjet" /T /C

Avant une opération récursive massive :

icacls "D:\Projets\*" /save "C:\Backup\acl-before-cleanup.txt" /T /C

est une assurance raisonnable.

Cas pratique : retrouver les références à un ancien SID

icacls sait rechercher un SID :

icacls "D:\Partages\*" /findsid *S-1-5-21-123456789-123456789-123456789-1042 /T

Le :

*

devant un SID numérique indique à icacls qu’il s’agit d’un SID littéral.

C’est particulièrement utile après :

• migration ;
• suppression de comptes ;
• restructuration Active Directory.

Cas pratique : reprendre possession puis restaurer une ACL propre

Supposons qu’un ancien dossier soit inaccessible.

Une procédure de récupération peut commencer par :

takeown /F "D:\Archives\AncienProjet" /A /R /D Y

Puis ajouter le groupe administratif approprié :

icacls "D:\Archives\AncienProjet" /grant "CONTOSO\File-Admins:(OI)(CI)(F)" /T /C

Ensuite, reconstruisez les ACL métier.

Évitez de laisser :

AdministrateurPersonnel → Full Control

comme solution définitive sur tout le serveur simplement parce qu’elle a permis la récupération.

Cas pratique : tester avant de supprimer un accès

Avant de retirer un groupe important :

CONTOSO\DL_Finance_Modification

identifiez :

• ses membres ;
• les utilisateurs concernés ;
• les autres groupes leur fournissant éventuellement des droits ;
• le partage SMB ;
• les accès effectifs.

Supprimer une ACE puis attendre que les utilisateurs téléphonent constitue bien une méthode de découverte des dépendances.

Simplement pas celle recommandée.

Les erreurs classiques

« Deny gagne toujours »

Trop simplifié.

Retenez plutôt l’ordre canonique :

Explicit Deny
Explicit Allow
Inherited Deny
Inherited Allow

et l’évaluation droit par droit.

Donner Full Control pour permettre l’écriture

Utilisez généralement :

Modify

si l’utilisateur doit gérer le contenu sans administrer la sécurité.

Utiliser Deny partout

Le refus implicite existe déjà.

N’accordez que ce qui est nécessaire.

Croire que /reset supprime tous les droits

/reset remet les ACL héritées par défaut.

Il peut donc réintroduire des droits provenant du parent.

Utiliser /grant sans examiner les ACE existantes

/grant n’efface pas automatiquement toutes les anciennes autorisations du principal.

Utilisez :

/grant:r

lorsque vous voulez remplacer ses autorisations explicites.

Oublier (OI)(CI)

Résultat :

le dossier possède votre belle ACL.

Les fichiers dessous continuent leur propre carrière administrative.

Refuser seulement Delete pour empêcher toute suppression

Le droit :

DELETE_CHILD

du dossier parent peut également autoriser la suppression.

Confondre NTFS et partage SMB

En accès réseau, les deux interviennent.

En accès local, la couche de partage SMB n’est pas celle qui décide.

Croire qu’Administrateur contourne toujours NTFS

Un administrateur peut devoir prendre possession puis modifier la DACL.

Déplacer un fichier et supposer qu’il reprend forcément les ACL du nouveau dossier

Un déplacement dans le même volume peut conserver les permissions existantes.

Vérifiez après une réorganisation sensible.

Attribuer les ACL directement aux personnes

Utilisez des groupes dès que possible.

Casser l’héritage sur tous les sous-dossiers

Vous créez une arborescence impossible à maintenir.

Modifier les ACL système pour résoudre une application

Le fait qu’une application fonctionne après :

Everyone : Full Control

ne prouve pas que c’était la solution.

Cela prouve uniquement qu’elle avait un problème d’accès.

Checklist avant une modification importante

1. Identifier le dossier exact.
2. Afficher son ACL avec icacls.
3. Identifier les ACE héritées et explicites.
4. Identifier les groupes concernés.
5. Vérifier les droits du partage SMB si l’accès est réseau.
6. Sauvegarder les DACL avant une opération massive.
7. Modifier les groupes plutôt que les utilisateurs lorsque possible.
8. Éviter les Deny sauf véritable besoin.
9. Tester les droits effectifs avec un compte représentatif.
10. Documenter l’exception si l’héritage est interrompu.

Une stratégie de permissions maintenable

Pour un dossier métier :

D:\Partages\Finance

une architecture propre peut être :

SYSTEM
→ Full Control

Administrateurs fichiers
→ Full Control

DL_Finance_Modification
→ Modify

DL_Finance_Lecture
→ Read & Execute

Puis :

Alice
Bob
Chloe
↓
groupes métier
↓
groupes d'accès
↓
ACL

Cette architecture est plus facile à :

• auditer ;
• documenter ;
• modifier ;
• automatiser ;
• dépanner.

Tableau récapitulatif des permissions standards

Permission	Lire	Écrire	Exécuter	Supprimer	Modifier ACL
Lecture	Oui	Non	Non	Non	Non
Lecture et exécution	Oui	Non	Oui	Non	Non
Écriture	Partiellement selon droits	Oui	Non	Non par lui-même	Non
Modification	Oui	Oui	Oui	Oui	Non
Contrôle total	Oui	Oui	Oui	Oui	Oui

Tableau récapitulatif icacls

Commande	Fonction
icacls chemin	Afficher la DACL
/grant	Ajouter des autorisations explicites
/grant:r	Remplacer les autorisations explicites du principal
/deny	Ajouter un refus explicite
/remove	Retirer les ACE d’un principal
/reset	Revenir aux ACL héritées par défaut
/inheritance:e	Activer l’héritage
/inheritance:d	Désactiver en copiant les ACE héritées
/inheritance:r	Désactiver et retirer les ACE héritées
/save	Sauvegarder des DACL
/restore	Restaurer des DACL sauvegardées
/setowner	Changer le propriétaire
/findsid	Rechercher un SID dans les DACL
/verify	Vérifier certaines incohérences d’ACL
/T	Traiter récursivement les descendants
/C	Continuer malgré certaines erreurs

Les concepts vraiment importants

Concept	À retenir
SID	Identité interne d’un utilisateur ou groupe
ACE	Une règle individuelle Allow, Deny ou Audit
DACL	Détermine les accès autorisés et refusés
SACL	Détermine certains audits de sécurité
Héritage	Transmet les ACE aux descendants selon leurs indicateurs
Explicite	Défini directement sur l’objet
Propriétaire	Possède notamment la capacité de modifier la DACL
Accès effectif	Résultat réel après groupes, ACE et héritage
Permission SMB	Couche supplémentaire lors d’un accès via un partage réseau

La méthode à retenir

Lorsque :

« Alice n’arrive pas à ouvrir le fichier. »

ne commencez pas immédiatement par :

icacls fichier /grant Alice:(F)

Procédez plutôt ainsi :

1. Identifier l'utilisateur réel
2. Vérifier ses groupes
3. Vérifier la DACL
4. Distinguer explicite et hérité
5. Identifier les Deny éventuels
6. Vérifier le partage SMB si accès réseau
7. Calculer ou tester l'accès effectif
8. Corriger au niveau du groupe approprié
9. Tester avec le compte concerné

Une permission fonctionne rarement mieux parce qu’on lui ajoute :

Full Control

jusqu’à ce que l’erreur disparaisse.

Elle fonctionne mieux lorsque l’on sait quelle permission manquait réellement.

Conclusion : NTFS n’est pas compliqué, il est précis

Les permissions NTFS deviennent pénibles lorsqu’on essaie de les réduire à :

Lecture
Écriture
Refus
Terminé

Le véritable modèle est plus riche :

Utilisateur
+
Groupes
+
Jeton d'accès
+
SID
+
DACL
+
ACE
+
Allow / Deny
+
Explicite / hérité
+
Ordre canonique
+
Propriété
+
Permission de partage éventuelle
↓
Accès effectif

Une fois cette logique comprise, la plupart des comportements qui semblaient absurdes commencent à devenir explicables.

Retenez surtout :

• attribuez les permissions à des groupes plutôt qu’à des personnes ;
• préférez Modify à Full Control pour les utilisateurs ordinaires ;
• utilisez l’héritage plutôt que dupliquer des milliers d’ACE ;
• réservez les Deny explicites aux véritables exceptions ;
• ne résumez pas le modèle par « Deny gagne toujours » ;
• n’oubliez pas que DELETE et DELETE_CHILD peuvent tous deux intervenir dans la suppression ;
• n’utilisez pas /reset en pensant qu’il efface simplement toutes les permissions ;
• vérifiez les ACL après un déplacement ou une migration ;
• pour un partage réseau, examinez à la fois SMB et NTFS ;
• sauvegardez les ACL avant une opération récursive importante ;
• et testez les droits effectifs plutôt que de déduire leur résultat à l’œil.

Le bon administrateur ne résout donc pas :

Accès refusé

avec :

Everyone : Full Control

Il détermine :

qui doit accéder à quoi, pour quelle opération, par quel chemin et grâce à quel groupe.

Après quoi Windows fait généralement exactement ce qu’on lui demande.

Et lorsqu’il refuse toujours l’accès, il reste une dernière possibilité statistiquement très crédible :

vous étiez en train de modifier les permissions du mauvais dossier.