Traditional WebSphere SPNEGO authentication fails - SECJ0056E: Authentication failed for reason Cannot find the user

Question

On Traditional WebSphere(tWAS), when logging in to the admin console using a SPNEGO token, authentication fails with the following message:

SECJ0056E: Authentication failed for reason Cannot find the user: [email protected]

I have standalone LDAP configured on the tWAS server to use the same host as my KDC, which is the same host that I create the SPNEGO token from. So the user does exist in the LDAP, and the user registry should be able to find the user.

WebSphere Platform ND 8.5.5.23

The SPNEGO token appears to be valid and I see a security subject is created in the trace.log and has the expected user.

SubjectHelper <  getKerberosAuthnTokenFromSubject Exit
                                 Subject:
    Principal: [email protected]

What am I missing?

Answer 1

Solution

My issue was fixed by selecting Trim Kerberos realm from principal name. This is done in the admin console on the SPNEGO web authentication panel.

Documented here: https://www.ibm.com/docs/en/was-nd/8.5.5?topic=ecswauac-adding-modifying-spnego-web-authentication-filters-using-administrative-console

Detailed Explanation:

I ultimately narrowed down the issue by seeing how the LDAP was being searched from the tWAS LdapRegistry code: LdapRegistryI 3 Filter: (&([email protected])(objectcategory=user))

I double checked the sAMAccountName on the AD machine itself, and there I found that sAMAccountName=user1 Aha! so at that point it clicked that the LDAPRegistry code doesn't know that [email protected] is user1.

The solution took me awhile to realize because I thought I already had the trimming enabled. What led me to believe this was because I saw this in the trace: AuthMechanism 3 trimUserName: true

As it turns out there are two different trimUserName attributes in the security.xml, one under the security:KRB5 authMechanism entry and another under the security:SPNEGO authMechanism entry.

The attribute was set to true under security:KRB5 (which is what fooled me), but was false under security:SPNEGO

After applying the solution I verified the username trimming was happening as expected by seeing the following trace statement: SpnegoHandler < com.ibm.ws.security.spnego.SpnegoHandler trimUsername: user1 RETURN

Hope this helps out others!