Kerberos - AES-256 Keytab does not work

Question

Our AD Team is going to disable RC4-HMAC so I have to change our JBoss-applications to AES. I added the aes types to krb5.conf and created new keytabs but that seems to not work. Tests besides the application with kinit show the same results.

There was an similar issue but its solution was already enabled for us. There is another guy (Rick Moritz) with my problem without an answer.

Server: SLES12

AD: Windows Server 2016

krb5.conf

[libdefaults]
  debug = false
  default_realm = MY.DOMAIN
  ticket_lifetime = 24000
  default_keytab_name = /app/myapp/sso/myapp_eu.keytab_AES
  dns_lookup_realm = false
  dns_lookup_kdc = false
  default_tkt_enctypes = aes256-cts aes128-cts rc4-hmac
  default_tgs_enctypes = aes256-cts aes128-cts rc4-hmac
  permitted_enctypes = aes256-cts aes128-cts rc4-hmac

[realms]
  MY.DOMAIN = {
    kdc = my.domain
    default_domain = my.domain
  }

[domain_realm]
  .my.domain = MY.DOMAIN
  my.domain = MY.DOMAIN

[appdefaults]
  forwardable = true

Keytabs

keytab old RC4:

klist -ket myapp_eu.keytab_RC4
Keytab name: FILE:myapp_eu.keytab_RC4
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   0 02/19/2018 14:41:39 [email protected] (arcfour-hmac)

keytab new AES256:

klist -ket myapp_eu.keytab_AES
Keytab name: FILE:myapp_eu.keytab_AES
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   0 03/14/2018 15:03:31 [email protected] (aes256-cts-hmac-sha1-96)

kinit tests (krb5 Version 1.12.5)

authentication with password (success):

kinit -fV [email protected]
klist -ef
Valid starting     Expires            Service principal
03/14/18 14:37:12  03/15/18 00:37:12  krbtgt/[email protected]
        renew until 03/15/18 14:37:06, Flags: FRIA
        Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

authentication with old keytab RC4 (success):

kinit -fV -k -t /app/myapp/sso/myapp_eu.keytab_RC4 [email protected]
klist -ef
Valid starting     Expires            Service principal
03/14/18 14:36:52  03/15/18 00:36:52  krbtgt/[email protected]
        renew until 03/15/18 14:36:51, Flags: FRIA
        Etype (skey, tkt): arcfour-hmac, aes256-cts-hmac-sha1-96

authentication with new keytab AES256 (failure):

kinit -fV -k -t /app/myapp/sso/myapp_eu.keytab_AES [email protected]
Using principal: [email protected]
Using keytab: /app/myapp/sso/myapp_eu.keytab_AES
kinit: Preauthentication failed while getting initial credentials

A look on the etypes shows that aes seems to work. But i cant figure out why i get a preauthentication error with the aes-keytabs.

The old and new keytabs were created by the following ktpass command:

ktpass -princ [email protected] -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -pass xxxxxxxx -kvno 0 -out myapp_eu.keytab_RC4
ktpass -princ [email protected] -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass xxxxxxxx -kvno 0 -out myapp_eu.keytab_AES

I already tried it with the correct kvno instead of 0 with the same result.

Thanks for you help or ideas.

P.S. anonymized MY.DOMAIN and myapp

Test with fresh compiled krb5 1.16

i combined the tips from Samson Scharfrichter and T.Heron and now i see a difference between the SALT i get from ktpass at the creation of the keytab and from the trace-output of kinit. But i dont know where it comes from and how to change it. The salt consists one of the SPNs in this case.

ktpass

PS X:\> ktpass -out x:\MyappEUv3.keytab -mapOp set +DumpSalt -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass xxxxxx -princ [email protected]
Building salt with principalname MyappEU and domain MY.DOMAIN (encryption type 18)...
Hashing password with salt "MY.DOMAINMyappEU".
Key created.
Output keytab to x:\MyappEUv3.keytab:
Keytab version: 0x502
keysize 71 [email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 1 etype 0x12 (AES256-SHA1) keylength 32 (0x326dd53c7fce5ac4f25d1d17c6a1cf721d7d044f7eb72eaa92a20125055a3b25)

kinit trace

 env KRB5_TRACE=/dev/stdout /home/akirsch/krb5-1.16_made/bin/kinit -fV -k -t /home/akirsch/MyappEUv3.keytab [email protected]
 Using default cache: /tmp/krb5cc_0
 Using principal: [email protected]
 Using keytab: /home/akirsch/MyappEUv3.keytab
 [32175] 1521108914.135563: Getting initial credentials for [email protected]
 [32175] 1521108914.135564: Looked up etypes in keytab: aes256-cts
 [32175] 1521108914.135566: Sending unauthenticated request
 [32175] 1521108914.135567: Sending request (153 bytes) to MY.DOMAIN
 [32175] 1521108914.135568: Resolving hostname MY.DOMAIN
 [32175] 1521108914.135569: Sending initial UDP request to dgram 172.18.32.134:88
 [32175] 1521108914.135570: Received answer (214 bytes) from dgram 172.18.32.134:88
 [32175] 1521108914.135571: Response was not from master KDC
 [32175] 1521108914.135572: Received error from KDC: -1765328359/Additional pre-authentication required
 [32175] 1521108914.135575: Preauthenticating using KDC method data
 [32175] 1521108914.135576: Processing preauth types: 16, 15, 19, 2
 [32175] 1521108914.135577: Selected etype info: etype aes256-cts, salt "MY.DOMAINHTTPmyapp-entw.intranet-test.my.domain", params ""
 [32175] 1521108914.135578: Retrieving [email protected] from FILE:/home/akirsch/MyappEUv3.keytab (vno 0, enctype aes256-cts) with result: 0/Success
 [32175] 1521108914.135579: AS key obtained for encrypted timestamp: aes256-cts/ECF3
 [32175] 1521108914.135581: Encrypted timestamp (for 1521108914.396292): plain 301AA011180F32303138303331353130313531345AA1050203060C04, encrypted F92E4F783F834FF6500EA86CAF8CA3088517CB02F75BD2C962E5B454DC02C6F3BBCAF59EEB6F52D58AA873FF5EDFCA1496F59D2A587701A1
 [32175] 1521108914.135582: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
 [32175] 1521108914.135583: Produced preauth for next request: 2
 [32175] 1521108914.135584: Sending request (231 bytes) to MY.DOMAIN
 [32175] 1521108914.135585: Resolving hostname MY.DOMAIN
 [32175] 1521108914.135586: Sending initial UDP request to dgram 10.174.50.13:88
 [32175] 1521108914.135587: Received answer (181 bytes) from dgram 10.174.50.13:88
 [32175] 1521108914.135588: Response was not from master KDC
 [32175] 1521108914.135589: Received error from KDC: -1765328360/Preauthentication failed
 [32175] 1521108914.135592: Preauthenticating using KDC method data
 [32175] 1521108914.135593: Processing preauth types: 19
 [32175] 1521108914.135594: Selected etype info: etype aes256-cts, salt "MY.DOMAINHTTPmyapp-entw.intranet-test.my.domain", params ""
 [32175] 1521108914.135595: Getting initial credentials for [email protected]
 [32175] 1521108914.135596: Looked up etypes in keytab: des-cbc-crc, des, des-cbc-crc, rc4-hmac, aes256-cts, aes128-cts
 [32175] 1521108914.135598: Sending unauthenticated request
 [32175] 1521108914.135599: Sending request (153 bytes) to MY.DOMAIN (master)
 kinit: Preauthentication failed while getting initial credentials

Solution 1

Thanks and T.Heron and Samson for the tips.

At the end there were only 2 steps to do.

1. Activate AES for the Account as described in T.Herons article
2. Use ktpass with mapuser to set the salt to the principal that is used as login. (a error will be shown but the salt will still be set)

The second part was hard to find out. MapUser will set the SALT and the UPN to the SPN which is mapped! There can only be one SALT.

You can see the current salt on linux using:

env KRB5_TRACE=/dev/stdout env KRB5_CONFIG=krb5.conf kinit -fV [email protected]

ExampleOutputLine (wrong salt in this case)

[10757] 1523617677.379889: Selected etype info: etype aes256-cts, salt "MYDOMAIN.COMHTTPvm41568226", params ""

Solution 2

Please ensure you clear the SPN(s) from the Active Directory account related to the keytab before generating a new keytab. This is a little known issue. In your case, I would run the following six step process and it should work:

1. setspn -D HTTP/myapp.my.domain MyappEU

2. Then generate the keytab:

   ktpass -princ HTTP/myapp.my.domain -mapUser [email protected] -pass xxxxxxxx -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -kvno 0 -out myapp_eu.keytab_AES
   

3. Verify the SPN you need is on the Active Directory account:

setspn -L MyappEU

4. Ensure the new SPN is reflected in the "User logon name" field in the Account tab of the Active Directory account and the checkbox "This account supports Kerberos AES 256 bit encryption" beneath that is checked:
   

5. In the standalone.xml file on your JBOSS server, don't forget to update the keytab file name there and then restart the JBOSS engine for the change to take effect.
6. Finally, you'll need the unlimited encryption strength Java JAR files in your Java_Home\lib\security directory on the JBOSS server or else your keytab won't be able to de-crypt AES256-SHA1 Kerberos tickets. If you are convinced the problem isn't in steps 1-5, then maybe this one is it.

Comments

[Samson Scharfrichter]

Java has trace flags for Kerberos debugging -- not easy to understand but at least you can compare OK/KO scenarios and see where the damn thing fails >> -Djava.security.debug=gssloginconfig,configfile,configparser‌​,logincontext and -Dsun.security.krb5.debug=true

[Samson Scharfrichter]

For C code e.g. kinit... I'm not familiar with the output of KRB5_TRACE but it might help. k5wiki.kerberos.org/wiki/Debugging_tips

[T-Heron]

You have no service principal defined in your ktpass syntax. What you have there listed instead is a user principal. See my article for a good example of ktpass syntax (about halfway down): social.technet.microsoft.com/wiki/contents/articles/…

[T-Heron]

What is the web URL the clients are going to when they hit your JBOSS application? With that, I'll be able to write up a detailed answer on how to make this work.

[Spezieh]

@Samson Scharfrichter I added the parameters but it does not do deliver more than my default debug output. I add parts of the Logs to my mainquestion.

[Spezieh]

@T.Heron Somehow the application was able to use this UPN and its keytab with RC4 already. We have some SPNs (http/myapp.my.domain) too and have the same results with it. I used the user in the examples here because i experience the same problem for it with KINIT. So i guess its not a problem in the application but with the keytab itself. BTW thanks for the article. Im going to check it now

[Samson Scharfrichter]

My 2 cents: disable UDP. I have heard horror stories of bizarre errors that disappeared after forcing TCP for Kerberos clients...

[T-Heron]

True. And if you are using Active Directory 2008 or above, TCP is always tried first because the MaxPacketSize default is set 0 in that version and all newer versions. Per: support.microsoft.com/en-us/help/244474/…