Modulul VII

MCT USE ONLY.
STUDENT USE PROHIBITED

7-1
Module 7
Securing Active Directory Domain Services
Contents:
Module Overview 7-1
Lesson 1: Securing domain controllers 7-2
Lesson 2: Implementing account security 7-15
Lesson 3: Implementing audit authentication 7-34
Lesson 4: Configuring managed service accounts 7-38
Lab: Securing AD DS 7-45
Module Review and Takeaways 7-54
Module Overview
In your organization’s information technology (IT) infrastructure, securing Active Directory Domain Services
(AD DS) domain controllers is a critical task. Domain controllers provide access to many different resources,
and they contain information about users and their passwords. If a single domain controller is
compromised, any objects in the same Active Directory domain or in any trusted domain are at risk of being
compromised, too.
The Windows Server 2016 operating system provides features and apps that you can use to help secure
your network against security threats. The operating system provides measures to secure domain
controllers by minimizing their attack surface and determining their domain-controller placements. The
operating system also determines the AD DS roles that are used for administration and design, and
implements password security, in addition to auditing when attacks occur. You also can use domain
controllers to deploy security measures to other clients and servers in your Windows-based infrastructure.
AD DS administrators must understand the threats to domain controllers and the methods that they can
use to secure AD DS and its domain controllers.
Objectives
After completing this module, you will be able to:
 Secure domain controllers.

 Implement account security.
 Implement audit authentication.
 Configure managed service accounts (MSAs).

MCT USE ONLY. STUDENT USE PROHIBITED
7-2 Securing Active Directory Domain Services
Lesson 1
Securing domain controllers
Your network’s domain controllers are the core of your AD DS infrastructure. They contain all of your user-
account information, and without them, users cannot sign in to the network or access the resources that
they need to perform their jobs. When user accounts are compromised, other accounts in the same domain
and any trusted domain also might be compromised. Therefore, securing your domain controllers is a
critical component in securing your entire IT infrastructure.
Lesson Objectives
After completing this lesson, you will be able to:
 Describe security risks that can affect domain controllers.
 Explain how to modify the security settings of domain controllers.
 Implement secure authentication.
 Secure physical access to domain controllers.
 Describe read-only domain controllers (RODCs).
 Deploy an RODC.
 Plan and configure RODC password replication policy.
 Configure a password replication policy.
 Describe role separation for RODC local administrators.
Security risks that can affect domain controllers

Before you define any security measures, you need
to determine against which threats you need to
protect your network. You need to define your
organization’s security boundaries, and you must
identify from where hackers or attackers might try
to compromise your security. For example, you will
need to secure your network against attacks from
outside your company. You also might have
regions, departments, or groups where you cannot
trust your organization’s employees in the same
way as you trust employees in a strictly controlled
environment, such as your main office. Do you
have administrative groups that you cannot trust? Do you have locations or departments that require a
higher level of security? All of these factors will have an impact on your security planning.
To secure your Active Directory domain and domain controllers, you need to address security in terms of
the following risks:
 Network security. An attacker must gain access to your network to get further information. Therefore,
you should ensure that network boundaries, such as firewalls and exposed services, are highly
protected. Also, you should ensure that your wireless networks are secured properly and do not allow
untrusted devices to connect to your internal network. Use certificates for wireless connections and
implement Network Access Protection (NAP) to secure network access.
Identity with Windows Server 2016 7-3
 Authentication attacks. Access to authentication credentials, such as user names and passwords, is the
primary target for anyone who tries to access your network and data. Active Directory domain
controllers store all information about all users and their passwords, and they need sufficient security to
protect this information.
 Elevation of privilege. While regular user credentials can access certain information, domain
administrators or other administrative groups have elevated privileges, giving those accounts control
over data. In many cases, administrators can grant themselves additional access to resources.
Additionally, they can configure security measures. If attackers can elevate the credentials they use by
putting their accounts into elevated groups in the same or trusted domains, they can lower security
and potentially bypass auditing or security safeguards.
 Denial of service (DoS) attack. A malicious user or users do not launch DoS attacks to access data, but
rather to disable services, systems, or whole infrastructures. Certain security measures, such as account
lockout policies, might be useful in protecting your network against some threats, but they also
provide an easily accessible DoS attack surface.
 Operating system, service, or app attacks. Network operating systems, in addition to services and apps
that support communication over networks, are vulnerable to security attacks. These systems provide
communication over a network, and attackers will try to trick the expected communications to make
these services do something differently than what was intended.
 Operational risks. It is important to maintain any organization’s infrastructure properly. Any kind of
software that operates over networks could be a potential target for attackers. To tighten security,
software and hardware vendors release updates regularly. Administrators need to keep their systems
up-to-date and remove or disable any unused user and computer accounts that are likely to have
unsecure passwords. Any permissions that are granted need to be verified and monitored regularly to
ensure that they do not leave a network vulnerable.
 Physical security threats. It is important for Active Directory domain controllers to be physically secure.
If someone gets physical access to a server, it is easier to disable security safeguards and run malicious
software locally to retrieve all passwords in a domain.
Modifying the security settings of domain controllers

An Active Directory domain usually includes
multiple domain controllers. To ensure that all
security settings apply consistently to all domain
controllers, you should configure security settings
for Active Directory domain controllers centrally.
To do this, use the Default Domain Controllers
Group Policy Object (GPO), or create a new,
custom GPO that is linked to the Domain
Controllers organizational unit (OU). You create all
domain-controller computer accounts in this OU,
and you should not move them out of this OU,
because they will fall out of the Default Domain
Controllers Policy scope.
Some organizations prefer to use a different GPO than the Default Domain Controllers Policy. When
configuring security settings, it is possible to apply settings that might be too secure. For example, you
could configure policies that lock out some administrative groups, or policies that prevent anyone from
accessing the domain. While it is simple to unlink or disable a custom GPO, you should not disable or unlink
the Default Domain Controllers Policy. For this reason, we recommend that you create a custom GPO and
link it to the Domain Controllers OU instead of modifying the Default Domain Controllers Policy.
Default Domain Policy vs. Default Domain Controllers Policy

There are two default GPOs, the Default Domain Policy and the Default Domain Controllers Policy, and it is
essential to understand the differences between the two:
 Default Domain Policy GPO. This GPO links to the domain, and it applies to all users and computers,
including client computers, domain controllers, and servers in the domain. You should use this policy
and others that link to a domain carefully. This policy should contain only settings that are explicitly
intended to apply to all objects in an organization.
 Default Domain Controllers GPO. This GPO links to the Domain Controllers OU, and it applies to all
domain controllers in the domain. This is the GPO in which you configure most security settings that
pertain to domain controllers.
Security settings in the GPO

The following are some of the most important security settings that you can configure in a GPO. You can
find the Security Settings in any GPO under Computer Configuration\Policies\Windows Settings:
 Account Policies. Under this node, you can configure the Password Policy, Account Lockout Policy,
and Kerberos Policy. These settings only apply to the local user accounts of the computers to which the
policy applies, unless you configure the settings in the Default Domain Policy. Only the Account
Policies that you configure in the Default Domain Policy apply to all domain accounts.
 Local Policies. This node contains three of the most important nodes for security configuration:
o Audit Policy. These settings configure legacy-auditing policies that apply to all Windows
operating-system versions. However, if you have Windows Server 2008 R2 and Windows 7 or
newer deployed in your network, we recommend that you use Advanced Audit Policy
Configuration instead of these auditing policies.
o User Rights Assignment. These settings configure many security settings that apply to user
rights. For example, you can specify who can access the computer from the network, who can sign
in locally or through Remote Desktop Services (RDS), and who is able to change the time or shut
down the computer. For domain controllers, you also can specify who is able to synchronize
directory services data.
o Security Options. These settings contain important security settings, including options for
managing default accounts, such as the Guest and Administrator accounts, and these options also
pertain to managing devices, domain controllers, domain-member security protocols, logon
security settings, network access, and security settings, among others.
 Event Log. Under this node, you can configure settings such as event log size, retention method, and
retention duration for the default Application, Security, and System event logs. It is important to have
all Security logs on domain controllers configured identically. If you configure the Security log on one
domain controller to keep logs for six days, and another retains logs for only three days, you will
receive inconsistent results, depending on the domain controller on which you perform the search.
 Restricted Groups. Under this node, you can define two properties for security-sensitive groups (or
restricted groups). For each group that you add here, you can define Members and Member of
attributes. For groups that you configure as restricted, you cannot change membership by using other
tools, such as Active Directory Users and Computers.
 System Services. Under this node, you can define startup behavior and security permissions for system
services by using GPOs. This enables you to disable all services that are not required for a specific server
role, such as a domain controller.
 Windows Firewall with Advanced Security. This setting allows you to administer Windows Firewall
with advanced security centrally. By using a GPO to configure Windows Firewall settings, you can
ensure that all servers that provide the same services, such as domain controllers, have a consistent
Windows Firewall configuration.
 Public Key Policies. Under this node, you configure settings that rely on a public key infrastructure
(PKI), such as the Encrypting File System (EFS) and its recovery key, BitLocker Drive Encryption,
Automatic Certificate Request Settings (autoenrollment), and Trusted Root Certification Authorities,
among others.
 Advanced Audit Policy Configuration. The settings under this node enable a more extensive policy
configuration than the Audit Policy under the Local Policies node. When targeting Windows
Server 2008 R2 or newer, or Windows 7 computers or newer, we recommend that you use the new
Advanced Audit Policy Configuration settings.
Implementing secure authentication

Having a secure authentication process is one of
the most important security components of your
domain environment, and you should consider the
following factors when implementing secure
authentication:
 Secure user accounts and passwords. It is very

important to secure user accounts and
passwords. You do this by configuring and
utilizing technical components, such as
configuring password and account policies,
and also by educating your users about how
to create and use complex and lengthy
passwords. If your apps support lengthy passwords, teach users how to use passphrases to replace
passwords.
 Secure groups with elevated permissions. Every organization has groups with elevated permissions.
These groups include the Domain Admins, Schema Admins, and Enterprise Admins groups.
Implementing secure management processes for these groups is important. For example, you might
limit who knows the passwords for members of these groups, and ensure that all administrators have
special administrative accounts and that they sign in only with those accounts when performing
administrative tasks. For these groups, you can also use the Restricted Groups setting in Group Policy,
which a later section of this module details.
 Audit critical object changes. To track any changes to critical administrative groups, such as built-in
accounts, built-in groups, and especially groups with elevated permissions, configure your auditing
policy to track all changes made to these groups. If possible, ensure that only members of an auditing
team have access to the audited events, which prevents administrators from deleting events.
 Deploy secure authentication. Two-factor authentication is the key to achieve heightened security,
beyond regular user name and password credentials. It is common to use smart cards to secure
authentication or implement multi-factor authentication with mobile phones. Smart cards have a
stored certificate that acts as a user’s credentials for signing in, rather than a user name and password.
To authenticate by using a smart card, you must possess the smart card, and you must have the
personal identification number (PIN) or password to unlock the private key. The combination of the
public key, known to the domain controller, and the private key on the smart card, enables the domain
controller to authenticate the user. You also can enforce the use of smart cards if users want to access
additional apps and across RDS. If you use smartphones as a second factor for authentication, you can
require users to use the application, text message, or phone to prove their identity.
 Secure network activity. Securing your network is necessary when trying to achieve a secure
client/server infrastructure. If your organization supports wireless networks, ensure that all networks
with access to your organization’s servers are secure, preferably by using certificates. If required,
provide public or guest networks to allow customers, partners, or other nonemployees to have Internet
access, rather than allowing them access to the corporate network. For your wired networks, consider
device health attestation to prevent unknown devices from connecting to your network. For critical
servers that host highly confidential information, consider enforcing Internet Protocol security (IPsec)
signatures or encryption to secure network communication.
 Establish deprovisioning and cleanup processes. Basically, provisioning empowers a new employee by
creating their account, group memberships, mailbox, and other components that they need to work in
your organization. Although provisioning is important, you should remember that the often-forgotten
deprovisioning is even more important. You must define and establish processes for employees who
resign voluntarily, and more important, involuntarily. Also, consider other reasons an employee might
take leave, such as parental leave or sabbatical leave. Define what type of access, if any, is necessary.
Additionally, you should decide whether to deactivate accounts, delete accounts, or remove accounts
from certain groups, such as general distribution lists or critical human resources (HR) apps, and decide
whether to allow or prevent access by users who are outside your organization’s network.
A cleanup process also is necessary for domain members, such as for client computers, because they
also are allowed to authenticate against the domain, and a malicious user may utilize their credentials
to compromise a network. Furthermore, ensure that there are no client computers or users that were
created, but which have not been used to connect to the domain. This is because their passwords are
default, well-known passwords, which a malicious user might discover and utilize.
 Secure client computers. If you want to secure your AD DS and Active Directory domain controllers,
you must secure your client computers. Client computers cache the last 10 logons, by default.
Therefore, if a client computer is lost, you need to have a process by which you track accounts that
signed in within the password-change interval, and you need to know how to reset passwords after a
loss is reported. You also need to protect your internal network from client computers that connect
from wired or wireless networks from homes, hotels, or airports. To protect client computers, ensure
that client computers have all security updates installed, that they have current virus protection and a
host-based firewall, and consider using drive encryption such as BitLocker drive encryption.
Securing physical access to domain controllers

The physical security of domain controllers is
critically important. Domain controllers contain all
of the credentials in your organization’s Active
Directory domain. If attackers achieve physical
access to your domain controllers, they can bypass
almost any safeguards that you have. They then
can access most passwords quickly, and they can
use this information to attack your network.
Therefore, you should do the following steps to

