Will Fiveash wrote: > On Thu, Oct 22, 2009 at 04:55:17PM -0500, Will Fiveash wrote: >> On Thu, Oct 22, 2009 at 05:40:47PM +0100, Darren Moffat wrote: >>> Wyllys Ingersoll wrote: >>>> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >>>> This information is Copyright 2009 Sun Microsystems >>>> 1. Introduction >>>> 1.1. Project/Component Working Name: >>>> pam_krb5 PKINIT support >>>> 1.2. Name of Document Author/Supplier: >>>> Author: Will Fiveash >>>> 1.3 Date of This Document: >>>> 22 October, 2009 > >>>> 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. >>> >>> 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. > > I believe there are two options in regards to the implementation of this > "fall back" config parameter. One is a new pam_krb5 argument set in > pam.conf like: > > 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 > > The other implementation option is to add support for a pam_krb5 stanza > in the krb5.conf [appdefaults] section which would be a bit more work. > Also note that currently there are no support pam_krb5 config parameters > in krb5.conf. Thoughts as to which implementation of password fall back > is preferable? > > Here are the example auth stacks involving pam_krb5 doing PKINIT (these > examples assume use of a passwd_fallback argument to pam_krb5): >
You also need an example of a system that does not not have PKINIT at all and the user uses a password. Is your pam_krb5 using the fact that the PAM_AUTHTOK is null, because pam_authtok_get has not been called to make a decision about PKINIT? This will be confusing for admins, as this is the first time I can recall of a module being used twice in the same stack. Your example 3 to an admin who does not have pkinit looks like a mistake with two likes out of order. If you still want to have it in the stack twice, you may want to use an explicit try_pkinit parameter on the first entry to indicate it is for pkinit. This is less ambiguous for the admin, and would mean to add pkinit to an existing stack would be to drop in a pam_krb5 try_pkinit before the pam_authtok_get. Your example 3 to an admin who does not have pkinit looks like a mistake with two lines out of order. Example 4 and 6 look like they will do the same thing too. > Example 1: Authenticate Users Through Kerberos PKINIT as First Choice > > The following is an excerpt of a sample pam.conf configuration file > that authenticates users through the Kerberos authentication > service and authenticates through the Unix login only if the > Kerberos authentication (using PKINIT) fails. This arrangement is > helpful when a majority of the users are networked by means of > Kerberos and when there are only a few non-Kerberos type user > accounts, such as root. The service illustrated below is for > dtlogin. Note, the user is prompted once for the PIN by pam_krb5. > > dtlogin auth required pam_unix_cred.so.1 > dtlogin auth sufficient pam_krb5.so.1 > dtlogin auth requisite pam_authtok_get.so.1 > dtlogin auth required pam_dhkeys.so.1 > dtlogin auth required pam_unix_auth.so.1 > > Example 2: > > Authenticate Users Through Kerberos PKINIT Only > > The following example allows authentication only to users that have > Kerberos-based accounts requiring PKINIT preauth. > > dtlogin auth required pam_unix_cred.so.1 > dtlogin auth binding pam_krb5.so.1 > > Example 3: > > Authenticate Users Through Kerberos PKINIT Optionally > > The following example allows users to acquire a Kerberos credential > using PKINIT preauth if they have a Kerberos account. Whether > pam_krb5 succeeds or fails the user must provide their Unix password > in order to login. > > dtlogin auth required pam_unix_cred.so.1 > dtlogin auth optional pam_krb5.so.1 > dtlogin auth requisite pam_authtok_get.so.1 > dtlogin auth required pam_unix_auth.so.1 > > Example 4: > > Authenticate Users Through Kerberos PKINIT as a requirement. > > The following example allows users to login if pam_krb5 is able to > acquire a Kerberos credential via PKINT preauth and in addition must > provide their Unix password to pam_unix_auth. > > dtlogin auth required pam_unix_cred.so.1 > dtlogin auth required pam_krb5.so.1 > dtlogin auth requisite pam_authtok_get.so.1 > dtlogin auth required pam_unix_auth.so.1 > > 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 > > 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. Or should it return ignore? Sounds safer, as if the admin forgets to add the second pam_krb5 or pam_unix_auth, you just let him login. > If > pam_krb5 PKINIT fails the second instance of pam_krb5 will try > password based preauth and return success or failure. But won't pam_authtok_get still prompt the user for a password? If the pkinit works, this looks a lot like example 4. > > 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 Should the above be sufficient? > dtlogin auth required pam_dhkeys.so.1 > dtlogin auth required pam_unix_auth.so.1 > -- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
