What FreeIPA manages
FreeIPA centralizes identity, authentication and access policy for Linux and UNIX systems. It holds users, groups, hosts and services, issues Kerberos tickets, runs an integrated certificate authority, and stores policy such as host-based access control and sudo rules. Enrolled hosts read that policy through SSSD, so an administrator changes access in one place and every enrolled server applies it.
FreeIPA is the upstream open-source project for Red Hat Identity Management (IdM) and is licensed under GPL-3.0. Red Hat's IdM documentation holds much of the detailed planning and recovery guidance, and it applies closely to FreeIPA. Teams that want vendor support usually run IdM on RHEL under a subscription; others run FreeIPA on Fedora, CentOS Stream or RHEL-compatible distributions.
It suits estates with many Linux servers, sprawling SSH keys and local accounts, or auditors asking who can reach which host with which privileges. Web single sign-on with SAML or OIDC usually comes from an identity broker, such as Keycloak, federated to FreeIPA.
The services inside a FreeIPA server
Each server runs several established open-source components, and backup, monitoring and upgrades must cover all of them.
389 Directory Server
The LDAP back end that stores users, hosts, policies and configuration. Replication between servers lets the domain survive the loss of a server.
MIT Kerberos KDC
The core of authentication. Users and hosts obtain tickets for single sign-on to SSH, NFS and other Kerberized services. Kerberos tolerates only small clock differences, so time synchronization is part of the design.
Dogtag certificate system
The integrated CA issues host and service certificates, renewed automatically through certmonger. An optional key recovery authority (KRA) supports the vault feature.
Integrated DNS
An optional BIND-based DNS server publishes the SRV records clients and AD trusts need. Estates that keep their own DNS delegate or forward a zone.
SSSD on clients
Resolves identities, authenticates users, applies access rules and caches credentials so logins continue during a short loss of contact with the servers.
Plan the replica topology
Red Hat's IdM planning and disaster recovery guides set out this guidance, and it applies to FreeIPA too. Red Hat supports up to 60 servers in one IdM domain.
| Topic | Guidance | Why it matters |
|---|---|---|
| Replicas per site | Place at least two servers in each data center that clients depend on. | One server can be patched or lost while local clients keep authenticating. |
| Replication agreements | Connect each server to at least two others and usually no more than four. Red Hat describes the upper figure as a recommendation. | Two agreements avoid single paths; more than four usually adds load without faster updates. |
| CA servers | Run the integrated CA on several servers. Red Hat's disaster recovery guide recommends three or more CA replicas. | If every CA server is lost, the domain can no longer build new replicas without restoring from backup. |
| Renewal and CRL roles | Record which server is the CA renewal server and which publishes the CRL. | These roles exist on one server each and must be moved before that server is decommissioned. |
Define access policy centrally
HBAC rules decide which users or groups may reach which hosts through which services, such as sshd or sudo. Test new rules with the HBAC test tool on a pilot host group before disabling the default allow-all rule, or administrators can be locked out.
Store sudo rules in FreeIPA and let SSSD deliver them. Group commands, scope rules to host groups, and remove local sudoers files once central rules are confirmed, so privileged access is reviewed in one place.
Enroll hosts with ipa-client-install or automation so each gets a Kerberos identity and keytab. Register services such as HTTP or NFS as principals and issue their certificates from the integrated CA with automatic renewal.
Integrate with Active Directory
Many organizations keep Active Directory for Windows and workforce accounts and use FreeIPA for Linux policy. A cross-forest trust lets AD users authenticate to FreeIPA-managed hosts with their AD credentials, while HBAC and sudo rules stay in FreeIPA. Red Hat's planning guide notes that a two-way trust is nearly equivalent to a one-way trust in practice, because IdM does not provide a Global Catalog service, so most deployments start with a one-way trust.
A trust needs separate DNS domains for FreeIPA and AD, name resolution in both directions, common Kerberos encryption types and open firewall ports. Decide how AD users get POSIX IDs before creating the trust: ID mapping derives UIDs and GIDs from AD security identifiers, while a POSIX range uses uidNumber and gidNumber attributes already set in AD. Changing that choice later changes file ownership on every host, so test it on a pilot group first. Trust controllers use Samba components installed with ipa-adtrust-install.
ID views override attributes such as login shell or home directory for AD users on specific hosts. Test logins from each relevant AD domain, group resolution and sudo rules that reference AD groups through external groups.
Harden the domain and plan recovery
Limit the admin account and Directory Manager credentials to break-glass use, and give administrators personal accounts with delegated roles. Set password policies per group, require one-time-password two-factor authentication for privileged users, and keep clocks synchronized. IdM Healthcheck (ipa-healthcheck) reports certificate, replication and service problems in one run.
Recovery combines replication, virtual machine snapshots and ipa-backup. A full-server backup includes configuration and LDAP data and needs services stopped, which a hidden replica allows without affecting clients. A data-only backup can run online. Back up a server that holds the CA, DNS and KRA roles you use, and encrypt backups with GPG before they leave it.
A full restore expects a server with the same hostname, IP address and IdM software version as the original. When one server fails, Red Hat prefers rebuilding it as a new replica, since a backup is usually older than replicated data. Keep restore from backup for cases such as losing every CA server or data corruption, and rehearse it in an isolated network.
Upgrades and migration paths
Minor updates arrive as distribution packages and run their upgrade steps during package installation. Update one server at a time, check replication and services, then continue. Moving to a new major operating system release is done through replicas: install a server on the new release as a replica, move the CA renewal server and CRL publisher roles to it, then decommission the old servers. Red Hat documents this path for IdM, and its RHEL 8 guide states that in-place upgrades of IdM servers from RHEL 7 are not supported.
Moving from FreeIPA on another distribution to IdM on RHEL follows the same replica approach. Migrating from an existing LDAP directory or NIS uses FreeIPA's migration tooling and a password plan, since users may need to authenticate once before Kerberos keys exist. Enroll clients in waves, starting with a host group whose owners can test logins, sudo and file ownership quickly.
FreeIPA operating ownership
FreeIPA sits underneath every enrolled login, so ownership has to cover the servers, the policy and the hosts that depend on them.
Identity platform
- Maintains servers, replication and the topology diagram.
- Tracks the CA renewal and CRL publisher role holders.
- Runs health checks, backups and restore rehearsals.
Access policy owners
- Approve HBAC and sudo rule changes.
- Review privileged groups and AD group mappings.
- Remove rules for retired systems.
Linux and host teams
- Enroll hosts through automation with consistent SSSD settings.
- Remove local accounts once central rules apply.
- Report login failures with host, user and time.
Security and PKI
- Protect Directory Manager and admin credentials.
- Monitor certificate expiry and CA health.
- Keep backups and their keys under separate control.
FreeIPA deployment questions
Can FreeIPA replace Active Directory?
For Linux identity and policy, often yes. For Windows desktops and Group Policy, no. A common pattern keeps AD for Windows and connects it to FreeIPA with a trust, so Linux access policy lives in FreeIPA.
Should we use the integrated DNS?
Integrated DNS simplifies SRV records and trust setup. If another team owns DNS, a delegated or forwarded zone works as long as the records FreeIPA needs are published and maintained.
Scope and handover
Effort depends on the number of sites and servers, whether an AD trust is needed, how many hosts and local accounts exist today, the state of DNS and time synchronization, and the amount of sudo and access policy to translate. Cleaning up existing local accounts and privileges often takes longer than installing the servers.
DeployOpen plans the topology, deploys and hardens the servers, configures the CA and DNS, sets up the AD trust where needed, translates access policy into HBAC and sudo rules, automates client enrollment, configures encrypted backups and rehearses a recovery. Handover includes the topology diagram with role holders, policy inventory, enrollment automation, restore record and upgrade procedure.
