Network Deployment (Distributed operating systems), v8.0 > Reference > Troubleshoot tips


SPNEGO troubleshooting tips


New feature

With WAS v8.0 we can use High Performance Extensible Logging (HPEL) instead of...

With HPEL, we access log information using the LogViewer tool.


SPNEGO issues and their possible solutions



Unable to resolve the Kerberos principal name

If you are unable to resolve the Kerberos principal name, as shown in the following trace example: 

[11/11/03 1:42:29:795 EST] 1d01b21e GetKrbToken   > Negotiation (GSS): Begin handshake
[11/11/03 1:42:29:795 EST] 1d01b21e Context
      > GSS Context init, servername:HTTP@johnwang5.jwcmd.com
[11/11/03 1:42:29:866 EST] 1d01b21e TraceNLS      u No message text associated with key Error.getting.the.Token, .GSS.Exception:org.ietf.jgss.GSSException,.major.code:.13,.minor.code:.0
 major.string:.Invalid.credentials
 minor.string:.Cannot.get.credential.from.JAAS.Subject.for.principal:.HTTP/192.168.0.4@168.0.4 in bundle
com.ibm.ejs.resources.security
[11/11/03 1:42:29:866 EST] 1d01b21e GetKrbToken   E Error getting the Token, GSS Exception:org.ietf.jgss.GSSException,
major code: 13, minor code: 0
 major string: Invalid credentials
 minor string: Cannot get credential from JAAS Subject for principal: HTTP/192.168.0.4@168.0.4
[11/11/03 1:42:29:876 EST] 1d01b21e TraceNLS      u No message text associated with key SpnegoTAI.exits.due.to.an.exception.
in bundle com.ibm.ejs.resources.security
[11/11/03 1:42:29:876 EST] 1d01b21e SpnegoTAI     E SpnegoTAI exits due to an exception.

add the IP address of the server in its host file. We must also recycle the application server to load the new host file.


WAS and the time on the AD domain controller are not synchronized within 5 minutes

The trace.log file for this issue is similar to the following: 

[11/11/03 1:44:09:499 EST] 1d01b21e GetKrbToken   > Negotiation (GSS): Begin handshake
[11/11/03 1:44:09:499 EST] 1d01b21e Context
      > GSS Context init, servername:HTTP@backendrc4.ibm.net
[11/11/03 1:44:09:499 EST] 1d01b21e Context
      > GSS Context init, done.
[11/11/03 1:44:09:679 EST] 1d01b21e SpnegoTAI     > Server response token as follows...
0000:  6082014f 06062b06 01050502 a1820143     `?.O..+.....¡?.C
0010:  3082013f a0030a01 01a10b06 092a8648     0?.? ....¡...*?H
0020:  82f71201 0202a282 01290482 01256082     ?÷....¢?.).?.%`?
0030:  01210609 2a864886 f7120102 0203007e
    .!..*?H?÷......~
0040:  82011030 82010ca0 03020105 a1030201     ?..0?.. ....¡...
0050:  1ea41118 0f323030 33313131 31303634     .¤...20031111064
0060:  3430395a a5050203 0a3548a6 03020125     409Z¥....5H¦...%
0070:  a90b1b09 4a57434d 442e434f 4daa2630     ©.....IBM.NETª&0
0080:  24a00302 0100a11d 301b1b04 48545450     $ ....¡.0...HTTP
0090:  1b136a6f 686e7761 6e67352e 6a77636d
    ..backendrc4.ibm
00a0:  642e636f 6dab81ab 1b81a86f 72672e69     .net.«?«.?¨org.i
00b0:  6574662e 6a677373 2e475353 45786365
     etf.jgss.GSSExce
00c0:  7074696f 6e2c206d 616a6f72 20636f64
     ption, major cod
00d0:  653a2031 302c206d 696e6f72 20636f64
     e: 10, minor cod
00e0:  653a2033 370a096d 616a6f72 20737472
     e: 37..major str
00f0:  696e673a 20446566 65637469 76652074
     ing: Defective t
