Skip to main content

Hitachi ID Password Manager Deployment Best Practices

This document outlines best practices for designing, installing and rolling out Hitachi ID Password Manager to manage credentials for on-premise and SaaS systems and applications.


This document outlines best practices for designing, installing and rolling out Password Manager to manage credentials for on-premise and SaaS systems and applications.

The remainder of this document is organized as follows:

  • System objectives -- what credential management systems are designed to do.
  • Mission statement -- how organizations should structure their internal communication about priorities and objectives.
  • Metrics -- how to measure the impact on the system.
  • Stake-holders -- who to involve in design, implementation and ongoing support.
  • Deployment and support team -- who the core individuals are that must build out and support the system and what their initial and long term commitment will be.
  • Features and design -- what processes the system should automate.
  • User access to the self-service UI -- how to ensure that users can resolve login problems wherever they may be, at any time and on any device in any state.
  • Formulating a uniform password policy -- how to develop a set of password rules that work for every system and every user community.
  • Equivalent credentials -- caution about weak links in security and how to avoid them.
  • Security questions -- design considerations for enrolling security questions and using them to authenticate users who forgot their password.
  • Augmenting security questions with a second factor -- how to improve security by front-ending security questions with a stronger, one-time-password credential.
  • Infrastructure integrations -- what systems the credential management automation should integrate with.
  • Password Manager: technical architecture -- the runtime platform and network architecture on which Password Manager is deployed.
  • Password Manager: server hardening -- how to lock down OS, DB and web servers to protect the system.
  • Password Manager: BYOD access to on-premise credential management -- how to enable users to access self-service from their phones or tablets, which are typically not attached to the corporate network.
  • Auto-discovery of user profiles and accounts -- how to minimize care and feeding of the system using auto-discovery.
  • User enrollment -- inviting users to answer security questions; install smart phone apps; etc.
  • Maximizing user adoption and ROI -- strategies to get users to enroll and to use the system to resolve login problems.
  • Ongoing administration and support -- what can be expected in terms of long term care and feeding of the system.

System objectives

A credential management system should deliver three benefits:

  • Improved user service:

    Fewer credentials for users to remember and manage and simpler, quicker and more convenient resolution for login problems.

  • Lower IT support cost:

    Fewer help desk calls related to login problems such as forgotten passwords, intruder lockouts or tokens left at home.

  • Stronger security:

    Stronger and more consistent enforcement of policies around password composition, change frequency and reuse, as well as more reliable processes to authenticate users who experience a login problem, before assisting them.

Mission statement

A mission statement documented before the system is deployed is helpful for getting all stake-holders to cooperate. One way to formulate this mission statement is to capture the state of affairs before the system is deployed and the desired end state. Following is an example:

Credential management system objectives

User service / SLA
Users manage 8 different passwords, on average.

With password synchronization, users will only have to manage 2 passwords.
Only some passwords expire and they do so at different times

Users will be prompted to change all passwords at the same time.
Different systems enforce different password policy rules.

A uniform password policy will supersede multiple, inconsistent rules.
Users sometimes forget their pre-boot password.

Enable self-service filesystem unlock via smart phone app.
Users sometimes forget their OS login password, in some cases while off-site.

Enable self-service password reset from the PC login screen, with VPN+WiFi integration to support users working outside the office.
IT support cost
30% of total help desk call volume is due to login problems.

Password synchronization and self-service problem resolution will reduce this call volume by at least 80%.
5% of total call volume is due to OTP token problems.

Offer self-service PIN reset and emergency passcodes via smart-phone app.
Help desk calls to resolve login problems take 10 minutes to resolve, on average.

Consolidate caller authentication, technician login, problem resolution and ticket generation behind a single UI, to reduce call duration to 2 minutes.
Security / authentication
Users have too many passwords and write them down.

Synchronization will eliminate the main user motivation for writing down passwords.
Different systems and applications enforce different password policies.

Implement a uniform policy with a superset of password composition, reuse and change frequency rules.
Users calling the help desk are not reliably identified.

Move most incidents to self-service and apply uniform authentication processes in both self-service and assisted-service contexts.
Not all systems log password changes.

Will record who changed passwords, on a central credential management system.
Too many IT support staff have logins with elevated rights, required to reset passwords for people who call the help desk.

Support staff will reset passwords through an assisted-service portal, eliminating the need for such accounts.



Before deploying a credential management system, it is useful to identify and start recording metrics. Once the system is deployed, continuing measurement of the same metrics will show its impact.

Following are some relevant metrics:

  1. Number of systems that maintain their own, distinct password, rather than leveraging Kerberos, LDAP, SAML, etc. to externalize authentication.
  2. Number of distinct passwords an average user must remember and manage.
  3. Average number of login prompts faced by a user, during a work day.
  4. Number of systems (with their own passwords) able to enforce password complexity rules consistent with enterprise policy.
  5. Password change frequency -- required versus actually enforced.
  6. Help desk call volumes related to login problems:
    1. Forgotten passwords, per system, per month.
    2. Intruder lockouts, per system, per month.
    3. Filesystem lockouts (forgotten pre-boot password), monthly.
    4. Token problems (left at home, lost, stolen, forgot PIN), monthly.
    5. Forgotten passwords by users off-site, monthly. This is different than forgotten passwords per system because it refers to users who cannot unlock their PC until they bring it back to the office -- an especially disruptive type of problem.


A credential management system has many integrations, each of which has an owner: endpoint devices, servers, applications, incident tracking systems, e-mail infrastructure, VPN, VoIP or other telephony systems and multi-factor authentication platforms. It impacts security, IT support and audit.

It is important to get buy-in from every stake-holder early in the project, to avoid objections, delays and implementation risk.

An authoritative sponsor is essential to get buy-in from a diverse group of stake-holders. Because of the large number of interested parties, it is almost inevitable that somebody will raise objections, try to change priorities or alter previously agreed-to designs. Too many interruptions like this will derail the project. A high profile business sponsor reduces these risks.

The following stake-holders should be engaged as early as possible when deploying the system and should sign off on objectives as described in (1):

  • Project Sponsor:
    Provide mandate and budget for the project. Ensure cooperation from other stake-holders.

  • Project Manager:
    Ensure the project is managed effectively by providing and coordinating Hitachi ID Systems customer resources.

  • Network Architect:
    Develop and approve network-level design documents. Place servers on the network and specify integrations, for example with VPNs, SSL concentrators, reverse web proxies, etc.

  • IAM application administrator:
    Responsible for ongoing configuration, administration, enhancement and upgrades to Password Manager, post production deployment. Assists in implementation of the system prior to moving to production, in order to gain maximum familiarity with the software and configuration.

  • Credential management application administrator:
    Responsible for ongoing configuration, administration, enhancement and upgrades to Password Manager, post production deployment. Assists in implementation of the system prior to moving to production, in order to gain maximum familiarity with the software and configuration.

  • Security Officer:
    Review, document and approve any changes that impact corporate security, including policies, authentication processes, SIEM integration, VPN integrations, any service or generic accounts, etc.

  • Auditor:
    Define audit requirements, such as data retention, periodic review of user privileges, etc. Periodically review activity on the system.

  • IT support manager:
    Often fund the system, to reduce call volumes and head count. Provide integration details and support for ticketing system. Define user-support processes.

  • System administrators: (for every integrated system)
    Provide integration details for each target system, provide service accounts and test IDs and verify correct operation. Assist with troubleshooting integrations.

  • Human resources representative:
    Represent the HR function, including providing data feeds and feedback about issues of confidentiality.

  • Intranet manager:
    Provide user interface standards, including sample HTML, CSS and JS, to ensure that Password Manager matches enterprise standards.

  • Network operations:
    Support deployment of servers, including hardware, VMs, OS images, DNS names, network routes, SSL certificates and/or termination, load balancing and system health monitoring.

  • Desktop support:
    Deploy client-side code and policies that allow/block execution of same.

Deployment and support team

Identity management and access governance projects tend to be long and indeed may never end, as deliverables are continually added over the life of the system. Organizations go through both business and infrastructure changes: reorganizations, hardware upgrades, new operating systems, new applications, etc. These changes trigger matching requirements in the identity management and access governance infrastructure and consequently lead to implementation and maintenance effort over the life of the system.

This is not to imply that individual deliverables cannot be implemented quickly and operated at low cost. Rather, it means that successful implementation of one feature or integration usually triggers interest by a wider range of stake-holders, who request further work, to deliver more features and integrate with more infrastructure.

With this in mind, it can be helpful to think of identity management and access governance implementation in terms of a process of continuous optimization, which is the responsibility of a permanent team, rather than a single, finite project.

Successful organizations respond to this by instituting a permanent identity management and access governance program, rather than staffing for a finite-term deployment project. This team should include a permanent technical application administrator and a permanent application owner, at a minimum.

The Hitachi ID Identity Manager product administrator position should be a single FTE. The Password Manager product administrator position can be a fractional FTE (e.g., 0.25). The Hitachi ID Privileged Access Manager product administrator position can be a fractional FTE (e.g., 0.5).

As with any long term program, it is important to have clear buy-in from stake-holders and an up-front agreement on project scope, deliverables, duration and cost in order to sustain investment and deliver on business expectations. Without such early commitment by stake-holders, project work may be aborted before deliverables are reached.

The permanently assigned Hitachi ID Systems customer team should consist of one or two individuals who have as many of the following skills as possible:

  • System and process design:
    • Security policy.
    • Network and data architecture.
    • IT support infrastructure and processes.

  • Product installation, ongoing administration:
    • Windows / AD administration.
    • Web server configuration and management.
    • Web application deployment and administration.

  • Initial integration and ongoing updates and extensions:
    • Familiarity with each target system.
    • IT support infrastructure and processes.
    • E-mail infrastructure.
    • IVR infrastructure, if telephony integration is in scope.

  • Development of business logic:
    • Programming or scripting (e.g., Perl, VB, Java, etc.).
    • Familiarity with data sources: LDAP, RDBMS, etc.
    • Familiarity with web applications, including HTML and optionally (to support a more interactive UI) JavaScript.

  • UI customization:
    • HTML and CSS markup.
    • JavaScript and AJAX if highly interactive forms are in scope.

  • Deployment and ongoing support:
    • IT support infrastructure and processes.
    • User education.
    • Metrics.

Features and design

The first step in deploying a credential management system is to specify what processes it will implement. All stake-holders must sign off on a design, preferably in writing.

Hitachi ID Systems recommends deploying as many automated processes as possible, as each process adds value. It's a good idea to capture the motivation for each feature before starting deployment, as this helps new stake-holders understand not only what's being undertaken but also why.

Following is a list of Password Manager features. Customers typically deploy most of these, but which ones they include depends on their priorities and whether they actually have the relevant infrastructure (e.g., full disk encryption software, smart cards, etc.).

  • Transparent password synchronization:

    When users change their password natively on a system where a password synchronization trigger has been installed, the new password is tested for strength against the Password Manager password policy and, if accepted, is changed both locally and on other systems where the user has accounts.

    Password Manager includes password synchronization triggers for Windows server or Active Directory (32-bit, 64-bit), Sun LDAP, IBM LDAP, Oracle Internet Directory, Unix (various), z/OS and iSeries (AS/400).

    Using a familiar and mandatory password change process guarantees 100% user adoption.

  • Web-based password synchronization:

    Users can change some or all of their passwords using the Password Manager web interface. The password policy is clearly explained on-screen and enforced interactively.

    Using an interactive web page to change passwords has educational benefits but requires user awareness and cooperation.

  • Self-service password reset:

    Users who have forgotten a password or triggered an intruder lockout can sign into Password Manager using other types of credentials to reset their password or clear the lockout. Non-password authentication options include security questions, voice biometrics, smart cards, hardware tokens and random PINs sent to a user's mobile phone using SMS.

    Access to self-service is available from a PC web browser, from the Windows login screen, using a telephone or using the mini web browser on a smart phone.

  • Self-service filesystem unlock (pre-boot, full-disk encryption)

    Users with full disk encryption software on their PC, who have forgotten the password that unlocks their computer prior to OS startup, can unlock their hard disk using a self-service process accessed via telephone.

    Password Manager includes a turn-key integrated voice response (IVR) system designed to automate password resets, PIN resets and unlock of encrypted filesystems via a self-service phone call. It ships with connectors for popular full disk encryption products from McAfee, CheckPoint, Symantec and Microsoft.

  • Token and smart card PIN reset:

    Users with a token who have forgotten their PIN or need an emergency pass code can access self-service PIN reset with a web portal or using a telephone. Users with a smart card can also reset their own PIN using an ActiveX control embedded in a web browser -- launched from their Windows desktop or login screen.

  • Assisted password reset:

    Authorized IT support staff can sign into a Password Manager web user interface to look up a caller's profile, authenticate the caller by keying in answers to security questions and reset one or more passwords. A ticket can be automatically submitted to the help desk incident management system.

  • Password policy enforcement:

    Password Manager normally enforces a global password policy to supplement the various policies enforced on each system and application. This policy ensures that passwords accepted by Password Manager will work on every system.

    The built-in policy engine includes over 50 built-in rules regarding length, mixed-case, digits, dictionary words and more. Regular expressions and plug-ins enable organizations to define new rules. Password history is infinite by default.

  • Password change notification / early warning:

    Password Manager can remind users to change their passwords, either using a native password change dialog or via the Password Manager web portal. Warnings are normally sent to users before their password actually expires on AD, LDAP or other systems. These invitations can be sent via e-mail or launched in a web browser when users sign into their PCs. Users can even be forced to change passwords by launching a kiosk-mode web browser when the user signs into their PC.

    Password change reminders are normally only sent at the start of users' work day and work week, to discourage users from changing passwords right before leaving work and subsequently forgetting the new password.

