WebSphere Portal SSO With SPEGNO

WebSphere with a side of SPNEGO
Configuring SPNEGO in
WebSphere 6.1, 7 and 8 Environments
Using Microsoft Active Directory
This document can be found on the web, www.ibm.com/support/techdocs
Version 4.0: June 17, 2013
Websphere Technical Sales

Rob Peeren
Consulting IT Specialist
robobob@ca.ibm.com
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
IBM Copyright, 2013

Web location of document (www.ibm.com/support/techdocs)
SPNEGO
Version 4.0, June 17, 2013

-3-
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
Configuration with a single instance of WebSphere Application Server (WAS)
Distributed
Configuration with a single instance of WAS, plus the setup of an HTTP server
on a separate machine routing requests to WAS.
Clustered
Configuration with a WAS ND cluster, also front-ended by HTTP servers.
Dispatched
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:
IBM Copyright, 2013

SPNEGO

-4-
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.
Differences Between WAS 6.1, WAS 7 and WAS 8

SPNEGO configuration on WAS 7 is more streamlined than in WAS 6.1, but the preparation is
identical. In the step-by-step instructions that follow, if there is no distinction made between
versions of WebSphere, then you need to perform that step regardless of which version you are using.
Configuration for WAS 7 and WAS 8 is virtually identical, and the minor differences are noted
within the document.
Additionally, there is only cosmetic difference between Windows Server 2008 and Windows Server
2003 (with the addition of the Windows power shell the most notable). Configuration on Windows
Server 2008 is exactly the same as the documentation below for Windows Server 2003.
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.
IBM Copyright, 2013

SPNEGO

-5-
Single Server SPNEGO Configuration

Introduction
In this example, we are going to set up SPNEGO on a single instance of WebSphere Application
Server. The topology looks like this:
Windows Client
Host Name: xpclient.robo.home.ca
AD Domain: ROBO.HOME.CA
Linux Server
Host Name: appserver1.robo.home.ca
Active Directory Server

Host Name: w2ksvr.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.
IBM Copyright, 2013

SPNEGO

-6-
Step 1 Create a User ID for the Application Server

The first thing we need to do is create an Active Directory ID for WebSphere to make use of.
Please note that the ID you will be creating here is not the same, and cannot be the same as the
WebSphere administration ID that you use when you turn on WebSphere Security (usually
wasadmin in test environments). The ID that we will be creating here is the ID that the instance of
WebSphere itself uses to authenticate to Active Directory.
Add the user wastest in your Active Directory domain, and assign it the password password.
Then take a look at the account properties:
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
SPNEGO

-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.
IBM Copyright, 2013

SPNEGO

-8-
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:
IBM Copyright, 2013

SPNEGO

-9-
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.
IBM Copyright, 2013

SPNEGO

- 10 -
Step 3 Set up Kerberos Configuration on the Application Server

Copy the key file from the Active Directory machine to a directory on your application server. This
can be any directory you like, but you will need to make sure you specify the exact path to the key
file in the Kerberos configuration file that you will be creating.
After the key file has been copied, the Kerberos configuration file needs to be set up on the target
server. Start up WebSphere, run wsadmin on the command line, and then enter the following
command:
$AdminTask createKrbConfigFile {-krbPath <config file name>
realm <KERBEROS REALM> -kdcHost <AD hostname> -dns <dns domain>
keytabPath /etc/krb5/<keytab filename>}
If you are running on a Windows machine, issue the command with Windows style path names (i.e
C:\WINNT).
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
SPNEGO

- 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.
IBM Copyright, 2013

SPNEGO

- 12 -
Step 4 Enable WebSphere Security

Launch the WebSphere admin console, navigate to the SecurityGlobal security page, and enable
security on the application server:
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:
IBM Copyright, 2013

SPNEGO

- 13 -
IBM Copyright, 2013

SPNEGO

- 14 -
Step 5 Enable SSO

You may now optionally set up your SSO domain. For browser based applications, the SPNEGO
authentication exchange results in regular LTPA tokens being returned to the client browser and
further authorization is done the traditional way with LTPA. If your browser will be communicating
to more than one application server, you may want to have your SSO environment set up as well.
On WAS 6 and 7, the screen looks like this:
On WAS 8 it looks like this:
IBM Copyright, 2013

SPNEGO

- 15 -
Step 6 Enable SPNEGO in WebSphere

Step 6 - WebSphere Version 6.1 Only
The next thing we need to do is activate trust association and configure the SPNEGO Trust
Association Interceptor (TAI):
Click on the Interceptors link to get the following:
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
SPNEGO

- 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:
IBM Copyright, 2013

SPNEGO

- 17 -
Step 6 - WebSphere Version 7 and 8

In the admin console, select SecurityGlobal securityWeb and SIP securitySPNEGO Web
authentication:
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:
IBM Copyright, 2013

SPNEGO

- 18 -
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.
IBM Copyright, 2013

SPNEGO

- 19 -
Step 7 Enable SPNEGO at the JVM level

You may have multiple JVMs in your instance of WebSphere, and you may only want SPNEGO
enabled on some of those JVMs. Enable SPNEGO for each JVM in the following way:
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!

Enabling SPNEGO at the JVM level is not required for WebSphere 7 or 8, but you still enable
security tracing in this manner, so simply drop the last two entries from the image above. The debug
entries are automatically placed in the Custom Properties table for you and set to off. Change them
to ALL for debugging.
IBM Copyright, 2013

SPNEGO

- 20 -
Step 8 Turn on SPNEGO Logging and Tracing

To get even more tracing, add the trace string com.ibm.ws.security.spnego.*=all in the Change
Log Detail Levels section of the logging and tracing section for your server in the admin console.
Remember to turn this off for production as well.
IBM Copyright, 2013

SPNEGO

- 21 -
Step 9 Restart WebSphere

SPNEGO is now fully enabled. Restart WebSphere.
On WAS 6.1, check the SystemOut.log file for lines that look like the following:
On WAS 7 and WAS 8, it should look like this:
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
SPNEGO

- 22 -
Step 10 Configure Browsers

Were getting close, but were not done quite yet! Now that SPNEGO is enabled on the server, you
need to configure your browsers to send their Kerberos tokens to the server when challenged.
You need to change a couple of settings to the browsers running on your Windows client machines.
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.
In this example, we set the two fields to robo.home.ca
Chrome
With Google Chrome, no special settings are required.
IBM Copyright, 2013

SPNEGO

- 23 -
Internet Explorer
For Internet Explorer, go into ToolsInternet OptionsSecurityLocal intranetSites and add the
SSO domain.
Here we added *.robo.home.ca.
IBM Copyright, 2013

SPNEGO

- 24 -
You also need to enable Integrated Windows Authentication. Go to ToolsInternet

OptionsAdvanced, scroll down to the Security section, and make sure that Enable Integrated
Windows Authentication is checked.
You will need to restart IE for the changes to take effect.
IBM Copyright, 2013

SPNEGO

- 25 -
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.
IBM Copyright, 2013

SPNEGO

- 26 -
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
SPNEGO

- 27 -
SPNEGO with a Remote Web Server

Introduction
We now have a single working instance of WebSphere with SPNEGO enabled. If you install an http
server and the WebSphere plug-in on the same machine as WebSphere, and deploy your app with
that web server, the SPNEGO exchange still works fine. Life is good!
Now what we want to do is create a multi-tiered environment by putting a separate http server in
front of WebSphere, as displayed in the following topology diagram:
Windows Client
Web Server
Host Name: webserver1.robo.home.ca
Linux Server

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:
IBM Copyright, 2013

SPNEGO

- 28 -
Huh?!?!?! Hitting the cancel button, we get the following page:
What just happened? Life was good five minutes ago!
IBM Copyright, 2013

SPNEGO

- 29 -
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.
IBM Copyright, 2013

SPNEGO

- 30 -
Step 1 Create a New AD User

Create a new AD user called websphere using the same directions from the last section, and give it
a permanent password of password.
IBM Copyright, 2013

SPNEGO

- 31 -
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
SPNEGO

- 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.
IBM Copyright, 2013

SPNEGO

- 33 -
Step 3 Modify Kerberos Configuration on the Application Server

Copy the new key file to your application server (not the web server), and put it in the same
directory as before. Now that you have a new key file, you need to change the Kerberos
configuration file to point to 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.
IBM Copyright, 2013

SPNEGO

- 34 -
Step 4 Update the WebSphere SPNEGO Configuration

The TAI currently contains the application server host name as the SPN, and we need to change that.
Log into the WebSphere admin console and change the TAI property to the name of the web server:

Update the SPNEGO Web Authentication page to change the hostname to the name of the web
server:
In this example, the property was changed from appserver1.robo.home.ca to

webserver1.robo.home.ca
IBM Copyright, 2013

SPNEGO

- 35 -

Restart WebSphere. If you disabled security, re-enable it first.
Restarting WebSphere will produce SystemOut.log file entries similar to the ones shown below:
Notice how the Service Principal Name has changed from the application server to the web server
address.
IBM Copyright, 2013

SPNEGO

- 36 -
Step 6 Surf!
Now surf to the snoop servlet by directing the browser to the web server machine:
We are back in business!

IBM Copyright, 2013
SPNEGO

- 37 -
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.
IBM Copyright, 2013

SPNEGO

- 38 -
Step 7 Re-map the Original SPN and Create a New Key

If we want to re-map the original SPN to a new user, we must first un-map it from the original user.
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.
IBM Copyright, 2013

SPNEGO

- 39 -
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.
IBM Copyright, 2013

SPNEGO

- 40 -
Step 8 Move the Updated Key File to the Server

Copy the key to the WebSphere Application Server machine, putting it in the same directory as
before. Make sure the entry in krb5.conf file points to this key file.
Step 9 Update the WebSphere SPNEGO Configuration

You need to add a second SPN entry in the SPNEGO TAI configuration:
Notice the SPN2 in the new property. You can have as many SPNs as you wish.
IBM Copyright, 2013

SPNEGO

- 41 -

Update the SPNEGO Web Authentication page to include both the application server hostname and
the web server hostname:
IBM Copyright, 2013

SPNEGO

- 42 -

When you restart WebSphere, you should see entries in the SystemOut.log file similar to the
following:
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!
IBM Copyright, 2013

SPNEGO

- 43 -
Clusters and Load Balancing with SPNEGO

Introduction
Now that we have the ability to apply SPNEGO to a multi-tier architecture, we would now like to
scale the system up to provide some load balancing and failover support, as displayed in the
following topology diagram:
Linux Server
Windows Client
Web Server
Host Name: webserver1.robo.home.ca
Linux Server
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.
IBM Copyright, 2013

SPNEGO

- 44 -
Step 1 Create a WebSphere ND Cell

Managing multi-tiered application and web servers is straightforward once they are collected within
a WebSphere ND cell. Set up your WebSphere ND cell to contain your cell manager and all of your
application servers, as shown in the diagram below:
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).
IBM Copyright, 2013

SPNEGO

- 45 -
Step 2 Incorporate the Web Server into the Cell

We would like to be able to send the WebSphere plugin-cfg.xml file directly to the web server
running on webserver1.robo.home.ca without manually manipulating it and/or copying it. We can
do this by adding the web server machine as an unmanaged node within the cell. Click on the Add
Node button from the panel displayed above, and then follow the procedure from the next set of
diagrams:
Select Unmanaged node and Click Next.
Select a name for your node and the host name where the web server is running. Click OK.
IBM Copyright, 2013

SPNEGO

- 46 -
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.
IBM Copyright, 2013

SPNEGO

- 47 -
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.
IBM Copyright, 2013

SPNEGO

- 48 -
Enter in the correct information, click Next, then click Finish.
You now have incorporated the independent web server into your ND cell.
IBM Copyright, 2013
SPNEGO

- 49 -
Step 3 - Create an Application Server Cluster

You have an incorporated cell, and the snoop servlet runs on both nodes within the cell, but that
doesnt mean we can load balance between them just yet. First we need to create an application
cluster, and then deploy it to the nodes and the web server.
Click on the Cluster link in the Servers section of the Admin Console:
Click the New button.
Enter a name for the cluster (we used snoopCluster here), then press then Next button.
IBM Copyright, 2013

SPNEGO

- 50 -
Select a member name for the first member in your cluster, select the node it runs on, and click Next.
IBM Copyright, 2013

SPNEGO

- 51 -
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.
You have successfully created an application cluster.

IBM Copyright, 2013
SPNEGO

- 52 -
Step 4 Deploy Applications to Cluster

Before you can start the cluster, you need to deploy the snoop servlet to it, which is contained in the
default application. Click on the Enterprise Applications link in Applications section of the Admin
Console:
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.
IBM Copyright, 2013

SPNEGO

- 53 -
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.
IBM Copyright, 2013

SPNEGO

- 54 -
Step 5 Set up SPNEGO in the Cluster

Setting up SPNEGO in an ND Cluster is exactly the same as setting up SPNEGO in the earlier
sections, there is just a little more of it.
For this example, there will be a policy that anyone wanting to access the applications servers will
have to be routed through the web server node. This means I only need to have a key for
webserver1.robo.home.ca. Luckily, we already created this key and this mapping in one of the
previous examples, so we dont even need to do that!
Lets follow the steps from the first example, and apply them as needed for the cluster:
Step 1 Create a User ID for the Application Server
We will reuse the websphere AD user that we already created.
We will reuse the websphere.keytab file that we already created for this account
Step 3 Set up Kerberos Configuration on the Application Server
The configuration file already exists on appserver1.robo.home.ca. We can copy it and the
websphere.keytab key file to the same directory on appserver2.robo.home.ca. We can use the
wsadmin command again, but copying the file works just as well.
Step 4 Enable WebSphere Security
Enable global security exactly as before, using the ND admin console.
Step 5 Enable SSO
Same as before.
IBM Copyright, 2013

SPNEGO

- 55 -
Step 6 Enable WebSphere SPNEGO Configuration

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.
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.
IBM Copyright, 2013

SPNEGO

- 56 -
Step 7 Enable SPNEGO at the JVM Level

As in the previous step, you need to enable SPNEGO at the JVM level for each node in your cluster:

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.
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:
IBM Copyright, 2013

SPNEGO

- 57 -
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.
IBM Copyright, 2013

SPNEGO

- 58 -
SPNEGO with Network Dispatchers and IP Sprayers

Now that we have achieved clustering in our environment, we can continue to scale it up with the
use of network dispatchers, as demonstrated in the topology diagram below:
Web Server
Host: webserver1.robo.home.ca
Linux Server
Host: appserver1.robo.home.ca
Windows Client
Host: xpclient.robo.home.ca
Dispatcher
Host: snoopcluster.robo.home.ca
Web Server
Host: webserver2.robo.home.ca
Linux Server
Host: appserver2.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.
IBM Copyright, 2013

SPNEGO

- 59 -
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.
Step 1 When Creating an ID for the Application Server

When you create the AD user ID that the application server uses, you need to set the Account is
trusted for delegation flag on the Account tab of the AD user properties, as displayed below:
Note that this option is not set for the individual client users, only for the application server ID.
IBM Copyright, 2013

SPNEGO

- 60 -
On Windows Server 2000 systems, delegation capability is set in the account options list of the
account tab:
IBM Copyright, 2013

SPNEGO

- 61 -
Step 2 When Enabling SPNEGO in WebSphere

WebSphere Version 6.1 Only
When setting the custom properties of the SPNEGO TAI in the WebSphere admin console, you need
to add an additional property named com.ibm.ws.security.spnego.SPN1.enableCredDelegate and
set its value to true. Once again, be mindful of the spelling and the case.
WebSphere Version 7 and 8

When setting up SPNEGO Web authentication for a host name in Global security, you need to set a
check-box to enable credential delegation:
IBM Copyright, 2013

SPNEGO

- 62 -
Step 3 When Creating the krb5.conf File

After you create the krb5.conf file, you will notice that the forwardable = true line is commented
out, as indicated in the image below:
Remove the comment marker and save the file.
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.
IBM Copyright, 2013

SPNEGO

- 63 -

WebSphere Portal SSO With SPEGNO

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

WebSphere Portal SSO With SPEGNO

Cargado por

Copyright:

Formatos disponibles

WebSphere with a side of SPNEGO

This document can be found on the web, www.ibm.com/support/techdocs

Version 4.0: June 17, 2013

Websphere Technical Sales

IBM Copyright, 2013

Version 4.0, June 17, 2013

Configuration with a single instance of WebSphere Application Server (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

IBM Copyright, 2013

Version 4.0, June 17, 2013

You Have Options!

Differences Between WAS 6.1, WAS 7 and WAS 8

IBM Copyright, 2013

Version 4.0, June 17, 2013

Single Server SPNEGO Configuration

Active Directory Server

IBM Copyright, 2013

Version 4.0, June 17, 2013

Step 1 Create a User ID for the Application Server

Version 4.0, June 17, 2013

In the example environment, the command was issued as follows:

IBM Copyright, 2013

Version 4.0, June 17, 2013

Active Directory 2000 Users

IBM Copyright, 2013

Version 4.0, June 17, 2013

IBM Copyright, 2013

Version 4.0, June 17, 2013

Step 3 Set up Kerberos Configuration on the Application Server

Version 4.0, June 17, 2013

$AdminTask createKrbConfigFile {-krbPath /etc/krb5/krb5.conf

IBM Copyright, 2013

Version 4.0, June 17, 2013

Step 4 Enable WebSphere Security

IBM Copyright, 2013

Version 4.0, June 17, 2013

IBM Copyright, 2013

Version 4.0, June 17, 2013

Step 5 Enable SSO

On WAS 8 it looks like this:

IBM Copyright, 2013

Version 4.0, June 17, 2013

Step 6 Enable SPNEGO in WebSphere

Click on the Interceptors link to get the following:

Click on the com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl link. You will now

Version 4.0, June 17, 2013

IBM Copyright, 2013

Version 4.0, June 17, 2013

Step 6 - WebSphere Version 7 and 8

Important WAS 8 feature:

IBM Copyright, 2013

Version 4.0, June 17, 2013

IBM Copyright, 2013

Version 4.0, June 17, 2013

Step 7 Enable SPNEGO at the JVM level

Step 7 - WebSphere Version 7 and 8

IBM Copyright, 2013

Version 4.0, June 17, 2013

Step 8 Turn on SPNEGO Logging and Tracing

Remember to turn this off for production as well.

IBM Copyright, 2013

Version 4.0, June 17, 2013