Domino Webserver Authentication Troubleshooting

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.

No Comments Found