Front cover - IBM Redbooks

490 Lotus Security Handbook
At this point the Notes client software prevents the user from accessing the
server.
Figure 11-16 Account lock out dialog box
The digest stored in the Person document is then scrambled and hence different
from the copy stored in the user ID. This mechanism also provides a safety net
for the administrators since – should the user have left the organization and the
administrator forgotten to add them to a deny access group list – then as long as
password checking remains enabled, anybody using the Notes user ID will be
unable to access the server since the digests will no longer match.
However, this is still no substitute for using the Deny Access ACL groups.
Even if the user changes his or her password after this period, that user will be
unable to access the server to submit the adminP password change request.
Once the user has seen this error message, that person has no option but to call
an administrator for assistance.
Unlocking the account
Unlocking the user's account requires assistance from an administrator who has
access to modify the user's Person document.
The steps are quite straightforward but there are opportunities to make errors if
the administrator doesn't complete the whole Adminp process or modifies the
wrong fields by mistake.
For example, by deleting the password digest in the person document, the next
time the user logs back into the server, that person will still be denied access
(this is the correct behavior since the Notes user ID file still contains an expiration
date that has expired). However, when the user changes their password in their
ID file the password digest in the user.id file also gets updated, but since there is
no digest in the person document there is no password digest check to take
place and the user is now granted access. Since the last change date is more
recent than that recorded in the person document, the client generates an
Adminp request.