Password expiration

Ken Hornstein kenh at cmf.nrl.navy.mil
Fri Mar 7 13:51:41 EST 2003


>Is anyone actually using the password expiration features of Kerberos?

Yes, but it was ... a lot of work.

I believe the _client_ support for this has been cleaned up and should
be better in MIT Kerberos 1.3, when it comes out (I don't know when that
will be).  So that is at least one important piece of the puzzle.

>	- I can only apparently get the pw_expiration info when running
>	  krb5_get_init_creds_password or krb5_get_init_creds, not with 
>	  another library function

That unfortunately is a limitation of the API, and that won't change.

>	  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?

>So, has anyone actually implemented password expiration in a decent fashion
>for the important login facilities for their network, i.e., xdm, dtlogin,
>sshd, su, xlock, etc ? My options appear to be:
>
>	- use or hack in native Kerberos support in my apps that does the
>	  right thing

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.

XDM is next on my list, but it's still down there; I looked at it
briefly, and the structure of XDM makes it difficult.  Maybe I'll check
out the PAM patch and try to leverage that work.

My basic thoughts for the rest are:

- dtlogin - Don't use it, replace it with xdm
- sshd - If we did use it, we would require GSSAPI/Kerberos 5 authentication,
  and that would push the authentication back to the client.
- su - We use sudo, and IIRC that already uses the get_init_creds interface
  so that one's been solved.

Note that I think I'm in the minority in my feelings regarding PAM, but
I'm _also_ in the minority that's got working password expiration warning,
so I don't feel too bad :-)

--Ken


More information about the Kerberos mailing list