Integrating SPNEGO with IBM Lotus Sametime 8

1

Integrating SPNEGO with IBM Sametime 8.5.2 components using IBM WebSphere Application Server

Conall O'Cofaigh ([email protected])IBM Collaboration Solutions, IBM Software Group, Mulhuddart, Ireland

Naveed Yousuf ([email protected])IBM Collaboration Solutions, IBM Software Group, Mulhuddart, Ireland

Pat Curtin ([email protected])IBM Collaboration Solutions, IBM Software Group, Mulhuddart, Ireland

July 2011

© Copyright International Business Machines Corporation 2011. All rights reserved.

Summary: This paper explains the steps to configure single sign-on (SSO) for IBM® Sametime® 8.5.2 Community Server, Meeting Server, Proxy Server, Media Manager, Advanced Server, and the Connect client, using Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) with the Sametime System Console as the authentication server. SPNEGO enables the SSO mechanism for Microsoft® Windows clients that are part of a Microsoft Active Directory Domain.

Table of Contents1 Overview...................................................................................................................................22 Configuring SPNEGO on Active Directory Server.....................................................................33 Configuring SPNEGO for Sametime System Console..............................................................64 Enabling SSO for WebSphere Application Server.....................................................................95 Enabling the Snoop servlet in WebSphere Application Server................................................106 Creating a unique Security Domain for the System Console...................................................117 Configuring client machine browsers......................................................................................15

7.1 For Microsoft Internet Explorer........................................................................................157.2 For Mozilla Firefox...........................................................................................................17

8 Generate and export Lightweight Third-party Authentication (LTPA) token.............................178.1 Create a Web SSO document on the Sametime Server..................................................19

9 Enabling Sametime Connect Client with SPNEGO.................................................................2010 Enabling SSO on Sametime Meeting Server........................................................................2211 Enabling SSO on Lotus Proxy Server...................................................................................2612 Enabling SSO on Lotus Media Manager (AV).......................................................................3313 Enabling SSO on Sametime Advanced Server.....................................................................3714 Troubleshooting and testing..................................................................................................42

14.1 Verify SPNEGO is properly configured in WebSphere Application Server.....................4214.2 Verify SSO is properly configured in WebSphere Application Server............................46

mailto:[email protected]



2

14.3 Enable tracing in WebSphere Application Server..........................................................4714.4 Verify SSO is properly configured in IBM Sametime......................................................49

15 Conclusion............................................................................................................................5116 Resources.............................................................................................................................51About the authors.......................................................................................................................51

1 OverviewIn this paper you will learn how to:

• Enable SPNEGO in Microsoft Active Directory• Configure the Sametime System Console to use SPNEGO• Use a WebSphere® Application Server token to enable IBM Lotus Domino® and

extended products like Sametime Connect Client, Meeting Server, Proxy Server, Media Manager and Advanced Server.

Figure 1 shows the full Sametime environment we use. For more information setting this up, refer to the wiki article, “Manually setting up a full IBM Sametime 8.5.2 environment .”

http://www-10.lotus.com/ldd/stwiki.nsf/dx/Manually_setting_up_a_full_IBM_Sametime_8.5.2_environment_

3

Figure 1. Diagram of the setup

2 Configuring SPNEGO on Active Directory ServerAll 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.

To configure the Active Directory identity for WebSphere Application Server, follow these steps:

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 is used by WebSphere Application Server to authenticate with Active Directory.

4

NOTE: On the Account tab, under the Account options section, select “'Password never expires” (see figure 2). If this option is not selected, you will be required to generate a new key each time the password changes.

Figure 2. Create User account window

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 (see figure 3):

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.

5

Figure 3. “ktpass” command output

3. Next, check the user account properties for vmpewas. The User logon name (see figure 4) should have been changed to the SPN name, confirming that the SPN is mapped to user account vmpewas.

Doing this mapping informs Active Directory that any authenticated client machine in your domain, using HTTP or HTTPs to talk to your WebSphere Application Server, will authenticate to the newly created vmpewas account.

6

Figure 4. User logon name

4. Now we must move the vmpewas.keytab created in Step 2 from the Active Directory server to the Sametime System Console machine, which is the WebSphere Application Server we will be using for SPNEGO authentication.

NOTE: This document describes the steps of enabling SPNEGO on a cell deployment, in which each Sametime component has its own deployment manager. That means that a keytab is to be created for each of the components' deployment managers.

If you set up an environment with a federated deployment, in which there is one deployment manager for all your Sametime components, then you need to create a keytab for each server and then merge all the keytabs into one master keytab that you will use on the deployment manager. For detailed steps on how to do this, refer to the product documentation topic, “Using the ktab command to manage the Kerberos keytab file . ”

3 Configuring SPNEGO for Sametime System ConsoleIn this section we enable SPNEGO on our Sametime System Console. First, make a note of the location of the keytab file copied over from the Active Directory server, for example, E:\IBM\vmpewas.keytab.

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Frsec_SPNEGO_kerb.html


http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rsec_SPNEGO_kerb.html

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rsec_SPNEGO_kerb.html




7

1. Using the keytab file, we must set up the Kerberos configuration file:

a) Log in to your Sametime System Console machine.b) From the Command line, change directory to the Application server bin directory (for

example, C:\Program Files\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 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 5).

Figure 5. keytabPath example

2. Now let's enable WebSphere Application Server security with SPNEGO:

a. On the System Console machine, navigate to the Sametime System Console administrative console page by going to https://<system_console_server>:8701/ibm/console/logon.jsp in a browser.

b. Select Security > Global Security, and under Authentication, go to Web and SIP Security, and select SPNEGO Web authentication (see figure 6).

8

Figure 6. Enable SPNEGO Web authentication

3. In the next window, select the “Dynamically update SPNEGO” and “Enable SPNEGO” options (see figure 7).

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

5. 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 7. SPNEGO Web authentication properties

6. Under SPNEGO filters, click New, to create a new SPNEGO filter (see figure 8). Here, the Host name field is the name of your System Console Server, and the Kerberos realm name

9

field is the name of the Active Directory realm, which must be in all capital letters. Also, the option, Trim Kerberos realm from the principal, must be enabled for this to work.

Figure 8. New SPNEGO filter properties window

7. Click OK and click Save, and then restart System Console Server; it is now configured with SPNEGO.

4 Enabling SSO for WebSphere Application ServerWe now enable SSO for the System Console Server:

1. From the administrative console page, select Security > Global Security; under Authentication, expand Web and SIP Security, and select Single sign-on (SSO), as shown in figure 9.

10

Figure 9. Enabling SSO

2. Under General Properties, select Enabled, and in the Domain name field, enter the DNS Domain name (see figure 10). Click OK and click Save.

Figure 10. SSO properties

5 Enabling the Snoop servlet in WebSphere Application ServerTo do this you must install the default applications.ear on the Sametime System Console:

11

1. From the Integrated Solutions Console, click WebSphere Application Server – Application – Application Types – WebSphere enterprise application > install.

2. Navigate to the installable apps directory (usually C:\Program Files\IBM\WebSphere\Appserver) and install DefaultApplications.ear.

3. Follow the next steps, accepting the default values.

4. Synchronize the server by saving master config, and then start the DefaultApplication.ear by clicking its checkbox and clicking Start. Its status icon should be green, for online.

5. Log in to your Sametime System console and select Security – Global security. Under User account repository, select Federated repositories and click Configure.

6. Click your Active Directory name and check that you have the correct DN set that will work for your Active Directory (see figure 11).

Figure 11. Federated repositories window

7. Restart the System Console Server.

6 Creating a unique Security Domain for the System ConsoleIn SPNEGO-enabled environments, it is necessary to disable SPNEGO for the STConsoleServer because the REST APIs and clients that are used by the InstallationManager and STPolicy Services on the Community server(s) do not support SPNEGO authentication.

