NTFS avancé Windows Server 2019 : sécuriser un dossier Warehouse (RDS) — créer/modifier partout, supprimer seulement ses fichiers, contrôler les déplacements

Besoin d’un dépôt commun où chacun peut créer et modifier partout, tout en ne supprimant que ses propres éléments ? Voici une recette NTFS solide pour un dossier « Warehouse » sur Windows Server 2019/RDS, avec scripts prêts à l’emploi, matrice de tests et points d’attention pour éviter les mauvaises surprises.

Sommaire

Contexte et objectifs

Dans un environnement Remote Desktop Services (serveur Terminal 2019), les utilisateurs du groupe Group‑RRG‑WHSusers doivent :

Créer des dossiers/fichiers n’importe où dans l’arborescence.
Modifier tout contenu existant (ouvrir, enregistrer, ajouter des fichiers).
Supprimer uniquement les éléments qu’ils ont eux‑mêmes créés.
Empêcher tout déplacement de dossiers/fichiers en dehors du partage.

Atteindre ces objectifs exige de comprendre deux droits NTFS souvent mal compris : Delete (supprimer l’objet lui‑même) et Delete Child (supprimer un enfant du dossier, visible dans l’interface comme « Delete subfolders and files »). Windows autorise la suppression si au moins l’un de ces deux droits est présent (OR logique). C’est la clef du design.

Principe de la solution

On combine trois idées :

Autoriser la création et la modification partout via des droits d’écriture, mais sans donner « Delete » ni « Delete Child » au groupe.
Donner « Full Control » au CREATOR OWNER sur sous‑dossiers et fichiers uniquement pour que l’auteur puisse supprimer/renommer ses objets.
Désactiver le chemin alternatif de suppression en refusant « Delete Child » sur le dossier racine (le parent), afin qu’un utilisateur ne puisse pas supprimer le fichier d’un autre via le droit du parent.

Ce schéma satisfait les trois premiers objectifs. Le quatrième (empêcher un déplacement hors partage) implique une nuance : un déplacement vers un autre volume est un copier + supprimer source. Si l’auteur a « Delete » sur son propre fichier (via CREATOR OWNER), il pourra déplacer son fichier hors du partage. Bloquer tout déplacement pour tout le monde en pur NTFS revient à refuser « Delete » sur tous les objets… ce qui interdit aussi à l’auteur de supprimer/renommer ses fichiers. On détaillera plus bas les compromis et atténuations possibles (GPO/FSRM/DLP).

Solution technique récapitulative (version fournie)

Voici la synthèse telle que souvent proposée. Elle fonctionne, mais nécessite un réglage fin des portées (voir Mise au point importante juste après) :

Étape	Objet NTFS	Type	S’applique à	Permissions cochées	But
1	Group‑RRG‑WHSusers	Autoriser	Ce dossier, sous‑dossiers et fichiers	Contrôle total	Création + modification partout
2	Group‑RRG‑WHSusers	Refuser	Ce dossier, sous‑dossiers et fichiers	Delete et Delete subfolders and files	Bloquer la suppression « générique »
3	CREATOR OWNER	Autoriser	Sous‑dossiers et fichiers	Contrôle total	Permettre au créateur de supprimer/renommer son propre contenu

Mise au point importante — En NTFS, une ACE Refuser prime sur une ACE Autoriser.

Si l’ACE « Refuser : Delete » (Étape 2) s’applique aux sous‑dossiers et fichiers, elle bloquera aussi le droit « Delete » pourtant accordé au CREATOR OWNER (Étape 3). L’auteur ne pourra alors pas supprimer/renommer ses propres éléments.
Pour que la logique « je ne supprime que ce que j’ai créé » fonctionne, l’ACE Refuser doit empêcher le chemin parent (Delete Child) plutôt que d’interdire le « Delete » sur les objets enfants. Concrètement : limiter le Refuser Delete Child au dossier racine uniquement, et ne pas refuser « Delete» au niveau des objets enfants.

