IBM has begun its internal deployment of the Notes ID vault, the new Notes ID file recovery and management feature in Lotus Notes and Domino 8.5. This article provides a window on phase 1 of our ID vault deployment during which we deployed the ID vault in one of the domains used by the Lotus development team. For more information on the Notes ID vault, see the article
ID vault overview FAQ and also the
ID vault documentation in the Lotus Domino 8 Information Center.
Note We have since deployed the ID vault in two additional domains. See the article
IBM's phase 2 deployment of the Notes ID vault for more information.
The first phase of the Notes ID vault deployment at IBM began this past summer when we had about wrapped up our ID vault feature development. Our goal for this phase was to expand our experience with the ID vault beyond our test labs and exercise vault features in a production environment. Of course, another important goal was to reap the benefits of the feature! In this phase we deployed the vault in the production domain used by Lotus developers. We began by uploading the IDs of 13 members of the ID vault development team who could test vault functionality easily, and then expanded the number ID vault users over time.
Phase 1 planning
During phase 1 we made the following initial ID vault configuration decisions:
- Deploy in the domain in which ID vault developers' home servers reside.
- Deploy vault replicas on existing, clustered, Domino mail servers running on both Windows and UNIX operating systems to exercise ID vault operation on multiple platforms.
- Issue vault trust from the IBM OU certifier under which the ID vault developers (and other Lotus developers) are certified.
- Use an explicit policy to upload the IDs of 13 ID vault development team members to the vault.
- Designate two of the domain administrators and four members of the ID vault development team as vault administrators.
- Give password reset authority to the two domain administrators and one ID vault developer who are also vault administrators.
- Provide the following forgotten password help text: "Please contact to have your password reset."
- When a password is reset in the vault, require the ID owner to change the password again.
Note It's important to note that some of these configuration decisions were made for the purpose of load testing and are not recommended for a customer environment. Examples: 1) we set up many more vault replicas than the number of users warranted; 2) in a typical environment, vault administrators are not likely to have password reset authority.
Here is an illustration of our initial ID vault deployment in the domain:
Phase 1 configuration steps
To set up an ID vault in the development domain, we performed the following steps:
Step 1. A server administrator in the domain added the names of four ID vault developers to the "Domain Administrators" group, a group that has "Administrators" access to the servers in the domain. "Administrators" access (specified in the Administrators field in the Security tab of a Server document) allowed the ID vault developers to create the ID vault and be vault administrators who can monitor and troubleshoot vault operations. In a typical customer environment, vault administrators will likely be a subset of existing server administrators.
Step 2. The lead ID vault developer (now in the "Domain Administrators" group) clicked the
Configuration tab of the Domino Administrator client and then clicked
Tools - ID Vaults - Create to create the first ID vault replica on a clustered mail server in the domain. During this step he also designated himself, two domain administrators, and the three other ID vault developers involved with ID vault deployment who had been added to the "Domain Administrators" group, as vault administrators.
- He did not create Vault Trust Certificates or Password Reset Certificates because he still needed to obtain the developer OU certifier ID file.
- He did not use the tool to set up the ID vault policy that assigned IDs to the vault; this he wanted to do manually because of a pre-existing, complex domain policy configuration. Note that this complex policy configuration will not be typical in customer environments and is due to the use of the domain to exercise software that is under development.
Here are the steps he completed after clicking
Tools - ID Vaults - Create:
Note: Here he skipped the configuration steps that he planned to do later by clicking
Next until he saw the following pane.
Step 3 The lead ID vault developer obtained the certifier ID file for the developer OU. He then clicked the
Configuration tab in the Domino Administrator client, clicked the
Security - ID Vaults view, selected the vault document, and clicked
Tools - ID Vaults - Manage to complete the steps to issue a Vault Trust Certificate from the developer OU certifier to the vault and to issue a Password Reset Certificate from the developer OU certifier to each vault administrator. The Vault Trust Certificate authorized IDs under the developer OU certifier to be stored in the vault; the Password Reset Certificates authorized the vault administrators to reset the passwords of the IDs in the vault.
Here are the steps he completed in the
ID Vaults - Manage tool:
In the following pane he specified the development OU under which were registered the ID vault developers who would test the ID vault functionality.
In the following pane he specified the people authorized to reset the passwords of IDs under the development OU.
To create the certificates, in a subsequent pane the lead ID vault developer was prompted to select the OU certifier ID file. He was then prompted for the password. Since for security reasons he hadn't been given the password, he allowed the owner of the certifier ID file to access his computer remotely so that the certifier owner could enter the password.
Step 4
The lead ID vault developer sent a copy of the vault ID file to one of the domain administrators to enable her to create vault replicas.
Step 5
The domain administrator created a replica of the vault on another server in the same cluster as the first vault server. She clicked the
Configuration tab in the Domino Administrator client, clicked the
Security - ID Vaults view, selected the vault document, and clicked
Tools - ID Vaults - Manage. She completed these steps in the ID Vaults - Manage tool:
She specified a second vault replica server (the bottom in the list below)
Step 6
The lead ID vault developer created a new, explicit policy for the vault.
First, he created a Security Settings document named "Vault settings" that specified the vault name and forgotten password text in the
ID Vault tab. He kept the default ID vault settings, "Enforce password change after password has been reset = Yes" and "Allow automatic ID downloads = Yes."
The
Basics tab:
The
ID Vault tab:
He created an explicit policy, assigned just himself to it (so he could test the ID upload to the vault before adding other developer names), and then added the vault security settings to the policy document.
Step 7
The next day, the lead ID vault developer verified that his ID had been uploaded to the vault. (
Note: to prevent a heavy server load if an ID vault is first enabled in an environment with many users, timing of the initial ID uploads to the vault is staggered but usually occur within 8 hours). He opened a vault server in the Domino Administrator, clicked the
Files tab, opened the IBM_ID_Vault folder, opened the vault database, and verified that there was a document with his ID attached.
Step 8
He added the names of the remaining 12 team members participating in the deployment to the vault policy assignment.
Step 9
A domain administrator used the
ID Vaults - Manage tool make four additional vault replicas.
Phase 1 Feature testing
The ID vault lead developer asked the developers whose ID had been uploaded to the vault to:
- Pretend they had forgotten their passwords and request a reset.
- Set up second client workstations and verify that copies of their IDs were downloaded to them from the vault.
- Change their passwords on their local IDs. Verify that they could use the new passwords on the workstations on which they changed them, and verify that the new passwords took effect on second workstations within a reasonable amount of time.
- Simulate missing IDs by renaming the IDs on the client workstations and then verifying that new copies were downloaded from the vault.
- Add encryption keys to their IDs. Verify that they could use the new encryption keys on the workstations used to add them, and that they could use them on second workstations within a reasonable amount of time.
- Import Internet certificates into their IDs. Verify that they could use the certificates on the workstations on which they imported them, and that they could use them on second computers within a reasonable amount of time.
He asked the vault administrators (who also had password reset authority) to:
- Reset passwords on IDs in the vault
- Extract copies of IDs from the vault, with and without the "Auditor" role in the vault database ACL. (Auditor role allows a vault administrator to extract an ID without knowing its password).
- Delete IDs from the vault
- Rename users by moving them from one hierarchy to another
- Upgrade user IDs with 630-bit keys to 1024-bit keys, and issue new 1024- bit keys to users with older 1024 bit keys
- Use the ID vault in various combinations with Notes shared login. Domino roaming, and file server roaming
- Use the ID vault with password checking/password expiration enabled.
Vault transaction monitoring
The vault administrators used the new Security Events view in the log files on the vault servers to verify that ID files were being uploaded to the vault and to check for errors. For more information on interpreting log messages, see the article
ID vault logging for 8.5 FAQ.
Phase 1 adjustments and expansion
We made the following adjustments after initial phase 1 testing:
- We used the ID Vaults - Manage tool to remove two vault replicas from the domain, to reduce the number of vault servers to be monitored.
- We increased the number of IDs uploaded to the vault by switching from the use of an explicit policy that assigned a vault to just 13 people to a dynamic home server policy that assigned the vault to people who had home servers in the domain. (We removed the 13 names from the explicit policy, created a dynamic policy and assigned it to a group of home servers, and added the vault security settings document to the new policy). As a result of this change about 15 additional IDs were uploaded to the vault. Note: IDs were uploaded only if they were registered under the developer OU certifier that had issued the Vault Trust Certificate and if they were used on a Notes 8.5 client.
- Later, we further increased the number of IDs uploaded to the vault by using the ID Vaults - Manage tool to issue a Vault Trust Certificate from the /IBM organization certifier to the vault. This allowed the IDs of 8.5 users with home servers in the domain but with the IDs registered under a different OU certifier than the developer OU to be uploaded to the vault.
- We also expanded the pilot to include two additional production domains; stay tuned for details!