In the case of the Installation Manager, the registration of the Install or Upgrade will fail. The STPolicy service on the Community Servers will fail with “unauthorized” errors and not pick up changes made in the Sametime System Console's Policy Administration area.

So to work around this, we need to create a unique Security Domain for the STConsoleServer:

12

1. Access the Deployment Manager Integrated Solutions Console, expand the Security section, select Security domains, and then click New (see figure 12).

Figure 12. Security domains

2. Give the SecurityDomain a descriptive name, such as "STConsoleServer," provide a description (optional), and click OK (see figure 13).

Figure 13. New Security domain

3. In the next window (see figure 14), save the changes.

13

Figure 14. Save changes

4. When the screen refreshes, click the "STConsoleServer" link; the window in figure 15 displays:

a) Assign the new Security profile to the correct scope by expanding the tree and clicking OK.

Figure 15. Assign new Security profile

14

b) Adjust the relevant Security Attributes; in this case, we expand the SPNEGO option and change the radio button to the "Customize for this domain" setting (see figure 16).

Figure 16. Assign new Security profile

15

c) Then click the "SPNEGO Web authentication" link to make our changes---simply clearing the "Enable SPNEGO" checkbox will be sufficient---and click OK (see figure 17).

Figure 17. Clear Enable SPNEGO Checkbox

d) Save to the master configuration by synchronizing the node (the STConsoleServer node is the only one directly affected by this change) and then restarting the STConsoleServer.

This will restore access to the STConsoleServer applications and leave SPNEGO intact for the rest of the environment.

You can validate that SPNEGO is disabled by hitting the STPolicy REST API directly; if you are prompted for basic authentication, then this is in effect. If you are not prompted, then repeat the steps, making sure that the scope is still checked and correcting it if it is not, and save/apply the changes.

7 Configuring client machine browsersLog in to the Active Directory domain on the client machine. Before we can validate that the System Console server is configured correctly to use SPNEGO, we must change some browser settings.

7.1 For Microsoft Internet Explorer1. 1. Select Tools – Internet Options – Security – Local Intranet – Sites – Advanced. Add the

SSO domain in the “Add this website to the zone field” (see figure 18).

16

Figure 18. Add SSO domain

2. Select Tools – Internet Options, click the Advanced tab and, under Settings, check the option “Enable Integrated Windows Authentication” (see figure 19).

Figure 19. Advanced tab of Internet Options window

17

3. Restart the browser; now we're all set.

7.2 For Mozilla Firefox1. 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 your SSO domain (see figure 20).

Figure 20. Set SSO domain

3. Restart the browser; you're all set.

Now, confirm that System Console 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://<system_console_server>:9080/snoop.

3. You should not be prompted to enter your username and password if SPNEGO is enabled correctly.

8 Generate and export Lightweight Third-party Authentication (LTPA) tokenTo export the WebSphere Portal token:

1. Log in to the WebSphere Application Server console, select Security – Global Security, and under Authentication, select LTPA (see figure 21).

18

Figure 21. Select LTPA authentication

2. Under the Key generation section, set the Key set group field to CellLTPAKeySetGroup and click the Generate keys button (see figure 22).

Figure 22. Generate keys

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

Figure 23. 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.”

19

Now we need to copy over vmpewas.ltpa to a machine that has the Domino Administration Client, so that we can configure SSO, using this WebSphere token.

8.1 Create a Web SSO document on the Sametime Server1. Start the Domino Administration Client, select File > Application > Open, and enter the

name of the Sametime Server.

2. Open the Names.nsf database.

3. Select Configuration, expand Web, and click Web Configurations. In there you will find the Web SSO token that Lotus Sametime automatically creates. Delete it.

4. Select Configuration, expand Servers, and All Servers, and double-click on your Sametime server, which should be listed.

5. Select the Create Web drop-down menu, and choose SSO Configuration.

6. Choose to edit the document; click Keys > Import WebSphere LTPA Keys (see figure 24).

Figure 24. Import WebSphere LTPA Keys

