InfoCenter Home >
5: Securing applications -- special topics >
5.8: Single Sign-On >
5.8.4: Troubleshooting SSO configurations
This article describes common problems in configuring single
sign-on between WebSphere Application Server and Domino and suggests
possible solutions. The problems include the following:
The client must be able to find Domino Server documents for the
participating SSO Domino servers. The Web SSO Configuration
document is encrypted for the servers that you specify,
so the home server indicated by the client's location record
must point to a server in the Domino domain where the participating
servers reside. This ensures that lookups can find the public keys
of the servers.
If you receive a message that states that one or more of the participating
Domino servers cannot be found, then those servers will not be able to
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 were used to encrypt the document by finding
the listed servers, authors, and administrators on the document.
During configuration of SSO, the Server document is configured for
Multi-Server in the Session Authentication field. Therefore, the
Domino HTTP server tries to find and load a Web SSO Configuration
document during startup. The Domino server console reports the
following 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. Such a server reports the following message:
HTTP: Error Loading Web SSO configuration. Reverting to
single-server session authentication.
Make sure that there is only one Web SSO Configuration
document in the Web Configurations view of the Domino
Directory and in the $WebSSOConfigs hidden view.
You cannot create more than one, but additional documents
can be inserted during replication.
Check the hidden view $WebSSOConfigs as follows:
- From a Lotus Notes client, select File --> Database --> Open.
- In the Open Database dialog, either type the
Domino server name and press Enter or select the Domino
server from the list.
- Type the value
names.nsf for the FileName field,
located at the bottom of the Open Database dialog box. Do not
press Enter. Instead, hold the the shift and control keys down and
click Open on the dialog box. This opens the
Domino Directory with all the hidden views exposed.
- At the bottom of the view list, click $WebSSOConfigs
and ensure there is only one document in this view.
If there are more than one, delete them all and re-create the
Web SSO Configuration document.
If there is only one Web SSO Configuration document, another
condition that can elicit the same error message is that the
public key of the Server document does not match the public key
in the ID file. 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, there is an error message displayed on the Domino Server Console
that states that the public key does not match the server ID. If this happens,
then 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, do the following:
- Copy the public key from the server ID file and paste
it into the Server document.
- Re-create the Web SSO Configuration document.
If a Web user is repeatedly prompted for a user ID and password,
SSO is not working because either the Domino or WebSphere security
server is not able to authenticate the user with the LDAP server.
Check the following possibilities:
- Verify that the LDAP server can be accessed from the Domino server
machine. Use the TCP/IP ping utility to
verify TCP/IP connectivity and that the host machine is running.
- Verify that the LDAP user is defined in the LDAP directory.
Use the ldapsearch utility to confirm that the
user ID exists and that the password is correct. For example,
the following command, entered as a single line, can be run
from 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 follow:
- No such object: This error indicates that the directory
entry referenced by either the user's DN value, which is
specified after the -D option, or the base DN value, which
is specified after the -b option, does not exist.
- Invalid credentials: This error indicates that the
password is invalid.
- Can't contact LDAP server: This error means that the
host name or port specified for the server is invalid
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 you are using the user's short name (or user ID) instead of the
Distinguished Name, ensure that the directory entry is configured
with the short name. For a Domino Directory, this is the
Short name/UserID field of the Person document. For other LDAP
directories, this is the userid property of the directory entry.
- If Domino authentication fails when using an LDAP directory other
than 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 WebSphere 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 DN of the directory containing
the directory entries of the users.
You can trace the Domino server's requests to the LDAP server by
adding the following line to the server's notes.ini file:
webauth_verbose_trace=1
After restarting the Domino server, trace messages are
displayed in the Domino server's console as Web users attempt
to authenticate to the Domino server.
After authenticating successfully, if a Web user is shown an authorization
error message, 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 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 URL to display the
directory contents:
Ldap://myhost.mycompany.com:389/ou=Rochester, o=IBM, c=US??sub
- If you have 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 invalid and need to be re-created.
If a Web user is prompted to authenticate each time he or she
accesses a resource, SSO is not configured correctly.
Check the following possibilities:
- Both WebSphere Application Server and Domino must be configured
to use the same LDAP directory. The HTTP cookie used for SSO
stores the full Distinguished Name (DN) of the user, for example,
cn=John Doe, ou=Rochester, o=IBM, c=US , and the DNS domain.
- If the Domino Directory is being used, Web users must be defined
by hierarchical names. 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 .
- URLs issued to Domino and WebSphere application servers configured
for SSO must specify the full DNS server name, not just the host
name or TCP/IP address. For browsers to be able 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 URL. (This is why
cookies cannot be used across TCP/IP domains.)
- Domino and WebSphere Application Server must be configured to use
the same DNS domain. Verify that the DNS domain value is exactly
the same, including capitalization. The DNS domain value can be found
on the Configure Global Security Settings panel of the WebSphere
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 Domino servers participating in SSO.
- Clustered Domino servers must have the host name populated with the
full DNS server name in the Server document for Domino ICM
(Internet Cluster Manager) to redirect to cluster members using SSO.
If this field is not populated, by default, ICM redirects URLs
to clustered Web servers by using only the host name. It cannot
send the SSO cookie because the DNS domain is not included in the URL.
To correct the problem, do the following:
- Edit the Server document.
- Select the Internet Protocols -- > HTTP tab.
- Enter the server's full DNS name in the Host names field.
- If a port value for an LDAP server was specified for a WebSphere
Application Server administrative domain, the Domino Web SSO
Configuration document must be edited and a backslash character (\)must
be inserted into the value of the LDAP Realm field before the colon
character (:). For example, replace myhost.mycompany.com:389 with
myhost.mycompany.com\:389.
|
|