Replica KDC has no support for encryption type

[Dr. Lars Hanke]

I enabled logging on both KDC. For some reason the KDC claims that 
/var/log was read-only. It's not, but logging to /tmp produced log files.

The results were not exactly enlightening. This is kinit -p user/admin, 
ldapsearch -b "cn=admin,dc=example,dc=com" -H ldap://krb2.example.com 
uid=user, ldapsearch -b "cn=admin,dc=example,dc=com" -H 
ldap://krb1.example.com uid=user on krb2:

Feb 07 10:47:13 krb2 krb5kdc[6696](Error): preauth spake failed to 
initialize: No SPAKE preauth groups configured
Feb 07 10:47:13 krb2 krb5kdc[6696](info): setting up network...
Feb 07 10:47:13 krb2 krb5kdc[6696](info): setsockopt(12,IPV6_V6ONLY,1) 
worked
Feb 07 10:47:13 krb2 krb5kdc[6696](info): setsockopt(14,IPV6_V6ONLY,1) 
worked
Feb 07 10:47:13 krb2 krb5kdc[6696](info): setsockopt(16,IPV6_V6ONLY,1) 
worked
Feb 07 10:47:13 krb2 krb5kdc[6696](info): set up 6 sockets
Feb 07 10:47:13 krb2 krb5kdc[6697](info): commencing operation
Feb 07 10:47:20 krb2 krb5kdc[6697](info): AS_REQ (8 etypes {18 17 20 19 
16 23 25 26}) 10.0.0.10: NEEDED_PREAUTH: user/admin at EXAMPLE.COM for 
krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required
Feb 07 10:47:24 krb2 krb5kdc[6697](info): AS_REQ (8 etypes {18 17 20 19 
16 23 25 26}) 10.0.0.10: ISSUE: authtime 1644227244, etypes {rep=18 
tkt=18 ses=18}, user/admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM
Feb 07 10:47:33 krb2 krb5kdc[6697](info): TGS_REQ (8 etypes {18 17 20 19 
16 23 25 26}) 10.0.0.10: BAD_ENCRYPTION_TYPE: authtime 0, 
user/admin at EXAMPLE.COM for ldap/krb2.example.com at EXAMPLE.COM, KDC has no 
support for encryption type
Feb 07 10:47:33 krb2 krb5kdc[6697](info): TGS_REQ (8 etypes {18 17 20 19 
16 23 25 26}) 10.0.0.10: BAD_ENCRYPTION_TYPE: authtime 0, 
user/admin at EXAMPLE.COM for ldap/krb2.example.com at EXAMPLE.COM, KDC has no 
support for encryption type
Feb 07 10:47:39 krb2 krb5kdc[6697](info): TGS_REQ (8 etypes {18 17 20 19 
16 23 25 26}) 10.0.0.10: ISSUE: authtime 1644227244, etypes {rep=18 
tkt=18 ses=18}, user/admin at EXAMPLE.COM for ldap/krb1.example.com at EXAMPLE.COM

Following these operations my ticket cache on krb2 contains:

07.02.2022 10:47:24  07.02.2022 20:47:24 krbtgt/EXAMPLE.COM at EXAMPLE.COM
        renew until 08.02.2022 10:47:20
07.02.2022 10:47:39  07.02.2022 20:47:24 ldap/krb1.example.com at EXAMPLE.COM
        renew until 08.02.2022 10:47:20

Then I change the kdc to krb1 in /etc/krb5.conf, and retry the failed 
ldapsearch -b "cn=admin,dc=example,dc=com" -H ldap://krb2.example.com 
uid=user. This is what I see in the log of krb1:


Feb 07 10:56:09 hel krb5kdc[16026](info): TGS_REQ (8 etypes {18 17 20 19 
16 23 25 26}) 10.0.0.10: ISSUE: authtime 1644227244, etypes {rep=18 
tkt=18 ses=18}, user/admin at EXAMPLE.COM for ldap/krb2.example.com at EXAMPLE.COM

After that the ticket cache also holds:


07.02.2022 10:56:09  07.02.2022 20:47:24 ldap/krb2.example.com at EXAMPLE.COM
        renew until 08.02.2022 10:47:20

The IP address in the logs is that of krb2. The full error message on 
krb2 is:

root at krb2:~# ldapsearch -b "cn=admin,dc=example,dc=com" -H 
ldap://krb2.example.com uid=user
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information (KDC 
has no support for encryption type)

To me the etypes (encryption types?) in the requests are all the same. 
So I'm still totally clueless ...

I appreciate any ideas for further troubleshooting.

Am 04.02.22 um 18:19 schrieb Greg Hudson:
> On 2/4/22 2:19 AM, Dr. Lars Hanke wrote:
>>          additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (KDC has no support for encryption type)
> It might help to compare the KDC log entry for this TGS request on the
> old and new KDC.
>
> During a TGS request, "KDC has no support for encryption type" can mean
> that the KDC could not select an encryption type for the session key.
> The session key enctype must be present in (1) the enctypes listed in
> the KDC request, (2) the KDC's permitted_enctypes if set, and (3) the
> enctypes supported by the server DB entry (which is usually the enctypes
> of the server's long-term keys, unless overridden by the
> session_enctypes string attribute).