7. Type in the path and the name of the LTPA key file, as shown in figure 25.

Figure 25. Enter Import File Name dialog

8. Type in the password; the key should be imported. Make sure the Configuration Name field is “LtpaToken” (see figure 26).

9. Enter the DNS domain to your domain name and then set the Map names in LTPA tokens field to Disabled.

10. Add the Sametime server to the Domino Server Names list.

11. All the data in the WebSphere Information section will populate automatically after the WebSphere token is imported. You need to change the Token format to " LtpaToken and LtpaToken2 (compatible with all releases of Domino)”, so that all the community server features are available for user in the stcenter.nsf (see figure 26).

20

Figure 26. LtpaToken Configuration document

12. Save the document. Under Configuration > Servers > All Server Documents, select your Sametime server name and click Edit server.

13. Click the Internet Protocol tab and then the Domino Web Engine tab.

14. Change the Session authentication to Multiple Servers (SSO), and ensure the Web SSO configuration field is set to LtpaToken.

15. Save the document and restart the server.

To verify that SPNEGO is working correctly, when your Sametime server is back up, navigate to the Snoop servlet in a browser on your client machine (http://<system_console_server>:9080/snoop), and then navigate to your Sametime server (http://<sametime_server>/stcenter.nsf).

You should automatically be logged in to the Sametime server in your browser. If this does not occur, refer to Section 14, “Troubleshooting and testing,” below.

9 Enabling Sametime Connect Client with SPNEGOYou should also test logging into a sametime connect client with SPNEGO too. To do this:

21

1. Launch a Connect client and click Connectivity (see figure 27).

Figure 27. Connect Client Connectivity button

2. Check the “Use token based single sign-on” checkbox and enter your SNOOP servlet page (in our case, http://<system_console_server>:9080/snoop). Choose the authentication type as “SPNEGO” (see figure 28).

Figure 28. Token-based SSO in Connect client

3. Go to the Server tab and enter the name of your Community server. Click OK, and then click Log In.

Users should now be able to log in without having to enter in any credentials. If this does not occur, refer to Section 14, “Troubleshooting and testing,” below.

22

10 Enabling SSO on Sametime Meeting ServerFollow the steps below to enable SSO for any WebSphere Application Server-based component in your environment. In this case we have a Meeting Server.

To do this, you must create a keytab for your server, following the steps in “Section 2: Configuring SPNEGO on Active Directory Server.” Then copy the keytab to your Meeting Server machine and follow these steps:

1. Copy over the LTPA key that was exported from WebSphere Application Server on the System Console machine to your Meeting Server machine.

2. From the administrative console page (http://<meeting_server>:8500/ibm/console), select Security > Global Security, and under Authentication, click LTPA.

3. In the Cross-cell single sign-on section, type in the password of your LTPA token, point to the location to which you have copied it, and click Import keys (see figure 29).

Figure 29. Cross-cell single sign-on window

4. From the administrative console page, select Security > Global Security; under Authentication, expand Web and SIP Security, and select Single sign-on (SSO), as shown in figure 30.


23


Figure 31. SSO General Properties window

6. Using the keytab file we generated for this server, we must set up the Kerberos configuration file:

a) Log in to your Sametime Meeting Server machine.b) From the Command line, change directory to the Application server bin directory (for

example, C:\Program Files\IBM\WebSphere\AppServer\bin).

24

c) Run wsadmin; enter the username/password to authenticate.d) Issue the following AdminTask command to create the Kerberos configuration file:


where:


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


Figure 32. keytabPath MS example


a) On the Meeting Server machine, navigate to the Meeting Server administrative console page by going to http://<meeting_server>:8500/ibm/console/ in a browser.

b) Select Security – Global Security, and under Authentication, go to Web and SIP Security, and select SPNEGO Web authentication (see figure 33).

25



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

• The “Kerberos keytab file with full path” field is the path to the file we copied over from Active Directory Server to WebSphere Application Server, for example, E:\IBM\vmpewas.keytab.


26

9. Under SPNEGO filters, click New, to create a new SPNEGO filter (see figure 35). Here, the Host name field is the name of your Meeting Server, and the Kerberos realm name field is the name of the Active Directory realm, which must be in all-capital letters. Also, the option, Trim Kerberos realm from the principal, must be enabled for this to work.


10. Click OK and click Save, and then restart Meeting Server; it is now configured with SPNEGO.

11. To verify that SPNEGO is working correctly, when the Meeting server is back up, navigate to the Meeting Server URL in your configured client browser (http://<meeting_server>/stmeetings).

You should automatically be logged in to Meeting Server in your browser. If not, refer to Section 13, “Troubleshooting and testing,” below.

You should also test logging into a Sametime Connect client with SPNEGO, and adding your Meeting Server in there. Make sure you can connect to the Meeting Server when you go to the Meeting Server tab on the Connect client. Again, refer to Section 14 if it does not work.

11 Enabling SSO on Lotus Proxy ServerFollow the steps below to enable SSO for any WebSphere Application Server-based component in your environment. In this case we have a Proxy server. To do this, you must create a keytab

27

for your server, following the steps in Section 2: Configuring SPNEGO on Active Directory Server. Then copy the keytab to your Proxy Server machine and follow these steps:

1. Copy over the LTPA key that was exported from WebSphere Application Server on the System Console machine to your Proxy Server machine.

2. From the administrative console page (http://<proxy_server>:8600/ibm/console), select Security > Global Security, and under Authentication, click LTPA.

3. In the Cross-cell single sign-on section, type in the password of your LTPA token, point to the location to which you have copied it, and click Import Key (see figure 36).

Figure 36. Cross-cell single sign-on

4. From the administrative console page, select Security > Global Security. Under Authentication, expand Web and SIP Security, and select Single sign-on (SSO), as shown in figure 37.

Figure 37. Enable SSO


28



a) Log in to your Sametime Proxy Server machine.b) From the Command line, change directory to the Application server bin directory (for



where:




29

Figure 39. keytabPath Proxy Server example


c) On the Meeting Server machine, navigate to the Proxy Server administrative console page by going to http://<proxy_server>:8600/ibm/console/ in a browser.

d) Select Security > Global Security, and under Authentication, go to Web and SIP Security, and select SPNEGO Web authentication (see figure 40).


30


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

• The “Kerberos keytab file with full path” field is the path to the file we copied over from Active Directory server to WebSphere Application Server, for example, E:\IBM\vmpewas.keytab.


9. Under SPNEGO filters, click New, to create a new SPNEGO filter (see figure 42). Here, the Host name field is the name of your Proxy Server, and the Kerberos realm name field is the name of the Active Directory realm, which must be in all-capital letters. Also, the option, Trim Kerberos realm from the principal, must be enabled for this to work. Click OK and click Save.

31


10. Select Security > Global security. Under User account repository, select Federated repositories and click Configure.

11. If it is not already there, add your Active Directory details and ensure you have the correct DN set that will work for your Active Directory (see figure 43).

Figure 43. Federated repositories window

32

12. Select Applications – Install New Application. While the Application Installation Wizard is running, prompts display to help you map security roles to users or groups. To change a role to user or group mappings for deployed applications, select Applications – Enterprise Application – deployed_application – Security roles to user/group mapping. Make sure you have the same settings as those shown in figure 44.

Figure 44. Security roles to user/group mapping

13. Select Security – Global Security – Web and SIP security – general settings, and make sure you have the same setting as those shown in figure 45.

Figure 45. Web Authentication Behavior

14. Restart the Proxy Server; it is now configured with SPNEGO.

15. To verify that SPNEGO is working correctly, when the Proxy Server is back up, navigate to the Proxy Server URL in your configured client browser (https://<proxy_server>:9080/popup.jsp or https://<proxy_server>:9080/index.jsp).

IMPORTANT: Do not use the URL, https://<proxy_server>:9080/stwebclient/popup.jsp, as the redirection will not work for SPNEGO authentication.

You should automatically be logged in to Proxy Server in your browser. If not, refer to Section 14 below.

33

12 Enabling SSO on Lotus Media Manager (AV)Follow the steps below to enable SSO for any WebSphere Application Server-based component in your environment. In this case we have a Media Manager (AV). To do this, you must create a keytab for your server, following the steps in Section 2: Configuring SPNEGO on Active Directory Server. Then copy the keytab to your AV Server machine and follow these steps:

1. Copy over the LTPA key that was exported from WebSphere Application Server on the System Console machine to your AV Server machine.

2. From the administrative console page (http://<av_server>:8800/ibm/console), select Security > Global Security, and under Authentication, click LTPA.



4. From the administrative console page, select Security – Global Security. Under Authentication, go to Web and SIP Security (see figure 47); select Single sign-on (SSO).


34




a) Log in to your AV Server machine.b) From the Command line, change directory to the Application Server bin directory (for



where:




35

Figure 49. keytabPath AV example


a) On the AV Server machine, navigate to the Meeting Server administrative console page by going to http://<av_server>:8800/ibm/console/ in a browser.



36



10. The “Kerberos keytab file with full path” field is the path to the file we copied over from Active Directory server to WebSphere Application Server, for example, E:\IBM\vmpewas.keytab.


11. Under SPNEGO filters, click New, to create a new SPNEGO filter (see figure 52). Here, the Host name field is the name of your AV Server, and the Kerberos realm name field is the name of the Active Directory realm, which must be in all capital letters. Also, the option, Trim Kerberos realm from the principal, must be enabled for this to work.

37


12. Click OK and click Save, and then restart AV Server; it is now configured with SPNEGO.

As there is no Media Manager URL that can be protected by SPNEGO, the best way to test whether your media manager is working is to log in to your Sametime Connect client and confirm that AV can be seen in your Preferences and that you are able to make AV calls.

13 Enabling SSO on Sametime Advanced ServerFollow the steps below to enable SSO for any WebSphere Application Server-based component in your environment. In this case we have an Advanced Server. To do this, you must create a keytab for your server, following the steps in Section 2: Configuring SPNEGO on Active Directory Server. Then copy the keytab to your Advanced Server machine and follow these steps:

1. Copy over the LTPA key that was exported from WebSphere Application Server on the System Console machine to your Advanced Server machine.

2. From the administrative console page (http://<advanced_server>:8900/ibm/console), select Security > Global Security and, under Authentication, click LTPA.


38


4. From the administrative console page, select Security > Global Security. Under Authentication, expand Web and SIP Security, and select Single sign-on (SSO), as shown in figure 54.



39



a) Log in to your Sametime Advanced Server machine.b) From the Command line, change directory to the Application server bin directory (for



where:




40

Figure 56. keytabPath Advanced Server example


a) On the Advanced Server machine, navigate to the Advanced Server administrative console page by going to http://<advanced_server>:8900/ibm/console/ in a browser.



41



10. The “Kerberos keytab file with full path” field is the path to the file we copied over from Active Directory server to WebSphere Application Server, for example, E:\IBM\vmpewas.keytab.


11. Under SPNEGO filters, click New, to create a new SPNEGO filter (see figure 59). Here, the Host name field is the name of your Advanced Server, and the Kerberos realm name field is the name of the Active Directory realm, which must be in all capital letters. Also, the option, Trim Kerberos realm from the principal, must be enabled for this to work.

42


12. Click OK and click Save, and then restart Advanced Server; it is now configured with SPNEGO.

