Windows Server 2025 / Progettare le autorizzazioni delle condivisioni per reparto

Le autorizzazioni delle cartelle condivise per reparto sono più semplici da gestire quando gli utenti appartengono a gruppi di reparto, questi gruppi entrano nei gruppi di autorizzazione delle risorse e le cartelle concedono accesso a questi ultimi. Il laboratorio separa Sales (Vendite) e Support (Assistenza). Verificherai sia le modifiche consentite nel proprio reparto sia l’accesso negato all’altro.

Separa account, gruppi di reparto e gruppi delle risorse

In un solo dominio, AGDLP significa Accounts → Global groups → Domain Local groups → Permissions: account, gruppi globali, gruppi locali di dominio e autorizzazioni. È un modello iniziale, non l’unica architettura possibile. Gli ambiti dei gruppi di Active Directory permettono di inserire gruppi globali nei gruppi locali di dominio. Questi ultimi appartengono alla directory e non sono i gruppi locali del computer FS1.

Usa FS1 già aggiunto al dominio con un volume del file system NTFS (New Technology File System). L’esercizio sulle autorizzazioni SMB e NTFS spiega i due livelli da configurare; SMB significa Server Message Block. Prima di creare D:\Shares\Sales e D:\Shares\Support, verifica che cartelle e nomi di condivisione non siano già usati. Crea soltanto nuove cartelle vuote del laboratorio, senza sostituire configurazioni di produzione. I nomi degli oggetti nella tabella sono letterali: non tradurre Sales, Support o i nomi dei gruppi.

Crea i gruppi e gli account di prova normali

1. In Utenti e computer di Active Directory apri Lab → LabGroups. Con Nuovo → Gruppo crea i quattro gruppi della tabella: GG con ambito globale e DL con ambito locale di dominio. Scegli per tutti la categoria dei gruppi di sicurezza (Security), non di distribuzione, e mantieni i nomi esatti.
2. In Lab → LabUsers crea sales.user1 e support.user1 con password iniziali diverse, conformi ai criteri effettivi. Se richiedi la modifica al primo accesso, completala accedendo a CLIENT1 prima di verificare le condivisioni.
3. Nelle proprietà di ciascun gruppo globale apri Membri → Aggiungi. Per l’appartenenza di reparto del laboratorio inserisci sales.user1 soltanto in GG_Sales e support.user1 soltanto in GG_Support.
4. Nei Membri di DL_FS_Sales_Modify aggiungi GG_Sales; in DL_FS_Support_Modify aggiungi GG_Support. Il gruppo locale di dominio contiene quindi il gruppo globale, non il contrario.
5. Conferma che nessuno dei due account sia amministratore o membro diretto o indiretto dei gruppi dell’altro reparto. Non rimuovere gruppi predefiniti senza comprenderne la funzione.

Consulta i parametri di creazione e ambito di New-ADGroup. Per la procedura grafica usa Utenti e computer di Active Directory su DC1 o un computer con gli strumenti di amministrazione remota e le autorizzazioni necessarie sulle unità organizzative del laboratorio. Esegui le query seguenti in PowerShell con il modulo ActiveDirectory disponibile. Un cambio di reparto dovrebbe normalmente modificare l’appartenenza ai gruppi di reparto, anziché aggiungere ogni utente a tutti gli elenchi di controllo di accesso (Access Control List, ACL) delle cartelle.

Get-ADGroupMember 'GG_Sales'
Get-ADGroupMember 'DL_FS_Sales_Modify'
Get-ADGroupMember 'GG_Support'
Get-ADGroupMember 'DL_FS_Support_Modify'

Senza -Recursive, Get-ADGroupMember mostra i membri diretti: GG_Sales deve contenere sales.user1, mentre DL_FS_Sales_Modify deve contenere GG_Sales. Lo stesso schema vale per Support. Vedere il gruppo globale nel gruppo della risorsa, invece degli utenti già espansi, è il risultato previsto. Controlla anche le appartenenze indirette prima di provare la separazione degli accessi.

Concedi Modifica NTFS ai gruppi delle risorse

