FreeIPA and Red Hat Identity Management Guide: Securing Hosts, Keytabs, HBAC and Sudo Rules

FreeIPA, shipped by Red Hat as Identity Management (IdM), is the domain controller for many Linux estates, and a weak deployment hands an attacker every host, keytab and sudo rule at once. It combines a 389 Directory Server LDAP store, an MIT Kerberos KDC, a Dogtag certificate authority, optional BIND DNS and SSSD on clients into one domain, so its failure modes look a lot like Active Directory's. This guide covers how identity and access decisions are made in an IdM domain, which roles and accounts are privileged, how host and service principals behave as non-human identities, what to log and the hardening baseline that matters most. It is written for Linux platform engineers, identity teams and security architects who run or audit FreeIPA or RHEL IdM.

Key takeaways

• Disable allow_all first. Every new domain ships with an enabled HBAC rule that lets all users reach all hosts through all services; until it is disabled, every other HBAC rule is cosmetic.
• Every host and service is a non-human identity. Host principals in /etc/krb5.keytab and service principals such as HTTP/ and ldap/ hold long-lived keys that authenticate without a human, so they need owners, inventory and rotation like any other NHI.
• Keytab retrieval rotates keys. Running ipa-getkeytab without -r generates a new key and silently invalidates every other copy of that keytab, which breaks clusters and also hides who holds old copies.
• Privilege lives in roles, sudo rules and a few special accounts. The admins group, cn=Directory Manager, the default RBAC roles and any sudo rule with command category all are your Tier 0 in a Linux estate.
• Patch the IdM servers like domain controllers. Recent FreeIPA flaws (CVE-2025-4404 and CVE-2025-7493) allowed escalation from an enrolled host to realm administrator, so server patch latency is a direct measure of domain risk.

How identity and access work in FreeIPA and IdM

An IdM domain is a set of replicated servers that share one LDAP tree, one Kerberos realm and, usually, one CA. Clients are enrolled with ipa-client-install, which configures SSSD, Kerberos and PAM, and retrieves the host keytab. From then on the client resolves users, groups, HBAC rules, sudo rules and SELinux user maps from the servers through SSSD, which caches them locally so logins keep working when servers are unreachable. See the SSSD and Linux Active Directory Integration Guide for the client side.

Authentication

The user authentication types an administrator can set are password, radius, otp, pkinit, hardened, idp and passkey. Each successful method stamps an authentication indicator on the Kerberos ticket, and services can require specific indicators, so you can make sudo or SSH to sensitive hosts accept only tickets obtained with OTP or a smart card. Kerberos ticket policy (ipa krbtpolicy-mod) sets maximum ticket life and renewal globally, per user or per indicator.

Authorisation on hosts

• HBAC rules: allow-only rules that combine who (users, user groups), where (hosts, host groups) and which PAM service (sshd, sudo, su-l, login, custom services). SSSD on the client evaluates them during PAM account checks. There are no deny rules: access is denied when nothing matches, which only works once allow_all is disabled.
• Sudo rules: combine users or groups, hosts or host groups, allowed and denied commands or command groups, RunAs users and groups, and sudo options. They are delivered through the SSSD sudo responder (authselect enable-feature with-sudo). Since sudo 1.8.23, PAM account checks run for every rule, including NOPASSWD ones, so the matching HBAC rule must also allow the sudo service. The sudo and sudoers Security Guide covers rule design itself.
• SELinux user maps and ID views: user maps confine IdM users per host (see the SELinux Guide); ID views override UIDs and shells per host group, so write access to an ID view can map one account onto another's files.

Admin roles and privileged access

IdM administration uses a three-layer model: permissions (an LDAP ACI on a target and attribute set), privileges (named bundles of permissions) and roles (bundles of privileges assigned to users, groups, hosts, host groups or services). The default roles are broad.

• Build custom roles: create privileges from the specific permissions a team needs (for example, password reset without group changes) rather than reusing a broad default role. Review selfservice and delegation rules too, since they also grant attribute write rights.
• Treat AD trusts as privilege paths: ipa trust-add creates a forest trust, and external AD groups can be nested into IdM groups used in HBAC and sudo rules. An AD Domain Admin can therefore become root on Linux through group nesting. The Federation and Trust Relationships Guide covers the governance side.
• Break-glass: vault admin and Directory Manager credentials and record IdM server sessions. See the Unix and Linux Privileged Access Guide.

