> 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-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf > Of Greg Hudson > Sent: Wednesday, August 17, 2016 8:20 AM > To: Osipov, Michael; kerberos@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@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
