Enterprise-Scale Password Management With P-Synch

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 P-Synch® password management software. It identifies business problems associated with the operation of password systems and describes how these problems are resolved using P-Synch features.

P-Synch 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.

P-Synch 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). P-Synch 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

Managing multiple passwords is complex. This complexity produces usability, security and cost problems.

Users often 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.

This complexity leads users to try to select trivial passwords, to avoid changing their passwords and to write down their passwords. When users do not violate security policy in any of these ways, they forget their passwords and generate significant help desk call volume.

Password problems are a top problem at most IT help desks, frequently accounting for 25% or more of the total volume of IT support calls.

Passwords are certain to remain in widespread use for a long time. Other authentication technologies, such as biometrics, smart cards and two-factor tokens, typically rely on passwords as either a second authentication factor (e.g., biometric plus password; token plus password/PIN) or as a backup authentication factor where the primary method is inaccessible (e.g., use a backup password instead of a smart card where a reader is unavailable).

Consequently, it's important to address password management problems: they are not likely to go away as other authentication technologies are deployed.

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

An invalid cached password causes several problems:

If the user attempts to access a network resource, the workstation will attempt to sign on with the cached password. Since the cached password is incorrect, this will increment the "number of invalid login attempts" counter on the user's network profile.
Repeated attempts to access network resources can cause the user's login ID to be temporarily disabled by the intruder lockout mechanism. Such attempts may happen without user interaction -- for example, a mail client such as MS Outlook may attempt to use the cached password to synchronize with a mail server.
If the user removes the computer from the network, he may attempt to log into the workstation with the new password, which won't work.

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://technet2.microsoft.com/windowsserver/en/library/1465d773-b763-45ec-b971-c23cdc27400e1033.mspx?mfr=true

Mobile, Disconnected Users

Traveling users typically log into their workstations using cached credentials. 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.

P-Synch Features

P-Synch 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 P-Synch from Hitachi ID is password synchronization.

P-Synch 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 P-Synch from Hitachi ID is self-service password reset.

Assisted Password Reset

P-Synch includes a help desk password reset console, which allows help desk analysts to assist callers without having direct administrative access to target systems:

Help desk analysts sign into P-Synch with a web browser.
Analysts can be authenticated using IDs and passwords internal to P-Synch or use pass-through authentication to an existing system.
For example, help desk analysts may sign into P-Synch using their Active Directory ID and password, with P-Synch validating the membership of each analyst in a designated AD security group and granting appropriate P-Synch privileges based on that group membership.
From the P-Synch 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 P-Synch 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 P-Synch 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 a help desk call tracking 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 credentials to the systems where passwords are being reset. Instead, P-Synch uses its own credentials to sign into target systems, and these credentials are encrypted in an internal P-Synch 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

P-Synch is normally configured to support a single, global password policy, to ensure that all new passwords will be acceptable to every system. This setup provides the most clear and understandable experience to users. P-Synch 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 OS/390 passwords, where users may enter very long passwords on AD but only 8 characters on the mainframe, P-Synch can require that passwords be exactly 8 characters long. Alternately, P-Synch 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. P-Synch 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, P-Synch 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 P-Synch 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 P-Synch on a shorter schedule than any other application or system password. This way, users are never prompted to change passwords by anything other than P-Synch itself or systems that automatically trigger P-Synch 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 P-Synch.

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 P-Synch, in addition to upcoming expiration on a managed system.

Password Reuse

In P-Synch, 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 Synchronization: Technical Architecture

Web-Browser Password Synchronization

(2)Users can synchronize some or all of their passwords by using a P-Synch web interface to make routine password changes. The password policy is clearly stated on the screen and enforced immediately. Each system where the user has a login ID is represented by a name and a check box.

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 P-Synch application.
P-Synch web server: prompts the user to type his network login ID.
User: types his network login ID.
P-Synch web server: prompts the user to type his current NOS password.
User: types his current password.
P-Synch web server: validates the password against the indicated system.
... repeat if authentication failed, lockout if too often.
P-Synch web server: prompts the user to enter a new password.
User: types a new password, selects some or all accounts.
P-Synch web server: validates password quality, possibly returns the user to previous step.
P-Synch web server: resets the password on selected systems to the new value.
P-Synch web server: displays a status page to the user.
P-Synch web server: writes a ticket to a call tracking system.
P-Synch web server: sends the user a confirmation e-mail.

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

The Apache, IIS and Sun ONE web servers are all supported.

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 P-Synch server, which in turn may draw data from an LDAP directory or database server. They can also communicate with services on the P-Synch server and run agents and plug-in programs to push data out to other systems (e.g., e-mail, help desk systems, SMS messages).

As mentioned above, the P-Synch 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 P-Synch 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 P-Synch 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 P-Synch 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 Windows NT, Active Directory (32-bit, 64-bit), Sun LDAP, IBM LDAP, Oracle Internet Directory, Unix (various), OS/390 and OS/400 password, the new password is subjected to a global password policy in addition to the native policy. If the password is acceptable, the new password is changed both on the initial system and, automatically, on every other system where the user has a login ID.

Use of an existing, familiar user interface to change passwords eliminates the need for training and guarantees high (100%) adoption rates.

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: (e.g., Windows NT, Active Directory (32-bit, 64-bit), Sun LDAP, IBM LDAP, Oracle Internet Directory, Unix (various), OS/390 and OS/400 ) validates password quality internally, then calls a P-Synch library to further validate password quality.
P-Synch library: contacts the P-Synch server; establishes an encrypted connection; forwards a request for password policy validation.
P-Synch server: validates password quality; returns result. In the event of an attempted policy violation, P-Synch may send a message directly to the user by e-mail or a Windows pop-up message; may write a call tracking system ticket and so on.
Login server: updates the user's password field internally, calls the P-Synch library to notify it of the successful change. Note that a failure to meet the P-Synch policy will normally block the initial password change from happening.
P-Synch library: contacts the P-Synch server; establishes an encrypted connection; forwards a request for password synchronization.
P-Synch server: queues up the new password for synchronization.
P-Synch server: resolves the single queued event to a list of passwords that must be set for this user (one per account).
P-Synch server: administratively sets the user's passwords on each system to the new value.
P-Synch 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 write a ticket to a call tracking system to alert someone of a problem.

Transparent synchronization architecture diagram (5)

Password Reset: Technical Architecture

Authenticating Users Without Passwords

(6)Users authenticate as follows:

On a web GUI:
- By typing their current password to a trusted system (for example Windows / Active Directory, OS/390, RADIUS, etc.).
- By answering a set of system-selected personal questions, whose answers may either be stored inside the P-Synch 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 P-Synch can be configured to have the support staff authenticate the user via the user's Q-A (Question-and-Answer) profile before the user is helped.

Challenge/Response Data Model

P-Synch 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 authentication, displayed to help desk staff or mandatory input by help desk staff, etc.
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 P-Synch 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

Several strategies are available with P-Synch, to assist users who forgot their initial network password and therefore cannot sign into their workstation, from which they might be able to open a web browser and access the self-service password reset URL.

Each of the available solutions has its own, unique, benefits and drawbacks:

Option	Pros	Cons
	Inexpensive, nothing to deploy.	The help desk continues to field a high password reset call volume. No solution for local passwords or mobile users.
	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.
"help" with no password. This launches a kiosk-mode password reset web UI in place of the Windows Explorer shell.	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.
For example, users who forget their network password log in using their employee ID in the username field and their date of birth + last 4 digits of their SSN in the password field. On login, users are presented with a kiosk-mode web browser interface for self service password reset.	Somewhat more complex, but still inexpensive deployment, with no client software. Users can reset both local and network passwords.	Personalized SKA accounts have static passwords, which may violate policy. Does not help mobile users.
	Simple deployment of centralized infrastructure. May reuse or extend an existing IVR (interactive voice response) system. Offers an easy solution to remote users.	New physical infrastructure is required. Users generally don't like to "talk to a machine" so adoption rates are lower than with a web UI. No solution for local passwords or mobile users.
