One of our users had her laptop stolen. To prevent unauthorized access - I re-registered her with the option of Mail system = None, and said yes when I got the prompt that ‘a person by that name already exists. do you want to update the entry?’. Is just doing this enough to prevent the original id being used to access notes? Is there something more/else I should be doing to prevent the id on the stolen laptop or any other copies of the id from accessing notes?Typically what is best practice in such cases where ids fall into the wrong hands?
Subject: I’d recommend against re-registering the user
Re-registering the user will prevent the legitimate user from decrypting and reading any of their old encrypted email and documents. Instead, what you can do is:
Turn on password checking on the servers and the user’s person record.
Turn on public key checking on (at least) that user’s mail server(s) and home server.
Have the user change their password
Have the user manually trigger user key rollover (User Security Dialog - Your Certificates//Other Actions//Create New Public Keys)
Certify those new keys immediately. Kick adminp, the CA process, or whatever other mechanism you use to manage your certifier.
Now the stolen ID can’t authenticate to the servers due to both password checking and public key checking. The stolen ID can’t be used to decrypt any new encrypted documents sent to the user, and the user can still decrypt any old encrypted documents that they can access. The thief can decrypt any of the user’s old encrypted data that he or she can access, but steps 1 and 2 will limit the scope of that… and re-registering the user wouldn’t.
While that would work, a problem may arise where they have registered the same user again. If you put the user in Deny Access, then neither user will be able to access the server (neither the old, stolen ID nor the new ID).
Assuming that the names are identical.
I would go with Stan’s recommendation to force password checking. I would also keep an eye on the Notes Logs to see if the stolen user is attempting access. You might be lucky to get the IP Address and find your stolen laptop.
Subject: And don’t forget that password checking must be enabled in the person document as well as the server document
And the server needs a reboot if this field in the server document is edited.
Also remember that if you keep the old ID, the user will be able to access any old email which was encrypted by/for him/her. If you use a new ID, they will not.
Immediately changing the password with the “check password” feature enabled should be all that’s required, really, to prevent access to the server(s) – the thief would need to locally change the password to match the new one, and since there is no indication of what that new password is, it can’t be brute-forced.
(You can brute-force a Notes password locally, which will give local access. If the user tries to access the server, though, all they’ll get is a “password has been changed” error, with no access to the password digest stored on the Person document. Each guess would require changing the local password and attempting access to the server. Since the history would never match the legitimate password on a different copy – whether that’s a concurrent copy kept on a desktop or one recovered from the recovery database – the brute-force approach can’t work.)