Variante recommandée (robuste et conforme aux objectifs 1–3)

Cette variante ajuste précisément les portées pour respecter l’intention tout en évitant les conflits d’héritage.

Racine du partage (D:\Warehouse)
- Group‑RRG‑WHSusers — Autoriser — Ce dossier, sous‑dossiers et fichiers
  Cochez Read & Execute, List folder contents, Read, Write. Ne cochez pas Delete ni Change permissions ni Take ownership.
- Group‑RRG‑WHSusers — Refuser — Ce dossier uniquement
  Cochez Delete subfolders and files (le parent ne peut pas supprimer ses enfants). Ne refusez pas « Delete » ici.
- CREATOR OWNER — Autoriser — Sous‑dossiers et fichiers uniquement
  Full Control. S’applique uniquement aux enfants (héritage « inherit only »), pas au dossier racine.
- Administrators / SYSTEM — Autoriser — Ce dossier, sous‑dossiers et fichiers
  Full Control (maintenance).

Pourquoi ça marche ?

Un utilisateur ne possède pas « Delete » sur les fichiers d’autrui, et le parent lui refuse « Delete Child » : il ne peut pas supprimer ceux des autres.
En revanche, l’auteur (via CREATOR OWNER) dispose de « Delete » sur ses propres objets : il peut supprimer/renommer les siens.
La création/édition partout demeure possible grâce aux droits d’écriture sans Delete.

Procédure pas‑à‑pas (GUI)

Préparer le partage
- Créez le dossier D:\Warehouse.
- Partagez‑le (SMB). Au niveau partage, deux approches :
  - Simple : Everyone ou Authenticated Users — Full Control, en pilotant la sécurité via NTFS uniquement.
  - Plus restrictive : Group‑RRG‑WHSusers — Change + Read (suffit pour l’usage, l’ACL NTFS fait le reste).
Désactiver l’héritage sur D:\Warehouse
Onglet Security ▸ Advanced → Disable inheritance → Convert inherited permissions into explicit permissions.
Nettoyer
Supprimez les ACE inutiles (ex. Users générique). Conservez Administrators et SYSTEM.
Ajouter les ACE selon la variante recommandée ci‑dessus :
- Group‑RRG‑WHSusers — Allow — This folder, subfolders and files → cochez Read & execute, List folder contents, Read, Write. Décochez Delete.
- Group‑RRG‑WHSusers — Deny — This folder only → cochez Delete subfolders and files.
- CREATOR OWNER — Allow — Subfolders and files only → Full Control.
Ordre et portée
Vérifiez dans Advanced que les ACE Deny apparaissent en tête, que la portée « This folder only » ou « Subfolders and files only » est bien respectée.
Propagation
Si des éléments existent déjà : cochez « Replace all child object permission entries with inheritable permission entries from this object » pour homogénéiser.
Actualisation des jetons
Demandez une déconnexion/reconnexion RDS des utilisateurs (ou klist purge) pour que les nouveaux droits soient pris en compte.

Procédure en ligne de commande (icacls)

Adaptez la lettre du lecteur et le nom du groupe si besoin.

:: Racine du partage
set ROOT=D:\Warehouse
set GROUP=Group-RRG-WHSusers

\:: 1) Désactiver l'héritage et convertir les ACE
icacls "%ROOT%" /inheritance\:d

\:: 2) Nettoyage de base (conservez SYSTEM et Administrators)
\:: \ icacls "%ROOT%" /remove\:g "Users" "Authenticated Users"

\:: 3) Droits de base pour le groupe (lecture+exécution+écriture, sans Delete)
icacls "%ROOT%" /grant "%GROUP%":(OI)(CI)(RX,W)

\:: 4) Refuser Delete Child au parent (ce dossier uniquement)
icacls "%ROOT%" /deny "%GROUP%":(DC)

\:: 5) CREATOR OWNER : Full Control sur enfants uniquement
icacls "%ROOT%" /grant "CREATOR OWNER":(OI)(CI)(IO)(F)

