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. > > 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. > 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). > 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). > 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.) Nico --
