5

Server is a RHEL7, Kerberos is AD (Windows). I'm only client of KDC.

Arcfour-hmac works fine but when I change encryption type to aes-256 and set up a new keytab, kinit still works, but not kvno. And even if the user seems to have a valid ticket (in klist) he is not able to start services anymore.

I don't have access to the Kerberos AD, but it seems properly configured to use aes-256, because end users (on Windows computers) already request tickets in this encryption type.

My krb5.conf :

[libdefaults]
default_realm = TOTO.NET
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
default_tkt_enctypes = aes256-cts aes128-cts des-cbc-md5 des-cbc-crc
default_tgs_enctypes = aes256-cts aes128-cts des-cbc-md5 des-cbc-crc
permitted_enctypes = aes256-cts aes128-cts des-cbc-md5 des-cbc-crc

[realms]
TOTO.NET = {
  kdc = kdc1.toto.net
  kdc = kdc2.toto.net
  admin_server = kdc1.toto.net
}

[domain_realm]
.toto.net = TOTO.NET
toto.net = TOTO.NET

And here the errors I got when I try to acquire a ticket with kvno :

[2477332] 1493147723.961912: Getting credentials myuser@TOTO.NET -> nn/myserver@TOTO.NET using ccache FILE:/tmp/krb5cc_0 
[2477332] 1493147723.962055: Retrieving myuser@TOTO.NET -> nn/myserver@TOTO.NET from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found (filename: /tmp/krb5cc_0) 
[2477332] 1493147723.962257: Retrieving myuser@TOTO.NET -> krbtgt/TOTO.NET@TOTO.NET from FILE:/tmp/krb5cc_0 with result: 0/Success 
[2477332] 1493147723.962267: Starting with TGT for client realm: myuser@TOTO.NET -> krbtgt/TOTO.NET@TOTO.NET 
[2477332] 1493147723.962274: Requesting tickets for nn/myserver@TOTO.NET, referrals on 
[2477332] 1493147723.962309: Generated subkey for TGS request: aes256-cts/17DF 
[2477332] 1493147723.962363: etypes requested in TGS request: aes256-cts, aes128-cts 
[2477332] 1493147723.962504: Encoding request body and padata into FAST request 
[2477332] 1493147723.962575: Sending request (1716 bytes) to TOTO.NET 
[2477332] 1493147723.962725: Resolving hostname kdc1.TOTO.NET 
[2477332] 1493147723.963054: Initiating TCP connection to stream ip_of_kdc1:88 
[2477332] 1493147723.964205: Sending TCP request to stream ip_of_kdc1:88 
[2477332] 1493147724.3751: Received answer (329 bytes) from stream ip_of_kdc1:88 
[2477332] 1493147724.3765: Terminating TCP connection to stream ip_of_kdc1:88 
[2477332] 1493147724.3846: Response was not from master KDC 
[2477332] 1493147724.3879: Decoding FAST response 
[2477332] 1493147724.3965: TGS request result: -1765328370/KDC has no support for encryption type

klist -ket mykeytab

Keytab name: FILE:nn.service.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   1 01/01/1970 01:00:00 nn/myserver01@TOTO.NET (aes256-cts-hmac-sha1-96)
   1 03/22/2017 16:34:55 nn/myserver02@TOTO.NET (aes256-cts-hmac-sha1-96)

Thanks for your help

tonio94
  • 460
  • 1
  • 6
  • 18
  • Inside the same directory that the keytab exists on your server, please run the following command, then re-edit your question with the results: *klist -k -t -e "filename of keytab"* – T-Heron Apr 28 '17 at 09:41
  • Did you check http://stackoverflow.com/questions/23801169/kdc-has-no-support-for-encryption-type-14? – Samson Scharfrichter Apr 28 '17 at 09:59
  • How exactly do you "acquire a ticket with kvno"? I don't get what you mean. – T-Heron Apr 29 '17 at 01:11
  • @T-Heron the kvno command almost always requests a ticket. In particular it determines the kvno that the TGS is using to issue tickets for a given principal by requesting a ticket for that principal as a service and printing the kvno from the unencrypted part of the ticket structure. – Sam Hartman Apr 29 '17 at 04:18
  • Does my answer answer your question? Please leave feedback, its the way this site works. – John R Smith Dec 09 '17 at 12:21

2 Answers2

5

Ask your AD administrator to enable support for AES-256 encryption types on the AD account associated with the keytab. To find that account, run this command:

setspn -Q nn/myserver01@TOTO.NET

the output will tell you the name of the account. It will start with CN=xxx, where "xxx" is the name of the AD account. To enable support for AES-256 encryption types on the AD account, tell your AD admin that the checkbox "This account supports Kerberos AES 256 bit encryption" must be checked, and that is found under Account tab, all the way at the bottom.

John R Smith
  • 848
  • 7
  • 18
  • 1
    Interestingly, I just attempted this, and my purely-aes-256 keytab still failed pre-auth. An RC4-hmac keytab worked fine. Is there anything else that could interfere/disable aes256-based auth? – Rick Moritz Jan 30 '18 at 12:35
  • @RickMoritz - I would make your query a new question, and link back to this. Include all the complete details of your environment including AD version and exact error messages. – John R Smith Feb 03 '18 at 21:12
  • Did this solution work for anyone? I doubt. I already have AES-256 enabled on the account, but didn't solve the issue. – Indranil Jan 11 '19 at 17:34
  • 1
    @RickMoritz Have you ever figured this out ? I have the same problem. If I use a keytab, only RC4 works. With AES, only if I try to kinit as the same user manually, that works fine, but not with keytab. – valorl Aug 20 '19 at 09:24
5

I just recently encountered this problem and was able to solve it.

for us, it was that AD was using a different salt than what the Kerberos client used by default.

That is, when using ktutil: addent -password -p servicepuppetnp@AMER.EXAMPLE.COM -k 4 -e arcfour-hmac Password for admspike_white@AMER.EXAMPLE.COM:

produces a keytab file that I could use to kinit as that principal. Whereas:

ktutil: addent -password -p admspike_white@AMER.EXAMPLE.COM -k 1 -e aes256-cts-hmac-sha1-96 Password for admspike_white@AMER.EXAMPLE.COM:

did not produce a keytab file that would allow successful kinit. (pre-auth failure).

I had to do this:

ktutil: addent -password -p admspike_white@AMER.EXAMPLE.COM -k 1 -e aes256-cts-hmac-sha1-96 -f Password for admspike_white@AMER.EXAMPLE.COM:

which tells ktutil to get the salt info from the AD DC. then it uses the correct salt. That produces a keytab file that allows successful kinit.

spike
  • 51
  • 1
  • 1
  • I ran into this issue starting from Debian 11 where arcfour has been deprecated. Using the -f flag for aes256 made it work for me again. – Sven Geggus Mar 21 '23 at 13:31