Nice explanation of how PAM *should* work, with Kerberos and AFS.
You sited the patch I sent to OpenSSH. There where two. The have sshd set the KRB5CCNAME into the pam_envlist so a pam_open_session routine can use this to get an AFS token. Usefull if sshd did the Kerberos authentication, or gssapi received delegated credentials. Bug #922 has been fixed, and #918 looks like it will also be accepted.
Sergio Gelato wrote:
* Maurizio Santini [2004-09-15 12:46:54 -0300]:
I've installed kerberos and got it work (I can get a ticket using kinit or login from a terminal) but the problem is the AFS token that doesn't get assigned.
Did you install MIT Kerberos or Heimdal?
Heimdal kinit has afslog support built-in (if you compiled it with AFS support; check your config.log). MIT Kerberos may still require you to run aklog as a separate step. (I'm not sure: I use Heimdal. Except on Mac OS X, where one can install an aklog.loginLogout plugin to acquire an AFS token in a way that's transparent for the user.)
In any case, your main concern seems to be PAM, and there the usual pattern
is:
(1) the auth stack gets a TGT from the password you provided;
(2) the account stack checks that the principal of your TGT is
authorised for the account you are trying to log into;
(3) pam_setcred() stores the TGT in a credentials cache (often a file in /tmp) owned by that account;
(4) the session stack gets an AFS service ticket from the TGT it
finds in the credentials cache, converts/stuffs it into a token and
passes that to the kernel for use on your [PAG's] behalf.
Steps (1) through (3) are normally done with a pam_krb5 module. My current favourite is at http://sourceforge.net/projects/pam-krb5/ (go for the 2003-05-31 snapshot, "1.3-rc8").
For step (4), you can use the pam_krb5afs module from the same package,
*if you link it with Heimdal libraries*. (Note that you can link the
PAM module against Heimdal and still use MIT Kerberos for other purposes
on the same system. There are only a few minor caveats in doing so.)
Otherwise, there is also a pam_openafs_session module that I believe
calls aklog to do the TGT->token conversion. Either approach should work.
I've read about the afs to kerberos migration kit and I wonder if I have to apply it to be able to use aklog and alike or if it's enough modifying /etc/pam.d/login file.
I don't think you need to patch any Kerberos source code (either MIT or
Heimdal) any more. It's certainly a good idea to install aklog (and/or Heimdal's afslog). Of course you'll need to configure the PAM stack for
the services you want to Kerberize (presumably sshd as well as login).
I've found it useful to turn on the debug option on pam_krb5afs in order to see the details of what was going on. It can be turned off once all the problems are sorted out.
About OpenSSH, one known issue is that the PAM session module needs to know where to find the credentials cache. Douglas Engert has published a patch to improve the chances of the KRB5CCNAME environment variable being visible to the PAM session stack. Try it out: you may need it. In any case, one of the things to check if you can't get AFS tokens through PAM is whether the session module is seeing the correct value of that environment variable.
Note that aklog supports a -d command-line option for debugging. _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
--
Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
