Delegare i permessi in Windows Server non vuol dire “dare Full Control a un utente e sperare bene”. Vuol dire costruire un modello di accesso che regga nel tempo: gruppi al posto degli account singoli, ACL leggibili, ereditarietà sotto controllo e delega limitata al perimetro necessario. Se la cartella è su un file server con più reparti, il problema non è solo chi può entrare oggi, ma chi riuscirà a mantenere quel set di permessi tra sei mesi senza rompere tutto.
Il punto di partenza è semplice: in Windows i permessi efficaci nascono dall’intersezione tra permessi NTFS, eventuali permessi di condivisione SMB e appartenenza ai gruppi. La regola pratica è sempre la stessa: si progetta il controllo sugli account di gruppo, si evita di assegnare permessi diretti agli utenti, si documenta il motivo della delega e si verifica con un account di test prima di mettere in produzione. Se salti uno di questi passaggi, la cartella “funziona” solo finché nessuno tocca nulla.
Modello corretto: gruppi, non utenti
La delega sensata parte dalla struttura AD o locale: gruppi ben nominati, ruoli separati e nessun privilegio assegnato direttamente ai singoli. Un pattern che funziona bene è questo: un gruppo per chi deve leggere, uno per chi deve modificare, uno per chi deve amministrare la cartella. In ambienti più ordinati si usano anche gruppi annidati o il modello AGDLP, ma il punto operativo non cambia: il file system deve vedere gruppi, non persone.
Un esempio pratico: su `D:\Condivisa\Progetti` puoi concedere lettura al gruppo `GG_Progetti_Read`, modifica a `GG_Progetti_Edit` e controllo completo solo a `GG_Progetti_Admin`. Se domani entra un nuovo tecnico, lo aggiungi al gruppo giusto e non tocchi la ACL della cartella. Questo riduce gli errori e rende più semplice capire chi ha fatto cosa quando salta fuori un accesso anomalo.
Permessi di condivisione e NTFS: chi comanda davvero
Su una share SMB conviene ricordare una cosa che spesso viene dimenticata: i permessi effettivi sono il risultato del livello più restrittivo tra condivisione e NTFS. Se la share consente solo Read ma NTFS dà Modify, l’utente resta bloccato sul Read. Per questo, in molte installazioni mature si semplifica la share lasciando permessi larghi sulla condivisione e si governa tutto con NTFS. È una scelta operativa, non un dogma, ma evita di inseguire due ACL diverse per lo stesso oggetto.
Se vuoi verificare in modo rapido la situazione di una share, puoi usare PowerShell e controllare sia la condivisione sia l’ACL della cartella. Esempio:
Get-SmbShare -Name
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.