What universally is the No. 1 call to the help desk? Everywhere I've ever been it is password recovery. The architecture that you put in place to handle it will always have two opposite priorities that you will need to balance: to maintain the highest level of security possible and to make it convenient for both the user and the help desk.
In R4, Lotus introduced the Escrow Agent. This was a step in the right direction but it had one fatal flaw. It meant that ALL of your IDs and passwords were stored in the same place. So any admin who had access to the repository had easy access to everyone's IDs.
The next step for Lotus was the introduction of "Password Recovery," in which copies of each user's ID are sent to a central repository at registration without a password. They have special information encoded in them that allows them to be unlocked, but the passwords have to be changed one at a time -- at a pretty high level of inconvenience. Any administrators can unlock an ID they need, but they can't easily unlock ALL the IDs. In addition, when implemented with password checking on the server, it is difficult for a help desk agent to get around the controls. (In a future tip, I'll document the architecture for setting up a secure ID distribution system for a level one help desk to use.)
Alas, the process for having the IDs sent to the repository is a bit finicky, and even small misconfigurations on the registration box will cause copies of the IDs not to be sent to the ID repository as defined in the certificate's recovery info. Here are a few valuable tricks that I have used to collect them.
Getting the user to accept recovery info after the fact:
- On a regular basis, I generate a fresh set of recovery extract files from my certificates (*.idb). This is done by selecting "Edit Recovery Information" and selecting "Export" from the dialog. I have all of these extracts sent to myself.
- Then, I run an agent that reconciles my names.nsf against my repository of ID files to establish whose IDs I need to collect.
- I can then send copies of the *.idb files to the users whose IDs I am missing with instructions for selecting "Actions-Accept Recovery Info" from the menu with the memo open. In ND6, all they need to do is put in their passwords, and the IDs will be sent back to the repository. In R5, it's pretty simple too; there are just a few more steps, but they're easy.
- You can actually set up a scheduled agent that keeps sending them these extract files until their IDs appear in the recovery database.
If the users ...
To continue reading for free, register below or login
To read more you must become a member of SearchDomino.com
won't or can't accept the recovery, but you do have a copy of their IDs somewhere:
- I had a situation where I had a set of about 300 IDs that I had the files for, but weren't in the recovery database. Unfortunately, I didn't know if the IDs themselves had recovery information in them. I certainly couldn't go through each one by hand, so I needed an automated way. What I discovered is that if you look at the ID file as a text file, the names of the recovery agents are in there in CLEAR TEXT! (Of course they are. The reason you need them is because you don't know the password, which is the thing that scrambles up the ID in the first place) I just wrote a quick agent that goes through a bunch of IDs and tells me which have recovery and which don't. See script below.
Do you have comments on this tip? Let us know.
Please let others know how useful it is via the rating scale below. Do you have a useful Notes/Domino tip or code to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.
