Troubleshooting Kerberos Issues with Weblogic Server

Found NTLM token when expecting SPNEGO

The browser is not set up correctly to send a spnego token, go back to the client configuration, and double check the browser configuration. IE needs to be configured with Integrated Windows Authentication should be turned on and the site listed in the Intranet domain. IE also needs to be configured with automatic logon. After making these changes, make sure to restart IE.

Refer to this link for IE Settings:-

http://msdn.microsoft.com/en-us/library/ms995329.aspx

Something is wrong in your SPN definition. Either no SPN was defined for this service, or you have duplicate SPNs, which means that the SPN resolved in more than one principal associated with it. You can verify this by typing:

LDIFDE -d DC=yourdomain ,DC=com -f c:\export.txt

This will export the list of AD objects to the file export.txt. Then look for your service (HTTP/) in the values of the attribute
ServicePrincipalName. If it shows more than once or not at all, you to overcome this exception remove the user account in AD and create again. Start all over the procedure from all over again.

Failure unspecified at GSS-API level (Mechanism level: Invalid argument (400) – Cannot find key of appropriate type to decrypt AP REP – RC4 with HMAC)

Active Directory account is configured to use the default
encryption type on Windows (RC4-HMAC). You can switch to use DES, by selecting “use DES encryption” in the AD account settings. After you switching to DES, reset the password.

In order to use RC4-HMAC, you’ll need to update the Kerberos configuration file to specify the encryption type.

default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac

Ref: – http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/jgss-features.html

Pre-authentication information was invalid (24)

This means that the service account password in the Active Directory and the password in the keytab file does not match. Make sure you have the correct password specified while generating the keytab file. Also, this error could be due to invalid principal name in the krb5login.conf file. When generating the keytab file using the ktpass utility, the principal name will be changed to HTTP/. Make sure you specify the principal name in the keytab file as HTTP/.

Double check the validity of your keytab, or of the password that you have entered. If you are confident about your password, many times, refreshing the password for the user in the AD server may solve the problem. (by right clicking on the user, selecting “Reset Password” and re-entering the same password specified earlier).

Another reason for that problem to happen is if there exist another
principal with the same short name in the AD server (different DNs but same CN).This is likely to happen if the host that runs WebLogic server already belongs to the network domain, then it will have an account in the Computers section,and a password there too. In that case, you will run into SPN issues as well.

The best way out of this is to create a new user account, with a different CN, and map the HTTP SPN to the new account, (and remove the SPN from any other account).

If the WebLogic server host is also on the same domain (or registerd with the same KDC/AD) where you are creating the SPN then there must a machine name already exists which has the mapping for the same URL which you want to map with SPN. In such cases best way is to create a DNS alias for WebLogic host and map the DNS alias with the machine name.

Ref: – http://forums.oracle.com/forums/thread.jspa?threadID=876942&tstart=0

Known issue with Windows Server 2003 SP1. Contact Microsoft for a fix.
-http://support.microsoft.com/kb/919557/en-us
http://hotfixv4.microsoft.com/Windows%20Server%
202003/sp2/Fix183877/3790/free/277896_ENU_i386_zip.exe

Failure unspecified at GSS-API level (Mechanism level: Checksum failed)

If the keytab files being generated by the ( Ktab\ktpass) JDK shipped with either WLS 9.x or WLS 10.0, the SSO is getting failed. If the keytab files being generated with JDK < 1.5.0_8, SSO getting failed with unsupported algorithm exception for WLS 10 server.Use JDK >= 1.5.0_8 to generate keytab files, then issue solves and the SSO works.

Even applying the following HOT FIX Might Help

http://support.microsoft.com/default.aspx?scid=kb;en-us;833708

Client not found in Kerberos database while getting initial credentials

This means that the principal does not exist in AD. Check and make sure that the <serviceaccount@domain> matches exactly the user logon name in AD.

KDC has no support for encryption type (14)’ error.

Cause 1: Your KDC does not support the encryption type requested.
Solution 1: Sun’s implementation of Kerberos supports the following encryption types: des-cbc-md5, des-cbc-crc and des3-cbc-sha1.
Applications can select the desired encryption type by specifying following tags in the Kerberos Configuration file krb5.conf:
[libdefaults]
default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1

If not specified, the default value is:
des-cbc-md5 des-cbc-crc des3-cbc-sha1

Cause 2: This exception is thrown when using native ticket cache on some Windows platforms. Microsoft has added a new feature in which they no longer export the session keys for Ticket-Granting Tickets (TGTs). As a result, the native TGT obtained on Windows has an “empty” session key and null EType. The effected platforms include: Windows Server 2003, Windows 2000 Server Service Pack 4 (SP4) and Windows XP SP2.
Solution 2: You need to update the Windows registry to disable this new feature. The registry key allowtgtsessionkey should be added–and set correctly–to allow session keys to be sent in the Kerberos Ticket-Granting Ticket.
On the Windows Server 2003 and Windows 2000 SP4, here is the required registry setting:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Value Name: allowtgtsessionkey
Value Type: REG_DWORD
Value: 0x01 ( default is 0 )
By default, the value is 0; setting it to “0x01” allows a session key to be included in the TGT.
Here is the location of the registry setting on Windows XP SP2:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\
Value Name: allowtgtsessionkey
Value Type: REG_DWORD
Value: 0x01

Ref:-

http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html

GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT credentials failed!

There are multiple reasons for this exception:

The principal exists in kerberos but the password is wrong. This is a
password problem. Double check the validity of your keytab, or of the password that you have entered. If you are confident about your password, many times, refreshing the password for the user in the AD server may solve the problem. (by right clicking on the user, selecting “Reset Password” and re-entering the same password specified earlier).

If there exist another principal with the same short name in the AD server (different DNs but same CN). This is likely to happen if the host that runs WebLogic server already belongs to the network domain, then it will have an account in the Computers section, and a password there too. In that case, you will run into SPN issues as well. The best way out of this is to create a new user account, with a different CN, and map the HTTP SPN to the new account, and remove the SPN from any other account).
If the WebLogic server host is also on the same domain (or registerd with the same KDC/AD) where you are creating the SPN then there must a machine name already exists which has the mapping for the same URL which you want to map with SPN. In such cases best way is to create a DNS alias for WebLogic host and map the DNS alias with the machine name.

Clock skew – If the time on the KDC and on the client differ significanlty (typically 5 minutes), this error can be returned. Synchronize the clocks (or have a system administrator do so).

The Kerberos realm name is not all uppercase. Make the Kerberos realm name all uppercase. Note: It is recommended to have all uppercase realm names. For details, refer to the Naming Conventions for the Realm Names and Hostnames section of this tutorial.

Ref: –

http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html

There is a known issue reported from SUN JDK 1.4.2_14, which also affects Jrockit JVM also.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6605907

This issue is fixed in JDK 1.4.2_18. http://java.sun.com/j2se/1.4.2/ReleaseNotes.html#142_18
(Check for the bug number: 6570062).

Also, the same issue is fixed in JRockit R27.6.2 also.

GSSException: Failure unspecified at GSS-API level (Mechanism level: Integrity check on decrypted field failed (31)

In case of multiple domain controllers where there is one root domain beatest.com and two children domains viz. child-a.beatest.com and
child-b.beatest.com, SSO works for request from user logged in child-a but fails when sent from a user logged in child-b with the following exception:

GSSException: Failure unspecified at GSS-API level (Mechanism level:
Integrity check on decrypted field failed (31))

This error occurs when you haven’t sufficiently purged your tickets. Meaning you changed the SPN but the client tried to use an old ticket so the server couldn’t decrypt it with the service principal key. Make sure you purge your tickets with kerbtray.exe after you set the password on the service account.

Ref:-

http://forums.sun.com/thread.jspa?threadID=5358178&tstart=0

Latest Comments

  1. hari April 26, 2010
  2. Faisal Khan April 27, 2010
  3. vidya sagar May 14, 2010
    • Administrator May 16, 2010
  4. Tariq Khan July 10, 2010
  5. Mangesh November 25, 2010
  6. Paulo Pereira May 25, 2011

Leave a Reply