Which Windows Server versions work with a FreeIPA trust?
Before you commit to a FreeIPA build, an identity or infrastructure lead needs to confirm that the AD forest, its domain controllers and the FreeIPA servers form a supported trust. The answer depends on current upstream documentation for Windows Server, AD forest and domain functional levels, RHEL and Samba, and the supplied sources do not give a version matrix. Treat the version question as an open check to close with written evidence, not as an assumption carried over from an older lab or a forum post.
The facts you can rely on now are narrower. FreeIPA builds cross-forest trusts with Active Directory through Samba components, so the Samba and RHEL packages on your IPA servers are part of the supported-version question, not a separate detail. The IPA DNS domain must also not overlap any DNS domain in the AD forest, which is a hard constraint you can check against the forest's domain list before any version is discussed. A trust that works on paper can still fail if that naming rule is broken, so run this check first.
Work through the confirmation in this order. First, record the forest functional level, each domain functional level and the version of every domain controller in the forest, including read-only controllers. Second, check the RHEL release, Samba version and FreeIPA release on each planned trust controller against the current FreeIPA trusts documentation and the relevant vendor matrices. Third, ask your AD team to confirm in writing which functional levels and controller versions they will keep during the trust period, because a later forest upgrade can change the answer. Any gap should go into the written scope as a dependency with an owner, so the build does not start on an unverified combination.
Which versions to confirm before choosing a trust design
This table lists the version and configuration items that decide whether a FreeIPA and Active Directory trust is supported and how it should be built. Read each row as a question to answer from your own inventory and the vendor documentation before you choose a trust direction or a Kerberos design. Record the exact values in your design document, because the trust, ID mapping and SMB settings all depend on them.
| Item | What it affects | Where to confirm | What to record |
|---|---|---|---|
| AD forest functional level | Which trust features and Kerberos encryption types are available across the forest and whether older domain controllers can hold the trust | Microsoft AD documentation for raising and reading functional levels, plus the forest properties on a domain controller | Current forest and domain functional level for every domain, and any planned raise |
| Domain controller operating system | Which Windows Server releases the trust must work with, including the Kerberos and LDAP behavior the FreeIPA side must match | Red Hat IdM and Samba release notes for the supported AD combinations, compared against your AD inventory | Operating system and build of each domain controller, grouped by domain and site |
| Mixed domain controller versions | Whether some controllers in a domain run older releases, which can change which settings are safe to enforce everywhere | Your AD inventory and the compatibility sections of the Red Hat IdM and Samba release notes | Every domain controller with its version, and whether any older controllers remain in service |
| FreeIPA server operating system and release | Which Samba, trust controller and ID mapping packages are available, and which FreeIPA behaviors apply | Red Hat IdM release notes and the FreeIPA release notes for the version you plan to run | Operating system release, IdM or FreeIPA version and the installed Samba package versions on every server |
| Samba components on the IPA side | Whether the trust controller and cross-forest trust components work with the chosen AD versions and FreeIPA release | Samba release notes and the Red Hat IdM documentation for trust packages | Samba package versions, trust controller count and the packages installed on each controller |
| SMB signing and encryption settings | Whether SMB traffic from Windows clients and file servers that rely on the trust can be signed or encrypted, and what must be enabled on each side | Microsoft SMB documentation for signing and encryption requirements, and the Samba documentation for the SMB settings you run | Current signing and encryption policy on domain controllers and file servers, and the minimum protocol level each side accepts |
| DNS naming | Whether the IPA domain and realm can coexist with AD names without overlap, and whether SRV records resolve from both sides | The FreeIPA trust documentation and your own DNS zone inventory on both the AD and IdM sides | IPA DNS domain, Kerberos realm, AD DNS domains, NetBIOS names and the zones each side hosts |
| Time synchronization and Kerberos settings | Whether Kerberos tickets across the trust remain valid, since clock skew and mismatched encryption types can break authentication | Your time source inventory and the Kerberos settings documented for FreeIPA and AD | Time source for each domain, measured skew, and the Kerberos encryption types enabled on each side |
Why Samba and DNS decide the trust, not only the Windows version
The trust is built on Samba components on the FreeIPA side, so the Samba release in your IdM servers supports the trust as much as the Windows version on the AD side does. When you read a support matrix, treat the Windows row as one input. The IPA release and its bundled Samba packages must also cover the functionality you need, such as the forest and domain levels you plan to trust. Confirm the exact Samba and FreeIPA combination with the vendor documentation for your platform before you commit to an AD version, because a Windows version alone does not settle whether the trust can be established.
The IPA domain must use a DNS domain that does not overlap with any domain in the AD forest, as stated on the FreeIPA Trusts page. Choose this name before installation, since renaming an IdM domain later is far harder than picking a clean name now. Map the DNS namespace on paper first: the IPA domain, the AD forest root and every AD child domain, with the owner of each zone. A clean separation here removes many later failures, including ambiguous SRV record lookups and realm naming conflicts that surface only when the trust is being validated.
A Windows version that sits inside the matrix can still fail if the DNS, time or Kerberos layer is misconfigured. Name resolution in each direction, correct SRV records, synchronized clocks and a working Kerberos exchange are all prerequisites that the Windows version does not provide. Before you read any version result as final, test name resolution and Kerberos from both sides: resolve the AD domain and its domain controllers from the IdM servers, resolve the IPA domain from the AD side, and request tickets across the trust path. Record the results with the DNS and Kerberos configuration you tested, so that a later failure can be traced to a specific layer instead of to the Windows release.
How to verify the supported combination before the trust build
This sequence confirms that your AD forest, domain controllers, FreeIPA servers and DNS layout fit a supported trust before anyone builds it. It ends with a signed-off matrix that both the identity and AD teams can point to.
Record the AD forest and domain functional levels
The AD administrator records the forest functional level, each domain's functional level and the forest and domain names, including any child or sibling domains that a trust would reach. Ask for the output of the Active Directory domain and forest queries or the equivalent view in Active Directory Domains and Trusts, then store it in the matrix. This step is done when every domain in scope has a recorded functional level and an owner who confirmed it.
Inventory each domain controller's operating system
Someone with read access to the directory lists every domain controller in each in-scope domain, with its hostname, Windows Server version, patch level and site. Include read-only domain controllers, because they can affect which controller answers a trust request. This step is done when the inventory covers every domain controller the AD team reports, and any gap between the directory listing and the team's own records is explained in writing.
Confirm the FreeIPA platform and component versions
The FreeIPA team records the operating system on each IdM server, the FreeIPA release installed and the Samba packages that provide the trust components. Check each item against the current vendor documentation for your RHEL or compatible release and the FreeIPA release notes, because support statements change between releases. This step is done when each version has a source reference and the platform owner has confirmed the combination is listed as supported for the trust you plan.
Check the IPA DNS domain for overlap
The identity team compares the IPA DNS domain with every DNS domain in the AD forest and confirms that none overlap. FreeIPA requires a DNS domain that does not overlap with any AD domain, so a shared or nested name stops the trust before it starts. Record the comparison as a table of names, and have the AD and identity owners both sign the result. This step is done when the table shows no overlap and both owners have initialed it.
Check SMB signing and encryption on domain controllers
The AD team exports the SMB signing and SMB encryption settings from the domain controller policies and records the effective values on each controller. Compare these with the requirements in the FreeIPA and Samba documentation for your release, and note any setting that requires signing or encryption where the trust components cannot comply. This step is done when every domain controller has a recorded effective setting and each mismatch has a named owner and a decision.
Run name resolution and Kerberos checks from both sides
Run forward and reverse lookups for the SRV records and domain controller names from a FreeIPA server and from an AD domain controller, and confirm that each side resolves the other's records. Then request a Kerberos ticket for a test account on each side, and capture the command output and any errors. Use the trust documentation to identify the expected records, and treat any failed lookup or ticket request as a blocker until it is fixed and retested. This step is done when both directions resolve and both test tickets are recorded with timestamps.
Record a signed-off support matrix
Assemble the outputs from the earlier steps into one matrix covering functional levels, domain controller versions, FreeIPA and Samba versions, DNS overlap result, SMB settings and connectivity tests. The AD owner, the FreeIPA owner and the security approver each sign it, and the document is stored with the change record. This step is done when every row has a recorded value, every open item has an owner, and all three signatures are on file before the trust build is scheduled.
Which settings break a trust after it appears to work
A trust can show as established while authentication, name resolution or file access still fails for specific users and hosts. The cards below cover settings that tend to fail quietly, so the AD team and the FreeIPA team can check them before cutover and again after any change.
SMB signing and encryption
Domain controllers and clients can require SMB signing or encryption, and a file path that works in testing can fail once a stricter policy is applied. Ask the AD team which SMB signing and encryption settings apply to the domain controllers and to Windows clients that reach Samba file servers on IPA clients. Confirm the settings on both sides match what your Samba configuration supports for the Windows Server versions in your forest.
DNS overlap between domains
The IPA DNS domain must not overlap with any domain in the AD forest, or name resolution for trust members can resolve to the wrong side. Overlap often appears only after a new subdomain or delegation is added on the AD side. Ask the AD DNS team to confirm the zones they host and any conditional forwarders, and check resolution of AD SRV records from an IPA client.
Kerberos and time skew
Kerberos rejects tickets when clocks drift beyond the allowed window, so a trust can work for one hour and fail for another. Check that every domain controller and IPA server syncs to a reliable time source, and that clients do too. Ask the AD team to confirm the time hierarchy for the forest, since domain controllers act as the reference clock for their domain.
Trust account credential handling
Setup creates a trust account whose shared secret must be entered on both sides. A secret that is rotated, copied with a stray character or stored in a ticket can cause logins to fail without an obvious error. Agree in writing who generates the secret, where it is stored and who may reset it. Confirm with the AD team that the trust object exists and that its secret was changed only through the agreed procedure.
Mixed domain controller versions
A forest can contain domain controllers from several Windows Server releases during a migration, and different releases can behave differently for Kerberos, SMB and trust-related checks. Ask the AD team for an inventory of every domain controller in each domain, including read-only controllers and any that are scheduled for retirement. Test authentication against each domain controller a client might reach, not only the one nearest the IPA server.
Version changes after go-live
A trust that works at cutover can fail after a domain controller upgrade, a functional level change, an IPA server upgrade or a change to SMB policy. Record the Windows Server version, functional levels and FreeIPA release in your change log, and rerun the same validation after each change. Ask the AD team to notify you before any domain controller or functional level change, and confirm the release notes for your FreeIPA version before upgrading.
What to confirm for a lab, a production forest or a mixed estate
A lab shows that the trust installs and that a test user can authenticate across it. It does not show that your forest, domain controllers or change process will behave the same way. Treat a passing lab as evidence about the software path only, and record the exact versions you tested so the result can be compared with production.
- Support matrix sign-off: Confirm in writing which Windows Server and RHEL combinations are supported for the trust, and record the versions used in the lab against that list.
- Functional levels: Record the forest and domain functional levels in the lab. Production levels may differ, and raising them is an AD team decision with its own rollback questions.
- Trust direction: A lab trust built in one direction does not settle the production choice. Read the direction and ID mapping pages in this content group before reusing lab settings.
- Domain controller spread: A single lab domain controller hides the replication and version differences across the domain controllers you actually run.
Before you treat a lab result as transferable, check that every version in the lab matches a combination confirmed for production.
In a single forest, the open questions concern the domain controllers that already exist and who approves changes to them. The AD team owns the forest and domain state, so the FreeIPA side cannot finish the trust alone. Agree the scope of each side before a change window is booked.
- Domain controller inventory: List every domain controller, including read-only domain controllers and those in remote sites, with its operating system version. Confirm each one against the support matrix, since mixed versions are common during AD upgrades.
- Functional level changes: Ask the AD team whether any functional level must be raised for the trust, what that change blocks in the forest, and whether it can be reversed.
- Ownership of the AD change: Name the person who performs the AD-side steps and the person who performs the FreeIPA-side steps, and record who signs off each one.
- SMB signing and encryption: Confirm the SMB signing and encryption policy that the Windows side enforces, because it affects how Samba file servers on Linux clients reach Windows resources.
- Trust direction: Settle one-way or two-way before the change. The direction and Kerberos implications are covered on the direction page in this content group.
Collect the matrix check, the domain controller inventory and the signed change approval in one document before any change is scheduled.
Multiple forests and mixed Linux and Windows estates add trust paths, DNS names and version combinations, and each forest can have its own team. A decision that is safe in one forest can affect a shared DNS namespace or a user population in another. Map every forest and its owners before the first trust is designed.
- Per-forest matrix: Each forest may have different functional levels and domain controller versions. Confirm the support matrix for every forest that will trust FreeIPA, not only the primary one.
- Overlapping DNS names: The IPA DNS domain must not overlap with any domain in the AD forest. Inventory the DNS names in every forest, including child and legacy domains, before naming anything.
- Trust path ownership: Identify which team owns each trust relationship and who approves changes that touch more than one forest.
- ID mapping per forest: Mapping choices in each forest determine the UIDs and GIDs that users receive. Use the ID range and ID view pages in this content group to make those decisions.
- Windows workstations: Windows machines do not join FreeIPA, so confirm which Windows users need Linux access and which Linux hosts they must reach.
Confirm all forests, owners and DNS names in a single inventory before the first trust is created.
What buyers ask before a FreeIPA and Windows trust project
Is any Windows Server version guaranteed to work with a FreeIPA trust?
No version can be guaranteed in advance. Compatibility depends on the combination of the AD forest and domain functional levels, the domain controller versions, the RHEL release running the IdM servers, and the Samba and Kerberos packages on those servers. The supported-combination question has to be checked against the vendor's current documentation and tested in your own environment before you commit to a design. A written review produces a matrix of what your estate actually runs and what must be verified or changed before the trust is built.
What does the compatibility matrix review cost, and who pays for it?
The review is a paid engagement, and the price follows from a written scope. DeployOpen does not publish a price list. The main cost components are the time to collect and verify AD and DNS details, the lab or test work needed to confirm behavior, and the write-up and review meeting. Your organization pays for the review, and internal staff time is an additional cost you should count. Ask any vendor for a quote that lists the environments covered, the number of domain controllers reviewed, and whether test work is included or optional.
How long does the review take, and what makes it longer?
Duration depends mostly on how quickly your team supplies accurate information and how many environments must be reviewed. Larger AD estates with many domain controllers, several forests, or separate production, staging and disaster recovery environments take longer to document and test. Change control adds time because approvals for any test trust or DNS change must be scheduled. Agree on a timeline in the written scope, and confirm which steps depend on your team's availability.
What must our team provide before the review starts?
Plan to provide a current AD inventory, including forest and domain functional levels, the list of domain controllers with their operating system versions, and the sites and subnets. You also need the DNS records for the AD domains, the planned IPA domain and realm names, the RHEL versions on the planned IdM servers, and a named contact on the AD team. Change approvals are needed for any test work that touches production DNS or domain controllers. Confirm the exact list with your reviewer, because gaps in the inventory are the most common cause of delays.
Can our own team run the compatibility review?
Yes, if your team has access to the AD forest, the DNS servers, and a test environment where trust setup can be attempted safely. The work requires knowledge of AD functional levels, Kerberos, DNS and the FreeIPA trust documentation, and it needs someone who can read the results and decide what changes. Many teams do the inventory internally and bring in a reviewer for the matrix analysis and test plan. Be honest about whether your team has time for the verification steps, since skipped tests tend to surface during the production cutover.
What changes when Windows Server or RHEL is upgraded later?
An upgrade can change which combinations are supported, so the matrix needs to be reviewed again before and after any change to a domain controller, a functional level, or an IdM server's RHEL release. Treat a domain controller upgrade or a functional level raise as a change that requires re-testing the trust, DNS and Kerberos paths. Keep the matrix as a living document with a named owner, and confirm current support statements with the vendors before scheduling the upgrade. Ask whether a retainer covering periodic re-review is part of your plan.
Which parts of the estate drive the cost of a trust review most?
Four factors shape the effort: the size of the AD estate, the number of domain controllers in scope, the number of environments such as production, test and disaster recovery, and the change control process your organization requires. A single forest with a few domain controllers and fast approvals is a small review. Multiple forests, many sites, and strict change windows increase both documentation and testing work. Ask for a quote that shows which of these factors it assumes, so you can adjust the scope if your estate is simpler or more complex than described.
Does a FreeIPA trust with Windows Server need an audit or certification?
A compatibility review does not produce an audit report, attestation or certification. DeployOpen prepares systems, configuration records and evidence for compliance assessments, but independent auditors and certification bodies issue any formal assessment. If your organization must show that the trust and identity design meets a specific control framework, ask the reviewer to map the evidence to the controls your auditor will use, and confirm the assessment requirements with that auditor early.
How DeployOpen scopes and delivers FreeIPA and AD trust work
DeployOpen plans, implements, documents and supports FreeIPA on servers you control, including the trust design that decides which Windows Server versions and domain levels your Active Directory forest can use. Each engagement starts from your current forest, your RHEL versions and your sync and SMB requirements, then turns them into a written scope before any change is made.
How we scope
- Inventory the AD forest and domain functional levels, domain controller operating systems and their patch state.
- Confirm the RHEL release on each planned IdM server and check it against the Windows versions in scope.
- Document SMB signing and encryption requirements for every file server that will serve trusted users.
- Agree the scope, deliverables and timeline in writing before work starts, since engagements are fixed-scope.
How we build
- Build a lab trust in a non-production environment that matches the forest level and domain controller versions you run.
- Test Kerberos authentication, ID mapping and SMB access from both the Linux and Windows sides before cutover.
- Record each version combination tested, including the RHEL packages and Samba components involved.
- Coordinate the AD-side and IdM-side changes so no one needs domain admin credentials on the other side.
How we hand over
- Deliver a compatibility matrix listing supported forest levels, domain controller versions and RHEL releases with test evidence.
- Provide runbooks for trust creation, validation, and rollback steps tied to your environment and change process.
- Document SMB encryption settings, required ports and DNS records so your teams can reproduce the setup.
- Train your Linux, identity and Windows administrators on the checks they will repeat during upgrades.
How we support
- Review the compatibility matrix before each Windows Server or RHEL upgrade that touches the trust path.
- Retest the trust after domain controller replacements, forest level changes or FreeIPA 4.x upgrades.
- Offer ongoing support, upgrades and continuous testing as a retainer, priced separately from the initial scope.
- Keep backup and restore procedures current, since restoring an outdated backup into an active topology can break replication.
