Russ Allbery <[EMAIL PROTECTED]> writes: > 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.
Thanks for the summary! Sounds like pam_gssapi is not a feasible idea then. /Simon _______________________________________________ Help-gss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gss