\:: 6) Sécuriser l'administration
icacls "%ROOT%" /grant "SYSTEM":(OI)(CI)(F)
icacls "%ROOT%" /grant "Administrators":(OI)(CI)(F)

\:: 7) Vérification
icacls "%ROOT%"

Commentaires :

(OI)(CI) propagent aux fichiers (Object Inherit) et dossiers (Container Inherit).
(IO) signifie « inherit‑only » (ne s’applique pas au dossier courant).
RX,W apporte la création/modification sans inclure D (Delete).
DC est Delete Child (« Delete subfolders and files »).

Matrice de tests (à exécuter avant mise en prod)

Cas	Acteur	Action	Résultat attendu	Détails/Notes
C1	A (créateur)	Créer un dossier/fichier n’importe où	Autorisé	Création OK (droits Write)
C2	B (autre utilisateur)	Modifier un fichier créé par A	Autorisé	Édition/enregistrement OK
C3	B (autre utilisateur)	Supprimer un fichier de A	Refusé	Pas de Delete sur l’objet et Delete Child refusé au parent
C4	A (créateur)	Supprimer son propre fichier	Autorisé	Via CREATOR OWNER
C5	A (créateur)	Renommer son dossier/fichier	Autorisé	Le renommage exige Delete sur l’objet ou Delete Child sur le parent ; A possède Delete via CREATOR OWNER
C6	B (autre utilisateur)	Renommer un fichier de A	Refusé	Ni Delete sur l’objet, ni Delete Child
C7	A (créateur)	Déplacer son fichier hors du partage (autre volume)	Possible (voir limites)	Copier+Delete : A a Delete via CREATOR OWNER
C8	B (autre utilisateur)	Déplacer un fichier de A hors du partage	Refusé	Pas de Delete et Delete Child refusé

Limites et optimisations

Renommage bloqué ?

Le renommage exige Delete sur l’objet ou Delete Child sur son parent. Si vous refusez « Delete » trop largement (sur les enfants), les utilisateurs ne pourront pas renommer, y compris leurs propres éléments. Solutions :

Ne refusez pas « Delete » sur les enfants ; laissez‑le apporté par CREATOR OWNER pour l’auteur.
Refusez uniquement « Delete Child » au parent (ce dossier uniquement), ce qui empêche la suppression des éléments d’autrui sans bloquer l’auteur.
Au besoin, créez des ACE spécifiques pour protéger des objets modèles (voir plus bas).

Déplacement hors partage

Un « déplacement » vers un autre volume = copier + supprimer. Dans la variante recommandée :

L’auteur peut déplacer son propre fichier (il a Delete via CREATOR OWNER).
Les autres utilisateurs ne peuvent ni le supprimer ni le déplacer (absence de Delete + Delete Child refusé).

Si vous devez interdire tout déplacement, même par l’auteur, cela contredit l’objectif « l’auteur peut supprimer ses fichiers ». Deux options :

Option stricte (verrouillage fort) : refusez « Delete » sur tous les objets. Conséquences : plus de suppression ni de renommage par les utilisateurs. À réserver à des répertoires « dépôt uniquement ».
Option équilibrée (recommandée) : conservez le modèle ci‑dessus et ajoutez des atténuations :
- Stratégies de groupe (GPO) pour restreindre l’UI (désactiver « Couper », menu contextuel, glisser‑déposer) — à valeur surtout dissuasive.
- Surveillance/Audit via FSRM (quotas, rapports) et journaux d’accès NTFS pour tracer les copies.
- Solutions DLP/EDR si la contrainte est réglementaire (empêchements par canal : USB, Cloud, e‑mail, etc.).

Gestion fine dans le temps (dossier modèle intouchable)

Pour un dossier modèle (structure de référence) que personne ne doit supprimer/renommer :

