9781119450610

These materials are © 2017 John Wiley & Sons, Inc.
Any dissemination, distribution, or unauthorized use

is strictly prohibited.
Securing
Privileged Access in
Active Directory
®
ManageEngine Special Edition
by Derek Melber, MVP
These materials are © 2017 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use
Securing Privileged Access in Active Directory®
For Dummies®, ManageEngine Special Edition
Published by
John Wiley & Sons, Inc.
111 River St.
Hoboken, NJ 07030-5774
www.wiley.com
Copyright © 2017 by John Wiley & Sons, Inc., Hoboken, New Jersey
No part of this publication may be reproduced, stored in a retrieval system or transmitted
in any form or by any means, electronic, mechanical, photocopying, recording, scanning,
or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States
Copyright Act, without the prior written permission of the Publisher. Requests to the
Publisher for permission should be addressed to the Permissions Department, John Wiley &
Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or
online at http://www.wiley.com/go/permissions.
Trademarks: Wiley, For Dummies, the Dummies Man logo, Dummies.com, and related trade
dress are trademarks or registered trademarks of John Wiley & Sons, Inc., and/or its affiliates
in the United States and other countries, and may not be used without written permission.
ManageEngine and the ManageEngine logo are trademarks or registered trademarks of ZOHO
Corporation. All other trademarks are the property of their respective owners. John Wiley &
Sons, Inc., is not associated with any product or vendor mentioned in this book.
LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO

REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE
CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT
LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED
OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CONTAINED
HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING
THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL
SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL
PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE FOR
DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS REFERRED TO IN
THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN
THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE
MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT
INTERNET WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN
THIS WORK WAS WRITTEN AND WHEN IT IS READ.
For general information on our other products and services, or how to create a custom For
Dummies book for your business or organization, please contact our Business Development
Department in the U.S. at 877-409-4177, contact info@dummies.biz, or visit www.wiley.
com/go/custompub. For information about licensing the For Dummies brand for products or
services, contact BrandedRights&Licenses@Wiley.com.
ISBN 978-1-119-45060-3 (pbk); ISBN 978-1-119-45061-0 (ebk)
Manufactured in the United States of America
10 9 8 7 6 5 4 3 2 1
Publisher’s Acknowledgments
We’re proud of this book and of the people who worked on it. Some of the
people who helped bring this book to market include the following:
Development Editor: Nicole Sholly Business Development

Representative: Karen Hattan
Project Editor: Martin V. Minner
Production Editor:
Executive Editor: Steve Hayes
Tamilmani Varadharaj
Editorial Manager: Rev Mengle
Introduction
A
s more and more important data is stored on an
organization’s networks and computers, those
networks and computers will continue to come
under attack. Many in the industry feel that these attacks are
successful because of the lack of control of privileged access.
Through my experience at ManageEngine, I have come to

believe this is the main root cause as well, so I wanted to
provide insight and guidance on how to protect privileged
accounts.
Privileged accounts typically fall into three categories:

Users (administrators), groups with privileges, and ser-
vice accounts.
This book focuses on keeping these three accounts secure.
About this Book

The book helps organizations and administrators focus
on the key aspects of securing privileged accounts. Merely
securing privileged accounts goes only so far because
changes can be made to secured accounts nearly within
seconds, making them insecure again. So, securing privi-
leged accounts is only one part of your responsibility; you
must also monitor changes to those accounts.
1
Monitoring privileged account changes includes tracking
and logging changes, logging what the accounts accessed,
alerting administrators that changes to these accounts
are made, and being able to run reports of historical
changes to the accounts.
Microsoft doesn’t provide the tools to complete these

tasks, which is why, in this book’s appendix, I provide
you with a robust and thorough list of links to free tools
and resources to help you track and secure privileged
accounts for your Active Directory environment.
Icons Used in This Book

This book uses the following icons to call your attention
to can’t-miss information.
I use this icon to introduce something that’s

particularly technical in nature.
Don’t miss the information marked with the

Tip icon — it can make your life easier.
When I need to emphasize a point that can

help you avoid potential pitfalls leading to
bad consequences, you’ll see this icon next to
the paragraph.
2
IN THIS CHAPTER
»» Securing local Administrator accounts
»» Determining whether Administrator
is being used
»» Creating a honeypot Administrator
account
»» Tracking failed logons to
Administrator account
Chapter 1
Administrator
Accounts
A
dministrator accounts are everywhere. All desk-
tops, servers, and Active Directory domains have
an Administrator account. Because these accounts
can be used to change security settings, install software
and hardware, access all a computer’s files, and make
changes to other user accounts, you must protect them.
Both local Administrator accounts on desktops and serv-

ers and the Administrator account in Active Directory
must be protected and secured.
3
You can use many techniques to secure Administrator
accounts, all of which contribute to the overall security
profile for these accounts.
Ideally, because Administrator accounts are so

critical to security, as many of the techniques
and options that can be used, should be used.
Local Administrator
Every desktop and server has a local Administrator
account. These accounts have full control over every
aspect of the computer (or server), and so need to be
secured.
The following sections discuss two actions that can be

taken to secure these accounts.
Using different passwords

For years, organizations have “imaged” an ideal
computer — that is, one that contains all the ideal
settings, applications, and various configurations — so
that the image could be copied onto new computers. This
solution provides an easy and efficient method for
placing new computers into an established environment
with the ideal configuration.
4
Unfortunately, each new computer that the image is
installed on receives the same password for the local
Administrator account. Each computer with the same
password is vulnerable to attacks such as pass-the-hash
and pass-the-ticket, which take advantage of the
oversight.
Therefore, each Administrator account on the network

must have a unique password.
Local Administrator Password Solution

(LAPS) is a solution that allows the Adminis-
trator password for both desktops and servers
to be managed and stored in Active Directory.
LAPS ensures that the Administrator password is unique

and constantly updated. This level of security can help
reduce the attacks against these accounts.
LAPS requires the installation and use of Active

Directory, Group Policy, and PowerShell.
Disabling the Administrator

account
Since the built-in Administrator account is attacked so
often based on the name and known security identifier
(SID), a good practice is to disable it so it can’t be a secu-
rity liability. The easiest way to disable the Administrator
account is through Group Policy.
5
Before you disable the built-in Administrator
account, be sure to create another user
account that has administrative privileges so
you can still administer the computer.
The built-in Administrator account is dis-

abled on Windows 7 and later by default.
Active Directory
Administrator
With the Administrator in Active Directory having ultimate
privileges, this account must be secured and protected.
Nearly every moderately sophisticated attacker is aware
that every Administrator account created (desktops, serv-
ers, and Active Directory) has an SID ending with -500.
This common knowledge makes it hard to hide this

account. However, you can make configurations to
increase the level of security around the Administrator
account. These configurations can also provide insight
into when the account is under attack.
Ensuring Administrator is not

being used
The Administrator account is the most important user
account in Active Directory. It cannot be deleted, and it
6
cannot be locked out. For all of these reasons, this account
should be protected and not used for daily tasks.
Instead, you need to verify that this account is not log-

ging in regularly.
Tracking and reporting on logons using the

Administrator account is easy using the
ADAudit Plus tool. See the appendix for more
tools and resources.
Additionally, you should not configure this account as a

service account in any way.
Creating the Administrator

honeypot
This security technique is not highly technical, but the
results are extraordinary. Because everyone knows the
name and SID of the built-in Administrator, the account
can be continually attacked without hesitation.
However, if the built-in Administrator account is

renamed, the attacker would need to know the new name
to attack the account. This is only a small step in security,
as the SID remains unchanged.
The important aspect of this measure is to create a new

Administrator account that has no privileges at all. Then,
if the bad logon attempts are tracked and threshold levels
7
associated with the bad logons configured, an email can be
sent when the new Administrator account is under attack.
The honeypot approach can expose internal employees

who are attempting to breach the network using the
Administrator account.
Software such as ManageEngine’s ADAudit

Plus can easily create alerts that track failed
logons for the Administrator account. Then,
when a set threshold of bad logons is reached,
an email is sent to one or more network
administrators indicating the attack.
Tracking failed logons

After you have created a new Administrator account with
no privileges, you can track when someone fails to log on
as this account. No one else in the environment will know
that the account is not the original Administrator account,
so anyone failing to log on is obviously attempting to
hack into the account.
Choose to receive email alerts only when cer-

tain thresholds of failed logon attempts are
made within a short period of time. This
indicates a significant attack instead of a
single failed logon attempt. ADAudit Plus
provides this level of monitoring and
alerting.
8
IN THIS CHAPTER
»» Determining privileged groups
»» Enumerating privileged groups
recursively
»» Tracking privileged group changes
Chapter 2
Privileged Group
Accounts
T
he most common way users are granted privileges
is to be placed into groups that have privileges. You
need to know these things about group privileges:
»» Which groups have privileges.

»» How privileges are granted to groups.
»» Which users are in what groups. (There can be
nested groups, which complicates things.)
»» When the membership of these groups changes.
9
Not only can groups be nested, but there is
nearly an unlimited depth of nested groups
possible.
Determine Privileged Groups

Many organizations have hundreds and even thousands
of groups in Active Directory (AD). Determining which
groups have privileged access is difficult. Understanding
how groups are granted privileges makes it easier to doc-
ument privileged groups.
Granting privileges
You have many ways to grant privileges to groups (and
therefore to users) in a Windows environment. Having so
many options for granting privileges makes reporting on
all of them difficult because they are not centralized.
Privileges can be granted down to the file level. So there

can be millions of privileges granted without being able
to truly report all of them.
Privileges can be granted in the following ways to AD

groups:
»» Adding to a group
»» Granting user rights
10
»» Access control list (ACL)
»» Delegation
Determining which groups have

privileges
You have many ways to grant privileges to groups. To
document which groups have privileges, look at the
groups you know have privileges first. AD has three cat-
egories of these groups:
»» Built-in groups with privileges: Every installation

of AD has the same default groups. Many have
elevated privileges. Documenting these groups is
essential to track and know who has privileges.
Examples are Domain Admins, Enterprise Admins,
and Schema Admins.
»» Service and application groups: Often an

installed application or service places one or more
groups that will be used to manage and administer
the application or service into AD. These groups
usually have elevated privileges. Examples are
Exchange Administrative Group and SharePoint
Administrative group.
»» Custom groups: Administrators often like groups

to have names that are comfortable to them. An
example would be to create a CorpAdmins group
and place this group in the Domain Admins group.
11
Enumerate Privileged Groups
Recursively
After you document all privileged groups, you must
ensure that the current group membership is correct.
Groups are commonly nested within groups, which are
further nested within groups, and so on. You need to get
a listing of all users within each group, including the
nested groups. This means you must obtain the list of
users recursively.
Until 2009 when Microsoft released the AD Module for

PowerShell, compiling a recursive list of users for a group
was nearly impossible because it was a manual task that
could take many hours. Even using PowerShell to per-
form this task can be inefficient because of the verifica-
tion process and formatting required to utilize the
information obtained from using PowerShell.
ADManager Plus provides recursive group

membership reports without the need for
any formatting to generate reports.
Tracking Group Changes

All the groups I focus on here can perform some level of
administration or configuration, so it is ideal to know
who has membership in these groups. After you’ve
12
enumerated the members for each group, you need to
configure the group members to be correct.
After you configure each group correctly, the next step is

to set up notifications to alert you when the group
changes membership. If you have no notifications, the
group membership remains the same.
To track changes to your privileged groups, you must be

able to log the changes, generate reports for all changes,
and receive real-time alerts for key group membership
changes. I describe these tasks next.
Logging changes
Microsoft provides auditing technology that allows all
changes to AD groups to be logged. Auditing is part of
Group Policy. If you enable account management audit-
ing, all group changes are monitored and logged.
Group Policy provides the Audit Policy that

allows for tracking of changes to nearly all
aspects of the operating system, including
group membership changes.
Generating change reports

Most compliance regulations, auditors, security profes-
sionals, and so on require reports of key privileged groups
and the change history. The reports must be all-inclusive
of each group’s changes during the period the report cov-
ers. The report should include these details:
13
»» Group changes: All users and groups added to and
removed from the group.
»» Date of change: The full date and time of the group

change.
»» Who made the change: The person executing the

change.
ADAudit Plus provides reports with full details

of group changes; it also allows delegation
and automation of this report generation.
Setting up real-time change alerts

Privileged groups provide an elevated level of access to AD
and the network, so any group that has significant privi-
leges and access (Domain Admins, Enterprise Admins,
and so on) should have special attention for changes.
When anyone is added to or removed from a key privi-
leged group, a real-time email alert should be sent to one
or more administrators to inform them of the change. The
alert must be in real-time, so there is little to no time for
the change to be leveraged, if the change is incorrect.
ADAudit Plus provides for real-time alerting

of key privileged group changes. The list of
privileged groups to be monitored is custom-
izable, allowing only the most important
group changes to trigger an alert.
14
IN THIS CHAPTER
»» Protecting service accounts
»» Documenting service accounts
»» Tracking service accounts
Chapter 3
Service Accounts
S
ervice accounts are either local accounts or user
accounts from Active Directory that perform func-
tions for applications or services. Usually these
functions are communications outside the computer
where the application or service is installed. Most service
accounts must have elevated privileges to perform actions
on the computer and on other devices on the network.
Because service accounts communicate with elevated

privileges and maintain the availability of the services
they facilitate, these accounts must be handled with great
care and protected at all cost.
Two major hurdles regarding service accounts include

knowing where they are configured and being able to
track any changes to the account. Overcoming both issues
allows you to better manage service account security.
15
Service accounts can be configured for nearly
every operating system. This chapter covers
service accounts for Windows services.
Why Protect Service Accounts

Most service accounts control the service and how the
service communicates with other computers and users.
Most services communicate outside the computer where
the service is installed, which means the service account
must have privileges beyond a single computer. This
expanded level of privilege is of utmost concern.
Suppose a service account, which has membership in the

Domain Admins group, is compromised by an attacker.
Because most service accounts are not monitored, nor is
their access tracked, the attacker will be able to access all
resources in the domain without detection.
If these elevated privileges are so powerful, by what means

are privileges granted to service accounts? A service
account can be granted elevated privileges in three primary
ways: group membership, user rights, and service account
access control lists (ACLs).
Group membership
Like privileged users in Chapter 1, service accounts can
have membership in a privileged group, which immedi-
ately grants them some level of privilege. This membership
16
is usually granted at the installation of the service and
association of the service account to the service.
User rights
User rights are a per-computer configuration. There are
more than 35 user rights that grant privileges such as
changing the system time, backing up files, and having
service-level access to the computer. Each user right
provides a different level of privilege over the computer.
Knowing which user rights a service has been granted
can help you track the service account.
User rights are typically granted to comput-

ers using Group Policy.
Service ACLs
Service ACLs aren’t typically used to grant privileges, but
it’s possible. The service ACLs include the ability to stop
the service, start the service, and even shut it down.
Acquiring Service Accounts

Because I focus on Windows services only, you can see a
listing of all services for each computer (workstation,
server, and domain controller) by using the services.msc
command from each computer. This shows you which
services are installed (with details about each).
17
In the list of services, you also see a Log On As column.
This entry enables you to get a listing of the service
accounts that are responsible for each service. These
accounts can be local or from Active Directory (AD).
Because services.msc can show only a per-computer

view of services, it isn’t ideal for getting a list of all Win-
dows service accounts for the organization. There might
be thousands of workstations, servers, and domain con-
trollers, which makes individual documentation difficult.
The ManageEngine free tool for services

provides a listing of all service accounts, per
computer, and the service for which they are
configured.
Tracking Service Accounts

Service accounts can literally make or break a service’s
availability. Various changes or configurations made to a
service account can halt the service for which it is respon-
sible. Thus, you must monitor all service accounts to
ensure they’re functioning correctly.
These three major aspects of monitoring and tracking

service accounts should be performed:
»» Monitor changes: Implement a system that tracks

all service accounts and any changes — passwords,
group membership, failed logons, and so on.
18
»» Set up alerts: Service accounts are so high profile that
notifications should be sent to key employees when
changes are made. The alerts must be in real-time
and include details: who made the change, what the
change was, and when the change was made.
»» Set up reporting: Reports give a historical view of

changes to service accounts, so they must be
possible for any timeframe.
ADAudit Plus from ManageEngine provides

the ability to monitor, alert, and report on
changes to a custom list of service accounts.
Monitor service account changes

If you aren’t monitoring service account changes, a ser-
vice might become unavailable. The administrator, who
is usually notified by an end-user that an application
isn’t working, must then follow standard troubleshoot-
ing techniques to track down the problem. A report of all
service account changes can reduce the troubleshooting
time required to investigate those changes.
Essential changes to monitor include password changes

and group membership changes, for example.
Decrease your organization’s attack surface

by limiting which computers service accounts
can log on to. A change to this list of comput-
ers indicates a potential attack.
19
Alerting service account changes
Notifying an administrator of changes to a service account
is very important. Administrators are often too busy to
check logs or run reports to ensure no changes have
occurred. If the administrator receives an email indicating
a change has occurred, he or she can take immediate action
to rectify the change or ensure the change is correct.
Alerts need to include full details of the

change: who made the change, when the
change was made, what the new value is (and
the old value, if possible), and where the
change was initiated.
Reporting account changes

Auditors and other security professionals benefit from
reports that show all changes to service accounts. The
ability to generate a historical view of all service account
changes can help auditors and other security professionals
maintain good security practices, ensure correct access,
and meet compliance requirements.
The ability to run reports for changes that occurred in the

past is necessary when investigating a breach or per-
forming other forensic tasks. Having the history of
changes down to the service account level can help deter-
mine if a change was the root cause for a breach.
20
Chapter 4
Ten Ways to Secure
Privileged Access
T
racking and securing privileged access requires
experience and knowledge. It also requires that
you take action to ensure that only the correct
users have privileges in your Active Directory controlled
environment.
Knowing where to look, how to secure settings, and what

is required to monitor and alert for tracking access is
essential in keeping tabs on who has privileges.
This chapter outlines and summarizes ten key points that

you need to consider for privileged access:
»» Don’t just configure, but monitor.

I find that so many organizations take the time to
secure privileged access, but then forget about it.
21
Without knowing who has access 24/7, you are
allowing incorrect changes or even attackers access
to your information without your knowledge.
Regularly monitoring who has access and when

changes are made keeps you on top of unauthor-
ized access.
»» Secure the built-in Administrator account.

The user SID ending with -500 is essential to your
Active Directory enterprise. Be sure to rename this
account, configure it with a long and strong
password, and create a new Administrator
honeypot user account.
See Chapter 2 for more about creating the

honeypot account.
»» Don’t use the Administrator account.

The built-in Administrator account is used to set up
Active Directory and to recover from major issues.
Do not use this account for routine management

and especially not as a service account.
»» Track failed logons by Administrator.

If you have renamed the Administrator account and
are still getting logon attempts for Administrator,
that means you are under attack!
22
Monitor failed honeypot Administrator logons to
track down attackers.
»» Determine groups with privileges.

You need to ensure that all privileged groups —
and not just the built-in groups — are documented.
Groups used for services, applications, and routine
administration need to be documented.
»» Enumerate group members recursively.

It is highly common to nest groups within
groups . . . within groups. So, when you’re docu-
menting groups that are used for services,
applications, and routine administration, be sure to
get all users within all nested groups, no matter
how deep the nesting is.
»» Track privileged group changes.

If you do not know when a group changes member-
ship, you do not know who has privileges. Ideally
you need to get a real-time email alert when any
key privileged group changes membership.
»» Acquire all service accounts.

Because service accounts have privileges, you need
to know all user accounts that are configured to
control services.
The Free Active Directory Service Account tool from

ManageEngine is ideal for this task.
23
See the appendix for more useful tools and
resources.
»» Track changes to service accounts.

Every administrator knows that if a service account
password is changed, group membership is
changed, and things will go bad.
Set up real-time email alerts for all changes to

service accounts to ensure you’re notified immedi-
ately when any changes occur.
»» Take action now!

Attackers are waiting for the right opportunity to
gain control of privileged accounts. When they see
an opportunity, they will seize it.
Take action now to reduce the likelihood that you

will be attacked by someone gaining unauthorized
access to a privileged account.
24
Appendix
Free Tools and
Resources
T
he chapters of this book give insight to securing
and monitoring privileged accounts. Before you
begin that tracking and securing, however, you
must know who and what has access in your environ-
ment. The free tools and resources listed in this appendix
provide you with the means and the guidance to help you
accomplish these goals.
Free Tools
The tools listed here are either free or come with a free
30-day trial that will allow you to explore the tool before
making a purchase.
»» ADAudit Plus (30-day trial)

www.manageengine.com/products/
active-directory-audit/
25
»» ADManager Plus (30-day trial)
www.manageengine.com/products/ad-manager/
»» ADSelfService Plus (30-day trial)

self-service-password
»» RecoveryManager Plus (30-day trial)

www.manageengine.com/ad-recovery-manager
»» FileAudit Plus (30-day trial)

www.manageengine.com/file-server-auditing/
»» EventLog Analyzer (30-day trial)

www.manageengine.com/products/eventlog/
»» Exchange Reporter Plus (30-day trial)

exchange-reports/
»» AD Query Tool
www.manageengine.com/products/free-windows-
active-directory-tools/free-windows-active-
directory-query-tool.html
»» CSV generator
active-directory-tools/free-active-directory-
csv-generator-tool.html
26
»» Last Logon Reporter
active-directory-tools/free-windows-last-
logon-reporter.html
»» AD Replication Manager
active-directory-tools/free-windows-ad-
replication-manager.html
»» Domain and DC Roles Reporter

active-directory-tools/free-windows-domain-
controller-roles-reporter.html
»» Local Users Manager

active-directory-tools/free-microsoft-windows-
powershell-cmdlet-manage-local-users-tool.html
»» Password Expiry Notifier

www.manageengine.com/products/self-service-
password/free-password-expiry-notification-
tool.html
»» Service Account Management Tool

service-account-management-reporting-tool.html
27
»» Weak Password Users Report
weak-password-finder.html
Free Resources
The ManageEngine blog provides hands-on information
for tracking and securing privileged accounts, explains
why each task is important, and gives an overview of the
many tools that can help you manage your Active Direc-
tory environment.
»» Security Hardening For Active Directory

www.manageengine.com/security-hardening-for-
windows-active-directory.html
»» Automating Privileged Group Modifications in

Active Directory
https://blogs.manageengine.com/active-directory/
adauditplus/2014/05/31/automating-privileged-
group-modifications-in-active-directory.html
28
»» Windows Service Account Finder and Reporter
https://blogs.manageengine.com/free-tools/
active-directory-free-tools/2015/07/16/windows-
service-account-finder-and-reporter.html
»» Tracking “Admin” Logon Failures Down to the IP

Address
https://blogs.manageengine.com/active-
directory/2015/07/02/tracking-admin-logon-
failures-down-to-the-ip-address.html
»» Securing Active Directory: Group Membership

Alerts
directory/2015/04/16/securing-active-
directory-group-membership-alerts.html
»» Securing Active Directory: Analyzing Group

Membership
directory/admanager/2015/04/03/securing-
active-directory-analyzing-group-membership.
html
»» Tracking Administrative Group Modifications

directory/2014/12/18/tracking-administrative-
group-modifications.html
29
»» Automatically Disable Unused User Accounts,
Except Service Accounts
https://blogs.manageengine.com/active-directory/
2016/12/08/automatically-disable-unused-user-
accounts-except-service-accounts.html
»» Alerting And Reporting On Windows Service

Account Modifications
directory/2015/11/19/alerting-and-reporting-
on-windows-service-account-modifications.html
»» Reporting On Windows Service Account

Configurations
directory/2015/11/12/reporting-on-windows-
service-account-configurations.html
»» Reducing Attack Surface Of Windows Service

Accounts
directory/admanager/2015/11/05/reducing-
attack-surface-of-windows-service-accounts.
html
»» Windows Service Account Finder and Reporter

https://blogs.manageengine.com/free-tools/
active-directory-free-tools/2015/07/16/windows-
service-account-finder-and-reporter.html
30
WILEY END USER LICENSE AGREEMENT
Go to www.wiley.com/go/eula to access Wiley’s ebook EULA.

9781119450610

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

9781119450610

Caricato da

Copyright:

Formati disponibili

These materials are © 2017 John Wiley & Sons, Inc.

Any dissemination, distribution, or unauthorized use

ManageEngine Special Edition

by Derek Melber, MVP

LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO

Development Editor: Nicole Sholly Business Development

Through my experience at ManageEngine, I have come to

Privileged accounts typically fall into three categories:

This book focuses on keeping these three accounts secure.

About this Book

Microsoft doesn’t provide the tools to complete these

Icons Used in This Book

I use this icon to introduce something that’s

Don’t miss the information marked with the

When I need to emphasize a point that can

Both local Administrator accounts on desktops and serv-

Ideally, because Administrator accounts are so

The following sections discuss two actions that can be

Using different passwords

Therefore, each Administrator account on the network

Local Administrator Password Solution

LAPS ensures that the Administrator password is unique

LAPS requires the installation and use of Active

Disabling the Administrator

The built-in Administrator account is dis-

This common knowledge makes it hard to hide this

Ensuring Administrator is not

Instead, you need to verify that this account is not log-

Tracking and reporting on logons using the

Additionally, you should not configure this account as a

Creating the Administrator

However, if the built-in Administrator account is

The important aspect of this measure is to create a new

The honeypot approach can expose internal employees

Software such as ManageEngine’s ADAudit

Tracking failed logons

Choose to receive email alerts only when cer-

»» Which groups have privileges.

»» When the membership of these groups changes.

Determine Privileged Groups

Privileges can be granted down to the file level. So there

Privileges can be granted in the following ways to AD

Determining which groups have

»» Built-in groups with privileges: Every installation

»» Service and application groups: Often an

»» Custom groups: Administrators often like groups

Until 2009 when Microsoft released the AD Module for

ADManager Plus provides recursive group

Tracking Group Changes

After you configure each group correctly, the next step is

To track changes to your privileged groups, you must be

Group Policy provides the Audit Policy that

Generating change reports

»» Date of change: The full date and time of the group

»» Who made the change: The person executing the

ADAudit Plus provides reports with full details

Setting up real-time change alerts

ADAudit Plus provides for real-time alerting

Because service accounts communicate with elevated

Two major hurdles regarding service accounts include

Why Protect Service Accounts

Suppose a service account, which has membership in the

If these elevated privileges are so powerful, by what means

User rights are typically granted to comput-