Avoiding "KDC has no support for encryption type while getting initial credentials" by pinning selected KDC

[Greg Hudson]

On 08/17/2016 08:51 AM, Osipov, Michael wrote:
> The keytab contains three keys for one principal: RC4, AES128, AES256.
> Our home realm is backed up by 80 to 100 KDCs of various Windows Server
> versions, not all support AES. KDC lookups rely on DNS only and we do
> not intend to hardcode them in krb5.conf.

I do not know a lot about administering Active Directory, but I thought
the usual practice here was to configure the newer AD servers to behave
as if they were of the least common denominator version.

> I would expect MIT Kerberos to pin the first working KDC because some
> Information has been negotiated already but send to a completely different
> KDC. This is annoying because I would expect the communication between client
> and server is predictable.

The Kerberos authentication protocol is intended to be stateless; if
different requests during an AS exchange go to different KDCs, that is
supposed to work.  We have talked about preferring the previously chosen
KDC during an AS exchange (mostly for the sake of marginal preauth
mechanism implementations), but I think the code changes necessary to
implement that properly would be extensive.