Objet ciblé : le dossier modèle.
Groupe : Group‑RRG‑WHSusers.
Refuser : Write + Delete + Delete Child (ou, plus propre, refuser Delete/Delete Child et conserver juste la lecture si le contenu doit rester accessible).

Bonnes pratiques complémentaires

Documenter en interne les règles pour expliquer les refus attendus (suppression, renommage, déplacement).
Auditer régulièrement les ACL afin de détecter des exceptions involontaires (droits hérités inattendus, ACE ajoutées par des applications).
Sauvegarder l’état des ACL avant modification. Exemple PowerShell ci‑dessous (Export‑Acl « maison »).
Éviter de multiplier les ACE Refuser ; une ACE Refuser mal portée peut bloquer des cas légitimes (ex. renommage par l’auteur).
Tester avec de vrais comptes (créateur vs non‑créateur) et un dossier déjà peuplé pour valider l’impact sur l’existant.

Scripts PowerShell utiles

Exporter et restaurer rapidement des ACL

# Export-Acl : photographie des ACL vers CSV
function Export-Acl {
    param(
        [Parameter(Mandatory)]
        [string]$Path,
        [Parameter(Mandatory)]
        [string]$Csv
    )
    $items = Get-ChildItem -LiteralPath $Path -Recurse -Force -ErrorAction SilentlyContinue
    $list = foreach ($i in @($Path) + $items.FullName) {
        try {
            $acl = Get-Acl -LiteralPath $i
            foreach ($ace in $acl.Access) {
                [pscustomobject]@{
                    Path                = $i
                    IdentityReference   = $ace.IdentityReference.Value
                    AccessControlType   = $ace.AccessControlType
                    FileSystemRights    = $ace.FileSystemRights
                    IsInherited         = $ace.IsInherited
                    InheritanceFlags    = $ace.InheritanceFlags
                    PropagationFlags    = $ace.PropagationFlags
                }
            }
        } catch {
            Write-Warning "ACL non lisible: $i - $($_.Exception.Message)"
        }
    }
    $list | Export-Csv -NoTypeInformation -Encoding UTF8 -Path $Csv
}

# Import-AclCsv : réapplique des ACL à partir d'un CSV (simple illustration)

function Import-AclCsv {
param(
\[Parameter(Mandatory)]
\[string]\$Csv
)
\$rows = Import-Csv -Path \$Csv
foreach (\$group in \$rows | Group-Object Path) {
\$path = \$group.Name
try {
\$acl = Get-Acl -LiteralPath \$path
\# Ici on reconstruit les ACE de base (exemple minimal)
\$acl.SetAccessRuleProtection(\$true, \$false) # désactive héritage, nettoie
foreach (\$r in \$group.Group) {
\$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
\$r.IdentityReference,
\$r.FileSystemRights,
\$r.InheritanceFlags,
\$r.PropagationFlags,
\$r.AccessControlType
)
\$acl.AddAccessRule(\$rule)
}
Set-Acl -LiteralPath \$path -AclObject \$acl
} catch {
Write-Warning "Echec ACL: \$path - \$($\_.Exception.Message)"
}
}
}

Astuce : pour une sauvegarde express des ACL de la racine seulement : Get-Acl D:\Warehouse | Format-List * | Out-File .\Warehouse.acl.txt.

Audit simple des permissions « Delete »

# Lister les objets où le groupe possède un droit Delete (à proscrire)
Get-ChildItem D:\Warehouse -Recurse -Directory -Force | ForEach-Object {
    $acl = Get-Acl $_.FullName
    $acl.Access |
        Where-Object { $_.IdentityReference -match 'Group-RRG-WHSusers' -and $_.FileSystemRights -match 'Delete' } |
        Select-Object @{n='Objet';e={$_.Path}}, IdentityReference, FileSystemRights, AccessControlType
}

FAQ et dépannage

Pourquoi ne pas se contenter d’« Autoriser : Modify » pour le groupe ?

Le niveau Modify inclut Delete. Vous perdriez l’asymétrie voulue (seul l’auteur peut supprimer). Il faut donc personnaliser les droits : « Read/Write/Execute » sans « Delete ».

