PK46336: The SPNEGO trust association interceptor (TAI) receives a NTLM token instead of a SPNEGO token

APAR status

• Closed as documentation error.

Error description

• SPNEGO works if WebSphere Application Server is running on a
  Microsoft Windows server. However, SPNEGO might not work
  with a UNIX-based server. On a UNIX-based server, the
  SPNEGO trust association interceptor (TAI) might receive a
  NTLM token on a UNIX-based server instead of a SPNEGO token.
  The client, or browser, might receive a 401 error.
  
  The root cause of this problem is multiple accounts using the
  same service principle name (SPN). This problem caused the
  Kerberos Key Distribution Center (KDC) to become confused. It
  is likely that the KDC cannot determine which secret key to
  use when encrypting the service ticket. Or, the KDC used the
  wrong secret key and negotiation fails, which results in an
  NTLM token being sent.
  
  To resolve the problem, you can export an LDAP Data Interchange
  Format (LDIF) file from Microsoft Active Directory and
  search for multiple accounts that use the same SPN. Use the
  following command: ldifde -f filename -s <name of dc>
  
  Using the setspn -d command, you can delete the SPN for the
  computer account. After that, Microsoft Internet Explorer
  can send a Kerberos token using SPNEGO instead of an NTLM
  token.
  

Local fix

• Remove multiple service accounts from the Lightweight Directory
  Access Protocol (LDAP) registry as explained.
  

Problem summary

• SUMMARY
  This APAR affects users of WebSphere Application Server Version
  6.1 who are finding that the Web browser client sends a NTLM
  token instead of a SPNEGO token to WebSphere Application Server.
  
  PROBLEM DESCRIPTION:
  The documentation does not describe the conditions under which
  the Web browser client sends a NTLM token instead of a SPNEGO
  token to WebSphere Application Server.
  
  PROBLEM SUMMARY:
  The Kerberos service principal name (SPN) has been defined to
  Microsoft Active Directory more than once. Either another user
  ID is defined with the same SPN or another user ID is defined
  with the same SPN, but one SPN includes a port number. The
  following categories describe these conditions:
  
  Same SPN but with differing user IDs
  setspn -a HTTP/myappserver.austin.ibm.com user1
  setspn -a HTTP/myappserver.austin.ibm.com user2
  
  Same SPN and same user IDs, but one ID is defined with a port
  number
  setspn -a HTTP/myappserver.austin.ibm.com user3
  setspn -a HTTP/myappserver.austin.ibm.com:9080 user3
  The documentation does not describe these conditions nor does
  the documentation provide a method for determining these
  conditions.
  

Problem conclusion

• The "Problem: Single sign-on is not occurring" section within
  the "SPNEGO trust association interceptor (TAI) troubleshooting
  tips" topic has been updated to include the following
  information in the Description section:
  The Kerberos service principal name (SPN) has been defined to
  the Active Directory more than once. You have either another
  user ID defined with the same SPN or another user ID defined
  with the same SPN with a port number defined. The following
  categories describe these conditions:
  
  Same SPN but with differing user IDs
  setspn -a HTTP/myappserver.austin.ibm.com user1
  setspn -a HTTP/myappserver.austin.ibm.com user2
  
  Same SPN and same user IDs, one with a port number defined
  setspn -a HTTP/myappserver.austin.ibm.com user3
  setspn -a HTTP/myappserver.austin.ibm.com:9080 user3
  
  The following information has been added to the User action
  section:
  
  If the problem is with either category of multiple SPN
  definitions, then remove the extra or conflicting SPN, confirm
  that the SPN is no longer registered with the Active Directory,
  and then add the SPN. You can search the Active Directory for
  other SPN entries that are causing multiple SPN definitions. The
  following commands are useful to determine multiple SPN
  definitions:
  
  setspn ?L userid
  Returns the message, cannot find account userid, if the SPN is
  not registered.
  
  setspn -L
  Displays the SPNs that exist.
  
  Date that information will be available externally to customers:
  The modified documentation will be available in the 3rd quarter
  update to the information centers, which is scheduled to occur
  on or before September 30, 2007.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels