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

[Todd Grayson]

Michael,

This does not fix your issue, its more for clarification of discussion.

The "domain functional level" should be dictating the behavior of the
aggregate AD environment. You can control the preference for encryption
type in the krb5.conf's [libdefaults] enctype
settings (default_tgs_enctypes,  permitted_enctypes, default_tkt_enctypes).

Consider the following might offer some possible workarounds?

As I understand it; kerberos will use the provided encryption types based
on order presented from the config.... so if you have a subset of services
and users that need everything negotiated with rc4-hmac as the preferred
encryption type, you would make sure that was listed first in the client
config.

The important thing to remember is use the naming presented in the enctypes
reference table from the krb5.conf / kdc.conf MIT docs (or enctype groups)
or the settings are ignored.

http://web.mit.edu/kerberos/krb5-1.13/doc/admin/conf_files/krb5_conf.html#libdefaults
http://web.mit.edu/kerberos/krb5-1.13/doc/admin/conf_files/kdc_conf.html#encryption-types

*If Java is in the mix you have to limit enctypes to whats supported under
the JGSS as well.

http://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/jgss-api-mechanism.html


On Wed, Aug 17, 2016 at 9:19 AM, Greg Hudson <ghudson at mit.edu> wrote:

> 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
>



-- 
Todd Grayson
Business Operations Manager
Customer Operations Engineering
Security SME