NTFS & partage SMB : pourquoi vos droits changent après avoir créé puis supprimé un partage (Windows Server 2022)

Vous avez partagé un dossier sur un Windows Server 2022, puis vous avez supprimé ce partage — et, surprise, les droits NTFS n’ont plus rien à voir avec l’état d’origine. Voici pourquoi cela arrive, comment l’éviter, et comment réparer proprement.

Sommaire

Contexte et symptôme

Sur un serveur membre d’un domaine :

Avant : l’ACL du dossier contient par exemple SYSTEM, Administrateurs (local), Utilisateurs, CREATOR OWNER, etc.
Après avoir partagé puis « Arrêter le partage » : l’ACL ne montre plus que SYSTEM, Administrateurs (local), Administrateur (domaine), parfois d’autres entrées « autorisées par l’assistant ».

La croyance courante est que « supprimer un partage remettra les ACL NTFS comme avant ». En réalité, c’est l’inverse : un partage n’a aucune obligation de restituer votre ACL NTFS d’origine, parce que les deux couches (partage SMB et NTFS) sont indépendantes par conception.

NTFS et Partage SMB : deux couches distinctes

Quand on accède à un dossier via le réseau (SMB), l’autorisation effective est l’intersection des permissions de partage et des permissions NTFS :

Les permissions de partage (ex. « Tout le monde : Lecture », « Utilisateurs authentifiés : Contrôle total ») sont évaluées en premier.
Les permissions NTFS (DACL) s’appliquent ensuite, pour tout accès local ou réseau.

Du point de vue du système, arrêter un partage revient simplement à retirer la porte d’entrée réseau. En soi, cela ne modifie pas l’ACL NTFS. Ce sont donc des actions effectuées au moment de la création du partage qui ont pu changer l’ACL — pas le fait de supprimer le partage.

Ce qui se passe vraiment quand on utilise les « assistants »

Plusieurs interfaces de Windows Server permettent de créer un partage : Explorateur (onglet Partage), Server Manager (Assistant SMB Share — Quick/Advanced), Gestion de l’ordinateur > Dossiers partagés, ou encore PowerShell (New-SmbShare). Certaines de ces interfaces proposent d’ajuster NTFS pour vous quand vous demandez « accès en modification », « accès en lecture/écriture », etc.

En clair : si, dans un assistant, vous cochez « autoriser la modification aux Utilisateurs », il y a de grandes chances qu’il ajoute ou retire des ACE NTFS pour coller au scénario demandé (par exemple ajouter Utilisateurs : Modification, ou remplacer Tout le monde par Utilisateurs authentifiés, ou encore convertir/rompre l’héritage). Quand vous arrêtez ensuite le partage, l’assistant ne revient pas sur ces changements NTFS, puisqu’il ne mémorise pas votre ACL d’origine.

Action dans l’UI	Impact réel	Ce qui surprend
« Partager ce dossier » > donner Lecture/Écriture aux utilisateurs	Modifie les permissions de partage et peut modifier NTFS (selon l’assistant)	On croit n’avoir touché qu’au partage, alors que l’ACL NTFS a changé
« Arrêter le partage »	Supprime l’accès SMB (la porte réseau). NTFS reste tel quel.	On s’attend à un « rollback » NTFS… qui n’existe pas

Pourquoi voit‑on disparaître des ACE comme « Utilisateurs » ou « CREATOR OWNER » ?

Deux mécanismes expliquent la « perte » apparente :

Remplacement explicite de l’ACL : l’assistant peut supprimer certaines ACE héritées et ajouter des ACE explicites (par exemple pour Administrateur (domaine)), ou convertir l’héritage en ACE explicites. On a alors l’impression d’un « nettoyage » agressif.
Propagation par héritage : si le changement a eu lieu sur un dossier parent avec l’option « Remplacer toutes les entrées d’autorisations des objets descendants… », toute l’arborescence est touchée. D’où l’impression d’une « perte massive » de droits.

CREATOR OWNER en particulier est une ACE spéciale utile pour donner des droits étendus au créateur d’un fichier sans lister des comptes nominativement. Si l’assistant retire cette ACE (ou casse l’héritage), vous perdez ce comportement.

Bonnes pratiques : séparer les rôles et versionner vos ACL

La stratégie la plus robuste est de conserver NTFS comme source de vérité et de régler le partage pour ne pas s’y opposer inutilement :

Concentrez la sécurité dans NTFS : définissez précisément les droits sur les groupes AD (RBAC), laissez l’ACL refléter la politique d’accès.
Simplifiez les permissions de partage : très souvent, un Contrôle total pour Utilisateurs authentifiés (ou Tout le monde selon la politique) est acceptable, car NTFS filtrera de toute manière. Réduisez les permissions de partage uniquement si vous avez un cas d’usage clair (ex. réducteur global pour un partage spécial).
Évitez les assistants qui « aident » NTFS : créez les partages avec New-SmbShare ou via Gestion de l’ordinateur > Dossiers partagés en vérifiant que vous ne modifiez pas les ACE NTFS.

Exemples PowerShell (partage sans toucher NTFS)

# 1) Créer un partage SMB "Donnees" pour D:\Donnees
New-SmbShare -Name "Donnees" -Path "D:\Donnees" `
  -FolderEnumerationMode AccessBased `
  -EncryptData $true `
  -CachingMode None

# 2) Définir des permissions de PARTAGE (pas NTFS)

Grant-SmbShareAccess -Name "Donnees" -AccountName "Utilisateurs authentifiés" -AccessRight Full -Force
Revoke-SmbShareAccess -Name "Donnees" -AccountName "Tout le monde" -Force

# 3) Laisser NTFS (Get-Acl / Set-Acl) piloter la granularité d'accès

Sauvegarder et restaurer une ACL NTFS (icacls)

Avant toute intervention risquée (changement massif de droits, migration, ajout d’un partage depuis un assistant), exportez l’ACL. En cas de souci, vous pourrez la restaurer fidèlement.

Exporter l’ACL (et sous‑dossiers)

icacls "D:\Données" /save "D:\acl_donnees.bak" /t /c

/t : récursif.
/c : continuer en cas d’erreurs.

Restaurer l’ACL

icacls "D:\" /restore "D:\acl_donnees.bak"

Astuce : la restauration se base sur les chemins enregistrés. Exécutez /restore depuis la racine adéquate (ici D:\) pour que les chemins relatifs retrouvent leurs cibles. Testez d’abord sur une copie.

PowerShell : comparer deux ACL et appliquer

$refPath   = "D:\Données\_ACL_REFERENCE"
$target    = "D:\Données"

$refAcl    = Get-Acl $refPath
$targetAcl = Get-Acl $target

# Diff simple des SDDL

if ($refAcl.Sddl -ne $targetAcl.Sddl) {
Write-Host "ACL différente, mise à jour en cours..."
Set-Acl -Path $target -AclObject $refAcl
}

Pour une granularité fine, comparez les ACE (Access) et traitez les écarts par entrée.

Procédure de réparation en cas de droits « cassés » après un partage

Isoler : tant que l’ACL n’est pas correcte, évitez de réexposer le dossier via SMB.
Inventorier l’existant :
- icacls "D:\Données" /save "D:\post_mortem.bak" /t pour garder une trace.
- Capture d’écran de Paramètres de sécurité avancés (onglet Sécurité), y compris l’héritage.
Restaurer : si vous avez une sauvegarde d’ACL (ou une copie miroir), mesurez l’écart et Set-Acl / icacls /restore. À défaut, recomposez l’ACL à partir de la politique interne (groupes AD, niveaux d’accès, héritage).
Vérifier : testez avec un compte utilisateur lambda et un compte propriétaire; vérifiez les dossiers enfants sensibles; testez l’héritage (Remplacer toutes les entrées… à manier avec précaution).
Réexposer : créez le partage sans modifier NTFS (PowerShell ou Gestion de l’ordinateur), assignez les permissions de partage minimales nécessaires.

Paramètres d’héritage et écueils fréquents

Héritage désactivé par mégarde : les dossiers enfants cessent de refléter la politique du parent. Réactivez l’héritage (ou appliquez « Ajouter les autorisations héritées à cette ACL ») et supprimez prudemment les ACE explicites indésirables.
« Remplacer toutes les entrées… » : utile pour « recaler » une hiérarchie entière, mais destructeur pour les exceptions locales ; sauvegardez toujours avant.
Confusion sur « Tout le monde » : sur les versions modernes de Windows, Tout le monde n’inclut pas l’anonyme par défaut. Beaucoup d’équipes préfèrent Utilisateurs authentifiés pour éviter toute ambiguïté.
CREATOR OWNER absent : réintroduisez‑le si vos workflows l’exigent (typiquement Contrôle total sur sous‑conteneurs et objets), sinon les fichiers créés n’obtiendront pas les droits attendus pour leur propriétaire.

Audit : savoir qui a modifié l’ACL et quand

Activez l’audit pour objectiver les changements et identifier l’outil (assistant, script, administrateur) responsable.

Stratégie d’audit avancée : Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies d’audit avancées > Accès aux objets :
- Audit des changements de permissions de fichier (événements typiques 4670 : « Les autorisations sur un objet ont été modifiées »).
- Audit de l’accès au partage de fichiers (événements 5140+ : création/modification/suppression d’un objet de partage : 5142, 5143, 5144).
SACL : sur le dossier, ajoutez une SACL (onglet Audit) pour pister les changements de permissions et d’accès si nécessaire.

Modèle de gouvernance (RBAC) pour vos partages

Un modèle simple et éprouvé :

Groupes AD par rôle : DATA_RH_LECTURE, DATA_RH_MODIF, DATA_RH_PLEIN…
ACL NTFS sur le dossier racine :
- Administrateurs (local) : Contrôle total (Cette arborescence uniquement).
- SYSTEM : Contrôle total.
- CREATOR OWNER : Contrôle total (sous‑conteneurs et objets).
- DATA_RH_LECTURE : Lecture & exécution (cette arborescence et descendants).
- DATA_RH_MODIF : Modification.
- Évitez d’utiliser directement Utilisateurs ou Tout le monde pour la granularité métier.
Partage SMB : Utilisateurs authentifiés : Contrôle total (ou Lecture si vous tenez à une double barrière), Administrateurs : Contrôle total.

Avec ce schéma, les assistants « facilitateurs » sont superflus. Vous contrôlez votre sécurité dans NTFS, de manière reproductible.

Tableau récapitulatif : quel outil pour quelle action ?

Besoin	Outil recommandé	Impact sur NTFS	Commandes / UI
Créer un partage sans toucher NTFS	PowerShell, Gestion de l’ordinateur	Aucun (si vous n’ouvrez pas l’éditeur d’ACL)	`New-SmbShare`, Dossiers partagés
Sauvegarder/Restaurer une ACL	Ligne de commande	Écrit/Replace DACL	`icacls /save`, `icacls /restore`
Traçabilité des changements	Journal Sécurité + Audit avancé	Aucun (lecture seulement)	Événements 4670, 5142–5144
Déploiement à grande échelle	GPO (File System), DSC, scripts PS	Rejoue la politique d’ACL	Security Settings > File System, `Set-Acl`

Check‑list « zéro surprise » pour vos prochains partages

Décider où vit la vérité : NTFS (recommandé).
Exporter l’ACL : icacls "chemin" /save acl.bak /t.
Créer le partage sans ouvrir la boîte de dialogue NTFS des assistants.
Régler uniquement les permissions de partage nécessaires.
Tester avec des comptes réels (lecture, modification, création/suppression).
Activer l’audit pour documenter toute modification future.

FAQ express

Arrêter un partage restaure‑t‑il les droits NTFS d’origine ?

Non. Supprimer un partage retire l’accès réseau, mais ne recompose pas l’ACL NTFS.

Pourquoi vois‑je « Administrateur (domaine) » ajouté dans l’ACL après un partage ?

Parce que l’assistant a créé une ACE explicite pour correspondre à l’option choisie (par ex. « administration » du partage). Ce n’est pas « magique », c’est une modification NTFS comme une autre.

Vaut‑il mieux « Tout le monde : Contrôle total » au niveau du partage ?

En entreprise, beaucoup optent pour Utilisateurs authentifiés : Contrôle total au niveau du partage, avec toute la restriction dans NTFS. C’est simple, lisible et évite que le partage entre en conflit avec la DACL.

Comment récupérer des ACL perdues ?

Si vous avez un /save d’icacls, un template GPO, une sauvegarde VSS ou un serveur miroir, restaurez. Sinon, reconstituez la DACL depuis la politique interne (groupes AD, héritage, CREATOR OWNER), puis figez‑la dans un script/DSC pour l’avenir.

Étude de cas : reproduction et correction

État initial : SYSTEM, Administrateurs, Utilisateurs : Lecture, CREATOR OWNER.
Création via l’Explorateur : « Partager » > « Lecture/Écriture pour Utilisateurs ». L’assistant ajoute Utilisateurs : Modification en NTFS et peut casser l’héritage.
Suppression du partage : « Arrêter le partage ». L’ACL reste modifiée.
Correction :
- Exporter l’ACL actuelle : icacls "D:\Data" /save D:\acl_now.bak /t.
- Restaurer l’ACL de référence : icacls "D:\" /restore D:\acl_ref.bak.
- Recréer le partage en PowerShell (New-SmbShare), puis Grant-SmbShareAccess sans toucher NTFS.

Points techniques complémentaires utiles

Ordre d’évaluation SMB : Partage ⟶ NTFS. L’accès effectif correspond à la moins permissive des deux couches.
Éviter les entrées nominatives : préférez les groupes AD (RBAC). Les entrées nominatives vieillissent mal et rendent les audits difficiles.
Éviter la double politique contradictoire : si vous restreignez à la fois au partage et à NTFS, documentez précisément qui fait quoi, sinon vous produisez des faux positifs d’« accès refusé ».
ABE (Access‑Based Enumeration) : utile pour masquer les dossiers non autorisés au niveau du partage, sans impact sur les permissions NTFS.
Chiffrement SMB : -EncryptData $true sur le partage ajoute une défense en profondeur sur le réseau, sans toucher aux droits.
Rôles « Administrateurs » vs « Administrateur (domaine) » : l’assistant peut ajouter une ACE explicite inutile. En général, l’appartenance de Domain Admins au groupe local Administrateurs suffit déjà.

Conclusion

Le comportement observé est normal : supprimer un partage ne remet jamais automatiquement les permissions NTFS d’origine. Ce sont les assistants de partage, lorsqu’ils promettent « lecture/écriture », qui modifient parfois l’ACL NTFS. La parade : séparez clairement les couches (partage minimal, NTFS comme vérité), sauvegardez vos ACL avant toute opération, auditez les changements et automatisez la politique via GPO/PowerShell. Ainsi, vous éliminez l’effet de surprise et vous gagnez en traçabilité.