Looking for something else?
Passwords and user certificates are two of the most popular administration topics on SearchDomino.com. Below are ten of the questions most commonly posed to the two administration experts on SearchDomino.com, Chuck Connell and Michael Lazar.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Recovering a password
Question 1: As a Domino administrator, how can I recover the password of a Notes user who forgets their password?
Answer: You should set up the official Notes Password Recovery feature. See the Domino Admin Help database.
Changing a password
Question 2: I am trying to change the Lotus Notes password to eight characters, but keep getting this message: "The password is insufficiently complex. Add more characters or varied characters."
Answer: I assume that you have the minimum password strength set to 8 for this ID, and that you are trying to set a password that is eight characters long. The problem is that Notes is looking for a "password strength" of 8, not a password length of 8 characters. Notes has a mysterious process for determining password strength, which is not exactly the same as the length of the password. For example "password" does not have a password strength of 8, but PassWerd might. Just try using better passwords and it should work.
Resetting a password
Question 3: Our administrator password has somehow either been changed or been corrupted. Is there a way to reset the password?
Unless you had set up an ID escrow agent (R4) or password recovery (R5), you may be out of luck. There is no feature to "reset" a password in a Domino/Notes ID file. However, all is not lost. Do you still have the Certifier ID and its password? If so, you can make a new administrator ID with the same username. That is the easiest route.
Missing the certifier ID password
Question 4: Our previous Notes administrator forgot to leave us the password of the certifier ID. What can we do? We need to urgently register new users.
You need to get that password. Otherwise, you will have to re-issue the certifier, which will cause problems. You would most likely wind up having to recertify all users and servers, because the root key for the certifier wouldn't match.
Question 5: We are doing password expiration for the first time for 6.5.3. Other than filling out the policy for security (the section called Password Expiration Settings) for all our /=O, are there any other places/sections that need to be completed? We would like the password change prompt to happen within the next two weeks. What do we put in for "required change interval?"
That's the only place you need it. If you want it to change in the next two weeks, you'd put 14 days in there. However, you would immediately have to change it to a more reasonable period (whatever your current policy is, say 90 days) almost immediately. In essence, to get the "soon" change, you are modifying that field twice. Some people might get prompted to change it twice, as well, because of the quick timeframe.
Password expiration and grace period
Question 6: What is a typical password expiration period? What is a typical grace period?
A typical password expiration period is 180 days. A typical grace period – the time interval in which a user's password has expired, but will still work – is typically 60 days.
No password prompt
Question 7: A Notes 6.0 client suddenly stopped prompting for a password. The user thinks it happened around the time that his certificate was renewed. I issued a new certificate for the user, but still no password prompt. What do I need to do to get his prompt back?
Answer: Sounds like the user (or someone) accidentally cleared the password from his Notes ID. Since he has no password at all, he is not being prompted for one. I would try: (R5) File/Tools/User ID/Set Password; or (R6) File/Security/User Security/Change Password.
Force users to change passwords
Question 8: As an administrator, I would like to force Notes users to change their password within the first few days or on the first use of the ID (like Novell and Microsoft do when you sign on to the network for the first time). Is there any way to do this?
Answer: There is no way to force users to change their initial Notes ID password. But here's a trick: Make each initial password a unique string that is so hard to type users will want to change it. An example is 5Ad*vG+4eF1$. If you had this password, you would change it as fast as you could. There is a tool on Chuck Connell's download page to help you quickly create these passwords.
Keep default password away from user
Question 9: After creating a user notes.id and generating a default password for this ID, is there a way to change this default password before sending it to the user? I want to keep this default password away from the user.
Answer: The only way would be to switch to that ID and then change the password yourself. Then send that version to the user.
Can I prevent someone from using a copy of a cert ID with a different password?
Question 10: Regarding the cert ID: I can change the password and even the public key via the Admin client using ID properties, but how can I prevent someone from using a copy of a cert ID with a different password? You don't have any Person document with which you can make the link and check the options "Check password...." I was thinking about the "Check public key," but in this case I need to generate another public key for the certifier ID with other possible problems, and I must implement the solution for the whole company. Is there a simpler solution?
Answer: The obvious answer is that all organizations should protect their certifier IDs very carefully. Admittedly, this is easier said than done. It is nearly impossible to prevent a trusted system administrator from taking home a copy of the cert ID on a diskette. However, Domino has two features which, taken together, protect you.
- The "check public keys" option on the server prevents someone from creating a bogus account for a real user. If someone uses a stolen cert id to make a new ID with the same name as an existing user, that new ID will have a different public key than the real user. So the bogus ID file will not work.
- The server option to "only allow users listed in the NAB" prevents someone from creating new (unauthorized) user ID files offline. If such as ID is created, it will be signed with the real organization certifier, but it won't be listed in the NAB, so it will not have server access.