Re: How to replace pam_krb5 on RHEL 8 systems
Ken Hornstein <[email protected]> Mon, 11 Jul 2022 10:14:39 -0400
| Newsgroups | gmane.comp.file-systems.openafs.general |
|---|---|
| Message-ID | <[email protected]> |
>(of course, authenticating with kerberos tickets instead of passwords is >a tad more complicated with ssshd doing stuff, too). Yeah, tell me about it. This is the PAM stack we ended up with: session required pam_stashcred.so save session required pam_chuser.so r2user session required pam_afs_session.so notokens session required pam_chuser.so r2e session required pam_chuser.so e2user session required pam_stashcred.so restore force-keyring session required pam_chuser.so e2r session required pam_afs_session.so nopag stashcred and chuser are PAM modules I wrote. For us the use of keyring credential caches is non-negotiable, but the owner of the session keyring ends up being wrong without some help. And sadly the owner of the AFS PAG is based on the real userid, but the Kerberos credential cache owner is based on the effective userid. So we use stashcred to save the Kerberos credential cache internally (received via credential forwarding), set the real userid to the value of the authenticated userid using chuser, create the PAG with pam_afs_session so it is owned by the authenticated user, switch things so now the effective userid is the authenticated userid, restore the Kerberos credential cache (and force it to be keyring and set KRB5CCNAME appropriately), switch everything back so we're running as root again, and THEN get an AFS token. It's a mess, but we get keyring credential caches and PAGs and it all works. --Ken