[krbdev.mit.edu #8038] Kadmind/kadmin.local issues after migration from version 1.12.2 to 1.13

[Andrei Maslennikov via RT]

Hi Ben, thanks a lot!

Will be waiting for further input from you.

Cheers - Andrei.

On Thu, Nov 20, 2014 at 5:10 PM, Benjamin Kaduk via RT <
rt-comment at krbdev.mit.edu> wrote:

> [andrei.maslennikov at gmail.com - Thu Nov 20 04:04:03 2014]:
>
> > Hello, it seems we are getting closer to the origin of the loop!
>
> Yes, indeed.
>
> > I.e. it looks like kadmin.local goes mad while comparing strings or
> looking
> > for encryption type "arcfour-hmac".
>
> We did change some code relating to how the keysalt list is processed, so
> that's likely the culprit
> here.
>
> > Thus the issue is turning around "arcfour-hmac". My current list of
> > encryption types includes this
> > family, and I have to keep them there as the principals already possess
> the
> > corresponding keys:
>
> This is not actually true; the "supported_enctypes" variable is rather
> misnamed -- it controls the
> generation of new keys on the KDC (e.g., from user-supplied passwords) by
> specifying which
> enctypes will be generated, but has no effect on the operation of existing
> keys.  (There is a
> separate variable, "permitted_enctypes", which does have that effect.)
>
> > "arcfour-hmac:normal arcfour-hmac:norealm arcfour-hmac:onlyrealm
> > arcfour-hmac-md5:normal"
>
> The arcfour family of enctypes do not actually use a salt, ever, so there
> is no difference between
> the :normal, :norealm, and :onlyrealm forms.  I am not yet sure if this
> duplication is causing the
> spinning, but it is certainly unnecessary in your configuration.
>
> > (If I recall it correctly, "arcfour-hmac" is used on Windows clients, and
> > we have some
> > Win machines that get the authentication from K5MIT and not from AD).
>
> Windows XP and Windows Server 2003 only support the arcfour and single-DES
> encryption types.
> Newer versions of windows also support the more modern AES encryption
> types (though perhaps
> Windows Server 2008 would need some manual configuration to start using
> them; this is not
> entirely clear to me).  If your windows clients are, e.g., Windows 7 and
> above, they can handle
> AES enctypes just fine.  You will probably need to go and rekey some
> things to make a full
> transition, but the mere presence of such windows clients does not require
> you to keep arcfour
> around.  The arcfour enctypes are likely to be deprecated in the next year
> or two.
>
> > What could be done about it?
>
> I will fire up a test KDC with the problematic supported_enctypes list and
> look into a fix.
>
> > Cheers - Andrei.
> >
> > PS I have mentioned that the Builds directory of my yesterday's tar file
> was
> > in fact containing two times 1.12.2 builds and not 1.12.2 and 1.13. I
> have
> > hence replaced the tar.file with the one correcting the correct Builds
> > subdir,
> > sorry for this mistake. You may again grab it at:
> >
> >        http://afsita.masl.eu/k5/k5.debug.tgz
>
> Thanks, but I think just the bit about supported_enctypes will be enough
> for now.
>
> Thanks for following up on this issue.
>
> -Ben
>