FreeIPA in the Enterprise

Identity & Access Management / Infrastructure

Active Directory has been the default answer to enterprise identity for two decades, but if your infrastructure leans Linux-heavy or container-native, FreeIPA is worth a serious look. This is a practical, end-to-end walkthrough of what FreeIPA is, how it stacks up against AD, how we deployed it in production, and how we handled the parts that usually trip teams up — mail integration, SSO, web app auth, and migrating an existing AD estate over without a lights-out weekend.

What is FreeIPA?

FreeIPA (Identity, Policy, Audit) is Red Hat's open-source identity management platform. It isn't a single tool — it's an integration layer bundling a directory, an authentication protocol, and a certificate authority into one managed stack:

389 Directory Server — the LDAP backend
MIT Kerberos — authentication and single sign-on
Dogtag Certificate System — an internal CA / PKI, included out of the box
BIND — integrated DNS (optional, but recommended)
SSSD on clients — the glue that makes Linux hosts talk to everything above
A web UI and CLI (ipa) for administration

Think of it as identity management built Linux-first — architecturally closer to a properly integrated LDAP + Kerberos + PKI stack than a reimplementation of AD's protocol suite.

FreeIPA vs. Active Directory

AreaActive DirectoryFreeIPA LicensingWindows Server CALs, per-core licensingFree, open source Native platformWindows-first, Linux bolted on via SSSD/winbindLinux-first, Windows via trust relationships DirectoryProprietary AD DS (LDAP-compatible)Standard 389 LDAP Auth protocolKerberos + legacy NTLMKerberos only — no NTLM baggage PKIRequires a separate AD CS roleBuilt-in Dogtag CA out of the box DNSIntegrated, AD-integrated zonesIntegrated via BIND, optional Policy modelGPOs — powerful, Windows-centricHBAC + native sudo rules, simpler mental model AutomationPowerShell + RSAT, Windows-boundFull CLI/API, Ansible-friendly Attack surfaceFrequent target — Kerberoasting, Golden/Silver Ticket, DCSync, NTLM relaySmaller surface, no NTLM — but poor SPN hygiene still opens Kerberoasting-style risk ReplicationMulti-master since 2008Native multi-master 389-DS replication Trust with the other sideN/ANative one-way or two-way cross-realm Kerberos trust with AD Cost at scaleScales expensively (CALs, server licenses)Scales for the cost of compute

Where FreeIPA wins

No NTLM — a huge chunk of AD's historical relay and pass-the-hash surface just doesn't exist
API-first administration — real infrastructure-as-code for identity
Built-in CA — working internal PKI from day one
HBAC + sudo rules are declarative, far smaller than the GPO model
No CALs — runs happily on a couple of modest VMs

Where AD still wins

Windows endpoint management — GPOs and Intune are unmatched for Windows fleets
Ecosystem maturity — more third-party software assumes AD schema
Familiarity — your helpdesk already knows it

Our take: if you're majority Linux/container infrastructure with a minority of Windows endpoints, FreeIPA as the source of truth with a cross-forest trust to AD for the Windows subset is the sweet spot — covered under Migration below.

Installation

We deployed on RHEL 9 / Rocky 9 — FreeIPA packages track RHEL releases closely; Fedora also works fine for lab environments.

Prerequisites

Static IP with correct forward and reverse DNS — get PTR records right before running the installer, this trips up more installs than anything else
Fully qualified hostname matching DNS
Firewall ports open: 80/443 (HTTP/HTTPS), 389/636 (LDAP/LDAPS), 88/464 (Kerberos, TCP+UDP), 53 (DNS if using integrated DNS), 123 (NTP/chrony)
SELinux enforcing — leave it on, FreeIPA ships its own policy

Base install

# RHEL/Rocky 9
sudo dnf install -y freeipa-server freeipa-server-dns

sudo ipa-server-install \
  --realm=CORP.EXAMPLE.COM \
  --domain=corp.example.com \
  --ds-password='<directory-manager-password>' \
  --admin-password='<admin-password>' \
  --setup-dns \
  --auto-forwarders \
  --allow-zone-overlap \
  --no-ntp

Notes from our deployment

--no-ntp because we already manage chrony centrally — let the installer skip its own NTP setup and point chrony at your internal time source manually. Kerberos is extremely time-sensitive (5-minute default clock skew tolerance by default), so get this right before anything else.

Use --setup-dns only if FreeIPA is going to be authoritative for the domain. If you already have DNS infrastructure you're not replacing, skip it and manage SRV records manually — more work, more flexibility.

On a modest VM (4 vCPU / 8GB) the full install — CA, KDC, and directory server — takes about 10–15 minutes.

Replica for HA

Never run single-master in production:

sudo dnf install -y freeipa-server freeipa-server-dns
sudo ipa-replica-install \
  --setup-dns \
  --auto-forwarders \
  --admin-password='<admin-password>'

We run three replicas across two DCs for quorum-ish resilience — 389-DS replication is multi-master, so any replica can serve writes.

Enrolling clients

sudo dnf install -y ipa-client
sudo ipa-client-install --mkhomedir --enable-dns-updates

This configures SSSD, PAM, NSS, and Kerberos on the client in a single pass.

Tweaking and hardening

A few changes from defaults worth making on any production install.

Tighter password policy

ipa pwpolicy-mod --maxlife=90 --minlife=1 --history=10 \
  --minlength=14 --minclasses=3 --maxfail=5 --failinterval=5 --lockouttime=900

Two-factor for privileged accounts

ipa user-mod jdoe --user-auth-type=otp

FreeIPA supports TOTP natively — users self-enroll a token via the web UI, compatible with Google Authenticator and FreeOTP.

HBAC rules — deny by default, allow explicitly

ipa hbacrule-add allow_ssh_ops --hostcategory=all
ipa hbacrule-add-user allow_ssh_ops --groups=ops-team
ipa hbacrule-add-service allow_ssh_ops --hbacsvcs=sshd

Sudo rules, centrally managed

ipa sudorule-add webserver_admins
ipa sudorule-add-allow-command webserver_admins --sudocmds='/usr/bin/systemctl restart httpd'
ipa sudorule-add-user webserver_admins --groups=web-admins
ipa sudorule-add-host webserver_admins --hosts=web01.corp.example.com

No more local /etc/sudoers sprawl across every box.

Replication topology

ipa-replica-manage list
ipa topologysegment-find domain

Don't let this sprawl into a mesh nobody understands — we run a simple hub topology across our two DCs.

Email integration

FreeIPA doesn't run mail itself, but it's an excellent auth and directory backend for Postfix + Dovecot.

Postfix (SMTP), authenticating against FreeIPA's LDAP

# /etc/postfix/main.cf
virtual_mailbox_domains = corp.example.com
virtual_mailbox_maps = ldap:/etc/postfix/ldap-users.cf
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

# /etc/postfix/ldap-users.cf
server_host = ldap://ipa01.corp.example.com
search_base = cn=users,cn=accounts,dc=corp,dc=example,dc=com
query_filter = (&(objectClass=posixAccount)(mail=%s))
result_attribute = uid

Dovecot (IMAP) with GSSAPI for real SSO to mail clients

# /etc/dovecot/conf.d/10-auth.conf
auth_mechanisms = plain login gssapi
auth_gssapi_hostname = mail.corp.example.com
auth_krb5_keytab = /etc/dovecot/dovecot.keytab

Generate the keytab as a FreeIPA service principal:

ipa service-add imap/mail.corp.example.com
ipa-getkeytab -s ipa01.corp.example.com -p imap/mail.corp.example.com -k /etc/dovecot/dovecot.keytab

With this in place, any domain-joined client holding a valid Kerberos ticket (kinit) authenticates to IMAP with zero password prompt — genuine SSO for mail, not just password sync dressed up as SSO.

Exchange / Outlook shops

For orgs mid-migration keeping Exchange (or moving to a hosted mail provider), this is usually the hardest cutover. Most teams use FreeIPA purely as the LDAP/Kerberos identity source via sync, rather than trying to replace Exchange outright. Treat "replace Exchange" and "replace AD" as two separate projects.

Enterprise deployment considerations

Replica placement — one per site/DC minimum; keep CA-configured replicas to a small trusted set, since that role carries broader privileges
Backup — automate ipa-backup (full or data-only), store off-host, and actually test restores with ipa-restore before you need it in an incident
Monitoring — 389-DS exposes stats via ldapsearch against cn=monitor; wire this into Prometheus and watch replication lag specifically
Scale — 389-DS handles tens of thousands of entries comfortably per instance; tune nsslapd-cachememsize and index attributes you query often for larger orgs
Change control — every ipa CLI command is auditable; ship /var/log/dirsrv/ and /var/log/httpd/ to your SIEM
Delegated admin — scope helpdesk staff to password resets and group membership via role-add / privilege-add, don't hand out full admin role membership

Migrating from Active Directory

AD → FreeIPA migrations generally take one of three shapes, in increasing order of disruption.

Cross-realm trust — coexistence, lowest risk

FreeIPA supports a native trust to an AD forest. AD users authenticate to Linux/FreeIPA-managed resources without any account migration at all:

ipa-adtrust-install --add-sids
ipa trust-add --type=ad corp.example.com \
  --admin Administrator --password

AD stays authoritative for Windows and user accounts; FreeIPA becomes authoritative for Linux hosts, sudo/HBAC policy, and service auth. AD users get UIDs/GIDs generated via ID mapping (ipa idrange-add) so they can log into Linux boxes and own files sanely. This is by far the least disruptive path.

Full account migration — for orgs actually decommissioning AD

Export users and groups from AD via ldifde or PowerShell's Get-ADUser / Get-ADGroup piped to CSV/LDIF.

Transform the data — AD's schema doesn't map 1:1 to POSIX unless it already has UNIX attributes extended. We wrote a Python + python-ldap transform script to generate POSIX attributes deterministically; FreeIPA's ipa migrate-ds can also do this directly if AD already has a POSIX schema extension.

Password continuity, honestly

AD does not export cleartext passwords or usable NTLM hashes for direct import into Kerberos. You generally cannot migrate password hashes directly. FreeIPA's supported approach is a migration web page (/ipa/migration) that captures the user's existing password on their first post-cutover login and provisions their Kerberos key at that moment — never storing plaintext at rest. Alternatively, force a reset on next login via ipa-migrate-ds in compat mode.

Re-enroll clients with ipa-client-install on every Linux host; Windows endpoints stay on AD under a hybrid trust or get rejoined if going fully Linux-only (rare).

Cut over DNS and the Kerberos realm last, in a maintenance window, with AD kept read-only and available for rollback for at least one full business cycle.

What we actually did

We ran Option 1 (cross-realm trust) in production for six months before doing a selective Option 2 migration for service accounts and Linux-only users, keeping true AD accounts under trust for the Windows population. Staged this way, the majority of users never saw a forced password reset.

Single sign-on (SSO)

FreeIPA's Kerberos core makes it a natural SSO hub, but "enterprise SSO" today usually also means SAML/OIDC for SaaS apps that don't speak Kerberos. We layer both.

True Kerberos SSO

Internal apps, intranet, and mail get zero-password-prompt SSO for any domain-joined client, as shown above for mail and below for web apps.

SAML / OIDC via Keycloak

We front FreeIPA with Keycloak, using FreeIPA as the LDAP user federation backend:

Keycloak Admin Console → User Federation → Add LDAP provider
  Connection URL: ldaps://ipa01.corp.example.com
  Users DN: cn=users,cn=accounts,dc=corp,dc=example,dc=com
  Bind DN: uid=svc-keycloak,cn=sysaccounts,cn=etc,dc=corp,dc=example,dc=com
  Authentication type: simple

This gets SAML 2.0 and OIDC identity provider capability for SaaS apps while FreeIPA stays the single source of truth for accounts, group membership, and password policy. Group memberships sync from FreeIPA groups to Keycloak roles, which map to SaaS entitlements — one place to add or remove someone from a project.

Web app and host integration

For internal web apps on Apache, native Kerberos SSO via mod_auth_gssapi:

sudo dnf install -y mod_auth_gssapi
ipa service-add HTTP/app.corp.example.com
ipa-getkeytab -s ipa01.corp.example.com -p HTTP/app.corp.example.com -k /etc/httpd/conf/http.keytab
sudo chown apache:apache /etc/httpd/conf/http.keytab

# Apache vhost config
<Location "/">
    AuthType GSSAPI
    AuthName "Corp SSO"
    GssapiCredStore keytab:/etc/httpd/conf/http.keytab
    Require valid-user
</Location>

Browsers on domain-joined machines with SPNEGO enabled (Chrome/Firefox with the negotiate-delegation whitelist set to your domain) authenticate silently — no login page, no password.

nginx and the web UI itself

mod_auth_gssapi isn't natively available for nginx, so most teams put a small Apache reverse-proxy shim in front purely for the auth layer, or move that particular app to the Keycloak/OIDC path instead. For the FreeIPA web UI itself, keep it reachable only from admin subnets — it's a high-value target and ordinary users don't need it; expose self-service password reset narrowly via a separate proxied path if required.

Closing thoughts

FreeIPA isn't a drop-in AD replacement, and pretending otherwise sets a migration up to fail. It's the right call when your identity needs are Linux/Kerberos-centric, you want infrastructure-as-code-friendly identity management, and you're willing to run a trust relationship — or a staged migration — for the Windows minority rather than forcing an all-or-nothing cutover.

For us, the combination of reduced attack surface from dropping NTLM, native PKI, and a fully scriptable API made it worth the investment. If you're evaluating this for your own org: start with a lab install, stand up the AD trust first, and prove out SSO for one internal app before touching anything production-critical.

Planning an identity overhaul?

We can walk your team through a FreeIPA deployment or a staged AD migration, from lab install to production cutover.

Talk to us about identity infrastructure