ID Vault Best Practices

Agenda
Configuration Best Practices Hints and Tips Self Service Password Reset Authority Best Practices

Planning ID Vault
Youll want to have the following information available when configuring your ID Vault[s]
How many [different] ID Vaults will you need for your environment? How many replicas of a single ID Vault will you have available?
What servers will host these replicas?

Whose ID files will be stored in each vault? Who will need to Administer the ID Vault? Who will need to reset passwords for users? Will you be implementing the Self-Service password application?

How many [different] ID Vaults will you need for your environment?
ID Vaults can not [currently] span multiple Domino Domains.
A Domino Domain is defined as a group of users and servers which share a single Domino Directory. A Domino Domain is not impacted by multiple OU/Orgs or DNS Domains [aka DNS Suffixes].

Why would you have multiple Vaults in a single Domain?

Most prominent justification for multiple vaults is [network layer] geographical location of users.
The client may connect to ANY ID Vault Server. There is not currently a means to control which Vault Server [for a single ID Vault] that users will connect to. Do not assume that hosting an ID Vault on a users home server will impact which server the client will attempt to connect to when accessing the ID Vault.

How many [different] ID Vaults will you need for your environment?
Consider a company with users spread across multiple continents.
It doesnt make sense to have users in Europe/Asia accessing an ID Vault based in the US. Especially if this is a costly or unreliable link. If you have a single vault and place a replica in the US and a Replica in Europe/Asia, you cannot guarantee that the US users will be accessing the US replica of the vault. Having a multiple ID Vaults, in US and Europe and/or Asia ID allows control over what ID Vault servers clients connect to.

How many [different] ID Vaults will you need for your environment?
Within a domain, users are assigned to vaults based on Policies.
In order to have multiple vaults in a single domain, there needs to be a way to assign different users to different vaults via policies.
Well cover some strategies for this tomorrow in our policy Best Practices Discussion Bottom line, if there is not an easy way to divide users based on policies, it may not be easy to assign/maintain multiple vaults.

How many [different] ID Vaults will you need for your environment?
What can't I do with multiple ID Vaults in the same Domino Domain?
The Password Reset Authority is Cross Certified at an OU/Org layer. If a users from a single OU/Org are assigned to different ID Vaults, it is NOT possible to assign a person Password Reset Authority for one vault and not the other.
Example:
You would like your Tier 1 Help Desk to have the ability to reset passwords for users. You do not want your Tier 1 Help Desk to be able to reset passwords for Executives and Domino Administrators While it makes sense to have multiple vaults for this purpose, Password Reset Authority is NOT configured on a per vault basis. This can only be accomplished by having a separate OU/Org for Executive and/or Administrators and does not require an additional ID Vault.

How many [different] ID Vaults will you need for your environment?
Another possible justification for multiple ID Vaults in a single Domino Domain
Significant number of users in a single domain No hard stats/numbers but as Domino Administrators you know:
At a certain point, databases start taking longer to backup and run maintenance on Certain size databases/number of documents can become more susceptible to corruption and other issues. As Domino Administrators, you should be familiar with these types of limits relative to your own environments.

My own personal experience as FSS, customers with 30-45K users have successfully enabled ID Vault with a single instance [multiple replicas] of an ID Vault.
This is only a considerable factor if you have around or more than this number of users. Not specific to ID Vault, just overall factors such as Database size, number of documents etc.

How many replicas of a single ID Vault will you have available?

We discussed previously that it is not possible to control which replica server a client may go to for ID Vault synching/downloading. With that in mind, what is the benefit of multiple replicas of ID Vault?
Failover if primary is down Disaster Recovery

Determine your companys worst-case scenario.

If:
Password changes are infrequent [every 90 days or more] There are not a significant number of roaming users sitting at new machines often [where ID Vault is used to roam the ID file] There are not a lot of new user setups occurring on a frequent basis

Your worst-case scenario if ID Vault were unavailable is that a password change may not get picked up by a client.

How many replicas of a single ID Vault will you have available?

Determine your companys worst-case scenario.
If:
Password changes are infrequent [every 90 days or more] There are not a significant number of roaming users sitting at new machines often [where ID Vault is used to roam the ID file] There are not a lot of new user setups occurring on a frequent basis You have deployed roaming users [using the ID Vault to roam the ID file] Users are sitting at new clients [or the cleanup option is enabled]

On the other hand, if:

Each company needs to evaluate their own worst-case scenario For most environments, 3 Vault Replica servers should be sufficient.
Primary, Backup, Disaster Recovery

An ID vault outage may mean several users being unable to login/access Lotus Notes

What servers should be ID Vault Replica Servers?

Keep the following in mind when planning for ID Vault Replica Servers:
Minimize [network] geographical distribution so servers are easily [and quickly] accessible by all users. Network Accessibility to all servers Security Best Practices
An ID Vault CAN reside and function on a server for which users do not have Server Access permission. Back-end servers such as an administration server or hub server which users can not access directly [due to Server Access controls], make good candidates for ID Vault Replica Servers.

What servers should be ID Vault Replica Servers?

Consider using Clustered Servers
It is not a requirement for ID Vault Replica servers to be in a cluster HOWEVER the ID Vaults need to replicate. Connection documents need to be properly configured to ensure the vaults can cluster replicate. Make sure you have a good understanding of how replication works. Adding the ID Vault to an existing connection document set to replicate every 5 minutes DOES NOT necessarily mean that replication will occur every 5 minutes If clustering will be used, be sure cluster replication is not backed up.
It is a good idea to have scheduled backup connection document utilizing scheduled replication in case there are issues with cluster replication or the cluster replication port.

What servers should be ID Vault Replica Servers?

ID Vault will not create/generate the amount of traffic or workload where dedicated servers are available. If your mail servers are at their maximum capacity, or currently having issues with cluster replication backing up, you may want to consider not using primary home/mail servers. If not using clustering, schedule replication will need to occur on a frequent basis, which needs to be taken into account. There is no advantage [at this time] to using a home/mail server over another server as the ID Vault server.
As FSS, I usually recommend a server like the Admin Server or other back-end server which users do not have direct access to.
This provides additional security for the ID Vault Database These type of back-end servers tend to be less utilized than mail/home servers.

Dont Do That ID Vault Replica Servers

Some customers have setup every home server as a vault replica server for a single ID Vault.
This is OK if you have a [very] small handful of home [mail] servers.
If you are here as an AVP customer, you are probably NOT in that small handful.

There are several issues with this type of configuration.

Dont Do That ID Vault Replica Servers

There are several issues with this type of configuration.
Think back to how we can not control what server the client may access a vault on. A user changes their password on client A, which synchs with a replica ID Vault on Server 1. That users goes to client B which attempts to access a replica ID Vault on Server 2.
There is NO association with a Vault Replica server and a users ID Vault. Therefore trying to load balance ID Vault functionality like this will not yield the expected results.

Can you assure that the replicas on Server 1 and Server 2 are consistent and have replicated between the user moving machines ? Can you configure this type of replication for all of the home servers in your environment. Some customers Ive visited have had difficulties keeping their names.nsf and admin4.nsf [and other databases like events4.nsf] replicating frequently and consistently in their environments.
Imagine having a 5 minute threshold to keeping every replica of ID Vault in synch across all of your servers. This can get quite messy when more than 3-4 [replica] servers are involved and they may not all be in the same cluster.

Dont Do That

Whose ID files will be stored in each vault?

ID Vault can be a bit confusing, especially when you have multiple OU/Orgs in your environment. During the ID Vault Setup, youll be asked several similar questions regarding OU/Orgs and the Vault

In order to have their ID Vault, a user needs to meet 2 criteria:

A users ID File has to be included in an OU/Org which is ALLOWED [cross certified] with an ID Vault The ID Vault needs to included in a policy which is assigned to that user.

It may be the case that an OU/Org level policy is being used, in which all users of a specific OU/Org would always meet both criteria, however it does not have to work out that way.

Whose ID files will be stored in each vault?

During the ID Vault Setup, you first are asked what OU/Orgs should be stored in the ID Vault you are configuring.
This is ONLY a listing of what OU/Orgs might possibly ever exist in the Vault.
A cross Certificate between the vault and the OU/Org you select here will be created.
Without this Cross-Certificate for a users OU/Org, security settings will not allow a users ID file to be stored in that vault regardless of policy settings.

Regardless of which OU/Orgs you select, NOTHING will be vaulted until you configure a policy.
The policy DOES NOT have to be an OU/Org level policy.

Select any OU/Org which is applicable to users that will be vaulted during the Vault Setup.
This is ONLY for security purposes, think What OU/Orgs are ALLOWED to use this vault

Whose ID files will be stored in each vault?

Later in the ID Vault Setup, you have the option to configure policies.
Policies are how to assign specific users to a vault. This is where you will configure which users do I want to start using the ID Vault. If you are only Piloting ID Vault or doing a Proof of Concept in your Production domain, the Policy is how you would initially limit your ID Vault Users.
Later the policy can be expanded, or additional policies added to assign additional users to the vault, as you expand your deployment.

Who will need to Administer the ID Vault?

During ID Vault Setup, you will be asked for the Vault Administrators.
The Vault Administrator functionality IS NOT related to who can reset passwords, or who can utilize the audit functionality. The Vault Administrator is only a list of who can go in and make changes to the Vault Configuration.
Like all of the items we are discussing now.

Who will need to Administer the ID Vault?

You do not need to be a vault administrator to:
Recover a users password from the ID Vault
This is configured via the Password Reset Authority You need to have the Auditor Role Checked in the ACL of the ID Vault Database

Extract an ID from the vault using the Auditor feature

Give other users permission to extract IDs from the vault with the Auditor Role Access/Open the Vault Database

You need manager access in the ACL of the ID Vault Database to assign the Auditor Role to other users. This is controlled via the ID Vault Database ACL Note: Most functionality does not require opening the vault database, however if someone did need to open the vault database, they DO NOT need to be configured as a vault administrator. As long as the users OU/Org is cross certified with the ID Vault, any Administrator with permission to create/modify policies, can assign additional users to an ID Vault.

Modify policies to assign the ID Vault users.

Who will need to Administer the ID Vault?

You DO need to be a vault administrator to:
Give new/additional users the ability to reset passwords.
Including configuring a server to host a self-service password reset application

Cross certify additional OU/Orgs to be cross certified with the ID Vault. Create/remove additional vault replica Servers
Note: Always use the Administration Client Manage ID Vault to create/remove ID Vault Replica Servers. Do not manually create or remove replicas of the ID Vault.

Add/Remove OTHER Vault Administrators Be VERY careful when assigning Vault Administrators
Keep Security and Accountability in Mind

Who will need to reset passwords for users?

There is the capable to allow for a significant amount of granularity with regards to the password reset authority. At first glance it can be very confusing. Dont implement granularity which is not required for your organization.
Is there a requirement regarding who can reset what passwords within your organization [based on OU/Org Structure]?

Who will need to reset passwords for users?

For example:
Within a single Domino Domain in your environment, are there different help desks for different sets of users? Do you need to prevent one help desk from resetting passwords for another group of users?

Most customers usually will have one list of people who will need to reset passwords for an entire Org.

There exists the ability to assign specific lists of people the ability to reset passwords for a specific OU/Org and NOT allow them to reset password for other OU/Orgs IF you have such a requirement.

Who will need to reset passwords for users?

When configuring password reset authority, when using the group assignment, understand this is a one-time convenience feature.
The security of ID Vault is designed to utilize cross certificates. There is no certificate for groups, so a group can not be cross certified with a vault as a password reset authority or a vault administrator.

The group will be expanded [at the time of configuration] and cross certificates will be created for all of the current members of that group. This is NOT a dynamic function. Users removed from a group WILL not have their cross certificates revoked. Users added to a group will not have cross certificates created for them. A Vault Administrator is responsible for maintaining the password reset authority.

Will you be implementing the Self-Service password application?

From a configuration standpoint:
The Domino server which will be hosting the SelfService Application AND the ID file signing agents making up the design of a self service password application. Both need to be configured as password reset authorities, and have the additional self service box enabled for the ID.

More on Self Service Password Application Shortly

Summary of Configuration
The previous slides should help to walk through the ID Vault Configuration steps.
Thee steps can be re-accessed at any time and modified by a Vault Administrator Always use the Admin Client Vault Administrator when making changes to Vault Configurations
Do not try to manually create/delete vault related cross certificates.

Configuration Questions?

Hints and Tips Recovering ID Files:

Recovering ID Files:
If you need to recover an ID file for an end user, do not use the Auditor ID Extraction feature.
The ID Extraction Function available to users with the Auditor role in the ID Vault Database ACL was designed to allow someone OTHER than the end user to obtain a copy of the end users ID file for audit purpose.

The auditor sets THEIR own password on the extracted copy of the ID file which DOES NOT synch with the ID Vault. Using this process to recover ID files for users, means you are providing them with a copy of their ID file which DOES NOT synch with the ID Vault.

The user [or someone acting on behalf of the user] should use the download process to have a proper ID file created from the ID Vault. Note: The attachment files within the ID Vault Database Documents are not valid ID files when attempting to directly detach.
The only way to obtain a working valid copy of a users ID file is through the download process.

Hints and Tips Shared and Service ID Files:

Shared ID Files:
Newsletter type IDs used to send email from, where multiple people may have a copy of the ID file, each with their own password set.

Service ID files:

As a Domino Administrator, you want to vault the ID for backup, recovery and reset purposes. End users dont want the password to synch across all of their copies.

Usually used to run an agent or a service-type machine may use the ID file to generate email.
These are also ID files Domino Administrators may want to vault, however not have actively synching to avoid potential software interaction issues.

Hints and Tips Shared and Service ID Files:

As a Domino Administrator how can you accomplish both?
Enable ID Vault via policy Allow the ID file to be harvested
Depending on how the ID file is used, it may not trigger automatic harvesting, you may need to manually login with the ID once

Once the ID file is harvested, go into the ID vault and mark the ID file inactive. Inactive prevents the ID file from being synched with multiple copies.
Allows a vaulted copy of the ID file to be retained/backed up etc as part of the ID Vault

Hints and Tips Name Change [OU/Org Moves]:

If a Vault Administrator OR Password Reset Authority needs to have their name changed, the AdminP rename process DOES not modify the cross certificate documents which were created during initial setup.
These users may lost their ability to perform associated functions. When a VA or PRA has a name change, a Vault Administrator will need to go into the Admin Client Vault Administration and remove/add the user [after the name change]

Self-Service Application Best Practices

The sample SSPRA is provided as an example of how to utilize the new password reset classes and functions. It does not contain any authentication or validation You will need to have a developer build in this functionality.

Self-Service Application Best Practices Considerations

Authentication Process
You need to validate that the person attempting to reset a password is the person they claim to be resetting the password for.

Validation

If HTTP Password synching is enabled, and users forgot or do not know their Notes password, they likely may not know their http password as well. Consider using a 3rd party LDAP system, Security Question Model, Authorization Number Model etc

A password reset will fail with the ID Vault if the new password does not meet password requirements including: Your application needs to validate that the password qualities are being met properly, or the password reset will fail on the back-end and the user may not be aware or understand why
Custom Password Requirements

Self-Service Application Best Practices Considerations

Error Handling
Errors with the password reset [including those related to validation] needs to be designed to provide feedback to the end user about errors reported by the Domino Server during the password reset.
Example:
New Password user enters does not meet password history requirements. Cant validate or check for this [without retaining history of passwords] however the Domino Server will not reset the password if this requirement is not met, and will report an error. Your code needs to be able to detect this error condition and report it back to the user, allowing them to re-enter a new potential password.

Self-Service Application Best Practices Hints and Tips

Policy Setting for Change Password after Password Reset
If using the Self-Service Password Reset application, this may create redundancy / confuse users by forcing them to change their password AGAIN after they just reset it using a SSPRA. The purpose of this option is when a SSPRA is NOT in use, and a Help Desk member may be resetting a password, the user is forced to change the password, preventing the ability for the Help Desk person to login as that user [with the knowledge of their new password] If this will be utilized in conjunction with an SSRPA, make sure the SSPRA is very clear that users are setting a temporary password which [once logged into Notes] they will be required to change.

Compatibility with other Features

Technote 1501086 Contains Support for ID Vault with other features such as roaming, Notes Single Logon and Notes Shared Logon. Information is also provided for support of these features with Citrix and 64-Bit Operating Systems Currently Unsupported Configurations contain SPR number. If any unsupported configurations impact your environment, you should request a 'Customer Report' be added for you. This can be done via PMR or by working with your AVL.