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

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.

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.