Strategies for successfully

managing privileged
accounts
Securing, managing and governing superusers

By Todd Peterson, IAM evangelist, One Identity

Introduction
One of the most important aspects of an identity and
access management (IAM) program is the securing,
management and governance of the accounts belonging to
superusers privileged accounts.

Like the accounts used by regular users, these superuser

accounts require access management ensuring that
admins have the access they need to do their job and
governance ensuring that there is oversight and control
over that access, often for the purpose of compliance.
Unfortunately, privileged accounts have some unique
idiosyncrasies that make both access management
and governance difficult or impossible with traditional
PAMmethods.

To learn how to deal with those unique characteristics and

manage your privileged accounts successfully, assume
that the ideal PAM program addresses the broadest range
of privileged accounts and elevated-access users. Thats
where the problems start for most organizations.

1
For a deeper discussion of privileged account management, read the
e-book Identity and Access Management for the Real World: Privileged
AccountManagement.

2
What goes into PAM?
PAM goes by a variety of names, including privileged
identity management (PIM) and privileged identity and
access management (PIAM). By whichever name, here
are several of the most common ways of managing
privileged accounts:
Unix root delegation This widely used approach
overcomes the all-ornothing nature of the Unix/Linux
root account by allowing an administrator to delegate
to certain users the right to run certain commands.
Credential vault or safe This newer approach
eliminates the sharing of privileged passwords
by storing them in a virtual vault, complete with
workflows and automation, to control their issuance,
return and modification.
Windows delegation This approach temporarily
elevates a regular users permissions to those of a
Windows administrator on their workstation. While that
The problem is that many PAM programs address only one or two of the underlying issues
3
elevated access is technically a PAM issue, the risk
of regular users exploiting the temporarily elevated
status to cause a breach is low compared to that of
granting them widespread network and system access.
Active Directory Administrator delegation Similar
to delegating the Unix/Linux root account, this
approach delegates the AD Administrator account on
WindowsServer.
Session monitoring In this approach, the business
is able to monitor activities performed by users while
they have elevated access.
PAM covers all of those approaches, but the problem is
that many PAM programs address only one or two of the
underlying issues, which is why many of them under-
deliver, fail to achieve desired objectives or fail outright.
As in other areas of IAM, addressing PAM in silos and
without a comprehensive view is bound to disappoint.
Is your PAM program on the right path?
Based on our experience with hundreds of
customers over many years, if people in your
organization are saying (or thinking) any of a few,
choice sentences, then chances are your PAM
program is in trouble:
1. Sudo is good enough.
Sudo (superuser do) is a free, open source tool
for Unix/Linux root delegation. Sudo ships with
nearly every Unix/Linux distribution, so it is almost
ubiquitous; however, building a PAM program on
sudo is shortsighted. In organizations with large
numbers of Unix servers, the lack of centralized
policy management in sudo leads to inefficiencies,
inaccuracies and vulnerabilities. Sudo is not
designed to allow tracking and auditing, and there
are ways around the security offered by sudo
that make it unacceptable for systems with strict
compliance requirements.
2. I trust my admins.
After all, youre the one who hired them, so you
may believe that they are good employees. Surely
they have a vested interest in seeing your business
succeed. But the 2014 Verizon Data Breach
Investigations Report points to an increase in
IAG ensures that the proper protections and controls are in place to remove as much
riskaspossible.
2
2014 Data Breach Investigations Report, Verizon, April 2014, www.verizonenterprise.com/DBIR/2014/
4
insider espionage targeting internal data and trade
secrets, and a broader range of tactics compared
to previous years, with privilege abuse accounting
for 88 percent of instances of insider and privilege
misuse. Most regulations demand controls on
2
access and separation of duties, which you cannot
satisfy by saying, I trust my admins. Too often,
this bury-your-head-in-the sand approach leads
to addressing an unfavorable audit or patching
a hole after an incident, then a hurried PAM
implementation, then a siloed and incomplete
PAMprogram.
3. All we need is a credential vault.
If you eliminate the sharing, you solve the problem
of privileged credentials, right? Maybe, but what
does it cost you? Consider the management
overhead involved in issuing, tracking, returning
and changing administrative passwords every time
anyone needs them. Most organizations have teams
of IT staff dedicated to administering with elevated
access. When that access depends on a credential
vault, your IT staff may spend more time managing
the overhead than it does managing elevated
access. Do you really want to use a vault for even
 the most mundane of IT tasks, those that fill the
majority of your staffs day?

Approaching PAM in a disjointed, siloed

manner is a recipe for failure.

4. We can approach PAM in a piecemeal manner.

Putting PAM in place one piece at a time, without
considering the ideal endstate and the required
connections and integrations, is a bad idea.
Imagine an organization that has sudo for Unix root
delegation, uses a sudo replacement from vendor
A when sudo doesnt suffice, manages a credential
vault from vendor B, has an AD Admin delegation
tool from vendor C, and is floating an RFP for a
governance solution for PAM involving vendors
D, E and F. Just as in user access management,
approaching PAM in a disjointed, siloed manner is
arecipe for failure.

5. Governance doesnt apply to PAM.

Governance is governance, and your auditor
doesnt care whether its easy to prove compliance
or not. Auditors want to see that you can correctly
provision elevated access across all systems and
perform attestation on that access. Since privileged
accounts are prime targets for breaches, the
requirement to govern those accounts and that
access is omnipresent. 3

If those attitudes prevail in your organization, it is

For a deeper discussion on the impact governance can have on your PAM time to re-evaluate and improve your approach to
program, read the e-book Identity and Access Management for the Real managing and securing privileged accounts.
World: Identity Governance.

5
Getting privileged account management right
The good news is that many organizations get PAM
right by following a few guidelines, without a wholesale
rip-and-replace. While the following list is not
comprehensive, it contains the ingredients most common
to successful PAM programs:
1. Unix has special needs. The Unix/Linux root
account is unique in that it is all-powerful, it is
independent from every other root account and it is a
point of vulnerability for the entire system, including
Unix data. Observance of a few simple rules helps
to improve security, efficiency and compliance for
the Unix/Linux root account and the administrators
whouse it:
When using sudo, manage it as efficiently
and consistently as possible. Look for ways to
centralize policy across all sudo instances.
When sudo doesnt meet your needs, choose a
sudo replacement that can draw from the same
policy set, management capabilities and account
administration as those systems that use sudo.
Unifying Unix/Linux access through an Active
Directory bridge can go a long way toward getting
PAM right on Unix machines. If the AD bridge also
influences sudo and any sudo replacements, then
the traditional difficulties in PAM on Unix/Linux
systems evaporate.
Dont forget keystroke logging. Ensure that you
can adequately monitor what your Unix/Linux
admins are doing, whether they use sudo or not,
6
and make sure you audit only once with a single
toolset across all Unix-based PAM systems.
2. AD is important. While Microsoft solved many
of the Unix-like security problems of Windows NT
with Active Directory in Windows XP, the native
management and security tools in AD lack support
for PAM. Every AD management or PAM program
should allow for delegating precisely the activities
that AD administrators may perform and providing
the permissions they need to do their jobs. Look for
an AD delegation tool (preferably one that integrates
fully with your AD bridge) to eliminate this often-
overlooked weakness in most PAM programs.
3. Dont just vault. Anonymous administrative access
is a big obstacle to successful privileged account
management. A credential vault is a good way to deal
with this problem, if you follow these rules:
Combine vaulting with delegation to provide
convenient and secure access for the day-to-day
activities of your administrators (particularly for
Unix/Linux and Active Directory). Also, provide
the extra-elevated access required for the
occasional firecall, to grant emergency access
toadministrators.
Choose a vault that covers the widest range of
accounts. Just as risky, and often much less
efficiently managed, are the service accounts
associated with infrastructure such as routers
and firewalls, and the hardcoded passwords that
 your applications pass to other applications and
datasources.

Unify policy and identity. Imagine how many silos

you can eliminate if the credential vault uses the
same set of policies, identities and roles used by
the delegation tools and your IAM systems. But if
the vault represents yet another silo, it will stand
in the way of a truly successful PAM project.

Include session audit. You achieve even greater

security and compliance gains when your
credential vault also allows you to audit sessions
and impose individual accountability on activities
performed with elevated rights.

4. Do it all with an eye toward governance.

Governance is the ultimate goal of IAM. 4

Unfortunately, few PAM projects anticipate the

governance issues that will eventually arise.
Governance on privileged accounts requires that
provisioning of elevated access (including provisioning
of delegated permissions, credential vault access
and workflows) be unified with the provisioning of
standard user accounts. In addition, the attestation/
recertification required for regular user access must
extend to privileged users and the access controlled
by PAM. If your PAM solution was not designed with
governance in mind, it will be difficult to retrofit
itlater.

To summarize, the ideal approach to PAM uses a unified

policy and identity set, combines vaulting with delegation
(for Unix/Linux and AD) and leads easily into governance.

4
For a detailed explanation of the hierarchy of IAM needs, read the e-book
IAM for the Real World: The Fundamentals.

7
One Identity for Privileged Account Management
One Identity includes a complete set of privileged
account management solutions designed to give you the
best chance at IAM success. One Identity includes:
Credential vault technology In an ultra-secure
appliance, the One Identity privilege safe offers the
complete set of capabilities required to eliminate
superuser password sharing across the enterprise,
including application-toapplication (A2A) and
application-to-database (A2DB) scenarios.
Active Directory One Identity optimizes privileged
account management with management and security
tools for AD, including a least-privileged model for the
AD Administrator account.
Privileged account governance Integrated with the
privilege safe is governance for privileged accounts
as well as for application access and unstructured
dataaccess.

Session audit Easily added to the privilege

safe, session audit enables you to watch what
administrators do through the credentials issued by
the safe and to restrict the commands they may run.

Unix-optimized privileged account management

One Identity includes a comprehensive suite of PAM
solutions with a single interface, perfectly suited
to Unix and Linux environments. Features include
the Active Directory bridge, a centralized policy
server with reporting for sudo and a deep, granular
replacement for sudo (depending on need).

One Identity includes a complete set of

privileged account management solutions
designed to give you the best chance at
IAM success.

8
Conclusion
Privileged account management (PAM) ensures that
administrators and superusers with privileged accounts
have the access they need to do their jobs. Organizations
that rely excessively on sudo, credential vaults and the
best intentions of administrators have difficulty complying
with governance requirements, but they can get PAM right
by following a few simple guidelines and rules.
One Identity for privileged account management offers
a credential vault, audit capabilities and a suite of
solutions for control of administrator access across the
enterprise, helping organizations manage their privileged
accountssuccessfully.

9
To learn more
For an in-depth look at IAM, read the e-book Identity and Access
Management for the Real World: The Fundamentals. And stay
tuned for more e-books in this series. Ill cover the entire range of
IAM projects:

Identity governance

Access management

Privileged management

For more information visit oneidentity.com

About One Identity
The One Identity family of identity and access management (IAM)
solutions offers IAM for the real world, including business-centric,
modular and integrated, and future-ready solutions for identity
governance, access management and privileged management.
If you have any questions regarding your potential
use of this material, contact:
Quest Software Inc.
Attn: LEGAL Dept
4 Polaris Way
Aliso Viejo, CA 92656
Refer to our Web site (www.quest.com) for regional
and international officeinformation.
Ebook-StrategiesForYourPrivilegedAccounts-Part3-US-KJ-25990
11
2017 Quest Software Inc. ALL RIGHTS RESERVED. This guide
contains proprietary information protected by copyright. The
software described in this guide is furnished under a software license
or nondisclosure agreement. This software may be used or copied
only in accordance with the terms of the applicable agreement. No
part of this guide may be reproduced or transmitted in any form or
by any means, electronic or mechanical, including photocopying and
recording for any purpose other than the purchasers personal use
without the written permission of Quest Software Inc.
The information in this document is provided in connection with
Quest Software products. No license, express or implied, by
estoppel or otherwise, to any intellectual property right is granted
by this document or in connection with the sale of Quest Software
products. EXCEPT AS SET FORTH IN THE TERMS AND CONDITIONS
AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT,
QUEST SOFTWARE ASSUMES NO LIABILITY WHATSOEVER AND
DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY
RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO
EVENT SHALL QUEST SOFTWARE BE LIABLE FOR ANY DIRECT,
INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL
DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR
LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF
INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE
THIS DOCUMENT, EVEN IF QUEST SOFTWARE HAS BEEN ADVISED
OF THE POSSIBILITY OF SUCH DAMAGES. Quest Software makes
no representations or warranties with respect to the accuracy or
completeness of the contents of this document and reserves the
right to make changes to specifications and product descriptions
at any time without notice. Quest Software does not make any
commitment to update the information contained in this document.