Join Linux to Active Directory with realmd and SSSD

Part A (steps 1 to 5) builds ad01. Part B (steps 6 to 11) joins rocky01, and step 12 joins ubu01.

Take snapshots of rocky01 and ubu01 first (VBoxManage snapshot rocky01 take before-l54 and the same for ubu01), and take one of ad01 at the end of step 5. Pick an Administrator password you’ll remember, at least 8 characters with upper case, lower case and digits, because Samba checks complexity.

1Create ad01 and give it its name

On the laptop, create the VM the same way you made ubu01 in Lesson 2, smaller:

VBoxManage createvm --name=ad01 --ostype=Ubuntu_64 --basefolder="C:\Lab\Linux" --register
VBoxManage modifyvm ad01 --memory=1536 --cpus=1 --firmware=bios --graphicscontroller=vmsvga --vram=16 --audio-enabled=off --nic1=natnetwork --nat-network1=LinuxLab --nic-type1=82540EM
VBoxManage createmedium disk --filename="C:\Lab\Linux\ad01\ad01.vdi" --size=15360 --format=VDI
VBoxManage storagectl ad01 --name=SATA --add=sata --controller=IntelAhci --portcount=4
VBoxManage storageattach ad01 --storagectl=SATA --port=0 --device=0 --type=hdd --medium="C:\Lab\Linux\ad01\ad01.vdi"
VBoxManage storagectl ad01 --name=IDE --add=ide
VBoxManage storageattach ad01 --storagectl=IDE --port=1 --device=0 --type=dvddrive --medium="C:\Lab\Linux\ISO\ubuntu-26.04.1-live-server-amd64.iso"
VBoxManage startvm ad01 --type=gui

In the installer use the same answers as for ubu01, except: IPv4 manual with subnet 10.10.10.0/24, address 10.10.10.40, gateway 10.10.10.1, name server 10.10.10.1, search domain corp.saatlab.test; server name ad01; user student; OpenSSH server on. The port forward 2241 to ad01 already exists from Lesson 2, so after the reboot connect from the laptop with ssh -p 2241 student@127.0.0.1 (password for now, keys come later).

On ad01, fix the host name entry and the time zone:

sudo sed -i '/^127\.0\.1\.1/d' /etc/hosts
echo '10.10.10.40  ad01.corp.saatlab.test  ad01' | sudo tee -a /etc/hosts
sudo timedatectl set-timezone Asia/Kolkata
hostname -f
timedatectl | grep -E 'Time zone|synchronized|NTP service'

You should see something like this:

10.10.10.40  ad01.corp.saatlab.test  ad01
ad01.corp.saatlab.test
                Time zone: Asia/Kolkata (IST, +0530)
System clock synchronized: yes
              NTP service: active

A domain controller’s full name must point to its real IP, not to the 127.0.1.1 line the Ubuntu installer adds, or the DNS records Samba creates will be wrong. The time zone is only for your eyes; Kerberos compares clocks in UTC. What matters is “synchronized: yes”, from chrony, which is Ubuntu’s default time service since 25.10.

✅ Checkpoint: hostname -f prints ad01.corp.saatlab.test and the clock is synchronized.

2Install Samba as a domain controller

Run this on ad01:

sudo apt update
sudo apt install -y samba-ad-dc krb5-user bind9-dnsutils

krb5-user asks three questions. Answer CORP.SAATLAB.TEST for the default realm and ad01.corp.saatlab.test for both server questions; the file it writes is replaced in step 3 anyway.

Then switch off the file-server services and get the DC service ready:

sudo systemctl disable --now smbd nmbd winbind
sudo systemctl mask smbd nmbd winbind
sudo systemctl unmask samba-ad-dc
sudo systemctl enable samba-ad-dc
sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.orig
samba --version

You should see something like this (the systemctl lines are cut):

Version 4.23.6-Ubuntu

A Samba DC runs everything from one service, samba-ad-dc, and the normal smbd, nmbd and winbind services must not start beside it. If one of them isn’t installed, systemctl says the unit doesn’t exist; that’s fine. The old smb.conf has to move out of the way because provisioning writes a new one.

✅ Checkpoint: systemctl is-enabled samba-ad-dc prints enabled and systemctl is-enabled smbd prints masked.

3Provision the domain corp.saatlab.test

Run this on ad01:

sudo samba-tool domain provision --use-rfc2307 --realm=CORP.SAATLAB.TEST --domain=SAATLAB --server-role=dc --dns-backend=SAMBA_INTERNAL

The last lines look something like this (the INFO prefix with the date and file name is shortened):

