On Thu, Nov 05, 2009 at 03:37:00PM -0600, Douglas E. Engert wrote:
>
>
> 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.
That is already in the current pam_krb5.5 man page but I'll provide it
for convenience:
dtlogin auth requisite pam_authtok_get.so.1
dtlogin auth required pam_unix_cred.so.1
dtlogin auth required pam_krb5.so.1
dtlogin auth required pam_unix_auth.so.1
> 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?
Yes.
> 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.
Let's see if any PSARC members have an issue with this. Remember that
pam_krb5 is relying on pam_authtok_get to prompt for a password and
unless that implementation is changed it means that pam_krb5 must be
stacked before and after pam_authtok_get in order to try PKINIT and fall
back to password based preauth if PKINIT fails.
> 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.
I am trying to avoid unnecessary arguments/options. If the PSARC
reviewers feel your point above has merit I will add a do_pkinit
argument (try_pkinit makes me think pam_krb5 will fall back to password
preauth which isn't the case).
> Your example 3 to an admin who does not have pkinit looks like a mistake
> with two lines out of order.
Hopefully they will read the docs. If that is not enough then maybe the
do_pkinit arg is necessary.
> Example 4 and 6 look like they will do the same thing too.
No, example 4 will not fall back to trying password based krb preauth
while example 6 does.
> > 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.
Good point and I've changed the code so the second instance of pam_krb5
will return PAM_IGNORE if the first instance of pam_krb5 returned
PAM_SUCCESS.
> > 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.
Example 6 may prompt for a PIN if the pkinit code finds a suitable token
and will always prompt for a password since pam_authtok_get is in there
and the first instance of pam_krb5 doing pkinti is required. If it were
sufficient and PKINIT succeeded the rest of the would be skipped.
> > 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?
No because pam_unix_auth is also required.
> > dtlogin auth required pam_dhkeys.so.1
> > dtlogin auth required pam_unix_auth.so.1
--
Will Fiveash
Sun Microsystems Inc.
http://opensolaris.org/os/project/kerberos/
Sent from mutt, a sweet ASCII MUA
