Hitachi ID Password Manager FAQ for Network Architects

How does Hitachi ID Password Manager (formerly P-Synch) reset passwords?

Password Manager resets passwords by signing into the target system with its own privileged password, looking up the relevant login account, setting the password attribute for that user and logging off from the target system.

At least one privileged ID/password is encrypted into the Password Manager database for each managed system.

On systems that support it, Password Manager's own credentials can be given limited privileges -- the right to list users, to search for users, to reset passwords and to set/clear flags such as intruder lockout.

Password Manager is web based. Client communication to the web server is HTTPS, while the server communicates with the managed systems directly using their various native protocols or via a Password Manager proxy server (128-bit AES encrypted TCP socket) or using a server-side agent (Unix, z/OS RSA Authentication Managers) with the same TCP socket encryption.

How does Password Manager synchronize passwords?

Since passwords are typically hashed on each system in a non-reversible, fashion and since different systems use incompatible password hashes, password synchronization must be an active process that takes place whenever users change their passwords.

There are really just two ways to synchronize passwords. Password Manager supports both of the possible mechanisms for password synchronization:

Transparent synchronization:
Password Manager can be configured to intercept native password changes on certain systems and:
- Apply a password policy beyond the one built into the system where a native password change first happened and potentially reject the initial password change
- Automatically synchronize the user's other passwords, on other systems, to the same value
Systems that can trigger password synchronization are Windows server or Active Directory (32-bit, 64-bit), Sun LDAP, IBM LDAP, Oracle Internet Directory, Unix (various), z/OS and iSeries (AS/400).
Web-based synchronization:
Users authenticate to the Password Manager web GUI, using any browser, by keying in their NOS or directory ID and password. They can then set a single password on one or more of their own IDs on one or more systems.

What kind of database does Password Manager use?

In most deployments, Password Manager does not require an external database. Rather, it defers to current state on target systems as authoritative.

Password Manager uses a built-in identity cache to store system configuration information and to cache user profile data drawn from managed systems. The cache significantly improves the run-time performance of Password Manager, as it eliminates the need to repeatedly connect to managed systems or to an external directory, to look up the same identity attributes again and again during the course of a session. The cache is not an authoritative data source -- it simply holds copies of user profile data close to the application, to improve performance.

The identity cache built into Password Manager:

Is not an authoritative source of data -- it is flushed nightly.
Stores data in an industry standard format (xBase/DBF), which most third-party query and reporting programs tools can read directly or through a standard Windows ODBC driver.
Note that third party software should only be used to query copies of Password Manager data files, not from the live dataset.
Is extremely fast (e.g., 1,000,000 record updates/second) and scalable (1 billion records/table).
Includes automatic data replication between multiple Password Manager servers (implemented by an included Password Manager data replication service), which provides for both scalability and high availability out of the box.

In Password Manager up to version 6.x and other products up to 4.x, the identity cache is implemented using the CodeBase embedded database engine. This is an open (ODBC-accessible, standard file format) system which does not require a separate software license or a DBA. It is installed as an integral component of Password Manager.

Starting with Password Manager version 7.x and other products 5.x, customers must choose either MS SQL Server or Oracle Database to house the identity cache and other Password Manager data. The free "express" editions of these products are acceptable and the "enterprise" editions are recommended.

In almost all deployments, Password Manager rebuilds the internal identity cache nightly, by pulling information from target systems. This process is fault tolerant (i.e., failure to reach a target system causes older information to be retained).

Some organizations already have user profile data, such as login IDs for each user on each system or security questions suitable for user authentication, in an existing database or directory. Password Manager is designed to plug into existing user profile databases or directories (using LDAP, ODBC, etc.), looking up user data at run-time, as required.

A set of built-in plug-in programs is provided to draw user profile data from LDAP, Active Directory or any ODBC database. This can either be done in real-time or in batch imports (for example, nightly).

What systems does Password Manager support?

(1)

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.

On what platform does Password Manager run?

Password Manager must be installed on a Windows 2003 or Windows 2008 server.

Installing on Windows 2003 or Windows 2008 allows Password Manager to leverage client software for most types of target systems, which is available only on the "Wintel" platform. In turn, this makes it possible for Password Manager to manage passwords and accounts on target systems without installing a server-side agent.

The Password Manager server must also be configured with a web server. Since the Password Manager application is implemented as CGI executables, any web server will work. The Password Manager installation program can detect and automatically configure IIS or Apache web servers, but other web servers can be configured manually.

Password Manager is a security application and should be locked down accordingly. Please refer to the Hitachi ID Systems document about hardening Password Manager servers to learn how to do this. In short, most of the native Windows services can and should be removed, leaving a very small attack surface, with exactly one inbound TCP/IP port (443):

IIS is not required (Apache is a reasonable substitute).
No ASP, JSP or PHP are used, so these engines should be disabled.
.NET is not required on the web UI, so should be disabled on IIS.
No ODBC or DCOM are required inbound, so these services should at least be filtered.
File sharing should be disabled.
Remote registry services should be disabled.
Inbound TCP/IP connections should be firewalled, allowing only port 443 and possibly terminal services (if required for some configuration tasks).

