- 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 that you specify. The home server that is 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 you 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. You cannot create more than
one document, but you can insert additional documents during replication.
If
you 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:
- Copy the public key from the server ID file and paste it into
the Server document.
- 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 WebSphere Application
Server security server cannot authenticate the user with the Lightweight
Directory Access Protocol (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, you can run the following
command, entered as a single line:
% 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 that is specified
by the -b option does not contain any directory entries.
- If you 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
that are specified in the Directory Assistance document must match
the values specified for the user registry in the WebSphere Application
Server administrative domain:
- Domain name
- LDAP host name
- LDAP port
- Base DN
Additionally, the rules that are defined in the Directory assistance
document must refer to the base distinguished name (DN) of the directory
that contains the directory entries of the users. You 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 WebSphere Application Server,
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, you can verify the members of the groups by using the following
Web site to display the directory contents: Ldap://myhost.mycompany.com:389/ou=Rochester,
o=IBM, c=US??sub
- If you changed the LDAP configuration information (host, port,
and base DN) in a WebSphere Application Server 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:
- Configure both WebSphere Application Server and the Domino server
to use the same LDAP directory. The HTTP cookie that is 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.
- 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.
- Specify the full DNS server name, not just the host name or TCP/IP
address for Web sites issued to Domino servers and WebSphere Application
Servers that are 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 you cannot use cookies across TCP/IP domains.
- Configure both Domino and the WebSphere
Application Server to use the same DNS domain. Verify that the DNS
domain value is exactly the same, including capitalization. The DNS
domain value is found on the Configure Global Security Settings panel
of the WebSphere Application Server administrative console and in
the Web SSO Configuration document of a Domino server. If you make
a change to the Domino Web SSO Configuration document, replicate the
modified document to all of the Domino servers participating in SSO.
- 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 by 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:
- Edit the Server document.
- Click Internet Protocols > HTTP tab.
- Enter the full DNS name of the server in the Host names field.
- If a port value for an LDAP server is specified for a WebSphere
Application Server 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 WebSphere Application Server
log onto 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
you apply PK25740, complete the following steps to log out users from
the application after the HTTP session has expired.
- In the administrative console, click Security > Global
security.
- Under Custom properties, click New.
- In the Name field, enter com.ibm.ws.security.web.logoutOnHTTPSessionExpire.
- In the Values field, enter true.
- Click Apply and Save to save the changes to your configuration.
- Resynchronize and restart the server.
Unexpected re-authentications: When
you set the com.ibm.ws.security.web.logoutOnHTTPSessionExpire custom
property to true, unexpected re-authentications might occur when you
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, you 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,
you can configure multiple Web applications with the same enterprise
application to share the same HTTP session. For more information,
see the Assembling so that session data can be shared topic.