FreeIPA

Last reviewed Sep 13, 2026 · 898 words

The trap with FreeIPA is treating it like another container in your compose file. It is not. It wants a dedicated host, a real fully qualified hostname with forward and reverse DNS that resolve before you run the installer, 2 GB of RAM at idle, and a Red Hat family operating system underneath. Meet those conditions and ipa-server-install gives you, in about 20 minutes, the only open-source stack that makes 50 Linux machines share users, sudo rules, SSH keys, certificates and Kerberos single sign-on the way Windows shops take for granted. Skip them and you will spend a weekend fighting DNS.

It is five services pretending to be one

Under the single ipa command sit 389 Directory Server for LDAP, MIT Kerberos for tickets, Dogtag for the certificate authority, BIND for DNS, and SSSD on every enrolled client to tie them together. FreeIPA's real product is the integration: create a user once and they get an LDAP entry, a Kerberos principal, a home directory policy and a place in host-based access control. The listing's "all-in-one identity stack" is exactly that, and it is also why the whole thing has a reputation for being heavy. You are running the same components a mid-size enterprise runs, tuned so one admin can manage them.

DNS and hostnames before anything else

Every FreeIPA problem I have debugged in a homelab traced back to naming. The server needs a hostname like ipa.home.example.com, not ipa, and the domain you give the installer becomes the Kerberos realm in upper case. Let FreeIPA run its own BIND and delegate the subdomain to it from your main resolver, or set every host's /etc/hosts by hand and regret it. Time must be synchronised, because Kerberos rejects tickets from a client that is 5 minutes out. Firewall ports 80, 443, 389, 636, 88, 464 and 53 between server and clients.

The supported platforms are Fedora, RHEL and its rebuilds like Rocky and AlmaLinux. There is a freeipa-server container image, but it needs systemd inside the container and privileged mode, and most people who start there end up on a small VM instead. The client side is broader: ipa-client-install works on Debian and Ubuntu, and a Raspberry Pi can enrol fine.

What it gives a Linux fleet that lldap cannot

lldap is the right call for 90 percent of homelabs: a 30 MB LDAP server that lets Nextcloud, Jellyfin and Gitea share one login. What it cannot do is everything that happens after login on the machines themselves. FreeIPA's host-based access control decides which groups may SSH into which hosts. Its sudo rules ship to every client, so admins get root on all servers and media gets it on one. It stores users' SSH public keys and SSSD serves them to sshd, so provisioning a new machine means enrolling it, not copying authorized_keys. Its CA issues host and service certificates and renews them automatically with certmonger. Kerberos gives passwordless SSH between enrolled hosts and ticket-based NFS.

If you have three servers and log into them with the same key, none of that matters. If you have 15 VMs, two people who need access, and a habit of rebuilding machines, it is the difference between identity and a spreadsheet.

It is not an OIDC provider, so pair it with Keycloak

FreeIPA does LDAP and Kerberos. It does not do OpenID Connect or SAML, which is what every modern web application in your stack wants. The standard pattern is FreeIPA as the source of truth for accounts and groups, with Keycloak or Authentik federated to its LDAP in front of your web apps. That gives you one password everywhere: SSH and sudo through SSSD, browser logins through OIDC. The SSO write-up covers the web side; FreeIPA is what you add underneath when the machines themselves need to know who you are.

For mixed networks with Windows clients, FreeIPA can establish a trust with a real Active Directory, or you can run Samba as an AD domain controller instead and accept weaker Linux policy features. Anyone weighing those options should read the Active Directory alternatives page before committing.

Backup, replicas, and the upgrade tax

ipa-backup produces a full or data-only archive; ship it off the host, because a lost FreeIPA server with no replica means re-enrolling every client. The better protection is a second server installed with ipa-replica-install, which is what the project expects and what makes upgrades survivable: update one, confirm, update the other. Major version upgrades track the OS, so a Rocky 9 to 10 move is also a FreeIPA move, and reading the release notes is not optional.

What I'd do

Run FreeIPA only if you have a dozen or more Linux hosts and care about sudo rules, SSH key distribution or certificates. Put it on a 2 vCPU, 4 GB Rocky or Alma VM with its own DNS zone, add a replica within the month, and front it with Keycloak for the web apps. For a typical homelab of a handful of containers on one or two boxes, install lldap and Authentik instead and keep the weekend. FreeIPA is excellent at a job most self-hosters do not yet have.