FreeIPA in Large Environments: Architecture, High Availability, HBAC, sudo and Keycloak

Why FreeIPA Is More Than LDAP

A small FreeIPA installation is quick to build. In larger environments, the questions change: What happens during a site outage? Who is the source of truth? Where are technical permissions modeled? Should DNS live inside FreeIPA? Which PKI issues which certificates? How do you avoid maintaining the same rights again in Keycloak?

This article builds on the practical starting point Installing FreeIPA: From the First Server to an Enrolled Linux Client. First comes the reproducible build; then come the enterprise questions: operations, clear ownership boundaries, high availability, HBAC, sudo, Keycloak, monitoring and recovery.

Red Hat Identity Management is the commercially supported enterprise variant of this technology for RHEL environments. Architecture decisions should therefore distinguish clearly: FreeIPA describes the open technology core, while Red Hat IdM is the supported platform with vendor lifecycle and enterprise support.

Architecture Overview

In larger environments, FreeIPA should not be treated as a single LDAP server. It is the core for Linux identities, Kerberos, groups, host access, HBAC and sudo. Other responsibilities can intentionally remain in separate systems.

Users / Admins
      |
      v
FreeIPA Multi-Primary Replicas
      |-- LDAP / LDAPS
      |-- Kerberos
      |-- HBAC / sudo
      |-- internal Dogtag PKI
      |
      +--> Linux clients via SSSD
      +--> Keycloak -> OIDC / SAML -> Applications
      +--> Monitoring and automation

External responsibilities:
      Knot DNS      -> authoritative DNS and service discovery
      Smallstep CA  -> service and infrastructure certificates
      Ansible/AWX   -> desired state, reviews and controlled rollout

This separation is not academic. It prevents DNS, service certificates, SSO claims and Linux access control from growing into one unclear operational bundle. Each component has a clear responsibility and can be monitored, changed and recovered separately.

Keep DNS Separate Deliberately

Integrated FreeIPA DNS is convenient in small environments. In larger environments, it can be reasonable to operate authoritative DNS separately, for example with Knot DNS. DNS then remains independent from identity, existing enterprise DNS processes can stay in place and FreeIPA does not become responsible for every infrastructure concern.

The responsibility does not disappear. External DNS must reliably provide FreeIPA discovery: A/AAAA, PTR, LDAP SRV, Kerberos SRV, kpasswd SRV, priorities, weights, TTLs and forward/reverse consistency. Kerberos is especially sensitive to naming and time issues.

_ldap._tcp.example.org.       SRV 0 100 389 idm-a.example.org.
_kerberos._udp.example.org.   SRV 0 100 88  idm-a.example.org.
_kerberos._tcp.example.org.   SRV 0 100 88  idm-a.example.org.
_kpasswd._udp.example.org.    SRV 0 100 464 idm-a.example.org.
_kpasswd._tcp.example.org.    SRV 0 100 464 idm-a.example.org.

External DNS is therefore not a flaw. It is an intentional architecture decision with its own operational contract. When FreeIPA replicas change, DNS discovery and client behavior must be tested as well.

Multi-Primary and Site Design

FreeIPA uses replicating multi-primary replicas. It is not a classic active/passive architecture. Changes are replicated between replicas, and clients can discover suitable servers through DNS.

An anonymized example: Site A runs three replicas, Site B runs one replica. This can be viable for the overall architecture because single node failures do not immediately take down the identity platform. Still, Site B has only one local IdM node and therefore no site-local IdM high availability.

• If Site B is an edge, DR or smaller branch site, a single replica can be acceptable.

• If Site B must continue autonomously, a second local replica or a clearly tested failover model should be evaluated.

• Four running servers do not automatically mean healthy replication. Topology, server roles, domain suffix, CA suffix and replication health must be checked actively.

Replication Is Not Backup

Replication protects against node loss. It does not protect against replicated deletions, faulty admin changes, logical directory corruption, compromised credentials or CA/PKI problems. An incorrect group or user state can be replicated very reliably to every replica. That is exactly why replication is not backup.

A reliable operating model separates three procedures: replication for availability, backup for data recovery and replica rebuild for lost nodes. Not every lost replica should be restored; often a clean rebuild followed by replication validation is the better path.

Separate Dogtag and Smallstep

FreeIPA includes Dogtag because internal FreeIPA functions need certificates. That does not mean Dogtag should automatically become the general enterprise service PKI. For web, service and infrastructure certificates, a separate Smallstep CA can be the cleaner model.

The most important rule is simple: no certificate should accidentally be managed by two renewal mechanisms at the same time. certmonger belongs to the FreeIPA-adjacent world. Smallstep manages its own service certificates. CA bundles and trust stores are distributed deliberately, but they are not certificate issuance by themselves.

Certificate Type                Owner              Renewal Tool        Monitoring
FreeIPA internal CA             Dogtag / FreeIPA   certmonger/Dogtag   IPA health and expiry
FreeIPA LDAP/HTTP if IPA-owned  FreeIPA            certmonger          getcert and service checks
Service and web TLS             Smallstep CA       step / ACME client  expiry and renewal checks
Trust stores and CA bundles     Automation         Ansible            file and trust validation

Identity Model with org, role, peg and hg

In larger environments, organization, responsibility, technical permission and target systems should be modeled separately. One practical model uses four namespaces: `org.*` for organizational membership, `role.*` for responsibilities, `peg.*` for technical permission or entitlement groups and `hg.*` for host groups.

User
  -> org.platform
  -> role.platform-admin
  -> peg.linux.production.login
  -> HBAC rule for sshd on hg.linux.production

The critical point is this: organization is not authorization. Being part of the platform team does not automatically mean someone needs root access on production systems. `peg.*` should therefore be the technical authorization boundary. Applications, HBAC, sudo and Keycloak should consume `peg.*` where possible, not `org.*`.

Host Groups as the Counterpart to Permissions

Host groups are the target side of the model. Instead of building rules per host, systems are grouped by function, risk and operational responsibility. A host can belong to several host groups, such as `hg.linux.production`, `hg.identity`, `hg.monitoring` or `hg.kubernetes.controlplane`.

Host groups should not explode. Groups that are too broad are risky; too many groups make the model unusable. A good start is a small, stable set for production Linux systems, staging, identity, monitoring, bastion, Kubernetes control plane, workers and database systems.

Introduce HBAC Safely

HBAC answers: who may access which host through which service? The target model combines technical permission group, host group and service. For SSH access, the abstract model looks like this:

peg.linux.production.login
  + hg.linux.production
  + sshd
  = allowed host access

The most important operational mistake is disabling global default rules too early. A safe HBAC rollout is additive and tested: inventory hosts, build host groups, define permission groups, create HBAC rules, run `ipa hbactest`, use test hosts, validate Break Glass and the AWX service account and only then reduce default rules.

Model sudo Centrally and Honestly

In larger Linux environments, sudo should not grow indefinitely through local `/etc/sudoers` files. Central sudo rules reduce drift, speed up offboarding and make permissions more auditable. The pattern is similar to HBAC:

peg.linux.production.sudo
  + hg.linux.production
  + sudo command group
  = central sudo rule

Command groups are useful, but they are not a cure-all. Commands such as `vim`, `less`, `bash`, `sh`, `python` or vague `systemctl` rules can enable indirect privilege escalation. For tightly controlled real admin groups, `ALL` can be more honest and easier to govern than a long, flawed whitelist.

Local Accounts and Break Glass

Local human accounts should not grow in parallel to the central IdM world. Normal admins and engineers belong in FreeIPA. Local accounts should remain limited to clearly justified cases: root, Break Glass, bootstrap, recovery and technical accounts that cannot be centralized for operational reasons.

Break Glass is not daily access. A reliable model uses strong random credentials or tightly controlled SSH keys, secure storage in a vault or password manager, logging, regular tests, rotation after use and clear ownership.

Keycloak as Consumer, Not Source of Truth

Keycloak should not replace FreeIPA. It should translate FreeIPA groups into OIDC or SAML claims. FreeIPA remains the source of truth for identity and entitlements. Keycloak handles federation, protocol translation, client scopes and claims. Applications consume only the permissions they actually need.

FreeIPA group
  -> peg.observability.zabbix.admin
  -> Keycloak client-specific mapper
  -> SAML/OIDC claim for Zabbix only
  -> Zabbix role mapping

