Integrating Linux with Active Directory

June 3, 2026 15 min read Systems Administration

linuxactive-directorysssdrealmdkerberosfreeipaidentity

Contents

This is the post the rest of the series was building toward. The earlier pieces explained Active Directory from the outside — the directory itself, Group Policy, Kerberos, and PowerShell — because to integrate Linux with AD you have to understand what AD actually is. Now we make a Linux box authenticate against that directory, so a user’s one corporate identity logs them into Windows desktops, Linux servers, and everything in between. One identity, one password, one place to disable an account when someone leaves. That last point is the real prize: in a mixed shop, the alternative to AD integration is local accounts scattered across every Linux host, which is an offboarding nightmare and an audit failure waiting to happen.

The good news for a Linux admin is that this is your turf. The pieces are Kerberos, LDAP, PAM, and NSS — all things you know — assembled by a daemon called SSSD that does the heavy lifting. You are not learning a Windows technology; you are pointing your familiar identity stack at a directory that happens to be AD.

The two architectures: direct join vs. trust

Before any commands, the fork in the road, because choosing wrong here means rebuilding later.

   OPTION A: DIRECT INTEGRATION (realmd + SSSD)
   --------------------------------------------
        AD  <-----  Linux hosts join the domain directly
       (DCs)        each host is an AD member, SSSD talks
                    straight to the DCs. Simple, no extra infra.
                    Best for: a handful-to-moderate number of
                    Linux hosts in an AD-centric org.

   OPTION B: IPA-AD TRUST (FreeIPA + cross-realm trust)
   ----------------------------------------------------
        AD  <===TRUST===>  FreeIPA  <-----  Linux hosts join IPA
       (DCs)              (IdM realm)         AD users flow in over
                                              the trust; Linux policy
                                              (sudo/HBAC) lives in IPA.
                    Best for: many Linux hosts, Linux-side policy
                    you want managed centrally on the Linux side.

Option A — direct integration. Each Linux host joins the AD domain directly as a member, like a Windows workstation does. realmd performs the join, SSSD handles ongoing authentication and lookups against the DCs. No extra infrastructure, minimal moving parts. This is the right default for most organizations: AD-centric, a moderate number of Linux hosts, no desire to run another identity server.

Option B — FreeIPA with an AD trust. You stand up FreeIPA (Red Hat’s open-source IdM — itself a 389-ds directory plus an MIT Kerberos KDC plus a CA, the Linux-world analogue of AD) and establish a cross-realm Kerberos trust with AD. AD remains the authoritative source of user identities; FreeIPA manages Linux-specific policy (sudo rules, host-based access control, automount, SSH keys) centrally on the Linux side. AD users authenticate through the trust without needing accounts created in IPA. This is more infrastructure but pays off when you have many Linux hosts and want their policy managed from a Linux-native control plane rather than bolted onto AD.

The decision heuristic: few-to-moderate Linux hosts in an AD shop → direct join (Option A). Large Linux estate wanting centralized Linux policy, with AD still owning identities → IPA-AD trust (Option B). Most of this post is Option A because it is what most readers need; the FreeIPA section at the end covers when and why to graduate to Option B.

The cast: realmd, SSSD, and the familiar stack underneath

Two tools you may not know sit on top of four subsystems you do.

realmd is a thin convenience layer that discovers a domain and orchestrates the join — it figures out the domain’s realm, installs the right packages, configures Kerberos and SSSD, and writes the host’s computer account into AD. It does the one-time setup and then mostly gets out of the way.
SSSD (System Security Services Daemon) is the workhorse that runs continuously. It authenticates users against the DC’s Kerberos, looks up users and groups over LDAP, caches credentials and identities (so logins keep working briefly if a DC is unreachable — genuinely important for laptops and flaky links), and feeds the results to the system through PAM and NSS.

Underneath, it is all things you already run: Kerberos (the MIT libraries, talking to the DC as KDC — exactly the protocol from the auth post), LDAP (querying AD’s directory for user/group attributes), PAM (the authentication stack that SSSD plugs into so login, sshd, and sudo consult AD), and NSS (the name-service switch, so getent passwd and id resolve AD users as if they were local). SSSD is the conductor; Kerberos/LDAP/PAM/NSS are the orchestra you already know.

Joining a host: the direct-integration walkthrough

Concretely, joining a RHEL/Ubuntu host to contoso.com. The package names differ slightly by distro but the flow is identical.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# 1. Install the toolkit (RHEL/Fedora family):
sudo dnf install realmd sssd oddjob oddjob-mkhomedir adcli samba-common-tools krb5-workstation
#   (Debian/Ubuntu: apt install realmd sssd sssd-tools adcli krb5-user packagekit)

# 2. PREREQUISITE — DNS and time, the two things that break everything:
#    The host MUST use the AD DNS servers (to find DCs via SRV records),
#    and its clock MUST be within ~5 minutes of the DC (Kerberos requirement).
sudo systemctl enable --now chronyd        # sync time first
resolvectl status                          # confirm DNS points at the DCs

# 3. Discover the domain (sanity check before joining):
realm discover contoso.com
#    Shows the realm, its DCs, and the packages required.

# 4. Join — this creates the host's computer account in AD:
sudo realm join --user=admin_account contoso.com
#    Prompts for the AD admin password; writes /etc/krb5.keytab and
#    configures /etc/sssd/sssd.conf automatically.

# 5. Verify:
realm list                                 # shows the joined domain + config
id alice@contoso.com                        # resolves an AD user to a uid/gids
getent passwd alice@contoso.com             # NSS now sees AD users

If those last two commands resolve an AD user, you are joined: Kerberos is configured, SSSD is running, and NSS/PAM are wired to the directory. The two prerequisites in step 2 are where essentially every failed join actually fails — wrong DNS (host cannot find a DC), or clock skew (Kerberos rejects the join). The earlier posts’ refrain holds: it is always DNS, and then it is the clock. Check both before blaming SSSD.

A user can now ssh alice@contoso.com@linuxhost and authenticate with their AD password. Add pam_mkhomedir (the oddjob-mkhomedir package, enabled with authselect/pam-auth-update) so their home directory is created on first login, and the experience matches logging into a Windows machine.

Two friction points appear immediately, and both have clean answers.

Login names. By default SSSD qualifies usernames with the domain — alice@contoso.com — which is unambiguous but tedious to type. For a single-domain environment you can set use_fully_qualified_names = False in sssd.conf so plain alice works, accepting that this only scales to one domain. Many shops keep the qualified names for correctness; it is a usability-vs-ambiguity trade-off you choose per environment.

POSIX identity — the uid/gid question. This is the conceptually important one. Linux needs every user to have a numeric UID and primary GID; AD users are identified by a SID, not a POSIX uid. Something has to map one to the other, consistently across every host (or alice’s files on server A have a different owner number than on server B, and NFS becomes chaos). Two strategies:

Strategy	How it works	When to use
ID mapping (algorithmic)	SSSD deterministically computes a uid/gid from each user’s SID, the same way on every host	Default; great when AD has no POSIX attributes and you do not need to match pre-existing uids
POSIX attributes from AD	AD stores `uidNumber`/`gidNumber`/`loginShell`/`unixHomeDirectory` on each user; SSSD reads them	When AD already carries POSIX attrs (e.g. RFC2307), or you must match specific uids (legacy NFS, existing files)

SSSD’s algorithmic ID mapping is the modern default and the reason direct join is so painless: it hashes the SID into a uid deterministically, so every host independently computes the same uid for the same user with zero coordination and no schema changes in AD. The catch is that those uids are SSSD’s invention, not anything meaningful to AD — fine for a greenfield Linux fleet, a problem if you have existing files owned by hand-assigned uids you must preserve. In that case you populate the POSIX attributes in AD (modern AD schemas include uidNumber/gidNumber) and set ldap_id_mapping = False so SSSD reads the real attributes instead of computing them. Decide this before you deploy widely, because changing the mapping strategy after files exist means re-owning everything.

Kerberos SSO and GSSAPI for SSH

Here the Kerberos post pays a concrete dividend: once a host is AD-joined and a user has a Kerberos ticket (which they get automatically when they log in via SSSD, or manually with kinit alice@CONTOSO.COM), they can SSH between Linux hosts without typing a password, using GSSAPI — the same single-sign-on that lets a Windows user hit file shares without re-authenticating.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# On the SSH server, in /etc/ssh/sshd_config:
GSSAPIAuthentication yes

# On the client, in ~/.ssh/config or /etc/ssh/ssh_config:
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes      # forward the ticket so the next hop works too

# Now, with a valid ticket (check with klist):
klist                              # shows your TGT and service tickets
ssh otherhost.contoso.com          # logs in via Kerberos, no password

What happens under the hood is exactly the protocol from the auth post: your session holds a TGT; SSH requests a service ticket for host/otherhost.contoso.com from the DC; the server validates it with its keytab; you are in. GSSAPIDelegateCredentials forwards your TGT to the remote host so you can hop further without re-authenticating — convenient, and a thing to use thoughtfully since it leaves your forwardable ticket on each hop (recall the delegation risks from the auth post). This is real SSO across the Linux fleet, built on the AD KDC, and it is one of the more satisfying payoffs of joining — the corporate identity that logs you into Windows now gets you password-lessly between Linux servers too.

Sudo rules from AD

Authenticating AD users is half the job; authorizing them — who can sudo what — is the other half, and you do not want it in a local /etc/sudoers on every host. SSSD can source sudo rules centrally so that “members of Linux-Admins may run all commands on the database servers” is defined once and enforced fleet-wide.

In the direct-join model, the cleanest path is to store sudo rules in AD (AD can hold the sudoRole schema, or you extend it) and point SSSD’s sudo provider at the directory:

1
2
3
4
5
6


# /etc/sssd/sssd.conf — enable the sudo provider
[sssd]
services = nss, pam, ssh, sudo

[domain/contoso.com]
sudo_provider = ad

1
2


# /etc/nsswitch.conf — tell sudo to consult SSSD:
sudo: files sss

Now sudo consults SSSD, which fetches the applicable rules from AD and caches them. A user’s sudo rights follow their AD group membership, managed centrally — disable their account or remove them from Linux-Admins in AD, and their sudo access disappears everywhere at once. This is the offboarding win made concrete: there is no per-host cleanup, because there was never per-host configuration.

In the FreeIPA model below, sudo rules live in IPA natively (IPA was designed to manage Linux sudo/HBAC) and apply to AD users coming over the trust — which is precisely why a large Linux estate often prefers Option B.

Samba: file shares and domain membership

Samba wears two hats in an AD world, and conflating them causes confusion.

As a file server, Samba serves SMB/CIFS shares to Windows and Linux clients, and when joined to AD it authenticates access using AD identities and honors AD group permissions — so a Linux box hosts the departmental file share and Windows users reach it with their normal credentials, ACLs and all. This is the common case: a Linux file server that is a first-class citizen of the Windows file-sharing world.

1
2
3
4
5
6
7
8
9


# /etc/samba/smb.conf — Samba as an AD domain member file server
[global]
   security = ads
   realm = CONTOSO.COM
   workgroup = CONTOSO
   # let Samba and SSSD agree on the same id-mapping so ownership lines up
[share]
   path = /srv/share
   read only = no

The non-obvious gotcha: Samba and SSSD each have their own notion of mapping AD users to uids, and if they disagree, file ownership comes out inconsistent (a file SSSD thinks alice owns, Samba thinks belongs to a different uid). Aligning their ID-mapping configuration — so both compute the same uid for the same SID — is the fiddly part of running Samba alongside SSSD on a joined host. Plan the mapping once and apply it to both.

Samba’s other hat is acting as an AD domain controller itself (Samba can run a compatible AD DC), which is a different and much larger undertaking — relevant if you want an AD-compatible domain without Windows Server at all, but out of scope here. For integration, Samba’s role is the file-server-as-domain-member case above.

