Joining a Debian client to a Samba AD domain (NethServer)

A guide to joining a Debian machine to an Active Directory domain managed by Samba AD on NethServer, using realmd and sssd.

Prerequisites

  • A working Samba AD domain (e.g. on NethServer)
  • A Debian client with working networking
  • A user allowed to join machines to the domain (e.g. administrator)
  • The client’s DNS must be able to resolve the AD domain records

1. Installing the packages

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

During the installation of krb5-user you are asked for the default Kerberos realm: enter it in uppercase, for example: AD.YOURDOMAIN.LOCAL

The next two prompts (Kerberos server and administrative server) can be filled in with the IP or hostname of the domain controller, or left empty: realmd discovers them via DNS anyway.

2. DNS configuration

The client must use a DNS server that can resolve the AD domain records (typically the domain controller itself, or a resolver that forwards requests to it correctly).

Check with:

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

It should return a record similar to:

_ldap._tcp.ad.yourdomain.local service = 0 100 389 dc-name.ad.yourdomain.local.

If the query fails with NXDOMAIN, the problem is almost always DNS: the resolver in use doesn’t know the domain and must be fixed before moving on (see the next section if you use Pi-hole or another local resolver).

Note: local DNS with Pi-hole or another resolver

If your network has a local resolver (e.g. Pi-hole) that clients use as their primary DNS, you need to set up conditional forwarding for the AD domain towards the domain controller, otherwise queries for that domain will fail.

On Pi-hole v6: Settings → DNS → Conditional forwarding, adding a line with the network range, the domain controller IP and the AD domain name.

3. Checking and joining the domain

sudo realm discover ad.yourdomain.local

The output must show type: kerberos and server-software: active-directory. Then:

sudo realm join -U administrator ad.yourdomain.local

You are asked for the join user’s password. When it finishes, check:

sudo realm list

It must show configured: kerberos-member.

4. SSSD configuration

Edit /etc/sssd/sssd.conf to enable automatic home directory creation and, if needed, choose whether to use short or fully qualified usernames (see Linking a local Debian profile to a Samba AD domain user for details).

sudo pam-auth-update --enable mkhomedir

Restart the service after every change:

sudo systemctl restart sssd

5. Final check

id username@ad.yourdomain.local

If it returns UID, GID and groups, the domain user is correctly resolved by the client. You can now test the login from a terminal (su - username@ad.yourdomain.local) or from the graphical login screen, choosing the option to enter a user that isn’t listed.

Sudo permissions for domain users

To grant sudo to a single domain user:

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

For an entire domain group:

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

Troubleshooting

  • realm: command not found: the binary lives in /usr/sbin, which isn’t always in the user’s PATH. Use sudo realm ... or the full path.
  • No such realm found: DNS problem. Check that the client queries a resolver that knows the AD domain.
  • Kerberos errors caused by the clock: the time difference between client and domain controller must not exceed 5 minutes. Check with chronyc tracking.
LinuxDebianActive DirectorySambaNethServer