In what ways can Password Manager be customized?

(2) (3) The entire Password Manager user interface is customizable and translatable. This includes graphical changes, text changes, layout changes, language translations, etc. No user interface elements are hard-coded into Password Manager.

User interface customization is simple to implement. Common elements, such as page layout and HTML preambles, are factored out into standard macros using an open source macro language (M4). Modifications made to M4 macros are propagated across the entire user interface.

Note that M4 (at least as it is used in Password Manager) is really just 3 keywords: include, define and ifelse. It is not something that administrators really have to learn. Rather, the complexity is in the information architecture (what elements are defined where). To customize the Password Manager UI, all that is needed is an understanding of HTML and CSS, plus a bit of patience to find the right macro to edit -- so that a change will propagate to the entire UI.

UI customizations are defined separately from the core UI, using a macro override scheme. This allows most customizations to survive Password Manager version upgrades with minimal intervention. For example, customers may define a new markup for HTML tables. This markup is placed in an override file and takes precedence over the default HTML table code. When Password Manager is upgraded, the customized markup will continue to take precedence over default HTML code.

In addition to modifying HTML and CSS code, customers can change the values of a number of system variables which alter Password Manager behavior. For example, password policy, intruder lockout frequency and duration, non-password authentication rules and more can all be adjusted from the Password Manager administrative web UI. System variables also survive version upgrades.

Password Manager behavioral modifications are made using plug-in points, rather than (as is common with many other applications) by modifying the JSP or ASP source code of Password Manager itself.

Plug-ins are scripts or executables installed on the Password Manager server. Password Manager components call plug-in programs to make business policy decisions or to look-up information. Examples include:

Look up a user's known, existing login accounts.
- Helpful for integration with an existing meta directory.
- Plug-ins are provided for LDAP directories and SQL databases.
Look up a user's security questions.
- Can be used to leverage existing authentication data.
- Plug-ins are provided for LDAP and SQL implementations.
Assign a new login ID to a newly created user.
- A sample script is provided that implements popular ID schemes.
Validate form inputs for workflow requests.
- Is normally used to validate form inputs, such as checking that a new hire's home address has mutually-consistent city, state and area code fields.
- Can also populate hidden fields (e.g., directory OU) and assign IDs (e.g., e-mail address) based on business policy.
Assign appropriate authorizers to workflow requests.
- May be based on the requester, recipient, entitlements or operations involved.
- Global authorization logic is easier to manage than assigning static authorizers to every conceivable kind of request.
Escalate from non-responsive authorizers to alternates.
- A default implementation is provided, to escalate to the previous authorizer's manager.

This architecture, which encapsulates business logic into stand-alone scripts or executables, has two important benefits:

It is significantly easier for organizations to adjust Password Manager behavior, since all such modifications are made in simple, self-contained files.
Business logic implemented in this way survives Password Manager version upgrades, reducing the cost and delay associated with major upgrades.

(4) Password Manager includes over 179 exit points.

Exit points may be triggered by many events, including:

Attempts to sign into Password Manager (successful or failed).
One user looking up the profile of another.
Changes to a user's profile, such as creating a new account or changing attributes or group memberships for an existing account.
Assigning a role to a user or removing a user from a role; changing Password Manager's configuration.
Running a report.
Triggering an intruder lockout.

Example uses of exit points include sending e-mails to users or administrators and creating, updating or closing incident records in an incident management application, notifying an IT infrastructure management system of an integration problem or recording a security event to a security incident event management (SIEM) or intrusion detection (IDS) system.

Various pre-built interface programs designed for use with exit points are included with Password Manager. They are generally scriptable and simplify the process of creating help desk incidents (e.g., BMC Remedy, HP Service Manager and the like) and sending e-mails.

For clarity, it should be noted that exit programs and plug-in programs in Password Manager are distinct components that serve different functions. Whereas plug-in programs are bidirectional -- Password Manager sends data to the plug-in, the plug-in responds with data that alters Password Manager's behavior -- exit programs are uni-directional and are used strictly to pass information outbound from Password Manager to other applications.

How does Password Manager compare to the "password reset disk" in Windows XP and .NET?

Starting with Windows XP, users can create a "password reset disk" whenever they change their passwords.

If a user forgets his login password, he can log into his workstation by typing his login ID but leaving the password field blank and instead inserting a previously-created password reset disk.

This feature is helpful for home users, but is significantly less useful than self-service password reset with Password Manager:

Does not work for domain users: The password reset disk feature does not work for domain passwords -- only local ones.
Inconvenient: Users must create a new disk whenever they change their passwords. In comparison, users register with Password Manager just once.
Inconvenient: Mobile must carry the password reset disk with them. In comparison, users can access Password Manager from any computer, at any time.
Insecure: Anyone who can touch the password reset disk can steal or copy it and subsequently log into the user's account. There is no comparable vulnerability in Password Manager.