javaactive-directorywebspherespnego

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

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: user1@MYDOMAIN.COM

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: user1@MYDOMAIN.COM

What am I missing?

Solution

  • 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: (&(sAMAccountName=user1@MYDOMAIN.COM)(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 user1@MYDOMAIN.COM 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!