Folks I am in the process of working through this but I thought I would
throw it out just in case there were other thoughts or I was chasing
down the wrong lane.
We have a requirement for sudo to use a different password than the user
password where I work. Now in RHEL 7 we implemented this requirement by
modifying the pam stack for sudo to use the pam_krb5 module like the
following:
auth required pam_env.so
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_krb5.so try_first_pass no_user_check
auth required pam_deny.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_krb5.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_krb5.so try_first_pass use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
Now pam_krb5 is configured to auth against a username/sudo principal in
/etc/krb5.conf like the following (the mappings is the important part):
[appdefaults]
pam = {
debug = false
forwardable = true
renew_lifetime = 24h
ticket_lifetime = 24h
krb4_convert = false
mappings = ^(.*)$ $1/sudo
}
pam_krb5 has for better or worse gone the way of the dodo in RHEL 8 and
so I am looking to implement something similar using sssd. Our systems
are already joined to an AD, and it appears to me for the moment that
the 'application domain' using pam_sss might be the right approach here.
I understand that it is best tested with LDAP, but well, here we go. So
thus far I have:
[application/appdom]
inherit_from =
ad.example.com
and the /etc/pam.d/sudo has the following inserted:
auth sufficient pam_sss.so forward_pass domains=appdom
Great it seems to work. Now I need to remap the name to username/sudo
and auth it against kerb. I don't even know if this is possible at this
point, but again I thought I would write it up and ask just in case
someone knew.
Thanks,
-Erinn