Password expiration

[Steve Langasek]

On Fri, Mar 07, 2003 at 02:15:55PM -0500, James F.Hranicky wrote:

> > >	  o If the pamified program ignores or improperly implements
> > >	    the pam conversation function once the password has expired, 
> > >	    the user gets logged in, the the password expiration time is 
> > >	    cleared (!!) from the KDC. I've seen this with sshd & kdm.

> > It gets _cleared_?  How could that happen ... the password expiration time
> > should only be cleared by a password change?

> *shrug* I haven't gone through all the code with gdb, but it's happened with
> two apps. I'll see if I can track down where it is. 

> Your reaction is the same as mine was, believe me.

FWIW, if this is what's happening, it must be a KDC bug.  (Not a PAM bug
-- for once :)

> > This has been my general approach; I've never been a huge fan of PAM
> > (because most of the OSes I use don't support it), so I've been doing
> > native Kerberos support.  At least in the xlock case, that work has
> > already been done; I made it support the prompter interface via
> > krb5_get_init_creds() and I've submitted that back to the xlock
> > maintainer; if you download the latest beta release, that code will be
> > in there.  The same work could be leveraged to support the PAM conversation
> > functions (currently xlock does not), but I figure I'll leave that
> > to someone who has PAM working.

> Well, the nice thing about PAM is I can use ignore_unknown_upn during the
> migration. Perhaps I should just put out the pamified version first, then
> once the conversion is done, put out the Kerberized version.

If the application in question is one that the user must type their
password into directly, there's no particular advantage to making it
Kerberos-aware instead of just making it PAM-aware, really (this is the
niche pam_krb5 is aimed at, in fact).  OTOH, apps like ssh that
communicate using a client-server model definitely are better off with
Kerberos (GSSAPI) support.

> > - sshd - If we did use it, we would require GSSAPI/Kerberos 5 authentication,
> >   and that would push the authentication back to the client.

> I understand the reasoning, but ssh clients would then really need to be
> able to prompt for the Kerberos password and get tickets for users, as
> well as do proper password expiration, before *I* would feel comfortable
> having my userbase use it.

... or you could require the use of a Kerberized client OS, such as Win2K,
so that they already have the tickets they need. :-)  A Kerberized ssh
client is still a must here, of course.  My own deployments have involved
ssh with the gssapi patches, plus pam_krb5 for backwards-compatible
password auth.

-- 
Steve Langasek
postmodern programmer