Integrations, API tokens and service accounts

Most of the non-human identity risk in an IdM domain sits in three object types: hosts, Kerberos services and LDAP system accounts.

Host principals and enrolment

• Enrolment one-time passwords: a host can be pre-created with a random one-time password (ipa host-add --random) and enrolled by binding as the host with that password. Treat the OTP as a secret: it should be short lived, delivered to the provisioning system only, and never baked into images.
• Host keytab: enrolment stores the host principal key in /etc/krb5.keytab. Root on the client can act as the host, and a cloned image with an enrolled keytab gives many machines one identity. Unenrol (ipa-client-install --uninstall) and delete host objects when machines are retired.

Service principals and keytabs

• Retrieval resets the key: the ipa-getkeytab man page warns that retrieving a keytab resets the secret for the principal and renders all other keytabs for it invalid. Use -r to retrieve the existing key for load-balanced or high-availability services.
• Who may create and retrieve: keytab creation and retrieval are separate rights, granted with ipa service-allow-create-keytab, ipa service-allow-retrieve-keytab and the host equivalents. Grant them to a provisioning host or group, not to individual admins, and review them like any other entitlement.
• Constrained delegation: service delegation rules and targets (ipa servicedelegationrule-*) let a front-end service obtain tickets to a back-end on behalf of users. CVE-2024-2698 showed that a delegation logic error let a proxy service impersonate any user to other targets, so keep delegation rules narrow and patched. See the Kerberos Delegation Security Guide.
• Keytab handling on clients: store keytabs with root or service-user ownership and mode 0600, keep them out of configuration management repositories and container images, and rotate on staff changes and host compromise. The Linux Service Accounts and Keytab Management Guide covers the full lifecycle.

LDAP system accounts and certificates

• System accounts: applications that only need to read LDAP use system accounts in cn=sysaccounts,cn=etc, which have no POSIX attributes and cannot log in to hosts. Current FreeIPA releases manage them with ipa sysaccount-add and a --privileged flag that lets an account change user passwords without forcing a reset; that flag plus the 'System: Change User password' permission makes the account a password-reset service, so treat it as privileged.
• Prefer Kerberos over bind passwords: where the application supports GSSAPI, give it a service principal and keytab instead of a simple-bind password, so there is no static password to leak from a config file.
• CA ACLs: the default CA ACL hosts_services_caIPAserviceCert lets all hosts and services request certificates from the caIPAserviceCert profile. If you add profiles for user or client authentication certificates, scope a new ACL tightly, because certificate issuance is an authentication path. The Machine Identity, PKI and Certificate Lifecycle Guide covers renewal and inventory; certmonger tracks IdM-issued certificates on each host.

Logging and detection

ipa commands run as root on a server can act directly against LDAP, so collect both the API audit and the Directory Server logs. For Linux-side collection see the Linux Logging and auditd for Defenders Guide; for roasting detection see the Kerberoasting and AS-REP Roasting Defence Guide.

Note on last logon: FreeIPA does not update krbLastSuccessfulAuth by default, for replication reliability, so you cannot find stale accounts from directory data alone. Use KDC and SSSD logs to compute last use for users, hosts and services.

Metrics that show it is working

• allow_all status and HBAC coverage: allow_all disabled in every domain, and the share of hosts covered by at least one specific HBAC rule (target 100%).
• Privileged membership: number of members in admins and in each role, reviewed monthly, with zero unexplained additions.
• Broad sudo rules: count of sudo rules with command category all or host category all, trending down.
• Stale principals: host and service principals with no KDC activity in 90 days, and the time to delete them.
• Strong authentication for admins: percentage of privileged users whose authentication type is otp, pkinit, hardened or passkey.
• Patch latency: days from a FreeIPA or IdM security advisory to all servers patched.

Hardening baseline

