Before we go on, we need to check if your machine is part of an Active Directory domain and check the correct configuration in your computer properties. If you can see your Windows domain name in the Domain section, you're a member. Otherwise, your computer needs to be synced with your target configuration domain by the administrator.

On your client's Windows machine, the login phase in the domain generates a valid Kerberos token cached with your credentials; you can check if the token is generated correctly with some powerful tools, which are very useful during diagnostic sessions.

You can find these utilities on the Windows Server 2003 Resource Kit Tools package and you can download this from the Microsoft site at http://www.microsoft.com/en-us/download/details.aspx?id=17657.

Kerbtray is a graphical and easy-to-use Microsoft tool that will display a detailed list of your Kerberos tokens cached with some key information:

You can also use this tool to clean your local token cache by right-clicking on the tray icon and selecting the Purge tickets option.

Klist is a command-line utility that will permit you to view and clean your local token caches; with this command you can easily write a batch command to pilot or monitor your token cache for a long time.

The following command redirects the output to a file, to save your token status:

klist > c:	oken.list.txt

It's very important to check if this client browser setting is enabled; without this, the Single Sign-On process will not work.

To check your settings, right-click on the Internet Explorer icon in your desktop and select Properties. Go to the Advanced tab and scroll down to the Security section and check Enable Integrated Windows Authentication—if it's not already selected.

It's essential to register a DNS record that will be used to access your Single Sign-On application installed in the WebLogic Server instance.

It's advisable to register all hostnames in your scenario—WebLogic nodes (for example, a network load balancer device), web server nodes, and any other existing and associated virtual IP. This information will allow us to register all Service Principal Names (SPNs), which are enabled to mark a trusted Single Sign-On access in your application at any level. This is powerful when you need to troubleshoot a problem.

The DNS entry can be provided with the internal Active Directory DNS service, or externally with some appliance DNS Server or some standard-compliant DNS Server. The working of the entire process is shown in the following diagram:

On the Active Directory side we need to create a technical user to associate the Service Principal Name; this technical user is fundamental in the token verification phase.

Add a sample user by checking the User cannot change password and Password never expires checkboxes (leave any other settings to default values). Check the Use Kerberos DES encryption types for this account option under the Account tab.

If you are using JVM 6 (or a later version) and Windows Server 2008, don't check this option; by doing so we can configure the encryption method as RC4 HMAC. This encryption type doesn't need any other Active Directory technical user configuration.

Also consider that Oracle certifies Internet Explorer 8.0 and FireFox 7.0.1 clients—which access user accounts defined in Active Directory and are encrypted with the AES-128, AES-256, or RC4 types—will run on a Windows 7 Enterprise platform.

Change the user password and remember it. If you change the encryption type, reset the user password again.

Now we need to add our Service Principal Name on this user; to access it we must use an Active Directory privileged user, as they can edit services to our technical user.

For example, consider the URL http://wls1.dom.int, which points to the IP configured on your WebLogic Server instance. Open a DOS command with a privileged user on a Windows machine in the domain and enter the following command:

setspn -A HTTP/wls1 technicaluser

The previous command associates the URL of WebLogic Server to our user.

setspn -A HTTP/wls1.dom.int technicaluser

The previous command associates the URL of WebLogic Server with the full domain specified to our user.

In this way, you have enabled the http://wls1.dom.int URL (and only that) to accept a Kerberos session and register any other URLs.

To check your registered Service Principal Name user entry, use the following command:

setspn -L technicaluser

Some important rules while creating a technical user with Active Directory are as follows:

Before proceeding we need to have a local Kerberos configuration file in accordance with your Active Directory and Kerberos configuration.

Check under ${java.home}/lib/security/krb5.conf or %windir%krb5.ini.

This file contains a list of important parameters; the following code snippet shows a sample section from that file:

[libdefaults]
   default_realm = DOM.INT
  ticket_lifetime=600
  default_tkt_enctypes = rc4-hmac aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crc
  default_tgs_enctypes = rc4-hmac aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crc
  permitted_enctypes = rc4-hmac aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crc
[realms]
  LOCAL.DOM.INT = {
     kdc = dc0.local.dom.int:88
     default_domain= DOM.INT
  }
[domain_realm]
  .dom.int = DOM.INT
[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true

On a Windows machine in the domain with a JDK installation (it is better to use the same JDK version that is installed on the server side), use the following command in a DOS window to generate a Keytab file:

c:Programsjdk1.6.0_02inKtab.exe –a technicaluser pwduser –k keytabname.keytab

With this, the following output is displayed:

Done!
Service key for technicaluser is saved in c:Programsjdk1.6.0_02injdk1.6.0_02inkeytabname.keytab

To check your Keytab file use the following command:

c:Programsjdk1.6.0_02inklist.exe -e -f -t -K –k c:Programsjdk1.6.0_02injdk1.6.0_02inkeytabname.keytab

The following output will be displayed in the command-line window:

Key tab: c:	est.keytab, 5 entries found.
[1] Service principal: [email protected]
         KVNO: 1
         Key type: 17
         Key: 0x8818f354b7c348bf234b95caffa9cdd
         Time stamp: May 11,  2012 11:57
[2] Service principal: [email protected]
         KVNO: 1
         Key type: 16
         Key: 0xec4f8cd12342223a2423425d7fa4e9fd
         Time stamp: May 11,  2012 11:57
[3] Service principal: [email protected]
         KVNO: 1
         Key type: 23
         Key: 0xd18a478dfcc5a1d2342311ac23165fa
         Time stamp: May 11,  2012 11:57
[4] Service principal: [email protected]
         KVNO: 1
         Key type: 3
         Key: 0x31d3b33132412222cfghb3e
         Time stamp: May 11,  2012 11:57
[5] Service principal: [email protected]
         KVNO: 1
         Key type: 1
         Key: 0x31d3b123412tffgb0cb3e
         Time stamp: May 11,  2012 11:57

Move the generated Keytab file and copy the krb5.ini file—now renamed to krb5.conf in the WebLogic Server—to the home WebLogic domain folder.

When on your server you use a JVM with a version greater than 1.6 update 21, keep in mind that now a new security control has been introduced.

In few words the KVNO number is checked and this is increased everytime you change your password on the KRDC. When this number doesn't match the one that we have on the keytab an exception is raised.

We have the following two solutions to solve this problem:

This is another important file that tells the WebLogic Server to use the Kerberos login module, where the keytab files are located, and also the path of the technical user, with the associated Service Principal Name.

Edit a file named krb5Login.conf and copy that in the WebLogic Server in the WebLogic domain home folder.

Next, a sample configuration wherein your WebLogic Server uses Oracle JVM version 6 or higher is shown in the following code snippet:

com.sun.security.jgss.krb5.initiate {
     com.sun.security.auth.module.Krb5LoginModule required
     principal="[email protected]" useKeyTab="true"
     keyTab="keytabname.keytab" storeKey="true" debug="false";
};
com.sun.security.jgss.krb5.accept {
     com.sun.security.auth.module.Krb5LoginModule required
     principal="[email protected]" useKeyTab="true" 
     keyTab="keytabname.keytab" storeKey="true" debug="false";
};

To activate our Kerberos configuration we need to specify some specific startup arguments; open WebLogic Admin Console and go to Server | Start Arguments. Then add the following:

-Djava.security.auth.login.config=krb5Login.conf
-Djavax.security.auth.useSubjectCredsOnly=false
-Dsun.security.krb5.debug=false
-Dweblogic.security.enableNegotiate=true
-Djava.security.krb5.conf=krb5.conf
-Dweblogic.wsee.component.exception=false
-DDebugSecurityAdjudicator=false

After this modification you need to restart your WebLogic server node; if you have multiple nodes in your cluster you need to apply these parameters for each one of them.