Multiple users started experiencing Kerberos failures, but not all users
Article ID: 259434
Updated On:
Products
Issue/Introduction
Suddenly a set of users experienced Kerberos failures. Most other users remained fine. A quick check of the Access Gateway Agent traces showed these error messages:
[01/29/2023][12:31:01][29191][140531387557632][2541b827-9dccd3bb-1a8e5650-cb7e87f1-5a38c99c-396][SmKcc::getKerberosToken][Failed to get authorization header from context]
[01/29/2023][12:31:01][29191][140531387557632][2541b827-9dccd3bb-1a8e5650-cb7e87f1-5a38c99c-396][SmKcc::getCredentials][Failed to obtain kerberos token]
But tokens were available on the workstations.
Ex.
[Working User] (Session Key using RC4-HMAC)
Client: XXXXXX @ US.AD.CORPORATE.COM
Server: HTTP/isecure-gateway.company.com @ US.AD.CORPORATE.COM
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
Start Time: 1/29/2023 20:40:50 (local)
End Time: 1/30/2023 4:25:09 (local)
Renew Time: 2/5/2023 18:25:09 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
Cache Flags: 0
Kdc Called: server.us.ad.corporate.com
Cause
Kerberos tracing was enabled
export KRB5_TRACE=/apps/CA/secure-proxy/krb5/kerbtrace.log
Here is an example:
Decrypted AP-REQ with specified server principal HTTP/[email protected]: rc4-hmac/7A9B
AP-REQ ticket: [email protected] -> HTTP/[email protected], session key aes256-cts/7F9A
Retrieving HTTP/[email protected] from FILE://apps/CA/secure-proxy/krb5-utsmwa.keytab (vno 0, enctype 0) with result: 0/Success
Retrieving HTTP/[email protected] from FILE://apps/CA/secure-proxy/krb5-utsmwa.keytab (vno 14, enctype rc4-hmac) with result: 0/Success
Decrypted AP-REQ with specified server principal HTTP/[email protected]: rc4-hmac/7A9B
AP-REQ ticket: [email protected] -> HTTP/[email protected], session key rc4-hmac/F3B0
Negotiated enctype based on authenticator: rc4-hmac
Authenticator contains subkey: rc4-hmac/935D
Resolving unique ccache of type MEMORY
Initializing MEMORY:Brv4blM with default princ [email protected]
Storing [email protected] -> krbtgt/[email protected] in MEMORY:Brv4blM
Creating AP-REP, time 1675050991.14314, subkey rc4-hmac/935D, seqnum 981402701
Getting credentials [email protected] -> smps/[email protected] using MEMORY:Brv4blM
Retrieving [email protected] -> smps/[email protected] from MEMORY:Brv4blM with result: -1765328243/Matching credential not found
Retrieving [email protected] -> krbtgt/[email protected] from MEMORY:Brv4blM with result: 0/Success
Staring with TGT for client realm: [email protected] -> krbtgt/[email protected]
You can see in the trace two different encrytion types were present, but only rc4-hmac was working as a token for the Access Gateway. AES256 was not.
This was confirmed by doing a klist on the working user's workstation:
[Working User] (Session Key using RC4-HMAC)
Client: XXXXXX @ US.AD.CORPORATE.COM
Server: HTTP/isecure-gateway.company.com @ US.AD.CORPORATE.COM
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
Start Time: 1/29/2023 20:40:50 (local)
End Time: 1/30/2023 4:25:09 (local)
Renew Time: 2/5/2023 18:25:09 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
Cache Flags: 0
Kdc Called: server.us.ad.corporate.com
Resolution
The encryption types are controlled in the KRB5.conf file.
Default locations
Windows - c:\windows\krb5,ini
Linux* - /etc/krb5/krb5.conf
* There is an environment variable that specifies the location, KRB5_CONFIG=
Reviewing the file revealed that AES256-cts was commented out, therefore not allowed.
#default_tgs_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
#default_tkt_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
#permitted_enctypes = aes128-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
default_tgs_enctypes = arcfour-hmac-md5
default_tkt_enctypes = arcfour-hmac-md5
permitted_enctypes = arcfour-hmac-md5
Updating this allowed AES256-cts to be accepted on the Access Gateway. There was a corporate change being rolled out to use higher encryptions, that is why only a subset of users were affected. The Access Gateway needed to be updated to support the new encryption, AES256-cts.
Feedback