User access to the self-service UI

Users should be able to resolve login problems wherever they happen to be, using whatever device is most appropriate and convenient, regardless of the state of their device. This means on-site at the office and also remote, from a browser on their PC, or their PC login screen, or a mobile device, and from the password prompt of their PC login screen, which asks for a (forgotten) password.

Some of these contexts present technical challenges, which the credential management system should address:

  1. A user who forgot or locked out their PC login password needs to be able to navigate to a password reset system from the PC login screen (Credential Provider on Windows Vista and later).

    Password reset via phone call or mobile app or another PC is not a satisfactory solution, because the user's password is cached locally on the PC and should be updated by the password reset process. For the same reason, VPN integration is required, so that when a user is off-site and forgets their PC login password, the new password can be injected back into the PC, making it usable again.

  2. A user who forgot their pre-boot password, used to unlock a full disk encryption product, needs to be able to interact with an unlock process to boot the OS on their PC. Later, once they have started up the OS, they can update the pre-boot password.

    Since there is no web browser in the pre-boot context, resolving pre-boot lockouts requires either a voice phone call or an app on the user's smart phone.

  3. A user who is off-site and has problems signing into the VPN should be able to interact with a solution on the Extranet, or via a phone call, or using an app on their smart phone, to unlock their credentials (typically a one time password token such as RSA SecurID).

  4. A user who forgot the PIN to their smart card needs to interact with an application on their PC, rather than a smart phone app or voice phone call, since problem resolution involves inserting the card into a reader and having software push an unblock code into the smart card. Smart cards are often used as the main PC login credential, so this kind of self-service needs to be made available at the PC login screen, rather than just from a web UI available to the already signed-on desktop.

Formulating a uniform password policy


Password Manager is normally configured to enforce a uniform password policy across all systems, to ensure that any new password will be acceptable to every integrated system. This provides the most clear and understandable experience to users. Password Manager is configured such that it will never accept or propagate a password that will not meet this global password policy.

For instance, in the case of an organization that has both Windows Active Directory (AD) and z/OS passwords, where users may enter very long passwords on AD but only 8 characters on the mainframe, Password Manager can require that passwords be exactly 8 characters long. Alternately, Password Manager can support longer passwords, but truncate them when it updates the mainframe (users generally prefer a fixed length, as it is easier to understand).

All systems enforce two types of password rules:

  • Complexity requirements ensure that users do not select easily-guessed passwords. Example rules are: disallowing any permutation of the user's login ID, password history, requiring mixed letters and digits, forbidding dictionary words, etc.

  • Character set and length limits on what can be physically stored in the password field on a given system.

A global password policy is normally created by combining and strengthening the best-of-breed complexity requirements from each system affected by the policy. Password Manager then combines these with the most restrictive storage constraints. This forces users to select strong, secure passwords on every system.

The alternative, of defining different password policies for every target system or for groups of target systems, is less user friendly. To update their passwords, users must select a system, choose a password, wait for the password update to complete, choose another system, select and input a different password, etc. Users must then remember multiple passwords and will continue to experience many password problems. It has been shown that users with many passwords have a strong tendency to write down their passwords.

Suggested policy rules

