Professional Documents
Culture Documents
Configuring SPNEGO in WebSphere 6.1, 7 and 8 Environments Using Microsoft Active Directory
Trademarks
The following terms are registered trademarks of International Business Machines Corporation in the United States and/or other countries: WebSphere. A full list of U.S. trademarks owned by IBM may be found at http://iplswww.nas.ibm.com/wpts/trademarks/trademar.htm. Microsoft, Windows, Windows NT, and Windows XP are registered trademarks of Microsoft Corporation in the United States and/or other countries. UNIX is a registered trademark in the United States and other countries licensed exclusively through The Open Group. LINUX is a registered trademark of Linus Torvalds. Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States and/or other countries. Other company, product and service names may be trademarks or service marks of others.
Summary of Changes
1.0 1.1 2.0 2.1 2.5 2.6 2.7 3.0 3.1 4.0 Initial Release Corrected hostnames in the examples. Change the term Key Volume Number with Key Version Number Clarifications and simplifications Added Windows 2000 disclaimer and cleaned up ktpass examples Expanded examples, standardized hostnames, and tested with Windows 2000 Added section on credential delegation Fixed section on credential delegation Changes to include WAS 7 Removed disablesecuritypreinvokeonfilters step (see page 27) Tweaked credential delegation (again!) Changes to include WAS 8 and AD 2008 R2
Table of Contents
Trademarks ........................................................................................................................................... 2 Summary of Changes ............................................................................................................................ 2 Table of Contents .................................................................................................................................. 3 Introduction ........................................................................................................................................... 4 Differences Between WAS 6.1, WAS 7 and WAS 8 ........................................................................... 5 Acknowledgements ............................................................................................................................... 5 Single Server SPNEGO Configuration ................................................................................................. 6 SPNEGO with a Remote Web Server ................................................................................................. 28 Clusters and Load Balancing with SPNEGO...................................................................................... 44 SPNEGO with Network Dispatchers and IP Sprayers ........................................................................ 59 Setting up Delegation .......................................................................................................................... 60
Introduction
SPNEGO, or the Simple and Protected GSSAPI Negotiation Mechanism, enables a straightforward single sign-on (SSO) mechanism for WebSphere in Kerberos environments. This document is intended to provide instructions to configure SPNEGO for WebSphere Application Server in standalone and clustered configurations using Microsoft Active Directory as the Kerberos security server. It is meant to be a quick-start guide, providing the minimum steps and default options required to get up and running quickly in several specific test scenarios, and is not meant to be a replacement for the official WebSphere documentation. Once you are comfortable with the basic SPNEGO steps that you learn here, please refer to your WebSphere Documentation Centre for further and more advanced configuration options. This document covers four basic SPNEGO configuration scenarios: Single Server, Distributed, Clustered, and Dispatched: Single Server Distributed Clustered Dispatched
Configuration with a single instance of WebSphere Application Server (WAS) Configuration with a single instance of WAS, plus the setup of an HTTP server on a separate machine routing requests to WAS. Configuration with a WAS ND cluster, also front-ended by HTTP servers. Discuss the configuration with an IP Sprayer in front of the WAS ND cluster
RedHat Enterprise Linux 4 was used as the OS to host all the instances of WebSphere V6 and V7 for the different scenarios. For WebSphere V8, RedHat Enterprise Linux 6.3 was used. An instance of Windows Server 2003 SP1 hosted the Active Directory and a Windows XP SP2 instance in the AD domain was used for the browser client. Testing was also performed with an instance of Windows Server 2000 SP4, and a Windows 7 client with Windows Server 2008 R2 as the security server. Windows Server 2008 R2 requires no additional support tools to be installed. For Windows Server 2003, you also need to have Windows 2003 Support Tools installed. The support tools are NOT installed when you install the operating system. You can download the support tools service pack for SP1 here: http://www.microsoft.com/downloads/details.aspx?FamilyId=6EC50B78-8BE1-4E81-B3BE4E7AC4F0912D&displaylang=en and SP2 here:
http://www.microsoft.com/en-us/download/details.aspx?id=15326
If you are using Windows 2000 SP4 as your security server, you will also need to download and install SP4 of the Windows 2000 support tools. You can download them here: http://www.microsoft.com/downloads/details.aspx?familyid=F08D28F3-B835-4847-B810BB6539362473&displaylang=en Additionally for Windows Server 2000 users, you may need to download the setspn.exe utility. You can get that here: http://www.microsoft.com/downloads/details.aspx?familyid=5fd831fd-ab77-46a3-9cfeff01d29e5c46&displaylang=en
You Have Options! Please note that in order to use SPNEGO you are not restricted to Microsoft Active Directory as your security server. To make use of other Kerberos servers for SPNEGO and SSO, please contact your IBM Software Services for WebSphere (ISSW) representative for assistance.
Acknowledgements
Thanks very much to Ut Le in Austin, Billy Lo in Toronto, and Martin Lansche in Toronto for reviewing this document and providing invaluable feedback.
Active Directory Server Host Name: w2ksvr.robo.home.ca AD Domain: ROBO.HOME.CA DNS Domain: robo.home.ca
The Windows client must be in the same Active Directory (AD) domain as the AD Server. In advanced scenarios, the client can be in a different domain, as long as the AD Servers are crosscertified. Cross-certification is not discussed in this document. When a user logs into the domain, it establishes that users identity on the network. In order for trusted third party authentication to take place, the instance of WebSphere on the Linux server must also have an AD identity. This is what we are going to establish in the following steps. Please note that if you will be configuring SPNEGO on a Windows system instead of a Linux system, you will still need a separate Windows client to surf from. For whatever reason, SPNEGO does not work locally on a system. You can use the browser on your AD server for testing, as long as your application server is installed elsewhere. Finally, make sure all of your system clocks are set to within five minutes of each other. Clocks that drift or are set out of this range will not authenticate correctly.
You can use whatever logon name you wish, as long as it is not the ID you will be using to activate WebSphere Security with. There are no special account options that you need to set, except perhaps to set the password to never expire in your test environment. This will save you the need to regenerate keys (discussed next) because the password never needs changing. Please remember that if you do change the password for the account, you will also need to regenerate the keys.
IBM Copyright, 2013 Web location of document (www.ibm.com/support/techdocs) SPNEGO Version 4.0, June 17, 2013 -7-
Step 2 Assign the Service Principal Name and Create Key File
After the account has been created, we need to map this account to the Kerberos Service Principal Name (SPN) and create a key file that WebSphere can use to log into the domain with. Please note that SPNs and keytabs are only required for the WebSphere Application Server instance, and not the Windows client users who will be logging in to the domain via the domain sign-on screen. To create the key, open a command window on the Active Directory 2003 server, and issue the ktpass command in the following manner: ktpass -out <keyfile name> -princ HTTP/fully qualified hostname@AD DOMAIN NAME -mapuser <AD user> -pass <password> -ptype KRB5_NT_PRINCIPAL
In the example environment, the command was issued as follows: ktpass out appserver1.keytab princ HTTP/appserver1.robo.home.ca@ROBO.HOME.CA mapuser wastest pass password -ptype KRB5_NT_PRINCIPAL Please note that case is very important here. HTTP must be all in capital letters as well as the AD domain name. If you get this wrong, authentication will not work.
Active Directory 2000 Users The ktpass command sets RC4-HMAC as the default cryptography for Active Directory 2003. If you are using Active Directory 2000, then RC4-HMAC is not available to you. Fortunately WebSphere supports DES-CBC-MD5, a cryptography also supported by Windows Server 2000. Unfortunately DES-CBC-MD5 is not the cryptography that ktpass defaults to on Windows 2000, so you need to explicitly identify it with the crypto flag when creating the key file. Issuing the same ktpass command on Windows 2000 would look like the following: ktpass out appserver1.keytab princ HTTP/appserver1.robo.home.ca@ROBO.HOME.CA mapuser wastest pass password -ptype KRB5_NT_PRINCIPAL crypto DES-CBC-MD5
Two things happen when you issue the ktpass command using the mapuser flag: A keytab file is created and the Service Principal Name (SPN) is mapped to the AD user wastest. The keytab file will get shipped to the Linux machine for WebSphere to make use of. WebSphere will use this key to authenticate itself in the AD domain as wastest. Basically, the mapping operation tells AD that any authenticated client using the http (or https) protocol to talk to appserver1.robo.home.ca in the ROBO.HOME.CA domain will authenticate to the wastest ID. So for example, when the client robobob logs into the AD domain, starts a browser and surfs to http://appserver1.robo.home.ca/snoop, the AD server says, Ah! The user robobob wants to talk with the user wastest. If you return to the account properties for the user, you will now see the following:
Note the User logon name field. It now contains the Service Principal Name (or SPN) of the ID. If you are using Windows Server 2000, then you will also notice that the account option to use DES encryption types for this account is now checked. You may notice in the WebSphere documentation the usage of the setspn command before ktpass is issued. When you use ktpass with the mapUser flag, the SPN is set automatically, so you dont actually need to issue the setspn command beforehand in this case. The examples in the later sections of this document show how setspn is used, but you dont need to worry about it right now. You may also note the documentation referring to the mapOp flag as well. Again, you dont need to worry about that in this example and it will be discussed later on.
In this example, appserver1.robo.home.ca is a Linux server. The appserver1.keytab file was copied to the /etc/krb5 directory, and the following command was invoked within wsadmin:
IBM Copyright, 2013 Web location of document (www.ibm.com/support/techdocs) SPNEGO Version 4.0, June 17, 2013 - 11 -
$AdminTask createKrbConfigFile {-krbPath /etc/krb5/krb5.conf realm ROBO.HOME.CA -kdcHost w2ksvr.robo.home.ca -dns robo.home.ca keytabPath /etc/krb5/appserver1.keytab} Note how the -realm flag corresponds to the Active Directory domain. When using AD, the Kerberos realm is always the AD domain name in upper case. The -kdcHost flag is the Active Directory hostname, and the dns flag is the DNS domain. In this example, the AD domain and the DNS domain are the same, but that may not necessarily always be the case. Once again, make note of the use of the mixed case, it is very significant! Executing this task will create a krb5.conf file, as shown below:
The krb5.conf file contains all of the information the WebSphere application server will need to authenticate itself with Active Directory, as well as authenticate Kerberos clients via the SPNEGO protocol.
Enable WebSphere security using the Active Directory server as a standalone LDAP registry (SPNEGO will also work when using federated repositories, but that is not discussed in this document). For the primary administrative user ID and the bind ID do not use the ID that you have just created a key file for. The ID you want to use here is the traditional wasadmin ID or something similar, as indicated in the following figure:
Click on the com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl link. You will now need to add at least one SPNEGO property, the service principal hostname, to enable SPNEGO on your server. Click the New button. In the name field, type com.ibm.ws.security.spnego.SPN1.hostName. In the value field, type the fully qualified hostname of your server. Click the OK button.
IBM Copyright, 2013 Web location of document (www.ibm.com/support/techdocs) SPNEGO Version 4.0, June 17, 2013 - 16 -
In our example, the hostname is appserver1.robo.home.ca. There are several other properties you will want to set for production environments. Refer to the WebSphere documentation centre for more details. Instead of using the admin console to set up the TAI configuration properties, you could also use wsadmin to create the properties interactively:
Important WAS 8 feature: For WAS 8, please make sure to de-select 'Use the alias host name for the application server' option if you don't have an alias set up. If you do not have an alias set up and you select this option, then the server name will fall back to the IP address of the machine and will not match the SPN we set up earlier using the host name.
After updating the initial options as above, click on the New button under SPNEGO Filters:
Enter in your local hostname and your Kerberos realm name. Select the Trim Kerberos realm from principal name checkbox. Click the OK button, click on the OK button again, then save the changes to the master configuration.
Note that the java.security.krb5.conf property must point to the location of the Kerberos configuration file you created earlier. To enable tracing, set com.ibm.security.jgss.debug and com.ibm.security.krb5.Krb5Debug to ALL. Be sure to turn these off for production!
On WAS 6.1, check the SystemOut.log file for lines that look like the following:
WAS 8 does not display this immediately, but after the first access attempt, so don't worry if you don't see this just quite yet.
IBM Copyright, 2013 Web location of document (www.ibm.com/support/techdocs) SPNEGO Version 4.0, June 17, 2013 - 22 -
Firefox
With Firefox, type about:config in the address bar. In the filter, type auth. There are then two fields you need to set: network.negotiate-auth.delegation-uris and network.negotiate-auth.trusteduris. Set both of these to your SSO domain.
Chrome
With Google Chrome, no special settings are required.
Internet Explorer
For Internet Explorer, go into Tools Internet Options Security Local intranet Sites and add the SSO domain.
You also need to enable Integrated Windows Authentication. Go to Tools Internet Options Advanced, scroll down to the Security section, and make sure that Enable Integrated Windows Authentication is checked.
Step 11 Surf!
Make sure you are logged into the AD domain from your client machine, start your browser and attempt to surf to the snoop servlet, using the fully qualified host name of the server. With security turned on, the snoop servlet will issue an authentication challenge to your browser, which will initiate the SPNEGO Kerberos exchange.
It works! In this example, we surfed to the http://appserver1.robo.home.ca:9080/snoop URL. You should see your Windows user ID in the User Principal field. Note the Authorization section of the request headers. It has the value Negotiate followed by an extremely long array of characters. This is how you can tell the SPNEGO exchange was successful (an NTLM header would be a short array of characters). You can also check the SystemOut.log file of the application server. To see something really cool, log into the AD domain as your wasadmin ID and then try surfing to the admin console. It should bypass the login screen entirely. Please note that you must always use the fully qualified host name for SPNEGO to work. Using the unqualified host name, or localhost will not work. Remember, the domain is king. If you are deploying your own web application, then you need to make sure you have your security constraints set in your web application deployment descriptor in order for SPNEGO to intercept the request. Congratulations!
What happened to disablesecuritypreinvokeonfilters? In earlier versions of this document, there was a step to add this custom property to the web container to get around an authentication problem when using https to surf to web applications that used a login page for authentication (like the admin console). It has been discovered that this causes a security exposure. IFIX PK77465 fixes this exposure, and the underlying problem it originally addressed. It is included in 6.1.0.25 and 7.0.0.5, and as a result this property no longer exists. If you are currently using this setting, please DISCONTINUE using it immediately and apply the necessary IFIX or fixpack for your installation.
IBM Copyright, 2013 Web location of document (www.ibm.com/support/techdocs) SPNEGO Version 4.0, June 17, 2013 - 27 -
Active Directory Server Host Name: w2ksvr.robo.home.ca AD Domain: ROBO.HOME.CA DNS Domain: robo.home.ca
To accomplish this, we bring in a separate box, install the http server on it, install the WebSphere plug-in, and copy the plugin-cfg.xml file from the WebSphere system to the web server. Now, fully expecting SPNEGO to work, we attempt to surf to the snoop servlet again via the web servers address, and we get the following:
We can get a clue to what is going on by turning off WebSphere security, restarting WebSphere, and then surfing to the snoop servlet via the web server again:
When the web server redirects the request to WebSphere, the server name changes from appserver1.robo.home.ca to webserver1.robo.home.ca. As you recall, the Service Principal Name (SPN) mapping we created was for appserver1.robo.home.ca. The name webserver1.robo.home.ca doesnt map to anything, so AD doesnt know which ID to create a session with. To resolve this issue, we will need to create another ID, map a new SPN, create a new key, and change some configuration information in WebSphere.
Step 2 Assign the Service Principal Name and Create Key File
Instead of using the ktpass command with the mapUser flag like we did last time, we are going to make it a two-step process with the use of the setspn command and ktpass without the mapUser flag: setspn a HTTP/<fully qualified hostname> <AD user> ktpass -out <keyfile name> -princ HTTP/<fully qualified hostname>@AD DOMAIN NAME -pass <password> -ptype KRB5_NT_PRINCIPAL
In the above example, the commands look like this: setspn a HTTP/webserver1.robo.home.ca websphere ktpass princ HTTP/webserver1.robo.home.ca@ROBO.HOME.CA out websphere.keytab -pass password ptype KRB5_NT_PRINCIPAL (AD 2000 Users: Remember to add crypto DES-CBC-MD5) Try issuing setspn l websphere as shown in the image above. It will show you the SPN that it is mapped to.
IBM Copyright, 2013 Web location of document (www.ibm.com/support/techdocs) SPNEGO Version 4.0, June 17, 2013 - 32 -
If we now take a look at the account properties for the websphere user:
You will notice that the logon name has not changed, unlike what happened last time when we created the mapping by just using the ktpass command with the mapUser flag. Making the mapping and key generation a two-step process with the setspn command gives us the ability to map multiple SPNs to the same AD user, cutting down on the number of user IDs you will need to create to support SPNEGO in your environment (we will see an example of this a little bit later). Mapping multiple SPNs to the same user ID is fine, but mapping the same SPN to multiple user IDs is extremely bad! Dont do it.
In this example, we changed the key file from appserver1.keytab to websphere.keytab. You could have also just overwritten the appserver1.keytab file and not change the krb5.conf file. Its up to you.
Notice how the Service Principal Name has changed from the application server to the web server address.
Step 6 Surf!
Now surf to the snoop servlet by directing the browser to the web server machine:
We have successfully switched the Service Principal Name from the application server to the web server. However, what if we want to be authenticated whether or not we are re-directed by the web server? Since we made the switch, we can no longer authenticate against the application server directly. You can solve this problem by setting a policy stating that everyone must go through the web server, or you can configure WebSphere to handle both Service Principal Names. As you recall, we already have two AD user IDs, two SPNs, and two key files. Lets revisit the setspn command to see how we can map both SPNs to the same AD user ID.
In the example above, we issued the following: setspn d HTTP/appserver1.robo.home.ca wastest setspn a HTTP/appserver1.robo.home.ca websphere This un-mapped the SPN from the user wastest, and re-mapped it to the user websphere. Remember, you cannot have the same SPN mapped to more than one user, so you must perform the setspn d before mapping to another user. If you look at the image above, you will notice how the setspn l websphere command now displays both SPNs.
After mapping, we need to add the new key to our key file. This is accomplished in the example with the following command: ktpass princ HTTP/appserver1.robo.home.ca@ROBO.HOME.CA in websphere.keytab out websphere.keytab pass password ptype KRB5_NT_PRINCIPAL (AD 2000 Users: remember to add crypto DES-CBC-MD5) In this example, the webserver1 key is still in the websphere.keytab file. Adding the in flag to ktpass will combine the appserver1 key with the webserver1 key instead of overwriting it. Make sure you combine the keys in this manner. What about mapOp? If you want to map multiple SPNs to the same user id, but find the use of the setspn command distasteful, the ktpass command allows you to collapse it all back into a single command by using the mapOp flag in combination with the mapUser flag. Take a look at the following two commands: ktpass princ HTTP/newserver1.robo.home.ca@ROBO.HOME.CA ptype KRB5_NT_PRINCIPALmapUser websphere mapOp set pass password out websphere.keytab ktpass prince HTTP/newserver2.robo.home.ca@ROBO.HOME.CA ptype KRB5_NT_PRINCIPAL mapUser websphere mapOp add pass password in websphere.keytab out websphere.keytab In this example, we want to map the newserver1 and newserver2 SPNs to the existing websphere user ID. The first ktpass command issues mapOp set. This will wipe out any previous SPN mappings to the websphere user ID and replace with the new one (If you issue this command in the current demo environment, it will wipe out the appserver1.robo.home.ca and webserver1.robo.home.ca mapping, so please be careful). The second ktpass command issues mapOp add. This will preserve the first mapping while creating the second mapping. Note as well the use of the in flag in the second ktpass command to preserve the key generated from the first ktpass command. The ktpass uses mapOp add as the default, so we didnt really need to specify it in the second example. Please note that the mapOp set flag will not remove mappings from any user other than the user identified with the mapUser flag. This means that you would still need to use the setpsn d command if you wanted to change the user ID an SPN points to.
Notice the SPN2 in the new property. You can have as many SPNs as you wish.
Notice how the two SPNs are now displayed. You can now surf using the webserver1.robo.home.ca address or the appserver1.robo.home.ca address and still be authenticated. Give it a try!
Linux Server Host Name: appserver2.robo.home.ca Active Directory Server Host Name: w2ksvr.robo.home.ca AD Domain: ROBO.HOME.CA DNS Domain: robo.home.ca
To provide scalability and high availability in our web applications, clustering web application servers within a WebSphere Network Deployment cell is a necessity. Getting SPNEGO to work in this environment is almost identical to how we set up SPNEGO in a multi-tiered environment in the last section, with most of the work being applied to simply building up the ND cell itself.
In the above example, WebSphere has been installed on a second Linux node, spnegoNode2 (appserver2.robo.home.ca), and the nodes have been consolidated into an ND cell, with the cell manager running on a third Linux machine. The ND cell instance can, of course, run on any of the application server node machines. How you set up your cluster is up to you. Before the cell was built up, WebSphere security was disabled on spnegoNode1 (appserver1.robo.home.ca).
Select a name for your node and the host name where the web server is running. Click OK.
You should now see something like the above image in your node list. Now that the webserverNode1 unmanaged node has been added, we can add the HTTP Server to it. From the admin console, click on Web Servers link in the Servers section of the menu pane:
If you installed HTTP servers on your application server nodes before you incorporated the cell, you should see something similar to the above image. If you didnt, then you wont see any web servers. Click New.
Select the webserverNode1 node, and enter webserver1 as the server name (webserver1 is the profile automatically given to a default WebSphere plug-in installs. If you specified a different name for the web server when you installed the WebSphere plug-in, use that profile name instead). Click Next.
Click Next.
You now have incorporated the independent web server into your ND cell.
IBM Copyright, 2013 Web location of document (www.ibm.com/support/techdocs) SPNEGO Version 4.0, June 17, 2013 - 49 -
Enter a name for the cluster (we used snoopCluster here), then press then Next button.
Select a member name for the first member in your cluster, select the node it runs on, and click Next.
Select a member name for the next member of your cluster and click on the Add Member button (you can use the same member name on different nodes, as long as it is unique for that node). Then click the Next button, and then the Finish button.
Click on the DefaultApplication link, and then on the Manage Modules link:
Highlight the cluster and web server the application will be deployed to, select the application, and then press the Apply button. Afterwards, press the OK button and then save to the master configuration.
Next, update the global web server plug-in configuration. From the Environment section of the Admin Console, select the Update global Web server plugin configuration link:
Click the OK button. Now select the Web servers link from the Servers section of the Admin Console:
Select the web server to update and click the Generate Plug-in button. Select the web server again, and then press the Propagate Plug-in button. Restart the web server on the web server node to make sure it picks up the changes quickly.
Step 6 Enable WebSphere SPNEGO Configuration Step 6 - WebSphere Version 6.1 Only Same as before, using webserver1.robo.home.ca as the SPN.
Note that TAI configuration is global for the entire cell. It only needs to be set once. After you make global changes, make sure you synchronize the changes with the nodes. Step 6 - WebSphere Version 7 and 8 Same as before using webserver1.robo.home.ca as the hostname:
This is global for the entire cell. Make sure the krb5.conf and keytab file are in the same directory on every machine in the cell that you want participating in SPNEGO.
Step 7 Enable SPNEGO at the JVM Level Step 7 - WebSphere Version 6.1 Only As in the previous step, you need to enable SPNEGO at the JVM level for each node in your cluster:
Step 7 - WebSphere Version 7 and 8 Same as before. You only need to set the debugging variables if you need to.
Step 8 Turn on SPNEGO Logging and Tracing Same as before. Step 9 Restart WebSphere In this case, you will need to restart the entire cell. Stop the node agents running on each of the nodes and any application servers that may also be running. Stop the cell manager, and then restart it. You should now have to log into the admin console with the wasadmin userid and password. Now restart the node agents on the application server nodes. Check in the System administration section of the admin console to make sure the nodes have come up successfully. Please note that you only need to restart the entire cell if you have just enabled WebSphere security as well. If security is already enabled, there is no need to restart the nodes or the cell manager. After the cell has restarted, you can now start the cluster:
Select the cluster and press the Start button. You can check the SystemOut.log files on each of the nodes to see if SPNEGO has successfully started. Make sure you look in the correct log files for the members of your cluster. Now log into the domain from your windows client, start up a browser and surf to the snoop servlet via the web server. The SPNEGO exchange should work just fine. Go into the admin console and shut one of the servers in your cluster down, and try to surf to the servlet again. It should fail-over to the second application server instance just fine. There are a lot of steps in this example, and mixing any of them up could result in SPNEGO not working correctly. If you have problems, carefully go over the steps again. A good first step is to turn security off and just make sure you have the cell set up correctly and the web application deployed correctly before worrying about the SPNEGO set up.
Active Directory Server Host Name: w2ksvr.robo.home.ca AD Domain: ROBO.HOME.CA DNS Domain: robo.home.ca
We can add a second web server in the web tier, and place a network dispatcher with a cluster address in front of the web tier. If we set the cluster host name to be snoopcluster.robo.home.ca and also set a policy dictating that all access needs to go through the dispatcher, then we only need to create the one SPN and one key for the whole system. We could have any number of application servers, web servers and deployed web applications all using the same key.
Setting up Delegation
If you are running a web application on WebSphere Application Server that needs to be able to forward along the clients credentials to another server, then there are a couple of extra things you need to do to enable this capability.
Note that this option is not set for the individual client users, only for the application server ID.
On Windows Server 2000 systems, delegation capability is set in the account options list of the account tab:
Performing these operations will expose the client credentials at the application server, giving server applications the ability to request and forward these credentials to another server. Please note that this is not an automatic process. Specific code needs to be written on the server to pull the credentials.