0100:  6f6b656e 0a096d69 6e6f7220 73747269
     oken..minor stri
0110:  6e673a20 436c6965 6e742074 696d6520
     ng: Client time
0120:  54756573 6461792c 204e6f76 656d6265     Tuesday, Novembe
0130:  72203131 2c203230 30332061 7420313a
    r 11, 2003 at 1:
0140:  33353a30 3120414d 20746f6f 20736b65     35:01 AM too ske
0150:  776564                                  wed

You can fix this issue in one of two ways. The preferred method is to synchronize the WebSphere system time to within 5 minutes of the time of the AD server. A best practice is to use a time server to keep all of the systems synchronized. Alternatively, you can also add or adjust the clockskew parameter in the Kerberos configuration file. Note that the default is 300 seconds (5 minutes).


No factory is available to create name for mechanism 1.3.6.1.5.5.2

If the systemout.log file contains an exception error similar to the following: 

[4/8/05 22:51:24:542 EDT] 5003e481 SystemOut
    O [JGSS_DBG_PROV] Provider IBMJGSSProvider version 1.01
does not support mech 1.3.6.1.5.5.2
[4/8/05 22:51:24:582 EDT] 5003e481 ServerCredent E com.ibm.issw.spnegoTAI.ServerCredential initialize() SPNEGO014:
Kerberos initialization Failure: org.ietf.jgss.GSSException, major code: 2, minor code: 0
 major string: Unsupported mechanism
 minor string: No factory available to create name for mechanism 1.3.6.1.5.5.2
 at com.ibm.security.jgss.i18n.I18NException.throwGSSException(I18NException.java:30)
 at com.ibm.security.jgss.GSSManagerImpl.a(GSSManagerImpl.java:36)
 at com.ibm.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:217)
 at com.ibm.security.jgss.GSSCredentialImpl.
<init>(GSSCredentialImpl.java:264)
.
.

make sure that the java.security file contains the IBMSPNEGO security provider and is defined correctly. It should contain a line similar to the following: 

security.provider.6=com.ibm.security.jgss.mech.spnego.IBMSPNEGO


A Kerberos error is received while decoding and verifying the SPNEGO token

You might receive the following exception error as the Java Generic Security Service (JGSS) library attempts to process the SPNEGO token: 

Error authenticating request. Reporting to client Major code = 11, Minor code = 31
org.ietf.jgss.GSSException, major code: 11, minor code: 31
 major string: General failure, unspecified at GSSAPI level  minor string: Kerberos error while decoding and verifying token: com.ibm.security.krb5.internal.KrbException, status code: 31
 message: Integrity check on decrypted field failed

This error is caused when the ticket is encoded by using one key and then an attempt is made to decode the ticket by using another key. There are number of possible explanations for this:

If the problem is with the keytab file, then fix it. If the problem is with multiple SPN definitions, remove the extra or conflicting SPN, confirm that the SPN is no longer registered with AD, and then add the SPN again. Read about Create a Kerberos service principal name and keytab file for more information. The Active Directory might need to be searched for other entries with SPNs defined that clash with the SPN using an LDAP browser.

To confirm that the SPN is not registered, the following command: 

setspn –l userid
should return with: 
Cannot find account userid

If the userid and keytab are for DES-CBC-MD5, after you create the userid, change the password for the userid and then create the keytab file. If you are using Windows Server 2003 upgrade to the latest version of ktpass.


Single sign-on does not occur

When trace is turned on, the following error message might appear: 

Client sent back a non-SPNEGO authentication header, SpnegoTAI exits

A possible reason for this error is that the client is returning an NT LAN manager (NTLM) response to the authorize challenge, not an SPNEGO token. This can occur due to one or more of the following issues:



Unable to use sign-on (SSO) with RC4-HMAC encryption

When trace is turned on you might receive the following error message: 

com.ibm.security.krb5.internal.crypto.KrbCryptoException, status code: 0
message: Checksum error; received checksum does not match computed checksum

Some possible reasons for this error include the following



Credential delegation might not work due to an invalid option in the ticket request

When trace is turned on, if the following error message appears: 

com.ibm.security.krb5.KrbException, status code: 101 message: Invalid option in ticket request

the Kerberos configuration file is not properly configured. Ensure that neither renewable nor proxiable are set to true.


Problems when accessing a protected URL through the SPNEGO SSO

You might receive an error similar to the following when accessing a protected URL through the SPNEGO SSO: 

Bad Request

Your browser sent a request that this server could not understand.
Size of request header field exceeds server limit.

Authorization: Negotiate YII……

This message is generated by the Apache/IBM HTTP Server, and indicates that the authorization header that your browser has returned is too large. The long string that follows the word Negotiate is the SPNEGO token. This SPNEGO token is a wrapper of the Windows Kerberos token. Windows includes the PAC information of the user in the Kerberos token. The more security groups that the user belongs to, the more PAC information is inserted in the Kerberos token, and the larger SPNEGO becomes. IBM HTTP Server 2.0 (as well as Apache 2.0 and IBM HTTP Server 6.0) limit the size of any acceptable HTTP header to be 8K. In Windows domains with many groups, and with user membership in many groups, the size of the user's SPNEGO token can exceed the 8K limit.

If possible, reduce the number of security groups that the user is a member of. IBM HTTP Server 2.0.47 cumulative fix PK01070 allows for HTTP header sizes up to and beyond the Microsoft limit of 12K.

After applying the fix specify the LimitRequestFieldSize parameter in the //publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/ d.conf file to increase the size of allowable headers from the default of 8192.


Even with JGSS tracing disabled, some KRB_DBG_KDC messages appear in the SystemOut.log

While most of the JGSS tracing is controlled by the com.ibm.security.jgss.debug property, a small set of messages are controlled by the com.ibm.security.krb5.Krb5Debug property. The default value of the krb5 property is to emit some messages to SystemOut.log.

To remove all KRB_DBG_KDC messages from the SystemOut.log, set the JVM property to -Dcom.ibm.security.krb5.Krb5Debug=none.


ktpass is unable to find the userid

When using ktpass, you might receive an error message similar to the following: 

DsCrackNames returned 0x2 in the name entry for server3
Failed getting target domain for specified user.

In an Active Directory forest, the userid lookup used by the ktpass.exe does not have a default domain name to be used. This does not occur when the domain controller is not in a forest.

To fix this problem, instead of specifying option -mapUser userid, use -mapUser userid@domain instead. For example, specify –mapUser server3@WIBM.NET.


Credential delegation does not work for any userid

If in the trace.log, an error exception similar to the following appears: 

> com.ibm.issw.spnegoTAI.Context getDelegateCred() Entry
d com.ibm.issw.spnegoTAI.Context getDelegateCred() unable to get Delegate Credential

< com.ibm.issw.spnegoTAI.Context getDelegateCred() Exit
W com.ibm.issw.spnegoTAI.SpnegoHandler handleRequest() SPNEGO021: No delegated credentials were found for user: nauser@NA.IBM.NET

the domain account on which the SPN is attached does not have the “Account is trusted for Delegation” property defined.

To address this issue, ensure that the domain account does define the “Account is trusted for Delegation” property.


A user is challenged for credentials even though the browser is properly configured

A user might be challenged for credentials even though the browser is configured properly. The TAI might have obtained the user's credentials from the SPNEGO token, and the user might have failed to log in. In the trace.log an exception error similar to the following appears: 

< com.ibm.issw.spnegoTAI.SpnegoTAI getAuthenticatedUsername(): lansche Exit
d com.ibm.issw.spnegoTAI.SpnegoTAI negotiateValidateandEstablishTrust(): Handshake finished, sending 200 :SC_OK

< com.ibm.issw.spnegoTAI.SpnegoTAI negotiateAndValidateEstablishedTrust Exit
A SECJ0222E: An unexpected exception occurred when trying to create a LoginContext. The LoginModule alias is system.WEB_INBOUND
and the exception is...

The userid (which is lansche in the example above) does not exist in the registry in use by WebSphere. This problem can be caused when:

