Integrating SPNEGO with IBM Lotus Sametime Purvi Trivedi Stephen Shepherd

Integrating SPNEGO with IBM Lotus Sametime
Purvi Trivedi
Advisory Software Engineer
IBM Software Group
Westford, MA USA
Stephen Shepherd
Senior Software Engineer
IBM Software Group
Bedford, NH USA
June 2009
© Copyright International Business Machines Corporation 2009. All rights reserved.
Abstract: Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) enables
the single sign-on (SSO) mechanism for Microsoft® Windows® clients that are part of a
Microsoft Active Directory Domain. This white paper explains the steps necessary to
configure SSO for IBM® Lotus® Sametime® Connect clients and IBM Lotus Notes®
clients integrated with IBM Lotus Sametime, using SPNEGO.
Table of Contents
1 Overview........................................................................................................................... 3
2 Installing WebSphere Application Server 7.0 and configuring authentication with
Active Directory...................................................................................................................3
2.1 Installing WebSphere Application Server 7.0........................................................... 3
2.2 Configure WebSphere Application Server 7.0 to authenticate to Active Directory. 5
3 Configuring WebSphere Application Server 7.0 with SPNEGO..................................... 7
3.1 Configure SPNEGO on Active Directory server.......................................................7
3.2 Configure SPNEGO as Web Authenticator for WebSphere Application Server 7.0..
10
3.3 Enabling SSO for WebSphere Application Server 7.0........................................... 14
4 Configuring client machine browsers............................................................................. 16
4.1 For Internet Explorer 6.x and 7.x............................................................................ 16
4.2 For Mozilla Firefox 3.x........................................................................................... 17
4.3 Confirm WebSphere Application Server is configured correctly for SPNEGO..... 18
5 Configuring Lotus Sametime with Active Directory...................................................... 18
5.1 Advanced LDAP configuration during installation.................................................18
5.2 Advanced LDAP Configuration after the installation............................................. 25
6 Enabling SSO for Sametime server using WebSphere token........................................ 28
6.1 Generate and export Lightweight Third-party Authentication (LTPA) token.........28
6.2 Create Web SSO document on the Sametime Server............................................. 30
7 Enabling client applications for SPNEGO...................................................................... 31
7.1 Enabling Sametime Connect Client with SPNEGO................................................31
7.2 Enabling SPNEGO for the embedded Sametime in Notes Client........................... 33
8 Troubleshooting and testing............................................................................................ 33
8.1 Confirm SPNEGO is properly configured in WebSphere Application Server....... 33
8.2 Verify SSO is properly configured in WebSphere Application Server................... 37
8.3 Enable tracing in WebSphere Application Server................................................... 38
8.4 Verify SSO is properly configured in Lotus Sametime........................................... 40
8.5 Enabling Sametime debug....................................................................................... 42
9 Conclusion...................................................................................................................... 44
10 Resources...................................................................................................................... 44
11 About the authors.......................................................................................................... 45
1 Overview
This white paper is intended to serve as a “quick start” guide that explains how to:
•
•
•
enable SPNEGO in Microsoft Active Directory
configure IBM WebSphere® Application Server 7 to use SPNEGO
use a WebSphere Application Server token to enable Lotus Domino and extended
products like Sametime Connect Client and Lotus Notes to use SPNEGO.
Figure 1 illustrates the various client and server components and interactions that we
address in this paper. (NOTE: Information for this diagram was derived from the
Sametime 8.0 Information Center)
Figure 1. Client and server components/interactions
2 Installing WebSphere Application Server 7.0 and
configuring authentication with Active Directory
For this configuration we have WebSphere Application Server authenticating against
Active Directory.
2.1 Installing WebSphere Application Server 7.0
The steps below are designed to navigate you through the basic configuration, to get you
up and running quickly. If you need more details, refer to the WebSphere Application
Server Information Center topic, Installing your application serving environment.
1. Install from the installation image on the product media or from the downloaded
Passport Advantage® image (Part number C1G0QML).
2. Download the required fixes:
•
Update Installers: http://www-01.ibm.com/support/docview.wss?
uid=swg21205991
•
Latest Fixpack from Fix Central (at the time of this writing, FP3 was the latest):
http://www-933.ibm.com/eserver/support/fixes/fixcentral/swg/selectfixes
3. Start the install by launching launchpad.exe:
a. Navigate to the WebSphere Application Server Installation tab.
b. Select the “Launch the installation wizard for the WebSphere Application Server”
option.
4. As you proceed through the wizard, select the options appropriate for your
configuration. If any of the pre-requisite checks fail, look for the problem in the
WebSphere Application Server log files located under: C:\Documents and Settings
\Administrator\waslogs. In our configuration we:
•
•
•
•
•
Selected no optional features
Set the install location to E:\IBM\WebSphere\AppServer
Set the WebSphere Application Server environment to “Application Server”
Enabled administrative security and set the local administrator to “admin” and
password to “password”
Started the install
5. Once the install has successfully completed, start the server. If there are any errors,
check the logs under E:\IBM\WebSphere\AppServer\profiles\AppSrv01\logs\server1
\startServer.
To launch the server, use either:
•
The menu commands, Start > All Programs > IBM WebSphere > Application
Server v7.0 > Profiles > AppSrv01 > Start the server, or
•
The command line, navigating to E:\IBM\WebSphere\AppServer\bin and
issuing the command: startServer server1
6. Next, we need to install the Update Installer and the Fixpack that you downloaded in
the first step. However, before doing this we must stop the Application Server. If you
have enabled administrative security, you need to enter the credentials (admin/
password):
Using command line window, navigate to E:\IBM\WebSphere\AppServer\bin and
issue the command: stopServer server1 -user admin -password password
7. Launch the install.exe from the UpdateInstaller directory. In our configuration we
selected to install it under E:\IBM\WebSphere\UpdateInstaller.
8. Once the Update Installer is successfully installed, we need to copy all the fixes we
downloaded in the first step to E:\IBM\WebSphere\UpdateInstaller\maintenance.
9. Launch the Update Installer:
a. Start > All Programs > IBM WebSphere > Update Installer for WebSphere v7.0
Software > Update Installer.
b. Select 'Install maintenance package'; the Directory path should be the same as that
in Step 7.
c. Select applicable packages (In our case we selected, 7.0.0-WS-WAS-WinX32FP0000003.pak)
d. Select to install the maintenance package(s)
10.Once the installation of the latest maintenance packs completes, start the server. Now
we are ready to enable security.
2.2 Configure WebSphere Application Server 7.0 to authenticate
to Active Directory
To enable security, follow these steps:
1. Launch the WebSphere Application Server console, using Start > All Programs IBM
WebSphere > Application Server v7.0 > Profiles > AppSrv01 > Administrative
console. An example of the URL might be: https://vmpewas.notesdev.ibm.com:9043/
ibm/console.
2. Authenticate using the administrator's ID and password created during installation of
WebSphere Application Server, for example, admin/password.
3. Navigate to Security > Global Security, and click the Security Configuration Wizard
button:
a. For Specify extent of protection, select “Enable application security”; click Next.
b. For User repository, select the repository that has the users and groups used for
authentication. In our case we selected “Standalone LDAP registry”.
c. Populate the Configure standalone LDAP registry dialog box (see figure 2).
Figure 2. Configure standalone LDAP registry
where the field Primary administrative user name = wsadmin, Type of LDAP
server = Microsoft Active Directory, Host = vmpeAD.notesdev.ibm.com, and Port
= 389.
The Base DN in this environment is:
DC=pelab,DC=notesdev,DC=ibm,DC=com
The Bind DN is:
CN=wasadmin,CN=users,DC=pelab,DC=notesdev,DC=ibm,DC=com
d. Select “Step 4: Summary” to ensure all settings look correct; click Finish.
4. Now we need to confirm that security is enabled. To do this, restart WebSphere
Application Server and try to view the status of the server, using the Command line
argument: serverStatus -all.
5. This time you will be prompted for a username/password (see figure 3). This user
should exist in your LDAP repository; in our case, we used wasadmin/Pa88w0rd,
which was previously created in the LDAP directory.
Figure 3. Username/password prompt
Being able to log in with your LDAP user confirms security is enabled correctly.
6. Another way to test whether security is enabled is to launch the WebSphere
Application Server console, using Start > All Programs IBM WebSphere >
Application Server v7.0 > Profiles > AppSrv01 > Administrative console.
If you try to log in using the old admin/password; it will fail. Now try to log in with the
username and password specified in your LDAP, for example, wasadmin/Pa88w0rd.
You should be able to log in successfully.
3 Configuring WebSphere Application Server 7.0 with
SPNEGO
SPNEGO Web Authentication is a new feature in WebSphere Application Server 7.0. If
you are using version 6.x, then you must use Trust Association Interceptor (TAI) to
configure WebSphere Application Server for SPNEGO. For more details, refer to the
Techdocs Library white paper, “WebSphere with a side of SPNEGO.”
3.1 Configure SPNEGO on Active Directory server
All client machines must be part of the same Active Directory domain as Active
Directory server. (If client machines are in a different domain, the Active Directory
servers must be cross-certified.) Here are the steps to configure an Active Directory
identity for WebSphere Application Server:
1. Create a User ID for WebSphere Application Server. This ID can be the name of your
machine, for example, VMPEWAS; however, it cannot be the ID that is used to enable
WebSphere Application Server security (in our case, for example, we cannot use
wasadmin).
This newly created ID will be used by WebSphere Application Server to authenticate
with Active Directory.
NOTE: Under Account options in the Account tab, select “'Password never
expires” (see figure 4). If this option is not selected, you will be required to generate a
new key each time the password changes.
Figure 4. Create User account
2. Now we need to map the account created in Step 1 to the Kerberos Service Principal
Name (SPN) and create the keytab file that WebSphere Application Server will use to
log in to the Active Directory domain:
On the Active Directory machine, open a command line and issue the “ktpass”
command as follows:
ktpass -out <keyfile name> -princ HTTP/fully qualified hostname@AD
DOMAIN NAME -mapuser <AD user> -pass <password> -ptype
KRB5_NT_PRINCIPAL
NOTE: “HTTP” and the Active Directory domain name must be in capital letters for
this command; if you use lower case, authentication will fail.
For our environment the command looks like that shown in figure 5.
Figure 5. “ktpass” command output
3. Next, check the user account properties for vmpewas. The User logon name (see figure
6) should have been changed to the SPN name, confirming the SPN is mapped to user
account vmpewas.
Doing this mapping informs Active Directory that any authenticated client machine in
the PELAB.NOTESDEV.IBM.COM domain, using HTTP or HTTPs to talk to
WebSphere Application Server vmpewas.notesdev.ibm.com, will authenticate to the
newly created vmpewas account.
Figure 6. User logon name
4. Now we must move the vmpewas.keytab created in Step 2 from the Active Directory
server to WebSphere Application Server (we placed ours under E:\IBM
\vmpewas.keytab).
3.2 Configure SPNEGO as Web Authenticator for WebSphere
Application Server 7.0
In this section we enable SPNEGO as the Web Authenticator for WebSphere Application
Server. First, make a note of the location of the keytab file copied over from the Active
Directory server, for example, E:\IBM\vmpewas.keytab.
1. Using the keytab file, we need to set up the Kerberos configuration file:
a. Start WebSphere Application Server.
b. From the Command line, change directory to the Application server bin directory,
that is, E:\IBM\WebSphere\AppServer\bin.
c. Run wsadmin; enter the username/password to authenticate.
d. Issue the following AdminTask command to create the Kerberos configuration file:
$AdminTask createKrbConfigFile {-krbPath <config file name> –realm
<KERBEROS REALM> -kdcHost <AD hostname> -dns <dns domain> –
keytabPath /etc/krb5/<keytab filename>}
where:
•
•
•
•
•
krbPath flag points to the location where you want the krb5.ini placed,
realm flag corresponds to the Active Directory domain and it must be capital
letters,
kdcHost flag is the hostname of Active Directory server,
dns flag is the dns domain, and
keytabPath is the path to the keytab file we copied over from the Active
Directory server (see figure 7).
Figure 7. keytabPath example
Note that krb5.ini is used by WebSphere Application Server to authenticate to Active
Directory (see figure 8).
Figure 8. Example krb5.ini authentication
2. Now let's enable WebSphere Application Server security with SPNEGO:
a. From the WebSphere Application Server administrative console page, select
Security > Global Security, and under Authentication, go to Web and SIP Security,
and select SPNEGO Web authentication (see figure 9).
Figure 9. Enabling SPNEGO Web authentication
b. Select the options “Dynamically update SPNEGO” and “Enable SPNEGO” (see
figure 10).
c. The “Kerberos configuration file with full path” field is the path to the file we
created in Step 2, for example, E:\IBM\krb5.ini.
d. The “Kerberos keytab file with full path” is the path to the file we copied over
from Active Directory server to WebSphere Application Server, for example, E:
\IBM\vmpewas.keytab.
Figure 10. SPNEGO Web authentication properties
e. Under SPNEGO filters, click New, to create a new SPNEGO filter for
vmpewas.notesdev.ibm.com (see figure 11). Here, “Host name” is the name of
your WebSphere Application Server, and “Kerberos realm name” is the name of
the Active Directory realm, which must be in capital letters. Also, the option
“Trim Kerberos realm from the principal” must be enabled for this to work.
Figure 11. New SPNEGO filter properties
3. Click OK and click Save, and then restart WebSphere Application Server; it is now
configured with SPNEGO.
3.3 Enabling SSO for WebSphere Application Server 7.0
We now enable SSO for WebSphere Application Server:
1. From the administrative console page, select Security > Global Security, and under
Authentication, go to Web and SIP Security and select Single sign-on (SSO), as shown
in figure 12.
Figure 12. Enabling SSO
2. Under General Properties, select Enabled, and in the Domain name field enter the
DNS Domain name (see figure 13).
3. Click OK and click Save.
Figure 13. SSO properties
.
4 Configuring client machine browsers
Log in to the Active Directory domain on the client machine. Before we can validate that
WebSphere Application Server is configured correctly to use SPNEGO, we must change
some browser settings.
4.1 For Internet Explorer 6.x and 7.x
1. Select Tools > Internet Options > Security > Local Intranet > Sites > Advanced. Add
the SSO domain here (see figure 14).
Figure 14. Add SSO domain
2. Now select Tools > Internet Options, click the Advanced tab, and under Settings,
check the option “Enable Integrated Windows Authentication” (see figure 15).
Figure 15. Enable Integrated Windows Authentication
3. Restart the browser; now we're all set.
4.2 For Mozilla Firefox 3.x
1. Type “about:config” in the address bar. A warning displays; click OK on the warning.
2. Set the filter to “auth”, and set the values of “network.negotiate-auth.delegation-uris”
and “network.negotiate-auth.trusteduris” to the SSO domain, notesdev.ibm.com (see
figure 16).
Figure 16. Set SSO domain
3. Restart the browser; you're all set.
4.3 Confirm WebSphere Application Server is configured
correctly for SPNEGO
1. Log in to your Windows client that is part of Active Directory Domain.
2. Open a browser and enter the URL http://vmpewas.notesdev.ibm.com/snoop.
3. You should not be prompted to enter your username and password; however, if you are
prompted to enter your log-in credentials, refer to the Troubleshooting and testing
section at the end of this paper.
5 Configuring Lotus Sametime with Active Directory
Lotus Sametime authentication with Active Directory can be completely configured
during the installation, or you can choose to perform the advanced configuration after the
installation. Both methods are discussed below.
5.1 Advanced LDAP configuration during installation
During the installation of the Sametime server, the screen “Select the directory to use for
collaboration” will display (see figure 17).
1. Select LDAP Directory, enter the fully qualified host name of the Active Directory
server in the LDAP Server Name field, and place a check the Advanced LDAP
Configuration checkbox.
NOTE: If you want to perform the Advanced LDAP configuration, proceed to Section
5.2, “Advanced LDAP Configuration after the installation” below.
Figure 17. Select the LDAP directory for collaboration
2. Click Next; the “Specify how to bind the Sametime server to the LDAP directory”
screen displays (see figure 18).
Figure 18. Specify how to bind Sametime server to LDAP directory
3. Select the Authenticated access radio button, and enter the full LDAP distinguished
name of the user in the Active Directory who has at least Read access, and enter that
person's password. (You may need to check with your Active Directory administrator
to obtain this information.)
4. Click the Test Connection button. If everything is configured correctly, a dialog box
should display stating “LDAP connection succeeded”.
5. Click OK and then click Next; the “Specify the authentication setting for Sametime
users to authenticate with an LDAP directory” screen displays (see figure 19).
Figure 19. Specifying authentication setting for Sametime users
6. The “Search filter to resolve a user name to a distinguish name” field should be:
(&(objectclass=organizationalPerson)(|(cn=%s)(sn=%s)(samAccountName=%s)
(mail=%s)))
7. The “Attribute in LDAP directory containing home Sametime server” field can be left
blank for our purposes. (This field is required if you have a Sametime community with
multiple servers. This may require a schema modification to add a new attribute, and
schema modification is beyond the scope of this paper.)
8. The “Sametime Administrator account in LDAP directory” field is needed for policies.
This name can be the same as the bind distinguish name specified previously, or it can
be any other administrator's LDAP distinguish name.
9. Click Next; the “Specify the search and filter criteria for people” screen displays (see
figure 20).
Figure 20. Specify the search and filter criteria for people
10. The “Search filter for selecting a name of a person from the LDAP directory” field
should be:
(&(objectclass=organizationalPerson)(|(cn=%s*)(sn=%s*)(samAccountName=%s*)
(mail=%s*)))
11. Enter the base object to start searching for persons. This base depends on your Active
Director tree structure.
12. Leave the “Policy search filter for base membership” field blank and click Next; the
“Specify the basic LDAP settings used for people entries” screen displays (see figure
21).
Figure 21. Specify the basic LDAP settings used for people entries
13.You can accept the defaults here; click Next. The “Specify the search and filter criteria
for groups” screen displays (see figure 22).
Figure 22. Specify the search and filter criteria for groups
14. Enter the following for the search filter for selecting groups:
(&(objectclass=group)(cn=%S*))
15. Enter the base object to start searching groups. Again, the base depends your Active
Directory tree structure.
16. The “Policy search filter for group membership” field should be entered as an
attribute member, instead of an actual search filter. The Sametime policy task will
examine this field and, since it is not a search filter, it will request this attribute when
searching for users and groups. This improves performance.
17. Click Next; the “Specify the basic LDAP settings used for group entries” screen
displays (see figure 23)
Figure 23. Specify the basic LDAP settings used for group entries
18. Accept the default for the Attribute that defines the display name of a group field.
Specify the group object class as “group”, and specify the attribute in the group object
that has the names of group members as “member”.
19. Click Next to proceed with the rest of the installation.
20. Once the installation is complete, start the Sametime server.
21. Using the Domino Administrator client, open the Directory Assistance database
(DA.nsf) and open the LDAP document.
22. Click the Edit Document button and click the LDAP Tab; a screen similar that shown
in figure 24 displays.
Figure 24. LDAP tab for the DA.nsf database
23.Change the “Base DN for search” field from
cn=users,dc=pelab,dc=notesdev,dc=ibm,dc=com
to
DC=pelab,DC=notesdev,DC=ibm,DC=com.
24. At the bottom of the screen, click the drop-down arrow next to the “Standard LDAP”
field value and select Active Directory (see figure 25) .
Figure 25. Changing the “Type of search filter to use” field
25. Click OK, and click the Save and Close button.
5.2 Advanced LDAP Configuration after the installation
If you did not select advanced LDAP configuration during the installation, you can do it
by using the Domino Administrator client. The installation creates an LDAP document in
the stconfig.nsf database and a directory assistance database named da.nsf:
1. Make sure the Sametime Server is started.
2. Start the Domino Administration Client; this can be done via any server in your
Domino domain.
3. Select the File > Open Server menu, enter the Sametime server, and click OK.
4. Click the Files tab and open the database stconfig.nsf.
5. Edit the LDAP document, modifying the fields as outlined in figure 26.
Figure 26. LDAP document fields
LDAP Server Settings:
Connection Settings
Organization Name:
Network Address of LDAP Connection: vmpead.notesdev.ibm.com
Port number for LDAP Connection: 389
Login Name for LDAP Connection: cn=Directory
Administrator,cn=users,dc=pelab,dc=notesdev,dc=ibm,dc=com
Password for LDAP Connection: Pa88w0rd
SSL Enabled: false
SSL Port: 636
Search Order: 1
Search Filters
Search filter for resolving person names:(&(objectclass=organizationalPerson)(|(cn=%s*)(sn=%s*)
(sAMAccontName=%s*)(mail=%s*)))
Search filter to use when resolving a user name to a distinguished name: (&
(objectclass=organizationalPerson)(|(cn=%s)(sn=%s)(sAMAccountName=%s)(mail=%s)))
Search filter for resolving group names: (&(objectclass=group)(cn=%s*))
Search Base and Scope
Base Objects
Base object when searching for person entries:
cn=users,dc=pelab,dc=notesdev,dc=ibm,dc=com
Base object when searching for group entries:
ou=groups,dc=pelab,dc=notesdev,dc=ibm,dc=com
Scope
Scope for searching for a person: recursive
Scope for searching for groups: recursive
Schema Settings
People
Groups
The attribute of the person entry that defines the internal ID of a Sametime user:
The attribute of the person entry that defines the person's name: cn
Attribute used to distinguish between two similar person names:
Attribute of the person entry that defines the person's e-mail address: mail
The person object class used to determine if an entry is a person: organizationalPerson
Attribute used to distinguish between two similar group names:
The attribute of the group entry that defines the group’s name: cn
Attribute in the group object class that has the names of the group members: member
The group object class used to determine if an entry is a group: group
Home Server
Name of the Home Server Attribute:
Membership
GroupMembership: memberof
BaseMembership:
6. Save the document and then open the Directory Assistance database da.nsf.
7. Click the LDAP tab and modify the fields as shown is shown in figure 27.
Figure 27. LDAP tab of DA.nsf database
8. Click the Save and Close button.
9. Add the Sametime administrator that is defined in the LDAP repository to the ACL of
the stconf.nsf and stconfig.nsf databases. If the Sametime administrator's LDAP DN is
cn=Sametime Administrator,cn=users,dc=pelab,dc=notesdev,dc=ibm,dc=com
then add the administrator to the ACLs, replacing the commas with forward slashes
(see figure 28):
cn=Sametime Administrator/cn=users/dc=pelab/dc=notesdev/dc=ibm/dc=com
Figure 28. Access Control List for Sametime Configuration database
10. Restart the Sametime Server.
11. Install a Lotus Sametime Connect client and make sure you can log in to Sametime
using a valid Active Directory user account.
12. Open a browser and access Sametime with an URL similar to the following:
http://vmpest.notesdev.ibm,com/stcenter.nsf
and log in with a valid Active Directory account.
6 Enabling SSO for Sametime server using WebSphere
token
Let's now enable SSO for Sametime server using a WebSphere token.
6.1 Generate and export Lightweight Third-party Authentication
(LTPA) token
1. To export the WebSphere Portal token, log in to the WebSphere Application Server
console, select Security > Global Security, and under Authentication, select LTPA (see
figure 29).
Figure 29. LTPA authentication
2. Under the Key generation section, set the “Key set group” field to
NodeLTPAKeySetGroup and click the Generate keys button (see figure 30).
Figure 30. Key generation
3. Under Cross-cell single sign-on, set the password and the fully qualified key file name,
and click the Export keys button (see figure 31).
Figure 31. Cross-cell single sign-on
4. Confirm that a Messages dialog comes up stating “The keys were successfully
exported to the file C:\ibm\vmpewas.ltpa.”
5. Now we copy over vmpewas.ltpa to a machine that has the Domino Administration
Client, so that we can configure SSO using this WebSphere token.
6.2 Create Web SSO document on the Sametime Server
1. Start the Domino Administration Client, select File > Open Server, and enter the
name of the Sametime Server.
2. Select Configuration, expand Servers, and All Servers.
3. Click Web > Create Web SSO Configuration.
4. Click Keys > Import WebSphere LTPA Keys (see figure 32).
Figure 32. Import WebSphere LTPA Keys
5. Type in the path and the name of the LTPA key file, as shown in figure 33.
Figure 33. Enter Import File name
6. Type in the password; the key should be imported.
7. Make sure the Configuration Name field is “LtpaToken” (see figure 34).
8. Enter the DNS domain to your domain name and then set the “Map names in LTPA
tokens” field to Disabled.
9. Add all the Sametime servers to the Domino Server Names list. All the data in the
WebSphere Information section will populate automatically after importing the
WebSphere token.
Figure 34. LtpaToken Configuration document
10. Save the document.
11. Open the Edit the Server document.
12. Click the Internet Protocol tab and then the Domino Web Engine tab.
13. Change the Session authentication to Multiple Servers (SSO) and ensure the Web
SSO configuration field is set to LtpaToken.
14. Save the document and restart the server.
7 Enabling client applications for SPNEGO
Here we discuss how to enable client applications for SPNEGO.
7.1 Enabling Sametime Connect Client with SPNEGO
1. Start the Sametime Connect client, and from the menu select File > Preferences >
Server Communities, Create a new server community.
2. On the Log In tab (see figure 35), select the “Use token based single sign-on” option.
Set the Authentication server URL field to your WebSphere Application Server
hostname/snoop and set Authentication type to “SPNEGO”.
Figure 35. New Server Community Log In tab
3. On the Server tab (see figure 36), set the Host server field to the Sametime server.
Figure 36. New Server Community Server tab
4. Click OK; you should now be able to log in to the Sametime Connect client without
entering a username or password (see figure 37).
Figure 37. Sametime Connect log in
7.2 Enabling SPNEGO for the embedded Sametime in Notes
Client
1. Start the Notes client and select File > Preferences > Sametime > Server Communities.
2. The setting here will be exactly the same as shown above in Section 7.1 above.
Once these settings are in place, Sametime authentication should work without needing a
username and password (see figure 38).
Figure 38. Sametime in Notes client log in
8 Troubleshooting and testing
8.1 Confirm SPNEGO is properly configured in WebSphere
Application Server
1. Log in to your Windows client and open Internet Explorer.
2. Select Tools > Internet options from the menu, and click the Advanced tab.
3. Scroll down to the Security section and make sure “Enable Integrated Windows
Authentication” is enabled.
4. Now select Tools > Internet Options > Security tab > Local intranet; click Sites, click
Advanced, and add the SSO domain in the Local intranet dialog box (see figure 39).
Figure 39. Add SSO domain web site
5. Start Wireshark, which can be downloaded from http://www.wireshark.org/
download.html, and select Capture > Interfaces from the menu.
6. Select the correct adapter and then click the Start button.
7. Restart the browser if you made changes in step 5 or 6.
8. Enter the URL http://vmpewas.notesdev.ibm.com/snoop and stop Wireshark, using
Capture > Stop.
9. Obtain the IP address of your Active Directory domain controller.
10. In the Filter field, enter http, and then click Apply. Navigate to the lines
GET /snoop HTTP/1.1
HTTP/1.1 401 Unauthorized (text/html)
11. Highlight the HTTP/1.1 401 Unauthorized packet; you'll notice WWW-Authenticate:
Negotiate\r\n (see figure 40).
Figure 40. WWW-Authenticate: Negotiate\r\n
12. Navigate to and highlight the second GET /snoop HTTP/1.1, and in the detail packet
window you can see the SPNEGO Token (see figure 41).
Figure 41. SPNEGO Token
13. If SPNEGO is not configured, the HTTP/1.1 Unauthorized packet will show WWWAuthenticate: Basic Realm (see figure 42).
Figure 42. Basic Realm
8.2 Verify SSO is properly configured in WebSphere Application
Server
Assuming you have confirmed that SPNEGO is properly configured, perform the
following steps to confirm the same for SSO:
1. Log in to your Windows client and open Internet Explorer.
2. Start Wireshark and select Capture > Interfaces.
3. Select the correct adapter then click the Start button.
4. Enter the URL http://vmpewas.notesdev.ibm.com/snoop and stop Wireshark, using the
Capture > Stop menu items.
5. Obtain the IP address of your Active Directory domain controller.
6. In the Filter field, enter “http” and click Apply. Navigate to the HTTP/1.1 OK packet,
and in the detail packet window, notice LtpaToken2 and LtpaToken (see figure 43).
Figure 43. LtpaToken2 and LtpaToken
If the HTTP 200 response does not contain the tokens, then SSO is not set up
correctly.
7. Log in to the administrator console via the URL https://vmpewas.notesdev.ibm.com:
9043/ibm/console.
8. Select Security > Global Security, and expand Web and SIP security.
9. Click Single Sign-on (SSO) and make sure Enabled is checked. If it is checked, and
you received HTTP 403 forbidden error or you are prompted for username and
password at log in, there maybe a problem validating the credentials with the Active
Directory, in which case, you should enable tracing.
8.3 Enable tracing in WebSphere Application Server
1. Log in to the administrator console via the URL
https://vmpewas.pelab.notesdev.ibm.com:9043/ibm/console
2. Expand the Troubleshooting section and click Logs and trace.
3. Click the Server (server1), click Diagnostic Trace, and click Change Log Detail levels.
4. Enter *=info: com.ibm.ws.security.spnego.*=all: com.ibm.ws.security.ltpa.*=all
5. Stop WebSphere Application Server.
6. Navigate to the Log directory, for example, C:\IBM\WebSphere\AppServer\profiles
\AppSrv01\logs\server1, and either delete trace.log or rename trace.log, if present.
7. Start WebSphere Application Server and log in to your Windows client.
8. Open Internet Explorer and enter the URL http://vmpewas.notesdev.ibm.com/snoop.
9. On WebSphere Application Server, examine the trace.log file. You may see something
similar to the following:
[5/11/09 16:06:41:776 EDT] 00000015 LdapRegistryI E SECJ0362E: Cannot
create credential for the user [email protected].
In this case the problem occurs because an LDAP Search was performed with a search
filter [email protected] and
objectcategory=user. We can see this by using Wireshark:
a. Start Wireshark on WebSphere Application Server and select Capture > Interfaces.
b. Select the correct adapter then click the Start button.
c. Log in to the Windows client and open Internet Explorer.
d. Enter the URL http://vmpewas.notesdev.ibm.com/snoop.
e. Stop Wireshark, using Capture > Stop, enter “ldap” in the Filter field, and click the
Apply button (see figure 44).
Figure 44. LDAP capture
10. To correct the problem, log in to the WebSphere Application Server administrator's
console.
11. Click Security > Global Security, and expand Web and SIP security.
12. Click SPNEGO Web Authentication and click the host name in SPNEGO Filters.
13. Check the box next to the option “Trim Kerberos realm from principal name”.
14. Click OK and click Save.
15. Log out of the administrator client and stop WebSphere Application Server.
16. Restart WebSphere Application Server.
8.4 Verify SSO is properly configured in Lotus Sametime
1. Log in to your Windows client and open Internet Explorer.
2. Enter the URL http://vmpewas.notesdev.ibm.com/snoop.
3. Change the URL to access stcenter.nsf on the Sametime server, using a URL such as
http://vmpest.notesdev.ibm.com/stcenter.nsf
You should see yourself logged in (see figure 45).
Figure 45. Welcome screen
4. If you do not see yourself logged on, make sure SSO has been properly enabled on the
Sametime server.
5. Also, you can enable debug by setting the Notes.ini parameters, as follows:
debug_sso_trace_level=3
enable_console_log=1
6. Restart the Sametime server and repeat Steps 1 through 3.
7. Open console.log on the Sametime server. This is in the IBM_Technical_Support
directory under the Domino data directory.
8. The console.log might show output like:
05/13/2009 09:26:32.82 AM [17BC:0012-08C4] SSO API> Token does not lead with 0
[Single Sign-On token is invalid].
05/13/2009 09:26:32.82 AM [17BC:0012-08C4] SSO API> ERROR: when decoding
Domino LtpaToken [Single Sign-On token is invalid].
The error (in bold) occurs when the Web SSO document in the Domino directory is
created with a Domino key.
Also, there could be a problem decrypting a WebSphere style, in which case the
console.log might look similar to the following:
05/13/2009 02:16:25.21 PM [0DC8:0017-0FA0] SSO API> Decrypt WebSphere style
Single Sign-On token (LTPA). [0] != u.
05/13/2009 02:16:25.21 PM [0DC8:0017-0FA0] SSO API> ERROR: when decoding
LtpaToken [Single Sign-On token is invalid].
05/13/2009 02:16:25.21 PM [0DC8:0017-0FA0] SSO API> *** Freeing Single Sign-On
Token List (SECTokenListFree) ***
05/13/2009 02:16:25.21 PM [0DC8:0017-0FA0] SSO API> *** Freeing Single Sign-On
Token (SECTokenFree) ***
05/13/2009 02:16:25.21 PM [0DC8:0017-0FA0] SSO API> *** Freeing Single Sign-On
Token (SECTokenFree) ***
05/13/2009 02:16:25.34 PM [0DC8:0017-0FA0] SSO API> *** Validating Token List
(SECTokenListValidateAndGetInfo) ***
9. To resolve the problem, you could export the LTPAToken from WebSphere
Application Server and recreate the Web SSO document on the Sametime server.
The console.log should look similar to the following when SSO is configured
correctly on the Sametime Server:
05/13/2009 02:51:00.78 PM [0D08:0012-0F2C] SSO API> -Raw Token Username =
CN=wasadmin,CN=Users,dc=pelab,dc=notesdev,dc=ibm,dc=com
05/13/2009 02:51:00.78 PM [0D08:0012-0F2C] SSO API> -LDAP Realm
=
vmpe07.notesdev.ibm.com\:389
05/13/2009 02:51:00.79 PM [0D08:0012-0F2C] SSO API> -Username
=
CN=wasadmin/CN=Users/dc=pelab/dc=notesdev/dc=ibm/dc=com
05/13/2009 02:51:00.79 PM [0D08:0012-0F2C] SSO API> -Raw Token Username =
CN=wasadmin,CN=Users,dc=pelab,dc=notesdev,dc=ibm,dc=com
05/13/2009 02:51:00.79 PM [0D08:0012-0F2C] SSO API> -Expiration Ticks =
1242247860666 [05/13/2009 04:51:00 PM].
8.5 Enabling Sametime debug
At times it may be desirable to enable debug on the Sametime server. To do this:
1. Add the following to the Notes.ini:
ST_DEBUG_FILE_NAME={Install Directory}\trace\stnotes.txt
2. Add the following to the Sametime.ini under the [Debug] section:
VP_LDAP_TRACE=1
VP_REG_TRACE=1
VP_AUTH_TRACE=1
STLINKS_DEBUG_LEVEL=5
3. Stop the Sametime server and delete the contents of the \Install Directory\trace folder.
4. Restart the Sametime server and examine stnotes.txt. The following is output in
stnotes.txt for a successful log on:
String <size=0>:
Calling LtpaDecodeToken
Calling decode using: g_pfnLTPADecode
LtpaDecodeToken returned with status (0)
User ID from the client User ID from the token- CN=wasadmin/CN=Users/dc=pelab/dc=notesdev/dc=ibm/
dc=com
Token - OA
+f0UbasVMyD7RibMWGKj9xEoNKndJDi0mtiaaL6LEc9yV1SZNZcLKglKFBaGpD3
+XJBk7iO62wDh9W8IO5kaX5Whq2+uz5VUXYmcxWxRMGPo/
QsL4agEOGhSvgVo2jhgrixe23dVpGwr9G
+CKuDNi3CIunPlGaLJ8kLu0wzY9NwNHCZkc0Od3CL00SDtUQBOeV+aUYv
+YOE3W4d9vX7oV4vGujzIaGtVs+e4LLGmxViXGNhb8p2WzLEbkNcBQGj+K3C
+FB4UrbLH2cCatTGxQ7/jRjFhgKHkJtrNb
+QQreTf1MvJugn31GipRcaA5CABq8AWxdv4rPzaeTlpBoSXNGD6SX61I4GvZKQgd
GCSPcytHZfT0E/Q==
getUserId: arguments: originalUser[] userFromToken[CN=wasadmin/CN=Users/
dc=pelab/dc=notesdev/dc=ibm/dc=com]
getUserId: about to resolve : [CN=wasadmin/CN=Users/dc=pelab/dc=notesdev/dc=ibm/
dc=com]
getUserDocFieldVal() Start. userName = CN=wasadmin/CN=Users/dc=pelab/
dc=notesdev/dc=ibm/dc=com
getUserDocFieldVal() after getLookupInfo rc: 0.
getUserDocFieldVal() End. rc: 0.
getUserId: resolved name [CN=wasadmin/CN=Users/DC=pelab/DC=notesdev/DC=ibm/
DC=com]
getUserId: return resolved userId [CN=wasadmin/CN=Users/DC=pelab/DC=notesdev/
DC=ibm/DC=com], taken from LTPA token
Verify LTPA token succeeded
String <size=55>:
43 4e 3d 77 61 73 61 64 6d 69 6e 2f 43 4e 3d 55 73 65 72 73 2f 64 63 3d
70 65 6c 61 62 2f 64 63
3d 6e 6f 74 65 73 64 65 76 2f 64 63 3d 69 62 6d 2f 64 63 3d 63 6f 6d
Request status(0)
However, if there is a failure, the stnotes.txt could show:
Calling LtpaDecodeToken
Calling decode using: g_pfnLTPADecode
LtpaDecodeToken returned with status (1212)
Verify LTPA token failed
Verify secrets token failed
Request status(36866)
5. Now examine the StUsers_yymmdd_hhmm_tttt_000.txt file. The following is output
after a successful log on:
090513_172626,INF,LDAP Aut,Looking up
CN=wasadmin,CN=Users,DC=pelab,DC=notesdev,DC=ibm,DC=com
090513_172626,INF,LDAP Aut,---- Thread ID: 3896
090513_172626,INF,LDAP Aut,User
CN=wasadmin,CN=Users,DC=pelab,DC=notesdev,DC=ibm,DC=com looked up
090513_172626,INF,LDAP Aut,---- Thread ID: 5324
090513_172626,INF,LDAP Aut,calling verifyToken for []
090513_172626,INF,LDAP Aut,user [] successfully authenticated by token
090513_172626,INF,LDAP Aut,Async auth done. [req -1] [code 0] [user
CN=wasadmin,CN=Users,DC=pelab,DC=notesdev,DC=ibm,DC=com] [name
wasadmin] [home ] [organization ]
9 Conclusion
You should now have a good idea of how to enable SPNEGO on Active Directory, how
to configure WebSphere Application Server 7 to use SPNEGO, and how to use a
WebSphere Application Server token to enable Lotus Domino, the Sametime Connect
client, and Lotus Notes to use SPNEGO.
10 Resources
•
IBM Lotus Sametime 8 Information Center:
http://publib.boulder.ibm.com/infocenter/sametime/v8r0/index.jsp
•
WebSphere Application Server 7 Information Center:
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/
com.ibm.websphere.base.doc/info/welcome_base.html
•
Lotus Support Technote #1240710, “Sametime LDAPServer document”:
http://www-01.ibm.com/support/docview.wss?rs=899&uid=swg21240710
•
developerWorks article, “Implementing SPNEGO TAI single sign-on for WebSphere
applications with z/OS and Windows Kerberos trusted realms”:
http://www.ibm.com/developerworks/websphere/techjournal/0707_rogers/
0707_rogers.html
•
IBM Redbooks publication, “WebSphere Application Server V7: Concepts, Planning
and Design”:
http://www.redbooks.ibm.com/abstracts/SG247708.html?Open
•
developerWorks Lotus Sametime product page:
http://www.ibm.com/developerworks/lotus/products/instantmessaging/?
S_TACT=105AGX13&S_CMP=LP
•
developerWorks WebSphere Application Server zone:
http://www.ibm.com/developerworks/websphere/zones/was/
11 About the authors
Purvi Trivedi is an Advisory Software Engineer and has been with IBM since 2003.
Focusing on integration and interoperability issues across the Workplace, Portal, and
Lotus Collaboration (WPLC) portfolio, she works closely with customers and Support to
provide cross-product solutions. As part of the Quality team, she drives initiatives to
identify quality gaps and improve the integration of WPLC's products.
She is passionate about virtualization, presenting at various conferences on best practices
for virtualizing Lotus Domino and Lotus Sametime. Purvi has an MS in Software
Engineering from Brandeis University and a BSc in Computer Science from UMass,
Amherst.
Stephen Shepherd is a Senior Software Engineer in IBM's Software Group. He has five
years of experience supporting cross-product integration issues and five years of
experience working with the Support Engineering team.
Prior to joining IBM he spent twenty-two years in software development, holding various
positions including Software Architect. Stephen was a contributor for WebSphere Portal
Collaboration Security Handbook, and a contributing author of the Sametime 7.5.1 Best
Practices for Enterprise Scale Deployment Redbooks publication. He holds a Master’s
degree in Mathematics.
Trademarks
•
IBM, Lotus, Notes, Passport Advantage, Redbooks, Sametime, and WebSphere are
trademarks or registered trademarks of IBM Corporation in the United States, other
countries, or both.
•
Microsoft and Windows are registered trademarks of Microsoft Corporation in the
United States, other countries, or both.
•
Java and all Java-based trademarks and logos are trademarks or registered trademarks
of Sun Microsystems, Inc. in the United States, other countries, or both.
•
Other company, product, and service names may be trademarks or service marks of
others.