Security / System Administration / Services & Applications

Configure Linux authentication with FreeIPA, HBAC, sudo, and bounded offline access

Enroll a production Linux host into FreeIPA 4.12.4 through verified DNS, time, and TLS trust; replace permissive access with tested HBAC and exact sudo rules; bound SSSD offline credentials; and operate break-glass, deprovisioning, failover, LDAP exceptions, and rollback safely.

150 min18 stepsHigh-impact changeRevision 1

Save or explore

#freeipa #idm #sssd #kerberos #ldap #hbac #sudo #authentication #dns #security #break-glass #deprovision

0 of 18 steps completed

Goal

Provide centralized Linux identity and least-privilege host authorization that remains recoverable during IdM outages without exposing reusable enrollment or LDAP secrets.

Supported environments

FreeIPA 4.12.4
Linux client RHEL-compatible 9/10 with distribution-supported ipa-client and SSSD

Prerequisites

Healthy replicated FreeIPA realm At least two supported, patched replicas, monitored replication, protected backups, and tested server recovery already exist.
Authoritative DNS and synchronized time Stable client FQDN/forward/reverse records, LDAP/Kerberos SRV discovery, and chrony health are verified from each client site.
Access-policy matrix User groups, host groups, PAM services, exact sudo commands, allowed/denied tests, deprovision SLA, and offline window are approved.
Independent recovery A vaulted, monitored local/console break-glass path works before enrollment, HBAC cutover, SSSD changes, or unenrollment.

Operating boundary

OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.

Full guide

What you will build

System

A production Linux client enrolled in an existing FreeIPA 4.12.4 realm through verified DNS, synchronized time, independently checked CA trust, a unique host keytab, and SSSD's native IPA provider.
An explicit access model in which group/host/service-scoped HBAC replaces `allow_all`, exact-command sudo grants only the intended operation, and positive plus negative tests prove the effective boundary.
An operational lifecycle with bounded offline credentials, replica failover evidence, monitored break-glass access, user/host deprovisioning, supported uninstall rollback, and a narrowly documented LDAP-only application exception.

Observable outcome

A production Linux client resolves identities and obtains Kerberos service tickets through SSSD's native IPA provider, discovers multiple replicas, and validates the IdM CA rather than accepting unknown trust.
Explicit HBAC rules allow the intended group/host/service tuple and deny a neighboring test identity after `allow_all` is disabled under an independently recoverable cutover.
Exact-command sudo policy is proven with an allowed operation and denied adjacent service/shell probes, without passwordless or wildcard privilege.
Offline login is intentionally bounded, its revocation lag is documented, replica failover is exercised, and break-glass access remains independent and monitored.
User and host deprovisioning preserves evidence while disabling keys/access, and supported client uninstall restores a verified pre-enrollment path.

Architecture

How the parts fit together

A FreeIPA client uses DNS SRV records to discover redundant IPA services, validates the realm CA, authenticates through Kerberos, resolves identities and policy through SSSD's IPA provider, and enforces access locally through NSS/PAM, HBAC, and sudo. Central policy remains authoritative while online; a deliberately finite cache trades immediate revocation for short outage survivability.

FreeIPA replicasServe replicated identity, Kerberos, LDAP, CA, HBAC, sudo, host/service principal, and discovery data. Production design needs multiple healthy replicas and monitored replication outside this client guide.

Authoritative DNS and timePublish stable host forward/reverse records and LDAP/Kerberos SRV discovery while chrony keeps client and KDC clocks within a tight operational tolerance.

Verified CA and Kerberos trustBind TLS endpoints and realm identities to an independently approved trust anchor; enrollment creates a host principal and protected keytab.

SSSD IPA providerIntegrate identity, authentication, access, sudo, discovery, cache, SSH host keys, and failover without applications handling blanket LDAP passwords.

HBAC and sudo policySeparate identity/authentication from host-service access and from privileged command authorization through explicit user groups, host groups, services, and commands.

Independent recovery pathProvide monitored console or management-plane access through a vaulted local identity when central DNS, time, Kerberos, LDAP, SSSD, or authorization is unavailable.

The client resolves its permanent FQDN and discovers multiple `_ldap` and `_kerberos` endpoints from authoritative DNS while synchronized time protects Kerberos ticket validity.
An operator verifies the FreeIPA CA fingerprint out of band and validates the selected server's TLS chain and hostname before enrollment.
Interactive enrollment installs CA/Kerberos/SSSD/PAM/NSS configuration and generates a unique host keytab without putting a reusable password on the process command line.
Online login resolves the user through SSSD, obtains/verifies Kerberos credentials, then evaluates an explicit HBAC tuple for the target host and PAM service.
A separate sudo lookup evaluates exact commands for the approved user/host groups; successful login does not imply privileged access.
During a bounded outage, only previously cached users may authenticate within the configured period; central disablement becomes effective after reconnect/cache refresh or local incident action.
Deprovision disables users/hosts and related credentials before deletion, preserving audit context and addressing cached, issued, and external credentials separately.

Assumptions

The realm already has at least two healthy, patched FreeIPA replicas per required failure domain, monitored replication, protected backups, and a tested server recovery procedure.
The reviewed upstream baseline is FreeIPA 4.12.4 as of 2026-07-28; the deployment uses a distribution-supported build with current security errata.
Client DNS uses authoritative FreeIPA-integrated or correctly delegated zones with stable A/AAAA, PTR, LDAP SRV, and Kerberos SRV records visible from the real client network.
Chrony or an equivalent supported service keeps every client and KDC synchronized to approved sources, with alerting well before Kerberos's maximum skew.
The client has a stable non-recycled FQDN and asset identity; cloned images do not contain another host's `/etc/krb5.keytab`, SSSD database, or machine certificate.
An independently tested console or management-plane break-glass path exists and its credential is vaulted, monitored, rotated, and unavailable for routine use.
Operators can create controlled positive and negative test identities/groups without using production user passwords in automation.
The organization accepts the documented finite offline-authentication window or disables credential caching on higher-assurance continuously connected hosts.

Key concepts

Authentication versus authorization: Kerberos proves an identity and SSSD resolves it; HBAC decides whether that identity may use a PAM service on a host, while sudo separately decides which privileged command may run.
Host principal and keytab: Enrollment creates a unique Kerberos identity such as `host/app01.example.net@EXAMPLE.NET` and stores long-term secret keys in `/etc/krb5.keytab`. A copied keytab is equivalent to a cloned machine identity.
HBAC: Host-Based Access Control evaluates user/group, host/host-group, and service/service-group dimensions. `allow_all` is a permissive default that must be replaced only after explicit rules and recovery are proven.
SSSD online and offline state: While online, SSSD consumes authoritative identity and policy. While offline, it may use cached credential verifiers and cached authorization data, creating bounded availability and unavoidable revocation lag.
Service discovery: DNS SRV records allow clients to choose and fail over among IPA, LDAP, and Kerberos endpoints. Hard-coded single-server configurations weaken resilience and can conceal topology errors.
LDAP-only exception: An LDAPS/StartTLS application bind can perform limited directory lookup/authentication but does not supply native host enrollment, Kerberos SSO, HBAC, sudo, keytab, certificate, or offline-policy integration.

Before you copy

Values used in this guide

{{ipaDomain}}

Lowercase DNS domain served by the FreeIPA realm.

Example: example.net

{{ipaRealm}}

Uppercase Kerberos realm associated with the deployment.

Example: EXAMPLE.NET

{{ipaServer}}

Verified bootstrap FreeIPA replica FQDN; SSSD later uses DNS discovery.

Example: ipa01.example.net

{{ipaCaCertificate}}

Integrity-protected public FreeIPA CA certificate with an out-of-band verified fingerprint.

Example: /root/bootstrap/ipa-ca.crt

{{clientFqdn}}

Permanent canonical FQDN of the Linux client.

Example: app01.example.net

{{clientAddress}}

Stable client address used to verify reverse DNS.

Example: 10.20.30.41

{{allowedUser}}

Controlled positive-test identity that belongs to the approved operator group.

Example: alice

{{deniedUser}}

Controlled negative-test identity intentionally excluded from the target HBAC rule.

Example: contractor-denied

{{testUser}}

Controlled deployer used to prove exact sudo allow and deny behavior.

Example: deployer

{{breakGlassUser}}secret

Local console/management recovery account whose credential remains in the emergency vault.

Example: local-recovery

{{breakGlassAdminGroup}}

Local group that holds only the constrained emergency recovery authorization.

Example: local-recovery

{{operatorGroup}}

FreeIPA user group allowed to reach production hosts over SSH.

Example: linux-ops

{{productionHostGroup}}

FreeIPA host group containing the intended production Linux clients.

Example: production-linux

{{adminHbacRule}}

Explicit HBAC rule replacing permissive allow_all access.

Example: prod-ops-ssh

{{sudoRule}}

FreeIPA sudo rule for one approved operational task.

Example: app-restart

{{deployerGroup}}

FreeIPA group containing identities allowed to perform the one delegated application action.

Example: app-deployers

{{applicationHostGroup}}

FreeIPA host group containing only systems that expose the delegated application operation.

Example: application-hosts

{{serviceUnit}}

Exact systemd unit delegated to the controlled deployer.

Example: example.service

{{preEnrollmentBackup}}secret

Root-readable archive of the scoped authentication configuration before enrollment.

Example: /var/backups/auth-before-freeipa-20260728.tgz

{{cachedUser}}

Controlled user that completed one approved online login before the offline-auth rehearsal.

Example: offline-test-cached

{{uncachedUser}}

Controlled user that has never authenticated on the canary and therefore must fail offline.

Example: offline-test-new

{{departingUser}}

Controlled or real offboarding identity processed through the reviewed disablement workflow.

Example: departing.user

{{applicationBindDn}}secret

Unique least-privilege LDAP-only service DN; its password is never stored in this value.

Example: uid=svc-inventory,cn=sysaccounts,cn=etc,dc=example,dc=net

Security and production boundaries

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.
A FreeIPA administrator, enrollment operator, host keytab, application bind identity, and local break-glass account are different trust classes. Do not collapse them into one reusable credential.
Use exact HBAC and sudo rules. Membership in a directory or successful Kerberos authentication is not permission to open a shell or run privileged commands.
Cached offline access is a conscious availability compromise. Encrypt disks, bound the lifetime, monitor prolonged offline state, and have a local response for stolen or disconnected systems.
Do not disable `allow_all`, unenroll a host, or change SSSD access settings without an open protected session plus tested independent recovery.

Stop before continuing if

Stop when DNS, time, hostname, certificate fingerprint, realm, issuer, serial database, or access-policy evidence differs from the approved inventory.
Stop before disabling a permissive rule, rotating a CA, revoking a certificate, or unenrolling a host unless break-glass access has just been tested through an independent path.
Stop when a command would expose a secret in argv, overwrite CA state, run two `openssl ca` writers concurrently, or grant an all-users/all-hosts authorization shortcut.
Stop after any unexplained certificate issuance, authentication bypass, policy mismatch, lost private key, CA database divergence, or inability to restore the identity service from protected artifacts.
Stop when forward/reverse DNS, SRV discovery, FQDN, realm, CA fingerprint, TLS hostname, or synchronized time fails validation.
Stop when a positive/negative HBAC or sudo test does not produce opposite expected outcomes, or when any wildcard/ALL/passwordless privilege appears.
Stop when offline authentication has no finite expiration, stakeholders expect instant offline revocation, or a client remains offline for unexplained periods.
Stop deprovisioning when host/service principals, certificates, DNS, snapshots, keytabs, or dependent resource ownership have not been inventoried.

decision

Define the identity boundary and supported FreeIPA baseline

read-only

Document the IdM realm, DNS domain, replica sites, client classes, identity owners, supported operating systems, login services, sudo scope, offline-auth policy, deprovision SLA, and recovery authority before enrolling a host.

Why this step matters

Central identity changes the failure and compromise radius of every enrolled host. A versioned service boundary and explicit authorization model prevent enrollment from silently becoming blanket access.

What to understand

FreeIPA 4.12.4 is the reviewed upstream baseline as of 2026-07-28; it includes the fix for CVE-2025-4404. Use the distribution-supported build and re-check errata before rollout.

This tutorial assumes an existing healthy multi-replica FreeIPA realm. It does not install the FreeIPA servers, migrate an Active Directory forest, or design cross-forest trust.

FreeIPA's SSSD IPA provider integrates identity, Kerberos, host keys, HBAC, sudo, certificates, and discovery. LDAP-only integration is a limited application compatibility path, not an equivalent host-login architecture.

System changes

Creates an approved identity, access, offline-operation, deprovision, and recovery design; no client configuration changes yet.

Syntax explained

FreeIPA 4.12.4: Current reviewed upstream security-fix baseline; verify the distribution package revision before use.
SSSD IPA provider: Native client path for Kerberos, HBAC, sudo, service discovery, and managed identity.
LDAP-only: Restricted fallback for applications that cannot use Kerberos/SSSD; it lacks the full host policy lifecycle.

Example output / evidence

Identity profile approved: FreeIPA 4.12.4; realm=EXAMPLE.NET; domain=example.net; Linux clients=RHEL-compatible 9/10; SSH via HBAC; sudo=exact commands; offline credentials=3 days; two replicas per site.

Checkpoint: Checkpoint: Define the identity boundary and supported FreeIPA baseline

Continue whenIdentity, platform, security, network, and recovery owners approve realm scope, policy owners, replica capacity, and bounded offline behavior.

Stop whenThe environment has one IdM server, no independent local recovery, unmanaged DNS/time, or expects LDAP bind passwords to replace host enrollment.

If this step fails

The client stays offline even though one IdM server is reachable.

Likely causeDNS SRV records are stale, firewalls block required services, site discovery is wrong, all discovered servers failed backoff, or CA/Kerberos trust differs across replicas.

Safe checks

dig +short _ldap._tcp.{{ipaDomain}} SRV
sssctl domain-status {{ipaDomain}}
nc -vz {{ipaServer}} 443
nc -vz {{ipaServer}} 389
kvno host/{{ipaServer}}

ResolutionRepair the discovery, network, replica, or trust inconsistency. Use supported SSSD failover rather than pinning a permanent single-server workaround.

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Use a managed identity service, Active Directory trust, or another distribution-supported identity provider when FreeIPA's platform and operational assumptions do not fit.

Stop conditions

Stop when the observed identity, trust, version, state, or output differs from the approved plan.
Stop when independent recovery access, a current state backup, or a named rollback owner is unavailable.

verification

Prove DNS discovery, stable host identity, and synchronized time

read-only

From the actual client subnet, verify its permanent FQDN, forward and reverse records, IdM LDAP and Kerberos SRV discovery, resolver ownership, and small chrony offset before contacting enrollment services.

Why this step matters

Kerberos binds identities to canonical names and time-limited tickets. Broken DNS or clock synchronization produces misleading authentication failures and can direct enrollment toward an unintended server.

What to understand

Use proper delegated DNS with service discovery rather than permanently pinning `/etc/hosts`; host-file exceptions hide replica failover and reverse-DNS defects.

Forward and reverse equality is an operational invariant for this host even where a specific protocol does not strictly require PTR.

Kerberos normally tolerates minutes of skew, but production monitoring should keep offset far smaller so failures are detected before authentication breaks.

System changes

Read-only validation of client hostname, resolver answers, IdM discovery, and time synchronization.

Syntax explained

_ldap._tcp SRV: Discovers LDAP/IPA service endpoints and priorities from DNS.
_kerberos._udp SRV: Discovers Kerberos KDC endpoints for the realm.
chronyc tracking: Shows synchronization state and current system-time offset.

Command

Fill variables0/3 ready

Values stay on this page and are never sent or saved.

Client Fqdn{{clientFqdn}}Permanent canonical FQDN of the Linux client.Client Address{{clientAddress}}Stable client address used to verify reverse DNS.Ipa Domain{{ipaDomain}}Lowercase DNS domain served by the FreeIPA realm.

hostnamectl --static; hostname -f; getent ahosts {{clientFqdn}}; dig +short -x {{clientAddress}}; dig +short _ldap._tcp.{{ipaDomain}} SRV; dig +short _kerberos._udp.{{ipaDomain}} SRV; chronyc tracking; chronyc sources -v

Example output / evidence

app01.example.net
app01.example.net
10.20.30.41 STREAM app01.example.net
app01.example.net.
0 100 389 ipa01.example.net.
0 100 389 ipa02.example.net.
0 100 88 ipa01.example.net.
0 100 88 ipa02.example.net.
Leap status     : Normal
System time     : 0.000184223 seconds slow of NTP time

Checkpoint: Checkpoint: Prove DNS discovery, stable host identity, and synchronized time

Continue whenStable FQDN, matching A/AAAA and PTR, at least two expected replicas in SRV answers, and synchronized time with a small offset.

Stop whenAny answer points outside the approved realm/site, names disagree, a single unexpected resolver owns discovery, or the clock is unsynchronized.

If this step fails

The client cannot discover an IdM server or Kerberos realm.

Likely causeThe host uses the wrong DNS resolver, the IdM DNS SRV records are absent, split-horizon DNS returns an unintended view, or the hostname has no stable forward and reverse mapping.

Safe checks

resolvectl status
dig +short _ldap._tcp.{{ipaDomain}} SRV
dig +short _kerberos._udp.{{ipaDomain}} SRV
getent ahosts {{clientFqdn}}
dig +short -x {{clientAddress}}

ResolutionCorrect the authoritative DNS delegation or resolver path and prove forward, reverse, LDAP, and Kerberos discovery from the client network before retrying enrollment.

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Rehearse the exact step in an isolated environment with production-shaped identities, names, and trust paths before production.

Stop conditions

Stop when the observed identity, trust, version, state, or output differs from the approved plan.
Stop when independent recovery access, a current state backup, or a named rollback owner is unavailable.

verification

Bootstrap and verify the IdM TLS trust anchor

read-only

Obtain the FreeIPA CA certificate through the approved bootstrap channel, verify its fingerprint with a second administrator channel, and validate the selected server certificate and hostname before enrollment.

Why this step matters

Enrollment installs a durable trust relationship and host key material. Validating only whatever certificate the network presents would make the bootstrap vulnerable to DNS, proxy, or routing compromise.

What to understand

Compare the SHA-256 CA fingerprint using an authenticated channel independent of the client network, such as a signed build manifest or two-person change record.

Validate both chain and hostname with SNI. A self-consistent but unauthorized CA is not acceptable.

Keep the bootstrap CA public but integrity-protected. It is not a secret and must never be confused with a CA private key.

System changes

Reads the staged CA certificate and the server's TLS handshake; does not yet modify the system trust store.

Syntax explained

-servername: Sends TLS SNI so the endpoint returns the certificate for the intended host.
-verify_return_error: Stops on certificate validation error instead of continuing for diagnostic output.
-fingerprint -sha256: Produces a strong digest that can be compared through an independent channel.

Command

Fill variables0/2 ready

Values stay on this page and are never sent or saved.

Ipa Ca Certificate{{ipaCaCertificate}}Integrity-protected public FreeIPA CA certificate with an out-of-band verified fingerprint.Ipa Server{{ipaServer}}Verified bootstrap FreeIPA replica FQDN; SSSD later uses DNS discovery.

openssl x509 -in {{ipaCaCertificate}} -noout -subject -issuer -dates -fingerprint -sha256; openssl s_client -connect {{ipaServer}}:443 -servername {{ipaServer}} -CAfile {{ipaCaCertificate}} -verify_return_error </dev/null 2>&1 | tail -n 8

Example output / evidence

subject=O=EXAMPLE.NET,CN=Certificate Authority
issuer=O=EXAMPLE.NET,CN=Certificate Authority
notBefore=Jul 14 08:00:00 2026 GMT
notAfter=Jul 14 08:00:00 2046 GMT
sha256 Fingerprint=9A:1C:62:7F:0B:72:42:48:77:AB:31:6E:0D:AE:CB:10:9F:44:1D:52:AD:87:31:25:C8:15:DD:72:B6:49:7E:91
Verification: OK
Verify return code: 0 (ok)

Checkpoint: Checkpoint: Bootstrap and verify the IdM TLS trust anchor

Continue whenThe independently approved CA fingerprint matches and the HTTPS endpoint verifies with the expected FQDN and chain.

Stop whenThe operator is asked to accept an unknown CA, the fingerprint differs, hostname verification fails, or a proxy substitutes another issuer.

If this step fails

Enrollment reports an untrusted certificate or connects to an unexpected server.

Likely causeThe CA certificate was obtained from an unverified location, DNS was poisoned or misconfigured, a proxy intercepted TLS, or the enrollment host is not part of the approved IdM deployment.

Safe checks

openssl x509 -in {{ipaCaCertificate}} -noout -subject -issuer -fingerprint -sha256
openssl s_client -connect {{ipaServer}}:443 -servername {{ipaServer}} -CAfile {{ipaCaCertificate}} </dev/null
Compare the CA fingerprint through an independent administrator channel.

ResolutionDo not accept the certificate interactively. Obtain the IdM CA through the controlled bootstrap channel, verify its SHA-256 fingerprint, and correct DNS or proxy routing.

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Rehearse the exact step in an isolated environment with production-shaped identities, names, and trust paths before production.

Stop conditions

Stop when the observed identity, trust, version, state, or output differs from the approved plan.
Stop when independent recovery access, a current state backup, or a named rollback owner is unavailable.

instruction

Model users, host groups, HBAC, sudo, and break-glass before enrollment

read-only

Create a reviewed matrix that maps business roles to user groups, client classes to host groups, interactive services to HBAC rules, and privileged tasks to exact sudo commands. Name positive and negative test identities for every path.

Why this step matters

FreeIPA enrollment makes central policy available but does not create least privilege automatically. A testable matrix prevents broad `allow_all` or sudo `ALL` rules from becoming the permanent design.

What to understand

Use groups and host groups as stable policy subjects; avoid rules tied to an ever-growing list of individual identities.

Separate authentication from authorization: resolving a user and obtaining a Kerberos ticket must not imply SSH or sudo permission.

Treat executable paths that can invoke shells, load arbitrary plugins, edit arbitrary files, or honor dangerous environment variables as equivalent to broad root access.

System changes

Creates policy records and test cases in change control; no IdM object is modified by this instructional step.

Syntax explained

HBAC: Controls which user/group may access which host/host-group through which PAM service.
sudo rule: Controls explicit privileged commands, hosts, users, run-as identity, and options.
break-glass: Independent local recovery identity used only through controlled console access.

Example output / evidence

Role matrix: linux-ops -> production-linux -> sshd through prod-ops-ssh; deployers -> app01/app02 -> /usr/bin/systemctl restart example.service through app-restart; contractor-denied is negative test; local-recovery is console-only.

Checkpoint: Checkpoint: Model users, host groups, HBAC, sudo, and break-glass before enrollment

Continue whenEvery intended login and privileged action has a matching allowed test and a neighboring denied test, with a named owner and expiry/review date.

Stop whenThe model relies on `allow_all`, sudo `ALL`, a shared administrator account, or a break-glass path that has not been independently exercised.

If this step fails

A user receives an interactive shell even though the intended HBAC rule should deny it.

Likely causeThe default `allow_all` HBAC rule is still enabled, a broad overlapping rule applies, the host/service group is wrong, or cached policy has not refreshed.

Safe checks

ipa hbactest --user={{deniedUser}} --host={{clientFqdn}} --service=sshd
ipa hbacrule-find --enabled=TRUE --all
sssctl user-checks {{deniedUser}} -a acct -s sshd

ResolutionKeep independent console access, find the exact allowing rule, narrow membership or service scope, refresh SSSD, and retest both an allowed and denied identity before declaring enforcement.

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Rehearse the exact step in an isolated environment with production-shaped identities, names, and trust paths before production.

Stop conditions

Stop when the observed identity, trust, version, state, or output differs from the approved plan.
Stop when independent recovery access, a current state backup, or a named rollback owner is unavailable.

command

Create and test an independent local break-glass path

caution

Provision the approved local recovery account through configuration management, store its randomly generated credential in the emergency vault, restrict it to console/management access, and test it before central enrollment.

Why this step matters

A central identity outage can remove the same credentials needed to repair it. A vaulted, monitored, narrowly reachable local account provides recovery without leaving a routine shared root password.

What to understand

Generate and rotate the credential outside shell arguments. Do not show the password, hash, or vault retrieval token in this tutorial.

Prefer console or a separate management plane. If SSH break-glass is unavoidable, use a separately protected hardware-backed key, source restrictions, alerting, and time-bounded enablement.

Record every retrieval and login; rotate the credential after any use and test it on a schedule without weakening HBAC.

System changes

Validates an already provisioned local recovery account and its constrained privilege; provisioning itself belongs to the approved configuration-management workflow.

Syntax explained

passwd -S: Shows whether the local password is usable or locked without exposing the password hash.
sudo -l -U: Lists effective local sudo authorization for the recovery identity.

Command

Fill variables0/2 ready

Values stay on this page and are never sent or saved.

Break Glass User{{breakGlassUser}}Local console/management recovery account whose credential remains in the emergency vault.Break Glass Admin Group{{breakGlassAdminGroup}}Local group that holds only the constrained emergency recovery authorization.

getent passwd {{breakGlassUser}}; passwd -S {{breakGlassUser}}; sudo -l -U {{breakGlassUser}}; getent group {{breakGlassAdminGroup}}; journalctl --since '-5 min' _UID="$(id -u {{breakGlassUser}})" --no-pager

Example output / evidence

local-recovery:x:991:991:Emergency local access:/var/lib/local-recovery:/bin/bash
local-recovery P 2026-07-28 0 99999 7 -1
User local-recovery may run the following commands on app01:
    (root) /usr/bin/systemctl status *, /usr/bin/journalctl *
local-recovery:x:991:

Checkpoint: Checkpoint: Create and test an independent local break-glass path

Continue whenThe account works through the independent path, cannot be used from ordinary untrusted networks, is monitored, and has only the recovery privileges documented.

Stop whenThe account is missing, uses a shared/static exposed password, grants unrestricted remote access, or has never been successfully exercised.

If this step fails

Unenrollment removes central login before local recovery is available.

Likely causeThe operator ran `ipa-client-install --uninstall` over the only privileged remote session or never validated a local console/break-glass account.

Safe checks

Keep the current privileged session open.
getent passwd {{breakGlassUser}}
sudo -l -U {{breakGlassUser}}
systemctl is-enabled sshd

ResolutionUse console recovery, restore the saved pre-enrollment configuration or re-enroll through a fresh one-time credential, and add an independent access gate to future change procedures.

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Use a cloud serial console, hypervisor console, out-of-band BMC, or immutable recovery image when a persistent local account is prohibited.

Stop conditions

Stop when the observed identity, trust, version, state, or output differs from the approved plan.
Stop when independent recovery access, a current state backup, or a named rollback owner is unavailable.

command

Enroll the host with interactive, auditable credentials

caution

Install the distribution-supported FreeIPA client, preserve the pre-enrollment configuration, then run interactive enrollment against the verified realm. Use an administrator or one-time enrollment credential only at the prompt, never in argv.

Why this step matters

Explicitly pinning already verified bootstrap values makes the change auditable while interactive secret entry avoids process-list and shell-history disclosure. The backup provides a bounded uninstall recovery path.

What to understand

Prefer a short-lived one-time host enrollment credential or restricted enrollment role rather than the FreeIPA `admin` account.

`--mkhomedir` enables home creation at first login; verify local storage ownership, quotas, encryption, and cleanup policy.

`--enable-dns-updates` is appropriate only when the host is authorized to maintain its record and DNS update policy is understood.

System changes

Backs up pre-enrollment authentication files.
Installs CA trust, Kerberos configuration, SSSD IPA domain, PAM/NSS integration, host principal/keytab, SSH integration, and optional DNS update behavior.

Syntax explained

dnf install ipa-client sssd-tools: Installs the distribution-supported enrollment client and SSSD diagnostic commands before preserving configuration.
--domain: Sets the DNS domain used for identity discovery.
--realm: Sets the uppercase Kerberos realm.
--server: Pins the verified bootstrap server while SSSD can later use discovered replicas.
--ca-cert-file: Uses the independently verified IdM CA instead of accepting an unknown certificate.
--mkhomedir: Configures automatic home-directory creation on first login.
--enable-dns-updates: Lets the enrolled host update its own DNS record when policy permits.

Command

Fill variables0/6 ready

Values stay on this page and are never sent or saved.

Pre Enrollment Backup{{preEnrollmentBackup}}Root-readable archive of the scoped authentication configuration before enrollment.Ipa Domain{{ipaDomain}}Lowercase DNS domain served by the FreeIPA realm.Ipa Realm{{ipaRealm}}Uppercase Kerberos realm associated with the deployment.Ipa Server{{ipaServer}}Verified bootstrap FreeIPA replica FQDN; SSSD later uses DNS discovery.Client Fqdn{{clientFqdn}}Permanent canonical FQDN of the Linux client.Ipa Ca Certificate{{ipaCaCertificate}}Integrity-protected public FreeIPA CA certificate with an out-of-band verified fingerprint.

sudo dnf install -y ipa-client sssd-tools && ipa --version && sudo install -o root -g root -m 0600 /dev/null {{preEnrollmentBackup}} && sudo tar --xattrs --acls -C / -czf {{preEnrollmentBackup}} etc/sssd etc/krb5.conf etc/krb5.conf.d etc/nsswitch.conf etc/pam.d && sudo ipa-client-install --domain={{ipaDomain}} --realm={{ipaRealm}} --server={{ipaServer}} --hostname={{clientFqdn}} --ca-cert-file={{ipaCaCertificate}} --mkhomedir --enable-dns-updates

Example output / evidence

Complete!
VERSION: 4.12.4, API_VERSION: 2.254
Discovery was successful!
Client hostname: app01.example.net
Realm: EXAMPLE.NET
DNS Domain: example.net
IPA Server: ipa01.example.net
BaseDN: dc=example,dc=net
Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: enrollment-operator
Password for enrollment-operator:
Client configuration complete.

Checkpoint: Checkpoint: Enroll the host with interactive, auditable credentials

systemctl is-active sssd; test -s /etc/krb5.keytab; sudo klist -kte /etc/krb5.keytab

Continue whenEnrollment completes for the approved host, SSSD is active, a nonempty host keytab exists, and no credential appears in process listings or logs.

Stop whenDiscovery values differ, an unknown CA prompt appears, installer requests a reusable secret in argv, or the host entry/keytab belongs to another machine.

If this step fails

ipa-client-install rejects the hostname, domain, realm, or server.

Likely causeThe host has a short or transient hostname, `/etc/hosts` contradicts DNS, command-line discovery values do not match the deployment, or a stale host entry/keytab exists.

Safe checks

hostnamectl --static
hostname -f
getent hosts {{clientFqdn}}
ipa host-show {{clientFqdn}}
test -s /etc/krb5.keytab && klist -kte /etc/krb5.keytab

ResolutionReconcile the stable FQDN and DNS first. Investigate and explicitly retire stale host identity before re-enrollment; never overwrite an unknown keytab merely to make installation proceed.

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Pre-create the host and use a one-time password delivered through the provisioning trust channel; enter it interactively and expire it immediately after enrollment.

Stop conditions

Stop when the observed identity, trust, version, state, or output differs from the approved plan.
Stop when independent recovery access, a current state backup, or a named rollback owner is unavailable.

verification

Verify host keys, identity resolution, Kerberos, NSS, PAM, and SSSD

