We are a little company (4 people) and actually trust each other. But now there is a problem. I assume that one of the former employees has taken my ID file with him and now using.
I really not an expert with certifying users and ID files.
What is the best action I can do now? I could change my password on the workstation. But does this also update the password in any ID files on remote computer?
Can I do something with certifying my id file again?
If someone can put me into right direction would be really nice.
Subject: How to decline a User ID file
Edit the server document:In the Security tab, click and hold on the field prompt for ‘check passwords on Notes IDs’
Also it may help if you search the administration help database for ‘password AND check’
Subject: RE: How to decline a User ID file
I will check this possibilty. Thanks.
I am checking the admin help right now. I am just confused what is what still. ID File, certificate, …
Subject: RE: How to decline a User ID file
Set the option to ‘yes’ in the server document.
Go to the view of people in the address book.
select all users
click on actions set password field
specify ‘check password’ in the dialogue box.
The server will store a ‘password digest’ in encrypted format in all the person documents.
It will compare the password digest with the password entered during the login attempt by the users.
If it matches, then goody goody. If it doesn’t, then the user cannot authenticate.
The meaning of this is that it will take (very slightly) longer for each login as the password entered is compared with the password known by the server.
Without this option (i.e. like you have it currently) the password entered is compared with the password digest stored in the Notes id file which is held on the user’s computer.
You need to set this up, then change your user password. Your naughty person who nicked your ID will no longer be allowed to log in unless he knows your new password.
Subject: RE: How to decline a User ID file
Thanks so much for your helpful response.
Subject: Generate a new key pair
Choose the “Create new public keys” option from the Other Options button in the Your Certificates panel of the User Security Dialog. This will generate a new RSA keypair in your ID file, which will prevent an attacker with an old copy of the ID from being able to sign documents with the new key or decrypt documents that were encrypted to the new key. If you also set “check public keys” in the server document, an attacker with an old copy of the ID file will no longer be able to log in to the server.
This will give you a more secure fix to the problem than turning on password checking… and you can do both, if you feel the need for redundancy. 
Good luck,
dave
Subject: What about documents that you had Encrypted w/ your old key pair?
Subject: RE: What about documents that you had Encrypted w/ your old key pair?
All documentation says that using the button to generate a new public key will keep the old private key, so that all previously-encrypted docs and dbs will still be accessible.
I would find this easier to believe if every test I’ve ever done didn’t make this out to be a lie; I’ve found that every time I’ve tried this, previously-encrypted docs and dbs were now inaccessible. Of course, since check passwords is such a better option, I haven’t tried it since R5.
Subject: The old key pair remains in the ID file
The old key pair is retained in the ID file for purposes of decrypting old encrypted documents, but the new key pair will be used for authentication and all new signatures and encrypted documents.