FreeIPA Active Directory trust setup

A cross-forest trust lets Active Directory users authenticate to FreeIPA, but it does not give a Linux host a usable account. Linux needs a numeric UID, a primary GID, a home directory, a login shell and a name that the host can resolve. Active Directory identifies users by security identifiers (SIDs), which are not POSIX numbers. FreeIPA therefore has to translate each SID into a UID and GID before SSSD on a client can present the user to PAM, the login stack and file ownership checks. Until that translation is defined, a trusted AD user may authenticate successfully and still have no working session on the host.

The translation is driven by ID ranges. For a trust, FreeIPA assigns a range of UIDs and GIDs to the trusted domain, and SIDs from that domain are mapped into the range by the ID mapping layer. Confirm the range size and the assigned base before go-live, because the range is the contract between the two directories. Overlapping or reused ranges are the main risk. If a range collides with local POSIX accounts, with another trusted domain, or with a range already used by a different FreeIPA deployment, two different people can end up with the same numeric UID. File ownership, quotas and audit trails then point to the wrong person, and the error often appears only after files have been written. Check existing ranges with the ID range tooling and the ipa-idrange-fix utility, and plan remediation before users log in, not after.

ID views let administrators override the attributes that SSSD returns for a user on specific hosts or host groups. Typical overrides include the home directory, the login shell and, where the environment requires it, the login name shown on that host. A view can be applied to a host group, so a legacy server can keep an existing home directory layout while newer hosts use the default. Overrides are a presentation layer. They change what a host shows for an account, but they do not change the underlying SID or the identity stored in the directory. Decide early which attributes truly need per-host differences, because every override is one more thing to test and to explain when a user reports a different home directory on a different machine.

ID views are applied per host through SSSD, so the effective result depends on the host's enrollment and its SSSD configuration. Verify the result on a representative host from each host group with the SSSD lookup tools, and confirm that the cache is refreshed after a view change. Remember that a correct identity does not grant access. HBAC rules still decide which trusted users may log in to which hosts, and sudo rules decide what they may run once inside. An AD user who appears with the right UID and shell can still be denied at the PAM layer. Test identity and access as two separate steps.

Attribute extensions, such as adding custom user attributes or changing the object classes used for trusted users, are covered in the FreeIPA customization topic and are not repeated here. Read that topic before you change any attribute that ID views depend on, so that mapping, views and extensions are designed together rather than adjusted one after another.

The test plan should prove three things before any AD user is allowed onto a production Linux host: the trust is healthy, identities resolve to the values you intended, and access is decided by FreeIPA policy rather than by accident. Run the checks in the same order every time, and write down what you ran, when, from which host, and what came back. That record is the evidence you will hand to your security team and, if needed, to an auditor. Start on the FreeIPA side by checking the trust status with the ipa trust-find and ipa trust-show commands, then confirm from the AD side that the trust object exists and is trusted in the expected direction. Both sides should agree on the trust state before you test anything else.

Next, test identity resolution on a Linux host enrolled in FreeIPA. Use getent passwd and getent group with a fully qualified AD user and group name, then confirm the UID, GID and home directory match the ID view and ID range you planned. A mismatch here usually means an ID view override is missing or the ID range was assigned in a different order than expected, so resolve this before moving on. Then authenticate as the AD user with kinit from the Linux host and check that a Kerberos ticket is issued and that an ssh login or su to a test account works where HBAC allows it. Record the ticket details and the SSSD log lines from the attempt, since those lines are your primary evidence for authentication flow.

Negative tests matter as much as positive ones. Confirm that an AD user without an allowed HBAC rule is denied on the target host, and that the denial is recorded in the logs with the rule that caused it. Then disable a test AD account, clear the SSSD cache for that user, and confirm that new logins fail. Repeat the check on a second FreeIPA replica to show that both replicas resolve the same identity and enforce the same policy. If the replicas disagree, stop and fix replication before continuing, because a split result means a host may accept a login that another host rejects. Confirm with your team which AD accounts are approved for these tests, and avoid using production administrator accounts.

Failure testing answers the question of what happens when the trust component or AD DNS is unavailable. Stop the trust-related service on one test replica, or block the path to AD DNS from a test host, then repeat a login that succeeded earlier. Cached credentials may still work for a limited period depending on your SSSD settings, so record the exact behavior rather than assuming it. Confirm that a previously denied user is still denied and that a disabled account is not accepted from cache. Check what the host logs and whether the failure produces a clear error. Restore the service and confirm that resolution and authentication return to normal without manual cache repair. Confirm the cache lifetime and offline behavior settings with your Linux and SSSD documentation before the test window.

Prepare a rollback step before you go live. Rollback should remove the ID view overrides that were applied to the AD trust and return hosts to the prior identity configuration, without deleting the trust itself. Keeping the trust in place means you can correct the override and retest without repeating the full trust setup. Test the rollback on a non-production replica, and confirm that after removal the affected AD users resolve with default values or stop resolving as you expect. Finally, store all test output, screenshots of the trust status, SSSD logs, and the rollback result in one controlled location with dates and operator names. Treat that evidence record as part of the deliverable, because it shows the trust was verified and that failure modes were understood before users depended on it.