[krbdev.mit.edu #6821] The +preauth default in kdc.conf isn't always obeyed.
D.H.Davis@bath.ac.uk via RT
rt-comment at krbdev.mit.edu
Wed Nov 17 11:00:08 EST 2010
On Wed, 17 Nov 2010, Greg Hudson via RT wrote:
> From: Greg Hudson via RT <rt-comment at krbdev.mit.edu>
> To: D.H.Davis at bath.ac.uk
> Date: Wed, 17 Nov 2010 15:33:13
> Subject: [krbdev.mit.edu #6821] The +preauth default in kdc.conf isn't always
> obeyed.
>
> Prior to 1.8, addprinc -randkey was implemented in three
> RPCs: create the principal with a dummy password and the
> disallow-all-tix flag, randomize its password, unset the
> disallow-all-tix flag. This had the unfortunate side effect of
> ignoring the KDC's default flags.
>
> There is now a better way (create the principal with a null
> password), but clients and servers both have to be at 1.8 for it
> to work.
Thanks for the very prompt reply.
I wondered if something like this was happening when I noticed
-randkey with 1.6.3 and 1.7.1 kadmin produced principals with a Key
vno of 2, whereas -randkey with a 1.8.x kadmin produced principals
with a Key vno of 1.
I note you're using RT so please flag this ticket as closed, if
you haven't done so already. It would be unreasonable to expect
the improved interface to be back-ported to earlier versions of
kerberos.
(This arose because I've recently switched to using the +preauth
default for all principals associated with humanoids. Easily
done by making it the default in kdc.conf. Typically I, and I
suspect others, use -randkey when generating host and service based
principals. So I was expecting to have to turn off preauth on such
principals as I'm not quite ready to go there yet. I was puzzled
when I didn't have to turn off +preauth with a production KDC
running 1.6.3. It had already been done for me!)
--
Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK
D.H.Davis at bath.ac.uk Phone: +44 1225 386101
More information about the krb5-bugs
mailing list