The recommended global password policy depends on the system with the most limited password fields. In many large organizations, this is often a z/OS mainframe, which only supports 8-character passwords, composed of letters, digits and three "special" characters (@, #, $).

  • For organizations with a mainframe

    • Length: 7 or 8 characters.
    • Characters: at least 2 letters, at least 1 digit, specials must be @, # or $.
    • Special words: no dictionary word, login ID or permutation thereof.
    • Repeats: no more than 1 pair of repeating characters.

    There are 39 possible characters in a password (letters, digits, 3 specials).

    Note: the total search space is 397 + 398 = 5,489,240,267,160 possible passwords.

  • For organizations without a mainframe

    • Length: 7 or more characters.
    • Characters: at least 2 letters, mixed case, at least 1 digit.
    • Special words: no dictionary word, login ID or permutation thereof.
    • Repeats: no more than 1 pair of repeating characters.

    There are 95 possible characters in a password (lowercase, uppercase, digits, 32 symbols on a US keyboard, space).

    Note: the total search space is no less than 957 = 69,833,729,609,375 possible passwords.

Where to enforce password policy

Password policy is enforced on both the Password Manager server and each of the managed systems. Ideally, each managed system enforces the largest possible subset of the policy rules enforced on the Password Manager server. In cases where a managed system initially had a rule that conflicts with the new global policy (i.e., it is impossible to compose a password that is simultaneously compatible with both the old native policy and the new global policy), the native policy should be adjusted to be compatible.

Password policy must not be disabled on any existing system, as this would allow users to bypass policy by making native password changes, without interacting with Password Manager.

Password policy must not be disabled on the Password Manager server, as this would allow users to bypass policy by making password changes using Password Manager, whose password resets are often subject to lesser restrictions when it commits new passwords to integrated systems.

Equivalent credentials

Password synchronization makes the security of managed systems equivalent, in the sense that if an intruder can compromise one password, the intruder can infer the value of the same user's passwords on other systems.

Password reset processes make passwords equivalent to the non-password authentication used to identify users who forgot their passwords or locked out their account.

Single sign-on makes the security of all in-scope applications the same as the security of an initial authentication.

Enrollment processes create security equivalence between the process used to sign into the enrollment system (usually a password) and the security questions or other data that are subsequently enrolled.

Organizations that do not take these connections into account can inadvertently lower the security of their entire organization. For example, if password reset processes authenticate users purely using security questions, and if the answers to those security questions are collected in an enrollment process, then the security of user profiles is only as good as the security of the credentials used to enroll those security questions.

Some organizations use a PIN, sent via e-mail or physical mail, to authenticate users prior to enrolling security questions. This makes the security of all subsequent passwords only as a good as that first PIN -- incredibly weak.

To ensure that user profiles are secure, follow these guidelines:

  • Password synchronization should go hand in hand with a requirement to use strong, frequently-changing passwords.

  • Password synchronization should not include systems with very weak security infrastructure (e.g., systems that store password in plain-text, or that have no intruder lockout mechanism triggered by repeated failed logins).

  • Self-service password reset should incorporate multi-factor authentication, such as sending a PIN to the user's phone or e-mail as a first authentication step and answering security questions as the second step.

  • Where self-service password reset relies on security questions, the number and complexity of questions should be maximized, within the bounds of usability.

  • Security question enrollment can follow authentication with an existing, strong password.

  • It is not acceptable to authenticate users with a static or short PIN, an employee number or a date of birth -- not even to enroll security questions.

  • IT support staff should authenticate callers with a process just as strong as is used for self-service. Where privacy legislation prohibits some security questions, use other questions at the help desk, but don't use fewer or weaker ones.

Security questions

Most organizations use security questions as at least part of the process for authenticating users who forgot or locked out their password.

Security equivalence

A password reset process makes the security of password authentication equivalent to the security of non-password authentication. This means, for example, that there is no sense in enforcing a strong password policy if users are authenticated to a password reset system with a 5 digit PIN, such as the last part of a social security number.

Memorable questions

Since password reset is provided to users who forgot their password, it makes sense to setup security questions whose answers users will not easily forget:

  1. It is not reasonable to use yet another password to authenticate users to a password reset system: if they forget the password they use daily, they won't remember a password that was assigned to them months or years in the past.
  2. Security questions should have static, factual and memorable answers. Avoid questions whose answers may change over time, such as "what is your favorite movie?"

Other best practices

Some additional recommendations for authentication with security questions:

  1. Combine free-form and pre-defined questions

    Ask users to enroll answers to standard questions, as the difficulty of guessing answers to these can be estimated.

    Also ask users to define their own question/answer pairs, as an attacker will not know what questions to research. Users often choose weak questions, so these should always be combined with standard questions, of a known 'quality.'

    Always prompt users to answer standard questions first, and only ask for answers to self-defined questions if correct answers to standard questions were entered. This reduces the odds that an attacker will know what user-defined questions to research.

  2. Avoid personally identifying information

    Ask legal counsel to review the offered, standard security questions. Avoid questions which may have legal consequences, such as social security numbers.

  3. Random sample

    Ask each user to enroll more question/answer pairs than will be used in any given authentication process. Prompt the user to answer only a random sample of those questions at login time. If the user answers incorrectly, prompt the user to answer the same questions again (not a new/random sample after a failed login), as this prevents attackers from "shopping" for questions whose answers they have already worked out.

  4. Intruder lockout

    If a given user fails to sign in several times in a row, lock out his user profile and do not accept further login attempts for a period of time. The number of failed attempts can be higher than might at first seem reasonable -- say 10 failed logins in 30 minutes. The lockout can be automatically cleared after a while -- say 20 minutes. The objective is simply to slow down guessing attacks against passwords or security questions.

    Intruder lockouts should apply to IP addresses as well. If user connections to Password Manager originate at distinct IPs, rather than a load balancer or reverse web proxy, then it's reasonable to lock out addresses that generate many login failures, as those may be used by an attacker. Be sure not to lock out any network infrastructure that aggregates traffic, however.

Sample questions

Sample security questions, which may have alpha-numeric questions and so are suitable for a text user interface, include:

  • Which bank branch do you live closest too?
  • What was the make of your first car?
  • What was the model of your first car?
  • What is your favorite food?
  • Who is your favorite book character?
  • What is your favorite game or sport?
  • What is your favorite movie?
  • What is your favorite pizza topping?
  • What is your favorite season of the year?
  • What is your favorite sports team?
  • In which department in the company did you first work?
  • What was your first position in the company?
  • Who is the person you admire the most?
  • What was the most memorable day in your life?
  • Who was your childhood hero?
  • What is the nickname of your youngest sibling?
  • What is the nickname of your oldest sibling?
  • Who was your first boss?
  • What award are you proudest of?
  • What city were you born in?
  • What is the farthest from home you have traveled?
  • What is the name of the first school you attended?
  • What is the name of the first person you were romantically interested in?
  • What is your astrological sign?
  • What is your father's middle name?
  • What is your mother's' middle name?
  • Who is your favorite actor or actress?
  • What is your favorite musical band?
  • What is your favorite beverage?
  • What is your favorite board game?
  • Who is your favorite book character?
  • Who is your favorite author?
  • What is your favorite dessert?
  • What is your favorite hobby or pastime?
  • What is your favorite ice cream topping?
  • What is your favorite song?
  • What is your favorite television show?
  • What is your favorite vacation spot?
  • What is your mother's maiden name?
  • What is your place of birth?
  • What is your school team's mascot name?
  • What was the breed of your first pet?
  • What was the color of your first automobile?
  • What was the name of your first childhood pet?
  • What was the name of your last childhood pet?
  • What is the name of your first girlfriend/boyfriend?
  • What was the street name of your childhood home?
  • What was your favorite toy when you were a child?
  • What did you do on your first job?
  • What was your first phone number as a child?
  • On what year did you purchase your first car?
  • Who is your favorite politician?
  • Who is your most disliked politician?
  • Who is a famous, living person you would most like to meet?
  • Who was a famous, now deceased person you would have liked to meet?
  • Who is your favorite artist?
  • With whom did you share your first romantic kiss?
  • Who was your favorite elementary school teacher?

Sample security questions, that have numeric answers and so are suitable for authentication using a touch-tone phone, include:

  • What is your favorite radio station (number on the dial - NNNN)?
  • In what year did you start with your company (CCYY)?
  • On what date were you hired?
  • What is your parents' wedding anniversary date (MMDD)?
  • What are the last 4 digits of your SSN or SIN?
  • What are the last 4 digits of your childhood home phone number?
  • What is a birth date of your youngest child (CCYYMMDD)?
  • What is a birth day of your oldest parent (MMDD)?
  • What is a birth day of your youngest parent (MMDD)?
  • On what date were you married (CCYYMMDD)?
  • On what date were you divorced (CCYYMMDD)?
  • What is your employee number?
  • What is your employee number?
  • What is your date of birth (MM/DD/YYYY)?
  • The last 4 digits of your passport number:
  • The last 4 digits of your driver's license number:

Augmenting security questions with a second factor

Security questions can be vulnerable to "social engineering" attacks, where an attacker does background research on a target user and subsequently impersonates that user by answering their security questions. It is therefore desirable to augment security questions with another credential. It is advisable to use the other credential before asking the user to answer security questions, so as not to show a would-be attacker what questions a user has enrolled answers to.

Common options for a second factor are:

  1. Send a random PIN to the user's mobile phone or personal e-mail address.
  2. Use a one time password device, such as an RSA SecurID token.
  3. Use a smart phone app, such as DuoSecurity.

Which factor to use depends on what the user in question has. For example, does the user have an RSA token? Has the user enrolled their mobile phone number? Has the user provided their personal e-mail address?

Infrastructure integrations

A credential management system must first integrate with the systems on which it sets passwords, PINs, certificates, biometrics, etc. This card management systems (smart cards), token authentication servers (OTP validation) and full disk encryption systems.

Credential management systems frequently also integrate with other IT infrastructure:


Purpose of the integration

When to activate

Invite users to enroll; remind users to change their passwords; notify users of events relating to their profile, such as queued password changes or intruder lockouts.

Initially. Every Password Manager system should be able to send e-mails.
Incident management (ticketing)

Create, update and/or close tickets to reflect events. Support centralized metrics of IT support activity, including self-service. Raise incidents to resolve technical problems, such as faults reported by connectors.

Useful in every deployment, but many defer this beyond the initial deployment.
Full disk encryption system

Enable users to unlock their PC if they forgot their pre-boot password.

Essential in every organization that has (a) full disk encryption and (b) password authentication pre-boot. Should be deployed early if possible.

Enable users to reset forgotten, locally cached Windows passwords while off-site.

In organizations where many users work off-site, or even where fewer but high-value people work off-site, providing password reset to these users is essential. This can only be done via deployment of client software and integration with the VPN. Should be deployed early if possible.
One time password tokens

PIN reset, clock synchronization, issuing emergency pass codes.

Enable users who forgot their token at home or forgot their PIN to regain access. Usually deployed in the first phase where required at all.
Telephony infrastructure, IVR

Offer self-service password or PIN reset, filesystem unlock via phone call.

Filesystem unlock and PIN resets for tokens used to sign into the VPN cannot be accessed from a PC browser, because the former is pre-boot and the latter is off-site. Phone call access to self-service can address these problems.
Mobile device management (smart phones)

Offer self-service via smart phone apps.

Deploy smart phone apps to enable users to manage credentials from BYOD.
Smart cards, card management system

PIN reset, emergency pass codes. Requires client-side code to integrate with card readers and integration with the CMS to retrieve card unblock codes.

Enable users who forgot their smart card at home or forgot their PIN to regain access. Usually deployed in the first phase where required at all.
IAM system

Where users have different login IDs on different systems, any pre-existing mapping data should be leveraged. Accelerate creation of credential management system user profiles (do not wait for auto-discovery to run).

The first scenario applies where IDs are inconsistent across systems. The second applies where new users are onboarded and need to use the credential management system immediately.

Leverage pre-existing security question data.

Either an initial bulk load or real-time lookup/validation.
Proxy system in DMZ or "cloud"

Mediate communication between on-premise systems and BYOD.

Phones and tablets are usually not attached to the corporate network. Allow these BYOD's to connect to a public URL, which authenticates a local app and forwards information to one of a pool of connections accepted from the on-premise credential management system.


Password Manager: technical architecture

Number and location of servers

Most deployments call for two or three Password Manager servers, preferably at two locations, each with its own local database instance and with the application arranging for real-time data replication between the database instances. User connections are load balanced across the servers.

This arrangement has many advantages:

  1. No single point of failure.
  2. Natural fault tolerance. Loss of a server or even a building only reduces capacity, but does not interrupt service.
  3. Excellent scalability.
  4. Ability to place Password Manager servers near target systems, to improve performance.

Too many servers can create high network traffic for replication. Too few mean inadequate redundancy in the event of a disaster.

Configuration of individual servers

A Password Manager server is typically configured based on standards set out in the data center where it will be installed.

Production Password Manager application servers are normally configured as follows:

  • Hardware requirements or equivalent VM capacity:
    • An Intel Xeon or similar CPU. Multi-core CPUs are supported and leveraged.
    • At least 8GB RAM -- 16GB or more is typical for a server.
    • At least 500GB disk, preferably configured as RAID for reliability and preferably larger for retention of more historical and log data. More disk is always better, to increase log retention.
    • At least one Gigabit Ethernet NIC.

  • Operating system:
    • Windows 2012R2 Server, with current service packs.
    • The server should not normally be a domain controller and in most deployments is not a domain member.

  • Installed and tested software on the server:
    • TCP/IP networking, with a static IP address and DNS name.
    • IIS web server with an SSL certificate.
    • At least one web browser and PDF viewer.

  • A database instance is required to host the Password Manager schema. Microsoft SQL Server 2012 is recommended (Oracle 11gR2 is supported on 9.0.x releases but has been be discontinued as of the 10.0 release). The SQL Server database software can be deployed on the same server as the Password Manager application, as this reduces hardware cost and allows application administrators full DBA access for troubleshooting and performance tuning purposes.

The file-system of the servers may be segmented as follows:

Password Manager Server Configuration

Size (GB)



The operating system and downloaded patches. The MSSQL database server software.


The Password Manager application and any third party software.


Log files

300 or more

Database contents (MSSQL)


Development, test and production environments

Three working environments are normally deployed:

  1. A development environment, where system administrators implement new versions of Password Manager, test out configurations, etc. This is where Hitachi ID Systems services staff do most of their work.
  2. An integration testing environment, where new versions of Password Manager are validated before being migrated to production.
  3. The production environment, which is subject to strict change controls.

Separating development from integration testing environments enables Hitachi ID Systems to proceed with developing new features and integrations and with troubleshooting, at the same time that Hitachi ID Systems customer tests previously released versions.

Separating integration testing from production environments enables Hitachi ID Systems customer to apply strict quality and change controls over its production environment, to avoid outages, misconfigurations and ultimately any adverse user or systems impact.

These three environments should have the following characteristics:

  1. Development
    1. May use virtual machines for Password Manager servers.
    2. There should be representative instances of each target type, but not necessarily as many of each type as there are in the other environments.
    3. There should be representative instances of non-target systems with which Password Manager will be integrated (e.g., help desk, e-mail, etc.).
    4. There should be a small number of users on each target, representing all user types. The number should be kept relatively small in order to expedite testing of code changes.
    5. No change control is applied to this environment.
    6. Hitachi ID Systems professional services staff should have continuously available remote control access to the Password Manager servers in this environment, to assist in configuring new features and integrations.

  2. Integration testing
    1. Should be a close mirror of the production environment.
    2. May use virtual machines for Password Manager servers.
    3. Should have as many Password Manager servers as production, to validate the setup of replication and load balancing.
    4. Target systems should mirror production systems, as much as possible, in terms of number and type.
    5. Each target system should have a recent snapshot of the user population from its corresponding production target system.
    6. Hitachi ID Systems consulting staff may request remote control access to the Password Manager servers in environment, during integration testing.
    7. Change control should be used to document changes to this environment. No special schedules or approvals are normally required for changes here.

  3. Production
    1. Typically two or more load balanced servers.
    2. Should be stable and closely monitored.
    3. Storage should be reasonably performant, on the assumption that the database server instance runs on the same OS instance as the application. This means SAN or NAS storage when servers are virtualized.
    4. Hitachi ID Systems normally requests remote control access to the Password Manager servers in this environment during production migration and subsequently only on an as-needed basis to help Hitachi ID Systems customer with any troubleshooting that comes up.
    5. Change control should be used to review, approve and schedule changes in this environment, so as to minimize disruption to users and to other production systems.

Proxy servers for hard-to-reach target systems

In some cases, the connection to a target system may be slow, insecure or simply blocked by a firewall. This is often true when the connection is made over a wide area network or requires the use of an insecure protocol but must cross an untrusted network segment.

To address such connectivity problems, Password Manager includes an application proxy server. When a proxy server is deployed, the main Password Manager server ceases to communicate with one or more (usually distant) target systems directly and instead forwards all communication to those systems through one or more proxy servers, which are co-located with the target systems in question.

Communication from the main Password Manager server to the proxy server(s) is encrypted, efficient and tolerant of high latency. It uses a single, arbitrarily-numbered TCP port number. Connections are strictly from the main Password Manager server to the proxy server (never back). A single TCP port supports an arbitrarily large number of target systems at the proxy server's location.

These characteristics of the communication between a Password Manager main server and a proxy server mean that firewall administrators will normally be willing and will always be technically able to route or forward a TCP port from the main server IP address to the proxy server IP address.

Communication between the proxy server and target systems continues to use native protocols. It is normally physically secured, in a high-bandwidth, low-latency, high-security data center network.

Deployment of the secure Password Manager proxy server is illustrated in Figure [link].


    Target systems connected through a proxy server

Password Manager: server hardening


Hitachi ID Systems makes available detailed instructions for hardening Password Manager servers. These instructions are available on-line here:

Password Manager runs on the Windows server platform, but aside from client libraries for target systems, actually uses very little Windows technology. This makes it possible to disable almost every component of the Windows server OS, significantly reducing the attack surface.

Server hardening typically involves the following:

  1. Physically securing the Password Manager server.
  2. Ensuring that the server has the latest service packs and hot fixes from Microsoft and that new patches are applied automatically.
  3. Removing all unneeded login IDs and renaming the Administrator account.
  4. Uninstalling every unused service.
  5. Minimize the number of system administrators who can sign into the server.
  6. Detaching the server from the domain, to block domain administrators from signing in.
  7. Enabling inbound packet filtering to only allow defined TCP ports.
  8. Removing or disabling any unneeded features of the IIS web server.
  9. Locking down filesystem access.
  10. Enabling security audit logs, at least of all logins to the server.
  11. Port scanning the server to check results.

Some of the most effective security measures are common sense:

  • Use a single-purpose server for Password Manager. Sharing this server with other applications introduces more complexity and more administrators, each of which carries its own incremental risk.

  • Use strong passwords for every administrative account on the server.

  • Maintain a current, well-patched operating system on the Password Manager server. This eliminates well-known bugs that have already been addressed by the vendor (Microsoft).

  • Automatically apply patches, especially security patches, to the OS, database server and any third party software.

  • Keep the Password Manager server in a physically secure location.

  • Provide security awareness training to all employees.

  • Install, and keep up to date anti-virus software.

  • Do not leave a login session open and unattended on the Password Manager server's console.

  • Attach the Password Manager server to a secure, internal network rather than the public Internet. If access from the Internet is required, mediate it via a reverse web proxy running a different OS an web server platform than Password Manager -- platform diversity reduces the risk of zero-day exploits.

  • Regularly review Password Manager, OS and network logs.

  • Use the Microsoft Security Compliance Manager to learn more about server hardening.

Physical security

Password Manager servers should be physically protected, since logical security measures can often be bypassed by an intruder with physical access to the console:

  • Restrict physical access

    Put Password Manager server(s) in a locked and secured room. Restrict access to authorized personnel only. Password Manager administrators should install and configure the server(s) and then only access it remotely via HTTPS to its web portal or RDP to the OS.

  • Connect a UPS

    Ensure that server power is protected, that graceful shutdowns occur when power is interrupted and that there is surge protection at least on incoming power connections.

  • Prevent boot from removable media

    Configure the server to boot from its physical or virtual hard drive and not from USB or optical drives.

Where the Password Manager server is virtualized, apply the above controls to the hypervisor.

Operating system access

Install the latest service packs, as these frequently include security patches and updates.

Keep up-to-date with the latest Windows security upgrades by subscribing to Microsoft's security bulletin at:

One way to limit the number of users who can access the Password Manager server is to remove it from any Windows domain. If the Password Manager server is not a member of a domain, it reduces the risk of a security intrusion in the domain being leveraged to gain unauthorized access to the Password Manager server.

  • Remove unused accounts, leaving just psadmin -- the Password Manager service account.
  • Create one administrator account to be used by the Password Manager OS administrator to manage the server and set a strong password on this account.
  • Disable the default administrator account.
  • Remove any Guest or unused service accounts.
  • Remove the terminal services user account TsInternetUser. This account is used by the Terminal Service Internet Connector License.

For any accounts that must remain, limit their access. At a minimum, block access by members of 'Everyone' to files and folders on the server.

If feasible, turn off the remote access and management features on the server to protect the server from remote access attempts using brute force password attacks. This includes the following:

  • Check that "Enable remote management of this server from other computers" is disabled.
  • Turn off "Remote Desktop Administration".

If remote administration of the OS is required:

  • Edit the local security policy and remove Administrators from the Allow log on through Remote Desktop Services policy.
  • Add an alternate account with lower privileges to the Remote Desktop Users group.

Open ports are an exploitable means of system entry. By limiting the number of open ports, you effectively reduce the number of potential entry points into the server. A server can be port scanned to identify available services.

Use packet filtering to block all inbound connections other than the following default ports required by Password Manager:

Default TCP port

443/TCP IIS / HTTPS web service.
5555/TCP Password Manager database service default port number (iddb).
2380/TCP Password Manager file replication service default port (idfilerep).
3334/TCP Password manager service (idpm).
2340/TCP Session monitoring package generation service (idsmpg).
4444/TCP RSA Authentication Manager Service (psace) - if RSA tokens are managed.


On Windows Server 2012, packet filtering is accessed by running the wf.msc control.

IIS configuration

IIS is more than a web server; it is also an FTP server, indexing server, proxy for database applications, and a server for active content and applications. Disable these features as Password Manager does not use them.

Create two separate NTFS partitions - one for the operating system and one for content IIS serves up. This will protect the OS from IIS compromise.

Always deploy a proper, issued-by-a-real-CA SSL certificate to Password Manager servers and disable plaintext HTTP access. Never use a self-signed certificate in a user-facing system, as this may condition users to ignore SSL validity warnings.

Assign the IIS user the right to read from but not write to static HTML, image file and Javascript files used by Password Manager.

Assign the IIS user the right to execute CGI programs but not other executables on the Password Manager filesystem.

Disable directory browsing -- there is no reason why a user connecting to the Password Manager web portal should be able to list files in any folder.

SQL Server configuration

Don't install anything beyond the core SQL server software. Specifically, leave out or disable:

  • SQL Server Analysis Services (SSAS).
  • SQL Server Integration Services (SSIS).
  • Full-Text Engine.
  • The Filter Daemon Launcher.
  • SQL Server Reporting Services (SSRS).
  • Active Directory Helper.
  • SQL Server VSS Writer service.
  • SQL Server Browser.

Password Manager will connect to the database locally, so network access can and should be disabled. Use SQL Configuration manager to disable all but shared memory access to the database.

After installing the SQL Server database software and Password Manager, remove access by the OS Administrators group to the database and change the password for the sa account.

Configure a dedicated, local-admin account for use by the The SQL Server Agent service, so that it runs in a different security context than the database itself.

Password Manager: BYOD access to on-premise credential management

Since Password Manager is a sensitive security application, with privileged access to many other systems in an organization and with access to sensitive personal data, most organizations are unwilling to expose Password Manager directly to the public Internet. This creates a problem for mobile device access to self-service, as illustrated in Figure [link].


    Outbound connections are routine, inbound connections are risky and rarely permitted

Hitachi ID Systems has developed a solution to this problem, by installing and activating an app natively on iOS and Android devices and hosting a proxy server in the cloud. This arrangement is shown in Figure [link].

Using this architecture:

  1. An app is installed on user devices.
  2. Users sign into Password Manager with their PC and ask to activate their device.
  3. The PC-based web UI displays an activation QR ode.
  4. The user runs the app on their device, which scans this QR code.
  5. The QR code includes encryption key material and a URL for a proxy service, in the cloud (i.e., on the public Internet).
  6. Users use the app to (indirectly) access the on-premise Password Manager web portal.
  7. The app connects to the cloud proxy, requesting content from the on-premise portal.
  8. The proxy checks key material provided by the app and may discard connection attempts. In this way, connections from regular browsers or devices which have not been correctly activated for a particular Password Manager instance are easily discarded.
  9. Simultaneously, a service on the Password Manager server connects to the proxy server, asking for page requests to fulfill.
  10. The proxy passes requests from mobile devices to connections from the Password Manager server.
  11. All connections that cross the corporate perimeter firewall in this architecture are outbound -- from the Password Manager server to the cloud proxy.
  12. All connections are encrypted.


    Cloud proxy architecture

Auto-discovery of user profiles and accounts

In most deployments, Password Manager fetches a full list of user IDs from every managed system, every night. This minimizes the need to manage accounts in Password Manager directly.

Selecting sources of profiles

In most installations, Password Manager is configured to "trust" one or more systems to be an authoritative source of Password Manager user profiles. Any user who is added to an authoritative system will, during the auto-discovery process, be automatically added to Password Manager. Conversely, users removed from all authoritative systems will be automatically removed from Password Manager.

This process ensures that users do not have to be explicitly or manually enrolled in or removed from Password Manager.

Users sign into Password Manager with their login ID on the authoritative system.

Where there is no obvious authoritative system, e-mail addresses or employee IDs can be extracted from an existing system and used as the authoritative ID.

Mapping login IDs to user profiles

Every enterprise identity management and access governance system, regardless of its features, must support login ID reconciliation. Users have login accounts and other records on various systems and these have to be attached to a single profile, in order to create a user-centric identity system. The process of attaching non-standard login IDs and other user identifiers to a single profile is called login ID reconciliation.

Password Manager supports multiple options for login ID reconciliation, as follows:

  • Automatically, typically by matching consistent login IDs.

  • By matching other attributes such as an SSN or employee ID, where they are available.

  • By drawing on an external source of data -- for example, some organizations maintain a mapping table or spreadsheet.

  • Using a self-service reconciliation process.

When self-service login ID reconciliation is required, it works as follows:

  • Users are automatically invited to complete their profiles -- for example via an e-mail with an embedded URL.
  • Users sign into the registration system, using a primary login ID and password or other types of credentials.
  • Users are asked to type their additional ID/password pairs. Each provided ID/password pair is compared against an automatically maintained inventory of login IDs drawn from target systems, to find instances where the user-entered login ID appears on a system and does not yet belong to a known user profile. Password Manager then attempts to sign into that system with the user-entered password. If the login attempt succeeded, the user's profile is updated with the system ID and the user-entered login ID.

Self-service reconciliation is inexpensive (about 5 minutes per user), reliable, fully automated (users are reminded to register until they actually do) and very secure.

Both self-service and administrative login ID reconciliation are logged. Other forms of login ID reconciliation are typically batch oriented and can be configured with logging if required.

Note that attempts to reconcile login IDs by matching on attributes of user profiles on target systems are often costly and/or insecure, especially when combined with a password management system:

  • The only attribute that is commonly available on every system is a user's full name. This may be inconsistent across systems and in many large organizations multiple users share the same full name and sometimes the same location.

  • Failure to automatically correlate an account leads to manual, administrative reconciliation, which is expensive.

  • Incorrect ID mapping allows one user to set another user's password, which is a serious breach of security.

Where self-service login ID reconciliation is required, the process is both inexpensive (25,000 users spending 5 minutes each costs nothing, while one consultant spending weeks or months is expensive) and error-free (since IDs are claimed with a validated password). This process is, to the best of Hitachi ID Systems knowledge, unique.

User enrollment

In many organizations, deployment of a credential management system requires a user enrollment process. Enrollment may be to get users to:

  1. Answer security questions;
  2. Install and activate an app on their smart phone;
  3. Provide their mobile phone number or personal e-mail address;
  4. Attach accounts with non-standard IDs to their profile;
  5. Provide biometric samples, such as a voiceprint;
  6. Review and accept corporate policy documents.

Where enrollment is required, it is helpful for the credential management system to automate the process by identifying users who must be enrolled, inviting and reminding them to enroll and provide a strongly authenticated enrollment user interface.

Password Manager includes built-in infrastructure to securely and automatically manage the user enrollment process:

  • By monitoring one or more systems of record, Password Manager automatically creates new and removes old profile IDs.
  • New users and existing users with incomplete profiles are automatically invited to complete their profiles (e.g., by answering security questions).
  • Invitations to enroll may be e-mailed to users.
  • Users may be more forcefully reminded to enroll by having a web browser automatically open to the enrollment page when they log into the network.
  • Users may be forced to enroll, by opening a kiosk-mode web browser to the enrollment page when they sign into the network, and blocking access to the Windows desktop until users complete their profile. This process is typically controlled by placing users into a "mandatory enrollment" AD group and attaching a suitable GPO to that group.
  • To enroll, users must first authenticate. This is normally done by leveraging an existing strong authenticator -- such as a network password or a token.
  • A single, integrated enrollment system supports collecting answers to security questions, mapping different login IDs, on different systems back to their owners and collecting biometric voice print samples.
The enrollment system in Password Manager includes schedule controls. For example, the maximum number of invitations to send daily can be limited, as can the frequency of invitations per user. Days-of-week during which to send invitations are identified as are holidays during which no invitations should be sent.

Figure [link] shows a dashboard that tracks enrollment progress.


    Screen shot: Enrollment Statistics

Following is a sample invitation e-mail sent to users:

  To all users:

  Acme, Inc. is activating a credential management system.
  This system will help you to manage your own passwords by:

  * Synchronizing passwords across your various login accounts.
  * If you forget your password or lock yourself out, you will be able
    to resolve the problem without calling the help desk.

  Please take a few moments to register with the credential management
  system now:

  * Click on the URL below.

  * Sign in with your Windows/AD ID and password.

  * Answer security questions as prompted.

  * Enter your mobile phone number and/or personal e-mail address
    as prompted (these will only be used to send you PINs at login time).

  * Please install the Hitachi ID Mobile Access app on your phone
    (it's on the Apple and Google markets) and activate it.  This
    will help you access the system while away from the office.

  Register now:

  Once enrolled, whenever you change your Windows password, all other
  logins will automatically get the same, new password.

  After completing your profile and installing the app on your phone,
  if you forget or lock out your Windows password, you will be able to
  click the 'Password Reset' tile on your Windows PC to get help,
  use the app to unlock your pre-boot password or reset your RSA SecurID

  If you have any questions, please contact

  Thank you!

  -- The IT department.

Maximizing user adoption and ROI

Password Manager generates a return on investment (ROI) by lowering IT support cost. This only happens when users experience fewer problems and choose self-service rather than calling the help desk. In other words, user adoption determines ROI.

Following are best practices for increasing user adoption and ROI.

Minimize password problems

Help users help themselves:

  1. Synchronize passwords, triggered by native password changes on Windows/AD.
  2. Send users advance warning that their password will expire soon. This is especially helpful for users who frequently work off-site, and may not receive reminders from Windows.
  3. Send password change reminders on Monday thru Thursday in the morning. This way, after users change their password, they will use the new password a few times before going home for the evening or weekend, and are more likely to remember it.

User awareness

Send mass e-mails introducing the system and explaining (a) why it is being deployed and (b) how to use it.

Incentives for enrollment

Offer incentives to users who complete their profiles early. Incentives can be quite inexpensive compared to the cost savings due to lower call volume and reduced head count at the help desk. Examples may include a draw for gift certificates, physical prizes (often electronic gadgets), etc.

Automated reminders

Users should get automated reminders to complete enrollment:

  1. Reminders should be personalized, not mass mail.
  2. Message severity should increase gradually. Start with a gentle e-mail, then a more stern e-mail, then one with the user's manager copied.
  3. The media used to send messages can also increase in severity. Start with e-mails, then automatically launch a web browser to the enrollment page at user login time and finally consider launching a full-screen, kiosk-mode browser that the user cannot close.
  4. Throttle the total number of e-mails sent per day, so as not to overload the help desk with calls from users who are not sure how to comply.
  5. Throttle the invitation frequency per user, so users don't become accustomed to the e-mails and immediately delete them.
  6. Schedule invitations for work days, not weekends or holidays.

Failure to send automated, personalized, persistent invitations to users leads to low adoption rates. This feature is really not optional.

A call to IT support is not the right time to enroll

Some organizations opt to enroll callers to the help desk who have not already completed their profiles. This can be effective but is a very expensive strategy, effectively negating any ROI from the system. Not recommended.

Charge-backs and manager feedback

Consider departmental charge-backs and e-mails to a user's manager whenever a user opts to call the help desk rather than utilizing self-service. This is a negative incentive, making it clear to users that continuing with business as usual is undesirable.

Reduce SLA for help desk calls

If users continue to call the help desk, park their calls on an audio message explaining self-service before they can speak to a human. This acts as another dis-incentive to continued calls to the help desk for services that are better completed via self-service.

Plan for user adoption

The key point regarding user adoption is to plan for a user engagement program. Failure to plan is really planning for failure.

Ongoing administration and support

The following sections describe the routine ongoing administration of Password Manager:

Functional test

Periodically test the functionality of the Password Manager server. If any component should fail, it is better to discover it pro-actively than wait for users to notice and complain.

Password changes

Create a test user that has at least one login ID on every system where Password Manager manages passwords. Regularly use either the administrator (PSA.EXE) or self-service (PSS.EXE) UI to change every password for this user. Make sure all passwords are changed, both through success messages in the UI and by trying to sign into each system with the new password.


If you implemented web-based registration, verify that a test user can update his own security questions, phone number and e-mail address.

Transparent password synchronization

If you deployed transparent password synchronization (highly recommended), periodically verify that a native password change does, indeed, trigger automatic password updates for the same user on other systems.

Help desk logins

Verify that help desk staff can log into the application and have the rights to reset passwords for users (e.g., for the test account mentioned above). Create a help desk user account for this purpose.

Sending e-mails

Monitor e-mails sent by the system. It should regularly send e-mails to users reminding them to change passwords and to new users inviting them to enroll. This is a critical feature, without which user adoption will be very low.

Creating call tracking system ticket

If you implemented ticket system integration, trigger relevant events, such as intruder lockouts, and verify that tickets are generated and populated appropriately.

IVR (phone call) integration

If you implemented an IVR user interface, verify that it is reachable, is able to identify and authenticate a test caller and can reset passwords and PINs.

Mobile access

If you enabled access from smart phones (highly recommended!), verify that it remains possible to sign into the system from an activated smart phone. Verify that new users are invited to install the app on their phones and are able to activate it.

Off-site, Windows login screen access

If you enabled access to self-service password reset from the Windows login screen from off-site, verify that this remains possible. Take a corporate laptop to a nearby coffee shop and access self-service from the Windows login screen.

Filesystem unlock

If you enabled access to self-service filesystem unlock for PCs or laptops that require a pre-boot password, ensure that unlock is accessible, using either the IVR or smart phone app to access Password Manager.

Changes to target system configuration

Changes made to the configuration on some targets can have an impact on Password Manager. Be sure to include testing of password changes in the change control process for every integrated system and application.

Monitor service health

Verify that all Password Manager services, including the database service (IDDB), the password management service (IDPM), log service, etc. are running at all times.

Monitor utilization

Use the Password Manager dashboard to monitor how many users there are in the system and how many of them have completed enrollment. Use built-in reports to monitor utilization of the system -- number of logins and passwords changes per day and per week.

Regularly run reports to search through logs and find error messages and e-mail those to the Password Manager administrator, to investigate and follow up on.


Password Manager deployment is straightforward and can be completed in a matter of weeks, typically requiring only a few days of professional services.

Because Password Manager impacts so many groups in an IT organization, it is important to have powerful and visible program sponsorship and to involve all stake-holders as early as possible.

Password Manager should be made available where users are, because users will need it to resolve login problems. This means pre-boot if users type a password to unlock filesystem encryption; at the PC login screen if laptops cache domain passwords; on-site and off-site; using their smart phones (app), a phone call and of course using a full screen web browser.

A successful deployment will expand over time. Some organizations start small - simple on-premise AD password reset, but then grow over time, to include access from mobile phones, pre-boot unlock for users with encrypted filesystems, password synchronization across legacy and SaaS applications and password reset for off-site laptops. To achieve this, long-term staffing is required. A single, strong technical resource is more than adequate, and in fact a fractional FTE is often all that's required.

This document outlines numerous best practices regarding features and integrations, network architecture, policies, user enrollment and adoption stake-holder engagement and ongoing support. These should be taken as guidelines and combined with specific organizational requirements to produce an implementation design and project plan.

page top page top