White Papers Frequently Asked Questions FAQ for Network Architects
Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

Hitachi ID Password Manager FAQ for Network Architects


How does Hitachi ID Password Manager 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 target 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:


What kind of database does Password Manager use?

Password Manager must be configured with a SQL-based relational database. The Password Manager replicating data service can be configured to use any of the following SQL database engines as its physical data store:

While the database server may be 32 or 64 bit, a 32-bit DB client is currently required. Hitachi ID Systems intends to switch from 32-bit application server code to 64-bit server code once adoption of Windows 2008R2 becomes dominant among our customers -- likely in 2014.

Password Manager maintains an identity cache in the database, which contains data about users, identity attributes and group memberships drawn from target systems nightly. This cache significantly improves the run-time performance of Password Manager, as it eliminates the need to repeatedly connect to target systems or to an external directory, to look up the same identity attributes again and again during the course of a workflow request or interactive user session.

The identity cache built into Password Manager:


What systems does Password Manager support?

(1)

Directories:

Servers:

Databases:

Any LDAP, AD, NDS, eDirectory, NIS/NIS+.

Windows 2000--2012, Samba, NDS, SharePoint.

Oracle, Sybase, SQL Server, DB2/UDB, ODBC, Informix.

Unix:

Mainframes:

Midrange:

Linux, Solaris, AIX, HPUX, 24 more variants.

z/OS with RAC/F, ACF/2 or TopSecret.

iSeries (OS400), OpenVMS.

ERP:

Collaboration:

Tokens, Smart Cards:

JDE, Oracle eBiz, PeopleSoft, SAP R/3, SAP ECC 6, 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, ServiceNow, HP Service Manager, CA Unicenter, Assyst, HEAT, Altiris, Clarify, Track-It!, RSA Envision, MS SCS Manager.

McAfee, CheckPoint, BitLocker, PGP.

SaaS:

Miscellaneous:

Extensible:

Salesforce.com, WebEx, Google Apps, MS Office 365, SOAP (generic).

OLAP, Hyperion, iLearn, Caché, Success Factors, VMWare vSphere. Cisco IOS, Juniper JUNOS, F5, iLO cards, DRAC cards, RSA cards, etc.

SSH, Telnet, TN3270, HTTP(S), SQL, LDAP, command-line.

 


On what platform does Password Manager run?

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

Installing on a Windows server 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):

  1. IIS is not required (Apache is a reasonable substitute).
  2. No ASP, JSP or PHP are used, so these engines should be disabled.
  3. .NET is not required on the web portal and in most cases can be disabled on IIS.
  4. No ODBC or DCOM are required inbound, so these services should at least be filtered.
  5. File sharing should be disabled.
  6. Remote registry services should be disabled.
  7. Inbound TCP/IP connections should be firewalled, allowing only port 443 and possibly terminal services (often required for some configuration tasks).

Each Password Manager server requires a database instance. SQL 2008R2 or SQL 2012 are the most common options, but Oracle database is also supported.


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. The entire UI is web based, and renders as straightforward HTML and CSS, with a bit of JavaScript for things like automatically placing the cursor in the correct field. As such, it is quite conventional and portable. Most customers brand the UI simply by modifying the CSS.

User interface customization is simple to implement. All HTML text is pulled into the web app from a "skin" file which is editable. HTML in web apps is highly repetitive -- every page looks more or less the same. Password Manager uses a simple macro system to factor out such commonalities, which allows customers to quickly customize the look and feel of the entire UI and ensure consistency between pages. This means that customers do not normally edit a skin file directly, but rather edit HTML snippets in a macro file and recompile a new skin. This is faster and more consistent.

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. The application does specify navigation sequence (i.e., what each screen does and how one navigates from one screen to another) but this too is quite customizable using a variety of policy settings.

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 need to learn. Rather, what complexity does exist is in the information architecture (which UI 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.

All English text in the UI is stored in a language file, and translations are supported by installing multiple language files. The same instance of the software may be accessed by different users in different languages, at the same time -- just by specifying a language in the URL. This mechanism means that all UI text is customizable by customers, either by editing the language file directly or by signing into our software in a special "language translation" mode which allows a user to change UI text by clicking on it and editing in-app.

UI customizations are defined separately from the core UI, using an override scheme. This allows 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 portal. 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 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:

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

Password Manager includes over 189 exit points. (4) Exit points may be triggered by many events, including:

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: