ID recovery

Use of the ID vault for ID recovery is strongly recommended. However, the ID recovery feature described in this topic is still supported.

About this task

If you do not use an ID vault, to recover from loss of, or damage to, an ID file, recommend to your users that they keep backup copies of their ID files in a secure place -- for example, on a disk stored in a locked area. Losing or damaging an ID file or forgetting a password has serious consequences. Without an ID, users cannot access servers or read messages and other data that they encrypted with the lost ID. To prevent problems that occur when users lose or damage ID files or forget passwords, set up Domino® to recover ID files.

Note: You can only use the ID recovery process to recover user ID files. You cannot recover certifier ID files.

Ideally, you should designate several administrators who will act as a group to recover IDs and passwords. Although you can designate a single administrator to manage ID recovery, you should consider having two or more administrators work together to recover ID files. Designating a group of administrators helps to prevent a breach of security by one administrator who has access to all ID files. When you designate a group of administrators, you can specify that only a subset of them be present during the actual ID recovery. For example, if you designate five administrators for ID recovery but require only three administrators to unlock the ID file, any three of the five can unlock the ID file. Designating a group of administrators and requiring only a subset also prevents problems that occur if one administrator is unavailable or leaves the company.

ID recovery administrators require access to the Domino® Administrator, explicit Reader access to the database in which the backup ID files are stored, and access to the certifier ID file or password. They do not have to be Domino® administrators.

Before you can recover ID files, an administrator who has access to the certifier ID file must specify recovery information, and the ID files themselves must be made recoverable. There are three ways to do this:

  • At registration, administrators create the ID file with a certifier ID that contains recovery information.
  • Administrators export recovery information from the certifier ID file and have the user accept it.
  • Administrators change recovery information using a Domino® Administrator client. Subsequently, recovery information is added automatically to users Notes® IDs when users authenticate to their home server.
Note:

Domino® stores ID recovery information in the certifier ID file. The information stored includes the names of administrators who are allowed to recover IDs, the address of the mail or mail-in database where users send an encrypted backup copy of their ID files, and the number of administrators required to unlock an ID file. The mail or mail-in database contains documents that store attachments of the encrypted backup ID files. These files are encrypted using a random key and cannot be used with Notes® until they are recovered.

An encrypted backup copy of the ID file is required to recover a lost or corrupted ID file. Recovering an ID file for which the password has been forgotten is a bit easier. If the original ID file contains recovery information, administrators can recover the ID file, even if an encrypted backup ID file doesn't exist.

You can set up ID recovery for user IDs at any time. If you do so before you register users, ID recovery information is automatically added to user IDs the first time that users authenticate with their home servers. 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.

CAUTION: If your users will be enabling Smartcards to use with their Notes® IDs, it is extremely important to set up ID recovery information for these IDs before any Internet keys are pushed onto the Smartcard. Otherwise, the ID file recovery process will not be able to restore those keys. Additionally, acquiring recovery information, through any means, makes any Internet keys that had been previously pushed to the Smartcard unrecoverable.

How ID recovery works

About this task

For each administrator, the user's ID file contains a recovery password that is randomly generated and encrypted with the administrator's public key. The password is unique for each administrator and user. For example, administrator Randi Bowker has a unique recovery password for user Alan Jones, and that password is stored in Alan's ID file. Administrator Randi Bowker has a unique recovery password for user Susan Salani, and that password is stored in Susan's ID file.

You can select the number of characters, or password length, for recovery passwords, which helps determine password strength, or likelihood to be compromised. A password length that is less than 16 is calculated using both alphanumeric characters and hexadecimals. Sixteen-character length passwords are generated using hexadecimals only. While password strength is important, as a strong password is less likely to be compromised, so is usability. A long and complex password can be difficult to use, so administrators also have the ability to choose a shorter password length.

In addition, administrators can now configure a custom message to help walk users through ID recovery.

To recover an ID, users and administrators do the following:

Procedure

  1. A user contacts each designated administrator to obtain the administrator's recovery password.
  2. The administrator obtains the recovery password by decrypting the recovery password stored in the user's ID file using the administrator's private key.
  3. The administrator then gives the recovery password to the user.
  4. The user repeats Steps 1 through 3 until the minimum number of administrators to unlock the ID file is reached.
  5. After the file is unlocked, the user must enter a new password to secure the ID file.

Results

When users acquire a new public key, accept a name change, or accept or create a document encryption key, Domino® automatically sends updated encrypted backup ID files to the centralized database. In the case of a server-based certificate authority , the recovery database will be updated once the user has connected to the server. Recertifying a user does not generate an encrypted copy of the ID file to be sent to the recovery database, as a user's Person Document already contains the updated public key.

If a user has been renamed by or moved to a different certifier that contains recovery information that is older than that of the user's previous certifier, the new certifier's recovery information will not be accepted into the user's ID file. Before using the new certifier, its recovery information must be updated so that it is more recent than the previous certifier's recovery information. To do this, the administrator should modify the new certifier's recovery information in some way and save it. This updates the recovery information for that certifer with a new timestamp, and ensures that users who are subsequently renamed with or moved to the updated certifier will have the correct recovery information propogated to their user IDs. The administrator can then undo the change, if desired.

To help prevent unauthorized users from recovering IDs without the authorized user's knowledge, make sure that password verification is enabled for users and servers. If password verification is enabled, the authorized user is aware of the change because the user cannot access servers using the legitimate ID. When the unauthorized user recovered the ID file, that user was forced to make a password change.

As an extra precaution, after recovering IDs, ask users to re-accept the recovery information and then change the public key on their ID files. Re-accepting recovery information happens automatically when the user accesses a database on the home server. This changes the recovery password information in the ID file. Changing the public key changes the public and private keys stored in the ID file.

ID recovery logging

About this task

Important information about client ID recovery activities is automatically logged to the local log.nsf file so that this information is available to administrators for troubleshooting purposes.

The following ID recovery information will be logged locally.

  • Date and time when recovery information is accepted into the ID file.
  • Instances when recovery information is rejected or fails to be accepted in the ID file.
  • Events that require a new backup to be mailed to the ID recovery database.
  • Emailing the recovery ID to the recovery database (successes and failures)