FreeIPA with an AD trust: the Option B graduation

When the Linux estate grows past “a handful of servers” into “a real fleet with its own access policies,” bolting everything onto AD starts to chafe — AD’s tooling is Windows-centric, Linux sudo/HBAC/automount management in AD is awkward, and you want a Linux-native control plane. This is when FreeIPA with a cross-realm trust to AD earns its complexity.

The architecture: FreeIPA is its own Kerberos realm and directory (a 389-ds + MIT KDC + Dogtag CA), and you establish a one-way trust where IPA trusts AD. AD stays the authoritative source of user identities — no user accounts are duplicated into IPA. AD users authenticate through the trust (Kerberos cross-realm, with Samba components on the IPA side speaking to AD), and IPA manages the Linux-side policy: HBAC (host-based access control — which users may log into which hosts), sudo rules, SSH keys, automount maps, all from one Linux-native interface. Linux hosts join IPA, not AD directly.

1
2
3
4
5
6
7


# On the IPA server, establish the trust (Samba/winbind components required):
ipa-adtrust-install
ipa trust-add --type=ad contoso.com --admin Administrator --password

# AD users and groups can now be referenced in IPA policy:
ipa sudorule-add-user --groups='Linux-Admins@contoso.com' db-admins-rule
ipa hbacrule-add-user --groups='Developers@contoso.com'   dev-host-access

The payoff: AD users flow in for identity; IPA gives you a clean, Linux-native place to define “who can log into what and run which commands,” including sudo and HBAC rules that reference AD groups directly. The cost: you run another identity server (highly available, ideally), the trust setup has real moving parts (DNS between the realms, Samba on the IPA side), and it is one more system to operate and secure. The trade is centralized, Linux-appropriate policy management for a non-trivial Linux fleet, versus the simplicity of direct join for a small one. Choose Option B when the Linux side is big enough that managing its policy as Linux policy is worth standing up IPA; stay with Option A when it is not.

The honest operational picture

What to expect once any of this is in production:

DNS and time are the perpetual failure modes. Ninety percent of “AD auth broke on this Linux host” is the host drifted off the AD DNS servers or its clock skewed past five minutes. Monitor both; chronyd and correct resolv.conf/systemd-resolved config are not optional.
The SSSD cache is a feature and a footgun. It keeps logins working when a DC blips, which is great — but a stale cache can also serve outdated group memberships or mask a real backend problem. sss_cache -E to invalidate, and know it exists when “I added them to the group but they still can’t sudo” appears (often just cache latency).
ID mapping must be decided before scale. Algorithmic ID mapping vs. POSIX attributes is a one-way-ish door once files exist with assigned ownership. Pick deliberately at the start.
getent and id are your truth-tellers. When debugging, getent passwd user@domain and id user@domain tell you whether NSS resolution works independent of whether login works — splitting “can I see the user” from “can the user authenticate,” which localizes the fault fast. realm list shows the join state; klist shows the ticket situation.
It is your stack, debugged with your tools. Unlike most Windows-adjacent work, when this breaks you debug it with Kerberos, LDAP, PAM, NSS, and journald — the things you already know. SSSD logs verbosely (/var/log/sssd/, bump debug_level) when you ask it to.

The strategic takeaway that closes this series: a mixed fleet does not require choosing between “everything on Windows” and “Linux as a second-class identity island.” With realmd and SSSD for the common case, GSSAPI for genuine SSO, AD-sourced sudo for centralized authorization, Samba for file sharing, and FreeIPA-with-trust when the Linux side grows up — one corporate identity works everywhere, managed from one place, disabled in one place. The earlier posts demystified AD as a distributed Kerberos-and-LDAP directory; this one shows that because it is exactly that, your Linux hosts can be full participants in it using the identity stack you have run all along. The directory may be Microsoft’s, but the integration is home turf.

Sources and further reading

This is the final post in the Windows Server and Active Directory series. From the directory itself through Group Policy, Kerberos, and PowerShell to one identity across a mixed fleet — the enterprise’s identity substrate, demystified for the Linux admin.