Host-based access control (HBAC)

Requires the hbac module. An HBAC rule answers one question: user U logging in to host H through service S, allowed or not. The client's sssd fetches the rules from IPA and evaluates them locally on every PAM authentication, so a rule change reaches clients after their cache refreshes (minutes by default; sss_cache -E at once).

Four dimensions

HBAC has allow rules only, no deny rules. Evaluation: walk every enabled rule; if any one matches on all three dimensions, allow; if none does, deny. Rules have no priority and there is no "first match wins".

To deny someone, make sure no rule covers them: remove them from the group or narrow the rule.

allow_all

The installer ships allow_all: anyone, any host, any service. While it is enabled every other rule is moot. The production switch-over:

1. Write the real rules first (ops group to web hosts via sshd, DBAs to database hosts…).
2. Make sure admins has a rule to every host, or administrators lock themselves out once allow_all goes.
3. Disable allow_all (keep it, do not delete it; it is the emergency switch).
4. Verify a login on one affected host.

allow_systemd-user is also shipped: it lets the systemd-user service open user sessions for everyone (loginctl enable-linger and user-level systemd units depend on it). Disable it and systemd --user fails after login.

HBAC services and service groups

A service name is the client's PAM service name (the file name under /etc/pam.d/): sshd, login, sudo, gdm, crond, ftp… 16 are shipped; add one for an in-house program that authenticates through PAM, using its PAM service name. Service groups bundle a family (e.g. Sudo holds sudo and sudo-i) so rules reference the group.

sudo appearing as an HBAC service means "may this user invoke sudo at all" is HBAC's decision, while "which commands" is decided by Sudo rules. Both must allow.

Simulating a login

From 1.0.3 the HBAC test page is available: enter user, target host and service, click "Run test"; the verdict is shown on top and the table lists whether each rule matched. CLI equivalent:

ipa hbactest --user=zhangwei --host=web01.linux.ipa.test --service=sshd
ipa hbactest --user=jdoe@ad.ipa.test --host=web01.linux.ipa.test --service=sshd --enabled

The output lists every rule with matched / not matched and the verdict. --enabled considers enabled rules only; --rules= tests one rule. AD users are given as user@ad.domain.

Boundaries

• HBAC decides whether a login happens, not what the session may do; file permissions and sudo have their own mechanisms.
• Usual reasons a rule "does not work": client sssd cache; allow_all still enabled; access_provider in the client's sssd.conf is not ipa.
• AD users must be brought into an IPA group through an External group before a rule can reference them.