addprinc -randkey broken in 1.7?
mdw at umich.edu
Wed Sep 16 17:04:00 EDT 2009
Russ Allbery <rra at stanford.edu> writes:
> Date: Wed, 16 Sep 2009 13:13:13 PDT
> To: "Leonard J. Peirce" <leonard.peirce at gmail.com>
> cc: kerberos at mit.edu
> From: Russ Allbery <rra at stanford.edu>
> Subject: Re: addprinc -randkey broken in 1.7?
> "Leonard J. Peirce" <leonard.peirce at 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:
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.
More information about the Kerberos