White Papers Password Management Best Practices Password Manager Deployment Best Practices
Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

Hitachi ID Password Manager Deployment Best Practices

This document outlines best practices for designing, installing and rolling out the Hitachi ID Password Manager password management solution in a medium to large organization.


This document outlines best practices for designing, installing and rolling out the Password Manager password management solution in a medium to large organization.

The remainder of this document is organized as follows:

Project objectives


A password management system is generally intended to deliver three benefits:

At the start of a password management project, it is important to quantify (i.e., set metrics for) the existing problems with password management and set out goals for improved service, cost and security.

A project mission statement, listing current problems and how they will be solved, can be laid out in a table such as the following:

Password management project objectives
Current problem Planned improvement

Each user has to 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 on individual schedules.

Users will be prompted to change every password at once.
  Different systems enforce different password policy rules.

A new, global password policy will be applied to all systems.

30% of total call volume is due to login/password problems.

Password synchronization and self-service reset will reduce the problem rate by at least 80%.
  A password call takes 10 minutes to resolve (authenticate caller, create ticket, login to administration tool, reset password, close ticket).

Password problem resolution will be streamlined with a single web interface and be reduced to 2 minutes/call.
Security /
quality of

Users have too many passwords and write them down.

Synchronization will eliminate the main user motivation for writing down passwords.
  Each system has a different and possibly inadequate password policy engine.

Password Manager will enforce a single, global, strong password policy.
  Users who call the help desk for assistance with passwords may not be properly authenticated.

Most users will use self-service, with strong authentication built-in. Password Manager will also enforce a new authentication process that requires help desk analysts to enter user responses to profile questions before they can reset a user's password.
  Password resets are not properly logged on all systems.

Password Manager will record who made each password reset, on which system, for which user.
  Too many (front line) support staff have administrative credentials, required to make password resets.

Support staff will reset passwords through Password Manager and their administrative access will be removed.
  Support staff reset passwords on some systems to which they connect using plain-text network protocols.

All new password updates will be through Password Manager, over HTTPS. Communication between Password Manager and managed systems will be protected in all cases -- in some cases physically and in other cases cryptographically.



A password management system may affect corporate security, network operating systems, managed servers, call tracking systems and e-mail.

It is important to get buy-in from every stake-holder early in the project. Failure to get early agreement from every stake-holder will result in project delays and may put successful project completion at risk.

An empowered project sponsor is essential to get buy-in from a diverse group of stake-holders. Because of the large number of project participants, it is almost inevitable that somebody will be reluctant to cooperate, assist or approve projected-related changes. A high profile project sponsor will reduce the project risk due to such minor disagreements.

The following stake-holders should be involved in the project at the earliest possible date. Stake-holders should be made aware of the project's objectives, as documented in (1) as early as possible.

Stake-holder Role in the password management project
Project sponsor

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

Ensure that the project is managed effectively.
Software installer / administrator

Installs as many components of the password management system as possible and manages the system when in production.
I.T. security officer

Review, document and approve any changes that impact corporate security, including new login IDs, server configuration and location, password policy, non-password authentication rules, security incident response, approved access channels (web, SKA, IVR), etc.
Owner, system administrator of the help desk call tracking system

Specify integration with the help desk call tracking system, both at the business requirements and at the field/value levels of detail.
Owner, administrator of every system where passwords will be managed

Validate integration process with each managed system, create administrative credentials for use by the system and assist with software installation and testing of password management on that system.
Owner of the corporate Intranet

Provide user interface standards, possibly implement GUI localization, and validate compliance with Intranet standards.
Representative, network infrastructure

Manage production server installation, connectivity, backup services, server health monitoring, load balancing.
Representative, desktop deployment

Evaluate the impact on desktops, either of the kiosk account or (in unusual cases) of any software deployed to the desktops.
Representative, user education

Prepare and/or validate user education documents.


System administrator

Each Password Manager installation should have a Password Manager software and server administrator. Following is a recommended skill-set for this person:

Design features

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

