Kerberos aes-256 encryption not working - authentication

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 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

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/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.

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