13. To verify that SPNEGO is working correctly, when the Advanced Server is back up, navigate to the Advanced Server URL in your configured client browser (http://<advanced_server>:9080/stadvanced).

You should automatically be logged in to Advanced Server in your browser. If not, refer to Section 14.

You should also test logging into a Sametime Connect client with SPNEGO, and adding your Advanced Server details in there. Make sure you can connect to the Advanced Server when you go to the Broadcast Communities and Chat Rooms tab on the Connect client. Again, refer to Section 14 if it does not work.

14 Troubleshooting and testingFinally, let's discuss some methods for testing and troubleshooting the configurations.

14.1 Verify SPNEGO is properly configured in WebSphere Application Server

43

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

Figure 60. 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 Start.

7. Restart the browser if you made changes in Step 5 or 6.

8. Enter the URL to your Snoop server, http://<system_console_machine>:9080/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 click Apply. Navigate to the lines:

GET /snoop HTTP/1.1HTTP/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 61).

44

Figure 61. WWW- Authenticate: Negotiate\r\n

12. Navigate to and highlight the second “GET /snoop HTTP/1.1”; in the detail packet window, you can see the SPNEGO Token (see figure 62).

45

Figure 62. SPNEGO Token

If SPNEGO is not configured, the HTTP/1.1 Unauthorized packet will show “WWW-Authenticate: Basic realm” (see figure 63).

46

Figure 63. Basic realm

14.2 Verify SSO is properly configured in WebSphere Application ServerAfter 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 of your Snoop server, http://<system_console_server>:9080/snoop, and stop Wireshark, using Capture – Stop.

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

47

Figure 64. LtpaToken2 and LtpaToken

If the HTTP 200 response does not contain the tokens, then SSO is not set up correctly, in which case, do the following:

1. Log in to the administrator console via the URL, https://<system_console_server>:8700/ibm/console.

2. Select Security – Global Security, and expand Web and SIP security.

3. Click Single sign-on (SSO), and make sure Enabled is checked. If it is checked, and you received an HTTP 403 forbidden error or you are prompted for a user name and password at log in, there may be a problem validating the credentials with the Active Directory, in which case, you should enable tracing.

14.3 Enable tracing in WebSphere Application Server1. Log in to the administrator console via the URL,

https://<system_console_server>:8700/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, and stop WebSphere Application Server.

48

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

6. Start WebSphere Application Server and log in to your Windows client.

7. Open Internet Explorer and enter the URL, http://<system_console_server>:9080/snoop.

8. 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] andobjectcategory=user. We can see this by using Wireshark:

a) Start Wireshark on WebSphere Application Server and select Capture > Interfaces.b) Select the correct adapter, click Start, and then log in to the Windows client and open

Internet Explorer.c) Enter the URL, http://<system_console_server>:9080/snoop.d) Stop Wireshark, using Capture > Stop, enter “ldap” in the Filter field, and click the Apply

button (see figure 65).

Figure 65. LDAP capture

49

To correct the problem:

1. Log in to the WebSphere Application Server administrator's console, click Security – Global Security, and expand Web and SIP security.

2. Click SPNEGO Web Authentication, and click the host name in SPNEGO Filters.

3. Check the box next to the option “Trim Kerberos realm from principal name.”

4. Click OK and click Save, and log out of the administrator client.

5. Stop and restart WebSphere Application Server.

14.4 Verify SSO is properly configured in IBM SametimeTo do this:

1. Log in to your Windows client, open Internet Explorer, and enter the URL http://<system_console_server>:9080/snoop.

2. Change the URL to access stcenter.nsf on the Sametime server, using a URL such ashttp://<sametime_server>/stcenter.nsf. You should see yourself logged in (see figure 66).

Figure 66. stcenter.nsf page

3. If you do not see yourself logged on, make sure SSO has been properly enabled on the Sametime server.

50

4. Also, you can enable debug by setting the Notes.ini parameters, as follows:

debug_sso_trace_level=3enable_console_log=1

5. Restart the Sametime server and repeat Steps 1 through 3.

