Secure Management of Access to Privileged Accounts

Secure Management
of Access to
Privileged Accounts
using Hitachi ID Privileged Access Manager
© 2014 Hitachi ID Systems, Inc. All rights reserved.

Every IT asset has at least one local, privileged login account. This includes workstations, servers, net-
work devices, databases, applications and more. Some assets also have privileged accounts used to run
services or authenticate one application to another.
Passwords for privileged accounts are used to install software, manage the device and perform technical
support functions. They are often “all powerful,” having unlimited access to system functions and data.
Consequently, compromise of privileged passwords is effectively compromise of the device.
Secure management of access to privileged accounts is essential to IT security. This document identiﬁes
technical challenges and offers solutions for effectively managing large numbers of sensitive passwords.
Contents
1 Overview: The Business Problem 1
2 A Simple Solution: Randomize Passwords 2
3 Technical Challenges / Solution Requirements 3
3.1 Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Workstations: Location and Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3 Scalability to Millions of Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.4 Reliable Operation and Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.5 Fault Tolerance: Hardware, Network and Facility Problems . . . . . . . . . . . . . . . . . . . 4
3.6 Encryption in Transit and Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.7 Connectivity and Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.8 Services and Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.9 Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.10 Audit Trails and Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Architectural Elements 7
4.2 Workstations: Location and Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Scalability to Millions of Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Auto-discovery and Auto-conﬁguration of Managed Systems and Accounts . . . . . . . . . . 7
4.5 Reliable Operation and Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6 Fault Tolerance: Hardware, Network and Data Center Problems . . . . . . . . . . . . . . . . 8
4.7 Encryption in Transit and Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.8 Connectivity and Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
i

Secure Management of Access to Privileged Accounts
4.9 Services and Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.9.1 Managing Passwords for Service Accounts . . . . . . . . . . . . . . . . . . . . . . 9
4.9.2 Managing Application Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.10 Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.11 Audit Trails and Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5 Hitachi ID Privileged Access Manager 11
5.1 Servers and Workstations: Push and Pull Modes . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1 Push Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.2 Pull Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2 High Availability and Data Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4 Auto-discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5 Hitachi ID Privileged Access Manager Network Architecture . . . . . . . . . . . . . . . . . . 14
5.7 Proxies to Cross Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.8 Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.9 Application Programming Interface (API) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.10 Reliable Password Changes and History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.11 Cryptographic Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.12 Logging and Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.13 Learn More . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
© 2014 Hitachi ID Systems, Inc. All rights reserved.

1 Overview: The Business Problem
In a typical enterprise-scale organization there are thousands of servers, workstations and network devices.
Normally, there is a single, shared administrator password for every type of device. For example, one
password may be used for each workstation of a given type or for every server with a given conﬁguration.
This is convenient for data center and desktop support staff: if they need to perform maintenance or an
upgrade on a workstation or server, they know how to log in.
Such static and well-known privileged passwords create both operational challenges and security problems:
• When administrator login IDs are shared by multiple IT users, there is no audit log mapping adminis-
trative changes to individual IT staff. If an administrator makes a change to a system that causes a
malfunction, it can be difﬁcult to determine who caused the problem.
• When the same privileged account and password exists on many systems, it is hard to coordinate
password changes. As a result, privileged passwords are rarely changed and are often known to
ex-employees.
These problems create security vulnerabilities. For example, if administrator passwords don’t change, then
former IT workers retain them beyond their term of employment. This clearly violates internal controls:
former employees should not have administrative access to corporate systems.
In most organizations, strong internal controls are mandatory. Privacy protection legislation such as HIPAA
and GLB, as well as legislation regarding corporate governance such as SOX, requires that systems con-
taining sensitive data be secured against unauthorized access. Effective management of access to privi-
leged accounts is therefore not an option, but a requirement.
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 1

2 A Simple Solution: Randomize Passwords
The obvious way to eliminate static and shared privileged passwords is to change them regularly. If every
sensitive password were randomized daily, control problems would be alleviated.
Since IT users often need to sign into privileged accounts, randomizing passwords is only half of the solu-
tion. Additional functions are required to control access by IT users to these accounts:
1. Authentication of IT users who wish to gain privileged access to a system.
2. Access control over which accounts IT users may access and when.
3. Audit logs recording such access, to create accountability.
The combined solution, capable of both randomizing large numbers of passwords and controlling access to
password values or to the underlying accounts, can be complex. The following section describes some of
the technical challenges that must be overcome in order to successfully deploy such a solution.

3 Technical Challenges / Solution Requirements
Describing a basic process for periodically randomizing and archiving administrator credentials is easy,
while implementing such a process in a manner that scales well to thousands of devices, that is secure and
fail-safe can be challenging.
The following sections describe some of the technical challenges such a system must address.
3.1 Platform Support
Every type of IT asset has a local administrator password. This is true even if network credentials are used
in the normal course of business to manage the device, since a local administrator password must be used
to attach each device to the network in the first place.
To be effective, a system for managing administrator passwords should support a broad array of platforms.
This includes workstations, Windows servers, Unix servers, network routers, database servers, ERP appli-
cations, midrange servers (iSeries, VMS, etc.), mainframe computers, directories and more. In short, every
device that contains sensitive data or whose operation is critical to the business should be supported.
3.2 Workstations: Location and Connectivity
A password management system can easily make connections to servers, which have fixed network ad-
dresses, 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 reliably secure local administrator passwords on workstations, a password management system should
include technology to overcome location, connectivity, address and firewall challenges.
3.3 Scalability to Millions of Credentials
A large organization may have thousands of workstations, servers and applications. If each of these IT
assets gets a new administrator password daily, the total number of passwords that must be securely

managed, including historical data, quickly grows into the millions of passwords.
Note that historical passwords need to be stored along with current ones, since in the event that a managed
device crashes and is restored from backup media, its old password will be needed.
A scalable solution for managing administrator passwords must be able to randomize tens of thousands of
passwords daily and to keep permanent records of millions of historical passwords.
3.4 Reliable Operation and Race Conditions
A robust system for managing administrator passwords must ensure that the password kept in its database
for a given administrator account always matches the password on the system in question. This should be
true even if an attempt to change passwords failed in the middle of an update.
For instance, if a password management system sets a new password on an IT asset and experiences a
connection failure, it is not clear whether the new or old password is actually in effect – should the value
stored in the database be updated?
A robust system for managing administrator passwords must ensure that the password it stores in its
database is always the right one – even if a fault occurred in the middle of a password update.
3.5 Fault Tolerance: Hardware, Network and Facility Problems
A password management system must be fault tolerant. If it becomes unavailable, IT workers would not be
able to do their jobs – making failure of the system catastrophic.
Hardware servers, including “appliances”1
sometimes fail, due to disk crashes, power supplies burning up,
etc. Network connections, especially over wide area links, also sometimes fail. Whole data centers can fail
as well, due to power outages, earthquakes, hurricanes, tornados, fires or floods.
If one component of a privileged access management system fails, the accounts it secures must still be
available. This is typically accomplished by running at least two servers, ideally at different sites. This
means that if one server or one data center goes offline, IT staff elsewhere will be able to keep retrieving
passwords and doing their jobs.
Fault tolerance between servers and sites requires data replication between servers. Such data replication
must take place in real-time. The alternative – scheduled, batch replication – is inadequate. Consider, for
example, a backup system that runs nightly. If a password management server were to fail just before a
backup cycle begins, then the day’s new passwords would be lost. If passwords are changed daily, the
current administrator password for almost every system would be lost: a catastrophic event.
3.6 Encryption in Transit and Storage
Compromise of even a single privileged password represents business risk. Compromise of many privi-
leged passwords may represent catastrophic business risk. Consequently, a system for securing access to
1Appliances are generally just branded x86 servers.

privileged accounts must protect these passwords cryptographically. It should protect passwords both when
they are stored (at rest) and in transit: between users and itself, between replicated servers and between
itself and target devices.
3.7 Connectivity and Firewalls
Networks are increasingly being segmented, to create a layered defense against intruders. This creates
situations where the privileged access management system is attached to one network segment while an
IT asset to which it controls access is attached to another segment.
To manage passwords on a system on the far side of a firewall, a password management system must
be able to send password updates over the firewall. This may not be simple: many network protocols are
insecure by design (e.g., SMB for Windows, SQL*Net for Oracle, plaintext LDAP, plaintext HTTP, etc.) and
are blocked by firewall administrators for good reason.
To overcome this problem, an effective password management system must be able to replace network
protocols that are native to a given target system with its own protocol. The password management system’s
network protocol must be appropriate to pass over a firewall.
3.8 Services and Applications
Sensitive passwords are not limited to those used by human IT workers. There are also service accounts,
used to run attended software such as web servers and application passwords. There are also application
passwords, used by one service on one computer to authenticate itself to another service, possibly on
another computer.
On many systems, service passwords are static and application passwords are embedded in scripts, pro-
grams or text files. These passwords unlock login IDs that are often just as powerful as administrator
accounts.
An effective solution for managing sensitive passwords should include mechanisms for managing service
and application passwords, in addition to managing the administrator passwords used by IT workers. This
calls for two specific capabilities:
1. The ability to automatically notify one program of the new password it should use to run a second
program, after the password on the account used to run the second program has been randomized.
2. An API that allows one application to securely fetch a password that it can subsequently use to au-
thenticate itself to another application.
3.9 Access Controls
Not every IT worker should be able to access every privileged account. Likewise, applications invoking an
API to retrieve a password should only be able to get passwords for services to which they legitimately need
to be able to connect.

To enforce such security policies, a password management system must include a ﬂexible access control
infrastructure, capable of determining whether a given user of the system – human or software agent –
should be granted access to a given privileged account.
3.10 Audit Trails and Alerts
Every action in the password management system, including looking up assets and their passwords and
changing access control policies should be auditable. This creates a chain of accountability between users
and their actions.
It also makes sense to link auditable events to alerts. For example, if a legitimate user retrieves a given
server’s administrator password, the owner of that server might wish to receive an e-mail about the event.
To create accountability, to meet audit requirements and to enable system owners to promptly respond to
anomalous administrator activity, a privileged access management system must include detailed logs of
user sessions, must retain its audit data indeﬁnitely and must be able to act on, rather than just record,
security events.

4 Architectural Elements
Each of the requirements set forth in the previous section can be addressed with a suitable architectural ele-
ment in the password management solution. These architectural components are described in the following
sections:
A rich set of connectors should be provided, to integrate with a broad range of target system types.
4.2 Workstations: Location and Connectivity
Client software should be available, to be installed on user workstations, which periodically contacts a cen-
tral cluster of password management servers and requests new passwords for locally managed accounts.
This “pull mode” approach eliminates the problems with a central server “pushing” out passwords to devices
with intermittent connectivity and dynamic IP addresses.
4.3 Scalability to Millions of Credentials
Multiple, concurrently-active password management servers should be supported, each of which can push
new passwords to servers and each of which can provide new passwords to workstations on demand.
As the need for scalability grows, the number of servers can be increased. Servers should be placed behind
a load balancer to hide this complexity from users and workstations.
4.4 Auto-discovery and Auto-configuration of Managed Systems and Accounts
It is not feasible to manually configure thousands of devices for periodic password changes. Instead, a
privileged access management system requires an auto-discovery infrastructure to:
1. Automatically find servers and workstations.
2. Automatically find administrator and service accounts.
3. Configure systems and accounts for periodic password updates.
4. Notify software components of new service account passwords.
4.5 Reliable Operation and Race Conditions
A reliable protocol is required, especially for workstations, to confirm password updates before updating
stored passwords.

Historical passwords should be retained indefinitely. In the event that an IT asset was damaged and had to
be recovered from backup media, passwords from the date the backup was made will be available.
4.6 Fault Tolerance: Hardware, Network and Data Center Problems
As mentioned in Subsection 4.3 on Page 7, multiple servers are required. Not only should the servers each
be able to randomize passwords in a multi-master configuration, but each server should house a complete
data set and should replicate all local updates to that data to every other server.
Multiple servers should be installed in different data centers. This provides the opportunity for performance
tuning, by having a local server manage passwords on local assets. It also provides for fault tolerance in the
event of a disaster at one data center. If one data center goes offline, the password management servers
at other data centers can keep working and will contain a full data set.
4.7 Encryption in Transit and Storage
Design of an encryption system for a password management system revolves around key management:
How are keys generated? How are keys associated with data, with servers, with end users and with
managed devices? Key management is an advanced topic and deserves separate treatment, beyond what
this white paper can cover. That said, some basic observations can be made:
1. Users can sign into the system with a user interface carried over HTTPS – i.e., HTTP over SSL.
2. Connections between the password management system and target servers will generally use their
native protocols, whose security will range from strong (e.g., HTTPS, SSH or LDAPS) to weak (e.g.,
SQL*Net, LDAP). External measures, such as IPSec, may be appropriate to protect communication
with some targets.
3. Connections between workstations and the password management system may be encrypted using
HTTPS or using another key handshake protocol.
4. Connections between multiple password management servers may be encrypted using either SSL –
which requires one cryptographic certificate to be purchased per server – or using symmetric server
keys generated for each server.
4.8 Connectivity and Firewalls
In order to cross firewalls without exposing insecure protocols, the password management system must
have components on both sides of the firewall. To avoid the need to fragment password storage into one
database per network segment, it makes sense to provide a proxy server – i.e., a server installed on one
network segment whose purpose is to run connectors and update passwords on another network segment.
The communication between a primary password management server and a password management proxy
server can be a simple, encrypted protocol over an arbitrarily numbered TCP port. This is robust, secure,
bandwidth efficient and easy for firewall administrators to understand and forward.

4.9 Services and Applications
4.9.1 Managing Passwords for Service Accounts
In order to manage passwords used to start services, the password management system must be able to
execute plug-in code, after successfully randomizing a password. The function of this installation-speciﬁc
code is to notify network components of the new password value.
Some plug-ins are common. For example, the Windows Service Control Manager, Scheduler and IIS web
server all store passwords in secondary storage (outside of the security database) in order to execute
processes as named users. Since other programs may have the same requirement, the infrastructure for
notifying programs of new passwords must be extensible (hence plug-ins).
4.9.2 Managing Application Passwords
In order to manage passwords used by one application to authenticate to another, an API must be exposed,
to enable applications to acquire current credentials. For example, a web application might use the API
to get a database password and use that password to connect to a database and read data which is then
displayed in a web page.
This type of API creates a circular problem: how does an application which needs a password authenti-
cate itself to the password management system? The obvious answer is that it must have its own (static)
password, but this approach is clearly undesirable, as it reduces security of the application password (now
randomized) back to a static password – but the point of a privileged access management system is pre-
cisely eliminate static password.
Some options for authenticating applications to the API include:
1. Using one-time passwords. The API can return not only the desired password, but also a new pass-
word which the calling application must use on for its next authentication.
2. Using environmental characteristics of the calling application. For example, a given application may
only be allowed to sign into the API if it connects from a given IP address, or from a device running a
particular operating system version, or even from an executable with a speciﬁc checksum.
4.10 Access Controls
A simple access control model maps privileges between individual passwords and individual users. For
example, user X is allowed to retrieve the current password for login ID Y on system Z.
As the number of systems, managed user accounts and IT users grows, this model breaks down – there
are simply too many relationships.
A more powerful model is to insert security groups between users and managed systems. Essentially users
are collected into groups (each user can belong to multiple groups) and groups are assigned privileges to
groups. For example, users A, B and C belong to group G. Members of group G are allowed to retrieve the
current password for login ID X on system Y and login ID Z on system W.

This model may also be difficult to manage in large environments – users must be explicitly attached to
groups (an administrative burden where there are many users and their responsibilities change often) and
large numbers of managed systems must be manually attached to multiple groups.
The best model is to define both user groups and managed system policies and to define access controls
(privileges) between the two. For example, users A, B and C belong to user group UG1. Managed systems
R, S and T belong to policy P1. Members of user group UG1 are allowed to connect to privileged accounts
on systems in policy P1.
This model provides for maximum flexibility and minimum administrative burden. It can be optimized further
by automating association of users with user groups and managed systems with policies.
1. User membership in groups can be determined based on their identity attributes or group member-
ships in a corporate directory (LDAP or Active Directory).
2. Managed system association with policies can be determined based on characteristics of the system
– for example based on DNS name, IP address, hardware class, operating system, MAC address,
directory OU of the system’s representative computer object, etc.
4.11 Audit Trails and Alerts
Logging is straightforward – record every event as it takes place and provide reports that are either user-
centric or system-centric to show event history.

5 Hitachi ID Privileged Access Manager
Hitachi ID Privileged Access Manager is a system for securing access to privileged accounts. It works by
regularly randomizing privileged passwords on workstations, servers, network devices and applications.
Random passwords are encrypted and stored on at least two replicated credential vaults. Access to privi-
leged accounts may be disclosed:
• To IT staff, after they have authenticated and their requests have been authorized.
• To applications, replacing embedded passwords.
• To Windows workstations and servers, which need them to start services.
Password changes and access disclosure are closely controlled and audited, to satisfy policy and regulatory
requirements.
Privileged Access Manager was designed to meet the design criteria laid out in this document. It is scalable,
reliable and secure.
5.1 Servers and Workstations: Push and Pull Modes
Hitachi ID Privileged Access Manager supports both server passwords, in “push mode,” and workstation
passwords, in “pull mode:”
5.1.1 Push Mode
When managing passwords on servers, Hitachi ID Privileged Access Manager normally operates in “push
mode.” This means that periodically the Privileged Access Manager server will initiate communication with
each target system, using connectors installed on the Privileged Access Manager server and randomize
privileged passwords on that target system.
The new password(s) will be encrypted and archived in the Privileged Access Manager server’s replicated
storage, where IT staff may retrieve them.
5.1.2 Pull Mode
When managing passwords on laptops, Hitachi ID Privileged Access Manager may be conﬁgured to oper-
ate in “pull mode.” This means that a local agent is installed on each mobile PC and this agent periodically
contacts the central Privileged Access Manager server, over HTTPS, to request new administrator pass-
words.
Once the local password has been set, a conﬁrmation is sent to the Privileged Access Manager server,
which stores the new value. The new password(s) are encrypted and archived in the Privileged Access
Manager server’s replicated storage, where IT staff may retrieve them.
Pull mode is often preferable for mobile devices because a server (i.e., Privileged Access Manager) has no

way of knowing where or when they will next be attached to the network and may be unable to initiate a
connection to the mobile device, due to firewalls, NAT, closed ports or other security measures.
Note: This feature meets the requirement described in Subsection 4.2 on Page 7.
5.2 High Availability and Data Replication
Once deployed, Hitachi ID 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 adminis-
trative 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.
To provide out-of-the-box data replication, Privileged Access Manager includes a database service that
replicates updates across multiple database instances. This service can be configured use either Oracle
or Microsoft SQL Server databases 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 organiza-
tions 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.
5.3 Scalability
Hitachi ID Privileged Access Manager is designed to scale to support over 1,000,000 password changes
per 24 hour period, in a physically and geographically replicated (i.e., high availability / disaster-proof)
configuration.
This is accomplished using a number of technologies:
1. Concurrent operation by multiple Privileged Access Manager servers – i.e., a multi-master replication
model.

2. A multi-threaded “push-mode” service that can push out tens of thousands of new passwords to
servers, routers and applications every hour.
3. A workstation service that can “pull” new passwords onto devices such as laptops at random intervals,
in order to support devices unreachable from a central server while distributing server workload over
the hours of the day.
4. A data replication protocol that is tolerant of both low-bandwidth and high-latency.
5.4 Auto-discovery
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. Com-
puter objects discovered in the directory 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 Hitachi ID 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 able to list, classify and probe over 10,000 sys-
tems per hour. It is normally scheduled to run daily.
In organizations that deploy the Privileged Access Manager workstation service, there is no need to man-
ually configure client devices in the Privileged Access Manager database. Instead, the workstation service
is installed on devices through one of several means:
1. By being made a part of the standard workstation software image.
2. By being distributed through a system such as SMS.

3. By being distributed using an Active Directory Group Policy Object (AD GPO).
Once installed, the Privileged Access Manager workstation service automatically starts and registers itself,
along with all local user accounts with the central Privileged Access Manager server cluster.
The software installation MSI package is constructed on the Privileged Access Manager server and includes
information about the Privileged Access Manager server URL, what managed system policies workstations
should be attached to, etc. This means that software installation can be fully automated and does not
present a user interface.
A similar approach is used to deliver .tar format installation packages to Unix and Linux workstations.
5.5 Privileged Access Manager Network Architecture
The Hitachi ID Privileged Access Manager network architecture is illustrated in Figure 1.
Load
Balancer
Request
new PWs,
GRP changes
Request
Disclosure
TCP/IP + AES
HTTPS
IT User
PCs
Managed
Laptops
(mobile)
HiPAM proxy
D.C. 3
Target
Systems
D.C. 2
Replicated Updates
Probe systems,
Randomize PWs
Assign GRPs
Single sign-on:
RDP, SSH, SQL, etc.
Target
Systems
Data Center 1
Target
Systems
Various Protocols
Workstation Service
Replicated, distributed
Hitachi ID Privileged Access Manager
ServersProbe systems,
Randomize PWs
Assign GRPs
Run connectors
locally
Corporate WAN Firewall
Download app-launch ActiveX.
Upload session capture
Figure 1: Privileged Access Manager Network Architecture Diagram
Pull mode agents, installed locally on devices and scalable to thousands of devices, are provided for:

1. Windows 2000 and XP workstations.
2. Windows Vista and Windows 7 workstations.
3. Windows 2000, Windows 2003 and Windows 2008 servers.
4. Unix and Linux servers and workstations.
Plugins are currently provided to update passwords, after randomization, in:
• The Windows Service Control Manager.
• The Windows Scheduler.
• The IIS Web Server.
Note: This feature meets the requirement described in Subsubsection 4.9.1 on Page 9.
Push mode agents, installed on the Hitachi ID Privileged Access Manager server itself and scalable to
thousands of devices, are provided for:
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 Ofﬁce
365, SOAP (generic).
OLAP, Hyperion, iLearn,
Caché, Success Factors,
VMWare vSphere.
SSH, Telnet, TN3270,
HTTP(S), SQL, LDAP,
command-line.

5.7 Proxies to Cross Firewalls
In some cases, the connection to a target system may be slow, insecure or simply blocked by a firewall.
This is often true when the connection is made over a wide area network or requires the use of an insecure
protocol but must cross an untrusted network segment.
To address such connectivity problems, Hitachi ID Privileged Access Manager includes an application proxy
server. When a proxy server is deployed, the main Privileged Access Manager server ceases to commu-
nicate with one or more (usually distant) target systems directly and instead forwards all communication to
those systems through one or more proxy servers, which are co-located with the target systems in question.
Communication from the main Privileged Access Manager server to the proxy server(s) is encrypted, effi-
cient and tolerant of high latency. It uses a single, arbitrarily-numbered TCP port number. Connections are
strictly from the main Privileged Access Manager server to the proxy server (never back). A single TCP port
supports an arbitrarily large number of target systems at the proxy server’s location.
These characteristics of the communication between a Privileged Access Manager main server and a proxy
server mean that firewall administrators will normally be willing and will always be technically able to route
or forward a TCP port from the main server IP address to the proxy server IP address.
Communication between the proxy server and target systems continues to use native protocols. It is nor-
mally physically secured, in a high-bandwidth, low-latency, high-security data center network.
Deployment of the secure Privileged Access Manager proxy server is illustrated in Figure 2.
Firewall
Remote Network
Firewall
Local Network
Target Systems
Possible
Intruder
Native protocol:
Slow?
Plaintext?
Blocked by firewall?
Fast, secure
protocol
TCP/IP + 128-bit Crypto
Various Protocols
Hitachi ID
Management Suite
Hitachi ID
Proxy Server
Figure 2: Target systems connected through a proxy server

5.8 Access Controls
The most common form of access control in the Hitachi ID 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 workstation WKSTN01234 to
policy RGWKSTNS”) or implicitly, using an expression. Expressions may be based on the operating system
type, IP address, MAC address or workstation name (e.g., “attach every workstation running Windows XP
in subnet 10.1.2.3/24 to policy X”)
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 a password.
5. What access disclosure methods to offer users who wish to sign into privileged accounts on attached
systems (e.g., launch remote desktop, launch SSH, temporarily place user in security groups, display
current password to user, etc.).
Privileged Access Manager users are organized into user groups, either explicitly or implicitly. In a typical
deployment, 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, that can be simultaneously assigned to the same user.
5.9 Application Programming Interface (API)
Hitachi ID Privileged Access Manager includes an API that enables applications to disclose passwords and
eliminates the storage of static, plaintext passwords. Privileged Access Manager periodically randomizes
service passwords, while applications use the API to retrieve passwords as/when required.
The Privileged Access Manager API is accessed using SOAP over HTTPS.
For example, Privileged Access Manager may randomize an Oracle DBMS login password every 24 hours.
Web applications which use the password to establish database connections can periodically sign into
Privileged Access Manager with their own credentials (see below) and retrieve the current Oracle login
password.

An important design consideration when implementing a privileged password retrieval API is how the client
which requests password disclosure (the web application in the above example) authenticates itself to
the API service. Privileged Access Manager secures this process with a combination of ACLs, one-time
passwords and IP subnets:
1. API clients have their own IDs, used to sign into Privileged Access Manager.
2. These IDs are attached to console user groups and assigned ACLs, allowing them to disclose some
passwords but not others.
3. API client login IDs are assigned one-time passwords (OTPs). In effect, the password used by the
client software to sign into the Privileged Access Manager API changes to a new, random string on
each API connection.
4. API client login IDs are bound to IP subnets. An API client can only sign into the API service from a
given IP range.
Wrapper code is provided for the SOAP API for a variety of platforms / programming languages, such as
.NET, Java, Linux/C, etc. This wrapper code manages several functions:
1. Storing the one time password (OTP) used to authenticate to the API.
2. Serializing access to the API, to support use of the OTP.
3. Keeping cached copies of passwords previously retrieved from the API, along with data about how
long to retain those copies and how long they should be assumed to be valid. This makes the system
more performant (due to less frequent API calls) and more reliable (continued operation even if the
API is temporarily unavailable).
4. Encrypting the above, sensitive data so that it’s not visible – even to locally privileged users.
Encryption of the OTP and of cached passwords implies an encryption key. The API wrappers support a
variety of methods to produce this key, including:
1. A static key (e.g., embedded into the application or configuration file) – useful during development or
debugging.
2. A key generated from characteristics of the machine on which the application runs, such as its MAC
addresses, IP addresses, hostname, etc.
3. A key generated from characteristics of the program which is calling the API (i.e., a cryptographic
hash of the program itself).
Hitachi ID Systems is happy to add platform bindings for this wrapper code based on customer demand
(i.e., we add support for the programming language and runtime that customers need as required, and
usually at no additional cost).
This wrapper is also provided in command-line form, suitable for retrieving passwords efficiently and se-
curely from Privileged Access Manager (with local, encrypted caching) and injecting those passwords on
the command-line, into configuration files or into the input of scripts.

Note: This feature meets the requirement described in Subsubsection 4.9.2 on Page 9.
5.10 Reliable Password Changes and History
Error checking is implemented to guard against a password being set before the Hitachi ID Privileged
Access Manager server is able to store the password value – i.e., a workstation or server can never get a
new password for a privileged account while Privileged Access Manager is unable to store the password.
Consider a laptop on which the local Privileged Access Manager service determines that the time has come
to change passwords:
If it simply changes passwords and then attempts to contact a central server to upload the new value, it may
not manage to connect to Privileged Access Manager and consequently must either undo the password
change or store the new password and periodically test for connectivity, in the hopes that the new password
can be uploaded before anyone needs to use it.
To avoid this problem, Privileged Access Manager’s “pull mode” mode of operation (used on laptops) works
as follows:
1. First, the laptop service connects to Privileged Access Manager and asks it to generate a new, random
password for a privileged account.
2. The laptop service then changes the password in the local security database and sends a conﬁrmation
message to Privileged Access Manager.
3. Privileged Access Manager updates the password in its vault and replicates the update to all other
Privileged Access Manager servers.
In the event that the Privileged Access Manager server did not receive a conﬁrmation message – for exam-
ple in the event that the workstation was suddenly turned off or disconnected – it will retain both the old and
new passwords. The new password is assumed to be current and the old password is archived.
In practice, as a fail-safe, all old passwords are retained in the vault. This is not only to support a fail-safe
password change process, but also to be able to retrieve old password values in the event that a managed
system is restored from archive media in the future.
5.11 Cryptographic Protection
Hitachi ID Privileged Access Manager makes extensive use of cryptography:
1. A built-in key is used to encrypt a master key, which is stored in the registry of each Privileged Access
Manager server.
2. Each site has a unique master key, used to encrypt local data.

3. Each “pull-mode” device has its own key, acquired at installation time and used to authenticate and
protect communication between that device and Privileged Access Manager servers.
4. Privileged Access Manager servers use an encrypted TCP/IP based protocol to protect data replica-
tion traffic amongst themselves.
5. User access to Privileged Access Manager is via HTTPS, which uses SSL encryption.
6. Communication between the workstation service, used to implement pull mode and Privileged Access
Manager servers is likewise via HTTPS.
All symmetric encryption uses 128-bit AES.
5.12 Logging and Reports
Hitachi ID Privileged Access Manager logs and can report on every disclosure of access to every privileged
account. This means that the time interval during which a user was connected to a privileged account or
during which a password was disclosed to a program or person is always recorded, is retained definitely
and is visible in reports.
Privileged Access Manager also logs all attempts by users to search for managed systems and to connect
to privileged accounts, even if login attempts were denied. This means that even rejected attempts and
requests to access privileged accounts are visible in reports.
Privileged Access Manager also logs auto-discovery and auto-configuration process status as well as man-
ual changes to its own configuration. This means that the health of systems on the network can be inferred
from Privileged Access Manager reports.
Exit traps can be used to forward copies of Privileged Access Manager log entries to another system (e.g.,
an SIEM, typically via SYSLOG) for analytics and tamper-proof archive.
In addition to logging user access to sensitive passwords, Privileged Access Manager can produce reports,
in HTML or CSV format, directly on the web user interface or delivered via e-mail, enumerating such access
by user or by managed system.
Privileged Access Manager includes over 189 exit points.
Exit points may be triggered by many events, including:
• Attempts to sign into Privileged Access 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 member-
ships for an existing account.
• Assigning a role to a user or removing a user from a role; changing Privileged Access 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 Privileged Access
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 Privileged Access Manager are
distinct components that serve different functions. Whereas plug-in programs are bidirectional – Privileged
Access Manager sends data to the plug-in, the plug-in responds with data that alters Privileged Access
Manager’s behavior – exit programs are uni-directional and are used strictly to pass information outbound
from Privileged Access Manager to other applications. .
5.13 Learn More
Learn more about Hitachi ID Privileged Access Manager at http://Hitachi-ID.com/Privileged-Access-Manager/.
Learn more about Hitachi ID Systems at http://Hitachi-ID.com/.
www.Hitachi-ID.com
500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: sales@Hitachi-ID.com
File: /pub/wp/documents/privileged-password-management/privileged-access-mana
Date: 2011-03-02

Secure Management of Access to Privileged Accounts

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (13)

Similaire à Secure Management of Access to Privileged Accounts

Similaire à Secure Management of Access to Privileged Accounts (20)

Plus de Hitachi ID Systems, Inc.

Plus de Hitachi ID Systems, Inc. (20)

Dernier

Dernier (20)

Secure Management of Access to Privileged Accounts