read-only

Inspect the enrolled host principal without exposing key material, validate SSSD configuration/domain state, obtain a user ticket interactively, resolve an approved identity, and verify server discovery.

Why this step matters

An installer success message does not prove that the keytab, SSSD provider, identity lookup, Kerberos trust, and failover discovery work together on the running system.

What to understand

Use `klist -kte`, not a command that prints key bytes. Keytab principals and encryption types are operational metadata but should still be protected in logs.

`sssctl config-check` catches structural configuration errors; `domain-status` shows whether SSSD is online and which services are active.

Destroy the user ticket after the test with `kdestroy`; never use a production user's password for automation.

System changes

Obtains a temporary Kerberos credential cache for the test user; otherwise reads active client state.

Syntax explained

klist -kte: Lists keytab principal, KVNO, timestamp, and encryption type without dumping secret keys.
sssctl config-check: Validates SSSD configuration syntax and permissions.
kvno: Requests a service ticket and displays its key version, proving KDC and service-principal reachability.

Command

Fill variables0/3 ready

Values stay on this page and are never sent or saved.

Ipa Domain{{ipaDomain}}Lowercase DNS domain served by the FreeIPA realm.Test User{{testUser}}Controlled deployer used to prove exact sudo allow and deny behavior.Ipa Server{{ipaServer}}Verified bootstrap FreeIPA replica FQDN; SSSD later uses DNS discovery.

sudo klist -kte /etc/krb5.keytab && sudo sssctl config-check && sudo sssctl domain-status {{ipaDomain}} && getent passwd {{testUser}} && kinit {{testUser}} && klist && kvno host/{{ipaServer}} && kdestroy

Example output / evidence

Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   2 07/28/2026 09:14:02 host/app01.example.net@EXAMPLE.NET
Issues identified by validators: 0
Online status: Online
Active servers:
IPA: ipa01.example.net
alice:*:1648200001:1648200001:Alice Operator:/home/alice:/bin/bash
Default principal: alice@EXAMPLE.NET
07/28/26 09:18:44  07/29/26 09:18:37  krbtgt/EXAMPLE.NET@EXAMPLE.NET
host/ipa01.example.net@EXAMPLE.NET: kvno = 3

Checkpoint: Checkpoint: Verify host keys, identity resolution, Kerberos, NSS, PAM, and SSSD

Continue whenCorrect host principal, clean SSSD validation, online domain, expected user identity, valid TGT, and service ticket from an approved replica.

Stop whenThe keytab names another host, identity attributes differ, SSSD is offline unexpectedly, or Kerberos reaches an unapproved realm/server.

If this step fails

The client enrolled, but `id` or `getent passwd` cannot resolve an IdM user.

Likely causeSSSD is unhealthy, the IPA domain is disabled, DNS/LDAP/Kerberos discovery is failing, the user is filtered, or stale negative cache hides a recently created identity.

Safe checks

systemctl status sssd --no-pager
sssctl config-check
sssctl domain-status {{ipaDomain}}
sssctl user-checks {{testUser}}
journalctl -u sssd --since '-15 min' --no-pager

ResolutionRepair discovery or SSSD configuration, preserve diagnostic logs, and invalidate only the affected cache after proving the authoritative identity exists. Do not recursively delete `/var/lib/sss`.

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Rehearse the exact step in an isolated environment with production-shaped identities, names, and trust paths before production.

Stop conditions

Stop when the observed identity, trust, version, state, or output differs from the approved plan.
Stop when independent recovery access, a current state backup, or a named rollback owner is unavailable.

verification

Establish positive and negative authentication baselines

read-only

Before tightening authorization, test identity lookup, Kerberos authentication, and the target PAM service with one intended operator and one intentionally excluded identity. Record the distinction between authentication success and host access.

Why this step matters

The expected pre-cutover result reveals the permissive baseline explicitly. Without a named denied identity, an operator can mistake successful authentication or `allow_all` behavior for correct least-privilege authorization.

What to understand

At this stage both users may still be granted by `allow_all`; that is evidence to be removed, not a final success condition.

`ipa hbactest` evaluates central rules, while `sssctl user-checks` exercises the client-facing PAM account path. Use both because cache and client configuration can change the effective result.

Do not test by repeatedly failing real passwords. Use controlled identities and preserve audit correlation IDs/timestamps.

System changes

Reads authoritative identity and access-policy state; creates no users, tickets, or policy changes.

Syntax explained

ipa hbactest: Simulates HBAC for a specific user, host, and PAM service against central policy.
-a acct -s sshd: Checks the PAM account phase for the sshd service through SSSD.

Command

Fill variables0/3 ready

Values stay on this page and are never sent or saved.

Allowed User{{allowedUser}}Controlled positive-test identity that belongs to the approved operator group.Denied User{{deniedUser}}Controlled negative-test identity intentionally excluded from the target HBAC rule.Client Fqdn{{clientFqdn}}Permanent canonical FQDN of the Linux client.

ipa user-show {{allowedUser}} --all; ipa user-show {{deniedUser}} --all; ipa hbactest --user={{allowedUser}} --host={{clientFqdn}} --service=sshd; ipa hbactest --user={{deniedUser}} --host={{clientFqdn}} --service=sshd; sudo sssctl user-checks {{allowedUser}} -a acct -s sshd; sudo sssctl user-checks {{deniedUser}} -a acct -s sshd

Example output / evidence

Access granted: True
Matched rules: allow_all
Access granted: True
Matched rules: allow_all
user: alice
action: acct
service: sshd
SSSD nss user lookup result: Success
PAM Environment: - no env -
PAM account management result: Success

Checkpoint: Checkpoint: Establish positive and negative authentication baselines

Continue whenBoth test identities resolve; the baseline output identifies precisely which current rule grants access and supplies a comparison for the later deny test.

Stop whenTest identities do not represent intended roles, central and client evaluation disagree without explanation, or authentication logs cannot be correlated.

If this step fails

A user receives an interactive shell even though the intended HBAC rule should deny it.

Likely causeThe default `allow_all` HBAC rule is still enabled, a broad overlapping rule applies, the host/service group is wrong, or cached policy has not refreshed.

Safe checks

ipa hbactest --user={{deniedUser}} --host={{clientFqdn}} --service=sshd
ipa hbacrule-find --enabled=TRUE --all
sssctl user-checks {{deniedUser}} -a acct -s sshd

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Rehearse the exact step in an isolated environment with production-shaped identities, names, and trust paths before production.

Stop conditions

Stop when the observed identity, trust, version, state, or output differs from the approved plan.
Stop when independent recovery access, a current state backup, or a named rollback owner is unavailable.

command

Create a narrow HBAC rule and prove it before cutover

caution

Create an explicit HBAC rule for the approved operator group, production host group, and `sshd` service. Add each dimension deliberately, then simulate allowed and denied users while the permissive rule still provides recovery.

Why this step matters

A fully scoped replacement rule must exist and pass simulation before removing the default safety net. Adding users, hosts, and services explicitly makes omissions visible during review.

What to understand

Use a dedicated HBAC service or service group for non-SSH PAM applications; do not assume an SSH rule controls console, sudo, cron, or application authentication.

Group membership changes authorization indirectly and therefore require the same review and deprovision SLA as rule edits.

The denied user may still be allowed by `allow_all` here. The important evidence is that the new rule matches only the intended user.

System changes

Creates and enables one central HBAC rule linking the approved user group, host group, and sshd service.

Syntax explained

hbacrule-add-user --groups: Scopes subjects through an approved group instead of individual exceptions.
hbacrule-add-host --hostgroups: Scopes targets to a maintained host class.
hbacrule-add-service --hbacsvcs: Restricts the PAM service to sshd.

Command

Fill variables0/6 ready

Values stay on this page and are never sent or saved.

Admin Hbac Rule{{adminHbacRule}}Explicit HBAC rule replacing permissive allow_all access.Operator Group{{operatorGroup}}FreeIPA user group allowed to reach production hosts over SSH.Production Host Group{{productionHostGroup}}FreeIPA host group containing the intended production Linux clients.Allowed User{{allowedUser}}Controlled positive-test identity that belongs to the approved operator group.Client Fqdn{{clientFqdn}}Permanent canonical FQDN of the Linux client.Denied User{{deniedUser}}Controlled negative-test identity intentionally excluded from the target HBAC rule.

ipa hbacrule-add {{adminHbacRule}} --desc='Production SSH for Linux operators'; ipa hbacrule-add-user {{adminHbacRule}} --groups={{operatorGroup}}; ipa hbacrule-add-host {{adminHbacRule}} --hostgroups={{productionHostGroup}}; ipa hbacrule-add-service {{adminHbacRule}} --hbacsvcs=sshd; ipa hbacrule-show {{adminHbacRule}} --all; ipa hbactest --user={{allowedUser}} --host={{clientFqdn}} --service=sshd; ipa hbactest --user={{deniedUser}} --host={{clientFqdn}} --service=sshd

Example output / evidence

Added HBAC rule "prod-ops-ssh"
  Rule name: prod-ops-ssh
  Enabled: TRUE
  User Groups: linux-ops
  Host Groups: production-linux
  Services: sshd
Access granted: True
Matched rules: prod-ops-ssh
Access granted: True
Matched rules: allow_all

Checkpoint: Checkpoint: Create a narrow HBAC rule and prove it before cutover

Continue whenThe new rule matches the allowed operator on this host and does not match the negative test identity.

Stop whenThe rule contains `all` categories, the denied identity matches it, host-group membership is incomplete, or break-glass access is untested.

If this step fails

A user receives an interactive shell even though the intended HBAC rule should deny it.

Likely causeThe default `allow_all` HBAC rule is still enabled, a broad overlapping rule applies, the host/service group is wrong, or cached policy has not refreshed.

Safe checks

ipa hbactest --user={{deniedUser}} --host={{clientFqdn}} --service=sshd
ipa hbacrule-find --enabled=TRUE --all
sssctl user-checks {{deniedUser}} -a acct -s sshd

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Rehearse the exact step in an isolated environment with production-shaped identities, names, and trust paths before production.

Stop conditions

Stop when the observed identity, trust, version, state, or output differs from the approved plan.
Stop when independent recovery access, a current state backup, or a named rollback owner is unavailable.

command

Disable allow_all through a controlled authorization cutover

danger

Keep an authenticated operator session and independent console open, confirm replacement rules for every required service and site, disable the default `allow_all` rule, refresh the client policy, then prove allowed login and denied login from a separate session.

Why this step matters

Disabling `allow_all` is the point at which an incomplete policy can lock out every central administrator. The controlled sequence retains two recovery paths and demands both positive and negative post-change evidence.

What to understand

Do not close the existing privileged session until a fresh allowed SSH session succeeds and the denied identity fails at the account phase.

Cache invalidation is disruptive and should be scoped to the change window. Avoid deleting SSSD databases, which can destroy offline credentials and forensic evidence.

Repeat tests against representative hosts in every site; a central simulation alone does not prove the client consumed the rule.

System changes

Disables the permissive global HBAC rule, invalidates SSSD caches, and restarts SSSD so explicit rules become effective.

Syntax explained

hbacrule-disable allow_all: Turns off the default rule without deleting it, allowing an auditable emergency re-enable.
sss_cache -E: Expires cached identity and policy entries so the client obtains current authorization data.
systemctl restart sssd: Reloads provider state after the controlled cache expiry.

Command

Fill variables0/3 ready

Values stay on this page and are never sent or saved.

Allowed User{{allowedUser}}Controlled positive-test identity that belongs to the approved operator group.Client Fqdn{{clientFqdn}}Permanent canonical FQDN of the Linux client.Denied User{{deniedUser}}Controlled negative-test identity intentionally excluded from the target HBAC rule.

allowed_before="$(ipa hbactest --user={{allowedUser}} --host={{clientFqdn}} --service=sshd)"; denied_before="$(ipa hbactest --user={{deniedUser}} --host={{clientFqdn}} --service=sshd)"; printf '%s
' "$allowed_before" "$denied_before"; printf '%s
' "$allowed_before" | grep -q 'Access granted: True' && printf '%s
' "$denied_before" | grep -q 'Access granted: False' && ipa hbacrule-disable allow_all && sudo sss_cache -E && sudo systemctl restart sssd; allowed_after="$(ipa hbactest --user={{allowedUser}} --host={{clientFqdn}} --service=sshd)"; denied_after="$(ipa hbactest --user={{deniedUser}} --host={{clientFqdn}} --service=sshd)"; printf '%s
' "$allowed_after" "$denied_after"; printf '%s
' "$allowed_after" | grep -q 'Access granted: True' && printf '%s
' "$denied_after" | grep -q 'Access granted: False' && sudo sssctl user-checks {{deniedUser}} -a acct -s sshd

Example output / evidence

Access granted: True
Matched rules: prod-ops-ssh
Access granted: True
Matched rules: allow_all
Disabled HBAC rule "allow_all"
Access granted: True
Matched rules: prod-ops-ssh
Access granted: False
Not matched rules: prod-ops-ssh
PAM account management result: Authentication failure

Checkpoint: Checkpoint: Disable allow_all through a controlled authorization cutover

Continue whenA fresh allowed SSH session works, the denied user is rejected, the current session remains open, and console break-glass is available.

Stop whenAny required role/service is denied, the negative user is allowed, SSSD remains offline, or the independent recovery path fails.

If this step fails

Disabling `allow_all` locks out administrators.

Likely causeReplacement HBAC rules omitted an administration group, target host, `sshd` service, or replication/site scenario, and break-glass access was not tested first.

Safe checks

Use the already-open root console or approved local break-glass session.
ipa hbactest --user={{adminUser}} --host={{clientFqdn}} --service=sshd
ipa hbacrule-show {{adminHbacRule}} --all

ResolutionRe-enable the last known-good rule through the independent recovery path, correct and test explicit replacement rules, then schedule a second controlled cutover.

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Stage the replacement rules on a canary host group first, then move hosts into the restricted group in small batches rather than disabling `allow_all` realm-wide at once.

Stop conditions

Stop unless two independent recovery paths are active: the current privileged session and a tested local/console break-glass path.
Immediately re-enable `allow_all` from the protected session if any named required access case fails, then investigate before retrying.

command

Create an exact-command sudo rule without shell escape

caution

Register the absolute executable and its constrained operation, create a host- and group-scoped sudo rule, require the user's own authentication, and avoid wildcard commands, editors, interpreters, package managers, or unrestricted systemctl.

Why this step matters

A central sudo rule can grant root on every matching host. Exact absolute commands, narrow group/host membership, and authentication preserve reviewable privilege boundaries.

What to understand

Argument matching behavior varies by sudo/SSSD versions; verify the effective `sudo -l` output on every supported client family and do not assume a visual string is a secure pattern.

`systemctl` can be dangerous when users may modify the unit or referenced environment/configuration. Restrict write access to the unit and everything it executes.

The add/remove probe demonstrates that passwordless authorization is not retained. In production, create the reviewed option state directly rather than relying on this illustrative guard.

System changes

Creates one central sudo command and a rule linking it to the approved deployer and application-host groups.

Syntax explained

sudocmd-add: Registers a specific privileged command object.
sudorule-add-allow-command: Associates only the registered command with this rule.
sudorule-add-user/host: Scopes the rule to maintained identity and host groups.

Command

Fill variables0/4 ready

Values stay on this page and are never sent or saved.

Service Unit{{serviceUnit}}Exact systemd unit delegated to the controlled deployer.Sudo Rule{{sudoRule}}FreeIPA sudo rule for one approved operational task.Deployer Group{{deployerGroup}}FreeIPA group containing identities allowed to perform the one delegated application action.Application Host Group{{applicationHostGroup}}FreeIPA host group containing only systems that expose the delegated application operation.

ipa sudocmd-add '/usr/bin/systemctl restart {{serviceUnit}}' && ipa sudorule-add {{sudoRule}} --desc='Restart one approved service' && ipa sudorule-add-user {{sudoRule}} --groups={{deployerGroup}} && ipa sudorule-add-host {{sudoRule}} --hostgroups={{applicationHostGroup}} && ipa sudorule-add-allow-command {{sudoRule}} --sudocmds='/usr/bin/systemctl restart {{serviceUnit}}' && ipa sudorule-show {{sudoRule}} --all

Example output / evidence

Added Sudo Command "/usr/bin/systemctl restart example.service"
Added Sudo Rule "app-restart"
  Enabled: TRUE
  User Groups: app-deployers
  Host Groups: application-hosts
  Sudo Allow Commands: /usr/bin/systemctl restart example.service
  Sudo Option: (none; authentication required)

Checkpoint: Checkpoint: Create an exact-command sudo rule without shell escape

Continue whenThe rule contains exactly one reviewed command, intended user/host groups, no wildcard, no ALL category, and no `!authenticate` option.

Stop whenThe command can open a shell, edit arbitrary files, load arbitrary code, or target a service whose unit/config is writable by the delegated user.

If this step fails

`sudo -l` grants commands broader than the reviewed policy.

Likely causeA wildcard, directory command, unrestricted run-as target, overlapping local sudoers file, broad IdM sudo rule, or shell-capable executable expands privilege.

Safe checks

sudo -l -U {{testUser}}
ipa sudorule-find --user={{testUser}} --host={{clientFqdn}} --all
grep -R --line-number --extended-regexp 'ALL|\*' /etc/sudoers /etc/sudoers.d 2>/dev/null

ResolutionRemove the broad rule, model exact executable paths and arguments where supported, avoid shells/editors/interpreters, and prove a permitted command succeeds while a neighboring command is denied.

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Rehearse the exact step in an isolated environment with production-shaped identities, names, and trust paths before production.

Stop conditions

Stop when the observed identity, trust, version, state, or output differs from the approved plan.
Stop when independent recovery access, a current state backup, or a named rollback owner is unavailable.

verification

Prove both the sudo allow path and adjacent deny path

caution

Refresh policy, then sign in through a separate terminal as the controlled test user. List effective authorization, run the approved restart, and attempt a neighboring service plus an interactive root shell while the same authenticated sudo timestamp is valid.

Why this step matters

A rule listing is not enough: client version, cache, local sudoers, argument semantics, and executable behavior determine the effective privilege. Adjacent denials expose accidental wildcard or ALL grants.

What to understand

Use an interactive terminal already logged in as the test identity for every command in this block so the password is never scripted or piped.

The negative probes run after the approved authenticated command and therefore must report policy denial rather than merely a missing password; any success is a release blocker.

Review local `/etc/sudoers.d` and configuration management so a local rule cannot silently supersede the central least-privilege model.

System changes

Restarts the single approved service and expires client caches; denied probes should make no system change.

Syntax explained

sudo -l: Shows the current controlled test user's effective sudo policy on the target host.
same authenticated timestamp: Makes negative probes demonstrate authorization denial rather than the absence of a password prompt.

Command

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Service Unit{{serviceUnit}}Exact systemd unit delegated to the controlled deployer.

sudo -l; sudo /usr/bin/systemctl restart {{serviceUnit}}; systemctl is-active {{serviceUnit}}; sudo /usr/bin/systemctl restart sshd; sudo /bin/sh -c id

Example output / evidence

User deployer may run the following commands on app01:
    (root) /usr/bin/systemctl restart example.service
[sudo] password for deployer:
active
Sorry, user deployer is not allowed to execute '/usr/bin/systemctl restart sshd' as root on app01.
Sorry, user deployer is not allowed to execute '/bin/sh -c id' as root on app01.

Checkpoint: Checkpoint: Prove both the sudo allow path and adjacent deny path

Continue whenOnly the approved command appears, it requires user authentication and works, while the adjacent service and shell probes are denied.

Stop whenAny ALL/wildcard appears, a negative probe succeeds, the user can modify the unit/config, or the approved command runs without the intended authentication.

If this step fails

An authorized sudo rule does not appear on the client.

Likely causeThe host or user is outside the rule, SSSD sudo responder/configuration is wrong, cache is stale, time/DNS is broken, or the rule's command/run-as membership is incomplete.

Safe checks

ipa sudorule-show {{sudoRule}} --all
sssctl domain-status {{ipaDomain}}
sudo -l -U {{testUser}}
journalctl -u sssd --since '-15 min' --no-pager | grep -i sudo

ResolutionCorrect authoritative rule membership, restore online connectivity, expire only the relevant cache entry, and retest. Do not add an emergency unrestricted local sudo rule.

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Rehearse the exact step in an isolated environment with production-shaped identities, names, and trust paths before production.

Stop conditions

Stop when the observed identity, trust, version, state, or output differs from the approved plan.
Stop when independent recovery access, a current state backup, or a named rollback owner is unavailable.

config

Bound SSSD offline credentials and document revocation lag

caution

Enable credential caching only when the host must survive a short IdM/network outage, set a finite offline credential lifetime, validate permissions and syntax, and explicitly accept that central disablement cannot immediately reach a disconnected client.

Why this step matters

Cached credentials improve availability but extend the time a stolen laptop, disabled account, or disconnected host may authenticate without central confirmation. A finite window makes that risk measurable.

What to understand

SSSD stores a salted password verifier rather than plaintext, but offline guessing and revocation lag remain security concerns; disk encryption and physical controls still matter.

`offline_credentials_expiration=3` means cached authentication expires after three days since the last successful online login; choose a shorter value where recovery connectivity is reliable.

HBAC and sudo data are cached separately. Test the exact supported distribution because offline authorization behavior and refresh timing can differ by package version.

System changes

Updates SSSD offline credential policy and will require an SSSD restart after validation.

Syntax explained

cache_credentials = true: Allows previously online-authenticated users to authenticate during an IdM outage.
offline_credentials_expiration = 3: Expires cached password authentication after three days without successful online authentication.
offline_failed_login_attempts = 3: Limits repeated failed offline attempts before delay behavior applies.
ipa_server = _srv_: Uses DNS service discovery and replica failover instead of a permanent single-server pin.

File /etc/sssd/sssd.conf

Configuration

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Ipa Domain{{ipaDomain}}Lowercase DNS domain served by the FreeIPA realm.

[domain/{{ipaDomain}}]
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_domain = {{ipaDomain}}
ipa_server = _srv_
cache_credentials = true

[pam]
offline_credentials_expiration = 3
offline_failed_login_attempts = 3
offline_failed_login_delay = 5

Example output / evidence

File ownership: root:root
File mode: 0600
Issues identified by validators: 0
Online status: Online
Cached authentication policy: maximum 3 days since last successful online authentication

Checkpoint: Checkpoint: Bound SSSD offline credentials and document revocation lag

sudo chown root:root /etc/sssd/sssd.conf; sudo chmod 0600 /etc/sssd/sssd.conf; sudo sssctl config-check; sudo systemctl restart sssd; sudo sssctl domain-status {{ipaDomain}}

Continue whenRoot-owned 0600 file, zero validator issues, SSSD restarts, and the domain returns online with the approved finite offline window.

Stop whenThe policy permits indefinite caching, config permissions expose data, SSSD fails validation/startup, or stakeholders assume disablement is immediate while offline.

If this step fails

A disabled user can still log in while the client is offline.

Likely causeSSSD cached credentials and a previously cached access decision remain valid inside the configured offline window; central revocation cannot be observed without connectivity.

Safe checks

sssctl domain-status {{ipaDomain}}
sssctl user-checks {{disabledUser}} -a acct -s sshd
grep -E '^(cache_credentials|offline_credentials_expiration)' /etc/sssd/sssd.conf

ResolutionTreat this as the documented offline-auth risk: restore connectivity or invalidate cached credentials locally through incident response, then shorten the bounded window if operationally feasible.

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Set `cache_credentials=false` on continuously connected high-assurance servers where loss of central availability should fail closed.
Use a shorter expiration for mobile/high-risk devices and rely on the tested local break-glass path for infrastructure recovery.

Stop conditions

Stop when the observed identity, trust, version, state, or output differs from the approved plan.
Stop when independent recovery access, a current state backup, or a named rollback owner is unavailable.

verification

Exercise replica failover and the offline-auth boundary

caution

In a canary environment, remove only one approved replica from the client's path, observe SSSD select another discovered server, then simulate a bounded all-replica outage and confirm exactly which pre-cached user can authenticate and when access expires.

Why this step matters

A configuration that appears redundant may still pin one replica or fail closed/open differently than expected. Controlled failure testing proves discovery, failover, cache boundaries, and recovery timing before a real outage.

What to understand

Do not stop all production IdM replicas or alter authoritative DNS globally. Use firewall/network controls scoped to the canary host or an isolated rehearsal.

Pre-cache only the dedicated test identity through a successful online login; do not pre-cache broad administrator populations merely to make the test pass.

Record how quickly SSSD detects failure and returns online, plus the security consequence that a centrally disabled cached user may remain usable during the finite offline period.

System changes

Temporarily alters the canary client's reachability to selected IdM replicas and may create a cached credential for the approved test user.

Syntax explained

_srv_: Lets SSSD consume DNS priorities and fail over among discovered IdM replicas.
sssctl domain-status: Reports online/offline state and currently active service servers.
user-checks: Exercises client PAM authorization for cached and uncached identities.

Command

Fill variables0/3 ready

Values stay on this page and are never sent or saved.

Ipa Domain{{ipaDomain}}Lowercase DNS domain served by the FreeIPA realm.Cached User{{cachedUser}}Controlled user that completed one approved online login before the offline-auth rehearsal.Uncached User{{uncachedUser}}Controlled user that has never authenticated on the canary and therefore must fail offline.

dig +short _ldap._tcp.{{ipaDomain}} SRV; sudo sssctl domain-status {{ipaDomain}}; sudo journalctl -u sssd --since '-10 min' --no-pager | grep -E 'Selected|offline|online|server'; klist; sudo sssctl user-checks {{cachedUser}} -a acct -s sshd; sudo sssctl user-checks {{uncachedUser}} -a acct -s sshd

Example output / evidence

0 100 389 ipa01.example.net.
0 100 389 ipa02.example.net.
Online status: Online
Active servers:
IPA: ipa02.example.net
[be[example.net]] Selected IPA server ipa02.example.net
cached-operator: PAM account management result: Success
never-cached-user: PAM account management result: Authentication failure

Checkpoint: Checkpoint: Exercise replica failover and the offline-auth boundary

Continue whenThe client fails from one replica to another, returns online after restoration, cached access matches the approved window, and never-cached access fails offline.

Stop whenThe client pins a dead server, uses an unapproved replica, an uncached identity succeeds offline, or connectivity cannot be restored within the maintenance window.

If this step fails

The client stays offline even though one IdM server is reachable.

Likely causeDNS SRV records are stale, firewalls block required services, site discovery is wrong, all discovered servers failed backoff, or CA/Kerberos trust differs across replicas.

Safe checks

dig +short _ldap._tcp.{{ipaDomain}} SRV
sssctl domain-status {{ipaDomain}}
nc -vz {{ipaServer}} 443
nc -vz {{ipaServer}} 389
kvno host/{{ipaServer}}

ResolutionRepair the discovery, network, replica, or trust inconsistency. Use supported SSSD failover rather than pinning a permanent single-server workaround.

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Use a lab replica set and a production-shaped client image when network controls cannot safely isolate only the canary host.

Stop conditions

Stop when the observed identity, trust, version, state, or output differs from the approved plan.
Stop when independent recovery access, a current state backup, or a named rollback owner is unavailable.

command

Disable a departing user and close cached-access gaps

caution

Disable the identity before deleting or anonymizing records, remove high-risk group and sudo memberships, revoke certificates and sessions under the incident/offboarding process, and identify offline clients that may still honor cached credentials.

Why this step matters

Disabling preserves audit and ownership history while stopping new central authentication. Immediate deletion can break forensic correlation without invalidating already cached or issued credentials.

What to understand

Inventory Kerberos tickets, certificates, SSH keys, API tokens, application sessions, vault access, and local accounts separately; FreeIPA user disablement cannot revoke every external credential.

Connected clients should reject the identity after cache refresh, but disconnected clients may honor cached authentication until the bounded expiration. High-risk departures require a device/network response.

Delay destructive deletion until retention, ownership transfer, and audit requirements are satisfied.

System changes

Disables the FreeIPA user and may trigger removal of group/rule memberships and certificate revocation through associated controlled workflows.

Syntax explained

user-disable: Stops central account authentication while retaining the directory object and audit relationships.
group-find --user: Finds groups that may confer access indirectly.
user-show --all --raw: Preserves authoritative user attributes, including stored certificate/key metadata where present, for separate credential disposition.

Command

Fill variables0/2 ready

Values stay on this page and are never sent or saved.

Departing User{{departingUser}}Controlled or real offboarding identity processed through the reviewed disablement workflow.Client Fqdn{{clientFqdn}}Permanent canonical FQDN of the Linux client.

ipa user-disable {{departingUser}}; ipa user-show {{departingUser}} --all --raw; ipa group-find --user={{departingUser}}; ipa sudorule-find --user={{departingUser}} --all; ipa hbactest --user={{departingUser}} --host={{clientFqdn}} --service=sshd

Example output / evidence

Disabled user account "departing.user"
  User login: departing.user
  Account disabled: True
-----------------
0 HBAC rules matched
-----------------
Access granted: False

Checkpoint: Checkpoint: Disable a departing user and close cached-access gaps

Continue whenThe account is disabled, no intended HBAC path grants access, privileged memberships are removed, credentials are inventoried, and offline-client exposure has an owner.

Stop whenThe account remains active, an overlapping rule grants access, critical resources lack a new owner, or the response assumes offline cache was revoked centrally.

If this step fails

A disabled user can still log in while the client is offline.

Likely causeSSSD cached credentials and a previously cached access decision remain valid inside the configured offline window; central revocation cannot be observed without connectivity.

Safe checks

sssctl domain-status {{ipaDomain}}
sssctl user-checks {{disabledUser}} -a acct -s sshd
grep -E '^(cache_credentials|offline_credentials_expiration)' /etc/sssd/sssd.conf

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Rehearse the exact step in an isolated environment with production-shaped identities, names, and trust paths before production.

Stop conditions

Stop when the observed identity, trust, version, state, or output differs from the approved plan.
Stop when independent recovery access, a current state backup, or a named rollback owner is unavailable.

command

Disable a retired host before removing key material

danger

Disable the host and associated service principals first, inventory certificates and DNS records, preserve required audit evidence, unenroll from a controlled local session, then securely erase keytabs and machine credentials through the asset-disposal workflow.

Why this step matters

Host keytabs and service credentials can authenticate cloned images after inventory removal. Disabling principals before local cleanup closes central use while preserving evidence for review.

What to understand

Do not delete the host object first: deletion can discard associations and audit context while copies of key material remain usable elsewhere.

Revoke host/service certificates separately, remove DNS only after traffic and ownership checks, and invalidate golden images or snapshots containing the old keytab.

Run uninstall only with a working local/console administrator. The current SSH session may survive briefly, but future central logins should not be assumed.

System changes

Disables central host identity, unconfigures the local FreeIPA client, and removes active host keytab/configuration according to installer behavior.

Syntax explained

host-disable: Invalidates the host's Kerberos keys without immediately deleting the directory object.
service-find: Locates service principals whose keys/certificates may outlive the host record.
--uninstall: Uses the supported client rollback path instead of manually deleting SSSD/Kerberos files.

Command

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Client Fqdn{{clientFqdn}}Permanent canonical FQDN of the Linux client.

ipa host-disable {{clientFqdn}} && ipa host-show {{clientFqdn}} --all && ipa service-find {{clientFqdn}} --all && ipa cert-find --host={{clientFqdn}} && sudo ipa-client-install --uninstall && sudo test ! -s /etc/krb5.keytab && echo 'Host keytab absent'

Example output / evidence

Disabled host "app01.example.net"
  Host name: app01.example.net
  Keytab: False
Unenrolling client from IPA server
Disabling client Kerberos and LDAP configurations
Client uninstall complete.
Host keytab absent

Checkpoint: Checkpoint: Disable a retired host before removing key material

Continue whenHost reports disabled, related principals/certificates have disposition records, uninstall succeeds through local recovery, and no keytab remains on live storage or templates.

Stop whenThe host still serves production traffic, another service uses its principal, local recovery is unavailable, or snapshots/images retain uncontrolled key material.

If this step fails

A decommissioned host can still request tickets or authenticate to services.

Likely causeThe host principal was not disabled, keytabs remain on disk or images, service principals were overlooked, caches remain valid, or the host was merely deleted from inventory.

Safe checks

ipa host-show {{clientFqdn}} --all
ipa service-find {{clientFqdn}} --all
klist -kte /etc/krb5.keytab
Review recent Kerberos and SSSD authentication logs.

ResolutionDisable host and related service principals first, revoke certificates where applicable, erase keytabs through the asset-destruction process, then remove inventory only after the retention period.

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

For a temporary repair, disable the host and preserve local configuration without uninstalling; re-enable only after incident review and key rotation.

Stop conditions

Stop before unenrollment unless an independent local/console administrator session is active and verified.
Stop if certificate, DNS, service-principal, backup-image, or asset-destruction ownership is unresolved.

command

Rollback a failed client enrollment safely

danger

When enrollment must be reversed, retain the current privileged session, disable any newly created host keys centrally, run the supported uninstaller, restore only reviewed pre-enrollment files if needed, and verify local NSS/PAM/SSH access before closing recovery.

Why this step matters

Manual deletion of SSSD, PAM, NSS, Kerberos, or keytab files can leave a partially enrolled host and cause lockout. The supported uninstall plus a scoped backup is the recoverable path.

What to understand

Do not blindly restore an archive over package-version changes. Inspect the uninstaller result and restore only files required by the known previous authentication stack.

Central host disablement prevents abandoned keys from being used if a backup or snapshot still contains them.

Prove both local recovery and the intended pre-enrollment authentication path in a fresh session before closing the existing privileged connection.

System changes

Removes FreeIPA client integration and may restore the reviewed pre-enrollment authentication configuration.

Syntax explained

ipa-client-install --uninstall: Invokes the supported reversal of SSSD, Kerberos, PAM/NSS, certificate, and SSH client integration.
tar --xattrs --acls: Restores preserved ownership, modes, ACLs, and extended attributes from the scoped backup.
authselect check: Validates the distribution authentication profile when authselect is present.

Command

Fill variables0/2 ready

Values stay on this page and are never sent or saved.

Pre Enrollment Backup{{preEnrollmentBackup}}Root-readable archive of the scoped authentication configuration before enrollment.Break Glass User{{breakGlassUser}}Local console/management recovery account whose credential remains in the emergency vault.

sudo ipa-client-install --uninstall && sudo tar --xattrs --acls -C / -xzf {{preEnrollmentBackup}} && sudo authselect check && getent passwd {{breakGlassUser}} && sudo -l -U {{breakGlassUser}}

Example output / evidence

Unenrolling client from IPA server
Restoring client configuration files
Client uninstall complete.
Current configuration is valid.
local-recovery:x:991:991:Emergency local access:/var/lib/local-recovery:/bin/bash
User local-recovery may run the following commands on app01:
    (root) /usr/bin/systemctl status *, /usr/bin/journalctl *

Checkpoint: Checkpoint: Rollback a failed client enrollment safely

Continue whenThe host is no longer enrolled, central host keys are disabled, local recovery works in a new session, and the previous authentication stack passes its own health check.

Stop whenUninstall is partial, a host key remains enabled, restored files mismatch packages, or closing the current session would remove the only access path.

If this step fails

Unenrollment removes central login before local recovery is available.

Likely causeThe operator ran `ipa-client-install --uninstall` over the only privileged remote session or never validated a local console/break-glass account.

Safe checks

Keep the current privileged session open.
getent passwd {{breakGlassUser}}
sudo -l -U {{breakGlassUser}}
systemctl is-enabled sshd

ResolutionUse console recovery, restore the saved pre-enrollment configuration or re-enroll through a fresh one-time credential, and add an independent access gate to future change procedures.

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Restore the whole canary VM/image from a verified pre-enrollment snapshot when configuration provenance is uncertain and application data is externalized.

Stop conditions

Keep the original privileged session open until a fresh independent login succeeds.
Escalate instead of manually deleting authentication databases when supported uninstall or restoration reports errors.

decision

Use LDAP-only integration only as a constrained application exception

read-only

For software that cannot use Kerberos or the SSSD IPA provider, approve a unique application service identity, narrow search base/filter and directory permissions, verify LDAPS or StartTLS hostname trust, and retrieve the bind secret through a protected runtime reference.

Why this step matters

LDAP bind can provide directory lookup and simple authentication, but it does not reproduce host enrollment, Kerberos SSO, HBAC, sudo, host keys, certificate lifecycle, or native offline policy. Treating it as equivalent creates hidden control gaps.

What to understand

Never use the Directory Manager, FreeIPA admin, or one shared bind DN across applications. Give each application a revocable identity and the minimum search/read rights.

Use LDAPS or StartTLS with CA and hostname verification; encryption without identity verification is vulnerable to interception.

Keep the secret out of argv, environment dumps, container image layers, source control, and world-readable unit files. Prefer a root-only credential file, systemd credential, or approved secret broker.

Document that the application owns pooling, reconnect, password rotation, server failover, audit correlation, and behavior when LDAP is unavailable.

System changes

Creates an exception design; implementing LDAP ACIs/service identity and application secret delivery requires separate approved changes.

Syntax explained

LDAPS: LDAP over TLS from connection start, with certificate and hostname verification.
StartTLS: Upgrades a plaintext LDAP connection to verified TLS before authentication; reject downgrade.
unique service identity: Limits blast radius and enables independent rotation, auditing, and revocation.
narrow search base/filter: Reduces exposed directory scope and accidental authorization by mere directory presence.

Example output / evidence

LDAP exception approved: app=legacy-inventory; endpoint=ldaps://ipa01.example.net:636; base=cn=users,cn=accounts,dc=example,dc=net; filter=(memberOf=cn=inventory-users,cn=groups,cn=accounts,dc=example,dc=net); bind=uid=svc-inventory,cn=sysaccounts,cn=etc,dc=example,dc=net; secret source=protected credential file; anonymous bind=denied.

Checkpoint: Checkpoint: Use LDAP-only integration only as a constrained application exception

Continue whenThe application validates TLS identity, anonymous access is denied, bind identity is unique/least-privilege, the secret is referenced securely, and limitations are accepted.

Stop whenThe design uses plaintext LDAP, skips certificate verification, embeds a password, grants broad directory/admin rights, or claims LDAP bind supplies HBAC/sudo/Kerberos controls.

If this step fails

An LDAP-only application either cannot bind securely or gains excessive directory visibility.

Likely causeIt uses plaintext LDAP, anonymous bind, a shared administrator DN, an unverified CA, an unscoped search base, or a reusable password exposed in a unit file/argv.

Safe checks

openssl s_client -connect {{ipaServer}}:636 -servername {{ipaServer}} -CAfile {{ipaCaCertificate}} </dev/null
ldapwhoami -H ldaps://{{ipaServer}} -D '{{applicationBindDn}}' -W
Review effective LDAP ACIs and the application's search base.

ResolutionUse a unique least-privilege service identity, LDAPS or StartTLS with hostname verification, a protected credential reference, and a narrow base/filter. Prefer native IPA/Kerberos integration when possible.

Security notes

Never put passwords, private-key passphrases, enrollment one-time passwords, LDAP bind credentials, keytabs, or recovery secrets in command arguments, shell history, environment dumps, tickets, screenshots, or this guide. Use an interactive prompt, protected file descriptor, hardware token, or approved secret broker.
Separate human administration, automated enrollment, signing, revocation, host operation, and break-glass duties. A single reusable domain administrator or CA key on online hosts defeats the intended security boundary.
Test both an allowed and a denied identity operation. A successful privileged administrator action does not prove least privilege, hostname verification, revocation, HBAC, or sudo enforcement.
Keep an independently tested recovery path that does not depend on the service being recovered. Identity and PKI outages can otherwise prevent the operators who need to repair them from logging in.

Alternatives

Prefer GSSAPI/Kerberos or an application-supported OIDC/SAML gateway backed by the organization's approved identity architecture.
Use SSSD/PAM on the host for system login instead of teaching every daemon to perform password binds.

Stop conditions

Stop when the observed identity, trust, version, state, or output differs from the approved plan.
Stop when independent recovery access, a current state backup, or a named rollback owner is unavailable.

Finish line

Verification checklist

Native identity and Kerberosgetent passwd {{testUser}}; kinit {{testUser}}; klist; kvno host/{{ipaServer}}Correct IPA identity attributes, valid realm TGT, and service ticket from an approved KDC.

HBAC allow and deny

ipa hbactest --user={{allowedUser}} --host={{clientFqdn}} --service=sshd; ipa hbactest --user={{deniedUser}} --host={{clientFqdn}} --service=sshd

Allowed user matches the explicit rule; denied user returns Access granted: False after allow_all is disabled.

Exact sudo boundarysudo -l -U {{testUser}}Only the reviewed absolute service restart appears; no ALL, wildcard, shell, editor, interpreter, or passwordless option is listed. The interactive negative proof is captured in the sudo verification step.

Replica and cache boundary

sssctl domain-status {{ipaDomain}}; sssctl user-checks {{cachedUser}} -a acct -s sshd; sssctl user-checks {{uncachedUser}} -a acct -s sshd

Replica failover works online; only the pre-cached test identity works inside the finite offline window.

Break-glass independencegetent passwd {{breakGlassUser}}; sudo -l -U {{breakGlassUser}}Local identity and constrained recovery privileges remain available without FreeIPA.

Recovery guidance

Common problems and safe checks

The client cannot discover an IdM server or Kerberos realm.

Likely causeThe host uses the wrong DNS resolver, the IdM DNS SRV records are absent, split-horizon DNS returns an unintended view, or the hostname has no stable forward and reverse mapping.

Safe checks

resolvectl status
dig +short _ldap._tcp.{{ipaDomain}} SRV
dig +short _kerberos._udp.{{ipaDomain}} SRV
getent ahosts {{clientFqdn}}
dig +short -x {{clientAddress}}

ResolutionCorrect the authoritative DNS delegation or resolver path and prove forward, reverse, LDAP, and Kerberos discovery from the client network before retrying enrollment.

Kerberos authentication fails with clock skew or a ticket is immediately invalid.

Likely causeThe client and IdM servers do not share a trustworthy time source, NTP is blocked, the VM clock jumped, or an incorrect timezone masked an unsynchronized clock.

Safe checks

timedatectl status
chronyc tracking
chronyc sources -v
date -u

ResolutionRestore synchronized time from the approved source, investigate large jumps, destroy stale tickets with `kdestroy`, and retry only after the offset is consistently small.

Enrollment reports an untrusted certificate or connects to an unexpected server.

Safe checks

openssl x509 -in {{ipaCaCertificate}} -noout -subject -issuer -fingerprint -sha256
openssl s_client -connect {{ipaServer}}:443 -servername {{ipaServer}} -CAfile {{ipaCaCertificate}} </dev/null
Compare the CA fingerprint through an independent administrator channel.

ResolutionDo not accept the certificate interactively. Obtain the IdM CA through the controlled bootstrap channel, verify its SHA-256 fingerprint, and correct DNS or proxy routing.

ipa-client-install rejects the hostname, domain, realm, or server.

Likely causeThe host has a short or transient hostname, `/etc/hosts` contradicts DNS, command-line discovery values do not match the deployment, or a stale host entry/keytab exists.

Safe checks

hostnamectl --static
hostname -f
getent hosts {{clientFqdn}}
ipa host-show {{clientFqdn}}
test -s /etc/krb5.keytab && klist -kte /etc/krb5.keytab

The client enrolled, but `id` or `getent passwd` cannot resolve an IdM user.

Likely causeSSSD is unhealthy, the IPA domain is disabled, DNS/LDAP/Kerberos discovery is failing, the user is filtered, or stale negative cache hides a recently created identity.

Safe checks

systemctl status sssd --no-pager
sssctl config-check
sssctl domain-status {{ipaDomain}}
sssctl user-checks {{testUser}}
journalctl -u sssd --since '-15 min' --no-pager

A user receives an interactive shell even though the intended HBAC rule should deny it.

Likely causeThe default `allow_all` HBAC rule is still enabled, a broad overlapping rule applies, the host/service group is wrong, or cached policy has not refreshed.

Safe checks

ipa hbactest --user={{deniedUser}} --host={{clientFqdn}} --service=sshd
ipa hbacrule-find --enabled=TRUE --all
sssctl user-checks {{deniedUser}} -a acct -s sshd

Disabling `allow_all` locks out administrators.

Likely causeReplacement HBAC rules omitted an administration group, target host, `sshd` service, or replication/site scenario, and break-glass access was not tested first.

Safe checks

Use the already-open root console or approved local break-glass session.
ipa hbactest --user={{adminUser}} --host={{clientFqdn}} --service=sshd
ipa hbacrule-show {{adminHbacRule}} --all

ResolutionRe-enable the last known-good rule through the independent recovery path, correct and test explicit replacement rules, then schedule a second controlled cutover.

`sudo -l` grants commands broader than the reviewed policy.

Likely causeA wildcard, directory command, unrestricted run-as target, overlapping local sudoers file, broad IdM sudo rule, or shell-capable executable expands privilege.

Safe checks

sudo -l -U {{testUser}}
ipa sudorule-find --user={{testUser}} --host={{clientFqdn}} --all
grep -R --line-number --extended-regexp 'ALL|\*' /etc/sudoers /etc/sudoers.d 2>/dev/null

An authorized sudo rule does not appear on the client.

Likely causeThe host or user is outside the rule, SSSD sudo responder/configuration is wrong, cache is stale, time/DNS is broken, or the rule's command/run-as membership is incomplete.

Safe checks

ipa sudorule-show {{sudoRule}} --all
sssctl domain-status {{ipaDomain}}
sudo -l -U {{testUser}}
journalctl -u sssd --since '-15 min' --no-pager | grep -i sudo

ResolutionCorrect authoritative rule membership, restore online connectivity, expire only the relevant cache entry, and retest. Do not add an emergency unrestricted local sudo rule.

A disabled user can still log in while the client is offline.

Likely causeSSSD cached credentials and a previously cached access decision remain valid inside the configured offline window; central revocation cannot be observed without connectivity.

Safe checks

sssctl domain-status {{ipaDomain}}
sssctl user-checks {{disabledUser}} -a acct -s sshd
grep -E '^(cache_credentials|offline_credentials_expiration)' /etc/sssd/sssd.conf

The client stays offline even though one IdM server is reachable.

Likely causeDNS SRV records are stale, firewalls block required services, site discovery is wrong, all discovered servers failed backoff, or CA/Kerberos trust differs across replicas.

Safe checks

dig +short _ldap._tcp.{{ipaDomain}} SRV
sssctl domain-status {{ipaDomain}}
nc -vz {{ipaServer}} 443
nc -vz {{ipaServer}} 389
kvno host/{{ipaServer}}

ResolutionRepair the discovery, network, replica, or trust inconsistency. Use supported SSSD failover rather than pinning a permanent single-server workaround.

A decommissioned host can still request tickets or authenticate to services.

Likely causeThe host principal was not disabled, keytabs remain on disk or images, service principals were overlooked, caches remain valid, or the host was merely deleted from inventory.

Safe checks

ipa host-show {{clientFqdn}} --all
ipa service-find {{clientFqdn}} --all
klist -kte /etc/krb5.keytab
Review recent Kerberos and SSSD authentication logs.

Unenrollment removes central login before local recovery is available.

Likely causeThe operator ran `ipa-client-install --uninstall` over the only privileged remote session or never validated a local console/break-glass account.

Safe checks

Keep the current privileged session open.
getent passwd {{breakGlassUser}}
sudo -l -U {{breakGlassUser}}
systemctl is-enabled sshd

ResolutionUse console recovery, restore the saved pre-enrollment configuration or re-enroll through a fresh one-time credential, and add an independent access gate to future change procedures.

An LDAP-only application either cannot bind securely or gains excessive directory visibility.

Likely causeIt uses plaintext LDAP, anonymous bind, a shared administrator DN, an unverified CA, an unscoped search base, or a reusable password exposed in a unit file/argv.

Safe checks

openssl s_client -connect {{ipaServer}}:636 -servername {{ipaServer}} -CAfile {{ipaCaCertificate}} </dev/null
ldapwhoami -H ldaps://{{ipaServer}} -D '{{applicationBindDn}}' -W
Review effective LDAP ACIs and the application's search base.

After the procedure

Alternatives and next steps

Consider these alternatives

Use a managed identity platform or distribution-supported Active Directory integration when the organization cannot operate redundant FreeIPA servers, DNS, Kerberos, CA, backup, and policy review safely.
Disable SSSD credential caching on continuously connected high-assurance hosts, accepting fail-closed authentication during IdM/network outages and relying on independent local recovery.
Roll out explicit HBAC through canary host groups before a realm-wide `allow_all` cutover, moving hosts in batches after positive and negative tests.
For legacy applications only, use a unique least-privilege LDAP service identity over verified LDAPS/StartTLS with a protected runtime credential; do not call it equivalent to native IPA enrollment.

Operate it safely

Roll out enrollment and policy to one canary per operating-system family and site; compare SSSD, sudo, PAM, and Kerberos behavior before broader deployment.
Monitor replica replication, KDC/LDAP/TLS health, DNS SRV accuracy, CA expiry, SSSD offline duration, HBAC denies, sudo events, and use of break-glass identities.
Automate drift checks for `allow_all`, ALL/wildcard sudo rules, stale host keytabs, disabled users with cached high-risk devices, unsupported client versions, and expiring certificates.
Rehearse IdM replica loss, DNS/time failure, user disablement during client outage, break-glass access, host decommission, and client rollback at least every 90 days.
Move LDAP-only applications toward Kerberos/GSSAPI or an approved federation gateway and rotate each unique bind credential on a documented schedule.

Reference

Frequently asked questions

Why not pass `--principal` and `--password` to automate ipa-client-install?

A password in argv can appear in process listings, job logs, shell history, crash data, and monitoring. Prefer a short-lived one-time enrollment credential entered through an approved protected channel or a provisioning integration that never exposes a reusable administrator password.

Does disabling a FreeIPA user immediately block an offline laptop?

No. A disconnected SSSD client cannot observe central disablement and may accept a previously cached credential until its configured offline expiration. Restore connectivity, perform local incident action, or use device/network controls for urgent revocation.

Can LDAP bind replace FreeIPA client enrollment?

Only for a narrowly scoped application lookup/authentication exception. It does not provide the native host identity, Kerberos SSO, HBAC, sudo, SSH host keys, certificate lifecycle, discovery, or integrated offline behavior supplied by SSSD's IPA provider.

Should we delete allow_all before creating HBAC rules?

No. Build and simulate explicit replacement rules first, retain a privileged session and tested console access, then disable—not delete—allow_all during a controlled canary cutover and prove both an allowed and denied login.

Recovery

Rollback

Keep the current privileged session and independent console open. Disable abandoned host credentials centrally, use the supported FreeIPA client uninstaller, restore only reviewed pre-enrollment authentication state, and prove fresh local access before closing recovery.

Pause rollout and preserve SSSD, Kerberos, PAM, NSS, installer, DNS, and time evidence before invalidating caches or restoring files.
For HBAC lockout, re-enable the last known-good rule through the protected session; do not add permanent wildcard access.
For bad sudo policy, disable the specific central rule and verify no overlapping local/central rule remains.
For failed enrollment, disable the host principal, run `ipa-client-install --uninstall`, and restore the scoped pre-enrollment backup only when package/config provenance matches.
For host retirement, keep the directory object disabled for the retention period and separately revoke certificates, erase keytabs from snapshots/images, transfer resource ownership, and remove DNS after traffic review.

Evidence

Sources and review

Verified 2026-07-24Review due 2026-10-22

FreeIPA 4.12.4 security-fix release notesofficial FreeIPA deployment recommendationsofficial FreeIPA DNS integrationofficial FreeIPA client architectureofficial FreeIPA HBAC and allow_all procedureofficial Red Hat Enterprise Linux 9: Installing an Identity Management clientofficial Red Hat Enterprise Linux 9: Preparing a system for IdM client installationofficial Red Hat Enterprise Linux 9: Configuring HBAC rulesofficial Red Hat Enterprise Linux 9: SSSD offline authentication configurationofficial