INFO ... Server Role:           active directory domain controller
INFO ... Hostname:              ad01
INFO ... NetBIOS Domain:        SAATLAB
INFO ... DNS Domain:            corp.saatlab.test
INFO ... DOMAIN SID:            S-1-5-21-2918346021-1460372877-3542210589
INFO ... Admin password:        <a random password>

That one command created the AD database, the Kerberos realm, the DNS zone corp.saatlab.test and the Administrator account. Without --adminpass it picks a random Administrator password and prints it, which keeps your password out of the shell history; you set your own below. --use-rfc2307 adds the Unix attribute fields to AD for later use.

Now point Samba’s DNS at the lab resolver for outside names, let ad01 use its own DNS, and start it:

sudo sed -i 's/^\(\s*dns forwarder = \).*/\110.10.10.1/' /etc/samba/smb.conf
sudo grep -E 'dns forwarder|realm|server role|workgroup' /etc/samba/smb.conf
sudo cp /var/lib/samba/private/krb5.conf /etc/krb5.conf
sudo systemctl disable --now systemd-resolved
sudo unlink /etc/resolv.conf
printf 'nameserver 127.0.0.1\nsearch corp.saatlab.test\n' | sudo tee /etc/resolv.conf
sudo systemctl start samba-ad-dc
sudo samba-tool user setpassword Administrator

You should see something like this:

	dns forwarder = 10.10.10.1
	realm = CORP.SAATLAB.TEST
	server role = active directory domain controller
	workgroup = SAATLAB
nameserver 127.0.0.1
search corp.saatlab.test
New Password:
Retype Password:
Changed password OK

Provisioning copied the resolver it found (127.0.0.53, the systemd-resolved stub) as the forwarder, which would loop once resolved is off, so it now forwards to 10.10.10.1. systemd-resolved is stopped because Samba’s DNS server needs port 53 and ad01 should ask itself first. The krb5.conf that Samba generated points Kerberos at this realm.

✅ Checkpoint: systemctl is-active samba-ad-dc prints active and the Administrator password is the one you chose.

4Open ad01’s firewall and test DNS and Kerberos

Switch on ufw on ad01 with SSH and the DC ports, for the lab network only:

sudo ufw allow OpenSSH
sudo ufw allow from 10.10.10.0/24 to any port 53,88,389,445,464,636,3268,3269 proto tcp
sudo ufw allow from 10.10.10.0/24 to any port 53,88,389,464 proto udp
sudo ufw enable
sudo ufw status numbered

Answer y. You should see something like this:

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] OpenSSH                    ALLOW IN    Anywhere
[ 2] 53,88,389,445,464,636,3268,3269/tcp ALLOW IN    10.10.10.0/24
[ 3] 53,88,389,464/udp          ALLOW IN    10.10.10.0/24
[ 4] OpenSSH (v6)               ALLOW IN    Anywhere (v6)

ad01 follows the same rule as ubu01 in Lesson 34: deny everything, then open what the service needs. Linux members need DNS, Kerberos, kpasswd, LDAP (TCP, plus UDP for the discovery ping) and the Global Catalog; 445 is there for Group Policy and Windows clients, 636 and 3269 for LDAP over TLS. A domain with Windows members or a second DC also needs 135, 139 and the RPC range 49152 to 65535, which this lab leaves closed.

Test from ad01 itself:

host -t SRV _ldap._tcp.corp.saatlab.test
host -t SRV _kerberos._udp.corp.saatlab.test
host -t A ad01.corp.saatlab.test
host -t A archive.ubuntu.com
kinit Administrator
klist

You should see something like this:

_ldap._tcp.corp.saatlab.test has SRV record 0 100 389 ad01.corp.saatlab.test.
_kerberos._udp.corp.saatlab.test has SRV record 0 100 88 ad01.corp.saatlab.test.
ad01.corp.saatlab.test has address 10.10.10.40
archive.ubuntu.com has address 185.125.190.82
Password for Administrator@CORP.SAATLAB.TEST:
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: Administrator@CORP.SAATLAB.TEST

Valid starting       Expires              Service principal
10/27/26 12:49:05    10/27/26 22:49:05    krbtgt/CORP.SAATLAB.TEST@CORP.SAATLAB.TEST
	renew until 11/03/26 12:49:01

The SRV records are what clients use to find this DC, outside names still resolve through the forwarder, and a Kerberos ticket for Administrator proves the KDC works. Tickets last 10 hours and can be renewed for 7 days, the AD defaults.

✅ Checkpoint: All four host lookups answer and klist shows a krbtgt ticket for CORP.SAATLAB.TEST.

5Create AD users and groups

On ad01, create two users (set a password for each when asked) and two groups:

sudo samba-tool user add meera --given-name=Meera --surname=Iyer
sudo samba-tool user add ravi --given-name=Ravi --surname=Kumar
sudo samba-tool group add linux-admins
sudo samba-tool group add linux-users
sudo samba-tool group addmembers linux-admins meera
sudo samba-tool group addmembers linux-users meera
sudo samba-tool group listmembers linux-users

You should see something like this:

New Password:
Retype Password:
User 'meera' added successfully
New Password:
Retype Password:
User 'ravi' added successfully
Added group linux-admins
Added group linux-users
Added members to group linux-admins
Added members to group linux-users
meera

meera is a Linux admin and may log in; ravi is an ordinary AD user who is only in Domain Users, so you can test a refusal later. These are AD accounts stored on ad01, not Linux accounts in /etc/passwd. Take the ad01 snapshot now (VBoxManage snapshot ad01 take ad01-ready).

Lesson 33’s SSH hardening isn’t on ad01 yet. Copy your laptop key with ssh-copy-id -p 2241 student@127.0.0.1, then create the same /etc/ssh/sshd_config.d/00-saat-hardening.conf on ad01 and restart ssh, so all VMs are key-only.

✅ Checkpoint: sudo samba-tool user list shows meera and ravi, and listmembers shows meera in linux-users.

6Point rocky01 at ad01 for DNS and check its clock

On rocky01, run this:

sudo nmcli connection modify enp0s3 ipv4.dns "10.10.10.40 10.10.10.1" ipv4.dns-search "corp.saatlab.test saatlab.test"
sudo nmcli device reapply enp0s3
sudo sed -i 's/^10\.10\.10\.40 .*/10.10.10.40  ad01.corp.saatlab.test  ad01.saatlab.test  ad01/' /etc/hosts
cat /etc/resolv.conf
dig +short -t SRV _ldap._tcp.corp.saatlab.test
chronyc -n tracking | grep -E '^(Reference ID|System time)'

You should see something like this:

# Generated by NetworkManager
search corp.saatlab.test saatlab.test
nameserver 10.10.10.40
nameserver 10.10.10.1
0 100 389 ad01.corp.saatlab.test.
Reference ID    : 2D4F0B2C (45.79.11.44)
System time     : 0.000183402 seconds fast of NTP time

ad01 is now the first DNS server, and the SRV lookup works from rocky01. 10.10.10.1 stays second so rocky01 can still reach the internet when ad01 is switched off on a small laptop; at work you would list only AD DNS servers (normally two DCs), because a resolver that doesn’t know the AD zone gives wrong answers. chrony says rocky01 is a fraction of a millisecond off, far inside Kerberos’s 5 minutes.

✅ Checkpoint: dig returns the SRV record for ad01 and the System time offset is well under a second.

7Discover and join the domain from rocky01

Install the packages, look at the domain, then join it:

sudo dnf install -y realmd sssd adcli oddjob oddjob-mkhomedir samba-common-tools krb5-workstation
realm discover corp.saatlab.test
sudo realm join -v -U Administrator corp.saatlab.test

You should see something like this (many join lines are cut):

corp.saatlab.test
  type: kerberos
  realm-name: CORP.SAATLAB.TEST
  domain-name: corp.saatlab.test
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools
 * Resolving: _ldap._tcp.corp.saatlab.test
 * Performing LDAP DSE lookup on: 10.10.10.40
 * Successfully discovered: corp.saatlab.test
Password for Administrator:
 * LANG=C /usr/sbin/adcli join --verbose --domain corp.saatlab.test --domain-realm CORP.SAATLAB.TEST --domain-controller 10.10.10.40 --login-type user --login-user Administrator --stdin-password
 * Calculated computer account name from fqdn: ROCKY01
 * Authenticated as user: Administrator@CORP.SAATLAB.TEST
 * Created computer account: CN=ROCKY01,CN=Computers,DC=corp,DC=saatlab,DC=test
 * Added the entries to the keytab: host/rocky01.saatlab.test@CORP.SAATLAB.TEST: FILE:/etc/krb5.keytab
 * /usr/bin/systemctl enable sssd.service
 * /usr/bin/sh -c /usr/bin/authselect select sssd with-mkhomedir --force && /usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start oddjobd.service
 * Successfully enrolled machine in realm

realm discover found the domain through DNS and lists the packages it needs, which you installed. The join did everything in section 1 to 3 of “How it works”: adcli authenticated as Administrator, created the computer account ROCKY01$, wrote the keytab, and realmd switched PAM to SSSD with home folder creation. Without -v a successful join prints nothing after the password.

✅ Checkpoint: realm list shows corp.saatlab.test with “configured: kerberos-member”.

8Look up AD users from rocky01

Run this:

id meera@corp.saatlab.test
getent passwd meera@corp.saatlab.test
id ravi@corp.saatlab.test
kinit meera@CORP.SAATLAB.TEST
klist

You should see something like this:

uid=1735401103(meera@corp.saatlab.test) gid=1735400513(domain users@corp.saatlab.test) groups=1735400513(domain users@corp.saatlab.test),1735401105(linux-admins@corp.saatlab.test),1735401106(linux-users@corp.saatlab.test)
meera@corp.saatlab.test:*:1735401103:1735400513:Meera Iyer:/home/meera@corp.saatlab.test:/bin/bash
uid=1735401104(ravi@corp.saatlab.test) gid=1735400513(domain users@corp.saatlab.test) groups=1735400513(domain users@corp.saatlab.test)
Password for meera@CORP.SAATLAB.TEST:
Ticket cache: KCM:1000
Default principal: meera@CORP.SAATLAB.TEST

Valid starting       Expires              Service principal
10/27/2026 13:12:40  10/27/2026 23:12:40  krbtgt/CORP.SAATLAB.TEST@CORP.SAATLAB.TEST
	renew until 11/03/2026 13:12:36

rocky01 now knows AD users and their groups without a single local account. The UIDs are large because SSSD calculated them from each SID: the last digits are the AD relative ID (1103 for meera, 513 for Domain Users), the front part is a range picked for this domain. The ticket proves meera’s password works against ad01; on Rocky the ticket cache lives in SSSD’s KCM service rather than a file in /tmp.

✅ Checkpoint: id shows linux-admins and linux-users for meera, only domain users for ravi, and klist shows meera’s ticket.

9Read and adjust sssd.conf

Run this:

sudo cat /etc/sssd/sssd.conf

You should see something like this:

[sssd]
domains = corp.saatlab.test
config_file_version = 2
services = nss, pam

[domain/corp.saatlab.test]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = CORP.SAATLAB.TEST
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = corp.saatlab.test
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad

Three lines are worth knowing by heart. use_fully_qualified_names = True makes user names meera@corp.saatlab.test, so an AD “priya” can never clash with the local priya from Lesson 15; companies with one domain often set it to False so people type only “meera”. fallback_homedir = /home/%u@%d sets the home folder, and ldap_id_mapping = True is the SID-based UID calculation. Any change needs a restart of sssd and, for user details, a cache flush.

Turn off dynamic DNS updates (ad01 doesn’t host the saatlab.test zone that rocky01’s own name is in), check, and restart:

sudo sed -i '/^\[domain\/corp.saatlab.test\]/a dyndns_update = False' /etc/sssd/sssd.conf
sudo sssctl config-check
sudo sss_cache -E
sudo systemctl restart sssd

You should see something like this:

Issues identified by validators: 0

Messages generated during configuration merging: 0

Used configuration snippet files: 0

sssctl catches typos in option names before a restart breaks logins. At work, servers usually have names inside the AD DNS zone and SSSD keeps their A records up to date itself, which is why dyndns_update is on by default.

✅ Checkpoint: sssctl reports 0 issues and id meera@corp.saatlab.test still answers after the restart.

10Allow only one AD group to log in

Run this:

sudo realm permit -g linux-users@corp.saatlab.test
realm list | grep -E 'login-policy|permitted'
sudo grep -E '^(access_provider|simple_allow_groups)' /etc/sssd/sssd.conf

You should see something like this:

  login-policy: allow-permitted-logins
  permitted-groups: linux-users@corp.saatlab.test
access_provider = simple
simple_allow_groups = linux-users@corp.saatlab.test

By default every user in the domain may log in to a joined server, which in a company of 5,000 people is rarely what you want. realm permit -g switches SSSD to the simple access provider with one allowed group. Now test both users as student (not root, so su asks for the password):

su - meera@corp.saatlab.test
id -un; pwd; exit
su - ravi@corp.saatlab.test
sudo journalctl --since "5 min ago" --no-pager | grep 'Access denied'

You should see something like this:

Password:
Creating home directory for meera@corp.saatlab.test.
meera@corp.saatlab.test
/home/meera@corp.saatlab.test
logout
Password:
su: Permission denied
Oct 27 13:20:44 rocky01 su[3402]: pam_sss(su-l:account): Access denied for user ravi@corp.saatlab.test: 6 (Permission denied)

meera’s password was checked against AD and oddjob created her home folder on first login. ravi’s password was right too, but the account check said no, and the log names the PAM service (su-l) and the reason. “Permission denied” after a correct password always means an access rule, not a wrong password.

✅ Checkpoint: meera gets a shell in /home/meera@corp.saatlab.test and ravi gets “su: Permission denied”.

11Give an AD group sudo

Create a rule file for linux-admins the Lesson 16 way, through visudo:

echo '%linux-admins@corp.saatlab.test ALL=(ALL) ALL' | sudo EDITOR='tee' visudo -f /etc/sudoers.d/ad-linux-admins >/dev/null
sudo chmod 0440 /etc/sudoers.d/ad-linux-admins
sudo visudo -c
sudo -l -U meera@corp.saatlab.test | tail -n 2
su - meera@corp.saatlab.test -c 'sudo whoami'

You should see something like this:

/etc/sudoers: parsed OK
/etc/sudoers.d/ad-linux-admins: parsed OK
/etc/sudoers.d/webteam: parsed OK
User meera@corp.saatlab.test may run the following commands on rocky01:
    (ALL) ALL
Password:
[sudo] password for meera@corp.saatlab.test:
root

The % means a group, and the group name is written the way id prints it, lower case with @corp.saatlab.test. sudo asks for meera’s own AD password, and the log line will say meera@corp.saatlab.test ran the command. Full root for an admin group is normal; for other teams, use narrow command lists like the webteam rule. When someone leaves linux-admins in AD, their sudo goes away on every server at their next login.

✅ Checkpoint: sudo -l -U meera@corp.saatlab.test shows (ALL) ALL and sudo -l -U ravi@corp.saatlab.test says ravi may not run sudo.

12Join ubu01 the same way

On ubu01, point DNS at ad01 (the nameservers block of the netplan file from Lesson 32) and fix the hosts line:

sudo sed -i -e 's/search: \[saatlab.test\]/search: [corp.saatlab.test, saatlab.test]/' -e 's/addresses: \[10.10.10.1\]/addresses: [10.10.10.40, 10.10.10.1]/' /etc/netplan/50-cloud-init.yaml
sudo netplan apply
resolvectl dns enp0s3; resolvectl domain enp0s3
sudo sed -i 's/^10\.10\.10\.40 .*/10.10.10.40  ad01.corp.saatlab.test  ad01.saatlab.test  ad01/' /etc/hosts

You should see something like this:

Link 2 (enp0s3): 10.10.10.40 10.10.10.1
Link 2 (enp0s3): corp.saatlab.test saatlab.test

If your nameservers block looks different from Lesson 32’s, edit it by hand so it lists 10.10.10.40 first. systemd-resolved keeps using whichever server answered last, so if AD names stop resolving on ubu01 after ad01 was off, run sudo resolvectl flush-caches or restart systemd-resolved.

Then install, join, switch on home folders, limit logins and add the sudo rule:

sudo apt install -y realmd sssd-ad sssd-tools adcli libnss-sss libpam-sss
sudo realm join -U Administrator corp.saatlab.test
sudo pam-auth-update --enable mkhomedir
sudo sed -i '/^\[domain\/corp.saatlab.test\]/a dyndns_update = False' /etc/sssd/sssd.conf
sudo systemctl restart sssd
sudo realm permit -g linux-users@corp.saatlab.test
echo '%linux-admins@corp.saatlab.test ALL=(ALL) ALL' | sudo EDITOR='tee' visudo -f /etc/sudoers.d/ad-linux-admins >/dev/null
sudo chmod 0440 /etc/sudoers.d/ad-linux-admins
sudo visudo -c
id meera@corp.saatlab.test

You should see something like this:

Password for Administrator:
/etc/sudoers: parsed OK
uid=1735401103(meera@corp.saatlab.test) gid=1735400513(domain users@corp.saatlab.test) groups=1735400513(domain users@corp.saatlab.test),1735401105(linux-admins@corp.saatlab.test),1735401106(linux-users@corp.saatlab.test)

Same UIDs as on rocky01, with nothing configured to make them match: both servers calculate them from the same SIDs. On Ubuntu realmd doesn’t touch PAM’s home folder setting, which is why pam-auth-update --enable mkhomedir is a separate step. The sudo rule works under sudo-rs too, because it only names a group; what sudo-rs can’t do is read sudo rules stored in AD through SSSD.

✅ Checkpoint: su - meera@corp.saatlab.test works on ubu01, su - ravi@corp.saatlab.test says Permission denied, and realm list on ubu01 shows kerberos-member.