Simon Josefsson <[EMAIL PROTECTED]> writes: > Ah, right. I recalled some GSS-API extensions for initial acquisition, > but I guess they were never implemented widely. It might have been a > better approach, though. But maybe there are other things that pam_krb5 > do which isn't possible to do via GSS-API?
Basically, what pam_krb5 has to do is: * Acquire initial credentials. This is normally done using a password but may instead be done using a smartcard and PKINIT. This requires dealing with a Kerberos prompting function and passing the prompts back to the user, since the Kerberos library may be doing other things at the same time (like forcing the user to change an expired password). * Verify that the initial credentials are valid by obtaining a service ticket for a local key and then checking that service ticket against the local key. This prevents KDC spoofing. * Store the initial credentials into a ticket cache and chown that ticket cache to the user. (Due to the way that OpenSSH works, it also has to be able to store them in a temporary file and read them back out later.) * Verify that the user is permitted to log on to this account by calling krb5_kuserok, which checks the Kerberos principal against the local account name, a .k5login if any, and against any principal to local account name mappings as configured in krb5.conf. * Obtain password changing credentials (different than the TGT since password changing credentials are marked DISALLOW_TGT_BASED). * Change the user's password. As near as I can tell, GSS-API doesn't provide facilities to do any of those operations. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ Help-gss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gss
