The IBM Lotus Domino System Verification Test (SVT) team tested several environmental configurations for the Lotus® Domino® server 8.5.1 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 included a Domino 8.5.3 server cluster, a Lotus® Sametime® 8.5.1 server, an IBM Tivoli Directory Server Lightweight Directory Access Protocol (LDAP) server, and a Lotus® Connections server. Domino 8.5.3 server cluster, a Sametime 8.5.1 Community, Meeting, Proxy, and Media servers, a IBM Tivoli 6.2 Lightweight Directory Access Protocol (LDAP) Server, a Lotus Connections server 3.0, and a Lotus Quickr 8.5.1 server.
The specifications of the servers used were as follows:
|Software Installed/purpose||Operating System||Hardware||Notes|
|Domino 8.5.3||Domino 8.5.3||AIX 6L Version 6.1 System, with TL1, and SP3||2 x PowerPC 4.5GHz/4GB Memory|
1 x Intel Pentium 4/2GB Memory
|Sametime Community Server 8.5.1||Domino 8.5.1/Sametime Community Server 8.5.1|
|Windows 2003 Enterprise x32 - SP2||Intel Xeon 3.00GHz/4.0GB Memory|
|Sametime Meeting Server 8.5.1 & Sametime Media Server 8.5.1||Sametime Meeting Server 8.5.1, Sametime Media Server 8.5.1, and WebSphere 184.108.40.206||Windows 2003 Enterprise x64 SP2||Intel Xeon 3.40GHz/4.0GB Memory|
|Sametime Proxy Server 8.5.1||Sametime Proxy Server 8.5.1 and WebSphere 220.127.116.11||Windows 2003 Enterprise x64 SP2||Intel Xeon 3.40GHz/4.0GB Memory|
|Lotus Quickr 8.5.1||Lotus Quickr 8.5.1 FP5||Windows 2003 Enterprise x32 - SP2||Intel Xeon 2.40GHz/2.0GB Memory|
|Lotus Connections||WebSphere 18.104.22.168 /Lotus Connections 3.0, DB2 v9.5|
IBM HTTP Server 22.214.171.124
|Windows 2003 SP2||Intel Xeon 2.40GHz/4.0GB Memory|
After the base installation of each product base, the first concern was coordinating authentication. It was important for Domino users, Sametime users, and Connections users to interact and inter operate 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.
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.
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.
: Upgrade from Sametime 8.01 or greater for richer Business card functionality.
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.1 Admin Help topic "Setting up Lotus iNotes with Sametime" were followed.
Additionally several other steps were taken:
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
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]
: 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.
The Lotus Connections 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.