Previous Next PDF

swipe to navigate

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, the credentials used by Password Manager 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.

Communication from user devices to Password Manager is HTTPS, so encrypted with SSL/TLS.

Communication from Password Manager to managed endpoints uses the various native protocols supported by each type of endpoint. i.e., the protocol used has everything to do with the type of endpoint system and what it "understands" and not much to do with Password Manager. Where communication to the endpoint is insecure, a Password Manager proxy server can be co-located with the endpoint system, so that most of the communication path (from main Password Manager server to proxy) is encrypted and the "last mile" uses that system's insecure protocol. Main server to proxy communication is TCP/IP with a shared key and 256-bit AES.

For z/OS mainframes, a local agent is also available, to eliminate the need for scripted TN3270 sessions. Communication to this local agent is encrypted (as above).

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 portal, 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?

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

  • Microsoft SQL Server 2016/2014/2012, Standard Edition.
  • Microsoft SQL Server 2016/2014/2012, Express Edition, with Advanced Services (free download from -- suitable for development, test and very small production environments.

Password Manager maintains an identity cache in the database, which contains data about users, identity attributes and group memberships drawn from target systems every few hours. 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:

  • Is not an authoritative source of data -- it is updated on a scheduled basis (i.e., every few hours).

  • Stores data in a clearly documented SQL schema, available to 3rd party reporting programs.

  • Includes automatic data replication between multiple Password Manager servers. This supports both scalability and high availability.

What systems does Password Manager support?

Directories: Databases: Server OS -- X86/IA64:
Active Directory and Azure AD; any LDAP; NIS/NIS+ and eDirectory. Oracle; SAP ASE and HANA; SQL Server; DB2/UDB; Hyperion; Caché MySQL; OLAP and ODBC. Windows: NT thru 2016; Linux and *BSD.
Server OS -- Unix: Server OS -- Mainframe: Server OS -- Midrange:
Solaris, AIX and HP-UX. RAC/F, ACF/2 and TopSecret. iSeries (OS400); OpenVMS and HPE/Tandem NonStop.
ERP, CRM and other apps: Messaging & collaboration: Smart cards and 2FA:
Oracle EBS; SAP ECC and R/3; JD Edwards; PeopleSoft;; Concur; Business Objects and Epic. Microsoft Exchange, Lync and Office 365; Lotus Notes/Domino; Google Apps; Cisco WebEx, Call Manager and Unity. Any RADIUS service or SAML IdP; Duo Security; RSA SecurID; SafeWord; Vasco; ActivIdentity and Schlumberger.
Access managers / SSO: Help desk / ITSM: Drive encryption:
CA SiteMinder; IBM Security Access Manager; Oracle AM; RSA Access Manager and Imprivata OneSign. ServiceNow; BMC Remedy, RemedyForce and Footprints; JIRA; HPE Service Manager; CA Service Desk; Axios Assyst; Ivanti HEAT; Symantec Altiris; Track-It!; MS SCS Manager and Cherwell. Microsoft BitLocker; McAfee; Symantec Endpoint Encryption and PGP; CheckPoint and Sophos SafeGuard.
Server health monitoring: HR / HCM: Extensible / scriptable:
HP iLO, Dell DRAC and IBM RSA. WorkDay; PeopleSoft HR; SAP HCM and SuccessFactors. CSV files; SCIM; SSH; Telnet/TN3270/TN5250; HTTP(S); SQL; LDAP; PowerShell and Python.
Hypervisors and IaaS: Mobile management: Network devices:
AWS; vSphere and ESXi. BlackBerry Enterprise Server and MobileIron. Cisco IOS PIX and ASA; Juniper JunOS and ScreenOS; F5 BigIP; HP Procurve; Brocade Fabric OS and CheckPoint SecurePlatform.
Filesystems and content: SIEM: Management & inventory:
Windows/CIFS/DFS; SharePoint; Samba; Hitachi Content Platform and HCP/Anywhere; and Twitter. Splunk; ArcSight; RSA Envision and QRadar. Any SIEM supporting SYSLOG or Windows events. Qualys; McAfee ePO and MVM; Cisco ACS; ServiceNow ITAM; HP UCMDB; Hitachi HiTrack.

On what platform does Password Manager run?

Password Manager must be installed on a Windows 2016, Windows 2012 or Windows 2012/R2.

Installing on a Windows server allows Password Manager to leverage client software for most types of target systems, which is available primarily 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.

Each Password Manager application server requires a web server. IIS is used as it comes with the Windows 2016 & Windows 2012 Server OS.

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. No ASP, JSP or PHP are used, so such engines should be disabled.
  2. Web-facing .NET is not used and should be disabled (some connectors require it, due to .NET API bindings).
  3. No ODBC or DCOM are required inbound, so these services should be filtered or disabled at the web server. As with .NET, ODBC is sometimes needed to connect to target systems.
  4. Inbound file sharing should be disabled.
  5. Remote registry services should be disabled.
  6. Inbound TCP/IP connections should be firewalled, allowing only port 443, remote desktop services (to configure the software) and a handful of ports between Password Manager servers, mainly for data replication.

Each Password Manager server requires a database instance. Microsoft SQL 2016 is the recommended choice. Microsoft SQL 2014 and 2012 are also supported. Oracle database was supported on versions up to 9.0.x and is not supported on 10.0 or later releases.

In what ways can Password Manager be customized?

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 these 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 macros (at least as used in Password Manager) consists of just 3 keywords: include, define and ifelse -- the macro language is trivial. 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 configuring the web portal to run in a special "language translation" mode which allows a user to change UI text by clicking on it and editing interactively.

UI customizations are defined separately from the core UI, using an override mechanism. 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 which takes precedence over the default HTML table code. When Password Manager is upgraded, the customized markup will continue to take precedence over default HTML markup.

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:

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

Password Manager includes over 300 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.
  • Triggering an intruder lockout.
  • Password synchronization or reset, success or failure.
  • Checking out a managed account, account set or group set.
  • Time-out of a privileged access session.
  • 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 configuration.
  • Running a report.

Example uses of exit points include sending e-mails to users, manipulating incidents in a ticketing system or forwarding an event to a security incident/event management (SIEM) system.

Various pre-built interface programs designed to be called from exit points are included with Password Manager. Scriptable interface programs can create help desk incidents (e.g., ServiceNow, BMC Remedy, HP Service Manager, etc.) and sending e-mails.

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 PC 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 enroll with Password Manager just once.

  • Inconvenient: Mobile users 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.

Previous Next PDF