In NAB, we have enabled password checking in user ID at person document. Somehow, I encounter that the user Last Change Date and Password Digest are not getting stored in address book ( The field is empty ). The password checking in server security for each ID is set to enable for interval of 30 days.
Every 30th day the system will prompt users to change their Notesmail password. Once the user change the password, by rite the password should updated at the Password Digest field and so is the Date of changing the password. The funny thing is, users do get the notification of password change popup screen that was notified by the system and user managed to change password. Any idea why....? I've checked the tech note, many people have raised this issue but no answer. Is there any alternative way to update the Last Change Date and the Password Digest?
Well, this one has me stumped. I am going to appeal to our fine readers to see if anyone knows the answer. There is quite a bit of discussion on Notes.net about why password updates may not work correctly, but you have a different problem. Your password changes are working correctly, but the password digest field is not updating. Does anyone out there in SearchDomino land have some ideas to help??
In my experience, when this occurs, it indicates there is a problem with AdminP, which is what is actually used to update the hash and change date. So, the first step is to verify that AdminP requests from that server are, in general working. Often, the requests database isn't set up correctly -- non-replica copies, incorrect server set to be administration server. Sometimes the AdminP process is not running. Sometimes there are dead requests in the queue, and AdminP gets stuck processing bad requests and never gets to more recent ones.
I would check the AdminP Requests database on the NAB's administration server to see if the password update requests are present.
The surest way to test that AdminP requests from a particular server are working is to create a new test user (including ID and mailbox), using the normal creation procedure. After the new person doc has replicated to the suspect server, open the NAB on that server, and rename the user. This should cause a rename request to go into the suspect server's AdminP Requests database. Look for it. That will then replicate to the administration server. Look for it there. AdminP should then process it. Check to see that it gets processed.
If it is all working, you can then attempt to repeat the process in a controlled way to update the user's password. Change a test user's location document so his home server is the suspect server. Shut down the test user's client. Clear the test user's password history. Wait for it to replicate to the suspect server. Have the test user start Notes, and access the suspect server. It should either prompt for a new password, and create a request for the change, or simply take the existing password, and send its digest as a request for change. You can then following the request through the same steps as for the rename.
Dig Deeper on Lotus Notes Domino Administration Tools
Related Q&A from Chuck Connell
Learn how to change authentication timeout interval for Domino Web Access logins. Continue Reading
SearchDomino.com expert Chuck Connell helps a Lotus Domino administrator troubleshoot a "File truncated – file may have been damaged" error ... Continue Reading
This administrator has a replication issue between two servers in two domains. Front-end replication works fine, but when replication is initiated ... Continue Reading