Domino Webserver Authentication Troubleshooting Table of Contents
If
you are having problems logging in
Problems
Moving Between Servers using SSO
Problems
with Timeouts when using SSO
If you are having problems logging in to your Domino server using a web
browser you can follow this script to try to diagnose the problem.
Before beginning you should make sure Internet Explorer has it's "Show
friendly HTTP error messages" option disabled:
You can access this option using the "Tools -> Internet Options"
menu in Internet Explorer. Sometimes these friendly error messages
can mask more informative errors returned from the Domino server.
If you are having problems logging
in:
1.
If you see the standard browser popup
window prompting for your username & password then you have Session-based
Authentication disabled on the Domino server.
1.
If you are receiving the popup window
over and over again, use the Cancel button and you may get an informational
error message. Typically this will either be "User not authenticated"
or "You are not authorized to perform this operation ".
2.
If you have enabled Session-based authentication,
check the server document to make sure the setting is in effect. You
will need to check the "Session authentication" field on the
Domino Web Engine tab:
1.
If you are using Internet Sites documents
this field will be on the Web Site document.
2.
If you are using the Web Configurations
documents this field will be on the Internet Protocols tab of the Domino
Server document.
3.
Restart the HTTP task within Domino
to make sure the setting has taken effect. Use the command "restart
task http" instead of "tell http restart" or "tell
http refresh" since these last two commands do not completely reload
the HTTP configuration.
1.
If you still see the browser popup
prompting you for credentials, make sure you are accessing the correct
Virtual Server or Internet Site.
1.
An easy way to test this is to change
the HomeURL field and make sure a request to that site brings you to the
correct resource. Useful examples are /homepage.nsf or /log.nsf :
2.
Make sure you are accessing the correct
server in your Notes client and web browser, as sometimes I end up
editing the server document on my hub server but don't realize it until
things aren't working the way they should.
4.
If you are not receiving any error messages
in the login form, you may be encountering the issues documented in
technotes 1090417 or 1308550 .
1.
Make sure you are using the server's fully
qualified domain name in your browser and make sure the domain name
matches what is specified in the SSO document:
5.
If you receive the message "You are
not authorized to perform this operation" error message
then you will need to check the ACL for the resource you are trying to
access. Also check group membership in case you are using a group
to authorize this user to the resource.
6.
If you receive the "Invalid username
or password was specified" error message this means the server
is unable to validate the username & password you have entered.
1.
Try different variations of the username.
If you are logging in with the user's shortname, such as "Tuser",
try using the first and last name, such as "Test User". If
that doesn't work, use the first entry in the user's Person document, which
should be their hierarchical name, such as "Test User/Org".
1.
If the shortname is the only name variation
that is failing to authenticate, you will have to change the following
field in the Server document to "More name variations with lower security"
:
Note that this change requires a Domino server restart.
2.
If you are unable to log in with "Test
User" then the server is possibly finding another user with that
same first and last name, but with a different Internet Password. Search
the $Users view in the server's names.nsf and any secondary directories
used for authentication. You may need to alter one of the users,
or simply inform the user they must use an alternate name to log in.
3.
If you are unable to log in with "Test
User/Org"
1.
Check the user's Internet Password as
set in the Person Document. Since the password is encrypted,
try setting it to a new value for testing purposes, which you can then
change at a later date. Be aware that this password may take a minute
or two to become active, per technote 1245252.
2.
Check the user's Person Document to
make sure "Test User/Org" is the first entry in their "User
Name" field. If they have some other value, this could be the
source of the authentication problems, and the first line should be changed
to be "Test User/Org".
3.
If the user does not exist in the Domino
Name and Address Book, check the secondary directory source (be it
a secondary Domino address book, or an external LDAP directory) to verify
the password you are using.
2.
Try a different user. If you
are able to log in with another user then you can compare the Person Documents
for the working and non-working users to look for differences.
3.
Check your Directory Assistance configuration.
The following are some basic settings to verify
1.
Make sure the "Trusted for Credentials"
option is enabled on the "Naming Contexts (Rules)" tab of the
Directory Assistance document
2.
Make sure the server is using your Directory
Assistance database: Issue the command "show xdir"
and look for output like the following:
show xdir
DomainName DirectoryType
ClientProtocol Replica/LDAP Server
1 LEBOWSKI Primary-Notes
Notes & LDAP names.nsf
2 TEST Secondary-Notes
Notes Huey/LTSwebserver!!names.nsf
Directory Assistance Database 'da.nsf' in use
7.
At this stage you may need to enable
debugging on the Domino server, specifically webauth_verbose_trace=1 and
contact an IBM Lotus Support rep to assist you with interpreting the output.
If you are having problems moving
between servers:
The following are three major causes for re-authentication even if you
have set up Multi-Server SSO (Single Sign-On) on multiple Domino (or Websphere)
servers.
1.
The various servers do not have closely
synchronized clocks. This is most likely your problem if you
can log in to Server A and then navigate to Server B without problems but
are prompted to re-authenticate when starting on Server B and then navigating
to Server A. Another indicator of this issue is if you see the following
message displayed in the login form: "Your session with the server
has expired or is invalid" . You can check the server times
using the Domino console command "show server" and making note
of the time displayed. This issue is documented in technotes 1159786
and 1210929 . IBM Lotus Support can enable debugging to verify if
this is causing your SSO problems, and technote 1210929 has steps and a
sample of the debugging output.
2.
Websphere & Domino are using different
SSO keys. This is most likely your issue if you are prompted
for authentication after navigating to a Domino server in your browser,
even though you have already authenticated with your Websphere server.
A key indicator of this issue is the message "Your session with
the server has expired or is invalid." If this is your issue
you will be re-prompted for authentication if you log in to the Domino
server but then navigate in your browser to your Websphere server. After
you log in to one of your Domino servers it you can navigate among your
Domino servers without the need to re-authenticate. Technote 1210929
has further documentation of this issue.
1.
The most common way to resolve this issue
is to re-generate and re-export the Ltpa keys within Websphere. To
do this, re-generate the Ltpa key within Websphere and then restart the
Websphere server to make sure these new keys are being used. Then
you need to export the new keys once the Websphere server has restarted,
and then import the newly exported Ltpa key into your Domino SSO configuration
document.
3.
One (or more) of the servers is unable
to read the SSO document. To see if this is your issue, log in
to each Domino server and make note of the cookie that is issued by the
server. There are quite a few ways to do this, and here are few simple
ones:
1.
Restart the Domino HTTP task and look
for the following message in the server console:
HTTP Server: Error loading Web SSO Configuration 'LtpaToken3' (Single Sign-On
configuration is invalid)
Make sure to use the command "restart task http" and not "tell
http restart" or "tell http refresh" as these will not completely
reload the server's HTTP configuration.
If you receive this error you need to make sure your Domino server is properly
listed in the "Participating Servers" section of your SSO configuration
document. Make sure to use the Domino hierarchical name and not the
server's DNS name or IP address:
1.
If you have checked this field but
your server is still unable to load the SSO configuration document you
need to make sure your address book contains one and only one entry for
the server's name. In some cases a user or group may have an alternate
name that matches the Domino server's name and this can cause the wrong
public key to be used when the SSO document is saved. The best way
to verify whether this is happening is to search the $Users view of your
server's names.nsf (and any secondary directories) to make sure only the
Domino server document is found when searching for "Test Server"
in this example.
2.
You should also check your Notes Client's
Location document to make sure it is accessing the correct server's address
book for name lookups and mail addressing. The easiest way to verify
this is to create a new Memo and verify you can find the server if you
click on the "To" field and use the Notes Client's address picker.
2.
Log in to the server using your browser
and then place the following in the address bar: "javascript:document.cookie".
After entering this and pressing Enter you should see the browser
display the cookies present in your browser. If the server is unable
to read the SSO configuration document you should see a DomAuthSessID cookie.
If SSO were working properly you would only see a LtpaToken cookie.
If you are experiencing timeout
issues: If you are prompted to re-authenticate
sooner than you feel you should be, check the following for possible resolution
1.
Check to see if the timeout occurs in
all applications on your server. Domino Web Access has some specialized
functionality for dealing with idle timeouts on the server, so if you don't
see the same timeout behavior in another standard Domino database you will
need to contact IBM Lotus Support to investigate the DWA timeout functionality.
2.
Read technote 1160458 to make sure you
have the Idle and Expiration timeouts set properly.
3.
Authenticate to the server and issue
the command "tell http show users" in the Domino server console.
The "Expires" column shows when that user session will
become invalid, regardless of activity or lack thereof. To increase
this time you should modify the "Expiration" field in the SSO
configuration document.
1.
If the Expires time does not correspond
with the Expiration field as set in the SSO Configuration document,
try creating a new SSO document and test with that. Note that the
expires time should never change once a user authenticates.
1.
Create a new SSO Configuration document
and set the Expiration field to 300 and name the document "LtpaTokenTesting"
:
Note - You will need to fill in the Organization field if your server
uses the Internet Sites documents instead of the Web Configuration documents.
2.
Modify your Server document or Internet
Site document to use this new LtpaTokenTesting SSO document.
3.
Restart the HTTP task using the Domino
console command "restart task http". Watch the Domino server
console for any errors while HTTP is loading.
4.
Log out of the server using http://server.domain.com/names.nsf?logout
5.
Re-authenticate and issue the command
"tell http show users" in the Domino server console. You
should now see the Expires column with a time 5 hours ahead of the server's
current time.
6.
If you don't see the correct Expires time
and you didn't notice any errors when HTTP was loading you should
check to make sure you are working with the correct server in your administrator
client and if you are, you should contact IBM Lotus Support for further
assistance.
2.
If you are not being timed out even though
you have been idle and should be timed out due to inactivity you should
check the "Idle Session Timeout" and "Minimum Timeout"
fields in the SSO document. Note that an inactive user can still
have a valid session if they are active for up to twice the "Minimum
Timeout". See technote 1160458 for more details.
1.
Create a new SSO Configuration document
and set the Expiration field to 300, the Minimum timeout to 5 minutes,
and the Configuration name to "LtpaTokenIdleTesting" :
Note - You will need to fill in the Organization field if your server
uses the Internet Sites documents instead of the Web Configuration documents.
2.
Modify your Server document or Internet
Site document to use this new LtpaTokenIdleTesting document.
3.
Restart the HTTP task using the Domino
console command "restart task http". Watch the Domino server
console for any errors or informational messages while HTTP is loading.
4.
Log out of the server using http://server.domain.com/names.nsf?logout
5.
Re-authenticate and issue the command
"tell http show users" in the Domino server console. You
should see your new user session with the Expires column showing the server's
current time plus 5 hours.
6.
Wait 12 minutes and then attempt to access
a database in your browser, even simply refreshing your current page
should be sufficient.
7.
If you are not prompted to re-authenticate
at this time, issue the "tell http show users" command and make
sure the Expires time has not changed for your user.
8.
If the Expires time has been updated then
your server is not using Multi-Server SSO. Check to make sure
the URL used in your web browser matches the correct Domino server and
Virtual Server or Internet Site document if those are in use.