After its
phase 1 deployment of the Notes ID vault, IBM began the second phase by setting up a Notes ID vault in two more production domains. This article describes the ID vault configurations in each domain (referred to as Domains A and B), and the experiences of the domain administrators.
Domain A ID vault deployment
An ID vault was deployed in Domain A in October 2008. As of this writing, it has about 300 registered users, about a third of whom have upgraded to Release 8.5 and have IDs in the vault.
The ID vault in Domain A is configured as follows:
- There are three replicas of the ID vault that were created on three existing servers that happened to be used for domain indexing. There is no relationship between the ID vault and domain indexing.
- There is one Vault Trust Certificate, issued from the /IBM organization certifier.
- Users are assigned to the vault through a group dynamic policy that leverages the auto-populated home server group feature in Release 8.5 (more on this below).
- The Security Settings document assigned to this policy specifies the following forgotten password help text: "Please Contact to have your password reset." For other options, the default settings are used, ie "Allow automatic downloads = Yes" and "Enforce password change after password has been reset=Yes."
- The vault administrators are the domain administrators and one ID vault developer.
- Password Reset Certificates are issued from the /IBM organization certifier to:
- The ID used for specifically for domain administration tasks
- A domino administrator for the domain.
- Several ID vault developers
- A server in the domain that will run a self-service password reset application (planned for the future.)
The domain server topology with respect to the ID vault looks like this (one of four mail server clusters is shown):
Domain A: How the ID vault is helping users and administrators
The domain administrator responsible for ID management says the ID vault is definitely one of her favorite Release 8.5 features. She loves the ease and speed with which users recover from forgotten passwords or corrupted/missing IDs. To date, five vaulted users have forgotten their passwords -- most of the users changed passwords and then forgot what they changed them to! In the past, recovering required the administrator to contact the IBM certifier owner who would then re-register the user, a process that could put users out-of-commission for 24-48 hours. Since the ID vault deployment, a user on a Release 8.5 client simply contacts the domain administrator, who uses the "Reset Password" tool in the Domino Administrator client to change the password of the ID copy in the vault. The user restarts the Notes client and the new password is in effect.
Important: This phase of the ID vault deployment uncovered an issue with password changes when password checking is enabled. If you use password checking, you should request a hotfix that is being provided to address the issue.
A missing ID file and a corrupted ID file have been recovered from the ID vault. In the missing ID file case, a user in the domain shipped off his laptop for repairs, and when it was returned he discovered that the hard drive had been reconfigured and the ID file was gone. The administrator, who at that point was new to ID management in a vaulted environment, responded by using the "Extract ID From Vault" tool in the Domino Administrator to get a copy of the ID file, which she then gave to the user. Although this method worked, the administrator now knows that the recommended recovery method is even simpler: without any ID on the client, the user provides the password when prompted, and a new copy of the ID is downloaded from the vault. Later, when a user reported a corrupted ID file, the administrator explained that the user could simply rename or delete the local corrupted copy to get a new copy downloaded from the vault.
Domain A: A closer look at the ID vault policy assignment
Users are assigned to the ID vault through a dynamic group policy that takes advantage of the auto-populated home server groups feature. Users automatically become members of a home server group if their home servers are selected in the group document. So administrators do not have to add user members manually. Also, the membership list is dynamic-- if a user moves from one home server to another, the group membership is updated automatically.
The domain administrators also like the dynamic group policy because it allows them to set an order of precedence that controls what priority the policy has relative to other policies when multiple policies apply to a user.
Here is how one of the domain administrators set up the groups and then assigned them to a dynamic ID vault policy:
1. For each home server in the domain, the administrator created a group document in which he selected "Auto-populate method: Home Server" and specified the home server name; any user with the specified home server was automatically added as a member of the group. Although he could have created one group that encompassed multiple home servers, he used this approach to have more flexibility when using the groups for other purposes.
2. For each cluster of mail servers in the domain, the administrator created a group whose members were the auto-populated groups for the home servers in that cluster.
3. He assigned each group created in Step 2 to the dynamic policy used for the ID vault:
Domain B ID vault deployment
There are about 2000 users registered in Domain B, and so far about 20% of them have vaulted IDs.
Here is a summary of the Domain B ID vault configuration:
- There are two replicas of the ID vault: one replica on a server that functions as the hub mail server/Domino Directory administration server, and another replica on an existing application server that runs hundreds of applications. Because Notes users do not have access to the hub/administration server, their Notes clients interact only with the ID vault replica on the application server.
- There is one Vault Trust Certificate, issued from the /IBM organization certifier.
- Users are assigned to the vault through an explicit policy that is named in each Person document.
- The Security Settings document assigned to this policy specifies the following forgotten password help text: "Welcome to the Notes ID Vault. Please log a ticket with the queue if you have any issues using it.." For other options, the default settings are used, ie "Allow automatic downloads = Yes" and "Enforce password change after password has been reset=Yes."
- The domain administrators are also the vault administrators.
- Password Reset Certificates are issued from the /IBM organization certifier to:
- An ID used for specifically for domain administration tasks
- The domain administrators/vault administrators
- A server in the domain that will run a self-service password reset application (planned for the future.)
The domain server topology with respect to the ID vault looks like this (one of five mail server clusters is shown):
Domain B: Administrator experiences and lessons learned
An administrator in the domain reports that the ID vault was easy to configure. One "gotcha" was that initially he didn't understand that to use the ID Vaults - Manage tool he had to first expand the Security - ID Vaults view in the Domino Directory and select the ID vault document.
No one in the domain has forgotten a password since deployment of the ID vault in October 2008, so there hasn't been an opportunity to try a password reset. Users haven't complained of any problems, even ones that use multiple Notes clients -- most are probably unaware that their IDs are vaulted!
The administrator is planning to customize the sample self-service password rest application provided with Domino 8.5 and deploy it in the domain so that users can reset their own passwords. He is also considering changing the policy configuration from explicit assignment through Person documents to dynamic policy assignment through auto-populated groups.