FreeIPA one-way vs two-way AD trust

FreeIPA one-way versus two-way trust: what each direction lets users reach

If your Linux estate runs on FreeIPA and must serve AD users, or the reverse, the trust direction decides which users can reach which resources, and changing it later is not a simple switch. Treat the direction as an architecture decision made before any trust is created, because the choice shapes who can authenticate to what, how identities are resolved on Linux hosts, and what has to be built around the trust afterward. The sources supplied for this topic do not give a complete per-direction access matrix, so the first task is to write down the access each side needs and confirm it against the current FreeIPA and Active Directory documentation.

FreeIPA can establish a cross-forest trust with Active Directory through Samba components, according to the FreeIPA Trusts page. That makes the trust a forest-level relationship rather than a simple user synchronization. One prerequisite is fixed by the design: the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest. Check this with the AD team before naming the IPA domain, since renaming it later is a major change. Confirm the exact trust configuration steps and any prerequisites for your FreeIPA release on the same Trusts page rather than relying on memory or older blog posts.

Ask the AD team to state which accounts must reach Linux hosts or IPA services and which IPA identities must reach AD resources. Then confirm, for each direction, what the trust lets those users do, including how Kerberos authentication, ticket issuance and group membership are evaluated across the trust. Pay particular attention to two-factor authentication, because an OTP factor enforced in FreeIPA may not behave the same way for users who arrive from the AD side. Document the expected result for each user group in a short test matrix, and run those tests on a non-production trust before you commit to a direction.

Comparing one-way and two-way trust for FreeIPA and AD users

This table compares the two trust directions across access, Linux login through ID mapping, setup work on each side, and two-factor behavior. Cells marked as unconfirmed need checking with the vendor or in a test environment before you choose a direction. The main takeaway is that the Kerberos and two-factor rows decide the direction, so test them first.

Question	One-way trust	Two-way trust
Which users reach which services	Users from the trusted side reach resources in the trusting domain only. Confirm the exact direction in a test.	Users from each forest can reach resources in the other. Confirm per service and per protocol.
AD users getting Linux access through ID mapping	Possible through an ID range on the IPA side. Confirm the supported mapping for your AD version.	Same mapping model. Confirm whether the reverse direction changes ID range setup.
Work on the IPA side	Create the trust and its ID range on the IPA servers. Confirm steps against the FreeIPA trust documentation.	Same IPA-side work, plus any extra objects the reverse direction needs. Confirm the list.
Work on the AD side	AD administrators create a matching trust object. Confirm the required AD-side steps for your forest level.	AD administrators create trust objects in both directions. Confirm the required steps.
Kerberos FAST	Not confirmed by the sources. Verify whether your AD domain controllers need FAST, and whether it works one-way.	Verify in a test. Two-way may be required for FAST to work, which should be confirmed before you choose.
Two-factor authentication (OTP)	IPA OTP tokens apply to IPA-issued Kerberos logins. Verify how AD users' second factors are checked across the trust.	Verify whether OTP checks for AD users work in both directions and whether RADIUS proxying applies.
DNS and naming	The IPA DNS domain must not overlap any AD forest domain. Applies to both directions.	The same non-overlap rule applies. Confirm DNS records on both sides before the trust is created.
Credentials exchanged	A shared trust secret is used, so IPA admins need no AD domain admin account. Confirm with the AD team.	Confirm whether the reverse direction requires additional AD credentials or shared secrets.

Which trust direction fits your AD and IdM use case

If your main need is letting AD users log in to Linux hosts enrolled in FreeIPA, the central question is which side authenticates them and where their Linux identity comes from. The trust is the mechanism that lets IdM hosts accept Kerberos tickets issued for AD accounts. Start by sizing the population: how many Linux hosts need AD logins, whether they sit in one site, and whether sudo and access rules should stay in IdM.

