Accounts and SSO: Part 3 — FreeIPA

FreeIPA — a centralized account management system for Linux servers and workstations. It solves the same problem as Active Directory in the Windows world: users, groups, passwords, access rights to servers and sudo rules are stored in one place instead of being configured on each machine separately.

Components

FreeIPA combines proven open components into a single manageable suite:

• 389 Directory Server — an LDAP directory where users, groups, hosts and policies are stored;
• MIT Kerberos — single sign-on: the user gets a ticket once and accesses servers without re-entering a password;
• Dogtag — a Certificate Authority for issuing certificates to servers and services;
• BIND DNS with zone storage integrated in the directory — an optional component;
• SSSD on clients — caches credentials and allows logging in even when the server is temporarily unavailable.

Everything can be managed via the web interface, the ipa command line and the API. FreeIPA’s integration layer is distributed under GPLv3; components keep their own licenses. The current version as of September 2026 is 4.13.4.

Important note: since version 4.7 the FreeIPA server does not provide accurate time. The ntpd service was replaced by chrony, and FreeIPA servers synchronize time only as clients. Accurate time for Kerberos remains critical, so a network NTP source is required separately.

Benefits in practice

• Centralized accounts. An employee is created once and can log into all connected servers; upon termination the account is disabled in one place.
• Access rules (HBAC). Which group can access which servers and via which services.
• Centralized sudo. Elevation rules are stored in the directory, not in files on each server.
• SSH keys in the directory. Users’ public keys are stored in FreeIPA and SSSD provides them to the server at login.
• Service certificates from the built-in Certificate Authority.
• Trust with Active Directory. Windows domain users can log into Linux servers with their accounts without being migrated into FreeIPA.

How to install

The server is installed on an RHEL-compatible system (RHEL, AlmaLinux, Rocky Linux) or Fedora. Requirements: a static IP address, the server’s fully qualified domain name (for example, ipa.example.lan), correct name resolution and accurate time.

dnf install ipa-server ipa-server-dns
ipa-server-install --setup-dns
kinit admin

The installer will ask for the domain name and Kerberos realm, the Directory Manager password and the admin account password — both at least 8 characters. After installation kinit admin obtains a Kerberos ticket; you can check it with klist. Clients are enrolled with ipa-client-install; the --mkhomedir option creates a home directory on first login.

For a second server and high availability configure replication (ipa-replica-install): without a replica a failure of the single server will leave everyone unable to log in.

Trust with Active Directory

Typical flow according to the project documentation:

ipa-adtrust-install --netbios-name=IPA -a 'admin-password'
ipa trust-add --type=ad ad.example.lan --admin Administrator --password
ipa trust-fetch-domains ad.example.lan

The main requirement is mutual visibility of domains in DNS: configure conditional forwards of each other’s zones on the AD controller and on the FreeIPA server. In addition, server times must match and Kerberos (88), LDAP (389), SMB (445) and other ports listed in the documentation must be open.

Limitations

• Complexity. Kerberos, LDAP, DNS and certificates require expertise; DNS or time errors cause hard-to-diagnose login failures.
• Not for web applications. User login to web services via OIDC is handled by Keycloak, which can source users from FreeIPA via LDAP.
• Server platform. The FreeIPA server is installed on RHEL-compatible systems and Fedora; clients work on other distributions as well.

Common mistakes

• A single FreeIPA server without a replica.
• Incorrect hostname or DNS: installation succeeds but clients cannot find the server.
• No accurate time source in the network after switching to chrony.
• Installing on a server where other services already use ports 80, 443 or 389.

When to choose

FreeIPA is appropriate when there are dozens or more Linux servers and managing accounts manually becomes impractical, and when Linux servers need to be connected to an existing Active Directory domain. For authenticating users to a single website this is an overly complex solution.