Central sudo rules are where identity management becomes concrete in Linux operations. Creating users centrally is not enough; the decisive question is who may run which administrative command on which host.

This article shows FreeIPA sudo rules from a real two-node lab: one FreeIPA server, one enrolled Linux client, one user group, one host group, one command group and multiple negative checks.

Target state: not generic sudo, but one specific command

In the lab, members of ops-sudo-status were allowed to run exactly /usr/bin/systemctl status sshd via sudo on client01.idm.lab.test. Restarting the service was not allowed. A second user outside the group could not run even the allowed status command.

That is the difference between a broad admin group and verifiable delegation: the rule describes users, target hosts, allowed commands and optionally RunAs context separately.

HBAC and sudo are different layers

HBAC answers whether a user may use a service on a host at all, for example SSH on a specific system. Sudo answers the next question: which privileged command this already logged-in user may run.

Both layers should be tested deliberately in production environments. A user may reach a host through HBAC and still have no sudo right. Conversely, a sudo rule does not help if the user cannot access the host or relevant service.

Rule structure

The tested structure used a FreeIPA user group for allowed operators, a host group for target systems, a sudo command for /usr/bin/systemctl status sshd, a sudo command group and a sudo rule connecting those building blocks.

As CLI logic, this maps to ipa group-add, ipa hostgroup-add, ipa sudocmd-add, ipa sudocmdgroup-add, ipa sudorule-add and then linking the user group, host group and allowed command group.

Client prerequisites

On the client, sudo and SSSD must work together. In the lab, services = nss, pam, ssh, sudo in sssd.conf and sudoers: files sss in nsswitch.conf were the important checkpoints.

If a rule looks correct in FreeIPA but does not apply on the client yet, that does not disprove the rule. The SSSD sudo provider, cache and refresh path must be inspected separately.

Positive check

The user opsallowed was a member of the allowed group. The SSH test on client01 showed that id resolved the central user correctly, sudo /usr/bin/systemctl status sshd returned the running sshd.service status and the return code was 0.

This proved not only the visible Web UI rule, but the actual client-side execution path.

Negative checks

The first negative check used a different command with the same user: opsallowed was not allowed to run sudo /usr/bin/systemctl restart sshd. The return code was 1.

The second negative check used another user: opsdenied was not part of the sudo group and could not run even the otherwise allowed status command. The return code was 1 as well.

Pitfall: SSSD sudo refresh

One real lab finding mattered: the first client-side check still reported that opsallowed was not allowed to run sudo on client01 even though the FreeIPA objects had already been created.

Only after targeted diagnosis, cache refresh and an SSSD restart did the rule resolve correctly. For operational guides this is central: rule creation and client-side visibility must be verified separately.

Technical acceptance

PASS: FreeIPA server installed, client enrolled, users and groups centrally visible, host group present, sudo command and command group present, positive sudo execution successful, negative command test successful, negative user test successful.

PARTIAL: The cache and refresh path must be observed per distribution and SSSD version in the target environment. This article describes the lab behavior; it does not replace customer-specific SSSD policy.

Practical checklist

Before release, administrators should check: user resolution with id, group membership, host group membership, sudoers: files sss, SSSD services including sudo, ipa sudorule-show, sudo -l as target user, allowed command, disallowed command and unauthorized user.

Conclusion

FreeIPA sudo rules are valuable when they are not used as a replacement for local wildcard sudo, but as centrally maintained, auditable delegation. The real acceptance happens on the client: positive and negative tests make the rule production-relevant.