[39058] in Kerberos
Re: Replica KDC has no support for encryption type
daemon@ATHENA.MIT.EDU (Dr. Lars Hanke)
Mon Feb 7 05:36:40 2022
Message-ID: <4e33beec-aa24-b317-f89a-85dd2c891db0@lhanke.de>
Date: Mon, 7 Feb 2022 11:32:56 +0100
MIME-Version: 1.0
Content-Language: de-DE
To: Greg Hudson <ghudson@mit.edu>, "kerberos@MIT.EDU" <kerberos@mit.edu>
From: "Dr. Lars Hanke" <debian@lhanke.de>
In-Reply-To: <387069fb-7834-588d-c8f7-b2575434402b@mit.edu>
Reply-To: debian@lhanke.de
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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@EXAMPLE.COM for
krbtgt/EXAMPLE.COM@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@EXAMPLE.COM for krbtgt/EXAMPLE.COM@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@EXAMPLE.COM for ldap/krb2.example.com@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@EXAMPLE.COM for ldap/krb2.example.com@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@EXAMPLE.COM for ldap/krb1.example.com@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@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@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@EXAMPLE.COM for ldap/krb2.example.com@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@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:
> 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).
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
