A user’s hard drive crashed, so in setting her up again, I put a copy of her original ID file back in the notes/data directory. When I tried to configure her workstation, I got as far as the pw prompt. After putting it in, I got a message saying something like “Another copy of the ID file has a different password and you must change the password on this copy to match it.”
Besides the obvious problem of not being able to change the pw until you have successfully configured the workstation for the first time, there were no other ID files anywhere in the lotus directory. Yes, the user changed my default pw after I set her up last time, but again, with the original ID file in place and no other ID files around, how did this message come up, and what is one supposed to do?
I plan to just create a new ID file for her and start from scratch unless there is something more to this than an illogical burp.
Subject: RE: Different password on “another copy” of ID file
No, the Required change interval is 0. Also, I understood what you said about the ID file changing when the pw is changed - but it’s fairly common for one of my users to forget their pw, so I’ve reloaded many original ID files, and I’ve never run into this problem before. What’s different this time?
Subject: RE: Different password on “another copy” of ID file
If it should turn out to be neither password checking, nor the password digest - as suggested by Ali - I’m running out of ideas.
Still password checking - which would normally cause just that message - is a pretty good idea to protect users from stolen id files. But it doesn’t play nicely with backing up original ids.
Did you look at password recovery as offered in Notes 6 and up? Initially, it takes a bit more work to set up than to just store away the original id files. But it really pays back. The backup id is always up to date. E.g., any changes like new passwords, new public keys or additional secret keys are never lost. Furthermore, you as an administrator no longer need to know the password to any user ID (so nobody can complain that you might have abused his/her id).
Subject: RE: Different password on “another copy” of ID file
Deleting the Password Digest as suggested by Ali worked, and the problem is solved. However a bit of mystery remains, as the user’s password checking was turned off. In fact, I discovered that all of my user’s Person docs are set that way (I only handle one division).
This morning I read up on passwords and verification, and now I understand much more than yesterday - but I see that in order for pw checking to be effective, I would have to ask all users to change their pw after turning it on, and that would meet with much wailing and gnashing of teeth. So I guess I’ll leave it for now.
I wish we had password recovery, but I am just a developer, not the SA. I am allowed to do some very basic admin tasks like registering people and managing groups, but that’s it.
Thank you so much for taking the time to help me!!
Subject: RE: Different password on “another copy” of ID file
It’s interesting, that the password digest was still obeyed, even though password checking itself has not been enabled. But well, this is nothing too weired to always keep it in the back or your mind.
“… but I see that in order for pw checking to be effective, I would have to ask all users to change their pw after turning it on …”.
That’s not too much of a problem, you could enforce password expiration using a policy (pretty restrictive in as a first step and change or disable it later).
“… but I am just a developer, not the SA. I am allowed to do some very basic admin tasks …”
That however is a problem, I have to agree. I won’t make this a question, so you don’t have to answer: There should be someone with a sound Domino administrator’s background to get some basics right and look after the system at least periodically.
Subject: RE: Different password on “another copy” of ID file
It’s only a guess on my part but maybe there is a Security Policy Setting that is in effect for the user(s).
In this case, the Person Document for the user(s) would/could still indicate “Check Password = Don’t check password” while “Check password on Notes id file” is set to “Yes” (Security Settings Doc>Password Management>Password Management Basics>Password Management Options).
The end result is that the checking and, therefore, the digest will become active.
Personally, I’d never start getting fancy with password policies until I had a solid ID/Password Recovery process in place.
BTW, 8.5 promises to provide new capabilities in this arena with the introduction of the ID Vault.