An 8-Step Guide to Administering Windows

without Domain Admin Privileges

Russell Smith, IT & Cybersecurity Consultant

An 8-Step Guide to Administering Windows without Domain Admin Privileges

TABLE OF CONTENTS
Introduction ............................................................................................... 3

How Privileged Credentials are Carelessly Exposed ......................................... 3

Security Considerations for Active Directory ................................................... 4

Best Practices for Securing Active Directory ................................................... 5

1. Enforce Least Privilege by Limiting Privileged Group Membership ............... 5

2. Fine-Grained User/Privileged User Account Management ........................... 5
3. Manage Administrative Access to End-User Devices .................................. 7
4. Manage Privileged Access to Servers....................................................... 8
5. Leverage PowerShell Just Enough Administration ..................................... 9
6. Use Privileged Access Management Across Domain Controllers .................. 9
7. Enable WSUS and Centralize Events ..................................................... 10
8. Enforce Separation of Administration .................................................... 10
Phased Approach to Privilege Management .................................................. 11

Powerbroker Privileged Access Management Platform ................................... 12

8 Steps to Administering Windows without Domain Admin Privileges............... 12

About Russell Smith .................................................................................. 14

An 8-Step Guide to Administering Windows without Domain Admin Privileges

INTRODUCTION
Hackers crave access to Active Directory (AD) because it provides a gateway into the entire
Windows IT infrastructure. With privileged access to domain controllers (DCs), malicious actors
can hide their tracks, while they covertly infiltrate the deepest levels of a compromised IT
infrastructure. In this how-to guide, Windows security expert and book author, Russell Smith,
examines how to efficiently administer Windows systems without using privileged domain
accounts, enabling you to drastically reduce your organization’s threat surface.

HOW PRIVILEGED CREDENTIALS ARE CARELESSLY EXPOSED

The Domain Admins group is a member of the local Administrators group on every domain-
joined device. The critical nature of domain administrator accounts, and other privileged AD
accounts, means that they should never be used on devices that are not secured to the same
standard as domain controllers. In practice though, organizations often grant IT staff privileged
access to AD, with the privileged accounts then used for everyday computing tasks, like
browsing the Internet or checking email, on devices that have a much larger attack surface than
domain controllers. IT staff often work with domain administrator privileges because it
facilitates administrative access to users’ devices.

Use of privileged AD credentials for everyday computing tasks makes it easy for hackers to
compromise the domain. And if users also have local administrative access to their devices,
hackers can use techniques, such as Pass-the-Hash (PtH), to gain privileged access to AD
without even having to crack the password for a privileged account. Through a series of simple
steps, hackers can also compromise cached credentials, or the local Security Accounts Manager
(SAM) database, on devices where users have local administrative privileges, to get access to
privileged AD accounts.

The Protected Users group, which was introduced in Windows Server 2012 R2, can help
mitigate some of these threats. But the mitigations only work in Windows 8.1 and Windows
Server 2012 R2 (or later) operating systems, and can’t protect against keyloggers and social
engineering.

Windows 10 introduces some new mitigations. Credential Guard protects domain accounts in a
virtualized container that is secured in the event that the Windows kernel is compromised.

An 8-Step Guide to Administering Windows without Domain Admin Privileges

Device Guard is also useful for preventing unauthorized kernel and user-mode code running
that could be used to compromise privileged AD accounts.

But while the technologies mentioned above provide some added protections, they are not
infallible. Ultimately, the optimal way to secure AD is to adhere to security best practices
provided by Microsoft.

SECURITY CONSIDERATIONS FOR ACTIVE DIRECTORY

All Active Directory (AD) domains have a built-in administrator account. This is the account that
you use to log in to a domain controller for the first time. The administrator account is a
member of the Domain Admins group by default and it is also a member of the Group Policy
Creator Owner group, which also has privileged access.

The built-in administrator is an unnamed account and has a well-known security identifier (SID).
This poses two problems:

• The use of unnamed accounts makes it difficult to track who is responsible for each user
session as well as any changes carried out using the unnamed account.

• The built-in administrator has a well-known SID (S-1-5-21domain-512), making it a prime

target for hackers because the SID can easily be identified in any AD domain. While
there’s no harm in renaming the built-in administrator account, the SID won’t change.

Domain administrators and users with privileged access to Active Directory pose an elevated
risk to enterprise security. There is a direct relationship between Active Directory and the
security of all systems that are joined to the domain because Active Directory manages the
security of all domain-joined systems. If AD is compromised, then the entire AD forest must be
considered compromised, including all end-user devices and servers that are part of the
domain. Once a hacker has privileged access to a domain, he/she can elevate to schema and
enterprise administrator, allowing him/her to compromise other domains in the forest.

An 8-Step Guide to Administering Windows without Domain Admin Privileges

BEST PRACTICES FOR SECURING ACTIVE DIRECTORY
1. Enforce Least Privilege by Limiting Privileged Group Membership

There are twelve built-in privileged groups in Active Directory. Each group has a well-known
SID. Microsoft recommends that privileged groups should remain empty most of the time (i.e.
they should only be populated when privileged access to a domain controller is required). As
soon as any necessary changes have been made, the user should be removed from the
privileged group. Removing users from privileged groups reduces the attack surface of your AD
forest.

Table A: The 12 privileged groups built into Active Directory

2. Fine-Grained User/Privileged User Account Management

Privileged access to the domain isn’t required to manage Active Directory objects, such as users
and groups. Access can be delegated to Organizational Units (OUs) so that users are able to
manage objects. You can delegate access to the built-in Users container or create an OU for
user accounts and delegate access to it. The Delegation of Control Wizard makes it easy to
grant users permission to perform common tasks, such as creating, deleting, and managing user
objects, or resetting user passwords.

Instead of logging in to a domain controller to manage user accounts, IT staff with delegated
control can use the Remote Server Administration Tools (RSAT) for Windows 10 to run the

An 8-Step Guide to Administering Windows without Domain Admin Privileges

Active Directory Users and Computers (ADUC) console on a PC. ADUC will allow the logged in
user to access the directory, but only perform the tasks that have been delegated to them.

Figure 1: Through built-in delegation, IT admins can assign rights and tasks to individual users
and/or groups of users.

More complicated tasks can be delegated to users in the wizard by assigning custom tasks.
Custom tasks give more control over what tasks users can perform and on which objects. But
for complete control over delegated permissions, you can modify access control entries (ACEs)
directly in the container or OU’s access control list (ACL).

Privileged User Account Management

Controlling access to privileged groups is more complicated. Microsoft has a solution based
around Identity Manager (MIM) and Windows Server 2016 JIT access. But where additional
tools are not available, the easiest way to grant privileged access to the domain is to use the
Domain Admins, Enterprise Admins, and Schema Admins groups. The other privileged groups
should remain empty. If you must use the other groups, consider removing their privileged
access to domain controllers.

An 8-Step Guide to Administering Windows without Domain Admin Privileges

Figure 2: Through the ADUC console, IT admins can manage privileged access to the domain.

The Domain Admins, Enterprise Admins, and Schema Admins groups are the only privileged
groups that can be moved into a custom OU. Control on a custom OU should be delegated to a
small set of directory service management accounts. These accounts can be used to temporarily
populate the Domain Admins, Enterprise Admins, and Schema Admins groups on request. This
method requires a separate process to manage access to the directory service management
accounts.

Directory service management accounts increase the cost of obtaining privileged access to the
domain. While they are not necessarily an ideal or convenient solution, it does mean that
nobody can get direct privileged access to the domain if an effective process for accessing the
management accounts is in place.

3. Manage Administrative Access to End-User Devices

The built-in administrator account on end-user devices also has a well-known SID. There are
two ways you can make the account more secure. The first is to create a new account, add it to
the BUILT-IN\Administrators group, and then disable the built-in administrator account. But the
most important step is to make sure the built-in administrator account, or account you use in
place of the built-in administrator, has a unique password on each device.

An 8-Step Guide to Administering Windows without Domain Admin Privileges

The Local Administrator Password Solutions (LAPS) is a free tool from Microsoft that enables
system administrators to set a random and unique password on each device, including member
servers, and securely store the passwords in Active Directory. A unique password must be set
on each device because if a shared password was compromised, it would allow hackers to move
laterally around your network, and potentially enable them to harvest privileged credentials to
Active Directory.

Managing administrative access to end-user devices is often accomplished with the help of the
Domain Admins group. Any user that is a member of Domain Admins automatically gets local
administrative access to all domain-joined devices. But giving IT staff privileged access to the
domain is risky.

To provide support staff with the access they need to manage user devices, create a group in
Active Directory and add it to the local Administrators group on users’ devices using Group
Policy. Local groups can be managed using Restricted Groups policy or Group Policy
Preferences.

If you chose to create an AD group for managing administrative access to workstations, first
confirm that when IT staff log in to their own devices, they are not granted local administrative
privileges. This can be achieved by making sure the Group Policy Object (GPO) used to add the
AD group to the BUILT-IN\Administrators group on users’ devices is not scoped to apply to
devices used by IT staff. Alternatively, you can provide IT staff with dedicated accounts for
supporting users’ devices.

4. Manage Privileged Access to Servers

Securing the local administrator account on member servers is also critical. LAPS can be used to
ensure that local administrator accounts have a unique password on each server. To guarantee
accountability, administrator access to member servers should be granted using domain
accounts.

No one should have permanent administrative access to a member server. To manage

administrative access, create a group in AD for each server and add it to the BUILT-
IN\Administrators group on the applicable server. You can then manage access to the server by
populating the server’s group in Active Directory. You can apply an approach similar to the one
used to manage privileged access to domain controllers, or be more lenient, depending on the
risk associated with the server and the applications it runs.

An 8-Step Guide to Administering Windows without Domain Admin Privileges

5. Leverage PowerShell Just Enough Administration

If you must give a user permanent access to a server, determine which privileged tasks must be
regularly performed. Access can be granted using PowerShell Just Enough Administration (JEA),
which is included in the Windows Management Framework (WMF) 5.0. JEA allows
organizations to assign staff elevated access to servers, while restricting the PowerShell
cmdlets, parameters, and modules that can be run.

JEA can be set up to give users access to a server in two ways. The first involves users accessing
a remote PowerShell endpoint on a server using their own account, and they get whatever
access their account is granted on the device. But the endpoint can be restricted so that
regardless of what permissions the user has, the tasks they can perform will be limited. For
instance, you could restrict DNS administrators to using just the PowerShell cmdlets required to
do their job.

The second method also requires users to connect to a remote PowerShell endpoint using their
own credentials, but any tasks performed are carried out using a per-session JEA virtual account
that has administrative privileges on the device. Users connecting to the endpoint never need
to know the virtual account’s password. The virtual account is managed by a JEA toolkit and
passwords set randomly using a scheduled task. And like the first method, the endpoint can be
constrained so that users have access to a limited set of capabilities.

PowerShell logs what was executed, when, where, and by whom in the event log. JEA toolkits
maintain a separate log file with information about the connecting host, process ID (PID), date,
time, toolkit, and RunSpaceID.

6. Use Privileged Access Management Across Domain Controllers

Windows Server 2016 Just-In-Time (JIT) access, with the help of a privileged access anagement
(PAM) solution, can be used to automate the workflow of granting users temporary access to
privileged AD groups, like Domain Admins. JIT allows organizations to assign privileged access to
a user only as it is required and for a limited time, after which access is revoked. Several new
technologies in Windows Server 2016 enable JIT administration, including shadow security
principals and time-limited group membership. Microsoft’s complex PAM solution requires
Microsoft Identity Management and an AD bastion forest that’s used to manage security in one
or more production domains.

An 8-Step Guide to Administering Windows without Domain Admin Privileges

To further secure domain controllers, privileged tasks should be performed from specially
designated workstations that are secured to the same level as DCs. Microsoft refers to these
devices as Privileged Access Workstations (PAWs). The Remote Server Administration Tools
(RSAT) and PowerShell modules for Active Directory can be used on PAWs to perform domain
controller administration tasks.

7. Enable WSUS and Centralize Events

Some IT administration tasks can and should be automated. This can reduce the need to
manually access servers using privileged credentials. Windows Server Update Services (WSUS)
is a built-in server role that can be used to keep Windows and Microsoft applications up-to-
date. With WSUS enabled, you’ve eliminated the need for administrators to log in with
privileged access to manually install updates.

Windows Server has built-in event log forwarding. Collecting event logs from all critical systems
in a central location allows IT to monitor what’s happening across the server estate without
accessing servers individually to read the event logs. The security event log on DCs has extra
protection and additional steps are required before it can be forwarded.

8. Enforce Separation of Administration

Managing privileged access to domain controllers that run line-of-business applications, or

Windows server roles and features, is more challenging than managing a server that is a
dedicated domain controller. A domain controller that doubles up as a fileserver will be difficult
to secure because fileservers need more hands-on maintenance than DCs. Virtualization allows
organizations to isolate DCs from other server applications. Starting in Windows Server 2012,
DCs can be virtualized using any hypervisor that supports VM-Generation ID. Windows Server
2016 Hyper-V Shielded VMs provide extra protection by encrypting VM data.

Microsoft recommends using a tiered administration model to separate high-risk end-user

devices from valuable assets like DCs and business applications. The model separates assets
into three tiers:

• Tier 0 is reserved for DCs, privileged accounts, and domains that have direct or indirect
administrative control of the AD forest

• Tier 1 is for application servers

An 8-Step Guide to Administering Windows without Domain Admin Privileges

 • Tier 2 is for end-user devices

Rules are used to prevent assets in lower tiers accessing devices in higher tiers. For example,
Tier 1 administrators can only log on interactively to Tier 1 trusted devices. Rules can be
enforced by using an appropriate Organizational Unit (OU) structure in AD and Group Policy.

PHASED APPROACH TO PRIVILEGE MANAGEMENT

Managing Windows without domain admin privileges is achievable for all sizes and types of
organization. But some of the technologies, such as PowerShell JEA, require more expertise.
Even if your IT staff lacks PowerShell expertise, you can take basic steps to significantly reduce
the attack surface of Active Directory (such as by restricting the use of privileged accounts) by
implementing processes outlined in this guide.

More complex mitigation techniques can be applied in a phased approach. And if the best
practices outlined in this guide are beyond the technical capabilities of your organization or
would prove inconvenient in practice, third-party Privilege Management Access solutions can
help secure Active Directory and your entire Windows estate.

While Microsoft offers these capabilities, implementing privilege management throughout an

enterprise can be challenging. Most companies don’t have the time, experience, or skill set to
set up, maintain, and customize these security practices. In addition, some of these Windows
functions assume that all assets are at the most current functional operating system levels.
And, while these administrative functions will work, IT admins may find themselves spending
substantial time trying to pull disparate data together to generate reports for auditing
purposes.

A more scalable approach to Windows security would be to utilize a solution designed

specifically for enterprise-wide privileged access management. The BeyondTrust
PowerBroker Privileged Access Management Platform is an integrated solution that
provides control and visibility over all privileged accounts, users, and activity. By uniting
capabilities that alternative providers offer as disjointed tools, the PowerBroker platform
simplifies deployments, reduces costs, improves system security, and reduces privilege risks.

An 8-Step Guide to Administering Windows without Domain Admin Privileges

POWERBROKER PRIVILEGED ACCESS MANAGEMENT PLATFORM

PowerBroker privileged access management solutions can augment and improve native
Microsoft processes for enabling privileged access and centralize all privileged access
management functions into a single console. Please see the table below for how
BeyondTrust can help.

8 STEPS TO ADMINISTERING WINDOWS WITHOUT DOMAIN

ADMIN PRIVILEGES
Windows Method for Securing Active
Directory
1. Enforce least privilege by limiting
privileged group membership
BeyondTrust PowerBroker Solution
Microsoft does not provide least privilege
functions to address all scenarios. And where
they do, these rights must be delegated to a
user account permanently. PowerBroker
elevates privileges for standard users on
Windows through fine-grained policy-based
controls that can be easily added or
removed .

2. Fine-grained user/privileged user account Setting up MIM and JIT can be complicated
management and require a configuration not available to

An 8-Step Guide to Administering Windows without Domain Admin Privileges

 Windows Method for Securing Active BeyondTrust PowerBroker Solution
Directory
all companies. PowerBroker elevates
privileges and delegates access to privileged
user accounts using fine-grained policy
management only when required. This
capability is available out of the box and does
not require providing a logon user with more
rights than they require.
3. Manage administrative access to end user PowerBroker secures and automates the
devices process for discovering, managing, and
4. Manage privileged access to servers cycling privileged account passwords across
all end-user devices. This capability allows for
a consistent security policy and auditing
platform throughout your enterprise without
exposing passwords in plain text.
5. Leverage PowerShell Just Enough Just Enough Administration can be
Administration complicated to set up and maintain, and not
all applications are PowerShell-enabled.
PowerBroker proactively identifies
applications and tasks that require
administrator privileges and automatically
generates rules for privilege elevation. This
capability allows admins to controls the
rights of applications, system tasks, etc.
easier and with a broader scope than what is
natively available.
6. Use privileged access management across PowerBroker provides privileged access
domain controllers across domain resources without granting
temporary or full administrative rights or
additional security group membership. This
allows you to provide the access that users
require without exposing the company to
additional risk — even on a temporary basis.
7. Enable WSUS and centralize events PowerBroker collects event logs related to
built-in tasks and updates without granting
admin privileges or requiring log in to
sensitive systems. This capability allows the
data collected to be used to further enhance
your overall security model.

An 8-Step Guide to Administering Windows without Domain Admin Privileges

 Windows Method for Securing Active
Directory
8. Enforce separation of administration
BeyondTrust PowerBroker Solution
PowerBroker enables separation of duties in
what administrators can do and/or what
rights are provided through role-based access
control, even on multi-purpose servers. This
functionality is important everywhere, and in
scenarios where you cannot separate out the
roles of an asset or server, becomes even
more critical to your security policy.

If you would like to review the security posture of your Active Directory, you can explore
different PAM solutions, get a Windows PAM consultation, or contact BeyondTrust to discuss
your privileged access management project.

ABOUT RUSSELL SMITH

Russell Smith specializes in the management and security of Microsoft-based IT systems. In
addition to a Contributing Editor at the Petri IT Knowledgebase – he is an instructor at
Pluralsight. Russell has more than 18 years of experience in IT, and has written a book on
Windows security, co-authored one for Microsoft’s Official Academic Course (MOAC) series,
and was a regular contributor at Windows IT Professional magazine.

Twitter: https://twitter.com/smithrussell

An 8-Step Guide to Administering Windows without Domain Admin Privileges