Associare un profilo locale Debian a un utente di dominio Samba AD

Guida per collegare la home di un utente locale già esistente su un client Debian all’identità di un utente di dominio, dopo aver completato il join descritto nella guida Unire un client Debian a un dominio Samba AD (NethServer). Include anche il comportamento di default con un utente di dominio nuovo che accede per la prima volta.

Scenario

Un utente locale (es. mario, UID 1000) ha già un profilo funzionante sul client, con i suoi file e le sue configurazioni. Dopo il join al dominio, si vuole che l’utente acceda con le credenziali di dominio continuando a usare lo stesso profilo.

Il problema della collisione dei nomi

Se l’utente locale e l’utente di dominio hanno lo stesso nome breve, con l’impostazione use_fully_qualified_names = False in SSSD il nome breve viene risolto per primo dall’utente locale (che ha priorità nella catena NSS), mascherando l’utente di dominio.

Per evitare ambiguità, quando il nome coincide conviene usare i nomi completi, modificando /etc/sssd/sssd.conf:

[domain/ad.tuodominio.local]
use_fully_qualified_names = True
fallback_homedir = /home/%u

sudo systemctl restart sssd

Con questa impostazione l’utente di dominio viene identificato come mario@ad.tuodominio.local, distinto dall’utente locale mario.

1. Disattivare l’utente locale (senza cancellarlo)

sudo usermod -L mario

Questo blocca la password locale senza eliminare l’account né i file, mantenendo una via di rientro in caso di problemi.

2. Collegare la home esistente all’utente di dominio

Si usa sss_override per associare la home locale all’utente di dominio, senza spostare né rinominare la cartella:

sudo sss_override user-add mario@ad.tuodominio.local -h /home/mario
sudo systemctl restart sssd

Verifica che l’override sia attivo:

getent passwd mario@ad.tuodominio.local

Il campo home deve risultare /home/mario.

3. Assegnare i file al nuovo UID

L’UID dell’utente di dominio è diverso da quello locale, quindi i file vanno riassegnati. Questo passaggio va fatto da un terminale testuale (TTY), con la sessione grafica dell’utente chiusa, per evitare che la sessione in corso perda l’accesso ai propri file.

sudo chown -R mario@ad.tuodominio.local:"domain users@ad.tuodominio.local" /home/mario

In alternativa, usando gli ID numerici (ottenibili con id mario@ad.tuodominio.local):

sudo chown -R UID:GID /home/mario

4. Riassegnare i gruppi locali

L’utente di dominio non eredita automaticamente i gruppi locali dell’utente originale (audio, video, stampa, rete, ecc.). Vanno aggiunti esplicitamente:

for g in audio video plugdev netdev scanner lpadmin cdrom; do
  sudo gpasswd -a 'mario@ad.tuodominio.local' $g
done

Verifica con:

getent group audio video netdev lpadmin

5. Permessi sudo

Se l’utente locale aveva sudo, va riassegnato esplicitamente a quello di dominio (vedi la guida al join per i dettagli):

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

6. Test del login

Prima di un riavvio completo, è utile testare l’accesso da un secondo terminale:

su - mario@ad.tuodominio.local

Se risponde senza errori di permessi sulla home, si può procedere con il login grafico, scegliendo l’opzione per inserire un utente non elencato e digitando il nome completo (mario@ad.tuodominio.local).

Il portachiavi (keyring) resta sulla vecchia password

Al primo login grafico con le credenziali di dominio può comparire la richiesta “Authentication required — the password you use to log in to your computer no longer matches that of your login keyring”. È normale: il portachiavi di GNOME era cifrato con la vecchia password locale.

Per sbloccarlo basta inserire la vecchia password locale nel campo proposto. Per evitare che la richiesta si ripresenti a ogni accesso, si può poi allineare la password del portachiavi a quella di dominio tramite l’applicazione “Password e chiavi” (Seahorse): tasto destro sul portachiavi “Login” → Cambia password, inserendo la vecchia password locale e impostando quella di dominio come nuova.

Se la vecchia password non è più disponibile, il portachiavi può essere rigenerato (con perdita delle credenziali salvate al suo interno):

mv ~/.local/share/keyrings ~/.local/share/keyrings.bak

Comportamento con un utente di dominio nuovo (primo accesso)

Quando un utente di dominio senza un profilo locale preesistente effettua il primo accesso al client, non serve alcuna associazione manuale: grazie a pam_mkhomedir (abilitato nella guida al join con pam-auth-update --enable mkhomedir), SSSD/PAM crea automaticamente una nuova home vuota al primo login, seguendo il percorso indicato da fallback_homedir in sssd.conf (tipicamente /home/%u, cioè /home/nomeutente@ad.tuodominio.local con i nomi completi attivi, o /home/nomeutente con i nomi brevi).

La nuova home viene popolata con gli scheletri standard di /etc/skel, esattamente come per un utente locale creato con adduser. Non c’è quindi nessun collegamento automatico con profili locali eventualmente già presenti con lo stesso nome: l’associazione a una home esistente, come descritto nei passaggi precedenti, va sempre fatta manualmente caso per caso.

Via di rientro

In caso di problemi, è possibile tornare all’utente locale originale:

sudo usermod -U mario
sudo chown -R 1000:1000 /home/mario