local user "help," as opposed to the domain "help" user.	Eliminates the domain-wide "generic" account, so is unlikely to violate any security policies. Users can reset both local and network passwords. Can be configured to assist mobile users by automatically establishing a temporary, filtered VPN connection.	Requires client software, which must be tested against every desktop image and deployed to many workstations.
	Eliminates any "generic" account. 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 address local passwords or mobile users. Users may prefer to call the help desk, rather than walking over to a physical kiosk.
with additional user interface components presented at login time. This enables users to launch a self-service password reset UI from the workstation login prompt.	User friendly, intuitive access to self service. Users can reset local passwords. Can be configured to assist mobile users by automatically establishing a temporary, filtered VPN connection.	Risky deployment of intrusive software to every workstation. Failed installations of GINA (Graphical Identification and Authentication library) extensions or wrappers can damage workstations in a way that makes it impossible to login -- this requires workstations to be re-imaged, which is very expensive.
to launch a self-service password reset UI from the workstation login prompt.	User friendly, intuitive access to self service. Users can reset local passwords. Can be configured to assist mobile users by automatically establishing a temporary, filtered VPN connection.	Risky 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.

P-Synch includes built-in infrastructure to securely and automatically manage the user enrollment process:

By monitoring one or more systems of record, P-Synch 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 providing challenge/response authentication data).
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.
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 challenge/response profiles, login ID reconciliation and voice print samples.

Login ID Reconciliation

Every enterprise identity 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.

P-Synch 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 set of credentials, such as their network login ID and password.
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. P-Synch 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 reconciliation, which is expensive.
Incorrect correlation will allow 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's 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 forgot their passwords can dial an IVR (interactive voice response) 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 (interactive voice response) systems can be extended using a P-Synch remote API (application programming interface), or ID-Telephony® -- a turn-key IVR (interactive voice response) system specifically designed for password resets -- can be acquired from Hitachi ID.

Telephone access (IVR) architecture diagram (7)

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.
ID-Telephony 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.
ID-Telephony server: connects to the P-Synch server.
P-Synch server: looks up the user's profile.
P-Synch server: selects random subset of the user's questions.
ID-Telephony server: prompts the user to answer some questions.
User: speaks answers into the telephone.
ID-Telephony 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. ID-Telephony server: asks P-Synch to generate a random password for this user.
2. P-Synch server: provides a random, policy-compliant password string.
3. ID-Telephony server: enunciates the password and asks the user to accept / retry.
4. User: presses a digit to accept the password choice.
5. ID-Telephony server: asks P-Synch to reset passwords for this user, on selected systems, to the requested password string.
6. P-Synch server: attempts password reset immediately and possibly queues it up for retries.
7. P-Synch 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. P-Synch server: writes a ticket to a call tracking system.
9. P-Synch 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.
ID-Telephony 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.
ID-Telephony server: connects to the P-Synch server.
P-Synch server: looks up the user's profile.
P-Synch server: selects random subset of the user's questions.
ID-Telephony server: prompts the user to answer the selected questions.
User: keys in (numeric) answers to the selected questions.
ID-Telephony server: forwards answers to the P-Synch server.
P-Synch 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. ID-Telephony server: asks P-Synch to generate a random password for this user.
2. P-Synch server: provides a random, policy-compliant password string.
3. ID-Telephony server: enunciates the password and asks the user to accept / retry.
4. User: presses a digit to accept the password choice.
5. ID-Telephony server: asks P-Synch to reset passwords for this user, on selected systems, to the requested password string.
6. P-Synch server: attempts password reset immediately and possibly queues it up for retries.
7. P-Synch 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. P-Synch server: writes a ticket to a call tracking system.
9. P-Synch server: sends the user a confirmation e-mail.

Integration with an Existing IVR System

P-Synch 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 (interactive voice response) 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 P-Synch server, using an encrypted TCP socket based on a shared secret key.

The P-Synch API (application programming interface) 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.

ID-Telephony: A Turn-key Password Reset IVR Solution

Overview:

ID-Telephony is a turn-key telephone user interface for the P-Synch password reset system. It enables organizations to quickly and inexpensively offer self-service password reset to users over a telephone, without making costly changes to existing telephone switching infrastructure.

ID-Telephony is appropriate for users who forgot or disabled their primary workstation login. It also enables mobile and work-at-home users to resolve connectivity issues without calling the help desk.

