Topics

Please refer to the following troubleshooting tips regarding Single Sign-on (SSO) for Domino and WebSphere. For more instructions on SSO, please see the Release Notes entitled, "Enabling Single Sign-on for Domino and WebSphere servers."

This Release Note contains troubleshooting tips for three scenarios:

• Configuring the Web SSO document fails
• Server Console fails to load the Web SSO document upon HTTP start-up
• Authentication fails

• The client must be able to find server documents for the participating Single Sign-on servers. Since the Web SSO document is encrypted for the servers you specify, your client's location record's home server must be pointing to a server in the domain where the participating servers reside so that lookups will be able to find the public keys of the servers. If you get a message box that states that one or more of the participating server's cannot be found, then those servers will not be able to decrypt this document and will not perform Single Sign-On.
  
  When the Web SSO document is saved, the status bar will state how many public keys were used to encrypt the document by finding the listed servers, Authors and Administrator's on the document.

• If the Server Document is configured for Multi-Server in the Session Authentication field, then the HTTP server will try to find and load a Web SSO Configuration document during start-up. The server console will report the following if a valid document is found and decrypted:

If participating SSO server is reporting the following, then SSO will not work:

HTTP: Error Loading Web SSO configuration. Reverting to single-server session authentication.

• Make sure that there is only one Web SSO document in the Web Configurations view of the Directory and the $WebSSOConfigs hidden view. Currently you cannot create more than one, but another one could be replicated over from another server. (In a future release this document will be managed by Adminp, as only one should exist per domain.) Check the hidden view $WebSSOConfigs. From a client, select File -> Database -> Open. In the dialog type in the server name and the names.nsf file in the bottom half. Hold the Shift and Ctrl buttons down and double click the open button. This will open up the directory with all the hidden views. Make sure you only have one document in this view. If you have more than one, then delete them all and recreate the document.
• If the server document's public key does not match the public key in the ID file then the decrypting of the Web SSO document will fail and receive the error message above on the console. This could happen if the id file was created multiple times and didn't update the server doc correctly. Usually there is an error on the server console that states that the public key does not match the server id. If this happens then SSO will not work because the document could be encrypted with a public key for which the server does not possess the corresponding private key to decrypt with. The way to correct this is to copy the public key out of the server id then paste it into the server doc and recreate the Web SSO document.

• WebSphere and Domino should both be configured for the same LDAP directory. The authentication token used for Single Sign-On stores the full Distinguished Name of the user (DN), for example, cn=john smith,ou=sales, o=ibm, c=us. The way to set up LDAP for Single Sign-on to work would be to set-up Directory Assistance in Domino and configure it to point at the LDAP server the WebSphere server is using. Another way is to load LDAP on the Domino Directory and configure WebSphere to use the Domino LDAP server.
• If Single Sign-on participating servers include WebSphere servers, using a Domino LDAP directory, the users with flat names will not work. If the participating servers are all Domino, then Single Sign-On will work with flat user names. It is best to always use hierarchical names and is strongly recommended.
• URLs issued to servers configured for Single Sign-on must specify the full DNS server name, not the host name or IP address. For browsers to be able to send cookies to a group of servers, the DNS domain must be included in the cookie. The DNS domain in the cookie must match the URL. This is why cookies cannot be used across TCP/IP domains.
• Clustered Servers must have the host name populated with the full DNS server name in the server document for ICM to redirect to cluster members using Single Sign-on. If this field is not populated ICM (the Internet Cluster Manager) will redirect URLs to clustered web servers with only the TCP/IP host name, by default, and will not be able to send the cookie because the DNS domain is not included in the URL. Edit the server document, go to the Internet Protocols tab -> HTTP tab -> host names field and add the server's full DNS name.
• If WebSphere's LDAP server is configured with a port, the Domino Web SSO configuration document must be edited and a \ must be added to the LDAP realm field for WebSphere servers. For example, replace r5qmr.iris.com:389 with r5qmr.iris.com\:389.