Enterprise-Scale Password Management With Hitachi ID Password Manager

Abstract

As users access ever more systems and applications, they accumulate passwords. User passwords may have different values, expire on different schedules and be subject to different composition rules. As a result of this complexity, users frequently write down their passwords or forget them, leading to security and support cost problems.

Effective password management addresses the problem of password complexity: Password synchronization helps users to remember a single, strong and frequently changed password. Self-service password reset enables users who forgot or locked out their password to resolve the problem without calling the help desk. Assisted password reset makes the remaining help desk calls shorter and ensures that callers are reliably authenticated prior to receiving service.

Introduction

This white paper describes the Hitachi ID Password Manager (formerly P-Synch) password management software. It identifies business problems associated with the operation of password systems and describes how these problems are resolved using Password Manager features.

Password Manager is a total password management solution. It is intended to reduce the cost of ownership of password systems and simultaneously improve their security. This is done through:

Password synchronization: Helping users to maintain a single, strong password across their login IDs.
Password policy: Enforcing robust password composition, expiration and history rules across all systems, regardless of the capabilities of their native password policy mechanisms.
Self-service password reset: Enabling users who have forgotten their password or triggered an intruder lockout to self-authenticate and resolve their own problem, without incurring a call to the help desk.
Assisted password reset: Streamlining password reset calls to the help desk, so that they are consistently secure and short.

Password Manager may be deployed to support internal user populations, characterized by modest numbers of complex users (i.e., fewer than a million users, typically with 5 -- 7 login ID/password pairs each). Password Manager may also be deployed to support Extranet user populations, characterized by larger numbers of simple users (typically over a million users, but with just a single LDAP ID each and infrequent logins).

Business Drivers: Operational Support for Password Systems

Users who must manage multiple passwords to corporate systems and applications have usability, security and cost problems.

Users have too many passwords. Each password may expire on a different schedule, be changed with a different user interface and be subject to different rules about password composition and reuse.

Some systems are able to force users to select hard-to-guess passwords, while others are not. Some systems require that users change their passwords periodically, while others cannot enforce expiration.

Users have trouble choosing and hard-to-guess passwords.

Users have trouble remembering passwords, because they have too many of them or because they chose a new password at the end of the day or week, and didn't have an opportunity to use it a few times before going home.

These problems drive users to choose trivial passwords, to avoid changing their passwords and to write down their passwords. All of these behaviors can compromise network security.

When users do comply with policy and regularly change their passwords to new, hard-to-guess values, they tend to forget their passwords and must call the help desk.

Password and login problems are the top incident type at most IT help desks, frequently accounting for 25% or more of total call volume.

In addition to the above security and support cost problems, users simply don't like memorizing and typing passwords. Password management is a nuisance that contributes to a negative perception of IT service.

Despite all these problems, passwords will continue to be needed for years to come:

Passwords are significantly less expensive to deploy and support than other technologies.
Other authentication technologies, such as biometrics, smart cards and hardware tokens, are typically used along with a password or PIN. i.e., "something you have" (smart card, token) or "something you are" (biometric) plus "something you know" (password, PIN).
Passwords are an important backup to other authentication technologies:
1. Hardware devices can be lost or stolen or simply left at home.
2. Some devices from which users need to access corporate systems, such as smart phones and home PCs, may not support more advanced authentication methods.

Since passwords are not going away, and remain difficult for users to manage, solutions are needed to help users more effectively manage their passwords.

Technical Challenges: Hard-To-Support Passwords

Enabling synchronization and self-service reset for passwords on centralized servers is reasonably straightforward. Technical problems arise, however, with locked out users, mobile users, cached credentials and PKI.

Locked Out Users

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 workstation 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 workstation desktop.

This problem is especially acute for mobile users, who use cached domain passwords to sign into their workstation and who may not be attached to the corporate network when they experience a forgotten password problem.

Cached Credentials

Windows workstations cache user login passwords -- typically Active Directory or NetWare NDS passwords. This is done for two reasons:

To enable users to log into their workstation while detached from the network (example: traveling laptop).
To automatically sign the user into resources, such as shared file and print services, without having to ask the user to retype his password.

When a user changes his password using the network client software on the workstation (e.g,. ctrl-alt-del method), the network client automatically updates its cached password.

On the other hand, if a user is logged into his workstation and simultaneously his password is reset elsewhere on the network -- for example by the help desk or by the user himself on a second concurrently logged in workstation, then the cached password on the workstation will be invalidated.

Similarly, if the user forgets his password and it is reset on the network while his PC is disconnected (e.g., remote), the new password will not be usable on the workstation until the workstation is re-attached to the network.

An invalid cached password causes several problems:

If the user's PC is not attached to the network when his password changes, the user will be unable to use the new password on his PC until he re-attaches to the network.
If the user's PC is attached to the network and the user attempts to access a network resource (file server, print queue, etc.), the workstation may send an incorrect, cached password to the network resource, which will increment the user's "number of invalid login attempts" counter. Repeated connection attempts may trigger an intruder lockout.

Replication Delays

(1)Active Directory does not propagate cleared intruder lockout flags on an expedited schedule. This can create problems for remote users who inadvertently trigger a lockout and subsequently call a central help desk for assistance. The help desk will typically clear the user's lockout on a domain controller near the help desk. This lockout may take a long time (hours) to reach the domain controllers against which the user wishes to authenticate or which service network resources that the user wishes to access.

This problem is especially acute in global organizations, with hundreds of domain controllers that employ a centralized user support function.

Note that AD password change replication is described here:

http://technet.microsoft.com/en-us/library/cc772726.aspx

Mobile, Disconnected Users

Traveling users typically log into their workstations using cached passwords. If they forget the cached password, offering them remote (e.g., over the telephone) assistance is either very expensive or insecure:

Expensive: the user must physically bring (or mail) the laptop to a corporate location, where a domain authentication is possible.
Insecure: alternately, the help desk can give the traveling user the login ID and password of an alternate or administrative ID over the phone, thereby compromising a local credential.

