WebSphere with a side of SPNEGO - IBM WWW Page · WebSphere with a side of SPNEGO Configuring...

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

[email protected]

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 - Initial Release

1.1 - Corrected hostnames in the examples.

- Change the term ‘Key Volume Number’ with ‘Key Version Number’

2.0 - Clarifications and simplifications

2.1 - Added Windows 2000 disclaimer and cleaned up ktpass examples

2.5 - Expanded examples, standardized hostnames, and tested with Windows 2000

2.6 - Added section on credential delegation

2.7 - Fixed section on credential delegation

3.0 - Changes to include WAS 7

3.1 - Removed disablesecuritypreinvokeonfilters step (see page 27)

- Tweaked credential delegation (again!)

4.0 - Changes to include WAS 8 and AD 2008 R2

© IBM Copyright, 2013 Version 4.0, June 17, 2013

Web location of document (www.ibm.com/support/techdocs) - 3 -

SPNEGO

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



SPNEGO

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-B3BE-

4E7AC4F0912D&displaylang=en

and SP2 here:



SPNEGO

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-B810-

BB6539362473&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-9cfe-

ff01d29e5c46&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.



SPNEGO

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:

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 cross-

certified. 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.

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

Windows Client



Linux Server








SPNEGO

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.



SPNEGO

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/[email protected]

–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.



SPNEGO

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/[email protected]

–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:



SPNEGO

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 don’t

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 don’t need to worry about it right now.

You may also note the documentation referring to the –mapOp flag as well. Again, you don’t need

to worry about that in this example and it will be discussed later on.



SPNEGO

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:



SPNEGO

$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.



SPNEGO

Step 4 – Enable WebSphere Security

Launch the WebSphere admin console, navigate to the ‘Security�Global 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:



SPNEGO



SPNEGO

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:



SPNEGO

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.



SPNEGO

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:



SPNEGO

Step 6 - WebSphere Version 7 and 8

In the admin console, select Security�Global security�Web and SIP security�SPNEGO 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:



SPNEGO

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.



SPNEGO

Step 7 – Enable SPNEGO at the JVM level


You may have multiple JVM’s in your instance of WebSphere, and you may only want SPNEGO

enabled on some of those JVM’s. 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.



SPNEGO

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.



SPNEGO

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.



SPNEGO

Step 10 – Configure Browsers

We’re getting close, but we’re 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.trusted-

uris’. 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.



SPNEGO

Internet Explorer

For Internet Explorer, go into Tools�Internet Options�Security�Local intranet�Sites and add the

SSO domain.

Here we added *.robo.home.ca.



SPNEGO

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.

You will need to restart IE for the changes to take effect.



SPNEGO

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.



SPNEGO

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.



SPNEGO

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:

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

server’s address, and we get the following:

Windows Client



Linux Server






Web Server

Host Name: webserver1.robo.home.ca

Windows Client



Linux Server






Web Server




SPNEGO

Huh?!?!?! Hitting the cancel button, we get the following page:

What just happened? Life was good five minutes ago!



SPNEGO

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

doesn’t map to anything, so AD doesn’t 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.



SPNEGO

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’.



SPNEGO


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/[email protected]

–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.



SPNEGO

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 SPN’s to the same AD user, cutting down on the number of user ID’s you

will need to create to support SPNEGO in your environment (we will see an example of this a little

bit later).

Mapping multiple SPN’s to the same user ID is fine, but mapping the same SPN to multiple user

ID’s is extremely bad! Don’t do it.



SPNEGO

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. It’s up to you.



SPNEGO

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



SPNEGO


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.



SPNEGO

Step 6 – Surf!

Now surf to the snoop servlet by directing the browser to the web server machine:

We are back in business!



SPNEGO

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 ID’s, two SPN’s, and two key files. Let’s revisit the

setspn command to see how we can map both SPN’s to the same AD user ID.



SPNEGO

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 SPN’s.



SPNEGO

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/[email protected]

–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 SPN’s 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/[email protected] –ptype

KRB5_NT_PRINCIPAL–mapUser websphere –mapOp set –pass password –out websphere.keytab

ktpass –prince HTTP/[email protected] –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 SPN’s 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 didn’t 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.



SPNEGO

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 SPN’s as you wish.



SPNEGO


Update the SPNEGO Web Authentication page to include both the application server hostname and

the web server hostname:



SPNEGO


When you restart WebSphere, you should see entries in the SystemOut.log file similar to the

following:

Notice how the two SPN’s 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!



SPNEGO

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:

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.

Windows Client



Linux Server






Web Server


Linux Server


Windows Client



Linux Server






Web Server


Linux Server




SPNEGO

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).



SPNEGO

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.



SPNEGO

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 didn’t, then you won’t see any web servers.

Click New.



SPNEGO

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.



SPNEGO

Enter in the correct information, click Next, then click Finish.

You now have incorporated the independent web server into your ND cell.



SPNEGO

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

doesn’t 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.



SPNEGO

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



SPNEGO

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.



SPNEGO

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.



SPNEGO

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.



SPNEGO

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 don’t even need to do that!

Let’s 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.



SPNEGO

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.



SPNEGO

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:



SPNEGO

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.



SPNEGO

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:

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.

Windows Client

Host: xpclient.robo.home.ca


Linux Server

Host: appserver1.robo.home.ca





Web Server

Host: webserver1.robo.home.ca

Linux Server


Web Server


Dispatcher

Host: snoopcluster.robo.home.ca

Windows Client

Host: xpclient.robo.home.ca


Linux Server






Web Server


Linux Server


Web Server


Dispatcher

Host: snoopcluster.robo.home.ca



SPNEGO

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.



SPNEGO

On Windows Server 2000 systems, delegation capability is set in the account options list of the

account tab:



SPNEGO

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:



SPNEGO

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.

WebSphere with a side of SPNEGO - IBM WWW Page · WebSphere with a side of SPNEGO Configuring...

Documents

Transcript of WebSphere with a side of SPNEGO - IBM WWW Page · WebSphere with a side of SPNEGO Configuring...