Greg Hudson <[email protected]> writes: > In the prompter, you can call krb5_get_prompt_types() to get an array of > types for each prompt. (It may return NULL in some cases.) If the > prompt type is KRB5_PROMPT_TYPE_PASSWORD, then you know you're being > asked for the password.
This is guaranteed to *not* be set for such things as a PKINIT PIN or an OTP code? > This should allow you to (1) disable password prompting when use_pkinit > is set, and (2) store the password when try_pkinit is set and the > library falls back. Is this sufficient? Not completely, although it certainly gets me closer. It doesn't allow disabling any other authentication method (such as OTP), which is what use_pkinit is defined to do. > More generally, I'm not sure the pam_krb5 module ought to be driving the > decision to use PKINIT. For Heimdal it may be necessary to make PKINIT > go at all, but MIT krb5 tries to control preauthentication from within > libkrb5 and the KDC, so that new mechanisms can be added via loadable > modules. I certainly understand why that approach is more attractive. However, I think there are two problems with that general philosophy when it comes to PAM configuration: 1. There's definitely a need to configure which preauth mechanisms you want to use at the granularity of the PAM configuration. For example, console logins may require a hardware smart card, but ssh authentications clearly can't (but may result in fewer privileges). You don't necessarily want to use the same authentication mechanisms for GDM and IMAP. And so forth. krb5.conf is generally system-global. 2. PAM needs to know when the account password is being entered so that it can support the normal semantics of the PAM stack, for good or for ill. > That said, we do have this in 1.11: > http://web.mit.edu/kerberos/krb5-latest/doc/appdev/init_creds.html#responder-callback > (See also http://k5wiki.kerberos.org/wiki/Projects/Responder) However, > it won't be integrated properly with PKINIT until 1.12. At least at first glance, I'm not seeing how this is related to this particular problem of choosing preauth types based on PAM context, although it certainly seems like a nicer prompter interface. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