6. Open console.log on the Sametime server. This is in the IBM_Technical_Support directory under the Domino data directory. 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 decodingDomino 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 styleSingle Sign-On token (LTPA). [0] != u.05/13/2009 02:16:25.21 PM [0DC8:0017-0FA0] SSO API> ERROR: when decodingLtpaToken [Single Sign-On token is invalid].05/13/2009 02:16:25.21 PM [0DC8:0017-0FA0] SSO API> *** Freeing Single Sign-OnToken List (SECTokenListFree) ***05/13/2009 02:16:25.21 PM [0DC8:0017-0FA0] SSO API> *** Freeing Single Sign-OnToken (SECTokenFree) ***05/13/2009 02:16:25.21 PM [0DC8:0017-0FA0] SSO API> *** Freeing Single Sign-OnToken (SECTokenFree) ***05/13/2009 02:16:25.34 PM [0DC8:0017-0FA0] SSO API> *** Validating Token List(SECTokenListValidateAndGetInfo) ***

7. 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=com05/13/2009 02:51:00.78 PM [0D08:0012-0F2C] SSO API> -LDAP Realm =vmpe07.notesdev.ibm.com\:38905/13/2009 02:51:00.79 PM [0D08:0012-0F2C] SSO API> -Username =CN=wasadmin/CN=Users/dc=pelab/dc=notesdev/dc=ibm/dc=com05/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=com05/13/2009 02:51:00.79 PM [0D08:0012-0F2C] SSO API> -Expiration Ticks =1242247860666 [05/13/2009 04:51:00 PM].

51

15 ConclusionYou should now have a good idea of how to configure SSO for Sametime Community Server, Meeting Server, Proxy Server, Media Manager, Advanced Server, and the Connect client, using SPNEGO with the Sametime System Console as the authentication server.

16 Resources“Setting up a full IBM Lotus Sametime 8.5.1 environment using the Sametime system console:”http://www-10.lotus.com/ldd/stwiki.nsf/dx/Setting_up_a_full_IBM_Lotus_Sametime_8.5.1_environment_using_the_Sametime_system_console#Resources

developerWorks Lotus Sametime product page:www.ibm.com/developerworks/lotus/products/instantmessaging/"http://www.ibm.com/developerworks/lotus/products/instantmessaging/

Lotus Sametime Forum:http://www.ibm.com/developerworks/lotus/products/instantmessaging/

Sametime wiki Product Documentation:http://www-10.lotus.com/ldd/stwiki.nsf/xpViewCategories.xsp?lookupName=Product%20Documentation

IBM Redbooks® publication: “Lotus Sametime Application Development Guide:”http://www.redbooks.ibm.com/abstracts/SG245651.html?Open

developerWorks WebSphere Application Server zone:http://www.ibm.com/developerworks/websphere/zones/was/

About the authorsConall O'Cofaigh is a Software Engineer working on the Sametime Verification Test team. He's been with IBM since 2008, focusing on integration and interoperability across Lotus Sametime products.

Naveed Yousuf is a Software Engineer working on various teams at IBM's Dublin Software Lab since 1999. He has worked with the Sametime Verification Test team for the past 4 years, focusing on integration and interoperability across Lotus Sametime products.

Pat Curtin is a Software Engineer working on various teams at IBM's Dublin Software Lab since 1999. He works with Lotus System Verification Test team, focusing on integration and interoperability across Lotus products.

http://www.ibm.com/developerworks/websphere/zones/was/

http://www.redbooks.ibm.com/abstracts/SG245651.html?Open

http://www-10.lotus.com/ldd/stwiki.nsf/xpViewCategories.xsp?lookupName=ProductDocumentation

http://www-10.lotus.com/ldd/stwiki.nsf/xpViewCategories.xsp?lookupName=ProductDocumentation

http://www.ibm.com/developerworks/lotus/products/instantmessaging/

http://www-10.lotus.com/ldd/stwiki.nsf/dx/Setting_up_a_full_IBM_Lotus_Sametime_8.5.1_environment_using_the_Sametime_system_console#Resources



52

Trademarks• developerWorks, Domino, IBM, Lotus, Redbooks, Sametime, and WebSphere are trademarks or

registered trademarks of IBM Corporation in the United States, other countries, or both.

• Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

• Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both.

• Other company, product, or service names may be trademarks or service marks of others.