Domino: Single sign-on configuration troubleshooting tips for security

• Failure to save the Domino Web SSO configuration document

  The client must find Domino server documents for the participating SSO Domino servers. The Web SSO configuration document is encrypted for the servers specified. The home server indicated by the client location record must point to a server in the Domino domain where the participating servers reside. This pointer ensures that lookups can find the public keys of the servers.

  If we receive a message stating that one or more of the participating Domino servers cannot be found, then those servers cannot decrypt the Web SSO configuration document or perform SSO.

  When the Web SSO configuration document is saved, the status bar indicates how many public keys are used to encrypt the document by finding the listed servers, authors, and administrators in the document.

• Failure of the Domino server console to load the Web SSO configuration document at Domino HTTP server startup

  During configuration of SSO, the server document is configured for Multi-Server in the Session Authentication field. The Domino HTTP server tries to find and load a Web SSO configuration document during startup. The Domino server console reports the following information if a valid document is found and decrypted: HTTP: Successfully loaded Web SSO Configuration.

  If a server cannot load the Web SSO configuration document, SSO does not work. In this case, a server reports the following message: HTTP: Error Loading Web SSO configuration. Reverting to single-server session authentication.

  Verify that only one Web SSO configuration document is in the web configurations view of the Domino directory and in the $WebSSOConfigs hidden view. We cannot create more than one document, but we can insert additional documents during replication.

  If we can verify only one Web SSO configuration document, consider another condition. When the public key of the server document does not match the public key in the ID file, this same error message can display. In this case, attempts to decrypt the Web SSO configuration document fail and the error message is generated.

  This situation can occur when the ID file is created multiple times, but the Server document is not updated correctly. Usually, an error message is displayed on the Domino server console stating that the public key does not match the server ID. If this situation occurs, SSO does not work because the document is encrypted with a public key for which the server does not possess the corresponding private key.

  To correct a key-mismatch problem:

  1. Copy the public key from the server ID file and paste it into the Server document.

  2. Create the Web SSO configuration document again.

• Authentication fails when accessing a protected resource.

  If a web user is repeatedly prompted for a user ID and password, SSO is not working because either the Domino or the WAS security server cannot authenticate the user with the LDAP server. Check the following possibilities:

  • Verify that the LDAP server is accessible from the Domino server machine. Use the TCP/IP ping utility to check TCP/IP connectivity and to verify that the host machine is running.

  • Verify that the LDAP user is defined in the LDAP directory. Use the idsldapsearch utility to confirm that the user ID exists and that the password is correct. For example, we can run the following command, entered as a single line:

    Use the OS/400 Qshell, a UNIX shell, or a Windows DOS prompt

    % ldapsearch -D "cn=John Doe, ou=Rochester, o=IBM, c=US" -w mypassword
    -h myhost.mycompany.com -p 389 -b "ou=Rochester, o=IBM, c=US" (objectclass=*)
    

    The percent character (%) indicates the prompt and is not part of the command. A list of directory entries is expected. Possible error conditions and causes are contained in the following list:

    • No such object: This error indicates that the directory entry referenced by either the user's distinguished name (DN) value, which is specified after the -D option, or the base DN value, which is specified after the -b option, does not exist.

    • Credentials that are not valid: This error indicates that the password is not valid.

    • Cannot contact the LDAP server: This error indicates that the host name or the port specified for the server is not valid or that the LDAP server is not running.

    • An empty list means that the base directory specified by the -b option does not contain any directory entries.

  • If we are using the user's short name or user ID instead of the distinguished name, verify that the directory entry is configured with the short name. For a Domino directory, verify the Short name/UserID field of the Person document. For other LDAP directories, verify the userid property of the directory entry.

  • If Domino authentication fails when using an LDAP directory other than a Domino directory, verify the configuration settings of the LDAP server in the Directory assistance document in the Directory assistance database. Also verify that the Server document refers to the correct Directory assistance document. The following LDAP values specified in the Directory Assistance document must match the values specified for the user registry in the WAS administrative domain:
    • Domain name
    • LDAP host name
    • LDAP port
    • Base DN

    Additionally, the rules defined in the Directory assistance document must refer to the base distinguished name (DN) of the directory containing the directory entries of the users.

    We can trace Domino server requests to the LDAP server by adding the following line to the server notes.ini file:

    webauth_verbose_trace=1

    After restarting the Domino server, trace messages are displayed in the Domino server console as Web users attempt to authenticate to the Domino server.

• Authorization failure when accessing a protected resource.

  After authenticating successfully, if an authorization error message is displayed, security is not configured correctly. Check the following possibilities:

  • For Domino databases, verify that the user is defined in the access-control settings for the database. Refer to the Domino administrative documentation for the correct way to specify the user's DN. For example, for the DN...
    cn=John Doe, ou=Rochester, o=IBM, c=US

    ...the value on the access-control list must be set as...

    John Doe/Rochester/IBM/US

  • For resources that are protected by WAS, verify that the security permissions are set correctly.

    • If granting permissions to selected groups, make sure that the user attempting to access the resource is a member of the group. For example, we can verify the members of the groups using the following website to display the directory contents:
      Ldap://myhost.mycompany.com:389/ou=Rochester, o=IBM, c=US??sub

    • If we changed the LDAP configuration information (host, port, and base DN) in a WAS administrative domain since the permissions were set, the existing permissions are probably not valid and need to be recreated.

• SSO failure when accessing protected resources.

  If a web user is prompted to authenticate with each resource, SSO is not configured correctly. Check the following possibilities:

  1. Configure both WAS and the Domino server to use the same LDAP directory.

     The HTTP cookie used for SSO stores the full DN of the user, for example...

     cn=John Doe, ou=Rochester, o=IBM, c=US

     ...and the domain name service (DNS) domain.

  2. Define web users by hierarchical names if the Domino directory is used.

     For example, update the User name field in the Person document to include names of this format as the first value: John Doe/Rochester/IBM/US.

  3. Specify the full DNS server name, not just the host name or TCP/IP address for websites issued to Domino servers and WASs configured for SSO.

     For browsers to send cookies to a group of servers, the DNS domain must be included in the cookie, and the DNS domain in the cookie must match the web address. This requirement is why we cannot use cookies across TCP/IP domains.

  4. Configure both Domino and the WAS to use the same DNS domain.

     Verify that the DNS domain value is exactly the same, including capitalization. We need the name of the DNS domain in which WAS is configured.

  5. Verify that the clustered Domino servers have the host name populated with the full DNS server name in the server document.

     By using the full DNS server name, Domino Internet Cluster Manager (ICM) can redirect to cluster members using SSO. If this field is not populated, by default, ICM redirects web addresses to clustered web servers using the host name of the server only. ICM cannot send the SSO cookie because the DNS domain is not included in the web address. To correct the problem:

     1. Edit the Server document.

     2. Click Internet Protocols > HTTP tab.

     3. Enter the full DNS name of the server in the Host names field.

  6. If a port value for an LDAP server is specified for a WAS administrative domain, edit the Domino Web SSO configuration document and insert a backslash character (\) into the value of the LDAP Realm field before the colon character (:).

     For example, replace...

     myhost.mycompany.com:389

     ...with...

     myhost.mycompany.com\:389

• Users are not logged out after the HTTP session timer expires.

  If users of WAS log on to an application and sit idle longer than the specified HTTP session timeout value, the user information is not invalidated and user credentials stay active until LTPA token timeout occurs.

  After applying PK25740 to log out users from the application after the HTTP session has expired.

  The following property only applies to applications using form login...

com.ibm.ws.security.web.logoutOnHTTPSessionExpire

1. In the administrative console, click Security > Global security.

2. Under Custom properties, click New.

3. In the Name field, enter...
   com.ibm.ws.security.web.logoutOnHTTPSessionExpire.

4. In the Values field, enter true.

5. Click Apply and Save to save the changes to the configuration.

6. Resynchronize and restart the server.

Unexpected re-authentications:

When we set custom property...

com.ibm.ws.security.web.logoutOnHTTPSessionExpire=true

...unexpected re-authentications might occur when we are working with multiple web applications. By default, each web application has its own unique HTTP session, but the web browser has one session cookie. To address this issue, we can change the HTTP session configuration by giving each application a unique session cookie name or path setting. As a result, each application gets its own session cookie. Alternatively, we can configure multiple web applications with the same enterprise application to share the same HTTP session.

Possible issues when SSO is enabled and Firefox v3.6.11 is configured to accept third-party cookies.

If we have SSO enabled, and when using Firefox v3.6.11 one of the following is true:

• It is configured to accept third-party cookies that are kept until they expire or until Firefox is closed

• We have one session open but are switching to different applications

• More than one session is opened for different applications that require different users for authorization

we might see the following error message: Error 403: AuthorizationFailed.

To resolve, clear the third-party cookies before launching a new application by doing the following:

1. Select Firefox Tools > Options > Privacy.

2. Ensure that the history is set to Remember History.

3. Click on Remove individual cookies to delete the cookies.

We can also close other sessions if Firefox is configured to accept third-party cookies that are kept until Firefox is closed.

Troubleshoot security configurations

Assembling so that session data can be shared