TM1 Forum

Hi,

We have successfully implemented SSO multiple times at a number of sites with TM1 Web. Currently, we are upgrading 2 unrelated environments to the latest PA version that also includes latest PA Spreadsheet Services. Software is installed on Windows 2019 OS as a fresh install.

These are the steps that we followed, triple-checked, and tried with multiple servers:
https://www.ibm.com/support/pages/how-c ... spnego-sso

In all cases, SSO is working initially, but then some users are getting sporadic login failures. This is what we see in the WebSphere tm1_messages log after enabling trace.

[KRB_DBG_KDC] KRBError:Default Executor-thread-5: >>>KRBError:
[KRB_DBG_KDC] KRBError:Default Executor-thread-5: sTime is Mon Mar 21 11:29:39 EDT 2022 1647876579000
[KRB_DBG_KDC] KRBError:Default Executor-thread-5: suSec is 768937
[KRB_DBG_KDC] KRBError:Default Executor-thread-5: error code is 31
[KRB_DBG_KDC] KRBError:Default Executor-thread-5: error Message is Integrity check on decrypted field failed
[KRB_DBG_KDC] KRBError:Default Executor-thread-5: msgType is 30

This error corresponds to the 0x1F KRB_AP_ERR_BAD_INTEGRITY code of the 4769 event in the domain controller. We tried recreating keytab/krb5.conf files with different encryption types including all, but it didn't resolve the issue.

Was anyone able to successfully configure PASS SSO ideally with software installed on Windows 2019 OS?
Has anyone experienced a similar issue? Any ideas of how to resolve it would be appreciated.

Thank you,
Alex

Hi Alex,

Are all users able to log in fine initially but then after some interaction disconnected? Or does the problem happen just for some users.

Have you considered

if the kerberos token is bloated causing thresholds to be reach

If the httpheadersize limit is being exceeded. If you can consistently reproduce the error i think tools like fiddler will help you see the headersize.

If it's just occurring for certain users, are those users part of more ad groups then the others users who are working fine

Hi burnstripe,

Thank you for your reply.

Issue is completely random. SSO can work, and then not work for the same user in a few hours, and then succeed again next day. We have a group of test users, and the fail and success users within that group change every day, so not very easy to replicate.

I compared tm1_messages trace between success and failure instances and noticed that the first line that is different between the success and failure logs is as follows:
Success: [JGSS_DBG_CTX] Default Executor-thread-3 Received delegated creds
Failure: [JGSS_DBG_CTX] Default Executor-thread-8 No delegated creds from peer

Failure
[KRB_DBG_TGS] Default Executor-thread-8 >>> KrbApReq: authenticate succeeded.
[JGSS_DBG_CTX] Default Executor-thread-8 Mutual authentication required ? true
[JGSS_DBG_CTX] Default Executor-thread-8 Session key type = rc4-hmac
[JGSS_DBG_CRED] Default Executor-thread-8 Krb5 name type = 1
[JGSS_DBG_CRED] Default Executor-thread-8 Krb5 name type = 2
[JGSS_DBG_CTX] Default Executor-thread-8 Successfully set AuthorizationData to the context.
[JGSS_DBG_CTX] Default Executor-thread-8 Remote subkey type = rc4-hmac
[JGSS_DBG_CTX] Default Executor-thread-8 No delegated creds from peer

Success
[KRB_DBG_TGS] Default Executor-thread-3 >>> KrbApReq: authenticate succeeded.
[JGSS_DBG_CTX] Default Executor-thread-3 Mutual authentication required ? true
[JGSS_DBG_CTX] Default Executor-thread-3 Session key type = rc4-hmac
[JGSS_DBG_CRED] Default Executor-thread-3 Krb5 name type = 1
[JGSS_DBG_CRED] Default Executor-thread-3 Krb5 name type = 2
[JGSS_DBG_CTX] Default Executor-thread-3 Successfully set AuthorizationData to the context.
[JGSS_DBG_CTX] Default Executor-thread-3 Remote subkey type = rc4-hmac
[JGSS_DBG_CTX] Default Executor-thread-3 Received delegated creds

I checked and service account is set as 'Trusted for delegation', so not sure why delegated credentials are not passed from time to time?

I don't think there's any permission issues by the sounds of things. But there's nearly always a pattern just unknown

If a user encounters the issue, does it continue failing for the rest of the session, and if the user were to logout or restart. When they are back connected does kerberos fail or succeed?

Are machine/dc/server clocks in sync?

Is there anything that may be occasionally blocking the request?

Can you monitor the performance of the dc? Perhaps at the time of failure there is a delay in processing the tickets due to high activity.

Perhaps add some monitoring on the DC to help give a clearer picture
https://techcommunity.microsoft.com/t5/ ... a-p/256796

If the issue is encountered it continues to fail for the rest of the session. Logging out of the machine and logging back in sometimes resolves the issue temporarily. We also managed to resolve the issue with one user by issuing 'klist purge' command - purging cached tickets.

Machine/dc/server clocks are in sync.

We are trying to capture a failure trace on DC. Side note: the site is migrating its DCs to 2019 server. Currently there is one 2016 DC and two 2019s. I am not sure if it is contributing to the issue.