FreeIPA + Samba AD Trust Architecture

The goal of this project is a cross-forest trust between FreeIPA and Samba AD: a single identity plane that serves both Linux and Windows workloads without duplicating users across two separate directories.

This is a hard problem. Real progress has been made. A real limitation has been hit. Here is an honest account of where things stand.

The Goal

In a mixed Linux/Windows environment, the common approach is to maintain parallel user accounts: one in an LDAP/Kerberos directory like FreeIPA for Linux hosts, and one in Active Directory for Windows clients. This creates administrative overhead, drift risk, and inconsistent access policy.

The better approach is identity federation: users exist once in FreeIPA, and a cross-forest Kerberos trust allows Windows systems to authenticate them without maintaining a second account. Group policy and access controls can be mapped across the trust boundary.

This is how mature enterprise environments handle heterogeneous identity. It is what this project is working toward.

What Was Built

Where the Wall Is

Cross-forest Kerberos trust between FreeIPA and Samba AD is the specific point of failure. The trust relationship can be initiated, but authentication does not successfully traverse the realm boundary in the way a genuine Active Directory cross-forest trust would.

Samba's AD implementation diverges from Microsoft's in ways that matter here. FreeIPA's Kerberos trust mechanism is designed to interoperate with real Windows Server Active Directory. At the cross-realm auth handoff, Samba does not fully honor the expected exchange, and the Ansible connector layer, while useful for attribute synchronization, cannot resolve the underlying authentication protocol gap.

This is a known limitation of Samba AD in cross-forest trust scenarios, not a misconfiguration issue. The architecture is correct. The tooling has a ceiling.

The Path Forward

The next step is deploying a genuine Windows Server instance to replace Samba AD as the Windows-side domain controller. Microsoft's 180-day evaluation license makes this feasible in a homelab context.

With a real AD DC in place, the cross-forest Kerberos trust with FreeIPA should behave as designed. This is the validated path used in enterprise environments running mixed Linux/Windows identity.

• Provision Windows Server on Proxmox using the 180-day evaluation
• Stand up a proper AD domain on the Windows DC
• Establish the cross-forest trust between FreeIPA and Windows AD
• Validate Kerberos ticket flow across realms
• Confirm Linux users can authenticate to Windows resources without duplicate accounts
• Film the full walkthrough and update this write-up

Why This Matters

Most environments that run both Linux and Windows infrastructure end up with duplicate user management. That means more surface area, more inconsistency, and more places for access policy to drift.

A properly federated identity model (one user, trusted across both environments) is the enterprise standard for a reason. Getting this working in a homelab requires the same tooling, the same architecture decisions, and the same failure modes as in production. Including the ones you hit and have to work around.

This project is ongoing. The documentation will be updated as the Windows Server phase completes.

Stack

• FreeIPA: Kerberos + LDAP + HBAC + sudo + SSH key management
• Samba AD: Active Directory-compatible domain controller (current)
• Windows Server: genuine AD DC (next phase, 180-day eval)
• Ansible: identity attribute bridge and connector automation
• Proxmox: hypervisor hosting all identity VMs