Douglas E. Engert schrieb: >>>>> Note that if pam_krb is stacked below pam_authtok_get it would >>>>> function >>>>> as it currently does which is to get the user's Kerberos credential >>>>> using their long term Kerberos password. >>>> That seems reasonable. >>>>
FWIW I feel uncomfortable with the idea that presence or absence of a PAM_AUTHTOK will change the behavior of pam_krb5 substantially. So I'd prefer a 'preauth' or 'pkinit' option here. >>>> I want to see an updated pam_krb5(5) man page explaining how to use >>>> PKINIT and including the example PAM stacks for use of PKINIT. >>> I'll work on that and send it as a reply. >> >> While working out the various permutations of PAM auth stacks I've >> discovered that my fasttrack was not complete in regards to new >> interfaces. In order for the fall back to work properly from PKINIT to >> password based preauth, pam_krb5 will need a user configurable option to >> tell the first instance of pam_krb5 (doing PKINIT preauth) whether there >> will be a second instance of pam_krb5 stacked below pam_authtok_get that >> will try password preauth if PKINIT preauth fails. The idea is that if >> the first instance of pam_krb5 (PKINIT) fails it will return PAM_IGNORE >> if the fall back option is set to true (it would be false by default). >> Otherwise the first instance of pam_krb5 (PKINIT) would return failure. >> To me that sounds like something that should not require a module option. Stack flow is controlled by the control flag part of the pam.conf entry. So if preauth failure is not fatal, it should simply be configured as 'optional' or 'sufficient'. >> Example 5: >> >> Authenticate Users Through Kerberos PKINIT, fall back to >> password based krb auth if PKINIT fails. >> >> The following example allows users to acquire a Kerberos credential >> using PKINIT preauth or using password based preauth if PKINIT >> fails. If PKINIT succeeds the user will not be prompted for their >> password. Note, if pam_krb5 PKINIT succeeds, the second instance of >> pam_krb5 will not try password preauth and will return success. >> If PKINIT fails the user will be prompted for their Kerberos >> password. >> >> dtlogin auth required pam_unix_cred.so.1 >> dtlogin auth sufficient pam_krb5.so.1 passwd_fallback >> dtlogin auth requisite pam_authtok_get.so.1 >> dtlogin auth required pam_krb5.so.1 >> What does your flag change here? Whether the first instance returns PAM_IGNORE or failure makes no difference. >> Example 6: >> >> Require users to authenticate either through Kerberos PKINIT or fall >> back to password based krb auth if PKINIT fails and authenticate >> with other required PAM modules. >> >> The following example allows users to acquire a Kerberos credential >> using PKINIT preauth or using password based preauth if PKINIT >> fails. Note, if pam_krb5 PKINIT succeeds, the second instance of >> pam_krb5 will not try password preauth and will just return success. >> If pam_krb5 PKINIT fails the second instance of pam_krb5 will try >> password based preauth and return success or failure. >> >> dtlogin auth required pam_unix_cred.so.1 >> dtlogin auth required pam_krb5.so.1 passwd_fallback >> dtlogin auth requisite pam_authtok_get.so.1 >> dtlogin auth required pam_krb5.so.1 >> dtlogin auth required pam_dhkeys.so.1 >> dtlogin auth required pam_unix_auth.so.1 >> What do you gain here vs. making the first pam_krb5.so.1 instance optional? Do you need failure modes where the first instance fails so fatally that it prevents login (after letting the subsequent password login proceed) as opposed to lesser failures that allow the fallback? Even for this you don't really need that option. Or do you need to support cases where you first do PKINIT authentication and later password-based authention on top of that? In this case, I'd expect to see an option on the second instance of the module. - J?rg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth at sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/
