SECURITY
How IDs are uploaded to a vault initially
A user ID can be uploaded to a vault if a parent certifier of the user ID has issued a Vault Trust Certificate certifying its trust of the vault and if the associated user's effective policy has a Security Settings document that specifies the vault name.
If these conditions are met for a new user being registered, the process of user registration uploads the ID to the vault. IBM® Lotus® Notes® setup copies the ID file to the Notes client, as it does for non-vaulted users, that is the first time the user authenticates with the home server.
Note If you do not want to keep copies of user IDs in the Domino Directory, clear the Advanced - ID File registration setting "Location for storing user ID - In Domino Directory," which is selected by default.
If the above conditions are met for an existing user, a copy of the user's ID is uploaded from the Notes client to the vault automatically. For more information on the timing of this operation, see "How copies of IDs on Notes clients are kept synchronized with the vault copies."
How copies of IDs on Notes clients are kept synchronized with the vault copies
When a user changes the ID on a Notes client, for example changes the password or adds an Internet certificate, the change needs to be pushed to the ID copy in the vault. When a change is made to an ID copy in a vault, for example the password is reset, the change needs to be pushed to the Notes client.
To synchronize a local copy of an ID with the vault copy, a client asks its home server for a list of servers that have a replica of the vault. If the home server is unavailable or does not run release 8.5 or higher, the client searches for a server in the home server cluster to provide the list. A server returns the list in random order to load balance synchronization among vault servers. The client tries each vault server in the returned list until one can satisfy its request. For better performance, the client caches the location of the first vault server that responds. This cache is cleared periodically to ensure that load balancing is maintained.
When a user changes the ID file on a client, switches IDs, or provides a new password after a password reset, the client attempts synchronization immediately. Otherwise, sychronization occurs as follows:
When the password on a user ID is changed anywhere (in the vault or on a client), the user can provide the new password from any client as long as the client can connect to the network to synchronize with the vault. The user does not have to change the password on each client workstation copy or copy the ID file from one client workstation to another. If a client does not have network connectivity, a user can continue to use the old password until a connection becomes available.
How ID recovery works for an ID in a vault
If the ID file on a user's computer is deleted, a copy of the ID is downloaded to the Notes client from the vault. This recovery occurs the next time the user attempts to access the ID file through Notes when the client is connected to the network.
How shared-login-enabled IDs work with a vault
Shared-login-enabled user IDs can be stored in a vault. In this case, the steps to recover the ID or to respond to a stolen ID are different than for non-shared-login-enabled IDs.
ID file recovery If a shared-login-enabled ID is deleted from user's computer or its local file name is changed, the Notes password must be reset on the copy of the ID in the vault. After the reset, the following actions occur:
1. A user is prompted for the new password when next starting Notes.
2. After the user provides the new password, a copy of the ID file is downloaded to the client from the vault.
3. After the download, if the user policy requires the use of shared login, the local ID is re-enabled for shared login and the user is no longer prompted for the password. If the user policy makes the use of shared login optional, the user must re-enable the feature through the User Security window.
Response to a stolen ID If you suspect that a non-shared-login-enabled ID is stolen, the correct response is to reset the password on the ID, roll over the keys on the ID, and ensure that server key checking is enabled. These steps help prevent unauthorized people from using the stolen ID because they won't know the new password required to obtain the new keys from the ID copy in the vault.
A shared-login-enabled ID is different in that it is protected with a secret in the local ID file rather than with a Notes password that the vault understands. The ID can be used only on the computer on which it was shared-login enabled. If a computer with a shared-login-enabled ID is stolen, perform these steps: disable shared login in the user policy, force the policy to replicate to all vault servers, respond as you would for a non-shared-login-enabled ID (reset the password, roll over the keys, enable server key checking), and afterwards re-enable shared login in the user policy.
How ID renaming and key rollover work with a vault
A user with a vaulted ID who requests a name change through the User Security window is not given the option to approve the change. The option to "Ask your approval before accepting name changes" is unavailable, and the change is always made on the client ID copy automatically during client-vault synchronization when the name change is detected on the server.
A user with a vaulted ID cannot request a key rollover through the User Security window; only an administrator can initiate key rollover through policy configuration. The key rollover on the client ID copy happens automatically during client-vault synchronization when the key rollover is detected on the server; the user is never prompted to accept the new keys.
Note If key rollover of IDs is in process, do not enable use of a vault until the key rollover is complete. In addition, when a vault is in use, always register new users with ID key sizes that conform to their effective policies.
Related topics