2011 wash scty id vault

ID Vault Best Practices

Agenda

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

Practices

Planning ID Vault• You’ll 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 user’s home server will impact which server the client will attempt to connect to when accessing the ID Vault.


• Consider a company with users spread across multiple continents.

– It doesn’t 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.


– 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.

– We’ll 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.


• 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.


• 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 company’s ‘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 company’s ‘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

– On the other hand, if:• 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]

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

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

– ‘Primary’, ‘Backup’, ‘Disaster Recovery’

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.


• 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.


• 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.

Don’t Do ThatID 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.

Don’t Do ThatID 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.– There is NO association with a Vault Replica server and a user’s ID Vault. Therefore trying to ‘load

balance’ ID Vault functionality like this will not yield the expected results.• 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.

– 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 I’ve 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.

• Don’t 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, you’ll 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 user’s 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.


• 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 user’s OU/Org, security settings will not allow a user’s 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’


• 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.


– You do not need to be a vault administrator to:• Recover a user’s password from the ID Vault

– This is configured via the ‘Password Reset Authority’• Extract an ID from the vault using the Auditor feature

– You need to have the ‘Auditor’ Role Checked in the ACL of the ID Vault Database• Give other users permission to extract IDs from the vault with the Auditor

Role– You need manager access in the ACL of the ID Vault Database to assign the ‘Auditor’

Role to other users.• Access/Open the Vault Database

– 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.

• Modify policies to assign the ID Vault users.– As long as the user’s 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.


– 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.• Don’t 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]?


• 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.


– 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 Self-

Service 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 TipsRecovering 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 user’s 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 user’s ID file is through the download process.

Hints and TipsShared 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.

• As a Domino Administrator, you want to vault the ID for backup, recovery and reset purposes.

• End users don’t want the password to synch across all of their copies.

• Service ID files:– 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 TipsShared 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 TipsName 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 PracticesConsiderations

• 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.• 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• Validation

– A password reset will fail with the ID Vault if the new password does not meet password requirements including:

• Custom Password Requirements– 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

Self-Service Application Best PracticesConsiderations

• 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.

» Can’t 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 PracticesHints 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.

2011 wash scty id vault

Documents

single id vault

multiple id vaults

different id vaults

id vault youll

additional id vault

id vault synchingdownloading

single vault

id files