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

[Osipov, Michael]

> If it is Active Directory that you are talking about here, I would be
> focusing on upgrading the DCs that are still running unsupported operating
> systems. There are no currently supported versions of Windows that cannot
> support AES128 and AES256.
> 
> You could turn off the AES enctypes in all DCs using group policy and work
> around this, but that brings its own set of security risks, though none as
> scary as running Windows 2000/2003.

Well, the forest has grown over the years, my company has 350 000 employees
with the largest AD installation on the planet. All is mixed and I have no
control over, I am an ant in the pile.

It ultimately means that I have to wait until the forest level will be raised
4 and up.

Michael

> -----Original Message-----
> From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On Behalf
> Of Greg Hudson
> Sent: Wednesday, August 17, 2016 8:20 AM
> To: Osipov, Michael; kerberos at mit.edu
> Subject: Re: Avoiding "KDC has no support for encryption type while
> getting initial credentials" by pinning selected KDC
> 
> 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.
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos