Problemi affrontati
- Le identità degli utenti erano gestite separatamente su ogni sistema, con account locali duplicati e difficili da disattivare.
- I client Linux non disponevano di un modo uniforme per autenticarsi sul dominio e applicare criteri di accesso.
- Il laboratorio doveva essere isolato e ripristinabile, per provare modifiche a GPO e struttura del dominio senza rischi.
- DNS e sincronizzazione dell'orario, prerequisiti di Kerberos, erano una fonte frequente di errori nell'iscrizione dei client.
Soluzione implementata
Su Proxmox VE, in una rete isolata, un controller di dominio Windows Server ospita Active Directory con DNS integrato. Unità organizzative separate dividono utenti, gruppi, computer Windows e computer Linux, e i gruppi seguono il principio del minimo privilegio. I client Windows ricevono i criteri tramite GPO, mentre i client Debian si iscrivono al dominio con realmd e usano SSSD per autenticazione, risoluzione delle identità e controllo degli accessi. L'appartenenza ai gruppi di dominio stabilisce chi può accedere e chi può usare sudo sui sistemi Linux.
Risultati
- Un unico account di dominio consente un accesso coerente ai client Windows e Linux, con disattivazione centralizzata.
- I criteri di accesso e di sicurezza si definiscono in un solo punto e si applicano a tutti i sistemi del laboratorio.
- Gli snapshot riportano il laboratorio a uno stato noto, rendendo sicuro provare modifiche a criteri e struttura.
- La procedura di iscrizione dei client Linux è documentata e ripetibile.
Descrizione tecnica
Il laboratorio riproduce in piccolo un ambiente di dominio misto: un controller di dominio Windows Server e client sia Windows sia Linux che si autenticano con le stesse identità. Serve a provare criteri, accessi e procedure di integrazione prima di applicarli in contesti più delicati.
Architettura del laboratorio
Su Proxmox VE, in una rete isolata dedicata al laboratorio, sono in esecuzione un controller di dominio Windows Server con Active Directory e DNS integrato, un client Windows e uno o più client Debian. Il dominio usa un sottodominio di un nome DNS di cui si ha il controllo; negli esempi si usa ad.example.com. Prima di ogni modifica rilevante a criteri o struttura viene creato uno snapshot delle VM, per poter tornare a uno stato noto. La documentazione del laboratorio riporta la struttura delle OU, i gruppi e la procedura di iscrizione dei client.
Componenti e scelte
- Unità organizzative e gruppi: utenti, gruppi, computer Windows e computer Linux stanno in OU separate. L'accesso ai sistemi dipende dall'appartenenza ai gruppi, secondo il principio del minimo privilegio.
- GPO: i criteri dei client Windows (sicurezza, blocco dello schermo, mappatura delle risorse) sono definiti in modo centrale e applicati per OU.
- DNS e orario: i client usano il controller di dominio come DNS, così da individuare i servizi di dominio, e l'orario è sincronizzato perché Kerberos tollera pochi minuti di scarto.
- SSSD e realmd sui client Debian: realmd automatizza l'iscrizione, SSSD gestisce identità, autenticazione e controllo degli accessi. Il gruppo degli amministratori Linux ottiene
sudocon una regola basata sul gruppo di dominio.
realm discover ad.example.com
realm join --user=amministratore ad.example.com
id utente@ad.example.comNota
L'iscrizione richiede le credenziali di un account autorizzato: vanno inserite in modo interattivo e non scritte in script o file versionati.
Verifiche e collaudo
Dopo l'iscrizione si controllano la risoluzione delle identità (id, getent), l'ottenimento di un ticket Kerberos (kinit, klist), l'accesso con un account di dominio e la creazione della home al primo login. Sul lato Windows si verificano l'applicazione dei criteri (gpresult) e lo stato del dominio (dcdiag). Si prova anche la disattivazione di un account centrale, confermando che l'accesso viene negato su tutti i sistemi. SSSD mantiene una cache delle credenziali per consentire l'accesso anche quando il controller di dominio non è raggiungibile: la durata massima di questa cache è un parametro configurabile, da scegliere in base al rischio accettabile.
Possibili evoluzioni
Un secondo controller di dominio con verifica della replica, la gestione automatica delle credenziali dell'amministratore locale, l'accesso SSH con Kerberos senza digitare credenziali e l'iscrizione dei client automatizzata con Ansible. L'approfondimento è in Active Directory in laboratorio.