|Test Infrastructure: Domino 8.5 and Tivoli Access Manager (WebSEAL) Integration |
|Abstract * ||Domino System Verification test tested several environmental configurations for the Domino 8.5 release. This document describes the Tivoli Access Manager environment. The purpose of the Tivoli Access Manager environment was to test Domino interoperability with other companion products, while configured to use IBM Tivoli Access Manager. This environment includes a Domino 8.5 server cluster, a Sametime 8.01 server, a WebSphere Portal 6.0.1 server with IBM HTTP Server, a IBM Tivoli Directory Server LDAP server, and a Lotus Connections server 2.0.1.|
Use this field for content. Place any attachments in the attachment field.
The IBM Lotus Domino System Verification Test (SVT) team tested several environmental configurations for the Lotus® Domino® server 8.5 release. This document describes the IBM® Tivoli® Access Manager (TAM) environment. The purpose of the TAM environment was to test Domino interoperability with other companion products, while configured to use IBM Tivoli Access Manager. This environment includes a Domino 8.5 server cluster, a Lotus® Sametime® 8.01server, an IBM® WebSphere® Portal 6.0.1 server with IBM HTTP Server, a IBM Tivoli Directory Server Lightweight Directory Access Protocol (LDAP) server, and a Lotus® Connections server.
The specifications of the servers used were as follows:
|Software Installed/purpose ||Operating System ||Hardware ||Notes |
|Domino 8.5 ||Domino 8.5 ||AIX 5,3 |
Windows 2003 SP1
|2 x PowerPC 4.5GHz/4GB Memory |
1 x Intel Pentium 4/2GB Memory
|Domain controller |
|Sametime 8.01 ||Domino 8.01/Sametime Community Server 8.01 ||AIX 5.3 ||2 x PowerPC 1.8GHz/1.5GB Memory |
|WebSphere Portal 6.0.1 ||WebSphere 6.0/WebSphere Portal 6.0.1||AIX 5.3 ||4 x PowerPC 3.7GHz/4GB Memory|
|IBM HTTP Server 6.0 ||Windows 2003 SP1 ||1 x Intel Pentium III 1 GHz/512KB Memory |
|Lotus Connections - Activities ||WebSphere 6.1/Lotus Connections-Activities ||Windows 2003 SP1 ||1 x Intel Pentium D 2.8 GHz/2GB Memory |
|Installation Notes, Hints, and Tips|
After the base installation of each product base, the first concern was coordinating authentication. It was important for Domino users, Sametime users, WebSphere Portal users and Connections users to interact and interoperate with each other without having to re-authenticate. In addition, many Notes applications, Lotus iNotes Access (iNotes) and WebSphere Portal have Sametime awareness and chat embedded within them. The Sametime server provided this service to each of the applications within the environment. This document focuses on the configuration aspects that provided the richness of the interoperability aspects.
In the following sections we will discuss more details of the configurations and some things we learned while testing.
|User registry/Directory/LDAP configuration|
The Domino servers have a populated directory containing registered users. This was necessary for native Notes/Domino mail delivery, ACL management, and so on. The Sametime, WebSphere Portal and Activities applications all used a Microsoft IBM Tivoli Directory Server LDAP for their user registries by way of using Tivoli Access Manager for authentication.
For this configuration, Tivoli Access Manager handles authentication and the creation of single-signon (SSO) tokens. The users in the Domino Directory include a reference to the user's corresponding IBM Tivoli Directory Server distinguished name.
This is the user record from IBM Tivoli Directory Server for the corresponding user:
dn: uid=JDoe, cn=users,dc=ibm,dc=com
cn: Jane Doe
This accomplished the mapping of the Domino users to the IBM Tivoli Directory Server users. The Domino Person LTPA user name setting provided that when a Notes/Domino application set a client LTPA token, it would be set with the DN from the IBM Tivoli Directory Server user repository. When an application using IBM Tivoli Directory Server (WebSphere Portal, Activities, Sametime) set the LTPA token, it would also be set with the DN from the IBM Tivoli Directory Server user repository. The Domino User name field allowed for Domino as an application server to accept the IBM Tivoli Directory Server user based token for authentication.
Each Domino's user's password and internet password also needed to be set.
No directory assistance or referrals were used.
|Sametime 8.01 server configuration|
The Sametime servers were configured to use IBM Tivoli Directory Server LDAP. That is accomplished by enabling Directory Assistance on the Sametime server. The Sametime community servers had no local populated directory of their own, except for the definition of their administrative user, During installation, the 'Enable HTTP tunnelling' option was chosen.
Within the stconfig.nsf database, the IP addresses of the Portal Server and Domino servers were added to the 'Community Connectivity' document, in the 'Community Trusted IPs' field.
Within the Sametime administration utility,
Under 'Policies' - 'Sametime Default Policy' - '
Must set this community as the default community' was unchecked.
Under 'Configuration' - 'Connectivity' - '
Address for HTTP tunneled client connections' was set to the Sametime server IP address.
The 'LDAP' Basics, Authentication, Searching, and Group Contents pages were all reviewed and modified as necessary to match our IBM Tivoli Directory Server LDAP config.
On the Sametime server, the sametime.ini was edited to include: VPS_TRUSTED_IPS=list of IPs,delimited by commas of the Portal Server and Domino server.
Recommendation: Upgrade from Sametime 8.01 or greater for richer Business card functionality.
|WebSphere Portal server configuration|
The WebSphere Portal server was configured as defined within the Portal server documentation.
Portal was configured to use the IBM Tivoli Directory Server LDAP for authentication.
Additionally, CSEnvironment.properties was configured for Sametime awareness and for Domino Directory integration.
The Domino directory integration provided services for Domino database access, and also for the ability to automatically detect the Portal user's individual mail server and file information.
For each Domino server, within the Server document, be sure to populate the Internet Protocols - HTTP - Hosts name(s) field with the DNS name of respective Domino server. This allows the mailserver attribute found in each user's person document in Notes canonical format to convert to the corresponding DNS name for HTTP connections to be successful.
We were binding anonymously to the Domino directory, so it was necessary to expose the attributes that Portal server needed to lookups. To accomplish this, add a LDAP configuration document that applies to all servers or to the server defined as the Domino Directory host and add http-hostname, http-port, mailfile and mailserver to the list of queriable attributes. See Portal documentation for a full list of other attributes that you may want to add.
Within /PortalServer/shared/app/config/CSEnvironment properties, in the Sametime section, the following additional values were set:
In the Domino Directory section, the following values were set:
In order for Sametime awareness and chat to work fully in the Firefox browser, some additional steps were taken. These steps are detailed fully within the Portal documentation: http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/collab/i_domi_t_sv_st_copy_stlinks.html
The Portal Server was the source of the LTPA key that was used throughout this configuration. Refer to the 'Notes about LTPA/SSO' section of this document or the WebSphere documentation on generating and exporting LTPA keys. Those keys were then imported into Domino 8.5, Domino 8.01 (Sametime Community servers) and the WebSphere Application Server hosting Activities.
|Domino 8.5 server configuration|
The Domino servers were clustered, using the standard Domino Administrator user interface. Mail file replicas were created across the cluster. The clustered machines represented various operating systems and installation paths.
Lotus iNotes (iNotes)/Sametime configuration.
The mail85.ntf template supports Lotus iNotes as well as traditional Notes client mail access. Sametime awareness and chat within iNotes using various resources.
To accomplish Sametime integration into iNotes, several items from the Domino 8.5 Admin Help topic "Setting up Lotus iNotes with Sametime" were followed.
The Domino Server is set up and users with the mail85.ntf template are created.
The Sametime server is set up.
The Sametime and Domino each have created connection documents to the other.
The Domino Server's configuration document is updated to include the Sametime server information as documented in the Domino Admin Help topic: "Editing the Configuration Settings document for Lotus iNotes" (choosing LTPA)
Note that the Sametime server specified is the Tivoli Access Manager junction for the Sametime server.
Configure the Java servlet support
Additionally several other steps were taken:
The contents of the STLinks folder from a Sametime server need to be copied to the same location on the iNotes servers.
Verify that the contents of hostInfo.js and stlinks.js on all Domino iNotes and Sametime servers toward the top include the lines:
For Firefox users:
On the Domino iNotes server, iNotes_WA_DisableFirefoxAwareness=0 was added to the notes.ini
The signed version of stlinks.jar was copied into the stlinks directory (from the stlinks/signed directory on the Sametime server) everywhere you have an stlinks directory. That is, on the Sametime servers, and on the Domino servers.
To allow the iNotes buddy list to work:
Create a text file on the Domino iNotes server called servlets.properties, in the data directory. In servlets.properties, add these lines:
servlet.DWABuddyList.initArgs=logging=1,stserver=[hostname of Sametime server]
Hint: During Domino server upgrades, the stlinks directory is overwritten back to a default state, so backup the /notesdata/domino/html/sametime/stlinks directory anytime that you are upgrading a configured server.
|Lotus Connections - Activities|
The Lotus Connections - Activities component was installed as its documentation described with a deviation in the WebSphere Security configuration. Standalone LDAP registry was defined instead of Federated repositories. This allowed for SSO via LTPA tokens to the other application servers in the environment.
These are general steps for installing and configuring TAM and WebSEAL, and to TAM work with Domino.
1. Use the Tivoli WebSEAL installation guide to install WebSEAL. The install guide is at http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?toc=/com.ibm.itame.doc/toc.xml
2. Connect your TAM server to the same LDAP that your Domino Server is going to use.
3. Create an LTPAtoken and create a Web SSO document for your Domino Server using the LTPAtoken you just created. See the section "Notes about LTPA/SSO" for more information on this.
4. Create a Junction for Domino Server. Here is an example syntax.
server task create -t tcp -h -p -j -w -i / -A -F -Z
server task default-wevseald-tamserver1 create -t tcp -h dominoserver1.ibm.com -p 80 -j -w -i /domino -A -F c:\ltpatoken -Z password
5. Import the Users from your LDAP server who will have access to the Domino Server, through TAM.
Here is an example syntax.
User Import Command -
User Import Dominouser1 "cn=domino user1,o=dominoorg"
6. Set the users accounts to Valid.
Here is an example syntax.
User Modify account-valid yes
User Modify DominoUser1 account-valid yes
7. Set the user passwords to Valid.
Here is an example syntax.
User Modify password-valid yes
User Modify DominoUser1 password-valid yes
These can be batched and into a file and run using the following command from a prompt on the WebSEAL Server.
Here is an example.
pdadmin -a -p c:\userimport.txt
The SSO/LTPA domain was started at the WebSphere Portal Deployment manager. From WebSphere, the LTPA keys were created and exported to be used within the rest of the environment.
To create and export your LTPA keys on a WebSphere Server:
WebSphere Administrator: Security - Global Security - Authentication Mechanisms/LTPA - Single Signon (SSO). Set the domain name field to the greatest common domain name that all the servers in the environment share. i.e. if WebSphere Portal is on wp2345.massachusetts.ibm.com, Sametime is on st2345.kentucky.ibm.com, Domino is on dom1234.massachusetts.ibm.com and the http servers are on http567.ibm.com, set the Domain name to ibm.com and Click Apply.
Go to Security - Global Security - Authentication Mechanisms/LTPA. Set a password, Generate keys, Export keys (defining a Key file name).
For the Sametime and Domino environments, go into the Domino Administrator, Servers View - All Server documents. From there, click the Web button and select Create Web SSO Configuration.
In the Web SSO Configuration document, set:
DNS domain to the Domain name value previously set on WebSphere
Map names in LTPA tokens to Enabled
Expiration time to the same expiration value had in WebSphere
For the field labeled Participating servers, add all the servers in the Domino environment within which you are working
Click the Keys button, and select Import WebSphere LTPA keys. Follow the prompts to import the WebSphere keys. Once the WebSphere LTPA keys are imported, verify and adjust the LDAP realm within this Web Configuration document is set to the DNS name of the IBM Tivoli Directory Server LDAP and LDAP port number separated by a \:, i.e.: ldapforconfig.company.com\:389.
In each Domino server's server document, Internet Protocols page, Domino Web Engine page, set Session authentication to: Multiple Servers (SSO)
Repeat this procedure for each Domino environment, including the Domino servers hosting Sametime.
For this to properly take effect, the Domino servers must be restarted.
For any other WebSphere environments within the environment, like Activities, import the WebSphere LTPA keys within the WebSphere Administrator for that application server.
The testing that occurred in this environment focused on end-to-end interoperability and single signon as well as Domino failover, replication, iNotes Access, Archiving, Mail, Calendar and Scheduling, Administration, Productivity editors, Basic and Standard clients, and cross OS interoperability. The WebSphere Portal Server was used to test Domino Portlets. The Lotus Connections server was used to host Activities within the Basic and Standard Notes Client. The Sametime server was used to provide awareness and chat to iNotes Applications, Notes clients, Basic and Standard client, and WebSphere Portal.
NOTE: Every customer 's configuration is different. Our results were obtained in a controlled test environment. Customer environments are usually less optimal and may not get the same results. Understanding your environment (usage scenario, network, etc...) is crucial before recommending scaling numbers, hardware and solutions.