[19175] in Kerberos
Re: Improved support for password/principal expiration
daemon@ATHENA.MIT.EDU (James F.Hranicky)
Fri May 2 15:05:29 2003
Date: Fri, 2 May 2003 15:03:38 -0400
From: "James F.Hranicky" <jfh@cise.ufl.edu>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Message-Id: <20030502150338.363aaeab.jfh@cise.ufl.edu>
In-Reply-To: <200305021822.h42IMqsG021717@ginger.cmf.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
cc: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
On Fri, 02 May 2003 14:22:52 -0400
Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote:
> >Currently, Kerberos cannot notify users of both impending principal
> >expiration and impending password expiration due to the fact that
> >there is only one field (key_exp) in struct _krb5_enc_kdc_rep_part {}.
>
> I'm ahead of you there, James :-)
Great!
> _on the client side only_ in the 1.3 alpha code (look at gic_pwd.c:327).
> This gives the KDC the ability to _unambigiously_ indicate password
> expiration to clients. Because of time issues I wasn't able to get
> the KDC-side support in there, but it's a small change.
Very cool -- so then I assume that if this is the standard way to do this,
the prompts sent back when checking key_exp should be changed to something
like
"This account will expire in %d <whatever>s"
right?
Are you saying this change won't go into the 1.3 code release, or that
it's just not in the alpha currently?
> rather than add my own. I cannot speak for MIT, but I would doubt
> very much that they would accept code that created a new ASN.1 element
> in an AS_REP without it going through the IETF process and everyone
> thoroughly understood the backwards compatibility issues.
No problem, sounds like a big deal, especially in light of your fix.
It's not like I'm Microsoft ;->
> varies by site). The code I wrote lets you set a KDC-specific variable
> that controls the threshold for password expiration notification.
> Since the last-req field is optional, not sending means "don't display
> the password expriation warning".
Ok, would this be set in kdc.conf or through kadmin?
> Sigh. Unfortunately, this ends up being very complex in practice, since
> sending back a display string opens up the whole internationalization
> mess. I personally think your best bet here is to work on a client-side
> configuration (as much as I loath client-side configuration, I don't see
> a reasonable alternative here).
Hmmm...I meant customization of the banner sent to the GIC prompter, so
it would be client side -- the KDC interaction would stay relatively
unchanged...something in krb5.conf?
[libdefaults]
gic_princ_exp_msg = /usr/local/etc/krb5/princ_exp_msg
gic_pass_exp_msg = /usr/local/etc/krb5/pass_exp_msg
Contents of /usr/local/etc/krb5/princ_exp_msg :
Information on renewing accounts can be found at
http://www.my.domain.com/accounts/renewals .
Contents of /usr/local/etc/krb5/pass_exp_msg :
Information on changing your password can be found at
http://www.my.domain.com/accounts/passchange .
Something like that...
Unfortunately, I'm not sure I could do anything else as the as_reply doesn't
get passed out of krb5_g_i_c_p() .
> >the expiration. Since I plan on using password expiration as well, the
> >above modifications would probably be necessary to make such a scheme
> >work well.
>
> Right, and here is a case where there really is a difference between
> client expiration and password expiration, so that makes everything more
> complicated (since most people are only interested in password expiration).
Sure, and this would mean str*cat'ing one message onto the banner containing
the other if both messages were to be displayed. I don't think it's hugely
more complicated -- what do you think?
I could try to code some of this up if you'd like.
Jim
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
