Russ Allbery <r...@stanford.edu> writes:
> Date: Wed, 16 Sep 2009 13:13:13 PDT
> To: "Leonard J. Peirce" <leonard.pei...@gmail.com>
> cc: kerberos@mit.edu
> From: Russ Allbery <r...@stanford.edu>
> Subject: Re: addprinc -randkey broken in 1.7?
>
> "Leonard J. Peirce" <leonard.pei...@gmail.com> writes:
>
> > When running (in kadmin)
>
> > addprinc -randkey host/host.domain
>
> > I get a complaint about the password not containing enough character
> > classes. Did I miss something? Not really a big deal since I can
> > just specify a password.
>
> > It used to work in 1.6.
>
> addprinc -randkey hasn't worked for principals that have a password policy
> set for somet time for me. The way -randkey works under the hood is that
> it adds the principal disabled with a fixed password (which is indeed
> pretty bad except that it's very long), then randomizes the key, and then
> enables the principal.
>
> This has other strange artifacts (or at least did -- I don't know if
> they've been fixed). For example, adding a principal with -randkey and
> -disallow_all_tix results in an enabled principal, igoring the
> -disallow_all_tix option.
Ah! I have a patch for this. I thought I had submitted this to MIT
long since, but I can't find any record that this happened.
Here's the patch:
/afs/umich.edu/user/m/d/mdw/build/krb5.15x/patches/krb5-1.6.3-ankfix1.patch
This changes the protocol to use a 'null' password to indicate randkey
operation.
If a new client talks to an old server, the behavior is to fall back to the old
case.
Obviously this was for 1.6.3, but it might apply to 1.7.
-Marcus Watts
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