Authentication path: Confirm that AD users will obtain tickets from AD and that IdM hosts will accept them through the trust.
Identity source: Decide how AD users receive UIDs and GIDs, because that choice affects every host and is hard to change later.
Access policy location: Determine whether HBAC and sudo rules in IdM will reference AD users and groups directly.
Scope of the trust: Ask the AD team whether the Kerberos flows your Linux hosts use require the trust to run in both directions.

Before scheduling a change, check with both teams which hosts, groups and service accounts must log in, and confirm the trust direction against the Kerberos configuration each side will run.

When Kerberos FAST can force a two-way trust

Kerberos FAST (Flexible Authentication Secure Tunneling) is a pre-authentication extension that wraps the Kerberos exchange in an armored channel, so that the client and the KDC can protect pre-authentication data and tie it to a session key. Whether a FreeIPA and Active Directory deployment depends on FAST, and whether that dependency forces the trust to run in both directions, is the question to settle before you pick a direction. We have not verified in this material how FAST behaves across a cross-forest trust, so treat any claim that it requires a two-way trust as a hypothesis until you test it.

Start by confirming two things against the current MIT Kerberos and FreeIPA documentation: which FAST options are enabled on your KDCs and clients, and whether a request from an AD user to an IdM host, or from an IdM user to an AD resource, needs the armoring ticket to be issued by a realm that the other side trusts. Check how the FreeIPA trust documentation describes the ticket flow for your release, and record the answer in your design. Also confirm which MIT Kerberos version your IdM servers and clients ship, since FAST support differs by release.

Test in your own forest before you fix the direction. Build a lab with a one-way trust, then run authentication from each side with FAST enabled and disabled, including any two-factor flow you plan to use. If a login fails only in one direction, you have evidence that FAST needs the reverse trust path. If both directions work with a one-way trust, record the result and the versions tested, and ask the AD team to review the trust attributes before the change window. Choosing a two-way trust to avoid a failure you have not reproduced adds trust surface you may not need.

How two-factor authentication changes under each trust direction

Two-factor authentication in FreeIPA depends on where the OTP check runs, which users have tokens, and whether Kerberos can carry the second factor to AD users. The cards below cover each of these points and the items to prove in a lab before any trust direction goes into production.

Where OTP checks run

FreeIPA stores HOTP and TOTP tokens in its own directory and verifies them on the IdM side. For an AD user, the question is whether the OTP check happens on an IdM server reached through the trust or whether the user is never enrolled with a token at all. Confirm in the lab which server performs the check for a trusted user and whether the token lookup succeeds across the trust direction you chose. Compare this against the FreeIPA OTP design page before you assume the design applies to AD accounts.

RADIUS proxying for AD users

FreeIPA can proxy OTP checks to an existing RADIUS server, which matters when a second factor is already managed outside IdM. Ask whether the RADIUS path is needed for trusted AD users or only for local IdM accounts. A one-way trust may leave AD users unable to reach the same proxy configuration that IdM users use. Test a trusted AD login end to end, including the RADIUS round trip, and record which component returns the final decision.

Which AD users get a second factor

A second factor applies only to users whose authentication path reaches a FreeIPA OTP check. Trusted AD users are authenticated by AD Kerberos, so their eligibility depends on how the trust maps them and whether they can be assigned tokens in IdM. Decide before rollout whether AD users will get IdM tokens, rely on a RADIUS-backed check, or be excluded from the second factor. Document the answer per user group, because the trust direction limits what each group can reach.

Kerberos settings the second factor needs

OTP authentication in FreeIPA runs through Kerberos pre-authentication, and FAST is the mechanism that protects the OTP exchange. Confirm that the Kerberos configuration on both sides supports FAST and that the trust setup does not block the armored exchange. If FAST cannot be used across the direction you chose, a two-way trust may be needed. Verify the clock skew, realm names and KDC referrals in a lab, since a failure here often looks like a plain wrong-password error.

Lab checks before rollout

Build a test trust in the chosen direction and run a checklist: an IdM user with a TOTP token, an AD user in an allowed group, an AD user outside it, and a login during a token failure. Record which server handles each step and what the error looks like on the client. Repeat the test after a replica or trust controller change. Ask your AD team to confirm the trust settings on their side, because the direction you pick affects their configuration as well as yours.

How to choose the trust direction and confirm it before setup

This sequence turns the trust direction question into a written, tested decision that both the FreeIPA and Active Directory teams accept before any trust object is created.

Gather user and resource requirements from both teams
Start by listing what each side needs: which AD users must log in to Linux hosts, which IdM users must reach AD resources, which applications and file shares are involved, and whether any service needs Kerberos from the other side. The FreeIPA team leads this with the AD team, and the output is a short written table of consumers, targets and required access. You know this step is done when both teams have signed off on that table and every requirement maps to a named direction of access.
Confirm DNS domain naming against the non-overlap rule
Check that the IPA DNS domain does not overlap with any domain in the AD forest, as the FreeIPA trust documentation requires. Compare the planned IPA domain, realm and any NetBIOS names with the AD forest's domain list, and confirm which DNS servers answer for each zone. The check passes when the AD team confirms in writing that no overlap exists, and when a lookup of the planned IPA hostnames returns the expected addresses from an AD-joined machine and from an IPA client.
Map Kerberos and two-factor needs to the trust direction
Review whether the users who need access rely on Kerberos FAST or on OTP-based two-factor authentication through FreeIPA. Where those mechanisms cross the trust, a one-way design may not carry the required ticket exchange, so the team should check the Kerberos settings with the FreeIPA MFA documentation before deciding. The output is a short matrix that states, for each user group, whether a one-way or two-way trust is needed. You know this step is done when the matrix is reviewed and any open questions about FAST are assigned to a named owner.
Test authentication behavior in a lab
Build a small lab with one IPA server, one client and one AD domain controller, using the same OS and AD functional levels planned for production where you can. Run a sample login for an AD user to a Linux host, a sample OTP login for an IdM user, and a sample access request in the reverse direction. Record which logins succeed, which fail and the error messages. The check is a written result for each test case, and the lab must show the expected outcome for each row of the matrix before the decision is accepted.
Record the trust direction decision with the AD team
Write a decision record that names the chosen trust direction, the access it grants, the access it does not grant, the test results that support it and the owners on each side. Share it with the AD team and the security or compliance owner, and ask them to confirm any assumption about trust rights in their environment. The decision is complete when all named owners have approved the record and it is stored with the project documents, so later changes must go through the same review.
Hand off to the trust build
Once the decision is recorded, move to the setup work, which is covered on the sibling pages for creating a trust with a shared secret, preparing trust controllers and agents, and planning DNS for the trust. This step confirms that the build team has the decision record, the lab results and the DNS check. You know it is done when the build team confirms that every prerequisite in the record has a passing check and that no open questions remain on the matrix.

Security and operational considerations for the trust direction

The trust direction decides what each side can request and who holds the credentials to change it. The cards below cover the boundary, the credentials, replication and backups, patching and monitoring, the points where a trust design is easiest to get wrong.

Trust boundary and requests

A one-way trust lets IdM users reach AD resources, or AD users reach IdM resources, depending on the direction chosen. A two-way trust opens requests in both directions and widens what each forest must accept from the other. Before choosing, list every service that must authenticate across the boundary, including Kerberos FAST, and confirm with the AD team which principals each side will accept. Treat the trust as a policy decision, not a default setting.

Privileged credentials on each side

Creating the trust needs administrative rights in both FreeIPA and Active Directory. A shared-secret setup lets each team configure its own half so that FreeIPA administrators do not need AD domain admin credentials. Agree in writing who holds the trust secret, where it is stored, who can rotate it, and which accounts may run the commands on each side. Review these grants whenever either team changes staff.

Replication and backups of trust state

Trust configuration and ID range data live in the FreeIPA directory, so they replicate across servers. Restoring an outdated backup into an active replica topology can break replication, which affects trust state as well as user data. Back up after the trust is created and after any change to it, then test a restore in a non-production copy. Confirm with your team which server runs certificate renewal and CRL publication, since that server needs the same care.

Patch tracking for the 4.x release line

Track FreeIPA releases on each server, not only on the first one you installed. The 4.13.4 stabilization release fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and hardened authentication checks across the API. Record the installed version on every replica and trust controller, schedule updates in a maintenance window, and confirm that the trust still works after each upgrade.

Monitoring failed cross-forest logins

Failed authentication across the trust can signal a misconfigured DNS record, an expired trust secret, a disabled AD account, or an attack against the boundary. Forward Kerberos and directory logs from every FreeIPA server and the trust controller to central logging, and set alerts on repeated failures from one forest. Ask your AD team to share matching domain controller events so both sides can correlate a single failed login.

Two-factor checks across the trust

Two-factor authentication for AD users depends on how the trust passes OTP and Kerberos settings. The FreeIPA OTP design supports HOTP and TOTP tokens and can proxy OTP checks to an existing RADIUS server, but cross-forest behavior needs confirmation in your own lab. Test an AD user's login with a token in each trust direction before go-live, and record which factor is enforced on each host.

Questions buyers ask about FreeIPA AD trust direction

What drives the cost of setting up a FreeIPA and AD trust?

The main cost drivers are the number of AD forests in scope, whether Kerberos features such as FAST force a two-way trust, how far two-factor authentication must reach, and how much time your AD and IdM staff can give the project. Each forest adds DNS, naming and trust validation work on both sides. Two-factor scope adds token enrollment, RADIUS or OTP design, and testing across clients. Ask any partner for a written scope that lists these items separately, state who performs each step, and separate one-time build work from recurring support. Prices are not published here, so a quote should follow from that written scope.

How long does it take to decide on a trust direction?

The decision depends less on calendar time than on answering three questions early: which AD users must reach IdM services, whether any service needs Kerberos FAST, and whether two-factor authentication applies to AD users. Gather those answers with the AD team, the IdM team and the application owners before any change request is opened. Your own timeline for this decision should be set by your change process and team availability, which we cannot estimate for you. Confirm the Windows Server and forest functional levels in your environment early, because they can narrow the options.

What do the AD and IdM teams each have to provide?

Both teams own half of the trust, so the work cannot be completed by one side alone. The AD team must confirm forest and domain functional levels, domain controller versions, DNS forwarding and whether the IPA domain name overlaps with any AD domain. The IdM team must confirm the IPA domain and realm naming, the trust controller placement, and the ID range plan. Agree on who holds which credentials, and who signs off each validation step. Keep the trust-setup procedure and the change record in a location both teams can read.

Can our internal team set up the trust without outside help?

A capable internal team can perform the setup if it has engineers who understand Kerberos, DNS and AD administration and time to test. The risk lies in the cross-team coordination and in the points where a wrong choice is hard to reverse, such as ID range design and trust direction. If your team has not run a cross-forest trust before, plan a lab test first using a non-production forest. Ask any partner to show how it will hand over runbooks and test evidence, so your team can operate the result after the project.

Which trust decisions are hard to reverse later?

The ID range type and the trust direction carry the most lasting effect. An ID range that maps from SIDs or reads AD POSIX attributes is hard to change once users have files and sessions tied to their UIDs and GIDs. The IPA domain name must not overlap with any AD domain, so DNS naming is also difficult to undo. Moving to a two-way trust later, if Kerberos FAST requires it, changes what AD users can reach and needs its own review. Document these choices and their rationale before the first trust is created.

Does a two-way trust change how two-factor authentication works for AD users?

It can. FreeIPA supports two-factor authentication with HOTP and TOTP tokens, including software and hardware tokens, and can proxy OTP checks to an existing RADIUS server. Whether AD users can use those factors depends on the trust direction and on Kerberos settings such as FAST, which must be confirmed for your versions and configuration. Test one AD user from start to finish with a token on each target host before rollout, and record which services accept the second factor. Confirm the exact behavior with your AD and IdM teams and in your own test environment.

How should we test the trust before committing to it?

Build a non-production copy of the FreeIPA and AD design, including DNS, trust controllers, a test AD user and a test Linux host. Run the setup steps in the order your runbook defines, then test login, sudo, HBAC rules and two-factor sign-in for each trust direction you are considering. Check replication, Kerberos ticket issuance and the expected access denials, and keep the results as evidence. Plan the backup and restore steps before testing, because restoring an outdated backup into an active replica topology can break replication, according to the FreeIPA backup documentation. Compare the outcomes with the written requirements before approving production work.

Limits to confirm in your environment before you choose

The trust direction depends on facts that sit outside FreeIPA: the Active Directory forest, the Windows versions in use, the FreeIPA release you plan to run, the DNS layout and the authentication tools your users already have. Confirm each item with the owner named on the card before you write the design.

AD forest and domain levels

Ask the AD team for the forest and domain functional levels, the Windows Server version of every domain controller, and whether any domain controller is out of support. These values decide which trust features and SMB encryption settings you can use, so a trust design built on an assumed level may fail during validation. Record the answers in writing before you compare trust directions.

Supported FreeIPA release

Confirm which FreeIPA release your platform vendor or distribution ships and whether it receives security fixes for the trust features you need. Recent stabilization releases fixed authentication flaws, so the version you pick affects both the security baseline and the upgrade path. Ask whether the trust design you choose is documented for that release line.

Kerberos FAST behavior for your clients

Ask the AD team whether domain controllers enforce Kerberos FAST or armoring and which client operating systems request it. If FAST is required for authentication, a one-way trust may not carry the ticket flow your users need, and the design may have to move to a two-way trust. Test representative clients against a lab trust before you commit to a direction.

DNS layout on both sides

Ask the network team how DNS zones are split between FreeIPA and the AD forest, and confirm that the IPA DNS domain does not overlap with any AD domain. Overlapping names or missing forward zones block the trust regardless of direction. Also confirm which DNS servers each client uses, since client lookups must reach the right zones from both sides.

Two-factor tokens and RADIUS server

Ask the security team which OTP tokens are issued today, including software tokens and hardware keys, and whether an existing RADIUS server already checks them. FreeIPA can proxy OTP checks to RADIUS, but the chosen trust direction changes which accounts get the second factor. Map each token type and user group to the trust design before you write the access policy.

How DeployOpen scopes the FreeIPA and AD trust decision

DeployOpen plans, implements, hardens, documents and supports FreeIPA inside your own infrastructure, including the trust direction decision that sets what AD users and IdM users can reach. We start from your Kerberos, MFA and access requirements, then write the scope and deliverables before any work begins.

How we scope

Document which AD users and groups must reach Linux hosts, and which IdM users must reach AD resources
Record whether Kerberos FAST or two-factor authentication requires a two-way trust in your environment
Agree the written scope, deliverables and timeline with your security, identity and AD teams before work starts

How we build

Confirm DNS domain naming does not overlap with any AD forest domain before the trust is created
Build the trust in the agreed direction, coordinating the AD-side steps with your Windows administrators
Test Kerberos ticket issuance, OTP login and host access policy from both sides of the trust

How we hand over

Deliver configuration records, trust validation results and a written test report for your auditors and operators
Document the trust direction, its limits and the reasons behind the choice for future architecture reviews
Walk your operations team through backups, replica placement and the steps to change trust settings later

How we support

Offer ongoing support, upgrades and continuous testing for FreeIPA as a retainer, if your team wants it
Review the trust configuration when FreeIPA or Windows Server versions change, using the agreed test set
Keep the scope and deliverables in writing so any change to trust direction goes through a documented change

FreeIPA one-way versus two-way trust with Active Directory