SPNEGO single-sign-on errors observed after installing Novembers 11, 2022 Microsoft Security Fixes

Troubleshooting

Problem

Microsoft®️issued a November 11, 2022 security fix against their Microsoft Windows™️ Operating System which included a change that caused issues with SPNEGO single-sign-on. This technote is designed to assist you in identifying the problems that may arise when using SPNEGO with WebSphere Application Server, and offers some corrective actions you can take. You may still need to work with your Windows or Active Directory administrator for assistance.

SPNEGO SSO is not working correctly due to a recent Microsoft security patch.
Please see the following externally linked information on the November 2022 patch Microsoft has released.

Windows Kerberos RC4-HMAC Elevation of Privilege Vulnerability CVE-2022-37966
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-37966

KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966
https://support.microsoft.com/en-us/topic/kb5021131-how-to-manage-the-kerberos-protocol-changes-related-to-cve-2022-37966-fd837ac3-cdec-4e76-a6ec-86e67501407d

Symptom

Cause

If you are using keytab that contains an entry with RC4-HMAC Encryption Type, the SPNEGO MustGather tracing will reveal either of the following errors.

Error "Illegal key size"

[JGSS_DBG_CTX] WebContainer : 1 Error authenticating request. Reporting to client

Major code = 11, Minor code = 0

org.ietf.jgss.GSSException, major code: 11, minor code: 0

major string: General failure, unspecified at GSSAPI level

minor string: Kerberos error while decoding and verifying token: com.ibm.security.krb5.internal.crypto.KrbCryptoException, status code: 0

message: java.security.InvalidKeyException: Illegal key size

Error "No key of type: 23"

[JGSS_DBG_CTX] WebContainer : 1 Error authenticating request. Reporting to client

Major code = 11, Minor code = 45

org.ietf.jgss.GSSException, major code: 11, minor code: 45

major string: General failure, unspecified at GSSAPI level

minor string: Kerberos error while decoding and verifying token: com.ibm.security.krb5.KrbException, status code: 45

message: No key of type: 23

* The numeral 23 in the second error refers to the keytype of RC4-HMAC

Diagnosing The Problem

First configure both the JVM custom properties, and separately the trace string, as defined in the following steps:

WebSphere Application Server traditional

Setup SPNEGO debugging output:

In the administrative console, navigate to Servers > [+] Server Types > WebSphere Application Servers > server_name.
Under Server Infrastructure, expand [+] Java and process management. Click Process Definition > Java Virtual Machine > Custom Properties.
Create two new Java ™ Virtual Machine (JVM) properties, assuming the properties don't already exist

    Name: com.ibm.security.jgss.debug
    Value: all

    Name: com.ibm.security.krb5.Krb5Debug
    Value: all
After creating the properties, save the changes.

Set up the WebSphere Application Server traditional SPNEGO tracing:

Expand TroubleShooting > Logs and Trace > server_name.
Click Diagnostic Trace Service.
1. Increase the Maximum Number of Historical Files from 1 to 10.
2. Click Apply (you can save the changes, or wait until after the next steps)
Next click Change Log Detail Levels.
1. Clear the trace string in the text box. Replace it with the following:
  *=info:SecurityDomain=all:com.ibm.ws.security.*=all:com.ibm.websphere.security.*=all:com.ibm.websphere.wim.*=all:com.ibm.wsspi.wim.*=all:com.ibm.ws.wim.*=all
2. Click OK (or Apply), and Save.
Stop the server
Delete or rename all the logs in the profile_home/logs directory.
By clearing the logs before restarting and then re-creating the issue, you will have a fresh and concise set of data to review, or otherwise provide to IBM Support
Next, restart the WebSphere Application Server instance
Reproduce the problem

If you need to be captured on Liberty Server. Please follow the given below link.

MustGather: SPNEGO problems on WebSphere Liberty

https://www.ibm.com/support/pages/node/559647

The resulting traces should contain one of the following errors if the issues are occurring

java.security.InvalidKeyException: Illegal key size
No key of type: 23

Resolving The Problem

Clients make two types of requests (KDC-REQ) to the KDC: AS-REQs and TGS-REQs. The client uses the AS-REQ to obtain initial tickets (typically a Ticket-Granting Ticket (TGT)), and uses the TGS-REQ to obtain service tickets. Please see the detailed flow in the following link; scroll to the section (and diagram) entitled "How Does SPNEGO Works in the WebSphere Application Server?".

How to Setup Single Sign-On (SSO) for HTTP requests using SPNEGO authentication in WebSphere Application Server
https://www.ibm.com/support/pages/node/6431271

Use the command klist tickets on your user's operating system (not the server's) to verify the encryption type of the Kerberos tickets the user has received. Normally tickets associated with WebSphere Application Server will start with HTTP/ for the Server attribute.

klist tickets

Issue 1, Identical Encryption and Key Types:
If you see, KerbTicket Encryption Type and Session Key Type are the same, a newly generated keytab file (with AES256-SHA1 only) is required.

Example entry seen in output from command klist tickets:

If KDC is not using RC4 and KDC is configured only with AES-256-CTS-HMAC-SHA1-96 encryption type, you will see the klist ticket output in the following example (the encryption and key types are highlighted in red here to assist in what you are looking for).

Client: websphereadmin @ WASSEC-L2.LOCAL

        Server: HTTP/waskdc1.wassec-l2.local/wassec-l2.local @ WASSEC-L2.LOCAL

        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

        Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize

        Start Time: 11/30/2022 11:18:03 (local)

        End Time: 11/30/2022 21:18:03 (local)

        Renew Time: 12/7/2022 11:18:03 (local)

        Session Key Type: AES-256-CTS-HMAC-SHA1-96

        Cache Flags: 0

        Kdc Called: kdc1.wassec-l2.local

Please make sure the following configuration and AD side.

For the Mapped SPN account, please use higher encryption keys, check the option “This account support AES 256 encryptions” in user properties, and Reset the password.

For example, please see the following screenshot.

Example Command for ktpass

ktpass -princ HTTP/servera.ibm.com@WASSEC-L2.LOCAL -ptype KRB5_NT_PRINCIPAL -mapUser spnmapuser -mapOp set -pass password123 -out c:\was-keytab\WASServer.keytab -crypto AES256-SHA1 +DumpSalt -kvno 0

Note: Typically, these klist and ktpass commands are run by Microsoft AD admins and belong to Microsoft. Please check with your Microsoft Admins or Microsoft support for further questions and investigation on the KDC side or client-side because the client pc requests a Service ticket from the Kerberos Ticket Granting Service (TGS) for the SPN requested by the client PC browser.

Ensure krb5.conf or krb4.ini Kerberos configuration file is configured with AES256 encryption type in WebSphere Application Server.

$AdminTask createKrbConfigFile {-krbPath /spnego/krb5.conf -realm WASSEC-L2.LOCAL -kdcHost waskdc1.fyre.ibm.com -dns fyre.ibm.com -encryption aes256-cts-hmac-sha1-96 -keytabPath /spnego/WASServer.keytab}

Sample of Kerberos Configuration file Krb5.ini & Krb5.conf

image-20230221183544-2

Issue 2, Different Encryption and Key Types:
If you see klist tickets as follows where KerbTicket Encryption Type as RC4-HMAC, and the Session Key Type as AES-256-CTS-HMAC-SHA1-96, you need to also generate a keytab, but with the argument -crypto All to workaround the issue.

Example entry seen in output from command klist tickets:
The command output shows in red that the encryption and key types differ.

Client: websphereadmin @ WASSEC-L2.LOCAL

        Server: HTTP/waskdc1.wassec-l2.local/wassec-l2.local @ WASSEC-L2.LOCAL

        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

        Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize

        Start Time: 11/30/2022 11:18:03 (local)

        End Time: 11/30/2022 21:18:03 (local)

        Renew Time: 12/7/2022 11:18:03 (local)

        Session Key Type: AES-256-CTS-HMAC-SHA1-96

        Cache Flags: 0

        Kdc Called: kdc1.wassec-l2.local

Note: If you have further questions about ticket behavior, you need to work with your Microsoft Admin or Support for specifics as to why the tickets' KerbTicket Encryption Type and the Session Key Type differ in values

Please make sure the following configuration and AD side.

For the Mapped SPN account, please use higher encryption keys, check the option “This account support AES 256 encryptions” in user properties, and Reset the password.

For example, please see the following screenshot.

image-20230221183039-1

Example Command for ktpass

ktpass -princ HTTP/servera.ibm.com@WASSEC-L2.LOCAL -ptype KRB5_NT_PRINCIPAL -mapUser spnmapuser -mapOp set -pass Passw0rd@$# -out c:\was-keytab\WASServer.keytab -crypto All +DumpSalt -kvno 0

Ensure krb5.conf or krb4.ini Kerberos configuration file is configured with AES256 encryption type in WebSphere Application Server.

Sample of Kerberos Configuration file Krb5.ini & Krb5.conf

image-20230221183544-2

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"ARM Category":[{"code":"a8m50000000Ccy2AAC","label":"WebSphere Application Server traditional-All Platforms-\u003ESecurity-\u003ESSO-\u003ESPNEGO\/Kerberos"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Tips

SPNEGO single-sign-on errors observed after installing Novembers 11, 2022 Microsoft Security Fixes

Troubleshooting

Problem

Symptom

Cause

Diagnosing The Problem

Resolving The Problem

Document Location

Was this topic helpful?

Document Information

UID

Share your feedback

Need support?