Not every `peg.*` belongs in every token. Token minimization reduces size, information exposure and governance risk. A Zabbix client does not need Kubernetes, Linux sudo or GitLab groups in its token. Client-specific mappers and scopes are the cleaner architecture.

Validate Deprovisioning Realistically

Disabling a user is not always enough. In a combined FreeIPA and Keycloak environment, teams must know how quickly access actually ends: FreeIPA state, group memberships, Keycloak sync, cache, access tokens, refresh tokens and application sessions all matter.

The guiding question is not only: is the user disabled in the directory? The real question is: can this person still use an existing token or application session anywhere? Only that view makes offboarding auditable.

Ansible, AWX and Desired State

Declarative IdM management is valuable because users, groups, memberships, HBAC, sudo and host groups can be versioned and reviewed. In larger environments, automation still needs to distinguish directory state from node-local state.

• Directory state: users, groups, memberships, HBAC, sudo and host groups. These are global LDAP objects and do not need to be logically written to every replica.

• Node-local state: packages, service configuration, local files, trust stores, OS configuration and host-local certificate files. These changes belong on the relevant nodes.

• Change control: Git review, merge, AWX execution and subsequent verification. For privileged groups, HBAC, sudo, CA and Keycloak roles, a four-eyes process is sensible.

Drift matters as well: what happens if someone changes FreeIPA manually? Does automation overwrite the state, report drift or is there an exception process? Without an answer, a second invisible permission model appears over time.

Monitoring Is More Than Port Checks

Port 389 being open does not mean LDAP is healthy. Port 88 being open does not mean Kerberos tickets work correctly. HTTP 200 does not mean FreeIPA, CA, replication and API are truly healthy. Enterprise monitoring needs several layers.

1. Infrastructure: CPU, RAM, disk, inodes, load, network and time.

2. Process: Directory Server, Kerberos, HTTPD, Dogtag, certmonger and Custodia.

3. Protocol: LDAP, LDAPS, Kerberos and HTTPS.

4. Functional: LDAP search, Kerberos ticket, IPA API read.

5. Replication: topology, lag, conflicts and suffix health.

6. Certificates: Dogtag, LDAP/HTTP, certmonger and Smallstep certificates.

7. End-to-end identity: synthetic test with a minimally privileged monitoring identity.

`ipa-healthcheck` adds another health layer. It does not replace functional tests, but it helps surface FreeIPA-specific error conditions. Monitoring credentials must not be human admin credentials.

Backup, Restore and Runbooks

FreeIPA needs its own backup and restore concept. VM snapshots and replication do not answer the same question. A good model covers `ipa-backup`, full vs. data-only, encryption, off-host storage, retention, site separation, required secrets and regular restore tests.

Runbooks should cover at least replica failure, replica rebuild, site failure, replication failure, Kerberos failure, LDAP failure, CA renewal, certificate expiry, backup, restore, emergency access, Keycloak federation failure and rolling upgrades.

Lifecycle and Rolling Maintenance

Tier-0 identity needs a predictable platform strategy. Short-lived distributions are not automatically wrong, but they mean more frequent upgrades, higher change rate, more rehearsal and more maintenance discipline. When vendor support, lifecycle, security advisories and clear accountability matter, Red Hat IdM on RHEL is the natural enterprise variant. That is an architecture and operations decision, not just a package choice.

1. Check IdM health before maintenance
2. Patch or upgrade one replica
3. Verify LDAP, Kerberos, CA and replication
4. Wait until the cluster is clean
5. Continue with the next replica

Every maintenance starts with health. After each individual replica, validate LDAP, Kerberos, CA, replication and login. Only then move to the next replica.

Why This Separation Helps

The architecture has clear benefits: less coupling, better ownership, cleaner change control, stronger auditability, less drift, faster offboarding and clearer recovery paths. It does not make FreeIPA smaller, but it makes the platform more governable.

The trade-offs are real: more components, more documentation, coordinated DNS and PKI, more monitoring, more runbooks and higher expectations for automation. That is why this model is most useful where Linux identities, multiple sites, SSO, compliance and central operations meet.

Professional Support