Un utilisateur ne peut pas renommer ses propres fichiers

Vérifiez que vous n’avez pas placé une ACE « Refuser : Delete » sur les sous‑dossiers et fichiers. Si oui, corrigez en :

Supprimez cette ACE de refus sur les enfants.
Refusez uniquement Delete Child au dossier racine (ce dossier uniquement).
Assurez‑vous que CREATOR OWNER possède bien Full Control sur sous‑dossiers et fichiers.

Le groupe « Group‑RRG‑Tserver » a déjà des refus

Une ACE Refuser sur n’importe quel autre groupe membre l’emportera et cassera la logique. Inspectez les ACE existantes, simplifiez et centralisez la politique sur un groupe unique (Group‑RRG‑WHSusers).

Les nouveaux droits ne s’appliquent pas immédiatement

Les jetons d’accès sont mis en cache par session RDS. Demandez une déconnexion/reconnexion aux utilisateurs (ou klist purge pour vider le cache Kerberos).

Check‑list avant validation

Héritage désactivé et converti.
ACE Deny uniquement au niveau racine (Delete Child : « This folder only »).
CREATOR OWNER Full Control sur « Subfolders and files only ».
Groupe applicatif : droits Write/Read/Execute sans « Delete ».
Administrators/SYSTEM : Full Control.
Plan de test exécuté (création, édition, suppression propre vs suppression d’autrui, renommages, déplacements).

Cas spécial : dossiers « gabarits » figés

Pour des gabarits non modifiables :

Ajoutez une ACE Refuser sur le dossier gabarit pour le groupe : Write + Delete + Delete Child (ou définissez le dossier en lecture seule en pratique).
Placez ces gabarits à la racine pour limiter la complexité d’héritage.

Référence rapide : notions NTFS clés

Terme	Signification	Impact dans ce scénario
Delete	Droit de supprimer l’objet lui‑même	L’auteur en a besoin pour supprimer/renommer ses propres éléments
Delete Child (Delete subfolders and files)	Supprimer un enfant à partir du dossier parent	Doit être refusé au parent pour empêcher la suppression « par le dessus »
CREATOR OWNER	Identité spéciale mappant l’auteur de l’objet	Donne à l’auteur le Full Control sur ses éléments
Héritage	Transmission des ACE du parent aux enfants	À maîtriser finement (« This folder only », « Subfolders and files only », « inherit only »)
Priorité des ACE	Les Deny l’emportent sur Allow	Évitez de refuser « Delete » sur les enfants, sous peine de bloquer l’auteur

Conclusion

En combinant droits d’écriture sans Delete pour le groupe, Full Control pour CREATOR OWNER sur les enfants et un refus ciblé de Delete Child au niveau racine, vous obtenez un dépôt « Warehouse » qui permet de créer/modifier partout, de supprimer uniquement ses propres éléments et qui empêche efficacement la suppression (ou le déplacement) du contenu d’autrui. Pour interdire tout déplacement hors partage, ajoutez des contrôles d’usage (GPO/FSRM/DLP), ou acceptez le compromis fonctionnel entre suppression par l’auteur et blocage de déplacement global.

Rappel opérationnel

Configurer via Security ▸ Advanced pour maîtriser héritage et portées.
Éviter tout Refuser parasite venant d’un autre groupe (ex. Group‑RRG‑Tserver).
Demander une déconnexion/reconnexion RDS pour actualiser les jetons de sécurité.

Annexe — Recette “strict verrouillée” (si vous devez absolument empêcher tout déplacement par tous)

Donnez au groupe des droits Read/Write/Execute sans Delete (comme plus haut).
Refusez aussi « Delete » sur tous les enfants (portée « Subfolders and files ») — attention : plus de suppression/renommage par l’auteur.
Réservez la suppression aux administrateurs via un processus de demande.

À n’utiliser que si les exigences de conformité l’imposent.