UbuntuNext

Joining an Ubuntu machine to a Microsoft Active Directory domain

Most organisations running Ubuntu workstations still rely on a Windows-based directory service somewhere in the stack. Whether the office is in a Parramatta business park or a coworking space in Fortitude Valley, the need to centralise logins, group policies and password resets rarely goes away. Joining Ubuntu to Active Directory lets staff use one set of credentials across laptops, file servers and the corporate VPN, which matters as Australian hybrid workers move between Brisbane offices and Sunshine Coast home setups.

The good news is that modern Ubuntu releases have made this far less painful than it used to be. Realmd and SSSD quietly handle the heavy lifting, and the process looks almost identical on a desktop workstation in Melbourne as it does on a server rack in Perth. The challenge is usually network reachability, DNS alignment and a clear understanding of which Realm object the administrator actually intends to bind against.

Before touching any configuration files, it helps to know what Active Directory really expects from a Linux client. The directory is essentially a Kerberos realm wrapped around an LDAP database, and Ubuntu needs to participate in both layers. Once that mental model clicks, every later step starts to feel logical rather than magical.

A useful first stop for anyone new to mixed-environment administration is the UbuntuNext homepage, which keeps an updated index of beginner walkthroughs alongside more advanced Samba and Kerberos material.

Understanding what Active Directory actually asks of Ubuntu

Active Directory is not a single protocol. It is a layered service that uses DNS to locate domain controllers, Kerberos for ticket-based authentication, and LDAP for directory queries. When a Windows machine joins a domain, it is silently registering itself in DNS, generating a machine account, and trusting the realm's Kerberos key distribution centre. Ubuntu has to perform the same dance, but with separate tools that each handle one part.

The realm name is usually based on the DNS domain, so an organisation operating under example.com.au will likely run a Kerberos realm called EXAMPLE.COM.AU. Case matters here — Kerberos conventions are uppercase, while DNS follows any casing the administrator chose. Treating the realm as case-sensitive early on saves debugging time later, especially when scripts are involved.

Australian businesses that run hybrid Azure AD environments also need to decide whether they are joining on-premises, joining through Azure AD Connect, or enrolling into Intune-managed cloud identities. The procedures below focus on the classic on-premises join, which remains common in government agencies bound by the Australian Government Information Security Manual and the Essential Eight maturity model.

Group policy from a Windows server does not apply to Ubuntu through Group Policy itself. Instead, administrators rely on SSSD's ability to read group membership, host-based access control and sudo rules from the directory. Think of the result as policy-equivalent information surfaced through familiar Linux tools.

Preparing the network and prerequisites

The single most common reason a join fails is DNS misalignment. Ubuntu must resolve the Active Directory domain to find a domain controller, which means the network adapter has to point at a DNS server that hosts the AD zone. In Australian deployments using NBN-based business connections, this usually means statically setting DNS to the domain controller rather than relying on the ISP's resolver.

A short checklist before installation:

Time synchronisation deserves extra attention in regional areas where NBN routing sometimes adds latency. Installing chrony and pointing it at the domain controller solves most clock-drift complaints that surface after lunch in Perth when European shifts hand over.

Administrator credentials are also required. A standard Domain User account usually cannot create machine accounts without delegation, and a Domain Admin login is overkill on production networks. Many Australian managed-service providers create a dedicated service account just for Linux joins, which simplifies auditing under the Notifiable Data Breaches scheme.

Installing the required packages

Ubuntu ships most of the prerequisites in the standard repositories, so no third-party PPAs are needed. A single apt command pulls in realmd, sssd, sssd-tools, krb5-user, samba-common-bin, adcli and the optional packagekit. Together these packages provide discovery, enrolment and ongoing identity resolution.

The terminal sequence looks like this on a fresh 22.04 or 24.04 install:

sudo apt update
sudo apt install realmd sssd sssd-tools krb5-user samba-common-bin adcli

During the install, the KDC prompt will appear and ask for the default realm. Resist the urge to skip it; entering EXAMPLE.COM.AU here saves a later edit to /etc/krb5.conf. If the field is left blank, the configuration will fail to negotiate a Kerberos ticket for any domain user.

After the install completes, run realm discover to confirm that realmd can see the directory. The output should list one or more domain controllers along with their software versions and supported features. If the result is empty, the problem is almost always DNS rather than credentials, and the fix is rarely more packages.

On a Sydney-managed laptop moving between offices, running the discover step on-site at each location also helps verify whether the firewall is permitting AD traffic across both the head office and any branch site-to-site links.

Configuring Kerberos and joining the realm

With packages in place, the actual join is a single command. The realm utility accepts a fully qualified administrator name, the realm itself and any optional organisational unit structure:

sudo realm join --user=administrator EXAMPLE.COM.AU

Behind the scenes, realmd calls adcli to create the computer account, registers the Service Principal Names, populates the keytab and rewrites SSSD configuration. The whole sequence usually finishes within a few seconds on a healthy network.

For more complex Australian deployments, especially those that push workstations to a specific OU such as OU=Linux,OU=Workstations,DC=example,DC=com,DC=au, the command becomes:

sudo realm join --user=svc-join \
  --computer-ou="OU=Linux,OU=Workstations" \
  EXAMPLE.COM.AU

After joining, edit /etc/sssd/sssd.conf to control which attributes are cached, whether home directories are auto-created and whether legacy LDAP fallback is enabled. A small but effective change is to set use_fully_qualified_names = True, which prevents accidental username collisions between local and domain accounts on shared developer hosts.

Restart SSSD with sudo systemctl restart sssd, then confirm the service is active and free of errors. Domain users should now appear in getent passwd for any account that has logged in at least once.

Verifying that logins and sudo rules actually work

Joining the realm rarely completes the work. Admins in Melbourne and Adelaide often report that the join reports success, yet users still see "authentication failure" when they try to log in graphically. Verification has to cover three layers: Kerberos tickets, NSS resolution and PAM behaviour.

Begin with a ticket request as a test user:

kinit test.user@EXAMPLE.COM.AU
klist

The list output should show a TGT issued by the realm's KDC. If kinit complains about an unknown realm, the /etc/krb5.conf file is almost certainly pointing at the wrong DNS domain.

Next, run id test.user@EXAMPLE.COM.AU to confirm that SSSD can resolve the account and read its group memberships. A result that lists uid, gid and group entries means the directory layer is healthy. A blank response usually indicates that the SSSD domain section is missing ldap_id_mapping or has an incorrect access_provider.

The final layer is PAM. Using pam-auth-update to enable mkhomedir ensures that domain users automatically receive a home directory under /home/example.com.au/test.user on first login. Australian hot-desking environments benefit enormously from this, since a contractor can sit down at any workstation in a Brisbane innovation hub and instantly have the right shell environment.

Sudo rules require a one-time configuration tweak. Either map specific AD groups to the local sudo group through realm permit, or write explicit %domain\ admins@EXAMPLE.COM.AU ALL=(ALL) ALL lines under /etc/sudoers.d/.

Troubleshooting the common Australian failure modes

A handful of issues appear repeatedly in local support tickets. The first is DNS over the NBN, where residential-grade routers hand out their own DNS rather than the domain controller. Forcing /etc/resolv.conf to point at the corporate resolver or enabling dns=none in NetworkManager usually solves it.

The second is SELinux or AppArmor blocking SSSD from reading the keytab. Running sudo ausearch -m AVC or sudo journalctl -t audit reveals denials that clear up after a relabel. AppArmor profiles shipped with Ubuntu are typically permissive enough, but hardened images from CIS-compliant vendors sometimes need an explicit SSSD rule.

The third is group policy objects that expect Windows-only behaviour. When an organisation enforces SMB signing through Group Policy, Linux clients using older Samba libraries will refuse connections silently. Updating Samba to a version that supports SMB2 signing and pinning the protocol minimum in /etc/samba/smb.conf prevents this.

A surprisingly common Sydney-specific issue is name resolution across the Harbour Bridge VPN tunnels, where one site uses the corp.example.local DNS suffix and another uses corp.example.com.au. Confirming that dns_search includes the correct domain on both networks stops intermittent login failures that look like flakiness but are actually suffix mismatches.

Finally, when a workstation has been joined previously and then removed, a leftover keytab and machine account can confuse re-enrolment. Removing the host from Active Directory, deleting /etc/krb5.keytab and clearing SSSD caches is the cleanest path before attempting a second join.

Keeping the joined Ubuntu workstation healthy over time

Membership in an Active Directory realm is not a one-time event. Password expirations, certificate rotations and group changes all need to propagate, and SSSD does most of this automatically as long as it remains healthy. A weekly check of sudo systemctl status sssd, paired with an inspection of journalctl -u sssd --since "7 days ago", catches credential drift before users start seeing lockouts.

Routine maintenance worth scheduling includes rotating the machine account password via adcli rotate-service-keytab, confirming NTP drift with chronyc tracking, and reviewing /var/log/sssd/*.log for any dp_target_generation slowdowns. On a fleet of laptops that fly between Adelaide and regional mine sites, this small overhead prevents the kind of escalation that ends with a support technician on a plane.

The most reliable single step after the join is complete is to run sudo pam-auth-update once more on each host so that the mkhomedir module is enabled across all entry points, then reboot and log in as a domain user to confirm that the entire session is built on directory credentials rather than cached locals.