Integrating SPNEGO with IBM Lotus Sametime

Transcription

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

2 Table of Contents 1 Overview Installing WebSphere Application Server 7.0 and configuring authentication with Active Directory Installing WebSphere Application Server Configure WebSphere Application Server 7.0 to authenticate to Active Directory. 5 3 Configuring WebSphere Application Server 7.0 with SPNEGO Configure SPNEGO on Active Directory server Configure SPNEGO as Web Authenticator for WebSphere Application Server Enabling SSO for WebSphere Application Server Configuring client machine browsers For Internet Explorer 6.x and 7.x For Mozilla Firefox 3.x Confirm WebSphere Application Server is configured correctly for SPNEGO Configuring Lotus Sametime with Active Directory Advanced LDAP configuration during installation Advanced LDAP Configuration after the installation Enabling SSO for Sametime server using WebSphere token Generate and export Lightweight Third-party Authentication (LTPA) token Create Web SSO document on the Sametime Server Enabling client applications for SPNEGO Enabling Sametime Connect Client with SPNEGO Enabling SPNEGO for the embedded Sametime in Notes Client Troubleshooting and testing Confirm SPNEGO is properly configured in WebSphere Application Server Verify SSO is properly configured in WebSphere Application Server Enable tracing in WebSphere Application Server Verify SSO is properly configured in Lotus Sametime Enabling Sametime debug Conclusion Resources About the authors... 45

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

4 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: uid=swg Latest Fixpack from Fix Central (at the time of this writing, FP3 was the latest): 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):

5 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, WS-WAS-WinX32FP 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: 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).

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

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

8 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

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

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

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

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

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

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

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

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

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

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

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

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

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

22 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*))

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

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

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.

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

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

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

29 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

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

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

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

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

34 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 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 Enter the URL 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/ Unauthorized (text/html) 11. Highlight the HTTP/ Unauthorized packet; you'll notice WWW-Authenticate: Negotiate\r\n (see figure 40).

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

36 Figure 41. SPNEGO Token 13. If SPNEGO is not configured, the HTTP/1.1 Unauthorized packet will show WWWAuthenticate: Basic Realm (see figure 42).

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

38 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 /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 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

39 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 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] LdapRegistryI E SECJ0362E: Cannot create credential for the user wasadmin@pelab.notesdev.ibm.com. In this case the problem occurs because an LDAP Search was performed with a search filter samaccountname=wasadmin@pelap.notesdev.ibm.com 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 e. Stop Wireshark, using Capture > Stop, enter ldap in the Filter field, and click the Apply button (see figure 44).

40 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 3. Change the URL to access stcenter.nsf on the Sametime server, using a URL such as

41 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 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/ :26:32.82 AM [17BC: C4] SSO API> Token does not lead with 0 [Single Sign-On token is invalid]. 05/13/ :26:32.82 AM [17BC: C4] SSO API> ERROR: when decoding Domino LtpaToken [Single Sign-On token is invalid].

42 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/ :16:25.21 PM [0DC8:0017-0FA0] SSO API> Decrypt WebSphere style Single Sign-On token (LTPA). [0]!= u. 05/13/ :16:25.21 PM [0DC8:0017-0FA0] SSO API> ERROR: when decoding LtpaToken [Single Sign-On token is invalid]. 05/13/ :16:25.21 PM [0DC8:0017-0FA0] SSO API> *** Freeing Single Sign-On Token List (SECTokenListFree) *** 05/13/ :16:25.21 PM [0DC8:0017-0FA0] SSO API> *** Freeing Single Sign-On Token (SECTokenFree) *** 05/13/ :16:25.21 PM [0DC8:0017-0FA0] SSO API> *** Freeing Single Sign-On Token (SECTokenFree) *** 05/13/ :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/ :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/ :51:00.78 PM [0D08:0012-0F2C] SSO API> -LDAP Realm = vmpe07.notesdev.ibm.com\:389 05/13/ :51:00.79 PM [0D08:0012-0F2C] SSO API> -Username = CN=wasadmin/CN=Users/dc=pelab/dc=notesdev/dc=ibm/dc=com 05/13/ :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/ :51:00.79 PM [0D08:0012-0F2C] SSO API> -Expiration Ticks = [05/13/ :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

43 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 d 69 6e 2f 43 4e 3d f d c f d 6e 6f f d d 2f d 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

44 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: _172626,INF,LDAP Aut,Looking up CN=wasadmin,CN=Users,DC=pelab,DC=notesdev,DC=ibm,DC=com _172626,INF,LDAP Aut,---- Thread ID: _172626,INF,LDAP Aut,User CN=wasadmin,CN=Users,DC=pelab,DC=notesdev,DC=ibm,DC=com looked up _172626,INF,LDAP Aut,---- Thread ID: _172626,INF,LDAP Aut,calling verifytoken for [] _172626,INF,LDAP Aut,user [] successfully authenticated by token _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: WebSphere Application Server 7 Information Center: com.ibm.websphere.base.doc/info/welcome_base.html Lotus Support Technote # , Sametime LDAPServer document : developerworks article, Implementing SPNEGO TAI single sign-on for WebSphere applications with z/os and Windows Kerberos trusted realms : _rogers.html IBM Redbooks publication, WebSphere Application Server V7: Concepts, Planning and Design :

45 developerworks Lotus Sametime product page: S_TACT=105AGX13&S_CMP=LP developerworks WebSphere Application Server zone: 11 About the authors Purvi Trivedi is an Advisory Software Engineer and has been with IBM since 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 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.