On Fri, Oct 7, 2011 at 10:20 AM, Luke Howard <[log in to unmask]> wrote:
>> So, I just whipped up a pam_gss. It actually uses SPNEGO so it will work with any mechanism. I'll clean up and publish the code tomorrow.
>
> Very rough and untested:
>
> http://www.padl.com/download/pam_gss.tar.gz
>
> The logic is:
>
> pam_sm_authenticate
> {
> GSS_Acquire_cred_with_password()
This has always been the hard part for me to swallow about this. At
least at Sun, since there's no way to handle password expiration and
all that jazz with just this function :(
But you don't need that for GSS-EAP! Indeed, you almost certainly
don't want to handle pwexp here for GSS-EAP! (Makes me wonder why
it's OK to do pwexp in PAM for Kerberos. We still need interaction to
deal with things like smartcards.)
This does work, and it's a great idea.
Presumably you prompt for principal name separately from PAM_USER?
> while context incomplete {
> GSS_Init_sec_context()
> GSS_Accept_sec_context()
> }
> GSS_Localname() to canonicalise user
Right, set PAM_USER to the local name. It should be possible for the
localname lookup to fail. In that case I would say return PAM_IGNORE.
Or do the userok() check here if PAM_USER is set.
> }
>
> pam_sm_acct_mgmt
> {
> GSS_Userok() to authorise user
> }
Actually, if the localname function produced a username, then this
check is not needed. But, because PAM_USER could have changed since,
it's best to do this anyways, even if it means doing it twice. But if
the userok() check could be expensive then you'll want to use a PAM
data to track what PAM_USER was when userok() was called and skip it
here if PAM_USER hasn't changed.
> pam_sm_setcred
> {
> GSS_Store_cred()
> }
Yup!!
Makes one want to add a simple interactive initial credential
acquisition interface (to handle PIN prompts, ...).
Nico
--
|
