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:
Clearly identifying the goals of a project which will deploy password management technology.
Who to involve in the project and when.
How to approach project design and recommended design choices.
Recommendations for a network architecture, for server configuration, etc.
Where and how data can be automatically loaded into the password management system, to minimize ongoing administration.
How to inform users about the system and whether / how to prompt users to register personal information.
Strategies to ensure how utilization, to maximize the value of the system.
How to measure the value of the system.
Overview of how to manage the deployed technology and how to gradually expand the system's functionality and value.
A password management system is generally intended to deliver three benefits:
This is due to fewer passwords to remember, a simpler password change mechanism and faster resolution of password and intruder lockout problems.
This is due to reduced help desk calls for password reset, faster resolution of remaining calls and reduced escalation of login problems.
This is due to stronger and more consistent password policy enforcement, more robust authentication of users who forgot their passwords and enforced password expiry across all systems.
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
|Password problem resolution will be streamlined with a single web interface and be reduced to 2 minutes/call.|
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
|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|
|Provide mandate and budget for the project. Ensure cooperation from other stake-holders.|
|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.|
Each Password Manager installation should have a Password Manager software and server administrator. Following is a recommended skill-set for this person:
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.
Password synchronization is any process or technology that helps users to maintain a single password, subject to a single security policy, across multiple systems.
Password synchronization is an effective mechanism for addressing password management problems on an enterprise network:
There are two ways to implement password synchronization:
One of the core features of Password Manager is password synchronization.
Password Manager implements both transparent and web based password synchronization.
Self-service password reset is defined as any process or technology that allows users who have either forgotten their password or triggered an intruder lockout to authenticate with an alternate method and repair their own problem, without calling the help desk.
Users who have forgotten their password or triggered an intruder lockout may launch a self-service application using an extension to their PC login prompt, using their own or another user's web browser or through a telephone call. Users establish their identity, without using their forgotten or disabled password, by answering a series of personal questions, using a hardware authentication token or by providing a biometric sample. Users can then either specify a new, unlocked password or ask that a randomly generated one be set.
Self-service password reset expedites problem resolution for users after a problem has already occurred and reduces help desk call volume. It can also be used to ensure that password problems are only resolved after strong user authentication, eliminating an important weakness of many help desks: social engineering attacks.
One of the core features of Password Manager from Hitachi ID Systems is self-service password reset.
Password Manager includes an assisted password reset web portal, which allows IT support staff to help callers without having direct administrative access to target systems:
For example, support staff may sign into Password Manager using their Active Directory ID and password, with Password Manager validating the membership of each support technician in a designated AD security group and granting appropriate Password Manager privileges based on that group membership.
Note that the same, different or overlapping security questions can be used for assisted and self-service authentication processes.
Assisted password reset reduces the cost of password support calls and ensures that such calls are handled in a consistent, secure fashion.
Organizations that have RSA SecurID tokens should allow users to clear or reset their PINs, resynchronize token clocks with the ACE server and enable/disable their own tokens. All of this should be accessible in a self-service facility, with password authentication.
There is no security impact to the above -- PIN resets in particular substitute one secret (a user's password) for another (the same user's PIN).
Support staff should be able to perform the same functions, after a reliable caller authentication process. Some organizations may also allow empower staff to issue emergency access numbers for users who misplaced their token and need access to infrastructure protected by token authentication.
Enabling self-service access to emergency pass codes reduces the security of tokens from two factor (hardware + PIN) to one factor (the password used to access self-service). This feature should only be enabled if token security can be safely reduced to password security.
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:
All users should be able to access routine password changes (authenticated with a current password) and self-service password reset from a web browser.
Most organizations will make this facility accessible only from inside the corporate network. Organizations with large numbers of mobile or external users may also expose this facility on their Extranet. Extranet access to Password Manager is normally provided through a reverse web proxy, where users access HTTPS content on the proxy, which fetches the actual pages from a Password Manager server in a protected subnet.
Users often forget their initial network login password or inadvertently trigger an intruder lockout. These users should be able to get assistance, reset their network or local password, clear intruder lockouts and get back to work.
Since these users have a problem with their PC login, they cannot access a conventional web browser or client/server application with which to resolve their problem. The problem these users face is how to get to a user interface, so that they can fix their login problem and subsequently access their own PC desktop.
This problem is especially acute for mobile users, who use cached domain passwords to sign into their PC and who may not be attached to the corporate network when they experience a forgotten password problem.
When users forget their primary password or trigger an intruder lockout, they are in a Catch-22 situation: they cannot log into their computer and open a web browser but cannot open a web browser to fix their password and make it possible to log in.
Password Manager includes a variety of mechanisms to address the problem of users locked out of their PC login screen. Each of these approaches has its own strengths and weaknesses, as described below:
users continue to call the help desk.
Ask a neighbor:
Use someone else's web browser to access self-service password reset.
Secure kiosk account (SKA):
Sign into any PC with a generic ID such as "help"
and no password. This launches a kiosk-mode web browser
directed to the password reset web page.
Same as the domain-wide SKA above, but the universal "help" account
is replaced with one personal account per user. For example,
each user's "help" account could have their employee number
for a login ID and a combination of their SSN and date of birth
for a password.
Same as the domain-wide SKA above, but the "help" account
is created on each computer, rather than on the domain.
Telephone password reset:
Users call an automated system, identify themselves using
touch-tone input of a numeric identifier, authenticate with
touch-tone input of answers to security questions or with
voice print biometrics and select a new password.
Deploy physical Intranet kiosks at each office location.
Windows XP: Install a GINA DLL on user computers, which adds
a "reset my password" button to the login screen.
GINA Extension Service:
Similar to the GINA DLL, but uses a sophisticated service
infrastructure to modify the UI of the native GINA, rather
than installing a GINA DLL.
The equivalent of a GINA DLL, but for the login infrastructure
on Windows Vista/7/8.
No other product or vendor supports as many options for assisting users locked out of their PC login screen.
The solution(s) that will be deployed to assist locked out users must be selected and appropriate change control and infrastructure must be provided for.
Users at home, traveling, or who frequently work at locations outside the corporate network may have problems with the passwords they use to connect to the corporate network.
These users benefit from access to self-service password reset on an IVR system. Such a system allows a traveling worker to reset his RAS password from a hotel room, for example.
IVR access to self-service password reset should be enabled whenever the number of users who have problems with network-connection passwords (RAS, VPN) is significant.
Users who forget their passwords can dial an IVR system with any telephone and initiate a password reset. Authentication using either touch-tone entry of personal secret information or using voice print verification is supported. Existing IVR systems can be extended using a Password Manager remote API or Hitachi ID Telephone Password Manager -- a turn-key IVR system specifically designed for password resets.
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 (@, #, $).
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.
There are 94 possible characters in a password (lowercase, uppercase, digits, 32 symbols on a US keyboard).
Note: the total search space is no less than 947 = 64,847,759,419,264 possible passwords.
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.
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:
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:
From the above, it is clear that Q&A authentication data must consist of static characteristics of the user. Questions such as SSN, mother's maiden name, city of birth, etc. are appropriate. Since answers to such questions may be vulnerable to social engineering attacks, it makes sense to use as many questions as feasible and to combine pre-defined questions with user-entered ones.
Users are authenticated to a password reset system by answering questions that only they should know. Such questions are frequently personal and may be protected by privacy regulations in some jurisdictions.
If privacy protection legislation applies in a given jurisdiction, it may be necessary to define two sets of questions that users may be asked to answer: one set that applies to self-service authentication, to which privacy legislation does not apply, and a second set that will be used by I.T. support analysts, which does not contain sensitive personal information.
Some oft-used questions that users are asked to answer during registration and which may then be used to authenticate users include:
Sample security questions, which may have alpha-numeric questions and so are suitable for a text user interface, include:
To ensure that authentication data is of good quality, users should be required to provide answers to some standard questions, where the questions were selected to ensure that they are relatively difficult to "socially engineer."
The Q&A process should be protected by an "intruder lockout" security feature, so that repeated failed attempts to authenticate as a given user trigger lockout of that user's profile and possibly a security alarm.
The limitation of pre-defined questions is that there are only a finite number of possible questions. An intruder could readily discover what those questions are and research answers to every possible question ahead of time. A determined intruder would not be caught by an intruder lockout mechanism.
To overcome this difficulty, a challenge-response system should combine both pre-defined questions (where the difficulty of guessing answers can be estimated) with user-defined questions (where the questions themselves are harder to guess, but the answers may be easier for an intruder to come by). The user-defined questions should only be presented to a user attempting authentication after the standard questions have been successfully answered.
While user-defined questions are not guaranteed to be hard to guess, they are less predictable than standard questions and make social engineering attacks significantly more difficult.
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.|
|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.|
Password Manager is designed for:
Password Manager is installed on hardened servers. All sensitive data is encrypted in storage and transit. Strong authentication and access controls protect business processes.
Multiple Password Manager servers can be installed, using a built-in data replication facility. Workload can be distributed using any load-balancing technology (IP, DNS, etc.). The end result is a multi-master, distributed architecture that is very easy to setup, as replication is handled at the application layer.
Password Manager uses a normalized, relational and indexed database back end. All access to the database is via stored procedures, which help to minimize communication overhead between the application and database. All Password Manager code is native code, which provides a 2x to 10x performance advantage as compared to Java or .NET
Open standards are used for inbound integration (SOAP) and outbound communications (SOAP, SMTP, HTTP, etc.).
Both the Password Manager user interface and all functionality can be customized to meet enterprise requirements.
Password Manager is easy to set up and requires minimal ongoing administration.
Figure [link] illustrates the Password Manager network architecture:
A Password Manager server is typically configured based on standards set out in the data center where it will be installed.
Client Software Used
The file-system of the servers may be segmented as follows:
|Password Manager Server Configuration|
Operating system files should be isolated and should have enough
space for regular updates (patches, service packs etc.)
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.|
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:
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:
Only the following services are required on Password Manager servers:
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 192.168.100.8 Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ ) Interesting ports on (192.168.100.8): (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 192.168.100.8 Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ ) All 1459 scanned ports on (192.168.100.8) are: filtered Nmap run completed -- 1 IP address (1 host up) scanned in 91 seconds
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.
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:
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:
|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.
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.
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].
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:
This is normally done by scheduling a backup to run after the Password Manager nightly automation has completed, as that automation creates fresh copies of the same files in the psupdate directory and those files are not used thereafter. The backup then skips the same files in the cgi-bin directory.
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.
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.
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.
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.
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.
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.
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:
In contrast, data cleansing projects require months of effort from multiple full time staff.
In contrast, both a data cleansing project and approximate matches on full name will yield erroneous matches, which will later constitute security breaches, including allowing one user to reset another's password.
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).
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:
Figure [link] shows a dashboard that tracks enrollment progress.
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 feature. 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 email@example.com. Thank you! -- The I.T. department.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
The following sections describe the routine ongoing administration of Password Manager:
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.
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.
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.
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.
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.
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.
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.
If you implemented an IVR user interface, verify that it is able to authenticate a test user and reset that user's passwords.
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 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.
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.
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):
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.
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.
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.
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.
Please refer to (9) for details about making backups of production Password Manager servers.
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.