Overview

Part 6 of the Identity series shows FreeIPA sudo rules in practice on Fedora 44. The goal is auditable delegation: an operator may inspect the sshd status on a defined client, but cannot restart the service, and users outside the group do not receive that privilege.

Important: HBAC decides whether a user may access a host and service at all. Sudo then decides which privileged commands are allowed on that host. They belong together, but they are not the same control.

https://ipa01.example.test/ipa/ui/

FreeIPA Web UI after login in the Fedora 44 sudo lab. Screenshot from the isolated FreeIPA C4 sudo lab on Fedora 44.

Lab Setup

bash
Server:        ipa01.example.test
Client:        client01.example.test
Domain:        example.test
Realm:         EXAMPLE.TEST
Distribution:  Fedora Linux 44
Kernel:        6.19.14-300.fc44.x86_64
SELinux:       Enforcing

Object Model

The lab does not use local sudoers files for the functional permission. The rule is modeled centrally in FreeIPA: user group, host group, sudo command, sudo command group and sudo rule.

bash
ipa group-add ops-sudo-status \
  --desc='Operators allowed to inspect selected service status'
ipa group-add-member ops-sudo-status --users=opsallowed


ipa hostgroup-add linux-clients \
  --desc='Linux clients using central sudo policy'
ipa hostgroup-add-member linux-clients --hosts=client01.example.test


ipa sudocmd-add '/usr/bin/systemctl status sshd'
ipa sudocmdgroup-add service-status-commands \
  --desc='Read-only service status commands'
ipa sudocmdgroup-add-member service-status-commands \
  --sudocmds='/usr/bin/systemctl status sshd'


ipa sudorule-add allow-service-status \
  --desc='Allow status inspection of sshd on Linux clients'
ipa sudorule-add-user allow-service-status --groups=ops-sudo-status
ipa sudorule-add-host allow-service-status --hostgroups=linux-clients
ipa sudorule-add-allow-command allow-service-status \
  --sudocmdgroups=service-status-commands
ipa sudorule-add-runasuser allow-service-status --users=root
ipa sudorule-add-option allow-service-status --sudooption='!authenticate'
https://ipa01.example.test/ipa/ui/

FreeIPA sudo rule allow-service-status with user group, host group, command group and RunAs root. Screenshot from the isolated FreeIPA C4 sudo lab on Fedora 44.

https://ipa01.example.test/ipa/ui/

FreeIPA group ops-sudo-status with the allowed operator. Screenshot from the isolated FreeIPA C4 sudo lab on Fedora 44.

https://ipa01.example.test/ipa/ui/

FreeIPA host group linux-clients with client01.example.test. Screenshot from the isolated FreeIPA C4 sudo lab on Fedora 44.

https://ipa01.example.test/ipa/ui/

FreeIPA sudo command group service-status-commands. Screenshot from the isolated FreeIPA C4 sudo lab on Fedora 44.

Client Integration Through SSSD

For sudo to see centralized rules, the client must query sudo rules through SSSD. In the lab, `sudoers: files sss`, the SSSD sudo responder and a cache refresh were part of the acceptance check.

bash
# /etc/nsswitch.conf
sudoers:    files sss


# /etc/sssd/sssd.conf
[sssd]
services = nss, pam, ssh, sudo


[sudo]


systemctl restart sssd
sss_cache -E
User opsallowed may run the following commands on client01:
    (root) NOPASSWD: /usr/bin/systemctl status sshd


User opsdenied is not allowed to run sudo on client01.

Positive Test

The opsallowed user is a member of ops-sudo-status. `sudo -l` shows only the allowed command. `SYSTEMD_PAGER=cat` makes the systemd status output non-interactive and scriptable.

uid=289600003(opsallowed) gid=289600003(opsallowed) groups=289600003(opsallowed),289600005(ops-sudo-status)


User opsallowed may run the following commands on client01:
    (root) NOPASSWD: /usr/bin/systemctl status sshd


SYSTEMD_PAGER=cat sudo -n /usr/bin/systemctl status sshd
Active: active (running)
rc=0

Negative Tests

opsallowed may read the service status but may not execute `systemctl restart sshd`. opsdenied resolves as an IPA user, but receives no sudo grant from the FreeIPA rule.

sudo -n /usr/bin/systemctl restart sshd
sudo: a password is required
restart_rc=1


uid=289600004(opsdenied) gid=289600004(opsdenied) groups=289600004(opsdenied)
SYSTEMD_PAGER=cat sudo -n /usr/bin/systemctl status sshd
sudo: a password is required
denied_user_rc=1

Result Check

Platform

Check
Server and client on Fedora Linux 44
Result
PASS

FreeIPA

Check
sudo rule allow-service-status exists
Result
PASS

Scope

Check
user group ops-sudo-status linked
Result
PASS

Scope

Check
host group linux-clients linked
Result
PASS

Scope

Check
only /usr/bin/systemctl status sshd allowed
Result
PASS

SSSD

Check
sudoers: files sss and sudo responder active
Result
PASS

Allow

Check
opsallowed may read sshd status as root
Result
PASS

Deny

Check
opsallowed may not restart sshd
Result
PASS

Deny

Check
opsdenied receives no sudo grant
Result
PASS

Practice Notes

  • `!authenticate` results in NOPASSWD behavior and should only be used where operational benefit and risk are documented.

  • After rule changes, SSSD cache and sudo refresh timing can become visible. For tests, `sss_cache -E` plus an SSSD restart is useful; in production, cache behavior should be planned deliberately.

  • For production roles, keep commands narrow and avoid broad root privileges through generic groups.