Which Active Directory integration model fits your Linux estate
For a Linux estate that must authenticate against Active Directory, Red Hat suggests direct integration below roughly 30 to 50 Linux systems and indirect integration through a central Identity Management server above that range or when rapid growth is expected. The tipping pattern is provisioning: direct integration is usually simplest when systems are deployed rarely and are mostly bare metal, while indirect integration fits virtual systems provisioned on demand, especially when an orchestration tool such as Red Hat Satellite builds them. Under either model, AD users still authenticate against Active Directory and its policies are enforced, so a requirement that logins go through AD is met either way.
Direct integration is the lower-overhead choice for a small, slowly changing estate. Each host joins the AD domain with SSSD (or Samba Winbind), and no extra identity servers need patching, backing up or replicating. The condition that changes the answer is central policy. If you need sudo rules and host-based access control (HBAC) managed from one place and applied consistently across many hosts, a FreeIPA server earns its overhead, because it holds those policies itself and the clients enforce them. Confirm with Red Hat's documentation which sudo and HBAC features your AD-joined hosts will and will not get before you assume parity.
Before choosing, count your systems and map how they are built. Ask whether new hosts appear by hand or from a template pipeline, and whether your growth forecast crosses the threshold within the life of the design. A FreeIPA trust also requires a DNS domain for the IPA side that does not overlap any AD domain, so check that naming now, since it is awkward to change later. Plan for FreeIPA's own operating load, including replicas, backups with ipa-backup, and the fact that a mis-restored backup can break replication. The RHEL 9 planning guide for AD integration is the natural next read for the decision rules.
How a direct AD join and a FreeIPA trust compare on each factor
This table sets a direct SSSD join to Active Directory against a FreeIPA deployment with a cross-forest trust, factor by factor. Read each row for the condition that tips it toward one option, and confirm the items the sources leave open in your own environment before deciding.
| Factor | Direct AD join with SSSD | FreeIPA with a cross-forest trust |
|---|---|---|
| System count | Red Hat suggests direct integration for fewer than roughly 30 to 50 Linux systems, where indirect overhead may not be worth it. | Red Hat suggests indirect integration through Identity Management above roughly 30 to 50 systems, or when rapid growth is expected. |
| Provisioning pattern | Usually simplest when systems are deployed rarely and are mostly bare metal, per Red Hat. | Suits virtual systems provisioned on demand, especially with orchestration tools such as Red Hat Satellite, per Red Hat. |
| Where Linux policy lives | Policy is spread across each host's configuration, so consistency depends on your own tooling and change control. | Host, sudo and HBAC policy is held centrally in FreeIPA, which is the main reason to run it when many hosts need matching rules. |
| Sudo and HBAC support | Confirm in your environment how sudo and access rules behave on each host when joined directly with SSSD, since the sources do not settle this. | FreeIPA provides central sudo and HBAC rules. Sudo and HBAC rules migrated from other LDAP servers need manual LDIF migration, per FreeIPA. |
| AD user experience | AD users authenticate directly against Active Directory and its policies apply, so the experience stays close to Windows-side behavior. | AD users still authenticate against Active Directory and its policies are enforced, so an AD-only authentication requirement is met by either model. |
| DNS requirements | Hosts depend on AD-integrated DNS for domain join and service location. Confirm the DNS design with your AD team. | FreeIPA deployment guidance advises at least two DNS servers in each client's resolv.conf and at least one replica per datacenter running DNS if used. The IPA domain must not overlap any AD forest domain. |
| Windows-side licensing exposure | Adds no Identity Management server, but Windows Server core licensing and CALs apply to the AD domain controllers you already run. | FreeIPA adds no license fee of its own, but the AD domain controllers still carry Windows Server licensing, and Windows Server 2025 needs CALs for each user or device. |
| Effort to change models later | Moving to FreeIPA later means adding an Identity Management layer and reworking host configuration. Confirm the migration path with your vendor or partner. | Removing FreeIPA later means moving hosts back to direct binds and migrating central sudo and HBAC rules out of IdM. Plan and test the change in writing before starting. |
What each model places on the Linux side
Both models put identity logic on Linux hosts, but in different places. A direct join keeps the work on each host, while a FreeIPA trust moves it into a central server that talks to Active Directory. The cards below cover what each component does during a login and what it adds to the estate to run and check.
Direct join with SSSD or Winbind
Each RHEL host is joined to the AD domain using SSSD or Samba Winbind, so the host itself resolves AD users, groups and Kerberos tickets. Every host needs its own join, its own configuration and its own clean-up when it is retired. Check how your team will keep sssd.conf and Kerberos settings consistent across hosts, and who owns that change when a host is rebuilt.
389 Directory Server for user data
FreeIPA stores users, groups, hosts and policies in 389 Directory Server, a multi-master LDAPv3 directory. Linux clients read identity data from this local directory rather than querying AD for every lookup. The trade-off is that replication between IdM servers becomes an operational task you must monitor, back up and test.
MIT Kerberos KDC and Dogtag CA
The MIT Kerberos KDC issues single sign-on tickets for the IPA realm, and the integrated Dogtag certificate authority issues host and service certificates. Both sit on the IdM servers, so their availability and certificate renewal schedule become part of your estate. Confirm which server performs certificate renewal and CRL publication in your topology, since the backup guidance treats the first server as the default holder of those tasks.
Optional DNS and NTP services
FreeIPA can run ISC BIND DNS and NTP alongside the directory, which the deployment guidance treats as dedicated services. Kerberos depends on correct DNS and time, so a trust does not reduce this planning work. Decide whether IdM will host DNS or whether existing resolvers stay in place, and check that every client lists at least two DNS servers in its resolver configuration.
Cross-forest trust built with Samba
The trust with an Active Directory forest is built with Samba components on the IdM side, so AD users can reach Linux resources while AD still authenticates them and enforces its policies. The trust is supported against Windows Server 2008 R2 or later. Confirm the functional level and domain controller versions in your forest before planning the trust, because the trust does not change what your AD domain controllers must support.
Non-overlapping DNS domain requirement
The IPA domain must use a DNS domain that does not overlap with any domain in the AD forest. This is a design decision made before installation, and it shapes hostnames, SRV record lookups and the trust itself. Inventory your existing AD DNS zones and choose the IPA domain name early, because renaming an established IdM domain is not a routine change.
How system count and provisioning pattern decide the model
Red Hat's guidance turns the choice into two questions: how many Linux systems you will run, and how those systems arrive. Its planning documentation suggests direct integration (joining each Linux host straight to Active Directory with SSSD) for fewer than roughly 30 to 50 systems, because a central Identity Management layer may add overhead that a small estate does not need. Above that range, or when you expect rapid growth, it suggests indirect integration, where hosts enroll with a FreeIPA server that holds a trust to AD. Treat the 30 to 50 figure as a rule of thumb from the vendor, not a cutoff. Your own growth plan for the next few years matters more than the count you have today.
The provisioning pattern can outweigh the count. Red Hat says direct integration is usually simplest when systems are deployed rarely and are mostly bare metal. It points toward indirect integration when virtual systems are provisioned on demand, especially with orchestration tools such as Red Hat Satellite. Before choosing, confirm three things with your platform team: how new hosts are built (golden images, kickstart, cloud templates or configuration management), how often that happens, and whether your tooling can enroll a host with a FreeIPA server automatically. If hosts are rebuilt weekly from templates, each rebuild repeats the join work under direct integration, which is a reason to test indirect integration before the estate grows.
Run a short test against your own plan. Count systems by type for the next two to three years, note which ones are cloned or created on demand, and ask your team to join a test host both ways. Confirm with Red Hat or your Satellite documentation how enrollment and host lifecycle are handled for your versions, since these details decide the effort more than the threshold does. The RHEL 9 planning guide for Active Directory integration is the natural next read for the exact criteria.
Central sudo and HBAC policy under each model
In this model, sudo and host-based access control (HBAC) rules are defined once on the Identity Management server and applied to every enrolled Linux host. Administrators write a rule for a host group or user group and every matching client picks it up, so the policy stays consistent as the estate grows. AD users keep authenticating against Active Directory, and the trust lets them reach Linux resources that the IdM rules govern.
- Central definition: sudo rules and HBAC rules live in one place, so a change applies across all enrolled hosts without editing each machine.
- Host groups: rules bind to groups of hosts, which fits environments where servers share a role, such as database or web tiers.
- Migration cost: if you move from another LDAP source, FreeIPA's migration how-to says sudo and HBAC rules need manual migration through LDIF, because the ipa migrate-ds command does not carry them over.
- Trust scope: AD users can be granted rules through the trust, so confirm which AD groups you will map to IdM policy before go-live.
- Operating dependency: the IdM servers become the policy source, so their availability and backup plan directly affect access decisions.
Before choosing this model, confirm in your own environment how many sudo and HBAC rules you already maintain, in what format, and whether a manual LDIF rebuild is acceptable in your migration window.
In this model, each Linux host joins Active Directory directly with SSSD or Samba Winbind, as Red Hat's direct integration guide describes. Microsoft's comparison of Active Directory and Entra ID notes that Group Policy manages Windows desktops and servers, while Linux machines need third-party tools or must be configured to authenticate against Active Directory as a Kerberos realm. Access policy for Linux is therefore not provided by Active Directory's Windows tooling, and you must choose the mechanism yourself.
- No central Linux policy engine: the Windows management model does not extend to Linux access rules, so sudo and login restrictions are configured on the host or through a tool you select.
- Per-host configuration: sudoers and access settings are managed where the host is, which can be manageable at small scale and drift-prone at large scale.
- Third-party tooling: you may need a configuration management or policy tool to push consistent rules, and that tool becomes part of the operating model.
- Kerberos realm setup: the host must be configured correctly against the AD realm, so the setup is a per-host task that must be repeated for every new system.
- Existing AD rules: AD group membership still controls who can log in, but what those users may run with sudo depends on the host configuration.
Before choosing this model, confirm which tool your team will use for Linux access policy, who maintains it, and how it is audited across hosts.
Access policy is the point where the two models differ most in day-to-day work, so verify it with your own data rather than relying on general descriptions. The checks below turn the vendor statements into a concrete inventory for your estate. They also show whether an IdM-centered policy model suits how your teams change access.
- Rule inventory: count your current sudo and HBAC rules, their owners and how often they change, since this sets the migration effort for an IdM rebuild.
- Source of truth: identify where access decisions are recorded today, whether in a spreadsheet, a configuration tool or Active Directory groups.
- Audit requirements: ask your auditors how they expect Linux privileged access to be evidenced, and whether a central record or per-host configuration review is required.
- AD group mapping: list the AD groups that should receive Linux rights and confirm they map cleanly to either IdM rules or host configuration.
- Ownership: name the team that will own the policy after go-live, and confirm they have the skills to operate IdM or the chosen host tooling.
If you are unsure how sudo and HBAC rules would behave in your specific trust layout, confirm the design with Red Hat or the FreeIPA project before committing.
What changes for AD users and their Windows administrators
AD users authenticate against Active Directory under both models. Under a cross-forest trust, a user's password check still happens in AD, and AD's policies (lockout, password rules, sign-in restrictions) still apply. Under direct integration, the same user is also authenticated by AD, through SSSD on each host. An AD requirement is therefore met by either design. What changes is where the Linux side learns about the user: a trust makes AD principals visible to FreeIPA, while direct joins make each Linux host an AD client. Confirm with your AD team that the trust or join does not alter any sign-in restriction they rely on.
A FreeIPA trust leaves AD's own operations in place. The trust lets AD users reach Linux resources and is supported for Active Directory domains on Windows Server 2008 R2 or later, according to the FreeIPA AD trust guide. Domain controllers, Group Policy objects and the Windows administrators who manage them stay where they are, and Windows devices keep their normal domain join. The FreeIPA side needs a DNS domain that does not overlap with any AD domain, so the AD team should review DNS zones and conditional forwarding before anything is configured. Ask them to confirm that no AD domain controller operation depends on Linux changes.
The practical change lands on the help desk and the mapping of groups. Help desk staff will need to know that a Linux access problem may sit in FreeIPA, in the trust, or in AD, and that the Kerberos ticket path crosses both. Access to Linux resources is granted through group membership, so the key decision is how AD security groups map to FreeIPA groups that feed sudo and HBAC rules. Confirm, with a sample of real AD users, which groups they belong to, which Linux hosts and sudo rules each group should reach, and who approves changes on either side. Unmapped groups are the most common source of unexpected access denials.
How to move between a direct join and a FreeIPA trust
This sequence takes a team from its current direct Active Directory join to a FreeIPA deployment with a cross-forest trust, or the reverse, with a checkpoint at each stage so that a move can pause or roll back without breaking authentication for AD users. Durations depend on scope and must be confirmed in a written plan before work starts.
Inventory systems and provisioning pattern
The Linux team lists every host that joins AD today, its operating system, whether it is bare metal or virtual, how often new hosts are built, and which orchestration tools create them. Red Hat's guidance on direct and indirect integration turns on system count and provisioning pattern, so this inventory decides whether a FreeIPA trust is worth the added servers. It also records which sudo rules, HBAC rules, SSH key settings and automation depend on the current join. The step is done when the inventory is signed off by the platform owner and the security lead, and when the team can state, in writing, whether the target is a trust or a continued direct join.
Confirm the IPA DNS domain does not overlap AD
Before any server is built, the architect checks the DNS domain planned for the IPA domain against every domain in the AD forest. FreeIPA's trust documentation requires that the two do not overlap, and changing the domain name later is a larger job than choosing it correctly now. The check should cover child and parent domains, and the team should confirm the DNS zones, delegation and resolver settings with the Active Directory and DNS owners. The step is complete when the domain name, the forest domain list and the DNS ownership are recorded in the design document and approved by the AD team.
Deploy FreeIPA replicas per published recommendations
The platform team builds FreeIPA servers following FreeIPA's deployment recommendations: at least two to three replicas in each datacenter, no more than four replication agreements per replica, dedicated servers that run nothing else, and at least one replica per datacenter running the certificate authority or DNS if those services are used. Clients should be configured with at least two DNS servers in resolv.conf. The team should also decide which server handles certificate renewal and CRL publication, because FreeIPA's backup guidance notes that the first server does this by default. The step is done when replication is healthy across all sites, a test client resolves and authenticates against each replica, and a backup has been taken and restored in a test environment.
Establish the cross-forest trust
The identity team creates the cross-forest trust between the FreeIPA domain and the AD forest, using the procedure in FreeIPA's Active Directory trust setup guide. The AD domain must be Windows Server 2008 R2 or later. The AD administrator and the IPA administrator each confirm the trust status and check that a test AD user can resolve and authenticate on a test Linux host. Users remain authenticated against AD, so AD password policy and account lockout still apply. The step is complete when the trust shows as established on both sides and a named AD test account logs in to a test host, with the results recorded in the change log.
Migrate sudo and HBAC rules manually
The Linux team recreates the sudo and host-based access control rules in FreeIPA. FreeIPA's migration how-to states that the migration command moves users and groups from other LDAP servers but does not move sudo or HBAC rules, which need to be exported as LDIF and imported by hand. Each rule should be reviewed for host groups, user groups and command lists, and the team should remove any rule that no longer matches a current need. The step is done when every exported rule has a documented equivalent in FreeIPA, a reviewer has signed off each mapping, and a test host shows the same sudo and login results as before.
Check Kerberos attributes after migration
The migration tool excludes Kerberos attributes because FreeIPA regenerates them, so the identity team must not expect existing Kerberos principals, keytabs or password hashes to carry across unchanged. Services that depend on keytabs, including web servers and database clients, need new keytabs issued from FreeIPA and deployed through the configuration management process. The team tests each service, confirms that single sign-on works for a sample of users, and records any service that still relies on the old realm. The step is complete when every service in the inventory has been tested against the new realm and any remaining exceptions are documented with an owner and a remediation date agreed in the written plan.
Cut hosts over in stages
The team moves hosts in waves, starting with a small, low-risk group such as test systems or a single application team. Each wave uses a documented change: rejoin or reconfigure the client, confirm the SSSD configuration, verify AD and FreeIPA logins, check sudo and HBAC behavior, and watch logs for failures. The rollback path for each host is written before the change and tested on the first wave. Later waves proceed only after the previous wave has run stably through an agreed review. The step is done when every host in the inventory has been moved or formally excluded, the rollback path has been retired or kept for audit, and the final state matches the design approved in the first step.
Operating effort for each model: replicas, backups, upgrades and skills
This table compares what each integration model asks of the operations team across replicas, backups, patching and skills. Read it as a list of tasks to staff and confirm: the direct join keeps the work on each host and the AD team, while a FreeIPA trust adds a service the Linux team must run well.
| Operating area | Direct AD join (SSSD on each host) | FreeIPA with AD cross-forest trust |
|---|---|---|
| Server footprint | No Linux identity servers to run; each host joins the AD domain with SSSD or Winbind | Dedicated FreeIPA servers, with replicas placed per datacenter following the FreeIPA deployment recommendations (at least two to three replicas per datacenter) |
| Replica placement | Not applicable; host availability depends on AD domain controllers already in place | Limit each replica to no more than four replication agreements; run PKI or DNS on at least one replica per datacenter if those services are used |
| Backup and restore | Host configuration and SSSD settings are backed up as part of normal host management; AD recovery stays with the AD team | Use ipa-backup and ipa-restore; restoring an outdated backup into an active replica topology can break replication, so confirm the restore runbook with the team before an incident |
| Certificate and CRL duties | Handled by the AD certificate services already in use, if any; confirm with the AD team | The first server handles certificate renewal and CRL publication by default, so confirm which server holds that role and how it fails over |
| Security patch cadence | Patching lands on each Linux host and on the AD domain controllers, each run by its own team | Apply the FreeIPA 4.13.4 security release, which fixed two CVEs including LDAP access control flaws, and then track later releases on the FreeIPA side |
| Skills the team needs | SSSD and PAM configuration, Kerberos realm settings on each host, and AD group policy knowledge held by the Windows team | Kerberos, LDAP, DNS and Samba trust components on the Linux side, plus enough AD knowledge to troubleshoot the trust from both sides |
| Who carries the work | Per-host configuration effort, repeated across every new system and rebuild | A central small team owns the IdM servers, while the AD team keeps control of its forest and domain controllers |
What buyers ask before choosing between direct join and a trust
What does the migration effort depend on?
The effort depends on how many Linux systems are involved, how many of them are provisioned automatically, and how much existing policy has to move. A direct join with SSSD is mostly configuration on each host, while a FreeIPA deployment adds servers, replication, DNS, certificates and a trust that must be designed before any host is enrolled. Sudo and HBAC rules do not move automatically. The FreeIPA migration how-to says users and groups can be migrated with ipa migrate-ds, but sudo and HBAC rules need manual migration through LDIF. Ask a partner to scope the host inventory, the rule sets to be rebuilt, the DNS layout, the trust design and the cutover plan, and to list what is excluded from the fixed scope.
Can a team run FreeIPA on its own?
A team can run FreeIPA alone if it has people who can operate Kerberos, LDAP, DNS and certificates and who will keep the replica topology healthy over time. FreeIPA is a community project with no paid edition, so support comes from the team, the community or a contracted partner. The FreeIPA deployment recommendations call for at least two to three replicas in each datacenter, dedicated servers and at least two DNS servers in each client's resolv.conf. Backups need a tested process, because the backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Confirm internal skills against that list before committing, and consider a fixed-scope engagement for the initial build and a retainer for upgrades.
How long does a trust project take?
The duration depends on scope, not on a single standard timeline, so no figure can be given here without a defined design. The work includes the IPA domain design, which must use a DNS domain that does not overlap with any domain in the AD forest, the Samba-based trust setup, DNS changes, host enrollment and testing of AD user logins against Linux resources. A small estate with one AD forest and a clear naming plan takes less design work than a multi-forest environment with many host groups. Ask the partner for a written milestone plan, the assumptions behind it and the Windows and network change windows that the plan depends on.
What drives the cost of each approach?
Cost has three main parts: software, infrastructure and people. FreeIPA has no license fee, and the Linux-side cost is mostly staff time, server hosting and the replicas required by the deployment guidance. An AD estate that needs a trust still has to run Windows domain controllers. Microsoft's Windows Server 2025 pricing page lists a suggested price of 1,176 US dollars for Standard and 6,771 US dollars for Datacenter for 16 core licenses, prices vary by region, and both editions need a Windows Server Client Access License for each user or device that accesses the server. Ask a quote to show one-time work separately from recurring support, retainers, licenses and the staff time that stays with your team.
Can a direct join later become a trust?
Moving from a direct join to a trust is possible in principle, but it is a new deployment, not a switch on existing hosts. Red Hat describes direct integration as Linux systems connected straight to Active Directory, and indirect integration as Linux systems connected to a central Identity Management server that is connected to Active Directory. Hosts enrolled directly would need to be re-pointed at the new server, their local sudo and access rules rebuilt in FreeIPA, and their identities checked for conflicts. Plan the cutover host group by host group and test each group before moving the next. Ask the partner how they would handle identity mapping and rollback.
What skills does the work need from the team?
The work needs working knowledge of Kerberos, DNS, LDAP and certificates on the Linux side, and of Active Directory administration on the Windows side. Red Hat notes that RHEL hosts can be joined directly to an Active Directory domain with SSSD or Samba Winbind, so the direct path leans mostly on Linux administration and AD group design. A trust adds Samba trust configuration, DNS zone planning and coordination with the Windows team on domain controllers and group policy. Both paths need someone who can read Kerberos tickets and DNS failures during a login problem. Confirm which of these skills sit in your team, and ask the partner which gaps their engagement would cover.
Which approach is harder to exit later?
A FreeIPA trust is harder to exit than a direct join because it adds a second identity system with its own servers, replication, certificates and policy store. Leaving it means moving users, groups, sudo and HBAC rules and host enrollments, and the FreeIPA migration documentation notes that sudo and HBAC rules need manual migration. A direct join keeps Active Directory as the single source of truth, so exiting means reconfiguring SSSD on each host. Ask a partner to document the export path for policy, the certificates in use and the rollback steps before the build starts.
How DeployOpen scopes and delivers the integration
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so the choice between direct Active Directory joins and a FreeIPA trust is made against your real system count, provisioning pattern and policy needs. We scope the work in writing before any build starts, then document and hand over what we deliver.
How we scope
- Count Linux hosts, planned growth and how systems are provisioned, including whether virtual machines are created on demand.
- Map which sudo and HBAC policies must be central, and which AD users and groups need access to which Linux resources.
- Agree the scope, deliverables and timelines in writing before work starts, since most engagements are fixed-scope.
- Confirm with your AD team the forest and DNS layout, because an IPA domain must not overlap any AD DNS domain.
How we build
- Deploy either direct SSSD joins or a FreeIPA server with a cross-forest trust, inside your cloud accounts, data centers or air-gapped networks.
- Configure replicas, DNS and certificate services according to the scope agreed for your environment.
- Test AD user logins, Kerberos single sign-on, sudo rules and HBAC policies against a defined set of test cases.
- Migrate existing sudo and HBAC rules by hand where automated migration does not cover them.
How we hand over
- Document the chosen integration model, configuration, trust settings and the reasons behind each design decision.
- Provide backup and restore procedures, including how replicas are restored so that an outdated backup does not break replication.
- Deliver runbooks for adding hosts, changing policies and onboarding AD users, so your team can run the platform.
- Walk your operations and security staff through the handover and the evidence needed for compliance assessments.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Plan FreeIPA upgrades and patch reviews, including security fixes in each release, against your change windows.
- Confirm with us which support scope fits your team before the engagement starts, so responsibilities are clear.
- Request a quote from the written scope, which sets the cost components, timelines and what recurs after handover.
