Unire un client Debian a un dominio Samba AD (NethServer)

Guida per collegare una macchina Debian a un dominio Active Directory gestito da Samba AD su NethServer, usando realmd e sssd.

Prerequisiti

  • Un dominio Samba AD funzionante (es. su NethServer)
  • Un client Debian con rete funzionante
  • Un utente con permessi di join sul dominio (es. administrator)
  • Il DNS del client deve poter risolvere i record del dominio AD

1. Installazione dei pacchetti

sudo apt update
sudo apt install -y realmd sssd sssd-tools adcli samba-common-bin \
  libnss-sss libpam-sss krb5-user packagekit oddjob oddjob-mkhomedir chrony

Durante l’installazione di krb5-user viene chiesto il realm Kerberos predefinito: va inserito in maiuscolo, ad esempio: AD.TUODOMINIO.LOCAL

Le due schermate successive (server Kerberos e server amministrativo) possono essere compilate con l’IP o l’hostname del controller di dominio, oppure lasciate vuote: realmd li scopre comunque via DNS.

2. Configurazione del DNS

Il client deve usare come server DNS uno che sappia risolvere i record del dominio AD (tipicamente il controller di dominio stesso, o un resolver che lo inoltra correttamente).

Verifica con:

nslookup -type=SRV _ldap._tcp.ad.tuodominio.local

Deve restituire un record simile a:

_ldap._tcp.ad.tuodominio.local service = 0 100 389 nome-dc.ad.tuodominio.local.

Se la richiesta fallisce con NXDOMAIN, il problema è quasi sempre il DNS: il resolver in uso non conosce il dominio e va corretto prima di proseguire (vedi la sezione successiva se usi Pi-hole o un altro resolver locale).

Nota: DNS locale con Pi-hole o altro resolver

Se in rete è presente un resolver locale (es. Pi-hole) che i client usano come DNS primario, va configurato un inoltro condizionale per il dominio AD verso il controller di dominio, altrimenti le richieste per quel dominio falliranno.

Su Pi-hole v6: Settings → DNS → Conditional forwarding, aggiungendo una riga con il range di rete, l’IP del controller di dominio e il nome del dominio AD.

3. Verifica e join al dominio

sudo realm discover ad.tuodominio.local

L’output deve indicare type: kerberos e server-software: active-directory. A quel punto:

sudo realm join -U administrator ad.tuodominio.local

Viene richiesta la password dell’utente di join. Al termine, verifica:

sudo realm list

Deve comparire configured: kerberos-member.

4. Configurazione di SSSD

Modifica /etc/sssd/sssd.conf per abilitare la creazione automatica delle home e, se necessario, decidere se usare nomi utente brevi o completi (vedi Associare un profilo locale Debian a un utente di dominio Samba AD per i dettagli).

sudo pam-auth-update --enable mkhomedir

Riavvia il servizio dopo ogni modifica:

sudo systemctl restart sssd

5. Verifica finale

id nomeutente@ad.tuodominio.local

Se restituisce UID, GID e gruppi, l’utente di dominio è correttamente risolto dal client. Il login può ora essere testato da terminale (su - nomeutente@ad.tuodominio.local) o dalla schermata grafica di accesso, scegliendo l’opzione per inserire un utente non elencato.

Permessi sudo per utenti di dominio

Per concedere sudo a un singolo utente di dominio:

echo "nomeutente@ad.tuodominio.local ALL=(ALL) ALL" | sudo tee /etc/sudoers.d/nomeutente-ad
sudo chmod 440 /etc/sudoers.d/nomeutente-ad
sudo visudo -c

Per un intero gruppo di dominio:

echo '%domain\ admins ALL=(ALL) ALL' | sudo tee /etc/sudoers.d/domain-admins

Risoluzione problemi comuni

  • realm: command not found: il binario sta in /usr/sbin, non sempre nel PATH utente. Usa sudo realm ... oppure il percorso completo.
  • No such realm found: problema DNS. Verifica che il client interroghi un resolver che conosce il dominio AD.
  • Errori Kerberos legati all’orologio: lo scarto tra client e controller di dominio non deve superare i 5 minuti. Verifica con chronyc tracking.
LinuxDebianActive DirectorySambaNethServer