Features:

An organization's existing help desk ACD (automatic call distribution) system is configured to transfer phone calls relating to password reset, intruder lockout or RSA token management problems from the main help desk phone number to a turn-key ID-Telephony server.

rsa When ID-Telephony receives a phone call, it prompts users to select a language, indicate the type of problem, authenticate themselves and resolve their own problem. ID-Telephony allows users to reset their own passwords on one or more systems, to clear intruder lockouts on one or more of their own accounts and to manage their own RSA SecurID token.

ID-Telephony authenticates callers using Q-A (Question-and-Answer) data stored in P-Synch user profiles or using a two-factor token (e.g., SecurID token or another hardware device). An optional biometric voice print verification engine is also available for ID-Telephony, enabling organizations to authenticate callers by comparing a prompted voice sample to characteristics of a user's voice, stored on file.

Caller authentication data used by ID-Telephony may be periodically imported into P-Synch from another system or may be collected in the course of a managed P-Synch user enrollment, with e-mail reminders to users followed up by users authenticating to a P-Synch web page with their network password and filling in their personal data. Voice print samples can also be enrolled using e-mail prompts to users and user authentication to the P-Synch web application, with a telephone used only for collecting voice samples from web-authenticated users.

ID-Telephony can be configured to support users who speak multiple languages, by recording multiple versions of each voice prompt.

The call flow implemented by ID-Telephony is fully customizable:

The user interface can be uni-lingual or multi-lingual.
Users may be identified by a numeric representation of their alpha-numeric network login ID, or by a numeric identifier such as an employee number.
Callers may be required to reset all of their passwords, or allowed to choose a single password to reset.
New passwords may be randomly generated by P-Synch, or entered by users using a touch-tone keypad.
Users may be given the option to clear an intruder lockout without changing passwords or may always be required to reset passwords.
New passwords may be pre-expired or may be usable until the normal expiration interval passes.

ID-Telephony can integrate with any existing telephony infrastructure. To match ID-Telephony to a given corporate PBX system, an appropriate Intel Dialogic telephony card is chosen. Dialogic cards are available for analog and digital phone systems and range from single-line to 32 phone lines per card. Dialogic cards may be sourced from Hitachi ID or from telephony hardware suppliers.

ID-Telephony may be installed on the same physical server as P-Synch or on its own Windows/Intel servers, with the addition of one or more Intel Dialogic telephony boards. Multiple ID-Telephony servers can integrate with multiple P-Synch servers.

ID-Telephony need not be co-located with P-Synch. Communication between ID-Telephony and P-Synch is carried by a single, encrypted TCP/IP socket. As a result, it is possible to deploy ID-Telephony servers in multiple locations and integrate them with a single cluster of P-Synch servers, securely connecting over WANs, the Internet and/or firewalls.

Benefits:

ID-Telephony enables mobile users, work-at-home users and users who have been locked out of their primary workstation login to resolve their own problem without calling the help desk.

ID-Telephony is an easy-to-deploy solution for telephone access to self-service password resets. In organizations that do not have a pre-existing IVR infrastructure, or in those where modifying IVR call logic is complex or expensive, ID-Telephony is an attractive alternative, as it requires only minimal changes to existing phone switching infrastructure.

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.

P-Synch includes a significant and mature infrastructure for managing (provision, manage passwords and other attributes, deliver to users and deprovision) PKI certificates.

Of necessity, this infrastructure combines a general facility, related to process and certificate storage and platform-specific bindings, for individual PKI products. Currently, Hitachi ID provides a platform binding for Lotus Notes ID files, which are the most widely deployed (though not 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. P-Synch 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. P-Synch 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. P-Synch 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).
P-Synch is the only product to automate not only ID file password resets, but also construction and maintenance of the ID file repository.

Hitachi ID is working on bindings between the general-purpose PKI administration infrastructure in P-Synch and other PKI products, from Microsoft, Entrust, Verisign, GeoTrust and other PKI vendors. Unfortunately, none of these PKI products is currently widely deployed, and demand for integration from Hitachi ID 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 (interactive voice response)) to reset a RAS or VPN password. This does not resolve problems users may encounter with their local workstation passwords or with cached domain credentials.

A locally-deployed secure kiosk account ( LSKA (local, secure kiosk account)) is available to assist mobile and off-site users who have forgotten the password they use to sign into their own workstation. The LSKA (local, secure kiosk account) establishes a temporary network connection, launches a locked-down web browser and allows the user to authenticate and issue a password reset that applies to their network password, both on network authentication services (e.g., Windows / Active Directory domain controllers) and on the local cache (i.e., the cached password used to authenticate the user when the workstation is disconnected). Use of the LSKA (local, secure kiosk account) is as follows:

The user's workstation is physically connected to a phone line or an Internet connection (Ethernet), but is not yet in any way connected to the corporate network.
The user forgot his local password or cached domain password.
The user signs into his workstation as "help" with an easy-to-remember or blank password. Alternately, the user activates a user interface element added to the GINA subsystem, such as an "I forgot my password" button.
LSKA (local, secure kiosk account) is launched. It runs a dialer-wrapper or a VPN-wrapper.
The dialer-wrapper or VPN-wrapper finds connection options in the registry and asks the user to select a connection. Here's an example menu that a user might see:
1. Toll-free dial-up: 1-800-123-4567
2. Direct dial-up: 1-234-456-7890
3. VPN connection
If the user selected a dial-up option, LSKA (local, secure kiosk account) asks him or her to type a dialing prefix. The default value is normally "9" and the user may type up to 3 digits here. (Note: limiting the number of digits prevents the user from abusing the service to dial real phone numbers).
The dialer/VPN-wrapper invokes a RAS or VPN client (Microsoft or third party), passes in either the phone number and dialing prefix or the IP address of the VPN server and credentials it got from the registry.
The dialer/VPN-wrapper waits for a connection. (registry-configurable tests are available to see if a connection has been successfully established. Things like checking for an "up" interface, PING-ing a given IP address, trying TCP connections to a given IP, etc.).
The dialer/VPN-wrapper displays an error dialog and then closes the window if it failed to get a valid connection.
The dialer/VPN-wrapper starts runurl, which is the P-Synch program that launches a locked-down, kiosk-mode web browser. The initial URL is set to the self-service password reset page on the P-Synch server.
The dialer/VPN-wrapper waits for user interaction (web browser to P-Synch web server) to complete in N minutes or less. If N or more minutes pass, it hangs up the user session and returns to the workstation login prompt.
The remainder of the process is a normal P-Synch web-based self-service password reset, which may include reference to an ActiveX component that updates the cached domain password on the workstation after a successful password reset.

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

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

The LSKA (local, secure kiosk account) solution is configured using a set of registry entries -- one registry key per connection service, which are populated when the LSKA (local, secure kiosk account) is installed on a workstation. LSKA (local, secure kiosk account) registry keys contain:

Type (dial vs. VPN)
Phone number
Login ID
Password
Display name, for the dialog box where we ask the user to pick an appropriate connection type
Command-line (with arguments) to use to invoke a connection, with %ARG% expansions for dialing prefix, phone number/IP, userid, password.
URL to pass into RUNURL
Timeout (in minutes or seconds) before it auto-hangs up.
Command-line (with arguments) to use to test for connection and how to tell that it worked / failed (perhaps keywords on stdout?)

Active Directory Replication

(7)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://technet2.microsoft.com/windowsserver/en/library/1465d773-b763-45ec-b971-c23cdc27400e1033.mspx?mfr=true

P-Synch 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

(8) P-Synch has been deployed by very large corporations. Some anecdotal examples of large scalability include:

Organizations with over 250,000 P-Synch users managing passwords on a single P-Synch instance, load balanced between just two servers.
Users distributed over six continents.
A single P-Synch instance, running on a single server, managing passwords on over 500 password systems.
A customer who deployed 20 P-Synch servers, with real-time data replication between them, to allow users to access the system even in the face of network outages.

The P-Synch architectural features that support scalability include:

The ability to install multiple instances per server.
The ability of instances to span multiple servers, where each server in a group is functionally identical; supporting the same users, systems and features.
A built-in, high-performance identity cache, which includes server-to-server data replication in real time.
This engine has been benchmarked at millions of record updates per second on Windows/Intel servers. The database uses standard, open-format files (xBase/DBF) to ensure compatibility with existing reporting and analytical tools.
Built-in services to monitor server health and dynamically update DNS records; for example to remove a malfunctioning server from load balancing rotation.

In addition, P-Synch incorporates many features that, while not directly performance-related, are required by large organizations:

The ability to operate across firewalls: between the user and P-Synch, as well as between P-Synch and managed systems.
Inclusion of a proxy service, which allows a P-Synch server in one location to manage passwords elsewhere, across slow and/or insecure WANs.
Support for multiple user interfaces and UI languages per server instance.
Auto-discovery of user IDs on managed systems, to eliminate ongoing manual administration and to minimize initial setup effort.
The ability to support self-service password reset for users who forgot their initial NOS login password without having to deploy desktop software (secure kiosk account).
Support for 21 user interface languages.

Security Technology

P-Synch 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, storing log data indefinitely and more.

P-Synch never requires plaintext passwords to be stored in configuration files or scripts and does not store plaintext passwords anywhere. P-Synch 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 (9)

Cryptography

Encryption is used to protect stored P-Synch data as follows:

Data	Algorithm	Key
Admin credentials, used to log into target systems	128-bit AES	128-bit random
User authentication Q-A (Question-and-Answer) profile answers	128-bit AES	128-bit random
User old password history	SHA-1	64-bit random salt

Data transmitted to and from P-Synch on the network is cryptographically protected, as follows:

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 OS/390
From Unix
From LDAP server
From WinNT DC
Set passwords, Create/update users
To Unix agent	128-bit AES	128-bit shared secret.
To OS/390 task
To RSA Authentication Manager
To proxy server
API (application programming interface) Session - socket
From calling system / IVR (interactive voice response)	128-bit AES	128-bit shared secret.
API (application programming interface) Session - web services
From calling system / IVR (interactive voice response)	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 P-Synch 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

Once a predefined number of invalid authorization attempts are reached, P-Synch can automatically lock the user out of the system, either for a specified duration or until unlocked by an administrator.

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

Session State Management

P-Synch 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 P-Synch 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 P-Synch server, keyed to the session ID.

Each HTML page in the P-Synch 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 P-Synch server and mapped to session IDs. Keys are valid for a single use and for a limited time. IDs are valid until cleared.

P-Synch 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.

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

Return on Investment

(10) Deploying P-Synch 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 P-Synch, 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.
P-Synch eliminates password problem escalation.

Example savings calculation

The following example illustrates how P-Synch 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.
P-Synch eliminates 80% of password problems, and reduces problem resolution time 2 minutes.

Monthly cost	Initial	P-Synch	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://P-Synch.com/roi/

Platform Support

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

(11)

Directories	File/print	Mainframes
LDAP (any), Active Directory, Windows NT domains, Novell eDirectory, Novell NDS, Unix NIS and NIS+, Kerberos/DCE (any)	Windows NT/2000/2003, Novell NetWare, OS2 LanManager, Samba	MVS / OS/390 / zOS, RACF, CA-ACF2, CA-TopSecret, VM/ESA, Siemens BS2000, Tandem NonStop, Unisys MCP
Unix	Midrange	Database
AIX, DGUX, Digital Unix, HPUX, IRIX, Linux, NCR, OSF4, SCO OS, Solaris, SunOS, Tru64, UnixWare, Unisys, passwd, shadow, Trusted Computing Base	HP MPE, OS/400/iSeries, OpenVMS	DB2/UDB, Informix, MSSQL, ODBC, Oracle, Sybase
ERP	Messaging	WebSSO
SAP R/3 4.0+, PeopleSoft 7.5+, Oracle Applications 11i+, JDE OneWorld	MS Exchange 5.5, MS Exchange 2000/03/07, Novell GroupWise, Lotus Domino/HTTP, Lotus Notes/ID files, HP OpenMail	IBM TAM, RSA ClearTrust, Entrust getAccess, CA SiteMinder, Oracle COREid, SAP portal
Flexible agents	Hardware tokens and Smartcards	Miscellaneous
API (application programming interface) integration, LDAP attributes, MQ Series, SQL commands, Telnet/TN3270/TN5250 sessions, Unix/Windows cmd-line integration, web forms, web services (SOAP, XML)	RSA SecurID, Secure Computing SafeWord, Vasco Digipass, GemPlus, Precise Biometrics	RADIUS (various), Local and cached Windows passwords. Peregrine ServiceCenter, Remedy ARS, Clarify eFrontOffice, NAI Magic, Tivoli ADSM, IBM OLAP, IBM Tivoli Access Manager Connected Backup

