New Internet password is not immediately usable
If you change your Internet password using the ChangePassword form in your Web browser, there can be a significant time delay before you can use that new password to log in to the Lotus® Domino® Web server.
Even if you change your Internet password by editing your Person document in the Domino Directory directly, you cannot always log in immediately with the new password.
In both cases, eventually you are able to log in with the new password. Why does this delay occur, and is it possible to shorten or lengthen the delay time?
The delay when changing an Internet password is documented in the Release Notes for Domino:
Changing your internet password in Domino Web Access
When you change your internet password, allow time for the server's AdminP process to run before the change takes effect. You may have to wait anywhere from 5 minutes to several hours depending on how often the AdminP process is set to run on the server.
If you change the Internet password by editing the Person document, AdminP is not involved, and you do not have to be concerned with the AdminP process. However, there are still other factors that can contribute to a delay for a period of time before the new Internet password can be used to authenticate to a Web server, such as:
- The HTTP task has a user cache that refreshes every two minutes by default.
- The NameLookup sub-processes have a cache that is refreshed only once every five minutes, if there was a change to one of the views in the server's Domino Directory.
- Depending on your Domino Server topology, you might have to wait for replication to occur between servers in order for the changes to the Person document to be updated on servers where you are actually logging in.
To affect the delay period, such as to make it shorter, you can consider the following options:
- If users change their password using the Web form, make sure the AdminP process is scheduled to process requests on a regular, short time interval.
- It is possible to change the size of the HTTP user cache to 0, which effectively eliminates the user cache, by editing the "Maximum Cached Users" field in the Server document. This change could shorten the delay period but would result in negative effects elsewhere in the HTTP task's processing of requests, so this is not a recommended change.
- The NameLookup cache can be manually cleared without any real negative effects. The command to do this at the Domino server console is "show nlcache reset."
Be aware that this command clears the Domino server's cache used for NameLookup, so all users will have to be found again to have their name and group information re-cached.
- Make sure that replication is scheduled to occur frequently if the change to the Person document is made on a server other than the HTTP server to which the user is authenticating. A frequent replication schedule will simply ensure updates to the Domino Directory are seen on all servers in a short period of time.
Similar behavior can be seen when you create and set up a new Web user, with the same underlying cause. This delay occurs for new Web users because the Update task on the Domino server must run to update certain views in the Domino Directory and other settings. Once the views are updated, the new Web user can log in as expected. Manually running the tasks generally does not minimize the delay because it still takes some time for these tasks to complete, especially if the data must replicate to another server.
This problem can be further exacerbated if you have multiple Domino HTTP servers in your environment and do not make use of Multi-Server SSO session authentication. If your password is effectively changed on ServerA, that change still takes some time to replicate to ServerB. Therefore, the same caches and delays may be encountered.
More support for:
Software version: 6.0, 6.5, 7.0, 8.0, 8.5, 9.0, 9.0.1
Operating system(s): AIX, IBM i, Linux, Solaris, Windows, z/OS
Reference #: 1245252
Modified date: 21 December 2006
Translate this page: