[19178] in Kerberos
Re: Improved support for password/principal expiration
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Fri May 2 16:45:41 2003
Message-Id: <200305022044.h42KiXsG023736@ginger.cmf.nrl.navy.mil>
To: "James F.Hranicky" <jfh@cise.ufl.edu>
In-Reply-To: Message from "James F.Hranicky" <jfh@cise.ufl.edu>
<20030502163607.53d1d962.jfh@cise.ufl.edu>
Date: Fri, 02 May 2003 16:44:33 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
cc: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
>Hmmm...the only "application" that can really interpret it is the kgicp()
>code, isn't it?
Depends on the API you're using. With krb5_get_init_creds_*(), yes.
With the old krb5_get_in_tkt() API you get the krb5_kdc_rep back as one
of the arguments, so you can peek at last_req fields or key-exp yourself
(which is what I used to do). And when I say "application", I really
mean any client code.
>I don't really understand how the client is supposed to interpret what
>the KDC means...
Heh, well, therein lies the problem :-)
>> Ah-ha, I had forgotten ... there is already a last-req entry allocated
>> for account expiration! Password expiration has a lr-value of 6, and
>> account expiration has a lr-value of 7. So there you go; you've
>> already got a spot in the protocol.
>
>Shall I code it up, or do you want to? :->
Unfortunately, I'm waaay too busy right now, so it would probably be better
coming from you.
>At this point, then, I don't know what to do with the key_exp field, except
>ignore it I suppose.
I think that's safest, personally.
>I believe I can patch it myself if necessary...any thoughts on running
>the 1.3 code in production :-> ?
I think it's a little early myself, since it is only in alpha.
>Ok -- does anyone on the list want me to take this over to krb5dev , or is this
>discussion enough?
I think maybe proposing the change on krbdev can't hurt.
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