(12)P-Synch includes a number of flexible agents, each of which is programmable (and thus can be said to embody an SDK (software development kit)). These agents allow organizations to quickly and with a minimum of programming or scripting, integrate P-Synch with custom and vertical market applications.

Flexible agents expose a number of processes, including:

Binding to an existing management API (application programming interface) (Java, Win32, Unix, COM, etc.).
Screen-scraping Telnet, TN3270, TN5250, SSH and raw TCP socket connections.
Navigating through web-based administration user interfaces over HTTP and HTTPS, with support for cookies, form parsing, redirects, etc.
Executing arbitrary SQL code on Oracle, Sybase, MSSQL, DB2/UDB, Informix and other (ODBC) types of databases.
Executing command-line administration programs on Unix (via local agent) and Win32 (on the P-Synch server).
Manipulating arbitrary attributes in an LDAP directory.
Posting updates to a web service (SOAP or other XML dialect over HTTP or HTTPS).
Sending messages using MQ Series.

Organizations that wish to write a completely new agent to a custom or vertical market application may do so using whatever development environment they prefer (J2EE, .NET, Perl, etc.) and invoke it as a command-line or web service target using the appropriate P-Synch flexible agent.

An effort of 4 hours to 4 days is typically required to integrate P-Synch with a custom or vertical market application. This compares favorably with competitors' products, where a custom Java or other 3GL connector must be written from scratch, taking weeks or months and requiring the P-Synch administrator to have significant programming experience and the ability to learn how to use a new framework and API quickly.

Other Integrations

P-Synch integrates closely with existing IT infrastructure:

Help Desk Systems

P-Synch 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. P-Synch currently includes binary interfaces for the following help desk ticketing applications:

Axios Assyst
BMC (formerly NAI) Magic (any version)
CA Unicenter Help Desk
Clarify eFrontOffice (currently just version 8)
FrontRange HEAT (any version)
HP Service Desk
Peregrine ServiceCenter (any version)
BMC/Remedy ARS (any version)
Siebel ERM (any version; using web services)
SupportSoft (any version; using web services)
Tivoli Problem Management / Service Desk (any version)
... and more

Authentication Devices

P-Synch 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.

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

Electronic Mail

Over 163 events throughout P-Synch 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

P-Synch 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 P-Synch, and uploaded into a meta directory, such as Microsoft ILM.

Rapid Deployment

Hitachi ID solutions are optimized for rapid deployment and this is a core design characteristic for all our products. Features such as a dynamic workflow, eliminating the need for role engineering, auto-discovery and self-service login ID reconciliation are intended specifically to eliminate cost and delays that separate product acquisition from production deployment.

(13) P-Synch 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 P-Synch.
Pre-built agents for 70+ systems eliminating the need for customers to develop their own connectors to common, off-the-shelf target systems.
Remote agents mean that P-Synch can manage users and passwords on systems without requiring the installation of intrusive local software on each target system.
Flexible agents enable organizations to integrate P-Synch 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 is committed to providing end-to-end identity management solutions to our customers. We support our clients from initial requirements discovery, through solution design, product deployment, and our proprietary Adoption Maximizer (AdMax®) program.

Successful implementation of an identity management system must be supported by an effective user adoption plan. For over ten years, Hitachi ID 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 to develop our AdMax program.

AdMax enables Hitachi ID 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's AdMax program is initiated during the discovery phase and completed only after the system is deployed and both Hitachi ID and the client sign off on the completed rollout.

The AdMax solution delivery process includes six components:

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

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