Linking a local Debian profile to a Samba AD domain user

A guide to linking the home directory of an existing local user on a Debian client to a domain user identity, after completing the join described in Joining a Debian client to a Samba AD domain (NethServer). It also covers the default behaviour for a brand-new domain user logging in for the first time.

Scenario

A local user (e.g. mario, UID 1000) already has a working profile on the client, with their files and settings. After joining the domain, you want the user to log in with domain credentials while keeping the same profile.

The name collision problem

If the local user and the domain user have the same short name, with use_fully_qualified_names = False in SSSD the short name is resolved first by the local user (which has priority in the NSS chain), masking the domain user.

To avoid ambiguity, when the names match it is better to use fully qualified names, by editing /etc/sssd/sssd.conf:

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

sudo systemctl restart sssd

With this setting the domain user is identified as mario@ad.yourdomain.local, distinct from the local user mario.

1. Disable the local user (without deleting it)

sudo usermod -L mario

This locks the local password without removing the account or its files, leaving a way back in case of problems.

2. Link the existing home to the domain user

Use sss_override to associate the local home with the domain user, without moving or renaming the folder:

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

Check that the override is active:

getent passwd mario@ad.yourdomain.local

The home field must show /home/mario.

3. Assign the files to the new UID

The domain user’s UID differs from the local one, so the files must be reassigned. Do this from a text terminal (TTY), with the user’s graphical session closed, so the running session doesn’t lose access to its own files.

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

Alternatively, using numeric IDs (obtainable with id mario@ad.yourdomain.local):

sudo chown -R UID:GID /home/mario

4. Reassign local groups

The domain user does not automatically inherit the original user’s local groups (audio, video, printing, network, etc.). They must be added explicitly:

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

Check with:

getent group audio video netdev lpadmin

5. Sudo permissions

If the local user had sudo, it must be explicitly granted to the domain user (see the join guide for details):

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

6. Testing the login

Before a full reboot, it’s useful to test the login from a second terminal:

su - mario@ad.yourdomain.local

If it works without permission errors on the home, you can proceed with the graphical login, choosing the option to enter a user that isn’t listed and typing the full name (mario@ad.yourdomain.local).

The keyring stays on the old password

At the first graphical login with domain credentials you may see the prompt “Authentication required — the password you use to log in to your computer no longer matches that of your login keyring”. This is normal: the GNOME keyring was encrypted with the old local password.

To unlock it, just enter the old local password in the field provided. To stop the prompt from reappearing at every login, you can then align the keyring password with the domain one using the “Passwords and Keys” application (Seahorse): right-click the “Login” keyring → Change Password, entering the old local password and setting the domain one as the new password.

If the old password is no longer available, the keyring can be regenerated (losing the credentials stored in it):

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

Behaviour with a new domain user (first login)

When a domain user without a pre-existing local profile logs in to the client for the first time, no manual association is needed: thanks to pam_mkhomedir (enabled in the join guide with pam-auth-update --enable mkhomedir), SSSD/PAM automatically creates a new empty home at first login, following the path set by fallback_homedir in sssd.conf (typically /home/%u, i.e. /home/username@ad.yourdomain.local with fully qualified names enabled, or /home/username with short names).

The new home is populated with the standard skeleton from /etc/skel, exactly like a local user created with adduser. There is therefore no automatic link with any local profile that may already exist under the same name: associating an existing home, as described in the steps above, must always be done manually, case by case.

Way back

If something goes wrong, you can go back to the original local user:

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