基于主机的访问控制(HBAC)
需要 hbac 模块。谁能从哪登录到哪台主机的哪个服务;规则的四个维度、allow_all 的处理、判定顺序,以及用 ipa hbactest 模拟登录。
本页说明 Policy 下的 Host-based access control 页面组,需要 hbac 模块。HBAC 规则回答一个问题:用户 U 通过服务 S 登录主机 H,是否放行。客户端 sssd 在每次 PAM 认证时向 IPA 获取规则并本地判定,规则修改后客户端要等缓存刷新(默认几分钟,sss_cache -E 立即生效)。

规则的四个维度

| 区块 | 内容 | Any 的含义 |
|---|---|---|
| Who the rule applies to | 用户、用户组 | 允许任何人 |
| Gives access to | 主机、主机组 | 任意主机 |
| Via the following services | HBAC 服务、服务组 | 任意服务 |
| Enabled、Disabled | 规则状态 | 禁用的规则不参与判定 |
HBAC 只有允许规则,没有拒绝规则。判定时遍历所有启用的规则,任一条在三个维度上都命中即放行,一条都不命中则拒绝。规则之间没有优先级,不存在先匹配先生效。
要拒绝某个用户,只能让没有任何规则覆盖到该用户:从组里移出,或收窄规则。
allow_all
安装后自带 allow_all:任何人、任何主机、任何服务。它启用时,其他规则等于不存在。生产环境的切换顺序:
- 写好业务规则(运维组到 Web 主机的 sshd、DBA 到数据库主机等)。
- 确认
admins组到所有主机有一条规则。否则禁用allow_all后管理员自己也无法登录。 - 禁用
allow_all。不删除,保留作应急开关。 - 在一台受影响的主机上验证登录。
allow_systemd-user 同样自带:允许 systemd-user 服务为所有人打开用户会话,loginctl enable-linger 和用户级 systemd 单元依赖它。禁用后用户登录时 systemd --user 启动失败。
HBAC 服务与服务组

服务名对应客户端上的 PAM 服务名(/etc/pam.d/ 里的文件名):sshd、login、sudo、gdm、crond、ftp 等。自带 16 个;自研程序通过 PAM 认证时按其 PAM 服务名添加一条。服务组把一类服务打包(如 Sudo 组含 sudo 与 sudo-i),规则引用组。
sudo 作为 HBAC 服务出现,表示能否执行 sudo 这个动作也受 HBAC 控制;sudo 能执行哪些命令由 Sudo 规则决定。两者都要放行。
模拟登录
1.0.3 起 HBAC Test 页可用:填写用户、目标主机、服务,选择 Run test,顶部给出允许或拒绝,下表列出每条规则是否命中。

命令行等价:
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输出列出每条规则命中与否和最终结论。--enabled 只看启用的规则;--rules= 单测某一条。AD 用户写作 user@ad.domain。
边界
| 事项 | 说明 |
|---|---|
| 控制范围 | HBAC 决定能否登录,不决定登录后的权限。文件权限和 sudo 各有各的机制 |
| 规则不生效 | 常见原因:客户端 sssd 缓存;allow_all 仍启用;客户端 sssd.conf 里 access_provider 不是 ipa |
| AD 用户 | 需要通过 External 组进入 IPA 组,规则才能引用 |