On Wed, Nov 11, 2009 at 06:28:59PM -0600, Nicolas Williams wrote: > On Wed, Nov 11, 2009 at 04:06:00PM -0800, Gary Winiger wrote: > > > I think this is > > > sufficient for now and it doesn't preclude adding module options or a > > > krb5.conf stanza (or even user_attr(4) name=value pairs) to control this > > > in the future. > > > > Hopefully pam_eval will be a longer term way of doing this. > > These are the types of configurations one might want: > > - use PKINIT > - use password-based auth > - ask the KDC and evaluate a PAM config corresponding to the pre-auth > required by the KDC > - use pam_user_policy > - ... > > pam_eval() helps with some. In the first two cases module options are > needed. > > What this case does is select between PKINIT and password-based auth in > a context-specific manner.
Correct. > > > I'm happy with the latest spec that has been proposed. > > > > I asked for through today at the meeting. Here's my summary: > > > > 3 In the case of stacking two pam_krb5(5) modules such that > > the first will pass through to pam_authtok_get(5), I'm unclear > > from the pam_sm_authenticate() spec what pam_authtok_get will > > do. Please specify what PAM items are set by the first > > instance so the admin knows what they will get from > > pam_authtok_get. I suspect there are two cases here: > > * PKINIT is not done, or fails; > > * PKINIT succeeds. > > No PAM items are set by pam_krb5's auth module. If PAM_AUTHTOK is not > set then it will try PKINIT, else it will try PA-ENC-TIMESTAMP. That is correct. > > 4 I'm still concerned that pam_sm_acct_mgmt() isn't applied > > when PKINIT is done. Viz with the diff marks removed. > > This: > > > Kerberos V5 Account Management Module > > The Kerberos account management component provides a > > function to perform account management, pam_sm_acct_mgmt(). > > This function checks to see if the pam_krb5 authentication > > module has noted that the user's password has not expired. > >-------------->This does not apply if the module is using PKINIT > >-------------->preauthentication. The following options may be passed in > >-------------->to the Kerberos V5 account management module: > > Does not mean that no account authorization happens. It only means that > when using PKINIT there is no password expiration, for semi-obvious > reasons (a password wasn't used, and there may not be one). If the user's password is expired the KDC will send an error message whether the user tries PKINIT or password preauth. However a password is required to for pam_krb5 to verify so password fall back must be configured if this is a possibility. > > Does pam_sm_authenticate() fail? What the outcome of not > > applying account management? Does it mean accounts cannot be > > expired if PKINIT is used? > > Account management does get applied, but in the PKINIT case there's > nothing to do: in the PA-ENC-TIMESTAMP case the only thing done is to > convert a KDC "key expired" error to PAM_NEW_AUTHTOK_REQD -- there's no > equivalent for PKINIT. > > The KDC "key expired" error to PAM_NEW_AUTHTOK_REQD conversion is the > only account management function that pam_krb5 ever implemented (it also > calls the pam_krb5:pam_sm_authenticate() if pam_krb5_migrate was used, > but that's orthogoanl here, and not really an authorization function). Correct. > > 5 I'm still concerned that pam_sm_chauthtok() isn't applied > > when PKINIT is done. Viz with diff marks removed. > > > > Kerberos V5 Password Management Module > > The Kerberos V5 password management component provides a > > function to change passwords, pam_sm_chauthtok(), in the > > Key Distribution Center (KDC) database. This does not > > apply if the module is using PKINIT preauthentication. > > The following flags may be passed to pam_sm_chauthtok(3PAM): > > > > What does this mean to the example PAM password stack and kpasswd? > > I think the above is wrong. That is, if some PAM module causes > pam_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD and/or the app > subsequently calls pam_chauthtok(), pam_krb5 will change a user's > password. But this may well fail: the KDC may not want to allow a > PKINIT user to change/set a password since the user may be expected to > use PKINIT. It may be good to make pam_krb5:pam_sm_chauthtok() return > PAM_IGNORE if a) PKINIT was used and b) the KDC rejects the password > change. (Will, I recommend making that change.) I've made the modification such that if the pam_sm_authenticate in pam_krb5 did not use a password as is the case with PKINIT then pam_sm_chauthtok() will return PAM_IGNORE if: - the new passwd is NULL - the old passwd is NULL - verification of the old passwd fails. If none of the above is true then pam_krb tries to change the password and will return an error if that fails. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA
