Skip to main content

Privileged Access Manager Product Q&A

What business problems does Hitachi ID Privileged Access Manager address?

It can be difficult to securely manage access to thousands of privileged accounts. Consequently, in many organizations, the passwords to privileged accounts are:

  • known to many people, possibly including former staff,
  • often the same on many systems,
  • rarely if ever changed, and
  • stored in plaintext, by people and by applications.

There are serious consequences to these password management practices, including:

  • There is no accountability for use of shared, privileged accounts. This is both a security / regulatory compliance problem and a problem with diagnosing operational problems.
  • Former staff may retain sensitive access.
  • Attackers have an easier time compromising these dangerous accounts.
  • If one system is compromised (e.g., an IT user's PC or an application server), the attacker can leverage passwords stored or typed on that system to compromise additional systems.

How does Privileged Access Manager work?

There are several technological approaches to more securely managing privileged passwords:




Eliminate shared passwords entirely and assign personal administrator-level accounts to each IT user, on each asset.

Individual accountability for configuration changes.

Too many administrator-level accounts on each system.

Create and delete personal administrator-level accounts for users on demand.

Individual accountability for configuration changes.

Complex integration between many systems and the corporate directory.

Modify operating systems and applications to check whether users are allowed to perform privileged actions, in real time. Manage access control policies centrally.

Fine-grained control over user access.

Too many administrator-level accounts on each system plus complex change control on each system.

Use software installed on each device to periodically change local passwords. Send a copy of these passwords to a secure vault, shared by many systems.

Works even in complex, segmented networks.

Requires software on each managed system.

Software on a central system periodically pushes new passwords to each device and keeps copies in a secure vault.

Minimal footprint on managed systems.

Requires connectivity from a central application to managed systems.


How often does Privileged Access Manager change passwords?

This is configurable, with the default being every 24 hours.

Privileged Access Manager secures sensitive passwords by periodically setting them to new, random values:

  1. On systems integrated via "push mode:"
    1. Periodically -- for example, every night between 3AM and 4AM.
    2. When users check accounts back in, after they are finished using them.
    3. When users request a specific password value.
    4. In the event of an urgent termination of a system administrator (randomize all passwords that person may have known).
    Note that "push mode" normally means that no software is deployed to the managed endpoint system.

  2. On systems integrated via "pull mode:"
    1. Periodically -- for example, every day.
    2. At a random time-of-day, to even out workload on the Privileged Access Manager service.
    3. Opportunistically, whenever network connectivity happens to be available from the managed endpoint to the central privileged access system.
    Note that "pull mode" implies a local agent on the managed endpoint system. This approach is useful on laptops, on rapidly provisioned/deprovisioned VMs in a cloud environment and in some isolated network segments.

How do we control who can sign into which privileged accounts?

The most common form of access control in the Privileged Access Manager is based on managed system policies. These policies are named collections of managed systems containing privileged accounts whose passwords may be randomized and access to which is controlled.

Managed systems may either be attached to a policy explicitly (e.g., "attach system SYS0123 to policy MSP-A") or implicitly, using an expression such as "all systems of type Linux at are attached to MSP-B". Expressions may be based on the operating system type, IP address, MAC address, system name or other metadata.

Managed system policies are configured with operational and access control rules, including:

  1. Which accounts' passwords to randomize on attached systems.
  2. How often to change passwords.
  3. How to compose random passwords (e.g., length, complexity, etc.).
  4. What actions to take after successful or failed attempts to disclose access.
  5. What access disclosure methods to offer authorized users -- e.g., launch a given type of client program with ID/password from the credential vault, display a password, copy buffer integration, temporary group membership or SSH trust, etc.

Privileged Access Manager users are organized into user groups, also either explicitly or implicitly. Most commonly, users are assigned to Privileged Access Manager user groups by virtue of their membership in Active Directory or LDAP groups. Groups of users are then assigned specific rights with respect to specific managed system policies. For example, "every user in group A may launch RDP sessions to privileged accounts on systems in policy B."

Business rules, such as segregation of duties between different sets of users, can also be enforced. This is done by examining, managing and limiting group membership on reference systems, such as Active Directory or LDAP.

How do we grant someone temporary or one-time access to a privileged account?

Privileged Access Manager includes the same authorization workflow engine as is used in Hitachi ID Identity Manager. Workflow enables users to request access to a privileged account that was not previously or permanently authorized. When this happens, one or more additional users are invited (via e-mail or SMS) to review and approve the request. Approved requests trigger a message to the request's recipient, including a URL to Privileged Access Manager where he or she can re-authenticate and "check out" access.

The workflow process is illustrated by the following series of steps:

  1. User UA signs in and requests that access to privileged account PA on system S be made available to user UB at some later time T. UA may be the same person as UB (a self-service request).
  2. Privileged Access Manager looks up authorizers associated with LA on S.
  3. Privileged Access Manager may run business logic to supplement this authorizer list, for example, UA or UB's manager. The final list of authorizers is LA. There are N authorizers but approval by just M (M <= N) is sufficient to disclose the password to PA.
  4. Privileged Access Manager sends e-mail invitations to authorizers LA.
  5. If authorizers fail to respond, they get automatic reminder e-mails.
  6. If authorizers still don't respond, Privileged Access Manager runs business logic to find replacements for them, effectively escalating the request. Privileged Access Manager will invite replacement authorizers next.
  7. Authorizers receive invitation e-mails, click on a URL embedded in the e-mail invitation, authenticate themselves to the Privileged Access Manager web portal, review the request and approve or deny it.
  8. If any authorizers deny the request, e-mails are sent to all participants (UA, UB and LA) and the request is terminated.
  9. If M authorizers approve the request, thank-you e-mails are sent to all participants. The e-mail sent to the recipient includes a URL to an access disclosure page.
  10. UB clicks on the e-mail URL and authenticates to Privileged Access Manager.
  11. UB clicks on a button in the web portal to check-out privileged access.
  12. UB then may click on a button to do one of the following (the options available will vary based on policy):
    1. Display the password (rarely allowed).
    2. Place a copy of the password in the operating system copy buffer (sometimes allowed).
    3. Launch an RDP, SSH, vSphere, SQL Studio or similar login session to PA on S (most common).

Can we configure a "two keys to launch" scenario for super-sensitive systems?

Privileged Access Manager supports approval of change requests by multiple business stake-holders and/or by multiple groups of business stake-holders. This allows for typical scenarios such as "approve this request by recipient's manager plus departmental IT contact plus application owner."

Since individuals may be unavailable to respond to a request, authorization can substitute groups for single approvers. Thus, the above example may be reformulated as "approve this request by recipient's manager or any of the manager's peers; plus either of two departmental IT contacts; plus any of three designated security contacts for the indicated application."

Change authorization is normally conducted by sending invitations to all authorizers at the same time. This "parallel" invitation process yields faster approval turn-around times but has no impact on security, since all requisite approvers must respond before a request is completed. Sequential invitations are also possible but are not recommended by Hitachi ID Systems due to the longer total time elapsed before all participants will approve or deny a request.

Can Privileged Access Manager manage password changes to Windows service accounts?

On the Windows operating system, service programs are run either using the SYSTEM login ID, which possesses almost every privilege on the system (and consequently can do the maximum harm) and which requires no password or using a named local or domain account. Services are run in the security context of a named account in order to reduce the privileges available to them at runtime.

When Windows services are run with a named account, the password for that account is needed to start the service process. This means that the Service Control Manager (SCM), IIS web server, Scheduler, etc. all need to know both the ID and password of service accounts, when they are configured to run jobs, services, application pools or similar contexts as a named account, rather than as SYSTEM.

Service account passwords differ from administrator passwords in that they appear in at least two places:

  1. Hashed, in the security database -- e.g., the local SAM database or Active Directory, just like any other account.
  2. Reversibly encrypted or plaintext, in the registry or a configuration file, where the program that starts the service (e.g., Service Control Manager, Scheduler, IIS, ...) can retrieve the password value when starting a new service process.

Some Windows components, notably IIS, are able to periodically change the passwords of local service accounts they use. Unfortunately, this capability does not extend to domain service accounts, used to run services on multiple systems and does not apply to all types of service accounts. This means that many Windows service account passwords remain static by default.

Privileged Access Manager can be configured to secure service account passwords. This means two things, depending on the mode of operation:

  1. In push mode (i.e., no local agent on the Windows server), Privileged Access Manager servers periodically connect to Windows servers or Active Directory in order to change the passwords of service accounts.
  2. If the local workstation service is installed on a Windows system (i.e., the "pull mode" agent), the Privileged Access Manager service periodically changes service account passwords locally, in coordination with the central Privileged Access Manager server cluster.

In both cases, Privileged Access Manager must notify the program that launches services -- the subscriber -- of the new password value, so that it can successfully launch the service at the time of the next system restart or when an administrator manually stops and restarts the service in question. In some cases, for example when domain accounts are used to run services, an immediate restart may be required or advisable, due to Kerberos token expiry. Privileged Access Manager can be configured to restart services after each automated password change.

Privileged Access Manager includes extensive automation to discover subscribers and subscriber-to-service-account dependency. This allows Hitachi ID Systems customers to review what services are run in the security context of what named users, on what systems. This is particularly helpful where services run in the security context of domain accounts, since multiple services on multiple servers may run as the same service account and may therefore require notification after each password change.

Privileged Access Manager includes several mechanisms to accomplish safe and secure changes to service account passwords:

  1. Auto-discovery of subscriber/account dependencies for a variety of subscriber types: IIS (multiple sub-components may have service accounts/passwords), Scheduler, SCM, DCOM, at various OS and subscriber versions.
  2. White-list policy tables:
    1. Initialized with discovered data about service accounts and services.
    2. Allow organizations to specify a password randomization schedule.
    3. Allow organizations to name application owners, who will be notified of password changes and any issues.
    4. Allow organizations to specify a style of notification. For example, notify the subscriber of new password values before a password change, after or both? Restart the subscriber or not?
  3. A mechanism that tests for the availability of all subscribers before each password change. In particular, if some systems where services run in the security context of a domain service account are unreachable, then changes to that account's password will be deferred.
  4. Built-in tools to notify subscribers of new password values and restart services if this was specified in the policy.
  5. A transaction manager that will retry notifications to subscribers that went off-line after a password was changed and before they could be notified of the new password value.

The above are primarily used when managed systems are integrated with Privileged Access Manager in "push mode" -- i.e., there is no locally installed agent on the target system and Privileged Access Manager initiates all connections remotely, over the network, directly or via a Privileged Access Manager proxy server deployed near the target system.

Where push mode is inappropriate -- for example because the relevant services (remote registry, WMI, etc.) are disabled or firewalled or because the end system is offline or inaccessible due to name resolution or IP routing issues (NAT, etc.), a local workstation service can be installed on the managed system, which performs essentially the same functions but with much simpler connectivity (call home over HTTPS) and no need for network accessible services on the local system.

The local workstation service is most often used on laptops and in firewalled network segments (DMZs).

Privileged Access Manager is normally configured to contact application owners after each password change and in the event of a problem. This makes troubleshooting easier in the event that notification failed and a service subsequently could not be started.

The entire infrastructure mentioned here is extensible. Customers can expand it to support other process-launching systems, such as third job party schedulers for example.

Can Privileged Access Manager randomize passwords on ....?

Privileged Access Manager comes with connectors for many popular systems and applications, as illustrated below. All connectors are included in the base price.




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

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

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




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

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

iSeries (OS400), OpenVMS.



Tokens, Smart Cards:

JDE, Oracle eBiz, PeopleSoft, SAP R/3, SAP ECC 6, Siebel, Business Objects.

Lotus Notes, Exchange, BlackBerry ES.

RSA SecurID, SafeWord, RADIUS, ActivIdentity, Schlumberger.


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 (PointSec), Microsoft (BitLocker), Symantec (PGP), Sophos SafeGuard (Sophos).



Extensible:, WebEx, Google Apps, MS Office 365, Concur, AWS, vCloud, 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.


Privileged Access Manager includes a number of flexible connectors, each of which is used to script integration with a common protocol or mechanism. These connectors allow organizations to quickly and inexpensively integrate Privileged Access Manager with custom and vertical market applications.

There are flexible connectors to script interaction with:

API binding:

Terminal emulation:

Web services:

Back end integration:


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

  • SSH
  • Telnet
  • TN3270, TN5250
  • Simulated browser

  • SOAP
  • REST
  • Pure HTTP(S)

  • SQL Injection
  • LDAP attributes

  • Windows
  • Power Shell
  • Unix/Linux


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

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

Can Privileged Access Manager launch an administrator login sessions to ....?

Privileged Access Manager controls access by users and programs to privileged accounts on managed endpoint systems. In most cases, this means that when a user is authorized to connect to a privileged account, the user is able to launch a login session directly to the managed account without seeing its password.

Display of current password values can be enabled through Privileged Access Manager policy configuration but is usually only recommended for users physically in the data center, who need access to a server console.

Access disclosure options include:

  1. Directly launch Terminal Services Client (RDP), SSH (PuTTY, SecureCRT, etc.), VMware vSphere, SQL Studio, web browser/form login and other connections to target systems from the Privileged Access Manager web user interface, without displaying a password value.
  2. Place a copy of a sensitive password into the Windows copy buffer. This password is automatically cleared from their copy buffer after a few seconds.
  3. Temporarily place the authorized user's Active Directory account in a local or domain security group.
  4. Temporarily append the authorized user's public SSH key into the managed account's .ssh/authorized_keys file.
  5. Where password display is required, display the password but automatically clear it from the user's browser display after a few seconds.

Policy rules determine which mechanisms are available to what users, managed systems and managed accounts.

What happens when an administrator needs to sign into the physical console of a server?

Password display is supported. Hitachi ID Systems recommends limiting the set of people who have access to this -- i.e., only data center staff should be able to display passwords and perhaps only with workflow approvals.

Which web browsers does Privileged Access Manager support?

Basic user interface

Privileged Access Manager presents an HTML5 user interface, compatible with all modern browsers, including IE8+, Firefox, Chrome, Edge, Opera, etc.

The Privileged Access Manager user interface is compatible and periodically tested with speaking web browsers (for the visually impaired).

In addition to standard HTML, Hitachi ID Password Manager can leverage IE/ActiveX components and Chrome/FF/Opera browser extensions to execute local code. Example uses of this optional capability include:

  1. To update cached passwords on corporate Windows laptops, after a successful password change.
  2. To notify full disk encryption software of a new primary Windows password, as FDE and Windows primary login passwords are normally synchronized.
  3. To notify enterprise single sign-on programs of new application passwords, so that they can update their "wallet."

In addition to standard HTML, Privileged Access Manager can leverage IE/ActiveX components or FF/Chrome/Opera browser extensions to execute local code. Example uses of this optional capability include:

  1. To launch login sessions to privileged accounts on managed systems and inject credentials into those login sessions (e.g., PuTTY, SecureCRT, RDP, SQL, vSphere, etc.).
  2. To record screen, keyboard, webcam and other data during the life of such login sessions.

ActiveX components used to launch login sessions

ActiveX components are provided with Privileged Access Manager to:

  1. Launch connections to target systems (RDP, SSH, SQL Studio, VMware vSphere, etc.) without having to disclose privileged passwords to users and without users having to type login IDs and passwords for the privileged accounts on systems they need to sign into. Any command-line client software, plus the RDP control built into Windows, can be activated in this way.
  2. Place a copy of a privileged password in a user's copy buffer and automatically remove it after a short time, without having to display it. This allows administrators to (briefly) paste a sensitive password into a login prompt without having to see it.

IE7 and later are supported as a platform to launch connections via ActiveX (IE6 also works but like all vendors, Hitachi ID Systems would prefer that IE6 disappeared as soon as possible).

Using ActiveX to launch administrator login sessions means the connection is directly from the user's PC to the managed system -- not though a proxy. This means there is no bottleneck for performance or service availability. It also means that Privileged Access Manager can launch a variety of client/server administration tools and is not limited to specific versions of specific protocols.

Starting with the 10.0 release, browser extensions for Chrome and FF are also supported, yielding the same results as above but without IE/ActiveX.

Can Privileged Access Manager you secure privileged passwords on laptops (which move around and get disconnected)?

A password management system can easily make connections to servers, which have fixed network addresses, are always on and are continuously connected to the network. It is much harder for a central password management server to connect to mobile laptops, for several reasons:

  • Laptops frequently move from site to site.
  • Even when they remain in one place, laptop IP addresses may change dynamically, due to use of DHCP.
  • Laptops are often turned off and do not respond to network inquiries when deactivated.
  • Laptops may be unplugged from the network, either to move them or for periods of disuse.
  • Laptops may be protected by a firewall that blocks network connections inbound to the PC.

In short, while it is easy for laptops to contact a central server, it is nearly impossible for the reverse to happen reliably.

To secure privileged accounts on mobile PCs (typically laptops), Privileged Access Manager includes a service, which installs on the relevant PCs and which contacts a central server to coordinate local password changes.

This architecture has several important advantages:

  • The local workstation service uses only HTTPS to communicate with the central server and works even when the PC is connected behind NAT devices, firewalls or application proxies.
  • The local workstation service does not randomize passwords unless it has established connectivity with the central privileged access management server. This avoids a situation where the central server does not know the new password value for a PC.
  • Dynamic IP addresses have no impact on this architecture.
  • Physical relocation and long periods of detached network connectivity may delay updates to local passwords, but do not introduce a failure whereby the local administrator passwords on a PC are unknown.

Privileged Access Manager supports management of passwords on laptops, which may be mobile, have dynamic IP addresses, get unplugged, etc. This is done using client software, which works by "pulling" new, passwords from the Privileged Access Manager server cluster. Client software is available for:

  1. Windows 2000, XP, Windows Vista~10, 2003, 2008/R2, 2012/R2.
  2. Unix (various vendors) and Linux (IA86).

The Windows pull-mode service includes plug-ins to notify operating system components of new service account passwords. Plug-ins are provided for the Windows Service Control Manager, Windows Scheduler and IIS.

How can we automate the setup and teardown of thousands of systems on Privileged Access Manager?

In organizations with large numbers of servers or other systems (e.g., databases, routers, etc.), clearly it is desirable to auto-discover and auto-maintain a list of systems and lists of accounts to manage on each managed system, rather than manually adding and maintaining thousands of separate target systems and accounts.

To auto-discover systems, most organizations pull data from an Active Directory or LDAP directory. The same data can be imported from multiple CSV or SQL sources -- for example, from the corporate CMDB or from Cisco ACS (for network devices). Computer objects or equivalent records discovered in the inventory system are classified based on their attributes and automatically managed (or not) and attached to appropriate managed system policies, which specify password change frequency, access control rules, access disclosure methods, etc.

A second auto-discovery process probes each managed system to find accounts that should be managed. On most systems, a list of local users and groups is generated. Specifically on Windows systems, this process also lists services, scheduled jobs, IIS objects (e.g., anonymous users, application pools, etc.) and DCOM objects and see what accounts are used to run each of them. Import rules determine which of these accounts will be managed by Privileged Access Manager (e.g., based on account attributes, group membership, security IDs, account/service relationship, etc.) and which managed system policies to assign to each managed account.

Alternatives to Active Directory- or LDAP-driven computer object lists include DNS queries or zone transfers, IP port scans of specific subnets and data imports from an inventory management system.

Privileged Access Manager also includes an automated mechanism to inform programs that store a copy of passwords of new password values. A plug-in program is provided to connect to Windows servers after each password change and automatically update Service Control Manager, Windows Scheduler, IIS or DCOM with new password values.

The Privileged Access Manager auto-discovery process is massively multi-threaded. It is able to list, classify and probe over 10,000 systems per hour. The entire process is usually scheduled to run daily.

Can Privileged Access Manager assign privileges less than full-administrator to users?

Yes. For Unix/Linux, please refer to the next question.

For Windows, see below.

Privileged Access Manager can be configured to provide privilege elevation by temporarily placing a user's (normally unprivileged) personal account into a privileged security group on the target system.

This process works as follows, using an Active Directory domain, a Windows server and an RDP connection in our example:

  1. Administrator A requests privileged access to system C.
  2. The request is approved either because A has been pre-approved for such access (typically via membership in a separate AD group) or because some other user, designated as an owner of system C, approves the request.
  3. Administrator A "checks out" access to system C.
  4. Privileged Access Manager places A's AD account into a privileged group on system C, such as (local group) "Administrators."
  5. A connects to C using RDP. This connection might be mediated by Privileged Access Manager, which can launch the RDP session directly from its web portal using an ActiveX control.
  6. Depending on how Privileged Access Manager and C are configured, A may have to type his personal AD password to establish the RDP connection to C.
  7. At some later time, A will either check-in the session or the session will time out. At this time, Privileged Access Manager will remove A's AD account from the privileged group on C.

This approach of manipulating group memberships rather than disclosing passwords has the advantage that audit logs on the target system (C in the example above) show activity by the individual administrator (A in the example above) rather than by a generic local administrator account.

The limitations of this approach are:

  1. It does not help with access to systems that are not linked to a directory (e.g., Windows in AD, Linux in LDAP, etc.) since it presupposes that the user can already sign into the system in question, but not with adequate privileges for the desired activity.
  2. It does not help with systems which are disconnected from the network.
  3. Users, once granted elevated privileges, can connect from a different client device and therefore bypass any client-based or proxy-based session monitoring infrastructure. If there is a desire to record (keylog, video capture, etc.) user activity, then this approach is not appropriate.

Can Privileged Access Manager interoperate with sudo on Unix/Linux?

Privileged Access Manager can be configured to grant privileged access to Unix and Linux computers by temporarily placing an administrative user's personal SSH public key into the trusted keys file of a functional account on the target computer.

This architecture works as follows:

  1. The Privileged Access Manager server gets its own SSH public and private keys.
  2. Every user who may require privileged access to Unix/Linux systems must have:
    1. An SSH client on his PC.
    2. A well known SSH public key.
  3. A copy of the public SSH key for every user is kept on the Privileged Access Manager server or on a Unix/Linux system which Privileged Access Manager can access.
  4. Each managed Unix/Linux computer is configured with:
    1. An SSHD listener.
    2. The SUDO package.
    3. A set of functional accounts (see below).
  5. The /etc/sudoers file on each managed Unix/Linux computer is configured to grant a set of predefined privileges to each functional account. For example:
    • The account dba might be allowed to perform DB-related tasks.
    • The account backup might be allowed to perform filesystem backups.
    • The account procmon might be allowed to perform runaway processes.
    • The account monitor might be allowed to perform stats from /proc.
  6. The .ssh/authorized_keys file of each of the functional accounts is configured to trust the public SSH key of the Privileged Access Manager server.
  7. At access checkout time, Privileged Access Manager modifies the .ssh/authorized_keys file of the functional account to which access was granted to include the public key of the user who needs access to that account.
  8. At access checkin or expiry time, Privileged Access Manager modifies the .ssh/authorized_keys file of the relevant functional account to remove the public key of the user who had access to that account.

The access disclosure process works as follows:

  1. Administrator A requests access to functional account F on computer C.
  2. The request is approved either because A has been pre-approved for such access (typically via membership in an AD group) or because some other user, with ownership rights to F@C, approves the request.
  3. Administrator A "checks out" access to F@C.
  4. Privileged Access Manager retrieves a copy of the .ssh/authorized_keys from F@C, adds A's public SSH key to the file and puts the new .ssh/authorized_keys back in F@C's home directory.
  5. A connects to F@C using SSH. This connection is authenticated using an SSH key exchange (not a password).
  6. A may have to type a password to access his own SSH private key, depending on how whether his SSH key is encrypted with his password.
  7. Eventually A will either check-in the session or the session will time out. When either event happens, Privileged Access Manager will remove A's public SSH key from F@C's .ssh/authorized_keys file.

Can Privileged Access Manager integrate with SIEM systems?

The logging service in Privileged Access Manager can be configured to forward SYSLOG messages to a network logging system, including services exposed by all popular SIEM applications.

How does Privileged Access Manager defend itself against compromise of sensitive passwords?

Encryption is used to protect stored Privileged Access Manager data as follows:

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


How do we protect Privileged Access Manager against data loss?

Once deployed, Privileged Access Manager becomes an essential part of an organization's IT infrastructure, since it alone has access to privileged passwords for thousands of networked devices. An interruption to the availability of Privileged Access Manager or its password vault would mean that administrative access to a range of devices is interrupted -- a major IT service disruption.

Since servers occasionally break down, Privileged Access Manager supports load balancing and data replication between multiple physical servers and multiple credential vaults. Any updates written to one database instance are automatically replicated, in real time, over an encrypted communication path, to all other Privileged Access Manager servers and all other credential vaults.

In short, Privileged Access Manager incorporates a highly available, replicated, multi-master architecture for both the application and the credential vault. The architecture is active-active, not active-standby as is common with other products.

To provide out-of-the-box data replication, Privileged Access Manager includes a database service that replicates updates across multiple database instances. This service uses a Microsoft SQL Server (one per app node) for physical storage. Hitachi ID Systems recommends one physical database per Privileged Access Manager server, normally on the same hardware as the Privileged Access Manager application.

The Privileged Access Manager data replication system makes it both simple and advisable for organizations to build a highly-available Privileged Access Manager server cluster, spanning multiple servers, with each server placed in a different data center. Replication traffic is encrypted, authenticated, bandwidth-efficient and tolerant of latency, making it suitable for deployment over a WAN.

This multi-site, multi-master replication is configured at no additional cost, beyond that of the hardware for additional Privileged Access Manager servers, and with minimal manual configuration.

Can Privileged Access Manager record what users do while signed into administrator accounts?

Privileged Access Manager includes a sophisticated infrastructure for monitoring, recording and playing back privileged account login sessions. This includes capturing:

  1. Successive screen shots of the interactive administrator login session (RDP, SSH, vSphere, etc.).
  2. Periodic photographs of the user (presumably) if a web-cam is present.
  3. Many types of input events, including key presses, mouse clicks, copies and pastes.
  4. Process names started and stopped.
  5. UI text elements (labels, text input fields, drop-downs, etc.) displayed on the screen.
  6. Mapping and disconnecting file shares (currently under development).
  7. Initiating file transfers, especially to removable media such as USB flash drives (currently under development).

Capture sources can be individually enabled, disabled or configured.

This data is stored in a secure database and can be accessed later:

  1. Search by user, target system, time, date or meta data.
  2. Play back movies of user interaction.
  3. Report on events during the session (copy, paste, transfer file to removable media, etc.).

This data can be extracted, for example for use in a forensic audit or as courtroom evidence.

Session capture can be initiated regardless of how a user established their login session:

  1. Direct connection to the managed endpoint, from the user's PC, where the user signed into Privileged Access Manager via IE and the session was launched via ActiveX.
  2. Direct connection to the managed endpoint, from the user's PC, where the user signed into Privileged Access Manager via another browser (Chrome, Firefox, Opera) and the session was launched via a browser extension.
  3. Proxied connection to the managed endpoint, where the user first signed into a Windows RDS proxy system and from there launched a browser to sign into the managed endpoint, after which an admin tool (e.g., SSH client, SQL client, etc.) was also launched on the Windows RDS server.
  4. HTML5 proxied connection to the managed endpoint, where the RDP or SSH session was established from a Linux/Tomcat proxy server to the managed endpoint, and its display is rendered into an HTML5 canvas in a second tab in the user's web browser.

Recorded sessions are stored in a combination of the Privileged Access Manager database (session meta data, keyboard input and other text events, etc.) and on server or network filesystems (video captures, web-cam snapshots, etc.).

Playback data is packaged as a ZIP file with XML files representing textual data, standard MP4 video files representing screen movies and JPEG files representing web-cam images. These ZIP files are intended to be suitable as forensic evidence in the context of investigation of improper employee or contractor behavior.

How does Privileged Access Manager control access to recorded login sessions (privacy protection)?

Session monitoring can have serious implications on user privacy and so should be implemented with great care. The session monitoring infrastructure is subject to strict access control rules and workflow infrastructure. For example, an auditor must first request the right to perform a given search through session data. If approved, he can execute the search and may find sessions of interest. The auditor must then request the right to playback selected sessions. Only if this second request is approved can the auditor retrieve session data. Of course, all such requests and searches this is indelibly logged.

Another measure used to protect user privacy in Privileged Access Manager is a pattern-matching censorship process. Hitachi ID Systems customers are encouraged to define regular expression patterns, matching passwords, social security numbers, credit card numbers, bank account numbers, etc. A process on the Privileged Access Manager server post-processes keystroke and keyword data captured by the session monitor, searching for matches for these patterns. Matches are deleted from the keystroke and keyword database.

page top page top