Presented here is a list of trouble shooting tips useful in diagnosing Simple and Protected GSS-API Negotiation (SPNEGO) TAI problems and exceptions.
Trace | Use |
---|---|
com.ibm.security.jgss.debug | Set this JVM Custom Property to all to trace through JGSS code. Messages appear in the trace.log file, and SystemOut.log. |
com.ibm.security.krb5.Krb5Debug | Set this JVM Custom Property to all to trace through the Kerberos5-specific JGSS code. Messages appear in the trace.log file, and SystemOut.log. |
com.ibm.ws.security.spnego.* | Set this trace on using the administrative console > troubleshooting > Logging and Tracing > server1 > Change Log Detail Levels > com.ibm.ws.security.spnego.*. Messages appear in the trace.log file. |
Symptom | [2/24/06 13:12:46:093 CST] 00000060 Context 2 com.ibm.ws.security.spnego.Context begin GSSContext accepted [2/24/06 13:12:46:093 CST] 00000060 Context E com.ibm.ws.security.spnego.Context begin CWSPN0011E: An invalid SPNEGO token has been encountered while authenticating a HttpServletRequest: 0000: 60820160 06062b06 01050502 a1820154 `..` ..+. .... ...T 0010: 30820150 a0030a01 01a10b06 092a8648 0..P .... .... .*.H 0020: 82f71201 0202a282 013a0482 01366082 .... .... .:.. .6`. 0030: 01320609 2a864886 f7120102 0203007e .2.. *.H. .... ...~ 0040: 82012130 82011da0 03020105 a1030201 ..!0 .... .... .... 0050: 1ea41118 0f323030 36303232 34313931 .... .200 6022 4191 0060: 3234365a a5050203 016b48a6 03020125 246Z .... .kH. ...% 0070: a9161b14 57535345 432e4155 5354494e .... WSSE C.AU STIN 0080: 2e49424d 2e434f4d aa2d302b a0030201 .IBM .COM .-0+ .... 0090: 00a12430 221b0448 5454501b 1a773230 ..$0 "..H TTP. .w20 00a0: 30337365 63646576 2e617573 74696e2e 03se cdev .aus tin. 00b0: 69626d2e 636f6dab 81aa1b81 a76f7267 ibm. com. .... .org 00c0: 2e696574 662e6a67 73732e47 53534578 .iet f.jg ss.G SSEx 00d0: 63657074 696f6e2c 206d616a 6f722063 cept ion, maj or c 00e0: 6f64653a 2031302c 206d696e 6f722063 ode: 10, min or c 00f0: 6f64653a 2033370a 096d616a 6f722073 ode: 37. .maj or s 0100: 7472696e 673a2044 65666563 74697665 trin g: D efec tive 0110: 20746f6b 656e0a09 6d696e6f 72207374 tok en.. mino r st 0120: 72696e67 3a20436c 69656e74 2074696d ring : Cl ient tim 0130: 65204672 69646179 2c204665 62727561 e Fr iday , Fe brua 0140: 72792032 342c2032 30303620 61742031 ry 2 4, 2 006 at 1 0150: 3a31323a 34352050 4d20746f 6f20736b :12: 45 P M to o sk 0160: 65776564 ewed |
User Action | The preferred way to resolve this issue is to synchronize
the WebSphere Application
Server system time to within 5 minutes of the AD server's time.
A best practice is to use a time server to keep all systems synchronized.
You can also add or adjust the clockskew parameter in the Kerberos
configuration file. Note: The default for the clockskew parameter
is 300 seconds (or 5 minutes).
|
Problem | Getting an exception: No factory available to create a name for mechanism 1.3.6.1.5.5.2. There is no factory available to process the creation of a name for the specific mechanism. |
Symptom | [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 > com.ibm.ws.security.spnego.ServerCredential initialize ENTRY 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) |
User Action | Check the java.security file to ensure it contains
the IBMSPNEGO security provider and that the provider is defined correctly.
The java.security file should contain a line similar to: security.provider.6=com.ibm.security.jgss.mech.spnego.IBMSPNEGO |
Symptom | The following error is displayed as the JGSS library is trying
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 |
Description | This exception is the result of encoding the ticket using
one key and attempting to decode it using a different key. There are
number of possible reasons for this condition:
|
User Action | If the problem is with the Kerberos keytab file, then regenerate
the keytab file. If the problem is with 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.
The Active Directory may need to be searched for other entries with
SPNs defined that clash with the SPN. To confirm that the SPN is
not registered, the command:
setspn –l useridshould return with the following response: Cannot find account userid |
Symptom | When tracing is enabled, the following message appears:[2/27/06 14:28:04:191 CST] 00000059 SpnegoHandler < com.ibm.ws.security.spnego.SpnegoHandler handleRequest: Received a non-SPNEGO Authorization Header RETURN |
Description | The client is returning an NT LAN manager (NTLM) response
to the authorize challenge, not a SPNEGO token. This condition can
be occur due to any of the following reasons:
|
User Action | If the SPN is defined incorrectly as HTTP/server.realm.com@REALM.COM with the addition of @REALM.COM, then delete the user, redefine the user, and redefine the SPN. If the problem is with the Kerberos keytab file, then regenerate the keytab file. 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:
|
Symptom | An invalid option is detected. When tracing is enabled, the
following message is displayed:com.ibm.security.krb5.KrbException, status code: 101 message: Invalid option in ticket request |
Description | The Kerberos configuration file is not properly configured. |
User Action | Ensure that neither renewable, nor proxiable are set to true. |
Symptom | Examine the following message in the trace that you receive
when trace is turned on:com.ibm.security.krb5.internal.crypto.KrbCryptoException, status code: 0 message: Checksum error; received checksum does not match computed checksum |
Description | RC4-HMAC encryption is not supported with a Microsoft Windows 2000
Kerberos key distribution center (KDC). To confirm this condition,
examine the trace and identify where the exception is thrown. The
content of the incoming ticket should be visible in the trace. Although
the incoming ticket is encrypted, the SPN for the service is readable.
If a Microsoft Windows 2000 KDC is used and
the system is configured to use RC4-HMAC, the string representing
the ticket for userid@REALM ( instead of the expected HTTP/hostname.realm@REALM)
is displayed. For example, this is beginning of the ticket received
from a Microsoft Windows 2000 KDC:0000: 01 00 6e 82 04 7f 30 82 04 7b a0 03 02 01 05 a1 ..n...0......... 0010: 03 02 01 0e a2 07 03 05 00 20 00 00 00 a3 82 03 ................ 0020: a5 61 82 03 a1 30 82 03 9d a0 03 02 01 05 a1 0a .a...0.......... 0030: 1b 08 45 50 46 44 2e 4e 45 54 a2 18 30 16 a0 03 ...REALM.COM.0.. 0040: 02 01 01 a1 0f 30 0d 1b 0b 65 70 66 64 77 61 73 .....0...userid 0050: 75 6e 69 74 a3 82 03 6e 30 82 03 6a a0 03 02 01 .a.f...n0..j....The realm is REALM.COM. The service name is userid. A correctly formed ticket for the same SPN is: 0000: 01 00 6e 82 04 56 30 82 04 52 a0 03 02 01 05 a1 ..n..V0..R...... 0010: 03 02 01 0e a2 07 03 05 00 20 00 00 00 a3 82 03 ................ 0020: 82 61 82 03 7e 30 82 03 7a a0 03 02 01 05 a1 0a .a...0..z....... 0030: 1b 08 45 50 46 44 2e 4e 45 54 a2 2a 30 28 a0 03 ..REALM.COM.0... 0040: 02 01 02 a1 21 30 1f 1b 04 48 54 54 50 1b 17 75 .....0...HTTP..u 0050: 73 31 30 6b 65 70 66 77 61 73 73 30 31 2e 65 70 serid.realm.com. 0060: 66 64 2e 6e 65 74 a3 82 03 39 30 82 03 35 a0 03 ...n.....90..5.. |
User Action | To correct the problem, either use the Single data encryption standard (DES) or use a Microsoft Windows 2003 Server for a KDC. Remember to regenerate the SPN, and the Kerberos keytab file. |
Symptom | Examine the following message:Bad Request Your browser sent a request that this server could not understand. Size of request header field exceeds server limit. Authorization: Negotiate YII…… |
Description | This message is generated by the Apache/IBM HTTP Server. This server is indicating that the authorization header returned by the user's browser is too large. The long string that follows the word Negotiate (in the error message above) is the SPNEGO token. This SPNEGO token is a wrapper of the Microsoft Windows Kerberos token. Microsoft Windows includes the user's PAC information 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 the SPNEGO becomes. IBM HTTP Server 2.0 (also Apache 2.0 and IBM HTTP Server 6.0) limit the size of any acceptable HTTP header to be 8K. In Microsoft Windows domains having many groups, and with user membership in many groups, the size of the user's SPNEGO token may exceed the 8K limit. |
User Action | If possible, reduce the number of security groups 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. WebSphere Application
Server Version 6.0 users can obtain this fix in fixpack 6.0.0.2. Note: Non-Apache
based Web servers may require differing solutions.
|
Symptom | Examine the SystemOut.log and note the some KRB_DBG_KDC messages appear there even with JGSS tracing disabled. |
Description | 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 com.ibm.security.krb5.Krb5Debug property has a default value to put some messages to the SystemOut.log |
User Action | .To remove all KRB_DBG_KDC messages from the SystemOut.log,
set the JVM property as follows:-Dcom.ibm.security.krb5.Krb5Debug=none |
Symptom | When an application contains a custom HTTP 401 error page, the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) trust association interceptor (TAI)-generated HTTP response page is not displayed in a browser. |
Description | When an application contains a custom HTTP 401 error page, the SPNEGO TAI-generated HTTP response page is not displayed in a browser. The custom HTTP 401 error page is displayed instead. |
User Action | You can customize your HTTP 401 page to include information concerning how to configure your browser to use SPNEGO. For more information, see Configuring the client browser to use SPNEGO and SPNEGO TAI custom properties configuration. |
Symptom | Note that HTTP Post parameters are lost during interaction
with the SPNEGO TAI, when stepping down to userid/password login. "Stepping down to userid/password login" means that the Microsoft Internet Explorer tries to respond initially with a SPNEGO token. If this response is unsuccessful, then the Microsoft Internet Explorer tries to respond with a NTLM token that is obtained through a userid/password challenge. |
||||||||||
Description | The Microsoft Internet
Explorer maintains state during a user's request. If a request
was given the response of an "HTTP 401 Authenticate Negotiate", and
the browser responds with a NTLM token obtained through a userid/password
challenge, the browser resubmits the request. If this second request
is given a response of an HTML page containing a redirection to the
same URL but with new arguments (via Javascript) then the browser
does not resubmit the POST parameters. Note: To avoid this problem,
it is critical to NOT perform the automatic redirection. If the user
clicks on a link, the problem does not occur.
|
||||||||||
User Action | The browser responds to the Authenticate/Negotiate challenge with an NTLM token, not an SPNEGO token. The SPNEGO TAI sees the NTLM, and returns back a HTTP 403 response, along with the HTML page. When the browser runs the Javascript redirTimer function, any POST of GET parameters that were present on the original request are lost. By
leveraging the SPN<id>.NTLMTokenReceivedPage property, an appropriate
message page can be returned to the user. The default message that
is returned (in the absence of a user defined property) is:
"<html><head><title>An NTLM Token was Received.</title></head>" + "<body>Your browser configuration is correct, but you have not logged into a supported Windows Domain." + "<p>Please login to the application using the normal login page.</html>"; Using the SPN<id>.NTLMTokenReceivedPage property, you can customize the exact response. It is critical that the returned HTML not perform a redirection. When the SPNEGO TAI has been configured to use the shipped default HTTPHeaderFilter class as the SPN<id>.filterClass, then the SPN<id>.filter can be used to allow the second request to flow directly to the normal WebSphere Application Server security mechanism. In this way, the user experiences the normal authentication mechanism. An
example of such a configuration follows. The required SPNEGO TAI properties
necessary and the HTML file content are presented.
Note: Observe that the filter property instructs the SPNEGO
TAI to NOT intercept any HTTP request that contains the string “noSPNEGO”.
Here
is an example of a generating a helpful response.
<html> <head> <title>NTLM Authentication Received </title> <script language="javascript"> var purl=""+document.location; if (purl.indexOf("noSPNEGO")<0) { if(purl.indexOf('?')>=0) purl+="&noSPNEGO"; else purl+="?noSPNEGO"; } </script> </head> <body> <p>An NTLM token was retrieved in response to the SPNEGO challenge. It is likely that you are not logged into a Windows domain.<br> Click on the following link to get the requested website. <script language="javascript"> document.write("<a href='"+purl+"'>"); document.write("Open the same page using the normal authentication mechanism."); document.write("</a><br>"); </script> You will not automatically be redirected. </body> </html> |
Symptom | 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 |
Description | When a Microsoft Internet Security Acceleration Server (ISA) exists between a client browser and WebSphere Application Server, 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 WebSphere Application Server fails because the SPNEGO OID has been converted and is now missing. |
User Action | 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. |
Symptom | You are using Microsoft Windows Version 7 with Internet Explorer Version 8, and you cannot get SPNEGO Single Sign On (SSO) to function. |
Description | If you are using Microsoft Windows Version 7 with Internet
Explorer Version 8, 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.... |
User Action | 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, you must 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:
Note: If you have more than one Microsoft Active Directory account that
you use to map to different SPNs, then you must repeat steps 1 through
3 above for each SPN and the merging of all the keytab files.
|