FreeIPA host-based access control and sudo rules

The HBAC and sudo decisions you define in FreeIPA are not made on the IdM servers at login time. They are made on each Linux host by SSSD, which fetches the relevant HBAC and sudo rules from the IdM servers, stores them in its local cache, and applies them through the PAM stack for logins and through the sudo integration for privilege escalation. This means the result of a login attempt depends on what the client currently holds, not only on what the directory contains. Plan your rollout around that fact, because the gap between a change in IdM and the moment a host enforces it is determined by the client.

Several practical consequences follow. A rule change made on an IdM server may not reach a given client until that client's cache refreshes, so a newly denied user may still log in for some time, and a newly granted user may be refused until the refresh happens. Test this on a representative host rather than assuming the change is live everywhere when the command completes. Also note which services each HBAC rule covers, such as sshd, login or sudo-related services. A rule that names only one service does not govern the others, so a host can enforce different outcomes for the same user depending on how they connect.

A host that cannot reach any IdM server is a separate case. Whether it keeps serving decisions from cache, and for how long, depends on SSSD cache and offline settings on that client. Some configurations allow cached credentials and cached rules to continue working during an outage, which protects availability but can keep a revoked user's access alive until the cache expires or the host reconnects. Confirm the cache lifetime, offline behavior and refresh interval for the exact SSSD and FreeIPA versions you run, and do not rely on defaults from memory, since these values have changed across releases and differ between distributions.

Sudo follows the same pattern. Sudo rules are evaluated on the client against the sudo rules SSSD has fetched, so a sudo change is subject to the same refresh timing and the same offline behavior as HBAC. Check that the sudo integration on your target distributions reads from SSSD in the way your design assumes, and confirm which sudo rule attributes are supported by your sudo and SSSD versions before you depend on them. Mismatched versions across hosts are a common source of inconsistent privilege behavior.

For the rollout, record the refresh and offline settings used on each host class, then test three cases: a rule grant taking effect, a rule revocation taking effect, and a login from a host with IdM servers unreachable. Keep the results with your change records. Re-run these checks after SSSD or FreeIPA upgrades, because the timing and cache behavior are the most likely things to change without an obvious error.

Testing an HBAC and sudo policy means proving, host by host, that the rules let the right people in and keep the wrong people out before any production user depends on them. Build a matrix with four combinations: an allowed user on an allowed host, an allowed user on a denied host, a denied user on an allowed host, and a denied user on a denied host. Run each combination separately for every HBAC service the rule names. In a FreeIPA deployment that usually means sshd for SSH, login for console access and sudo for privilege escalation, because an HBAC rule that lists only sshd does not govern console or sudo logins. Record the expected outcome beside each cell before you run it, so a surprising result is visible rather than explained away afterward.

Sudo tests need their own checks. Log in to a test host as the test user and run sudo -l to confirm the command list that SSSD delivers from the sudo rules in IdM. Compare that output with the rule definition, including command lists, run-as users and any options that change behavior. Then confirm that a command outside the list fails for that user. A test that only shows an allowed command works proves less than a test showing a denied command is refused. Run the checks against the client's actual SSSD cache state, since a stale cache can show a rule that the server has already changed or removed.

Checking that a denial is safe matters as much as checking that it happens. Use a dedicated test account for denied-user cases, and confirm it is denied without disturbing local administrator access on the host. The break-glass path, meaning the local or out-of-band access your team uses when IdM or SSSD is unavailable, must still work after every negative test. Verify this on a non-production host first. Then confirm that a rollback works: disable or revert the rule, let SSSD refresh, and check that the previously denied or allowed access returns to its prior state. Ask your team to write down who can perform the rollback and how long a change takes to reach clients, because that answer depends on your SSSD cache settings and should be confirmed in your own environment, not assumed.

Keep a dated record of every run. For each result, note the date, the tester, the rule name and version of the policy, the host name, the exact operating system and the FreeIPA and SSSD versions on that host, and the pass or fail outcome with the command output that supports it. Versions matter because the same rule can behave differently across client releases, and an audit or internal review will ask which configuration was in force on which date. Store the records with your change tickets so the link between a rule change and its test evidence is clear.

Re-run the full matrix after every platform upgrade, every change to HBAC or sudo rules, and every change to host groups or user groups that those rules reference. Upgrades of IdM servers and of SSSD on clients can change how rules are evaluated, so a policy that passed before an upgrade is not proof that it passes after one. Prioritize the denied-user and denied-host cases after upgrades, because a regression there widens access silently. If your team lacks the time or skills to run and document this matrix, ask a partner to include it in the written scope and to show the evidence format before work starts.

Once HBAC and sudo rules are live, the most useful early signal is denied activity. A rule that is too strict shows up first as a denied login or a refused sudo command, so monitoring should start on the day the first host group moves off allow_all. Collect denied logins and failed sudo attempts from every enrolled host into one place, and confirm where your distribution writes them. Authentication denials usually appear in the PAM or secure log, and sudo failures typically go to syslog or the journal, but your own hosts will show the exact locations. Agree with the security team which patterns trigger an alert, which ones go to the platform team as a tuning request, and how long each category of denial is kept.

Membership needs a scheduled review, and the schedule is an organizational decision that should be written down. Over time, HBAC rules and sudo rules drift through group changes: users are added to a group that is nested into a host group, service accounts are created for a new job, or an emergency access group is never removed. At each review, confirm that every HBAC and sudo rule still points to the intended user groups and host groups, that nested groups resolve to the people you expect, and that emergency access remains limited to the hosts it was approved for. Record what changed, who approved it, and what was removed, so the review leaves evidence behind as well as a clean policy.

Back up the domain before each batch of rule changes, using the backup tooling FreeIPA documents, ipa-backup. FreeIPA offers full backups and online data-only backups, so decide which one fits each change and test that the backup completes in your environment. The backup documentation also warns that restoring an outdated backup into an active replica topology can break replication. That warning changes how you plan restores. Before a restore is ever needed, document which server is the restore target, whether replicas must be stopped or removed from the topology first, who authorizes the restore, and how the team will confirm replication afterward. Rehearse that plan on a copy of the domain that is not serving production logins, because the first real restore is the wrong time to learn the sequence.

Re-test access policy after every FreeIPA upgrade and every operating system upgrade on an enrolled host. An OS update can change PAM or SSSD behavior, and a FreeIPA update can change how rules are evaluated or how clients receive them, so a rule that worked last quarter may not behave the same way now. Rerun the test matrix for each affected host group and confirm that expected logins succeed, expected denials still happen, and sudo commands resolve as intended. Release sequencing, replica order, and the broader upgrade process belong to the FreeIPA upgrades and support topic, so this section only covers whether the access policy still does what it was approved to do.

Keep four records current, because each one answers a question that someone will ask during an audit or an incident. The rule inventory lists every HBAC and sudo rule, its purpose, the groups it references, and the hosts it applies to. The test matrix results show which logins and commands were tested, against which hosts, and the outcome of each run. The change log records each rule change, the reason, the approver, and the backup taken before it. The owner for each host group names the person or team accountable for approving changes and answering questions about that group's access. If any of these records are missing, a routine review turns into a reconstruction exercise, so assign someone to maintain them as part of the change process.