[OpenAFS] How to replace pam_krb5 on RHEL 8 systems

[Dave Botsch]

I think all we had to do, actually, was set appropriate options for
GSSAPI in sshd_config ... and make sure it was still using PAM for the
account and session pieces.


We did not have to use any stashcred or chuse stuff... our session stack
looks like:

session     optional                                     pam_keyinit.so revoke
session     required                                     pam_limits.so
-session    optional                                     pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     optional pam_afs_session.so program=/opt/local/bin/aklog
session     required                                     pam_unix.so
session     optional                                     pam_sss.so


(We had to recompile aklog to deal with krb5-1.18 breaking unique
kerberos caches, hence pointing to the other external aklog program,
which does, btw, work with the standard pam_afs_session)

I believe all we did was to add the pam_afs_session line to the session
stack.


Thanks.

On Mon, Jul 11, 2022 at 10:14:39AM -0400, Ken Hornstein wrote:
> >(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
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

-- 
********************************
David William Botsch
Programmer/Analyst
@CornellCNF
botsch@cnf.cornell.edu
********************************