Академический Документы
Профессиональный Документы
Культура Документы
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.
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.
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.
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.
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.
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
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).
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.
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.
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.
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.
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.
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.
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.
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.
• Tier 0 is reserved for DCs, privileged accounts, and domains that have direct or indirect
administrative control of the AD forest
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.
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.
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.
2. Fine-grained user/privileged user account Setting up MIM and JIT can be complicated
management and require a configuration not available to
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.
Twitter: https://twitter.com/smithrussell