Replica KDC has no support for encryption type

[Dr. Lars Hanke]

I want to set up a replicated Kerberos server on a different site. The
original Kerberos with LDAP backend (ldapi:///) is running for more than
a decade. So I cloned the LXC container with Kerberos and LDAP and
instantiated it on the new site just adapting host names, certificates,
etc. This apparently worked provided the database was not changed of
course. For that reason I set up the new LDAP as a syncprov replication
of the original one also using Kerberos for authentication. The
configuration of the KDC remained unchanged. This also worked e.g. I see
the principals created on the original server on the replica KDC.

By setting the 'kdc' for the realm in '/etc/krb5.conf' I can now select,
which KDC to use. Using tickets from the original KDC I can authenticate
users to both LDAP servers. I can use the new KDC to authenticate users
to the original LDAP server, BUT using the new KDC to obtain a ticket
for the new LDAP I get:

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)

Checking the ticket cache with 'klist -e' I cannot see any difference
which KDC I used. The TGT can be obtained from either server.

Logging 'slapd' I found that LDAP is accessed for the TGT, but not for
the service ticket - same for both installations. So at the first glance
it seems unrelated to LDAP. I did a 'service krb5-kdc restart' after
LDAP replication was up and running.

Kerberos 1.17 and OpenLDAP 2.4.47 are current Debian 10. I wanted to
upgrade to bullseye as soon as the system is running.

Any ideas what is happening?

Thanks for your help,
- lars.

[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).

[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/ad...@EXAMPLE.COM for
krbtgt/EXAMP...@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/ad...@EXAMPLE.COM for krbtgt/EXAMP...@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/ad...@EXAMPLE.COM for ldap/krb2.exa...@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/ad...@EXAMPLE.COM for ldap/krb2.exa...@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/ad...@EXAMPLE.COM for ldap/krb1.exa...@EXAMPLE.COM

Following these operations my ticket cache on krb2 contains:

07.02.2022 10:47:24  07.02.2022 20:47:24 krbtgt/EXAMP...@EXAMPLE.COM
       renew until 08.02.2022 10:47:20
07.02.2022 10:47:39  07.02.2022 20:47:24 ldap/krb1.exa...@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/ad...@EXAMPLE.COM for ldap/krb2.exa...@EXAMPLE.COM

After that the ticket cache also holds:


07.02.2022 10:56:09  07.02.2022 20:47:24 ldap/krb2.exa...@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@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: