Kerberos aes-256 encryption not working

Question

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 [email protected] -> nn/[email protected] using ccache FILE:/tmp/krb5cc_0 
[2477332] 1493147723.962055: Retrieving [email protected] -> nn/[email protected] from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found (filename: /tmp/krb5cc_0) 
[2477332] 1493147723.962257: Retrieving [email protected] -> krbtgt/[email protected] from FILE:/tmp/krb5cc_0 with result: 0/Success 
[2477332] 1493147723.962267: Starting with TGT for client realm: [email protected] -> krbtgt/[email protected] 
[2477332] 1493147723.962274: Requesting tickets for nn/[email protected], 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/[email protected] (aes256-cts-hmac-sha1-96)
   1 03/22/2017 16:34:55 nn/[email protected] (aes256-cts-hmac-sha1-96)

Thanks for your help

Phalan

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" – Gymnasiast

Did you check #23801669? – Homemaking

How exactly do you "acquire a ticket with kvno"? I don't get what you mean. – Gymnasiast

@Gymnasiast 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. – Brighten

Does my answer answer your question? Please leave feedback, its the way this site works. – Hospitality

Answer 1

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/[email protected]

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.

Hospitality

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? – Seaport

@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. – Hospitality

Did this solution work for anyone? I doubt. I already have AES-256 enabled on the account, but didn't solve the issue. – Emotionalize

@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. – Abuse

Answer 2

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 [email protected] -k 4 -e arcfour-hmac Password for [email protected]:

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

ktutil: addent -password -p [email protected] -k 1 -e aes256-cts-hmac-sha1-96 Password for [email protected]:

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

I had to do this:

ktutil: addent -password -p [email protected] -k 1 -e aes256-cts-hmac-sha1-96 -f Password for [email protected]:

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.

Pleuron

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. – Mindy