Password expiration

James F.Hranicky jfh at cise.ufl.edu
Fri Mar 7 14:15:55 EST 2003


On Fri, 07 Mar 2003 13:51:41 -0500
Ken Hornstein <kenh at cmf.nrl.navy.mil> wrote:

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

Ok -- is the 1.3 CVS worth installing at this point?

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

Ok.

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

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

> 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

We don't, I just threw it in for reference :->

> - 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. I'm all for that, really, though ultimately
getting all my users Kerberized ssh on all remote systems that would need
to connect to mine seems unlikely.

> - su - We use sudo, and IIRC that already uses the get_init_creds interface
>   so that one's been solved.

Pamified su on Solaris seems to work properly, fortunately. On Linux with
su, there still seem to be problems.

> 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 :-)

Anything I can reasonably do to speed up the process I will.

Jim 


More information about the Kerberos mailing list