To fix this problem, ensure that the user that is being asserted to WAS by the TAI is the configured WebSphere registry.


A user using the Novell client cannot authenticate using SPNEGO

If a user using the Novell client cannot authenticate using SPNEGO they might receive a “An NTLM token is received.” message.

The user might have logged into the Novell Client but did not perform a Windows Kerberos login (this can be confirmed using the Kerbtray utility). If a user has logged onto the Windows domain and has a Kerberos ticket, the user cannot utilize SPNEGO authentication.

To fix this problem, remove the Novell client and use the default Windows domain login.


Access SPNEGO sites via some caching proxy servers can cause SPNEGO authentication issues

If you access SPNEGO sites via some caching proxy servers you might not be able to authenticate using SPNEGO. The message “SPNEGO authentication not supported on this client” might be displayed.

It is possible that the caching proxy is changing the hostname that returns on the HTTP 401 Authenticate Negotiate response.

If we have this issue, contact your proxy vendor for a possible solution.


Virtual Private Networks (VPN) software and firewalls might interfere with SPNEGO operations

You might experience problems with VPN software and firewalls that might interfere with SPNEGO operations.

To resolve these issues, contact your VPN and or firewall vendors for any configuration changes that might be necessary.


Possible browser issue when accessing a SPNEGO protected application

There might be a browser issue if you log onto a domain machine using one password (for example, passwordA) and then log onto a second domain machine by changing your original password (for example, you might change your password on the second domain machine to passwordB).

Once you return to the original domain machine, you might not be able to obtain either a SPNEGO/Kerberos or an NTLM response to the Negotiate challenge. After two attempts, the browser displays an HTTP 404 error message.

To resolve this issue, log off the original domain machine and log back on with the new password (passwordB).


Possible browser issue with Internet Explorer 6.0

When WAS is configured with SPNEGO and fallback is enabled for a request, Internet Explorer 6.0 might fail to login to the form login pages.

To avoid this situation, complete one of the following actions:



Error pages defined for the NTLMTokenReceivedPage or the SpnegoNotSupportedPage properties do load from an http:// URL

The error pages defined for the NTLMTokenReceivedPage or the SpnegoNotSupportedPage properties do load from an http:// URL. The following trace message might appear: 

Could not load the SPNEGO not supported content, going with the default content.
Exception received: java.net.ProtocolException: Server redirected too many  times (20)

This issue occurs when the loaded file performs an automatic redirect. It is not possible to both load the file from a web server and also use an automatic redirection

To resolve this issue, load the content from a file:/// URL, not an http:// URL.


A client browser SSO attempt fails to authenticate with WAS when you use a SPNEGO token with Microsoft Internet Security Acceleration Server

When tracing is enabled, the following messages exist: 

com.ibm.ws.security.spnego.SpnegoHandler isAuthHeaderNotSPNEGO
ENTRY Negotiate



       

com.ibm.ws.security.spnego.SpnegoHandler isAuthHeaderNotSPNEGO
Client sent back a non-SPNEGO authentication header

When a Microsoft Internet Security Acceleration Server (ISA) exists between a client browser and WAS, ISA might intercept the SPNEGO authentication header from the client browser request. ISA converts the SPNEGO object identifier (OID) to a Kerberos OID. The authentication attempt with WAS fails because the SPNEGO OID has been converted and is now missing.

For information about how to fix this issue, see the "Users cannot access a web site that is published in ISA Server 2006 if the web site accepts only the SPNEGO authentication package" topic on the Microsoft Corporation Support site.


Microsoft Windows v7 and Internet Explorer v8 disables DES encryption type by default

If you are using Microsoft Windows v7 with Internet Explorer v8, and you cannot get SPNEGO Single Sign On (SSO) to function, it could be because Windows Version 7 disabled DES encryption type for Kerberos by default. When trace is turned on the following message appears: 

Client sent back a non-SPNEGO authentication header....

It is recommended that you change your encryption type to RC4-HMAC or to AES. If you still choose to use the DES encryption type, however, refer to the Windows 7 documentation for help on how to enable the DES encryption type.

The following is an example of how to change your encryption type from DES to RC4:

  1. Make sure the Microsoft Active Directory account that you use to map to the SPN does not have the Use DES encryption type for this account box checked. In the Microsoft Active Directory machine:

    1. Click Start > Programs > Administrative Tools > Active Directory Users and Computers > Users .

    2. Click on the Microsoft Active Directory account that you use to map to the SPN.

    3. Select the account, and then make sure that the Use DES encryption type for this account box is not checked.

  2. Reset the password for the Microsoft Active Directory account that you use to map to the SPN. We can reset it to the same password.
  3. Regenerate the keytab with the RC4 encryption type.
  4. Copy the new keytab file to the WAS servers.
  5. Update the Kerberos configuration (krb5.ini/krb5.conf) files to list RC4 first for the default_tkt_enctypes and default_tgs_enctypes attributes.

    For example: 

    default_tkt_enctypes = rc4-hmac des-cbc-md5
default_tgs_enctypes = rc4-hmac des-cbc-md5
    .

  6. Stop and restart all WAS servers.

If we have more than one Microsoft Active Directory account that you use to map to different SPNs, then repeat steps 1 through 3 above for each SPN and the merging of all the keytab files.


SPNEGO authentication fails when a web browser does not send a web form with the user id and password

A form login fails when the browser does not send user id or password. This condition can occur when SPNEGO authentication fails and SPNEGO fallback occurs. We can work around this condition as described below.

If you are using Microsoft Windows XP SP2 with Internet Explorer v6, install the KB902409 fix module plus edit the registry as follows: 

key: HKEY_CURRENT_USER or




  
HKEY_LOCAL_MACHINE\Software\Microsoft\InternetExplorer\Main\FeatureControl
\FEATURE_HTTP_DISABLE_NTLM_PREAUTH_IF_ABORTED_KB902409           
name : Iexplore.exe




        
type : REG_DWORD                                                        
value: 1                                                                
name : Explorer.exe




        
type : REG_DWORD                                                        
value: 1

If you are using Microsoft Windows XP SP3 with Internet Explorer Version 6, install the KB902409 fix module.

If you are using Microsoft Windows v7 with Internet Explorer v8, install the KB902409 fix module and edit the registry as follows: 

key  :                                                                  
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\InternetSettings
name : DisableNTLMPreAuth




  
type : REG_DWORD                                                        
value: 1


Correcting realm change issues and subsequent SPNEGO logon failures

In a SPNEGO web authentication environment in which a realm change is to occur, errors can occur in making the realm change, which then can lead to subsequent SPNEGO logon failures. The steps to correct these errors is as follows:

Realm Change: The realm can consist of identities in the file-based repository that is built into the system, in one or more external repositories, or in both the built-in, file-based repository and one or more external repositories. We can change realms in a SPNEGO environment by changing the name as follows:

  1. In the admin console, click Security > Global security > Kerberos configuration > SPNEGO Web authentication and uncheck the Enable SPNEGO checkbox.

  2. In the console, click...

      Security | Global security

  3. Under User account repository, select Federated repositories from the Available realm definitions field and click Configure.

  4. When you finish adding or updating your federated repository, to validate changes...

      Security > Global security > Apply

  5. If we have removed a user/role identity and want it to function successfully under the new realm, add it back to the new realm after the realm name change.

  6. Restart the dmgr to ensure that these the user/role identity can function under the new realm.

SPNEGO Web authentication: To ensure that the user/role changes can successfully logon under this new realm, perform the following:

  1. Ensure that the application server is running.

  2. In the admin console, click Security > Global security

  3. Under Authentication, highlight the radio button for LTPA.

    The Kerberos and LTPA option is not be selectable unless we have configured Kerberos prior to this step. For SPNEGO, you ONLY need to use the LTPA option.

  4. Click Apply. Users under the new realm can now SPNEGO logon.


Troubleshoot security configurations
Users cannot access a web site that is published in ISA Server 2006 if the web site accepts only the SPNEGO authentication package

+

Search Tips   |   Advanced Search