AD trust prerequisites and setup
Five things to check before creating a one-way "AD users log in to Linux" trust, the commands, and how to verify lookups. Any one missing makes trust-add fail or user resolution silent.
None of this is needed to install IDMatrix. It is the prerequisite list for the AD trust; prepare it before install and the trust goes up in one pass. Requires the Enterprise licence.
Shape of the trust
IDMatrix establishes a one-way trust: the IPA domain trusts the AD forest, so AD users log in to Linux hosts joined to IPA with their own credentials. IPA users cannot log in to Windows. Nothing is installed on the AD side; AD only gains a trust object and a DNS forwarder to the IPA domain.
AD users get Linux uids / gids mapped from their SIDs. The trust creates <AD domain>_id_range automatically, disjoint from the local ID range. HBAC and sudo rules can reference AD groups through external group mapping.
Not in the picture: sssd caches tickets and HBAC rules, so with AD unreachable an already-cached user still logs in within offline_credentials_expiration (default 0, unlimited); the referral depends on IPA DNS resolving the AD domain, which is why DNS is item 1 of the checklist.
Checklist
1. DNS
Both sides must resolve each other forward and reverse. This is the most common failure.
| Direction | Requirement | How |
|---|---|---|
| IPA to AD | The IPA server resolves the AD domain's SRV records and DC hostnames | After install: ipa dnsforwardzone-add <AD domain> --forwarder <AD DNS IP> --skip-overlap-check |
| AD to IPA | AD domain controllers resolve the IPA server FQDN | Add the IPA A and PTR records to AD DNS, or a conditional forwarder to the IPA domain |
| IPA itself | IPA_HOSTNAME A and PTR agree and are not loopback | Install prerequisite; see Requirements |
Verify:
dig +short _ldap._tcp.<AD domain> SRV @localhost # lists AD DCs
nslookup <AD DC FQDN>
dig +short -x <IPA IP> # returns the IPA FQDN2. Time
IPA and the AD DC within 5 minutes, ideally on the same NTP source. Beyond that every authentication fails with KRB5KDC_ERR_SKEW. Check chronyc tracking and compare date on both sides.
3. AD administrator
An account that can create trust objects on the AD side, normally a domain admin. The password is entered interactively during trust-add and never written to a file.
4. Network
Open both ways between IPA and the AD DCs: 53, 88, 464, 389, 636, 445, 135 and 1024–1300 (RPC dynamic ports). IPA_SETUP_FIREWALLD=true on bare metal only opens IPA's own ports; add the AD ones by hand.
5. IPA side
- adtrust installed via
IPA_SETUP_ADTRUST=true.ipactl statusshowssmbandwinbindRUNNING. IPA_NETBIOSdiffers from the AD domain's NetBIOS name.- The licence includes the AD trust module (Enterprise). Trusts appears under IPA Server in the console only then.
Create the trust
Forward zone to AD
kinit admin
ipa dnsforwardzone-add <AD domain> --forwarder <AD DNS IP> --skip-overlap-check
dig +short _ldap._tcp.<AD domain> SRV @localhost--skip-overlap-check is needed because the AD and IPA domains often share a parent; the overlap check rejects that.
One-way trust
ipa trust-add <AD domain> --type ad --admin <AD admin> --password --range-type=ipa-ad-trustExpect the last line Trust status: Established and verified.
Do not add --two-way=True. A two-way trust needs AD to connect back to IPA for validation, which fails with WERR_CONNECTION_REFUSED in most environments; one-way is enough for "AD users log in to Linux" and more robust.
Verify lookups
ipa trust-show <AD domain>
id <AD user>@<AD domain> # uid / gid / groups; uid inside <AD domain>_id_range
ipa idrange-find # shows the generated <AD domain>_id_rangeThen ssh to a Linux client joined to IPA with an AD account; the home directory is created on first login (the playbook enables oddjob-mkhomedir).
Let AD groups govern Linux access
AD groups cannot go directly into HBAC or sudo rules. Map them to an IPA external group and nest that in a POSIX group:
ipa group-add --external ad_admins_external
ipa group-add-member ad_admins_external --external '<AD domain>\Domain Admins'
ipa group-add ad_admins
ipa group-add-member ad_admins --groups ad_admins_external
# HBAC / sudo rules then reference ad_adminsIn the console: Identity → Groups → User groups, tick "External" when creating the group.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
trust-add cannot find the AD domain | No forward zone, or AD DNS unreachable | Do step one first; verify SRV with dig |
WERR_CONNECTION_REFUSED | Two-way trust | Drop --two-way, use --range-type=ipa-ad-trust |
Clock skew / KRB5KDC_ERR_SKEW | More than 5 minutes apart | Same NTP source on both sides |
trust-add succeeded but id <AD user>@<AD domain> returns nothing | SSSD has not fetched yet, or winbind is down | ipactl status for smb / winbind; sss_cache -E and retry |
| AD user resolves but ssh is refused | The default allow_all HBAC rule is disabled and the user matches no rule | ipa hbactest --user <AD user>@<AD domain> --host <host> --service sshd shows which rule blocks |
| No Trusts page in the console | Licence lacks the AD trust module | Check mods in status.json |
Configuration
customer.env, variable by variable. Model A's .env and Model B's customer.env share one variable set; only the connection method and a few container settings differ.
Licence
Four tiers by feature module and managed host count. Offline activation by default, one .lic per IPA server; the console is read-only until activated.