While the frequency of password reset incidents for traveling users is typically low, the cost per incident is 10x to 100x higher than for network-attached users.

Managing PKI Passwords

Public key infrastructures typically deploy certificate files on user workstations. This enables users to access encrypted documents and e-mail and send authenticated and secure messages while off-line.

Certificate files are typically encrypted and decrypted using a user's personal password. In other words, users have a "PKI password," which is not necessarily stored on any server. Rather, this password is used to unlock the user's personal certificate file.

This is true of both standards-based PKI (e.g., using x.509 certificates) and proprietary PKI (e.g., Lotus Notes ID files).

"PKI passwords," including Lotus Notes ID file passwords, are difficult to support, because they cannot be administratively reset:

The PKI certificate may exist in multiple locations (e.g., multiple workstations, the user's home directory, a flash drive, etc.).
Some or all of these storage locations may be inaccessible to a central, network-attached password management system.
The PKI certificate must be decrypted, using the current password, before it can be re-encrypted with the new password. In other words, there is no notion of an administrative password reset, which does not rely on knowledge of the current password.

Password Manager Features

Password Manager is designed to reduce the cost and improve the security of password systems:

Password Synchronization

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:

Users with synchronized passwords tend to remember their passwords.
Simpler password management means that users make significantly fewer password-related calls to the help desk.
Users with just one or two passwords are much less likely to write down their passwords.

There are two ways to implement password synchronization:

Transparent password synchronization, where native password changes, that already take place on a common system (example: Active Directory) are automatically propagated through the password management system to other systems and applications.
Web-based password synchronization, where users are asked to change all of their passwords at once, using a web application, instead of continuing to use native tools to change passwords.

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

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 or locked out a password may launch a self-service application using an extension to their workstation 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.

Assisted Password Reset

Password Manager includes an assisted password reset console, which allows IT support staff to help callers without having direct administrative access to target systems:

Help desk analysts sign into Password Manager with a web browser.
Analysts can be authenticated using IDs and passwords internal to Password Manager or use pass-through authentication to an existing system.
For example, help desk analysts may sign into Password Manager using their Active Directory ID and password, with Password Manager validating the membership of each analyst in a designated AD security group and granting appropriate Password Manager privileges based on that group membership.
From the Password Manager web interface, analysts can search for the caller's profile by login ID or full name.
Analysts can be required to authenticate the caller -- for example by keying answers to some of the user's personal questions, which Password Manager can validate against an internal database or external directory.
Note that the same, different or overlapping question-and-answer data may be used for assisted password reset and for self-service authentication.
Once both the analyst and caller have been authenticated, analysts can reset the caller's password, lock or unlock the caller's access to Password Manager or update the caller's profile. Assisted password resets may be configured to also expire the new password, requiring the user to change it on the next login.
All transactions -- analyst login, user profile lookup, successful or failed password reset and more may trigger e-mails to the user, to the analyst or to a third party, such as a security officer. The same events can also trigger automatic creation, update or closure of tickets in an incident management system.
Since only a single, simple web interface is used, an assisted password reset is normally completed in 1--2 minutes.
User-filter and account-filter plug-in points are available, making it possible to delegate password reset capabilities to managers, platform administration groups and regional help desks and to ensure that such groups get only appropriate password reset and user profile lookup privileges.
At no point in the process does an analyst require administrative access to the systems where passwords are being reset. Instead, Password Manager uses its own credentials to sign into target systems, and these are encrypted in an internal Password Manager database.

Assisted password reset reduces the cost of password support calls and ensures that such calls are uniformly processed in a consistent, secure fashion.

Password Policy Enforcement

Password Manager is normally configured to support a single, global password policy, to ensure that all new passwords will be acceptable to every 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 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:

Complexity requirements ensure that users do not select easily-guessed passwords. Example rules are: disallowing any permutation of the user's login ID, password history, requiring mixed letters and digits, forbidding dictionary words, etc.
Representational constraints limit what can be physically stored in a password field on a given system. Usually there are just two such rules: maximum length and allowable character set.

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.

Password Expiration / Aging Enforcement

To enforce password expiration and to get users to trigger web-based password synchronization, Password Manager is configured to detect upcoming password expiration on individual systems (e.g., Windows or NetWare servers, LDAP directories) and to prompt users to change all of their passwords at once with the Password Manager web GUI, rather than one system at a time with native password change screens.

Typically password expiration is configured so that users change their passwords with Password Manager on a shorter schedule than any other application or system password. This way, users are never prompted to change passwords by anything other than Password Manager itself or systems that automatically trigger Password Manager transparent password synchronization.

Early notification of upcoming password expiration is a viable alternative to transparent password synchronization, especially in cases where it is impossible to trigger synchronization from the primary login system that users most often use.

Users can be notified of upcoming password expiration by e-mail. Alternately, a small client program can be added to global network login scripts, which checks whether the user currently logging in is on the list of "soon to expire" users and if so opens the user's default web browser to a URL that asks the user to change his passwords with a web GUI, using Password Manager.

Users can be forced to change their passwords when they sign into the network, by opening a kiosk-mode web browser to the password change screen and requiring the user to change passwords before they can close this browser.

The timing of password expiration can be calculated based on the most recent password change a user made with Password Manager, in addition to upcoming expiration on a managed system.

Password Reuse

In Password Manager, password history is "infinite" by default. Unless specifically allowed, users are prevented from reusing passwords at all. Where password reuse is allowed, it is based on a time interval, rather than the number of intervening password changes. Password history is stored in a one-way, non-reversible hash (SHA-1 plus 64-bit random salt).

Password Synchronization: Technical Architecture

Web-Browser Password Synchronization

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

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

Password change and/or synchronization from a web browser works as follows:

User: decides to change his password(s) or has been prompted to by e-mail or a "web pop-up" during the login process.
User: manually or automatically opens a web browser, navigates through the Intranet to the Password Manager application.
Password Manager web server: prompts the user to type his network login ID.
User: types his network login ID.
Password Manager web server: prompts the user to type his current NOS password.
User: types his current password.
Password Manager web server: validates the password against the indicated system.
... repeat if authentication failed, lockout if too often.
Password Manager web server: prompts the user to enter a new password.
User: types a new password, selects some or all accounts.
Password Manager web server: validates password quality, possibly returns the user to previous step.
Password Manager web server: resets the password on selected systems to the new value.
Password Manager web server: displays a status page to the user.
Password Manager web server: creates a ticket on an incident management system.
Password Manager web server: sends the user a confirmation e-mail.

Password Manager exposes a web user interface using a set of self-contained CGI programs, compiled as Windows binaries and running under any standards-compliant web server on the Windows platform.

The Apache and IIS web servers are supported. The CGI architecture eliminates the need for an application server -- no .NET or Java runtime is needed. This both simplifies the architecture and improves runtime performance.

The CGI user interface programs accept input forms, assemble new screens using skin files (see below) and display new forms. CGI programs access identity profile data in an identity cache on the Password Manager server, which in turn may draw data from an LDAP directory or database server. They can also communicate with services on the Password Manager server and run connectors and plug-in programs to push data out to other systems (e.g., e-mail, help desk systems, SMS messages).

As mentioned above, the Password Manager user interface is constructed using skin files, which are just text files with a set of HTML snippets. Multiple skin files may be installed on the same Password Manager instance, to support multiple "look and feel" skins as well as multiple language translations.

The HTML snippets in skin files are highly regular. To reduce administration and customization effort, they are generated using a text macro system (m4) from macro files. Macros define constructs such as standard page headers and footers, table headers and footers, button faces, color schemes, fonts, etc.

All text generated by Password Manager also comes from the skin files. In the macro system, all human-language text is drawn from a messages file. It is this file which gets translated when adding a human language to the Password Manager user interface. This is advantageous, since the messages file has no markup and is easy for translation agencies to deal with. All HTML markup and button images are automatically generated from these message files.

Web access architecture diagram (3)

Transparent Password Synchronization

(4)When users change their password natively on a system where a password synchronization trigger has been installed, the new password is subjected to an extra password policy and, if accepted, is changed both locally and on other systems where the user has accounts.

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

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

Transparent password synchronization, triggered by a native password change on a monitored system works as follows:

User: decides to change his password(s) or has been prompted to during the login process.
User: enters his login ID, current password and desired value.
Login server: validates password quality internally, then calls a Password Manager library to further validate password quality.
Password Manager library: contacts the Password Manager server; establishes an encrypted connection; forwards a request for password policy validation.
Password Manager server: validates password quality; returns result. In the event of an attempted policy violation, Password Manager may send a message directly to the user by e-mail or a Windows pop-up message; may create an incident management system ticket and so on.
Login server: updates the user's password field internally, calls the Password Manager library to notify it of the successful change. Note that a failure to meet the Password Manager policy will normally block the initial password change from happening.
Password Manager library: contacts the Password Manager server; establishes an encrypted connection; forwards a request for password synchronization.
Password Manager server: queues up the new password for synchronization.
Password Manager server: resolves the single queued event to a list of passwords that must be set for this user (one per account).
Password Manager server: administratively sets the user's passwords on each system to the new value.
Password Manager server: in the event of failure, re-queues and retries; may send the user one or more e-mails to notify of the problem; may create a ticket on an incident management system to alert someone of a problem.

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

Transparent synchronization architecture diagram (5)

Password Reset: Technical Architecture

Authenticating Users Without Passwords

(6)Users may authenticate into Password Manager as follows:

On a web GUI:
- By typing their current password to a trusted system (for example Windows / Active Directory, z/OS, RADIUS, etc.).
- By answering a set of system-selected personal questions, whose answers may either be stored inside the Password Manager server or may be validated on an existing system (Oracle, LDAP, mainframe and so on).
- Using a security token (e.g., SecurID pass-code or other device).
- Using a PKI certificate or smart card.
Using a telephone:
- By keying in one or more personal identification numbers (e.g., employee number, date of hire, driver's license number).
- By matching a voice print sample taken at time of authentication against a previously recorded sample on file (biometric voice print verification)

Moreover, if the user decides to call the help desk, then Password Manager can be configured to have the support staff authenticate the caller by asking for answers to security questions before offering assistance.

Challenge/Response Data Model

Password Manager supports multiple question sets in the context of challenge/response authentication:

Each question set either allows users to define their own question-and-answer pairs or requires users to answer some number of pre-defined questions.
Each question set with pre-defined questions has its own, normally unique, list of questions.
Questions may have formatting constraints (e.g., all numeric for use with a touch tone IVR (interactive voice response) system).
Questions sets may be used in different contexts -- self-service authentication, help desk user authentication, displayed to IT support users or mandatory input by IT support users.
Users may be required to fill in some minimum number of the questions in each set. For example, a question set may have a set of 20 standard questions and users must populate answers to at least 5.
During authentication, some defined number of questions is drawn from each relevant question set, at random, to carry out authentication.
Question sets can be assigned to authentication screens. This makes it possible to serialize the authentication process. For example, users must successfully answer some questions from their pre-defined set before being prompted to answer their own free-form questions. This can force an attacker to compromise some answers before even starting to figure out the answers to others.
Question/answer data in each question set may be stored in different places. For example, data for one question set may be physically on the Password Manager servers, while a second might be accessed on an LDAP directory and a third validated against an HR application.
There is no limit to the number of question sets, questions per set or answers per user.

Careful configuration of challenge/response authentication is required to ensure that it is at least as strong as hard-to-guess and regularly changing passwords.

Access For Locked Out Users

(7) When users forget or lock out their primary password, 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 locked out users. Each of these approaches has its own strengths and weaknesses, as described below:

Option	Pros	Cons
Do nothing: users continue to call the help desk.	Inexpensive, nothing to deploy.	The help desk continues to field a high password reset call volume. No solution for local passwords or mobile users.
Ask a neighbor: Use someone else's web browser to access self-service password reset.	Inexpensive, no client software to deploy.	Users may be working alone or at odd hours. No solution for local passwords or mobile users. Wastes time for two users, rather than one. May violate a security policy in some organizations.
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.	Simple, inexpensive deployment, with no client software component. Users can reset both local and network passwords.	Introduces a "generic" account on the network, which may violate policy, no matter how well it is locked down. One user can trigger a lockout on the "help" account, denying service to other users who require a password reset. Does not help mobile users.
Personalized SKA: 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.	Eliminates the "guest" account on the domain, which does not have a password.	Requires creation of thousands of additional domain accounts. Requires ongoing creation and deletion of domain accounts. These new accounts are special -- their passwords do not expire and would likely not meet strength rules.
Local SKA: Same as the domain-wide SKA above, but the "help" account is created on each computer, rather than on the domain.	Eliminates the "guest" account on the domain. Can be configured to assist mobile users who forgot their cached domain password (by automatically establishing a temporary VPN connection).	Requires a small footprint on each computer (the local "help" account.
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.	Simple deployment of centralized infrastructure. No client software impact. May leverage an existing IVR system. Helpful for remote users who need assistance connecting to the corporate VPN.	New physical infrastructure is usually required. Users generally don't like to "talk to a machine" so adoption rates are lower than with a web UI. Does not help mobile users who forgot their cached domain password. Does not help unlock PINs on smart cards.
Physical kiosks: Deploy physical Intranet kiosks at each office location.	Eliminates generic or guest accounts. May be used by multiple applications that are suitable for physically-present but unauthenticated users (e.g., phone directory lookup, badge management, etc.).	Costly to deploy -- hardware at many locations. Does not help mobile users who forgot their cached domain password. Users may prefer to call the help desk, rather than walking over to a physical kiosk.
GINA DLL: Windows XP: Install a GINA DLL on user computers, which adds a "reset my password" button to the login screen.	User friendly, intuitive access to self service. Can be configured to assist mobile users who forgot their cached domain password (by automatically establishing a temporary VPN connection). Works on Windows Terminal Server and Citrix Presentation Manager.	Requires intrusive software to be installed on every computer. Broken installation or out-of-order uninstallation will render the computer inoperable (i.e., "brick the PC").
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.	User friendly, intuitive access to self service. Can be configured to assist mobile users who forgot their cached domain password (by automatically establishing a temporary VPN connection). More robust, fault-tolerant installation process than the GINA DLL.	Requires software to be installed on every computer. Does not work on Citrix Presentation Server or Windows Terminal Server -- only works on personal computers.
Credential Provider: The equivalent of a GINA DLL, but for the login infrastructure on Windows 7 and Windows Vista.	User friendly, intuitive access to self service. Can be configured to assist mobile users who forgot their cached domain password (by automatically establishing a temporary VPN connection). Works on Windows Terminal Server and Citrix Presentation Manager. More robust infrastructure than GINA DLLs on Windows XP.	Deployment of intrusive software to every workstation.

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 forget or lock out their passwords). 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:

By monitoring one or more systems of record, Password Manager automatically creates new and removes old profile IDs.
New users and existing users with incomplete profiles are automatically prompted to complete their profiles (e.g., by answering security questions).
Invitations to enroll may be e-mailed to users.
Users may be more forcefully reminded to enroll by having a web browser automatically open to the enrollment page when they log into the network.
Users may be forced to enroll, by opening a kiosk-mode web browser to the enrollment page when they sign into the network, and blocking access to the Windows desktop until users complete their profile. This process is typically controlled by placing users into a "mandatory enrollment" AD group and attaching a suitable GPO to that group.
To enroll, users must first authenticate. This is normally done by leveraging an existing strong authenticator -- such as a network password or a token.
A single, integrated enrollment system supports collecting answers to security questions, mapping different login IDs, on different systems back to their owners and collecting biometric voice print samples.

Login ID Reconciliation

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

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

Automatically, typically by matching consistent login IDs.
By matching other attributes such as an SSN or employee ID, where they are available.
By drawing on an external source of data -- for example, some organizations maintain a mapping table or spreadsheet.
Using a self-service reconciliation process.

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

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

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

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

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

The only attribute that is commonly available on every system is a user's full name. This may be inconsistent across systems and in many large organizations multiple users share the same full name and sometimes the same location.
Failure to automatically correlate an account leads to manual, administrative reconciliation, which is expensive.
Incorrect ID mapping allows one user to set another user's password, which is a serious breach of security.

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

Telephony / IVR Integration

A popular option for extending password reset services to locked out users is to extend this service over a telephone, using an integrated voice response (IVR) system.

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 (application programming interface), or Hitachi ID Telephone Password Manager -- a turn-key IVR system specifically designed for password resets.

Telephone access (IVR) architecture diagram (8)

Password Reset Process with Voice Print Verification

Password reset using a telephone, voice print caller authentication and a randomly-generated password (to minimize alpha-numeric input on a telephone) works as follows:

User: forgets password or triggers intruder lockout.
User: dials the support number, navigates to the "password problems" section.
Telephone Password Manager server: prompts the user to key in a personal ID, such as an employee number or a numeric mapping of the user's alphanumeric network login ID (e.g., smith01 maps to 7648401).
User: keys in the ID.
Telephone Password Manager server: connects to the Password Manager server.
Password Manager server: looks up the user's profile.
Password Manager server: selects random subset of the user's questions.
Telephone Password Manager server: prompts the user to answer some questions.
User: speaks answers into the telephone.
Telephone Password Manager server: compares answers to voice characteristics stored on file.
... Repeat if failed, continue if success, possible lockout.
The process by which the user chooses a new password proceeds as follows:
1. Telephone Password Manager server: asks Password Manager to generate a random password for this user.
2. Password Manager server: provides a random, policy-compliant password string.
3. Telephone Password Manager server: enunciates the password and asks the user to accept / retry.
4. User: presses a digit to accept the password choice.
5. Telephone Password Manager server: asks Password Manager to reset passwords for this user, on selected systems, to the requested password string.
6. Password Manager server: attempts password reset immediately and possibly queues it up for retries.
7. Password Manager server: may set the "password expired" flag on new passwords, so that the user will be forced to choose a new password at login time.
8. Password Manager server: writes a ticket to an incident management system.
9. Password Manager server: sends the user a confirmation e-mail.

Password Reset Process with Touch-Tone Verification

Password reset using a telephone, with touch-tone caller authentication and a randomly-generated password (to minimize alpha-numeric input on a telephone) works as follows:

User: forgets password or triggers intruder lockout.
User: dials the support number, navigates to the "password problems" section.
Telephone Password Manager server: prompts the user to key in a personal ID, such as an employee number or a numeric mapping of the user's alphanumeric network login ID (e.g., smith01 maps to 7648401).
User: keys in the ID.
Telephone Password Manager server: connects to the Password Manager server.
Password Manager server: looks up the user's profile.
Password Manager server: selects random subset of the user's questions.
Telephone Password Manager server: prompts the user to answer the selected questions.
User: keys in (numeric) answers to the selected questions.
Telephone Password Manager server: forwards answers to the Password Manager server.
Password Manager server: compares answers to registered data.
... Repeat if failed, continue if success, possible lockout.
The process by which the user chooses a new password proceeds as follows:
1. Telephone Password Manager server: asks Password Manager to generate a random password for this user.
2. Password Manager server: provides a random, policy-compliant password string.
3. Telephone Password Manager server: enunciates the password and asks the user to accept / retry.
4. User: presses a digit to accept the password choice.
5. Telephone Password Manager server: asks Password Manager to reset passwords for this user, on selected systems, to the requested password string.
6. Password Manager server: attempts password reset immediately and possibly queues it up for retries.
7. Password Manager server: may set the "password expired" flag on new passwords, so that the user will be forced to choose a new password at login time.
8. Password Manager server: writes a ticket to an incident management system.
9. Password Manager server: sends the user a confirmation e-mail.

Integration with an Existing IVR System

Password Manager includes a client library that can be installed on an existing systems, such as IVR platforms and other, third-party applications. This API allows native code on the external (example: IVR) system to:

Look up a user profile.
Retrieve a set of authentication questions for the user
(typically these have numeric answers in IVR applications).
Validate answers entered by the user to his own question.
Request a randomly-generated password to offer the user.
Request a password reset for the user.

This library implements a secure remote procedure call to the Password Manager server, using an encrypted TCP socket based on a shared secret key.

The Password Manager API includes a C-language binding for Windows (DLL) and Unix (shared object library for any flavor of Unix, including UnixWare as used by Lucent/Avaya products). It is also exposed as a SOAP web service and an ActiveX component.

Telephone Password Manager: A Turn-key Password Reset IVR Solution

Overview:

Telephone Password Manager is a turn-key telephone user interface for the Password Manager authentication management solution. It enables organizations to quickly and inexpensively offer self-service password reset, PIN reset and disk unlock to users over a telephone, without having to configure a complex IVR system.

Features:

Telephone Password Manager supports self-service management of authentication factors and recovery of disk encryption keys over a telephone with:

User identification:
Users who call Telephone Password Manager typically identify themselves by typing a personal identifier on a touch-tone telephone keypad. The identifier may be a pre-existing numerical ID, such as an employee number, or a letters-to-digits mapping of an alpha-numeric ID, such as the user's network login ID.
User authentication:
Once identified, users must be authenticated. Telephone Password Manager supports authentication with a hardware token (e.g., RSA SecurID), by asking the user to key in answers to numeric security questions using a touch-tone telephone keypad on their phone (e.g., driver's license number, SSN, date of birth, etc.) or using an optional biometric voice verification module.
Password reset:
Once authenticated, users can initiate a password reset. This may be for one or all of their passwords and the new password may either be randomly generated and read out to the user or user-specified. New passwords may be set to expire after first use.
PIN reset:
Authenticated users can also use Telephone Password Manager to reset the PINs on their RSA SecurID tokens. A randomly-generated or a user-specified PIN may be used.
Disk unlock:
Users with a full disk encryption program protecting their computer can use Telephone Password Manager to automate the key recovery process in the event that they forgot the password that unlocks their computer.
Text to speech:
Telephone Password Manager is normally configured to play .WAV audio files as prompts for user input. It also includes a text to speech mechanism that makes it easier to develop new navigation menus and defer new voice recordings.
Speech to text:
While text input into Telephone Password Manager is usually made with a touch-tone keypad, Telephone Password Manager can be configured to recognize small dictionaries of spoken words, so that users can make alphanumeric input by speaking the names of letters and digits.
PBX integration:
Telephone Password Manager can be directly integrated into an existing PBX system, by installing the appropriate (to that PBX system) Dialogic telephony board on each Telephone Password Manager server.
VoIP integration:
Telephone Password Manager can also be connected to a voice-over-IP network and configured to accept VoIP calls.

Benefits:

Telephone Password Manager lowers IT support costs and improves user service by enabling mobile, remote or locked out users to resolve problems with their password, hardware token or encrypted hard disk on their own, without calling the help desk.

Telephone Password Manager can improve the security of IT support processes by authenticating users with biometric voice-print verification prior to offering services such as password or PIN reset.

Managing PKI Certificate Passwords

PKI standards generally relate to certificate format and use, not to the administration of certificates -- issuance, delivery to users, installation on PCs and smart cards and revocation. Unfortunately, a major cost of PKI is exactly these processes of managing certificates.

Password Manager includes a significant and mature infrastructure for managing (provision, manage passwords and other attributes, deliver to users and revoke) PKI certificates.

Of necessity, this infrastructure combines a general facility, related to business process and certificate storage with a set of platform-specific bindings, for individual PKI/certificate authority products. Currently, Hitachi ID Systems provides a platform binding for Lotus Notes ID files, which is by far the most widely deployed (though not necessarily standards-based) PKI infrastructure today:

Lotus Notes actually uses two separate passwords for each user:

HTTPPassword hashes, stored on a Notes / Domino server.
These are a straight-forward password hash in a field in an .NSF file on the server. Password Manager can be configured to verify, change and reset these passwords directly.
Passwords used to encrypt ID files, typically stored on user workstations. These cannot be administratively reset.
1. Password Manager includes technology to help organizations both build out and maintain a repository of every user's ID file, along with a recoverably encrypted password for that ID file.
2. Password Manager simulates password resets on ID files by retrieving an ID file from the repository, opening it with a password from the repository, changing the password to a new value and delivering the new ID file to the user.
3. Both collection of ID files from users, to maintain the repository, and delivery of updated ID files back to users, supports multiple mechanisms, including via file synchronization and a shared staging directory (no client software required) and via a Notes Extension DLL installed on user workstations (immediate and silent delivery and collection).
Password Manager is the only product to automate not only ID file password resets, but also construction and maintenance of the ID file repository.

Hitachi ID Systems is working on bindings between the general-purpose PKI administration infrastructure in Password Manager and other PKI products, from Microsoft, Entrust, Verisign, GeoTrust and other PKI vendors. Unfortunately, none of these PKI products is currently widely deployed, and customer demand for integrations is therefore limited.

Support for Mobile, Disconnected Users

When users are off-site and not connected to the corporate network, they can use a telephony solution (IVR) to reset a VPN password. This does not resolve problems users may encounter with their local workstation passwords or with cached domain passwords.

A locally-deployed secure kiosk account ( LSKA (local, secure kiosk account)), GINA extension service or credential provider are available to assist mobile, off-site users who have forgotten the password they use to sign into their own workstation. These solutions establish a temporary network connection, launch a locked-down web browser and enable the user to authenticate to Password Manager with something other than their domain or VPN password. Once authenticated, the user can reset their password(s) both on network services and locally on their workstation (via ActiveX). The LSKA or GINA (Graphical Identification and Authentication library) extension service works as follows:

The user's workstation is physically connected to a public network (e.g., the Internet, a hotel network, their home network, etc.) but has not yet established a VPN connection to the corporate network.
The user forgot his local password or cached domain password or triggered a lockout.
If the LSKA is deployed, The user signs into his workstation with the user name "help" and no password.
If the GINA extension service is deployed, the user presses a button on the Windows login screen with a label such as "I forgot my password."
The LSKA or GINA service is launched and starts a VPN-wrapper program.
The VPN-wrapper invokes a VPN client (Microsoft or third party) and initializes it with generic connection and credential data (i.e., the same data for all users; data stored in the user's registry in an encrypted format).
The VPN-wrapper waits for a connection. Different tests may have been deployed to test for connectivity, such as checking for an "up" interface, PING-ing a given IP address, trying TCP connections to a given IP/port number, etc.).
The VPN-wrapper displays an error dialog and returns the user to the Windows login prompt if it failed to connect.
The VPN-wrapper launches RUNURL, which is the Password Manager program that opens a locked-down, kiosk-mode web browser. The initial URL is set to the self-service password reset page on the Password Manager server.
The VPN-wrapper waits for the web browser to close, normally in N minutes or less. When the browser is closed or time runs out, it closes the browser, terminates the VPN connection and returns the user to the Windows login screen.
In the web browser session, the user completes a self-service password reset as usual (i.e., the remote / mobile nature of the connection does not impact this process).

The sequence of executable components on the workstation, some of which are already present, is:

The VPN-wrapper, which is launched as the shell for the local "help" user (part of Password Manager).
The VPN client (pre-existing).
One or more connection-testing programs (part of Password Manager).
RUNURL, which locks down the PC and launches a kiosk-mode web browser (part of Password Manager).
The user's default web browser (pre-existing).

The LSKA and GINA service solutions are configured using a set of registry entries, defining items such as:

VPN server connection information.
Generic VPN login ID and password.
URL to launch for SSPR.
Timeout for VPN sessions.
Commands to run to test for a connection.

Active Directory Replication

(8)Active Directory does not propagate cleared intruder lockout flags on an expedited schedule. This can create problems for remote users who inadvertently trigger a lockout and subsequently call a central help desk for assistance. The help desk will typically clear the user's lockout on a domain controller near the help desk. This lockout may take a long time (hours) to reach the domain controllers against which the user wishes to authenticate or which service network resources that the user wishes to access.

This problem is especially acute in global organizations, with hundreds of domain controllers that employ a centralized user support function.

Note that AD password change replication is described here:

http://technet.microsoft.com/en-us/library/cc772726.aspx

Password Manager uniquely circumvents the problem of slow replication of cleared intruder lockouts between Active Directory domain controllers by automatically directing password resets and cleared intruder lockouts to a select set of domain controllers, which the user is most likely to access:

DCs on the user's home site, based on the user's home directory UNC and the IP address of the server that hosts this UNC.
DCs on the user's current site, based on the user's web browser IP address (this only applies to self-service password reset).
DCs mapped to either of these sites by an administrator-configured rule set. For example, at global or regional data centers.

Scalability

(9) Password Manager has been deployed in very large organizations, including:

One password reset system supporting 750,000 users and another supporting more than 2,000,000 users (both Extranet-facing).
Internal corporate deployments with up to 300,000 users.
Users distributed over six continents (nobody in Antarctica).
A single Password Manager instance, running on a single server, managing passwords on over 3,200 stand-alone Unix systems.

This level of scalability is a result of many features:

Built-in data replication.
Explicit support for load-balanced configurations with cooperation between replica servers.
Multi-threading operation of the UI components, service components and connectors.
A local, high-performance database that contains easily accessed data about users, including their security questions and various login IDs.

In addition, Password Manager incorporates many features that, while not directly performance-related, are needed to operate in large, complex networks:

Compatibility with reverse web proxies, which can expose some or all of the Password Manager UI to less-trusted network segments (e.g., DMZ).
A proxy server, which allows Password Manager to operate across firewalls.
Support for multiple languages (including Unicode) per running instance.
Auto-discovery of users and groups on integrated systems.

Security Technology

Password Manager is designed to be secure. It is protected using a multi-layered security architecture, which includes running on a hardened OS, using file system ACLs, providing strong application-level user authentication, filtering user inputs, encrypting sensitive data, enforcing application-level ACLs and storing log data indefinitely.

Password Manager never requires plaintext passwords to be stored in configuration files or scripts and does not store plaintext passwords anywhere. Password Manager does not ship with a default administrator password -- one must be typed in at installation time.

These security measures are illustrated in Figure [link].

Network architecture security diagram (10)

Cryptography

Encryption is used to protect stored Password Manager data as follows:

Data stored on the Password Manager server
Data	Algorithm	Key
Privileged passwords, used to log into target systems	128-bit AES	128-bit random
Answers to security questions	128-bit AES	128-bit random
User old password history	SHA-1	64-bit random salt

(11)Data transmitted to and from Password Manager on the network is cryptographically protected, as follows:

Data transmitted to/from the Password Manager server
To/From	Algorithm	Key length
Interactive sessions
User browser	SSL (varies)	128 bits.
Trigger password synchronization
From Win2K/2K3 AD DC	128-bit AES	128-bit shared secret.
From z/OS
From Unix
From LDAP server
Set passwords, Create/update users
To Unix agent	128-bit AES	128-bit shared secret.
To z/OS task
To RSA Authentication Manager
To proxy server
API
From calling system / IVR	128-bit AES	128-bit shared secret.
API
From calling system / IVR	HTTPS	128 bits.
Set passwords, Create/update users
To target system	native	Varies. Use proxy server when native protocol is inadequate.

User Interface Input Protection

The CGI programs (which are responsible for all Password Manager user interfaces) use a special string library to validate all input before processing. This includes variable length, filtering out special characters, HTML codes, SQL codes, checking for valid formatting and value ranges, etc.

Use of a standard approach to filtering all inputs prevents buffer overrun, cross-site scripting and similar attacks.

Authentication Lockouts

The Password Manager login screens include an intruder lockout feature.

Once a predefined number of invalid authentication attempts are reached, Password Manager can automatically lock the user out of the system, either for a specified duration or until an administrator unlocks the user.

Lockouts normally also trigger e-mails (to the user and possibly to a security officer) and alarms (including help desk tickets).

Session State Management

Password Manager user interfaces all authenticate users with a password or other credential at initial access. Once authenticated, users are assigned a session ID, which is globally unique within the context of that Password Manager server, by virtue of containing a date and a sequence number (record number in a session table).

All state information associated with the user's login session -- for example the user's login ID and name, ACLs, web user interface navigation history, request form details and more -- are tracked on the Password Manager server, keyed to the session ID.

Each HTML page in the Password Manager user interface contains a hidden tag, with a session key. The session key is a sequence of 16 randomly generated bytes and is newly and randomly generated for each and every displayed web page. Session keys are also stored on the Password Manager server and mapped to session IDs. Keys are valid for a single use and for a limited time. IDs are valid until cleared (e.g., by logoff or time out).

Password Manager validates that user input came from an active, current session by looking up the session key from the user input form, to find the appropriate session ID and validate that timeout has not happened. Session keys may not be reused, so session playback, or even use of the browser "Back" button is prohibited.

Password Manager has user inactivity timeouts that can be set on a module by module basis. A Password Manager web page submitted after this timeout has expired will be rejected and the user will be asked to re-authenticate.

Return on Investment

(12) Deploying Password Manager saves money for three groups of people in an organization:

Users:
Password synchronization reduces the incidence of password problems. In most organizations, over 80% of problems are eliminated. Accordingly, users waste less time making unsuccessful attempts to log into systems.
Support staff:
Both password synchronization and self-service password resets eliminate calls to the help desk. Together, they normally reduce password-related call volume by over 90%.
Once calls reach the help desk, they are resolved much more quickly, using a single tool that integrates caller authentication, multiple password resets and creation of problem tickets. Using a web browser, support staff can resolve password calls in 1-2 minutes.
System administrators:
Without Password Manager, most support organizations escalate some password calls to system administrators. This is done when the support organization does not have training or security clearance to reset passwords on the systems in question.
Password Manager eliminates password problem escalation.

Example savings calculation

The following example illustrates how Password Manager reduces the cost of password management:

10000 users experience 3000 password problems per month. Users spend 10 minutes with a password problem before calling for help.
The help desk takes 10 minutes to resolve password problems.
1/6 of calls are escalated from the help desk to system administrators.
Password Manager eliminates 80% of password problems, and reduces problem resolution time 2 minutes.

Monthly cost	Initial	Password Manager	Savings
Users	3000 calls x 20 minutes x $40/hr	600 calls x 12 minutes x $40/hr
	= $40,000	= $4,800	$35,200
Help desk	3000 calls x 10 minutes x $40/h	600 calls x 2 minutes x $40/hr
	= $20,000	= $800	$19,200
Administrators	500 calls x 5 minutes x $40/hr
	= $1,670	0	$1,670
Monthly Total	$61,670	$5,600	$56,070

To estimate the cost savings in your organization, try our on-line calculator at:

http://Password-Manager.Hitachi-ID.com/roi/

Platform Support

Password Manager can manage passwords on most systems directly. It includes built-in support for the following systems:

(13)

Directories:	Servers:	Databases:
Any LDAP, AD, NDS, eDirectory, NIS/NIS+.	Windows 2000, 2003, 2008, Samba, Novell, SharePoint.	Oracle, Sybase, SQL Server, DB2/UDB, ODBC.
Unix:	Mainframes:	Midrange:
Linux, Solaris, AIX, HPUX, 24 more.	z/OS with RAC/F, ACF/2 or TopSecret.	iSeries (OS400), OpenVMS.
ERP:	Collaboration:	Tokens, Smart Cards:
JDE, Oracle eBiz, PeopleSoft, SAP R/3, Siebel, Business Objects.	Lotus Notes, Exchange, GroupWise, BlackBerry ES.	RSA SecurID, SafeWord, RADIUS, ActivIdentity, Schlumberger.
WebSSO:	Help Desk:	HDD Encryption:
CA Siteminder, IBM TAM, Oracle AM, RSA Access Manager.	BMC Remedy, BMC SDE, HP Service Manager, CA Unicenter, Assyst, HEAT, Altiris, etc.	McAfee, CheckPoint.

(14)Password Manager includes a number of flexible connectors, each of which is used to script integration with a common protocol or mechanism. These connectors allow organizations to quickly and inexpensively integrate Password Manager with custom and vertical market applications. The ability to quickly and inexpensively add integrations increases the value of the Password Manager system as a whole.

There are flexible connectors to script interaction with:

API binding:

Terminal emulation:

Web services:

Back end integration:

Command-line:

C, C++
Java, J2EE
.NET
COM, ActiveX
MQ Series

SSH
Telnet
TN3270, TN5250
Simulated browser

SOAP
WebRPC
Pure HTTP(S)

SQL Injection
LDAP attributes

Windows
PowerShell
Unix/Linux

Organizations that wish to write a completely new connector to integrate with a custom or vertical market application may do so using whatever development environment they prefer (J2EE, .NET, Perl, etc.) and invoke it as either a command-line program or web service.

If Hitachi ID Systems customer develops their own integrations, an effort of between four hours and four days is typical. Alternately, Hitachi ID Systems offers fixed-cost custom integrations for a nominal fee.

Other Integrations

Password Manager integrates closely with existing IT infrastructure:

Help Desk Systems

Password Manager can update existing call records, or create new ones, in any help desk call management system. Over 100 event types can trigger this interface, which implements different business logic for each defined event.

Binary interfaces, ODBC database updates and e-mail integration are all supported. Password Manager currently includes binary interfaces for the following help desk ticketing applications:

Axios Assyst.
BMC/Remedy ARS (4, 5, 6, 7).
BMC Service Desk Express (7.0, 7.5, 9.x).
CA Unicenter Help Desk.
Clarify eFrontOffice (8, 12).
FrontRange HEAT (5, 6, 7, 8).
HP Service Desk.
HP Service Manager (any version).
Numara Track-It!
Symantec / Altiris.
... and more

Authentication Devices

Password Manager is closely integrated with RSA SecurID tokens. Users who wish to access a self-service facility may authenticate with their SecurID pass code. Users can also manage their own SecurID token, after authenticating with a network password or question profile.

Password Manager also supports RADIUS authentication, enabling users to sign on with other (non-RSA) tokens.

Electronic Mail

Over 179 events throughout Password Manager can trigger automatic notifications, which include e-mails to users, requesters, recipients, authorizers, administrators, security officers and more. A simple scripting language is used to specify the e-mail recipient in each case. The notification exit can draw on any data source, incorporate any request attribute and apply any logic, to identify e-mail recipients and to compose message content.

Meta Directories

Password Manager can access information about where users have login accounts, and what those accounts are called, in an existing meta directory. Alternately, this information can be automatically collected and maintained by Password Manager, and uploaded into a meta directory, such as Microsoft ILM.

Rapid Deployment

Hitachi ID Systems solutions are optimized for rapid deployment -- this is a core design characteristic across all products in the Hitachi ID Management Suite. Features such as a dynamic workflow, an architecture which does not depend on role engineering, auto-discovery of users on target systems and self-service login ID reconciliation are all designed to eliminate costly deployment steps and minimize ongoing administration.

(15) Password Manager is designed for rapid deployment:

No client software required, even for access to self-service password reset from the workstation login prompt.
Automated discovery of every login ID on every managed system, nightly.
Self-service login ID reconciliation where login IDs on different systems are different and there is no pre-existing correlation data.
A built-in identity cache that captures user profile data and eliminates the need to install or manage a database or directory before installing Password Manager.
Built-in connectors for every common system and application eliminating the need for customers to develop their own connectors to common, off-the-shelf target systems.
Remote connectors mean that Password Manager can manage users and passwords on systems without requiring the installation of intrusive local software on each target system.
Flexible connectors enable organizations to integrate Password Manager with custom applications, vertical market software, application service providers (ASPs) and service bureaus quickly -- taking just 2 hours to 4 days per new target system.

Ensuring User Adoption

Hitachi ID Systems is committed to providing end-to-end identity and access management solutions to our customers. We support our clients from initial requirements discovery, through solution design, product deployment, and our proprietary Adoption Maximizer (Hitachi ID Adoption Maximizer) program.

Successful implementation of an identity and access management system must be supported by an effective user adoption plan. For over ten years, Hitachi ID Systems has deployed flexible solutions across all industries, to midsize and large multi-national enterprises, delivering significant business value to the client. This experience has allowed Hitachi ID Systems to develop our Hitachi ID Adoption Maximizer program.

Hitachi ID Adoption Maximizer enables Hitachi ID Systems customers to effectively engage their end users throughout the project life cycle, to realize these objectives:

Maximize adoption of all self-service functions (password reset, account registration, biometric enrollment, etc.) across all user groups and computer environments.
Typically reach 80% - 90% user adoption in 90 days.
Gain early ROI (return on investment) by improving:
- Help desk productivity.
- Admin staff productivity.
- End-user productivity.
Maximize user satisfaction.

Implementation of Hitachi ID Systems Hitachi ID Adoption Maximizer program is initiated during the discovery phase and completed only after the system is deployed and both Hitachi ID Systems and the client sign off on the completed rollout.

The Hitachi ID Adoption Maximizer solution delivery process includes six components:

Needs assessment.
Hitachi ID Adoption Maximizer toolkit.
Workflow optimization and GUI customization.
Communication plan for all stakeholders.
End-user incentives.
Feedback and metrics.

The Hitachi ID Adoption Maximizer program improves user adoption by at least 50% over a typical unassisted deployment. Hitachi ID Adoption Maximizer is available from Hitachi ID Systems solution delivery team, both as a stand-alone solution offering and as part of the complete solution delivery program.