kadmin.local "ank -randkey" ignores kdc.conf's default_principal_flags?
Marcus Watts
mdw at umich.edu
Thu Jun 3 16:35:37 EDT 2010
> Date: Thu, 03 Jun 2010 16:21:43 EDT
> To: Marcus Watts <mdw at umich.edu>
> cc: "kerberos at mit.edu" <kerberos at mit.edu>
> From: Tom Yu <tlyu at MIT.EDU>
> Subject: Re: kadmin.local "ank -randkey" ignores kdc.conf's default_principal_f
> ***lags?
>
> Marcus Watts <mdw at umich.edu> writes:
>
> >> Date: Thu, 03 Jun 2010 14:23:14 EDT
> >> To: Adam Megacz <megacz at cs.berkeley.edu>
> >> cc: "kerberos at mit.edu" <kerberos at MIT.EDU>
> >> From: Greg Hudson <ghudson at MIT.EDU>
> >> Subject: Re: kadmin.local "ank -randkey" ignores kdc.conf's default_principa
> l_f
> >> ***lags?
> >>
> >> On Wed, 2010-06-02 at 23:43 -0400, Adam Megacz wrote:
> >> > Related to my previous posting, I find that even though I have
> >> >
> >> > default_principal_flags = +preauth
> >> >
> >> > in kdc.conf, when I use kadmin.local's "ank -randkey" command to create
> >> > a service principal, the principal is created with no attributes.
> >>
> >> This is a known bug; it was fixed in 1.7.1 and 1.8.
> >
> > ... and here's a previous message I posted to this list which
> > is unobviously relevant here:
> > http://www.mail-archive.com/kerberos@mit.edu/msg15880.html
>
> In older releases, "ank -randkey" has three phases. The first phase
> creates the principal with all tickets disabled and with a fixed
> password. To do so, it sets a bit in the request attribute mask sent
> to the server, indicating that the kadmin client is overriding the
> default princpal flags (which normally get filled in by the server if
> the client didn't indicate that it was going to override them). Phase
> two is a "randkey" operation, and phase three is to clear the
> "DISALLOW_ALL_TIX" flag. If you didn't explicitly specify any
> principal flags in the client, that means no principal flags are set
> when "ank -randkey" is finished.
>
> This has since been fixed, as Greg said.
Yes. I understand that the "long-term" fix Greg committed was based on
the patch I included in this message. In my case, the impetus to make
this change was to improve password plugin checking behavior, which is why
I failed to submit this patch in the usual fashion.
-Marcus Watts
More information about the Kerberos
mailing list