Use of IPA to control su access

Rocky Linux Help & Support
1

I thought I’d take a look at ipa-server and ipa-client. Setup, so far, has been pretty simple. On a Rocky8 machine I installed the server and configured it. Then on a couple of Rocky8 and CentOS7 clients I connected to the domain.

So far, so good. I can create users, hostgroups, hbac rules etc. So my “test1” user can ssh into machines in the “foo” hostgroup, but no where else. It can also run sudo cat and no other sudo command.

The problem I’m running into is in managing su access.

The test command says it shouldn’t work:

ipa hbactest --user=admin --host=rh-client1.spuddy.org --service=su
---------------------
Access granted: False
---------------------
  Not matched rules: allow_all_users_services
  Not matched rules: allow_ssh
  Not matched rules: allow_su
  Not matched rules: allow_sudo
  Not matched rules: allow_systemd-user

However…

[admin@rh-client1 ~]$ id
uid=1722600000(admin) gid=1722600000(admins) groups=1722600000(admins),12345(flibble)
[admin@rh-client1 ~]$ su
Password: 
[root@rh-client1 admin]#

The PAM configuration looks sane:

 cat /etc/pam.d/su
#%PAM-1.0
auth            required        pam_env.so
auth            sufficient      pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth           sufficient      pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth           required        pam_wheel.so use_uid
auth            substack        system-auth
auth            include         postlogin
account         sufficient      pam_succeed_if.so uid = 0 use_uid quiet
account         include         system-auth
password        include         system-auth
session         include         system-auth
session         include         postlogin
session         optional        pam_xauth.so

I’m not sure how to debug this; obviously I can’t strace because that blocks setuid from running, so it always fails. I can’t even tell if it’s PAM or sssd that’s not responding correctly. Or if I’ve just messed up configuration :wink:

Any hints welcome!

2

Did you leave the allow_all rule enabled? If you disabled it and it’s still working, have you cleared the sssd cache?

3

Good questions; I should have added that detail to my question.

allow_all is disabled (as demonstrated by it not showing in the hbactest command).

sss_cache -E has been run multiple times. I had previously noticed this doesn’t impact sudo rules; that seems to have a 15 minute refresh no matter what, but this config is now hours old. It’s now the first thing I run when something doesn’t look right :slight_smile: