Password Recovery

HCL Domino Domino Forum
1

Setting up the password recovery seems to be a puzzling thing to set up. At least I’m having some intriguing occurances. I’ve followed word for word what was written in Admin Help, a few books I have, a workbook from a Lotus Notes training course I took and I have mixed success with password recovery.

First, in all but one of the user’s I did testing on, I had to copy the backup id that was sent from the user’s “accepted recovery information” email, into the user’s local data directory in order for password recovery to be possible.

I did not see anywhere written that I would have to do this. It did, in fact work without copying the backup id locally with one test user.

Second “problem” I have is that I went into the database housing all of the backup ids and noticed that there is 30 more than I set up in there. No one accepted recovery information, because I didn’t send it to anyone. Nowhere did I see anything written saying that this task would be automated once a user is already registered. In fact, as I read it, it was something I had to do manually. Not a problem, a blessing really. But I am curious where they came from(I’ve checked log.nsf - nothing mentioned under misc events)and how/why they came to be.

An even more interesting note on the mysteriously created backup id files is that none of them have either our standard backup password nor the user’s password associated with them, nor is the password field blank.

Can anyone explain the “first” and “second” issue I’m having to me? Did I do something wrong/miss something?

Any input would be greatly appreciated,

Brian

2

Subject: ID File Recovery

I’ll address your questions in reverse order…

An even more interesting note on the mysteriously created backup id files is that none of them have either our standard backup password nor the user’s password associated with them, nor is the password field blank.

Encrypted backups created by ID File Recovery don’t store the user’s password, nor can they be unlocked by any password. The only way to unlock and use an encrypted backup ID is to recover the ID with ID File Recovery.

Second “problem” I have is that I went into the database housing all of the backup ids and noticed that there is 30 more than I set up in there. No one accepted recovery information, because I didn’t send it to anyone.

Due to substantial demand by administrators, the user intervention was mostly removed from ID File Recovery in ND6. Users will no longer be prompted to send off (and allowed to cancel out of sending) encrypted backups to the backup database. Additionally, when using the new CA process, recovery information will be migrated from the certifier ID into the directory, and downloaded automatically by users who connect to their home servers.

First, in all but one of the user’s I did testing on, I had to copy the backup id that was sent from the user’s “accepted recovery information” email, into the user’s local data directory in order for password recovery to be possible.

I did not see anywhere written that I would have to do this. It did, in fact work without copying the backup id locally with one test user.

I’m not sure what could be causing that. The local copy of the ID file can be recovered in the same fashion as the encrypted backup. However, the “Recover ID File” menu option was removed from ND6, so now in order to access the Recover ID dialog, you need to cancel out of an initial password prompt and select the “Recover ID file” option, which should let you browse to the ID file that you want to recover.

dave

3

Subject: Password Recovery

We have always done that - replacing the id file in the user’s data directory with one we detached from the recovery mail-in database. I’m not sure why… looking at help it doesn’t seem like you need to.

And, to address your second point, that is in the Admin Help:

<<If you set up ID recovery information after you have registered Notes users, recovery information is automatically added to the user IDs the next time users authenticate with their home servers.>>

Sounds like all of your users’ id files should have been sent to the recovery database automatically. The backup ids would never and should never have any recognizable password associated with them. They are encrypted and could not be used without going through the extract recovery password process.