Windows Server 2019: permessi NTFS con CREATOR OWNER per impedire eliminazioni altrui e bloccare gli spostamenti

Vuoi dare al team di magazzino piena operatività sui propri file, impedire la cancellazione di file altrui e bloccare lo spostamento fuori dalla share? Ecco una guida completa e collaudata per Windows Server 2019 basata su NTFS e sul ruolo speciale CREATOR OWNER.

Indice

Scenario e obiettivo

L’obiettivo è costruire una cartella condivisa su Windows Server 2019 in cui gli utenti del magazzino possano:

creare e modificare cartelle e file propri e altrui;
non eliminare cartelle o file creati da altri, ma poter eliminare i propri;
non spostare elementi fuori dalla gerarchia mappata (niente “trascinamenti” verso desktop o altre unità).

La soluzione si ottiene con una combinazione precisa di voci Allow/Deny nelle ACL di NTFS, affiancata dall’uso del SID speciale CREATOR OWNER e di alcune impostazioni SMB.

Risultato atteso in breve

Quando un utente crea un file o una cartella all’interno della share, ne diventa proprietario e, grazie a CREATOR OWNER, ha Full Control su quell’oggetto, compresa l’eliminazione. Gli altri membri del gruppo possono lavorare sul file (aprirlo, modificarlo, rinominarlo secondo le regole che vedremo), ma non possono cancellarlo. Gli spostamenti verso cartelle esterne alla gerarchia falliscono perché richiedono il permesso Delete che è negato a livello di gruppo.

Concetti chiave di NTFS da tenere a mente

Non esiste in NTFS un criterio “Se l’utente è proprietario allora Permetti”: lo si ottiene tramite la voce CREATOR OWNER, che applica autorizzazioni ereditate ai nuovi oggetti creati.
Le voci Deny possono bloccare operazioni dirette e indirette (es. Delete può impedire anche la Rinomina in certe condizioni).
La valutazione delle ACL segue l’ordine canonico: esplicite prima delle ereditate, e all’interno di ogni gruppo prima i Deny, poi gli Allow. Questo è il motivo per cui è strategico far sì che il CREATOR OWNER (Allow esplicito sugli oggetti creati) prevalga sul Deny ereditato del gruppo.
Spostare un elemento:
- all’interno dello stesso volume equivale a una rinomina tra directory e richiede Delete sulla voce di origine e Create nella destinazione;
- verso un volume diverso è un’operazione copy + delete, quindi senza Delete la seconda fase fallisce.

Progettazione dei permessi

Questa è la combinazione di ACL che soddisfa i requisiti:

Voce	Identità	Tipo	Si applica a	Diritti	Note operative
1	Gruppo Magazzino	Allow	Cartella radice, sottocartelle e file	Tutti tranne “Delete” e “Delete subfolders and files”	Consente pieno lavoro sugli oggetti, senza possibilità di eliminare.
2	Gruppo Magazzino	Deny	Cartella radice, sottocartelle e file	“Delete” e “Delete subfolders and files”	Blocca la cancellazione di oggetti altrui e lo spostamento fuori dalla share.
3	CREATOR OWNER	Allow	Sottocartelle e file (non la radice)	“Full Control”	Chi crea l’oggetto ne è proprietario e può anche cancellarlo.

Perché funziona: il Deny del gruppo (voce 2) è ereditato dagli oggetti; la voce CREATOR OWNER (voce 3) diventa invece un Allow esplicito sui nuovi oggetti. In fase di controllo accessi, l’Allow esplicito del proprietario prevale sull’eventuale Deny ereditato del gruppo, consentendo all’autore di eliminare i propri elementi senza aprire la cancellazione a tutti.

Procedura passo‑passo con la GUI

Preparazione

Crea un gruppo AD (es. GRPMagazzinoRW_NoDelete) e aggiungi i soli utenti che devono operare nella share.
Crea la cartella radice (es. D:\Dati\Magazzino).
Condividi la cartella come share SMB (es. \\SERVER\Magazzino).
- Permessi di condivisione: Change per il Gruppo Magazzino, Full Control per Administrators. È buona prassi lasciare che sia NTFS a fare il grosso del lavoro.
- Valuta l’attivazione di Access-Based Enumeration se vuoi nascondere cartelle per cui l’utente non ha permessi.

Impostazione pratica delle ACL NTFS

Apri Proprietà ► Sicurezza ► Avanzate sulla cartella radice.
Se servono modifiche sostanziali, disattiva Eredita autorizzazioni. Quando richiesto, scegli Copia per trasformare in autorizzazioni esplicite quelle utili e poi rimuovi gli account superflui (es. Users, Everyone).
Aggiungi (o verifica) le voci seguenti nell’ordine indicato:
- Gruppo Magazzino — Allow su Cartella, Sottocartelle e File: tutti i diritti tranne “Delete” e “Delete subfolders and files”.
- Gruppo Magazzino — Deny su Cartella, Sottocartelle e File: “Delete” e “Delete subfolders and files”.
- CREATOR OWNER — Allow su Sottocartelle e File: “Full Control”.
Clic su OK, quindi Applica.

Verifiche essenziali con un account di test

L’utente membro solo del gruppo deve poter creare cartelle e file, nonché modificarli.
Non deve poter cancellare elementi creati da altri.
Deve poter cancellare i propri elementi (perché ne è proprietario).
Il tentativo di spostare un file fuori dalla gerarchia condivisa deve fallire (il file resta nella share, anche se può essere stata copiata una versione all’esterno).

Rinomina: perché talvolta non funziona e come rimediare

La rinomina richiede il permesso Delete sull’oggetto oppure Delete Subfolders and Files sulla cartella padre. Se neghi Delete a livello di gruppo sui file, la rinomina dei file può fallire anche se l’utente ha il resto dei permessi.

Soluzioni pratiche:

Lasciare “Delete” negato solo sulle cartelle (radice e sottocartelle), ma non sui file: la rinomina dei file torna a funzionare perché non richiede più il permesso bloccato sull’oggetto.
In alternativa, aggiungere un’ulteriore voce Allow per CREATOR OWNER con “Delete” sui file: chi è proprietario potrà rinominare i propri file anche se al gruppo è negato il Delete ereditato.

Prevenire gli spostamenti fuori dalla share

Su volumi diversi il move è copy + delete: il blocco su Delete impedisce la seconda fase, così l’originale resta nella share.
Su stesso volume uno spostamento equivale a una rinomina di percorso: richiede Delete nella directory di origine. Negando Delete sulla cartella radice (e sottocartelle), impedisci spostamenti verso cartelle esterne alla gerarchia.
Con i soli permessi NTFS non puoi impedire la copia. Se la copia dei dati fuori dalla share è un rischio, valuta tecnologie di Data Loss Prevention (DLP), Rights Management, criteri di Endpoint DLP o etichettatura dei documenti.

Automazione con PowerShell

Per ambienti ripetibili o per documentare la configurazione, ecco un esempio di script che imposta le tre voci chiave. Lo script:

disattiva l’ereditarietà sulla cartella radice, preservando le voci utili come esplicite;
concede al Gruppo Magazzino un Allow “quasi completo” (Full Control) e subito dopo un Deny mirato a Delete e Delete Subfolders and Files che rimuove la possibilità di eliminare;
aggiunge CREATOR OWNER: Full Control applicato solo a sottocartelle e file (InheritOnly), così chi crea rimane libero di eliminare i propri oggetti.

# Parametri
$Path  = "D:\Dati\Magazzino"
$Group = "DOMINIO\GRPMagazzinoRW_NoDelete"

Crea cartella se non esiste
if (-not (Test-Path $Path)) { New-Item -ItemType Directory -Path $Path -Force | Out-Null }

ACL attuale
$acl = Get-Acl -Path $Path

Proteggi da ereditarietà, preservando le voci ereditate come esplicite
$acl.SetAccessRuleProtection($true, $true)

Identità
$groupNt        = New-Object System.Security.Principal.NTAccount($Group)
$creatorOwnerSid = New-Object System.Security.Principal.SecurityIdentifier(
    [System.Security.Principal.WellKnownSidType]::CreatorOwnerSid, $null)

1) Gruppo - Allow (quasi completo)
$ruleAllow = New-Object System.Security.AccessControl.FileSystemAccessRule(
    $groupNt,
    [System.Security.AccessControl.FileSystemRights]::FullControl,
    [System.Security.AccessControl.InheritanceFlags] "ContainerInherit, ObjectInherit",
    [System.Security.AccessControl.PropagationFlags]::None,
    [System.Security.AccessControl.AccessControlType]::Allow
)
$acl.AddAccessRule($ruleAllow)

2) Gruppo - Deny (Delete + Delete Subfolders and Files)
$denyRights = [System.Security.AccessControl.FileSystemRights]::Delete `
            -bor [System.Security.AccessControl.FileSystemRights]::DeleteSubdirectoriesAndFiles
$ruleDeny = New-Object System.Security.AccessControl.FileSystemAccessRule(
    $groupNt,
    $denyRights,
    [System.Security.AccessControl.InheritanceFlags] "ContainerInherit, ObjectInherit",
    [System.Security.AccessControl.PropagationFlags]::None,
    [System.Security.AccessControl.AccessControlType]::Deny
)
$acl.AddAccessRule($ruleDeny)

3) CREATOR OWNER - Allow Full Control (solo su sottocartelle e file)
$ruleCO = New-Object System.Security.AccessControl.FileSystemAccessRule(
    $creatorOwnerSid,
    [System.Security.AccessControl.FileSystemRights]::FullControl,
    [System.Security.AccessControl.InheritanceFlags] "ContainerInherit, ObjectInherit",
    [System.Security.AccessControl.PropagationFlags]::InheritOnly,
    [System.Security.AccessControl.AccessControlType]::Allow
)
$acl.AddAccessRule($ruleCO)

Applica
Set-Acl -Path $Path -AclObject $acl

(Opzionale) Condivisione SMB
New-SmbShare -Name "Magazzino" -Path $Path -FullAccess "BUILTIN\Administrators" -ChangeAccess $Group
Grant-SmbShareAccess -Name "Magazzino" -AccountName $Group -AccessRight Change -Force

Nota: concedere Full Control al gruppo e poi negare i diritti di eliminazione produce, in pratica, “quasi completo meno Delete”. Se vuoi evitare che i membri possano modificare le ACL, sostituisci l’Allow di gruppo con un set esplicito di diritti (es. Read & Execute, List Folder, Create, Write, Append ecc.) senza includere Write DAC o Take Ownership.

Schema variante per rinomina più permissiva

Se la rinomina dei file è critica e riscontri blocchi, puoi adottare una variante conservativa:

Deny “Delete” solo sulle cartelle (radice e sottocartelle) e non sui file: la rinomina dei file funziona perché non è più colpita dal Deny sull’oggetto.
Mantieni CREATOR OWNER: Full Control su sottocartelle e file.

In questo modo proteggi la struttura (cartelle) da cancellazioni e spostamenti indesiderati, lasciando più libertà di gestione ai file.

Checklist di test funzionali

Operazione	Utente che è proprietario	Utente non proprietario	Esito atteso
Crea cartella/file	✔	✔	Tutti possono creare nel perimetro autorizzato.
Modifica contenuto	✔	✔	Consentito a tutti i membri.
Rinomina file	✔	✔/✖	Dipende dalla variante adottata (vedi sezione rinomina).
Elimina i propri oggetti	✔	—	Il proprietario può eliminare grazie a CREATOR OWNER.
Elimina oggetti altrui	✖	✖	Bloccato dal Deny ereditato al gruppo.
Sposta fuori dalla share	✖	✖	Fallisce per mancanza di Delete sulla sorgente.

Troubleshooting e casi particolari

Rinomina che fallisce: controlla se il Deny “Delete” colpisce anche i file. Applica la variante suggerita o aggiungi Allow Delete ai file per CREATOR OWNER.
Voci Deny ereditate da altri gruppi: rimuovile o riducine l’ambito. Un Deny in alto nella catena può scavalcare le tue regole.
Token di sicurezza obsoleto: dopo modifiche a gruppi/ACL, esegui log off/log on o klist purge per rigenerare il token dell’utente.
File bloccati da processi: antivirus, indicizzatori o software di sincronizzazione possono mantenere handle aperti impedendo rinomina/eliminazione. Prova da Safe Mode/Tool di sblocco o pianifica l’operazione a servizio arrestato.
Office e file temporanei (~$): non preoccuparti: sono di proprietà del creatore e seguono le stesse regole di eliminazione.
DFS/repliche: assicurati che le ACL siano consistenti sui target. Documenta e applica le modifiche in modo identico su ogni replica.
Offline Files (CSC): i client con cache offline possono completare operazioni in differita; in caso di conflitti, vince la regola del server (il Delete negato porta a fallimento della sincronizzazione della cancellazione).

Audit, controllo e governance

Se vuoi tracciare i tentativi di cancellazione/spostamento:

Abilita i criteri di Audit Object Access (Success/Failure) tramite GPO.
In Proprietà ► Sicurezza ► Avanzate ► Auditing aggiungi il Gruppo Magazzino con auditing su Delete e Delete Subfolders and Files (Sottocartelle e File).
Monitora il registro Security per gli eventi pertinenti (ad es. 4663) su server.

Backup e ripristino delle ACL

Salva e ripristina le ACL come parte della documentazione di sistema:

:: Salvataggio ricorsivo
icacls "D:\Dati\Magazzino" /save "C:\ACL\Magazzino_acl.txt" /t /c

:: Ripristino
icacls "D:\Dati" /restore "C:\ACL\Magazzino_acl.txt"

Mantieni una copia del file ACL assieme al change log, così chi subentrerà capirà perché esistono voci Deny granulari e come sono state applicate.

Domande frequenti

Posso ottenere lo stesso risultato senza Deny?
In NTFS, senza una logica “se proprietario allora permetti”, il Deny mirato sui Delete è il modo più affidabile per vietare la cancellazione da parte di terzi, salvaguardando al contempo la libertà del proprietario sugli oggetti creati.

È meglio usare Permessi di condivisione o NTFS?
I permessi NTFS sono più granulati e stabili. Mantieni i permessi di condivisione semplici (Change per il gruppo, Full per Admin) e demanda il controllo fine a NTFS.

Gli amministratori possono comunque eliminare tutto?
Sì. Gli amministratori possono anche assumere la proprietà di qualunque oggetto. In molti ambienti è un requisito operativo.

Come gestire utenti in più gruppi?
Se un utente appartiene a gruppi con permessi divergenti, assicurati che non esistano Deny indesiderati in altri gruppi. Ricorda l’ordine di valutazione: le voci esplicite prevalgono sulle ereditate.

Come limito la copia fuori dalla share?
NTFS non può impedirla. Servono strumenti DLP/IRM o criteri di endpoint per il controllo dell’esfiltrazione.

Controlli finali consigliati

Rimuovi eventuali voci Deny ereditate (es. gruppi tecnici) che potrebbero avere priorità inattese.
Dopo ogni modifica importante, esegui log off/log on dell’utente di test per rigenerare il token.
Documenta la configurazione (screenshot, esport ACL, script PowerShell) e allega una tabella di responsabilità.

Conclusioni

Con l’accoppiata Allow quasi completo al gruppo, Deny su Delete e Delete Subfolders and Files, e CREATOR OWNER: Full Control su sottocartelle e file, soddisfi tutti i requisiti: gli utenti lavorano liberamente sui propri dati, non possono eliminare quelli altrui e non riescono a spostare contenuti fuori dal perimetro della share. Le varianti proposte ti consentono di affinare il comportamento della rinomina senza sacrificare la protezione della struttura, mentre automazione, audit e backup ACL rendono la soluzione gestibile e sostenibile nel tempo.

Impostazione pratica riassunta

Proprietà ► Sicurezza ► Avanzate sulla cartella radice.
Disattiva Eredita autorizzazioni se ci sono voci ereditate indesiderate; copia quelle utili.
Aggiungi/ordina le tre voci come indicato in tabella (Gruppo Allow quasi completo → Gruppo Deny Delete/DS&F → CREATOR OWNER Full su sottocartelle e file).
Verifica con un account di test:
- creazione/rinomina file e cartelle;
- impossibilità di cancellare elementi altrui;
- possibilità di eliminare i propri elementi;
- fallimento degli spostamenti fuori dalla gerarchia.

Nota tecnica su rinomina
La rinomina richiede Delete sull’oggetto o Delete Subfolders and Files sulla cartella padre. Se il Deny di gruppo include i file, la rinomina può fallire: limita il Deny alle sole cartelle oppure aggiungi Allow Delete ai file per CREATOR OWNER.

Prevenire lo spostamento
Uno spostamento verso un volume diverso è una copia + cancellazione: il Deny su Delete impedisce la cancellazione della sorgente, lasciando il file al suo posto. Per movimenti nello stesso volume, negare Delete nella cartella origine impedisce la rinomina tra directory.

Con questa combinazione di voci Allow/Deny e il ruolo speciale CREATOR OWNER si soddisfano i requisiti richiesti, lasciando agli utenti piena operatività sui propri dati e tutele sull’integrità della struttura condivisa.