Following is a list of features and policies that Hitachi ID Systems recommends as best practices, along with justification for each one.



To maximize user adoption rate, a password management system, and self-service password reset in particular, must be made available to users regardless of their location and situation:

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 attempt to 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 (older) 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 the preset length rule, as it is easier to understand than automatic truncation).

In general, systems enforce one of two types of password rules:

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 representational 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 considered to be user-unfriendly. To update their passwords, users must select a system, choose a password, wait for the password update to complete, possibly re-authenticate, choose another system, choose 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.

The recommended global password policy depends on the system with the most restrictive representation rules. In many large organizations, this is an OS390 (zOS, MVS) mainframe, which only supports 8-character passwords, composed of letters, digits and three "special" characters (@, #, $).

Password policy must be enforced on both the Password Manager server and each of the managed systems. Ideally, each managed system should enforce 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 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 not subject to policy rules on most systems.

Security equivalence in authentication


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 services (both self-service and assisted) make passwords equivalent to the non-password authentication used to validate users who forgot their passwords.

If password reset services rely on users answering personal questions, and if the answers to those personal questions are collected in a registration process, then both the subsequent Q&A authentication and the passwords that can be reset with that authentication are made equivalent to the authentication used to initially register Q&A data.

To ensure that authentication is reliable, the above points lead to some basic design requirements:

Authentication process using challenge-response


As mentioned above, 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.

In most organizations, hardware tokens are not widespread enough to use as the sole means for non-password authentication. Both hardware tokens and biometric identification systems can be costly, especially in comparison to passwords. In the absence of such strong authenticators, non-password authentication normally means use of a challenge-response process to validate the identity of users.

Since password reset is provided to users who forgot their password, it makes sense to use information that users will not forget. In particular, 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 are unlikely to remember a password that was assigned to them months or years in the past, which they have never used since. By the same argument, Q&A data used for non-password authentication should be static, factual and memorable. Avoid questions whose answers may change over time, such as "what is your favorite movie?"

Some additional recommendations for challenge-response authentication:


A password management system obviously integrates with the systems on which it can set user passwords.

Password management systems frequently also integrate with other I.T. infrastructure. A description of different types of integrations and when they are appropriate, follows:

System Integration process When to activate
E-mail system Prompt users to register. Whenever user registration is required (see [link]).
  Notify users of changes to their passwords or profiles This is recommended in every organization where the majority of users access e-mail.
H.R. system Access existing Q-A data for authentication. Whenever the password management system provides password reset to users (self-service) or analysts, and the existing data is adequate (covers most users, is reliable and sufficiently hard to guess).
Call tracking system Write tickets to reflect ongoing activity. Closed tickets are purely for utilization monitoring, open tickets are to escalate technical or security problems. Appropriate if an organization relies on the help desk call tracking system to meter support activity.
Directory /
meta directory.
Look up on what systems a user has login IDs, and what those IDs are. Appropriate if a directory already exists and has this data.
  Access existing Q-A profile data. As with H.R. systems above.
  Write login ID correlation data into a meta directory. Appropriate when Password Manager deployment precedes meta directory installation, and login ID correlation is difficult with existing data in the directories being connected. Note: this leverages self-service registration of login IDs in Password Manager to populate a meta directory ([link]).
NOS / login scripts Automatically prompt users to change their passwords with the Password Manager web GUI during the network login process. Works well for primarily-NetWare environments, where transparent synchronization triggered from Novell password changes is not possible.
NOS / security policy Secure Kiosk Account (SKA) allows users to access self-service password reset by logging into the network as "help" with no password. Useful for any organization that deploys self-service password reset to a population of users who are primarily network-attached at the time of first login, and whose workstations are members of a login domain (Windows, NetWare, NIS, etc.).
IVR server Self-service password reset using a telephone, with either challenge-response authentication (numeric responses keyed on a touch tone phone), or biometric voice print verification. Appropriate when a significant fraction of password resets are due to people who have a problem with the password they type to establish a RAS connection.
Token authentication system Authenticate to self-service password reset with a token. This is better than Q-A -- appropriate if tokens are widely deployed.
  Manage tokens Only available for SecurID tokens -- appropriate if there are many SecurID hard or soft tokens deployed.


Technical architecture


Password Manager is designed for:

Figure [link] illustrates the Password Manager network architecture:


    Network architecture diagram (5)

Server configuration

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

(6) Each Password Manager server is configured as follows:

Depending on which integrations are activated, some of the following client software packages may be required:

    List of Client Software (7)

Target Integration

Client Software Used


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

Password Manager Server Configuration
Disk volume




Operating system files should be isolated and should have enough space for regular updates (patches, service packs etc.)

This is based on a 30 GB HDD. Additionally, if other software will be installed on the Password Manager server (e.g. Backup software, remote control software) then the required hard disk size may need to be increased. (note)

The                 Password Manager proxy server only needs client software                 installed if it is proxying connections of that                 particular type of target system.  For example, to                 manage a Lotus Notes password or account via a                 Password Manager proxy server, the Lotus Notes client                 software must be installed on the Password Manager Proxy (and                 is not required on the Password Manager primary or secondary                 server.) (note)

80 GB or more

Table (_label_tab:FullClientSoftwareTable) describes some of the client software that may be necessary to either manage passwords on a given target type or create tickets in a given incident management system.

log files 80 GB In case Password Manager log files become large, it is good practice to have them isolated from operating system and application files to prevent essential files from becoming corrupt.


Locking down servers

The Password Manager server houses sensitive data, including administrator credentials and in some cases private user profile information.

To protect this data, the Password Manager relies on host operating system and web server security measures, as well as sound application security features built directly into the software.

Following are instructions for locking down the host operating system and web server:

Operating system

The host operating system on the Password Manager server should be locked-down and fully patched, as defined below:

Only the following services are required on Password Manager servers:

The following services, at most, are needed on the Password Manager server:

If additional services are required during implementation, then Hitachi ID Systems will notify Hitachi ID Systems customer.

All other services should be disabled unless there is some specific reason (not related to Password Manager) to enable them.

The Password Manager server should not be a member of any domains. This reduces the risk of a security intrusion in the domain being leveraged to gain unauthorized access to the Password Manager server.

Packet filtering should be enabled on the Password Manager server, to block all inbound connections other than those to the web service, as shown in the figure below:


A hardened Password Manager server can be port scanned to identify available services. Following is a typical port scan result, prior to Password Manager installation:

    delli:/data/idan/vmware/win2ksrv# nmap -sT

    Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
    Interesting ports on  (
    (The 1551 ports scanned but not shown below are in state: closed)
    Port       State       Service
    443/tcp    open        https                   

    Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
    delli:/data/idan/vmware/win2ksrv# nmap -sU

    Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
    All 1459 scanned ports on  ( are: filtered

    Nmap run completed -- 1 IP address (1 host up) scanned in 91 seconds

The process table on the same server looks like this:


Note: VMWare entries reflect the fact that this sample was taken from a virtual machine.

This server was running with just the mandatory services described earlier.

Web server

The web server is a required component, as it provides all user interface components. It should therefore be carefully protected.

Since Password Manager does not require any web server functionality beyond the ability to serve static documents (HTML, images) and to execute self-contained CGI executable programs, all non-essential web server content should be removed.

If Apache is used, all non-essential modules should be commented out of the configuration rules.

If IIS is used, this means removing IISAdmin, Printers, Scripts and similar folders, as shown below:


The web server's scripting, indexing and data access subsystems should likewise be removed:


As an extra precaution, remote data services are disabled by removing the following registry keys:

ODBC drivers are also all disabled, both manually (remove data sources) and add this entry to the registry:

Multiple servers, load balancing and high availability

Transparent synchronization in particular and password management in general, can produce high transaction bursts, which may necessitate a large processing capacity.

There is no advantage to building a very large single Password Manager server, since the rate at which passwords can be set on a single system may depend on that system's load and capacity, as well as on client software, some of which are serialized. For example, the NetWare client only supports a single-threaded sequence of password resets.

Single threading clients that come with some managed systems, combined with high peak load and a requirement for high availability imply multiple load-balanced servers in a high-availability configuration.

Password Manager supports multiple servers, each of which is functionally identical and supports the same global user population. Load can be distributed between servers using DNS round-robin, or at the IP level with devices such as F5 Big/IP or Cisco Local Director.

Password Manager includes technology to dynamically replicate data updates between multiple servers and to have one server monitor another server's health.

The number of servers in production should generally be at least 2, to provide for high availability. To determine whether more servers are needed, first find values for the following variables:

Variable Description
U The number of users who will synchronize passwords using Password Manager.
A The average number of accounts per user.
T The average number of seconds per password reset (assume 3 seconds if not sure.)
Z The number of time zones in which users, whose passwords will expire, work. We assume that users are evenly distributed between time zones and that their passwords expire in the first hour of their workday.
P The password expiry interval (e.g., 30 days).


There should be at least this many production servers to handle peak load:

1 + [U / P x 7 / 5 / Z x A] / [60x 60x 5 / T]

In addition to production servers, there should normally be one development server, used to stage and test upgrades and configuration changes.

To summarize: a typical organization requires three servers -- two in production and one for development. Some organizations may require more servers in production, if they generate extremely high peak traffic.

A nice feature of Password Manager is that the development server can be switched into production and a production server can be switched into development. This makes upgrades fast and painless: develop on a test server until ready, then switch roles between the development and production master servers.

Network utilization and server location

As illustrated in Figure (_label_fig:combined-net-arch), Password Manager may be integrated with a broad range of existing network infrastructure.

User interaction with Password Manager is normally over HTTPS and is both light (requires little bandwidth) and tolerate of high latency.

Most Password Manager interaction with managed systems normally generates relatively little traffic. The sequence is normally login, reset password, logout. At night, Password Manager will generate a single larger burst of traffic to each managed system, to extract a list of user IDs from that system ([link]).

Password Manager interaction with some managed systems and in particular with NOS servers and some applications may be sensitive to high latency connections.

The nightly user list and the sensitivity of some managed systems' native protocols to latency mean that Password Manager servers should be installed as close as possible to the largest possible number of managed systems.

Ideally, three servers should be rack mounted near one another: a master server, a slave server and a development server. Master and development will periodically exchange roles, after upgrades and configuration changes.

Proxy servers

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 (8)

Backup and restore


All Password Manager software, configuration and data is normally stored on the file-system and in the registry of a single server.

The requirements for backing up Password Manager are:

If/when a restore is needed, just recover the file-system and registry onto a server with the same web service pre-installed. Re-run the nightly automation before bringing a restored server back into production.

Automatic discovery of login IDs


In most installations, Password Manager fetches a full list of user IDs from every managed system, every night. This is intended to reduce or ongoing manual administration of Password Manager and in particular to eliminate any need to manually enroll, update or remove users from Password Manager.

Selecting an authoritative system

In most installations, Password Manager is configured to "trust" one or more systems to be an authoritative source of Password Manager profile IDs. 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.

When user IDs are consistent

On systems that use login IDs consistent with the authoritative system, Password Manager is configured to automatically correlate IDs. Users automatically see these login IDs in their profile.

Inconsistent login IDs

When users have inconsistent login IDs on different systems, their non-standard login IDs have to be associated with their authoritative login ID.

If the correlating data exists in any format before Password Manager is deployed, then it should be used. Otherwise, correlating data must be acquired -- and this is typically done by prompting users to register their own alternate login IDs with a web GUI.

With an existing meta directory

If a meta directory already exists, then Password Manager can use it to retrieve login ID correlating data, either in real-time or in batch form.

In this case, no user registration of alternate login IDs is required.

With no pre-existing correlation


(12)In environments where users have different login IDs on different systems and where there is no reliable method or data set to correlate different IDs back to individual users, Password Manager can automatically prompt users to register and correlate their own login IDs.

Self-service login ID reconciliation is fast, inexpensive, secure and reliable. It significantly expedites system deployment in organizations where login IDs are different and cannot be automatically reconciled.

Self-service login ID reconciliation works as follows:

Self-service login ID reconciliation has major advantages over data cleansing projects and over approximate matching on attributes such as full names:

Automated correlation

If user IDs are different, but each system where a user has a login ID has some common attribute in the user record (e.g., SSN or employee number), then correlating data can be automatically generated.

Before pursuing this approach, validate that the common attribute is truly unique and widely populated. In particular, full names are not appropriate key attributes, as they are frequently mistyped, and many people share an identical full name (e.g., Michael Smith).

User enrollment


In many organizations, deployment of a password management system requires a user enrollment process. Users may have to provide personal data such as answers to authentication questions (which can subsequently be used to authenticate users who forgot their passwords or triggered a lockout). Users may be asked to attach their non-standard IDs to their profiles. Users may have to provide biometric samples, likewise used for non-password authentication in the event of a future password problem. Finally, users may simply be asked to review and agree to some corporate policy, for example regarding password sharing or writing down their password.

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

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

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.

Following is a sample registration request e-mail:

  To all users:

  Acme, Inc. is activating a password management system on our network.
  This system will help you to manage your own passwords:

  * It will help you to synchronize passwords for all of your systems.

  * If you forget your password, you will be able to reset it yourself,
    without calling the help desk.

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

  * Click on the URL below.

  * In your web browser, log in with your Windows ID and password.

  * Select the ``Personal information'' screen and fill in the blanks.
    Your answers on this form will be used to verify your identity
    should you forget your password in the future.

  * Select the ``Add login accounts'' screen and type every login ID /
    password pair that you currently use.  This lets our system verify
    what systems you log into.

  To register now click here --->         http://password.acme.com/

  After you have registered, you will still have to change your Windows
  password every 60 days.  When you do that, all your other passwords
  will be automatically set to the same new value.

  One password is easy to remember: please find and destroy any notes
  you may have that contain your system passwords.

  You can also change your passwords or registration information any time,
  using the same URL (above).

  After registering, if you forget or disable your Windows password, you
  can just log into your workstation with the ID "help" and no password,
  and follow the on-screen instructions to fix your problem.  Please
  *do* put a sticky note on your monitor to remind yourself of this

  From now on, passwords will be subjected to a more secure password
  policy, to make them harder for intruders to guess.  Please make sure
  that your new passwords:

  * Have at least 7 and at most 8 characters.

  * Have at least one digit and at least two letters.

  * Have both lowercase and uppercase letters.

  * Are not derived in any way from a dictionary word or name.

  Do change your passwords at least every 60 days and do not reuse old
  passwords (ever).

  If you have any questions, please contact password_support@acme.com.

  Thank you!

  -- The I.T. department.

Maximizing adoption rates

Password Manager is intended to deliver value to an organization, by reducing support costs, improving user service and strengthening security.

The following sections describe some strategies to increase user adoption of Password Manager, which maximizes its value:

User education

Provide users education about password management generally, and Password Manager in particular. Education may be wholly electronic (e.g., how-to and frequently-asked-questions web pages) and in some organizations may be incorporated into a broader training schedule, where users receive live instruction.

If providing purely electronic education, get the users' attention. For example, one Password Manager customer admonishes users: Passwords are like underwear -- change them often and don't share them with your friends.

Incentives for registration

Some organizations that deployed Password Manager have had great success with incenting users to register early. A moderate number of inexpensive prizes (such as restaurant gift certificates), available on a random draw to early registrants or a small number of expensive gifts (such as PDAs, smart phones or holiday airfare) have been used successfully to motivate users to enroll.

Forced enrollment

Some organizations have opted to force users to enroll with Password Manager -- which typically means completing their personal Q&A profile. This is done by associating users who will be forced to enroll with an Active Directory GPO that replaces their normal login shell (explorer.exe) with a kiosk mode web browser directed at the enrollment page. Users are removed from the AD group that activates this GPO on successful enrollment.

This strategy is very effective, but should be preceded with a user education program advising users to enroll voluntarily. Organizations pursuing mandatory enrollment should have strong and vocal executive support prior to activating this feature.

Enrollment in general and forced enrollment in particular should be paced -- not all users should be invited to or required to enroll at the same time. A user enrollment / invitation pace of 500 to 1000 users per day is reasonable in most organizations.

Registration during assisted service

Some organizations choose not to automatically prompt users to register, but instead register users when they first call the help desk with a password problem, after Password Manager deployment.

This approach to user registration technically works, but tends to lengthen service desk problem resolution time, because the analyst is registering and educating the user, not just resolving a simple problem. Avoid this approach if possible, and if it is taken, plan on increased password problem incident support cost for 12--18 months.

Incentives for utilization

Some organizations have increased user adoption rates for self-service password reset (rather than assisted reset) by offering prizes, similar to those for enrollment, to users of the self-service system.

This approach should be used with care, as users with no password problem at all may use the system to qualify.

Adjusting response time with assisted service

Some organizations intentionally reduce the level of service for assisted password problem resolution. For example, users may have to wait through a recording on the automatic call director (ACD) system that explains self-service password reset before they can talk to a human analyst to resolve their problem.

Conversely, organizations where assisted resolution of password problems is very fast and friendly may get poor user adoption of self-service, since assisted service is so convenient.

Plan for user adoption

The strategy for user enrollment, education and service adoption depends heavily on corporate culture.

The common thread with every approach is that planning is required, and budget should be set aside for user education and user incentive programs.

High adoption rates do not happen with technology alone.

Measuring value

In many organizations, the help desk pays for Password Manager and expects to measure a direct economic value from it. The following sections discuss how Password Manager utilization and value can be measured.

Measuring activity

Password Manager records all activity in a session log table. This includes full sessions, with login time/date, operations, the identify of users and support analysts, results on managed systems and more.

Use the SESSREP program provided with Password Manager to extract a summary of this activity from a given time period.

Once Password Manager is deployed, require support analysts to carry out all password resets with Password Manager, rather than with native tools. If possible, disable their access to native password resets. This will ensure that all password resets are recorded in Password Manager and yield usable metrics.

Trend analysis

Over time (e.g., monthly), run SESSREP to record both user access to Password Manager (registration, synchronization, self-service reset) and analyst access (assisted reset incidents and duration).

Plot registration against total user population, to illustrate how many users have registered, how many remain and what the estimated completion date will be.

Plot password synchronization over time, to measure basic utilization of the system.

Plot the sum of self-service password reset and assisted reset over time, to show how effective password management reduces the frequency of password problems.

Plot the fraction of password resets that are self-service over time, to show how users transition from assisted service to self-service.

User productivity

User productivity benefits are primarily due to reduced frequency of password problems. Refer to the trend analysis in the previous section for an analysis of reduced password problems over time.

Support cost

Password-related support cost is due entirely to assisted password resets. Refer to the trend analysis in the previous section for an analysis of reduced volume of help desk password resets over time.

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 both the administrator (nph-psa) and self-service (nph-pss) web GUIs to change every password for this user.

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 analysts can log into the application. Create a test analyst ID for this, either internally on Password Manager or on another system if you use pass-thru authentication.

Directory integration

If you integrated with a corporate or meta directory, and Password Manager accesses user and login ID information on that system, verify that you can still log in with the ID of a user who does not exist locally on the Password Manager server. Test with both nph-psa, nph-pss, nph-pss and pushpass.

Sending e-mails

If you implemented e-mail notifications for registration, clear a test user's profile and verify that the user does receive an invitation to register.

If you implemented e-mail notification of events (e.g., password change, intruder lockout, etc.), trigger every relevant event and verify that e-mails were sent out appropriately.

Creating call tracking system ticket

If you implemented call tracking system integration, trigger every relevant event and verify that tickets were opened appropriately. Open the tickets in the call tracking system to verify that they are constructed correctly.

IVR integration

If you implemented an IVR user interface, verify that it is able to authenticate a test user and reset that user's passwords.

User registration

If you implemented web-based registration, verify that a test user can update his own Q&A profile or login aliases, as appropriate.

If this feature is enabled, also verify that help desk analysts can register Q&A data on behalf of callers in nph-psa.

Changes to target system configuration


Changes made to the configuration on some targets can have an impact on Password Manager. Arrange with your change control manager (or your system and/or application owners) to notify you of changes to individual system configuration.

For example:

Use a test server to validate configuration changes such as installation of updated client software or modified scripts before you enable those changes in production.

Monitoring service health


You can check service health by monitoring the contents of the service log files in the temporary logging directory, or by using the Password Manager administration module (nph-psa.exe). The log files should give few or no warnings, and no errors.

To check service health using the Password Manager administration module (nph-psa.exe):

  1. Log into the Password Manager administration module (nph-psa.exe).
  2. Click Server monitor -> Service to see the Monitor Password Manager server page.
  3. Check the status of the services.
  4. Click Manage next to the service you want to check to see the Password Manager server manager page for that service.
  5. Read the contents of the log in the temp directory in the field at the bottom of the page.
  6. Check the Windows Event Viewer for warnings or errors.
  7. Use the Windows Task Manager to monitor system CPU, memory and I/O load.

Monitoring the pushpass service


The psppmon program monitors the pushpass service and sends out an e-mail when pushpass starts up or goes down. The message will state at what time pushpass went down, and whether it was restarted. If pushpass has stopped, the service appends the last 200 lines of the specified log file to the email.

psppmon can execute a program, such as a batch file to restart the service, if pushpass is down for too long. By default, psppmon will try to execute the program once. You can specify a number of times that it will retry while pushpass is down.

The service will monitor the Password Manager databases every 24 hours from the time it is started. If any of the databases double in size or drop by half, psppmon will send a warning e-mail.

Monitoring transparent synchronization on Windows servers


Monitor the health of the transparent synchronization DLL (psintcpt.dll) on Windows NT PDCs and Windows 2000 DCs. Run netstat -an to see whether there are many (more than 20 or 30) TCP connections pending between the PDC/DC and the Password Manager server. If so, there may be a problem with the Password Manager server.

Monitoring utilization

Monitor Password Manager utilization to determine the progress of your deployment and to ensure the success of Password Manager operation. You can do this using the Password Manager administration module (nph-psa.exe), or with the sessrep program.

Password Manager includes a facility to allow help-desk users, with the specified right, to run reports on Password Manager targets, users, usage, and events.

Use the sessrep program to provide a quick statistical report, in ASCII text format, on the usage of all Password Manager modules.

Randomizing target system credentials


Use the admchgpw program to change the administrator passwords used by Password Manager to log into various systems. Run admchgpw periodically to ensure that Password Manager target system credentials are random and secure.

After each password change, the new value is verified, and if the change was successful, it is stored in the Password Manager database host table.

Verify that password verify and reset operations continue to work on every target system after running admchgpw.

Making backups


Please refer to (9) for details about making backups of production Password Manager servers.

Purging old Q&A data


If entire question sets or individual questions are removed from Password Manager, related answers that were already defined by the end user will remain in the response database. This data is left in the database table in case the questions are returned later.

As a result, deploychk and possibly sessrep produces invalid data and reports.

Also, when a question is created and then deleted, and then re-created (for example, if it was deleted in error), it will be given a new QID and the previously defined answers would no longer match, and may be considered invalid.

To purge this data, pack and re-index the response database with the dbop program.


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 I.T. organization, it is important to have powerful and visible project sponsorship and to involve all stake-holders as early as possible.

This document outlines numerous best practices regarding technical architecture, security policies, user enrollment, maximizing user adoption and ongoing administration. These should be taken as guidelines and combined with specific requirements of each organization to produce an implementation design and project plan.