Users gain access to Hitachi ID Privileged Access Manager itself -- for example, to make configuration changes and run reports -- and to managed systems and accounts through user classes.

User classes are expressions in terms of identity attributes and group memberships on integrated systems. For example, a user may be considered a member of a user class called "Windows Server Administrators NYC" if he satisfies the conditions:

  1. Member of "Windows server administrators" group on the Active Directory domain ADCORP; and
  2. The user's location code in HR is "NYC."

Members of the user class "Windows Server Administrators NYC" can then be granted access rights within Privileged Access Manager, such as:

  1. Can sign into the Privileged Access Manager web portal.
  2. Can run reports.
  3. Can request access to privileged accounts.
  4. Can checkout access to privileged accounts attached to the managed system policy "NYC Windows Servers" without additional approvals.

Most Privileged Access Manager deployments leverage AD or LDAP groups in the user classes that control user rights. This means that trustworthy management of who is attached to key AD and LDAP groups underpins the security of Privileged Access Manager and by extension the security of access to privileged accounts across the enterprise.

Privileged Access Manager includes workflows, policy enforcement and reports to help organizations effectively manage these sensitive groups. This includes:

  1. Workflow screens where users can request group membership. Requests are subjected to policy review (including SoD -- see below) and approval by other business users (e.g., managers, group owners, etc.).
  2. Periodic certification (review and cleanup) of the membership of sensitive groups.
  3. Enforcement of segregation of duties policies, to prevent users from acquiring toxic combinations of rights via the Privileged Access Manager request/approval workflow.
  4. Detection of existing segregation of duties policies, to identify users who either already had toxic combinations of rights before an SoD policy was defined or who acquired such combinations using tools other than Privileged Access Manager.

SoD rules in Privileged Access Manager are formulated as:

  1. No user may have more than N of the following entitlements.
  2. Entitlements may be group memberships (e.g., on AD domains or LDAP directories).
  3. Entitlements may also be role memberships (e.g., sets of groups).
  4. Entitlements may span target systems (e.g., one on AD, two on LDAP).
  5. Attribute X taking on value Y on system Z can be treated as a synthetic group membership.

Using this infrastructure, SoD rules such as the following can be defined, enforced and monitored:

  1. Windows administrators can only manage systems in a single data center.
  2. No user may be both a Windows and Linux administrator.
  3. Users who can request playback of a recorded administrator login session cannot also authorize such playback.