1. Inventory first: export hosts, services, keytab permissions, roles and their members, HBAC and sudo rules, CA ACLs and trusts (ipa host-find, ipa service-find, ipa role-find, ipa hbacrule-find, ipa sudorule-find, ipa caacl-find, ipa trust-find).
2. Build specific HBAC rules before you switch off allow_all: create rules per host group and service (for example, linux-admins to all servers via sshd, sudo and su-l; application teams to their host groups via sshd), then simulate with ipa hbactest for representative users, hosts and services.
3. Disable, do not delete, allow_all: ipa hbacrule-disable allow_all gives you a one-command rollback (ipa hbacrule-enable allow_all) if a critical login path was missed. Roll out in a maintenance window, starting with a pilot host group, and keep the allow_systemd-user rule that pam_systemd needs.
4. Tighten sudo: replace command category all with command groups, set explicit RunAs users, avoid NOPASSWD except for automation that cannot prompt, and require authentication indicators for sudo on sensitive hosts.
5. Harden admin authentication: set privileged users to otp, pkinit or passkey, shorten their ticket lifetime with a per-user or per-indicator ticket policy, and apply a stricter password policy group (ipa pwpolicy-add) for admins and service users that still have passwords.
6. Protect the servers: restrict network access to the IdM ports (LDAP 389 and 636, Kerberos 88 and 464, HTTPS 443, DNS 53 if used) to client networks, disable anonymous LDAP reads where your clients allow it, apply your RHEL baseline (see the Red Hat Enterprise Linux Security Hardening Guide), and patch every replica on the same cycle.
7. Protect backups: ipa-backup output contains the directory, Kerberos keys and CA material. Encrypt it with --gpg, store it offline from the servers and restrict who can restore it.
8. Clean up principals: remove host and service objects for retired systems, review keytab create and retrieve permissions quarterly, and rotate keytabs for services whose administrators have left.

Decision guidance

Common misconfigurations

• allow_all left enabled: careful HBAC rules are written and tested but have no effect because the default rule still grants everything.
• Sudo rules with all categories: a rule with host category all, command category all and RunAs all for a large group is domain-wide root. Pair it with the AD trust nesting above and an AD compromise becomes Linux root.
• Keytabs copied around: keytabs exported for a cluster without -r break other nodes, so engineers copy one file everywhere and into Git. The keytab then outlives the system and nobody knows who holds it.
• Unpatched servers: CVE-2025-4404 and CVE-2025-7493 let a user who could create services, or who controlled a host, take a realm administrator identity because FreeIPA did not validate the uniqueness of krbCanonicalName. CVE-2024-3183 let a user obtain material for offline password guessing of other principals. All were fixed in updates; unpatched servers turn a minor foothold into domain compromise.
• Admin used as an automation account: provisioning scripts run as admin with a password in a variable file, giving every pipeline compromise full domain control.

Framework mapping

In CIS Controls v8.1 the work sits mainly in Control 5 (Account Management) and Control 6 (Access Control Management); in ISO/IEC 27001:2022 Annex A it maps to A.5.15 access control, A.5.18 access rights and A.8.2 privileged access rights.

Practitioner checklist

• Confirm allow_all is disabled in every IdM domain and that ipa hbactest results match intended access for a sample of users and hosts.
• List members of admins and every role; remove anyone without a current need and require OTP, smart card or passkey for those who remain.
• Vault the Directory Manager password and alert on any bind that uses it.
• Find sudo rules with command category all or host category all and replace them with command groups and host groups.
• Review who holds keytab create and retrieve permissions for every service, and use -r for shared keys.
• Delete host and service principals with no KDC activity in 90 days after confirming with owners.
• Give automation a dedicated identity with a custom role and a keytab held in a secrets manager.
• Review AD trust group nesting into IdM groups used by HBAC and sudo rules.
• Forward IPA API, Directory Server, KDC and client PAM logs to the SIEM and test one detection for each.
• Patch all replicas within your critical patch window and encrypt ipa-backup output.

Standards and references

• FreeIPA: About FreeIPA
• FreeIPA Documentation: Workshop Unit 4, Host-based access control (HBAC)
• FreeIPA Documentation: Workshop Unit 8, Sudo rule management
• FreeIPA: ipa-getkeytab manual page
• Red Hat: Configuring host-based access control rules (RHEL 9)
• CVE Program: CVE-2025-4404 FreeIPA privilege escalation from host to domain admin
• CVE Program: CVE-2024-3183 FreeIPA offline brute force of user password hashes
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Kerberos Security Guide · Linux Service Accounts and Keytab Management Guide · Linux PAM Guide · Service Account Security Guide