Managing Lotus Notes ID file passwords presents some unique and complex challenges. This document provides an overview of these challenges, and the various ways in which they can be addressed using Hitachi ID Password Manager.
Further information can be found in the full "Password Manager Installation and Configuration Guide."
There are two challenges to centrally managing Lotus Notes ID files:
It is impossible to administratively reset passwords on Lotus Notes ID files. The ID files are encrypted using each user's current password and must be decrypted using the same current password before they can be re-encrypted using a new password.
An administrative password reset is defined as a password change made using an administrative ID and password and without the user's current password. From this definition, it is clear that administrative password resets are just not possible for Lotus Notes ID files.
Note that it is possible to change an ID file password -- just not administratively reset one.
Lotus Notes ID files may be physically stored anywhere -- on a user's PC (typically in C:\Notes\Data), on a network share, or even on removable media. Many copies of the same ID file may have to be managed. For example, A manager may have copies of the same ID file on her primary PC, her notebook, her assistant's PC, her home PC and on a flash memory device.
IBM/Lotus does not provide any mechanism for gathering or distributing ID files in Lotus Notes versions prior to 8.5.Consequently, there is no simple, standard mechanism for a server such as Password Manager to deliver updated ID files back to their user/owners unless all user PCs have Notes 8.5 or later and all Notes servers run Notes 8.5 or later.
Lotus Notes is probably the most widely deployed PKI system today, despite pre-dating standards such as X.509. The challenges described above apply not only to Lotus Notes, but also to most public key infrastructure (PKI) systems, since they generally maintain encrypted certificate files on user PCs.
Many organizations address these two challenges by storing copies of each user's Lotus Notes ID file in a central repository. This may be a file share, a Lotus Notes NSF database or some other storage system. Normally, a matching password is either stored in the repository alongside each ID file or else ID files are issued (and stored) with an implicit password, such as the user's login ID or a fixed, well-known string.
Starting with version 8.5 of Lotus Notes (all clients and servers must run this), there is a native repository built into Lotus Notes itself.
Using the central repository (built-in or custom-built), administrative password resets are simulated by extracting an old copy of the user's ID file from the repository, opening it with the old password, also from the repository, making a non-administrative password change and delivering the modified ID to the user. Different implementations vary in regards to how the repository is managed and how ID files are delivered to users.
Since users may change the contents of their ID file, the copy of their ID file in the repository may become obsolete. This leads to the third major challenge with managing Lotus Notes ID files:
The content of a user's ID file may change over time. Users may attach new encryption keys or cross-certifications to their ID files. Users change names (for example, when they marry). In each of these cases, the ID file must change to match.
This is a problem in an environment where password resets on ID files are simulated using a repository of old ID files, other than the repository built into Notes 8.5 (or later) servers, when used in conjunction with Notes 8.5 (or later) clients. The ID files stored in the repository may be quite old and not contain changes that happened since enrollment, such as cross certifications and name changes. If a user's password is "reset," -- i.e., the old ID file retrieved from the repository, changed and delivered to the user -- such changes will be lost.
One solution offered by IBM/Lotus to resolve problems that arise when users forget their own passwords is key escrow. Key escrow was introduced with Lotus Notes R5, and works as follows:
ID file recovery does work, but has serious operational problems:
Unregistered users will not be supported by the process. Users must take several steps to register, and in some cases even users who wish to cooperate (by accepting the recovery message and enabling harvesting) will fail to perform these steps correctly.