1. Su FS1 apri Proprietà di D:\Shares\Sales → Sicurezza → Avanzate. Registra le voci e i relativi ambiti prima di modificare la configurazione.
2. Solo su questa cartella nuova e vuota, disabilita l’ereditarietà e converti le autorizzazioni ereditate in voci esplicite. Mantieni il Controllo completo necessario per SYSTEM e amministratori. La conversione non elimina le concessioni ampie.
3. Esamina Utenti, Utenti autenticati, Everyone e altri gruppi generici. Rimuovi dalla cartella le autorizzazioni non necessarie, anche quelle di lettura che consentirebbero l’accesso all’altro reparto.
4. Concedi ad AD\DL_FS_Sales_Modify Modifica con ambito sulla cartella, sulle sottocartelle e sui file. Non aggiungere sales.user1 direttamente all’ACL.
5. Ripeti su D:\Shares\Support con AD\DL_FS_Support_Modify. Ogni cartella deve includere soltanto il proprio gruppo della risorsa, oltre alle autorizzazioni amministrative necessarie.

Modifica consente le normali operazioni sui contenuti e non equivale a Controllo completo o alla gestione di tutte le autorizzazioni. Le concessioni Consenti provenienti da più gruppi possono sommarsi. Imposta prima le autorizzazioni necessarie ed elimina gli accessi ampi non richiesti su queste nuove cartelle; non iniziare aggiungendo una voce Nega per l’altro reparto.

Configura le condivisioni e il nome del server

1. Apri Proprietà di D:\Shares\Sales → Condivisione → Condivisione avanzata e condividi la cartella con il nome letterale Sales.
2. In Autorizzazioni concedi Modifica (Change) ad AD\DL_FS_Sales_Modify e mantieni i diritti amministrativi richiesti. Rimuovi gli accessi ampi non necessari per altri utenti; non concedere Controllo completo all’intero dominio.
3. Condividi D:\Shares\Support come Support e concedi Modifica (Change) ad AD\DL_FS_Support_Modify. Controlla le impostazioni predefinite e salva separatamente entrambe le configurazioni.
4. In PowerShell su FS1 esamina percorsi e autorizzazioni con i comandi seguenti. Name e Path devono corrispondere alla tabella. Oltre alle voci amministrative previste, ogni gruppo della risorsa deve avere Allow e Change soltanto sulla propria condivisione.

Get-SmbShare -Name Sales,Support | Select-Object Name,Path
Get-SmbShareAccess -Name Sales
Get-SmbShareAccess -Name Support

Usa \\fs1.ad.example.test\Sales e \\fs1.ad.example.test\Support. Mantieni lo stesso nome del server durante le prove, senza alternare indirizzi IP o alias improvvisati. L’enumerazione basata sull’accesso può nascondere le voci, ma un nome invisibile non dimostra che l’accesso sia negato. Prova anche il percorso diretto della condivisione dell’altro reparto.

Verifica le due identità e l’accesso all’altro reparto

Disconnetti la sessione su CLIENT1 e accedi nuovamente come sales.user1. Controlla whoami, whoami /groups e le connessioni SMB, per evitare di riutilizzare una sessione amministrativa. In Sales crea un file di prova, modificalo, rileggilo ed eliminalo. Prova quindi ad aprire direttamente Support: l’accesso deve essere negato. Ripeti la prova inversa come support.user1 e registra i risultati delle due identità. Se non corrispondono alla tabella, verifica separatamente autorizzazioni di condivisione, ACL NTFS, ereditarietà, appartenenze e credenziali effettive; non mascherare il problema concedendo Controllo completo.

Per simulare un trasferimento, registra le appartenenze iniziali di sales.user1, rimuovi solo questo account da GG_Sales e aggiungilo a GG_Support. Mantieni invariate ACL e altre utenze. Dopo disconnessione e nuovo accesso, l’utente dovrebbe lavorare in Support e perdere l’accesso a Sales nelle condizioni del laboratorio. Ripristina poi esattamente le appartenenze originali, rinnova la sessione e verifica nuovamente lo stato iniziale. Prima della pulizia individua i riferimenti alle autorizzazioni: eliminare prima i gruppi può lasciare identificatori di sicurezza (Security Identifier, SID) non risolti nelle ACL. Conserva cartelle, condivisioni e registrazioni per il successivo esercizio sul file system distribuito DFS.