further secure your Active Directory domain
controllers, including that you:
 Only deploy domain controllers where you

can ensure physical security. If your server locations do not have dedicated rooms with access control,
do not put a domain controller in that environment.
 Use RODCs, where possible. You can use RODCs as domain controllers in locations with less physical
security because, by default, RODCs do not store secrets such as account passwords. A later section of
this lesson details RODCs.
 Use BitLocker drive encryption. To provide an extra level of security, consider encrypting domain-
controller hard drives by using BitLocker. This prevents attackers from accessing the data on server
hard drives if they are removed from the servers. Windows Server 2016 supports using BitLocker on
volumes that store AD DS databases. However, it does not support the use of EFS to protect AD DS
database files.
 Monitor hot-swap disk systems. Usually, servers deploy with hot-swap disk systems, which enable you
to change a drive, without server interruption, when a hardware failure occurs. If you have Redundant
Array of Independent Disks (RAID) Level 1 mirroring in your servers, you should ensure that you have
monitoring in place, so you are aware if any disks are removed or exchanged. Otherwise, it is simple to
remove, and possibly replace, a drive from your domain controller. If someone possesses your domain
controller’s hard drive, he or she has the same ability to exploit the system as they would if they had the
whole domain controller.
 Protect virtual disks. Many organizations deploy domain controllers as virtual machines. The virtual
disks used by virtual machines must be as secure as physical disks, and the administrators of your
virtual infrastructure must be as trusted as your Domain Admins. Sometimes, running a dedicated
virtual infrastructure for critical components such as domain controllers addresses these risks.
 Store backups in secure locations. Your domain-controller backups contain all of the same information
as domain controllers. Make sure that backups are stored in secure locations, which only trusted
administrators can access.
What are RODCs?

Branch offices present a unique challenge for an
organization’s IT staff. Branch offices usually are
smaller sites in which no datacenter exists.
Additionally, branch offices might not have a
secure facility in which to house servers, and there
might be few, if any, local IT staff to support the
servers. If a wide area network (WAN) link
separates a branch office from your hub site,
depending on the number of users and the
services that are available in the branch office, you
must decide whether to place a domain controller
in the branch office. AD DS in Windows
Server 2008 and newer versions support a new type of domain controller, a read-only domain controller or
RODC, which deploys in this type of environment.
Reasons for deploying RODCs

If you do not deploy a domain controller in a branch office, you must use a WAN link to direct
authentication and service-ticket activities to the hub site. When a user first tries to access a specific service,
the user’s client requests a service ticket from a domain controller. Users typically connect to multiple
services during a workday, so service-ticket activity happens regularly. Authentication and service ticket
activity over a WAN link between a branch office and a hub site can result in slow or unreliable
performance.
If you place a domain controller in a branch office, authentication occurs more efficiently. However, there
are several potentially significant concerns, which include:
 A domain controller maintains a copy of all object’s attributes in its domain, including secure
information, such as user passwords. If a hacker accesses or steals a domain controller, or its hard drive
or backup drive, a determined malicious user could identify valid user names and passwords. At that
point, your entire domain is compromised, and you would have to reset passwords for every user and
computer account in the domain. Server security at branch offices often is not ideal, so a branch-office
domain controller poses a considerable security risk.
 Changes to the Active Directory database on a branch-office domain controller replicate to the hub
site and to the environment’s other domain controllers. Therefore, corruption to a branch-office
domain controller poses a risk to the integrity of the organization’s AD DS. For example, a branch office
administrator who performs a restoration of the domain controller from an outdated backup could
cause significant repercussions for the entire domain.
 A branch-office domain controller might require maintenance, such as the installation of new device
drivers. To perform maintenance on a standard domain controller, you must sign in as a member of the
Administrators group, which means that you effectively are an administrator of the domain. It might
not be appropriate to grant that level of capability to a branch-office support team.
These concerns can leave organizations with a difficult decision. For this reason, Microsoft introduced the
RODC, which addresses the branch-office scenario. An RODC is a domain controller that maintains a copy
of all objects and attributes in the domain, except for secure information such as password-related
properties. If you do not configure caching, an RODC receives sign-in requests from branch office users and
forwards them to a domain controller in the hub site for authentication.
You can configure a password replication policy for an RODC that specifies the user and computer accounts
for which passwords might be cached on the RODC. If any user signs in by using an RODC, the RODC
requests that user’s credentials from a full domain controller. When the user is a member of the password
replication policy that applies to an RODC, the RODC can retrieve the password, and the full domain
controller allows the replication of the secret. This means that the next time the user requests
authentication from the same RODC, the RODC can perform the task locally. While users who are included
in the password replication policy sign in, the RODC builds its cache of credentials so that it can perform
authentication locally for those users. Normally, you add users and computers to the password replication
policy who are in the same physical site as the RODC.
Because RODCs maintain only a subset of user credentials, security exposure is limited if an RODC is
compromised or stolen. If an RODC is compromised, only the user and computer accounts that the RODC
cached must have their passwords reset.
The RODC replication process also enhances security. An RODC replicates changes to AD DS from writable
domain controllers, but it does not replicate any data to other domain controllers. This eliminates the
exposure of Active Directory services to corruption because of changes made to a compromised branch-
office domain controller. Finally, RODCs have the equivalent of a local Administrators group. You can give
one or more local support personnel the ability to maintain an RODC fully without granting them the
equivalent Domain Admins rights.
RODC limitations and considerations

To reduce security risks and administrative costs, some domain controller options that are available for
writable domain controllers are not available on RODCs. Before you decide to deploy an RODC, you should
be aware of the following limitations and considerations:
 RODCs cannot be operations master role holders. Operations master role holders must be able to write
information to the Active Directory database. Because of the read-only nature of the RODC’s Active
Directory database, it cannot act as an operations master role holder.
 RODCs cannot be bridgehead servers. Bridgehead servers specifically replicate changes from other
sites. RODCs perform only inbound replication, so they cannot act as a bridgehead server for a site.
 You should have only one RODC per site, per domain. If you have multiple RODCs, the behavior of
caching is inconsistent because shared secrets are only cached if a user signs in to that specific RODC. It
is likely that one RODC has the shared secrets and another RODC in the same site does not have them
at all.
 RODCs cannot authenticate across trusts when a WAN connection is not available. If your users and
computers are in different domains, they cannot perform logons when the branch site uses RODCs and
is disconnected from the hub site.
 Because AD DS changes cannot be written directly to an RODC, no replication changes originate at an

RODC. This means that any changes or corruption that a hacker might make at branch locations cannot
replicate from the RODC to the forest. This also reduces the workload of the hub’s bridgehead servers
and the effort required to monitor replication. RODC’s unidirectional replication applies to both AD DS
and Distributed File System (DFS) replication.
 RODCs cannot support any app properly that needs to update AD DS interactively, such as Microsoft
Exchange Server. If you are going to deploy Exchange Server or similar apps at a site, you also should
deploy a writable domain controller. Further, if you deploy Exchange Server at a site, you also should
have a physically secure location for your servers.
 You can install the Domain Name System (DNS) server service on RODCs. RODCs can replicate all app
directory partitions that DNS uses, including ForestDnsZones and DomainDnsZones. If you install a
DNS server on an RODC, clients can query it for name resolution just as they would query any other
DNS server. Similar to the AD DS information on an RODC, the DNS zone information on an RODC is
read-only, and therefore, it does not support client updates directly. When client computers try to
register a resource record in a DNS zone hosted on an RODC, the RODC returns the name of a full
domain controller that contains a writable copy of that zone to the client. The client uses the full
domain controller to register the record.
Deploying an RODC
Before deploying an RODC in your Windows
Server 2016-based AD DS, you must:
 Run ADPrep /RODCPrep if you have

upgraded your domain from Windows Server
2003 or older versions.
 Ensure that you have a sufficient number of

domain controllers to support your RODCs.
RODCs need Windows Server 2008 or newer
writable domain controllers as replication
partners.
 Note that if you are using Windows
Server 2012 or newer as writable domain controllers, you do not have additional prerequisites for
RODCs.
After completing the preparatory steps, you can install an RODC. An RODC can be a full or Server Core
installation of Windows Server 2016. You can perform an RODC installation in one step or in two steps by
prestaging the account.
Installing an RODC in one step

You can use the Active Directory Domain Services Configuration Wizard, even remotely, in Server
Manager to create an RODC. On the Additional Domain Controller Options page of the wizard, you only
have to click RODC.
Alternatively, you can use the Install-ADDSDomainController cmdlet with the –ReadOnlyReplica switch
to install an RODC.
On a Server Core installation of Windows Server 2016, we recommend that you use Server Manager
remotely or to use the Install-ADDSDomainController Windows PowerShell command-line interface
cmdlet remotely by using the Invoke-Command cmdlet.
Installing an RODC in two steps: prestaging and delegated promotion

You can complete the installation of an RODC in two stages; a different individual performs each stage. The
first stage of the installation creates an account for an RODC in AD DS. The second stage of the installation
attaches the actual server that will be the RODC to the account that was created for it previously. You can
delegate the ability to attach the server to a non-administrative group or a user, such as a delegated branch
office administrator.
During the first stage, the Active Directory Domain Services Configuration Wizard records all of the
data about the RODC, such as its domain-controller account name and the site in which it will be placed.
The distributed Active Directory database stores this information. A member of the Domain Admins group
must perform this stage of the installation.
The administrator who creates the RODC account also can specify which users or groups can complete the
next stage of the installation. Any user or group in the branch office who was delegated the right to
complete the installation can perform the next stage. This stage does not require any membership in built-
in groups, such as the Domain Admins group. If the user who creates the RODC account does not specify
any delegate to complete the installation and administer the RODC, only a member of the Domain Admins
or Enterprise Admins groups can complete the installation.
You can perform a staged installation of an RODC by using several approaches. You can precreate an RODC
account by using Active Directory Administrative Center, which is appropriate for a small number of
accounts. You also can use the Add-ADDSReadOnlyDomainControllerAccount cmdlet with appropriate
switches.
Planning and configuring an RODC password replication policy

A password replication policy determines which
users’ or computers’ credentials that a specific
RODC caches. If a password replication policy
allows an RODC to cache a user's credentials, the
RODC can process that user’s authentication and
service-ticket activities. If an RODC cannot cache a
user's credentials, the RODC refers the
authentication and service-ticket activities to a
writable domain controller.
Two multivalued attributes of the RODC's

computer account determine the password
replication policy of an RODC. These attributes are
the allowed list and the denied list. If a user's account is on the allowed list, the RODC caches the user's
credentials. You can include groups on the allowed list, in which case the RODC caches all users who belong
to the group. If a user is on both the allowed list and the denied list, the user's credentials are not cached—
the denied list takes precedence.
Domain-wide password replication policy

To facilitate the management of your password replication policy, Windows Server 2008 or newer
operating systems create two domain local security groups in the Users container within AD DS:
 Allowed RODC Password Replication Group. Members of this group are included in the allowed list of
each new RODC. By default, the group has no members. Therefore, by default, a new RODC does not
cache any user’s credentials. You should add users for whom you want all domain RODCs to cache
credentials to the Allowed RODC Password Replication Group.
 Denied RODC Password Replication Group. Members of this group are included in the denied list of
each new RODC. You should add users whose credentials you want to ensure are never cached by
domain RODCs to the Denied RODC Password Replication Group. By default, this group contains
security-sensitive accounts that are members of groups including Domain Admins, Enterprise Admins,
and Group Policy Creator Owners.
Note: Users are not the only generators of authentication and service-ticket activity.
Computers in a branch office also require such activity. To improve system performance and to
ensure that computers can establish a secure channel with a domain controller in a branch office,
also allow the branch RODC to cache computer credentials. During a WAN outage, be aware that
users are only able to sign in when both the computer’s and the user’s credentials are cached.
RODC-specific password replication policy

These two groups allow you to manage password replication policy on all RODCs. However, to best support
a branch-office scenario, you need to allow the RODC in each branch office to cache user and computer
credentials in that specific location. Therefore, while you can use the global denied list, you should
configure a specific allowed list for each RODC.
RODC filtered attribute set

Some apps that use AD DS as a data store might use credential-like data, such as passwords, credentials,
and encryption keys, which you do not want to store on an RODC, in case it becomes compromised. For
these apps, you can configure a schema attribute set that will not replicate to an RODC. This set of
attributes is the RODC filtered attribute set. Attributes that you define in the RODC filtered attribute set
cannot replicate to any RODCs in the forest. You cannot add system-critical attributes to the RODC filtered
attribute set. An attribute is system-critical if the following require it to function properly:
 AD DS
 Local Security Authority

 Security Accounts Manager
 Microsoft-specific Security Support Provider Interfaces, such as Kerberos version 5 protocol
If you have apps that you want to use the RODC filtered attribute set, you have to verify with the app
vendor if they support it. While write-requests to an RODC receive referrals to a full domain controller, apps
that ask an RODC for an attribute in the RODC filtered attribute set receive it as empty. RODC knows about
the attribute but never receives a value for it. The app must be aware of this feature and know to request a
writable domain controller when reading the RODC filtered attribute set.
Demonstration: Configuring a password replication policy

In this demonstration, you will see how to:
 Stage a delegated installation of an RODC.
 View an RODC’s password replication policy.
 Configure an RODC-specific password replication policy.
 Verify the resultant password policy.
Demonstration Steps
Stage a delegated installation of an RODC

1. On LON-DC1, from Server Manager, open Active Directory Sites and Services, create a new site
named Munich, and then assign it to the DEFAULTIPSITELINK.
2. Start Active Directory Administrative Center, and then navigate to the Domain Controllers OU.
3. Precreate an RODC account with the name MUC-RODC1, which also should be a DNS server and a
Global catalog.
4. Delegate Bill Norman to install and administer the RODC.
5. Finish the precreation of the RODC account.

View an RODC’s password replication policy

1. In Active Directory Administrative Center, in the Domain Controllers OU, open the properties of
the MUC-RODC1 computer account.
2. In the Extensions section, select the Password Replication Policy tab, and then note its settings.
Configure an RODC-specific password replication policy

1. Switch to Server Manager, and from the Tools menu, start Active Directory Users and Computers.
2. Navigate to the Users container, and then create a new group named Munich Allowed RODC
Password Replication Group.
3. Add Ana Cantrell to the new group.
4. Switch to Active Directory Administrative Center and then open the properties of MUC-RODC1.
5. In the Extensions section, on the Password Replication Policy tab, configure the Munich Allowed
RODC Password Replication Group to allow password replication, and then close the properties of
MUC-RODC1.
Verify the resultant password policy

1. In Active Directory Administrative Center, open the properties of MUC-RODC1, and then in the
Extensions section, on the Password Replication Policy tab, click Advanced.
2. Note that this dialog box displays all accounts whose passwords are stored in the RODC.
3. Select Accounts that have been authenticated to this Read-only Domain Controller, and then
note that this page only shows accounts that have the requisite permissions and that the RODC has
authenticated.
4. Select the Resultant Policy tab, and then add Ana Cantrell. Note that Ana has a Resultant Setting of
Allow.
5. Close all open dialog boxes.
Separating RODC local administration

RODCs in branch offices might require
maintenance, such as updates to device drivers.
Additionally, small branch offices might combine
the RODC role with a file-server role on a single
system. In this scenario, it will be important to back
up the system. RODCs support local administration
by using the administrator role separation feature.
With this feature, you can delegate any domain
user or security group as a RODC’s local
administrator, without granting that user or group
rights to the domain or other domain controllers.
Therefore, a delegated administrator can sign in to
an RODC to perform maintenance work, such as upgrading a driver on the server. However, the delegated
administrator cannot sign in to any other domain controller or perform any other administrative task in the
domain.
Each RODC maintains a local database of groups for specific administrative purposes. You can add a
domain user account to these local roles to allow support of a specific RODC.
You can configure the delegated administrators for an RODC when you precreate an RODC computer
account or when you install the RODC. You can add a user or group on the Delegation of RODC
Installation and Administration page in the Active Directory Domain Services Installation Wizard.
You also can add the user or group account on the Managed By tab of the RODC account properties in
Active Directory Users and Computers.
Question: How can you provide extra security for hard drives in domain controllers?
Lesson 2
Implementing account security
As an administrator, you must make sure that user accounts in your environment conform to the security
standards set by your organization. To achieve this, Window Server 2016 allows you to use account policies
to configure security-related settings for user accounts. Additionally, with Windows Server 2016, you can
configure additional security with protected groups, authentication policies, and authentication policy silos.
This lesson explains the settings that are available for account security and the methods to configure those
settings.
Lesson Objectives
 Describe account security in Windows Server 2016.
 Describe password policies.

 Describe account lockout policies.
 Describe Kerberos policies.
 Configure domain account policies.
 Describe how to protect groups in AD DS.
 Describe fine-grained password and lockout policies.
 Describe Password Settings objects (PSOs).

 Configure a fine-grained password policy.
 Describe PSO precedence and resultant PSO.
 Explain account-security options in Windows Server 2016.
 Configure user account policies.
 Describe how to enhance password authentication with Windows Hello and the Microsoft Azure Multi-
Factor Authentication (MFA) service.
Account security in Windows Server 2016

In any authentication-based network, it is critically
important to secure account credentials, such as
user names and passwords. To achieve account
security, Windows Server 2016 provides multiple
options, including:
 Password policies to configure multiple

requirements, such as password age, length,
and complexity, which users’ passwords must
meet.
 Account lockout policies that enable you to

configure that an account must lock when the
wrong passwords are entered.
 Fine-grained password policies that provide the ability to specify different password policies and
account lockout policies for different groups of users, such as executives, administrators, service
accounts, or regular users.
 Protected users, which enables you to specify critical accounts that should be additionally secured.
 Authentication policies and authentication policy silos that provide you the ability to use claim-based
rules to specify which users are able to sign in to which computers.
 Kerberos policies that determine Kerberos-related settings, such as ticket lifetimes and enforcement.
This lesson explains these options in further detail.
Password policies
Account policies in AD DS define the default
settings for security-related attributes that are
assigned to user objects. In AD DS, account
policies classify into three different groups of
settings: password policy, account lockout, and
Kerberos policy. You can configure password
policy and account lockout settings in the local
policy settings for an individual Windows
Server 2016 server, or you can configure all three
groups of settings for the entire domain by using
the Group Policy Management console in AD DS.
When local policy settings and Group Policy
settings conflict, Group Policy settings override local policy settings.
In Group Policy Management within AD DS, most policy settings can apply at different levels within the
AD DS structure: domain, site, or OU. However, account policies for domain accounts can apply only at one
level in AD DS—to the entire domain. Therefore, only one set of account policy settings can apply to an
AD DS domain.
The password policy is one of the most important policies when securing your AD DS user accounts. Use the
password policy to configure the properties of the passwords that users might choose. You use these
settings to ensure that users cannot use simple passwords, which provide insufficient protection against
password attacks.
You define the password policy by using the following settings:
 Enforce password history. This is the number of unique, new passwords that must be associated with
a user account before an old password can be reused. The default setting is 24 previous passwords.
When you use this setting with the minimum password age setting, the enforced password history
setting prevents constant reuse of the same password.
 Maximum password age. This is the number of days that a user can utilize a password before they
must change it. Regularly changing passwords helps prevent the compromise of passwords. However,
you must balance this security consideration against the logistical considerations that result from
requiring users to change passwords too often. The default setting of 42 days is appropriate for most
organizations.
 Minimum password age. This is the number of days that a password must be used before the user
can change it. The default value is one day, which is appropriate if you also enforced password history.
You can restrict the constant use of the same password if you use this setting with the enforced
password history setting.
 Minimum password length. This is the minimum number of characters that a user’s password must
contain. The default value is seven. This default is a widely used minimum, but you should consider
increasing the password length to at least 10 characters to enhance security.
 Complexity requirements. Windows Server includes a default password filter that is enabled by
default, and you should not disable it. The filter requires that a password have the following
characteristics:
o Does not contain your name or your user name
o Contains at least six characters

o Contains characters from three of the following four groups:
 Uppercase letters [A–Z]
 Lowercase letters [a–z]
 Numerals [0–9]
 Special, non-alphanumeric characters, such as !@#)(*&^%
Account lockout policies

In addition to password policies, most
organizations configure account lockout policies.
While password policies specify that users need to
use secure passwords, account lockout policies
enable you to define whether accounts should be
locked if there are too many sign-in attempts with
invalid passwords.
You can define thresholds for an account lockout,

the duration of the lockout, and a way to unlock
accounts. Thresholds for an account lockout
stipulate that accounts become inoperable after a
certain number of failed sign-in attempts during a
certain time period. Account lockout policies help detect and prevent brute-force attacks on account
passwords. The following settings are available:
 Account lockout duration. Defines the number of minutes that a locked account remains locked.
After the specified number of minutes, the account unlocks automatically. To specify that an
administrator must unlock the account, set the value to 0. Consider using fine-grained password
policies to require administrators to unlock high-security accounts, and then configure this setting to
30 minutes for normal users.
 Account lockout threshold. Determines the number of failed sign-in attempts that are allowed
before a user account is locked out. A value of 0 means that the account is never locked out. You
should set this value high enough to allow for mistyped passwords, but low enough to ensure the
failure of brute force attempts to guess a password. Common values for this setting range from three
through five.
 Reset account lockout counter after. Determines how many minutes must elapse after a failed sign-
in attempt before the sign-in counter is reset to 0. This setting applies when a user has typed in a
password incorrectly, but the user has not exceeded the account lockout threshold. Consider setting
this value to 30 minutes.
Most organizations implement account lockout policies to prevent attackers from using password-guessing
techniques to gain access to a network. Although this approach provides a level of security, it also exposes
your organization to a DoS attack because attackers can run scripts to guess user passwords and lock out all
user accounts. This prevents the correct person from being able to access his or her account. If you choose
not to implement account lockout policies, it is critical that you monitor failed sign-in attempts in real time
to prevent attackers from taking advantage of this configuration.
Kerberos policies
You deploy Kerberos policy settings for the entire
domain from the Default Domain Policy. This
policy is for domain user and computer accounts,
and determines Kerberos-related settings such as
ticket lifetimes and enforcement. Kerberos policies
do not exist in the Local Computer Policy.
The Kerberos Policy configuration options contain
settings for the Kerberos v5 authentication
protocol ticket-granting ticket (TGT), the session
ticket lifetimes, and time-stamp settings. For most
organizations, the default settings are appropriate.
You will find the Kerberos policy in the Group
Policy Object Editor in the Account Policy section of the Computer Configuration node, Security
Settings page, under the Password and Account Lockout policies.
Kerberos is an authentication protocol that issues identity tickets, which allow entities to prove who they are
to other entities in a secure manner. Kerberos has several unique advantages as an authentication protocol.
It has the ability to provide delegated authentication by allowing Windows operating system services to
impersonate a client computer when accessing resources for it. Kerberos provides single sign-on for
domain users and computers by issuing TGTs that they can trade for session tickets to access specific server
sessions. Kerberos has expansive interoperability with other networking components because Kerberos is
part of the TCP/IP suite of nonproprietary protocols. Kerberos provides a more efficient authentication with
servers because you use Kerberos session tickets presented by user-level services for approved access to
server resources. Finally, Kerberos delivers mutual authentication because the server presents its credentials
back to the user-level services.
Kerberos policy
You can use the Kerberos policy in a GPO to enforce user sign in restrictions and to define thresholds for
maximum service and user ticket lifetime, maximum user ticket renewal lifetime, and the maximum time
computer clocks can be out of synchronization. The following settings are available:
 Enforce user logon restrictions. Determines if the Kerberos v5 Key Distribution Center (KDC) will
validate every session ticket request against the user account’s user rights policy. This can add extra
security, but it is not required. Choosing to enforce user logon restrictions can slow down services’
access to network resources. This setting is enabled by default.
 Maximum lifetime for service ticket. Defines the maximum time a service ticket is valid for
authenticating client access to a particular service. If the service ticket expires before the client requests
the server connection, the server will respond with an error and the client redirects requests back to the
KDC to receive a new service ticket. This maximum lifetime must be at least 10 minutes but not greater
than the maximum lifetime for a user ticket. By default, the maximum service-ticket lifetime is 600
minutes, or 10 hours.
 Maximum lifetime for user ticket. Sets the amount of time a user account’s TGT is valid. The default
is 10 hours.
 Maximum lifetime for user ticket renewal. Sets the amount of time, in days, for which the user
account’s TGT can be renewed. The default is seven days.
 Maximum tolerance for computer clock synchronization. Determines the amount of time that
client computers' clocks can be out of sync with the domain controller. The primary domain controller
(PDC) emulator operation master role on a domain determines the correct time for the entire domain.
The domain replication packets of TGT and service tickets are time stamped and the times on the
various tickets and packets are verified between correspondent computers. However, it is possible for
any two computers to be out of sync on their clocks. Administrators can set the amount of time by
which the clocks can be out of sync. The default for this setting is five minutes.
You can create access control based on claims and compound authentication by deploying Dynamic Access
Control (DAC). You must ensure that you have sufficient Windows Server 2008 or newer domain controllers
available that use these new authorization types. The KDC administrative template policy setting allows
you to configure a domain controller to support claims and compound authentication for DAC and
Kerberos armoring. Additionally, Windows Server 2012 or newer domain controller is required for Kerberos
clients running the Windows 10, Windows 8.1, or Windows 8 operating systems to support claims and
compound authentication by using Kerberos authentication.
Note: Devices that are running Windows 8 and newer operating systems will fail
authentication if they cannot find a domain controller that is running Windows Server 2012 or
newer. You must ensure that there are sufficient domain controllers that are running Windows
Server 2012 or newer for any account, referral, and resource domains that are supported.
Demonstration: Configuring domain account policies

In this demonstration, you will see how to configure a domain-based password policy and an account
lockout policy.
Demonstration Steps
Configure a domain-based password policy

1. On LON-DC1, from Server Manager, open the Group Policy Management console.
2. Edit the Default Domain Policy, and then configure the following account password policy settings:
o Password history: 20 passwords
o Maximum password age: 45 days
o Minimum password age: 1 day
o Password length: 10 characters

o Complexity enabled: Yes
Configure an account lockout policy

1. In the Group Policy Management Editor window, configure the following account lockout policy
settings for the Default Domain Policy:
o Account lockout duration: 30 minutes
o Account lockout threshold: 5 attempts
o Reset account lockout counter after: 15 minutes
2. Close the Group Policy Management Editor window and the Group Policy Management console.
Protecting groups in AD DS
In most AD DS deployments, some security groups
are considered as security critical. Windows Server
2016 provides the Restricted Groups feature and
the Protected Users security groups feature to
provide additional protection for these groups.
Restricted groups
For security-critical local groups on servers or
workstations, you can use the Restricted Groups
functionality available in Group Policy to control
membership in these groups and membership of
these groups.
Restricted Groups allow you to select a local security group and define two attributes: Members and
Member of.
When defining the Members attribute, you specify who should and should not belong to the restricted
group being configured. When you configure the Members attribute, any current member of a restricted
group that is not listed as member is removed automatically, with the exception of the administrator in the
Administrators group. Additionally, any user that is listed as member, who is not currently a member of the
restricted group, is added automatically.
When you use the Member of attribute of a restricted group, make sure that the restricted group is a
member of groups that are listed in the Member Of text box. You cannot use this attribute to remove the
restricted group from any other group.
To configure Restricted Groups, open Group Policy Management Editor and navigate to the
Computer Configuration\Policies\Windows Settings\Security Settings node.
An example of when you might want to use Restricted Groups is if you want to control membership in the
local Administrator group on your organization’s workstations.
Note: You cannot use this feature to manage domain groups in AD DS. You must use the
Restricted Groups feature only with local groups on client or server computers.
Protected Users security groups

Windows Server 2012 R2 introduced the Protected Users security group, which generates nonconfigurable
protection on:
 Devices and computers that are running Windows Server 2012 R2 and Windows 8.1 or newer operating
systems.
 Domain controllers in domains with a primary domain controller that are running Windows
Server 2012 R2 or newer.
This substantially reduces the memory footprint of credentials when users sign in to computers on the
network from an uncompromised computer. Consider the following points when using Protected Users
groups:
 The Protected Users group membership cannot authenticate by using NTLM, Digest authentication, or
Credential Security Support Provider (an authentication mechanism also known as CredSSP). On
devices running Windows 8.1 and newer, passwords are not cached, so the device that uses any one of
these Security Support Providers (SSPs) will fail to authenticate to a domain when the account is part of
the Protected User group.
 The Kerberos protocol will not use the weaker Data Encryption Standard (DES) or RC4 encryption types
in the preauthentication process. Therefore, you must configure the domain to support at least the
Advanced Encryption Standard (AES) cipher suite.
 You cannot delegate the user’s account with Kerberos constrained or unconstrained delegation. This
can cause former connections to other systems to fail if the user is in the Protected Users group.
 The default Kerberos TGTs lifetime setting of four hours is configurable by using Authentication
Policies and Silos, which you can access through the Active Directory Administrative Center. This
means that the user must authenticate again after four hours.
Fine-grained password and lockout policies

Starting with Windows Server 2008, administrators
can define more than one password policy in a
single domain by implementing fine-grained
password policies. These give you individual
control over user password requirements, and you
can have different password requirements for
different users or groups. This is beneficial for
enforcing more restrictive password settings for
administrators, service accounts, or users with
highly critical business functions.
To support the fine-grained password policy

feature, AD DS in Windows Server 2008 and newer
includes two object types:
 Password Settings Container. Windows Server creates this container by default, and you can view it in
the domain’s system container. The container stores the PSOs that you create and link to global
security groups or to users.
 PSOs. Members of the Domain Admins group create PSOs and then define specific password and
account lockout settings to link to a specific security group or user.
Fine-grained password policies only apply to user objects, InetOrgPerson objects, or global security
groups. By linking a PSO to a user or a group, you are modifying an attribute called msDS-PSOApplied,
which is empty by default. This approach now treats password and account lockout settings not as domain-
wide requirements, but as attributes of a specific user or a group. For example, to configure a strict
password policy for administrative accounts, create a global security group, add the administrative user
accounts as members, and then link a PSO to the group. Applying fine-grained password policies to a
group in this manner is more manageable than applying policies to each individual user account. If you
create a new service account, you simply add it to a group, and the PSO manages the account.
By default, only members of the Domain Admins group can create and apply fine-grained password
policies. However, you also can delegate the ability to set these policies to other users on a domain-by-
domain basis.
Applying fine-grained password policies

You cannot apply a fine-grained password policy directly to an OU. To apply a fine-grained password policy
to OU users, you can use a shadow group. A shadow group is a global security group that maps logically to
an OU and enforces a fine-grained password policy. You can add an OU’s users as members of the newly
created shadow group, and then you can apply the fine-grained password policy to this shadow group. If
you move a user from one OU to another, you must update the membership of the corresponding shadow
groups.
The settings that fine-grained password policies manage are identical to those in the Password Policy and
Accounts Policy nodes of a GPO. However, you neither implement fine-grained password policies as part
of Group Policy nor are they applied as part of a GPO. Instead, the PSO is a separate class of object in AD DS
that maintains the settings for fine-grained password policy. Additionally, fine-grained password policies
do not interfere with custom password settings or filters that you might have implemented.
You can create one or more PSOs in your domain. Each contains a complete set of password and lockout
policy settings, and each allows the same configuration options that are available in domain-based
password and lockout settings. You apply a PSO by linking it to one or more global security groups or users.
To use a fine-grained password policy, your domain functional level must be at least Windows
Server 2008, which means that all of your domain controllers in the domain must be running at
least Windows Server 2008. To meet this condition, you must raise the domain functional level to
at least Windows Server 2008.
To confirm and modify the domain functional level, use the following procedure:
1. Open Active Directory Domains and Trusts.
2. In the console tree, expand Active Directory Domains and Trusts, and then expand the tree until you
can see the domain.
3. Right-click the domain, and then click Raise domain functional level.
Tools for creating PSOs

PSOs are the key components to implementing
fine-grained password policies. The following table
highlights some settings that a PSO can contain.
Setting Value Description
Password settings
Name String Name of the PSO. Make sure to

implement a naming strategy for PSOs.
ComplexityEnabled True or False Defines if the PSO enforces the use of

complex passwords.
MinPasswordLength Integer Minimum length of the password.
MaxPasswordAge Time: Maximum amount of days before users

dd.hh:mm:ss will need to change their passwords.
MinPasswordAge Time: Minimum amount of time before users are

dd.hh:mm:ss able to change their passwords. You use
this often with PasswordHistoryCount to
prevent users from changing their
passwords multiple times right away to
reuse their old passwords.
PasswordHistoryCount Integer Number of passwords that cannot be

reused.
ReversibleEncryptionEnabled True or False Defines if reversible encryption is allowed.

You must set it to False unless you have
specific reasons to allow reversible
encryption.
Account lockout settings
LockoutThreshold Integer Number of wrong password logons that

lead to a locked account.
LockoutObservationWindow Time: hh:mm:ss Time period during which the number of

wrong passwords will lock the account.
LockoutDuration Time: hh:mm:ss Duration after which the account will

unlock automatically. If not configured, an
administrator needs to unlock the
account.
Setting Value Description
General settings
Precedence Integer Number that defines the priority of the

PSO. If different PSOs apply to the same
user, the precedence defines which one
will apply.
PSOApplied Multivalue list Distinguished names of the users or global

of distinguished security groups to which the PSO should
names apply.
ProtectedFromAccidentalDeletion True or False Defines whether the PSO should be

protected from accidental deletion.
You can create and apply PSOs in the Windows Server 2012 and newer environment by using either of the
following tools:
 Windows PowerShell
 Active Directory Administrative Center
Configuring PSOs by using Windows PowerShell

In Windows Server 2012 and newer, you can use the following cmdlets in the Active Directory module for
Windows PowerShell to create and manage PSOs in your domain:
 New-ADFineGrainedPasswordPolicy. This cmdlet creates a new PSO and defines its parameters. For
example, the following command creates a new PSO named TestPwd and then specifies its settings:
New-ADFineGrainedPasswordPolicy TestPswd -ComplexityEnabled:$true -

LockoutDuration:"00:30:00" -LockoutObservationWindow:"00:30:00" -LockoutThreshold:"0"
-MaxPasswordAge:"42.00:00:00" -MinPasswordAge:"1.00:00:00" -MinPasswordLength:"7" -
PasswordHistoryCount:"24" -Precedence:"1" -ReversibleEncryptionEnabled:$false -
ProtectedFromAccidentalDeletion:$true
 Add-FineGrainedPasswordPolicySubject. This cmdlet enables you to link a user or group to an

existing PSO. For example, the following command links the TestPwd PSO to the AD DS group named
Marketing:
Add-ADFineGrainedPasswordPolicySubject TestPwd –Subjects0 Marketing
Configuring PSOs by using Active Directory Administrative Center

The Active Directory Administrative Center provides a GUI for creating and managing PSOs. To manage
PSOs in the Active Directory Administrative Center, follow this procedure:
1. Open Active Directory Administrative Center.
2. Click Manage, click Add Navigation Nodes, in the Add Navigation Node dialog box, select the
appropriate target domain, and then click OK.
3. In the Active Directory Administrative Center navigation pane, open the System container, and
then click Password Settings Container.
4. In the Tasks pane, click New, and then click Password Settings.
5. Configure the settings for the new PSO.
6. Under Directly Applies To, click Add, type Marketing, and then click OK.
This associates the Password Policy object with the members of the global group that you created for
the test environment.
7. Click OK to submit the creation of the PSO.
Note: The Active Directory Administrative Center interface for PSO management uses the
Windows PowerShell cmdlets mentioned previously to carry out the creation and management of
PSOs.
Demonstration: Configuring a fine-grained password policy

In this demonstration, you will see how to configure and apply a fine-grained password policy.
Demonstration Steps
1. On LON-DC1, open Active Directory Administrative Center.
2. Change the group scope for the Managers group to Global.
Note: Ensure that you open the Properties dialog box for the Managers group, and not the
Managers OU.
3. In Active Directory Administrative Center, configure a fine-grained password policy for the
Adatum\Managers group with the following settings:
o Name: ManagersPSO
o Precedence: 10
o Password history: 20 passwords
o Complexity enabled: Yes
o Minimum password age: 1 day

o Number of failed logon attempts allowed: 3 attempts
o Reset failed logon attempts count after: 30 minutes
o Select Until an administrator manually unlocks the account
4. Close the Active Directory Administrative Center.

PSO precedence and resultant PSO

You can link more than one PSO to a user or a
security group. This happens when a user is a
member of multiple security groups that might
each already have an assigned PSO or when you
assign multiple PSOs directly to a user object. In
either case, only one PSO can be the effective
password policy. If you assign multiple PSOs to a
user or a group, the msDS-
PasswordSettingsPrecedence attribute helps
determine the resultant PSO. A PSO with a lower
value takes precedence over a PSO with a higher
value.
The following process describes how AD DS determines the resultant PSO if you link multiple PSOs to a user
or a group:
1. Any PSO that you link directly to a user object is the resultant PSO. If you link multiple PSOs directly to
the user object, the PSO with the lowest msDS-PasswordSettingsPrecedence value is the resultant
PSO. If two PSOs have the same precedence, the PSO with the mathematically smallest objectGUID is
the resultant PSO.
2. If you do not link any PSOs directly to the user object, AD DS compares the PSOs for all global security
groups that contain the user object. The PSO with the lowest msDS-PasswordSettingsPrecedence
value is the resultant PSO. If you apply multiple PSOs to the same user, and they have the same msDS-
PasswordSettingsPrecedence value, AD DS applies the PSO with the mathematically smallest
objectGUID.
3. If you do not link any PSOs to the user object, either directly or indirectly through group membership,
AD DS applies the Default Domain Policy.
All user objects contain a new attribute called msDS-ResultantPSO. You can use this attribute to
determine the distinguished name of the PSO that AD DS applies to the user object. If you do not link a PSO
to the user object, this attribute does not contain any value and the Default Domain Policy GPO contains
the effective password policy. To view the effective PSO that AD DS applies to a user, open Active
Directory Users and Computers, and on the View menu, ensure that Advanced Features is enabled. You
then should open the properties of a user account, and you can view the msDS-ResultantPSO attribute on
the Attribute Editor tab if you have configured the Show Constructed Attributes option under the Filter
options.
Note: While you must define PSOs from a highly privileged group such as Domain Admins,
you should train help-desk administrators to evaluate the effective PSOs for a user. This helps
administrators answer users’ questions when they do not understand which password settings
apply.
Account-security options in Windows Server 2016

Secure accounts achieve a secure AD DS forest and
domain infrastructure. By default, every account
that signs in to a domain-joined client or server is
cached locally on that computer. The computer
maintains, by default, the last 10 user profiles and
their associated credentials. This is risky, for
example, in the following situations:
 Consider an administrative account that is

used for troubleshooting or supporting users
by signing in locally to a regular user’s device.
The user account profile and its credentials are
stored in the system. If the owner of the
system has higher local rights, he or she can use tools to retrieve the administrative credentials, and
then use them to access other information on the network.
 Certain user accounts and computers contain highly critical information. Therefore, ensure that only
authorized users can sign in to their workstations, and make sure that other users cannot access the
same computers.
You should configure highly trusted service accounts for authorization only on a certain set of computers.
To provide administrators with the ability to address these risks and requirements, Windows Server 2016
and Windows Server 2012 R2 include new functionalities for credential protection and management:
 Protected Users
 Authentication policies
 Authentication policy silos
Protected Users
The Protected Users security group prevents highly sensitive accounts from being locally cached on domain
member computers. It requires domain-controller authentication for those accounts for every sign in that
occurs.
Protected Users is a new group that you can use to configure highly sensitive accounts and you can find it
in the Users container in AD DS. To enable Protected Users, an administrator simply adds the highly trusted
accounts to the Protected Users security group. This Protected Users feature does not require Windows
Server 2012 R2 domain controllers. However, this group is created only when a Windows Server 2012 R2 or
newer domain controller receives the PDC emulator operations master role. For further use of this feature, it
is not necessary that the PDC emulator operations master remain on the Windows Server 2012 R2 domain
controller, and it is not necessary to maintain the domain controller. However, because the domain
controller can only be promoted when the schema has been extended, the schema extension for Windows
Server 2012 R2 or newer needs to be in place even if the feature does not require it.
The Protected Users feature is a client-side feature that protects domain accounts on domain member
computers. Protected Users depend on the domain member’s operating system and is available on the
following operating systems:
 Windows 8.1 or newer
 Windows Server 2012 R2 or newer

Older operating systems will not support this feature and will not prevent the accounts in the Protected
Users group from being cached locally. To ensure that accounts within the Protected Users group are not
compromised on older operating systems, use the other methods such as the Deny log on locally security
setting where appropriate.
Protected Users who sign in to a domain member computer that has a supported operating system will be
prevented from using the following protocols:
 Default credential delegation, or Credential Security Support Provider (CredSSP)
 Digest authentication
 NTLM
When all domain controllers of the sign-in domain are based on Windows Server 2012 R2, and the domain
functional level is raised to Windows Server 2012 R2, additional security is provided. Because of this
additional security, users cannot:
 Use DES or RC4 encryption in Kerberos preauthentication.
 Be delegated with unconstrained or constrained delegation.

 Renew their Kerberos TGT without contact with the domain controller.
The following applies when a user is a member of the Protected Users security group:
 The user must be able to use authentication based on AES encryption. Therefore, all domain controllers
must be at a Windows Server 2008 level or newer.
 The password of any account in the Protected Users group must have been changed against a
Windows Server 2008 or newer domain controller to ensure that the password was encrypted by using
AES.
 On supported domain members, such as Windows 10 and Windows Server 2016, the credentials of the
user will not be cached.
 The user will only be able to sign in to domain members that are able to authenticate against a domain
controller. Offline sign in will not work for these accounts. The startup of services that use an account
that is a member of the Protected Users group will fail when the domain member is offline.
 The maximum lifetime of the issued Kerberos TGT and the maximum lifetime for ticket renewal are
limited to 240 minutes (four hours). While administrators configure all other accounts by using the
domain policy settings, which are 10 hours by default for the ticket and seven days for renewal, four
hours are hard-coded for Protected Users.
Protected Users is a security setting that is global within the domain. This setting does not allow you to
protect certain users only on certain devices. Therefore, use Protected Users carefully and test it before
relying on the Protected Users feature.
Authentication policies
With authentication policies, you can configure more-restrictive Kerberos settings for specific user or
service accounts. Additionally, you can use DAC claims to define conditions that need to be met by users,
service accounts, and/or devices during sign in.
Authentication policies implement by using a new object class with the name authentication policy in
AD DS.
To implement authentication policies, you need to ensure that you meet the following prerequisites,
including that:
 All domain controllers in the domain must be based on Windows Server 2012 R2 or newer.
 The domain functional level must be Windows Server 2016 or Windows Server 2012 R2.
 Domain controllers must be configured to support DAC.

 Windows 10, Windows 8.1, Windows 8, Windows Server 2016, Windows Server 2012 R2, or Windows
Server 2012 domain members must be configured to support DAC, including Kerberos compound
claims (device claims).
When configuring an authentication policy in the Active Directory Administrative Center, you can configure
the following settings:
 Display name of the authentication policy.
 Description.
 If the policy should be enforced (default), or if you want to validate the policy by audit policy
restrictions only.
 Accounts to which the policy should apply. Accounts are in the authentication policy settings; however,
be aware that you configure this on the account, unlike authentication policy silos, where the accounts
are configured within the silo.
 For user, service, and computer accounts, you can define the following settings separately:
o The TGT lifetime of the account.
o Access control conditions using DAC claims that define which users or services are able to run on
which devices.
You can configure these settings to user accounts either within the user properties window in the Active
Directory Administrative Center, or by configuring them in the authentication policy properties window.
Regardless of where you configure these settings, they are written to the authentication policy. After you
configure these settings, you will sign in to a device, or you will receive the message that “Your account is
configured to prevent you from using this PC.” In either case, an event is logged.
Note: While older operating systems had options to restrict users from signing in to specific
devices, they were easy to circumvent. Authentication policies and authentication-policy silos that
are built on Kerberos (instead of names only), and DAC claims, provide a secure method to ensure
that only certain users can sign in to certain devices.
Note: Authentication policies do not prevent users from signing in by using NTLM. When a
domain member is fully able to communicate by using Kerberos, it is likely that the rules
configured in the authentication policy work as expected. However, there might be scenarios
where NTLM is used. To prevent this, consider combining Protected Users and account policies.
Authentication policy silos

Authentication policy silos enable administrators to configure users, service accounts, and computers within
the same security scope to apply the same authentication policy. Authentication policies enable
administrators to select a separate authentication policy for each security principal type: user, service, or
computer accounts. The system then adds an additional claim to a silo’s principals, which enables file-server
administrators to restrict access to certain files for security principals of specific authentication policy silos.
The prerequisites of authentication policy silos are the same as the prerequisites of authentication policies.
You should use them as an alternative means to assign user, service, or computer accounts to use certain
authentication policies. By using Active Directory delegation, you are able to assign different roles to create
authentication policies, and then assign those policies to security principals by using authentication policy
silos.
Like authentication policies, you can configure authentication policy silos to be enforced or in auditing
mode. Authentication policies are enforced by default, while authentication policy silos are configured in
auditing mode. Additionally, authentication policy silos have a higher precedence than authentication
policies.
Furthermore, authentication policy silos do provide a claim and an administrator can use it to ensure that
certain files or certain file structures can only be accessed when users or computers have been validated by
an authentication policy silo.
Additional Reading: For more information on credentials protection and management,

refer to: http://aka.ms/R5bfid
Configuring user account policies

There are several options available for configuring
user account policies when you are administering
an AD DS environment.
Local policy settings with Secpol.msc

Each individual Windows Server 2016 computer
has its own set of account policies, which apply to
accounts created and managed on the local
computer. To configure these policy settings, open
the Local Security Policy Console by running
secpol.msc at the command prompt. You can
locate the password policy and account policy
settings within the Local Security Policy Console
by expanding Security Settings, and then expanding Account Policies.
Group Policy with Group Policy management

In the AD DS domain environment, you configure domain-wide account policy settings within the Group
Policy Management Editor. To find the settings’ domain-wide account policy settings, expand the
Computer Configuration node, expand the Policies node, expand the Windows Settings node, expand
the Security Settings node, and then expand the Account Policies node.
The settings found within the Account Policies node are the same settings found in the Local Security
Policy, with the addition of the Kerberos Policy settings that apply to domain authentication.
The Group Policy account policy settings exist in the template of every GPO that you create in the Group
Policy Management console. However, you can apply an account policy only once in a domain and in only
one GPO. This is the Default Domain Policy, and it links to the root of the AD DS domain. Therefore, the
account policy settings in the Default Domain Policy apply to every computer that is joined to the domain.
Note: If settings conflict between the account policy settings in the Local Security Policy and
the account policy settings in the Default Domain Policy GPO, the Default Domain Policy settings
take precedence.
When you initially install a Windows operating system, such as Windows 8.1, Windows 10, or Windows
Server 2016, the computer will have a password policy with settings configured and established by default,
but the account lockout policy does not have any settings configured. When you install a domain, the
Default Domain Policy that is created contains all three policies. You can make changes to any of the
policies, including configuring the settings in the account lockout policy. However, you need to consider
the implications carefully before doing so.
In most cases, your organization will already have established domains and computer systems that have
these settings configured. Most organizations also have numerous written security policies that dictate
standards for password and account lockout policies. In these cases, you cannot make changes without
approval or without addressing the written security policies.
Enhancing password authentication with Windows Hello and MFA

As user identities become more critical, it is
necessary to develop new technologies to protect
identities, and to protect the process of identity
verification or authentication. In the new version of
operating systems, and in cloud services, Microsoft
provides enhanced authentication technologies
that combine multiple factors.
Windows Hello and Microsoft Passport

To enhance security on the client side, and to
additionally secure authentication process,
Microsoft implemented Microsoft Passport and
Windows Hello technologies in the Windows 10
operating system. These technologies allow you to use additional or different methods of authentication,
instead of the traditional combination of a user name and password.
Windows Hello is the biometric technology that allows users to sign in to Windows by using their
fingerprints, facial recognition, or iris scan. Many business laptops today have built-in fingerprint readers,
and Windows Hello supports most of the existing fingerprint-reader hardware. Additionally, on some
mobile devices, such as Microsoft Lumia 950, an iris-scan camera is available, and it uses Windows Hello to
recognize a user and allow them to sign in.
Windows Hello technology enables you to use alternative and more secure methods to sign in to your
computer or mobile device. Additionally, because Windows Hello is an extensible technology, it will be
compatible with new hardware that has not yet reached the market.
Microsoft Passport is a technology that complements Windows Hello. Microsoft Passport provides a two-
factor authentication by combining biometrics data from Windows Hello with encryption keys taken from
the device. Microsoft Passport also lets you establish a PIN that you can use to sign in to a Windows 10
device, instead of using a password. Using a PIN instead of a password is more secure, as the PIN is bound
to the device that you use. For each device that you use, you can establish a different PIN, but still be signed
in with a same user account.
Microsoft Passport is a technology that uses trusted platform module (TPM) chips intensively. TPM provides
the ability to store authentication keys securely. When the user authenticates to Windows Hello, by using
the biometrics mechanism, Microsoft Passport takes the authentication data and uses it to have the TPM
chip generate a set of public and private keys.
On each Windows 10 device (mobile, desktop, and laptop), you can configure more than one
authentication method. For example, you can configure a PIN and also utilize your fingerprint to sign in to
your Windows 10 computer. Furthermore, upon each sign in, you can decide which method you will use.
Similarly, on your mobile Windows 10 device, such as Lumia 950, you can use a PIN or an iris scan to unlock
the device.
Windows Hello is the technology that you can also use to authenticate to your application, not just to the
operating system. Developers can use Windows Hello to enhance security on their applications that require
authentication.
Microsoft Azure Multi-Factor Authentication

The purpose of Multi-Factor Authentication (MFA) is to increase security. Traditionally, standard
authentication requires knowledge of sign-in credentials, which typically consist of a user name and an
associated password. Multi-Factor Authentication adds an extra verification that relies on either having
access to a device that is presumably in the possession of the rightful owner or having physical
characteristics of that person, as in the case of biometrics. This additional requirement makes it
considerably more difficult for an unauthorized individual to compromise the authentication process.
Multi-Factor Authentication is integrated into Azure Active Directory (Azure AD). It allows the use of a
phone as the physical device that provides the means of confirming a user’s identity. The process of
implementing Multi-Factor Authentication for an Azure AD user account starts when a user with the global
administrator role enables the account for Multi-Factor Authentication from the Azure portal. At the next
sign-in attempt, the user is prompted to set up authentication by selecting one of the following options:
 Mobile phone. Requires the user to provide a mobile phone number. Verification can be a text
message or in the form of a phone call—at the end of which, the user must press the pound key (#).
 Office phone. Requires the specification of the OFFICE PHONE entry of the user’s contact information
in Azure AD. An administrator must preconfigure this entry, and the user cannot modify or provide this
entry at verification time.
 Mobile app. Requires that the user has a smartphone on which the user must install and configure the
mobile phone app.
As part of the verification process, a user also can generate application passwords, because Multi-Factor
Authentication is limited to authenticating access to applications and services from a browser. Effectively, it
does not apply to traditional desktop applications or modern applications such as Outlook, Skype for
Business, or mobile apps for email. A user then can use their configuration settings to assign randomly
generated application passwords to individual applications.
However, application passwords can be vulnerable to attacks. Therefore, as an administrator, you can
prevent all directory users from creating application passwords. You also can invalidate all application
passwords for an individual user if the computer or device where the applications are installed is
compromised.
After the verification process is complete, the Multi-Factor Authentication status for the user changes from
enabled to enforced. The same verification process repeats during every subsequent authentication
attempt. The additional security verification option appears in the Access Panel, reflecting the status
change. From the Access Panel, you can choose and configure a different verification mechanism and
generate application passwords. Generating application passwords is especially important, because without
assigned application passwords, desktop applications and modern applications that rely on authenticated
access to Azure AD will fail to connect to Azure Cloud Services.
You can use Multi-Factor Authentication to protect on-premises resources by using the Azure Multi-Factor
Authentication Server. Multi-Factor Authentication Server integrates with Internet Information Services (IIS)
authentication to secure Microsoft IIS web applications, Remote Authentication Dial-in User Service
(RADIUS) authentication, Lightweight Directory Access Protocol (LDAP) authentication, and Windows
authentication.
Before you can use the Multi-Factor Authentication Server, you must download and activate it. The
download is available through a link on the Multi-Factor Authentication management portal. The Azure
Multi-Factor Authentication Users Portal is an Internet Information Services (IIS) website at which users can
enroll for Azure Multi-Factor Authentication and manage their Multi-Factor Authentication accounts.
User enrollment and self-management involves users completing their enrollment, such as by selecting an
authentication method if the administrator has not prespecified this.
Question: Which technology allows you to use biometric functionality to sign in to Windows
devices?
Lesson 3
Implementing audit authentication
Auditing is an important security component. Windows Server 2016 domain controllers and other servers
log security-related events to the Security log, where you can monitor and identify issues that might
warrant further investigation. Auditing can log successful activities to provide documentation of changes. It
also can log failed and potentially malicious attempts to access enterprise resources. Auditing involves up
to three management steps: configuring an audit policy, configuring auditing settings on objects, and
viewing events in the Security log. In this lesson, you will learn how to configure auditing to address several
common scenarios.
Lesson Objectives
 Describe account logon and logon events.
 Configure authentication-related audit policies.
 Describe scope audit policies.
 View logon events.
Account logon and logon events

Before configuring auditing, you first need to
understand the difference between two similarly
named policy settings: Audit account logon
events and Audit logon events.
When a user signs in to any computer in the

domain by using a domain user account, a domain
controller authenticates this attempt. This
generates an account logon event on the domain
controller.
The computer to which the user signs in, for

example, the user’s laptop, generates a logon
event. The computer did not authenticate the user
against the account, but rather passed the account to a domain controller for validation. However, the
computer did allow the user to sign in interactively to the computer. Therefore, the event is a logon event.
When a user connects to a folder on a server in the domain, that server authorizes the user for a type of
logon called a network logon. Again, the server does not authenticate the user. Instead, it relies on the
ticket that the domain controller gives to the user. However, the user connection generates a logon event
on the server.
Advanced audit policies

In previous Windows Server versions, such as Windows Server 2008, there are only nine auditing categories.
Administrators can configure each category to perform auditing and to monitor the success, failure, or both
success and failure, of specific tasks and events. These events are fairly broad in scope, and can be triggered
by a variety of similar actions, some of which can generate a large number of event log entries.
In Windows Server 2012 and Windows Server 2016, the number of auditable events expanded from nine to
53, which enables administrators to be more selective in the number and types of events to audit.
These new, advanced audit policies allow administrators to connect business rules and audit policies. This
gives administrators much more control over the logon process, and they can obtain information about
very specific events that happen during the logon or logoff process.
For an account logon event, you now can define four different audit settings:
 Credential validation. Audits events that validation tests generate on user-account logon credentials.
 Kerberos service ticket operations. Audits events that Kerberos service-ticket requests generate.
 Other account logon events. Audits events that are generated by responses to credential requests
that are not credential validation or Kerberos tickets requests.
 Kerberos authentication service. Audits events that Kerberos authentication TGT requests generate.
You can audit the following logon and logoff events:
 Logon. Audits events that are generated by user account logon attempts on a computer.
 Logoff. Audits events that closing a logon session generates. These events occur on the accessed
computer, and for an interactive logon, the security audit event is generated on the computer to which
the user account logged on.
 Account lockout. Audits events that are generated by a failed attempt to sign in to an account that is
locked out.
 IPsec main mode. Audits events that are generated by the Internet Key Exchange (IKE) protocol and
Authenticated Internet Protocol (AuthIP) during main mode negotiations.
 IPsec quick mode. Audits events that IKE and AuthIP generate during quick-mode negotiations.
 IPsec extended mode. Audits events that IKE and AuthIP generate during extended-mode
negotiations.
 Special logon. Audits events that special logons generate.
 Other logon and logoff events. Audits of other events that are related to logon and logoff, and which
are not included in the Logon and Logoff settings.
 Network Policy Server. Audits events that are generated by RADIUS, Internet Authentication Service,
and NAP user access requests. These requests can be Grant, Deny, Discard, Quarantine, Lock, and
Unlock.
Basic audit policies vs. advanced audit policies

The basic security audit-policy settings are in Security Settings\Local Policies\Audit Policy, and the
advanced security audit policy settings are in Security Settings\Advanced Audit Policy Configuration
\Audit Policies. Although the basic and advanced security audit-policy settings appear to overlap, they are
recorded and applied differently.
The new set of advanced audit policies enables administrators to be more selective in the number and
types of events to audit. For example, where a basic audit policy provides a single setting for account logon,
advanced audit policy provides four. Enabling the single basic account logon setting is the equivalent of
setting all four advanced account logon settings. In comparison, setting a single advanced audit policy
setting does not generate audit events for activities for which you have no interest. For example, if you
enable success auditing for the basic Audit account logon events policy setting, only success events will
be logged for all account logon-related behaviors. In comparison, you can configure success auditing for
one advanced account logon setting, failure auditing for a second advanced account logon setting, success
and failure auditing for a third advanced account logon setting, or no auditing, depending on the needs of
your organization.
Note: Using both the basic and advanced settings can cause unexpected results. Therefore,
do not combine the two sets of audit policy settings. If you use Advanced Audit Policy
Configuration settings, you should enable the Audit: Force audit policy subcategory
settings (Windows Vista or later) to override audit policy category settings policy setting
under Local Policies\Security Options. This will prevent conflicts between similar settings by
forcing basic security auditing to be ignored.
Demonstration: Configuring authentication-related audit policies

In this demonstration, you will see how to configure authentication-related audit polices.
Demonstration Steps
2. Navigate to the Default Domain Controllers Policy, and then edit the policy.
3. In the Group Policy Management Editor window, navigate to Computer Configuration

\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy.
4. Explain the nine legacy policy categories shown in the details pane.
5. Navigate to Computer Configuration\Policies\Windows Settings\Security Settings

\Advanced Audit Policy Configuration\Audit Policies.
6. View the ten main categories under advanced audit policies, and then click Account Logon and
Logon/Logoff to view the available subcategories.
7. Under Account Logon, open the properties of the Audit Kerberos Authentication Service policy.
8. Note that you can enable the policy to log a Success or Failure event. Enable the policy, and select
Success and Failure.
9. Click the Explain tab to view the detailed information about the event, the default logging settings,
and the predicted auditing volume.
10. Apply the changed policy, and then click OK to close the policy setting.
Scoping audit policies

As with all policy settings, you should define the
scope carefully for the GPOs that apply your audit
policies, so that the settings affect the correct
systems. For example, if you want to audit
attempts by users to connect to remote desktop
servers in your enterprise, you can configure logon
event auditing in a GPO that is linked to the OU
that contains your remote-desktop servers.
However, on the other hand, if you want to audit
desktop logons by users in your Human Resources
department, you can configure logon-event
auditing in a GPO that is linked to the OU that
contains Human Resources computer objects. Remember that a domain user who signs in to a client
computer or connects to a server will generate a logon event—not an account logon event—on that
system.
Only domain controllers generate account-logon events for domain users. Remember that an account-
logon event occurs on the domain controller that authenticates a domain user, regardless of where that
user logs on. If you want to audit logons to domain accounts, you should ensure account logon event
auditing to affect all domain controllers. The Default Domain Controllers GPO that is created when you
install your first domain controller is an ideal GPO in which to configure account logon audit policies.
Demonstration: Viewing logon events

In this demonstration, you will see how to view logon events.
Demonstration Steps
1. On LON-DC1, run gpupdate /force.
2. Sign out.
3. Attempt to sign in as Adatum\Aidan with the password 123456.
4. Sign in as Adatum\Administrator with the password Pa55w.rd.
5. From Server Manager, in the Tools menu, open Event Viewer.

6. Navigate to the Security log.
7. Show the Audit Failure event with the Event ID 4771, and then show the Audit Success event with the
Event ID 4768.
Verify the correctness of the statement by placing a mark in the column to the right.
Statement Answer
When a user signs in to a domain controller, a logon event is generated.

Lesson 4
Configuring managed service accounts
Creating user accounts to provide authentication for applications, system services, and background
processes is a common practice in the Windows environment. Historically, you would create accounts and
name them for use by a specific service. Windows Server 2016 supports AD DS account-like objects, known
as managed service accounts (MSAs), which make service accounts easier to manage and which pose less of
a security risk to your environment.
This lesson will introduce you to MSAs and the new functionality related to MSAs introduced in Windows
Server 2016.
Lesson Objectives
 Describe service accounts.
 Identify the challenges of using standard user accounts for services.
 Describe MSAs.
 Describe group MSAs.
 Configure group MSAs.
 Describe Kerberos delegation and service principal names (SPNs).
Overview of service accounts

In the Windows operating system, applications
sometimes require administrative access to local
and network resources. In the past, it was common
to give these applications administrative account
permissions to the resources. For example, a
Microsoft SQL Server needs to manage its
databases and it might need local administrative
access to do this. In a distributed SQL Server
environment, with multiple SQL Servers each
hosting numerous databases, it might need
administrative access to all of them. For that
reason, an administrator needs to create an
account for SQL Server that belongs to the Domain Admins group, or at least the computers’ local
Administrators group, with a password that is configured to not ever expire. Administrators need to
remember to periodically change the password manually on every server service under which it runs. This
type of account introduces possible security issues and, if compromised, can endanger an entire domain.
Therefore, because of the possible security issues, you could consider running the program or service by
using a built-in local account. Windows operating systems have three built-in local accounts to allow
program and service access of resources. These accounts are tied to the individual computer rather than a
user account, as follows:
 Local System. Has extensive privileges on the local system and acts as the computer on the network. It
is a very high-privileged built-in account. The name of the account is NT AUTHORITY\SYSTEM.
 Local Service. Has the same level of access to resources and objects as members of the local Users
group. This limited access helps protect the system if individual services or processes are compromised.
Services running as the Local Service account will access network resources as a null session without
any credentials. The name of the account is NT AUTHORITY\LOCAL SERVICE.
 Network Service. Has more access to resources and objects than members of the Users group have,
such as the Local Service account. Services that run as the Network Service account access network
resources by using the credentials of the computer account. The name of the account is NT
AUTHORITY\NETWORK SERVICE.
You should be aware that using the Local System account still might compromise security, considering the
high-level privileges under which it operates. Therefore, you should take extra care when using this account
for program access. Alternatively, the Local Service account might not have enough privileges to access all
the resources required by the program. If the program needs resources on other computers, you could use
the Network Service account. However, you must add the machine account to a group in the domain or
individually on the other computers. In all cases, you should make a thorough security analysis to ensure
you consider all aspects of using the service accounts.
Challenges of using service accounts

Many programs such as SQL Server or IIS contain
services that you install on the server that hosts the
program. These services typically run at server
startup or are triggered by other events. Services
often run in the background and do not require
any user interaction.
For a service to start up and authenticate, you use

a service account. A service account may be an
account that is local to the computer, such as the
built-in Local System, Local Service, or Network
Service accounts. You also can configure a service
account to use a domain-based account located in
AD DS.
To help centralize administration and to meet program requirements, many organizations choose to use a
domain-based account to run program services. Although this does provide some benefit over using a local
account, there are several associated challenges, such as the following:
 Extra administration effort might be necessary to manage the service account password securely. This
includes tasks such as changing the password and resolving situations that cause an account lockout.
Service accounts also typically are configured to have passwords that do not expire, which may go
against your organization’s security policies.
 Difficulty in determining where a domain-based account is used as a service account. You might use a
standard user account for multiple services on various servers throughout the environment. A simple
task, such as changing the password, may cause authentication issues for some applications. It is
important to know where and how to use a standard user account when it is associated with a program
service.
 Extra administration effort may be necessary to manage the service principal name (SPN). Using a
standard user account may require manual administration of the SPN. If the logon account of the
service changes, the computer name is changed. Alternatively, if a DNS host name property is
modified, you may need to modify the SPN registrations manually to reflect the change. A
misconfigured SPN causes authentication problems with the program service.
Windows Server 2016 supports an AD DS object, named a Managed Service Account (MSA), which you use
to facilitate service-account management. The subsequent topics provide information on the requirements
and use of MSAs in Windows Server 2016.
Overview of managed service accounts

An MSA is an AD DS object class that enables
simplified password and SPN management for
service accounts. The MSA was introduced in
Windows 7 and Windows Server 2008 R2.
Many network-based programs use an account to

run services or provide authentication. For
example, a program on a local computer might use
the Local Service, Network Service, or Local System
accounts. These service accounts may work fine.
However, these typically are shared among
multiple programs and services, which makes it
difficult to manage for a specific program.
Furthermore, you cannot manage these local service accounts at the domain level.
Alternatively, it is common that a program might use a standard domain account that you configure
specifically for the program. However, the main drawback is that you need to manage passwords manually,
which increases administration effort. A managed service account can provide a program with its own
unique account, while eliminating the need for an administrator to administer the account’s credentials
manually.
How an MSA works

MSAs are stored in AD DS as msDS-ManagedServiceAccount objects. This class inherits structural aspects
from the Computer class, which it inherits from the User class. This enables an MSA to fulfill User-like
functions, such as providing authentication and security context for a running service. It also enables an
MSA to use the same password-update mechanism that Computer objects in AD DS use, which is a process
that requires no user intervention.
MSAs provide the following benefits to simplify administration:
 Automatic password management. An MSA maintains its own password, including password changes,
automatically.
 Simplified SPN management. SPN management happens automatically if you configure your domain
at the Windows Server 2008 R2 domain functional level or higher.
MSAs are stored in the CN=Managed Service Accounts, DC=<domain>, DC=<com> container. You can
view this by enabling the Advanced Features option on the View menu within Active Directory Users
and Computers. This container is visible by default in the Active Directory Administrative Center.
Requirements for using MSAs

To use an MSA, the server that runs the service or program must be running Windows Server 2008 R2 or a
newer operating system. You also must ensure that Microsoft .NET Framework 3.5.x and the Active
Directory module for Windows PowerShell are both installed on the server.
Note: You cannot share a standard MSA between multiple computers or that you use in
server clusters where the service is replicated between nodes. Additionally, you cannot use MSAs
for unattended scheduled tasks.
To simplify and provide full automatic password and SPN management, we strongly recommend that the
AD DS domain be at the Windows Server 2008 R2 functional level or higher. However, if you have a domain
controller that is running Windows Server 2008, you can update the Active Directory schema to Windows
Server 2008 R2 to support this feature. The only disadvantage is that the domain administrator must
configure SPN data manually for the MSAs.
Using MSAs on Windows Server 2016 Domain Controllers

In Windows Server 2016, you create MSAs as the new group managed service account object type by
default. However, on a Windows Server 2016 domain controller, you accommodate this by creating a key
distribution services (KDS) root key for the domain. To create the root key, you must run the following
cmdlet from the Active Directory module for Windows PowerShell:
Add-KDSRootKey –EffectiveTime ((Get-Date).AddHours(-10))
The next topic discusses group MSAs in more detail, including providing further explanation of how you
can create a KDS root key and the Add-KDSRootKey cmdlet.
What are group MSAs?

You use group MSAs to extend the capabilities of
standard MSAs to more than one server in your
domain. In server-farm scenarios with Network
Load Balancing (NLB) clusters or IIS servers, you
often need to run system or program services
under the same service account. Standard MSAs
cannot provide MSA functionality to services that
are running on more than one server. However, by
using group MSAs, you can configure multiple
servers to use the same MSA and still retain the
benefits that MSAs provide, such as automatic
password maintenance and simplified SPN
management.
Requirements for group MSAs

Your environment must meet the following requirements if you want to support group MSA functionality,
including that:
 At least one domain controller must be running Windows Server 2012 or newer to store managed
password information.
 Client computers using group MSAs must have Windows 8 or newer, and server-based computers must
have Windows Server 2012 or newer.
 You must create a KDS root key on one of the domain’s domain controllers. To create the KDS root key,
you must run the following command from the Active Directory Module for Windows PowerShell on a
Windows Server 2016 domain controller:
Add-KdsRootKey –EffectiveImmediately
Note: The –EffectiveImmediately switch uses the current time to establish the timestamp
that marks the key as valid. However, when using the –EffectiveImmediately switch, the actual
effective time is set to 10 hours later than the current time. This 10-hour difference is to allow for
AD DS replication to replicate changes to other domain controllers in the domain. For testing
purposes, you can bypass this functionality by setting the –EffectiveTime parameter to 10 hours
before the current time by running the following command:
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
Group MSA functionality

Group MSAs enable managed service account functionality across multiple servers by delegating the
management of MSA password information to Windows Server 2016 domain controllers. By doing this, the
management of passwords is no longer dependent on the relationship between a single server and AD DS,
but is controlled entirely by AD DS.
The group managed service account object contains a list of principals, either computers or AD DS groups,
which are allowed to retrieve group MSA password information from AD DS. The principals then can use
the Managed Service Account group for authentication for services.
You create group MSAs by using the same cmdlets that you used for creating the standard MSA from the
Active Directory Module for Windows PowerShell. That is, the cmdlets used for managed service account
management create group MSAs by default.
On a Windows Server 2016 domain controller, create a new MSA by using the New-ADServiceAccount
cmdlet with the –PrinicipalsAllowedToRetrieveManagedPassword parameter. This parameter accepts
one or more comma-separated computer accounts or AD DS groups that are permitted to obtain password
information for the group MSA that is stored in AD DS on Windows Server 2016 domain controllers.
For example, the following cmdlet creates a new group MMSA called SQLFarm, and enables the LON-SQL1,
LON-SQL2, and LON-SQL3 hosts to use the group MSA:
New_ADServiceAccount –Name LondonSQLFarm –PrincipalsAllowedToRetrieveManagedPassword LON-

SQL1, LON-SQL2, LON-SQL3
After you add a computer to use the PrincipalsAllowedToRetrieveManagedPassword parameter, you

can assign the group MSA to services by using the same assignment process as standard MSAs.
Using AD DS groups to manage group MSAs

You can use AD DS security groups to identify group MSAs. When you use an AD DS group for the
PrincipalsAllowedToRetriveManagedPassword parameter, any computers that are members of that
group will be allowed to retrieve the password and utilize group MSA functionality. When you use an
AD DS group as the principal allowed to retrieve a managed password, any accounts that are members of
the group will also have the same capability.
Demonstration: Configuring group MSAs

In this demonstration, you will see how to configure group MSAs.
Demonstration Steps
Create the KDS root key for the domain

1. On LON-DC1, from Server Manager, open the Active Directory Module for Windows PowerShell
console.
2. Use the Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10)) cmdlet to create the domain

KDS root key.
Create and associate an MSA

1. Use the New-ADServiceAccount cmdlet to create an MSA.
2. Use the Add-ADComputerServiceAccount cmdlet to associate the MSA with LON-SVR1.
3. Use the Get-ADSeviceAccount cmdlet to view the newly-created MSA and confirm proper
configuration.
Install an MSA
1. On LON-SVR1, open the Active Directory Module for Windows PowerShell console.
2. Use the Install-ADServiceAccount cmdlet to install the MSA on LON-SVR1.

3. Open Server Manager, and start the Services console.
4. Open the Properties pages for the Data Sharing Service, and then select the Log On tab.
5. Configure the Data Sharing Service to use Adatum\SampleApp_SVR1$.

6. Clear the password for both the Password and Confirm password boxes.
SPNs and Kerberos delegation

In some scenarios, a program for a service might
need to make a connection to another server’s
services on behalf of the client. For example, when
a client uses a front-end server that makes a
connection to a back-end server, this connection
requires authentication. Kerberos uses
authentication delegation for such scenarios. The
requesting service, which in this example is the
client, requests that the KDC authorize a second
service to act on its behalf. The second service then
can delegate authentication to a third service.
However, in Windows Server 2008 and newer,
Microsoft has added the constrained delegation model to limit the scope of services that can be delegated
this way, particularly third-tier services and beyond. This model provides a safer form of delegation for
services to use.
When you use constrained delegation, you can configure service account delegation to specific sets of
service accounts. You can configure a particular service account to be trusted for delegation to a specific
instance of a service running on a specific computer or a set of specific instances of services running on
specified computers.
An SPN is a unique identifier for each instance of a service running on a computer. When using Kerberos
authentication, a defined SPN for a service allows clients to identify that instance of the service on the
network. The SPN is registered in AD DS and is associated with the account of the service that the SPN
specifies. When a service needs to authenticate to another service, it uses that service’s SPN to distinguish it
from other services on that computer. A service can use constrained delegation if it can obtain a Kerberos
service ticket for itself on behalf of the user being delegated, in this case, another service. When using
constrained delegation, the user can obtain the service ticket directly by authenticating through curb roles
or the service can obtain the service ticket on behalf of the user.
One problem with this model is that when a domain administrator configured the service for constrained
delegation, the service administrator did not know which front-end service was being delegated to the
resource services they owned. In Windows Server 2016, this is overcome by also allowing the service
administrator to configure a service’s constrained delegation. This means that the back-end service
administrator to allow or deny access by front-end services.
Windows Server 2012 and Windows Server 2016 implement new extensions for constrained delegation. For
example, the Service for User to Proxy, known as S4U2proxy extension allows a service to use its Kerberos
service ticket for a user to obtain a service ticket from the KDC to a back-end service. A service
administrator can configure constrained delegation on the back-end service’s account, even in another
domain. You can configure front-end services, such as Microsoft Office Outlook on the Web and Microsoft
SharePoint Server, for constrained delegation to back-end servers on other domains. This enhances your
ability to support service solutions across domains by using your existing Kerberos authentication
mechanisms.
Question: How are group MSAs different from standard MSAs?

Lab: Securing AD DS
Scenario
The security team at A. Datum Corporation has been examining possible security issues in the organization,
focusing on AD DS. The security team is particularly concerned with AD DS authentication and security of
branch-office domain controllers.
You must help improve security and monitoring of authentication against the enterprise’s AD DS domain.
Additionally, management at A. Datum has instituted a password policy, and you must enforce it for all user
accounts and develop a more-stringent password policy for security-sensitive administrative accounts. It
also is important that you implement an appropriate audit trail to help monitor authentication attempts
within AD DS.
The second part of your assignment includes deploying and configuring RODCs to support AD DS
authentication within a branch office. Lastly, you should evaluate the usage of a group MSA by deploying it
to the test server.
Objectives
After completing this lab, you will be able to:
 Implement security policies for accounts, passwords, and administrative groups.

 Deploy and configure an RODC.
 Create and associate a group MSA.
Lab Setup
Estimated Time: 60 minutes
Virtual machines: 20742B-LON-DC1 and 20742B-LON-SVR1
User name: Adatum\Administrator
Password: Pa55w.rd
For this lab, you will use the available virtual machine environment. Before you begin the lab, you must
complete the following steps:
1. On the host computer, start Hyper-V Manager.
2. In Hyper-V Manager, click 20742B-LON-DC1, and then in the Actions pane, click Start.
3. In the Actions pane, click Connect. Wait until the virtual machine starts.
4. Sign in by using the following credentials:
o User name: Adatum\Administrator
o Password: Pa55w.rd
5. Repeat steps two through four for 20742B-LON-SVR1.

Exercise 1: Implementing security policies for accounts, passwords, and

administrative groups
Scenario
A. Datum management has indicated that it is important that all management processes are as secure as
possible, to help prevent a security breach. The company’s security and management teams have identified
its business requirements with respect to account logons and password security. In this exercise, you will
define and implement the Group Policy settings to meet the company’s requirements.
Supporting documentation
A. Datum GPO strategy proposal
Requirements overview
A. Datum has identified the following requirements regarding account logon and password policies:
 All users must use a password that is at least eight characters long. For IT administrators, the minimum
length must be 10 characters.
 Passwords for all users must be complex and stored securely.
 All users, except IT administrators, must change their password every 60 days or less.
 IT administrators must change their password every 30 days or less.
 If users enter the wrong password more than five times within 20 minutes, their accounts must be locked.
For normal users, accounts are unlocked automatically after one hour.
 For IT administrators, accounts must be locked after three incorrect password attempts. IT administrator
accounts are never unlocked automatically. An administrator must unlock the account. IT administrator
accounts include all members of the IT group and the Domain Admins group.
 No users should be able to use at least 10 of their previous passwords.
 The membership list for the local Administrators group on all member servers must be limited to only the
local Administrator account, the Domain Admins group, and the IT group.
 The Domain Admins group must include only the Administrator account.
 The Enterprise Admins and Schema Admins groups must be empty during normal operations. Users must
be added explicitly to these groups only when they need to perform tasks that require this level of
administrative rights.
 Other built-in groups, such as Account Operators and Server Operators, should contain no members. If
users are added to one of these groups, they should be removed from the group automatically.
 All changes made to user objects and security groups in AD DS must be audited.
Proposals
List the settings that you must configure to meet A. Datum’s requirements regarding password policies and
account lockout.
Configuration for IT
Setting Configuration for all users administrators
Enforce password history
Maximum password age
Minimum password age
Minimum password length
Passwords must meet complexity

requirements
A. Datum GPO strategy proposal
Store password using reversible

encryption
Account lockout duration
Account lockout threshold
Reset account lockout counter after
1. How can you configure that IT administrators have different password and account lockout settings than
regular users?
2. How can you identify IT administrators in terms of more restricted password and account lockout
settings?
3. How can you meet the requirement to limit the membership list for the local Administrators groups on all
member servers to only the local Administrator account, the Domain Admins group, and the IT group?
4. How can you meet the requirement that the Domain Admins group must include only the Administrator
account, and that the Enterprise Admins and Schema Admins groups must be empty during normal
operations?
5. How can you meet the requirement that other built-in groups, such as Account Operators and Server
Operators, must not contain members?
6. How can you meet the requirement that you must audit all changes to AD DS?
The main tasks for this exercise are as follows:
1. Identify the required settings.
2. Configure password settings for all users.

3. Configure a PSO for IT administrators.
4. Implement administrative security policies.
5. Implement administrative auditing.
 Task 1: Identify the required settings

1. Read the documentation provided.
2. Fill in the table of settings according to the requirements of A. Datum Corporation.
3. Answer the additional questions from the proposals document.
 Task 2: Configure password settings for all users

2. Navigate to the Default Domain Policy, and then click Edit.
3. In the Group Policy Management Editor window, navigate to Computer Configuration

\Policies\Windows Settings\Security Settings\Account Policies, and then select Password Policy.
4. Configure the following policy settings:
o Enforce password history: 10 passwords remembered
o Minimum password age: 1 days
o Password must meet complexity requirements: Enabled
o Store passwords using reversible encryption: Disabled
5. Select Account Lockout Policy, and then define and configure the following policy settings:
o Account lockout duration: 60 minutes
o Accept the suggested value change
o Account lockout threshold: 5 invalid logon attempts
o Reset account lockout counter after: 20 minutes
6. Close the Group Policy Management Editor window and the Group Policy Management console.
 Task 3: Configure a PSO for IT administrators

1. On LON-DC1, from Server Manager, open Active Directory Administrative Center.
2. Navigate to Adatum (local)\System\Password Settings Container.
3. Create a new PSO with the following parameters:
o Name: Adatum Administrators Password Settings

o Precedence: 10
o Enforce minimum password length: Selected, 10 characters minimum password length
o Enforce password history: Selected, 10 passwords remembered
o Password must meet complexity requirements: Selected
o Store password using reversible encryption: Not selected
Password age options:

o Enforce minimum password age: Selected
o User cannot change the password within (days): 1
o Enforce maximum password age: Selected

o User must change the password after (days): 30
Account lockout options:
o Enforce account lockout policy: Selected
o Number of failed logon attempts allowed: 3
o Reset failed logon attempts count after (mins): 20
o Account will be locked out: Until an administrator manually unlocks the account
4. In the Directly Applies To section, configure the PSO to apply to the IT group.
5. IT will not work because it is not a global group. Open Windows PowerShell, and then verify the IT
group’s scope with the following command:
Get-ADGroup IT
6. Modify the group’s scope by using the following command:
Set-ADGroup IT –GroupScope Global
7. In the Directly Applies To section, configure the PSO to apply to the following groups:
o IT
o Domain Admins
8. Create the PSO.
9. In Active Directory Administrative Center, switch to the Overview page, and in the Global Search
box, search for Abbi Skinner. Use the View resultant password settings to verify that the Adatum
Administrative Password Settings PSO applies to Abbi; he is in the IT group.
10. Repeat step nine to verify the user Adam Hobbs. He is not in an IT group, and the Default Domain
Policies settings apply to him.
11. Close Active Directory Administrative Center and Windows PowerShell.
 Task 4: Implement administrative security policies

1. On LON-DC1, open Active Directory Administrative Center and create a top-level OU named
Adatum Servers.
2. Move LON-SVR1 and LON-SVR2 to the Adatum Servers OU.
3. Open the Group Policy Management console, and then create and link a policy named Restricted
Administrators on Member Servers to the Adatum Servers OU.
4. Edit the GPO to restrict the local Administrators group to the Administrator account, the Domain
Admins group, and the IT group.
5. Switch to LON-SVR1 and refresh Group Policy.
6. Verify that the policy has applied to LON-SVR1 and has restricted the local Administrators group.
7. Switch back to LON-DC1.
8. Edit the Default Domain Controllers Policy.
9. Configure the GPO with Restricted Groups. Add the groups Account Operators and Server
Operators, and configure both to contain no members.
10. Close the Group Policy Management console.
 Task 5: Implement administrative auditing

1. On LON-DC1, from Server Manager, start the Group Policy Management console.
2. Navigate to and edit the Default Domain Controllers Policy.

3. Configure the Default Domain Controllers Policy to enable Success auditing of Audit Directory
Service Changes under Computer Configuration\Policies\Windows Settings\Security Settings
\Advanced Audit Policy Configuration\Audit Policies\DS Access.
4. In the Default Domain Controllers Policy, enable Success auditing of Audit Security Group
Membership under Computer Configuration\Policies\Windows Settings\Security Settings
\Advanced Audit Policy Configuration\Audit Policies\Account Management.
5. In the Default Domain Controllers Policy, enable the policy Audit: Force audit policy subcategory
settings (Windows Vista or later) to override audit policy category settings under Computer
Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options.
6. At a command prompt, type gpudate /force, and then press Enter.
7. Open Active Directory Users and Computers and enable the Advanced Features view. In the
Adatum.com properties dialog box, under Advanced Security Settings, in Auditing, locate the
Success auditing entry for Everyone with Special access, which applies to This object only.
8. Open and change the auditing entry to apply to This object and all descendent objects.
9. In Active Directory Users and Computers, add the user Abbi Skinner to the Domain Admins group.
10. Locate the user Ada Russel in the Marketing OU, and then change her city from London to
Birmingham.
11. Open Event Viewer, go into the Security log, and then open the most recent Event ID 4728. In the
properties, note that ADATUM\Administrator has added ADATUM\Abbi to the Domain Admins
groups.
12. In Event Viewer, open the most recent Event ID 5136, and note that ADATUM\Administrator has
modified the user object cn=Ada Russel and deleted the value London.
13. Move and open the next event in the Event Properties details page, and notice that
ADATUM\Administrator has modified Ada Russel and added the value Birmingham.
14. Close all open windows except for Server Manager.
Results: After this exercise, you should have identified and configured the security policies for A. Datum.
Exercise 2: Deploying and configuring an RODC

Scenario
In this exercise, you will configure the server LON-SVR1 as an RODC in the distant branch office. To avoid
travel costs, you decide to do the conversion remotely, working with a desktop-support technician and the
branch’s only IT staff member. This user already has installed a Windows Server 2016 computer named
LON-SVR1. You will stage a delegated installation of an RODC so that this administrative user can complete
the installation. After the deployment is complete, you will configure a domain-wide password replication
policy and the password replication policy specific to LON-SVR1.
1. Stage a delegated installation of an RODC.
2. Run the Active Directory Domain Services Installation Wizard on an RODC to complete the deployment
process.
3. Configure the domain-wide password replication policy.
4. Create a group to manage password replication to the branch office RODC.

5. Evaluate the resultant password replication policy.
 Task 1: Stage a delegated installation of an RODC
Preparation
To prestage an RODC account, the computer name must not be in use in the domain. Therefore, you first
need to remove LON-SVR1 from the domain by performing the following steps:
1. Remove LON-SVR1 from the domain, add it to the MUNICH workgroup, and then restart the server.
2. Sign in as:
o User name: Administrator
3. Switch to LON-DC1.
4. From Server Manager, start Active Directory Users and Computers, navigate to the Adatum
Servers OU, and then delete LON-SVR1. Confirm the deletion.
Stage a delegated installation of an RODC

1. In Active Directory Sites and Services, create a new site named Munich, and then assign it to
DEFAULTIPSITELINK.
2. Start Active Directory Administrative Center, and then navigate to the Domain Controllers OU.
3. Precreate an RODC account with the name LON-SVR1, which also should be a DNS Server and a
Global Catalog.
4. Delegate Nestor Fiore to install and administer the RODC.

5. Finish the precreation of the RODC account.
 Task 2: Run the Active Directory Domain Services Installation Wizard on an RODC to
complete the deployment process
1. Switch to LON-SVR1. From Server Manager, start the Add Roles and Features Wizard.
2. Use the wizard to install Active Directory Domain Services on LON-SVR1. Accept the installation of
features and management tools.
3. When the installation is finished, click in the notification area of Server Manager to promote this
server to a domain controller.
4. Configure to add the server as a domain controller to an existing domain. Click Change, and provide
the following credentials:
o User name: Adatum\Nestor
5. Select Adatum.com as the domain, and then proceed.
6. Notice that the Active Directory Domain Services Installation Wizard finds the precreated account.
Accept all further defaults in the wizard to use that account, and then configure AD DS.
 Task 3: Configure the domain-wide password replication policy

1. Switch to LON-DC1. From Server Manager, start Active Directory Administrative Center.
2. Make the IT group, found in the IT OU, a member of the Denied RODC Password Replication Group.
Note: The members of the IT group have elevated permissions, so storing their password on
an RODC would be a security risk. Therefore, you add the IT group to the global Deny List, which
applies to every RODC in the domain.
 Task 4: Create a group to manage password replication to the branch office RODC
1. Switch to Server Manager, and from the Tools menu, start Active Directory Users and Computers.
2. Navigate to the Users container, and then create a new group named Munich Allowed RODC
Password Replication Group.
3. Add Ana Cantrell to the new group.
4. In Active Directory Administrative Center, from the Domain Controllers OU, view the properties
for LON-SVR1.
5. In the Extensions section, on the Password Replication Policy tab, configure the Munich Allowed
RODC Password Replication Group to allow password replication. Close the properties for
LON-SVR1.
 Task 5: Evaluate the resultant password replication policy

1. In Active Directory Administrative Center, open the properties of LON-SVR1, and then in the
Extensions section, on the Password Replication Policy tab, click Advanced. Note that this dialog
box shows all accounts whose passwords are stored in the RODC.
2. Select Accounts that have been authenticated to this Read-only Domain Controller, and then
note that this only shows accounts that have the permissions and already have been authenticated by
this RODC.
3. Click the Resultant Policy tab, and then add Ana Cantrell. Notice that Ana Cantrell has a resultant
policy of Allow.
4. Close all open dialog boxes.
Results: After this exercise, you should have deployed and configured an RODC.
Exercise 3: Creating and associating a group MSA

Scenario
You need to configure a group MSA to support a new web-based application that is being deployed. Using
a group MSA will help maintain the password security requirements for the account.
1. Create and associate an MSA.
2. Install a group MSA.

3. Prepare for the next module.
 Task 1: Create and associate an MSA

1. On LON-DC1, open the Active Directory Module for Windows PowerShell console.
2. Create the KDS root key by using the Add-KdsRootKey cmdlet. Make the effective time minus 10
hours, so the key will be effective immediately.
3. Create the new service account named Webservice for the host LON-DC1.
4. Associate the Webservice MSA with LON-DC1.

5. Verify the group MSA was created by using the Get-ADServiceAccount cmdlet.
 Task 2: Install a group MSA

1. On LON-DC1, install the Webservice service account by using the following command:
Install-ADServiceAccount –Identity Webservice
2. From the Tools menu in Server Manager, open Internet Information Services (IIS) Manager.
3. Expand LON-DC1 (Adatum\Administrator), and then click Application Pools.
4. In the DefaultAppPool actions pane, in the Advanced Settings dialog box, configure the
DefaultAppPool to use the Webservice$ account as the identity. Note that you can click the ellipsis
(…) by the identity name to add the Webservice$ account as a custom account.
5. Stop and then start the application pool.
Results: After completing this exercise, you should have configured an MSA.
 Task 3: Prepare for the next module

When you finish the lab, revert the virtual machines to their initial state. To do this, perform the following
steps:
1. On the host computer, start Hyper-V Manager.

2. In the Virtual Machines list, right-click 20742B-LON-DC1, and then click Revert.
3. In the Revert Virtual Machine dialog box, click Revert.
4. Repeat steps two and three for 20742B-LON-SVR1.
Question: In the lab, you configured the password settings for all users within the Default
Domain Policy, and you configured the password settings for Administrators within a PSO.
What other options were available to help you accomplish the solution?
Question: In the lab, you were using precedence for the administrative PSO with a value of 10.
What is the reason for this?
Module Review and Takeaways

Review Questions
Question: Why is physical security so important, especially for AD DS domain controllers?
Question: You need to implement auditing policies for domain authentication and changes
to directory services. What is the best way to implement these auditing settings?
Question: Your organization requires you to maintain a highly reliable and secure AD DS
infrastructure. It also requires that users can access corporate email from the Internet by using
Outlook Web Access. You are considering implementing account-lockout settings. What must
you consider?
Tools
The following table lists the tools that this module references.
Tool Use for Where to find it
Active Directory Users Managing objects within AD DS, such as users, groups, Server Manager
and Computers and computers.
Active Directory Managing objects within AD DS, such as users, groups, Server Manager
Administrative Center and computers.
Group Policy Managing, reporting, backup, and restoration of GPOs. Server Manager
Management
Gpupdate.exe Manually updating the GPOs of local machines. Command-line
Common Issues and Troubleshooting Tips

Common Issue Troubleshooting Tip
You have configured advanced auditing

policy settings, but they do not apply.
You have configured auditing of account

logon or directory services changes. Now
you are testing them, but you cannot find
the events in your server’s event log.

Modulul VII

Uploaded by

Copyright:

Available Formats

Modulul VII

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modulul VII

Uploaded by

Copyright:

Available Formats

MCT USE ONLY.

STUDENT USE PROHIBITED

Lesson 1: Securing domain controllers 7-2

Lesson 2: Implementing account security 7-15

Lesson 3: Implementing audit authentication 7-34

Lesson 4: Configuring managed service accounts 7-38

Lab: Securing AD DS 7-45

Module Review and Takeaways 7-54

 Secure domain controllers.

 Implement audit authentication.

 Configure managed service accounts (MSAs).

 Explain how to modify the security settings of domain controllers.

 Implement secure authentication.

 Secure physical access to domain controllers.

 Describe read-only domain controllers (RODCs).

 Plan and configure RODC password replication policy.

 Configure a password replication policy.

 Describe role separation for RODC local administrators.

Security risks that can affect domain controllers

Modifying the security settings of domain controllers

Default Domain Policy vs. Default Domain Controllers Policy

Security settings in the GPO

Implementing secure authentication

 Secure user accounts and passwords. It is very

Securing physical access to domain controllers

Therefore, you should do the following steps to

 Only deploy domain controllers where you

What are RODCs?

Reasons for deploying RODCs

RODC limitations and considerations

 Because AD DS changes cannot be written directly to an RODC, no replication changes originate at an

 Run ADPrep /RODCPrep if you have

 Ensure that you have a sufficient number of

Installing an RODC in one step

Installing an RODC in two steps: prestaging and delegated promotion

Planning and configuring an RODC password replication policy

Two multivalued attributes of the RODC's

Domain-wide password replication policy

RODC-specific password replication policy

RODC filtered attribute set

 Local Security Authority

 Microsoft-specific Security Support Provider Interfaces, such as Kerberos version 5 protocol

Demonstration: Configuring a password replication policy

 Stage a delegated installation of an RODC.

 View an RODC’s password replication policy.

 Configure an RODC-specific password replication policy.

 Verify the resultant password policy.

Stage a delegated installation of an RODC

5. Finish the precreation of the RODC account.

View an RODC’s password replication policy

Configure an RODC-specific password replication policy

Verify the resultant password policy

5. Close all open dialog boxes.

Separating RODC local administration

 Describe account security in Windows Server 2016.

 Describe password policies.

 Describe Kerberos policies.

 Configure domain account policies.

 Describe how to protect groups in AD DS.