Windows 10

Table of Contents
Device security
AppLocker
Administer AppLocker
AppLocker design guide
AppLocker deployment guide
AppLocker technical reference
BitLocker
Overview of BitLocker and device encryption in Windows 10
BitLocker frequently asked questions (FAQ)
Prepare your organization for BitLocker: Planning and policies
BitLocker basic deployment
BitLocker: How to deploy on Windows Server 2012 and later
BitLocker: Management recommendations for enterprises
BitLocker: How to enable Network Unlock
BitLocker: Use BitLocker Drive Encryption Tools to manage BitLocker
BitLocker: Use BitLocker Recovery Password Viewer
BitLocker Group Policy settings
BCD settings and BitLocker
BitLocker Recovery Guide
Protect BitLocker from pre-boot attacks
Protecting cluster shared volumes and storage area networks with BitLocker
Control the health of Windows 10-based devices
Device Guard deployment guide
Introduction to Device Guard: virtualization-based security and code integrity
policies
Requirements and deployment planning guidelines for Device Guard
Planning and getting started on the Device Guard deployment process
Deploy Device Guard: deploy code integrity policies
Deploy Device Guard: enable virtualization-based security
Encrypted Hard Drive
Security auditing
Basic security audit policies
Advanced security audit policies
Security policy settings
Administer security policy settings
Configure security policy settings
Security policy settings reference
Trusted Platform Module
Trusted Platform Module Overview
TPM fundamentals
How Windows 10 uses the TPM
TPM Group Policy settings
Back up the TPM recovery information to AD DS
Manage TPM commands
Manage TPM lockout
Change the TPM owner password
View status, clear, or troubleshoot the TPM
Understanding PCR banks on TPM 2.0 devices
TPM recommendations
Windows security baselines
Windows 10 Mobile security guide
Change history for device security
Device Security
6/20/2017 1 min to read Edit Online
Learn more about how to help secure your Windows 10 and Windows 10 Mobile devices.
SECTION DESCRIPTION
AppLocker Describes AppLocker, and can help you decide if your

organization can benefit from deploying AppLocker application
control policies. AppLocker helps you control which apps and
files users can run. These include executable files, scripts,
Windows Installer files, dynamic-link libraries (DLLs), packaged
apps, and packaged app installers.
BitLocker Provides information about BitLocker, which is a data

protection feature that integrates with the operating system
and addresses the threats of data theft or exposure from lost,
stolen, or inappropriately decommissioned computers.
Control the health of Windows 10-based devices Learn more about protecting high-value assets.
Device Guard deployment guide Device Guard is a combination of hardware and software
security features that, when configured together, will lock a
device down so that it can only run trusted applications. If the
app isnt trusted it cant run, period. It also means that even if
an attacker manages to get control of the Windows kernel, he
or she will be much less likely to be able to run malicious
executable code after the computer restarts because of how
decisions are made about what can run and when.
Encrypted Hard Drive Provides information about Encrypted Hard Drive, which uses
the rapid encryption that is provided by BitLocker Drive
Encryption to enhance data security and management.
Security auditing Describes how the IT professional can use the security auditing
features in Windows, and how organizations can benefit from
using these technologies, to enhance the security and
manageability of networks.
Security policy settings Provides a collection of reference topics that describe the
common scenarios, architecture, and processes for security
settings.
Trusted Platform Module Provides links to information about the Trusted Platform
Module (TPM), which is a secure crypto-processor that helps
you with actions such as generating, storing, and limiting the
use of cryptographic keys.
Windows 10 Mobile security guide Learn more about securing your Windows 10 Mobile devices.
Windows security baselines Learn why you should use security baselines in your
organization.
AppLocker
Applies to
Windows 10
This topic provides a description of AppLocker and can help you decide if your organization can benefit from
deploying AppLocker application control policies. AppLocker helps you control which apps and files users can run.
These include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and
packaged app installers.
AppLocker can help you:
Define rules based on file attributes that persist across app updates, such as the publisher name (derived from
the digital signature), product name, file name, and file version. You can also create rules based on the file path
and hash.
Assign a rule to a security group or an individual user.
Create exceptions to rules. For example, you can create a rule that allows all users to run all Windows binaries,
except the Registry Editor (regedit.exe).
Use audit-only mode to deploy the policy and understand its impact before enforcing it.
Create rules on a staging server, test them, then export them to your production environment and import them
into a Group Policy Object.
Simplify creating and managing AppLocker rules by using Windows PowerShell.
AppLocker helps reduce administrative overhead and helps reduce the organization's cost of managing computing
resources by decreasing the number of Help Desk calls that result from users running unapproved apps.
AppLocker addresses the following app security scenarios:
Application inventory
AppLocker has the ability to enforce its policy in an audit-only mode where all app access activity is
registered in event logs. These events can be collected for further analysis. Windows PowerShell cmdlets
also help you analyze this data programmatically.
Protection against unwanted software
AppLocker has the ability to deny apps from running when you exclude them from the list of allowed apps.
When AppLocker rules are enforced in the production environment, any apps that are not included in the
allowed rules are blocked from running.
Licensing conformance
AppLocker can help you create rules that preclude unlicensed software from running and restrict licensed
software to authorized users.
Software standardization
AppLocker policies can be configured to allow only supported or approved apps to run on computers
within a business group. This permits a more uniform app deployment.
Manageability improvement
AppLocker includes a number of improvements in manageability as compared to its predecessor Software
Restriction Policies. Importing and exporting policies, automatic generation of rules from multiple files,
audit-only mode deployment, and Windows PowerShell cmdlets are a few of the improvements over
Software Restriction Policies.
When to use AppLocker

In many organizations, information is the most valuable asset, and ensuring that only approved users have access
to that information is imperative. Access control technologies, such as Active Directory Rights Management
Services (AD RMS) and access control lists (ACLs), help control what users are allowed to access.
However, when a user runs a process, that process has the same level of access to data that the user has. As a
result, sensitive information could easily be deleted or transmitted out of the organization if a user knowingly or
unknowingly runs malicious software. AppLocker can help mitigate these types of security breaches by restricting
the files that users or groups are allowed to run. Software publishers are beginning to create more apps that can
be installed by non-administrative users. This could jeopardize an organization's written security policy and
circumvent traditional app control solutions that rely on the inability of users to install apps. By creating an
allowed list of approved files and apps, AppLocker helps prevent such per-user apps from running. Because
AppLocker can control DLLs, it is also useful to control who can install and run ActiveX controls.
AppLocker is ideal for organizations that currently use Group Policy to manage their PCs.
The following are examples of scenarios in which AppLocker can be used:
Your organization's security policy dictates the use of only licensed software, so you need to prevent users
from running unlicensed software and also restrict the use of licensed software to authorized users.
An app is no longer supported by your organization, so you need to prevent it from being used by everyone.
The potential that unwanted software can be introduced in your environment is high, so you need to reduce
this threat.
The license to an app has been revoked or it is expired in your organization, so you need to prevent it from
being used by everyone.
A new app or a new version of an app is deployed, and you need to prevent users from running the old version.
Specific software tools are not allowed within the organization, or only specific users should have access to
those tools.
A single user or small group of users needs to use a specific app that is denied for all others.
Some computers in your organization are shared by people who have different software usage needs, and you
need to protect specific apps.
In addition to other measures, you need to control the access to sensitive data through app usage.
AppLocker can help you protect the digital assets within your organization, reduce the threat of malicious software
being introduced into your environment, and improve the management of application control and the
maintenance of application control policies.
System requirements
AppLocker policies can only be configured on and applied to computers that are running on the supported
versions and editions of the Windows operating system. Group Policy is required to distribute Group Policy
Objects that contain AppLocker policies. For more info, see Requirements to Use AppLocker.
AppLocker rules can be created on domain controllers.
Installing AppLocker
AppLocker is included with enterprise-level editions of Windows. You can author AppLocker rules for a single
computer or for a group of computers. For a single computer, you can author the rules by using the Local Security
Policy editor (secpol.msc). For a group of computers, you can author the rules within a Group Policy Object by
using the Group Policy Management Console (GPMC).
Note: The GPMC is available in client computers running Windows only by installing the Remote Server
Administration Tools. On computer running Windows Server, you must install the Group Policy Management
feature.
Using AppLocker on Server Core

AppLocker on Server Core installations is not supported.
Virtualization considerations
You can administer AppLocker policies by using a virtualized instance of Windows provided it meets all the system
requirements listed previously. You can also run Group Policy in a virtualized instance. However, you do risk losing
the policies that you created and maintain if the virtualized instance is removed or fails.
Security considerations
Application control policies specify which apps are allowed to run on the local computer.
The variety of forms that malicious software can take make it difficult for users to know what is safe to run. When
activated, malicious software can damage content on a hard disk drive, flood a network with requests to cause a
denial-of-service (DoS) attack, send confidential information to the Internet, or compromise the security of a
computer.
The countermeasure is to create a sound design for your application control policies on PCs in your organization,
and then thoroughly test the policies in a lab environment before you deploy them in a production environment.
AppLocker can be part of your app control strategy because you can control what software is allowed to run on
your computers.
A flawed application control policy implementation can disable necessary applications or allow malicious or
unintended software to run. Therefore, it is important that organizations dedicate sufficient resources to manage
and troubleshoot the implementation of such policies.
For additional information about specific security issues, see Security considerations for AppLocker.
When you use AppLocker to create application control policies, you should be aware of the following security
considerations:
Who has the rights to set AppLocker policies?
How do you validate that the policies are enforced?
What events should you audit?
For reference in your security planning, the following table identifies the baseline settings for a PC with AppLocker
installed:
SETTING DEFAULT VALUE
Accounts created None
Authentication method Not applicable
Management interfaces AppLocker can be managed by using a Microsoft

Management Console snap-in, Group Policy Management,
and Windows PowerShell
Ports opened None

SETTING DEFAULT VALUE
Minimum privileges required Administrator on the local computer; Domain Admin, or any
set of rights that allow you to create, edit and distribute
Group Policy Objects.
Protocols used Not applicable
Scheduled Tasks Appidpolicyconverter.exe is put in a scheduled task to be run

on demand.
Security Policies None required. AppLocker creates security policies.
System Services required Application Identity service (appidsvc) runs under

LocalServiceAndNoImpersonation.
Storage of credentials None
In this section
TOPIC DESCRIPTION
Administer AppLocker This topic for IT professionals provides links to specific

procedures to use when administering AppLocker policies.
AppLocker design guide This topic for the IT professional introduces the design and
planning steps required to deploy application control policies
by using AppLocker.
AppLocker deployment guide This topic for IT professionals introduces the concepts and
describes the steps required to deploy AppLocker policies.
AppLocker technical reference This overview topic for IT professionals provides links to the
topics in the technical reference.
Applies to
Windows 10
This topic for IT professionals provides links to specific procedures to use when administering AppLocker policies.
AppLocker helps administrators control how users can access and use files, such as executable files, packaged
apps, scripts, Windows Installer files, and DLLs. Using AppLocker, you can:
Define rules based on file attributes derived from the digital signature, including the publisher, product name,
file name, and file version. For example, you can create rules based on the publisher attribute that is persistent
through updates, or you can create rules for a specific version of a file.
Create exceptions to rules. For example, you can create a rule that allows all Windows processes to run, except
Registry Editor (regedit.exe).
Import and export rules. The import and export affects the entire policy. For example, if you export a policy, all
of the rules from all of the rule collections are exported, including the enforcement settings for the rule
collections. If you import a policy, the existing policy is overwritten.
Simplify creating and managing AppLocker rules by using AppLocker PowerShell cmdlets. > Note For more
info about enhanced capabilities of AppLocker to control Windows apps, see Packaged apps and packaged app
installer rules in AppLocker.
In this section
TOPIC DESCRIPTION
Maintain AppLocker policies This topic describes how to maintain rules within AppLocker
policies.
Edit an AppLocker policy This topic for IT professionals describes the steps required to
modify an AppLocker policy.
Test and update an AppLocker policy This topic discusses the steps required to test an AppLocker
policy prior to deployment.
Deploy AppLocker policies by using the enforce rules setting This topic for IT professionals describes the steps to deploy
AppLocker policies by using the enforcement setting method.
Use the AppLocker Windows PowerShell cmdlets This topic for IT professionals describes how each AppLocker
Windows PowerShell cmdlet can help you administer your
AppLocker application control policies.
Use AppLocker and Software Restriction Policies in the same This topic for IT professionals describes concepts and
domain procedures to help you manage your application control
strategy using Software Restriction Policies and AppLocker.
TOPIC DESCRIPTION
Optimize AppLocker performance This topic for IT professionals describes how to optimize
AppLocker policy enforcement.
Monitor app usage with AppLocker This topic for IT professionals describes how to monitor app
usage when AppLocker policies are applied.
Manage packaged apps with AppLocker This topic for IT professionals describes concepts and lists
procedures to help you manage Packaged apps with
AppLocker as part of your overall application control strategy.
Working with AppLocker rules This topic for IT professionals describes AppLocker rule types
and how to work with them for your application control
policies.
Working with AppLocker policies This topic for IT professionals provides links to procedural
topics about creating, maintaining, and testing AppLocker
policies.
Using the MMC snap-ins to administer AppLocker

You can administer AppLocker policies by using the Group Policy Management Console to create or edit a Group
Policy Object (GPO), or to create or edit an AppLocker policy on a local computer by using the Local Group Policy
Editor snap-in or the Local Security Policy snap-in (secpol.msc).
Administer Applocker using Group Policy
You must have Edit Setting permission to edit a GPO. By default, members of the Domain Admins group, the
Enterprise Admins group, and the Group Policy Creator Owners group have this permission. Also, the Group
Policy Management feature must be installed on the computer.
1. Open the Group Policy Management Console (GPMC).
2. Locate the GPO that contains the AppLocker policy to modify, right-click the GPO, and then click Edit.
3. In the console tree, double-click Application Control Policies, double-click AppLocker, and then click the
rule collection that you want to create the rule for.
Administer AppLocker on the local PC
1. Click Start, type local security policy, and then click Local Security Policy.
2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then
click Yes.
3. In the console tree of the snap-in, double-click Application Control Policies, double-click AppLocker, and
then click the rule collection that you want to create the rule for.
Using Windows PowerShell to administer AppLocker

For how-to info about administering AppLocker with Windows PowerShell, see Use the AppLocker Windows
PowerShell Cmdlets. For reference info and examples how to administer AppLocker with Windows PowerShell,
see the AppLocker cmdlets.
Maintain AppLocker policies
Applies to
Windows 10
This topic describes how to maintain rules within AppLocker policies.
Common AppLocker maintenance scenarios include:
A new app is deployed, and you need to update an AppLocker policy.
A new version of an app is deployed, and you need to either update an AppLocker policy or create a new rule to
update the policy.
An app is no longer supported by your organization, so you need to prevent it from being used.
An app appears to be blocked but should be allowed.
An app appears to be allowed but should be blocked.
A single user or small subset of users needs to use a specific app that is blocked.
There are two methods you can use to maintain AppLocker policies:
Maintaining AppLocker policies by using Group Policy
Maintaining AppLocker policies on the local computer
As new apps are deployed or existing apps are removed by your organization or updated by the software
publisher, you might need to make revisions to your rules and update the Group Policy Object (GPO) to ensure that
your policy is current.
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot specify a version
for the AppLocker policy by importing additional rules. To ensure version control when modifying an AppLocker
policy, use Group Policy management software that allows you to create versions of GPOs.
Caution: You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because
AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected
behavior.
Maintaining AppLocker policies by using Group Policy

For every scenario, the steps to maintain an AppLocker policy distributed by Group Policy include the following
tasks.
Step 1: Understand the current behavior of the policy
Before modifying a policy, evaluate how the policy is currently implemented. For example, if a new version of the
application is deployed, you can use Test-AppLockerPolicy to verify the effectiveness of your current policy for
that app.
Step 2: Export the AppLocker policy from the GPO
Updating an AppLocker policy that is currently enforced in your production environment can have unintended
results. Therefore, export the policy from the GPO and update the rule or rules by using AppLocker on your
AppLocker reference or test computer. To prepare an AppLocker policy for modification, see Export an AppLocker
policy from a GPO.
Step 3: Update the AppLocker policy by editing the appropriate AppLocker rule
After the AppLocker policy has been exported from the GPO into the AppLocker reference or test computer, or has
been accessed on the local computer, the specific rules can be modified as required.
To modify AppLocker rules, see the following:
Edit AppLocker rules
Merge AppLocker policies by using Set-ApplockerPolicy or Merge AppLocker policies manually
Delete an AppLocker rule
Enforce AppLocker rules
Step 4: Test the AppLocker policy
You should test each collection of rules to ensure that the rules perform as intended. (Because AppLocker rules are
inherited from linked GPOs, you should deploy all rules for simultaneous testing in all test GPOs.) For steps to
perform this testing, see Test and update an AppLocker policy.
Step 5: Import the AppLocker policy into the GPO
After testing, import the AppLocker policy back into the GPO for implementation. To update the GPO with a
modified AppLocker policy, see Import an AppLocker policy into a GPO.
Step 6: Monitor the resulting policy behavior
After deploying a policy, evaluate the policy's effectiveness.
Maintaining AppLocker policies by using the Local Security Policy snap-

in
For every scenario, the steps to maintain an AppLocker policy by using the Local Group Policy Editor or the Local
Security Policy snap-in include the following tasks.
Step 1: Understand the current behavior of the policy
Before modifying a policy, evaluate how the policy is currently implemented.
Step 2: Update the AppLocker policy by modifying the appropriate AppLocker rule
Rules are grouped into a collection, which can have the policy enforcement setting applied to it. By default,
AppLocker rules do not allow users to open or run any files that are not specifically allowed.
To modify AppLocker rules, see the appropriate topic listed on Administer AppLocker.
Step 3: Test the AppLocker policy
You should test each collection of rules to ensure that the rules perform as intended. For steps to perform this
testing, see Test and update an AppLocker policy.
Step 4: Deploy the policy with the modified rule
You can export and then import AppLocker policies to deploy the policy to other computers running Windows 8 or
later. To perform this task, see Export an AppLocker policy to an XML file and Import an AppLocker policy from
another computer.
Step 5: Monitor the resulting policy behavior
After deploying a policy, evaluate the policy's effectiveness.
Additional resources
For steps to perform other AppLocker policy tasks, see Administer AppLocker.
Edit an AppLocker policy
Applies to
Windows 10
This topic for IT professionals describes the steps required to modify an AppLocker policy.
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot create a new
version of the policy by importing additional rules. To modify an AppLocker policy that is in production, you should
use Group Policy management software that allows you to version Group Policy Objects (GPOs). If you have
created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can either
manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You cannot automatically
merge policies by using the AppLocker snap-in. You must create one rule collection from two or more policies. The
AppLocker policy is saved in XML format, and the exported policy can be edited with any text or XML editor. For
info about merging policies, see Merge AppLocker policies manually or Merge AppLocker policies by using Set-
ApplockerPolicy.
There are two methods you can use to edit an AppLocker policy:
Editing an AppLocker policy by using Group Policy
Editing an AppLocker policy by using the Local Security Policy snap-in
Editing an AppLocker policy by using Group Policy

The steps to edit an AppLocker policy distributed by Group Policy include the following:
Step 1: Use Group Policy management software to export the AppLocker policy from the GPO
AppLocker provides a feature to export and import AppLocker policies as an XML file. This allows you to modify an
AppLocker policy outside your production environment. Because updating an AppLocker policy in a deployed GPO
could have unintended consequences, you should first export the AppLocker policy to an XML file. For the
procedure to do this, see Export an AppLocker policy from a GPO.
Step 2: Import the AppLocker policy into the AppLocker reference PC or the PC you use for policy
maintenance
After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that
you can edit the policy. For the procedure to import an AppLocker policy, see Import an AppLocker policy from
another computer.
Caution: Importing a policy onto another PC will overwrite the existing policy on that PC.
Step 3: Use AppLocker to modify and test the rule

AppLocker provides ways to modify, delete, or add rules to a policy by modifying the rules within the collection.
For the procedure to modify a rule, see Edit AppLocker rules.
For the procedure to delete a rule, see Delete an AppLocker rule.
For procedures to create rules, see:
Create a rule that uses a publisher condition
Create a rule that uses a path condition
Create a rule that uses a file hash condition
Enable the DLL rule collection
For steps to test an AppLocker policy, see Test and update an AppLocker policy.
For procedures to export the updated policy from the reference computer back into the GPO, see Export an
AppLocker policy to an XML file and Import an AppLocker policy into a GPO.
Step 4: Use AppLocker and Group Policy to import the AppLocker policy back into the GPO
For procedures to export the updated policy from the reference computer back into the GPO, see Export an
AppLocker policy to an XML file and Import an AppLocker policy into a GPO.
Caution: You should never edit an AppLocker rule collection while it is being enforced in Group Policy.
Because AppLocker controls what files are allowed run, making changes to a live policy can create unexpected
behavior. For info about testing policies, see Test and update an AppLocker policy.
Note: If you are performing these steps by using Microsoft Advanced Group Policy Management (AGPM),
check out the GPO before exporting the policy.
Editing an AppLocker policy by using the Local Security Policy snap-in

The steps to edit an AppLocker policy distributed by using the Local Security Policy snap-in (secpol.msc) include
the following tasks.
Step 1: Import the AppLocker policy
On the PC where you maintain policies, open the AppLocker snap-in from the Local Security Policy snap-in
(secpol.msc). If you exported the AppLocker policy from another PC, use AppLocker to import it onto the PC.
After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that
you can edit the policy. For the procedure to import an AppLocker policy, see Import an AppLocker policy from
another computer.
Caution: Importing a policy onto another PC will overwrite the existing policy on that PC.
Step 2: Identify and modify the rule to change, delete, or add

AppLocker provides ways to modify, delete, or add rules to a policy by modifying the rules within the collection.
For the procedure to modify a rule, see Edit AppLocker rules.
For the procedure to delete a rule, see Delete an AppLocker rule.
For procedures to create rules, see:
Step 3: Test the effect of the policy
For steps to test an AppLocker policy, see Test and update an AppLocker policy.
Step 4: Export the policy to an XML file and propagate it to all targeted computers
For procedures to export the updated policy from the reference computer to targeted computers, see Export an
AppLocker policy to an XML file and Import an AppLocker policy from another computer.
Test and update an AppLocker policy
Applies to
Windows 10
This topic discusses the steps required to test an AppLocker policy prior to deployment.
You should test each set of rules to ensure that the rules perform as intended. If you use Group Policy to manage
AppLocker policies, complete the following steps for each Group Policy Object (GPO) where you have created
AppLocker rules. Because AppLocker rules are inherited from linked GPOs, you should deploy all of the rules for
simultaneous testing in all of your test GPOs.
Step 1: Enable the Audit only enforcement setting

By using the Audit only enforcement setting, you can ensure that the AppLocker rules that you have created are
properly configured for your organization. This setting can be enabled on the Enforcement tab of the
AppLocker Properties dialog box. For the procedure to do this, see Configure an AppLocker policy for audit
only.
Step 2: Configure the Application Identity service to start

automatically
Because AppLocker uses the Application Identity service to verify the attributes of a file, you must configure it to
start automatically in any one GPO that applies AppLocker rules. For the procedure to do this, see Configure the
Application Identity Service. For AppLocker policies that are not managed by a GPO, you must ensure that the
service is running on each PC in order for the policies to be applied.
Step 3: Test the policy

Test the AppLocker policy to determine if your rule collection needs to be modified. Because you have created
AppLocker rules, enabled the Application Identity service, and enabled the Audit only enforcement setting, the
AppLocker policy should be present on all client PC that are configured to receive your AppLocker policy.
The Test-AppLockerPolicy Windows PowerShell cmdlet can be used to determine whether any of the rules in
your rule collection will be blocked on your reference PCs. For the procedure to do this, see Test an AppLocker
policy by using Test-AppLockerPolicy.
Step 4: Analyze AppLocker events

You can either manually analyze AppLocker events or use the Get-AppLockerFileInformation Windows
PowerShell cmdlet to automate the analysis.
To manually analyze AppLocker events
You can view the events either in Event Viewer or a text editor and then sort those events to perform an analysis,
such as looking for patterns in application usage events, access frequencies, or access by user groups. If you have
not configured an event subscription, then you will have to review the logs on a sampling of computers in your
organization. For more information about using Event Viewer, see Monitor application usage with AppLocker.
To analyze AppLocker events by using Get-AppLockerFileInformation
You can use the Get-AppLockerFileInformation Windows PowerShell cmdlet to analyze AppLocker events
from a remote computer. If an app is being blocked and should be allowed, you can use the AppLocker cmdlets to
help troubleshoot the problem.
For both event subscriptions and local events, you can use the Get-AppLockerFileInformation cmdlet to
determine which files have been blocked or would have been blocked (if you are using the Audit only
enforcement mode) and how many times the event has occurred for each file. For the procedure to do this, see
Monitor Application Usage with AppLocker.
After using Get-AppLockerFileInformation to determine how many times that a file would have been blocked
from running, you should review your rule list to determine whether a new rule should be created for the blocked
file or whether an existing rule is too strictly defined. Ensure that you check which GPO is currently preventing the
file from running. To determine this, you can use the Group Policy Results Wizard to view rule names.
Step 5: Modify the AppLocker policy

After you have identified which rules need to be edited or added to the policy, you can use the Group Policy
Management Console to modify the AppLocker rules in the relevant GPOs. For AppLocker policies that are not
managed by a GPO, you can use the Local Security Policy snap-in (secpol.msc). For info how to modify an
AppLocker policy, see, Edit an AppLocker policy.
Step 6: Repeat policy testing, analysis, and policy modification

Repeat the previous steps 35 until all the rules perform as intended before applying enforcement.
Deploy AppLocker policies by using the enforce rules
setting
Applies to
Windows 10
This topic for IT professionals describes the steps to deploy AppLocker policies by using the enforcement setting
method.
Background and prerequisites

These procedures assume that you have already deployed AppLocker policies with the enforcement set to Audit
only, and you have been collecting data through the AppLocker event logs and other channels to determine what
effect these policies have on your environment and the policy's adherence to your application control design.
For info about the AppLocker policy enforcement setting, see Understand AppLocker enforcement settings.
For info about how to plan an AppLocker policy deployment, see AppLocker Design Guide.
Step 1: Retrieve the AppLocker policy

results. Using Group Policy, you can export the policy from the Group Policy Object (GPO) and then update the rule
or rules by using AppLocker on your AppLocker reference or test PC. For the procedure to do this, see Export an
AppLocker policy from a GPO and Import an AppLocker policy into a GPO. For local AppLocker policies, you can
update the rule or rules by using the Local Security policy snap-in (secpol.msc) on your AppLocker reference or test
PC. For the procedures to do this, see Export an AppLocker policy to an XML file and Import an AppLocker policy
from another computer.
Step 2: Alter the enforcement setting

Rule enforcement is applied only to a collection of rules, not to individual rules. AppLocker divides the rules into
collections: executable files, Windows Installer files, packaged apps, scripts, and DLL files. By default, if enforcement
is not configured and rules are present in a rule collection, those rules are enforced. For information about the
enforcement setting, see Understand AppLocker Enforcement Settings. For the procedure to alter the enforcement
setting, see Configure an AppLocker policy for audit only.
Step 3: Update the policy

for the AppLocker policy by importing additional rules. To ensure version control when modifying an AppLocker
policy, use Group Policy management software that allows you to create versions of GPOs. An example of this type
of software is the Advanced Group Policy Management feature from the Microsoft Desktop Optimization Pack.
behavior.
For the procedure to update the GPO, see Import an AppLocker policy into a GPO.
For the procedures to distribute policies for local PCs by using the Local Security Policy snap-in (secpol.msc), see
Export an AppLocker policy to an XML file and Import an AppLocker policy from another computer.
Step 4: Monitor the effect of the policy

When a policy is deployed, it is important to monitor the actual implementation of that policy. You can do this by
monitoring your support organization's app access request activity and reviewing the AppLocker event logs. To
monitor the effect of the policy, see Monitor Application Usage with AppLocker.
Use the AppLocker Windows PowerShell cmdlets
Applies to
Windows 10
This topic for IT professionals describes how each AppLocker Windows PowerShell cmdlet can help you administer
your AppLocker application control policies.
AppLocker Windows PowerShell cmdlets

The five AppLocker cmdlets are designed to streamline the administration of an AppLocker policy. They can be
used to help create, test, maintain, and troubleshoot an AppLocker policy. The cmdlets are intended to be used in
conjunction with the AppLocker user interface that is accessed through the Microsoft Management Console (MMC)
snap-in extension to the Local Security Policy snap-in and Group Policy Management Console.
To edit or update a Group Policy Object (GPO) by using the AppLocker cmdlets, you must have Edit Setting
permission. By default, members of the Domain Admins group, the Enterprise Admins group, and the Group
Policy Creator Owners group have this permission. To perform tasks by using the Local Security policy snap-in,
you must be a member of the local Administrators group, or equivalent, on the computer.
Retrieve application information
The Get-AppLockerFileInformation cmdlet retrieves the AppLocker file information from a list of files or from an
event log. File information that is retrieved can include publisher information, file hash information, and file path
information.
File information from an event log may not contain all of these fields. Files that are not signed do not have any
publisher information.
Set AppLocker policy
The Set-AppLockerPolicy cmdlet sets the specified GPO to contain the specified AppLocker policy. If no Lightweight
Directory Access Protocol (LDAP) is specified, the local GPO is the default.
Retrieve an AppLocker policy
The Get-AppLockerPolicy cmdlet gets the AppLocker policy from the local GPO, from a specified GPO, or from the
effective AppLocker policy on the device. The output of the AppLocker policy is an AppLockerPolicy object or an
XML-formatted string.
Generate rules for a given user or group
The New-AppLockerPolicy cmdlet uses a list of file information to automatically generate rules for a given user or
group. It can generate rules based on publisher, hash, or path information. Use Get-AppLockerFileInformation
to create the list of file information.
Test the AppLocker Policy against a file set
The Test-AppLockerPolicy cmdlet uses the specified AppLocker policy to test whether a specified list of files are
allowed to run or not on the local device for a specific user.
Use AppLocker and Software Restriction Policies in
the same domain
Applies to
Windows 10
This topic for IT professionals describes concepts and procedures to help you manage your application control
strategy using Software Restriction Policies and AppLocker.
Using AppLocker and Software Restriction Policies in the same domain

AppLocker is supported on systems running Windows 7 and above. Software Restriction Policies (SRP) is
supported on systems running Windows Vista or earlier. You can continue to use SRP for application control on
your pre-Windows 7 computers, but use AppLocker for computers running Windows Server 2008 R2, Windows 7
and later. It is recommended that you author AppLocker and SRP rules in separate GPOs and target the GPO with
SRP policies to systems running Windows Vista or earlier. When both SRP and AppLocker policies are applied to
computers running Windows Server 2008 R2, Windows 7 and later, the SRP policies are ignored.
The following table compares the features and functions of Software Restriction Policies (SRP) and AppLocker.
APPLICATION CONTROL FUNCTION SRP APPLOCKER
Scope SRP policies can be applied to all AppLocker policies apply only to
Windows operating systems Windows Server 2008 R2, Windows
beginning with Windows XP and 7, and later.
Windows Server 2003.
Policy creation SRP policies are maintained through AppLocker policies are maintained
Group Policy and only the through Group Policy and only the
administrator of the GPO can administrator of the GPO can
update the SRP policy. The update the policy. The
administrator on the local computer administrator on the local computer
can modify the SRP policies defined can modify the AppLocker policies
in the local GPO. defined in the local GPO.
AppLocker permits customization of
error messages to direct users to a
Web page for help.
Policy maintenance SRP policies must be updated by AppLocker policies can be updated
using the Local Security Policy by using the Local Security Policy
snap-in (if the policies are created snap-in (if the policies are created
locally) or the Group Policy locally), or the GPMC, or the
Management Console (GPMC). Windows PowerShell AppLocker
cmdlets.
Policy application SRP policies are distributed through AppLocker policies are distributed
Group Policy. through Group Policy.
Enforcement mode SRP works in the deny list mode AppLocker by default works in the
where administrators can create allow list mode where only those
rules for files that they do not want files are allowed to run for which
to allow in this Enterprise whereas there is a matching allow rule.
the rest of the file are allowed to
run by default.
SRP can also be configured in the
allow list mode so that by default
all files are blocked and
administrators need to create allow
rules for files that they want to
allow.
File types that can be controlled SRP can control the following file AppLocker can control the following
types: file types:
Executables Executables
Dlls Dlls
Scripts Scripts
Windows Installers Windows Installers
SRP cannot control each file type Packaged apps and installers
separately. All SRP rules are in a
single rule collection. AppLocker maintains a separate
rule collection for each of the five
file types.
Designated file types SRP supports an extensible list of AppLocker currently supports the
file types that are considered following file extensions:
executable. Administrators can add
extensions for files that should be Executables (.exe, .com)
considered executable. Dlls (.ocx, .dll)
Scripts (.vbs, .js, .ps1, .cmd,
.bat)
Windows Installers (.msi,
.mst, .msp)
Packaged app installers
(.appx)
Rule types SRP supports four types of rules: AppLocker supports three types of
rules:
Hash
File hash
Path
Path
Signature
Publisher
Internet zone
Editing the hash value In Windows XP, you could use SRP AppLocker computes the hash
to provide custom hash values. value itself. Internally, it uses the
SHA2 Authenticode hash for
Beginning with Windows 7 and Portable Executables (exe and dll)
Windows Server 2008 R2, you can and Windows Installers and a SHA2
only select the file to hash, not flat file hash for the rest.
provide the hash value.
Support for different security levels With SRP, you can specify the AppLocker does not support
permissions with which an app can security levels.
run. So, you can configure a rule
such that Notepad always runs with
restricted permissions and never
with administrative privileges.
SRP on Windows Vista and earlier
supported multiple security levels.
On Windows 7, that list was
restricted to just two levels:
Disallowed and Unrestricted (Basic
User translates to Disallowed).
Manage Packaged apps and Not supported .appx is a valid file type which
Packaged app installers. AppLocker can manage.
Targeting a rule to a user or a SRP rules apply to all users on a AppLocker rules can be targeted to
group of users particular computer. a specific user or a group of users.
Support for rule exceptions SRP does not support rule AppLocker rules can have
exceptions. exceptions which allow you to
create rules such as Allow
everything from Windows except
for regedit.exe.
Support for audit mode SRP does not support audit mode. AppLocker supports audit mode
The only way to test SRP policies is which allows you to test the effect
to set up a test environment and of their policy in the real production
run a few experiments. environment without impacting the
user experience. Once you are
satisfied with the results, you can
start enforcing the policy.
Support for exporting and SRP does not support policy AppLocker supports the importing
importing policies import/export. and exporting of policies. This
allows you to create AppLocker
policy on a sample device, test it
out and then export that policy and
import it back into the desired
GPO.
Rule enforcement Internally, SRP rules enforcement Internally, AppLocker rules for .exe
happens in the user-mode which is and .dll files are enforced in the
less secure. kernel-mode which is more secure
than enforcing them in the user-
mode.
Optimize AppLocker performance
Applies to
Windows 10
This topic for IT professionals describes how to optimize AppLocker policy enforcement.
Optimization of Group Policy

AppLocker policies can be implemented by organization unit (OU) using Group Policy. If so, your Group Policy
infrastructure should be optimized and retested for performance when AppLocker policies are added to existing
Group Policy Objects (GPOs) or new GPOs are created, as you do with adding any policies to your GPOs.
For more info, see the Optimizing Group Policy Performance article in TechNet Magazine.
AppLocker rule limitations
The more rules per GPO, the longer AppLocker requires for evaluation. There is no set limitation on the number of
rules per GPO, but the number of rules that can fit into a 100 MB GPO varies based on the complexity of the rule,
such as the number of file hashes included in a single file hash condition.
Using the DLL rule collection
When the DLL rule collection is enabled, AppLocker must check each DLL that an application loads. The more DLLs,
the longer AppLocker requires to complete the evaluation.
Monitor app usage with AppLocker
Applies to
Windows 10
This topic for IT professionals describes how to monitor app usage when AppLocker policies are applied.
Once you set rules and deploy the AppLocker policies, it is good practice to determine if the policy
implementation is what you expected.
Discover the effect of an AppLocker policy
You can evaluate how the AppLocker policy is currently implemented for documentation or audit purposes, or
before you modify the policy. Updating your AppLocker Policy Deployment Planning document will help you
track your findings. For information about creating this document, see Create your AppLocker planning
document. You can perform one or more of the following steps to understand what application controls are
currently enforced through AppLocker rules.
Analyze the AppLocker logs in Event Viewer
When AppLocker policy enforcement is set to Enforce rules, rules are enforced for the rule collection and
all events are audited. When AppLocker policy enforcement is set to Audit only, rules are not enforced
but are still evaluated to generate audit event data that is written to the AppLocker logs.
For the procedure to access the log, see View the AppLocker Log in Event Viewer.
Enable the Audit only AppLocker enforcement setting
By using the Audit only enforcement setting, you can ensure that the AppLocker rules are properly
configured for your organization. When AppLocker policy enforcement is set to Audit only, rules are only
evaluated but all events generated from that evaluation are written to the AppLocker log.
For the procedure to do this, see Configure an AppLocker policy for audit only.
Review AppLocker events with Get-AppLockerFileInformation
For both event subscriptions and local events, you can use the Get-AppLockerFileInformation Windows
PowerShell cmdlet to determine which files have been blocked or would have been blocked (if you are
using the audit-only enforcement mode) and how many times the event has occurred for each file.
For the procedure to do this, see Review AppLocker Events with Get-AppLockerFileInformation.
Review AppLocker events with Test-AppLockerPolicy
You can use the Test-AppLockerPolicy Windows PowerShell cmdlet to determine whether any of the
rules in your rule collections will be blocked on your reference device or the device on which you maintain
policies.
For the procedure to do this, see Test an AppLocker policy by using Test-AppLockerPolicy.
Review AppLocker events with Get-AppLockerFileInformation
For both event subscriptions and local events, you can use the Get-AppLockerFileInformation Windows
PowerShell cmdlet to determine which files have been blocked or would have been blocked (if the Audit only
enforcement setting is applied) and how many times the event has occurred for each file.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this
procedure.
Note: If the AppLocker logs are not on your local device, you will need permission to view the logs. If the
output is saved to a file, you will need permission to read that file.
To review AppLocker events with Get-AppLockerFileInformation

1. At the command prompt, type PowerShell, and then press ENTER.
2. Run the following command to review how many times a file would have been blocked from running if
rules were enforced:
Get-AppLockerFileInformation EventLog EventType Audited Statistics
3. Run the following command to review how many times a file has been allowed to run or prevented from
running:
Get-AppLockerFileInformation EventLog EventType Allowed Statistics
View the AppLocker Log in Event Viewer

When AppLocker policy enforcement is set to Enforce rules, rules are enforced for the rule collection and all
events are audited. When AppLocker policy enforcement is set to Audit only, rules are only evaluated but all
events generated from that evaluation are written to the AppLocker log.
procedure.
To view events in the AppLocker log by using Event Viewer
1. Open Event Viewer. To do this, click Start, type eventvwr.msc, and then press ENTER.
2. In the console tree under Application and Services Logs\Microsoft\Windows, double-click AppLocker.
AppLocker events are listed in either the EXE and DLL log, the MSI and Script log, or the Packaged app-
Deployment or Packaged app-Execution log. Event information includes the enforcement setting, file name,
date and time, and user name. The logs can be exported to other file formats for further analysis.
Related topics
AppLocker
Manage packaged apps with AppLocker
Applies to
Windows 10
This topic for IT professionals describes concepts and lists procedures to help you manage Packaged apps with
AppLocker as part of your overall application control strategy.
Understanding Packaged apps and Packaged app installers for

AppLocker
Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an
app package share the same identity. With classic Windows apps, each file within the app could have a unique
identity. With packaged apps, it is possible to control the entire app by using a single AppLocker rule.
Note: AppLocker supports only publisher rules for packaged apps. All packaged apps must be signed by the
software publisher because Windows does not support unsigned packaged apps.
Typically, an app consists of multiple components: the installer that is used to install the app, and one or more exes,
dlls, or scripts. With classic Windows apps, not all these components always share common attributes such as the
softwares publisher name, product name, and product version. Therefore, AppLocker controls each of these
components separately through different rule collections, such as exe, dll, script, and Windows Installer rules. In
contrast, all the components of a packaged app share the same publisher name, package name, and package
version attributes. Therefore, you can control an entire app with a single rule.
Comparing classic Windows apps and packaged apps
AppLocker policies for packaged apps can only be applied to apps installed on computers running at least
Windows Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least
Windows Server 2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be enforced in
tandem. The differences between packaged apps and classic Windows apps that you should consider include:
Installing the apps All packaged apps can be installed by a standard user, whereas a number of classic
Windows apps require administrative privileges to install. In an environment where most of the users are
standard users, you might not have numerous exe rules (because classic Windows apps require administrative
privileges to install), but you might want to have more explicit policies for packaged apps.
Changing the system state Classic Windows apps can be written to change the system state if they are run
with administrative privileges. Most packaged apps cannot change the system state because they run with
limited privileges. When you design your AppLocker policies, it is important to understand whether an app that
you are allowing can make system-wide changes.
Acquiring the apps Packaged apps can be acquired through the Store, or by loading using Windows
PowerShell cmdlets (which requires a special enterprise license). Classic Windows apps can be acquired through
traditional means.
AppLocker uses different rule collections to control packaged apps and classic Windows apps. You have the choice
to control one type, the other type, or both.
For info about controlling classic Windows apps, see Administer AppLocker.
For more info about packaged apps, see Packaged apps and packaged app installer rules in AppLocker.
Design and deployment decisions
You can use two methods to create an inventory of packaged apps on a computer: the AppLocker console or the
Get-AppxPackage Windows PowerShell cmdlet.
Note: Not all packaged apps are listed in AppLockers application inventory wizard. Certain app packages are
framework packages that are leveraged by other apps. By themselves, these packages cannot do anything, but
blocking such packages can inadvertently cause failure for apps that you want to allow. Instead, you can create
Allow or Deny rules for the packaged apps that use these framework packages. The AppLocker user interface
deliberately filters out all the packages that are registered as framework packages. For info about how to create
an inventory list, see Create list of apps deployed to each business group.
For info about how to use the Get-AppxPackage Windows PowerShell cmdlet, see the AppLocker PowerShell
Command Reference.
For info about creating rules for Packaged apps, see Create a rule for packaged apps.
Consider the following info when you are designing and deploying apps:
Because AppLocker supports only publisher rules for packaged apps, collecting the installation path information
for packaged apps is not necessary.
You cannot create hash- or path-based rules for packaged apps because all packaged apps and packaged app
installers are signed by the software publisher of the package. Classic Windows apps were not always
consistently signed; therefore, AppLocker has to support hash- or path-based rules.
By default, if there are no rules in a particular rule collection, AppLocker allows every file that is included in
that rule collection. For example, if there are no Windows Installer rules, AppLocker allows all .msi, .msp, and
.mst files to run. An existing AppLocker policy that was targeted at computers running Windows Server 2008
R2 and Windows 7 would not have rules for Packaged apps. Therefore, when a computer running at least
Windows Server 2012 or Windows 8 joins a domain where an AppLocker policy is already configured, users
would be allowed to run any packaged app. This might be contrary to your design.
To prevent all packaged apps from running on a newly domain-joined computer, by default AppLocker
blocks all packaged apps on a computer running at least Windows Server 2012 or Windows 8 if the existing
domain policy has rules configured in the exe rule collection. You must take explicit action to allow packaged
apps in your enterprise. You can allow only a select set of packaged apps. Or if you want to allow all
packaged apps, you can create a default rule for the packaged apps collection.
Using AppLocker to manage packaged apps

Just as there are differences in managing each rule collection, you need to manage the packaged apps with the
following strategy:
1. Gather information about which Packaged apps are running in your environment. For information about
how to do this, see Create list of apps deployed to each business group.
2. Create AppLocker rules for specific packaged apps based on your policy strategies. For more information,
see Create a rule for packaged apps and Packaged Apps Default Rules in AppLocker.
3. Continue to update the AppLocker policies as new package apps are introduced into your environment. To
do this, see Add rules for packaged apps to existing AppLocker rule-set.
4. Continue to monitor your environment to verify the effectiveness of the rules that are deployed in
AppLocker policies. To do this, see Monitor app usage with AppLocker.
Working with AppLocker rules
Applies to
Windows 10
This topic for IT professionals describes AppLocker rule types and how to work with them for your application
control policies.
In this section
TOPIC DESCRIPTION
Create a rule that uses a file hash condition This topic for IT professionals shows how to create an
AppLocker rule with a file hash condition.
Create a rule that uses a path condition This topic for IT professionals shows how to create an
AppLocker rule with a path condition.
Create a rule that uses a publisher condition This topic for IT professionals shows how to create an
AppLocker rule with a publisher condition.
Create AppLocker default rules This topic for IT professionals describes the steps to create a
standard set of AppLocker rules that will allow Windows
system files to run.
Add exceptions for an AppLocker rule This topic for IT professionals describes the steps to specify
which apps can or cannot run as exceptions to an AppLocker
rule.
Create a rule for packaged apps This topic for IT professionals shows how to create an
AppLocker rule for packaged apps with a publisher condition.
Delete an AppLocker rule This topic for IT professionals describes the steps to delete an
AppLocker rule.
Edit AppLocker rules This topic for IT professionals describes the steps to edit a
publisher rule, path rule, and file hash rule in AppLocker.
Enable the DLL rule collection This topic for IT professionals describes the steps to enable the
DLL rule collection feature for AppLocker.
Enforce AppLocker rules This topic for IT professionals describes how to enforce
application control rules by using AppLocker.
Run the Automatically Generate Rules wizard This topic for IT professionals describes steps to run the wizard
to create AppLocker rules on a reference device.
The three AppLocker enforcement modes are described in the following table. The enforcement mode setting
defined here can be overwritten by the setting derived from a linked Group Policy Object (GPO) with a higher
precedence.
ENFORCEMENT MODE DESCRIPTION
Not configured This is the default setting which means that the rules defined
here will be enforced unless a linked GPO with a higher
precedence has a different value for this setting.
Enforce rules Rules are enforced.
Audit only Rules are audited but not enforced. When a user runs an app
that is affected by an AppLocker rule, the app is allowed to
run and the info about the app is added to the AppLocker
event log. The Audit-only enforcement mode helps you
determine which apps will be affected by the policy before the
policy is enforced. When the AppLocker policy for a rule
collection is set to Audit only, rules for that rule collection are
not enforced
When AppLocker policies from various GPOs are merged, the rules from all the GPOs are merged and the
enforcement mode setting of the winning GPO is applied.
Rule collections
The AppLocker console is organized into rule collections, which are executable files, scripts, Windows Installer files,
packaged apps and packaged app installers, and DLL files. These collections give you an easy way to differentiate
the rules for different types of apps. The following table lists the file formats that are included in each rule
collection.
RULE COLLECTION ASSOCIATED FILE FORMATS
Executable files .exe

.com
Scripts .ps1
.bat
.cmd
.vbs
.js
Windows Installer files .msi

.msp
.mst
Packaged apps and packaged app installers .appx
DLL files .dll

.ocx
Important: If you use DLL rules, you need to create an allow rule for each DLL that is used by all of the allowed
apps.
When DLL rules are used, AppLocker must check each DLL that an application loads. Therefore, users may
experience a reduction in performance if DLL rules are used.
The DLL rule collection is not enabled by default. To learn how to enable the DLL rule collection, see DLL rule
collections.
Rule conditions
Rule conditions are criteria that help AppLocker identify the apps to which the rule applies. The three primary rule
conditions are publisher, path, and file hash.
Publisher: Identifies an app based on its digital signature
Path: Identifies an app by its location in the file system of the computer or on the network
File hash: Represents the system computed cryptographic hash of the identified file
Publisher
This condition identifies an app based on its digital signature and extended attributes when available. The digital
signature contains info about the company that created the app (the publisher). Executable files, dlls, Windows
installers, packaged apps and packaged app installers also have extended attributes, which are obtained from the
binary resource. In case of executable files, dlls and Windows installers, these attributes contain the name of the
product that the file is a part of, the original name of the file as supplied by the publisher, and the version number
of the file. In case of packaged apps and packaged app installers, these extended attributes contain the name and
the version of the app package.
Note: Rules created in the packaged apps and packaged app installers rule collection can only have publisher
conditions since Windows does not support unsigned packaged apps and packaged app installers.
Note: Use a publisher rule condition when possible because they can survive app updates as well as a change
in the location of files.
When you select a reference file for a publisher condition, the wizard creates a rule that specifies the publisher,
product, file name, and version number. You can make the rule more generic by moving the slider up or by using a
wildcard character (*) in the product, file name, or version number fields.
Note: To enter custom values for any of the fields of a publisher rule condition in the Create Rules Wizard, you
must select the Use custom values check box. When this check box is selected, you cannot use the slider.
The File version and Package version control whether a user can run a specific version, earlier versions, or later
versions of the app. You can choose a version number and then configure the following options:
Exactly. The rule applies only to this version of the app
And above. The rule applies to this version and all later versions.
And below. The rule applies to this version and all earlier versions.
The following table describes how a publisher condition is applied.
OPTION THE PUBLISHER CONDITION ALLOWS OR DENIES
All signed files All files that are signed by any publisher.
Publisher only All files that are signed by the named publisher.
Publisher and product name All files for the specified product that are signed by the named
publisher.
Publisher and product name, and file name Any version of the named file or package for the named
product that are signed by the publisher.
Publisher, product name, file name, and file version Exactly

The specified version of the named file or package for the
named product that are signed by the publisher.
Publisher, product name, file name, and file version And above
The specified version of the named file or package and any
new releases for the product that are signed by the publisher.
Publisher, product name, file name, and file version And below
The specified version of the named file or package and any
earlier versions for the product that are signed by the
publisher.
Custom You can edit the Publisher, Product name, File name,
Version Package name, and Package version fields to
create a custom rule.
Path
This rule condition identifies an application by its location in the file system of the computer or on the network.
AppLocker uses custom path variables for well-known paths, such as Program Files and Windows.
The following table details these path variables.
WINDOWS DIRECTORY OR DISK APPLOCKER PATH VARIABLE WINDOWS ENVIRONMENT VARIABLE
Windows %WINDIR% %SystemRoot%
System32 %SYSTEM32% %SystemDirectory%
Windows installation directory %OSDRIVE% %SystemDrive%
Program Files %PROGRAMFILES% %ProgramFiles% and

%ProgramFiles(x86)%
Removable media (for example, a CD or %REMOVABLE%

DVD)
Removable storage device (for example, %HOT%

a USB flash drive)
Important: Because a path rule condition can be configured to include a large number of folders and files, path
conditions should be carefully planned. For example, if an allow rule with a path condition includes a folder
location that non-administrators are allowed to write data into, a user can copy unapproved files into that
location and run the files. For this reason, it is a best practice to not create path conditions for standard user
writable locations, such as a user profile.
File hash
When you choose the file hash rule condition, the system computes a cryptographic hash of the identified file. The
advantage of this rule condition is that because each file has a unique hash, a file hash rule condition applies to
only one file. The disadvantage is that each time the file is updated (such as a security update or upgrade) the file's
hash will change. As a result, you must manually update file hash rules.
AppLocker default rules
AppLocker includes default rules, which are intended to help ensure that the files that are required for Windows to
operate properly are allowed in an AppLocker rule collection. For background, see Understanding AppLocker
default rules, and for steps, see Create AppLocker default rules.
Executable default rule types include:
Allow members of the local Administrators group to run all apps.
Allow members of the Everyone group to run apps that are located in the Windows folder.
Allow members of the Everyone group to run apps that are located in the Program Files folder.
Script default rule types include:
Allow members of the local Administrators group to run all scripts.
Allow members of the Everyone group to run scripts that are located in the Program Files folder.
Allow members of the Everyone group to run scripts that are located in the Windows folder.
Windows Installer default rule types include:
Allow members of the local Administrators group to run all Windows Installer files.
Allow members of the Everyone group to run all digitally signed Windows Installer files.
Allow members of the Everyone group to run all Windows Installer files that are located in the
Windows\Installer folder.
DLL default rule types:
Allow members of the local Administrators group to run all DLLs.
Allow members of the Everyone group to run DLLs that are located in the Program Files folder.
Allow members of the Everyone group to run DLLs that are located in the Windows folder.
Packaged apps default rule types:
Allow members of the Everyone group to install and run all signed packaged apps and packaged app installers.
AppLocker rule behavior

If no AppLocker rules for a specific rule collection exist, all files with that file format are allowed to run. However,
when an AppLocker rule for a specific rule collection is created, only the files explicitly allowed in a rule are
permitted to run. For example, if you create an executable rule that allows .exe files in %SystemDrive%\FilePath to
run, only executable files located in that path are allowed to run.
A rule can be configured to use allow or deny actions:
Allow. You can specify which files are allowed to run in your environment, and for which users or groups of
users. You can also configure exceptions to identify files that are excluded from the rule.
Deny. You can specify which files are not allowed to run in your environment, and for which users or groups of
Important: For a best practice, use allow actions with exceptions. You can use a combination of allow and deny
actions but understand that deny actions override allow actions in all cases, and can be circumvented.
Important: If you join a computer running at least Windows Server 2012 or Windows 8 to a domain that
already enforces AppLocker rules for executable files, users will not be able to run any packaged apps unless
you also create rules for packaged apps. If you want to allow any packaged apps in your environment while
continuing to control executable files, you should create the default rules for packaged apps and set the
enforcement mode to Audit-only for the packaged apps rule collection.
Rule exceptions
You can apply AppLocker rules to individual users or to a group of users. If you apply a rule to a group of users, all
users in that group are affected by that rule. If you need to allow a subset of a user group to use an app, you can
create a special rule for that subset. For example, the rule "Allow everyone to run Windows except Registry Editor"
allows everyone in the organization to run the Windows operating system, but it does not allow anyone to run
Registry Editor.
The effect of this rule would prevent users such as Help Desk personnel from running a program that is necessary
for their support tasks. To resolve this problem, create a second rule that applies to the Help Desk user group:
"Allow Help Desk to run Registry Editor." If you create a deny rule that does not allow any users to run Registry
Editor, the deny rule will override the second rule that allows the Help Desk user group to run Registry Editor.
DLL rule collection

Because the DLL rule collection is not enabled by default, you must perform the following procedure before you
can create and enforce DLL rules.
procedure.
To enable the DLL rule collection
1. Click Start, type secpol.msc, and then press ENTER.
2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then
click Yes.
3. In the console tree, double-click Application Control Policies, right-click AppLocker, and then click
Properties.
4. Click the Advanced tab, select the Enable the DLL rule collection check box, and then click OK.
Important: Before you enforce DLL rules, make sure that there are allow rules for each DLL that is used
by any of the allowed apps.
AppLocker wizards
You can create rules by using two AppLocker wizards:
1. The Create Rules Wizard enables you to create one rule at a time.
2. The Automatically Generate Rules Wizard allows you to create multiple rules at one time. You can either select a
folder and let the wizard create rules for the relevant files within that folder or in case of packaged apps let the
wizard create rules for all packaged apps installed on the computer. You can also specify the user or group to
which to apply the rules. This wizard automatically generates allow rules only.
Additional considerations
By default, AppLocker rules do not allow users to open or run any files that are not specifically allowed.
Administrators should maintain an up-to-date list of allowed applications.
There are two types of AppLocker conditions that do not persist following an update of an app:
A file hash condition File hash rule conditions can be used with any app because a cryptographic
hash value of the app is generated at the time the rule is created. However, the hash value is specific
to that exact version of the app. If there are several versions of the application in use within the
organization, you need to create file hash conditions for each version in use and for any new versions
that are released.
A publisher condition with a specific product version set If you create a publisher rule condition
that uses the Exactly version option, the rule cannot persist if a new version of the app is installed. A
new publisher condition must be created, or the version must be edited in the rule to be made less
specific.
If an app is not digitally signed, you cannot use a publisher rule condition for that app.
AppLocker rules cannot be used to manage computers running a Windows operating system earlier than
Windows Server 2008 R2 or Windows 7. Software Restriction Policies must be used instead. If AppLocker rules
are defined in a Group Policy Object (GPO), only those rules are applied. To ensure interoperability between
Software Restriction Policies rules and AppLocker rules, define Software Restriction Policies rules and
AppLocker rules in different GPOs.
The packaged apps and packaged apps installer rule collection is available on devices running at least Windows
Server 2012 and Windows 8.
When the rules for the executable rule collection are enforced and the packaged apps and packaged app
installers rule collection does not contain any rules, no packaged apps and packaged app installers are allowed
to run. In order to allow any packaged apps and packaged app installers, you must create rules for the packaged
apps and packaged app installers rule collection.
When an AppLocker rule collection is set to Audit only, the rules are not enforced. When a user runs an
application that is included in the rule, the app is opened and runs normally, and information about that app is
added to the AppLocker event log.
A custom configured URL can be included in the message that is displayed when an app is blocked.
Expect an increase in the number of Help Desk calls initially because of blocked apps until users understand that
they cannot run apps that are not allowed.
Applies to
Windows 10
This topic for IT professionals shows how to create an AppLocker rule with a file hash condition.
File hash rules use a system-computed cryptographic hash of the identified file.
For info about the file hash condition, see Understanding the File Hash Rule Condition in AppLocker.
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group
Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in
a security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer AppLocker.
To create a new rule with a file hash condition
1. Open the AppLocker console, and then click the rule collection that you want to create the rule for.
2. On the Action menu, click Create New Rule.
3. On the Before You Begin page, click Next.
4. On the Permissions page, select the action (allow or deny) and the user or group that the rule should apply to,
and then click Next.
5. On the Conditions page, select the File hash rule condition, and then click Next.
6. Browse Files to locate the targeted application file.
Note: You can also click Browse Folders which calculates the hash for all the appropriate files relative
to the rule collection. To remove hashes individually, click the Remove button.
7. Click Next.
8. On the Name page, either accept the automatically generated rule name or type a new rule name, and then
click Create.
Applies to
Windows 10
This topic for IT professionals shows how to create an AppLocker rule with a path condition.
The path condition identifies an app by its location in the file system of the computer or on the network.
Important: When creating a rule that uses a deny action, path conditions are less secure for preventing access
to a file because a user could easily copy the file to a different location than what is specified in the rule.
Because path rules correspond to locations within the file system, you should ensure that there are no
subdirectories that are writable by non-administrators. For example, if you create a path rule for C:\ with the
allow action, any file within C:\ will be allowed to run, including users' profiles.
For info about the path condition, see Understanding the path rule condition in AppLocker.
a security template. For information how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To create a new rule with a path condition
5. On the Conditions page, select the Path rule condition, and then click Next.
6. Click Browse Files to locate the targeted folder for the app.
Note: When you browse to a file or folder location, the wizard automatically converts absolute file
paths to use AppLocker path variables. You may edit the path after browsing to specify an absolute
path, or you may type the path directly into the Path box. To learn more about AppLocker path
variables, see Understanding the path rule condition in AppLocker.
7. Click Next.
8. (Optional) On the Exceptions page, specify conditions by which to exclude files from being affected by the
rule. Click Next.
click Create.
Applies to
Windows 10
This topic for IT professionals shows how to create an AppLocker rule with a publisher condition.
You can use publisher conditions only for files that are digitally signed; the publisher condition identifies an app
based on its digital signature and extended attributes. The digital signature contains information about the
company that created the app (the publisher). The extended attributes, which are obtained from the binary
resource, contain the name of the product that the file is part of and the version number of the application. The
publisher may be a software development company, such as Microsoft, or the information technology department
of your organization. Packaged app rules are by definition rules that use publisher conditions. For info about
creating a packaged app rule, see Create a rule for packaged apps.
For info about the publisher condition, see Understanding the publisher rule condition in AppLocker.
To create a new rule with a publisher condition
5. On the Conditions page, select the Publisher rule condition, and then click Next.
6. On the Publisher page, click Browse to select a signed file, and then use the slider to specify the scope of the
rule. To use custom values in any of the fields or to specify a specific file version, select the Use custom values
check box. For example, you can use the asterisk (*) wildcard character within a publisher rule to specify that
any value should be matched.
7. Click Next.
rule. Click Next.
click Create.
Create AppLocker default rules
Applies to
Windows 10
This topic for IT professionals describes the steps to create a standard set of AppLocker rules that will allow
Windows system files to run.
AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the files that
are required for Windows to operate properly are allowed to run.
Important: You can use the default rules as a template when creating your own rules to allow files within the
Windows folders to run. However, these rules are only meant to function as a starter policy when you are first
testing AppLocker rules. The default rules can be modified in the same way as other AppLocker rule types.
a security template. For information how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To create default rules
1. Open the AppLocker console.
2. Right-click the appropriate rule type for which you want to automatically generate default rules. You can
automatically generate rules for executable, Windows Installer, script rules and Packaged app rules.
3. Click Create Default Rules.
Related topics
Understanding AppLocker default rules
Add exceptions for an AppLocker rule
Applies to
Windows 10
This topic for IT professionals describes the steps to specify which apps can or cannot run as exceptions to an
AppLocker rule.
Rule exceptions allow you to specify files or folders to exclude from the rule. For more information about
exceptions, see Understanding AppLocker rule exceptions.
To configure exceptions for a rule
2. Expand the rule collection, right-click the rule that you want to configure exceptions for, and then click
Properties.
3. Click the Exceptions tab.
4. In the Add exception box, select the rule type that you want to create, and then click Add.
For a publisher exception, click Browse, select the file that contains the publisher to exclude, and then
click OK.
For a path exception, choose the file or folder path to exclude, and then click OK.
For a file hash exception, edit the file hash rule, and click Remove.
For a packaged apps exception, click Add to create the exceptions based on reference app and rule scope.
Create a rule for packaged apps
Applies to
Windows 10
This topic for IT professionals shows how to create an AppLocker rule for packaged apps with a publisher
condition.
Packaged apps, also known as Universal Windows apps, are based on an app model that ensures that all the files
within an app package share the same identity. Therefore, it is possible to control the entire app using a single
AppLocker rule as opposed to the non-packaged apps where each file within the app could have a unique identity.
Windows does not support unsigned packaged apps which implies all packaged apps must be signed. AppLocker
supports only publisher rules for packaged apps. A publisher rule for a packaged app is based on the following
information:
Publisher of the package
Package name
Package version
All the files within a package as well as the package installer share these attributes. Therefore, an AppLocker rule
for a packaged app controls both the installation as well as the running of the app. Otherwise, the publisher rules
for packaged apps are no different than the rest of the rule collections; they support exceptions, can be increased
or decreased in scope, and can be assigned to users and groups.
For info about the publisher condition, see Understanding the publisher rule condition in AppLocker.
To create a packaged app rule
2. On the Action menu, or by right-clicking on Packaged app Rules, click Create New Rule.
5. On the Publisher page, you can select a specific reference for the packaged app rule and set the scope for
the rule. The following table describes the reference options.
SELECTION DESCRIPTION EXAMPLE

Use an installed packaged app If selected, AppLocker requires You want the Sales group only
as a reference you to choose an app that is to use the app named
already installed on which to Microsoft.BingMaps for its
base your new rule. AppLocker outside sales calls. The
uses the publisher, package Microsoft.BingMaps app is
name and package version to already installed on the device
define the rule. where you are creating the rule,
so you choose this option, and
select the app from the list of
apps installed on the computer
and create the rule using this
app as a reference.
Use a packaged app installer If selected, AppLocker requires Your company has developed a
as a reference you to choose an app installer number of internal line-of-
on which to base your new rule. business packaged apps. The app
A packaged app installer has the installers are stored on a
.appx extension. AppLocker uses common file share. Employees
the publisher, package name and can install the required apps
package version of the installer from that file share. You want to
to define the rule. allow all your employees to
install the Payroll app from this
share. So you choose this option
from the wizard, browse to the
file share and choose the installer
for the Payroll app as a reference
to create your rule.
The following table describes setting the scope for the packaged app rule.
Applies to Any publisher This is the least restrictive scope You want the Sales group to use
condition for an Allow rule. It any packaged app from any
permits every packaged app to signed publisher. You set the
run or install. permissions to allow the Sales
group to be able to run any app.
Conversely, if this is a Deny rule,
then this option is the most
restrictive because it denies all
apps from installing or running.
Applies to a specific Publisher This scopes the rule to all apps You want to allow all your users
published by a particular to install apps published by the
publisher. publisher of Microsoft.BingMaps.
You could select
Microsoft.BingMaps as a
reference and choose this rule
scope.
Applies to a Package name This scopes the rule to all You want to allow your Sales
packages that share the group to install any version of
publisher name and package the Microsoft.BingMaps app.
name as the reference file. You could select the
Microsoft.BingMaps app as a
reference and choose this rule
scope.
Applies to a Package version This scopes the rule to a You want to be very selective in
particular version of the package. what you allow. You do not want
to implicitly trust all future
updates of the
Microsoft.BingMaps app. You
can limit the scope of your rule
to the version of the app
currently installed on your
reference computer.
Applying custom values to the Selecting the Use custom You want to allow users to install
rule values check box allows you to all Microsoft.Bing* applications
adjust the scope fields for your which include
particular circumstance. Microsoft.BingMaps,
Microsoft.BingWeather,
Microsoft.BingMoney. You can
choose the Microsoft.BingMaps
as a reference, select the Use
custom values check box and
edit the package name field by
adding Microsoft.Bing* as the
Package name.
6. Click Next.
rule. This allows you to add exceptions based on the same rule reference and rule scope as you set before. Click
Next.
click Create.
Applies to
Windows 10
This topic for IT professionals describes the steps to delete an AppLocker rule.
As older apps are retired and new apps are deployed in your organization, it will be necessary to modify the
application control policies. If an app becomes unsupported by the IT department or is no longer allowed due to
the organization's security policy, then deleting the rule or rules associated with that app will prevent the app from
running.
For info about testing an AppLocker policy to see what rules affect which files or applications, see Test an
AppLocker policy by Using Test-AppLockerPolicy.
To delete a rule in an AppLocker policy
2. Click the appropriate rule collection for which you want to delete the rule.
3. In the details pane, right-click the rule to delete, click Delete, and then click Yes.
Note: When using Group Policy, for the rule deletion to take effect on computers within the domain, the GPO
must be distributed or refreshed.
When this procedure is performed on the local device, the AppLocker policy takes effect immediately.
To clear AppLocker policies on a single system or remote systems Use the Set-AppLockerPolicy cmdlet with
the -XMLPolicy parameter, using an .XML file that contains the following contents:
<AppLockerPolicy Version="1">
<RuleCollection Type="Exe" EnforcementMode="NotConfigured" />
<RuleCollection Type="Msi" EnforcementMode="NotConfigured" />
<RuleCollection Type="Script" EnforcementMode="NotConfigured" />
<RuleCollection Type="Dll" EnforcementMode="NotConfigured" />
</AppLockerPolicy>
To use the Set-AppLockerPolicy cmdlet, first import the Applocker modules:
PS C:\Users\Administrator> import-module AppLocker
We will create a file (for example, clear.xml), place it in the same directory where we are executing our cmdlet, and
add the preceding XML contents. Then run the following command:
C:\Users\Administrator> Set-AppLockerPolicy -XMLPolicy .\clear.xml
This will remove all AppLocker Policies on a machine and could be potentially scripted to use on multiple
machines using remote execution tools with accounts with proper access.
Applies to
Windows 10
This topic for IT professionals describes the steps to edit a publisher rule, path rule, and file hash rule in
AppLocker.
For more info about these rule types, see Understanding AppLocker rule condition types.
Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or
in a security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To edit a publisher rule
1. Open the AppLocker console, and then click the appropriate rule collection.
2. In the Action pane, right-click the publisher rule, and then click Properties.
3. Click the appropriate tab to edit the rule properties.
Click the General tab to change the rule name, add a rule description, configure whether the rule is
used to allow or deny applications, and set the security group for which this rule should apply.
Click the Publisher tab to configure the certificate's common name, the product name, the file name, or
file version of the publisher.
Click the Exceptions tab to create or edit exceptions.
When you finish updating the rule, click OK.
To edit a file hash rule
2. Choose the appropriate rule collection.
3. In the Action pane, right-click the file hash rule, and then click Properties.
used to allow or deny applications, and set the security group in which this rule should apply.
Click the File Hash tab to configure the files that should be used to enforce the rule. You can click
Browse Files to add a specific file or click Browse Folders to add all files in a specified folder. To
remove hashes individually, click Remove.
To edit a path rule
2. Choose the appropriate rule collection.
3. In the Action pane, right-click the path rule, and then click Properties.
used to allow or deny applications, and set the security group in which this rule should apply.
Click the Path tab to configure the path on the computer in which the rule should be enforced.
Click the Exceptions tab to create exceptions for specific files in a folder.
Applies to
Windows 10
This topic for IT professionals describes the steps to enable the DLL rule collection feature for AppLocker.
The DLL rule collection includes the .dll and .ocx file formats.
For info about these rules, see DLL rules in AppLocker.
To enable the DLL rule collection
1. From the AppLocker console, right-click AppLocker, and then click Properties.
2. Click the Advanced tab, select the Enable the DLL rule collection check box, and then click OK.
Important: Before you enforce DLL rules, make sure that there are allow rules for each DLL that is used
by any of the allowed apps.
Applies to
Windows 10
This topic for IT professionals describes how to enforce application control rules by using AppLocker.
After AppLocker rules are created within the rule collection, you can configure the enforcement setting to Enforce
rules or Audit only on the rule collection.
There is no audit mode for the DLL rule collection. DLL rules affect specific apps. Therefore, test the impact of these
rules first before deploying them to production.
To enforce AppLocker rules by configuring an AppLocker policy to Enforce rules, see Configure an AppLocker
policy for enforce rules.
Caution: AppLocker rules will be enforced immediately on the local device or when the Group Policy object
(GPO) is updated by performing this procedure. If you want to see the effect of applying an AppLocker policy
before setting the enforcement setting to Enforce rules, configure the policy to Audit only. For info about
how to do this, see Configure an AppLocker policy for audit onlyor Test an AppLocker policy by Using Test-
AppLockerPolicy.
Run the Automatically Generate Rules wizard
Applies to
Windows 10
This topic for IT professionals describes steps to run the wizard to create AppLocker rules on a reference device.
AppLocker allows you to automatically generate rules for all files within a folder. It will scan the specified folder
and create the condition types that you choose for each file in that folder.
Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local device or in a
security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer AppLocker.
To automatically generate rules
2. Right-click the appropriate rule type for which you want to automatically generate rules. You can automatically
generate rules for executable, Windows Installer, script and packaged app rules.
3. Click Automatically Generate Rules.
4. On the Folder and Permissions page, click Browse to choose the folder to be analyzed. By default, this is the
Program Files folder.
5. Click Select to choose the security group in which the default rules should be applied. By default, this is the
Everyone group.
6. The wizard provides a name in the Name to identify this set of rules box based on the name of the folder
that you have selected. Accept the provided name or type a different name, and then click Next.
7. On the Rule Preferences page, choose the conditions that you want the wizard to use while creating rules,
and then click Next. For more info about rule conditions, see Understanding AppLocker rule condition
types.
Note: The Reduce the number of rules created by grouping similar files check box is selected by
default. This helps you organize AppLocker rules and reduce the number of rules that you create by
performing the following operations for the rule condition that you select:
One publisher condition is created for all files that have the same publisher and product name.
One path condition is created for the folder that you select. For example, if you select C:\Program
Files\ProgramName\ and the files in that folder are not signed, the wizard creates a rule for
%programfiles%\ProgramName\\*.
One file hash condition is created that contains all of the file hashes. When rule grouping is disabled, the
wizard creates a file hash rule for each file.
8. Review the files that were analyzed and the rules that will be automatically created. To make changes, click
Previous to return to the page where you can change your selections. After reviewing the rules, click
Create.
Note: If you are running the wizard to create your first rules for a GPO, you will be prompted to create the
default rules, which allow critical system files to run, after completing the wizard. You may edit the default rules
at any time. If your organization has decided to edit the default rules or create custom rules to allow the
Windows system files to run, ensure that you delete the default rules after replacing them with your custom
rules.
Working with AppLocker policies
Applies to
Windows 10
This topic for IT professionals provides links to procedural topics about creating, maintaining, and testing
AppLocker policies.
In this section
TOPIC DESCRIPTION
Configure the Application Identity service This topic for IT professionals shows how to configure the
Application Identity service to start automatically or manually.
Configure an AppLocker policy for audit only This topic for IT professionals describes how to set AppLocker
policies to **Audit only ** within your IT environment by using
AppLocker.
Configure an AppLocker policy for enforce rules This topic for IT professionals describes the steps to enable the
AppLocker policy enforcement setting.
Display a custom URL message when users try to run a This topic for IT professionals describes the steps for displaying
blocked app a customized message to users when an AppLocker policy
denies access to an app.
Export an AppLocker policy from a GPO This topic for IT professionals describes the steps to export an
AppLocker policy from a Group Policy Object (GPO) so that it
can be modified.
Export an AppLocker policy to an XML file This topic for IT professionals describes the steps to export an
AppLocker policy to an XML file for review or testing.
Import an AppLocker policy from another computer This topic for IT professionals describes how to import an
AppLocker policy.
Import an AppLocker policy into a GPO This topic for IT professionals describes the steps to import an
AppLocker policy into a Group Policy Object (GPO).
Add rules for packaged apps to existing AppLocker rule-set This topic for IT professionals describes how to update your
existing AppLocker policies for packaged apps using the
Remote Server Administration Toolkit (RSAT).
Merge AppLocker policies by using Set-ApplockerPolicy This topic for IT professionals describes the steps to merge
AppLocker policies by using Windows PowerShell.
Merge AppLocker policies manually This topic for IT professionals describes the steps to manually
merge AppLocker policies to update the Group Policy Object
(GPO).
TOPIC DESCRIPTION
Refresh an AppLocker policy This topic for IT professionals describes the steps to force an
update for an AppLocker policy.
Test an AppLocker policy by using Test-AppLockerPolicy This topic for IT professionals describes the steps to test an
AppLocker policy prior to importing it into a Group Policy
Object (GPO) or another computer.
Configure the Application Identity service
Applies to
Windows 10
This topic for IT professionals shows how to configure the Application Identity service to start automatically or
manually.
The Application Identity service determines and verifies the identity of an app. Stopping this service will prevent
AppLocker policies from being enforced.
Important: When using Group Policy, you must configure it to start automatically in at least one Group Policy
Object (GPO) that applies AppLocker rules. This is because AppLocker uses this service to verify the attributes
of a file.
To start the Application Identity service automatically using Group Policy

1. On the Start screen, type gpmc.msc to open the Group Policy Management Console (GPMC).
2. Locate the GPO to edit, right-click the GPO, and then click Edit.
3. In the console tree under Computer Configuration\Windows Settings\Security Settings, click System
Services.
4. In the details pane, double-click Application Identity.
5. In Application Identity Properties, configure the service to start automatically.
procedure.
To start the Application Identity service manually
1. Right-click the taskbar, and click Task Manager.
2. Click the Services tab, right-click AppIDSvc, and then click Start Service.
3. Verify that the status for the Application Identity service is Running.
Starting with Windows 10, the Application Identity service is now a protected process. Because of this, you can no
longer manually set the service Startup type to Automatic.
Configure an AppLocker policy for audit only
Applies to
Windows 10
This topic for IT professionals describes how to set AppLocker policies to Audit only within your IT environment
by using AppLocker.
After AppLocker rules are created within the rule collection, you can configure the enforcement setting to Enforce
rules or Audit only.
Note: There is no audit mode for the DLL rule collection. DLL rules affect specific apps. Therefore, test the
impact of these rules first before deploying them to production. To enable the DLL rule collection, see Enable
the DLL rule collection.
Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or
in a security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To audit rule collections
2. On the Enforcement tab, select the Configured check box for the rule collection that you want to enforce,
and then verify that Audit only is selected in the list for that rule collection.
3. Repeat the above step to configure the enforcement setting to Audit only for additional rule collections.
4. Click OK.
Configure an AppLocker policy for enforce rules
Applies to
Windows 10
This topic for IT professionals describes the steps to enable the AppLocker policy enforcement setting.
Note: When AppLocker policy enforcement is set to Enforce rules, rules are enforced for the rule collection
and all events are audited.
For info about how AppLocker policies are applied within a GPO structure, see Understand AppLocker rules and
enforcement setting inheritance in Group Policy.
To enable the Enforce rules enforcement setting
2. On the Enforcement tab of the AppLocker Properties dialog box, select the Configured check box for the
rule collection that you are editing, and then verify that Enforce rules is selected.
3. Click OK.
For info about viewing the events generated from rules enforcement, see Monitor app usage with AppLocker.
Display a custom URL message when users try to run
a blocked app
Applies to
Windows 10
This topic for IT professionals describes the steps for displaying a customized message to users when an AppLocker
policy denies access to an app.
Using Group Policy, AppLocker can be configured to display a message with a custom URL. You can use this URL to
redirect users to a support site that contains info about why the user received the error and which apps are
allowed. If you do not display a custom message when an apps is blocked, the default access denied message is
displayed.
To complete this procedure, you must have the Edit Setting permission to edit a GPO. By default, members of the
Domain Admins group, the Enterprise Admins group, and the Group Policy Creator Owners group have this
permission.
To display a custom URL message when users try to run a blocked app
1. On the Start screen, type gpmc.msc to open the Group Policy Management Console (GPMC).
2. Navigate to the Group Policy Object (GPO) that you want to edit.
3. Right-click the GPO, and then click Edit.
4. In the console tree under Policies\Administrative Templates\Windows Components, click File Explorer.
5. In the details pane, double-click Set a support web page link.
6. Click Enabled, and then type the URL of the custom Web page in the Support Web page URL box.
7. Click OK to apply the setting.
Export an AppLocker policy from a GPO
Applies to
Windows 10
This topic for IT professionals describes the steps to export an AppLocker policy from a Group Policy Object (GPO)
so that it can be modified.
results. Therefore, export the policy from the GPO and update the rule or rules by using AppLocker on your
AppLocker reference device.
To complete this procedure, you must have the Edit Setting permission to edit a GPO. By default, members of the
permission.
Export the policy from the GPO
1. In the Group Policy Management Console (GPMC), open the GPO that you want to edit.
2. In the console tree under Computer Configuration\Policies\Windows Settings\Security
Settings\Application Control Policies, click AppLocker.
3. Right-click AppLocker, and then click Export Policy.
4. In the Export Policy dialog box, type a name for the exported policy (for example, the name of the GPO), select
a location to save the policy, and then click Save.
5. The AppLocker dialog box will notify you of how many rules were exported. Click OK.
Export an AppLocker policy to an XML file
Applies to
Windows 10
This topic for IT professionals describes the steps to export an AppLocker policy to an XML file for review or
testing. Membership in the local Administrators group, or equivalent, is the minimum required to complete this
procedure.
To export an AppLocker policy to an XML file
1. From the AppLocker console, right-click AppLocker, and then click Export Policy.
2. Browse to the location where you want to save the XML file.
3. In the File name box, type a file name for the XML file, and then click Save.
Import an AppLocker policy from another computer
Applies to
Windows 10
This topic for IT professionals describes how to import an AppLocker policy.
Before completing this procedure, you should have exported an AppLocker policy. For more information, see
Export an AppLocker policy to an XML file.
procedure.
Caution: Importing a policy will overwrite the existing policy on that computer.
To import an AppLocker policy

1. From the AppLocker console, right-click AppLocker, and then click Import Policy.
2. In the Import Policy dialog box, locate the file that you exported, and then click Open.
3. The Import Policy dialog box will warn you that importing a policy will overwrite the existing rules and
enforcement settings. If acceptable, click OK to import and overwrite the policy.
4. The AppLocker dialog box will notify you of how many rules were overwritten and imported. Click OK.
Import an AppLocker policy into a GPO
Applies to
Windows 10
This topic for IT professionals describes the steps to import an AppLocker policy into a Group Policy Object (GPO).
AppLocker policies can be created as local security policies and modified like any other local security policy, or
they can be created as part of a GPO and managed by using Group Policy. You can create AppLocker policies on
any supported computer. For info about which Windows editions are supported, see Requirements to Use
AppLocker.
Important: Follow your organization's standard procedures for updating GPOs. For info about specific steps
to follow for AppLocker policies, see Maintain AppLocker policies.
To complete this procedure, you must have the Edit Setting permission to edit a GPO. By default, members of
the Domain Admins group, the Enterprise Admins group, and the Group Policy Creator Owners group have
this permission.
To import an AppLocker policy into a GPO
1. In the Group Policy Management Console (GPMC), open the GPO that you want to edit.
2. In the console tree under Computer Configuration\Policies\Windows Settings\Security
Settings\Application Control Policies, click AppLocker.
3. Right-click AppLocker, and then click Import Policy.
4. In the Import Policy dialog box, locate the XML policy file, and click Open.
5. The AppLocker dialog box will notify you of how many rules were imported. Click OK.
Add rules for packaged apps to existing AppLocker
rule-set
Applies to
Windows 10
This topic for IT professionals describes how to update your existing AppLocker policies for packaged apps using
the Remote Server Administration Toolkit (RSAT).
You can create packaged app rules for the computers running Windows Server 2012 or Windows 8 and later in
your domain by updating your existing AppLocker rule set. All you need is a computer running at least Windows 8.
Download and install the Remote Server Administration Toolkit (RSAT) from the Microsoft Download Center.
RSAT comes with the Group Policy Management Console which allows you to edit the GPO or GPOs where your
existing AppLocker policy are authored. RSAT has the necessary files required to author packaged app rules.
Packaged app rules will be ignored on computers running Windows 7 and earlier but will be enforced on those
computers in your domain running at least Windows Server 2012 and Windows 8.
Merge AppLocker policies by using Set-
ApplockerPolicy
Applies to
Windows 10
This topic for IT professionals describes the steps to merge AppLocker policies by using Windows PowerShell.
The Set-AppLockerPolicy cmdlet sets the specified Group Policy Object (GPO) to contain the specified AppLocker
policy. If no Lightweight Directory Access Protocol (LDAP) is specified, the local GPO is the default. When the
Merge parameter is used, rules in the specified AppLocker policy will be merged with the AppLocker rules in the
target GPO specified in the LDAP path. The merging of policies will remove rules with duplicate rule IDs, and the
enforcement setting specified by the AppLocker policy in the target GPO will be preserved. If the Merge parameter
is not specified, then the new policy will overwrite the existing policy.
For info about using Set-AppLockerPolicy, including syntax descriptions and parameters, see Set-
AppLockerPolicy.
For info about using Windows PowerShell for AppLocker, including how to import the AppLocker cmdlets into
Windows PowerShell, see Use the AppLocker Windows PowerShell cmdlets.
You can also manually merge AppLocker policies. For the procedure to do this, see Merge AppLocker policies
manually.
To merge a local AppLocker policy with another AppLocker policy by using LDAP paths
1. Open the PowerShell command window. For info about performing Windows PowerShell commands for
AppLocker, see Use the AppLocker Windows PowerShell cmdlets.
2. At the command prompt, type C:\PS>Get-AppLockerPolicy -Local | Set-AppLockerPolicy -LDAP "LDAP:
//<string>" -Merge where <string> specifies the LDAP path of the unique GPO.
Example
Gets the local AppLocker policy, and then merges the policy with the existing AppLocker policy in the GPO
specified in the LDAP path.
C:\PS>Get-AppLockerPolicy -Local | Set-AppLockerPolicy -LDAP "LDAP://DC13.Contoso.com/CN={31B2F340-016D-11D2-

945F-00C044FB984F9},CN=Policies,CN=System,DC=Contoso,DC=com" -Merge
Merge AppLocker policies manually
Applies to
Windows 10
This topic for IT professionals describes the steps to manually merge AppLocker policies to update the Group
Policy Object (GPO).
If you have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can
either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You cannot
automatically merge policies by using the AppLocker console. You must create one rule collection from two or
more policies. For info about merging policies by using the cmdlet, see Merge AppLocker policies by using Set-
ApplockerPolicy.
The AppLocker policy is saved in XML format, and the exported policy can be edited with any text or XML editor.
Rule collections are specified within the RuleCollection Type element. The XML schema includes five attributes
for the different rule collections, as shown in the following table:
RULE COLLECTION RULECOLLECTION TYPE ELEMENT
Executable rules Exe
Windows Installer rules Msi
Script rules Script
DLL rules Dll
Packaged apps and packaged app installers Appx
Rule enforcement is specified with the EnforcementMode element. The three enforcement modes in the XML
correspond to the three enforcement modes in the AppLocker console, as shown in the following table:
XML ENFORCEMENT MODE ENFORCEMENT MODE IN GROUP POLICY
NotConfigured Not configured (rules are enforced)
AuditOnly Audit only
Enabled Enforce rules
Each of the three condition types use specific elements. For XML examples of the different rule types, see Merge
AppLocker policies manually.
procedure.
To merge two or more AppLocker policies
1. Open an XML policy file in a text editor or XML editor, such as Notepad.
2. Select the rule collection where you want to copy rules from.
3. Select the rules that you want to add to another policy file, and then copy the text.
4. Open the policy where you want to add the copied rules.
5. Select and expand the rule collection where you want to add the rules.
6. At the bottom of the rule list for the collection, after the closing element, paste the rules that you copied from
the first policy file. Verify that the opening and closing elements are intact, and then save the policy.
7. Upload the policy to a reference computer to ensure that it is functioning properly within the GPO.
Refresh an AppLocker policy
Applies to
Windows 10
This topic for IT professionals describes the steps to force an update for an AppLocker policy.
If you update the rule collection on a local computer by using the Local Security Policy snap-in, the policy will take
effect immediately. If Group Policy is used to distribute the AppLocker policy and you want to immediately
implement the policy, you must manually refresh the policy. The Group Policy refresh might take several minutes,
depending upon the number of policies within the Group Policy Object (GPO) and the number of target computers.
To use Group Policy to distribute the AppLocker policy change, you need to retrieve the deployed AppLocker policy
first. To prepare for the update and subsequent refresh, see Edit an AppLocker policy
Edit an AppLocker policy and Use the AppLocker Windows PowerShell cmdlets.
To complete this procedure, you must have Edit Setting permission to edit a GPO. By default, members of the
permission.
To manually refresh the AppLocker policy by using Group Policy
1. From a command prompt, type gpupdate /force, and then press ENTER.
2. When the command finishes, close the command prompt window, and then verify that the intended rule
behavior is correct. You can do this by checking the AppLocker event logs for events that include "policy
applied."
To change a policy on an individual computer, or to implement that policy on other computers, without using
Group Policy, you first need to update the rule within the rule collection. For information about updating existing
rules, see Edit AppLocker rules. For information about creating a new rule for an existing policy, see:
procedure.
To refresh the AppLocker policy on the local computer
Update the rule collection by using the Local Security Policy console with one of the following procedures:
When finished, the policy is in effect.
To make the same change on another device, you can use any of the following methods:
From the device that you made the change on, export the AppLocker policy, and then import the policy onto
the other device. To do this, use the AppLocker Export Policy and Import Policy features to copy the rules
from the changed computer.
Caution: When importing rules from another computer, all the rules will be applied, not just the one
that was updated. Merging policies allows both existing and updated (or new) rules to be applied.
Merge AppLocker policies. For procedures to do this, see Merge AppLocker policies manually and Merge
AppLocker policies by using Set-ApplockerPolicy.
Test an AppLocker policy by using Test-
AppLockerPolicy
Applies to
Windows 10
This topic for IT professionals describes the steps to test an AppLocker policy prior to importing it into a Group
Policy Object (GPO) or another computer.
The Test-AppLockerPolicy Windows PowerShell cmdlet can be used to determine whether any of the rules in
your rule collections will be blocked on your reference computer or the computer on which you maintain policies.
Perform the following steps on any computer where the AppLocker policies are applied.
Any user account can be used to complete this procedure.
To test an AppLocker policy by using Test-AppLockerPolicy
1. Export the effective AppLocker policy. To do this, you must use the Get-AppLockerPolicy Windows
PowerShell cmdlet.
a. Open a Windows PowerShell command prompt window as an administrator.
b. Use the Get-AppLockerPolicy cmdlet to export the effective AppLocker policy to an XML file:
Get-AppLockerPolicy Effective XML > <PathofFiletoExport.XML>
2. Use the Get-ChildItem cmdlet to specify the directory that you want to test, specify the Test-
AppLockerPolicy cmdlet with the XML file from the previous step to test the policy, and use the Export-
CSV cmdlet to export the results to a file to be analyzed:
Get-ChildItem <DirectoryPathtoReview> -Filter <FileExtensionFilter> -Recurse | Convert-Path | Test-
AppLockerPolicy XMLPolicy <PathToExportedPolicyFile> -User <domain\username> -Filter
<TypeofRuletoFilterFor> | Export-CSV <PathToExportResultsTo.CSV>
The following shows example input for Test-AppLockerPolicy:
PS C:\ Get-AppLockerPolicy Effective XML > C:\Effective.xml

PS C:\ Get-ChildItem 'C:\Program Files\Microsoft Office\' filter *.exe Recurse | Convert-Path | Test-
AppLockerPolicy XMLPolicy C:\Effective.xml User contoso\zwie Filter Denied,DeniedByDefault | Export-CSV
C:\BlockedFiles.csv
In the example, the effective AppLocker policy is exported to the file C:\Effective.xml. The Get-ChildItem cmdlet is
used to recursively gather path names for the .exe files in C:\Program Files\Microsoft Office\. The XMLPolicy
parameter specifies that the C:\Effective.xml file is an XML AppLocker policy file. By specifying the User parameter,
you can test the rules for specific users, and the Export-CSV cmdlet allows the results to be exported to a comma-
separated file. In the example, -FilterDenied,DeniedByDefault displays only those files that will be blocked for the
user under the policy.
AppLocker design guide
Applies to
Windows 10
This topic for the IT professional introduces the design and planning steps required to deploy application control
policies by using AppLocker.
This guide provides important designing and planning information for deploying application control policies by
using AppLocker. It is intended for security architects, security administrators, and system administrators.
Through a sequential and iterative process, you can create an AppLocker policy deployment plan for your
organization that will address your specific application control requirements by department, organizational unit,
or business group.
This guide does not cover the deployment of application control policies by using Software Restriction Policies
(SRP). However, SRP is discussed as a deployment option in conjunction with AppLocker policies. For info about
these options, see Determine your application control objectives.
To understand if AppLocker is the correct application control solution for your organization, see Understand
AppLocker policy design decisions.
In this section
TOPIC DESCRIPTION
Understand AppLocker policy design decisions This topic for the IT professional lists the design questions,
possible answers, and ramifications of the decisions when you
plan a deployment of application control policies by using
AppLocker within a Windows operating system environment.
Determine your application control objectives This topic helps you with the decisions you need to make to
determine what applications to control and how to control
them by comparing Software Restriction Policies (SRP) and
AppLocker.
Create a list of apps deployed to each business group This topic describes the process of gathering app usage
requirements from each business group in order to
implement application control policies by using AppLocker.
Select the types of rules to create This topic lists resources you can use when selecting your
application control policy rules by using AppLocker.
Determine the Group Policy structure and rule enforcement This overview topic describes the process to follow when you
are planning to deploy AppLocker rules.
Plan for AppLocker policy management This topic for describes the decisions you need to make to
establish the processes for managing and maintaining
AppLocker policies.
TOPIC DESCRIPTION
Create your AppLocker planning document This planning topic for the IT professional summarizes the
information you need to research and include in your
AppLocker planning document.
After careful design and detailed planning, the next step is to deploy AppLocker policies. AppLocker Deployment
Guide covers the creation and testing of policies, deploying the enforcement setting, and managing and
maintaining the policies.
Understand AppLocker policy design decisions
Applies to
Windows 10
This topic for the IT professional lists the design questions, possible answers, and ramifications of the decisions
when you plan a deployment of application control policies by using AppLocker within a Windows operating
system environment.
When you begin the design and planning process, you should consider the ramifications of your design choices.
The resulting decisions will affect your policy deployment scheme and subsequent application control policy
maintenance.
You should consider using AppLocker as part of your organization's application control policies if all the following
are true:
You have deployed or plan to deploy the supported versions of Windows in your organization. For specific
operating system version requirements, see Requirements to Use AppLocker.
You need improved control over the access to your organization's applications and the data your users access.
The number of applications in your organization is known and manageable.
You have resources to test policies against the organization's requirements.
You have resources to involve Help Desk or to build a self-help process for end-user application access issues.
The group's requirements for productivity, manageability, and security can be controlled by restrictive policies.
The following questions are not in priority or sequential order. They should be considered when you deploy
application control policies (as appropriate for your targeted environment).
Which apps do you need to control in your organization?
You might need to control a limited number of apps because they access sensitive data, or you might have to
exclude all applications except those that are sanctioned for business purposes. There might be certain business
groups that require strict control, and others that promote independent application usage.
POSSIBLE ANSWERS DESIGN CONSIDERATIONS
Control all apps AppLocker policies control applications by creating an allowed

list of applications by file type. Exceptions are also possible.
AppLocker policies can only be applied to applications
installed on computers running one of the supported versions
of Windows. For specific operating system version
requirements, see Requirements to use AppLocker.
Control specific apps When you create AppLocker rules, a list of allowed apps are
created. All apps on that list will be allowed to run (except
those on the exception list). Apps that are not on the list will
be prevented from running. AppLocker policies can only be
applied to apps installed on computers running any of the
supported versions of Windows. For specific operating system
version requirements, see Requirements to use AppLocker.
Control only Classic Windows applications, only Universal AppLocker policies control apps by creating an allowed list of
Windows apps, or both apps by file type. Because Universal Windows apps are
categorized under the Publisher condition, Classic Windows
applications and Universal Windows apps can be controlled
together. AppLocker policies for Universal Windows apps can
be applied only to apps that are installed on PCs that support
the Windows Store, but Classic Windows applications can be
controlled with AppLocker on all supported versions of
Windows. The rules you currently have configured for Classic
Windows applications can remain, and you can create new
ones for Universal Windows apps.
For a comparison of Classic Windows applications and
Universal Windows apps, see Comparing Classic Windows
applications and Universal Windows apps for AppLocker
policy design decisions in this topic.
Control apps by business group and user AppLocker policies can be applied through a Group Policy
Object (GPO) to computer objects within an organizational
unit (OU). Individual AppLocker rules can be applied to
individual users or to groups of users.
Control apps by computer, not user AppLocker is a computer-based policy implementation. If your
domain or site organizational structure is not based on a
logical user structure, such as an OU, you might want to set
up that structure before you begin your AppLocker planning.
Otherwise, you will have to identify users, their computers,
and their app access requirements.
Understand app usage, but there is no need to control any AppLocker policies can be set to audit app usage to help you
apps yet track which apps are used in your organization. You can then
use the AppLocker event log to create AppLocker policies.
Important: The following list contains files or types of files that cannot be managed by AppLocker:
AppLocker does not protect against running 16-bit DOS binaries in a NT Virtual DOS Machine (NTVDM).
This technology allows running legacy DOS and 16-bit Windows programs on computers that are using
Intel 80386 or higher when there is already another operating system running and controlling the
hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when
AppLocker is configured to otherwise block binaries and libraries. If it is a requirement to prevent 16-bit
applications from running, you must configure the Deny rule in the Executable rule collection for
NTVDM.exe.
You cannot use AppLocker to prevent code from running outside the Win32 subsystem. In particular, this
applies to the (POSIX) subsystem in Windows NT. If it is a requirement to prevent applications from running
in the POSIX subsystem, you must disable the subsystem.
AppLocker can only control VBScript, JScript, .bat files, .cmd files and Windows PowerShell scripts. It does
not control all interpreted code that runs within a host process, for example Perl scripts and macros.
Interpreted code is a form of executable code that runs within a host process. For example, Windows batch
files (*.bat) run within the context of the Windows Command Host (cmd.exe). To use AppLocker to control
interpreted code, the host process must call AppLocker before it runs the interpreted code, and then enforce
the decision that is returned by AppLocker. Not all host processes call into AppLocker. Therefore, AppLocker
cannot control every kind of interpreted code, for example Microsoft Office macros.
Important: You should configure the appropriate security settings of these host processes if you must
allow them to run. For example, configure the security settings in Microsoft Office to ensure that only
signed and trusted macros are loaded.
AppLocker rules allow or prevent an app from launching. AppLocker does not control the behavior of apps
after they are launched. Applications could contain flags that are passed to functions that signal AppLocker
to circumvent the rules and allow another .exe or .dll file to be loaded. In practice, an app that is allowed by
AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must follow a
process that best suits your needs to thoroughly vet each app before allowing them to run using AppLocker
rules.
For more info, see Security considerations for AppLocker.
Comparing Classic Windows applications and Universal Windows apps for AppLocker policy design decisions
AppLocker policies for Universal Windows apps can only be applied to apps that are installed on computers
running Windows operating systems that support Windows Store apps. However, Classic Windows applications
can be controlled in Windows Server 2008 R2 and Windows 7, in addition to those computers that support
Universal Windows apps. The rules for Classic Windows applications and Universal Windows apps can be enforced
together. The differences you should consider for Universal Windows apps are:
All Universal Windows apps can be installed by a standard user, whereas a number of Classic Windows
applications require administrative credentials to install. So in an environment where most of the users are
standard users, you might not need numerous exe rules, but you might want more explicit policies for
packaged apps.
Classic Windows applications can be written to change the system state if they run with administrative
credentials. Most Universal Windows apps cannot change the system state because they run with limited
permissions. When you design your AppLocker policies, it is important to understand whether an app that you
are allowing can make system-wide changes.
Universal Windows apps can be acquired through the Store, or they can be side-loaded by using Windows
PowerShell cmdlets. If you use Windows PowerShell cmdlets, a special Enterprise license is required to acquire
Universal Windows apps. Classic Windows applications can be acquired through traditional means, such as
through software vendors or retail distribution.
AppLocker controls Universal Windows apps and Classic Windows applications by using different rule collections.
You have the choice to control Universal Windows apps, Classic Windows applications, or both.
For more info, see Packaged apps and packaged app installer rules in AppLocker.
How do you currently control app usage in your organization?
Most organizations have evolved app control policies and methods over time. With heightened security concerns
and an emphasis on tighter IT control over desktop use, your organization might decide to consolidate app control
practices or design a comprehensive application control scheme. AppLocker includes improvements over SRP in
the architecture and management of application control policies.
Security polices (locally set or through Group Policy) Using AppLocker requires increased effort in planning to
create correct policies, but this results in a simpler distribution
method.
Non-Microsoft app control software Using AppLocker requires a complete app control policy
evaluation and implementation.
Managed usage by group or OU Using AppLocker requires a complete app control policy
Authorization Manager or other role-based access Using AppLocker requires a complete app control policy
technologies evaluation and implementation.
Other Using AppLocker requires a complete app control policy

Which Windows desktop and server operating systems are running in your organization?
If your organization supports multiple Windows operating systems, app control policy planning becomes more
complex. Your initial design decisions should consider the security and management priorities of applications that
are installed on each version of the operating system.
Your organization's computers are running a combination AppLocker rules are only applied to computers running
of the following operating systems: the supported versions of Windows, but SRP rules can be
applied to all versions of Windows beginning with
Windows 10 Windows XP and Windows Server 2003. For specific
Windows 8 operating system version requirements, see Requirements
to use AppLocker.
Windows 7
Windows Vista Note
If you are using the Basic User security level as assigned
Windows XP in SRP, those privileges are not supported on
Windows Server 2012 computers running that support AppLocker.
Windows Server 2008 R2

Windows Server 2008 AppLocker policies as applied through a GPO take
precedence over SRP policies in the same or linked GPO.
Windows Server 2003 SRP policies can be created and maintained the same way.
Your organization's computers are running only the Use AppLocker to create your application control policies.
following operating systems:
Windows 10
Windows 8.1
Windows 8
Windows 7
Windows Server 2012
Are there specific groups in your organization that need customized application control policies?
Most business groups or departments have specific security requirements that pertain to data access and the
applications used to access that data. You should consider the scope of the project for each group and the groups
priorities before you deploy application control policies for the entire organization.

Yes For each group, you need to create a list that includes their
application control requirements. Although this may increase
the planning time, it will most likely result in a more effective
deployment.
If your GPO structure is not currently configured so that you
can apply different policies to specific groups, you can
alternatively apply AppLocker rules in a GPO to specific user
groups.
No AppLocker policies can be applied globally to applications that

are installed on PCs running the supported versions of
Windows as listed in Requirements to use AppLocker.
Depending on the number of apps you need to control,
managing all the rules and exceptions might be challenging.
Does your IT department have resources to analyze application usage, and to design and manage the policies?
The time and resources that are available to you to perform the research and analysis can affect the detail of your
plan and processes for continuing policy management and maintenance.
Yes Invest the time to analyze your organization's application

control requirements, and plan a complete deployment that
uses rules that are as simply constructed as possible.
No Consider a focused and phased deployment for specific

groups by using a small number of rules. As you apply
controls to applications in a specific group, learn from that
deployment to plan your next deployment.
Does your organization have Help Desk support?

Preventing your users from accessing known, deployed, or personal applications will initially cause an increase in
end-user support. It will be necessary to address the various support issues in your organization so security
policies are followed and business workflow is not hampered.
Yes Involve the support department early in the planning phase

because your users may inadvertently be blocked from using
their applications, or they may seek exceptions to use specific
applications.
No Invest time in developing online support processes and

documentation before deployment.
Do you know what applications require restrictive policies?

Any successful application control policy implementation is based on your knowledge and understanding of app
usage within the organization or business group. In addition, the application control design is dependent on the
security requirements for data and the apps that access that data.

Yes You should determine the application control priorities for a

business group and then attempt to design the simplest
scheme for their application control policies.
No You will have to perform an audit and requirements gathering

project to discover the application usage. AppLocker provides
the means to deploy policies in Audit only mode, and tools
to view the event logs.
How do you deploy or sanction applications (upgraded or new) in your organization?

Implementing a successful application control policy is based on your knowledge and understanding of
application usage within the organization or business group. In addition, the application control design is
dependent on the security requirements for data and the applications that access that data. Understanding the
upgrade and deployment policy will help shape the construction of the application control policies.
Ad hoc You need to gather requirements from each group. Some

groups might want unrestricted access or installation, while
other groups might want strict controls.
Strict written policy or guidelines to follow You need to develop AppLocker rules that reflect those
policies, and then test and maintain the rules.
No process in place You need to determine if you have the resources to develop
an application control policy, and for which groups.
Does your organization already have SRP deployed?

Although SRP and AppLocker have the same goal, AppLocker is a major revision of SRP.
Yes You cannot use AppLocker to manage SRP settings, but you
can use SRP to manage application control policies on
computers running on any of the supported operating
systems listed in Requirements to use AppLocker. In addition,
if AppLocker and SRP settings are configured in the same
GPO, only the AppLocker settings will be enforced on
computers running those supported operating systems.
Note: If you are using the Basic User security level as

assigned in SRP, those permissions are not supported on
computers running the supported operating systems.
No Policies that are configured for AppLocker can only be applied

to computers running the supported operating systems, but
SRP is also available on those operating systems.
What are your organization's priorities when implementing application control policies?
Some organizations will benefit from application control policies as shown by an increase in productivity or
conformance, while others will be hindered in performing their duties. Prioritize these aspects for each group to
allow you to evaluate the effectiveness of AppLocker.
Productivity: The organization assures that tools work and To meet innovation and productivity goals, some groups
required applications can be installed. require the ability to install and run a variety of software from
different sources, including software that they developed.
Therefore, if innovation and productivity is a high priority,
managing application control policies through an allowed list
might be time consuming and an impediment to progress.
Management: The organization is aware of and controls the In some business groups, application usage can be managed
apps it supports. from a central point of control. AppLocker policies can be built
into a GPO for that purpose. This shifts the burden of app
access to the IT department, but it also has the benefit of
controlling the number of apps that can be run and
controlling the versions of those apps
Security: The organization must protect data in part by AppLocker can help protect data by allowing a defined set of
ensuring that only approved apps are used. users access to apps that access the data. If security is the top
priority, the application control policies will be the most
restrictive.
How are apps currently accessed in your organization?

AppLocker is very effective for organizations that have application restriction requirements if they have
environments with a simple topography and application control policy goals that are straightforward. For example,
AppLocker can benefit an environment where non-employees have access to computers that are connected to the
organizational network, such as a school or library. Large organizations also benefit from AppLocker policy
deployment when the goal is to achieve a detailed level of control on the desktop computers with a relatively small
number of applications to manage, or when the applications are manageable with a small number of rules.
Users run without administrative rights. Apps are installed by using an installation deployment
technology.
AppLocker can help reduce the total cost of ownership for Users must be able to install applications as needed.
business groups that typically use a finite set of apps, such as
human resources and finance departments. At the same time,
these departments access highly sensitive information, much
of which contains confidential and proprietary information. By
using AppLocker to create rules for specific apps that are
allowed to run, you can help limit unauthorized applications
from accessing this information.
**Note: **AppLocker can also be effective in helping create
standardized desktops in organizations where users run as
administrators. However, it is important to note that users
with administrative credentials can add new rules to the local
AppLocker policy.
Users currently have administrator access, and it would be Enforcing AppLocker rules is not suited for business groups
difficult to change this. that must be able to install apps as needed and without
approval from the IT department. If one or more OUs in your
organization has this requirement, you can choose not to
enforce application rules in those OUs by using AppLocker or
to implement the Audit only enforcement setting through
AppLocker.
Is the structure in Active Directory Domain Services based on the organization's hierarchy?
Designing application control policies based on an organizational structure that is already built into Active
Directory Domain Services (AD DS) is easier than converting the existing structure to an organizational structure.
Because the effectiveness of application control policies is dependent on the ability to update policies, consider
what organizational work needs to be accomplished before deployment begins.
Yes AppLocker rules can be developed and implemented through

Group Policy, based on your AD DS structure.
No The IT department must create a scheme to identify how

application control policies can be applied to the correct user
or computer.
Record your findings

The next step in the process is to record and analyze your answers to the preceding questions. If AppLocker is the
right solution for your goals, tyou can set your application control policy objectives and plan your AppLocker rules.
This process culminates in creating your planning document.
For info about setting your policy goals, see Determine your application control objectives.
For info about creating your planning document, see Create your AppLocker planning document.
Determine your application control objectives
Applies to
Windows 10
This topic helps you with the decisions you need to make to determine what applications to control and how to
control them by comparing Software Restriction Policies (SRP) and AppLocker.
AppLocker is very effective for organizations with app restriction requirements whose environments have a
simple topography and the application control policy goals are straightforward. For example, AppLocker can
benefit an environment where non-employees have access to computers connected to the organizational
network, such as a school or library. Large organizations also benefit from AppLocker policy deployment when
the goal is to achieve a detailed level of control on the PCs that they manage for a relatively small number of
apps.
There are management and maintenance costs associated with a list of allowed apps. In addition, the purpose of
application control policies is to allow or prevent employees from using apps that might actually be productivity
tools. Keeping employees or users productive while implementing the policies can cost time and effort. Lastly,
creating user support processes and network support processes to keep the organization productive are also
concerns.
Use the following table to develop your own objectives and determine which application control feature best
addresses those objectives.
Scope SRP policies can be applied to all AppLocker policies apply only to
Windows operating systems the support versions of Windows
beginning with Windows XP and listed in Requirements to use
Windows Server 2003. AppLocker.
Policy creation SRP policies are maintained AppLocker policies are maintained
through Group Policy and only the through Group Policy and only the
administrator of the GPO can administrator of the GPO can
update the SRP policy. The update the policy. The
administrator on the local administrator on the local
computer can modify the SRP computer can modify the
policies defined in the local GPO. AppLocker policies defined in the
local GPO.
AppLocker permits customization
of error messages to direct users to
a Web page for help.
Policy maintenance SRP policies must be updated by AppLocker policies can be updated
using the Local Security Policy by using the Local Security Policy
snap-in (if the policies are created snap-in (if the policies are created
locally) or the Group Policy locally), or the GPMC, or the
Management Console (GPMC). Windows PowerShell AppLocker
cmdlets.
Policy application SRP policies are distributed AppLocker policies are distributed
through Group Policy. through Group Policy.
Enforcement mode SRP works in the deny list mode AppLocker by default works in the
where administrators can create allow list mode where only those
rules for files that they do not want files are allowed to run for which
to allow in this Enterprise whereas there is a matching allow rule.
the rest of the file are allowed to
run by default.
SRP can also be configured in the
allow list mode such that the by
default all files are blocked and
administrators need to create allow
rules for files that they want to
allow.
File types that can be controlled SRP can control the following file AppLocker can control the
types: following file types:
Executables Executables
Dlls Dlls
Scripts Scripts
Windows Installers Windows Installers
SRP cannot control each file type Packaged apps and
separately. All SRP rules are in a installers
single rule collection.
AppLocker maintains a separate
rule collection for each of the five
file types.
Designated file types SRP supports an extensible list of AppLocker does not support this.
file types that are considered AppLocker currently supports the
executable. You can add extensions following file extensions:
for files that should be considered
executable. Executables (.exe, .com)
Dlls (.ocx, .dll)
Scripts (.vbs, .js, .ps1, .cmd,
.bat)
Windows Installers (.msi,
.mst, .msp)
Packaged app installers
(.appx)
Rule types SRP supports four types of rules: AppLocker supports three types of
rules:
Hash
Hash
Path
Path
Signature
Publisher
Internet zone
Editing the hash value SRP allows you to select a file to AppLocker computes the hash
hash. value itself. Internally it uses the
SHA2 Authenticode hash for
Portable Executables (Exe and Dll)
and Windows Installers and a SHA2
flat file hash for the rest.
Support for different security levels With SRP, you can specify the AppLocker does not support
permissions with which an app can security levels.
run. So, you can configure a rule
such that notepad always runs with
restricted permissions and never
with administrative privileges.
SRP on Windows Vista and earlier
supported multiple security levels.
On Windows 7, that list was
restricted to just two levels:
Disallowed and Unrestricted (Basic
User translates to Disallowed).
Manage Packaged apps and Unable .appx is a valid file type which
Packaged app installers. AppLocker can manage.
Targeting a rule to a user or a SRP rules apply to all users on a AppLocker rules can be targeted to
group of users particular computer. a specific user or a group of users.
Support for rule exceptions SRP does not support rule AppLocker rules can have
exceptions exceptions which allow
administrators to create rules such
as Allow everything from Windows
except for Regedit.exe.
Support for audit mode SRP does not support audit mode. AppLocker supports audit mode
The only way to test SRP policies is which allows administrators to test
to set up a test environment and the effect of their policy in the real
run a few experiments. production environment without
impacting the user experience.
Once you are satisfied with the
results, you can start enforcing the
policy.
Support for exporting and SRP does not support policy AppLocker supports the importing
importing policies import/export. and exporting of policies. This
allows you to create AppLocker
policy on a sample computer, test
it out and then export that policy
and import it back into the desired
GPO.
Rule enforcement Internally, SRP rules enforcement Internally, AppLocker rules for exes
happens in the user-mode which is and dlls are enforced in the kernel-
less secure. mode which is more secure than
enforcing them in the user-mode.
For more general info, see AppLocker.

Create a list of apps deployed to each business
group
Applies to
Windows 10
This topic describes the process of gathering app usage requirements from each business group in order to
implement application control policies by using AppLocker.
Determining app usage

For each business group, determine the following:
The complete list of apps used, including different versions of an app
The full installation path of the app
The publisher and signed status of each app
The type of requirement the business groups set for each app, such as business critical, business productivity,
optional, or personal. It might also be helpful during this effort to identify which apps are supported or
unsupported by your IT department, or supported by others outside your control.
A list of files or apps that require administrative credentials to install or run. If the file requires administrative
credentials to install or run, users who cannot provide administrative credentials will be prevented from
running the file even if the file is explicitly allowed by an AppLocker policy. Even with AppLocker policies
enforced, only members of the Administrators group can install or run files that require administrative
credentials.
How to perform the app usage assessment
Although you might already have a method in place to understand app usage for each business group, you will
need to use this information to help create your AppLocker rule collection. AppLocker includes the Automatically
Generate Rules wizard and the Audit only enforcement configuration to assist you with planning and creating
your rule collection.
Application inventory methods
Using the Automatically Generate Rules wizard quickly creates rules for the applications you specify. The wizard is
designed specifically to build a rule collection. You can use the Local Security Policy snap-in to view and edit the
rules. This method is very useful when creating rules from a reference computer, and when creating and
evaluating AppLocker policies in a testing environment. However, it does require that the files be accessible on the
reference computer or through a network drive. This might mean additional work in setting up the reference
computer and determining a maintenance policy for that computer.
Using the Audit only enforcement method permits you to view the logs because it collects information about
every process on the computers receiving the Group Policy Object (GPO). Therefore, you can see what the
enforcement will be on the computers in a business group. AppLocker includes Windows PowerShell cmdlets that
you can use to analyze the events from the event log and cmdlets to create rules. However, when you use Group
Policy to deploy to several computers, a means to collect events in a central location is very important for
manageability. Because AppLocker logs information about files that users or other processes start on a computer,
you could miss creating some rules initially. Therefore, you should continue your evaluation until you can verify
that all required applications that are allowed to run are accessed successfully.
Tip: If you run Application Verifier against a custom application with any AppLocker policies enabled, it might
prevent the application from running. You should either disable Application Verifier or AppLocker. You can
create an inventory of Universal Windows apps on a device by using two methods: the Get-AppxPackage
Windows PowerShell cmdlet or the AppLocker console.
The following topics in the AppLocker Step-by-Step Guide describe how to perform each method:
Automatically generating executable rules from a reference computer
Using auditing to track which apps are used
Prerequisites to completing the inventory
Identify the business group and each organizational unit (OU) within that group to which you will apply
application control policies. In addition, you should have identified whether or not AppLocker is the most
appropriate solution for these policies. For info about these steps, see the following topics:
Next steps
Identify and develop the list of apps. Record the name of the app, whether it is signed or not as indicated by the
publisher's name, and whether or not it is a mission critical, business productivity, optional, or personal
application. Record the installation path of the apps. For info about how to do this, see Document your app list.
After you have created the list of apps, the next step is to identify the rule collections, which will become the
policies. This information can be added to the table under columns labeled:
Use default rule or define new rule condition
Allow or deny
GPO name
To do this, see the following topics:
Select the types of rules to create
Determine the Group Policy structure and rule enforcement
Document your app list
Applies to
Windows 10
This planning topic describes the app information that you should document when you create a list of apps for
AppLocker policies.

Apps
Record the name of the app, whether it is signed as indicated by the publisher's name, and whether it is a mission
critical, business productivity, optional, or personal app. Later, as you manage your rules, AppLocker displays this
information in the format shown in the following example: MICROSOFT OFFICE INFOPATH signed by
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US.
Installation path
Record the installation path of the apps. For example, Microsoft Office 2016 installs files to
%programfiles%\Microsoft Office\Office16\, which is C:\Program Files\Microsoft Office\Office16\ on most devices.
The following table provides an example of how to list applications for each business group at the early stage of
designing your application control policies. Eventually, as more planning information is added to the list, the
information can be used to build AppLocker rules.
IMPLEMENT
BUSINESS GROUP ORGANIZATIONAL UNIT APPLOCKER? APPS INSTALLATION PATH
Bank Tellers Teller-East and Yes Teller Software C:\Program

Teller-West Files\Woodgrove\
Teller.exe
Windows files C:\Windows
Human Resources HR-All Yes Check Payout C:\Program

Files\Woodgrove\
HR\Checkcut.exe
Time Sheet C:\Program

Organizer Files\Woodgrove\
HR\Timesheet.exe
Internet Explorer C:\Program

7 Files\Internet
Explorer
IMPLEMENT
BUSINESS GROUP ORGANIZATIONAL UNIT APPLOCKER? APPS INSTALLATION PATH
Windows files C:\Windows
Note: AppLocker only supports publisher rules for Universal Windows apps. Therefore, collecting the
installation path information for Universal Windows apps is not necessary.
Event processing
As you create your list of apps, you need to consider how to manage the events that are generated by user access,
or you need to deny running those apps to make your users as productive as possible. The following list is an
example of what to consider and what to record:
Will event forwarding be implemented for AppLocker events?
What is the location of the AppLocker event collection?
Should an event archival policy be implemented?
Will the events be analyzed and how often?
Should a security policy be in place for event collection?
Policy maintenance
As you create your list of apps, you need to consider how to manage and maintain the policies that you will
eventually create. The following list is an example of what to consider and what to record:
How will rules be updated for emergency app access and permanent access?
How will apps be removed?
How many older versions of the same app will be maintained?
How will new apps be introduced?
Next steps
After you have created the list of applications, the next step is to identify the rule collections, which will become the
application control policies. This information can be added to the table under the following columns:
Use default rule or define new rule condition
Allow or deny
GPO name
To identify the rule collections, see the following topics:
Determine Group Policy structure and rule enforcement
Applies to
Windows 10
This topic lists resources you can use when selecting your application control policy rules by using AppLocker.
When determining what types of rules to create for each of your groups, you should also determine what
enforcement setting to use for each group. Different rule types are more applicable for some apps, depending on
the way that the applications are deployed in a specific business group.
The following topics provide additional information about AppLocker rules that can help you decide what rules to
use for your applications:
Understanding AppLocker rule behavior
Understanding AppLocker rule exceptions
Understanding AppLocker rule collections
Understanding AppLocker allow and deny actions on rules
Understanding AppLocker rule condition types
Select the rule collection
The rules you create will be in one of the following rule collections:
Executable files: .exe and .com
Windows Installer files: .msi, .msp, and .mst
Scripts: .ps1, .bat, .cmd, .vbs, and .js
Packaged apps and packaged app installers: .appx
DLLs: .dll and .ocx
By default, the rules will allow a file to run based upon user or group privilege. If you use DLL rules, a DLL allow
rule has to be created for each DLL that is used by all of the allowed apps. The DLL rule collection is not enabled
by default.
In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is C:\Program
Files\Woodgrove\Teller.exe, and this app needs to be included in a rule. In addition, because this rule is part of a
list of allowed applications, all the Windows files under C:\Windows must be included as well.
Determine the rule condition
A rule condition is criteria upon which an AppLocker rule is based and can only be one of the rule conditions in
the following table.
RULE CONDITION USAGE SCENARIO RESOURCES

RULE CONDITION USAGE SCENARIO RESOURCES
Publisher To use a publisher condition, the files For more info about this rule condition,
must be digitally signed by the see Understanding the publisher rule
software publisher, or you must do so condition in AppLocker.
by using an internal certificate. Rules
that are specified to the version level
might have to be updated when a new
version of the file is released.
Path Any file can be assigned this rule For more info about this rule condition,
condition; however, because path rules see Understanding the path rule
specify locations within the file system, condition in AppLocker.
any subdirectory will also be affected by
the rule (unless explicitly exempted).
File hash Any file can be assigned this rule For more info about this rule condition,
condition; however, the rule must be see Understanding the file hash rule
updated each time a new version of the condition in AppLocker.
file is released because the hash value is
based in part upon the version.
In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is signed and is
located at C:\Program Files\Woodgrove\Teller.exe. Therefore, the rule can be defined with a publisher condition. If
the rule is defined to a specific version and above (for example, Teller.exe version 8.0 and above), then this will
allow any updates to this app to occur without interruption of access to the users if the app's name and signed
attributes stay the same.
Determine how to allow system files to run
Because AppLocker rules build a list of allowed apps, a rule or rules must be created to allow all Windows files to
run. AppLocker provides a means to ensure system files are properly considered in your rule collection by
generating the default rules for each rule collection. You can use the default rules (listed in AppLocker default
rules) as a template when creating your own rules. However, these rules are only meant to function as a starter
policy when you are first testing AppLocker rules so that the system files in the Windows folders will be allowed to
run. When a default rule is created, it is denoted with "(Default rule)" in its name as it appears in the rule collection.
You can also create a rule for the system files based on the path condition. In the preceding example, for the Bank
Tellers group, all Windows files reside under C:\Windows and can be defined with the path rule condition type.
This will permit access to these files whenever updates are applied and the files change. If you require additional
application security, you might need to modify the rules created from the built-in default rule collection. For
example, the default rule to allow all users to run .exe files in the Windows folder is based on a path condition that
allows all files within the Windows folder to run. The Windows folder contains a Temp subfolder to which the
Users group is given the following permissions:
Traverse Folder/Execute File
Create Files/Write Data
Create Folders/Append Data
These permissions settings are applied to this folder for application compatibility. However, because any user can
create files in this location, allowing apps to be run from this location might conflict with your organization's
security policy.
Next steps
After you have selected the types of rules to create, record your findings as explained in Document your
AppLocker rules.
After recording your findings for the AppLocker rules to create, you will need to consider how to enforce the rules.
For info about how to do this, see Determine Group Policy structure and rule enforcement.
Document your AppLocker rules
Applies to
Windows 10
This topic describes what rule conditions to associate with each file, how to associate the rule conditions with each
file, the source of the rule, and whether the file should be included or excluded.

To complete this AppLocker planning document, you should first complete the following steps:
1. Determine your application control objectives
2. Create a list of apps deployed to each business group
3. Select the types of rules to create
Document the following items for each business group or organizational unit:
Whether your organization will use the built-in default AppLocker rules to allow system files to run.
The types of rule conditions that you will use to create rules, stated in order of preference.
The following table details sample data for documenting rule type and rule condition findings. In addition, you
should now consider whether to allow an app to run or deny permission for it to run. For info about these settings,
see Understanding AppLocker allow and deny actions on rules.
USE DEFAULT
RULE OR
DEFINE NEW
BUSINESS ORGANIZATIO IMPLEMENT INSTALLATION RULE ALLOW OR
GROUP NAL UNIT APPLOCKER? APPLICATIONS PATH CONDITION DENY
Bank Teller-East Yes Teller C:\Progra File is

Tellers and Teller- Software m signed;
West Files\Woo create a
dgrove\Te publisher
ller.exe condition
Windows C:\Windo Create a

files ws path
exception
to the
default
rule to
exclude
\Windows
\Temp
USE DEFAULT
RULE OR
DEFINE NEW
BUSINESS ORGANIZATIO IMPLEMENT INSTALLATION RULE ALLOW OR
GROUP NAL UNIT APPLOCKER? APPLICATIONS PATH CONDITION DENY
Human HR-All Yes Check C:\Progra File is

Resources Payout m signed;
Files\Woo create a
dgrove\H publisher
R\Checkcu condition
t.exe
Time C:\Progra File is not

Sheet m signed;
Organizer Files\Woo create a
dgrove\H file hash
R\Timeshe condition
et.exe
Internet C:\Progra File is

Explorer 7 m signed;
Files\Inter create a
net publisher
Explorer</ condition
p>
Windows C:\Windo Use the

files ws default
rule for
the
Windows
path
Next steps
For each rule, determine whether to use the allow or deny option. Then, three tasks remain:
Determine Group Policy structure and rule enforcement
Plan for AppLocker policy management
Create your AppLocker planning document
Determine the Group Policy structure and rule
enforcement
Applies to
Windows 10
This overview topic describes the process to follow when you are planning to deploy AppLocker rules.
In this section
TOPIC DESCRIPTION
Understand AppLocker enforcement settings This topic describes the AppLocker enforcement settings for
rule collections.
Understand AppLocker rules and enforcement setting This topic for the IT professional describes how application
inheritance in Group Policy control policies configured in AppLocker are applied through
Group Policy.
Document the Group Policy structure and AppLocker rule This planning topic describes what you need to investigate,
enforcement determine, and record in your application control policies plan
when you use AppLocker.
When you are determining how many Group Policy Objects (GPOs) to create when you apply an AppLocker
policy in your organization, you should consider the following:
Whether you are creating new GPOs or using existing GPOs
Whether you are implementing Software Restriction Policies (SRP) policies and AppLocker policies in the
same GPO
GPO naming conventions
GPO size limits
Note: There is no default limit on the number of AppLocker rules that you can create. However, in Windows
Server 2008 R2, GPOs have a 2 MB size limit for performance. In subsequent versions, that limit is raised to
100 MB.
Understand AppLocker enforcement settings
Applies to
Windows 10
This topic describes the AppLocker enforcement settings for rule collections.
Rule enforcement is applied only to a collection of rules, not to individual rules. AppLocker divides the rules into
four collections: executable files, Windows Installer files, scripts, and DLL files. For more info about rule collections,
see Understanding AppLocker rule collections. By default, if enforcement is not configured and rules are present in
a rule collection, those rules are enforced. The following table details the three AppLocker rule enforcement
settings in Group Policy for each rule collection.
ENFORCEMENT SETTING DESCRIPTION
Not configured By default, enforcement is not configured in a rule collection.

If rules are present in the corresponding rule collection, they
are enforced. If rule enforcement is configured in a higher-
level linked Group Policy object (GPO), that enforcement value
overrides the Not configured value.
Enforce rules Rules are enforced for the rule collection, and all rule events
are audited.
Audit only Rule events are audited only. Use this value when planning
and testing AppLocker rules.
For the AppLocker policy to be enforced on a device, the Application Identity service must be running. For more
info about the Application Identity service, see Configure the Application Identity service.
When AppLocker policies from various GPOs are merged, the enforcement modes are merged by using the
standard Group Policy order of inheritance, which is local, domain, site, and organizational unit (OU). The Group
Policy setting that was last written or applied by order of inheritance is used for the enforcement mode, and all
rules from linked GPOs are applied.
Understand AppLocker rules and enforcement setting
inheritance in Group Policy
Applies to
Windows 10
This topic for the IT professional describes how application control policies configured in AppLocker are applied
through Group Policy.
Rule enforcement is applied only to collections of rules, not individual rules. AppLocker divides the rules into the
following collections: executable files, Windows Installer files, scripts, packaged apps and packaged app installers,
and DLL files. The options for rule enforcement are Not configured, Enforce rules, or Audit only. Together, all
AppLocker rule collections compose the application control policy, or AppLocker policy.
Group Policy merges AppLocker policy in two ways:
Rules. Group Policy does not overwrite or replace rules that are already present in a linked Group Policy
Object (GPO). For example, if the current GPO has 12 rules and a linked GPO has 50 rules, 62 rules are
applied to all computers that receive the AppLocker policy.
Important: When determining whether a file is permitted to run, AppLocker processes rules in the
following order:
1. Explicit deny. An administrator created a rule to deny a file.

2. Explicit allow. An administrator created a rule to allow a file.
3. Implicit deny. This is also called the default deny because all files that are not affected by an allow rule
are automatically blocked.
Enforcement settings. The last write to the policy is applied. For example, if a higher-level GPO has the
enforcement setting configured to Enforce rules and the closest GPO has the setting configured to Audit
only, Audit only is enforced. If enforcement is not configured on the closest GPO, the setting from the
closest linked GPO will be enforced. Because a computer's effective policy includes rules from each linked
GPO, duplicate rules or conflicting rules could be enforced on a user's computer. Therefore, you should
carefully plan your deployment to ensure that only rules that are necessary are present in a GPO.
The following figure demonstrates how AppLocker rule enforcement is applied through linked GPOs.
In the preceding illustration, note that all GPOs linked to Contoso are applied in order as configured. The rules that
are not configured are also applied. For example, the result of the Contoso and Human Resources GPOs is 33 rules
enforced, as shown in the client HR-Term1. The Human Resources GPO contains 10 non-configured rules. When
the rule collection is configured for Audit only, no rules are enforced.
When constructing the Group Policy architecture for applying AppLocker policies, it is important to remember:
Rule collections that are not configured will be enforced.
Group Policy does not overwrite or replace rules that are already present in a linked GPO.
AppLocker processes the explicit deny rule configuration before the allow rule configuration.
For rule enforcement, the last write to the GPO is applied.
Document the Group Policy structure and AppLocker
rule enforcement
Applies to
Windows 10
This planning topic describes what you need to investigate, determine, and record in your application control
policies plan when you use AppLocker.

4. Determine the Group Policy structure and rule enforcement
After you determine how to structure your Group Policy Objects (GPOs) so that you can apply AppLocker policies,
you should record your findings. You can use the following table to determine how many GPOs to create (or edit)
and which objects they are linked to. If you decided to create custom rules to allow system files to run, note the
high-level rule configuration in the Use default rule or define new rule condition column.
The following table includes the sample data that was collected when you determined your enforcement settings
and the GPO structure for your AppLocker policies.
USE
DEFAULT
RULE OR
DEFINE NEW
BUSINESS ORGANIZATI IMPLEMENT INSTALLATIO RULE ALLOW OR
GROUP ONAL UNIT APPLOCKER? APPS N PATH CONDITION DENY GPO NAME
Bank Teller- Yes Teller C:\Prog File is Allow Tellers-

Tellers East Softwar ram signed; AppLoc
and e Files\W create a kerTelle
Teller- oodgro publish rRules
West ve\Telle er
r.exe conditio
n
Window C:\Wind Create Allow

s files ows a path
exceptio
n to the
default
rule to
exclude
\Windo
ws\Tem
p
USE
DEFAULT
RULE OR
DEFINE NEW
BUSINESS ORGANIZATI IMPLEMENT INSTALLATIO RULE ALLOW OR
GROUP ONAL UNIT APPLOCKER? APPS N PATH CONDITION DENY GPO NAME
Human HR-All Yes Check C:\Prog File is Allow HR-

Resourc Payout ram signed; AppLoc
es Files\W create a kerHRR
oodgro publish ules
ve\HR\ er
Checkc conditio
ut.exe n
Time C:\Prog File is Allow

Sheet ram not
Organiz Files\W signed;
er oodgro create a
ve\HR\T file hash
imeshee conditio
t.exe n
Internet C:\Prog File is Deny

Explorer ram signed;
7 Files\Int create a
ernet publish
Explorer er
 conditio
n
Window C:\Wind Use a Allow

s files ows default
rule for
the
Window
s path
Next steps
After you have determined the Group Policy structure and rule enforcement strategy for each business group's
apps, the following tasks remain:
Applies to
Windows 10
This topic for describes the decisions you need to make to establish the processes for managing and maintaining
AppLocker policies.
Policy management
Before you begin the deployment process, consider how the AppLocker rules will be managed. Developing a
process for managing AppLocker rules helps assure that AppLocker continues to effectively control how
applications are allowed to run in your organization.
Application and user support policy
Developing a process for managing AppLocker rules helps assure that AppLocker continues to effectively control
how applications are allowed to run in your organization. Considerations include:
What type of end-user support is provided for blocked applications?
How are new rules added to the policy?
How are existing rules updated?
Are events forwarded for review?
Help desk support
If your organization has an established help desk support department in place, consider the following when
deploying AppLocker policies:
What documentation does your support department require for new policy deployments?
What are the critical processes in each business group both in work flow and timing that will be affected by
application control policies and how could they affect your support department's workload?
Who are the contacts in the support department?
How will the support department resolve application control issues between the end user and those who
maintain the AppLocker rules?
End-user support
Because AppLocker is preventing unapproved apps from running, it is important that your organization carefully
plan how to provide end-user support. Considerations include:
Do you want to use an intranet site as a first line of support for users who have tried to run a blocked app?
How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily allow
access to a blocked app?
Using an intranet site
AppLocker can be configured to display the default message but with a custom URL. You can use this URL to
redirect users to a support site that contains information about why the user received the error and which
applications are allowed. If you do not display a custom URL for the message when an app is blocked, the default
URL is used.
The following image shows an example of the error message for a blocked app. You can use the Set a support
web link policy setting to customize the More information link.
For steps to display a custom URL for the message, see Display a custom URL message when users try to run a
blocked app.
AppLocker event management
Each time that a process requests permission to run, AppLocker creates an event in the AppLocker event log. The
event details which file tried to run, the attributes of that file, the user that initiated the request, and the rule GUID
that was used to make the AppLocker execution decision. The AppLocker event log is located in the following path:
Applications and Services Logs\Microsoft\Windows\AppLocker. The AppLocker log includes three logs:
1. EXE and DLL. Contains events for all files affected by the executable and DLL rule collections (.exe, .com, .dll,
and .ocx).
2. MSI and Script. Contains events for all files affected by the Windows Installer and script rule collections (.msi,
.msp, .ps1, .bat, .cmd, .vbs, and .js).
3. Packaged app-Deployment or Packaged app-Execution, contains events for all Universal Windows apps
affected by the packaged app and packed app installer rule collection (.appx).
Collecting these events in a central location can help you maintain your AppLocker policy and troubleshoot rule
configuration problems. Event collection technologies such as those available in Windows allow administrators to
subscribe to specific event channels and have the events from source computers aggregated into a forwarded
event log on a Windows Server operating system collector. For more info about setting up an event subscription,
see Configure Computers to Collect and Forward Events.
Policy maintenance
As new apps are deployed or existing apps are updated by the software publisher, you will need to make revisions
to your rule collections to ensure that the policy is current.
for the policy by importing additional rules. To ensure version control when modifying an AppLocker policy, use
Group Policy management software that allows you to create versions of Group Policy Objects (GPOs). An
example of this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop
Optimization Pack. For more info about Advanced Group Policy Management, see Advanced Group Policy
Management Overview (https://go.microsoft.com/fwlink/p/?LinkId=145013).
behavior.
New version of a supported app

When a new version of an app is deployed in the organization, you need to determine whether to continue to
support the previous version of that app. To add the new version, you might only need to create a new rule for
each file that is associated with the app. If you are using publisher conditions and the version is not specified, then
the existing rule or rules might be sufficient to allow the updated file to run. You must ensure, however, that the
updated app has not altered the file names or added files to support new functionality. If so, then you must modify
the existing rules or create new rules. To continue to reuse a publisher-based rule without a specific file version,
you must also ensure that the file's digital signature is still identical to the previous versionthe publisher,
product name, and file name (if configured in your rule) must all match for the rule to be correctly applied.
To determine whether a file has been modified during an app update, review the publisher's release details
provided with the update package. You can also review the publisher's web page to retrieve this information. Each
file can also be inspected to determine the version.
For files that are allowed or denied with file hash conditions, you must retrieve the new file hash. To add support
for a new version and maintain support for the older version, you can either create a new file hash rule for the
new version or edit the existing rule and add the new file hash to the list of conditions.
For files with path conditions, you should verify that the installation path has not changed from what is stated in
the rule. If the path has changed, you need to update the rule before installing the new version of the app
Recently deployed app
To support a new app, you must add one or more rules to the existing AppLocker policy.
App is no longer supported
If your organization has determined that it will no longer support an application that has AppLocker rules
associated with it, the easiest way to prevent users from running the app is to delete these rules.
App is blocked but should be allowed
A file could be blocked for three reasons:
The most common reason is that no rule exists to allow the app to run.
There may be an existing rule that was created for the file that is too restrictive.
A deny rule, which cannot be overridden, is explicitly blocking the file.
Before editing the rule collection, first determine what rule is preventing the file from running. You can
troubleshoot the problem by using the Test-AppLockerPolicy Windows PowerShell cmdlet. For more info about
troubleshooting an AppLocker policy, see Testing and Updating an AppLocker Policy
(https://go.microsoft.com/fwlink/p/?LinkId=160269).
Next steps
After deciding how your organization will manage your AppLocker policy, record your findings.
End-user support policy. Document the process that you will use for handling calls from users who have
attempted to run a blocked app, and ensure that support personnel have clear escalation steps so that the
administrator can update the AppLocker policy, if necessary.
Event processing. Document whether events will be collected in a central location called a store, how that
store will be archived, and whether the events will be processed for analysis.
Policy maintenance. Detail how rules will be added to the policy and in which GPO the rules are defined.
For information and steps how to document your processes, see Document your application control management
processes.
Document your application control management
processes
Applies to
Windows 10
This planning topic describes the AppLocker policy maintenance information to record for your design document.

5. Plan for AppLocker policy management
The three key areas to determine for AppLocker policy management are:
1. Support policy
Document the process that you will use for handling calls from users who have attempted to run a blocked
app, and ensure that support personnel know recommended troubleshooting steps and escalation points for
your policy.
2. Event processing
Document whether events will be collected in a central location, how that store will be archived, and whether
the events will be processed for analysis.
3. Policy maintenance
Detail how rules will be added to the policy, in which Group Policy Object (GPO) the rules should be defined,
and how to modify rules when apps are retired, updated, or added.
The following table contains the added sample data that was collected when determining how to maintain and
manage AppLocker policies.
USE
DEFAULT
RULE OR
IMPLEMEN DEFINE
ORGANIZA T NEW RULE
BUSINESS TIONAL APPLOCKE INSTALLAT CONDITIO ALLOW OR SUPPORT
GROUP UNIT R? APPS ION PATH N DENY GPO NAME POLICY
USE
DEFAULT
RULE OR
IMPLEMEN DEFINE
ORGANIZA T NEW RULE
Bank Teller- Yes Teller C:\Pro File is Allow Tellers Web

Tellers East Softw gram signe - help
and are Files\ d; AppL
Teller- Wood create ocker
West grove a Teller
\Teller publis Rules
.exe her
condit
ion
Wind C:\Wi Creat Allow Help

ows ndow ea desk
files s path
excep
tion
to the
defaul
t rule
to
exclud
e
\Wind
ows\T
emp
Huma HR-All Yes Check C:\Pro File is Allow HR- Web

n Payou gram signe AppL help
Resou t Files\ d; ocker
rces Wood create HRRul
grove a es
\HR\C publis
heckc her
ut.exe condit
ion
Time C:\Pro File is Allow Web

Sheet gram not help
Orga Files\ signe
nizer Wood d;
grove create
\HR\Ti a file
mesh hash
eet.ex condit
e ion
USE
DEFAULT
RULE OR
IMPLEMEN DEFINE
ORGANIZA T NEW RULE
Intern C:\Pro File is Deny Web

et gram signe help
Explor Files\I d;
er 7 ntern create
et a
Explor publis
er condit
ion
Wind C:\Wi Use Allow Help

ows ndow the desk
files s defaul
t rule
for
the
Wind
ows
path
The following two tables illustrate examples of documenting considerations to maintain and manage AppLocker
policies.
Event processing policy
One discovery method for app usage is to set the AppLocker enforcement mode to Audit only. This will write
events to the AppLocker logs, which can be managed and analyzed like other Windows logs. After apps have been
identified, you can begin to develop policies regarding the processing and access to AppLocker events.
The following table is an example of what to consider and record.
APPLOCKER EVENT
BUSINESS GROUP COLLECTION LOCATION ARCHIVAL POLICY ANALYZED? SECURITY POLICY
Bank Tellers Forwarded to: Standard None Standard

AppLocker Event
Repository on
srvBT093
Human Resources DO NOT 60 months Yes, summary Standard

FORWARD. reports monthly
srvHR004 to managers
Policy maintenance policy When applications are identified and policies are created for application control, then
you can begin documenting how you intend to update those policies. The following table is an example of what to
consider and record.
APPLICATION APPLICATION VERSION APPLICATION
BUSINESS GROUP RULE UPDATE POLICY DECOMMISSION POLICY POLICY DEPLOYMENT POLICY
Bank Tellers Planned: Monthly Through business General policy: Coordinated

through business office triage Keep past through business
office triage versions for 12 office
30-day notice months
Emergency: required 30-day notice
Request through List policies for required
help desk each application
Human Resources Planned: Monthly Through HR General policy: Coordinated

through HR triage triage Keep past through HR
versions for 60
Emergency: 30-day notice months 30-day notice
Request through required required
help desk List policies for
each application
Next steps
After you have determined your application control management strategy for each of the business group's
applications, the following task remains:
Applies to
Windows 10
This planning topic for the IT professional summarizes the information you need to research and include in your
AppLocker planning document.
The AppLocker deployment design

The design process and the planning document help you investigate application usage in your organization and
record your findings so you can effectively deploy and maintain application control policies by using AppLocker.
You should have completed these steps in the design and planning process:
3. Select types of rules to create
4. Determine Group Policy structure and rule enforcement
AppLocker planning document contents
Your planning document should contain:
A list of business groups that will participate in the application control policy project, their requirements, a
description of their business processes, and contact information.
Application control policy project target dates, both for planning and deployment.
A complete list of apps used by each business group (or organizational unit), including version information
and installation paths.
What condition to apply to rules governing each application (or whether to use the default set provided by
AppLocker).
A strategy for using Group Policy to deploy the AppLocker policies.
A strategy in processing the application usage events generated by AppLocker.
A strategy to maintain and manage AppLocker polices after deployment.
Sample template for an AppLocker planning document
You can use the following form to construct your own AppLocker planning document.
Business group:
Operating system environment: (Windows and non-Windows)
Contacts Business contact: Technical contact:
Other departments In this business group: Affected by this project:

Security policies Internal: Regulatory/compliance:
Business goals Primary: Secondary:
Project target dates Design signoff date: Policy deployment date:
Rules
USE
DEFAULT
RULE OR
IMPLEMEN DEFINE
ORGANIZA T NEW RULE
Event processing
APPLOCKER EVENT
Policy maintenance
APP DECOMMISSION APP DEPLOYMENT

BUSINESS GROUP RULE UPDATE POLICY POLICY APP VERSION POLICY POLICY
Planned:
Emergency:
Example of an AppLocker planning document

Rules
USE
DEFAULT
RULE OR
IMPLEMEN DEFINE
ORGANIZA T NEW RULE
BUSINESS TIONAL APPLOCKE APPLICATI INSTALLAT CONDITIO ALLOW OR SUPPORT
GROUP UNIT R? ONS ION PATH N DENY GPO NAME POLICY
Bank Teller Yes Teller C:\Pr File is Allow Teller Web

Tellers -East Softw ogra signe s- help
and are m d; AppL
Teller Files\ create ocker
-West Wood a Teller
grove publis Rules
\Teller her
.exe condi
tion
USE
DEFAULT
RULE OR
IMPLEMEN DEFINE
ORGANIZA T NEW RULE

ows ndow ea desk
files s path
excep
tion
to the
defaul
t rule
to
exclu
de
\Wind
ows\T
emp
Huma HR- Yes Check C:\Pr File is Allow HR- Web

n All Payo ogra signe AppL help
Resou ut m d; ocker
rces Files\ create HRRul
Wood a es
grove publis
\HR\C her
heckc condi
ut.exe tion
Time C:\Pr File is Allow Web

Sheet ogra not help
Orga m signe
nizer Files\ d;
Wood create
grove a file
\HR\T hash
imesh condi
eet.ex tion
e
Intern C:\Pr File is Deny Web

et ogra signe help
Explor m d;
er 7 Files\I create
ntern a
et publis
Explor her
er tion
USE
DEFAULT
RULE OR
IMPLEMEN DEFINE
ORGANIZA T NEW RULE

ows ndow the desk
files s defaul
t rule
for
the
Wind
ows
path
Event processing
APPLOCKER EVENT

AppLocker Event
Repository on
srvBT093
Human Resources DO NOT 60 months Yes, summary Standard

FORWARD. reports monthly
srvHR004 to managers
Policy maintenance


through business office triage Keep past through business
office triage versions for 12 office
30-day notice months
Emergency: required 30-day notice
Request through List policies for required
Human Resources Planned: Monthly Through HR General policy: Coordinated

through HR triage Keep past through HR
triage versions for 60
30-day notice months 30-day notice
Emergency: required required
Request through List policies for
The AppLocker Policies Design Guide is the predecessor to the AppLocker Policies Deployment Guide. When
planning is complete, see the AppLocker policies deployment guide.
For more general info, see AppLocker.
Applies to
Windows 10
This topic for IT professionals introduces the concepts and describes the steps required to deploy AppLocker
policies.
This guide provides steps based on your design and planning investigation for deploying application control
policies by using AppLocker. It is intended for security architects, security administrators, and system
administrators. Through a sequential and iterative deployment process, you can create application control
policies, test and adjust the policies, and implement a method for maintaining those policies as the needs in your
organization change.
This guide covers the use of Software Restriction Policies (SRP) in conjunction with AppLocker policies to control
application usage. For a comparison of SRP and AppLocker, see Using Software Restriction Policies and
AppLocker policies in this guide. To understand if AppLocker is the correct application control solution for you,
see Understand AppLocker policy design decisions.
Prerequisites to deploying AppLocker policies

The following are prerequisites or recommendations to deploying policies:
Understand the capabilities of AppLocker:
AppLocker
Document your application control policy deployment plan by addressing these tasks:
Understand the AppLocker policy deployment process
Create list of apps deployed to each business group
Select types of rules to create
Determine Group Policy Structure and rule enforcement
Contents of this guide

This guide provides steps based on your design and planning investigation for deploying application control
policies created and maintained by AppLocker for computers running any of the supported versions of Windows
listed in Requirements to use AppLocker.
In this section
TOPIC DESCRIPTION
Understand the AppLocker policy deployment process This planning and deployment topic for the IT professional
describes the process for using AppLocker when deploying
application control policies.
TOPIC DESCRIPTION
Requirements for Deploying AppLocker Policies This deployment topic for the IT professional lists the
requirements that you need to consider before you deploy
AppLocker policies.
Use Software Restriction Policies and AppLocker policies This topic for the IT professional describes how to use
Software Restriction Policies (SRP) and AppLocker policies in
the same Windows deployment.
Create Your AppLocker policies This overview topic for the IT professional describes the steps
to create an AppLocker policy and prepare it for deployment.
Deploy the AppLocker policy into production This topic for the IT professional describes the tasks that
should be completed before you deploy AppLocker
application control settings.
Understand the AppLocker policy deployment
process
Applies to
Windows 10
This planning and deployment topic for the IT professional describes the process for using AppLocker when
deploying application control policies.
To successfully deploy AppLocker policies, you need to identify your application control objectives and construct
the policies for those objectives. The key to the process is taking an accurate inventory of your organization's
applications, which requires investigation of all the targeted business groups. With an accurate inventory, you can
create rules and set enforcement criteria that will allow the organization to use the required applications and allow
the IT department to manage a controlled set of applications.
The following diagram shows the main points in the design, planning, and deployment process for AppLocker.
Resources to support the deployment process
The following topics contain information about designing, planning, deploying, and maintaining AppLocker
policies:
For info about the AppLocker policy design and planning requirements and process, see AppLocker Design
Guide.
For info about the AppLocker policy deployment requirements and process, see AppLocker deployment guide.
For info about AppLocker policy maintenance and monitoring, see Administer AppLocker.
For info about AppLocker policy architecture, components, and processing, see AppLocker technical reference.
Requirements for deploying AppLocker policies
Applies to
Windows 10
This deployment topic for the IT professional lists the requirements that you need to consider before you deploy
AppLocker policies.
The following requirements must be met or addressed before you deploy your AppLocker policies:
Deployment plan
Supported operating systems
Policy distribution mechanism
Event collection and analysis system
Deployment plan
An AppLocker policy deployment plan is the result of investigating which applications are required and necessary
in your organization, which apps are optional, and which apps are forbidden. To develop this plan, see AppLocker
Design Guide. The following table is an example of the data you need to collect and the decisions you need to make
to successfully deploy AppLocker policies on the supported operating systems (as listed in Requirements to use
AppLocker).
USE
DEFAULT
RULE OR
IMPLEMEN DEFINE
ORGANIZA T NEW RULE
Bank Teller- Yes Teller C:\Pro File is Allow Tellers Web

Tellers East softw gram signe help
and are Files\ d;
Teller- Wood create
West grove a
\Teller publis
.exe her
condit
ion
USE
DEFAULT
RULE OR
IMPLEMEN DEFINE
ORGANIZA T NEW RULE

ows ndow ea Desk
files s path
excep
tion
to the
defaul
t rule
to
exclud
e
\Wind
ows\T
emp
Time C:\Pro File is Allow Web

Sheet gram not help
Orga Files\ signe
nizer Wood d;
grove create
\HR\Ti a file
mesh hash
eet.ex condit
e ion
Huma HR-All Yes Check C:\Pro File is Allow HR Web

n Payou gram signe help
Resou t Files\ d;
rces Wood create
grove a
\HR\C publis
heckc her
ut.exe condit
ion
Intern C:\Pro File is Deny Help

et gram signe Desk
Explor Files\I d;
er 7 ntern create
et a
Explor publis
er condit
ion
USE
DEFAULT
RULE OR
IMPLEMEN DEFINE
ORGANIZA T NEW RULE

ows ndow the Desk
files s defaul
t rule
for
the
Wind
ows
path
Event processing policy
APPLOCKER EVENT

srvBT093
Human Resources Do not forward 60 months Yes; summary Standard

reports monthly
to managers
Policy maintenance policy


through business office triage; 30- Keep past through business
office triage day notice versions for 12 office; 30-day
required months notice required
Emergency:
Request through List policies for
Help Desk each application
Human Resources Planned: Through Through HR General policy: Coordinated

HR triage triage; 30-day Keep past through HR; 30-
notice required versions for 60 day notice
Emergency: months required
Request through
Help Desk List policies for
each application
Supported operating systems

AppLocker is supported only on certain operating systems. Some features are not available on all operating
systems. For more information, see Requirements to use AppLocker.
Policy distribution mechanism
You need a way to distribute the AppLocker policies throughout the targeted business groups. AppLocker uses
Group Policy management architecture to effectively distribute application control policies. AppLocker policies can
also be configured on individual computers by using the Local Security Policy snap-in.
Event collection and analysis system
Event processing is important to understand application usage. You must have a process in place to collect and
analyze AppLocker events so that application usage is appropriately restricted and understood. For procedures to
monitor AppLocker events, see:
Configure an AppLocker policy for enforce rules
See also
Use Software Restriction Policies and AppLocker
policies
Applies to
Windows 10
This topic for the IT professional describes how to use Software Restriction Policies (SRP) and AppLocker policies in
the same Windows deployment.
Understand the difference between SRP and AppLocker

You might want to deploy application control policies in Windows operating systems earlier than Windows Server
2008 R2 or Windows 7. You can use AppLocker policies only on the supported versions and editions of Windows
as listed in Requirements to use AppLocker. However, you can use SRP on those supported editions of Windows
plus Windows Server 2003 and Windows XP. To compare features and functions in SRP and AppLocker so that you
can determine when to use each technology to meet your application control objectives, see Determine your
application control objectives.
Use SRP and AppLocker in the same domain

SRP and AppLocker use Group Policy for domain management. However, when policies are generated by SRP and
AppLocker exist in the same domain, and they are applied through Group Policy, AppLocker policies take
precedence over policies generated by SRP on computers that are running an operating system that supports
AppLocker. For info about how inheritance in Group Policy applies to AppLocker policies and policies generated by
SRP, see Understand AppLocker rules and enforcement setting inheritance in Group Policy.
Important: As a best practice, use separate Group Policy Objects to implement your SRP and AppLocker
policies. To reduce troubleshooting issues, do not combine them in the same GPO.
The following scenario provides an example of how each type of policy would affect a bank teller software app,
where the app is deployed on different Windows desktop operating systems and managed by the Tellers GPO.
TELLERS GPO WITH TELLERS GPO WITH

OPERATING SYSTEM APPLOCKER POLICY TELLERS GPO WITH SRP APPLOCKER POLICY AND SRP
Windows 10, Windows 8.1, AppLocker policies in the Local AppLocker policies AppLocker policies in the
Windows 8,and Windows 7 GPO are applied, and they supersede policies generated GPO are applied, and they
supersede any local by SRP that are applied supersede the policies
AppLocker policies. through the GPO. generated by SRP in the
GPO and local AppLocker
policies or policies generated
by SRP.
Windows Vista AppLocker policies are not Policies generated by SRP in Policies generated by SRP in
applied. the GPO are applied, and the GPO are applied, and
they supersede local policies they supersede local policies
generated by SRP.AppLocker generated by SRP.
policies are not applied. AppLocker policies not
applied.
TELLERS GPO WITH TELLERS GPO WITH
OPERATING SYSTEM APPLOCKER POLICY TELLERS GPO WITH SRP APPLOCKER POLICY AND SRP
Windows XP AppLocker policies are not Policies generated by SRP in Policies generated by SRP in
applied. the GPO are applied, and the GPO are applied, and
they supersede local policies they supersede local policies
generated by SRP. generated by SRP.
AppLocker policies are not AppLocker policies not
applied. applied.
Note: For info about supported versions and editions of the Windows operating system, see Requirements to
use AppLocker.
Test and validate SRPs and AppLocker policies that are deployed in the
same environment
Because SRPs and AppLocker policies function differently, they should not be implemented in the same GPO. This
makes testing the result of the policy straightforward, which is critical to successfully controlling application usage
in the organization. Configuring a testing and policy distribution system can help you understand the result of a
policy. The effects of policies generated by SRP and AppLocker policies need to be tested separately and by using
different tools.
Step 1: Test the effect of SRPs
You can use the Group Policy Management Console (GPMC) or the Resultant Set of Policy (RSoP) snap-in to
determine the effect of applying SRPs by using GPOs.
Step 2: Test the effect of AppLocker policies
You can test AppLocker policies by using Windows PowerShell cmdlets. For info about investigating the result of a
policy, see:
Test an AppLocker policy by using Test-AppLockerPolicy
Another method to use when determining the result of a policy is to set the enforcement mode to Audit only.
When the policy is deployed, events will be written to the AppLocker logs as if the policy was enforced. For info
about using the Audit only mode, see:
See also
Create Your AppLocker policies
Applies to
Windows 10
This overview topic for the IT professional describes the steps to create an AppLocker policy and prepare it for
deployment.
Creating effective application control policies with AppLocker starts by creating the rules for each app. Rules are
grouped into one of five rule collections. The rule collection can be configured to be enforced or to run in Audit
only mode. An AppLocker policy includes the rules in the five rule collections and the enforcement settings for
each rule collection.
Step 1: Use your plan

You can develop an application control policy plan to guide you in making successful deployment decisions. For
more info about how to do this and what you should consider, see the AppLocker Design Guide. This guide is
intended for security architects, security administrators, and system administrators. It contains the following topics
to help you create an AppLocker policy deployment plan for your organization that will address your specific
application control requirements by department, organizational unit, or business group:
1. Understand the AppLocker policy deployment process
2. Understand AppLocker policy design decisions
8. Create your AppLocker planning document
Step 2: Create your rules and rule collections

Each rule applies to one or more apps, and it imposes a specific rule condition on them. Rules can be created
individually or they can be generated by the Automatically Generate Rules Wizard. For the steps to create the rules,
see Create Your AppLocker rules.
Step 3: Configure the enforcement setting

An AppLocker policy is a set of rule collections that are configured with a rule enforcement setting. The
enforcement setting can be Enforce rules, Audit only, or Not configured. If an AppLocker policy has at least one
rule, and it is set to Not configured, all the rules in that policy will be enforced. For info about configuring the rule
enforcement setting, see Configure an AppLocker policy for audit only and Configure an AppLocker policy for
enforce rules.
Step 4: Update the GPO

AppLocker policies can be defined locally on a device or applied through Group Policy. To use Group Policy to
apply AppLocker policies, you must create a new Group Policy Object (GPO) or you must update an existing GPO.
You can create or modify AppLocker policies by using the Group Policy Management Console (GPMC), or you can
import an AppLocker policy into a GPO. For the procedure to do this, see Import an AppLocker policy into a GPO.
Step 5: Test the effect of the policy

In a test environment or with the enforcement setting set at Audit only, verify that the results of the policy are
what you intended. For info about testing a policy, see Test and update an AppLocker policy.
Step 6: Implement the policy

Depending on your deployment method, import the AppLocker policy to the GPO in your production environment,
or if the policy is already deployed, change the enforcement setting to your production environment value
Enforce rules or Audit only.
Step 7: Test the effect of the policy and adjust

Validate the effect of the policy by analyzing the AppLocker logs for application usage, and then modify the policy
as necessary. To do this, see Monitor app usage with AppLocker.
Next steps
Follow the steps described in the following topics to continue the deployment process:
1. Create Your AppLocker rules
2. Test and update an AppLocker policy
3. Deploy the AppLocker policy into production
See also
Create Your AppLocker rules
Applies to
Windows 10
This topic for the IT professional describes what you need to know about AppLocker rules and the methods that
you can to create rules.
Creating AppLocker rules

AppLocker rules apply to the targeted app, and they are the components that make up the AppLocker policy.
Depending on your IT environment and the business group that requires application control policies, setting these
access rules for each application can be time-consuming and prone to error. With AppLocker, you can generate
rules automatically or create rules individually. Creating rules that are derived from your planning document can
help you avoid unintended results. For info about this planning document and other planning activities, see
AppLocker Design Guide.
Automatically generate your rules
You can use a reference device to automatically create a set of default rules for each of the installed apps, test and
modify each rule as necessary, and deploy the policies. Creating most of the rules for all the installed apps gives
you a starting point to build and test your policies. For info about performing this task, see the following topics:
Configure the AppLocker reference device
Run the Automatically Generate Rules wizard
Create your rules individually
You can create rules and set the mode to Audit only for each installed app, test and update each rule as necessary,
and then deploy the policies. Creating rules individually might be best when you are targeting a small number of
applications within a business group.
Note: AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the
files that are required for Windows to operate properly are allowed in an AppLocker rule collection. You can
also edit the default rules. For information about creating the default rules for the Windows operating system,
see Create AppLocker default rules.
For information about performing this task, see:

1. Create a rule that uses a publisher condition
2. Create a rule that uses a path condition
3. Create a rule that uses a file hash condition
4. Edit AppLocker rules
5. Enforce AppLocker rules
6. Configure an AppLocker policy for audit only
About selecting rules
AppLocker policies are composed of distinct rules for specific apps. These rules are grouped by collection, and they
are implemented through an AppLocker policy definition. AppLocker policies are managed by using Group Policy
or by using the Local Security Policy snap-in for a single computer.
When you determine what types of rules to create for each of your business groups or organizational units (OUs),
you should also determine what enforcement setting to use for each group. Certain rule types are more applicable
for some apps, depending on how the apps are deployed in a specific business group.
For info about how to determine and document your AppLocker rules, see AppLocker Design Guide.
For info about AppLocker rules and AppLocker policies, see the following topics:
Next steps
1. Import an AppLocker policy into a GPO
2. Import an AppLocker policy from another computer
3. Test and update an AppLocker policy
4. Deploy the AppLocker policy into production
Related topics
Create Your AppLocker policies
Deploy the AppLocker policy into production
Applies to
Windows 10
This topic for the IT professional describes the tasks that should be completed before you deploy AppLocker
application control settings.
After successfully testing and modifying the AppLocker policy for each Group Policy Object (GPO), you are ready
to deploy the enforcement settings into production. For most organizations, this means switching the AppLocker
enforcement setting from Audit only to Enforce rules. However, it is important to follow the deployment plan
that you created earlier. For more info, see the AppLocker Design Guide. Depending on the needs of different
business groups in your organization, you might deploy different enforcement settings for linked GPOs.
Understand your design decisions
Before you deploy an AppLocker policy, you should determine:
For each business group, which applications will be controlled and in what manner. For more info, see Create a
list of apps deployed to each business group.
How to handle requests for application access. For info about what to consider when developing your support
policies, see Plan for AppLocker policy management.
How to manage events, including forwarding events. For info about event management in AppLocker, see
Monitor app usage with AppLocker.
Your GPO structure, including how to include policies generated by Software Restriction Policies and
AppLocker policies. For more info, see Determine the Group Policy structure and rule enforcement.
For info about how AppLocker deployment is dependent on design decisions, see Understand AppLocker policy
design decisions.
AppLocker deployment methods
If you have configured a reference device, you can create and update your AppLocker policies on this device, test
the policies, and then export the policies to the appropriate GPO for distribution. Another method is to create the
policies and set the enforcement setting on Audit only, then observe the events that are generated.
Use a reference device to create and maintain AppLocker policies
This topic describes the steps to use an AppLocker reference computer to prepare application control
policies for deployment by using Group Policy or other means.
Deploy AppLocker policies by using the enforce rules setting
This topic describes the steps to deploy the AppLocker policy by changing the enforcement setting to Audit
only or to Enforce rules.
See also
Use a reference device to create and maintain
AppLocker policies
Applies to
Windows 10
This topic for the IT professional describes the steps to create and maintain AppLocker policies by using a reference
computer.
Background and prerequisites

An AppLocker reference device is a baseline device you can use to configure policies and can subsequently be used
to maintain AppLocker policies. For the procedure to configure a reference device, see Configure the AppLocker
reference device.
An AppLocker reference device that is used to create and maintain AppLocker policies should contain the
corresponding apps for each organizational unit (OU) to mimic your production environment.
Important: The reference device must be running one of the supported editions of Windows. For information
about operating system requirements for AppLocker, see Requirements to use AppLocker.
You can perform AppLocker policy testing on the reference device by using the Audit only enforcement setting or
Windows PowerShell cmdlets. You can also use the reference device as part of a testing configuration that includes
policies that are created by using Software Restriction Policies.
Step 1: Automatically generate rules on the reference device

With AppLocker, you can automatically generate rules for all files within a folder. AppLocker scans the specified
folder and creates the condition types that you choose for each file in that folder. For the procedure to do this, see
Run the Automatically Generate Rules wizard.
Note: If you run this wizard to create your first rules for a Group Policy Object (GPO), after you complete the
wizard, you will be prompted to create the default rules, which allow critical system files to run. You can edit the
default rules at any time. If your organization has decided to edit the default rules or create custom rules to
allow the Windows system files to run, ensure that you delete the default rules after you replace them with
your custom rules.
Step 2: Create the default rules on the reference device

AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the files that
are required for Windows to operate properly are allowed in an AppLocker rule collection. You must run the
default rules for each rule collection. For info about default rules and considerations for using them, see
Understanding AppLocker default rules. For the procedure to create default rules, see Create AppLocker default
rules.
Important: You can use the default rules as a template when you create your own rules. This allows files within
the Windows directory to run. However, these rules are only meant to function as a starter policy when you are
first testing AppLocker rules.
Step 3: Modify rules and the rule collection on the reference device
If AppLocker policies are currently running in your production environment, export the policies from the
corresponding GPOs and save them to the reference device. For the procedure to do this, see Export an AppLocker
policy from a GPO. If no AppLocker policies have been deployed, create the rules and develop the policies by using
the following procedures:
Step 4: Test and update AppLocker policy on the reference device

You should test each set of rules to ensure that they perform as intended. The Test-AppLockerPolicy Windows
PowerShell cmdlet can be used to determine whether any of the rules in your rule collection will be blocked on
your reference device. Perform the steps on each reference device that you used to define the AppLocker policy.
Ensure that the reference device is joined to the domain and that it is receiving the AppLocker policy from the
appropriate GPO. Because AppLocker rules are inherited from linked GPOs, you should deploy all of the rules to
simultaneously test all of your test GPOs. Use the following procedures to complete this step:
Test an AppLocker Policy with Test-AppLockerPolicy
Discover the Effect of an AppLocker Policy
Caution: If you have set the enforcement setting on the rule collection to Enforce rules or you have not
configured the rule collection, the policy will be implemented when the GPO is updated in the next step. If you
have set the enforcement setting on the rule collection to Audit only, application access events are written to
the AppLocker log, and the policy will not take effect.
Step 5: Export and import the policy into production

When the AppLocker policy has been tested successfully, it can be imported into the GPO (or imported into
individual computers that are not managed by Group Policy) and checked for its intended effectiveness. To do this,
perform the following procedures:
Export an AppLocker policy to an XML file
Import an AppLocker policy into a GPO or
Discover the Effect of an AppLocker Policy
If the AppLocker policy enforcement setting is Audit only and you are satisfied that the policy is fulfilling your
intent, you can change it to Enforce rules. For info about how to change the enforcement setting, see Configure an
AppLocker policy for enforce rules.
Step 6: Monitor the effect of the policy in production

If additional refinements or updates are necessary after a policy is deployed, use the appropriate following
procedures to monitor and update the policy:
Edit an AppLocker policy
Refresh an AppLocker policy
See also
Deploy the AppLocker policy into production
Determine which apps are digitally signed on a
reference device
Applies to
Windows 10
This topic for the IT professional describes how to use AppLocker logs and tools to determine which applications
are digitally signed.
The Windows PowerShell cmdlet Get-AppLockerFileInformation can be used to determine which apps installed
on your reference devices are digitally signed. Perform the following steps on each reference computer that you
used to define the AppLocker policy. The device does not need to be joined to the domain.
procedure.
To determine which apps are digitally signed on a reference device
1. Run Get-AppLockerFileInformation with the appropriate parameters.
The Get-AppLockerFileInformation cmdlet retrieves the AppLocker file information from a list of files or
from an event log. File information that is retrieved can include publisher information, file hash information,
and file path information. File information from an event log may not contain all of these fields. Files that are
not signed do not have any publisher information.
2. Analyze the publisher's name and digital signature status from the output of the command.
For command parameters, syntax, and examples, see Get-AppLockerFileInformation.
Related topics
Configure the AppLocker reference device
Applies to
Windows 10
This topic for the IT professional describes the steps to create an AppLocker policy platform structure on a
reference computer.
An AppLocker reference device that is used for the development and deployment of AppLocker policies should
mimic the directory structure and corresponding applications in the organizational unit (OU) or business group for
the production environment. On a reference device, you can:
Maintain an application list for each business group.
Develop AppLocker policies by creating individual rules or by creating a policy by automatically generating
rules.
Create the default rules to allow the Windows system files to run properly.
Run tests and analyze the event logs to determine the affect of the policies that you intend to deploy.
The reference device does not need to be joined to a domain, but it must be able to import and export AppLocker
policies in XML format. The reference computer must be running one of the supported editions of Windows as
listed in Requirements to use AppLocker.
Warning: Do not use operating system snapshots when creating AppLocker rules. If you take a snapshot of the
operating system, install an app, create AppLocker rules, and then revert to a clean snapshot and repeat the
process for another app, there is a chance that duplicate rule GUIDs can be created. If duplicate GUIDs are
present, AppLocker policies will not work as expected.
To configure a reference device

1. If the operating system is not already installed, install one of the supported editions of Windows on the
device.
Note: If you have the Group Policy Management Console (GPMC) installed on another device to test
your implementation of AppLocker policies, you can export the policies to that device
2. Configure the administrator account.

To update local policies, you must be a member of the local Administrators group. To update domain
policies, you must be a member of the Domain Admins group or have been delegated privileges to use
Group Policy to update a Group Policy Object (GPO).
3. Install all apps that run in the targeted business group or OU by using the same directory structure.
The reference device should be configured to mimic the structure of your production environment. It
depends on having the same apps in the same directories to accurately create the rules.
See also
After you configure the reference computer, you can create the AppLocker rule collections. You can build,
import, or automatically generate the rules. For procedures to do this, see Working with AppLocker rules.
Applies to
Windows 10
This overview topic for IT professionals provides links to the topics in the technical reference. AppLocker advances
the application control features and functionality of Software Restriction Policies. AppLocker contains new
capabilities and extensions that allow you to create rules to allow or deny apps from running based on unique
identities of files and to specify which users or groups can run those apps.
In this section
TOPIC DESCRIPTION
What Is AppLocker? This topic for the IT professional describes what AppLocker is
and how its features differ from Software Restriction Policies.
Requirements to use AppLocker This topic for the IT professional lists software requirements
to use AppLocker on the supported Windows operating
systems.
AppLocker policy use scenarios This topic for the IT professional lists the various application
control scenarios in which AppLocker policies can be
effectively implemented.
How AppLocker works This topic for the IT professional provides links to topics
about AppLocker architecture and components, processes
and interactions, rules and policies.
AppLocker architecture and components This topic for IT professional describes AppLockers basic
architecture and its major components.
AppLocker processes and interactions This topic for the IT professional describes the process
dependencies and interactions when AppLocker evaluates
and enforces rules.
AppLocker functions This topic for the IT professional lists the functions and
security levels for the Software Restriction Policies (SRP) and
AppLocker features.
Security considerations for AppLocker This topic for the IT professional describes the security
considerations you need to address when implementing
AppLocker.
Tools to Use with AppLocker This topic for the IT professional describes the tools available
to create and administer AppLocker policies.
AppLocker Settings This topic for the IT professional lists the settings used by
AppLocker.
What Is AppLocker?
Applies to
Windows 10
This topic for the IT professional describes what AppLocker is and how its features differ from Software Restriction
Policies.
AppLocker advances the app control features and functionality of Software Restriction Policies. AppLocker contains
new capabilities and extensions that allow you to create rules to allow or deny apps from running based on unique
identities of files and to specify which users or groups can run those apps.
Using AppLocker, you can:
Control the following types of apps: executable files (.exe and .com), scripts (.js, .ps1, .vbs, .cmd, and .bat),
Windows Installer files (.mst, .msi and .msp), and DLL files (.dll and .ocx), and packaged apps and packaged app
installers (appx).
Define rules based on file attributes derived from the digital signature, including the publisher, product name,
file name, and file version. For example, you can create rules based on the publisher attribute that is persistent
through updates, or you can create rules for a specific version of a file.
Create exceptions to rules. For example, you can create a rule that allows all Windows processes to run except
Registry Editor (Regedit.exe).
Import and export rules. The import and export affects the entire policy. For example, if you export a policy, all of
the rules from all of the rule collections are exported, including the enforcement settings for the rule collections.
If you import a policy, all criteria in the existing policy are overwritten.
Streamline creating and managing AppLocker rules by using Windows PowerShell cmdlets.
AppLocker helps reduce administrative overhead and helps reduce the organization's cost of managing computing
resources by decreasing the number of help desk calls that result from users running unapproved apps
For information about the application control scenarios that AppLocker addresses, see AppLocker policy use
scenarios.
What features are different between Software Restriction Policies and

AppLocker?
Feature differences
The following table compares AppLocker to Software Restriction Policies.
FEATURE SOFTWARE RESTRICTION POLICIES APPLOCKER
Rule scope All users Specific user or group
Rule conditions provided File hash, path, certificate, registry File hash, path, and publisher
path, and Internet zone
FEATURE SOFTWARE RESTRICTION POLICIES APPLOCKER
Rule types provided Defined by the security levels: Allow and deny
Disallowed
Basic User
Unrestricted
Default rule action Unrestricted Implicit deny
Audit-only mode No Yes
Wizard to create multiple rules at No Yes

one time
Policy import or export No Yes
Rule collection No Yes
Windows PowerShell support No Yes
Custom error messages No Yes
Application control function differences

The following table compares the application control functions of Software Restriction Policies (SRP) and
AppLocker.
Operating system scope SRP policies can be applied to all AppLocker policies apply only to
Windows operating systems those supported operating system
beginning with Windows XP and versions and editions listed in
Windows Server 2003. Requirements to use AppLocker.
But these systems can also use SRP.
Note
Use different GPOs for SRP and
AppLocker rules.
User support SRP allows users to install AppLocker policies are maintained
applications as an administrator. through Group Policy, and only the
administrator of the device can
update an AppLocker policy.
AppLocker permits customization of
error messages to direct users to a
Web page for help.
Policy maintenance SRP policies are updated by using AppLocker policies are updated by
the Local Security Policy snap-in or using the Local Security Policy
the Group Policy Management snap-in or the GPMC.
Console (GPMC).
AppLocker supports a small set of
PowerShell cmdlets to aid in
administration and maintenance.
Policy management infrastructure To manage SRP policies, SRP uses To manage AppLocker policies,
Group Policy within a domain and AppLocker uses Group Policy within
the Local Security Policy snap-in for a domain and the Local Security
a local computer. Policy snap-in for a local computer.
Block malicious scripts Rules for blocking malicious scripts AppLocker rules can control the
prevents all scripts associated with following file formats: .ps1, .bat,
the Windows Script Host from .cmd, .vbs, and .js. In addition, you
running, except those that are can set exceptions to allow specific
digitally signed by your files to run.
organization.
Manage software installation SRP can prevent all Windows The Windows Installer rule
Installer packages from installing. It collection is a set of rules created
allows .msi files that are digitally for Windows Installer file types
signed by your organization to be (.mst, .msi and .msp) to allow you to
installed. control the installation of files on
client computers and servers.
Manage all software on the All software is managed in one rule Unlike SRP, each AppLocker rule
computer set. By default, the policy for collection functions as an allowed
managing all software on a device list of files. Only the files that are
disallows all software on the user's listed within the rule collection will
device, except software that is be allowed to run. This
installed in the Windows folder, configuration makes it easier for
Program Files folder, or subfolders. administrators to determine what
will occur when an AppLocker rule is
applied.
Different policies for different users Rules are applied uniformly to all On a device that is shared by
users on a particular device. multiple users, an administrator can
specify the groups of users who can
access the installed software. Using
AppLocker, an administrator can
specify the user to whom a specific
rule should apply.
Related topics
Requirements to use AppLocker
Applies to
Windows 10
This topic for the IT professional lists software requirements to use AppLocker on the supported Windows
operating systems.
General requirements
To use AppLocker, you need:
A device running a supported operating system to create the rules. The computer can be a domain
controller.
For Group Policy deployment, at least one device with the Group Policy Management Console (GPMC) or
Remote Server Administration Tools (RSAT) installed to host the AppLocker rules.
Devices running a supported operating system to enforce the AppLocker rules that you create.
Note: You can use Software Restriction Policies with AppLocker, but with some limitations. For more info,
see Use AppLocker and Software Restriction Policies in the same domain.
Operating system requirements

The following table show the on which operating systems AppLocker features are supported.
VERSION CAN BE CONFIGURED CAN BE ENFORCED AVAILABLE RULES NOTES
Windows 10 Yes Yes Packaged apps You can use the

Executable AppLocker CSP to
Windows Installer configure AppLocker
Script policies on any
DLL edition of Windows
10. You can only
manage AppLocker
with Group Policy on
devices running
Windows 10
Enterprise, Windows
10 Education, and
Windows Server
2016.
Windows Server Yes Yes Packaged apps

2016 Executable
Windows Server Windows Installer
2012 R2 Script
Windows Server DLL
2012
VERSION CAN BE CONFIGURED CAN BE ENFORCED AVAILABLE RULES NOTES
Windows 8.1 Yes Yes Packaged apps Only the Enterprise

Executable edition supports
Windows Installer AppLocker
Script
DLL
Windows RT 8.1 No No N/A
Windows 8 Pro No No N/A
Windows 8 Yes Yes Packaged apps

Enterprise Executable
Windows Installer
Script
DLL
Windows RT No No N/A
Windows Server Yes Yes Executable Packaged app rules

2008 R2 Standard Windows Installer will not be enforced.
Script
DLL

2008 R2 Enterprise Windows Installer will not be enforced.
Script
DLL

2008 R2 Datacenter Windows Installer will not be enforced.
Script
DLL

2008 R2 for Windows Installer will not be enforced.
Itanium-Based Script
Systems DLL
Windows 7 Ultimate Yes Yes Executable Packaged app rules

Windows Installer will not be enforced.
Script
DLL
Windows 7 Yes Yes Executable Packaged app rules

Enterprise Windows Installer will not be enforced.
Script
DLL
Windows 7 Yes No Executable No AppLocker rules

Professional Windows Installer are enforced.
Script
DLL
AppLocker is not supported on versions of the Windows operating system not listed above. Software
Restriction Policies can be used with those versions. However, the SRP Basic User feature is not supported on
the above operating systems.
See also
Optimize AppLocker performance
Use AppLocker and Software Restriction Policies in the same domain
Manage packaged apps with AppLocker
AppLocker Design Guide
AppLocker policy use scenarios
Applies to
Windows 10
This topic for the IT professional lists the various application control scenarios in which AppLocker policies can be
effectively implemented.
AppLocker can help you improve the management of application control and the maintenance of application
control policies. Application control scenarios addressed by AppLocker can be categorized as follows:
1. App inventory
AppLocker has the ability to enforce its policy in an audit-only mode where all app access activity is collected
in event logs for further analysis. Windows PowerShell cmdlets are also available to help you understand
app usage and access.
2. Protection against unwanted software
AppLocker has the ability to deny apps from running simply by excluding them from the list of allowed apps
per business group or user. If an app is not specifically identified by its publisher, installation path, or file
hash, the attempt to run the application fails.
3. Licensing conformance
AppLocker can provide an inventory of software usage within your organization, so you can identify the
software that corresponds to your software licensing agreements and restrict application usage based on
licensing agreements.
4. Software standardization
AppLocker policies can be configured to allow only supported or approved apps to run on computers within
a business group. This permits a more uniform app deployment.
5. Manageability improvement
AppLocker policies can be modified and deployed through your existing Group Policy infrastructure and can
work in conjunction with policies created by using Software Restriction Policies. As you manage ongoing
change in your support of a business group's apps, you can modify policies and use the AppLocker cmdlets
to test the policies for the expected results. You can also design application control policies for situations in
which users share computers.
Use scenarios
The following are examples of scenarios in which AppLocker can be used:
Your organization implements a policy to standardize the applications used within each business group, so you
need to determine the expected usage compared to the actual usage.
The security policy for application usage has changed, and you need to evaluate where and when those
deployed apps are being accessed.
Your organization's security policy dictates the use of only licensed software, so you need to determine which
apps are not licensed or prevent unauthorized users from running licensed software.
An app is no longer supported by your organization, so you need to prevent it from being used by everyone.
Your organization needs to restrict the use of Universal Windows apps to just those your organization approves
of or develops.
The potential that unwanted software can be introduced in your environment is high, so you need to reduce this
threat.
The license to an app has been revoked or is expired in your organization, so you need to prevent it from being
used by everyone.
A new app or a new version of an app is deployed, and you need to allow certain groups to use it.
Specific software tools are not allowed within the organization, or only specific users have access to those tools.
A single user or small group of users needs to use a specific app that is denied for all others.
Some computers in your organization are shared by people who have different software usage needs.
In addition to other measures, you need to control the access to sensitive data through app usage.
Related topics
How AppLocker works
Applies to
Windows 10
This topic for the IT professional provides links to topics about AppLocker architecture and components, processes
and interactions, rules and policies.
The following topics explain how AppLocker policies for each of the rule condition types are evaluated:
AppLocker architecture and components
AppLocker processes and interactions
The following topics explain how AppLocker rules and policies work:
Understanding the publisher rule condition in AppLocker
Understanding the path rule condition in AppLocker
Understanding the file hash rule condition in AppLocker
Executable rules in AppLocker
Windows Installer rules in AppLocker
Script rules in AppLocker
DLL rules in AppLocker
Packaged apps and packaged app installer rules in AppLocker
AppLocker Design Guide
Applies to
Windows 10
This topic describes how AppLocker rules are enforced by using the allow and deny options in AppLocker.
If no AppLocker rules for a specific rule collection exist, all files with that file format are allowed to run. However,
when an AppLocker rule for a specific rule collection is created, only the files explicitly allowed in a rule are
permitted to run. For example, if you create an executable rule that allows .exe files in %SystemDrive%\FilePath to
run, only executable files located in that path are allowed to run.
A rule can be configured to use either an allow or deny action:
Allow. You can specify which files are allowed to run in your environment and for which users or groups of
Deny. You can specify which files are not allowed to run in your environment and for which users or groups of
Important: You can use a combination of allow actions and deny actions. However, we recommend using
allow actions with exceptions because deny actions override allow actions in all cases. Deny actions can also be
circumvented. For example, if you configure a deny action for a file or folder path, the user can still run the file
from any other path.
Related topics
How AppLocker works
Applies to
Windows 10
This topic describes the result of applying AppLocker rule exceptions to rule collections.
You can apply AppLocker rules to individual users or a group of users. If you apply a rule to a group of users, all
users in that group are affected by that rule. If you need to allow a subset of a user group to use an app, you can
create a special rule for that subset.
For example, the rule "Allow Everyone to run Windows except Registry Editor" allows everyone in the organization
to run Windows but does not allow anyone to run Registry Editor. The effect of this rule would prevent users such
as help desk personnel from running a program that is necessary for their support tasks. To resolve this problem,
create a second rule that applies to the Helpdesk user group: "Allow Helpdesk to run Registry Editor." If you create
a deny rule that does not allow any users to run Registry Editor, the deny rule will override the second rule that
allows the Helpdesk user group to run Registry Editor.
Related topics
How AppLocker works
Applies to
Windows 10
This topic explains the five different types of AppLocker rules used to enforce AppLocker policies.
An AppLocker rule collection is a set of rules that apply to one of five types:
Executable files: .exe and .com
Windows Installer files: .msi, mst, and .msp
Scripts: .ps1, .bat, .cmd, .vbs, and .js
DLLs: .dll and .ocx
Packaged apps and packaged app installers: .appx
If you use DLL rules, a DLL allow rule has to be created for each DLL that is used by all of the allowed apps.
Important: Each app can load several DLLs, and AppLocker must check each DLL before it is allowed to run.
Therefore, creating DLL rules might cause performance problems on some computers. Denying some DLLs
from running can also create app compatibility problems. As a result, the DLL rule collection is not enabled by
default.
For info about how to enable the DLL rule collection, see Enable the DLL rule collection.
Related topics
How AppLocker works
Understanding AppLocker allow and deny actions on
rules
Applies to
Windows 10
This topic explains the differences between allow and deny actions on AppLocker rules.
Allow action versus deny action on rules

Unlike Software Restriction Policies (SRP), each AppLocker rule collection functions as an allowed list of files. Only
the files that are listed within the rule collection are allowed to run. This configuration makes it easier to determine
what will occur when an AppLocker rule is applied.
You can also create rules that use the deny action. When applying rules, AppLocker first checks whether any
explicit deny actions are specified in the rule list. If you have denied a file from running in a rule collection, the
deny action will take precedence over any allow action, regardless of which Group Policy Object (GPO) the rule
was originally applied in. Because AppLocker functions as an allowed list by default, if no rule explicitly allows or
denies a file from running, AppLocker's default deny action will block the file.
Deny rule considerations
Although you can use AppLocker to create a rule to allow all files to run and then use rules to deny specific files,
this configuration is not recommended. The deny action is generally less secure than the allow action because a
malicious user could modify the file to invalidate the rule. Deny actions can also be circumvented. For example, if
you configure a deny action for a file or folder path, the user can still run the file from any other path. The
following table details security concerns for different rule conditions with deny actions.
RULE CONDITION SECURITY CONCERN WITH DENY ACTION
Publisher A user could modify the properties of a file (for example, re-
signing the file with a different certificate).
File hash A user could modify the hash for a file.
Path A user could move the denied file to a different location and
run it from there.
Important: If you choose to use the deny action on rules, you must ensure that you first create rules that allow
the Windows system files to run. AppLocker enforces rules for allowed applications by default, so after one or
more rules have been created for a rule collection (affecting the Windows system files), only the apps that are
listed as being allowed will be permitted to run. Therefore, creating a single rule in a rule collection to deny a
malicious file from running will also deny all other files on the computer from running.
Related topics
How AppLocker works
Applies to
Windows 10
This topic for the IT professional describes the three types of AppLocker rule conditions.
Rule conditions are criteria that the AppLocker rule is based on. Primary conditions are required to create an
AppLocker rule. The three primary rule conditions are publisher, path, and file hash.
Publisher
To use a publisher condition, the files must be digitally signed by the software publisher, or you must do so by
using an internal certificate. Rules that are specified to the version level might have to be updated when a new
version of the file is released. For more info about this rule condition, see Understanding the publisher rule
condition in AppLocker.
Path
Any file can be assigned this rule condition; however, because path rules specify locations within the file system,
any subdirectory will also be affected by the rule (unless explicitly exempted). For more info about this rule
condition, see Understanding the path rule condition in AppLocker.
File hash
Any file can be assigned this rule condition; however, the rule must be updated each time a new version of the file
is released because the hash value is unique to that the version of the file. For more info about this rule condition,
see Understanding the file hash rule condition in AppLocker.
Considerations
Selecting the appropriate condition for each rule depends on the overall application control policy goals of the
organization, the AppLocker rule maintenance goals, and the condition of the existing (or planned) application
deployment. The following questions can help you decide which rule condition to use.
1. Is the file digitally signed by a software publisher?
If the file is signed by a software publisher, we recommend that you create rules with publisher conditions.
You may still create file hash and path conditions for signed files. However, if the file is not digitally signed
by a software publisher, you can:
Sign the file by using an internal certificate.
Create a rule by using a file hash condition.
Create a rule by using a path condition.
Note: To determine how many applications on a reference computer are digitally signed, you
can use the Get-AppLockerFileInformation Windows PowerShell cmdlet for a directory of
files. For example, Get-AppLockerFileInformation Directory C:\Windows\ -FileType EXE -recurse
displays the properties for all .exe and .com files within the Windows directory.
2. What rule condition type does your organization prefer?

If your organization is already using Software Restriction Policies (SRP) to restrict what files users can run,
rules using file hash or path conditions are probably already in place.
Note: For a list of supported operating system versions and editions to which SRP and AppLocker
rules can be applied, see Requirements to use AppLocker.
Related topics
How AppLocker works
Understanding the publisher rule condition in
AppLocker
Applies to
Windows 10
This topic explains the AppLocker publisher rule condition, what controls are available, and how it is applied.
Publisher conditions can be made only for files that are digitally signed; this condition identifies an app based on
its digital signature and extended attributes. The digital signature contains information about the company that
created the app (the publisher). The extended attributes, which are obtained from the binary resource, contain the
name of the product that the app is part of and the version number of the app. The publisher may be a software
development company, such as Microsoft, or the Information Technology department of your organization.
Publisher conditions are easier to maintain than file hash conditions and are generally more secure than path
conditions. Rules that are specified to the version level might have to be updated when a new version of the file is
released. The following table describes the advantages and disadvantages of the publisher condition.
PUBLISHER CONDITION ADVANTAGES PUBLISHER CONDITION DISADVANTAGES
Frequent updating is not required. The file must be signed.

You can apply different values within a certificate. Although a single rule can be used to allow an
entire product suite, all files in the suite must be
A single rule can be used to allow an entire signed uniformly.
product suite.
You can use the asterisk (*) wildcard character
within a publisher rule to specify that any value
should be matched.
Wildcard characters can be used as values in the publisher rule fields according to the following specifications:
Publisher
The asterisk (*) character used by itself represents any publisher. When combined with any string value, the
rule is limited to the publisher with a value in the signed certificate that matches the character string. In
other words, the asterisk is not treated as a wildcard character if used with other characters in this field. For
example, using the characters "M*" limits the publisher name to only a publisher with the name "M*." Using
the characters "*x*" limits the publisher name only to the name *x*. A question mark (?) is not a valid
wildcard character in this field.
Product name
The asterisk (*) character used by itself represents any product name. When combined with any string
value, the rule is limited to the product of the publisher with a value in the signed certificate that matches
the character string. In other words, the asterisk is not treated as a wildcard character if used with other
characters in this field. A question mark (?) is not a valid wildcard character in this field.
File name
Either the asterisk (*) or question mark (?) characters used by themselves represent any and all file names.
When combined with any string value, the string is matched with any file name containing that string.
File version
The asterisk (*) character used by itself represents any file version. If you want to limit the file version to a
specific version or as a starting point, you can state the file version and then use the following options to
apply limits:
Exactly. The rule applies only to this version of the app
And above. The rule applies to this version and all later versions.
And Below. The rule applies to this version and all earlier versions.
The following table describes how a publisher condition is applied.
All signed files All files that are signed by a publisher.
Publisher only All files that are signed by the named publisher.
Publisher and product name All files for the specified product that are signed by the
named publisher.
Publisher, product name, and file name Any version of the named file for the named product that is
signed by the publisher.
Publisher, product name, file name, and file version Exactly

The specified version of the named file for the named product
that is signed by the publisher.
Publisher, product name, file name, and file version And above
The specified version of the named file and any new releases
for the product that are signed by the publisher.
Publisher, product name, file name, and file version And below
The specified version of the named file and any older versions
for the product that are signed by the publisher.
Custom You can edit the Publisher, Product name, File name, and
Version fields to create a custom rule.
For an overview of the three types of AppLocker rule conditions and explanations of the advantages and
disadvantages of each, see Understanding AppLocker rule condition types.
Related topics
How AppLocker works
Applies to
Windows 10
This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it is applied.
The path condition identifies an application by its location in the file system of the computer or on the network.
When creating a rule that uses a deny action, path conditions are less secure than publisher and file hash
conditions for preventing access to a file because a user could easily copy the file to a different location than the
location specified in the rule. Because path rules specify locations within the file system, you should ensure that
there are no subdirectories that are writable by non-administrators. For example, if you create a path rule for C:\
with the allow action, any file under that location will be allowed to run, including within users' profiles. The
following table describes the advantages and disadvantages of the path condition.
PATH CONDITION ADVANTAGES PATH CONDITION DISADVANTAGES
You can easily control many folders or a single file. It might be less secure if a rule that is configured
to use a folder path contains subfolders that are
You can use the asterisk (*) as a wildcard character writable by non-administrators.
within path rules.
You must specify the full path to a file or folder
when creating path rules so that the rule will be
properly enforced.
AppLocker does not enforce rules that specify paths with short names. You should always specify the full path to a
file or folder when creating path rules so that the rule will be properly enforced.
The asterisk (*) wildcard character can be used within Path field. The asterisk (*) character used by itself
represents any path. When combined with any string value, the rule is limited to the path of the file and all the files
under that path. For example, %ProgramFiles%\Internet Explorer\* indicates that all files and subfolders within the
Internet Explorer folder will be affected by the rule.
AppLocker uses path variables for well-known directories in Windows. Path variables are not environment
variables. The AppLocker engine can only interpret AppLocker path variables. The following table details these
path variables.
WINDOWS DIRECTORY OR DRIVE APPLOCKER PATH VARIABLE WINDOWS ENVIRONMENT VARIABLE
Windows %WINDIR% %SystemRoot%
System32 %SYSTEM32% %SystemDirectory%
Windows installation directory %OSDRIVE% %SystemDrive%
Program Files %PROGRAMFILES% %ProgramFiles% and

%ProgramFiles(x86)%
WINDOWS DIRECTORY OR DRIVE APPLOCKER PATH VARIABLE WINDOWS ENVIRONMENT VARIABLE
Removable media (for example, CD or %REMOVABLE%

DVD)
Removable storage device (for example, %HOT%

USB flash drive)
Related topics
How AppLocker works
Understanding the file hash rule condition in
AppLocker
Applies to
Windows 10
This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it is applied.
File hash rules use a system-computed cryptographic hash of the identified file. For files that are not digitally
signed, file hash rules are more secure than path rules. The following table describes the advantages and
disadvantages of the file hash condition.
FILE HASH CONDITION ADVANTAGES FILE HASH CONDITION DISADVANTAGES
Because each file has a unique hash, a file hash condition Each time that the file is updated (such as a security update or
applies to only one file. upgrade), the file's hash will change. As a result, you must
manually update file hash rules.
Related topics
How AppLocker works
Applies to
Windows 10
This topic for IT professional describes the set of rules that can be used to ensure that required Windows system
files are allowed to run when the policy is applied.
AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the files
that are required for Windows to operate properly are allowed in an AppLocker rule collection.
Important: You can use the default rules as a template when creating your own rules. However, these rules
are only meant to function as a starter policy when you are first testing AppLocker rules so that the system
files in the Windows folders will be allowed to run.
If you require additional app security, you might need to modify the rules created from the built-in default rule
collection. For example, the default rule to allow all users to run .exe files in the Windows folder is based on a
path condition that allows all files within the Windows folder to run. The Windows folder contains a Temp
subfolder to which the Users group is given the following permissions:
Create Files/Write Data
Create Folders/Append Data
These permissions settings are applied to this folder for app compatibility. However, because any user can create
files in this location, allowing applications to be run from this location might conflict with your organization's
security policy.
In this section
TOPIC DESCRIPTION
Executable rules in AppLocker This topic describes the file formats and available default
rules for the executable rule collection.
Windows Installer rules in AppLocker This topic describes the file formats and available default
rules for the Windows Installer rule collection.
Script rules in AppLocker This topic describes the file formats and available default
rules for the script rule collection.
DLL rules in AppLocker This topic describes the file formats and available default
rules for the DLL rule collection.
Packaged apps and packaged app installer rules in AppLocker This topic explains the AppLocker rule collection for packaged
app installers and packaged apps.
Related topics
How AppLocker works
Applies to
Windows 10
This topic describes the file formats and available default rules for the executable rule collection.
AppLocker defines executable rules as any files with the .exe and .com extensions that are associated with an app.
Because all of the default rules for the executable rule collection are based on folder paths, all files under those
paths will be allowed. The following table lists the default rules that are available for the executable rule collection.
PURPOSE NAME USER RULE CONDITION TYPE
Allow members of the local (Default Rule) All files BUILTIN\Administrators Path: *
Administrators group access
to run all executable files
Allow all users to run (Default Rule) All files located Everyone Path: %windir%*
executable files in the in the Windows folder
Windows folder
Allow all users to run (Default Rule) All files located Everyone Path: %programfiles%*
executable files in the in the Program Files folder
Program Files folder
Related topics
Understanding AppLocker Default Rules
Applies to
Windows 10
This topic describes the file formats and available default rules for the Windows Installer rule collection.
AppLocker defines Windows Installer rules to include only the following file formats:
.msi
.msp
.mst
The purpose of this collection is to allow you to control the installation of files on client computers and servers
through Group Policy or the Local Security Policy snap-in. The following table lists the default rules that are
available for the Windows Installer rule collection.
Allow members of the local (Default Rule) All Windows BUILTIN\Administrators Path: *
Administrators group to run Installer files
all Windows Installer files
Allow all users to run (Default Rule) All digitally Everyone Publisher: * (all signed files)
Windows Installer files that signed Windows Installer
are digitally signed files
Allow all users to run (Default Rule) All Windows Everyone Path: %windir%\Installer*
Windows Installer files that Installer files in
are located in the Windows %systemdrive%\Windows\In
Installer folder staller
Related topics
Applies to
Windows 10
This topic describes the file formats and available default rules for the script rule collection.
AppLocker defines script rules to include only the following file formats:
.ps1
.bat
.cmd
.vbs
.js
The following table lists the default rules that are available for the script rule collection.
Allows members of the local (Default Rule) All scripts BUILTIN\Administrators Path: *
Administrators group to run
all scripts
Allow all users to run scripts (Default Rule) All scripts Everyone Path: %windir%*
in the Windows folder located in the Windows
folder
Allow all users to run scripts (Default Rule) All scripts Everyone Path: %programfiles%*
in the Program Files folder located in the Program Files
folder
Related topics
Applies to
Windows 10
This topic describes the file formats and available default rules for the DLL rule collection.
AppLocker defines DLL rules to include only the following file formats:
.dll
.ocx
The following table lists the default rules that are available for the DLL rule collection.
Allows members of the local (Default Rule) All DLLs

Administrators group to run
all DLLs
BUILTIN\Administrators Path: *
Allow all users to run DLLs (Default Rule) Microsoft

in the Windows folder Windows DLLs
Everyone Path: %windir%*
Allow all users to run DLLs (Default Rule) All DLLs

in the Program Files folder located in the Program Files
folder
Everyone Path: %programfiles%*
Important: If you use DLL rules, a DLL allow rule has to be created for each DLL that is used by all of the
allowed apps
Caution: When DLL rules are used, AppLocker must check each DLL that an app loads. Therefore, users may
experience a reduction in performance if DLL rules are used.
Related topics
Packaged apps and packaged app installer rules in
AppLocker
Applies to
Windows 10
This topic explains the AppLocker rule collection for packaged app installers and packaged apps.
Universal Windows apps can be installed through the Windows Store or can be sideloaded using the Windows
PowerShell cmdlets. Universal Windows apps can be installed by a standard user unlike some Classic Windows
applications that sometimes require administrative privileges for installation. Typically, an app consists of multiple
components the installer used to install the app and one or more exes, dlls or scripts. With Classic Windows
applications, not all those components always share common attributes such as the publisher name, product
name and product version. Therefore, AppLocker has to control each of these components separately through
different rule collections exe, dll, script and Windows Installers. In contrast, all the components of a Universal
Windows app share the same attributes: Publisher name, Package name and Package version. It is therefore
possible to control an entire app with a single rule.
AppLocker enforces rules for Universal Windows apps separately from Classic Windows applications. A single
AppLocker rule for a Universal Windows app can control both the installation and the running of an app. Because
all Universal Windows apps are signed, AppLocker supports only publisher rules for Universal Windows apps. A
publisher rule for a Universal Windows app is based on the following attributes of the app:
Publisher name
Package name
Package version
In summary, including AppLocker rules for Universal Windows apps in your policy design provides:
The ability to control the installation and running of the app
The ability to control all the components of the app with a single rule rather than controlling individual binaries
within the app
The ability to create application control policies that survive app updates
Management of Universal Windows apps through Group Policy.
AppLocker architecture and components
Applies to
Windows 10
This topic for IT professional describes AppLockers basic architecture and its major components.
AppLocker relies on the Application Identity service to provide attributes for a file and to evaluate the AppLocker
policy for the file. AppLocker policies are conditional access control entries (ACEs), and policies are evaluated by
using the attribute-based access control SeAccessCheckWithSecurityAttributes or AuthzAccessCheck
functions.
AppLocker provides three ways to intercept and validate if a file is allowed to execute according to an AppLocker
policy.
A new process is created
When a new process is created, such as an executable file or a Universal Windows app is run, AppLocker invokes
the Application Identity component to calculate the attributes of the main executable file used to create a new
process. It then updates the new process's token with these attributes and checks the AppLocker policy to verify
that the executable file is allowed to run.
A DLL is loaded
When a new DLL loads, a notification is sent to AppLocker to verify that the DLL is allowed to load. AppLocker calls
the Application Identity component to calculate the file attributes. It duplicates the existing process token and
replaces those Application Identity attributes in the duplicated token with attributes of the loaded DLL. AppLocker
then evaluates the policy for this DLL, and the duplicated token is discarded. Depending on the result of this check,
the system either continues to load the DLL or stops the process.
A script is run
Before a script file is run, the script host (for example. for .ps1 files the script host is PowerShell) invokes AppLocker
to verify the script. AppLocker invokes the Application Identity component in user-mode with the file name or file
handle to calculate the file properties. The script file then is evaluated against the AppLocker policy to verify that it
is allowed to run. In each case, the actions taken by AppLocker are written to the event log.
Related topics
AppLocker processes and interactions
Applies to
Windows 10
This topic for the IT professional describes the process dependencies and interactions when AppLocker evaluates
and enforces rules.
How policies are implemented by AppLocker

AppLocker policies are collections of AppLocker rules that might contain any one of the enforcement settings
configured. When applied, each rule is evaluated within the policy and the collection of rules is applied according to
the enforcement setting and according to your Group Policy structure.
The AppLocker policy is enforced on a computer through the Application Identity service, which is the engine that
evaluates the policies. If the service is not running, policies will not be enforced. The Application Identity service
returns the information from the binaryeven if product or binary names are emptyto the results pane of the
Local Security Policy snap-in.
AppLocker policies are stored in a security descriptor format according to Application Identity service
requirements. It uses file path, hash, or fully qualified binary name attributes to form allow or deny actions on a
rule. Each rule is stored as an access control entry (ACE) in the security descriptor and contains the following
information:
Either an allow or a deny ACE ("XA" or "XD" in security descriptor definition language (SDDL) form).
The user security identifier (SID) that this rule is applicable to. (The default is the authenticated user SID, or "AU"
in SDDL.)
The rule condition containing the appid attributes.
For example, an SDDL for a rule that allows all files in the %windir% directory to run uses the following format:
XA;;FX;;;AU;(APPID://PATH == "%windir%\*").
An AppLocker policy for DLLs and executable files is read and cached by kernel mode code, which is part of
appid.sys. Whenever a new policy is applied, appid.sys is notified by a policy converter task. For other file types, the
AppLocker policy is read every time a SaferIdentifyLevel call is made.
Understanding AppLocker rules
An AppLocker rule is a control placed on a file to govern whether or not it is allowed to run for a specific user or
group. Rules apply to five different types, or collections, of files:
An executable rule controls whether a user or group can run an executable file. Executable files most often have
the .exe or .com file name extensions and apply to applications.
A script rule controls whether a user or group can run scripts with a file name extension of .ps1, .bat, .cmd, .vbs,
and .js.
A Windows Installer rule controls whether a user or group can run files with a file name extension of .msi, mst
and .msp (Windows Installer patch).
A DLL rule controls whether a user or group can run files with a file name extension of .dll and .ocx.
A packaged app and packaged app installer rule controls whether a user or group can run or install a packaged
app. A Packaged app installer has the .appx extension.
There are three different types of conditions that can be applied to rules:
A publisher condition on a rule controls whether a user or group can run files from a specific software
publisher. The file must be signed.
A path condition on a rule controls whether a user or group can run files from within a specific directory or its
subdirectories.
A file hash condition on a rule controls whether a user or group can run files with matching encrypted
hashes.
An AppLocker rule collection is a set of rules that apply to one of the following types: executable files,
Windows Installer files, scripts, DLLs, and packaged apps.
Rule conditions are criteria that the AppLocker rule is based on. Primary conditions are required to create an
AppLocker rule. The three primary rule conditions are publisher, path, and file hash.
Understanding the publisher rule condition in AppLocker
Understanding the file hash rule condition in AppLocker
AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the
files that are required for Windows to operate properly are allowed in an AppLocker rule collection.
Packaged apps and packaged app installer rules in AppLocker
You can apply AppLocker rules to individual users or a group of users. If you apply a rule to a group of
users, all users in that group are affected by that rule. If you need to allow only a subset of a user group to
use an application, you can create a special rule for that subset.
Understanding AppLocker rule behavior and Understanding AppLocker allow and deny actions on Rules
Each AppLocker rule collection functions as an allowed list of files.
Understanding AppLocker policies
An AppLocker policy is a set of rule collections and their corresponding configured enforcement settings that have
been applied to one or more computers.
Rule enforcement is applied only to collections of rules, not individual rules. AppLocker divides the rules into
four collections: executable files, Windows Installer files, scripts, and DLL files. The options for rule
enforcement are Not configured, Enforce rules, or Audit only. Together, all AppLocker rule collections
compose the application control policy, or AppLocker policy. By default, if enforcement is not configured and
rules are present in a rule collection, those rules are enforced.
Understanding AppLocker and Group Policy
Group Policy can be used to create, modify, and distribute AppLocker policies in separate objects or in combination
with other policies.
Understand AppLocker rules and enforcement setting inheritance in Group Policy
When Group Policy is used to distribute AppLocker policies, rule collections that are not configured will be
enforced. Group Policy does not overwrite or replace rules that are already present in a linked Group Policy
Object (GPO) and applies the AppLocker rules in addition to existing rules. AppLocker processes the explicit
deny rule configuration before the allow rule configuration, and for rule enforcement, the last write to the
GPO is applied.
Related topics
AppLocker functions
Applies to
Windows 10
This topic for the IT professional lists the functions and security levels for the Software Restriction Policies (SRP)
and AppLocker features.
Functions
The following list includes the SRP functions beginning with Windows Server 2003 and AppLocker functions
beginning with Windows Server 2008 R2 and links to current documentation on MSDN:
SaferGetPolicyInformation Function
SaferCreateLevel Function
SaferCloseLevel Function
SaferIdentifyLevel Function
SaferComputeTokenFromLevel Function
SaferGetLevelInformation Function
SaferRecordEventLogEntry Function
SaferiIsExecutableFileType Function
Security level ID
AppLocker and SRP use the security level IDs to stipulate the access requirements to files listed in policies. The
following table shows those security levels supported in SRP and AppLocker.
SECURITY LEVEL ID SRP APPLOCKER
SAFER_LEVELID_FULLYTRUSTED Supported Supported
SAFER_LEVELID_NORMALUSER Supported Not supported
SAFER_LEVELID_CONSTRAINED Supported Not supported
SAFER_LEVELID_UNTRUSTED Supported Not supported
SAFER_LEVELID_DISALLOWED Supported Supported
In addition, URL zone ID is not supported in AppLocker.
Related topics
Security considerations for AppLocker
Applies to
Windows 10
This topic for the IT professional describes the security considerations you need to address when implementing
AppLocker.
The purpose of AppLocker is to restrict the access to software, and therefore, the data accessed by the software, to
a specific group of users or within a defined business group. The following are security considerations for
AppLocker:
AppLocker is deployed within an enterprise and administered centrally by those in IT with trusted credentials. This
makes its policy creation and deployment conform to similar policy deployment processes and security
restrictions.
AppLocker policies are distributed through known processes and by known means within the domain through
Group Policy. But AppLocker policies can also be set on individual computers if the person has administrator
privileges, and those policies might be contrary to the organization's written security policy. The enforcement
settings for local policies are overridden by the same AppLocker policies in a Group Policy Object (GPO). However,
because AppLocker rules are additive, a local policy that is not in a GPO will still be evaluated for that computer.
Microsoft does not provide a way to develop any extensions to AppLocker. The interfaces are not public. A user
with administrator credentials can automate some AppLocker processes by using Windows PowerShell cmdlets.
For info about the Windows PowerShell cmdlets for AppLocker, see the AppLocker Cmdlets in Windows
PowerShell.
AppLocker runs in the context of Administrator or LocalSystem, which is the highest privilege set. This security
context has the potential of misuse. If a user with administrative credentials makes changes to an AppLocker policy
on a local device that is joined to a domain, those changes could be overwritten or disallowed by the GPO that
contains the AppLocker rule for the same file (or path) that was changed on the local device. However, because
AppLocker rules are additive, a local policy that is not in a GPO will still be evaluated for that computer. If the local
computer is not joined to a domain and is not administered by Group Policy, a person with administrative
credentials can alter the AppLocker policy.
When securing files in a directory with a rule of the path condition type, whether using the allow or deny action on
the rule, it is still necessary and good practice to restrict access to those files by setting the access control lists
(ACLs) according to your security policy.
AppLocker does not protect against running 16-bit DOS binaries in the Virtual DOS Machine (NTVDM). This
technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or
later when there is already another operating system running and controlling the hardware. The result is that 16-
bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise
block binaries and libraries. If it is a requirement to prevent 16-bit applications from running, you must configure
the Deny rule in the executable rule collection for NTVDM.exe.
You cannot use AppLocker (or Software Restriction Policies) to prevent code from running outside the Win32
subsystem. In particular, this applies to the (POSIX) subsystem in Windows NT. If it is a requirement to prevent
applications from running in the POSIX subsystem, you must disable the subsystem.
AppLocker can only control VBScript, JScript, .bat files, .cmd files, and Windows PowerShell scripts. It does not
control all interpreted code that runs within a host process, for example, Perl scripts and macros. Interpreted code
is a form of executable code that runs within a host process. For example, Windows batch files (*.bat) run within
the context of the Windows Command Host (cmd.exe). To control interpreted code by using AppLocker, the host
process must call AppLocker before it runs the interpreted code, and then enforce the decision returned by
AppLocker. Not all host processes call into AppLocker and, therefore, AppLocker cannot control every kind of
interpreted code, such as Microsoft Office macros.
Important: You should configure the appropriate security settings of these host processes if you must allow
them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and
trusted macros are loaded.
AppLocker rules either allow or prevent an application from launching. AppLocker does not control the behavior of
applications after they are launched. Applications could contain flags passed to functions that signal AppLocker to
circumvent the rules and allow another .exe or .dll to be loaded. In practice, an application that is allowed by
AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must thoroughly
examine each application before allowing them to run by using AppLocker rules.
Note: Two flags that illustrate this condition are SANDBOX_INERT , which can be passed to
CreateRestrictedToken , and LOAD_IGNORE_CODE_AUTHZ_LEVEL , which can be passed to LoadLibraryEx . Both of
these flags signal AppLocker to circumvent the rules and allow a child .exe or .dll to be loaded.
You can block the Windows Subsystem for Linux by blocking LxssManager.dll.
Related topics
Tools to use with AppLocker
Applies to
Windows 10
This topic for the IT professional describes the tools available to create and administer AppLocker policies.
The following tools can help you administer the application control policies created by using AppLocker on the
local device or by using Group Policy. For info about the basic requirements for using AppLocker, see
Requirements to use AppLocker.
AppLocker Local Security Policy MMC snap-in
The AppLocker rules can be maintained by using the Local Security Policy snap-in (secpol.msc) of the
Microsoft Management Console (MMC). For procedures to create, modify, and delete AppLocker rules, see
Working with AppLocker rules.
Generate Default Rules tool
AppLocker includes default rules for each rule collection accessed through the Local Security Policy snap-in.
These rules are intended to help ensure that the files that are required for Windows to operate properly are
allowed in an AppLocker rule collection. For info about how to use this tool, see Create AppLocker default
rules. For a list of the default rules, see AppLocker default rules.
Automatically Generate AppLocker Rules wizard
By using the Local Security Policy snap-in, you can automatically generate rules for all files within a folder.
The wizard will scan the specified folder and create the condition types that you choose for each file in that
folder. For info about how to use this wizard, see Run the Automatically Generate Rules wizard.
Group Policy
You can edit an AppLocker policy by adding, changing, or removing rules by using the Group Policy
Management Console (GPMC).
If you want additional features to manage AppLocker policies, such as version control, use Group Policy
management software that allows you to create versions of Group Policy Objects (GPOs). An example of this
type of software is the Advanced Group Policy Management feature from the Microsoft Desktop
Optimization Pack.
Remote Server Administration Tools (RSAT)
You can use a device with a supported operating system that has the Remote Server Administration Tools
(RSAT) installed to create and maintain AppLocker policies.
Event Viewer
The AppLocker log contains information about applications that are affected by AppLocker rules. For info
about using Event Viewer to review the AppLocker logs, see Using Event Viewer with AppLocker, and
Monitor app usage with AppLocker.
AppLocker PowerShell cmdlets
The AppLocker Windows PowerShell cmdlets are designed to streamline the administration of AppLocker
policy. They can be used to help create, test, maintain, and troubleshoot an AppLocker policy. The cmdlets
are intended to be used in conjunction with the AppLocker user interface that is accessed through the Local
Security Policy snap-in and the GPMC. For information about the cmdlets, see the AppLocker PowerShell
Command Reference.
Related topics
Using Event Viewer with AppLocker
Applies to
Windows 10
This topic lists AppLocker events and describes how to use Event Viewer with AppLocker.
The AppLocker log contains information about applications that are affected by AppLocker rules. Each event in the
log contains detailed info about:
Which file is affected and the path of that file
Which packaged app is affected and the package identifier of the app
Whether the file or packaged app is allowed or blocked
The rule type (path, file hash, or publisher)
The rule name
The security identifier (SID) for the user or group identified in the rule
Review the entries in the Event Viewer to determine if any applications are not included in the rules that you
automatically generated. For instance, some line-of-business apps are installed to non-standard locations, such as
the root of the active drive (for example: %SystemDrive%).
For info about what to look for in the AppLocker event logs, see Monitor app usage with AppLocker.
To review the AppLocker log in Event Viewer
1. Open Event Viewer.
2. In the console tree under Application and Services Logs\Microsoft\Windows, click AppLocker.
The following table contains information about the events that you can use to determine which apps are affected by
AppLocker rules.
EVENT ID LEVEL EVENT MESSAGE DESCRIPTION
8000 Error Application Identity Policy Indicates that the policy was
conversion failed. Status * not applied correctly to the
<%1> * computer. The status
message is provided for
troubleshooting purposes.
8001 Information The AppLocker policy was Indicates that the AppLocker
applied successfully to this policy was successfully
computer. applied to the computer.
8002 Information *<File name> * was allowed Specifies that the .exe or .dll
to run. file is allowed by an
AppLocker rule.
8003 Warning *<File name> * was allowed Applied only when the
to run but would have been **Audit only ** enforcement
prevented from running if mode is enabled. Specifies
the AppLocker policy were that the .exe or .dll file would
enforced. be blocked if the **Enforce
rules ** enforcement mode
were enabled.
8004 Error *<File name> * was not Access to *<file name> * is

allowed to run. restricted by the
administrator. Applied only
when the **Enforce rules **
enforcement mode is set
either directly or indirectly
through Group Policy
inheritance. The .exe or .dll
file cannot run.
8005 Information *<File name> * was allowed Specifies that the script or
to run. .msi file is allowed by an
AppLocker rule.
8006 Warning *<File name> * was allowed Applied only when the
to run but would have been **Audit only ** enforcement
prevented from running if mode is enabled. Specifies
the AppLocker policy were that the script or .msi file
enforced. would be blocked if the
**Enforce rules **
enforcement mode were
enabled.
8007 Error *<File name> * was not Access to *<file name> * is

allowed to run. restricted by the
administrator. Applied only
when the **Enforce rules **
enforcement mode is set
either directly or indirectly
through Group Policy
inheritance. The script or .msi
file cannot run.
8008 Error AppLocker disabled on the Added in Windows Server

SKU. 2012 and Windows 8.
8020 Information Packaged app allowed. Added in Windows Server

2012 and Windows 8.
8021 Information Packaged app audited. Added in Windows Server

2012 and Windows 8.
8022 Information Packaged app disabled. Added in Windows Server

2012 and Windows 8.
8023 Information Packaged app installation Added in Windows Server

allowed. 2012 and Windows 8.
8024 Information Packaged app installation Added in Windows Server

audited. 2012 and Windows 8.
8025 Warning Packaged app installation Added in Windows Server

disabled. 2012 and Windows 8.
8027 Warning No Packaged app rule Added in Windows Server

configured. 2012 and Windows 8.
Related topics
Tools to use with AppLocker
AppLocker settings
Applies to
Windows 10
This topic for the IT professional lists the settings used by AppLocker.
The following table describes the settings and values used by AppLocker.
SETTING VALUE
Registry path Policies are stored in

HKEY_LOCAL_Machine\Software\Policies\Microsoft\Wind
ows\SrpV2
Firewall ports Not applicable
Security policies Custom created, no default
Group Policy settings Custom created, no default
Network ports Not applicable
Service accounts Not applicable
Performance counters Not applicable
Related topics
BitLocker
Applies to
Windows 10
This topic provides a high-level overview of BitLocker, including a list of system requirements, practical
applications, and deprecated features.
BitLocker Drive Encryption is a data protection feature that integrates with the operating system and addresses
the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers.
BitLocker provides the most protection when used with a Trusted Platform Module (TPM) version 1.2 or later. The
TPM is a hardware component installed in many newer computers by the computer manufacturers. It works with
BitLocker to help protect user data and to ensure that a computer has not been tampered with while the system
was offline.
On computers that do not have a TPM version 1.2 or later, you can still use BitLocker to encrypt the Windows
operating system drive. However, this implementation will require the user to insert a USB startup key to start
the computer or resume from hibernation. Starting with Windows 8, you can use an operating system volume
password to protect the operating system volume on a computer without TPM. Both options do not provide the
pre-startup system integrity verification offered by BitLocker with a TPM.
In addition to the TPM, BitLocker offers the option to lock the normal startup process until the user supplies a
personal identification number (PIN) or inserts a removable device, such as a USB flash drive, that contains a
startup key. These additional security measures provide multifactor authentication and assurance that the
computer will not start or resume from hibernation until the correct PIN or startup key is presented.
Practical applications
Data on a lost or stolen computer is vulnerable to unauthorized access, either by running a software-attack tool
against it or by transferring the computer's hard disk to a different computer. BitLocker helps mitigate
unauthorized data access by enhancing file and system protections. BitLocker also helps render data inaccessible
when BitLocker-protected computers are decommissioned or recycled.
There are two additional tools in the Remote Server Administration Tools, which you can use to manage
BitLocker.
BitLocker Recovery Password Viewer. The BitLocker Recovery Password Viewer enables you to locate
and view BitLocker Drive Encryption recovery passwords that have been backed up to Active Directory
Domain Services (AD DS). You can use this tool to help recover data that is stored on a drive that has been
encrypted by using BitLocker. The BitLocker Recovery Password Viewer tool is an extension for the Active
Directory Users and Computers Microsoft Management Console (MMC) snap-in. By using this tool, you
can examine a computer object's Properties dialog box to view the corresponding BitLocker recovery
passwords. Additionally, you can right-click a domain container and then search for a BitLocker recovery
password across all the domains in the Active Directory forest. To view recovery passwords, you must be a
domain administrator, or you must have been delegated permissions by a domain administrator.
BitLocker Drive Encryption Tools. BitLocker Drive Encryption Tools include the command-line tools,
manage-bde and repair-bde, and the BitLocker cmdlets for Windows PowerShell. Both manage-bde and
the BitLocker cmdlets can be used to perform any task that can be accomplished through the BitLocker
control panel, and they are appropriate to use for automated deployments and other scripting scenarios.
Repair-bde is provided for disaster recovery scenarios in which a BitLocker protected drive cannot be
unlocked normally or by using the recovery console.
New and changed functionality

To find out what's new in BitLocker for Windows 10, such as support for the XTS-AES encryption algorithm, see
the BitLocker section in "What's new in Windows 10, versions 1507 and 1511."
System requirements
BitLocker has the following hardware requirements:
For BitLocker to use the system integrity check provided by a Trusted Platform Module (TPM), the computer must
have TPM 1.2 or later. If your computer does not have a TPM, enabling BitLocker requires that you save a startup
key on a removable device, such as a USB flash drive.
A computer with a TPM must also have a Trusted Computing Group (TCG)-compliant BIOS or UEFI firmware. The
BIOS or UEFI firmware establishes a chain of trust for the pre-operating system startup, and it must include
support for TCG-specified Static Root of Trust Measurement. A computer without a TPM does not require TCG-
compliant firmware.
The system BIOS or UEFI firmware (for TPM and non-TPM computers) must support the USB mass storage
device class, including reading small files on a USB flash drive in the pre-operating system environment.
The hard disk must be partitioned with at least two drives:
The operating system drive (or boot drive) contains the operating system and its support files. It must be
formatted with the NTFS file system.
The system drive contains the files that are needed to load Windows after the firmware has prepared the
system hardware. BitLocker is not enabled on this drive. For BitLocker to work, the system drive must not be
encrypted, must differ from the operating system drive, and must be formatted with the FAT32 file system on
computers that use UEFI-based firmware or with the NTFS file system on computers that use BIOS firmware.
We recommend that system drive be approximately 350 MB in size. After BitLocker is turned on it should
have approximately 250 MB of free space.
When installed on a new computer, Windows will automatically create the partitions that are required for
BitLocker.
When installing the BitLocker optional component on a server you will also need to install the Enhanced Storage
feature, which is used to support hardware encrypted drives.
In this section
TOPIC DESCRIPTION
Overview of BitLocker and device encryption in Windows 10 This topic for the IT professional provides an overview of the
ways that BitLocker and device encryption can help protect
data on devices running Windows 10.
BitLocker frequently asked questions (FAQ) This topic for the IT professional answers frequently asked
questions concerning the requirements to use, upgrade,
deploy and administer, and key management policies for
BitLocker.
TOPIC DESCRIPTION
Prepare your organization for BitLocker: Planning and policies This topic for the IT professional explains how can you plan
your BitLocker deployment.
BitLocker basic deployment This topic for the IT professional explains how BitLocker
features can be used to protect your data through drive
encryption.
BitLocker: How to deploy on Windows Server 2012 and later This topic for the IT professional explains how to deploy
BitLocker and Windows Server 2012 and later.
BitLocker: How to enable Network Unlock This topic for the IT professional describes how BitLocker
Network Unlock works and how to configure it.
BitLocker: Use BitLocker Drive Encryption Tools to manage This topic for the IT professional describes how to use tools
BitLocker to manage BitLocker.
BitLocker: Use BitLocker Recovery Password Viewer This topic for the IT professional describes how to use the
BitLocker Recovery Password Viewer.
BitLocker Group Policy settings This topic for IT professionals describes the function, location,
and effect of each Group Policy setting that is used to
manage BitLocker.
BCD settings and BitLocker This topic for IT professionals describes the BCD settings that
are used by BitLocker.
BitLocker Recovery Guide This topic for IT professionals describes how to recover
BitLocker keys from AD DS.
Protect BitLocker from pre-boot attacks This detailed guide will help you understand the
circumstances under which the use of pre-boot
authentication is recommended for devices running Windows
10, Windows 8.1, Windows 8, or Windows 7; and when it can
be safely omitted from a devices configuration.
Protecting cluster shared volumes and storage area networks This topic for IT pros describes how to protect CSVs and
with BitLocker SANs with BitLocker.
If you're looking for info on how to use it with Windows 10 IoT Core, see Enabling Secure Boot and BitLocker
Device Encryption on Windows 10 IoT Core.
Overview of BitLocker and device encryption in
Windows 10
Applies to
Windows 10
This topic explains how BitLocker and device encryption can help protect data on devices running Windows 10. For
an architectural overview about how device encryption works with Secure Boot, see Secure boot and device
encryption overview. For a general overview and list of topics about BitLocker, see BitLocker.
When users travel, their organizations confidential data goes with them. Wherever confidential data is stored, it
must be protected against unauthorized access. Windows has a long history of providing at-rest data-protection
solutions that guard against nefarious attackers, beginning with the Encrypting File System in the Windows 2000
operating system. More recently, BitLocker has provided encryption for full drives and portable drives; in Windows
10, BitLocker will even protect individual files, with data loss prevention capabilities. Windows consistently
improves data protection by improving existing options and by providing new strategies.
Table 2 lists specific data-protection concerns and how they are addressed in Windows 10 and Windows 7.
Table 2. Data Protection in Windows 10 and Windows 7
WINDOWS 7 WINDOWS 10
When BitLocker is used with a PIN to protect startup, PCs Modern Windows devices are increasingly protected with
such as kiosks cannot be restarted remotely. device encryption out of the box and support SSO to
seamlessly protect the BitLocker encryption keys from cold
boot attacks.
Network Unlock allows PCs to start automatically when

connected to the internal network.
Users must contact the IT department to change their Modern Windows devices no longer require a PIN in the pre-
BitLocker PIN or password. boot environment to protect BitLocker encryption keys from
cold boot attacks.
Users who have standard privileges can change their BitLocker

PIN or password on legacy devices that require a PIN.
When BitLocker is enabled, the provisioning process can take BitLocker pre-provisioning, encrypting hard drives, and Used
several hours. Space Only encryption allow administrators to enable
BitLocker quickly on new computers.
There is no support for using BitLocker with self-encrypting BitLocker supports offloading encryption to encrypted hard
drives (SEDs). drives.
Administrators have to use separate tools to manage BitLocker supports encrypted hard drives with onboard
encrypted hard drives. encryption hardware built in, which allows administrators to
use the familiar BitLocker administrative tools to manage
them.
WINDOWS 7 WINDOWS 10
Encrypting a new flash drive can take more than 20 minutes. Used Space Only encryption in BitLocker To Go allows users to
encrypt drives in seconds.
BitLocker could require users to enter a recovery key when BitLocker requires the user to enter a recovery key only when
system configuration changes occur. disk corruption occurs or when he or she loses the PIN or
password.
Users need to enter a PIN to start the PC, and then their Modern Windows devices are increasingly protected with
password to sign in to Windows. device encryption out of the box and support SSO to help
protect the BitLocker encryption keys from cold boot attacks.
The sections that follow describe these improvements in more detail. Also see:
Additional description of improvements in BitLocker: see the BitLocker section in "What's new in Windows 10,
versions 1507 and 1511."
Introduction and requirements for BitLocker: see BitLocker.
Prepare for drive and file encryption

The best type of security measures are transparent to the user during implementation and use. Every time there is
a possible delay or difficulty because of a security feature, there is strong likelihood that users will try to bypass
security. This situation is especially true for data protection, and thats a scenario that organizations need to avoid.
Whether youre planning to encrypt entire volumes, removable devices, or individual files, Windows 10 meets your
needs by providing streamlined, usable solutions. In fact, you can take several steps in advance to prepare for data
encryption and make the deployment quick and smooth.
TPM pre -provisioning
In Windows 7, preparing the TPM for use offered a couple of challenges:
You can turn on the TPM in the BIOS, which requires someone to either go into the BIOS settings to turn it on or
to install a driver to turn it on from within Windows.
When you enable the TPM, it may require one or more restarts.
Basically, it was a big hassle. If IT staff were provisioning new PCs, they could handle all of this, but if you wanted to
add BitLocker to devices that were already in users hands, those users would have struggled with the technical
challenges and would either call IT for support or simply leave BitLocker disabled.
Microsoft includes instrumentation in Windows 10 that enables the operating system to fully manage the TPM.
There is no need to go into the BIOS, and all scenarios that required a restart have been eliminated.
Deploy hard drive encryption

BitLocker is capable of encrypting entire hard drives, including both system and data drives. BitLocker pre-
provisioning can drastically reduce the time required to provision new PCs with BitLocker enabled. With Windows
10, administrators can turn on BitLocker and the TPM from within the Windows Preinstallation Environment before
they install Windows or as part of an automated deployment task sequence without any user interaction.
Combined with Used Disk Space Only encryption and a mostly empty drive (because Windows is not yet installed),
it takes only a few seconds to enable BitLocker. With earlier versions of Windows, administrators had to enable
BitLocker after Windows had been installed. Although this process could be automated, BitLocker would need to
encrypt the entire drive, a process that could take anywhere from several hours to more than a day depending on
drive size and performance, which significantly delayed deployment. Microsoft has improved this process through
multiple features in Windows 10.
Device encryption
Beginning in Windows 8.1, Windows automatically enables BitLocker device encryption on devices that support
InstantGo. With Windows 10, Microsoft offers device encryption support on a much broader range of devices,
including those that are InstantGo. Microsoft expects that most devices in the future will pass the testing
requirements, which makes device encryption pervasive across modern Windows devices. Device encryption
further protects the system by transparently implementing device-wide data encryption.
Unlike a standard BitLocker implementation, device encryption is enabled automatically so that the device is always
protected. The following list outlines how this happens:
When a clean installation of Windows 10 is completed and the out-of-box experience is finished, the computer
is prepared for first use. As part of this preparation, device encryption is initialized on the operating system
drive and fixed data drives on the computer with a clear key (this is the equivalent of standard BitLocker
suspended state).
If the device is not domain joined, a Microsoft account that has been granted administrative privileges on the
device is required. When the administrator uses a Microsoft account to sign in, the clear key is removed, a
recovery key is uploaded to the online Microsoft account, and a TPM protector is created. Should a device
require the recovery key, the user will be guided to use an alternate device and navigate to a recovery key
access URL to retrieve the recovery key by using his or her Microsoft account credentials.
If the user uses a domain account to sign in, the clear key is not removed until the user joins the device to a
domain and the recovery key is successfully backed up to Active Directory Domain Services (AD DS). You must
enable the Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives Group Policy setting, and select the Do not enable BitLocker until
recovery information is stored in AD DS for operating system drives option. With this configuration, the
recovery password is created automatically when the computer joins the domain, and then the recovery key is
backed up to AD DS, the TPM protector is created, and the clear key is removed.
Similar to signing in with a domain account, the clear key is removed when the user logs on to an Azure AD
account on the device. As described in the bullet point above, the recovery password is created automatically
when the user authenticates to Azure AD. Then, the recovery key is backed up to Azure AD, the TPM protector is
created, and the clear key is removed.
Microsoft recommends that device encryption be enabled on any systems that support it, but the automatic device
encryption process can be prevented by changing the following registry setting:
Subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BitLocker
Value: PreventDeviceEncryption equal to True (1)
Type: REG_DWORD
Administrators can manage domain-joined devices that have device encryption enabled through Microsoft
BitLocker Administration and Monitoring (MBAM). In this case, device encryption automatically makes additional
BitLocker options available. No conversion or encryption is required, and MBAM can manage the full BitLocker
policy set if any configuration changes are required.
Used Disk Space Only encryption

BitLocker in earlier Windows versions could take a long time to encrypt a drive, because it encrypted every byte on
the volume (including parts that did not have data). That is still the most secure way to encrypt a drive, especially if
a drive has previously contained confidential data that has since been moved or deleted, in which case traces of the
confidential data could remain on portions of the drive marked as unused. But why encrypt a new drive when you
can simply encrypt the data as it is being written? To reduce encryption time, BitLocker in Windows 10 lets users
choose to encrypt just their data. Depending on the amount of data on the drive, this option can reduce encryption
time by more than 99 percent. Exercise caution when encrypting only used space on an existing volume on which
confidential data may have already been stored in an unencrypted state, however, because those sectors can be
recovered through disk-recovery tools until they are overwritten by new encrypted data. In contrast, encrypting
only used space on a brand-new volume can significantly decrease deployment time without the security risk
because all new data will be encrypted as it is written to the disk.
Encrypted hard drive support

SEDs have been available for years, but Microsoft couldnt support their use with some earlier versions of Windows
because the drives lacked important key management features. Microsoft worked with storage vendors to improve
the hardware capabilities, and now BitLocker supports the next generation of SEDs, which are called encrypted hard
drives. Encrypted hard drives provide onboard cryptographic capabilities to encrypt data on drives, which improves
both drive and system performance by offloading cryptographic calculations from the PCs processor to the drive
itself and rapidly encrypting the drive by using dedicated, purpose-built hardware. If you plan to use whole-drive
encryption with Windows 10, Microsoft recommends that you investigate hard drive manufacturers and models to
determine whether any of their encrypted hard drives meet your security and budget requirements. For more
information about encrypted hard drives, see Encrypted Hard Drive.
Preboot information protection

An effective implementation of information protection, like most security controls, considers usability as well as
security. Users typically prefer a simple security experience. In fact, the more transparent a security solution
becomes, the more likely users are to conform to it. It is crucial that organizations protect information on their PCs
regardless of the state of the computer or the intent of users. This protection should not be cumbersome to users.
One undesirable and previously commonplace situation is when the user is prompted for input during preboot,
and then again during Windows logon. Challenging users for input more than once should be avoided. Windows
10 can enable a true SSO experience from the preboot environment on modern devices and in some cases even on
older devices when robust information protection configurations are in place. The TPM in isolation is able to
securely protect the BitLocker encryption key while it is at rest, and it can securely unlock the operating system
drive. When the key is in use and thus in memory, a combination of hardware and Windows capabilities can secure
the key and prevent unauthorized access through cold-boot attacks. Although other countermeasures like PIN-
based unlock are available, they are not as user-friendly; depending on the devices configuration they may not
offer additional security when it comes to key protection. For more information, see BitLocker Countermeasures
and Choose the right BitLocker countermeasure.
Manage passwords and PINs

When BitLocker is enabled on a system drive and the PC has a TPM, you can choose to require that users type a
PIN before BitLocker will unlock the drive. Such a PIN requirement can prevent an attacker who has physical access
to a PC from even getting to the Windows logon, which makes it virtually impossible for the attacker to access or
modify user data and system files.
Requiring a PIN at startup is a useful security feature because it acts as a second authentication factor (a second
something you know). This configuration comes with some costs, however. One of the most significant is the
need to change the PIN regularly. In enterprises that used BitLocker with Windows 7 and the Windows Vista
operating system, users had to contact systems administrators to update their BitLocker PIN or password. This
requirement not only increased management costs but made users less willing to change their BitLocker PIN or
password on a regular basis. Windows 10 users can update their BitLocker PINs and passwords themselves,
without administrator credentials. Not only will this feature reduce support costs, but it could improve security, too,
because it encourages users to change their PINs and passwords more often. In addition, InstantGo devices do not
require a PIN for startup: They are designed to start infrequently and have other mitigations in place that further
reduce the attack surface of the system. For more information about how startup security works and the
countermeasures that Windows 10 provides, see Protect BitLocker from pre-boot attacks.
Configure Network Unlock

Some organizations have location-specific data security requirements. This is most common in environments
where high-value data is stored on PCs. The network environment may provide crucial data protection and enforce
mandatory authentication; therefore, policy states that those PCs should not leave the building or be disconnected
from the corporate network. Safeguards like physical security locks and geofencing may help enforce this policy as
reactive controls. Beyond these, a proactive security control that grants data access only when the PC is connected
to the corporate network is necessary.
Network Unlock enables BitLocker-protected PCs to start automatically when connected to a wired corporate
network on which Windows Deployment Services runs. Anytime the PC is not connected to the corporate network,
a user must type a PIN to unlock the drive (if PIN-based unlock is enabled). Network Unlock requires the following
infrastructure:
Client PCs that have Unified Extensible Firmware Interface (UEFI) firmware version 2.3.1 or later, which supports
Dynamic Host Configuration Protocol (DHCP)
A server running at least Windows Server 2012 with the Windows Deployment Services role
A server with the DHCP server role installed
For more information about how to configure Network Unlock, see BitLocker: How to enable Network Unlock.
Microsoft BitLocker Administration and Monitoring

Part of the Microsoft Desktop Optimization Pack, MBAM makes it easier to manage and support BitLocker and
BitLocker To Go. MBAM 2.5 with Service Pack 1, the latest version, has the following key features:
Enables administrators to automate the process of encrypting volumes on client computers across the
enterprise.
Enables security officers to quickly determine the compliance state of individual computers or even of the
enterprise itself.
Provides centralized reporting and hardware management with Microsoft System Center Configuration
Manager.
Reduces the workload on the help desk to assist end users with BitLocker recovery requests.
Enables end users to recover encrypted devices independently by using the Self-Service Portal.
Enables security officers to easily audit access to recovery key information.
Empowers Windows Enterprise users to continue working anywhere with the assurance that their corporate
data is protected.
Enforces the BitLocker encryption policy options that you set for your enterprise.
Integrates with existing management tools, such as System Center Configuration Manager.
Offers an IT-customizable recovery user experience.
Supports Windows 10.
For more information about MBAM, including how to obtain it, see Microsoft BitLocker Administration and
Monitoring on the MDOP TechCenter.
Applies to
Windows 10
This topic for the IT professional answers frequently asked questions concerning the requirements to use,
upgrade, deploy and administer, and key management policies for BitLocker.
BitLocker is a data protection feature that encrypts the hard drives on your computer to provide enhanced
protection against data theft or exposure on computers and removable drives that are lost or stolen, and more
secure data deletion when BitLocker-protected computers are decommissioned as it is much more difficult to
recover deleted data from an encrypted drive than from a non-encrypted drive.
Overview and requirements
Upgrading
Deployment and administration
Key management
BitLocker To Go
Active Directory Domain Services (AD DS)
Security
BitLocker Network Unlock
Other questions
Overview and requirements

How does BitLocker work?
How BitLocker works with operating system drives
You can use BitLocker to mitigate unauthorized data access on lost or stolen computers by encrypting all user files
and system files on the operating system drive, including the swap files and hibernation files, and checking the
integrity of early boot components and boot configuration data.
How BitLocker works with fixed and removable data drives
You can use BitLocker to encrypt the entire contents of a data drive. You can use Group Policy to require that
BitLocker be enabled on a drive before the computer can write data to the drive. BitLocker can be configured with
a variety of unlock methods for data drives, and a data drive supports multiple unlock methods.
Does BitLocker support multifactor authentication?
Yes, BitLocker supports multifactor authentication for operating system drives. If you enable BitLocker on a
computer that has a TPM version 1.2 or later, you can use additional forms of authentication with the TPM
protection.
What are the BitLocker hardware and software requirements?
For requirements, see System requirements.
Note: Dynamic disks are not supported by BitLocker. Dynamic data volumes will not be displayed in the
Control Panel. Although the operating system volume will always be displayed in the Control Panel, regardless
of whether it is a Dynamic disk, if it is a dynamic disk it is cannot be protected by BitLocker.
Why are two partitions required? Why does the system drive have to be so large?
Two partitions are required to run BitLocker because pre-startup authentication and system integrity verification
must occur on a separate partition from the encrypted operating system drive. This configuration helps protect the
operating system and the information in the encrypted drive.
Which Trusted Platform Modules (TPMs) does BitLocker support?
BitLocker supports TPM version 1.2 or higher.
How can I tell if a TPM is on my computer?
Open the TPM MMC console (tpm.msc) and look under the Status heading.
Can I use BitLocker on an operating system drive without a TPM?
Yes, you can enable BitLocker on an operating system drive without a TPM version 1.2 or higher, if the BIOS or
UEFI firmware has the ability to read from a USB flash drive in the boot environment. This is because BitLocker will
not unlock the protected drive until BitLocker's own volume master key is first released by either the computer's
TPM or by a USB flash drive containing the BitLocker startup key for that computer. However, computers without
TPMs will not be able to use the system integrity verification that BitLocker can also provide. To help determine
whether a computer can read from a USB device during the boot process, use the BitLocker system check as part
of the BitLocker setup process. This system check performs tests to confirm that the computer can properly read
from the USB devices at the appropriate time and that the computer meets other BitLocker requirements.
How do I obtain BIOS support for the TPM on my computer?
Contact the computer manufacturer to request a Trusted Computing Group (TCG)-compliant BIOS or UEFI boot
firmware that meets the following requirements:
It is compliant with the TCG standards for a client computer.
It has a secure update mechanism to help prevent a malicious BIOS or boot firmware from being installed on
the computer.
What credentials are required to use BitLocker?
To turn on, turn off, or change configurations of BitLocker on operating system and fixed data drives, membership
in the local Administrators group is required. Standard users can turn on, turn off, or change configurations of
BitLocker on removable data drives.
What is the recommended boot order for computers that are going to be BitLocker-protected?
You should configure the startup options of your computer to have the hard disk drive first in the boot order,
before any other drives such ach as CD/DVD drives or USB drives. If the hard disk is not first and you typically
boot from hard disk, then a boot order change may be detected or assumed when removable media is found
during boot. The boot order typically affects the system measurement that is verified by BitLocker and a change in
boot order will cause you to be prompted for your BitLocker recovery key. For the same reason, if you have a
laptop with a docking station, ensure that the hard disk drive is first in the boot order both when docked and
undocked.
Upgrading
Can I upgrade to Windows 10 with BitLocker enabled?
Yes.
What is the difference between suspending and decrypting BitLocker?
Decrypt completely removes BitLocker protection and fully decrypts the drive.
Suspend keeps the data encrypted but encrypts the BitLocker volume master key with a clear key. The clear key is
a cryptographic key stored unencrypted and unprotected on the disk drive. By storing this key unencrypted, the
Suspend option allows for changes or upgrades to the computer without the time and cost of decrypting and re-
encrypting the entire drive. After the changes are made and BitLocker is again enabled, BitLocker will reseal the
encryption key to the new values of the measured components that changed as a part of the upgrade, the volume
master key is changed, the protectors are updated to match and the clear key is erased.
Do I have to decrypt my BitLocker-protected drive to download and install system updates and upgrades?
No user action is required for BitLocker in order to apply updates from Microsoft, including Windows quality
updates and feature updates. Users need to suspend BitLocker for Non-Microsoft software updates, such as:
Computer manufacturer firmware updates
TPM firmware updates
Non-Microsoft application updates that modify boot components
Note: If you have suspended BitLocker, you can resume BitLocker protection after you have installed the
upgrade or update. Upon resuming protection, BitLocker will reseal the encryption key to the new values of
the measured components that changed as a part of the upgrade or update. If these types of upgrades or
updates are applied without suspending BitLocker, your computer will enter recovery mode when restarting
and will require a recovery key or password to access the computer.
Deployment and administration

Can BitLocker deployment be automated in an enterprise environment?
Yes, you can automate the deployment and configuration of BitLocker and the TPM using either WMI or Windows
PowerShell scripts. How you choose to implement the scripts depends on your environment. You can also use
Manage-bde.exe to locally or remotely configure BitLocker. For more info about writing scripts that use the
BitLocker WMI providers, see BitLocker Drive Encryption Provider. For more info about using Windows
PowerShell cmdlets with BitLocker Drive Encryption, see BitLocker Cmdlets in Windows PowerShell.
Can BitLocker encrypt more than just the operating system drive?
Yes.
Is there a noticeable performance impact when BitLocker is enabled on a computer?
Generally it imposes a single-digit percentage performance overhead.
How long will initial encryption take when BitLocker is turned on?
Although BitLocker encryption occurs in the background while you continue to work, and the system remains
usable, encryption times vary depending on the type of drive that is being encrypted, the size of the drive, and the
speed of the drive. If you are encrypting very large drives, you may want to set encryption to occur during times
when you will not be using the drive.
You can also choose whether or not BitLocker should encrypt the entire drive or just the used space on the drive
when you turn on BitLocker. On a new hard drive, encrypting just the used spaced can be considerably faster than
encrypting the entire drive. When this encryption option is selected, BitLocker automatically encrypts data as it is
saved, ensuring that no data is stored unencrypted.
What happens if the computer is turned off during encryption or decryption?
If the computer is turned off or goes into hibernation, the BitLocker encryption and decryption process will resume
where it stopped the next time Windows starts. This is true even if the power is suddenly unavailable.
Does BitLocker encrypt and decrypt the entire drive all at once when reading and writing data?
No, BitLocker does not encrypt and decrypt the entire drive when reading and writing data. The encrypted sectors
in the BitLocker-protected drive are decrypted only as they are requested from system read operations. Blocks that
are written to the drive are encrypted before the system writes them to the physical disk. No unencrypted data is
ever stored on a BitLocker-protected drive.
How can I prevent users on a network from storing data on an unencrypted drive?
You can can Group Policy settings to require that data drives be BitLocker-protected before a BitLocker-protected
computer can write data to them. For more info, see BitLocker Group Policy settings. When these policy settings
are enabled, the BitLocker-protected operating system will mount any data drives that are not protected by
BitLocker as read-only.
What system changes would cause the integrity check on my operating system drive to fail?
The following types of system changes can cause an integrity check failure and prevent the TPM from releasing
the BitLocker key to decrypt the protected operating system drive:
Moving the BitLocker-protected drive into a new computer.
Installing a new motherboard with a new TPM.
Turning off, disabling, or clearing the TPM.
Changing any boot configuration settings.
Changing the BIOS, UEFI firmware, master boot record, boot sector, boot manager, option ROM, or other early
boot components or boot configuration data.
What causes BitLocker to start into recovery mode when attempting to start the operating system drive?
Because BitLocker is designed to protect your computer from numerous attacks, there are numerous reasons why
BitLocker could start in recovery mode. In BitLocker, recovery consists of decrypting a copy of the volume master
key using either a recovery key stored on a USB flash drive or a cryptographic key derived from a recovery
password. The TPM is not involved in any recovery scenarios, so recovery is still possible if the TPM fails boot
component validation, malfunctions, or is removed.
Can I swap hard disks on the same computer if BitLocker is enabled on the operating system drive?
Yes, you can swap multiple hard disks on the same computer if BitLocker is enabled, but only if the hard disks
were BitLocker-protected on the same computer. The BitLocker keys are unique to the TPM and operating system
drive, so if you want to prepare a backup operating system or data drive for use in case of disk failure, you need to
make sure that they were matched with the correct TPM. You can also configure different hard drives for different
operating systems and then enable BitLocker on each one with different authentication methods (such as one with
TPM-only and one with TPM+PIN) without any conflicts.
Can I access my BitLocker-protected drive if I insert the hard disk into a different computer?
Yes, if the drive is a data drive, you can unlock it from the BitLocker Drive Encryption Control Panel item just as
you would any other data drive by using a password or smart card. If the data drive was configured for automatic
unlock only, you will have to unlock it by using the recovery key. The encrypted hard disk can be unlocked by a
data recovery agent (if one was configured) or it can be unlocked by using the recovery key.
Why is "Turn BitLocker on" not available when I right-click a drive?
Some drives cannot be encrypted with BitLocker. Reasons a drive cannot be encrypted include insufficient disk
size, an incompatible file system, if the drive is a dynamic disk, or a drive is designated as the system partition. By
default, the system drive (or system partition) is hidden from display. However, if it is not created as a hidden drive
when the operating system was installed due to a custom installation process, that drive might be displayed but
cannot be encrypted.
What type of disk configurations are supported by BitLocker?
Any number of internal, fixed data drives can be protected with BitLocker. On some versions ATA and SATA-based,
direct-attached storage devices are also supported.
Key management
What is the difference between a recovery password, recovery key, PIN, enhanced PIN, and startup key?
For tables that list and describe elements such as a recovery password, recovery key, and PIN, see BitLocker key
protectors and BitLocker authentication methods.
How can the recovery password and recovery key be stored?
The recovery password and recovery key for an operating system drive or a fixed data drive can be saved to a
folder, saved to one or more USB devices, saved to your Microsoft Account, or printed.
For removable data drives, the recovery password and recovery key can be saved to a folder, saved to your
Microsoft Account, or printed. By default, you cannot store a recovery key for a removable drive on a removable
drive.
A domain administrator can additionally configure Group Policy to automatically generate recovery passwords
and store them in Active Directory Domain Services (AD DS) for any BitLocker-protected drive.
Is it possible to add an additional method of authentication without decrypting the drive if I only have the TPM
authentication method enabled?
You can use the Manage-bde.exe command-line tool to replace your TPM-only authentication mode with a
multifactor authentication mode. For example, if BitLocker is enabled with TPM authentication only and you want
to add PIN authentication, use the following commands from an elevated command prompt, replacing <4-20 digit
numeric PIN> with the numeric PIN you want to use:
manage-bde protectors delete %systemdrive% -type tpm
manage-bde protectors add %systemdrive% -tpmandpin <4-20 digit numeric PIN>
When should an additional method of authentication be considered?

New hardware that meets Windows Hardware Compatibility Program requirements make a PIN less critical as a
mitigation, and having a TPM-only protector is likely sufficient when combined with policies like device lockout.
For example, Surface Pro and Surface Book do not have external DMA ports to attack. For older hardware, where a
PIN may be needed, its recommended to enable enhanced PINs that allow non-numeric characters such as letters
and punctuation marks, and to set the PIN length based on your risk tolerance and the hardware anti-hammering
capabilities available to the TPMs in your computers.
If I lose my recovery information, will the BitLocker-protected data be unrecoverable?
BitLocker is designed to make the encrypted drive unrecoverable without the required authentication. When in
recovery mode, the user needs the recovery password or recovery key to unlock the encrypted drive.
Important: Store the recovery information in AD DS, along with your Microsoft Account, or another safe
location.
Can the USB flash drive that is used as the startup key also be used to store the recovery key?
While this is technically possible, it is not a best practice to use one USB flash drive to store both keys. If the USB
flash drive that contains your startup key is lost or stolen, you also lose access to your recovery key. In addition,
inserting this key would cause your computer to automatically boot from the recovery key even if TPM-measured
files have changed, which circumvents the TPM's system integrity check.
Can I save the startup key on multiple USB flash drives?
Yes, you can save a computer's startup key on multiple USB flash drives. Right-clicking a BitLocker-protected drive
and selecting Manage BitLocker will provide you the options to duplicate the recovery keys as needed.
Can I save multiple (different) startup keys on the same USB flash drive?
Yes, you can save BitLocker startup keys for different computers on the same USB flash drive.
Can I generate multiple (different) startup keys for the same computer?
You can generate different startup keys for the same computer through scripting. However, for computers that
have a TPM, creating different startup keys prevents BitLocker from using the TPM's system integrity check.
Can I generate multiple PIN combinations?
You cannot generate multiple PIN combinations.
What encryption keys are used in BitLocker? How do they work together?
Raw data is encrypted with the full volume encryption key, which is then encrypted with the volume master key.
The volume master key is in turn encrypted by one of several possible methods depending on your authentication
(that is, key protectors or TPM) and recovery scenarios.
Where are the encryption keys stored?
The full volume encryption key is encrypted by the volume master key and stored in the encrypted drive. The
volume master key is encrypted by the appropriate key protector and stored in the encrypted drive. If BitLocker
has been suspended, the clear key that is used to encrypt the volume master key is also stored in the encrypted
drive, along with the encrypted volume master key.
This storage process ensures that the volume master key is never stored unencrypted and is protected unless you
disable BitLocker. The keys are also saved to two additional locations on the drive for redundancy. The keys can be
read and processed by the boot manager.
Why do I have to use the function keys to enter the PIN or the 48-character recovery password?
The F1 through F10 keys are universally mapped scan codes available in the pre-boot environment on all
computers and in all languages. The numeric keys 0 through 9 are not usable in the pre-boot environment on all
keyboards.
When using an enhanced PIN, users should run the optional system check during the BitLocker setup process to
ensure that the PIN can be entered correctly in the pre-boot environment.
How does BitLocker help prevent an attacker from discovering the PIN that unlocks my operating system
drive?
It is possible that a personal identification number (PIN) can be discovered by an attacker performing a brute force
attack. A brute force attack occurs when an attacker uses an automated tool to try different PIN combinations until
the correct one is discovered. For BitLocker-protected computers, this type of attack, also known as a dictionary
attack, requires that the attacker have physical access to the computer.
The TPM has the built-in ability to detect and react to these types of attacks. Because different manufacturers'
TPMs may support different PIN and attack mitigations, contact your TPM's manufacturer to determine how your
computer's TPM mitigates PIN brute force attacks. After you have determined your TPM's manufacturer, contact
the manufacturer to gather the TPM's vendor-specific information. Most manufacturers use the PIN authentication
failure count to exponentially increase lockout time to the PIN interface. However, each manufacturer has different
policies regarding when and how the failure counter is decreased or reset.
How can I determine the manufacturer of my TPM?
You can determine your TPM manufacturer in the TPM MMC console (tpm.msc) under the TPM Manufacturer
Information heading.
How can I evaluate a TPM's dictionary attack mitigation mechanism?
The following questions can assist you when asking a TPM manufacturer about the design of a dictionary attack
mitigation mechanism:
How many failed authorization attempts can occur before lockout?
What is the algorithm for determining the duration of a lockout based on the number of failed attempts and
any other relevant parameters?
What actions can cause the failure count and lockout duration to be decreased or reset?
Can PIN length and complexity be managed with Group Policy?
Yes and No. You can configure the minimum personal identification number (PIN) length by using the Configure
minimum PIN length for startup Group Policy setting and allow the use of alphanumeric PINs by enabling the
Allow enhanced PINs for startup Group Policy setting. However, you cannot require PIN complexity by Group
Policy.
For more info, see BitLocker Group Policy settings.
BitLocker To Go
BitLocker To Go is BitLocker Drive Encryption on removable data drives. This includes the encryption of USB flash
drives, SD cards, external hard disk drives, and other drives formatted by using the NTFS, FAT16, FAT32, or exFAT
file systems.

What if BitLocker is enabled on a computer before the computer has joined the domain?
If BitLocker is enabled on a drive before Group Policy has been applied to enforce backup, the recovery
information will not be automatically backed up to AD DS when the computer joins the domain or when Group
Policy is subsequently applied. However, you can use the Choose how BitLocker-protected operating system
drives can be recovered, Choose how BitLocker-protected fixed drives can be recovered and Choose how
BitLocker-protected removable drives can be recovered Group Policy settings to require that the computer
be connected to a domain before BitLocker can be enabled to help ensure that recovery information for BitLocker-
protected drives in your organization is backed up to AD DS.
The BitLocker Windows Management Instrumentation (WMI) interface does allow administrators to write a script
to back up or synchronize an online client's existing recovery information; however, BitLocker does not
automatically manage this process. The manage-bde command-line tool can also be used to manually back up
recovery information to AD DS. For example, to back up all of the recovery information for the C: drive to AD DS,
you would use the following command from an elevated command prompt: manage-bde -protectors -
adbackup C:.
Important: Joining a computer to the domain should be the first step for new computers within an
organization. After computers are joined to a domain, storing the BitLocker recovery key to AD DS is
automatic (when enabled in Group Policy).
Is there an event log entry recorded on the client computer to indicate the success or failure of the Active
Directory backup?
Yes, an event log entry that indicates the success or failure of an Active Directory backup is recorded on the client
computer. However, even if an event log entry says "Success," the information could have been subsequently
removed from AD DS, or BitLocker could have been reconfigured in such a way that the Active Directory
information can no longer unlock the drive (such as by removing the recovery password key protector). In
addition, it is also possible that the log entry could be spoofed.
Ultimately, determining whether a legitimate backup exists in AD DS requires querying AD DS with domain
administrator credentials by using the BitLocker password viewer tool.
If I change the BitLocker recovery password on my computer and store the new password in AD DS, will AD
DS overwrite the old password?
No. By design, BitLocker recovery password entries do not get deleted from AD DS; therefore, you might see
multiple passwords for each drive. To identify the latest password, check the date on the object.
What happens if the backup initially fails? Will BitLocker retry the backup?
If the backup initially fails, such as when a domain controller is unreachable at the time when the BitLocker setup
wizard is run, BitLocker does not try again to back up the recovery information to AD DS.
When an administrator selects the Require BitLocker backup to AD DS check box of the Store BitLocker
recovery information in Active Directory Domain Service (Windows 2008 and Windows Vista) policy
setting, or the equivalent Do not enable BitLocker until recovery information is stored in AD DS for
(operating system | fixed data | removable data) drives check box in any of the Choose how BitLocker-
protected operating system drives can be recovered, Choose how BitLocker-protected fixed data drives
can be recovered, Choose how BitLocker-protected removable data drives can be recovered policy
settings, this prevents users from enabling BitLocker unless the computer is connected to the domain and the
backup of BitLocker recovery information to AD DS succeeds. With these settings configured if the backup fails,
BitLocker cannot be enabled, ensuring that administrators will be able to recover BitLocker-protected drives in the
organization.
When an administrator clears these check boxes, the administrator is allowing a drive to be BitLocker-protected
without having the recovery information successfully backed up to AD DS; however, BitLocker will not
automatically retry the backup if it fails. Instead, administrators can create a script for the backup, as described
earlier in What if BitLocker is enabled on a computer before the computer has joined the domain? to capture the
information after connectivity is restored.
Security
What form of encryption does BitLocker use? Is it configurable?
BitLocker uses Advanced Encryption Standard (AES) as its encryption algorithm with configurable key lengths of
128 or 256 bits. The default encryption setting is AES-128, but the options are configurable by using Group Policy.
What is the best practice for using BitLocker on an operating system drive?
The recommended practice for BitLocker configuration on an operating system drive is to implement BitLocker on
a computer with a TPM version 1.2 or higher and a Trusted Computing Group (TCG)-compliant BIOS or UEFI
firmware implementation, plus a PIN. By requiring a PIN that was set by the user in addition to the TPM validation,
a malicious user that has physical access to the computer cannot simply start the computer.
What are the implications of using the sleep or hibernate power management options?
BitLocker on operating system drives in its basic configuration (with a TPM but without advanced authentication)
provides additional security for the hibernate mode. However, BitLocker provides greater security when it is
configured to use an advanced authentication mode (TPM+PIN, TPM+USB, or TPM+PIN+USB) with the hibernate
mode. This method is more secure because returning from hibernation requires BitLocker authentication. As a
best practice, we recommend that sleep mode be disabled and that you use TPM+PIN for the authentication
method.
What are the advantages of a TPM?
Most operating systems use a shared memory space and rely on the operating system to manage physical
memory. A TPM is a hardware component that uses its own internal firmware and logic circuits for processing
instructions, thus shielding it from external software vulnerabilities. Attacking the TPM requires physical access to
the computer. Additionally, the tools and skills necessary to attack hardware are often more expensive, and usually
are not as available as the ones used to attack software. And because each TPM is unique to the computer that
contains it, attacking multiple TPM computers would be difficult and time-consuming.
Note: Configuring BitLocker with an additional factor of authentication provides even more protection against
TPM hardware attacks.
BitLocker Network Unlock

BitLocker Network Unlock enables easier management for BitLocker-enabled desktops and servers that use the
TPM+PIN protection method in a domain environment. When a computer that is connected to a wired corporate
network is rebooted, Network Unlock allows the PIN entry prompt to be bypassed. It automatically unlocks
BitLocker-protected operating system volumes by using a trusted key that is provided by the Windows
Deployment Services server as its secondary authentication method.
To use Network Unlock you must also have a PIN configured for your computer. When your computer is not
connected to the network you will need to provide the PIN to unlock it.
BitLocker Network Unlock has software and hardware requirements for both client computers, Windows
Deployment services, and domain controllers that must be met before you can use it.
Network Unlock uses two protectors, the TPM protector and the one provided by the network or by your PIN,
whereas automatic unlock uses a single protector, the one stored in the TPM. If the computer is joined to a
network without the key protector it will prompt you to enter your PIN. If the PIN is not available you will need to
use the recovery key to unlock the computer if it can ot be connected to the network.
For more info, see BitLocker: How to enable Network Unlock.
Other questions
Can I run a kernel debugger with BitLocker?
Yes. However, the debugger should be turned on before enabling BitLocker. Turning on the debugger ensures that
the correct measurements are calculated when sealing to the TPM, allowing the computer to start properly. If you
need to turn debugging on or off when using BitLocker, be sure to suspend BitLocker first to avoid putting your
computer into recovery mode.
How does BitLocker handle memory dumps?
BitLocker has a storage driver stack that ensures memory dumps are encrypted when BitLocker is enabled.
Can BitLocker support smart cards for pre -boot authentication?
BitLocker does not support smart cards for pre-boot authentication. There is no single industry standard for smart
card support in the firmware, and most computers either do not implement firmware support for smart cards, or
only support specific smart cards and readers. This lack of standardization makes supporting them very difficult.
Can I use a non-Microsoft TPM driver?
Microsoft does not support non-Microsoft TPM drivers and strongly recommends against using them with
BitLocker. Attempting to use a non-Microsoft TPM driver with BitLocker may cause BitLocker to report that a TPM
is not present on the computer and not allow the TPM to be used with BitLocker.
Can other tools that manage or modify the master boot record work with BitLocker?
We do not recommend modifying the master boot record on computers whose operating system drives are
BitLocker-protected for a number of security, reliability, and product support reasons. Changes to the master boot
record (MBR) could change the security environment and prevent the computer from starting normally, as well as
complicate any efforts to recover from a corrupted MBR. Changes made to the MBR by anything other than
Windows might force the computer into recovery mode or prevent it from booting entirely.
Why is the system check failing when I am encrypting my operating system drive?
The system check is designed to ensure your computer's BIOS or UEFI firmware is compatible with BitLocker and
that the TPM is working correctly. The system check can fail for several reasons:
The computer's BIOS or UEFI firmware cannot read USB flash drives.
The computer's BIOS, uEFI firmware, or boot menu does not have reading USB flash drives enabled.
There are multiple USB flash drives inserted into the computer.
The PIN was not entered correctly.
The computer's BIOS or UEFI firmware only supports using the function keys (F1F10) to enter numerals in the
pre-boot environment.
The startup key was removed before the computer finished rebooting.
The TPM has malfunctioned and fails to unseal the keys.
What can I do if the recovery key on my USB flash drive cannot be read?
Some computers cannot read USB flash drives in the pre-boot environment. First, check your BIOS or UEFI
firmware and boot settings to ensure that the use of USB drives is enabled. If it is not enabled, enable the use of
USB drives in the BIOS or UEFI firmware and boot settings and then try to read the recovery key from the USB
flash drive again. If it still cannot be read, you will have to mount the hard drive as a data drive on another
computer so that there is an operating system to attempt to read the recovery key from the USB flash drive. If the
USB flash drive has been corrupted or damaged, you may need to supply a recovery password or use the recovery
information that was backed up to AD DS. Also, if you are using the recovery key in the pre-boot environment,
ensure that the drive is formatted by using the NTFS, FAT16, or FAT32 file system.
Why am I unable to save my recovery key to my USB flash drive?
The Save to USB option is not shown by default for removable drives. If the option is unavailable, it means that a
system administrator has disallowed the use of recovery keys.
Why am I unable to automatically unlock my drive?
Automatic unlocking for fixed data drives requires that the operating system drive also be protected by BitLocker.
If you are using a computer that does not have a BitLocker-protected operating system drive, the drive cannot be
automatically unlocked. For removable data drives, you can add automatic unlocking by right-clicking the drive in
Windows Explorer and clicking Manage BitLocker. You will still be able to use the password or smart card
credentials you supplied when you turned on BitLocker to unlock the removable drive on other computers.
Can I use BitLocker in Safe Mode?
Limited BitLocker functionality is available in Safe Mode. BitLocker-protected drives can be unlocked and
decrypted by using the BitLocker Drive Encryption Control Panel item. Right-clicking to access BitLocker
options from Windows Explorer is not available in Safe Mode.
How do I "lock" a data drive?
Both fixed and removable data drives can be locked by using the Manage-bde command-line tool and the lock
command.
Note: Ensure all data is saved to the drive before locking it. Once locked, the drive will become inaccessible.
The syntax of this command is:

manage-bde <driveletter> -lock
Outside of using this command, data drives will be locked on shutdown and restart of the operating system. A
removable data drive will also be locked automatically when the drive is removed from the computer.
Can I use BitLocker with the Volume Shadow Copy Service?
Yes. However, shadow copies made prior to enabling BitLocker will be automatically deleted when BitLocker is
enabled on software-encrypted drives. If you are using a hardware encrypted drive, the shadow copies are
retained.
Does BitLocker support virtual hard disks (VHDs)?
BitLocker is not supported on bootable VHDs, but BitLocker is supported on data volume VHDs, such as those
used by clusters, if you are running Windows 10, Windows 8.1, Windows 8, Windows Server 2012, or Windows
Server 2012 R2.
Can I use BitLocker with virtual machines (VMs)?
Yes. Password protectors and virtual TPMs can be used with BitLocker to protect virtual machines. VMs can be
domain joined, Azure AD-joined, or workplace-joined (in Settings under Accounts > Access work or school >
Connect to work or school to receive policy. You can enable encryption either while creating the VM or by using
other existing management tools such as the BitLocker CSP, or even by using a startup script or logon script
delivered by Group Policy. Windows Server 2016 also supports Shielded VMs and guarded fabric to protect VMs
from malicious administrators.
More information
Prepare your organization for BitLocker: Planning and Policies
BitLocker: How to deploy on Windows Server 2012
BitLocker Cmdlets in Windows PowerShell
Prepare your organization for BitLocker: Planning
and policies
Applies to
Windows 10
This topic for the IT professional explains how can you plan your BitLocker deployment.
When you design your BitLocker deployment strategy, define the appropriate policies and configuration
requirements based on the business requirements of your organization. The following topics will help you collect
information that you can use to frame your decision-making process about deploying and managing BitLocker
systems.
Audit your environment
Encryption keys and authentication
TPM hardware configurations
Non-TPM hardware configurations
Disk configuration considerations
BitLocker provisioning
Active Directory Domain Services considerations
FIPS support for recovery password protector
Audit your environment

To plan your enterprise deployment of BitLocker, you must first understand your current environment. Conduct
an informal audit to define your current policies, procedures, and hardware environment. Begin by reviewing your
existing corporate security policies as they relate to disk encryption software. If your organization is not currently
using disk encryption software, none of these policies will exist. If you are using disk encryption software, then you
might need to modify your organization's policies to address the capabilities of BitLocker.
Use the following questions to help you document your organization's current disk encryption security policies:
1. Are there policies to address which computers will use BitLocker and which computers will not use BitLocker?
2. What policies exist to control recovery password and recovery key storage?
3. What are the policies for validating the identity of users that need to perform BitLocker recovery?
4. What policies exist to control who in the organization has access to recovery data?
5. What policies exist to control computer decommissioning or retirement?
Encryption keys and authentication

BitLocker helps prevent unauthorized access to data on lost or stolen computers by:
Encrypting the entire Windows operating system volume on the hard disk.
Verifying the boot process integrity.
The trusted platform module (TPM) is a hardware component installed in many newer computers by the
computer manufacturers. It works with BitLocker to help protect user data and to ensure that a computer has not
been tampered with while the system was offline.
In addition, BitLocker offers the option to lock the normal startup process until the user supplies a personal
identification number (PIN) or inserts a removable USB device, such as a flash drive, that contains a startup key.
These additional security measures provide multifactor authentication and assurance that the computer will not
start or resume from hibernation until the correct PIN or startup key is presented.
On computers that do not have a TPM version 1.2 or higher, you can still use BitLocker to encrypt the Windows
operating system volume. However, this implementation will require the user to insert a USB startup key to start
the computer or resume from hibernation, and does not provide the pre-startup system integrity verification
offered by BitLocker working with a TPM.
BitLocker key protectors
KEY PROTECTOR DESCRIPTION
TPM A hardware device used to help establish a secure root-of-

trust. BitLocker only supports TPM version 1.2 or higher.
PIN A user-entered numeric key protector that can only be used

in addition to the TPM.
Enhanced PIN A user-entered alphanumeric key protector that can only be

used in addition to the TPM.
Startup key An encryption key that can be stored on most removable

media. This key protector can be used alone on non-TPM
computers, or in conjunction with a TPM for added security.
Recovery password A 48-digit number used to unlock a volume when it is in

recovery mode. Numbers can often be typed on a regular
keyboard, if the numbers on the normal keyboard are not
responding you can always use the function keys (F1-F10) to
input the numbers.
Recovery key An encryption key stored on removable media that can be

used for recovering data encrypted on a BitLocker volume.
BitLocker authentication methods

AUTHENTICATION METHOD REQUIRES USER INTERACTION DESCRIPTION
TPM only No TPM validates early boot components.
TPM + PIN Yes TPM validates early boot components.

The user must enter the correct PIN
before the start-up process can
continue, and before the drive can be
unlocked. The TPM will enter lockout if
the incorrect PIN is entered repeatedly
to protect the PIN from brute force
attacks. The number of repeated
attempts that will trigger a lockout is
variable.
AUTHENTICATION METHOD REQUIRES USER INTERACTION DESCRIPTION
TPM + Network key No The TPM successfully validates early

boot components, and a valid
encrypted network key has been
provided from the WDS server. This
authentication method provides
automatic unlock of operating system
volumes at system reboot while still
maintaining multifactor authentication.
TPM + startup key Yes The TPM successfully validates early

boot components, and a USB flash
drive containing the startup key has
been inserted.
Startup key only Yes The user is prompted to insert the USB
flash drive that holds the recovery key
and/or startup key and reboot the
computer.
Will you support computers without TPM version 1.2 or higher?

Determine whether you will support computers that do not have a TPM version 1.2 or higher in your
environment. If you choose to support BitLocker on this type of computer, a user must use a USB startup key to
boot the system. This requires additional support processes similar to multifactor authentication.
What areas of your organization need a baseline level of data protection?
The TPM-only authentication method will provide the most transparent user experience for organizations that
need a baseline level of data protection to meet security policies. It has the lowest total cost of ownership. TPM-
only might also be more appropriate for computers that are unattended or that must reboot unattended.
However, TPM-only authentication method offers the lowest level of data protection. This authentication method
protects against attacks that modify early boot components, but the level of protection can be affected by
potential weaknesses in hardware or in the early boot components. BitLockers multifactor authentication
methods significantly increase the overall level of data protection.
What areas of your organization need a more secure level of data protection?
If there are areas of your organization where data residing on user computers is considered highly-sensitive,
consider the best practice of deploying BitLocker with multifactor authentication on those systems. Requiring the
user to input a PIN significantly increases the level of protection for the system. You can also use BitLocker
Network Unlock to allow these computers to automatically unlock when connected to a trusted wired network
that can provide the Network Unlock key.
What multifactor authentication method does your organization prefer?
The protection differences provided by multifactor authentication methods cannot be easily quantified. Consider
each authentication method's impact on Helpdesk support, user education, user productivity, and automated
systems management processes.
TPM hardware configurations

In your deployment plan, identify what TPM-based hardware platforms will be supported. Document the
hardware models from an OEM of your choice, so that their configurations can be tested and supported. TPM
hardware requires special consideration during all aspects of planning and deployment.
TPM 1.2 states and initialization
For TPM 1.2, there are multiple possible states. Windows 10 automatically initializes the TPM, which brings it to an
enabled, activated, and owned state. This is the state that BitLocker requires before it can use the TPM.
Endorsement keys
For a TPM to be usable by BitLocker, it must contain an endorsement key, which is an RSA key pair. The private
half of the key pair is held inside the TPM and is never revealed or accessible outside the TPM. If the TPM does not
contain an endorsement key, BitLocker will force the TPM to generate one automatically as part of BitLocker setup.
An endorsement key can be created at various points in the TPMs lifecycle, but needs to be created only once for
the lifetime of the TPM. If an endorsement key does not exist for the TPM, it must be created before TPM
ownership can be taken.
For more information about the TPM and the TCG, see the Trusted Computing Group: Trusted Platform Module
(TPM) Specifications (https://go.microsoft.com/fwlink/p/?linkid=69584).
Non-TPM hardware configurations

Devices that do not include a TPM can still be protected by drive encryption. Windows To Go workspaces can be
BitLocker protected using a startup password and PCs without a TPM can use a startup key.
Use the following questions to identify issues that might affect your deployment in a non-TPM configuration:
Are password complexity rules in place?
Do you have budget for USB flash drives for each of these computers?
Do your existing non-TPM devices support USB devices at boot time?
Test your individual hardware platforms with the BitLocker system check option while you are enabling BitLocker.
The system check will ensure that BitLocker can read the recovery information from a USB device and encryption
keys correctly before it encrypts the volume. CD and DVD drives cannot act as a block storage device and cannot
be used to store the BitLocker recovery material.
Disk configuration considerations

To function correctly, BitLocker requires a specific disk configuration. BitLocker requires two partitions that meet
the following requirements:
The operating system partition contains the operating system and its support files; it must be formatted with
the NTFS file system
The system partition (or boot partition) contains the files that are needed to load Windows after the BIOS or
UEFI firware has prepared the system hardware. BitLocker is not enabled on this partition. For BitLocker to
work, the system partition must not be encrypted and must be on a different partition than the operating
system. On UEFI platforms the system partition must be formatted with the FAT 32 file system. On BIOS
platforms the system partition must be formatted with the NTFS file system. It should be at least 350 MB in
size
Windows setup will automatically configure the disk drives of your computer to support BitLocker encryption.
Windows Recovery Environment (Windows RE) is an extensible recovery platform that is based on Windows Pre-
installation Environment (Windows PE). When the computer fails to start, Windows automatically transitions into
this environment, and the Startup Repair tool in Windows RE automates the diagnosis and repair of an
unbootable Windows installation. Windows RE also contains the drivers and tools that are needed to unlock a
volume protected by BitLocker by providing a recovery key or recovery password. To use Windows RE in
conjunction with BitLocker, the Windows RE boot image must reside on a volume that is not protected by
BitLocker.
Windows RE can also be used from boot media other than the local hard disk. If you choose not to install
Windows RE on the local hard disk of BitLocker-enabled computers, you can use alternate boot methods, such as
Windows Deployment Services, CD-ROM, or USB flash drive, for recovery.
BitLocker provisioning
In Windows Vista and Windows 7, BitLocker was provisioned post installation for system and data volumes
through either the manage-bde command line interface or the Control Panel user interface. With newer operating
systems, BitLocker can be easily provisioned before the operating system is installed. Preprovisioning requires
that the computer have a TPM.
To check the BitLocker status of a particular volume, administrators can look at the status of the drive in the
BitLocker control panel applet or Windows Explorer. A status of "Waiting For Activation" with a yellow exclamation
icon means that the drive was preprovisioned for BitLocker. This status means that there was only a clear
protector used when encrypting the volume. In this case, the volume is not protected and needs to have a secure
key added to the volume before the drive is considered fully protected. Administrators can use the control panel
options, manage-bde tool or WMI APIs to add an appropriate key protector and the volume status will be updated.
When using the control panel options, administrators can choose to Turn on BitLocker and follow the steps in
the wizard to add a protector, such as a PIN for an operating system volume (or a password if no TPM exists), or a
password or smart card protector to a data volume. Then the drive security window is presented prior to changing
the volume status.
Administrators can enable BitLocker prior to operating system deployment from the Windows Pre-installation
Environment (WinPE). This is done with a randomly generated clear key protector applied to the formatted
volume and encrypting the volume prior to running the Windows setup process. If the encryption uses the Used
Disk Space Only option this step takes only a few seconds and so incorporates well into regular deployment
processes.

The BitLocker Setup wizard provides administrators the ability to choose the Used Disk Space Only or Full
encryption method when enabling BitLocker for a volume. Administrators can use the new BitLocker Group Policy
setting to enforce either Used Disk Space Only or Full disk encryption.
Launching the BitLocker Setup wizard prompts for the authentication method to be used (password and smart
card are available for data volumes). Once the method is chosen and the recovery key is saved, you are asked to
choose the drive encryption type, either Used Disk Space Only or Full drive encryption.
Used Disk Space Only means that only the portion of the drive that contains data will be encrypted, unused space
will remain unencrypted. This causes the encryption process to be much faster, especially for new PCs and data
drives. When BitLocker is enabled with this method as data is added to the drive the portion of the drive used will
be encrypted, so there is never unencrypted data stored on the drive.
Full drive encryption means that the entire drive will be encrypted, regardless of whether data is stored on it or
not. This is useful for drives that have been repurposed and may contain data remnants from their previous use.
Active Directory Domain Services considerations

BitLocker integrates with Active Directory Domain Services (AD DS) to provide centralized key management. By
default, no recovery information is backed up to Active Directory. Administrators can configure Group Policy
settings to enable backup of BitLocker or TPM recovery information. Before configuring these settings verify that
access permissions have been granted to perform the backup.
By default, domain administrators are the only users that will have access to BitLocker recovery information.
When you plan your support process, define what parts of your organization need access to BitLocker recovery
information. Use this information to define how the appropriate rights will be delegated in your AD DS
environment.
It is a best practice to require backup of recovery information for both the TPM and BitLocker to AD DS. You can
implement this practice by configuring the Group Policy settings below for your BitLocker-protected computers.
BITLOCKER GROUP POLICY SETTING CONFIGURATION
BitLocker Drive Encryption: Turn on BitLocker backup to Require BitLocker backup to AD DS (Passwords and key
Active Directory Domain Services packages)
Trusted Platform Module Services: Turn on TPM backup to Require TPM backup to AD DS
Active Directory Domain Services
The following recovery data will be saved for each computer object:
Recovery password
A 48-digit recovery password used to recover a BitLocker-protected volume. Users enter this password to
unlock a volume when BitLocker enters recovery mode.
Key package data
With this key package and the recovery password, you will be able decrypt portions of a BitLocker-
protected volume if the disk is severely damaged. Each key package will only work with the volume it was
created on, which can be identified by the corresponding volume ID.
TPM owner authorization password hash
When ownership of the TPM is taken a hash of the ownership password can be taken and stored in AD DS.
This information can then be used to reset ownership of the TPM.
Starting in Windows 8, a change to how the TPM owner authorization value is stored in AD DS was implemented
in the AD DS schema. The TPM owner authorization value is now stored in a separate object which is linked to the
Computer object. This value was stored as a property in the Computer object itself for the default Windows Server
2008 R2 and later schemas.
To take advantage of this integration, you must upgrade your domain controllers to Windows Server 2012 or
extend the Active Directory schema and configure BitLocker-specific Group Policy objects.
Note: The account that you use to update the Active Directory schema must be a member of the Schema
Admins group.
Windows Server 2012 domain controllers have the default schema to backup TPM owner authorization
information in the separate object. If you are not upgrading your domain controller to Windows Server 2012 you
need to extend the schema to support this change.
To support Windows 8 and later computers that are managed by a Windows Server 2003 or Windows
2008 domain controller
There are two schema extensions that you can copy down and add to your AD DS schema:
TpmSchemaExtension.ldf
This schema extension brings parity with the Windows Server 2012 schema. With this change, the TPM
owner authorization information is stored in a separate TPM object linked to the corresponding computer
object. Only the Computer object that has created the TPM object can update it. This means that any
subsequent updates to the TPM objects will not succeed in dual boot scenarios or scenarios where the
computer is reimaged resulting in a new AD computer object being created. To support such scenarios, an
update to the schema was created.
TpmSchemaExtensionACLChanges.ldf
This schema update modifies the ACLs on the TPM object to be less restrictive so that any subsequent
operating system which takes ownership of the computer object can update the owner authorization value
in AD DS. However, this is less secure as any computer in the domain can now update the OwnerAuth of
the TPM object (although it cannot read the OwnerAuth) and DOS attacks can be made from within the
enterprise. The recommended mitigation in such a scenario is to do regular backup of TPM objects and
enable auditing to track changes for these objects.
To download the schema extensions, see AD DS schema extensions to support TPM backup.
If you have a Windows Server 2012 domain controller in your environment, the schema extensions are already in
place and do not need to be updated.
Caution: To configure Group Policy objects to backup TPM and BitLocker information in AD DS at least one of
the domain controllers in your forest must be running at least Windows Server 2008 R2. If Active Directory
backup of the TPM owner authorization value is enabled in an environment without the required schema
extensions, the TPM provisioning will fail and the TPM will remain in a Not Ready state for computers running
Windows 8 and later.
Setting the correct permissions in AD DS

To initialize the TPM successfully so that you can turn on BitLocker requires that the correct permissions for the
SELF account in be set in AD DS for the ms-TPMOwnerInformation attribute. The following steps detail setting
these permissions as required by BitLocker:
1. Open Active Directory Users and Computers.
2. Select the organizational unit (OU) which contains the computer accounts that will have BitLocker turned on.
3. Right-click the OU and click Delegate Control to open the Delegation of Control wizard.
4. Click Next to go to the Users or Groups page and then click Add.
5. In the Select Users, Computers, or Groups dialog box, type SELF as the object name and then click OK Once
the object has been validated you will be returned to the Users or Groups wizard page and the SELF account
will be listed. Click Next.
6. On the Tasks to Delegate page, choose Create a custom task to delegate and then click Next.
7. On the Active Directory Object Type page, choose Only the following objects in the folder and then
check Computer Objects and then click Next.
8. On the Permissions page, for Show these permissions, check General, Property-specific, and
Creation/deletion of specific child objects. Scroll down the Permissions list and check both Write
msTPM-OwnerInformation and Write msTPM-TpmInformationForComputer then click Next.
9. Click Finish to apply the permissions settings.
FIPS support for recovery password protector

Functionality introduced in Windows Server 2012 R2 and Windows 8.1, allows BitLocker to be fully functional in
FIPS mode.
Note: The United States Federal Information Processing Standard (FIPS) defines security and interoperability
requirements for computer systems that are used by the U.S. federal government. The FIPS 140 standard
defines approved cryptographic algorithms. The FIPS 140 standard also sets forth requirements for key
generation and for key management. The National Institute of Standards and Technology (NIST) uses the
Cryptographic Module Validation Program (CMVP) to determine whether a particular implementation of a
cryptographic algorithm is compliant with the FIPS 140 standard. An implementation of a cryptographic
algorithm is considered FIPS 140-compliant only if it has been submitted for and has passed NIST validation.
An algorithm that has not been submitted cannot be considered FIPS-compliant even if the implementation
produces identical data as a validated implementation of the same algorithm.
Prior to these supported versions of Windows, when Windows was in FIPS mode, BitLocker prevented the creation
or use of recovery passwords and instead forced the user to use recovery keys. For more information about these
issues, see the support article kb947249.
But on computers running these supported systems with BitLocker enabled:
FIPS-compliant recovery password protectors can be created when Windows is in FIPS mode. These protectors
use the FIPS 140 NIST SP800-132 algorithm.
Recovery passwords created in FIPS mode on Windows 8.1 can be distinguished from recovery passwords
created on other systems.
Recovery unlock using the FIPS-compliant algorithm based recovery password protector work in all cases that
currently work for recovery passwords.
When FIPS-compliant recovery passwords unlock volumes, the volume is unlocked to allow read/write access
even while in FIPS mode.
FIPS-compliant recovery password protectors can be exported and stored in AD a while in FIPS mode.
The BitLocker Group Policy settings for recovery passwords work the same for all Windows versions that support
BitLocker, whether in FIPs mode or not.
However, you cannot use recovery passwords generated on a system in FIPS mode for systems earlier than
Windows Server 2012 R2 and Windows 8.1. Recovery passwords created on Windows Server 2012 R2 and
Windows 8.1 are incompatible with BitLocker on operating systems prior to Windows Server 2012 R2 and
Windows 8.1; so recovery keys should be used instead.
More information
BitLocker
Applies to
Windows 10
This topic for the IT professional explains how BitLocker features can be used to protect your data through drive
encryption.
The following sections provide information that will help you put together your basic deployment plan for
implementing BitLocker in your organization:
Using BitLocker to encrypt volumes
Down-level compatibility
Using manage-bde to encrypt volumes with BitLocker
Using PowerShell to encrypt volumes with BitLocker
Using BitLocker to encrypt volumes

BitLocker provides full volume encryption (FVE) for operating system volumes, as well as fixed and removable data
volumes. To support fully encrypted operating system volumes, BitLocker uses an unencrypted system volume for
the files required to boot, decrypt, and load the operating system. This volume is automatically created during a
new installation of both client and server operating systems.
In the event that the drive was prepared as a single contiguous space, BitLocker requires a new volume to hold the
boot files. BdeHdCfg.exe can create these volumes.
Note: For more info about using this tool, see Bdehdcfg in the Command-Line Reference.
BitLocker encryption can be done using the following methods:

BitLocker control panel
Windows Explorer
manage-bde command line interface
BitLocker Windows PowerShell cmdlets
Encrypting volumes using the BitLocker control panel
Encrypting volumes with the BitLocker control panel (click Start, type bitlocker, click Manage BitLocker) is how
many users will utilize BitLocker. The name of the BitLocker control panel is BitLocker Drive Encryption. The
BitLocker control panel supports encrypting operating system, fixed data and removable data volumes. The
BitLocker control panel will organize available drives in the appropriate category based on how the device reports
itself to Windows. Only formatted volumes with assigned drive letters will appear properly in the BitLocker control
panel applet. To start encryption for a volume, select Turn on BitLocker for the appropriate drive to initialize the
BitLocker Drive Encryption Wizard. BitLocker Drive Encryption Wizard options vary based on volume type
(operating system volume or data volume).
Operating system volume
Upon launch, the BitLocker Drive Encryption Wizard verifies the computer meets the BitLocker system
requirements for encrypting an operating system volume. By default, the system requirements are:
REQUIREMENT DESCRIPTION
Hardware configuration The computer must meet the minimum requirements for
the supported Windows versions.
Operating system BitLocker is an optional feature which can be installed by

Server Manager on Windows Server 2012 and later.
Hardware TPM TPM version 1.2 or 2.0

A TPM is not required for BitLocker; however, only a
computer with a TPM can provide the additional security
of pre-startup system integrity verification and multifactor
authentication.
BIOS configuration A Trusted Computing Group (TCG)-compliant

BIOS or UEFI firmware.
The boot order must be set to start first from the
hard disk, and not the USB or CD drives.
The firmware must be able to read from a USB
flash drive during startup.
File system For computers that boot natively with UEFI firmware, at
least one FAT32 partition for the system drive and one
NTFS partition for the operating system drive.
For computers with legacy BIOS firmware, at least two
NTFS disk partitions, one for the system drive and one for
the operating system drive.
For either firmware, the system drive partition must be at
least 350 megabytes (MB) and set as the active partition.
Hardware encrypted drive prerequisites (optional) To use a hardware encrypted drive as the boot drive, the
drive must be in the uninitialized state and in the security
inactive state. In addition, the system must always boot
with native UEFI version 2.3.1 or higher and the CSM (if
any) disabled.
Upon passing the initial configuration, users are required to enter a password for the volume. If the volume does
not pass the initial configuration for BitLocker, the user is presented with an error dialog describing the
appropriate actions to be taken. Once a strong password has been created for the volume, a recovery key will be
generated. The BitLocker Drive Encryption Wizard will prompt for a location to save this key. A BitLocker recovery
key is a special key that you can create when you turn on BitLocker Drive Encryption for the first time on each drive
that you encrypt. You can use the recovery key to gain access to your computer if the drive that Windows is
installed on (the operating system drive) is encrypted using BitLocker Drive Encryption and BitLocker detects a
condition that prevents it from unlocking the drive when the computer is starting up. A recovery key can also be
used to gain access to your files and folders on a removable data drive (such as an external hard drive or USB flash
drive) that is encrypted using BitLocker To Go, if for some reason you forget the password or your computer
cannot access the drive.
You should store the recovery key by printing it, saving it on removable media, or saving it as a file in a network
folder or on your OneDrive, or on another drive of your computer that you are not encrypting. You cannot save the
recovery key to the root directory of a non-removable drive and cannot be stored on the encrypted volume. You
cannot save the recovery key for a removable data drive (such as a USB flash drive) on removable media. Ideally,
you should store the recovery key separate from your computer. After you create a recovery key, you can use the
BitLocker control panel to make additional copies.
When the recovery key has been properly stored, the BitLocker Drive Encryption Wizard will prompt the user to
choose how to encrypt the drive. There are two options:
Encrypt used disk space only - Encrypts only disk space that contains data
Encrypt entire drive - Encrypts the entire volume including free space
It is recommended that drives with little to no data utilize the used disk space only encryption option and that
drives with data or an operating system utilize the encrypt entire drive option.
Note: Deleted files appear as free space to the file system, which is not encrypted by used disk space only.
Until they are wiped or overwritten, deleted files hold information that could be recovered with common data
forensic tools.
Selecting an encryption type and choosing Next will give the user the option of running a BitLocker system check
(selected by default) which will ensure that BitLocker can properly access the recovery and encryption keys before
the volume encryption begins. It is recommended to run this system check before starting the encryption process.
If the system check is not run and a problem is encountered when the operating system attempts to start, the user
will need to provide the recovery key to start Windows.
After completing the system check (if selected), the BitLocker Drive Encryption Wizard will restart the computer to
begin encryption. Upon reboot, users are required to enter the password chosen to boot into the operating system
volume. Users can check encryption status by checking the system notification area or the BitLocker control panel.
Until encryption is completed, the only available options for managing BitLocker involve manipulation of the
password protecting the operating system volume, backing up the recovery key, and turning BitLocker off.
Data volume
Encrypting data volumes using the BitLocker control panel interface works in a similar fashion to encryption of the
operating system volumes. Users select Turn on BitLocker within the control panel to begin the BitLocker Drive
Encryption wizard. Unlike for operating system volumes, data volumes are not required to pass any configuration
tests for the wizard to proceed. Upon launching the wizard, a choice of authentication methods to unlock the drive
appears. The available options are password and smart card and automatically unlock this drive on this
computer. Disabled by default, the latter option will unlock the data volume without user input when the
operating system volume is unlocked.
After selecting the desired authentication method and choosing Next, the wizard presents options for storage of
the recovery key. These options are the same as for operating system volumes. With the recovery key saved,
selecting Next in the wizard will show available options for encryption. These options are the same as for
operating system volumes; used disk space only and full drive encryption. If the volume being encrypted is
new or empty, it is recommended that used space only encryption is selected.
With an encryption method chosen, a final confirmation screen displays before beginning the encryption process.
Selecting Start encrypting will begin encryption.
Encryption status displays in the notification area or within the BitLocker control panel.
OneDrive option
There is a new option for storing the BitLocker recovery key using the OneDrive. This option requires that
computers are not members of a domain and that the user is using a Microsoft Account. Local accounts do not
give the option to utilize OneDrive. Using the OneDrive option is the default, recommended recovery key storage
method for computers that are not joined to a domain.
Users can verify the recovery key was saved properly by checking their OneDrive for the BitLocker folder which is
created automatically during the save process. The folder will contain two files, a readme.txt and the recovery key.
For users storing more than one recovery password on their OneDrive, they can identify the required recovery key
by looking at the file name. The recovery key ID is appended to the end of the file name.
Using BitLocker within Windows Explorer
Windows Explorer allows users to launch the BitLocker Drive Encryption wizard by right clicking on a volume and
selecting Turn On BitLocker. This option is available on client computers by default. On servers, you must first
install the BitLocker and Desktop-Experience features for this option to be available. After selecting Turn on
BitLocker, the wizard works exactly as it does when launched using the BitLocker control panel.
Down-level compatibility
The following table shows the compatibility matrix for systems that have been BitLocker enabled then presented to
a different version of Windows.
Table 1: Cross compatibility for Windows 10, Windows 8.1, Windows 8, and Windows 7 encrypted volumes
Encryption Type Windows 10 and Windows 8 Windows 7

Windows 8.1
Fully encrypted on Presents as fully N/A Presented as fully

Windows 8 encrypted encrypted
Used Disk Space Only Presents as encrypt on N/A Presented as fully

encrypted on Windows write encrypted
8
Fully encrypted volume Presents as fully Presented as fully N/A

from Windows 7 encrypted encrypted
Partially encrypted Windows 10 and Windows 8 will complete N/A

volume from Windows 7 Windows 8.1 will encryption regardless of
complete encryption policy
regardless of policy
Encrypting volumes using the manage -bde command line interface

Manage-bde is a command-line utility that can be used for scripting BitLocker operations. Manage-bde offers
additional options not displayed in the BitLocker control panel. For a complete list of the options, see Manage-bde.
Manage-bde offers a multitude of wider options for configuring BitLocker. This means that using the command
syntax may require care and possibly later customization by the user. For example, using just the manage-bde -on
command on a data volume will fully encrypt the volume without any authenticating protectors. A volume
encrypted in this manner still requires user interaction to turn on BitLocker protection, even though the command
successfully completed because an authentication method needs to be added to the volume for it to be fully
protected. Command line users need to determine the appropriate syntax for a given situation. The following
section covers general encryption for operating system volumes and data volumes.
Listed below are examples of basic valid commands for operating system volumes. In general, using only the
manage-bde -on <drive letter> command will encrypt the operating system volume with a TPM-only protector
and no recovery key. However, many environments require more secure protectors such as passwords or PIN and
expect to be able to recover information with a recovery key.
Determining volume status
A good practice when using manage-bde is to determine the volume status on the target system. Use the
following command to determine volume status:
manage-bde -status
This command returns the volumes on the target, current encryption status and volume type (operating system or
data) for each volume. Using this information, users can determine the best encryption method for their
environment.
Enabling BitLocker without a TPM
For example, suppose that you want to enable BitLocker on a computer without a TPM chip. To properly enable
BitLocker for the operating system volume, you will need to use a USB flash drive as a startup key to boot (in this
example, the drive letter E). You would first create the startup key needed for BitLocker using the protectors
option and save it to the USB drive on E: and then begin the encryption process. You will need to reboot the
computer when prompted to complete the encryption process.
manage-bde protectors -add C: -startupkey E:

manage-bde -on C:
Enabling BitLocker with a TPM only

It is possible to encrypt the operating system volume without any defined protectors using manage-bde. The
command to do this is:
manage-bde -on C:
This will encrypt the drive using the TPM as the protector. If a user is unsure of the protector for a volume, they can
use the -protectors option in manage-bde to list this information with the command:
manage-bde -protectors -get <volume>
Provisioning BitLocker with two protectors

Another example is a user on non-TPM hardware who wishes to add a password and SID-based protector to the
operating system volume. In this instance, the user adds the protectors first. This is done with the command:
manage-bde -protectors -add C: -pw -sid <user or group>
This command will require the user to enter and then confirm the password protector before adding them to the
volume. With the protectors enabled on the volume, the user just needs to turn BitLocker on.
Data volume
Data volumes use the same syntax for encryption as operating system volumes but they do not require protectors
for the operation to complete. Encrypting data volumes can be done using the base command:
manage-bde -on <drive letter> or users can choose to add protectors to the volume. It is recommended that at
least one primary protector and a recovery protector be added to a data volume.
Enabling BitLocker with a password
A common protector for a data volume is the password protector. In the example below, we add a password
protector to the volume and turn BitLocker on.
manage-bde -protectors -add -pw C:
manage-bde -on C:
Using manage-bde to encrypt volumes with BitLocker

Encrypting volumes using the BitLocker Windows PowerShell cmdlets
Windows PowerShell cmdlets provide an alternative way to work with BitLocker. Using Windows PowerShell's
scripting capabilities, administrators can integrate BitLocker options into existing scripts with ease. The list below
displays the available BitLocker cmdlets.
Name Parameters
Add-BitLockerKeyProtector -ADAccountOrGroup
-ADAccountOrGroupProtector
-Confirm
-MountPoint
-Password
-PasswordProtector
-Pin
-RecoveryKeyPath
-RecoveryKeyProtector
-RecoveryPassword
-RecoveryPasswordProtector
-Service
-StartupKeyPath
-StartupKeyProtector
-TpmAndPinAndStartupKeyProtector
-TpmAndPinProtector
-TpmAndStartupKeyProtector
-TpmProtector
-WhatIf
Backup-BitLockerKeyProtector -Confirm
-KeyProtectorId
-MountPoint
-WhatIf
Disable-BitLocker -Confirm
-MountPoint
-WhatIf
Disable-BitLockerAutoUnlock -Confirm
-MountPoint
-WhatIf
Enable-BitLocker -AdAccountOrGroup
-AdAccountOrGroupProtector
-Confirm
-EncryptionMethod
-HardwareEncryption
-Password
-PasswordProtector
-Pin
-RecoveryKeyPath
-RecoveryPassword
-Service
-SkipHardwareTest
-StartupKeyPath
-TpmAndPinProtector
-TpmProtector
-UsedSpaceOnly
-WhatIf
Enable-BitLockerAutoUnlock -Confirm
-MountPoint
-WhatIf
Get-BitLockerVolume -MountPoint
Lock-BitLocker -Confirm
-ForceDismount
-MountPoint
-WhatIf
Remove-BitLockerKeyProtector -Confirm
-KeyProtectorId
-MountPoint
-WhatIf
Resume-BitLocker -Confirm
-MountPoint
-WhatIf
Suspend-BitLocker -Confirm
-MountPoint
-RebootCount
-WhatIf
Unlock-BitLocker -AdAccountOrGroup
-Confirm
-MountPoint
-Password
-RecoveryKeyPath
-RecoveryPassword
-RecoveryPassword
-WhatIf
Similar to manage-bde, the Windows PowerShell cmdlets allow configuration beyond the options offered in the
control panel. As with manage-bde, users need to consider the specific needs of the volume they are encrypting
prior to running Windows PowerShell cmdlets. A good initial step is to determine the current state of the
volume(s) on the computer. You can do this using the Get-BitLocker volume cmdlet. The output from this cmdlet
displays information on the volume type, protectors, protection status, and other useful information. Occasionally,
all protectors may not be shown when using Get-BitLockerVolume due to lack of space in the output display. If
you do not see all of the protectors for a volume, you can use the Windows PowerShell pipe command (|) to
format a listing of the protectors.
Note: In the event that there are more than four protectors for a volume, the pipe command may run out of
display space. For volumes with more than four protectors, use the method described in the section below to
generate a listing of all protectors with protector ID.
Get-BitLockerVolume C: | fl
If you wanted to remove the existing protectors prior to provisioning BitLocker on the volume, you can utilize the
Remove-BitLockerKeyProtector cmdlet. Accomplishing this requires the GUID associated with the protector to be
removed. A simple script can pipe the values of each Get-BitLockerVolume return out to another variable as seen
below:
$vol = Get-BitLockerVolume
$keyprotectors = $vol.KeyProtector
Using this, we can display the information in the $keyprotectors variable to determine the GUID for each
protector. Using this information, we can then remove the key protector for a specific volume using the command:
Remove-BitLockerKeyProtector <volume>: -KeyProtectorID "{GUID}"
Note: The BitLocker cmdlet requires the key protector GUID enclosed in quotation marks to execute. Ensure
the entire GUID, with braces, is included in the command.

Using the BitLocker Windows PowerShell cmdlets is similar to working with the manage-bde tool for encrypting
operating system volumes. Windows PowerShell offers users a lot of flexibility. For example, users can add the
desired protector as part command for encrypting the volume. Below are examples of common user scenarios and
steps to accomplish them using the BitLocker cmdlets for Windows PowerShell. To enable BitLocker with just the
TPM protector. This can be done using the command:
Enable-BitLocker C:
The example below adds one additional protector, the StartupKey protectors, and chooses to skip the BitLocker
hardware test. In this example, encryption starts immediately without the need for a reboot.
Enable-BitLocker C: -StartupKeyProtector -StartupKeyPath <path> -SkipHardwareTest
Data volume
Data volume encryption using Windows PowerShell is the same as for operating system volumes. You should add
the desired protectors prior to encrypting the volume. The following example adds a password protector to the E:
volume using the variable $pw as the password. The $pw variable is held as a SecureString value to store the user
defined password. Last, encryption begins.
$pw = Read-Host -AsSecureString

<user inputs password>
Enable-BitLockerKeyProtector E: -PasswordProtector -Password $pw
Using a SID based protector in Windows PowerShell

The ADAccountOrGroup protector is an Active Directory SID-based protector. This protector can be added to both
operating system and data volumes, although it does not unlock operating system volumes in the pre-boot
environment. The protector requires the SID for the domain account or group to link with the protector. BitLocker
can protect a cluster-aware disk by adding a SID-based protector for the Cluster Name Object (CNO) that lets the
disk properly failover and be unlocked to any member computer of the cluster.
Warning: The SID-based protector requires the use of an additional protector (such as TPM, PIN, recovery key,
etc.) when used on operating system volumes.
To add an ADAccountOrGroup protector to a volume requires either the actual domain SID or the group name
preceded by the domain and a backslash. In the example below, the CONTOSO\Administrator account is added as
a protector to the data volume G.
Enable-BitLocker G: -AdAccountOrGroupProtector -AdAccountOrGroup CONTOSO\Administrator
For users who wish to use the SID for the account or group, the first step is to determine the SID associated with
the account. To get the specific SID for a user account in Windows PowerShell, use the following command:
get-aduser -filter {samaccountname -eq "administrator"}
Note: Use of this command requires the RSAT-AD-PowerShell feature.

Tip: In addition to the Windows PowerShell command above, information about the locally logged on user
and group membership can be found using: WHOAMI /ALL. This does not require the use of additional
features.
In the example below, the user wishes to add a domain SID based protector to the previously encrypted operating
system volume. The user knows the SID for the user account or group they wish to add and uses the following
command:
Add-BitLockerKeyProtector C: -ADAccountOrGroupProtector -ADAccountOrGroup "<SID>"
Note: Active Directory-based protectors are normally used to unlock Failover Cluster enabled volumes.
Using PowerShell to encrypt volumes with BitLocker

Checking BitLocker status
To check the BitLocker status of a particular volume, administrators can look at the status of the drive in the
BitLocker control panel applet, Windows Explorer, manage-bde command line tool, or Windows PowerShell
cmdlets. Each option offers different levels of detail and ease of use. We will look at each of the available methods
in the following section.
Checking BitLocker status with the control panel
Checking BitLocker status with the control panel is the most common method used by most users. Once opened,
the status for each volume will display next to the volume description and drive letter. Available status return
values with the control panel include:
STATUS DESCRIPTION
On BitLocker is enabled for the volume
Off BitLocker is not enabled for the volume
Suspended BitLocker is suspended and not actively protecting the volume
Waiting for Activation BitLocker is enabled with a clear protector key and requires
further action to be fully protected
If a drive is pre-provisioned with BitLocker, a status of "Waiting for Activation" displays with a yellow exclamation
icon on volume E. This status means that there was only a clear protector used when encrypting the volume. In this
case, the volume is not in a protected state and needs to have a secure key added to the volume before the drive is
fully protected. Administrators can use the control panel, manage-bde tool, or WMI APIs to add an appropriate key
protector. Once complete, the control panel will update to reflect the new status. Using the control panel,
administrators can choose Turn on BitLocker to start the BitLocker Drive Encryption wizard and add a protector,
like PIN for an operating system volume (or password if no TPM exists), or a password or smart card protector to a
data volume. The drive security window displays prior to changing the volume status. Selecting Activate
BitLocker will complete the encryption process.
Once BitLocker protector activation is completed, the completion notice is displayed.
Checking BitLocker status with manage -bde
Administrators who prefer a command line interface can utilize manage-bde to check volume status. Manage-bde
is capable of returning more information about the volume than the graphical user interface tools in the control
panel. For example, manage-bde can display the BitLocker version in use, the encryption type, and the protectors
associated with a volume.
To check the status of a volume using manage-bde, use the following command:
manage-bde -status <volume>
Note: If no volume letter is associated with the -status command, all volumes on the computer display their
status.
Checking BitLocker status with Windows PowerShell

Windows PowerShell commands offer another way to query BitLocker status for volumes. Like manage-bde,
Windows PowerShell includes the advantage of being able to check the status of a volume on a remote computer.
Using the Get-BitLockerVolume cmdlet, each volume on the system will display its current BitLocker status. To get
information that is more detailed on a specific volume, use the following command:
Get-BitLockerVolume <volume> -Verbose | fl
This command will display information about the encryption method, volume type, key protectors, etc.
Provisioning BitLocker during operating system deployment
Administrators can enable BitLocker prior to operating system deployment from the Windows Pre-installation
Environment. This is done with a randomly generated clear key protector applied to the formatted volume and
encrypting the volume prior to running the Windows setup process. If the encryption uses the Used Disk Space
Only option described later in this document, this step takes only a few seconds and incorporates well into regular
deployment processes.
Decrypting BitLocker volumes
Decrypting volumes removes BitLocker and any associated protectors from the volumes. Decryption should occur
when protection is no longer required. BitLocker decryption should not occur as a troubleshooting step. BitLocker
can be removed from a volume using the BitLocker control panel applet, manage-bde, or Windows PowerShell
cmdlets. We will discuss each method further below.
Decrypting volumes using the BitLocker control panel applet
BitLocker decryption using the control panel is done using a Wizard. The control panel can be called from
Windows Explorer or by opening the directly. After opening the BitLocker control panel, users will select the Turn
off BitLocker option to begin the process. Once selected, the user chooses to continue by clicking the confirmation
dialog. With Turn off BitLocker confirmed, the drive decryption process will begin and report status to the control
panel.
The control panel does not report decryption progress but displays it in the notification area of the task bar.
Selecting the notification area icon will open a modal dialog with progress.
Once decryption is complete, the drive will update its status in the control panel and is available for encryption.
Decrypting volumes using the manage -bde command line interface
Decrypting volumes using manage-bde is very straightforward. Decryption with manage-bde offers the advantage
of not requiring user confirmation to start the process. Manage-bde uses the -off command to start the decryption
process. A sample command for decryption is:
manage-bde -off C:
This command disables protectors while it decrypts the volume and removes all protectors when decryption is
complete. If a user wishes to check the status of the decryption, they can use the following command:
manage-bde -status C:
Decrypting volumes using the BitLocker Windows PowerShell cmdlets

Decryption with Windows PowerShell cmdlets is straightforward, similar to manage-bde. The additional advantage
Windows PowerShell offers is the ability to decrypt multiple drives in one pass. In the example below, the user has
three encrypted volumes, which they wish to decrypt.
Using the Disable-BitLocker command, they can remove all protectors and encryption at the same time without the
need for additional commands. An example of this command is:
DisableBitLocker
If a user did not want to input each mount point individually, using the -MountPoint parameter in an array can
sequence the same command into one line without requiring additional user input. An example command is:
Disable-BitLocker -MountPoint E:,F:,G:
See also
Prepare your organization for BitLocker: Planning and p\olicies
BitLocker recovery guide
BitLocker overview
and later
Applies to
Windows 10
This topic for the IT professional explains how to deploy BitLocker on Windows Server 2012 and later.
For all Windows Server editions, BitLocker must be installed using Server Manager. However, you can still
provision BitLocker before the server operating system is installed as part of your deployment.
Installing BitLocker
BitLocker requires administrator privileges on the server to install. You can install BitLocker either by using Server
Manager or Windows PowerShell cmdlets.
To install BitLocker using Server Manager
To install BitLocker using Windows PowerShell
To install BitLocker using Server Manager
1. Open Server Manager by selecting the Server Manager icon or running servermanager.exe.
2. Select Manage from the Server Manager Navigation bar and select Add Roles and Features to start the
Add Roles and Features Wizard.
3. With the Add Roles and Features Wizard open, select Next at the Before you begin pane (if shown).
4. Select Role-based or feature-based installation on the Installation type pane of the Add Roles and
Features Wizard pane and select Next to continue.
5. Select the Select a server from the server pool option in the Server Selection pane and confirm the server
for the BitLocker feature install.
6. Server roles and features install using the same wizard in Server Manager. Select Next on the Server Roles
pane of the Add Roles and Features wizard to proceed to the Features pane.
7. Select the check box next to BitLocker Drive Encryption within the Features pane of the Add Roles and
Features Wizard. The wizard will show the additional management features available for BitLocker. If you
do not want to install these features, deselect the Include management tools option and select Add
Features. Once optional features selection is complete, select Next to proceed in the wizard.
Note: The Enhanced Storage feature is a required feature for enabling BitLocker. This feature enables
support for Encrypted Hard Drives on capable systems.
8. Select Install on the Confirmation pane of the Add Roles and Features Wizard to begin BitLocker
feature installation. The BitLocker feature requires a restart to complete. Selecting the Restart the
destination server automatically if required option in the Confirmation pane will force a restart of the
computer after installation is complete.
9. If the Restart the destination server automatically if required check box is not selected, the Results pane
of the Add Roles and Features Wizard will display the success or failure of the BitLocker feature installation.
If required, a notification of additional action necessary to complete the feature installation, such as the restart
of the computer, will be displayed in the results text.
To install BitLocker using Windows PowerShell
Windows PowerShell offers administrators another option for BitLocker feature installation. Windows PowerShell
installs features using the servermanager or dism module; however, the servermanager and dism modules do
not always share feature name parity. Because of this, it is advisable to confirm the feature or role name prior to
installation.
Note: You must restart the server to complete the installation of BitLocker.
Using the servermanager module to install BitLocker

The servermanager Windows PowerShell module can use either the Install-WindowsFeature or
Add-WindowsFeature to install the BitLocker feature. The Add-WindowsFeature cmdlet is merely a stub to the
Install-WindowsFeature . This example uses the Install-WindowsFeature cmdlet. The feature name for BitLocker in
the servermanager module is BitLocker . This can be determined using the Get-WindowsFeature cmdlet with a
query such as:
Get-WindowsFeature Bit
The results of this command displays a table of all of the feature names beginning with Bit as their prefix. This
allows you to confirm that the feature name is BitLocker for the BitLocker feature.
By default, installation of features in Windows PowerShell does not include optional sub-features or management
tools as part of the install process. This can be seen using the -WhatIf option in Windows PowerShell.
Install-WindowsFeature BitLocker -WhatIf
The results of this command show that only the BitLocker Drive Encryption feature installs using this command.
To see what would be installed with the BitLocker feature including all available management tools and sub-
features, use the following command:
Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools -WhatIf | fl
The result of this command displays the following list of all the administration tools for BitLocker that would be
installed along with the feature, including tools for use with Active Directory Domain Services (AD DS) and Active
Directory Lightweight Directory Services (AD LDS).
BitLocker Drive Encryption
BitLocker Drive Encryption Tools
BitLocker Drive Encryption Administration Utilities
BitLocker Recovery Password Viewer
AD DS Snap-Ins and Command-Line Tools
AD DS Tools
AD DS and AD LDS Tools
The command to complete a full installation of the BitLocker feature with all available features and then rebooting
the server at completion is:
Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools -Restart
Important: Installing the BitLocker feature using Windows PowerShell does not install the Enhanced Storage
feature. Administrators wishing to support Encrypted Hard Drives in their environment will need to install the
Enhanced Storage feature separately.
Using the dism module to install BitLocker

The dism Windows PowerShell module uses the Enable-WindowsOptionalFeature cmdlet to install features. The
BitLocker feature name for BitLocker is BitLocker . The dism module does not support wildcards when searching
for feature names. To list feature names for the dism module, use the Get-WindowsOptionalFeatures cmdlet. The
following command will list all of the optional features in an online (running) operating system.
Get-WindowsOptionalFeature -Online | ft
From this output, we can see that there are three BitLocker related optional feature names: BitLocker, BitLocker-
Utilities and BitLocker-NetworkUnlock. To install the BitLocker feature, the BitLocker and BitLocker-Utilities
features are the only required items.
To install BitLocker using the dism module, use the following command:
Enable-WindowsOptionalFeature -Online -FeatureName BitLocker -All
This command will prompt the user for a reboot. The Enable-WindowsOptionalFeature cmdlet does not offer
support for forcing a reboot of the computer. This command does not include installation of the management
tools for BitLocker. For a complete installation of BitLocker and all available management tools, use the following
command:
Enable-WindowsOptionalFeature -Online -FeatureName BitLocker, BitLocker-Utilities -All
More information
BitLocker overview
BitLocker Management Recommendations for
Enterprises
This topic explains recommendations for managing BitLocker, both on-premises using older hardware and cloud-
based management of modern devices.
Forward-looking recommendations for managing BitLocker

The ideal for modern BitLocker management is to eliminate the need for IT admins to set management policies
using tools or other mechanisms by having Windows perform tasks that it is more practical to automate. This
vision leverages modern hardware developments. The growth of TPM 2.0, Secure Boot, and other hardware
improvements, for example, has helped to alleviate the support burden on the helpdesk, and we are seeing a
consequent decrease in support call volumes, yielding improved user satisfaction.
Therefore, we recommend that you upgrade your hardware so that your devices comply with InstantGo or
Hardware Security Test Interface (HSTI) specifications to take advantage of their automated features, for example,
when using Azure Active Directory (Azure AD).
Though much Windows BitLocker documentation has been published, customers frequently ask for
recommendations and pointers to specific, task-oriented documentation that is both easy to digest and focused on
how to deploy and manage BitLocker. This article links to relevant documentation, products, and services to help
answer this and other related frequently-asked questions, and also provides BitLocker recommendations for:
Domain-joined computers
Devices joined to Azure Active Directory (Azure AD)
Workplace-joined PCs and Phones
Servers
Scripts
BitLocker management at a glance

PC OLD HARDWARE PC NEW* HARDWARE SERVERS/VMS PHONE
On-premises MBAM MBAM Scripts N/A

Domain-joined
Cloud-managed MDM Auto-encryption Scripts MDM/EAS
*PC hardware that supports InstantGo or HSTI
Recommendations for domain-joined computers

Windows continues to be the focus for new features and improvements for built-in encryption management, for
example, automatically enabling encryption on devices that support InstantGo beginning with Windows 8.1. For
more information, see Overview of BitLocker and device encryption in Windows 10.
Companies that image their own computers using Microsoft System Center 2012 Configuration Manager SP1
(SCCM) or later can use an existing task sequence to pre-provision BitLocker encryption while in Windows
Preinstallation Environment (WinPE) and can then enable protection. This can help ensure that computers are
encrypted from the start, even before users receive them. As part of the imaging process, a company could also
decide to use SCCM to pre-set any desired BitLocker Group Policy.
For older client computers with BitLocker that are domain joined on-premises, Microsoft BitLocker Administration
and Management[1] (MBAM) remains the best way to manage BitLocker. MBAM continues to be maintained and
receives security patches. Using MBAM provides the following functionality:
Encrypts device with BitLocker using MBAM
Stores BitLocker Recovery keys in MBAM Server
Provides Recovery key access to end-user, helpdesk and advanced helpdesk
Provides Reporting on Compliance and Recovery key access audit
[1] The latest MBAM version is MBAM 2.5 with Service Pack 1 (SP1).
Recommendations for devices joined to Azure Active Directory

Devices joined to Azure Active Directory (Azure AD) are managed using Mobile Device Management (MDM) policy
such as Microsoft Intune. Device encryption status can be queried from managed machines via the Policy
Configuration Settings Provider (CSP), which reports on whether BitLocker device encryption is enabled on the
device. Compliance with device encryption policy can be a requirement for Conditional Access to services like
Exchange Online and SharePoint Online.
Starting with Windows 10 version 1703 (also known as the Windows Creators Update), the enablement of
BitLocker can be triggered over MDM either by the Policy CSP or the Bitlocker CSP. The BitLocker CSP adds policy
options that go beyond ensuring that encryption has occurred, and is available on computers that run Windows 10
Business or Enterprise editions and on Windows Phones.
For hardware that is compliant with InstantGo and HSTI, when using either of these features, device encryption is
automatically turned on whenever the user joins a device to Azure AD. Azure AD provides a portal where recovery
keys are also backed up, so users can retrieve their own recovery key for self-service, if required. For older devices
that are not yet encrypted, beginning with Windows 10 version 1703 (the Windows 10 Creators Update), admins
can use the BitLocker CSP to trigger encryption and store the recovery key in Azure AD.
Workplace-joined PCs and phones

For Windows PCs and Windows Phones that enroll using Connect to work or school account, BitLocker device
encryption is managed over MDM, and similarly for Azure AD domain join.
Recommendations for servers

Servers are often installed, configured, and deployed using PowerShell, so the recommendation is to also use
PowerShell to enable BitLocker on a server, ideally as part of the initial setup. BitLocker is an Optional Component
(OC) in Windows Server, so follow the directions in BitLocker: How to deploy on Windows Server 2012 and later to
add the BitLocker OC.
The Minimal Server Interface is a prerequisite for some of the BitLocker administration tools. On a Server Core
installation, you must add the necessary GUI components first. The steps to add shell components to Server Core
are described in Using Features on Demand with Updated Systems and Patched Images and How to update local
source media to add roles and features.
If you are installing a server manually, such as a stand-alone server, then choosing Server with Desktop Experience
is the easiest path because you can avoid performing the steps to add a GUI to Server Core.
Additionally, lights out data centers can take advantage of the enhanced security of a second factor while avoiding
the need for user intervention during reboots by optionally using a combination of BitLocker (TPM+PIN) and
BitLocker Network Unlock. BitLocker Network Unlock brings together the best of hardware protection, location
dependence, and automatic unlock, while in the trusted location. For the configuration steps, see BitLocker: How to
enable Network Unlock.
For more information, see the Bitlocker FAQs article and other useful links in Related Articles.
PowerShell examples
For Azure AD-joined computers, including virtual machines, the recovery password should be stored in Azure
Active Directory.
Example: Use PowerShell to add a recovery password and back it up to Azure AD before enabling BitLocker
PS C:\>Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector
PS C:\>$BLV = Get-BitLockerVolume -MountPoint "C:
PS C:\>BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[0].KeyProtectorId
For domain-joined computers, including servers, the recovery password should be stored in Active Directory
Domain Services (AD DS).
Example: Use PowerShell to add a recovery password and back it up to AD DS before enabling BitLocker
PS C:\>Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector
PS C:\>$BLV = Get-BitLockerVolume -MountPoint "C:
PS C:\>Backup-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[0].KeyProtectorId
Subsequently, you can use PowerShell to enable BitLocker.

Example: Use PowerShell to enable BitLocker with a TPM protector
PS C:\>Enable-BitLocker -MountPoint "D:" -EncryptionMethod XtsAes256 -UsedSpaceOnly -TpmProtector
Example: Use PowerShell to enable BitLocker with a TPM+PIN protector, in this case with a PIN set to 123456
PS C:\>$SecureString = ConvertTo-SecureString "123456" -AsPlainText -Force
PS C:\> Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -UsedSpaceOnly -Pin $SecureString -

TPMandPinProtector
Related Articles
Bitlocker: FAQs
Microsoft BitLocker Administration and Management (MBAM)
Overview of BitLocker and automatic encryption in Windows 10
System Center 2012 Configuration Manager SP1 (Pre-provision BitLocker task sequence)
Enable BitLocker task sequence
BitLocker Group Policy Reference
Microsoft Intune (Overview)
Configuration Settings Providers (Policy CSP: See Security-RequireDeviceEncryption)
BitLocker CSP
Windows Server setup tools

Windows Server Installation Options
How to update local source media to add roles and features
How to add or remove optional components on Server Core (Features on Demand)
BitLocker: How to deploy on Windows Server 2012 and newer
Shielded VMs and Guarded Fabric
Powershell
BitLocker cmdlets for Windows PowerShell
Surface Pro Specifications
Applies to
Windows 10
This topic for the IT professional describes how BitLocker Network Unlock works and how to configure it.
Network Unlock was introduced in Windows 8 and Windows Server 2012 as a BitLocker protector option for
operating system volumes. Network Unlock enables easier management for BitLocker enabled desktops and
servers in a domain environment by providing automatic unlock of operating system volumes at system reboot
when connected to a wired corporate network. This feature requires the client hardware to have a DHCP driver
implemented in its UEFI firmware. Without Network Unlock, operating system volumes protected by TPM+PIN
protectors require a PIN to be entered when a computer reboots or resumes from hibernation (for example, by
Wake on LAN). This can make it difficult to enterprises to roll out software patches to unattended desktops and
remotely administered servers.
Network Unlock allows BitLocker-enabled systems with TPM+PIN and that meet the hardware requirements to
boot into Windows without user intervention. Network Unlock works in a similar fashion to the TPM+StartupKey
at boot. Rather than needing to read the StartupKey from USB media, however, the key for Network Unlock is
composed from a key stored in the TPM and an encrypted network key that is sent to the server, decrypted and
returned to the client in a secure session.
This topic contains:
Network Unlock core requirements
Network Unlock sequence
Create the certificate template for Network Unlock
Turning off Network Unlock
Update Network Unlock certificates
Troubleshoot Network Unlock
Configure Network Unlock on unsupported systems
Network Unlock core requirements

Network Unlock must meet mandatory hardware and software requirements before the feature can
automatically unlock domain joined systems. These requirements include:
You must be running at least Windows 8 or Windows Server 2012.
Any supported operating system with UEFI DHCP drivers can be Network Unlock clients.
A server running the Windows Deployment Services (WDS) role on any supported server operating system.
BitLocker Network Unlock optional feature installed on any supported server operating system.
A DHCP server, separate from the WDS server.
Properly configured public/private key pairing.
Network Unlock Group Policy settings configured.
The network stack must be enabled to use the Network Unlock feature. Equipment manufacturers deliver their
products in various states and with different BIOS menus, so you need to confirm that the network stack has
been enabled in the BIOS before starting the computer.
Note: To properly support DHCP within UEFI, the UEFI-based system should be in native mode without a
compatibility support module (CSM) enabled.
For Network Unlock to work reliably on computers running Windows 8 and later, the first network adapter on
the computer, usually the onboard adapter, must be configured to support DHCP and used for Network Unlock.
This is especially worth noting when you have multiple adapters, and you wish to configure one without DHCP,
such as for a lights-out management protocol. This configuration is necessary because Network Unlock will stop
enumerating adapters when it reaches one with a DHCP port failure for any reason. Thus, if the first enumerated
adapter does not support DHCP, is not plugged into the network, or fails to report availability of the DHCP port
for any reason, then Network Unlock will fail.
The Network Unlock server component installs on supported versions of Windows Server 2012 and later as a
Windows feature using Server Manager or Windows PowerShell cmdlets. The feature name is BitLocker Network
Unlock in Server Manager and BitLocker-NetworkUnlock in Windows PowerShell. This feature is a core
requirement.
Network Unlock requires Windows Deployment Services (WDS) in the environment where the feature will be
utilized. Configuration of the WDS installation is not required; however, the WDS service needs to be running on
the server.
The network key is stored on the system drive along with an AES 256 session key, and encrypted with the 2048-
bit RSA public key of the unlock server's certificate. The network key is decrypted with the help of a provider on a
supported version of Windows Server running WDS, and returned encrypted with its corresponding session key.
Network Unlock sequence

The unlock sequence starts on the client side, when the Windows boot manager detects the existence of Network
Unlock protector. It leverages the DHCP driver in UEFI to obtain an IP address for IPv4 and then broadcasts a
vendor-specific DHCP request that contains the network key and a session key for the reply, all encrypted by the
server's Network Unlock certificate, as described above. The Network Unlock provider on the supported WDS
server recognizes the vendor-specific request, decrypts it with the RSA private key, and returns the network key
encrypted with the session key via its own vendor-specific DHCP reply.
On the server side, the WDS server role has an optional plugin component, like a PXE provider, which is what
handles the incoming Network Unlock requests. The provider can also be configured with subnet restrictions,
which would require that the IP address provided by the client in the Network Unlock request belong to a
permitted subnet in order to release the network key to the client. In instances where the Network Unlock
provider is unavailable, BitLocker fails over to the next available protector to unlock the drive. In a typical
configuration, this means the standard TPM+PIN unlock screen is presented to unlock the drive.
The server side configuration to enable Network Unlock also requires provisioning a 2048-bit RSA public/private
key pair in the form of an X.509 certificate, and for the public key certificate to be distributed to the clients. This
certificate must be managed and deployed through the Group Policy editor directly on a domain controller with
at least a Domain Functional Level of Windows Server 2012. This certificate is the public key that encrypts the
intermediate network key (which is one of the two secrets required to unlock the drive; the other secret is stored
in the TPM).
Phases in the Network Unlock process
1. The Windows boot manager detects that a Network Unlock protector exists in the BitLocker configuration.
2. The client computer uses its DHCP driver in the UEFI to obtain a valid IPv4 IP address.
3. The client computer broadcasts a vendor-specific DHCP request that contains the Network Key (a 256-bit
intermediate key) and an AES-256 session key for the reply. Both of these keys are encrypted using the 2048-
bit RSA Public Key of the Network Unlock certificate from the WDS server.
4. The Network Unlock provider on the WDS server recognizes the vendor-specific request.
5. The provider decrypts it with the WDS servers BitLocker Network Unlock certificate RSA private key.
6. The WDS provider then returns the network key encrypted with the session key using its own vendor-specific
DHCP reply to the client computer. This forms an intermediate key.
7. The returned intermediate key is then combined with another local 256-bit intermediate key that can only be
decrypted by the TPM.
8. This combined key is used to create an AES-256 key that unlocks the volume.
9. Windows continues the boot sequence.

The following steps allow an administrator to configure Network Unlock in a domain where the Domain
Functional Level is at least Windows Server 2012.
Step One: Install the WDS Server role
The BitLocker Network Unlock feature will install the WDS role if it is not already installed. If you want to install it
separately before you install BitLocker Network Unlock you can use Server Manager or Windows PowerShell. To
install the role using Server Manager, select the Windows Deployment Services role in Server Manager.
To install the role using Windows PowerShell, use the following command:
Install-WindowsFeature WDS-Deployment
You must configure the WDS server so that it can communicate with DHCP (and optionally Active Directory
Doman Services) and the client computer. You can do using the WDS management tool, wdsmgmt.msc, which
starts the Windows Deployment Services Configuration Wizard.
Step Two: Confirm the WDS Service is running
To confirm the WDS service is running, use the Services Management Console or Windows PowerShell. To
confirm the service is running in Services Management Console, open the console using services.msc and check
the status of the Windows Deployment Services service.
To confirm the service is running using Windows PowerShell, use the following command:
Get-Service WDSServer
Step Three: Install the Network Unlock feature

To install the Network Unlock feature, use Server Manager or Windows PowerShell. To install the feature using
Server Manager, select the BitLocker Network Unlock feature in the Server Manager console.
To install the feature using Windows PowerShell, use the following command:
Install-WindowsFeature BitLocker-NetworkUnlock
Step Four: Create the Network Unlock certificate

Network Unlock can use imported certificates from an existing PKI infrastructure, or you can use a self-signed
certificate.
To enroll a certificate from an existing certification authority (CA), do the following:
1. Open Certificate Manager on the WDS server using certmgr.msc
2. Under the Certificates - Current User item, right-click Personal
3. Select All Tasks, then Request New Certificate
4. Select Next when the Certificate Enrollment wizard opens
5. Select Active Directory Enrollment Policy
6. Choose the certificate template created for Network Unlock on the Domain controller and select Enroll.
When prompted for more information, add the following attribute to the certificate:
Select the Subject Name pane and provide a friendly name value. It is suggested that this friendly
name include information for the domain or organizational unit for the certificate. For example
"BitLocker Network Unlock Certificate for Contoso domain"
7. Create the certificate. Ensure the certificate appears in the Personal folder.
8. Export the public key certificate for Network Unlock
a. Create a .cer file by right-clicking the previously created certificate, choosing All Tasks, then Export.
b. Select No, do not export the private key.
c. Select DER encoded binary X.509 and complete exporting the certificate to a file.
d. Give the file a name such as BitLocker-NetworkUnlock.cer.
9. Export the public key with a private key for Network Unlock
a. Create a .pfx file by right-clicking the previously created certificate, choosing All Tasks, then Export.
b. Select Yes, export the private key.
c. Complete the wizard to create the .pfx file.
To create a self-signed certificate, you can either use the New-SelfSignedCertificate cmdlet in Windows
PowerShell or use Certreq.
Windows PowerShell example:
New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -Subject "CN=BitLocker Network Unlock
certificate" -Provider "Microsoft Software Key Storage Provider" -KeyUsage KeyEncipherment -KeyUsageProperty
Decrypt,Sign -KeyLength 2048 -HashAlgorithm sha512 -TextExtension @("1.3.6.1.4.1.311.21.10=
{text}OID=1.3.6.1.4.1.311.67.1.1","2.5.29.37={text}1.3.6.1.4.1.311.67.1.1")
Certreq example:
1. Create a text file with an .inf extension. For example, notepad.exe BitLocker-NetworkUnlock.inf.
2. Add the following contents to the previously created file:
[NewRequest]
Subject="CN=BitLocker Network Unlock certificate"
ProviderType=0
MachineKeySet=True
Exportable=true
RequestType=Cert
KeyUsage="CERT_KEY_ENCIPHERMENT_KEY_USAGE"
KeyUsageProperty="NCRYPT_ALLOW_DECRYPT_FLAG | NCRYPT_ALLOW_SIGNING_FLAG"
KeyLength=2048
SMIME=FALSE
HashAlgorithm=sha512
[Extensions]
1.3.6.1.4.1.311.21.10 = "{text}"
_continue_ = "OID=1.3.6.1.4.1.311.67.1.1"
2.5.29.37 = "{text}"
_continue_ = "1.3.6.1.4.1.311.67.1.1"
3. Open an elevated command prompt and use the certreq tool to create a new certificate using the
following command, specifying the full path to the file created previously, along with the file name:
certreq -new BitLocker-NetworkUnlock.inf BitLocker-NetworkUnlock.cer
4. Verify the previous command properly created the certificate by confirming the .cer file exists.
5. Launch Certificates - Local Machine by running certlm.msc.
6. Create a .pfx file by opening the Certificates Local Computer\Personal\Certificates path in the
navigation pane, right-clicking the previously imported certificate, selecting All Tasks, then Export. Follow
through the wizard to create the .pfx file.
Step Five: Deploy the private key and certificate to the WDS server
With the certificate and key created, deploy them to the infrastructure to properly unlock systems. To deploy the
certificates, do the following:
1. On the WDS server, open a new MMC and add the certificates snap-in. Select the computer account and local
computer when given the options.
2. Right-click the Certificates (Local Computer) - BitLocker Drive Encryption Network Unlock item, choose All
Tasks, then Import.
3. In the File to Import dialog, choose the .pfx file created previously.
4. Enter the password used to create the .pfx and complete the wizard.
Step Six: Configure Group Policy settings for Network Unlock
With certificate and key deployed to the WDS server for Network Unlock, the final step is to use Group Policy
settings to deploy the public key certificate to computers that you want to be able to unlock using the Network
Unlock key. Group Policy settings for BitLocker can be found under \Computer Configuration\Administrative
Templates\Windows Components\BitLocker Drive Encryption using the Local Group Policy Editor or the
Microsoft Management Console.
The following steps describe how to enable the Group Policy setting that is a requirement for configuring
Network Unlock.
1. Open Group Policy Management Console (gpmc.msc).
2. Enable the policy Require additional authentication at startup and select the Require startup PIN with
TPM option.
3. Turn on BitLocker with TPM+PIN protectors on all domain-joined computers.
The following steps describe how to deploy the required Group Policy setting:
Note: The Group Policy settings Allow network unlock at startup and Add Network Unlock Certificate
were introduced in Windows Server 2012.
1. Copy the .cer file created for Network Unlock to the domain controller.
2. On the domain controller, launch Group Policy Management Console (gpmc.msc).
3. Create a new Group Policy Object or modify an existing object to enable the Allow network unlock at
startup setting.
4. Deploy the public certificate to clients:
a. Within Group Policy Management Console, navigate to the following location: Computer
Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\BitLocker
Drive Encryption Network Unlock Certificate.
b. Right-click the folder and choose Add Network Unlock Certificate.
c. Follow the wizard steps and import the .cer file that was copied earlier.
Note: Only one network unlock certificate can be available at a time. If a new certificate is required, delete
the current certificate before deploying a new one. The Network Unlock certificate is located in the
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\SystemCertificates\FVE_NKP key on the client
computer.
Step Seven: Require TPM+PIN protectors at startup

An additional step is for enterprises to use TPM+PIN protectors for an extra level of security. To require
TPM+PIN protectors in an environment, do the following:
1. Open Group Policy Management Console (gpmc.msc).
2. Enable the policy Require additional authentication at startup and select the Require startup PIN with
TPM option.
3. Turn on BitLocker with TPM+PIN protectors on all domain-joined computers.
Create the certificate template for Network Unlock
The following steps detail how to create a certificate template for use with BitLocker Network Unlock. A properly
configured Active Directory Services Certification Authority can use this certificate to create and issue Network
Unlock certificates.
1. Open the Certificates Template snap-in (certtmpl.msc).
2. Locate the User template. Right-click the template name and select Duplicate Template.
3. On the Compatibility tab, change the Certification Authority and Certificate recipient fields to Windows
Server 2012 and Windows 8 respectively. Ensure the Show resulting changes dialog box is selected.
4. Select the General tab of the template. The Template display name and Template name should clearly
identify that the template will be used for Network Unlock. Clear the checkbox for the Publish certificate in
Active Directory option.
5. Select the Request Handling tab. Select Encryption from the Purpose drop down menu. Ensure the Allow
private key to be exported option is selected.
6. Select the Cryptography tab. Set the Minimum key size to 2048. (Any Microsoft cryptographic provider
that supports RSA can be used for this template, but for simplicity and forward compatibility we recommend
using the Microsoft Software Key Storage Provider.)
7. Select the Requests must use one of the following providers option and clear all options except for the
cryptography provider you selected, such as the Microsoft Software Key Storage Provider.
8. Select the Subject Name tab. Select Supply in the request. Select OK if the certificate templates pop-up
dialog appears.
9. Select the Issuance Requirements tab. Select both CA certificate manager approval and Valid existing
certificate options.
10. Select the Extensions tab. Select Application Policies and choose Edit.
11. In the Edit Application Policies Extension options dialog box, select Client Authentication, Encrypting
File System, and Secure Email and choose Remove.
12. On the Edit Application Policies Extension dialog box, select Add.
13. On the Add Application Policy dialog box, select New. In the New Application Policy dialog box enter
the following information in the space provided and then click OK to create the BitLocker Network Unlock
application policy:
Name: BitLocker Network Unlock
Object Identifier: 1.3.6.1.4.1.311.67.1.1
14. Select the newly created BitLocker Network Unlock application policy and select OK.
15. With the Extensions tab still open, select the Edit Key Usage Extension dialog, select the Allow key
exchange only with key encryption (key encipherment) option. Select the Make this extension critical
option.
16. Select the Security tab. Confirm that the Domain Admins group has been granted Enroll permission.
17. Select OK to complete configuration of the template.
To add the Network Unlock template to the Certification Authority, open the Certification Authority snap-in
(certsrv.msc). Right-click the Certificate Templates item and choose New, Certificate Template to issue.
Select the previously created BitLocker Network Unlock certificate.
After adding the Network Unlock template to the Certification Authority, this certificate can be used to configure
BitLocker Network Unlock.
Subnet policy configuration files on WDS Server (Optional)
By default, all clients with the correct Network Unlock Certificate and valid Network Unlock protectors that have
wired access to a Network Unlock-enabled WDS server via DHCP are unlocked by the server. A subnet policy
configuration file on the WDS server can be created to limit which subnet(s) Network Unlock clients can use to
unlock.
The configuration file, called bde-network-unlock.ini, must be located in the same directory as the Network
Unlock provider DLL and it applies to both IPv6 and IPv4 DHCP implementations. If the subnet configuration
policy becomes corrupted, the provider will fail and stop responding to requests.
The subnet policy configuration file must use a [SUBNETS] section to identify the specific subnets. The named
subnets may then be used to specify restrictions in certificate subsections. Subnets are defined as simple name-
value pairs, in the common INI format, where each subnet has its own line, with the name on the left of the
equals sign, and the subnet identified on the right of the equal sign as a Classless Inter-Domain Routing (CIDR)
address or range. The key word ENABLED is disallowed for subnet names.
[SUBNETS]
SUBNET1=10.185.250.0/24 ; comment about this subrange could be here, after the semi-colon
SUBNET2=10.185.252.200/28
SUBNET3= 2001:4898:a:2::/64 ; an IPv6 subnet
SUBNET4=2001:4898:a:3::/64; in production, the admin would likely give more useful names, like BUILDING9-
EXCEPT-RECEP.
```
Following the \[SUBNETS\] section, there can be sections for each Network Unlock certificate, identified by
the certificate thumbprint formatted without any spaces, which define subnets clients can be unlocked from
with that certificate.
>**Note:** When specifying the certificate thumbprint, do not include any spaces. If spaces are included in
the thumbprint the subnet configuration will fail because the thumbprint will not be recognized as valid.
Subnet restrictions are defined within each certificate section by denoting the allowed list of permitted
subnets. If any subnet is listed in a certificate section, then only those subnets listed are permitted for
that certificate. If no subnet is listed in a certificate section, then all subnets are permitted for that
certificate. If a certificate does not have a section in the subnet policy configuration file, then no
subnet restrictions are applied for unlocking with that certificate. This means for restrictions to apply to
every certificate, there must be a certificate section for every Network Unlock certificate on the server,
and an explicit allowed list set for each certificate section.
Subnet lists are created by putting the name of a subnet from the \[SUBNETS\] section on its own line below
the certificate section header. Then, the server will only unlock clients with this certificate on the
subnet(s) specified as in the list. For troubleshooting, a subnet can be quickly excluded without deleting
it from the section by simply commenting it out with a prepended semi-colon.
[2158a767e1c14e88e27a4c0aee111d2de2eafe60]
;Comments could be added here to indicate when the cert was issued, which Group Policy should get it, and so
on.
;This list shows this cert is only allowed to unlock clients on SUBNET1 and SUBNET3 subnets. In this
example, SUBNET2 is commented out.
SUBNET1
;SUBNET2
SUBNET3
To disallow the use of a certificate altogether, its subnet list may contain the line DISABLED".
Turning off Network Unlock
To turn off the unlock server, the PXE provider can be unregistered from the WDS server or uninstalled
altogether. However, to stop clients from creating Network Unlock protectors the Allow Network Unlock at
startup Group Policy setting should be disabled. When this policy setting is updated to disabled on client
computers any Network Unlock key protectors on the computer will be deleted. Alternatively, the BitLocker
Network Unlock certificate policy can be deleted on the domain controller to accomplish the same task for an
entire domain.
Note: Removing the FVENKP certificate store that contains the Network Unlock certificate and key on the
WDS server will also effectively disable the servers ability to respond to unlock requests for that certificate.
However, this is seen as an error condition and is not a supported or recommended method for turning off
the Network Unlock server.
Update Network Unlock certificates

To update the certificates used by Network Unlock, administrators need to import or generate the new certificate
for the server and then update the Network Unlock certificate Group Policy setting on the domain controller.
Troubleshoot Network Unlock

Troubleshooting Network Unlock issues begins by verifying the environment. Many times, a small configuration
issue will be the root cause of the failure. Items to verify include:
Verify client hardware is UEFI-based and is on firmware version is 2.3.1 and that the UEFI firmware is in native
mode without a Compatibility Support Module (CSM) for BIOS mode enabled. Do this by checking that the
firmware does not have an option enabled such as "Legacy mode" or "Compatibility mode" or that the
firmware does not appear to be in a BIOS-like mode.
All required roles and services are installed and started
Public and private certificates have been published and are in the proper certificate containers. The presence
of the Network Unlock certificate can be verified in the Microsoft Management Console (MMC.exe) on the
WDS server with the certificate snap-ins for the local computer enabled. The client certificate can be verified
by checking the registry key
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\SystemCertificates\FVE_NKP on the client
computer.
Group policy for Network Unlock is enabled and linked to the appropriate domains
Verify group policy is reaching the clients properly. This can be done using the GPRESULT.exe or RSOP.msc
utilities.
Verify the Network (Certificate Based) protector is listed on the client. This can be done using either
manage-bde or Windows PowerShell cmdlets. For example the following command will list the key
protectors currently configured on the C: drive of the lcoal computer:
Manage-bde protectors get C:
Note: Use the output of manage-bde along with the WDS debug log to determine if the proper
certificate thumbprint is being used for Network Unlock
Files to gather when troubleshooting BitLocker Network Unlock include:

1. The Windows event logs. Specifically the BitLocker event logs and the Microsoft-Windows-Deployment-
Services-Diagnostics-Debug log
Debug logging is turned off by default for the WDS server role, so you will need to enable it first. You can
use either of the following two methods to turn on WDS debug logging.
a. Start an elevated command prompt and run the following command:
wevtutil sl Microsoft-Windows-Deployment-Services-Diagnostics/Debug /e:true
b. Open Event Viewer on the WDS server.

In the left pane, click Applications and Services Logs, click Microsoft, click Windows, click
Deployment-Services-Diagnostics, and then click Debug.
In the right pane, click Enable Log.
2. The DHCP subnet configuration file (if one exists).
3. The output of the BitLocker status on the volume, this can be gathered into a text file using manage-bde -
status or Get-BitLockerVolume in Windows PowerShell.
4. Network Monitor capture on the server hosting the WDS role, filtered by client IP address.
Configure Network Unlock Group Policy settings on earlier versions

Network Unlock and the accompanying Group Policy settings were introduced in Windows Server 2012 but can
be deployed using operating systems running Windows Server 2008 R2 and Windows Server 2008.
Requirements
The server hosting WDS must be running any of the server operating systems designated in the Applies To
list at the beginning of this topic.
Client computers must be running any of the client operating systems designated in the Applies To list at the
beginning of this topic.
The following steps can be used to configure Network Unlock on these older systems.
1. Step One: Install the WDS Server role
2. Step Two: Confirm the WDS Service is running
3. Step Three: Install the Network Unlock feature
4. Step Four: Create the Network Unlock certificate
5. Step Five: Deploy the private key and certificate to the WDS server
6. Step Six: Configure registry settings for Network Unlock
Apply the registry settings by running the following certutil script on each computer running any of the
client operating systems designated in the Applies To list at the beginning of this topic. certutil -f -
grouppolicy -addstore FVE_NKP BitLocker-NetworkUnlock.cer reg add
"HKLM\SOFTWARE\Policies\Microsoft\FVE" /v OSManageNKP /t REG_DWORD /d 1 /f reg add
"HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseAdvancedStartup /t REG_DWORD /d 1 /f reg add
"HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UsePIN /t REG_DWORD /d 2 /f reg add
"HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPMPIN /t REG_DWORD /d 2 /f reg add
"HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPM /t REG_DWORD /d 2 /f reg add
"HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPMKey /t REG_DWORD /d 2 /f reg add
"HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPMKeyPIN /t REG_DWORD /d 2 /f
7. Create the Network Unlock certificate
8. Deploy the private key and certificate to the WDS server
9. Create the certificate template for Network Unlock
10. Require TPM+PIN protectors at startup
See also
BitLocker overview
BitLocker: Use BitLocker Drive Encryption Tools to
manage BitLocker
Applies to
Windows 10
This topic for the IT professional describes how to use tools to manage BitLocker.
BitLocker Drive Encryption Tools include the command line tools manage-bde and repair-bde and the BitLocker
cmdlets for Windows PowerShell.
Both manage-bde and the BitLocker cmdlets can be used to perform any task that can be accomplished through
the BitLocker control panel and are appropriate to use for automated deployments and other scripting scenarios.
Repair-bde is a special circumstance tool that is provided for disaster recovery scenarios in which a BitLocker
protected drive cannot be unlocked normally or using the recovery console.
1. Manage-bde
2. Repair-bde
3. BitLocker cmdlets for Windows PowerShell
Manage-bde
Manage-bde is a command-line tool that can be used for scripting BitLocker operations. Manage-bde offers
additional options not displayed in the BitLocker control panel. For a complete list of the manage-bde options, see
the Manage-bde command-line reference.
Manage-bde includes less default settings and requires greater customization for configuring BitLocker. For
example, using just the manage-bde -on command on a data volume will fully encrypt the volume without any
authenticating protectors. A volume encrypted in this manner still requires user interaction to turn on BitLocker
protection, even though the command successfully completed because an authentication method needs to be
added to the volume for it to be fully protected. The following sections provide examples of common usage
scenarios for manage-bde.
Using manage -bde with operating system volumes
Listed below are examples of basic valid commands for operating system volumes. In general, using only the
manage-bde -on <drive letter> command will encrypt the operating system volume with a TPM-only protector
and no recovery key. However, many environments require more secure protectors such as passwords or PIN and
expect to be able to recover information with a recovery key. It is recommended that at least one primary protector
and a recovery protector be added to an operating system volume.
A good practice when using manage-bde is to determine the volume status on the target system. Use the
following command to determine volume status:
manage-bde -status
This command returns the volumes on the target, current encryption status and volume type (operating system or
data) for each volume.
The following example illustrates enabling BitLocker on a computer without a TPM chip. Before beginning the
encryption process you must create the startup key needed for BitLocker and save it to the USB drive. When
BitLocker is enabled for the operating system volume, the BitLocker will need to access the USB flash drive to
obtain the encryption key (in this example, the drive letter E represents the USB drive). You will be prompted to
reboot to complete the encryption process.
manage-bde protectors -add C: -startupkey E:

manage-bde -on C:
Note: After the encryption is completed, the USB startup key must be inserted before the operating system
can be started.
An alternative to the startup key protector on non-TPM hardware is to use a password and an
ADaccountorgroup protector to protect the operating system volume. In this scenario, you would add the
protectors first. This is done with the command:
manage-bde -protectors -add C: -pw -sid <user or group>
This command will require you to enter and then confirm the password protector before adding them to the
volume. With the protectors enabled on the volume, you can then turn BitLocker on.
On computers with a TPM it is possible to encrypt the operating system volume without any defined protectors
using manage-bde. The command to do this is:
manage-bde -on C:
This will encrypt the drive using the TPM as the default protector. If you are not sure if a TPM protector is available,
to list the protectors available for a volume, run the following command:
manage-bde -protectors -get <volume>
Using manage -bde with data volumes

Data volumes use the same syntax for encryption as operating system volumes but they do not require protectors
for the operation to complete. Encrypting data volumes can be done using the base command:
manage-bde -on <drive letter> or you can choose to add additional protectors to the volume first. It is
recommended that at least one primary protector and a recovery protector be added to a data volume.
A common protector for a data volume is the password protector. In the example below, we add a password
protector to the volume and turn BitLocker on.
manage-bde -protectors -add -pw C:

manage-bde -on C:
Repair-bde
You may experience a problem that damages an area of a hard disk on which BitLocker stores critical information.
This kind of problem may be caused by a hard disk failure or if Windows exits unexpectedly.
The BitLocker Repair Tool (Repair-bde) can be used to access encrypted data on a severely damaged hard disk if
the drive was encrypted by using BitLocker. Repair-bde can reconstruct critical parts of the drive and salvage
recoverable data as long as a valid recovery password or recovery key is used to decrypt the data. If the BitLocker
metadata data on the drive has become corrupt, you must be able to supply a backup key package in addition to
the recovery password or recovery key. This key package is backed up in Active Directory Domain Services (AD DS)
if you used the default setting for AD DS backup. With this key package and either the recovery password or
recovery key, you can decrypt portions of a BitLocker-protected drive if the disk is corrupted. Each key package will
work only for a drive that has the corresponding drive identifier. You can use the BitLocker Recovery Password
Viewer to obtain this key package from AD DS.
Tip: If you are not backing up recovery information to AD DS or if you want to save key packages alternatively,
you can use the command manage-bde -KeyPackage to generate a key package for a volume.
The Repair-bde command-line tool is intended for use when the operating system does not start or when you
cannot start the BitLocker Recovery Console. You should use Repair-bde if the following conditions are true:
1. You have encrypted the drive by using BitLocker Drive Encryption.
2. Windows does not start, or you cannot start the BitLocker recovery console.
3. You do not have a copy of the data that is contained on the encrypted drive.
Note: Damage to the drive may not be related to BitLocker. Therefore, we recommend that you try other tools
to help diagnose and resolve the problem with the drive before you use the BitLocker Repair Tool. The
Windows Recovery Environment (Windows RE) provides additional options to repair computers.
The following limitations exist for Repair-bde:

The Repair-bde command-line tool cannot repair a drive that failed during the encryption or decryption
process.
The Repair-bde command-line tool assumes that if the drive has any encryption, then the drive has been fully
encrypted.
For more information about using repair-bde, see Repair-bde.
BitLocker cmdlets for Windows PowerShell

Windows PowerShell cmdlets provide a new way for administrators to use when working with BitLocker. Using
Windows PowerShell's scripting capabilities, administrators can integrate BitLocker options into existing scripts
with ease. The list below displays the available BitLocker cmdlets.
Name Parameters
Add-BitLockerKeyProtector -ADAccountOrGroup
-ADAccountOrGroupProtector
-Confirm
-MountPoint
-Password
-PasswordProtector
-Pin
-RecoveryKeyPath
-RecoveryPassword
-Service
-StartupKeyPath
-TpmAndPinProtector
-TpmProtector
-WhatIf
Backup-BitLockerKeyProtector -Confirm
-KeyProtectorId
-MountPoint
-WhatIf
Disable-BitLocker -Confirm
-MountPoint
-WhatIf
Disable-BitLockerAutoUnlock -Confirm
-MountPoint
-WhatIf
Enable-BitLocker -AdAccountOrGroup
-AdAccountOrGroupProtector
-Confirm
-EncryptionMethod
-HardwareEncryption
-Password
-PasswordProtector
-Pin
-RecoveryKeyPath
-RecoveryPassword
-Service
-SkipHardwareTest
-StartupKeyPath
-TpmAndPinProtector
-TpmProtector
-UsedSpaceOnly
-WhatIf
Enable-BitLockerAutoUnlock -Confirm
-MountPoint
-WhatIf
Get-BitLockerVolume -MountPoint
Lock-BitLocker -Confirm
-ForceDismount
-MountPoint
-WhatIf
Remove-BitLockerKeyProtector -Confirm
-KeyProtectorId
-MountPoint
-WhatIf
Resume-BitLocker -Confirm
-MountPoint
-WhatIf
Suspend-BitLocker -Confirm
-MountPoint
-RebootCount
-WhatIf
Unlock-BitLocker -AdAccountOrGroup
-Confirm
-MountPoint
-Password
-RecoveryKeyPath
-RecoveryPassword
-RecoveryPassword
-WhatIf
Similar to manage-bde, the Windows PowerShell cmdlets allow configuration beyond the options offered in the
control panel. As with manage-bde, users need to consider the specific needs of the volume they are encrypting
prior to running Windows PowerShell cmdlets. A good initial step is to determine the current state of the
volume(s) on the computer. You can do this using the Get-BitLockerVolume cmdlet. The Get-BitLockerVolume
cmdlet output gives information on the volume type, protectors, protection status and other details.
Tip: Occasionally, all protectors may not be shown when using Get-BitLockerVolume due to lack of space in the
output display. If you do not see all of the protectors for a volume, you can use the Windows PowerShell pipe
command (|) to format a full listing of the protectors. Get-BitLockerVolume C: | fl
If you want to remove the existing protectors prior to provisioning BitLocker on the volume, you could use the
Remove-BitLockerKeyProtector cmdlet. Accomplishing this requires the GUID associated with the protector to be
removed.
A simple script can pipe the values of each Get-BitLockerVolume return out to another variable as seen below:
$vol = Get-BitLockerVolume
$keyprotectors = $vol.KeyProtector
Using this, you can display the information in the $keyprotectors variable to determine the GUID for each
protector.
Using this information, you can then remove the key protector for a specific volume using the command:
Remove-BitLockerKeyProtector <volume>: -KeyProtectorID "{GUID}"
Note: The BitLocker cmdlet requires the key protector GUID enclosed in quotation marks to execute. Ensure
the entire GUID, with braces, is included in the command.
Using the BitLocker Windows PowerShell cmdlets with operating system volumes
Using the BitLocker Windows PowerShell cmdlets is similar to working with the manage-bde tool for encrypting
operating system volumes. Windows PowerShell offers users a lot of flexibility. For example, users can add the
desired protector as part command for encrypting the volume. Below are examples of common user scenarios and
steps to accomplish them in BitLocker Windows PowerShell.
The following example shows how to enable BitLocker on an operating system drive using only the TPM protector:
Enable-BitLocker C:
In the example below, adds one additional protector, the StartupKey protector and chooses to skip the BitLocker
hardware test. In this example, encryption starts immediately without the need for a reboot.
Enable-BitLocker C: -StartupKeyProtector -StartupKeyPath <path> -SkipHardwareTest
Using the BitLocker Windows PowerShell cmdlets with data volumes

Data volume encryption using Windows PowerShell is the same as for operating system volumes. You should add
the desired protectors prior to encrypting the volume. The following example adds a password protector to the E:
volume using the variable $pw as the password. The $pw variable is held as a SecureString value to store the user
defined password.
$pw = Read-Host -AsSecureString

<user inputs password>
Enable-BitLockerKeyProtector E: -PasswordProtector -Password $pw
Using an AD Account or Group protector in Windows PowerShell

The ADAccountOrGroup protector, introduced in Windows 8 and Windows Server 2012, is an Active Directory
SID-based protector. This protector can be added to both operating system and data volumes, although it does not
unlock operating system volumes in the pre-boot environment. The protector requires the SID for the domain
account or group to link with the protector. BitLocker can protect a cluster-aware disk by adding a SID-based
protector for the Cluster Name Object (CNO) that lets the disk properly failover to and be unlocked by any
member computer of the cluster.
Warning: The ADAccountOrGroup protector requires the use of an additional protector for use (such as
TPM, PIN, or recovery key) when used on operating system volumes
To add an ADAccountOrGroup protector to a volume requires either the actual domain SID or the group name
preceded by the domain and a backslash. In the example below, the CONTOSO\Administrator account is added as
a protector to the data volume G.
Enable-BitLocker G: -AdAccountOrGroupProtector -AdAccountOrGroup CONTOSO\Administrator
For users who wish to use the SID for the account or group, the first step is to determine the SID associated with
the account. To get the specific SID for a user account in Windows PowerShell, use the following command:
Note: Use of this command requires the RSAT-AD-PowerShell feature.
get-aduser -filter {samaccountname -eq "administrator"}

Tip: In addition to the PowerShell command above, information about the locally logged on user and group
membership can be found using: WHOAMI /ALL. This does not require the use of additional features.
The following example adds an ADAccountOrGroup protector to the previously encrypted operating system
volume using the SID of the account:
Add-BitLockerKeyProtector C: -ADAccountOrGroupProtector -ADAccountOrGroup S-1-5-21-3651336348-8937238915-

291003330-500
Note: Active Directory-based protectors are normally used to unlock Failover Cluster enabled volumes.
More information
BitLocker overview
Applies to
Windows 10
This topic for the IT professional describes how to use the BitLocker Recovery Password Viewer.
The BitLocker Recovery Password Viewer tool is an optional tool included with the Remote Server Administration
Tools (RSAT). It lets you locate and view BitLocker recovery passwords that are stored in Active Directory Domain
Services (AD DS). You can use this tool to help recover data that is stored on a drive that has been encrypted by
using BitLocker. The BitLocker Active Directory Recovery Password Viewer tool is an extension for the Active
Directory Users and Computers Microsoft Management Console (MMC) snap-in. Using this tool, you can examine
a computer object's Properties dialog box to view the corresponding BitLocker recovery passwords. Additionally,
you can right-click a domain container and then search for a BitLocker recovery password across all the domains in
the Active Directory forest. You can also search for a password by password identifier (ID).
Before you start

To complete the procedures in this scenario:
You must have domain administrator credentials.
Your test computers must be joined to the domain.
On the test computers, BitLocker must have been turned on after joining the domain.
The following procedures describe the most common tasks performed by using the BitLocker Recovery Password
Viewer.
To view the recovery passwords for a computer
1. In Active Directory Users and Computers, locate and then click the container in which the computer is
located.
2. Right-click the computer object, and then click Properties.
3. In the Properties dialog box, click the BitLocker Recovery tab to view the BitLocker recovery passwords that
are associated with the computer.
To copy the recovery passwords for a computer
1. Follow the steps in the previous procedure to view the BitLocker recovery passwords.
2. On the BitLocker Recovery tab of the Properties dialog box, right-click the BitLocker recovery password that
you want to copy, and then click Copy Details.
3. Press CTRL+V to paste the copied text to a destination location, such as a text file or spreadsheet.
To locate a recovery password by using a password ID
1. In Active Directory Users and Computers, right-click the domain container, and then click Find BitLocker
Recovery Password.
2. In the Find BitLocker Recovery Password dialog box, type the first eight characters of the recovery password
in the Password ID (first 8 characters) box, and then click Search. By completing the procedures in this
scenario, you have viewed and copied the recovery passwords for a computer and used a password ID to locate
a recovery password.
More information
BitLocker Overview
Applies to
Windows 10
This topic for IT professionals describes the function, location, and effect of each Group Policy setting that is used
to manage BitLocker Drive Encryption.
To control what drive encryption tasks the user can perform from the Windows Control Panel or to modify other
configuration options, you can use Group Policy administrative templates or local computer policy settings. How
you configure these policy settings depends on how you implement BitLocker and what level of user interaction
will be allowed.
Note: A separate set of Group Policy settings supports the use of the Trusted Platform Module (TPM). For
details about those settings, see Trusted Platform Module Group Policy settings.
BitLocker Group Policy settings can be accessed using the Local Group Policy Editor and the Group Policy
Management Console (GPMC) under Computer Configuration\Administrative Templates\Windows
Components\BitLocker Drive Encryption. Most of the BitLocker Group Policy settings are applied when
BitLocker is initially turned on for a drive. If a computer is not compliant with existing Group Policy settings,
BitLocker may not be turned on or modified until the computer is in a compliant state. When a drive is out of
compliance with Group Policy settings (for example, if a Group Policy setting was changed after the initial
BitLocker deployment in your organization, and then the setting was applied to previously encrypted drives), no
change can be made to the BitLocker configuration of that drive except a change that will bring it into
compliance.
If multiple changes are necessary to bring the drive into compliance, you must suspend BitLocker protection,
make the necessary changes, and then resume protection. This situation could occur, for example, if a removable
drive was initially configured to be unlocked with a password and then Group Policy settings are changed to
disallow passwords and require smart cards. In this situation, you need to suspend BitLocker protection by using
the Manage-bde command-line tool, delete the password unlock method, and add the smart card method. After
this is complete, BitLocker is compliant with the Group Policy setting and BitLocker protection on the drive can be
resumed.

The following sections provide a comprehensive list of BitLocker Group Policy settings that are organized by
usage. BitLocker Group Policy settings include settings for specific drive types (operating system drives, fixed
data drives, and removable data drives) and settings that are applied to all drives.
The following policy settings can be used to determine how a BitLocker-protected drive can be unlocked.
Allow devices with Secure Boot and protected DMA ports to opt out of preboot PIN
Allow network unlock at startup
Require additional authentication at startup
Allow enhanced PINs for startup
Configure minimum PIN length for startup
Disable new DMA devices when this computer is locked
Disallow standard users from changing the PIN or password
Configure use of passwords for operating system drives
Require additional authentication at startup (Windows Server 2008 and Windows Vista)
Configure use of smart cards on fixed data drives
Configure use of passwords on fixed data drives
Configure use of smart cards on removable data drives
Configure use of passwords on removable data drives
Validate smart card certificate usage rule compliance
Enable use of BitLocker authentication requiring preboot keyboard input on slates
The following policy settings are used to control how users can access drives and how they can use BitLocker on
their computers.
Deny write access to fixed drives not protected by BitLocker
Deny write access to removable drives not protected by BitLocker
Control use of BitLocker on removable drives
The following policy settings determine the encryption methods and encryption types that are used with
BitLocker.
Choose drive encryption method and cipher strength
Configure use of hardware-based encryption for fixed data drives
Configure use of hardware-based encryption for operating system drives
Configure use of hardware-based encryption for removable data drives
Enforce drive encryption type on fixed data drives
Enforce drive encryption type on operating system drives
Enforce drive encryption type on removable data drives
The following policy settings define the recovery methods that can be used to restore access to a BitLocker-
protected drive if an authentication method fails or is unable to be used.
Choose how BitLocker-protected operating system drives can be recovered
Choose how users can recover BitLocker-protected drives (Windows Server 2008 and Windows Vista)
Store BitLocker recovery information in Active Directory Domain Services (Windows Server 2008 and
Windows Vista)
Choose default folder for recovery password
Choose how BitLocker-protected fixed drives can be recovered
Choose how BitLocker-protected removable drives can be recovered
Configure the pre-boot recovery message and URL
The following policies are used to support customized deployment scenarios in your organization.
Allow Secure Boot for integrity validation
Provide the unique identifiers for your organization
Prevent memory overwrite on restart
Configure TPM platform validation profile for BIOS-based firmware configurations
Configure TPM platform validation profile (Windows Vista, Windows Server 2008, Windows 7, Windows
Server 2008 R2)
Configure TPM platform validation profile for native UEFI firmware configurations
Reset platform validation data after BitLocker recovery
Use enhanced Boot Configuration Data validation profile
Allow access to BitLocker-protected fixed data drives from earlier versions of Windows
Allow access to BitLocker-protected removable data drives from earlier versions of Windows
Allow devices with Secure Boot and protected DMA ports to opt out of preboot PIN
This policy setting allows users on devices that are compliant with InstantGo or the Microsoft Hardware Security
Test Interface (HSTI) to not have a PIN for preboot authentication.
Policy description With this policy setting, you can allow TPM-only
protection for newer, more secure devices, such as
devices that support InstantGo or HSTI, while requiring
PIN on older devices.
Introduced Windows 10, version 1703
Drive type Operating system drives
Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives
Conflicts This setting overrides the Require startup PIN with

TPM option of the Require additional authentication at
startup policy on compliant hardware.
When enabled Users on InstantGo and HSTI compliant devices will have
the choice to turn on BitLocker without preboot
authentication.
When disabled or not configured The options of the Require additional authentication at
startup policy apply.
Reference
The preboot authentication option Require startup PIN with TPM of the Require additional authentication at
startup policy is often enabled to help ensure security for older devices that do not support InstantGo. But
visually impaired users have no audible way to know when to enter a PIN. This setting enables an exception to
the PIN-required policy on secure hardware.
Allow network unlock at startup
This policy controls a portion of the behavior of the Network Unlock feature in BitLocker. This policy is required
to enable BitLocker Network Unlock on a network because it allows clients running BitLocker to create the
necessary network key protector during encryption. This policy is used in addition to the BitLocker Drive
Encryption Network Unlock Certificate security policy (located in the Public Key Policies folder of Local
Computer Policy) to allow systems that are connected to a trusted network to properly utilize the Network
Unlock feature.
Policy description With this policy setting, you can control whether a
BitLocker-protected computer that is connected to a
trusted local area network and joined to a domain can
create and use network key protectors on TPM-enabled
computers to automatically unlock the operating system
drive when the computer is started.
Introduced Windows Server 2012 and Windows 8

Conflicts None
When enabled Clients configured with a BitLocker Network Unlock

certificate can create and use Network Key Protectors.
When disabled or not configured Clients cannot create and use Network Key Protectors
Reference
To use a network key protector to unlock the computer, the computer and the server that hosts BitLocker Drive
Encryption Network Unlock must be provisioned with a Network Unlock certificate. The Network Unlock
certificate is used to create a network key protector and to protect the information exchange with the server to
unlock the computer. You can use the Group Policy setting Computer Configuration\Windows
Settings\Security Settings\Public Key Policies\BitLocker Drive Encryption Network Unlock Certificate
on the domain controller to distribute this certificate to computers in your organization. This unlock method uses
the TPM on the computer, so computers that do not have a TPM cannot create network key protectors to
automatically unlock by using Network Unlock.
Note: For reliability and security, computers should also have a TPM startup PIN that can be used when the
computer is disconnected from the wired network or cannot connect to the domain controller at startup.
For more information about Network Unlock, see BitLocker: How to enable Network Unlock.
Require additional authentication at startup
This policy setting is used to control which unlock options are available for operating system drives.
Policy description With this policy setting, you can configure whether
BitLocker requires additional authentication each time
the computer starts and whether you are using BitLocker
with a Trusted Platform Module (TPM). This policy
setting is applied when you turn on BitLocker.
Introduced Windows Server 2008 R2 and Windows 7


Conflicts If one authentication method is required, the other

methods cannot be allowed.
Use of BitLocker with a TPM startup key or with a TPM
startup key and a PIN must be disallowed if the Deny
write access to removable drives not protected by
BitLocker policy setting is enabled.
When enabled Users can configure advanced startup options in the

BitLocker Setup Wizard.
When disabled or not configured Users can configure only basic options on computers
with a TPM.
Only one of the additional authentication options can be
required at startup; otherwise, a policy error occurs.
Reference
If you want to use BitLocker on a computer without a TPM, select the Allow BitLocker without a compatible
TPM check box. In this mode, a USB drive is required for startup. Key information that is used to encrypt the
drive is stored on the USB drive, which creates a USB key. When the USB key is inserted, access to the drive is
authenticated and the drive is accessible. If the USB key is lost or unavailable, you need to use one of the
BitLocker recovery options to access the drive.
On a computer with a compatible TPM, four types of authentication methods can be used at startup to provide
added protection for encrypted data. When the computer starts, it can use:
only the TPM for authentication
insertion of a USB flash drive containing the startup key
the entry of a 6-digit to 20-digit personal identification number (PIN)
a combination of the PIN and the USB flash drive
There are four options for TPM-enabled computers or devices:
Configure TPM startup
Allow TPM
Require TPM
Do not allow TPM
Configure TPM startup PIN
Allow startup PIN with TPM
Require startup PIN with TPM
Do not allow startup PIN with TPM
Configure TPM startup key
Allow startup key with TPM
Require startup key with TPM
Do not allow startup key with TPM
Configure TPM startup key and PIN
Allow TPM startup key with PIN
Require startup key and PIN with TPM
Do not allow TPM startup key with PIN
Allow enhanced PINs for startup
This policy setting permits the use of enhanced PINs when you use an unlock method that includes a PIN.
enhanced startup PINs are used with BitLocker.

Conflicts None
When enabled All new BitLocker startup PINs that are set will be
enhanced PINs. Existing drives that were protected by
using standard startup PINs are not affected.
When disabled or not configured Enhanced PINs will not be used.
Reference
Enhanced startup PINs permit the use of characters (including uppercase and lowercase letters, symbols,
numbers, and spaces). This policy setting is applied when you turn on BitLocker.
Important: Not all computers support enhanced PIN characters in the preboot environment. It is strongly
recommended that users perform a system check during the BitLocker setup to verify that enhanced PIN
characters can be used.
Configure minimum PIN length for startup

This policy setting is used to set a minimum PIN length when you use an unlock method that includes a PIN.
Policy description With this policy setting, you can configure a minimum
length for a TPM startup PIN. This policy setting is
applied when you turn on BitLocker. The startup PIN
must have a minimum length of 6 digits, and it can have
a maximum length of 20 digits.

Conflicts None
When enabled You can require that users enter a minimum number of
digits to when setting their startup PINs.
When disabled or not configured Users can configure a startup PIN of any length between
6 and 20 digits.
Reference
This policy setting is applied when you turn on BitLocker. The startup PIN must have a minimum length of 6
digits and can have a maximum length of 20 digits.
Disable new DMA devices when this computer is locked
This policy setting allows you to block direct memory access (DMA) for all hot pluggable PCI ports until a user
signs in to Windows.
Policy description This setting helps prevent attacks that use external PCI-
based devices to access BitLocker keys.
Introduced Windows 10, version 1703
Policy path Computer Configuration\Administrative Templates\Windows

Components\BitLocker Drive Encryption\Operating System
Drives
Conflicts None
When enabled Every time the user locks the screen, DMA will be blocked on
hot pluggable PCI ports until the user signs in again.
When disabled or not configured DMA is available on hot pluggable PCI devices if the device is
turned on, regardless of whether a user is signed in.
Reference
This policy setting is only enforced when BitLocker or device encyption is enabled.
Disallow standard users from changing the PIN or password
This policy setting allows you to configure whether standard users are allowed to change the PIN or password
that is used to protect the operating system drive.
standard users are allowed to change the PIN or
password used to protect the operating system drive.

Conflicts None
When enabled Standard users are not allowed to change BitLocker PINs
or passwords.
When disabled or not configured Standard users are permitted to change BitLocker PINs
or passwords.
Reference
To change the PIN or password, the user must be able to provide the current PIN or password. This policy setting
is applied when you turn on BitLocker.
This policy controls how non-TPM based systems utilize the password protector. Used in conjunction with the
Password must meet complexity requirements policy, this policy allows administrators to require password
length and complexity for using the password protector. By default, passwords must be eight characters in
length. Complexity configuration options determine how important domain connectivity is for the client. For the
strongest password security, administrators should choose Require password complexity because it requires
domain connectivity, and it requires that the BitLocker password meets the same password complexity
requirements as domain sign-in passwords.
Policy description With this policy setting, you can specify the constraints
for passwords that are used to unlock operating system
drives that are protected with BitLocker.

Conflicts Passwords cannot be used if FIPS-compliance is enabled.
Note
The System cryptography: Use FIPS-compliant
algorithms for encryption, hashing, and signing
policy setting, which is located at Computer
Configuration\Windows Settings\Security
Settings\Local Policies\Security Options specifies
whether FIPS-compliance is enabled.
When enabled Users can configure a password that meets the

requirements you define. To enforce complexity
requirements for the password, select Require
complexity.
When disabled or not configured The default length constraint of 8 characters will apply to
operating system drive passwords and no complexity
checks will occur.
Reference
If non-TPM protectors are allowed on operating system drives, you can provision a password, enforce complexity
requirements on the password, and configure a minimum length for the password. For the complexity
requirement setting to be effective, the Group Policy setting Password must meet complexity requirements,
which is located at Computer Configuration\Windows Settings\Security Settings\Account
Policies\Password Policy\ must be also enabled.
Note: These settings are enforced when turning on BitLocker, not when unlocking a volume. BitLocker allows
unlocking a drive with any of the protectors that are available on the drive.
When set to Require complexity, a connection to a domain controller is necessary when BitLocker is enabled to
validate the complexity the password. When set to Allow complexity, a connection to a domain controller is
attempted to validate that the complexity adheres to the rules set by the policy. If no domain controllers are
found, the password will be accepted regardless of actual password complexity, and the drive will be encrypted
by using that password as a protector. When set to Do not allow complexity, there is no password complexity
validation. Passwords must be at least 8 characters. To configure a greater minimum length for the password,
enter the desired number of characters in the Minimum password length box.
When this policy setting is enabled, you can set the option Configure password complexity for operating
system drives to:
Allow password complexity
Do not allow password complexity
Require password complexity
Require additional authentication at startup (Windows Server 2008 and Windows Vista)
This policy setting is used to control what unlock options are available for computers running Windows Server
2008 or Windows Vista.
Policy description With this policy setting, you can control whether the
BitLocker Setup Wizard on computers running Windows
Vista or Windows Server 2008 can set up an additional
authentication method that is required each time the
computer starts.
Introduced Windows Server 2008 and Windows Vista
Drive type Operating system drives (Windows Server 2008 and

Windows Vista)

Conflicts If you choose to require an additional authentication

method, other authentication methods cannot be
allowed.
When enabled The BitLocker Setup Wizard displays the page that allows
the user to configure advanced startup options for
BitLocker. You can further configure setting options for
computers with or without a TPM.
When disabled or not configured The BitLocker Setup Wizard displays basic steps that
allow users to enable BitLocker on computers with a
TPM. In this basic wizard, no additional startup key or
startup PIN can be configured.
Reference
On a computer with a compatible TPM, two authentication methods can be used at startup to provide added
protection for encrypted data. When the computer starts, it can require users to insert a USB drive that contains a
startup key. It can also require users to enter a 6-digit to 20-digit startup PIN.
A USB drive that contains a startup key is needed on computers without a compatible TPM. Without a TPM,
BitLocker-encrypted data is protected solely by the key material that is on this USB drive.
There are two options for TPM-enabled computers or devices:
Configure TPM startup PIN
Allow startup PIN with TPM
Require startup PIN with TPM
Do not allow startup PIN with TPM
Configure TPM startup key
Allow startup key with TPM
Require startup key with TPM
Do not allow startup key with TPM
These options are mutually exclusive. If you require the startup key, you must not allow the startup PIN. If you
require the startup PIN, you must not allow the startup key. Otherwise, a policy error will occur.
To hide the advanced page on a TPM-enabled computer or device, set these options to Do not allow for the
startup key and for the startup PIN.
Configure use of smart cards on fixed data drives
This policy setting is used to require, allow, or deny the use of smart cards with fixed data drives.
Policy description With this policy setting, you can specify whether smart
cards can be used to authenticate user access to the
BitLocker-protected fixed data drives on a computer.
Drive type Fixed data drives

Encryption\Fixed Data Drives
Conflicts To use smart cards with BitLocker, you may also need to
modify the object identifier setting in the Computer
Configuration\Administrative Templates\BitLocker
Drive Encryption\Validate smart card certificate
usage rule compliance policy setting to match the
object identifier of your smart card certificates.
When enabled Smart cards can be used to authenticate user access to

the drive. You can require smart card authentication by
selecting the Require use of smart cards on fixed
data drives check box.
When disabled Users cannot use smart cards to authenticate their

access to BitLocker-protected fixed data drives.
When not configured Smart cards can be used to authenticate user access to a
BitLocker-protected drive.
Reference
Note: These settings are enforced when turning on BitLocker, not when unlocking a drive. BitLocker allows
unlocking a drive by using any of the protectors that are available on the drive.
Configure use of passwords on fixed data drives

This policy setting is used to require, allow, or deny the use of passwords with fixed data drives.
Policy description With this policy setting, you can specify whether a
password is required to unlock BitLocker-protected fixed
data drives.


Conflicts To use password complexity, the Computer

Configuration\Windows Settings\Security
Settings\Account Policies\Password
Policy\Password must meet complexity
requirements policy setting must also be enabled.

requirements you define. To require the use of a
password, select Require password for fixed data
drive. To enforce complexity requirements on the
password, select Require complexity.
When disabled The user is not allowed to use a password.
When not configured Passwords are supported with the default settings, which
do not include password complexity requirements and
require only 8 characters.
Reference
When set to Require complexity, a connection to a domain controller is necessary to validate the complexity of
the password when BitLocker is enabled.
When set to Allow complexity, a connection to a domain controller is attempted to validate that the complexity
adheres to the rules set by the policy. However, if no domain controllers are found, the password is accepted
regardless of the actual password complexity, and the drive is encrypted by using that password as a protector.
When set to Do not allow complexity, no password complexity validation is performed.
Passwords must be at least 8 characters. To configure a greater minimum length for the password, enter the
desired number of characters in the Minimum password length box.
For the complexity requirement setting to be effective, the Group Policy setting Computer
Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\Password must
meet complexity requirements must also be enabled. This policy setting is configured on a per-computer
basis. This means that it applies to local user accounts and domain user accounts. Because the password filter
that is used to validate password complexity is located on the domain controllers, local user accounts cannot
access the password filter because they are not authenticated for domain access. When this policy setting is
enabled, if you sign in with a local user account, and you attempt to encrypt a drive or change a password on an
existing BitLocker-protected drive, an "Access denied" error message is displayed. In this situation, the password
key protector cannot be added to the drive.
Enabling this policy setting requires that connectivity to a domain be established before adding a password key
protector to a BitLocker-protected drive. Users who work remotely and have periods of time in which they
cannot connect to the domain should be made aware of this requirement so that they can schedule a time when
they will be connected to the domain to turn on BitLocker or to change a password on a BitLocker-protected data
drive.
Important: Passwords cannot be used if FIPS compliance is enabled. The System cryptography: Use FIPS-
compliant algorithms for encryption, hashing, and signing policy setting in Computer
Configuration\Windows Settings\Security Settings\Local Policies\Security Options specifies whether
FIPS compliance is enabled.
Configure use of smart cards on removable data drives

This policy setting is used to require, allow, or deny the use of smart cards with removable data drives.
Policy description With this policy setting, you can specify whether smart
cards can be used to authenticate user access to
BitLocker-protected removable data drives on a
computer.
Drive type Removable data drives

Encryption\Removable Data Drives
Conflicts To use smart cards with BitLocker, you may also need to
modify the object identifier setting in the Computer
Configuration\Administrative Templates\BitLocker
Drive Encryption\Validate smart card certificate
usage rule compliance policy setting to match the
object identifier of your smart card certificates.
When enabled Smart cards can be used to authenticate user access to

the drive. You can require smart card authentication by
selecting the Require use of smart cards on
removable data drives check box.
When disabled or not configured Users are not allowed to use smart cards to authenticate
their access to BitLocker-protected removable data
drives.
When not configured Smart cards are available to authenticate user access to a
BitLocker-protected removable data drive.
Reference
Configure use of passwords on removable data drives

This policy setting is used to require, allow, or deny the use of passwords with removable data drives.
Policy description With this policy setting, you can specify whether a
password is required to unlock BitLocker-protected
removable data drives.

Conflicts To use password complexity, the Password must meet

complexity requirements policy setting, which is
located at Computer Configuration\Windows
Settings\Security Settings\Account
Policies\Password Policy must also be enabled.

requirements you define. To require the use of a
password, select Require password for removable
data drive. To enforce complexity requirements on the
password, select Require complexity.
When disabled The user is not allowed to use a password.
When not configured Passwords are supported with the default settings, which
do not include password complexity requirements and
require only 8 characters.
Reference
If you choose to allow the use of a password, you can require a password to be used, enforce complexity
requirements, and configure a minimum length. For the complexity requirement setting to be effective, the
Group Policy setting Password must meet complexity requirements, which is located at Computer
Configuration\Windows Settings\Security Settings\Account Policies\Password Policy must also be
enabled.
Passwords must be at least 8 characters. To configure a greater minimum length for the password, enter the
desired number of characters in the Minimum password length box.
When set to Require complexity, a connection to a domain controller is necessary when BitLocker is enabled to
validate the complexity the password.
When set to Allow complexity, a connection to a domain controller will be attempted to validate that the
complexity adheres to the rules set by the policy. However, if no domain controllers are found, the password will
still be accepted regardless of actual password complexity and the drive will be encrypted by using that
password as a protector.
When set to Do not allow complexity, no password complexity validation will be done.
Note: Passwords cannot be used if FIPS compliance is enabled. The System cryptography: Use FIPS-
compliant algorithms for encryption, hashing, and signing policy setting in Computer
Configuration\Windows Settings\Security Settings\Local Policies\Security Options specifies whether
FIPS compliance is enabled.
For information about this setting, see System cryptography: Use FIPS-compliant algorithms for encryption,
hashing, and signing.
Validate smart card certificate usage rule compliance
This policy setting is used to determine what certificate to use with BitLocker.
Policy description With this policy setting, you can associate an object
identifier from a smart card certificate to a BitLocker-
protected drive.
Drive type Fixed and removable data drives

Encryption
Conflicts None
When enabled The object identifier that is specified in the Object

identifier setting must match the object identifier in the
smart card certificate.
When disabled or not configured The default object identifier is used.
Reference
This policy setting is applied when you turn on BitLocker.
The object identifier is specified in the enhanced key usage (EKU) of a certificate. BitLocker can identify which
certificates can be used to authenticate a user certificate to a BitLocker-protected drive by matching the object
identifier in the certificate with the object identifier that is defined by this policy setting.
The default object identifier is 1.3.6.1.4.1.311.67.1.1.
Note: BitLocker does not require that a certificate have an EKU attribute; however, if one is configured for the
certificate, it must be set to an object identifier that matches the object identifier configured for BitLocker.
Enable use of BitLocker authentication requiring preboot keyboard input on slates
This policy setting allows users to enable authentication options that require user input from the preboot
environment even if the platform indicates a lack of preboot input capability.
Policy description With this policy setting, you can allow users to enable
authentication options that require user input from the
preboot environment, even if the platform indicates a
lack of preboot input capability.
Drive type Operating system drive

Encryption\Operating System Drive
Conflicts None
When enabled Devices must have an alternative means of preboot

input (such as an attached USB keyboard).
When disabled or not configured The Windows Recovery Environment must be enabled on
tablets to support entering the BitLocker recovery
password.
Reference
The Windows touch keyboard (such as used by tablets) is not available in the preboot environment where
BitLocker requires additional information, such as a PIN or password.
It is recommended that administrators enable this policy only for devices that are verified to have an alternative
means of preboot input, such as attaching a USB keyboard.
When the Windows Recovery Environment is not enabled and this policy is not enabled, you cannot turn on
BitLocker on a device that uses the Windows touch keyboard.
If you do not enable this policy setting, the following options in the Require additional authentication at
startup policy might not be available:
Configure TPM startup PIN: Required and Allowed
Configure TPM startup key and PIN: Required and Allowed
Deny write access to fixed drives not protected by BitLocker
This policy setting is used to require encryption of fixed drives prior to granting Write access.
Policy description With this policy setting, you can set whether BitLocker
protection is required for fixed data drives to be writable
on a computer.

Conflicts See the Reference section for a description of conflicts.
When enabled All fixed data drives that are not BitLocker-protected are
mounted as Read-only. If the drive is protected by
BitLocker, it is mounted with Read and Write access.
When disabled or not configured All fixed data drives on the computer are mounted with
Read and Write access.
Reference
Conflict considerations include:
1. When this policy setting is enabled, users receive "Access denied" error messages when they try to save data
to unencrypted fixed data drives. See the Reference section for additional conflicts.
2. If BdeHdCfg.exe is run on a computer when this policy setting is enabled, you could encounter the
following issues:
If you attempted to shrink the drive and create the system drive, the drive size is successfully reduced
and a raw partition is created. However, the raw partition is not formatted. The following error
message is displayed: "The new active drive cannot be formatted. You may need to manually prepare
your drive for BitLocker."
If you attempt to use unallocated space to create the system drive, a raw partition will be created.
However, the raw partition will not be formatted. The following error message is displayed: "The new
active drive cannot be formatted. You may need to manually prepare your drive for BitLocker."
If you attempt to merge an existing drive into the system drive, the tool fails to copy the required boot
file onto the target drive to create the system drive. The following error message is displayed:
"BitLocker setup failed to copy boot files. You may need to manually prepare your drive for BitLocker."
3. If this policy setting is enforced, a hard drive cannot be repartitioned because the drive is protected. If you are
upgrading computers in your organization from a previous version of Windows, and those computers were
configured with a single partition, you should create the required BitLocker system partition before you apply
this policy setting to the computers.
Deny write access to removable drives not protected by BitLocker
This policy setting is used to require that removable drives are encrypted prior to granting Write access, and to
control whether BitLocker-protected removable drives that were configured in another organization can be
opened with Write access.
BitLocker protection is required for a computer to be
able to write data to a removable data drive.

Conflicts See the Reference section for a description of conflicts.
When enabled All removable data drives that are not BitLocker-
protected are mounted as Read-only. If the drive is
protected by BitLocker, it is mounted with Read and
Write access.
When disabled or not configured All removable data drives on the computer are mounted
with Read and Write access.
Reference
If the Deny write access to devices configured in another organization option is selected, only drives with
identification fields that match the computer's identification fields are given Write access. When a removable
data drive is accessed, it is checked for a valid identification field and allowed identification fields. These fields are
defined by the Provide the unique identifiers for your organization policy setting.
Note: You can override this policy setting with the policy settings under User
Configuration\Administrative Templates\System\Removable Storage Access. If the Removable
Disks: Deny write access policy setting is enabled, this policy setting will be ignored.
Conflict considerations include:

1. Use of BitLocker with the TPM plus a startup key or with the TPM plus a PIN and startup key must be
disallowed if the Deny write access to removable drives not protected by BitLocker policy setting is
enabled.
2. Use of recovery keys must be disallowed if the Deny write access to removable drives not protected by
3. You must enable the Provide the unique identifiers for your organization policy setting if you want to
deny Write access to drives that were configured in another organization.
Control use of BitLocker on removable drives
This policy setting is used to prevent users from turning BitLocker on or off on removable data drives.
Policy description With this policy setting, you can control the use of
BitLocker on removable data drives.

Conflicts None
When enabled You can select property settings that control how users
can configure BitLocker.
When disabled Users cannot use BitLocker on removable data drives.
When not configured Users can use BitLocker on removable data drives.
Reference
For information about suspending BitLocker protection, see BitLocker Basic Deployment.
The options for choosing property settings that control how users can configure BitLocker are:
Allow users to apply BitLocker protection on removable data drives Enables the user to run the
BitLocker Setup Wizard on a removable data drive.
Allow users to suspend and decrypt BitLocker on removable data drives Enables the user to remove
BitLocker from the drive or to suspend the encryption while performing maintenance.
Choose drive encryption method and cipher strength
This policy setting is used to control the encryption method and cipher strength.
Policy description With this policy setting, you can control the encryption
method and strength for drives.
Drive type All drives

Encryption
Conflicts None
When enabled You can choose an encryption algorithm and key cipher
strength for BitLocker to use to encrypt drives.
When disabled or not configured BitLocker uses the default encryption method of AES
128-bit or the encryption method that is specified by the
setup script.
Reference
By default, BitLocker uses AES 128-bit encryption. Available options are AES-128 and AES-256. The values of this
policy determine the strength of the cipher that BitLocker uses for encryption. Enterprises may want to control
the encryption level for increased security (AES-256 is stronger than AES-128). Changing the encryption method
has no effect if the drive is already encrypted or if encryption is in progress. In these cases, this policy setting is
ignored.
Warning: This policy does not apply to encrypted drives. Encrypted drives utilize their own algorithm, which
is set by the drive during partitioning.
When this policy setting is disabled, BitLocker uses AES with the same bit strength (128-bit or 256-bit) as
specified in the policy setting Choose drive encryption method and cipher strength (Windows Vista,
Windows Server 2008, Windows 7). If neither policy is set, BitLocker uses the default encryption method, AES-
128, or the encryption method that is specified in the setup script.
Configure use of hardware -based encryption for fixed data drives
This policy controls how BitLocker reacts to systems that are equipped with encrypted drives when they are used
as fixed data volumes. Using hardware-based encryption can improve the performance of drive operations that
involve frequent reading or writing of data to the drive.
Policy description With this policy setting, you can manage BitLockers use
of hardware-based encryption on fixed data drives and
to specify which encryption algorithms BitLocker can use
with hardware-based encryption.

Conflicts None
When enabled You can specify additional options that control whether
BitLocker software-based encryption is used instead of
hardware-based encryption on computers that do not
support hardware-based encryption. You can also specify
whether you want to restrict the encryption algorithms
and cipher suites that are used with hardware-based
encryption.
When disabled BitLocker cannot use hardware-based encryption with
fixed data drives, and BitLocker software-based
encryption is used by default when the drive in
encrypted.
When not configured BitLocker uses hardware-based encryption with the

encryption algorithm that is set for the drive. If
hardware-based encryption is not available, BitLocker
software-based encryption is used instead.
Reference
Note: The Choose drive encryption method and cipher strength policy setting does not apply to
hardware-based encryption.
The encryption algorithm that is used by hardware-based encryption is set when the drive is partitioned. By
default, BitLocker uses the algorithm that is configured on the drive to encrypt the drive. The Restrict
encryption algorithms and cipher suites allowed for hardware-based encryption option of this setting
enables you to restrict the encryption algorithms that BitLocker can use with hardware encryption. If the
algorithm that is set for the drive is not available, BitLocker disables the use of hardware-based encryption.
Encryption algorithms are specified by object identifiers (OID), for example:
Advanced Encryption Standard (AES) 128 in Cipher Block Chaining (CBC) mode OID: 2.16.840.1.101.3.4.1.2
AES 256 in CBC mode OID: 2.16.840.1.101.3.4.1.42
Configure use of hardware -based encryption for operating system drives
This policy controls how BitLocker reacts when encrypted drives are used as operating system drives. Using
hardware-based encryption can improve the performance of drive operations that involve frequent reading or
writing of data to the drive.
of hardware-based encryption on operating system
drives and specify which encryption algorithms it can use
with hardware-based encryption.

Conflicts None
encryption.

operating system drives, and BitLocker software-based
encrypted.

Reference
If hardware-based encryption is not available, BitLocker software-based encryption is used instead.
Configure use of hardware -based encryption for removable data drives
This policy controls how BitLocker reacts to encrypted drives when they are used as removable data drives. Using
hardware-based encryption can improve the performance of drive operations that involve frequent reading or
writing of data to the drive.
of hardware-based encryption on removable data drives
and specify which encryption algorithms it can use with
Drive type Removable data drive

Conflicts None
encryption.

removable data drives, and BitLocker software-based
encrypted.

Reference
If hardware-based encryption is not available, BitLocker software-based encryption is used instead.
Enforce drive encryption type on fixed data drives
This policy controls whether fixed data drives utilize Used Space Only encryption or Full encryption. Setting this
policy also causes the BitLocker Setup Wizard to skip the encryption options page so no encryption selection
displays to the user.
Policy description With this policy setting, you can configure the encryption
type that is used by BitLocker.

Drive type Fixed data drive

Conflicts None
When enabled This policy defines the encryption type that BitLocker
uses to encrypt drives, and the encryption type option is
not presented in the BitLocker Setup Wizard.
When disabled or not configured The BitLocker Setup Wizard asks the user to select the
encryption type before turning on BitLocker.
Reference
This policy setting is applied when you turn on BitLocker. Changing the encryption type has no effect if the drive
is already encrypted or if encryption is in progress. Choose Full encryption to require that the entire drive be
encrypted when BitLocker is turned on. Choose Used Space Only encryption to require that only the portion of
the drive that is used to store data is encrypted when BitLocker is turned on.
Note: This policy is ignored when you are shrinking or expanding a volume and the BitLocker driver uses the
current encryption method. For example, when a drive that is using Used Space Only encryption is expanded,
the new free space is not wiped as it would be for a drive that is using Full encryption. The user could wipe
the free space on a Used Space Only drive by using the following command: manage-bde -w. If the volume
is shrunk, no action is taken for the new free space.
For more information about the tool to manage BitLocker, see Manage-bde.
Enforce drive encryption type on operating system drives
This policy controls whether operating system drives utilize Full encryption or Used Space Only encryption.
Setting this policy also causes the BitLocker Setup Wizard to skip the encryption options page, so no encryption
selection displays to the user.
Drive type Operating system drive

Conflicts None
When enabled The encryption type that BitLocker uses to encrypt drives
is defined by this policy, and the encryption type option
is not presented in the BitLocker Setup Wizard.
Reference
Note: This policy is ignored when shrinking or expanding a volume, and the BitLocker driver uses the current
encryption method. For example, when a drive that is using Used Space Only encryption is expanded, the
new free space is not wiped as it would be for a drive that uses Full encryption. The user could wipe the free
space on a Used Space Only drive by using the following command: manage-bde -w. If the volume is
shrunk, no action is taken for the new free space.
Enforce drive encryption type on removable data drives
This policy controls whether fixed data drives utilize Full encryption or Used Space Only encryption. Setting this
policy also causes the BitLocker Setup Wizard to skip the encryption options page, so no encryption selection
displays to the user.
Drive type Removable data drive

Conflicts None
When enabled The encryption type that BitLocker uses to encrypt drives
is defined by this policy, and the encryption type option
is not presented in the BitLocker Setup Wizard.
Reference
Note: This policy is ignored when shrinking or expanding a volume, and the BitLocker driver uses the current
encryption method. For example, when a drive that is using Used Space Only encryption is expanded, the
new free space is not wiped as it would be for a drive that is using Full Encryption. The user could wipe the
free space on a Used Space Only drive by using the following command: manage-bde -w. If the volume is
shrunk, no action is taken for the new free space.
This policy setting is used to configure recovery methods for operating system drives.
Policy description With this policy setting, you can control how BitLocker-
protected operating system drives are recovered in the
absence of the required startup key information.

Conflicts You must disallow the use of recovery keys if the Deny
When using data recovery agents, you must enable the
policy setting.
When enabled You can control the methods that are available to users
to recover data from BitLocker-protected operating
system drives.
When disabled or not configured The default recovery options are supported for BitLocker
recovery. By default, a data recovery agent is allowed,
the recovery options can be specified by the user
(including the recovery password and recovery key), and
recovery information is not backed up to AD DS.
Reference
The Allow data recovery agent check box is used to specify whether a data recovery agent can be used with
BitLocker-protected operating system drives. Before a data recovery agent can be used, it must be added from
Public Key Policies, which is located in the Group Policy Management Console (GPMC) or in the Local Group
Policy Editor.
For more information about adding data recovery agents, see BitLocker basic deployment.
In Configure user storage of BitLocker recovery information, select whether users are allowed, required, or
not allowed to generate a 48-digit recovery password.
Select Omit recovery options from the BitLocker setup wizard to prevent users from specifying recovery
options when they enable BitLocker on a drive. This means that you will not be able to specify which recovery
option to use when you enable BitLocker. Instead, BitLocker recovery options for the drive are determined by the
policy setting.
In Save BitLocker recovery information to Active Directory Domain Services, choose which BitLocker
recovery information to store in Active Directory Domain Services (AD DS) for operating system drives. If you
select Store recovery password and key packages, the BitLocker recovery password and the key package are
stored in AD DS. Storing the key package supports recovering data from a drive that is physically corrupted. If
you select Store recovery password only, only the recovery password is stored in AD DS.
Select the Do not enable BitLocker until recovery information is stored in AD DS for operating system
drives check box if you want to prevent users from enabling BitLocker unless the computer is connected to the
domain and the backup of BitLocker recovery information to AD DS succeeds.
Note: If the Do not enable BitLocker until recovery information is stored in AD DS for operating
system drives check box is selected, a recovery password is automatically generated.
Choose how users can recover BitLocker-protected drives (Windows Server 2008 and Windows Vista)
This policy setting is used to configure recovery methods for BitLocker-protected drives on computers running
Windows Server 2008 or Windows Vista.
Policy description With this policy setting, you can control whether the
BitLocker Setup Wizard can display and specify BitLocker
recovery options.
Drive type Operating system drives and fixed data drives on

computers running Windows Server 2008 and Windows
Vista

Encryption
Conflicts This policy setting provides an administrative method of

recovering data that is encrypted by BitLocker to prevent
data loss due to lack of key information. If you choose
the Do not allow option for both user recovery options,
you must enable the Store BitLocker recovery
information in Active Directory Domain Services
(Windows Server 2008 and Windows Vista) policy
setting to prevent a policy error.
When enabled You can configure the options that the Bitlocker Setup
Wizard displays to users for recovering BitLocker
encrypted data.
When disabled or not configured The BitLocker Setup Wizard presents users with ways to
store recovery options.
Reference
This policy is only applicable to computers running Windows Server 2008 or Windows Vista. This policy setting
is applied when you turn on BitLocker.
Two recovery options can be used to unlock BitLocker-encrypted data in the absence of the required startup key
information. Users can type a 48-digit numerical recovery password, or they can insert a USB drive that contains
a 256-bit recovery key.
Saving the recovery password to a USB drive stores the 48-digit recovery password as a text file and the 256-bit
recovery key as a hidden file. Saving it to a folder stores the 48-digit recovery password as a text file. Printing it
sends the 48-digit recovery password to the default printer. For example, not allowing the 48-digit recovery
password prevents users from printing or saving recovery information to a folder.
Important: If TPM initialization is performed during the BitLocker setup, TPM owner information is saved or
printed with the BitLocker recovery information. The 48-digit recovery password is not available in FIPS-
compliance mode.
Important: To prevent data loss, you must have a way to recover BitLocker encryption keys. If you do not
allow both recovery options, you must enable the backup of BitLocker recovery information to AD DS.
Otherwise, a policy error occurs.
Store BitLocker recovery information in Active Directory Domain Services (Windows Server 2008 and
Windows Vista)
This policy setting is used to configure the storage of BitLocker recovery information in AD DS. This provides an
administrative method of recovering data that is encrypted by BitLocker to prevent data loss due to lack of key
information.
Policy description With this policy setting, you can manage the AD DS
backup of BitLocker Drive Encryption recovery
information.
Drive type Operating system drives and fixed data drives on

computers running Windows Server 2008 and Windows
Vista.

Encryption
Conflicts None
When enabled BitLocker recovery information is automatically and
silently backed up to AD DS when BitLocker is turned on
for a computer.
When disabled or not configured BitLocker recovery information is not backed up to AD

DS.
Reference
This policy is only applicable to computers running Windows Server 2008 or Windows Vista.
BitLocker recovery information includes the recovery password and unique identifier data. You can also include a
package that contains an encryption key for a BitLocker-protected drive. This key package is secured by one or
more recovery passwords, and it can help perform specialized recovery when the disk is damaged or corrupted.
If you select Require BitLocker backup to AD DS, BitLocker cannot be turned on unless the computer is
connected to the domain and the backup of BitLocker recovery information to AD DS succeeds. This option is
selected by default to help ensure that BitLocker recovery is possible.
A recovery password is a 48-digit number that unlocks access to a BitLocker-protected drive. A key package
contains a drives BitLocker encryption key, which is secured by one or more recovery passwords. Key packages
may help perform specialized recovery when the disk is damaged or corrupted.
If the Require BitLocker backup to AD DS option is not selected, AD DS backup is attempted, but network or
other backup failures do not prevent the BitLocker setup. The Backup process is not automatically retried, and the
recovery password might not be stored in AD DS during BitLocker setup. TPM initialization might be needed
during the BitLocker setup. Enable the Turn on TPM backup to Active Directory Domain Services policy
setting in Computer Configuration\Administrative Templates\System\Trusted Platform Module
Services to ensure that TPM information is also backed up.
For more information about this setting, see TPM Group Policy settings.
Choose default folder for recovery password
This policy setting is used to configure the default folder for recovery passwords.
Policy description With this policy setting, you can specify the default path
that is displayed when the BitLocker Setup Wizard
prompts the user to enter the location of a folder in
which to save the recovery password.
Introduced Windows Vista

Encryption
Conflicts None
When enabled You can specify the path that will be used as the default
folder location when the user chooses the option to save
the recovery password in a folder. You can specify a fully
qualified path or include the target computer's
environment variables in the path. If the path is not
valid, the BitLocker Setup Wizard displays the computer's
top-level folder view.
When disabled or not configured The BitLocker Setup Wizard displays the computer's top-
level folder view when the user chooses the option to
save the recovery password in a folder.
Reference
Note: This policy setting does not prevent the user from saving the recovery password in another folder.

This policy setting is used to configure recovery methods for fixed data drives.
protected fixed data drives are recovered in the absence
of the required credentials.

When using data recovery agents, you must enable and
configure the Provide the unique identifiers for your
organization policy setting.
to recover data from BitLocker-protected fixed data
drives.
Reference
BitLocker-protected fixed data drives. Before a data recovery agent can be used, it must be added from Public
Key Policies, which is located in the Group Policy Management Console (GPMC) or in the Local Group Policy
Editor.
not allowed to generate a 48-digit recovery password or a 256-bit recovery key.
options when they enable BitLocker on a drive. This means that you cannot specify which recovery option to use
when you enable BitLocker. Instead, BitLocker recovery options for the drive are determined by the policy setting.
In Save BitLocker recovery information to Active Directory Doman Services, choose which BitLocker
recovery information to store in AD DS for fixed data drives. If you select Backup recovery password and key
package, the BitLocker recovery password and the key package are stored in AD DS. Storing the key package
supports recovering data from a drive that has been physically corrupted. To recover this data, you can use the
Repair-bde command-line tool. If you select Backup recovery password only, only the recovery password is
stored in AD DS.
For more information about the BitLocker repair tool, see Repair-bde.
Select the Do not enable BitLocker until recovery information is stored in AD DS for fixed data drives
check box if you want to prevent users from enabling BitLocker unless the computer is connected to the domain
and the backup of BitLocker recovery information to AD DS succeeds.
Note: If the Do not enable BitLocker until recovery information is stored in AD DS for fixed data
drives check box is selected, a recovery password is automatically generated.
Choose how BitLocker-protected removable drives can be recovered

This policy setting is used to configure recovery methods for removable data drives.
protected removable data drives are recovered in the
absence of the required credentials.

When using data recovery agents, you must enable and
configure the Provide the unique identifiers for your
organization policy setting.
to recover data from BitLocker-protected removable
data drives.
Reference
BitLocker-protected removable data drives. Before a data recovery agent can be used, it must be added from
Public Key Policies , which is accessed using the GPMC or the Local Group Policy Editor.
not allowed to generate a 48-digit recovery password.
options when they enable BitLocker on a drive. This means that you cannot specify which recovery option to use
when you enable BitLocker. Instead, BitLocker recovery options for the drive are determined by the policy setting.
In Save BitLocker recovery information to Active Directory Domain Services, choose which BitLocker
recovery information to store in AD DS for removable data drives. If you select Backup recovery password and
key package, the BitLocker recovery password and the key package are stored in AD DS. If you select Backup
recovery password only, only the recovery password is stored in AD DS.
Select the Do not enable BitLocker until recovery information is stored in AD DS for removable data
drives check box if you want to prevent users from enabling BitLocker unless the computer is connected to the
domain and the backup of BitLocker recovery information to AD DS succeeds.
Note: If the Do not enable BitLocker until recovery information is stored in AD DS for fixed data
drives check box is selected, a recovery password is automatically generated.
Configure the pre -boot recovery message and URL

This policy setting is used to configure the entire recovery message and to replace the existing URL that is
displayed on the pre-boot recovery screen when the operating system drive is locked.
Policy description With this policy setting, you can configure the BitLocker
recovery screen to display a customized message and
URL.
Introduced Windows 10
Policy path Computer Configuration \ Administrative Templates \

Windows Components \ BitLocker Drive Encryption \
Operating System Drives \ Configure pre-boot recovery
message and URL
Conflicts None
When enabled The customized message and URL are displayed on the
pre-boot recovery screen. If you have previously enabled
a custom recovery message and URL and want to revert
to the default message and URL, you must keep the
policy setting enabled and select the Use default
recovery message and URL option.
When disabled or not configured If the setting has not been previously enabled the
default pre-boot recovery screen is displayed for
BitLocker recovery. If the setting previously was enabled
and is subsequently disabled the last message in Boot
Configuration Data (BCD) is displayed whether it was the
default recovery message or the custom message.
Reference
Enabling the Configure the pre-boot recovery message and URL policy setting allows you to customize the
default recovery screen message and URL to assist customers in recovering their key.
Once you enable the setting you have three options:
If you select the Use default recovery message and URL option, the default BitLocker recovery message
and URL will be displayed on the pre-boot recovery screen.
If you select the Use custom recovery message option, type the custom message in the Custom recovery
message option text box. The message that you type in the Custom recovery message option text box will
be displayed on the pre-boot recovery screen. If a recovery URL is available, include it in the message.
If you select the Use custom recovery URL option, type the custom message URL in the Custom recovery
URL option text box. The URL that you type in the Custom recovery URL option text box replaces the
default URL in the default recovery message, which will be displayed on the pre-boot recovery screen.
Important: Not all characters and languages are supported in the pre-boot environment. We strongly
recommended that you verify the correct appearance of the characters that you use for the custom message
and URL on the pre-boot recovery screen.
Important: Because you can alter the BCDEdit commands manually before you have set Group Policy
settings, you cannot return the policy setting to the default setting by selecting the Not Configured option
after you have configured this policy setting. To return to the default pre-boot recovery screen leave the
policy setting enabled and select the Use default message options from the Choose an option for the
pre-boot recovery message drop-down list box.
Allow Secure Boot for integrity validation

This policy controls how BitLocker-enabled system volumes are handled in conjunction with the Secure Boot
feature. Enabling this feature forces Secure Boot validation during the boot process and verifies Boot
Configuration Data (BCD) settings according to the Secure Boot policy.
Secure Boot will be allowed as the platform integrity
provider for BitLocker operating system drives.

Conflicts If the Configure TPM platform validation profile for

native UEFI firmware configurations Group Policy
setting is enabled and PCR 7 is omitted, BitLocker is
prevented from using Secure Boot for platform or BCD
integrity validation.
For more information about PCR 7, see Platform
Configuration Register (PCR) in this topic.
When enabled or not configured BitLocker uses Secure Boot for platform integrity if the
platform is capable of Secure Boot-based integrity
validation.
When disabled BitLocker uses legacy platform integrity validation, even

on systems that are capable of Secure Boot-based
integrity validation.
Reference
Secure Boot ensures that the computer's preboot environment loads only firmware that is digitally signed by
authorized software publishers. Secure Boot also provides more flexibility for managing preboot configurations
than BitLocker integrity checks prior to Windows Server 2012 and Windows 8. When this policy is enabled and
the hardware is capable of using Secure Boot for BitLocker scenarios, the Use enhanced Boot Configuration
Data validation profile Group Policy setting is ignored, and Secure Boot verifies BCD settings according to the
Secure Boot policy setting, which is configured separately from BitLocker.
Warning: Enabling this policy might result in BitLocker recovery when manufacturer-specific firmware is
updated. If you disable this policy, suspend BitLocker prior to applying firmware updates.

This policy setting is used to establish an identifier that is applied to all drives that are encrypted in your
organization.
Policy description With this policy setting, you can associate unique
organizational identifiers to a new drive that is enabled
with BitLocker.

Encryption
Conflicts Identification fields are required to manage certificate-

based data recovery agents on BitLocker-protected
drives. BitLocker manages and updates certificate-based
data recovery agents only when the identification field is
present on a drive and it is identical to the value that is
configured on the computer.
When enabled You can configure the identification field on the

BitLocker-protected drive and any allowed identification
field that is used by your organization.
When disabled or not configured The identification field is not required.
Reference
These identifiers are stored as the identification field and the allowed identification field. The identification field
allows you to associate a unique organizational identifier to BitLocker-protected drives. This identifier is
automatically added to new BitLocker-protected drives, and it can be updated on existing BitLocker-protected
drives by using the Manage-bde command-line tool.
An identification field is required to manage certificate-based data recovery agents on BitLocker-protected drives
and for potential updates to the BitLocker To Go Reader. BitLocker manages and updates data recovery agents
only when the identification field on the drive matches the value that is configured in the identification field. In a
similar manner, BitLocker updates the BitLocker To Go Reader only when the identification field on the drive
matches the value that is configured for the identification field.
The allowed identification field is used in combination with the Deny write access to removable drives not
protected by BitLocker policy setting to help control the use of removable drives in your organization. It is a
comma-separated list of identification fields from your organization or external organizations.
You can configure the identification fields on existing drives by using the Manage-bde command-line tool.
When a BitLocker-protected drive is mounted on another BitLocker-enabled computer, the identification field
and the allowed identification field are used to determine whether the drive is from an outside organization.
Multiple values separated by commas can be entered in the identification and allowed identification fields. The
identification field can be any value up to 260 characters.
Prevent memory overwrite on restart
This policy setting is used to control whether the computer's memory will be overwritten the next time the
computer is restarted.
Policy description With this policy setting, you can control computer restart
performance at the risk of exposing BitLocker secrets.
Introduced Windows Vista

Encryption
Conflicts None
When enabled The computer will not overwrite memory when it

restarts. Preventing memory overwrite may improve
restart performance, but it increases the risk of exposing
BitLocker secrets.
When disabled or not configured BitLocker secrets are removed from memory when the
computer restarts.
Reference
This policy setting is applied when you turn on BitLocker. BitLocker secrets include key material that is used to
encrypt data. This policy setting applies only when BitLocker protection is enabled.
Configure TPM platform validation profile for BIOS -based firmware configurations
This policy setting determines what values the TPM measures when it validates early boot components before it
unlocks an operating system drive on a computer with a BIOS configuration or with UEFI firmware that has the
Compatibility Support Module (CSM) enabled.
Policy description With this policy setting, you can configure how the
computer's TPM security hardware secures the BitLocker
encryption key.

Conflicts None
When enabled You can configure the boot components that the TPM
validates before unlocking access to the BitLocker-
encrypted operating system drive. If any of these
components change while BitLocker protection is in
effect, the TPM does not release the encryption key to
unlock the drive. Instead, the computer displays the
BitLocker Recovery console and requires that the
recovery password or the recovery key is provided to
unlock the drive.
When disabled or not configured The TPM uses the default platform validation profile or
the platform validation profile that is specified by the
setup script.
Reference
This policy setting does not apply if the computer does not have a compatible TPM or if BitLocker has already
been turned on with TPM protection.
Important: This Group Policy setting only applies to computers with BIOS configurations or to computers
with UEFI firmware with the CSM enabled. Computers that use a native UEFI firmware configuration store
different values in the Platform Configuration Registers (PCRs). Use the Configure TPM platform
validation profile for native UEFI firmware configurations Group Policy setting to configure the TPM
PCR profile for computers that use native UEFI firmware.
A platform validation profile consists of a set of PCR indices that range from 0 to 23. The default platform
validation profile secures the encryption key against changes to the following:
Core Root of Trust of Measurement (CRTM), BIOS, and Platform Extensions (PCR 0)
Option ROM Code (PCR 2)
Master Boot Record (MBR) Code (PCR 4)
NTFS Boot Sector (PCR 8)
NTFS Boot Block (PCR 9)
Boot Manager (PCR 10)
BitLocker Access Control (PCR 11)
Note: Changing from the default platform validation profile affects the security and manageability of your
computer. BitLockers sensitivity to platform modifications (malicious or authorized) is increased or
decreased depending on inclusion or exclusion (respectively) of the PCRs.
The following list identifies all of the PCRs available:

PCR 0: Core root-of-trust for measurement, BIOS, and Platform extensions
PCR 1: Platform and motherboard configuration and data.
PCR 2: Option ROM code
PCR 3: Option ROM data and configuration
PCR 4: Master Boot Record (MBR) code
PCR 5: Master Boot Record (MBR) partition table
PCR 6: State transition and wake events
PCR 7: Computer manufacturer-specific
PCR 8: NTFS boot sector
PCR 9: NTFS boot block
PCR 10: Boot manager
PCR 11: BitLocker access control
PCR 12-23: Reserved for future use
Configure TPM platform validation profile (Windows Vista, Windows Server 2008, Windows 7, Windows
Server 2008 R2)
This policy setting determines what values the TPM measures when it validates early boot components before
unlocking a drive on a computer running Windows Vista, Windows Server 2008, or Windows 7.
computer's TPM security hardware secures the BitLocker
encryption key.

Conflicts None
When enabled You can configure the boot components that the TPM
validates before unlocking access to the BitLocker-
encrypted operating system drive. If any of these
components change while BitLocker protection is in
effect, the TPM does not release the encryption key to
unlock the drive. Instead, the computer displays the
BitLocker Recovery console and requires that the
recovery password or the recovery key is provided to
unlock the drive.
When disabled or not configured The TPM uses the default platform validation profile or
setup script.
Reference
This policy setting does not apply if the computer does not have a compatible TPM or if BitLocker is already
turned on with TPM protection.
A platform validation profile consists of a set of PCR indices that range from 0 to 23. The default platform
validation profile secures the encryption key against changes to the following:
Core Root of Trust of Measurement (CRTM), BIOS, and Platform Extensions (PCR 0)
Option ROM Code (PCR 2)
Master Boot Record (MBR) Code (PCR 4)
NTFS Boot Sector (PCR 8)
NTFS Boot Block (PCR 9)
Boot Manager (PCR 10)
BitLocker Access Control (PCR 11)
Note: The default TPM validation profile PCR settings for computers that use an Extensible Firmware
Interface (EFI) are the PCRs 0, 2, 4, and 11 only.

PCR 0: Core root-of-trust for measurement, EFI boot and run-time services, EFI drivers embedded in system
ROM, ACPI static tables, embedded SMM code, and BIOS code
PCR 1: Platform and motherboard configuration and data. Hand-off tables and EFI variables that affect system
configuration
PCR 2: Option ROM code
PCR 3: Option ROM data and configuration
PCR 4: Master Boot Record (MBR) code or code from other boot devices
PCR 5: Master Boot Record (MBR) partition table. Various EFI variables and the GPT table
PCR 6: State transition and wake events
PCR 7: Computer manufacturer-specific
PCR 8: NTFS boot sector
PCR 9: NTFS boot block
PCR 10: Boot manager
PCR 12 - 23: Reserved for future use
Warning: Changing from the default platform validation profile affects the security and manageability of
your computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or
Configure TPM platform validation profile for native UEFI firmware configurations
This policy setting determines what values the TPM measures when it validates early boot components before
unlocking an operating system drive on a computer with native UEFI firmware configurations.
computer's Trusted Platform Module (TPM) security
hardware secures the BitLocker encryption key.

Conflicts Setting this policy with PCR 7 omitted, overrides the
Allow Secure Boot for integrity validation Group
Policy setting, and it prevents BitLocker from using
Secure Boot for platform or Boot Configuration Data
(BCD) integrity validation.
If your environments use TPM and Secure Boot for
platform integrity checks, this policy should not be
configured.
For more information about PCR 7, see Platform
Configuration Register (PCR) in this topic.
When enabled Before you turn on BitLocker, you can configure the boot
components that the TPM validates before it unlocks
access to the BitLocker-encrypted operating system
drive. If any of these components change while BitLocker
protection is in effect, the TPM does not release the
encryption key to unlock the drive. Instead, the
computer displays the BitLocker Recovery console and
requires that the recovery password or the recovery key
is provided to unlock the drive.
When disabled or not configured BitLocker uses the default platform validation profile or
setup script.
Reference
This policy setting does not apply if the computer does not have a compatible TPM or if BitLocker is already
turned on with TPM protection.
Important: This Group Policy setting only applies to computers with a native UEFI firmware configuration.
Computers with BIOS or UEFI firmware with a Compatibility Support Module (CSM) enabled store different
values in the Platform Configuration Registers (PCRs). Use the Configure TPM platform validation
profile for BIOS-based firmware configurations Group Policy setting to configure the TPM PCR profile
for computers with BIOS configurations or for computers with UEFI firmware with a CSM enabled.
A platform validation profile consists of a set of Platform Configuration Register (PCR) indices ranging from 0 to
23. The default platform validation profile secures the encryption key against changes to the core system
firmware executable code (PCR 0), extended or pluggable executable code (PCR 2), boot manager (PCR 4), and
the BitLocker access control (PCR 11).
PCR 0: Core System Firmware executable code
PCR 1: Core System Firmware data
PCR 2: Extended or pluggable executable code
PCR 3: Extended or pluggable firmware data
PCR 4: Boot Manager
PCR 5: GPT/Partition Table
PCR 6: Resume from S4 and S5 Power State Events
PCR 7: Secure Boot State
For more information about this PCR, see Platform Configuration Register (PCR) in this topic.
PCR 8: Initialized to 0 with no Extends (reserved for future use)
PCR 12: Data events and highly volatile events
PCR 13: Boot Module Details
PCR 14: Boot Authorities
PCR 15 23: Reserved for future use
Warning: Changing from the default platform validation profile affects the security and manageability of
your computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or
Reset platform validation data after BitLocker recovery

This policy setting determines if you want platform validation data to refresh when Windows is started following
a BitLocker recovery. A platform validation data profile consists of the values in a set of Platform Configuration
Register (PCR) indices that range from 0 to 23.
Policy description With this policy setting, you can control whether
platform validation data is refreshed when Windows is
started following a BitLocker recovery.

Conflicts None
When enabled Platform validation data is refreshed when Windows is

When disabled Platform validation data is not refreshed when Windows

is started following a BitLocker recovery.
When not configured Platform validation data is refreshed when Windows is

Reference
For more information about the recovery process, see the BitLocker recovery guide.
Use enhanced Boot Configuration Data validation profile
This policy setting determines specific Boot Configuration Data (BCD) settings to verify during platform
validation. A platform validation uses the data in the platform validation profile, which consists of a set of
Platform Configuration Register (PCR) indices that range from 0 to 23.
Policy description With this policy setting, you can specify Boot
Configuration Data (BCD) settings to verify during
platform validation.

Conflicts When BitLocker is using Secure Boot for platform and

Boot Configuration Data integrity validation, the Use
enhanced Boot Configuration Data validation
profile Group Policy setting is ignored (as defined by
the Allow Secure Boot for integrity validation Group
Policy setting).
When enabled You can add additional BCD settings, exclude the BCD
settings you specify, or combine inclusion and exclusion
lists to create a customized BCD validation profile, which
gives you the ability to verify those BCD settings.
When disabled The computer reverts to a BCD profile validation similar

to the default BCD profile that is used by Windows 7.
When not configured The computer verifies the default BCD settings in
Windows.
Reference
Note: The setting that controls boot debugging (0x16000010) is always validated, and it has no effect if it is
included in the inclusion or the exclusion list.
Allow access to BitLocker-protected fixed data drives from earlier versions of Windows
This policy setting is used to control whether access to drives is allowed by using the BitLocker To Go Reader,
and if the application is installed on the drive.
Policy description With this policy setting, you can configure whether fixed
data drives that are formatted with the FAT file system
can be unlocked and viewed on computers running
Windows Vista, Windows XP with Service Pack 3 (SP3), or
Windows XP with Service Pack 2 (SP2).


Conflicts None
When enabled and When not configured Fixed data drives that are formatted with the FAT file
system can be unlocked on computers running Windows
Server 2008, Windows Vista, Windows XP with SP3, or
Windows XP with SP2, and their content can be viewed.
These operating systems have Read-only access to
BitLocker-protected drives.
When disabled Fixed data drives that are formatted with the FAT file
system and are BitLocker-protected cannot be unlocked
on computers running Windows Vista, Windows XP with
SP3, or Windows XP with SP2. BitLocker To Go Reader
(bitlockertogo.exe) is not installed.
Reference
Note: This policy setting does not apply to drives that are formatted with the NTFS file system.
When this policy setting is enabled, select the Do not install BitLocker To Go Reader on FAT formatted fixed
drives check box to help prevent users from running BitLocker To Go Reader from their fixed drives. If BitLocker
To Go Reader (bitlockertogo.exe) is present on a drive that does not have an identification field specified, or if the
drive has the same identification field as specified in the Provide unique identifiers for your organization
policy setting, the user is prompted to update BitLocker, and BitLocker To Go Reader is deleted from the drive. In
this situation, for the fixed drive to be unlocked on computers running Windows Vista, Windows XP with SP3, or
Windows XP with SP2, BitLocker To Go Reader must be installed on the computer. If this check box is not
selected, BitLocker To Go Reader will be installed on the fixed drive to enable users to unlock the drive on
computers running Windows Vista, Windows XP with SP3, or Windows XP with SP2.
Allow access to BitLocker-protected removable data drives from earlier versions of Windows
This policy setting controls access to removable data drives that are using the BitLocker To Go Reader and
whether the BitLocker To Go Reader can be installed on the drive.
removable data drives that are formatted with the FAT
file system can be unlocked and viewed on computers
running Windows Vista, Windows XP with SP3, or
Windows XP with SP2.

Conflicts None
When enabled and When not configured Removable data drives that are formatted with the FAT
file system can be unlocked on computers running
Windows Vista, Windows XP with SP3, or Windows XP
with SP2, and their content can be viewed. These
operating systems have Read-only access to BitLocker-
protected drives.
When disabled Removable data drives that are formatted with the FAT
file system that are BitLocker-protected cannot be
unlocked on computers running Windows Vista,
Windows XP with SP3, or Windows XP with SP2.
BitLocker To Go Reader (bitlockertogo.exe) is not
installed.
Reference
Note: This policy setting does not apply to drives that are formatted with the NTFS file system.
When this policy setting is enabled, select the Do not install BitLocker To Go Reader on FAT formatted
removable drives check box to help prevent users from running BitLocker To Go Reader from their removable
drives. If BitLocker To Go Reader (bitlockertogo.exe) is present on a drive that does not have an identification
field specified, or if the drive has the same identification field as specified in the Provide unique identifiers for
your organization policy setting, the user will be prompted to update BitLocker, and BitLocker To Go Reader is
deleted from the drive. In this situation, for the removable drive to be unlocked on computers running Windows
Vista, Windows XP with SP3, or Windows XP with SP2, BitLocker To Go Reader must be installed on the
computer. If this check box is not selected, BitLocker To Go Reader will be installed on the removable drive to
enable users to unlock the drive on computers running Windows Vista, Windows XP with SP3, or Windows XP
with SP2 that do not have BitLocker To Go Reader installed.
FIPS setting
You can configure the Federal Information Processing Standard (FIPS) setting for FIPS compliance. As an effect of
FIPS compliance, users cannot create or save a BitLocker password for recovery or as a key protector. The use of
a recovery key is permitted.
Policy description Notes
Introduced Windows Server 2003 with SP1
Drive type System-wide

Policy path Local Policies\Security Options\System cryptography:
Use FIPS compliant algorithms for encryption,
hashing, and signing
Conflicts Some applications, such as Terminal Services, do not

support FIPS-140 on all operating systems.
When enabled Users will be unable to save a recovery password to any

location. This includes AD DS and network folders. In
addition, you cannot use WMI or the BitLocker Drive
Encryption Setup izard to create a recovery password.
When disabled or not configured No BitLocker encryption key is generated
Reference
This policy needs to be enabled before any encryption key is generated for BitLocker. Note that when this policy
is enabled, BitLocker prevents creating or using recovery passwords, so recovery keys should be used instead.
You can save the optional recovery key to a USB drive. Because recovery passwords cannot be saved to AD DS
when FIPS is enabled, an error is caused if AD DS backup is required by Group Policy.
You can edit the FIPS setting by using the Security Policy Editor (Secpol.msc) or by editing the Windows registry.
You must be an administrator to perform these procedures.
For more information about setting this policy, see System cryptography: Use FIPS compliant algorithms for
encryption, hashing, and signing.
Power management Group Policy settings: Sleep and Hibernate

PCs default power settings for a computer will cause the computer to enter Sleep mode frequently to conserve
power when idle and to help extend the systems battery life. When a computer transitions to Sleep, open
programs and documents are persisted in memory. When a computer resumes from Sleep, users are not
required to re-authenticate with a PIN or USB startup key to access encrypted data. This might lead to conditions
where data security is compromised.
However, when a computer hibernates the drive is locked, and when it resumes from hibernation the drive is
unlocked, which means that users will need to provide a PIN or a startup key if using multifactor authentication
with BitLocker. Therefore, organizations that use BitLocker may want to use Hibernate instead of Sleep for
improved security. This setting does not have an impact on TPM-only mode, because it provides a transparent
user experience at startup and when resuming from the Hibernate states.
You can use disable the following Group Policy settings, which are located in Computer
Configuration\Administrative Templates\System\Power Management to disable all available sleep states:
Allow Standby States (S1-S3) When Sleeping (Plugged In)
Allow Standby States (S1-S3) When Sleeping (Battery)
About the Platform Configuration Register (PCR)

A platform validation profile consists of a set of PCR indices that range from 0 to 23. The scope of the values can
be specific to the version of the operating system.
Changing from the default platform validation profile affects the security and manageability of your computer.
BitLockers sensitivity to platform modifications (malicious or authorized) is increased or decreased depending
on inclusion or exclusion (respectively) of the PCRs.
About PCR 7
PCR 7 measures the state of Secure Boot. With PCR 7, BitLocker can leverage Secure Boot for integrity validation.
Secure Boot ensures that the computer's preboot environment loads only firmware that is digitally signed by
authorized software publishers. PCR 7 measurements indicate whether Secure Boot is on and which keys are
trusted on the platform. If Secure Boot is on and the firmware measures PCR 7 correctly per the UEFI
specification, BitLocker can bind to this information rather than to PCRs 0, 2, and 4 which have the
measurements of the exact firmware and Bootmgr images loaded. This reduces the likelihood of BitLocker
starting in recovery mode as a result of firmware and image updates, and it provides you with greater flexibility
to manage the preboot configuration.
PCR 7 measurements must follow the guidance that is described in Appendix A Trusted Execution Environment
EFI Protocol.
PCR 7 measurements are a mandatory logo requirement for systems that support InstantGo (also known as
Always On, Always Connected PCs), such as the Microsoft Surface RT. On such systems, if the TPM with PCR 7
measurement and Secure Boot are correctly configured, BitLocker binds to PCR 7 and PCR 11 by default.
See also
BitLocker overview
Applies to
Windows 10
This topic for IT professionals describes the BCD settings that are used by BitLocker.
When protecting data at rest on an operating system volume, during the boot process BitLocker verifies that the
security sensitive boot configuration data (BCD) settings have not changed since BitLocker was last enabled,
resumed, or recovered.
BitLocker and BCD Settings

In Windows 7 and Windows Server 2008 R2, BitLocker validated nearly all BCD settings with the winload,
winresume, and memtest prefixes. However, this high degree of validation caused BitLocker to go into recovery
mode for benign setting changes, for example, when applying a language pack BitLocker would enter recovery.
In Windows 8, Windows Server 2012, and later operating systems BitLocker narrows the set of BCD settings
validated to reduce the chance of benign changes causing a BCD validation problem. If you believe that there is a
risk in excluding a particular BCD setting from the validation profile, you can increase BCD validation coverage to
suit your validation preferences. Alternatively, if a default BCD setting is persistently triggering recovery for benign
changes, then you can exclude that BCD setting from the validation profile.
When secure boot is enabled
Computers with UEFI firmware can use Secure Boot to provide enhanced boot security. When BitLocker is able to
use Secure Boot for platform and BCD integrity validation, as defined by the Allow Secure Boot for integrity
validation group policy setting, the Use enhanced Boot Configuration Data validation profile group policy
is ignored.
One of the benefits of using Secure Boot is that it can correct BCD settings during boot without triggering recovery
events. Secure Boot enforces the same BCD settings as BitLocker. Secure Boot BCD enforcement is not configurable
from within the operating system.
Customizing BCD validation settings

To modify the BCD settings BitLocker validates the IT Pro will add or exclude BCD settings from the platform
validation profile by enabling and configuring the Use enhanced Boot Configuration Data validation profile
Group Policy setting.
For the purposes of BitLocker validation, BCD settings are associated with a specific set of Microsoft boot
applications. BCD settings are either associated with a specific boot application or can apply to all boot applications
by associating a prefix to the BCD setting entered in the Group Policy setting. Prefix values include:
winload
winresume
memtest
all
All BCD settings are specified by combining the prefix value with either a hexadecimal (hex) value or a friendly
name.
The BCD setting hex value is reported when BitLocker enters recovery mode and is stored in the event log (event ID
523). The hex value uniquely identifies which BCD setting caused the recovery event.
You can quickly obtain the friendly name for the BCD settings on your computer by using the command
bcdedit.exe /enum all .
Not all BCD settings have friendly names, for those settings the hex value is the only way to configure an exclusion
policy.
When specifying BCD values in the Use enhanced Boot Configuration Data validation profile Group Policy
setting, use the following syntax:
Prefix the setting with the boot application prefix
Append a colon :
Append either the hex value or the friendly name
If entering more than one BCD setting, you will need to enter each BCD setting on a new line
For example, either winload:hypervisordebugport or winload:0x250000f4 yield the same value.
Setting that applies to all boot applications may be applied only to an individual application, however the reverse is
not true. For example, one can specify either: all:locale or winresume:locale , but as the bcd setting win-pe
does not apply to all boot applications, winload:winpe is valid, but all:winpe is not valid. The setting that
controls boot debugging ( bootdebug or 0x16000010) will always be validated and will have no effect if it is
included in the provided fields.
Note: Take care when configuring BCD entries in the Group Policy setting. The Local Group Policy Editor does
not validate the correctness of the BCD entry. BitLocker will fail to be enabled if the Group Policy setting
specified is invalid.
Default BCD validation profile

The following table contains the default BCD validation profile used by BitLocker in Windows 8, Windows Server
2012, and later operating systems:
HEX VALUE PREFIX FRIENDLY NAME
0x11000001 all device
0x12000002 all path
0x12000030 all loadoptions
0x16000010 all bootdebug
0x16000040 all advancedoptions
0x16000041 all optionsedit
0x16000048 all nointegritychecks
0x16000049 all testsigning
0x16000060 all isolatedcontext
0x1600007b all forcefipscrypto

0x22000002 winload systemroot
0x22000011 winload kernel
0x22000012 winload hal
0x22000053 winload evstore
0x25000020 winload nx
0x25000052 winload restrictapiccluster
0x26000022 winload winpe
0x26000025 winload lastknowngood
0x26000081 winload safebootalternateshell
0x260000a0 winload debug
0x260000f2 winload hypervisordebug
0x26000116 winload hypervisorusevapic
0x21000001 winresume filedevice
0x22000002 winresume filepath
0x26000006 winresume debugoptionenabled
Full list of friendly names for ignored BCD settings

This following is a full list of BCD settings with friendly names which are ignored by default. These settings are not
part of the default BitLocker validation profile, but can be added if you see a need to validate any of these settings
before allowing a BitLockerprotected operating system drive to be unlocked.
Note: Additional BCD settings exist that have hex values but do not have friendly names. These settings are not
included in this list.
0x12000004 all description
0x12000005 all locale
0x12000016 all targetname
0x12000019 all busparams
0x1200001d all key

0x1200004a all fontpath
0x14000006 all inherit
0x14000008 all recoverysequence
0x15000007 all truncatememory
0x1500000c all firstmegabytepolicy
0x1500000d all relocatephysical
0x1500000e all avoidlowmemory
0x15000011 all debugtype
0x15000012 all debugaddress
0x15000013 all debugport
0x15000014 all baudrate
0x15000015 all channel
0x15000018 all debugstart
0x1500001a all hostip
0x1500001b all port
0x15000022 all emsport
0x15000023 all emsbaudrate
0x15000042 all keyringaddress
0x15000047 all configaccesspolicy
0x1500004b all integrityservices
0x1500004c all volumebandid
0x15000051 all initialconsoleinput
0x15000052 all graphicsresolution
0x15000065 all displaymessage
0x15000066 all displaymessageoverride

0x16000009 all recoveryenabled
0x1600000b all badmemoryaccess
0x1600000f all traditionalkseg
0x16000017 all noumex
0x1600001c all dhcp
0x1600001e all vm
0x16000020 all bootems
0x16000046 all graphicsmodedisabled
0x16000050 all extendedinput
0x16000053 all restartonfailure
0x16000054 all highestmode
0x1600006c all bootuxdisabled
0x16000072 all nokeyboard
0x16000074 all bootshutdowndisabled
0x1700000a all badmemorylist
0x17000077 all allowedinmemorysettings
0x22000040 all fverecoveryurl
0x22000041 all fverecoverymessage
0x31000003 all ramdisksdidevice
0x32000004 all ramdisksdipath
0x35000001 all ramdiskimageoffset
0x35000002 all ramdisktftpclientport
0x35000005 all ramdiskimagelength
0x35000007 all ramdisktftpblocksize
0x35000008 all ramdisktftpwindowsize

0x36000006 all exportascd
0x36000009 all ramdiskmcenabled
0x3600000a all ramdiskmctftpfallback
0x3600000b all ramdisktftpvarwindow
0x21000001 winload osdevice
0x22000013 winload dbgtransport
0x220000f9 winload hypervisorbusparams
0x22000110 winload hypervisorusekey
0x23000003 winload resumeobject
0x25000021 winload pae
0x25000031 winload removememory
0x25000032 winload increaseuserva
0x25000033 winload perfmem
0x25000050 winload clustermodeaddressing
0x25000055 winload x2apicpolicy
0x25000061 winload numproc
0x25000063 winload configflags
0x25000066 winload groupsize
0x25000071 winload msi
0x25000072 winload pciexpress
0x25000080 winload safeboot
0x250000a6 winload tscsyncpolicy
0x250000c1 winload driverloadfailurepolicy
0x250000c2 winload bootmenupolicy
0x250000e0 winload bootstatuspolicy

0x250000f0 winload hypervisorlaunchtype
0x250000f3 winload hypervisordebugtype
0x250000f4 winload hypervisordebugport
0x250000f5 winload hypervisorbaudrate
0x250000f6 winload hypervisorchannel
0x250000f7 winload bootux
0x250000fa winload hypervisornumproc
0x250000fb winload hypervisorrootprocpernode
0x250000fd winload hypervisorhostip
0x250000fe winload hypervisorhostport
0x25000100 winload tpmbootentropy
0x25000113 winload hypervisorrootproc
0x25000115 winload hypervisoriommupolicy
0x25000120 winload xsavepolicy
0x25000121 winload xsaveaddfeature0
0x25000129 winload xsaveremovefeature
0x2500012a winload xsaveprocessorsmask
0x2500012b winload xsavedisable

0x25000130 winload claimedtpmcounter
0x26000004 winload stampdisks
0x26000010 winload detecthal
0x26000024 winload nocrashautoreboot
0x26000030 winload nolowmem
0x26000040 winload vga
0x26000041 winload quietboot
0x26000042 winload novesa
0x26000043 winload novga
0x26000051 winload usephysicaldestination
0x26000054 winload uselegacyapicmode
0x26000060 winload onecpu
0x26000062 winload maxproc
0x26000064 winload maxgroup
0x26000065 winload groupaware
0x26000070 winload usefirmwarepcisettings
0x26000090 winload bootlog
0x26000091 winload sos
0x260000a1 winload halbreakpoint
0x260000a2 winload useplatformclock
0x260000a3 winload forcelegacyplatform
0x260000a4 winload useplatformtick
0x260000a5 winload disabledynamictick
0x260000b0 winload ems
0x260000c3 winload onetimeadvancedoptions

0x260000c4 winload onetimeoptionsedit
0x260000e1 winload disableelamdrivers
0x260000f8 winload hypervisordisableslat
0x260000fc winload hypervisoruselargevtlb
0x26000114 winload hypervisordhcp
0x21000005 winresume associatedosdevice
0x25000007 winresume bootux
0x25000008 winresume bootmenupolicy
0x26000003 winresume customsettings
0x26000004 winresume pae
0x25000001 memtest passcount
0x25000002 memtest testmix
0x25000005 memtest stridefailcount
0x25000006 memtest invcfailcount
0x25000007 memtest matsfailcount
0x25000008 memtest randfailcount
0x25000009 memtest chckrfailcount
0x26000003 memtest cacheenable
0x26000004 memtest failuresenabled

BitLocker recovery guide
Applies to
Windows 10
This topic for IT professionals describes how to recover BitLocker keys from AD DS.
Organizations can use BitLocker recovery information saved in Active Directory Domain Services (AD DS) to access
BitLocker-protected data. Creating a recovery model for BitLocker while you are planning your BitLocker
deployment is recommended.
This article assumes that you understand how to set up AD DS to back up BitLocker recovery information
automatically, and what types of recovery information are saved to AD DS.
This article does not detail how to configure AD DS to store the BitLocker recovery information.
This article contains the following topics:
What Is BitLocker Recovery?
Testing Recovery
Planning Your Recovery Process
Using Additional Recovery Information
Resetting Recovery Passwords
Retrieving the BitLocker Key Package
What is BitLocker recovery?

BitLocker recovery is the process by which you can restore access to a BitLocker-protected drive in the event that
you cannot unlock the drive normally. In a recovery scenario you have the following options to restore access to
the drive:
The user can supply the recovery password. If your organization allows users to print or store recovery
passwords, the user can type in the 48-digit recovery password that they printed or stored on a USB drive or
with your Microsoft Account online. (Saving a recovery password with your Microsoft Account online is only
allowed when BitLocker is used on a PC that is not a member of a domain).
A data recovery agent can use their credentials to unlock the drive. If the drive is an operating system drive, the
drive must be mounted as a data drive on another computer for the data recovery agent to unlock it.
A domain administrator can obtain the recovery password from AD DS and use it to unlock the drive. Storing
recovery passwords in AD DS is recommended to provide a way for IT professionals to be able to obtain
recovery passwords for drives in their organization if needed. This method requires that you have enabled this
recovery method in the BitLocker Group Policy setting Choose how BitLocker-protected operating system
drives can be recovered located at Computer Configuration\Administrative Templates\Windows
Components\BitLocker Drive Encryption\Operating System Drives in the Local Group Policy Editor. For
more information, see BitLocker Group Policy settings.
What causes BitLocker recovery?
The following list provides examples of specific events that will cause BitLocker to enter recovery mode when
attempting to start the operating system drive:
On PCs that use either BitLocker or Device Encryption, when an attack is detected, the device will immediately
reboot and enter into BitLocker recovery mode. To take advantage of this functionality Administrators can set
the Interactive logon: Machine account lockout threshold Group Policy setting located in \Computer
Configuration\Windows Settings\Security Settings\Local Policies\Security Options in the Local Group
Policy Editor, or use the MaxFailedPasswordAttempts policy of Exchange ActiveSync (also configurable
through Windows Intune), to limit the number of failed password attempts before the device goes into Device
Lockout.
On devices with TPM 1.2, changing the BIOS or firmware boot device order causes BitLocker recovery.
However, devices with TPM 2.0 do not start BitLocker recovery in this case. TPM 2.0 does not consider a
firmware change of boot device order as a security threat because the OS Boot Loader is not compromised.
Having the CD or DVD drive before the hard drive in the BIOS boot order and then inserting or removing a CD
or DVD.
Failing to boot from a network drive before booting from the hard drive.
Docking or undocking a portable computer. In some instances (depending on the computer manufacturer and
the BIOS), the docking condition of the portable computer is part of the system measurement and must be
consistent to validate the system status and unlock BitLocker. This means that if a portable computer is
connected to its docking station when BitLocker is turned on, then it might also need to be connected to the
docking station when it is unlocked. Conversely, if a portable computer is not connected to its docking station
when BitLocker is turned on, then it might need to be disconnected from the docking station when it is
unlocked.
Changes to the NTFS partition table on the disk including creating, deleting, or resizing a primary partition.
Entering the personal identification number (PIN) incorrectly too many times so that the anti-hammering logic
of the TPM is activated. Anti-hammering logic is software or hardware methods that increase the difficulty and
cost of a brute force attack on a PIN by not accepting PIN entries until after a certain amount of time has
passed.
Turning off the support for reading the USB device in the pre-boot environment from the BIOS or UEFI
firmware if you are using USB-based keys instead of a TPM.
Turning off, disabling, deactivating, or clearing the TPM.
Upgrading critical early startup components, such as a BIOS or UEFI firmware upgrade, causing the related boot
measurements to change.
Forgetting the PIN when PIN authentication has been enabled.
Updating option ROM firmware.
Upgrading TPM firmware.
Adding or removing hardware; for example, inserting a new card in the computer, including some PCMIA
wireless cards.
Removing, inserting, or completely depleting the charge on a smart battery on a portable computer.
Changes to the master boot record on the disk.
Changes to the boot manager on the disk.
Hiding the TPM from the operating system. Some BIOS or UEFI settings can be used to prevent the
enumeration of the TPM to the operating system. When implemented, this option can make the TPM hidden
from the operating system. When the TPM is hidden, BIOS and UEFI secure startup are disabled, and the TPM
does not respond to commands from any software.
Using a different keyboard that does not correctly enter the PIN or whose keyboard map does not match the
keyboard map assumed by the pre-boot environment. This can prevent the entry of enhanced PINs.
Modifying the Platform Configuration Registers (PCRs) used by the TPM validation profile. For example,
including PCR[1] would result in BitLocker measuring most changes to BIOS settings, causing BitLocker to
enter recovery mode even when non-boot critical BIOS settings change.
Note: Some computers have BIOS settings that skip measurements to certain PCRs, such as PCR[2].
Changing this setting in the BIOS would cause BitLocker to enter recovery mode because the PCR
measurement will be different.
Moving the BitLocker-protected drive into a new computer.
Upgrading the motherboard to a new one with a new TPM.
Losing the USB flash drive containing the startup key when startup key authentication has been enabled.
Failing the TPM self-test.
Having a BIOS, UEFI firmware, or an option ROM component that is not compliant with the relevant Trusted
Computing Group standards for a client computer. For example, a non-compliant implementation may record
volatile data (such as time) in the TPM measurements, causing different measurements on each startup and
causing BitLocker to start in recovery mode.
Changing the usage authorization for the storage root key of the TPM to a non-zero value.
Note: The BitLocker TPM initialization process sets the usage authorization value to zero, so another
user or process must explicitly have changed this value.
Disabling the code integrity check or enabling test signing on Windows Boot Manager (Bootmgr).
Pressing the F8 or F10 key during the boot process.
Adding or removing add-in cards (such as video or network cards), or upgrading firmware on add-in cards.
Using a BIOS hot key during the boot process to change the boot order to something other than the hard drive.
Note: Before you begin recovery, we recommend that you determine what caused recovery. This might help
prevent the problem from occurring again in the future. For instance, if you determine that an attacker has
modified your computer by obtaining physical access, you can create new security policies for tracking who
has physical presence. After the recovery password has been used to recover access to the PC, BitLocker will
reseal the encryption key to the current values of the measured components.
For planned scenarios, such as a known hardware or firmware upgrades, you can avoid initiating recovery by
temporarily suspending BitLocker protection. Because suspending BitLocker leaves the drive fully encrypted, the
administrator can quickly resume BitLocker protection after the planned task has been completed. Using suspend
and resume also reseals the encryption key without requiring the entry of the recovery key.
Note: If suspended BitLocker will automatically resume protection when the PC is rebooted, unless a reboot
count is specified using the manage-bde command line tool.
If software maintenance requires the computer be restarted and you are using two-factor authentication, you can
enable BitLocker Network Unlock to provide the secondary authentication factor when the computers do not have
an on-premise user to provide the additional authentication method.
Recovery has been described within the context of unplanned or undesired behavior, but you can also cause
recovery as an intended production scenario, in order to manage access control. For example, when you redeploy
desktop or laptop computers to other departments or employees in your enterprise, you can force BitLocker into
recovery before the computer is given to a new user.
Testing recovery
Before you create a thorough BitLocker recovery process, we recommend that you test how the recovery process
works for both end users (people who call your helpdesk for the recovery password) and administrators (people
who help the end user get the recovery password). The forcerecovery command of manage-bde is an easy way
for you to step through the recovery process before your users encounter a recovery situation.
To force a recovery for the local computer
1. Click the Start button, type cmd in the Start Search box, right-click cmd.exe, and then click Run as
administrator.
2. At the command prompt, type the following command and then press ENTER:
manage-bde -forcerecovery <Volume>
To force recovery for a remote computer

1. On the Start screen, type cmd.exe, and then click Run as administrator.
2. At the command prompt, type the following command and then press ENTER:
manage-bde. -ComputerName <ComputerName> -forcerecovery <Volume>
Note: ComputerName represents the name of the remote computer. Volume represents the volume on the
remote computer that is protected with BitLocker.
Planning your recovery process

When planning the BitLocker recovery process, first consult your organization's current best practices for
recovering sensitive information. For example: How does your enterprise handle lost Windows passwords? How
does your organization perform smart card PIN resets? You can use these best practices and related resources
(people and tools) to help formulate a BitLocker recovery model.
Organizations that rely on BitLocker Drive Encryption and BitLocker To Go to protect data on a large number of
computers and removable drives running the Windows 10, Windows 8, or Windows 7 operating systems and
Windows to Go should consider using the Microsoft BitLocker Administration and Monitoring (MBAM) Tool
version 2.0, which is included in the Microsoft Desktop Optimization Pack (MDOP) for Microsoft Software
Assurance. MBAM makes BitLocker implementations easier to deploy and manage and allows administrators to
provision and monitor encryption for operating system and fixed drives. MBAM prompts the user before
encrypting fixed drives. MBAM also manages recovery keys for fixed and removable drives, making recovery
easier to manage. MBAM can be used as part of a Microsoft System Center deployment or as a stand-alone
solution. For more info, see Microsoft BitLocker Administration and Monitoring.
After a BitLocker recovery has been initiated, users can use a recovery password to unlock access to encrypted
data. You must consider both self-recovery and recovery password retrieval methods for your organization.
When you determine your recovery process, you should:
Become familiar with how you can retrieve the recovery password. See:
Self-recovery
Recovery password retrieval
Determine a series of steps for post-recovery, including analyzing why the recovery occurred and resetting
the recovery password. See:
Post-recovery analysis
Self-recovery
In some cases, users might have the recovery password in a printout or a USB flash drive and can perform self-
recovery. We recommend that your organization create a policy for self-recovery. If self-recovery includes using a
password or recovery key stored on a USB flash drive, the users should be warned not to store the USB flash drive
in the same place as the PC, especially during travel, for example if both the PC and the recovery items are in the
same bag it would be very easy for access to be gained to the PC by an unauthorized user. Another policy to
consider is having users contact the Helpdesk before or after performing self-recovery so that the root cause can
be identified.
Recovery password retrieval
If the user does not have a recovery password in a printout or on a USB flash drive, the user will need to be able to
retrieve the recovery password from an online source. If the PC is a member of a domain the recovery password
can be backed up to AD DS. However, this does not happen by default, you must have configured the appropriate
Group Policy settings before BitLocker was enabled on the PC. BitLocker Group Policy settings can be found in the
Local Group Policy Editor or the Group Policy Management Console (GPMC) under Computer
Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption. The
following policy settings define the recovery methods that can be used to restore access to a BitLocker-protected
drive if an authentication method fails or is unable to be used.
Choose how BitLocker-protected removable drives can be recovered In each of these policies, select
Save BitLocker recovery information to Active Directory Domain Services and then choose which
BitLocker recovery information to store in Active Directory Domain Services (AD DS). Select the Do not enable
BitLocker until recovery information is stored in AD DS check box if you want to prevent users from
enabling BitLocker unless the computer is connected to the domain and the backup of BitLocker recovery
information for the drive to AD DS succeeds.
Note: If the PCs are part of a workgroup, users should be advised to save their BitLocker recovery password
with their Microsoft Account online. Having an online copy of your BitLocker recovery password is
recommended to help ensure that you do not lose access to your data in the event that recovery is required.
The BitLocker Recovery Password Viewer for Active Directory Users and Computers tool allows domain
administrators to view BitLocker recovery passwords for specific computer objects in Active Directory.
You can use the following list as a template for creating your own recovery process for recovery password
retrieval. This sample process uses the BitLocker Recovery Password Viewer for Active Directory Users and
Computers tool.
Record the name of the user's computer
Verify the user's identity
Locate the recovery password in AD DS
Gather information to determine why recovery occurred
Give the user the recovery password
Record the name of the user's computer
You can use the name of the user's computer to locate the recovery password in AD DS. If the user does not know
the name of the computer, ask the user to read the first word of the Drive Label in the BitLocker Drive
Encryption Password Entry user interface. This is the computer name when BitLocker was enabled and is
probably the current name of the computer.
Verify the user's identity
You should verify that the person that is asking for the recovery password is truly the authorized user of that
computer. You may also wish to verify that the computer with the name the user provided belongs to the user.
Locate the recovery password in AD DS
Locate the Computer object with the matching name in AD DS. Because Computer object names are listed in the
AD DS global catalog, you should be able to locate the object even if you have a multi-domain forest.
Multiple recovery passwords
If multiple recovery passwords are stored under a computer object in AD DS, the name of the BitLocker recovery
information object includes the date that the password was created.
If at any time you are unsure what password to provide, or if you think you might be providing the incorrect
password, ask the user to read the eight character password ID that is displayed in the recovery console.
Since the password ID is a unique value that is associated with each recovery password stored in AD DS, running a
query using this ID will find the correct password to unlock the encrypted volume.
Gather information to determine why recovery occurred
Before you give the user the recovery password, you should gather any information that will help determine why
the recovery was needed, in order to analyze the root cause during the post-recovery analysis. For more info about
post-recovery analysis, see Post-recovery analysis.
Give the user the recovery password
Because the recovery password is 48 digits long the user may need to record the password by writing it down or
typing it on a different computer. If you are using MBAM, the recovery password will be regenerated after it is
recovered from the MBAM database to avoid the security risks associated with an uncontrolled password.
Note: Because the 48-digit recovery password is long and contains a combination of digits, the user might
mishear or mistype the password. The boot-time recovery console uses built-in checksum numbers to detect
input errors in each 6-digit block of the 48-digit recovery password, and offers the user the opportunity to
correct such errors.
Post-recovery analysis
When a volume is unlocked using a recovery password, an event is written to the event log and the platform
validation measurements are reset in the TPM to match the current configuration. Unlocking the volume means
that the encryption key has been released and is ready for on-the-fly encryption when data is written to the
volume, and on-the-fly decryption when data is read from the volume. After the volume is unlocked, BitLocker
behaves the same way, regardless of how the access was granted.
If you notice that a computer is having repeated recovery password unlocks, you might want to have an
administrator can perform post-recovery analysis to determine the root cause of the recovery and refresh
BitLocker platform validation so that the user no longer needs to enter a recovery password each time that the
computer starts up. See:
Determine the root cause of the recovery
Refresh BitLocker protection
Determine the root cause of the recovery
If a user needed to recover the drive, it is important to determine the root cause that initiated the recovery as soon
as possible. Properly analyzing the state of the computer and detecting tampering may reveal threats that have
broader implications for enterprise security.
While an administrator can remotely investigate the cause of recovery in some cases, the end user might need to
bring the computer that contains the recovered drive on site to analyze the root cause further.
Review and answer the following questions for your organization:
1. What BitLocker protection mode is in effect (TPM, TPM + PIN, TPM + startup key, startup key only)? Which PCR
profile is in use on the PC?
2. Did the user merely forget the PIN or lose the startup key? If a token was lost, where might the token be?
3. If TPM mode was in effect, was recovery caused by a boot file change?
4. If recovery was caused by a boot file change, is this due to an intended user action (for example, BIOS upgrade),
or to malicious software?
5. When was the user last able to start the computer successfully, and what might have happened to the
computer since then?
6. Might the user have encountered malicious software or left the computer unattended since the last successful
startup?
To help you answer these questions, use the BitLocker command-line tool to view the current configuration and
protection mode (for example, manage-bde -status). Scan the event log to find events that help indicate why
recovery was initiated (for example, if boot file change occurred). Both of these capabilities can be performed
remotely.
Resolve the root cause
After you have identified what caused recovery, you can reset BitLocker protection and avoid recovery on every
startup.
The details of this reset can vary according to the root cause of the recovery. If you cannot determine the root
cause, or if malicious software or a rootkit might have infected the computer, Helpdesk should apply best-practice
virus policies to react appropriately.
Note: You can perform a BitLocker validation profile reset by suspending and resuming BitLocker.
Unknown PIN
Lost startup key
Changes to boot files ### Unknown PIN
If a user has forgotten the PIN, you must reset the PIN while you are logged on to the computer in order to
prevent BitLocker from initiating recovery each time the computer is restarted.
To prevent continued recovery due to an unknown PIN
1. Unlock the computer using the recovery password.
2. Reset the PIN:
a. Right-click the drive and then click Change PIN
b. In the BitLocker Drive Encryption dialog, click Reset a forgotten PIN. If you are not logged in with an
administrator account you must provide administrative credentials at this time.
c. In the PIN reset dialog, provide and confirm the new PIN to use and then click Finish.
3. You will use the new PIN the next time you unlock the drive.
Lost startup key
If you have lost the USB flash drive that contains the startup key, then you must unlock the drive by using the
recovery key and then create a new startup key.
To prevent continued recovery due to a lost startup key
1. Log on as an administrator to the computer that has the lost startup key.
2. Open Manage BitLocker.
3. Click Duplicate start up key, insert the clean USB drive on which you are going to write the key and then click
Save.
Changes to boot files
This error might occur if you updated the firmware. As a best practice you should suspend BitLocker before
making changes the firmware and then resume protection after the update has completed. This prevents the
computer from going into recovery mode. However if changes were made when BitLocker protection was on you
can simply log on to the computer using the recovery password and the platform validation profile will be updated
so that recovery will not occur the next time.
Windows RE and BitLocker

Windows Recovery Environment (RE) can be used to recover access to a drive protected by BitLocker or by Device
Encryption. If a PC is unable to boot after two failures, Startup Repair will automatically start. When Startup Repair
is launched automatically due to boot failures, it will only execute operating system and driver file repairs,
provided that the boot logs or any available crash dump point to a specific corrupted file. In Windows 8.1 and later,
devices that include firmware to support specific TPM measurements for PCR[7] the TPM can validate that
Windows RE is a trusted operating environment and will unlock any BitLocker-protected drives if Windows RE has
not been modified. If the Windows RE environment has been modified, for example the TPM has been disabled,
the drives will stay locked until the BitLocker recovery key is provided. If Startup Repair is not able to be run
automatically from the PC and instead Windows RE is manually started from a repair disk, the BitLocker recovery
key must be provided to unlock the BitLockerprotected drives.
Using additional recovery information

Besides the 48-digit BitLocker recovery password, other types of recovery information are stored in Active
Directory. This section describes how this additional information can be used.
BitLocker key package
If the recovery methods discussed earlier in this document do not unlock the volume, you can use the BitLocker
Repair tool to decrypt the volume at the block level. The tool uses the BitLocker key package to help recover
encrypted data from severely damaged drives. You can then use this recovered data to salvage encrypted data,
even after the correct recovery password has failed to unlock the damaged volume. We recommend that you still
save the recovery password. A key package cannot be used without the corresponding recovery password.
Note: You must use the BitLocker Repair tool repair-bde to use the BitLocker key package.
The BitLocker key package is not saved by default. To save the package along with the recovery password in AD DS
you must select the Backup recovery password and key package option in the Group Policy settings that
control the recovery method. You can also export the key package from a working volume. For more details on
how to export key packages, see Retrieving the BitLocker Key Package.
Resetting recovery passwords

You should invalidate a recovery password after it has been provided and used. It should also be done when you
intentionally want to invalidate an existing recovery password for any reason.
You can reset the recovery password in two ways:
Use manage-bde You can use manage-bde to remove the old recovery password and add a new recovery
password. The procedure identifies the command and the syntax for this method.
Run a script You can run a script to reset the password without decrypting the volume. The sample script in
the procedure illustrates this functionality. The sample script creates a new recovery password and invalidates
all other passwords.
To reset a recovery password using manage-bde
1. Remove the previous recovery password
Manage-bde protectors delete C: type RecoveryPassword
2. Add the new recovery password
Manage-bde protectors add C: -RecoveryPassword
3. Get the ID of the new recovery password. From the screen copy the ID of the recovery password.
Manage-bde protectors get C: -Type RecoveryPassword
4. Backup the new recovery password to AD DS
Manage-bde protectors adbackup C: -id {EXAMPLE6-5507-4924-AA9E-AFB2EB003692}
Warning: You must include the braces in the ID string.
To run the sample recovery password script

1. Save the following sample script in a VBScript file. For example: ResetPassword.vbs.
2. At the command prompt, type a command similar to the following:
cscript ResetPassword.vbs
Important: This sample script is configured to work only for the C volume. You must customize the script to
match the volume where you want to test password reset.
Note: To manage a remote computer, you can specify the remote computer name rather than the local
computer name.
You can use the following sample script to create a VBScript file to reset the recovery passwords.
' Target drive letter

strDriveLetter = "c:"
' Target computer name
' Use "." to connect to the local computer
strComputerName = "."
' --------------------------------------------------------------------------------
' Connect to the BitLocker WMI provider class
' --------------------------------------------------------------------------------
strConnectionStr = "winmgmts:" _
& "{impersonationLevel=impersonate,authenticationLevel=pktPrivacy}!\\" _
& strComputerName _
& "\root\cimv2\Security\MicrosoftVolumeEncryption"
On Error Resume Next 'handle permission errors

Set objWMIService = GetObject(strConnectionStr)
If Err.Number <> 0 Then
WScript.Echo "Failed to connect to the BitLocker interface (Error 0x" & Hex(Err.Number) & ")."
Wscript.Echo "Ensure that you are running with administrative privileges."
WScript.Quit -1
End If
On Error GoTo 0
strQuery = "Select * from Win32_EncryptableVolume where DriveLetter='" & strDriveLetter & "'"
Set colTargetVolumes = objWMIService.ExecQuery(strQuery)
If colTargetVolumes.Count = 0 Then
WScript.Echo "FAILURE: Unable to find BitLocker-capable drive " & strDriveLetter & " on computer " &
strComputerName & "."
WScript.Quit -1
End If
' there should only be one volume found
For Each objFoundVolume in colTargetVolumes
set objVolume = objFoundVolume
Next
' objVolume is now our found BitLocker-capable disk volume
' --------------------------------------------------------------------------------
' Perform BitLocker WMI provider functionality
' --------------------------------------------------------------------------------
' Add a new recovery password, keeping the ID around so it doesn't get deleted later
' Add a new recovery password, keeping the ID around so it doesn't get deleted later
' ----------------------------------------------------------------------------------
nRC = objVolume.ProtectKeyWithNumericalPassword("Recovery Password Refreshed By Script", , sNewKeyProtectorID)
If nRC <> 0 Then
WScript.Echo "FAILURE: ProtectKeyWithNumericalPassword failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
' Removes the other, "stale", recovery passwords
' ----------------------------------------------------------------------------------
nKeyProtectorTypeIn = 3 ' type associated with "Numerical Password" protector
nRC = objVolume.GetKeyProtectors(nKeyProtectorTypeIn, aKeyProtectorIDs)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectors failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
' Delete those key protectors other than the one we just added.
For Each sKeyProtectorID In aKeyProtectorIDs
If sKeyProtectorID <> sNewKeyProtectorID Then
nRC = objVolume.DeleteKeyProtector(sKeyProtectorID)
If nRC <> 0 Then
WScript.Echo "FAILURE: DeleteKeyProtector on ID " & sKeyProtectorID & " failed with return code 0x" & Hex(nRC)
WScript.Quit -1
Else
' no output
'WScript.Echo "SUCCESS: Key protector with ID " & sKeyProtectorID & " deleted"
End If
End If
Next
WScript.Echo "A new recovery password has been added. Old passwords have been removed."
' - some advanced output (hidden)
'WScript.Echo ""
'WScript.Echo "Type ""manage-bde -protectors -get " & strDriveLetter & " -type recoverypassword"" to view
existing passwords."
Retrieving the BitLocker key package

You can use two methods to retrieve the key package, as described in Using Additional Recovery Information:
Export a previously-saved key package from AD DS. You must have Read access to BitLocker recovery
passwords that are stored in AD DS.
Export a new key package from an unlocked, BitLocker-protected volume. You must have local
administrator access to the working volume, before any damage has occurred.
The following sample script exports all previously-saved key packages from AD DS.
To run the sample key package retrieval script
1. Save the following sample script in a VBScript file. For example: GetBitLockerKeyPackageADDS.vbs.
2. At the command prompt, type a command similar to the following:
cscript GetBitLockerKeyPackageADDS.vbs -?
You can use the following sample script to create a VBScript file to retrieve the BitLocker key package from AD DS.
' --------------------------------------------------------------------------------
' Usage
' --------------------------------------------------------------------------------
Sub ShowUsage
Wscript.Echo "USAGE: GetBitLockerKeyPackageADDS [Path To Save Key Package] [Optional Computer Name]"
Wscript.Echo "If no computer name is specified, the local computer is assumed."
Wscript.Echo
Wscript.Echo "Example: GetBitLockerKeyPackageADDS E:\bitlocker-ad-key-package mycomputer"
WScript.Quit
End Sub
' --------------------------------------------------------------------------------
' Parse Arguments
' --------------------------------------------------------------------------------
Set args = WScript.Arguments
Select Case args.Count
Case 1
If args(0) = "/?" Or args(0) = "-?" Then
ShowUsage
Else
strFilePath = args(0)
' Get the name of the local computer
Set objNetwork = CreateObject("WScript.Network")
strComputerName = objNetwork.ComputerName
End If
Case 2
ShowUsage
Else
strComputerName = args(1)
End If
Case Else
ShowUsage
End Select
' --------------------------------------------------------------------------------
' Get path to Active Directory computer object associated with the computer name
' --------------------------------------------------------------------------------
Function GetStrPathToComputer(strComputerName)
' Uses the global catalog to find the computer in the forest
' Search also includes deleted computers in the tombstone
Set objRootLDAP = GetObject("LDAP://rootDSE")
namingContext = objRootLDAP.Get("defaultNamingContext") ' e.g. string dc=fabrikam,dc=com
strBase = "<GC://" & namingContext & ">"
Set objConnection = CreateObject("ADODB.Connection")

Set objCommand = CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOOBject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection
strFilter = "(&(objectCategory=Computer)(cn=" & strComputerName & "))"
strQuery = strBase & ";" & strFilter & ";distinguishedName;subtree"
objCommand.CommandText = strQuery
objCommand.Properties("Page Size") = 100
objCommand.Properties("Timeout") = 100
objCommand.Properties("Cache Results") = False
' Enumerate all objects found.
Set objRecordSet = objCommand.Execute
If objRecordSet.EOF Then
WScript.echo "The computer name '" & strComputerName & "' cannot be found."
WScript.Quit 1
End If
' Found object matching name
Do Until objRecordSet.EOF
dnFound = objRecordSet.Fields("distinguishedName")
GetStrPathToComputer = "LDAP://" & dnFound
objRecordSet.MoveNext
Loop
' Clean up.
Set objConnection = Nothing
Set objCommand = Nothing
Set objRecordSet = Nothing
End Function
' --------------------------------------------------------------------------------
' Securely access the Active Directory computer object using Kerberos
' --------------------------------------------------------------------------------
Set objDSO = GetObject("LDAP:")
strPathToComputer = GetStrPathToComputer(strComputerName)
WScript.Echo "Accessing object: " + strPathToComputer
Const ADS_SECURE_AUTHENTICATION = 1
Const ADS_USE_SEALING = 64 '0x40
Const ADS_USE_SIGNING = 128 '0x80
' --------------------------------------------------------------------------------
' Get all BitLocker recovery information from the Active Directory computer object
' --------------------------------------------------------------------------------
' Get all the recovery information child objects of the computer object
Set objFveInfos = objDSO.OpenDSObject(strPathToComputer, vbNullString, vbNullString, _
ADS_SECURE_AUTHENTICATION + ADS_USE_SEALING + ADS_USE_SIGNING)
objFveInfos.Filter = Array("msFVE-RecoveryInformation")
' Iterate through each recovery information object and saves any existing key packages
nCount = 1
strFilePathCurrent = strFilePath & nCount
For Each objFveInfo in objFveInfos
strName = objFveInfo.Get("name")
strRecoveryPassword = objFveInfo.Get("msFVE-RecoveryPassword")
strKeyPackage = objFveInfo.Get("msFVE-KeyPackage")
WScript.echo
WScript.echo "Recovery Object Name: " + strName
WScript.echo "Recovery Password: " + strRecoveryPassword
' Validate file path
Set fso = CreateObject("Scripting.FileSystemObject")
If (fso.FileExists(strFilePathCurrent)) Then
WScript.Echo "The file " & strFilePathCurrent & " already exists. Please use a different path."
WScript.Quit -1
End If
' Save binary data to the file
SaveBinaryDataText strFilePathCurrent, strKeyPackage
WScript.echo "Related key package successfully saved to " + strFilePathCurrent

' Update next file path using base name
nCount = nCount + 1
strFilePathCurrent = strFilePath & nCount
Next
'----------------------------------------------------------------------------------------
' Utility functions to save binary data
'----------------------------------------------------------------------------------------
Function SaveBinaryDataText(FileName, ByteArray)
'Create FileSystemObject object
Dim FS: Set FS = CreateObject("Scripting.FileSystemObject")
'Create text stream object

Dim TextStream
Set TextStream = FS.CreateTextFile(FileName)
'Convert binary data To text And write them To the file

TextStream.Write BinaryToString(ByteArray)
End Function
Function BinaryToString(Binary)
Dim I, S
For I = 1 To LenB(Binary)
S = S & Chr(AscB(MidB(Binary, I, 1)))
Next
BinaryToString = S
End Function
WScript.Quit
The following sample script exports a new key package from an unlocked, encrypted volume.
To run the sample key package retrieval script
1. Save the following sample script in a VBScript file. For example: GetBitLockerKeyPackage.vbs
2. Open an administrator command prompt, type a command similar to the following:
cscript GetBitLockerKeyPackage.vbs -?
' --------------------------------------------------------------------------------
' --------------------------------------------------------------------------------
' Usage
' --------------------------------------------------------------------------------
Sub ShowUsage
Wscript.Echo "USAGE: GetBitLockerKeyPackage [VolumeLetter/DriveLetter:] [Path To Save Key Package]"
Wscript.Echo
Wscript.Echo "Example: GetBitLockerKeyPackage C: E:\bitlocker-backup-key-package"
WScript.Quit
End Sub
' --------------------------------------------------------------------------------
' Parse Arguments
' --------------------------------------------------------------------------------
Set args = WScript.Arguments
Select Case args.Count
Case 2
ShowUsage
Else
strDriveLetter = args(0)
End If
Case Else
ShowUsage
End Select
' --------------------------------------------------------------------------------
' Other Inputs
' --------------------------------------------------------------------------------
' Target computer name
' Use "." to connect to the local computer
strComputerName = "."
' Default key protector ID to use. Specify "" to let the script choose.
strDefaultKeyProtectorID = ""
' strDefaultKeyProtectorID = "{001298E0-870E-4BA0-A2FF-FC74758D5720}" ' sample
' --------------------------------------------------------------------------------
' Connect to the BitLocker WMI provider class
' --------------------------------------------------------------------------------
strConnectionStr = "winmgmts:" _
& "{impersonationLevel=impersonate,authenticationLevel=pktPrivacy}!\\" _
& strComputerName _
& "\root\cimv2\Security\MicrosoftVolumeEncryption"
On Error Resume Next 'handle permission errors

Set objWMIService = GetObject(strConnectionStr)
If Err.Number <> 0 Then
WScript.Echo "Failed to connect to the BitLocker interface (Error 0x" & Hex(Err.Number) & ")."
Wscript.Echo "Ensure that you are running with administrative privileges."
WScript.Quit -1
End If
On Error GoTo 0
strQuery = "Select * from Win32_EncryptableVolume where DriveLetter='" & strDriveLetter & "'"
Set colTargetVolumes = objWMIService.ExecQuery(strQuery)
If colTargetVolumes.Count = 0 Then
WScript.Echo "FAILURE: Unable to find BitLocker-capable drive " & strDriveLetter & " on computer " &
strComputerName & "."
WScript.Quit -1
End If
' there should only be one volume found
For Each objFoundVolume in colTargetVolumes
set objVolume = objFoundVolume
Next
' objVolume is now our found BitLocker-capable disk volume
' --------------------------------------------------------------------------------
' Perform BitLocker WMI provider functionality
' --------------------------------------------------------------------------------
' Collect all possible valid key protector ID's that can be used to get the package
' ----------------------------------------------------------------------------------
nNumericalKeyProtectorType = 3 ' type associated with "Numerical Password" protector
nRC = objVolume.GetKeyProtectors(nNumericalKeyProtectorType, aNumericalKeyProtectorIDs)
If nRC <> 0 Then
WScript.Quit -1
End If
nExternalKeyProtectorType = 2 ' type associated with "External Key" protector
nRC = objVolume.GetKeyProtectors(nExternalKeyProtectorType, aExternalKeyProtectorIDs)
If nRC <> 0 Then
WScript.Quit -1
End If
' Get first key protector of the type "Numerical Password" or "External Key", if any
' ----------------------------------------------------------------------------------
if strDefaultKeyProtectorID = "" Then
' Save first numerical password, if exists
If UBound(aNumericalKeyProtectorIDs) <> -1 Then
strDefaultKeyProtectorID = aNumericalKeyProtectorIDs(0)
End If
' No numerical passwords exist, save the first external key
If strDefaultKeyProtectorID = "" and UBound(aExternalKeyProtectorIDs) <> -1 Then
strDefaultKeyProtectorID = aExternalKeyProtectorIDs(0)
End If
' Fail case: no recovery key protectors exist.
If strDefaultKeyProtectorID = "" Then
WScript.Echo "FAILURE: Cannot create backup key package because no recovery passwords or recovery keys exist.
Check that BitLocker protection is on for this drive."
WScript.Echo "For help adding recovery passwords or recovery keys, type ""manage-bde -protectors -add -?""."
WScript.Quit -1
End If
End If
' Get some information about the chosen key protector ID
' ----------------------------------------------------------------------------------
' is the type valid?
nRC = objVolume.GetKeyProtectorType(strDefaultKeyProtectorID, nDefaultKeyProtectorType)
If Hex(nRC) = "80070057" Then
WScript.Echo "The key protector ID " & strDefaultKeyProtectorID & " is not valid."
WScript.Echo "This ID value may have been provided by the script writer."
ElseIf nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectorType failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
' what's a string that can be used to describe it?
strDefaultKeyProtectorType = ""
Select Case nDefaultKeyProtectorType
Case nNumericalKeyProtectorType
strDefaultKeyProtectorType = "recovery password"
Case nExternalKeyProtectorType
strDefaultKeyProtectorType = "recovery key"
Case Else
WScript.Echo "The key protector ID " & strDefaultKeyProtectorID & " does not refer to a valid recovery
password or recovery key."
WScript.Echo "This ID value may have been provided by the script writer."
End Select
' Save the backup key package using the chosen key protector ID
' ----------------------------------------------------------------------------------
nRC = objVolume.GetKeyPackage(strDefaultKeyProtectorID, oKeyPackage)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyPackage failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
' Validate file path
Set fso = CreateObject("Scripting.FileSystemObject")
If (fso.FileExists(strFilePath)) Then
WScript.Echo "The file " & strFilePath & " already exists. Please use a different path."
WScript.Quit -1
End If
Dim oKeyPackageByte, bKeyPackage
For Each oKeyPackageByte in oKeyPackage
'WScript.echo "key package byte: " & oKeyPackageByte
bKeyPackage = bKeyPackage & ChrB(oKeyPackageByte)
bKeyPackage = bKeyPackage & ChrB(oKeyPackageByte)
Next
' Save binary data to the file
SaveBinaryDataText strFilePath, bKeyPackage
' Display helpful information
' ----------------------------------------------------------------------------------
WScript.Echo "The backup key package has been saved to " & strFilePath & "."
WScript.Echo "IMPORTANT: To use this key package, the " & strDefaultKeyProtectorType & " must also be saved."
' Display the recovery password or a note about saving the recovery key file
If nDefaultKeyProtectorType = nNumericalKeyProtectorType Then
nRC = objVolume.GetKeyProtectorNumericalPassword(strDefaultKeyProtectorID, sNumericalPassword)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectorNumericalPassword failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
WScript.Echo "Save this recovery password: " & sNumericalPassword
ElseIf nDefaultKeyProtectorType = nExternalKeyProtectorType Then
WScript.Echo "The saved key file is named " & strDefaultKeyProtectorID & ".BEK"
WScript.Echo "For help re-saving this external key file, type ""manage-bde -protectors -get -?"""
End If
'----------------------------------------------------------------------------------------
' Utility functions to save binary data
'----------------------------------------------------------------------------------------
Function SaveBinaryDataText(FileName, ByteArray)
'Create FileSystemObject object
Dim FS: Set FS = CreateObject("Scripting.FileSystemObject")
'Create text stream object

Dim TextStream
Set TextStream = FS.CreateTextFile(FileName)
'Convert binary data To text And write them To the file

TextStream.Write BinaryToString(ByteArray)
End Function
Function BinaryToString(Binary)
Dim I, S
For I = 1 To LenB(Binary)
S = S & Chr(AscB(MidB(Binary, I, 1)))
Next
BinaryToString = S
End Function
See also
BitLocker overview
Applies to
Windows 10
This detailed guide will help you understand the circumstances under which the use of pre-boot authentication is
recommended for devices running Windows 10, Windows 8.1, Windows 8, or Windows 7; and when it can be
safely omitted from a devices configuration.
BitLocker uses encryption to protect the data on your drive, but BitLocker security is only effective when the
encryption key is protected. Many users have relied on pre-boot authentication to protect the operating systems
integrity, disk encryption solution (for example, encryption keys), and the PCs data from offline attacks. With pre-
boot authentication, users must provide some form of credential before unlocking encrypted volumes and starting
Windows. Typically, they authenticate themselves using a PIN or a USB flash drive as a key.
Full-volume encryption using BitLocker Drive Encryption is vital for protecting data and system integrity on
devices running the Windows 10, Windows 8.1, Windows 8, or Windows 7 operating system. It is equally
important to protect the BitLocker encryption key. On Windows 7 devices, sufficiently protecting that key often
required pre-boot authentication, which many users find inconvenient and complicates device management.
Pre-boot authentication provides excellent startup security, but it inconveniences users and increases IT
management costs. Every time the PC is unattended, the device must be set to hibernate (in other words, shut
down and powered off); when the computer restarts, users must authenticate before the encrypted volumes are
unlocked. This requirement increases restart times and prevents users from accessing remote PCs until they can
physically access the computer to authenticate, making pre-boot authentication unacceptable in the modern IT
world, where users expect their devices to turn on instantly and IT requires PCs to be constantly connected to the
network.
If users lose their USB key or forget their PIN, they cant access their PC without a recovery key. With a properly
configured infrastructure, the organizations support will be able to provide the recovery key, but doing so
increases support costs, and users might lose hours of productive work time.
Starting with Windows 8, Secure Boot and Windows Trusted Boot startup process ensures operating system
integrity, allowing Windows to start automatically while minimizing the risk of malicious startup tools and rootkits.
In addition, many modern devices are fundamentally physically resistant to sophisticated attacks against the
computers memory, and now Windows authenticates the user before making devices that may represent a threat
to the device and encryption keys available for use.
In this topic
The sections that follow help you understand which PCs still need pre-boot authentication and which can meet
your security requirements without the inconvenience of it.
Types of attacks for volume encryption keys
BitLocker countermeasures
Choose the right BitLocker countermeasure
See also
BitLocker overview
Applies to
Windows 10
There are many ways Windows helps protect your organization from attacks, including Unified Extensible Firmware
Interface (UEFI) Secure Boot, Trusted Platform Module (TPM), Group Policy, complex passwords, and account
lockouts.
The next few sections describe each type of attack that could be used to compromise a volume encryption key,
whether for BitLocker or a non-Microsoft encryption solution. After an attacker has compromised a volume
encryption key, the attacker can read data from your system drive or even install malware while Windows is offline.
Each section begins with a graphical overview of the attacks strengths and weaknesses as well as suggested
mitigations.
Bootkit and rootkit attacks
Rootkits are a sophisticated and dangerous type of malware that runs in kernel mode, using the same privileges as
the operating system. Because rootkits have the same or possibly even more rights than the operating system, they
can completely hide themselves from Windows and even an antimalware solution. Often, rootkits are part of an
entire suite of malware that can bypass local logins, record passwords, transfer private files, and capture
cryptography keys.
Different types of bootkits and rootkits load at different software levels:
Kernel level. Rootkits running at the kernel level have the highest privilege in the operating system. They may
be able to inject malicious code or replace portions of the core operating system, including both the kernel and
device drivers.
Application level. These rootkits are aimed to replace application binaries with malicious code, such as a
Trojan, and can even modify the behavior of existing applications.
Library level. The purpose of library-level rootkits is to hook, patch, or replace system calls with malicious code
that can hide the malwares presence.
Hypervisor level. Hypervisor rootkits target the boot sequence. Their primary purpose is to modify the boot
sequence to load themselves as a hypervisor.
Firmware level. These rootkits overwrite the PCs BIOS firmware, giving the malware low-level access and
potentially the ability to install or hide malware, even if its cleaned or removed from the hard disk.
Regardless of the operating system or encryption method, rootkits have access to confidential data once installed.
Application-level rootkits can read any files the user can access, bypassing volume-level encryption. Kernel-,
library-, hypervisor-, and firmware-level rootkits have direct access to system files on encrypted volumes and can
also retrieve an encryption key from memory.
Windows offers substantial protection from bootkits and rootkits, but it is possible to bypass operating system
security when an attacker has physical access to the device and can install the malware to the device while
Windows is offline. For example, an attacker might boot a PC from a USB flash drive containing malware that starts
before Windows. The malware can replace system files or the PCs firmware or simply start Windows under its
control.
To sufficiently protect a PC from boot and rootkits, devices must use pre-boot authentication or Secure Boot, or the
encryption solution must use the devices Trusted Platform Module (TPM) as a means of monitoring the integrity of
the end-to-end boot process. Pre-boot authentication is available for any device, regardless of the hardware, but
because it is inconvenient to users, it should be used only to mitigate threats that are applicable to the device. On
devices with Secure Boot enabled, you do not need to use pre-boot authentication to protect against boot and
rootkit attacks.
Although password protection of the UEFI configuration is important for protecting a devices configuration and
preventing an attacker from disabling Secure Boot, use of a TPM and its Platform Configuration Register (PCR)
measurements (PCR7) to ensure that the systems bootloader (whether a Windows or non-Microsoft encryption
solution) is tamper free and the first code to start on the device is critical. An encryption solution that doesnt use a
devices TPM to protect its components from tampering may be unable to protect itself from bootkit-level
infections that could log a users password or acquire encryption keys.
For this reason, when BitLocker is configured on devices that include a TPM, the TPM and its PCRs are always used
to secure and confirm the integrity of the preoperating system environment before making encrypted volumes
accessible.
Any change to the UEFI configuration invalidates the PCR7 and requires the user to enter the BitLocker recovery
key. Because of this feature, its not critical to password-protect your UEFI configuration. But UEFI password
protection is a best practice and is still required for systems not using a TPM (such as non-Microsoft alternatives).
Brute -force Sign-in Attacks
Attackers can find any password if you allow them to guess enough times. The process of trying millions of
different passwords until you find the right one is known as a brute-force sign-in attack. In theory, an attacker
could obtain any password by using this method.
Three opportunities for brute-force attacks exist:
Against the pre-boot authenticator. An attacker could attack the device directly by attempting to guess the
users BitLocker PIN or an equivalent authenticator. The TPM mitigates this approach by invoking an anti-
hammering lockout capability that requires the user to wait until the lockout period ends or enter the BitLocker
recovery key.
Against the recovery key. An attacker could attempt to guess the 48-digit BitLocker recovery key. Even
without a lockout period, the key is long enough to make brute-force attacks impractical. Specifically, the
BitLocker recovery key has 128 bits of entropy; thus, the average brute-force attack would succeed after
18,446,744,073,709,551,616 guesses. If an attacker could guess 1 million passwords per second, the average
brute-force attack would require more than 580,000 years to be successful.
Against the operating system sign-in authenticator. An attacker can attempt to guess a valid user name
and password. Windows implements a delay between password guesses, slowing down brute-force attacks. In
addition, all recent versions of Windows allow administrators to require complex passwords and password
lockouts. Similarly, administrators can use Microsoft Exchange ActiveSync policy or Group Policy to configure
Windows 8.1 and Windows 8 to automatically restart and require the user to enter the BitLocker 48-digit
recovery key after a specified number of invalid password attempts. When these settings are enabled and users
follow best practices for complex passwords, brute-force attacks against the operating system sign-in are
impractical.
In general, brute-force sign-in attacks are not practical against Windows when administrators enforce complex
passwords and account lockouts.
Direct Memory Access Attacks
Direct memory access (DMA) allows certain types of hardware devices to communicate directly with a devices
system memory. For example, if you use Thunderbolt to connect another device to your computer, the second
device automatically has Read and Write access to the target computers memory.
Unfortunately, DMA ports dont use authentication and access control to protect the contents of the computers
memory. Whereas Windows can often prevent system components and apps from reading and writing to
protected parts of memory, a device can use DMA to read any location in memory, including the location of any
encryption keys.
DMA attacks are relatively easy to execute and require little technical skills. Anyone can download a tool from the
Internet, such as those made by Passware, ElcomSoft, and others, and then use a DMA attack to read confidential
data from a PCs memory. Because encryption solutions store their encryption keys in memory, they can be
accessed by a DMA attack.
Not all port types are vulnerable to DMA attacks. USB in particular does not allow DMA, but devices that have any
of the following port types are vulnerable:
FireWire
Thunderbolt
ExpressCard
PCMCIA
PCI
PCI-X
PCI Express
To perform a DMA attack, attackers typically connect a second PC that is running a memory-scanning tool (for
example, Passware, ElcomSoft) to the FireWire or Thunderbolt port of the target computer. When connected, the
software scans the system memory of the target and locates the encryption key. Once acquired, the key can be
used to decrypt the drive and read or modify its contents.
A much more efficient form of this attack exists in theory: An attacker crafts a custom FireWire or Thunderbolt
device that has the DMA attack logic programmed on it. Now, the attacker simply needs to physically connect the
device. If the attacker does not have physical access, they could disguise it as a free USB flash drive and distribute it
to employees of a target organization. When connected, the attacking device could use a DMA attack to scan the
PCs memory for the encryption key. It could then transmit the key (or any data in the PCs memory) using the PCs
Internet connection or its own wireless connection. This type of attack would require an extremely high level of
sophistication, because it requires that the attacker create a custom device (devices of these types are not readily
available in the marketplace at this time).
Today, one of the most common uses for DMA ports on Windows devices is for developer debugging, a task that
some developers need to perform and one that few consumers will ever perform. Because USB; DisplayPort; and
other, more secure port types satisfy consumers, most new mobile PCs do not include DMA ports. Microsofts view
is that because of the inherent security risks of DMA ports, they do not belong on mobile devices, and Microsoft
has prohibited their inclusion on any InstantGo-certified devices. InstantGo devices offer mobile phonelike power
management and instant-on capabilities; at the time of writing, they are primarily found in Windows tablets.
DMA-based expansion slots are another avenue of attack, but these slots generally appear only on desktop PCs
that are designed for expansion. Organizations can use physical security to prevent outside attacks against their
desktop PCs. In addition, a DMA attack on the expansion slot would require a custom device; as a result, an attacker
would most likely insert an interface with a traditional DMA port (for example, FireWire) into the slot to attack the
PC.
To mitigate a port-based DMA attack an administrator can configure policy settings to disable FireWire and other
device types that have DMA. Also, many PCs allow those devices to be disabled by using firmware settings.
Although the need for pre-boot authentication can be eliminated at the device level or through Windows
configuration, the BitLocker pre-boot authentication feature is still available when needed. When used, it
successfully mitigates all types of DMA port and expansion slot attacks on any type of device.
Hyberfil.sys Attacks
The hyberfil.sys file is the Windows hibernation file. It contains a snapshot of system memory that is generated
when a device goes into hibernation and includes the encryption key for BitLocker and other encryption
technologies. Attackers have claimed that they have successfully extracted encryption keys from the hyberfil.sys
file.
Like the DMA port attack discussed in the previous section, tools are available that can scan the hyberfile.sys file
and locate the encryption key, including a tool made by Passware. Microsoft does not consider Windows to be
vulnerable to this type of attack, because Windows stores the hyberfil.sys file within the encrypted system volume.
As a result, the file would be accessible only if the attacker had both physical and sign-in access to the PC. When an
attacker has sign-in access to the PC, there are few reasons for the attacker to decrypt the drive, because they
would already have full access to the data within it.
In practice, the only reason an attack on hyberfil.sys would grant an attacker additional access is if an administrator
had changed the default Windows configuration and stored the hyberfil.sys file on an unencrypted drive. By
default, Windows 10 is designed to be secure against this type of attack.
Memory Remanence Attacks
A memory remanence attack is a side-channel attack that reads the encryption key from memory after restarting a
PC. Although a PCs memory is often considered to be cleared when the PC is restarted, memory chips dont
immediately lose their memory when you disconnect power. Therefore, an attacker who has physical access to the
PCs memory might be able to read data directly from the memoryincluding the encryption key.
When performing this type of cold boot attack, the attacker accesses the PCs physical memory and recovers the
encryption key within a few seconds or minutes of disconnecting power. This type of attack was demonstrated by
researchers at Princeton University. With the encryption key, the attacker would be able to decrypt the drive and
access its files.
To acquire the keys, attackers follow this process:
1. Freeze the PCs memory. For example, an attacker can freeze the memory to 50C by spraying it with aerosol
air duster spray.
2. Restart the PC.
3. Instead of restarting Windows, boot to another operating system. Typically, this is done by connecting a
bootable flash drive or loading a bootable DVD.
4. The bootable media loads the memory remanence attack tools, which the attacker uses to scan the system
memory and locate the encryption keys.
5. The attacker uses the encryption keys to access the drives data.
If the attacker is unable to boot the device to another operating system (for example, if bootable flash drives have
been disabled or Secure Boot is enabled), the attacker can attempt to physically remove the frozen memory from
the device and attach it to a different, possibly identical device. Fortunately, this process has proven extremely
unreliable, as evidenced by the Defence Research and Development Canada (DRDC) Valcartier groups analysis
(see An In-depth Analysis of the Cold Boot Attack). On an increasing portion of modern devices, this type of attack
is not even possible, because memory is soldered directly to the motherboard.
Although Princetons research proved that this type of attack was possible on devices that have removable
memory, device hardware has changed since the research was published in 2008:
Secure Boot prevents the malicious tools that the Princeton attack depends on from running on the target
device.
Windows systems with BIOS or UEFI can be locked down with a password, and booting to a USB drive can be
prevented.
If booting to USB is required on the device, it can be limited to starting trusted operating systems by using
Secure Boot.
The discharge rates of memory are highly variable among devices, and many devices have memory that is
completely immune to memory remanence attacks.
Increased density of memory diminishes their remanence properties and reduces the likelihood that the attack
can be successfully executed, even when memory is physically removed and placed in an identical system where
the systems configuration may enable booting to the malicious tools.
Because of these factors, this type of attack is rarely possible on modern devices. Even in cases where the risk
factors exist on legacy devices, attackers will find the attack unreliable. For detailed info about the practical uses for
forensic memory acquisition and the factors that make a computer vulnerable or resistant to memory remanence
attacks, read An In-depth Analysis of the Cold Boot Attack.
The BitLocker pre-boot authentication feature can successfully mitigate memory remanence attacks on most
devices, but you can also mitigate such attacks by protecting the system UEFI or BIOS and prevent the PC from
booting from external media (such as a USB flash drive or DVD). The latter option is often a better choice, because
it provides sufficient protection without inconveniencing users with pre-boot authentication.
See also
BitLocker countermeasures
BitLocker overview
BitLocker Countermeasures
Applies to
Windows 10
Windows uses technologies including TPM, Secure Boot, Trusted Boot, and Early Launch Antimalware (ELAM) to
protect against attacks on the BitLocker encryption key. BitLocker is part of a strategic approach to securing mobile
data through encryption technology. Data on a lost or stolen computer is vulnerable to unauthorized access, either
by running a software attack tool against it or by transferring the computers hard disk to a different computer.
Today, BitLocker helps mitigate unauthorized data access on lost or stolen computers before the operating system
is started by:
Encrypting the hard drives on your computer. For example, you can turn on BitLocker for your operating
system drive, a fixed data drive, or a removable data drive (such as a USB flash drive). Turning on BitLocker for
your operating system drive encrypts all system files on the operating system drive, including the swap files
and hibernation files.
Ensuring the integrity of early boot components and boot configuration data. On devices that have a
TPM version 1.2 or higher, BitLocker uses the enhanced security capabilities of the TPM to help ensure that your
data is accessible only if the computers boot components appear unaltered and the encrypted disk is located in
the original computer.
The sections that follow provide more detailed information about the different technologies that Windows uses to
protect against attacks on the BitLocker encryption key in four different boot phases: before startup, during pre-
boot, during startup, and finally after startup.
Protection before startup
Before Windows starts, you must rely on security features implemented as part of the device hardware, including
TPM and Secure Boot. Fortunately, many modern computers feature TPM.
Software alone isnt sufficient to protect a system. After an attacker has compromised software, the software might
be unable to detect the compromise. Therefore, a single successful software compromise results in an untrusted
system that might never be detected. Hardware, however, is much more difficult to modify.
A TPM is a microchip designed to provide basic security-related functions, primarily involving encryption keys. The
TPM is usually installed on the motherboard of a computer and communicates with the rest of the system through
a hardware bus. Physically, TPMs are designed to be tamper-proof. If an attacker tries to physically retrieve data
directly from the chip, theyll probably destroy the chip in the process. By binding the BitLocker encryption key
with the TPM and properly configuring the device, its nearly impossible for an attacker to gain access to the
BitLocker-encrypted data without obtaining an authorized users credentials. Therefore, computers with a TPM can
provide a high level of protection against attacks that attempt to directly retrieve the BitLocker encryption key. For
more info about TPM, see Trusted Platform Module.
UEFI and Secure Boot
No operating system can protect a device when the operating system is offline. For that reason, Microsoft worked
closely with hardware vendors to require firmware-level protection against boot and rootkits that might
compromise an encryption solutions encryption keys.
The UEFI is a programmable boot environment introduced as a replacement for BIOS, which has for the most part
remained unchanged for the past 30 years. Like BIOS, PCs start UEFI before any other software; it initializes
devices, and UEFI then starts the operating systems bootloader. As part of its introduction into the preoperating
system environment, UEFI serves a number of purposes, but one of the key benefits is to protect newer devices
against a sophisticated type of malware called a bootkit through the use of its Secure Boot feature.
Recent implementations of UEFI (starting with version 2.3.1) can verify the digital signatures of the devices
firmware before running it. Because only the PCs hardware manufacturer has access to the digital certificate
required to create a valid firmware signature, UEFI can prevent firmware-based bootkits. Thus, UEFI is the first link
in the chain of trust.
Secure Boot is the foundation of platform and firmware security and was created to enhance security in the pre-
boot environment regardless of device architecture. Using signatures to validate the integrity of firmware images
before they are allowed to execute, Secure Boot helps reduce the risk of bootloader attacks. The purpose of Secure
Boot is to block untrusted firmware and bootloaders (signed or unsigned) from being able to start on the system.
With the legacy BIOS boot process, the preoperating system environment is vulnerable to attacks by redirecting
bootloader handoff to possible malicious loaders. These loaders could remain undetected to operating system and
antimalware software. The diagram in Figure 1 contrasts the BIOS and UEFI startup processes.
Figure 1. The BIOS and UEFI startup processes

With Secure Boot enabled, UEFI, in coordination with the TPM, can examine the bootloader and determine whether
its trustworthy. To determine whether the bootloader is trustworthy, UEFI examines the bootloaders digital
signature. Using the digital signature, UEFI verifies that the bootloader was signed using a trusted certificate.
If the bootloader passes these two tests, UEFI knows that the bootloader isnt a bootkit and starts it. At this point,
Trusted Boot takes over, and the Windows bootloader, using the same cryptographic technologies that UEFI used
to verify the bootloader, then verifies that the Windows system files havent been changed.
Starting with Windows 8, certified devices must meet several requirements related to UEFI-based Secure Boot:
They must have Secure Boot enabled by default.
They must trust Microsofts certificate (and thus any bootloader Microsoft has signed).
They must allow the user to configure Secure Boot to trust other signed bootloaders.
Except for Windows RT devices, they must allow the user to completely disable Secure Boot.
These requirements help protect you from rootkits while allowing you to run any operating system you want. You
have three options for running non-Microsoft operating systems:
Use an operating system with a certified bootloader. Microsoft can analyze and sign non-Microsoft
bootloaders so that they can be trusted. The Linux community is using this process to enable Linux to take
advantage of Secure Boot on Windows-certified devices.
Configure UEFI to trust your custom bootloader. Your device can trust a signed, non-certified
bootloader that you specify in the UEFI database, allowing you to run any operating system, including
homemade operating systems.
Turn off Secure Boot. You can turn off Secure Boot. This does not help protect you from bootkits, however.
To prevent malware from abusing these options, the user has to manually configure the UEFI firmware to trust a
non-certified bootloader or to turn off Secure Boot. Software cannot change the Secure Boot settings. Any device
that doesnt require Secure Boot or a similar bootloader-verification technology, regardless of the architecture or
operating system, is vulnerable to bootkits, which can be used to compromise the encryption solution. UEFI is
secure by design, but its critical to protect the Secure Boot configuration by using password protection. In
addition, although several well-publicized attacks against UEFI have occurred, they were exploiting faulty UEFI
implementations. Those attacks are ineffective when UEFI is implemented properly.
For more information about Secure Boot, refer to Securing the Windows 8.1 Boot Process.
Protection during pre -boot: Pre -boot authentication
Pre-boot authentication with BitLocker is a process that requires the use of either a Trusted Platform Module
(TPM), user input, such as a PIN, or both, depending on hardware and operating system configuration, to
authenticate prior to making the contents of the system drive accessible. In the case of BitLocker, BitLocker
encrypts the entire drive, including all system files. BitLocker accesses and stores the encryption key in memory
only after a pre-boot authentication is completed using one or more of the following options: Trusted Platform
Module (TPM), user provides a specific PIN, USB startup key.
If Windows cant access the encryption key, the device cant read or edit the files on the system drive. Even if an
attacker takes the disk out of the PC or steals the entire PC, they wont be able to read or edit the files without the
encryption key. The only option for bypassing pre-boot authentication is entering the highly complex, 48-digit
recovery key.
The BitLocker pre-boot authentication capability is not specifically designed to prevent the operating system from
starting: Thats merely a side effect of how BitLocker protects data confidentiality and system integrity. Pre-boot
authentication is designed to prevent the encryption key from being loaded to system memory on devices that are
vulnerable to certain types of cold boot attacks. Many modern devices prevent an attacker from easily removing
the memory, and Microsoft expects those devices to become even more common in the future.
On computers with a compatible TPM, operating system drives that are BitLocker-protected can be unlocked in
four ways:
TPM-only. Using TPM-only validation does not require any interaction with the user to decrypt and provide
access to the drive. If the TPM validation succeeds, the user logon experience is the same as a standard logon. If
the TPM is missing or changed or if the TPM detects changes to critical operating system startup files, BitLocker
enters its recovery mode, and the user must enter a recovery password to regain access to the data.
TPM with startup key. In addition to the protection that the TPM provides, part of the encryption key is stored
on a USB flash drive, referred to as a startup key. Data on the encrypted volume cannot be accessed without the
startup key.
TPM with PIN. In addition to the protection that the TPM provides, BitLocker requires that the user enter a PIN.
Data on the encrypted volume cannot be accessed without entering the PIN.
TPM with startup key and PIN. In addition to the core component protection that the TPM provides, part of
the encryption key is stored on a USB flash drive, and a PIN is required to authenticate the user to the TPM. This
configuration provides multifactor authentication so that if the USB key is lost or stolen, it cannot be used for
access to the drive, because the correct PIN is also required.
For many years, Microsoft has recommended using pre-boot authentication to protect against DMA and memory
remanence attacks. Today, Microsoft only recommends using pre-boot authentication on PCs where the
mitigations described in this document cannot be implemented. These mitigations may be inherent to the device
or may come by way of configurations that IT can provision to devices and Windows itself.
Although effective, pre-boot authentication is inconvenient to users. In addition, if a user forgets their PIN or loses
their startup key, theyre denied access to their data until they can contact their organizations support team to
obtain a recovery key. Today, most new PCs running Windows 10, Windows 8.1, or Windows 8 provide sufficient
protection against DMA attacks without requiring pre-boot authentication. For example, most modern PCs include
USB port options (which are not vulnerable to DMA attacks) but do not include FireWire or Thunderbolt ports
(which are vulnerable to DMA attacks).
BitLocker-encrypted devices with DMA ports enabled, including FireWire or Thunderbolt ports, should be
configured with pre-boot authentication if they are running Windows 10, Windows 7, Windows 8, or Windows 8.1
and disabling the ports using policy or firmware configuration is not an option. Windows 8.1 and later InstantGo
devices do not need pre-boot authentication to defend against DMA-based port attacks, as the ports will not be
present on certified devices. A non-InstantGo Windows 8.1 and later device requires pre-boot authentication if
DMA ports are enabled on the device and additional mitigations described in this document are not implemented.
Many customers find that the DMA ports on their devices are never used, and they choose to eliminate the
possibility of an attack by disabling the DMA ports themselves, either at the hardware level or through Group
Policy. Many new mobile devices have the system memory soldered to the motherboard, which helps prevent the
cold bootstyle attack, where the system memory is frozen, removed, and then placed into another device. Those
devices, and most PCs, can still be vulnerable when booting to a malicious operating system, however.
You can mitigate the risk of booting to a malicious operating system:
Windows 10 (without Secure Boot), Windows 8.1 (without Secure Boot), Windows 8 (without UEFI-
based Secure Boot), or Windows 7 (with or without a TPM). Disable booting from external media, and
require a firmware password to prevent the attacker from changing that option.
Windows 10, Windows 8.1, or Windows 8 (certified or with Secure Boot). Password protect the firmware,
and do not disable Secure Boot.
Protection During Startup
During the startup process, Windows 10 uses Trusted Boot and Early Launch Antimalware (ELAM) to examine the
integrity of every component. The sections that follow describe these technologies in more detail.
Trusted Boot
Trusted Boot takes over where UEFI-based Secure Boot leaves offduring the operating system initialization
phase. The bootloader verifies the digital signature of the Windows kernel before loading it. The Windows kernel,
in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files,
and ELAM driver. If a file has been modified or is not properly signed with a Microsoft signature, Windows detects
the problem and refuses to load the corrupted component. Often, Windows can automatically repair the corrupted
component, restoring the integrity of Windows and allowing the PC to start normally.
Windows 10 uses Trusted Boot on any hardware platform: It requires neither UEFI nor a TPM. However, without
Secure Boot, its possible for malware to compromise the startup process prior to Windows starting, at which point
Trusted Boot protections could be bypassed or potentially disabled.
Early Launch Antimalware
Because UEFI-based Secure Boot has protected the bootloader and Trusted Boot has protected the Windows kernel
or other Windows startup components, the next opportunity for malware to start is by infecting a non-Microsoft
boot-related driver. Traditional antimalware apps dont start until after the boot-related drivers have been loaded,
giving a rootkit disguised as a driver the opportunity to work.
Early Launch Antimalware (ELAM) is designed to enable the antimalware solution to start before all non-Microsoft
drivers and apps. ELAM checks the integrity of non-Microsoft drivers to determine whether the drivers are
trustworthy. Because Windows needs to start as fast as possible, ELAM cannot be a complicated process of
checking the driver files against known malware signatures. Instead, ELAM has the simple task of examining every
boot driver and determining whether it is on the list of trusted drivers. If malware modifies a boot-related driver,
ELAM will detect the change, and Windows will prevent the driver from starting, thus blocking driver-based
rootkits. ELAM also allows the registered antimalware provider to scan drivers that are loaded after the boot
process is complete.
Windows Defender in Windows 10 supports ELAM, as do Microsoft System Center 2012 Endpoint Protection and
non-Microsoft antimalware apps.
To do this, ELAM loads an antimalware driver before drivers that are flagged as boot-start can be executed. This
approach provides the ability for an antimalware driver to register as a trusted boot-critical driver. It is launched
during the Trusted Boot process, and with that, Windows ensures that it is loaded before any other non-Microsoft
software.
With this solution in place, boot drivers are initialized based on the classification that the ELAM driver returns
according to an initialization policy. IT pros have the ability to change this policy through Group Policy. ELAM
classifies drivers as follows:
Good. The driver has been signed and has not been tampered with.
Bad. The driver has been identified as malware. It is recommended that you not allow known bad drivers to be
initialized.
Bad but required for boot. The driver has been identified as malware, but the computer cannot successfully
boot without loading this driver.
Unknown. This driver has not been attested to by your malware-detection application or classified by the
ELAM boot-start driver.
While the features listed above protect the Windows boot process from malware threats that could compromise
BitLocker security, it is important to note that DMA ports may be enabled during the window of time between
when BitLocker unlocks the drive and Windows boots to the point that Windows can set any port related policies
that have been configured. This period of time where the encryption key could be exposed to a DMA attack could
be less than a minute on recent devices or longer depending on system performance. The use of pre-boot
authentication with a PIN can be used to successfully mitigate against an attack.
Protection After Startup: eliminate DMA availability
Windows InstantGocertified devices do not have DMA ports, eliminating the risk of DMA attacks. On other
devices, you can disable FireWire, Thunderbolt, or other ports that support DMA.
See also
Types of Attacks for Volume Encryption Keys
BitLocker overview
Applies to
Windows 10
This section outlines the best countermeasures you can use to protect your organization from bootkits and
rootkits, brute force sign-in, Direct Memory Access (DMA) attacks, Hyberfil.sys attacks, and memory remanence
attacks. You can use BitLocker to protect your Windows 10 PCs. Whichever operating system youre using,
Microsoft and Windows-certified devices provide countermeasures to address attacks and improve your data
security. In most cases, this protection can be implemented without the need for pre-boot authentication.
Tables 1 and 2 summarize the recommended mitigations for different types of attacks against PCs running recent
versions of Windows. The orange blocks indicate that the system requires additional configuration from the
default settings.
Windows 8.1 Windows 8.1 Certified

without TPM (with TPM)
Bootkits and Without TPM, boot Secure by default when UEFI-based Secure Boot is enabled and
Rootkits integrity checking is not a firmware password is required to change settings
available
Brute Force Secure by default, and Secure by default, and can be improved with account lockout
Sign-in can be improved with and device lockout Group Policy settings
account lockout Group
Policy
DMA If policy is deployed, If policy is deployed, secure by default for all lost or stolen
Attacks secure by default for all devices because new DMA devices are granted access only when
lost or stolen devices an authorized user is signed in
because new DMA
devices are granted
access only when an
authorized user is
signed in
Hyberfil.sys Secure by default; Secure by default; hyberfil.sys secured on encrypted volume

Attacks hyberfil.sys secured on
encrypted volume
Memory Password protect the Password protect the firmware and ensure Secure Boot is
Remanence firmware and disable enabled. If an attack is viable, consider pre-boot authentication
Attacks booting from external
media. If an attack is
viable, consider pre-
boot authentication
Table 1. How to choose the best countermeasures for Windows 8.1

Windows 10 Windows 10 Certified
without TPM (with TPM)
Bootkits and Without TPM, boot Secure by default when UEFI-based Secure Boot is enabled and
Rootkits integrity checking is not a firmware password is required to change settings
available
Brute Force Secure by default, and Secure by default, and can be improved with account lockout
Sign-in can be improved with and device lockout Group Policy settings
account lockout Group
Policy
DMA If policy is deployed, Secure by default; certified devices do not expose vulnerable
Attacks secure by default for all DMA busses.
lost or stolen devices Can be additionally secured by deploying policy to restrict DMA
because new DMA devices:
devices are granted
access only when an DataProtection/AllowDirectMemoryAccess
authorized user is Block 1394 and Thunderbolt
signed in
Hyberfil.sys Secure by default; Secure by default; hyberfil.sys secured on encrypted volume

Attacks hyberfil.sys secured on
encrypted volume
Memory Password protect the Password protect the firmware and ensure Secure Boot is
Remanence firmware and disable enabled.
Attacks booting from external The most effective mitigation, which we advise for high-security
media. If an attack is devices, is to configure a TPM+PIN protector, disable Standby
viable, consider pre- power management, and shut down or hibernate the device
boot authentication before it leaves the control of an authorized user.
Table 2. How to choose the best countermeasures for Windows 10

The latest InstantGo devices, primarily tablets, are designed to be secure by default against all attacks that might
compromise the BitLocker encryption key. Other Windows devices can be secure by default too. DMA portbased
attacks, which represent the attack vector of choice, are not possible on InstantGo devices because these port types
are prohibited. The inclusion of DMA ports on even non-InstantGo devices is extremely rare on recent devices,
particularly on mobile ones. This could change if Thunderbolt is broadly adopted, so IT should consider this when
purchasing new devices. In any case, DMA ports can be disabled entirely, which is an increasingly popular option
because the use of DMA ports is infrequent in the non-developer space. To prevent DMA port usage unless an
authorized user is signed in, you can set the DataProtection/AllowDirectMemoryAccess policy by using Mobile
Device Management (MDM) or the Group Policy setting Disable new DMA devices when this computer is
locked (beginning with Windows 10, version 1703). This setting is Not configured by default. The path to the
Group Policy setting is:
Computer Configuration|Administrative Templates|Windows Components|BitLocker Drive Encryption
Memory remanence attacks can be mitigated with proper configuration; in cases where the system memory is
fixed and non-removable, they are not possible using published techniques. Even in cases where system memory
can be removed and loaded into another device, attackers will find the attack vector extremely unreliable, as has
been shown in the DRDC Valcartier groups analysis (see An In-depth Analysis of the Cold Boot Attack).
Windows 7 PCs share the same security risks as newer devices but are far more vulnerable to DMA and memory
remanence attacks, because Windows 7 devices are more likely to include DMA ports, lack support for UEFI-based
Secure Boot, and rarely have fixed memory. To eliminate the need for pre-boot authentication on Windows 7
devices, disable the ability to boot to external media, password-protect the BIOS configuration, and disable the
DMA ports. If you believe that your devices may be a target of a memory remanence attack, where the system
memory may be removed and put into another computer to gain access to its contents, consider testing your
devices to determine whether they are susceptible to this type of attack.
In the end, many customers will find that pre-boot authentication improves security only for a shrinking subset of
devices within their organization. Microsoft recommends a careful examination of the attack vectors and
mitigations outlined in this document along with an evaluation of your devices before choosing to implement pre-
boot authentication, which may not enhance the security of your devices and instead will only compromise the
user experience and add to support costs.
See also
BitLocker Countermeasures
BitLocker overview
Protecting cluster shared volumes and storage area
networks with BitLocker
Applies to
Windows Server 2016
This topic for IT pros describes how to protect CSVs and SANs with BitLocker.
BitLocker can protect both physical disk resources and cluster shared volumes version 2.0 (CSV2.0). BitLocker on
clustered volumes allows for an additional layer of protection for administrators wishing to protect sensitive, highly
available data. By adding additional protectors to the clustered volume, administrators can also add an additional
barrier of security to resources within an organization by allowing only certain user accounts access to unlock the
BitLocker volume.
Configuring BitLocker on Cluster Shared Volumes

Using BitLocker with Clustered Volumes
BitLocker on volumes within a cluster are managed based on how the cluster service "views" the volume to be
protected. The volume can be a physical disk resource such as a logical unit number (LUN) on a storage area
network (SAN) or network attached storage (NAS).
Important SANs used with BitLocker must have obtained Windows Hardware Certification. For more info, see
Windows Hardware Lab Kit.
Alternatively, the volume can be a cluster-shared volume, a shared namespace, within the cluster. Windows Server
2012 expanded the CSV architecture, now known as CSV2.0, to enable support for BitLocker. When using BitLocker
with volumes designated for a cluster, the volume will need to turn on BitLocker before its addition to the storage
pool within cluster or put the resource into maintenance mode before BitLocker operations will complete.
Windows PowerShell or the manage-bde command line interface is the preferred method to manage BitLocker on
CSV2.0 volumes. This is recommended over the BitLocker Control Panel item because CSV2.0 volumes are mount
points. Mount points are an NTFS object that is used to provide an entry point to other volumes. Mount points do
not require the use of a drive letter. Volumes that lack drive letters do not appear in the BitLocker Control Panel
item. Additionally, the new Active Directory-based protector option required for cluster disk resource or CSV2.0
resources is not available in the Control Panel item.
Note: Mount points can be used to support remote mount points on SMB based network shares. This type of
share is not supported for BitLocker encryption.
For thinly provisioned storage, such as a Dynamic Virtual Hard Disk (VHD), BitLocker runs in Used Disk Space Only
encryption mode. You cannot use the manage-bde -WipeFreeSpace command to transition the volume to full-
volume encryption on these types of volumes. This is blocked in order to avoid expanding thinly provisioned
volumes to occupy the entire backing store while wiping the unoccupied (free) space.
Active Directory-based protector
You can also use an Active Directory Domain Services (AD DS) protector for protecting clustered volumes held
within your AD DS infrastructure. The ADAccountOrGroup protector is a domain security identifier (SID)-based
protector that can be bound to a user account, machine account or group. When an unlock request is made for a
protected volume, the BitLocker service interrupts the request and uses the BitLocker protect/unprotect APIs to
unlock or deny the request. BitLocker will unlock protected volumes without user intervention by attempting
protectors in the following order:
1. Clear key
2. Driver-based auto-unlock key
3. ADAccountOrGroup protector
a. Service context protector
b. User protector
4. Registry-based auto-unlock key
Note: A Windows Server 2012 or later domain controller is required for this feature to work properly.
Turning on BitLocker before adding disks to a cluster using Windows PowerShell

BitLocker encryption is available for disks before or after addition to a cluster storage pool. The advantage of
encrypting volumes prior to adding them to a cluster is that the disk resource does not require suspending the
resource to complete the operation. To turn on BitLocker for a disk before adding it to a cluster, do the following:
1. Install the BitLocker Drive Encryption feature if it is not already installed.
2. Ensure the disk is formatted NTFS and has a drive letter assigned to it.
3. Identify the name of the cluster with Windows PowerShell.
Get-Cluster
4. Enable BitLocker on the volume of your choice with an ADAccountOrGroup protector, using the cluster
name. For example, use a command such as:
Enable-BitLocker E: -ADAccountOrGroupProtector -ADAccountOrGroup CLUSTER$
Warning: You must configure an ADAccountOrGroup protector using the cluster CNO for a BitLocker
enabled volume to either be shared in a Cluster Shared Volume or to fail over properly in a traditional
failover cluster.
5. Repeat the preceding steps for each disk in the cluster.

6. Add the volume(s) to the cluster.
Turning on BitLocker for a clustered disk using Windows PowerShell
When the cluster service owns a disk resource already, it needs to be set into maintenance mode before BitLocker
can be enabled. Use the following steps for turning BitLocker on for a clustered disk:
1. Install the BitLocker Drive Encryption feature if it is not already installed.
2. Check the status of the cluster disk using Windows PowerShell.
Get-ClusterResource "Cluster Disk 1"
3. Put the physical disk resource into maintenance mode using Windows PowerShell.
Get-ClusterResource "Cluster Disk 1" | Suspend-ClusterResource

4. Identify the name of the cluster with Windows PowerShell.
Get-Cluster
5. Enable BitLocker on the volume of your choice with an ADAccountOrGroup protector, using the cluster
name. For example, use a command such as:
Enable-BitLocker E: -ADAccountOrGroupProtector -ADAccountOrGroup CLUSTER$
Warning: You must configure an ADAccountOrGroup protector using the cluster CNO for a BitLocker
enabled volume to either be shared in a Cluster Shared Volume or to fail over properly in a traditional
failover cluster.
6. Use Resume-ClusterResource to take the physical disk resource back out of maintenance mode:
Get-ClusterResource "Cluster Disk 1" | Resume-ClusterResource
7. Repeat the preceding steps for each disk in the cluster.

Adding BitLocker encrypted volumes to a cluster using manage -bde
You can also use manage-bde to enable BitLocker on clustered volumes. The steps needed to add a physical disk
resource or CSV2.0 volume to an existing cluster includes the following:
1. Verify the BitLocker Drive Encryption feature is installed on the computer.
2. Ensure new storage is formatted as NTFS.
3. Encrypt the volume, add a recovery key and add the cluster administrator as a protector key using the
manage-bde command line interface (see example):
Manage-bde -on -used <drive letter> -RP -sid domain\CNO$ -sync
a. BitLocker will check to see if the disk is already part of a cluster. If it is, administrators will
encounter a hard block. Otherwise, the encryption will continue.
b. Using the -sync parameter is optional. Using it ensures the command waits until the encryption
for the volume is completed before releasing the volume for use in the cluster storage pool.
4. Open the Failover Cluster Manager snap-in or cluster PowerShell cmdlets to enable the disk to be clustered
Once the disk is clustered it can also be enabled for CSV.
5. During the resource online operation, cluster will check to see if the disk is BitLocker encrypted.
a. If the volume is not BitLocker enabled, traditional cluster online operations occur.
b. If the volume is BitLocker enabled, the following check occurs:
If volume is locked, BitLocker will impersonate the CNO and unlock the volume using the CNO
protector. If this operation fails an event will be logged that the volume could not be unlocked and
the online operation will fail.
6. Once the disk is online in the storage pool, it can be added to a CSV by right clicking on the disk resource
and choosing "Add to cluster shared volumes". CSVs can include both encrypted and unencrypted
volumes. To check the status of a particular volume for BitLocker encryption, administrators can utilize the
manage-bde -status command with a path to the volume inside the CSV namespace as seen in the example
command line below.
manage-bde -status "C:\ClusterStorage\volume1"
Physical Disk Resources

Unlike CSV2.0 volumes, physical disk resources can only be accessed by one cluster node at a time. This means that
operations such as encrypting, decrypting, locking or unlocking volumes require context to perform. For example,
you cannot unlock or decrypt a physical disk resource if you are not administering the cluster node that owns the
disk resource because the disk resource is not available.
Restrictions on BitLocker actions with cluster volumes
The following table contains information about both Physical Disk Resources (i.e. traditional failover cluster
volumes) and Cluster Shared Volumes (CSV) and the actions that are allowed by BitLocker in each situation.
Action On owner node On Metadata On (Data Maintenance

of failover Server (MDS) of Server) DS of Mode
volume CSV CSV
Manage-bde Blocked Blocked Blocked Allowed

on

off
Manage-bde Blocked Blocked** Blocked Allowed

Pause/Resume

lock
manage-bde Blocked Blocked Blocked Allowed

wipe
Unlock Automatic via Automatic via Automatic via Allowed

cluster service cluster service cluster service
manage-bde Allowed Allowed Blocked Allowed

protector add
manage-bde - Allowed Allowed Blocked Allowed

protector -
delete
manage-bde Allowed (not Allowed (not Blocked Allowed (not

autounlock recommended) recommended) recommended)
Manage-bde - Allowed Allowed Blocked Allowed

upgrade
Shrink Allowed Allowed Blocked Allowed
Extend Allowed Allowed Blocked Allowed
Note: Although the manage-bde -pause command is Blocked in clusters, the cluster service will automatically
resume a paused encryption or decryption from the MDS node
In the case where a physical disk resource experiences a failover event during conversion, the new owning node
will detect the conversion is not complete and will complete the conversion process.
Other considerations when using BitLocker on CSV2.0
Some other considerations to take into account for BitLocker on clustered storage include the following:
BitLocker volumes have to be initialized and beginning encryption before they are available to add to a CSV2.0
volume.
If an administrator needs to decrypt a CSV volume, remove the volume from the cluster or put into disk
maintenance mode. You can add the CSV back to the cluster while waiting for decryption to complete.
If an administrator needs to start encrypting a CSV volume, remove the volume from the cluster or put it in
maintenance mode.
If conversion is paused with encryption in progress and the CSV volume is offline from the cluster, the cluster
thread (health check) will automatically resume conversion when the volume is online to the cluster.
If conversion is paused with encryption in progress and a physical disk resource volume is offline from the
cluster, the BitLocker driver will automatically resume conversion when the volume is online to the cluster.
If conversion is paused with encryption in progress, while the CSV volume is in maintenance mode, the cluster
thread (health check) will automatically resume conversion when moving the volume back from maintenance.
If conversion is paused with encryption in progress, while the disk resource volume is in maintenance mode, the
BitLocker driver will automatically resume conversion when the volume is moved back from maintenance
mode.
Control the health of Windows 10-based devices
Applies to
Windows 10
This article details an end-to-end solution that helps you protect high-value assets by enforcing, controlling, and
reporting the health of Windows 10-based devices.
Introduction
In Bring Your Own Device (BYOD) scenarios, employees bring commercially available devices to access both work-
related resources and their personal data. Users want to use the device of their choice to access the organizations
applications, data, and resources not only from the internal network but also from anywhere. This phenomenon is
also known as the consumerization of IT.
Users want to have the best productivity experience when accessing corporate applications and working on
organization data from their devices. That means they will not tolerate being prompted to enter their work
credentials each time they access an application or a file server. From a security perspective, it also means that
users will manipulate corporate credentials and corporate data on unmanaged devices.
With the increased use of BYOD, there will be more unmanaged and potentially unhealthy systems accessing
corporate services, internal resources, and cloud apps.
Even managed devices can be compromised and become harmful. Organizations need to detect when security has
been breached and react as early as possible in order to protect high-value assets.
As Microsoft moves forward, security investments are increasingly focused on security preventive defenses and
also on detection and response capabilities.
Windows 10 is an important component of an end-to-end security solution that focuses not only on the
implementation of security preventive defenses, but adds device health attestation capabilities to the overall
security strategy.
Description of a robust end-to-end security solution

Todays computing threat landscape is increasing at a speed never encountered before. The sophistication of
criminal attacks is growing, and there is no doubt that malware now targets both consumers and professionals in
all industries.
During recent years, one particular category of threat has become prevalent: advanced persistent threats (APTs).
The term APT is commonly used to describe any attack that seems to target individual organizations on an on-
going basis. In fact, this type of attack typically involves determined adversaries who may use any methods or
techniques necessary.
With the BYOD phenomena, a poorly maintained device represents a target of choice. For an attacker, its an easy
way to breach the security network perimeter, gain access to, and then steal high-value assets.
The attackers target individuals, not specifically because of who they are, but because of who they work for. An
infected device will bring malware into an organization, even if the organization has hardened the perimeter of
networks or has invested in its defensive posture. A defensive strategy is not sufficient against these threats.
A different approach
Rather than the traditional focus on the prevention of compromise, an effective security strategy assumes that
determined adversaries will successfully breach any defenses. It means that its necessary to shift focus away from
preventative security controls to detection of, and response to, security issues. The implementation of the risk
management strategy, therefore, balances investment in prevention, detection, and response.
Because mobile devices are increasingly being used to access corporate information, some way to evaluate device
security or health is required. This section describes how to provision device health assessment in such a way that
high-value assets can be protected from unhealthy devices.
Devices that are used to access corporate resources must be trusted. An efficient end-to-end security approach is
able to evaluate device health and use the current security state when granting access to a high-value asset.
A robust design needs to establish the users identity, strengthen the authentication method if needed, and learn
behavior like the network location the user regularly connects from. Also, a modern approach must be able to
release sensitive content only if user devices are determined to be healthy and secure.
The following figure shows a solution built to assess device health from the cloud. The device authenticates the
user through a connection to an identity provider in the cloud. If the managed asset contains highly confidential
information, the conditional access engine of the identity provider may elect to verify the security compliance of
the mobile device before access is granted. The users device is able to prove its health status that can be sent at
any time or when mobile device management (MDM) requests it.
Windows devices can be protected from low-level rootkits and bootkits by using low-level hardware technologies
such as Unified Extensible Firmware Interface (UEFI) Secure Boot.
Secure Boot is a firmware validation process that helps prevent rootkit attacks; it is part of the UEFI specification.
The intent of UEFI is to define a standard way for the operating system to communicate with modern hardware,
which can perform faster and with more efficient input/output (I/O) functions than older, software interrupt-driven
BIOS systems.
A device health attestation module can communicate measured boot data that is protected by a Trusted Platform
Module (TPM) to a remote service. After the device successfully boots, boot process measurement data is sent to a
trusted cloud service (Health Attestation Service) using a more secure and tamper-resistant communication
channel.
Remote health attestation service performs a series of checks on the measurements. It validates security related
data points, including boot state (Secure Boot, Debug Mode, and so on), and the state of components that manage
security (BitLocker, Device Guard, and so on). It then conveys the health state of the device by sending a health
encrypted blob back to the device.
An MDM solution typically applies configuration policies and deploys software to devices. MDM defines the
security baseline and knows the level of compliance of the device with regular checks to see what software is
installed and what configuration is enforced, as well as determining the health status of the device.
An MDM solution asks the device to send device health information and forward the health encrypted blob to the
remote health attestation service. The remote health attestation service verifies device health data, checks that
MDM is communicating to the same device, and then issues a device health report back to the MDM solution.
An MDM solution evaluates the health assertions and, depending on the health rules belonging to the organization,
can decide if the device is healthy. If the device is healthy and compliant, MDM passes that information to the
identity provider so the organizations access control policy can be invoked to grant access.
Access to content is then authorized to the appropriate level of trust for whatever the health status and other
conditional elements indicate.
Depending on the requirements and the sensitivity of the managed asset, device health status can be combined
with user identity information when processing an access request. Access to content is then authorized to the
appropriate level of trust. The Conditional Access engine may be structured to allow additional verification as
needed by the sensitivity of the managed asset. For example, if access to high-value data is requested, additional
security authentication may need to be established by querying the user to answer a phone call before access is
granted.
Microsofts security investments in Windows 10
In Windows 10, there are three pillars of investments:
Secure identities. Microsoft is part of the FIDO Alliance which aims to provide an interoperable method of
secure authentication by moving away from the use of passwords for authentication, both on the local system
as well as for services like on-premises resources and cloud resources.
Information protection. Microsoft is making investments to allow organizations to have better control over
who has access to important data and what they can do with that data. With Windows 10, organizations can
take advantage of policies that specify which applications are considered to be corporate applications and can
be trusted to access secure data.
Threat resistance. Microsoft is helping organizations to better secure enterprise assets against the threats of
malware and attacks by using security defenses relying on hardware.
Protect, control, and report on the security status of Windows 10-based devices
This section is an overview that describes different parts of the end-to-end security solution that helps protect
high-value assets and information from attackers and malware.
NUMBER PART OF THE SOLUTION DESCRIPTION
1 Windows 10-based device The first time a Windows 10-based

device is powered on, the out-of-box
experience (OOBE) screen is displayed.
During setup, the device can be
automatically registered into Azure
Active Directory (AD) and enrolled in
MDM.
A Windows 10-based device with TPM
can report health status at any time by
using the Health Attestation Service
available with all editions of Windows
10.
2 Identity provider Azure AD contains users, registered

devices, and registered application of
organizations tenant. A device always
belongs to a user and a user can have
multiple devices. A device is represented
as an object with different attributes like
the compliance status of the device. A
trusted MDM can update the
compliance status.
Azure AD is more than a repository.
Azure AD is able to authenticate users
and devices and can also authorize
access to managed resources. Azure AD
has a conditional access control engine
that leverages the identity of the user,
the location of the device and also the
compliance status of the device when
making a trusted access decision.
3 Mobile device management Windows 10 has MDM support that

enables the device to be managed out-
of-box without deploying any agent.
MDM can be Microsoft Intune or any
third-party MDM solution that is
compatible with Windows 10.
4 Remote health attestation The Health Attestation Service is a

trusted cloud service operated by
Microsoft that performs a series of
health checks and reports to MDM
what Windows 10 security features are
enabled on the device.
Security verification includes boot state
(WinPE, Safe Mode, Debug/test modes)
and components that manage security
and integrity of runtime operations
(BitLocker, Device Guard).
5 Enterprise managed asset Enterprise managed asset is the

resource to protect.
For example, the asset can be Office
365, other cloud apps, on-premises web
resources published by Azure AD, or
even VPN access.
The combination of Windows 10-based devices, identity provider, MDM, and remote health attestation creates a
robust end-to-end-solution that provides validation of health and compliance of devices that access high-value
assets.
Protect devices and enterprise credentials against threats

This section describes what Windows 10 offers in terms of security defenses and what control can be measured
and reported to.
Windows 10 hardware -based security defenses
The most aggressive forms of malware try to insert themselves into the boot process as early as possible so that
they can take control of the operating system early and prevent protection mechanisms and antimalware software
from working. This type of malicious code is often called a rootkit or bootkit. The best way to avoid having to deal
with low-level malware is to secure the boot process so that the device is protected from the very start. Windows
10 supports multiple layers of boot protection. Some of these features are available only if specific types of
hardware are installed. For more information, see the Hardware requirements section.
Windows 10 supports features to help prevent sophisticated low-level malware like rootkits and bootkits from
loading during the startup process:
Trusted Platform Module. A Trusted Platform Module (TPM) is a hardware component that provides
unique security features.
Windows 10 leverages security characteristics of a TPM for measuring boot integrity sequence (and based
on that, unlocking automatically BitLocker protected drives), for protecting credentials or for health
attestation.
A TPM implements controls that meet the specification described by the Trusted Computing Group (TCG). At
the time of this writing, there are two versions of TPM specification produced by TCG that are not
compatible with each other:
The first TPM specification, version 1.2, was published in February 2005 by the TCG and standardized
under ISO / IEC 11889 standard.
The latest TPM specification, referred to as TPM 2.0, was released in April 2014 and has been approved
by the ISO/IEC Joint Technical Committee (JTC) as ISO/IEC 11889:2015.
Windows 10 uses the TPM for cryptographic calculations as part of health attestation and to protect the keys
for BitLocker, Windows Hello, virtual smart cards, and other public key certificates. For more information,
see TPM requirements in Windows 10.
Windows 10 recognizes versions 1.2 and 2.0 TPM specifications produced by the TCG. For the most recent
and modern security features, Windows 10 supports only TPM 2.0.
TPM 2.0 provides a major revision to the capabilities over TPM 1.2:
Update crypto strength to meet modern security needs
Support for SHA-256 for PCRs
Support for HMAC command
Cryptographic algorithms flexibility to support government needs
TPM 1.2 is severely restricted in terms of what algorithms it can support
TPM 2.0 can support arbitrary algorithms with minor updates to the TCG specification documents
Consistency across implementations
The TPM 1.2 specification allows vendors wide latitude when choosing implementation details
TPM 2.0 standardizes much of this behavior
Secure Boot. Devices with UEFI firmware can be configured to load only trusted operating system
bootloaders. Secure Boot does not require a TPM.
The most basic protection is the Secure Boot feature, which is a standard part of the UEFI 2.2+ architecture.
On a PC with conventional BIOS, anyone who can take control of the boot process can boot by using an
alternative OS loader, and potentially gain access to system resources. When Secure Boot is enabled, you
can boot using only an OS loader thats signed using a certificate stored in the UEFI Secure Boot DB.
Naturally, the Microsoft certificate used to digitally sign the Windows 10 OS loaders are in that store, which
allows UEFI to validate the certificate as part of its security policy. Secure Boot must be enabled by default on
all computers that are certified for Windows 10 under the Windows Hardware Compatibility Program.
Secure Boot is a UEFI firmware-based feature, which allows for the signing and verification of critical boot
files and drivers at boot time. Secure Boot checks signature values of the Windows Boot Manager, BCD
store, Windows OS loader file, and other boot critical DLLs at boot time before the system is allowed to fully
boot into a usable operating system by using policies that are defined by the OEM at build time. Secure Boot
prevents many types of boot-based rootkit, malware, and other security-related attacks against the
Windows platform. Secure Boot protects the operating system boot process whether booting from local
hard disk, USB, PXE, or DVD, or into full Windows or Windows Recovery Environment (RE). Secure Boot
protects the boot environment of a Windows 10 installation by verifying the signatures of the critical boot
components to confirm malicious activity did not compromise them. Secure Boot protection ends after the
Windows kernel file (ntoskrnl.exe) has been loaded.
Note: Secure Boot protects the platform until the Windows kernel is loaded. Then protections like ELAM
take over.
Secure Boot configuration policy. Extends Secure Boot functionality to critical Windows 10 configuration.
Examples of protected configuration information include protecting Disable Execute bit (NX option) or
ensuring that the test signing policy (code integrity) cannot be enabled. This ensures that the binaries and
configuration of the computer can be trusted after the boot process has completed. Secure Boot
configuration policy does this with UEFI policy. These signatures for these policies are signed in the same
way that operating system binaries are signed for use with Secure Boot.
The Secure Boot configuration policy must be signed by a private key that corresponds to one of the public
keys stored in the Key Exchange Key (KEK) list. The Microsoft Certificate Authority (CA) will be present in the
KEK list of all Windows certified Secure Boot systems. By default, a policy signed by the Microsoft KEK shall
be work on all Secure Boot systems. BootMgr must verify the signature against the KEK list before applying
a signed policy. With Windows 10, the default Secure Boot configuration policy is embedded in bootmgr.
The bootloader verifies the digital signature of the Windows 10 kernel before loading it. The Windows 10
kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers,
startup files, and the ELAM component. This step is important and protects the rest of the boot process by
verifying that all Windows boot components have integrity and can be trusted.
Early Launch Antimalware (ELAM). ELAM tests all drivers before they load and prevents unapproved
drivers from loading.
Traditional antimalware apps dont start until after the boot drivers have been loaded, which gives a rootkit
that is disguised as a driver the opportunity to work. ELAM is a Windows mechanism introduced in a
previous version of Windows that allows antimalware software to run very early in the boot sequence. Thus,
the antimalware component is the first third-party component to run and control the initialization of other
boot drivers until the Windows operating system is operational. When the system is started with a complete
runtime environment (network access, storage, and so on), then a full-featured antimalware is loaded.
ELAM can load a Microsoft or non-Microsoft antimalware driver before all non-Microsoft boot drivers and
applications, thus continuing the chain of trust established by Secure Boot and Trusted Boot. Because the
operating system hasnt started yet, and because Windows needs to boot as quickly as possible, ELAM has a
simple task: Examine every boot driver and determine whether it is on the list of trusted drivers. If its not
trusted, Windows wont load it.
Note: Windows Defender, Microsoft's antimalware included by default in Windows 10, supports ELAM;
it can be replaced with a third-party antimalware compatible solution. The name of the Windows
Defender ELAM driver is WdBoot.sys. Windows Defender in Windows 10 uses its ELAM driver to roll
back any malicious changes made to the Windows Defender driver at the next reboot. This prevents
kernel mode malware making lasting changes to Windows Defenders mini-filter driver before
shutdown or reboot.
The ELAM signed driver is loaded before any other third-party drivers or applications, which allows the
antimalware software to detect and block any attempts to tamper with the boot process by trying to load
unsigned or untrusted code.
The ELAM driver is a small driver with a small policy database that has a very narrow scope, focused on
drivers that are loaded early at system launch. The policy database is stored in a registry hive that is also
measured to the TPM, to record the operational parameters of the ELAM driver. An ELAM driver must be
signed by Microsoft and the associated certificate must contain the complementary EKU
(1.3.6.1.4.1.311.61.4.1).
Virtualization-based security (Hyper-V + Secure Kernel). Virtualization-based security is a completely
new enforced security boundary that allows you to protect critical parts of Windows 10.
Virtualization-based security isolates sensitive code like Kernel Mode Code Integrity or sensitive corporate
domain credentials from the rest of the Windows operating system. For more information, refer to the
Virtualization-based security section.
Hyper-V Code Integrity (HVCI). Hyper-V Code Integrity is a feature of Device Guard that ensures only
drivers, executables, and DLLs that comply with the Device Guard Code Integrity policy are allowed to run.
When enabled and configured, Windows 10 can start the Hyper-V virtualization-based security services,
including Hyper-V Code Integrity (HVCI). HVCI helps protect the system core (kernel), privileged drivers, and
system defenses, like antimalware solutions, by preventing malware from running early in the boot process,
or after startup.
HVCI uses virtualization-based security to isolate Code Integrity, the only way kernel memory can become
executable is through a Code Integrity verification. This means that kernel memory pages can never be
Writable and Executable (W+X) and executable code cannot be directly modified.
Note: Device Guard devices that run Kernel Mode Code Integrity with virtualization-based security must
have compatible drivers. For additional information, please read the Driver compatibility with Device
Guard in Windows 10 blog post.
The Device Guard Code Integrity feature lets organizations control what code is trusted to run into the
Windows kernel and what applications are approved to run in user mode. Its configurable by using a policy.
Device Guard Code Integrity policy is a binary file that Microsoft recommends you sign. The signing of the
Code Integrity policy aids in the protection against a malicious user with Administrator privileges trying to
modify or remove the current Code Integrity policy.
Credential Guard. Credential Guard protects corporate credentials with hardware-based credential
isolation.
In Windows 10, Credential Guard aims to protect domain corporate credentials from theft and reuse by
malware. With Credential Guard, Windows 10 implemented an architectural change that fundamentally
prevents the current forms of the pass-the-hash (PtH) attack.
This is accomplished by leveraging Hyper-V and the new virtualization-based security feature to create a
protected container where trusted code and secrets are isolated from the Windows kernel. That means that
even if the Windows kernel is compromised an attacker has no way to read and extract the data required to
initiate a PtH attack. Credential Guard prevents this because the memory where secrets are stored is no
longer accessible from the regular OS, even in kernel mode - the hypervisor controls who can access the
memory.
Health attestation. The devices firmware logs the boot process, and Windows 10 can send it to a trusted
server that can check and assess the devices health.
Windows 10 takes measurements of the UEFI firmware and each of the Windows and antimalware
components are made as they load during the boot process. Additionally, they are taken and measured
sequentially, not all at once. When these measurements are complete, their values are digitally signed and
stored securely in the TPM and cannot be changed unless the system is reset.
For more information, see Secured Boot and Measured Boot: Hardening Early Boot Components Against
Malware.
During each subsequent boot, the same components are measured, which allows comparison of the
measurements against an expected baseline. For additional security, the values measured by the TPM can be
signed and transmitted to a remote server, which can then perform the comparison. This process, called
remote device health attestation, allows the server to verify health status of the Windows device.
Although Secure Boot is a proactive form of protection, health attestation is a reactive form of boot
protection. Health attestation ships disabled in Windows and is enabled by an antimalware or an MDM
vendor. Unlike Secure Boot, health attestation will not stop the boot process and enter remediation when a
measurement does not work. But with conditional access control, health attestation will help to prevent
access to high-value assets.
Virtualization-based security
Virtualization-based security provides a new trust boundary for Windows 10. leverages Hyper-V hypervisor
technology to enhance platform security. Virtualization-based security provides a secure execution environment to
run specific Windows trusted code (trustlet) and to protect sensitive data.
Virtualization-based security helps to protect against a compromised kernel or a malicious user with Administrator
privileges. Note that virtualization-based security is not trying to protect against a physical attacker.
The following Windows 10 services are protected with virtualization-based security:
Credential Guard (LSA Credential Isolation): prevents pass-the-hash attacks and enterprise credential theft that
happens by reading and dumping the content of lsass memory
Device Guard (Hyper-V Code Integrity): Device Guard uses the new virtualization-based security in Windows
10 to isolate the Code Integrity service from the Windows kernel itself, which lets the service use signatures
defined by your enterprise-controlled policy to help determine what is trustworthy. In effect, the Code Integrity
service runs alongside the kernel in a Windows hypervisor-protected container.
Other isolated services: for example, on Windows Server 2016, there is the vTPM feature that allows you to
have encrypted virtual machines (VMs) on servers.
Note: Virtualization-based security is only available with Windows 10 Enterprise. Virtualization-based security
requires devices with UEFI (2.3.1 or higher) with Secure Boot enabled, x64 processor with Virtualization
Extensions and SLAT enabled. IOMMU, TPM 2.0. and support for Secure Memory overwritten are optional, but
recommended.
The schema below is a high-level view of Windows 10 with virtualization-based security.
Credential Guard
In Windows 10, when Credential Guard is enabled, Local Security Authority Subsystem Service (lsass.exe) runs
sensitive code in an Isolated user mode to help protect data from malware that may be running in the normal user
mode. This helps ensure that protected data is not stolen and reused on remote machines, which mitigates many
PtH-style attacks.
Credential Guard helps protect credentials by encrypting them with either a per-boot or persistent key:
The per-boot key is used for any in-memory credentials that do not require persistence. An example of such a
credential would be a ticket-granting ticket (TGT) session key. This key is negotiated with a Key Distribution
Center (KDC) every time authentication occurs and is protected with a per-boot key.
The persistent key, or some derivative, is used to help protect items that are stored and reloaded after a
reboot. Such protection is intended for long-term storage, and must be protected with a consistent key.
Credential Guard is activated by a registry key and then enabled by using an UEFI variable. This is done to
protect against remote modifications of the configuration. The use of a UEFI variable implies that physical access
is required to change the configuration. When lsass.exe detects that credential isolation is enabled, it then
spawns LsaIso.exe as an isolated process, which ensures that it runs within isolated user mode. The startup of
LsaIso.exe is performed before initialization of a security support provider, which ensures that the secure mode
support routines are ready before any authentication begins.
Device Guard
Device Guard is a new feature of Windows 10 Enterprise that allows organizations to lock down a device to help
protect it from running untrusted software. In this configuration, the only applications allowed to run are those that
are trusted by the organization.
The trust decision to execute code is performed by using Hyper-V Code Integrity, which runs in virtualization-based
security, a Hyper-V protected container that runs alongside regular Windows.
Hyper-V Code Integrity is a feature that validates the integrity of a driver or system file each time it is loaded into
memory. Code integrity detects whether an unsigned driver or system file is being loaded into the kernel, or
whether a system file has been modified by malicious software that is being run by a user account with
Administrator privileges. On x64-based versions of Windows 10 kernel-mode drivers must be digitally signed.
Note: Independently of activation of Device Guard Policy, Windows 10 by default raises the bar for what runs
in the kernel. Windows 10 drivers must be signed by Microsoft, and more specifically, by the WHQL (Windows
Hardware Quality Labs) portal. Additionally, starting in October 2015, the WHQL portal will only accept driver
submissions, including both kernel and user mode driver submissions, that have a valid Extended Validation
(EV) Code Signing Certificate.
With Device Guard in Windows 10, organizations are now able to define their own Code Integrity policy for use on
x64 systems running Windows 10 Enterprise. Organizations have the ability to configure the policy that determines
what is trusted to run. These include drivers and system files, as well as traditional desktop applications and scripts.
The system is then locked down to only run applications that the organization trusts.
Device Guard is a built-in feature of Windows 10 Enterprise that prevents the execution of unwanted code and
applications. Device Guard can be configured using two rule actions - allow and deny:
Allow limits execution of applications to an allowed list of code or trusted publisher and blocks everything else.
Deny completes the allow trusted publisher approach by blocking the execution of a specific application.
At the time of this writing, and according to Microsofts latest research, more than 90 percent of malware is
unsigned completely. So implementing a basic Device Guard policy can simply and effectively help block the vast
majority of malware. In fact, Device Guard has the potential to go further, and can also help block signed malware.
Device Guard needs to be planned and configured to be truly effective. It is not just a protection that is enabled or
disabled. Device Guard is a combination of hardware security features and software security features that, when
configured together, can lock down a computer to help ensure the most secure and resistant system possible.
There are three different parts that make up the Device Guard solution in Windows 10:
The first part is a base set of hardware security features introduced with the previous version of Windows.
TPM for hardware cryptographic operations and UEFI with modern firmware, along with Secure Boot, allows
you to control what the device is running when the systems start.
After the hardware security feature, there is the code integrity engine. In Windows 10, Code Integrity is now
fully configurable and now resides in Isolated user mode, a part of the memory that is protected by
virtualization-based security.
The last part of Device Guard is manageability. Code Integrity configuration is exposed through specific Group
Policy Objects, PowerShell cmdlets, and MDM configuration service providers (CSPs).
For more information on how to deploy Device Guard in an enterprise, see the Device Guard deployment guide.
Device Guard scenarios
As previously described, Device Guard is a powerful way to lock down systems. Device Guard is not intended to be
used broadly and it may not always be applicable, but there are some high-interest scenarios.
Device Guard is useful and applicable on fixed workloads systems like cash registers, kiosk machines, Secure
Admin Workstations (SAWs), or well managed desktops. Device Guard is highly relevant on systems that have very
well-defined software that are expected to run and dont change too frequently. It could also help protect
Information Workers (IWs) beyond just SAWs, as long as what they need to run is known and the set of
applications is not going to change on a daily basis.
SAWs are computers that are built to help significantly reduce the risk of compromise from malware, phishing
attacks, bogus websites, and PtH attacks, among other security risks. Although SAWs cant be considered a silver
bullet security solution to these attacks, these types of clients are helpful as part of a layered, defense-in-depth
approach to security.
To protect high-value assets, SAWs are used to make secure connections to those assets.
Similarly, on corporate fully-managed workstations, where applications are installed by using a distribution tool
like System Center Configuration Manager, Intune, or any third-party device management, then Device Guard is
very applicable. In that type of scenario, the organization has a good idea of the software that an average user is
running.
It could be challenging to use Device Guard on corporate, lightly-managed workstations where the user is typically
allowed to install software on their own. When an organization offers great flexibility, its quite difficult to run
Device Guard in enforcement mode. Nevertheless, Device Guard can be run in Audit mode, and in that case, the
event log will contain a record of any binaries that violated the Device Guard policy. When Device Guard is used in
Audit mode, organizations can get rich data about drivers and applications that users install and run.
Before you can benefit from the protection included in Device Guard, Code Integrity policy must be created by
using tools provided by Microsoft, but the policy can be deployed with common management tools, like Group
Policy. The Code Integrity policy is a binary-encoded XML document that includes configuration settings for both
the User and Kernel-modes of Windows 10, along with restrictions on Windows 10 script hosts. Device Guard Code
Integrity policy restricts what code can run on a device.
Note: Device Guard policy can be signed in Windows 10, which adds additional protection against
administrative users changing or removing this policy.
Signed Device Guard policy offers stronger protection against a malicious local administrator trying to defeat
Device Guard.
When the policy is signed, the GUID of the policy is stored in a UEFI pre-OS secure variable which offers tampering
protection. The only way to update the Device Guard policy subsequently is to provide a new version of the policy
signed by the same signer or from a signer specified as part of the Device Guard policy into the UpdateSigner
section.
The importance of signing applications
On computers with Device Guard, Microsoft proposes to move from a world where unsigned apps can be run
without restriction to a world where only signed and trusted code is allowed to run on Windows 10.
With Windows 10, organizations will make line-of-business (LOB) apps available to members of the organization
through the Windows Store infrastructure. More specifically, LOB apps will be available in a private store within the
public Windows Store. Windows Store signs and distributes Universal Windows apps and Classic Windows apps.
All apps downloaded from the Windows Store are signed.
In organizations today, the vast majority of LOB applications are unsigned. Code signing is frequently viewed as a
tough problem to solve for a variety of reasons, like the lack of code signing expertise. Even if code signing is a best
practice, a lot of internal applications are not signed.
Windows 10 includes tools that allow IT pros to take applications that have been already packaged and run them
through a process to create additional signatures that can be distributed along with existing applications.
Why are antimalware and device management solutions still necessary?
Although allow-list mechanisms are extremely efficient at ensuring that only trusted applications can be run, they
cannot prevent the compromise of a trusted (but vulnerable) application by malicious content designed to exploit a
known vulnerability. Device Guard doesnt protect against user mode malicious code run by exploiting
vulnerabilities.
Vulnerabilities are weaknesses in software that could allow an attacker to compromise the integrity, availability, or
confidentiality of the device. Some of the worst vulnerabilities allow attackers to exploit the compromised device by
causing it to run malicious code without the users knowledge.
Its common to see attackers distributing specially crafted content in an attempt to exploit known vulnerabilities in
user mode software like web browsers (and their plug-ins), Java virtual machines, PDF readers, or document
editors. As of today, 90 percent of discovered vulnerabilities affect user mode applications compared to the
operating system and kernel mode drivers that host them.
To combat these threats, patching is the single most effective control, with antimalware software forming
complementary layers of defense.
Most application software has no facility for updating itself, so even if the software vendor publishes an update that
fixes the vulnerability, the user may not know that the update is available or how to obtain it, and therefore remains
vulnerable to attack. Organizations still need to manage devices and to patch vulnerabilities.
MDM solutions are becoming prevalent as a light-weight device management technology. Windows 10 extends the
management capabilities that have become available for MDMs. One key feature Microsoft has added to Windows
10 is the ability for MDMs to acquire a strong statement of device health from managed and registered devices.
Device health attestation
Device health attestation leverages the TPM to provide cryptographically strong and verifiable measurements of
the chain of software used to boot the device.
For Windows 10-based devices, Microsoft introduces a new public API that will allow MDM software to access a
remote attestation service called Windows Health Attestation Service. A health attestation result, in addition with
other elements, can be used to allow or deny access to networks, apps, or services, based on whether devices prove
to be healthy.
For more information on device health attestation, see the Detect an unhealthy Windows 10-based device section.
Hardware requirements
The following table details the hardware requirements for both virtualization-based security services and the health
attestation feature. For more information, see Minimum hardware requirements.
HARDWARE MOTIVATION
UEFI 2.3.1 or later firmware with Secure Boot enabled Required to support UEFI Secure Boot.
UEFI Secure Boot ensures that the device boots only
authorized code.
Additionally, Boot Integrity (Platform Secure Boot) must
be supported following the requirements in Hardware
Compatibility Specification for Systems for Windows 10
under the subsection:
System.Fundamentals.Firmware.CS.UEFISecureBoot.Conn
ectedStandby
Virtualization extensions, such as Intel VT-x, AMD-V, and Required to support virtualization-based security.
SLAT must be enabled
Note
Device Guard can be enabled without using
virtualization-based security.
X64 processor Required to support virtualization-based security that

uses Windows Hypervisor. Hyper-V is supported only on
x64 processor (and not on x86).
Direct Memory Access (DMA) protection can be enabled
to provide additional memory protection but requires
processors to include DMA protection technologies.
IOMMU, such as Intel VT-d, AMD-Vi Support for the IOMMU in Windows 10 enhances system
resiliency against DMA attacks.
Trusted Platform Module (TPM) Required to support health attestation and necessary for
additional key protections for virtualization-based security.
TPM 2.0 is supported; TPM 1.2 is also supported
beginnning with Windows 10, version 1703.
This section presented information about several closely related controls in Windows 10. The multi-layer defenses
and in-depth approach helps to eradicate low-level malware during boot sequence. Virtualization-based security is
a fundamental operating system architecture change that adds a new security boundary. Device Guard and
Credential Guard respectively help to block untrusted code and protect corporate domain credentials from theft
and reuse. This section also briefly discussed the importance of managing devices and patching vulnerabilities. All
these technologies can be used to harden and lock down devices while limiting the risk of attackers compromising
them.
Detect an unhealthy Windows 10-based device

As of today, many organizations only consider devices to be compliant with company policy after theyve passed a
variety of checks that show, for example, that the operating system is in the correct state, properly configured, and
has security protection enabled. Unfortunately, with todays systems, this form of reporting is not entirely reliable
because malware can spoof a software statement about system health. A rootkit, or a similar low-level exploit, can
report a false healthy state to traditional compliance tools.
The biggest challenge with rootkits is that they can be undetectable to the client. Because they start before
antimalware, and they have system-level privileges, they can completely disguise themselves while continuing to
access system resources. As a result, traditional computers infected with rootkits appear to be healthy, even with
antimalware running.
As previously discussed, the health attestation feature of Windows 10 uses the TPM hardware component to
securely record a measurement of every boot-related component, including firmware, Windows 10 kernel, and
even early boot drivers. Because, health attestation leverages the hardware-based security capabilities of TPM, the
log of all boot measured components remains out of the reach of any malware.
By attesting a trusted boot state, devices can prove that they are not running low-level malware that could spoof
later compliance checks. TPM-based health attestation provides a reliable anchor of trust for assets that contain
high-value data.
What is the concept of device health?
To understand the concept of device health, its important to know traditional measures that IT pros have taken to
prevent the breach of malware. Malware control technologies are highly focused on the prevention of installation
and distribution.
However, the use of traditional malware prevention technologies like antimalware or patching solutions brings a
new set of issues for IT pros: the ability to monitor and control the compliance of devices accessing organizations
resources.
The definition of device compliance will vary based on an organizations installed antimalware, device
configuration settings, patch management baseline, and other security requirements. But health of the device is
part of the overall device compliance policy.
The health of the device is not binary and depends on the organizations security implementation. The Health
Attestation Service provides information back to the MDM on which security features are enabled during the boot
of the device by leveraging trustworthy hardware TPM.
But health attestation only provides information, which is why an MDM solution is needed to take and enforce a
decision.
Remote device health attestation
In Windows 10, health attestation refers to a feature where Measured Boot data generated during the boot process
is sent to a remote device health attestation service operated by Microsoft.
This is the most secure approach available for Windows 10-based devices to detect when security defenses are
down. During the boot process, the TCG log and PCRs values are sent to a remote Microsoft cloud service. Logs are
then checked by the Health Attestation Service to determine what changes have occurred on the device.
A relying party like an MDM can inspect the report generated by the remote health attestation service.
Note: To use the health attestation feature of Windows 10, the device must be equipped with a discrete or
firmware TPM. There is no restriction on any particular edition of Windows 10.
Windows 10 supports health attestation scenarios by allowing applications access to the underlying health
attestation configuration service provider (CSP) so that applications can request a health attestation token. The
measurement of the boot sequence can be checked at any time locally by an antimalware or an MDM agent.
Remote device health attestation combined with an MDM provides a hardware-rooted method for reporting the
current security status and detecting any changes, without having to trust the software running on the system.
In the case where malicious code is running on the device, the use of a remote server is required. If a rootkit is
present on the device, the antimalware is no longer reliable, and its behavior can be hijacked by a malicious code
running early in the startup sequence. That's why it's important to use Secure Boot and Device Guard, to control
which code is loaded during the boot sequence.
The antimalware software can search to determine whether the boot sequence contains any signs of malware, such
as a rootkit. It can also send the TCG log and the PCRs to a remote health attestation server to provide a separation
between the measurement component and the verification component.
Health attestation logs the measurements in various TPM Platform Configuration Registers (PCRs) and TCG logs
during the boot process.
When starting a device equipped with TPM, a measurement of different components is performed. This includes
firmware, UEFI drivers, CPU microcode, and also all the Windows 10 drivers whose type is Boot Start. The raw
measurements are stored in the TPM PCR registers while the details of all events (executable path, authority
certification, and so on) are available in the TCG log.
The health attestation process works as follows:
1. Hardware boot components are measured.
2. Operating system boot components are measured.
3. If Device Guard is enabled, current Device Guard policy is measured.
4. Windows kernel is measured.
5. Antivirus software is started as the first kernel mode driver.
6. Boot start drivers are measured.
7. MDM server through the MDM agent issues a health check command by leveraging the Health Attestation CSP.
8. Boot measurements are validated by the Health Attestation Service
Note: By default, the last 100 system boot logs and all associated resume logs are archived in the
%SystemRoot%\logs\measuredboot folder. The number of retained logs may be set with the registry
REG_DWORD value PlatformLogRetention under the HKLM\SYSTEM\CurrentControlSet\Services\TPM
key. A value of 0 will turn off log archival and a value of 0xffffffff will keep all logs.
The following process describes how health boot measurements are sent to the health attestation service:
1. The client (a Windows 10-based device with TPM) initiates the request with the remote device health attestation
service. Because the health attestation server is expected to be a Microsoft cloud service, the URI is already pre-
provisioned in the client.
2. The client then sends the TCG log, the AIK signed data (PCR values, boot counter) and the AIK certificate
information.
3. The remote device heath attestation service then:
a. Verifies that the AIK certificate is issued by a known and trusted CA and the certificate is valid and not
revoked.
b. Verifies that the signature on the PCR quotes is correct and consistent with the TCG log value.
c. Parses the properties in the TCG log.
d. Issues the device health token that contains the health information, the AIK information, and the boot
counter information. The health token also contains valid issuance time. The device health token is
encrypted and signed, that means that the information is protected and only accessible to issuing health
attestation service.
4. The client stores the health encrypted blob in its local store. The device health token contains device health
status, a device ID (the Windows AIK), and the boot counter.
Device health attestation components

The device health attestation solution involves different components that are TPM, Health Attestation CSP, and the
Windows Health Attestation Service. Those components are described in this section.
This section describes how PCRs (that contain system configuration data), endorsement key (EK) (that act as an
identity card for TPM), SRK (that protect keys) and AIKs (that can report platform state) are used for health
attestation reporting.
In a simplified manner, the TPM is a passive component with limited resources. It can calculate random numbers,
RSA keys, decrypt short data, store hashes taken when booting the device.
A TPM incorporates in a single component:
A RSA 2048-bit key generator
A random number generator
Nonvolatile memory for storing EK, SRK, and AIK keys
A cryptographic engine to encrypt, decrypt, and sign
Volatile memory for storing the PCRs and RSA keys
Endorsement key
The TPM has an embedded unique cryptographic key called the endorsement key. The TPM endorsement key is a
pair of asymmetric keys (RSA size 2048 bits).
The endorsement key public key is generally used for sending securely sensitive parameters, such as when taking
possession of the TPM that contains the defining hash of the owner password. The EK private key is used when
creating secondary keys like AIKs.
The endorsement key acts as an identity card for the TPM. For more information, see Understand the TPM
endorsement key.
The endorsement key is often accompanied by one or two digital certificates:
One certificate is produced by the TPM manufacturer and is called the endorsement certificate. The
endorsement certificate is used to prove the authenticity of the TPM (for example, that its a real TPM
manufactured by a specific chip maker) to local processes, applications, or cloud services. The endorsement
certificate is created during manufacturing or the first time the TPM is initialized by communicating with an
online service.
The other certificate is produced by the platform builder and is called the platform certificate to indicate that a
specific TPM is integrated with a certain device. For certain devices that use firmware-based TPM produced by
Intel or Qualcomm, the endorsement certificate is created when the TPM is initialized during the OOBE of
Windows 10.
Note: Secure Boot protects the platform until the Windows kernel is loaded. Then protections like Trusted Boot,
Hyper-V Code Integrity and ELAM take over. A device that uses Intel TPM or Qualcomm TPM gets a signed
certificate online from the manufacturer that has created the chip and then stores the signed certificate in TPM
storage. For the operation to succeed, if you are filtering Internet access from your client devices, you must
authorize the following URLs:
For Intel firmware TPM: https://ekop.intel.com/ekcertservice

For Qualcomm firmware TPM: https://ekcert.spserv.microsoft.com/
Attestation Identity Keys
Because the endorsement certificate is unique for each device and does not change, the usage of it may present
privacy concerns because it's theoretically possible to track a specific device. To avoid this privacy problem,
Windows 10 issues a derived attestation anchor based on the endorsement certificate. This intermediate key, which
can be attested to an endorsement key, is the Attestation Identity Key (AIK) and the corresponding certificate is
called the AIK certificate. This AIK certificate is issued by a Microsoft cloud service.
Note: Before the device can report its health using the TPM attestation functions, an AIK certificate must be
provisioned in conjunction with a third-party service like the Microsoft Cloud CA service. After it is provisioned,
the AIK private key can be used to report platform configuration. Windows 10 creates a signature over the
platform log state (and a monotonic counter value) at each boot by using the AIK.
The AIK is an asymmetric (public/private) key pair that is used as a substitute for the EK as an identity for the TPM
for privacy purposes. The private portion of an AIK is never revealed or used outside the TPM and can only be used
inside the TPM for a limited set of operations. Furthermore, it can only be used for signing, and only for limited,
TPM-defined operations.
Windows 10 creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft is
hosting a cloud service called Microsoft Cloud CA to establish cryptographically that it is communicating with a real
TPM and that the TPM possesses the presented AIK. After the Microsoft Cloud CA service has established these
facts, it will issue an AIK certificate to the Windows 10-based device.
Many existing devices that will upgrade to Windows 10 will not have a TPM, or the TPM will not contain an
endorsement certificate. To accommodate those devices, Windows 10 allows the issuance of AIK
certificates without the presence of an endorsement certificate. Such AIK certificates are not issued by
Microsoft Cloud CA. Note that this is not as trustworthy as an endorsement certificate that is burned into the device
during manufacturing, but it will provide compatibility for advanced scenarios like Windows Hello for Business
without TPM.
In the issued AIK certificate, a special OID is added to attest that endorsement certificate was used during the
attestation process. This information can be leveraged by a relying party to decide whether to reject devices that
are attested using AIK certificates without an endorsement certificate or accept them. Another scenario can be to
not allow access to high-value assets from devices that are attested by an AIK certificate that is not backed by an
endorsement certificate.
Storage root key
The storage root key (SRK) is also an asymmetric key pair (RSA with a minimum of 2048 bits length). The SRK has
a major role and is used to protect TPM keys, so that these keys cannot be used without the TPM. The SRK key is
created when the ownership of the TPM is taken.
Platform Configuration Registers
The TPM contains a set of registers that are designed to provide a cryptographic representation of the software and
state of the system that booted. These registers are called Platform Configuration Registers (PCRs).
The measurement of the boot sequence is based on the PCR and TCG log. To establish a static root of trust, when
the device is starting, the device must be able to measure the firmware code before execution. In this case, the Core
Root of Trust for Measurement (CRTM) is executed from the boot, calculates the hash of the firmware, then stores it
by expanding the register PCR[0] and transfers execution to the firmware.
PCRs are set to zero when the platform is booted, and it is the job of the firmware that boots the platform to
measure components in the boot chain and to record the measurements in the PCRs. Typically, boot components
take the hash of the next component that is to be run and record the measurements in the PCRs. The initial
component that starts the measurement chain is implicitly trusted. This is the CRTM. Platform manufacturers are
required to have a secure update process for the CRTM or not permit updates to it. The PCRs record a cumulative
hash of the components that have been measured.
The value of a PCR on its own is hard to interpret (it is just a hash value), but platforms typically keep a log with
details of what has been measured, and the PCRs merely ensure that the log has not been tampered with. The logs
are referred as a TCG log. Each time a register PCR is extended, an entry is added to the TCG log. Thus, throughout
the boot process, a trace of the executable code and configuration data is created in the TCG log.
TPM provisioning
For the TPM of a Windows 10-based device to be usable, it must first be provisioned. The process of provisioning
differs somewhat based on TPM versions, but, when successful, it results in the TPM being usable and the owner
authorization data (ownerAuth) for the TPM being stored locally on the registry.
When the TPM is provisioned, Windows 10 will first attempt to determine the EK and locally stored ownerAuth
values by looking in the registry at the following location:
HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement
During the provisioning process, the device may need to be restarted.
Note that the Get-TpmEndorsementKeyInfo PowerShell cmdlet can be used with administrative privilege to get
information about the endorsement key and certificates of the TPM.
If the TPM ownership is not known but the EK exists, the client library will provision the TPM and will store the
resulting ownerAuth value into the registry if the policy allows it will store the SRK public portion at the following
location: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Admin\SRKPub
As part of the provisioning process, Windows 10 will create an AIK with the TPM. When this operation is
performed, the resulting AIK public portion is stored in the registry at the following location:
HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\WindowsAIKPub
Note: For provisioning AIK certificates and filtering Internet access, you must authorize the following wildcard
URL: https://*.microsoftaik.azure.net
Windows 10 Health Attestation CSP

Windows 10 contains a configuration service provider (CSP) specialized for interacting with the health attestation
feature. A CSP is a component that plugs into the Windows MDM client and provides a published protocol for how
MDM servers can configure settings and manage Windows-based devices. The management protocol is
represented as a tree structure that can be specified as URIs with functions to perform on the URIs such as get,
set, delete, and so on.
The following is a list of functions performed by the Windows 10 Health Attestation CSP:
Collects data that is used to verify a devices health status
Forwards the data to the Health Attestation Service
Provisions the Health Attestation Certificate that it receives from the Health Attestation Service
Upon request, forwards the Health Attestation Certificate (received from the Health Attestation Service) and
related runtime information to the MDM server for verification
During a health attestation session, the Health Attestation CSP forwards the TCG logs and PCRs values that are
measured during the boot, by using a secure communication channel to the Health Attestation Service.
When an MDM server validates that a device has attested to the Health Attestation Service, it will be given a set of
statements and claims about how that device booted, with the assurance that the device did not reboot between
the time that it attested its health and the time that the MDM server validated it.
Windows Health Attestation Service
The role of Windows Health Attestation Service is essentially to evaluate a set of health data (TCG log and PCR
values), make a series of detections (based on available health data) and generate encrypted health blob or
produce report to MDM servers.
Note: Both device and MDM servers must have access to has.spserv.microsoft.com using the TCP protocol
on port 443 (HTTPS).
Checking that a TPM attestation and the associated log are valid takes several steps:
1. First, the server must check that the reports are signed by trustworthy AIKs. This might be done by checking
that the public part of the AIK is listed in a database of assets, or perhaps that a certificate has been checked.
2. After the key has been checked, the signed attestation (a quote structure) should be checked to see whether it is
a valid signature over PCR values.
3. Next the logs should be checked to ensure that they match the PCR values reported.
4. Finally, the logs themselves should be examined by an MDM solution to see whether they represent known or
valid security configurations. For example, a simple check might be to see whether the measured early OS
components are known to be good, that the ELAM driver is as expected, and that the ELAM driver policy file is
up to date. If all of these checks succeed, an attestation statement can be issued that later can be used to
determine whether or not the client should be granted access to a resource.
The Health Attestation Service provides the following information to an MDM solution about the health of the
device:
Secure Boot enablement
Boot and kernel debug enablement
BitLocker enablement
VSM enabled
Signed or unsigned Device Guard Code Integrity policy measurement
ELAM loaded
Safe Mode boot, DEP enablement, test signing enablement
Device TPM has been provisioned with a trusted endorsement certificate
For completeness of the measurements, see Health Attestation CSP.
The following table presents some key items that can be reported back to MDM depending on the type of Windows
10-based device.
OS TYPE KEY ITEMS THAT CAN BE REPORTED
Windows 10 Mobile PCR0 measurement

Secure Boot enabled
Secure Boot db is default
Secure Boot dbx is up to date
Secure Boot policy GUID is default
Device Encryption enabled
Code Integrity revocation list timestamp/version is
up to date
Windows 10 for desktop editions PCR0 measurement

Secure Boot Enabled
Secure Boot db matches Expected
Secure Boot dbx is up to date
Secure Boot policy GUID matches Expected
BitLocker enabled
Virtualization-based security enabled
ELAM was loaded
Code Integrity version is up to date
Code Integrity policy hash matches Expected
Leverage MDM and the Health Attestation Service

To make device health relevant, the MDM solution evaluates the device health report and is configured to the
organizations device health requirements.
A solution that leverages MDM and the Health Attestation Service consists of three main parts:
1. A device with health attestation enabled. This will usually be done as a part of enrollment with an MDM provider
(health attestation will be disabled by default).
2. After this is enabled, and every boot thereafter, the device will send health measurements to the Health
Attestation Service hosted by Microsoft, and it will receive a health attestation blob in return.
3. At any point after this, an MDM server can request the health attestation blob from the device and ask Health
Attestation Service to decrypt the content and validate that its been attested.
Interaction between a Windows 10-based device, the Health Attestation Service, and MDM can be performed as
follows:
1. The client initiates a session with the MDM server. The URI for the MDM server would be part of the client app
that initiates the request. The MDM server at this time could request the health attestation data by using the
appropriate CSP URI.
2. The MDM server specifies a nonce along with the request.
3. The client then sends the AIK quoted nonce + the boot counter and the health blob information. This health blob
is encrypted with a Health Attestation Service public key that only the Health Attestation Service can decrypt.
4. The MDM server:
a. Verifies that the nonce is as expected.
b. Passes the quoted data, the nonce and the encrypted health blob to the Health Attestation Service server.
5. The Health Attestation Service:
a. Decrypts the health blob.
b. Verifies that the boot counter in the quote is correct using the AIK in the health blob and matches the
value in the health blob.
c. Verifies that the nonce matches in the quote and the one that is passed from MDM.
d. Because the boot counter and the nonce are quoted with the AIK from the health blob, it also proves that
the device is the same one as the one for which the health blob has been generated.
e. Sends data back to the MDM server including health parameters, freshness, and so on.
Note: The MDM server (relying party) never performs the quote or boot counter validation itself. It gets the
quoted data and the health blob (which is encrypted) and sends the data to the Health Attestation Service for
validation. This way, the AIK is never visible to the MDM, which thereby addresses privacy concerns.
Setting the requirements for device compliance is the first step to ensure that registered devices that do not meet
health and compliance requirements are detected, tracked, and have actions enforced by the MDM solution.
Devices that attempt to connect to resources must have their health evaluated so that unhealthy and noncompliant
devices can be detected and reported. To be fully efficient, an end-to-end security solution must impose a
consequence for unhealthy devices like refusing access to high-value assets. That is the purpose of conditional
access control, which is detailed in the next section.
Control the security of a Windows 10-based device before access is
granted
Todays access control technology, in most cases, focuses on ensuring that the right people get access to the right
resources. If users can authenticate, they get access to resources using a device that the organizations IT staff and
systems know very little about. Perhaps there is some check such as ensuring that a device is encrypted before
giving access to email, but what if the device is infected with malware?
The remote device health attestation process uses measured boot data to verify the health status of the device. The
health of the device is then available for an MDM solution like Intune.
Note: For the latest information on Intune and Windows 10 features support, see the Microsoft Intune blog
and What's new in Microsoft Intune.
The figure below shows how the Health Attestation Service is expected to work with Microsofts cloud-based Intune
MDM service.
An MDM solution can then leverage health state statements and take them to the next level by coupling with client
policies that will enable conditional access to be granted based on the devices ability to prove that its malware
free, its antimalware system is functional and up to date, the firewall is running, and the devices patch state is
compliant.
Finally, resources can be protected by denying access to endpoints that are unable to prove theyre healthy. This
feature is much needed for BYOD devices that need to access organizational resources.
Built-in support of MDM in Windows 10
Windows 10 has an MDM client that ships as part of the operating system. This enables MDM servers to manage
Windows 10-based devices without requiring a separate agent.
Third-party MDM server support
Third-party MDM servers can manage Windows 10 by using the MDM protocol. The built-in management client is
able to communicate with a compatible server that supports the OMA-DM protocol to perform enterprise
management tasks. For additional information, see Azure Active Directory integration with MDM.
Note: MDM servers do not need to create or download a client to manage Windows 10. For more information,
see Mobile device management.
The third-party MDM server will have the same consistent first-party user experience for enrollment, which also
provides simplicity for Windows 10 users.
Management of Windows Defender by third-party MDM
This management infrastructure makes it possible for IT pros to use MDM-capable products like Intune, to manage
health attestation, Device Guard, or Windows Defender on Windows 10-based devices, including BYODs that arent
domain joined. IT pros will be able to manage and configure all of the actions and settings they are familiar with
customizing by using Intune with Intune Endpoint Protection on down-level operating systems. Admins that
currently only manage domain joined devices through Group Policy will find it easy to transition to managing
Windows 10-based devices by using MDM because many of the settings and actions are shared across both
mechanisms.
For more information on how to manage Windows 10 security and system settings with an MDM solution, see
Custom URI settings for Windows 10 devices.
Conditional access control
On most platforms, the Azure Active Directory (Azure AD) device registration happens automatically during
enrollment. The device states are written by the MDM solution into Azure AD, and then read by Office 365 (or by
any authorized Windows app that interacts with Azure AD) the next time the client tries to access an Office 365
compatible workload.
If the device is not registered, the user will get a message with instructions on how to register (also known as
enrolling). If the device is not compliant, the user will get a different message that redirects them to the MDM web
portal where they can get more information on the compliance problem and how to resolve it.
Azure AD authenticates the user and the device, MDM manages the compliance and conditional access policies,
and the Health Attestation Service reports about the health of the device in an attested way.
Office 365 conditional access control

Azure AD enforces conditional access policies to secure access to Office 365 services. A tenant admin can create a
conditional access policy that blocks a user on a non-compliant device from accessing an Office 365 service. The
user must conform to the companys device policies before access can be granted to the service. Alternately, the
admin can also create a policy that requires users to just enroll their devices to gain access to an Office 365 service.
Policies may be applied to all users of an organization, or limited to a few target groups and enhanced over time to
include additional target groups.
When a user requests access to an Office 365 service from a supported device platform, Azure AD authenticates
the user and device from which the user launches the request; and grants access to the service only when the user
conforms to the policy set for the service. Users that do not have their device enrolled are given remediation
instructions on how to enroll and become compliant to access corporate Office 365 services.
When a user enrolls, the device is registered with Azure AD, and enrolled with a compatible MDM solution like
Intune.
Note Microsoft is working with third-party MDM ISVs to support automated MDM enrollment and policy
based access checks. Steps to turn on auto-MDM enrollment with Azure AD and Intune are explained in the
Windows 10, Azure AD And Microsoft Intune: Automatic MDM Enrollment Powered By The Cloud! blog post.
When a user enrolls a device successfully, the device becomes trusted. Azure AD provides single-sign-on to access
company applications and enforces conditional access policy to grant access to a service not only the first time the
user requests access, but every time the user requests to renew access.
The user will be denied access to services when sign-in credentials are changed, a device is lost/stolen, or the
compliance policy is not met at the time of request for renewal.
Depending on the type of email application that employees use to access Exchange online, the path to establish
secured access to email can be slightly different. However, the key components: Azure AD, Office 365/Exchange
Online, and Intune, are the same. The IT experience and end-user experience also are similar.
Clients that attempt to access Office 365 will be evaluated for the following properties:
Is the device managed by an MDM?
Is the device registered with Azure AD?
Is the device compliant?
To get to a compliant state, the Windows 10-based device needs to:
Enroll with an MDM solution.
Register with Azure AD.
Be compliant with the device policies set by the MDM solution.
Note: At the present time, conditional access policies are selectively enforced on users on iOS and Android
devices. For more information, see the Azure AD, Microsoft Intune and Windows 10 Using the cloud to
modernize enterprise mobility! blog post.
Cloud and on-premises apps conditional access control

Conditional access control is a powerful policy evaluation engine built into Azure AD. It gives IT pros an easy way to
create access rules beyond Office 365 that evaluate the context of a user's logon to make real-time decisions about
which applications they should be allowed to access.
IT pros can configure conditional access control policies for cloud SaaS applications secured by Azure AD and even
on-premises applications. Access rules in Azure AD leverage the conditional access engine to check device health
and compliance state reported by a compatible MDM solution like Intune in order to determine whether to allow
access.
For more information about conditional access, see Azure Conditional Access Preview for SaaS Apps.
Note: Conditional access control is an Azure AD Premium feature that's also available with EMS. If you don't
have an Azure AD Premium subscription, you can get a trial from the Microsoft Azure site.
For on-premises applications there are two options to enable conditional access control based on a device's
compliance state:
For on-premises applications that are published through the Azure AD Application Proxy, you can configure
conditional access control policies as you would for cloud applications. For more details, see the Azure AD
Conditional Access preview updated: Now supports On-Premises and Custom LOB apps blog post.
Additionally, Azure AD Connect will sync device compliance information from Azure AD to on-premises AD.
ADFS on Windows Server 2016 will support conditional access control based on a device's compliance state. IT
pros will configure conditional access control policies in ADFS that use the device's compliance state reported
by a compatible MDM solution to secure on-premises applications.
The following process describes how Azure AD conditional access works:

1. User has already enrolled with MDM through Workplace Access/Azure AD join which registers device with
Azure AD.
2. When the device boots or resumes from hibernate, a task Tpm-HASCertRetr is triggered to request in
background a health attestation blob. Device sends TPM boot measurements to the Health Attestation Service.
3. Health Attestation Service validates device state and issues an encrypted blob to the device based on the health
state with details on failed checks (if any).
4. User logs on and the MDM agent contacts the Intune/MDM server.
5. MDM server pushes down new policies if available and queries health blob state and other inventory state.
6. Device sends a health attestation blob previously acquired and also the value of the other state inventory
requested by the Intune/MDM server.
7. Intune/MDM server sends the health attestation blob to Health Attestation Service to be validated.
8. Health Attestation Service validates that the device which sent the health attestation blob is healthy, and returns
this result to Intune/MDM server.
9. Intune/MDM server evaluates compliance based on the compliance and the queried inventory/health attestation
state from device.
10. Intune/MDM server updates compliance state against device object in Azure AD.
11. User opens app, attempts to access a corporate managed asset.
12. Access gated by compliance claim in Azure AD.
13. If the device is compliant and the user is authorized, an access token is generated.
14. User can access the corporate managed asset.
For more information about Azure AD join, see the Azure AD & Windows 10: Better Together for Work or School
white paper.
Conditional access control is a topic that many organizations and IT pros may not know as well as they should. The
different attributes that describe a user, a device, compliance, and context of access are very powerful when used
with a conditional access engine. Conditional access control is an essential step that helps organizations secure
their environment.
Takeaways and summary

The following list contains high-level key take-aways to improve the security posture of any organization. However,
the few take-aways presented in this section should not be interpreted as an exhaustive list of security best
practices.
Understand that no solution is 100 percent secure
If determined adversaries with malicious intent gain physical access to the device, they could eventually
break through its security layers and control it.
Use health attestation with an MDM solution
Devices that attempt to connect to high-value assets must have their health evaluated so that unhealthy and
noncompliant devices can be detected, reported, and eventually blocked.
Use Credential Guard
Credential Guard is a feature that greatly helps protect corporate domain credentials from pass-the-hash
attacks.
Use Device Guard
Device Guard is a real advance in security and an effective way to help protect against malware. The new
Device Guard feature in Windows 10 blocks untrusted apps (apps not authorized by your organization).
Sign Device Guard policy
Signed Device Guard policy helps protect against a user with administrator privileges trying to defeat the
current policy. When a policy is signed, the only way to modify Device Guard subsequently is to provide a
new version of the policy signed by the same signer or from a signer specify as part of the Device Guard
policy.
Use virtualization-based security
When you have Kernel Mode Code Integrity protected by virtualization-based security, the code integrity
rules are still enforced even if a vulnerability allows unauthorized kernel mode memory access. Keep in
mind that Device Guard devices that run Kernel Code Integrity with virtualization-based security must have
compatible drivers.
Start to deploy Device Guard with Audit mode
Deploy Device Guard policy to targeted computers and devices in Audit mode. Monitor the Code Integrity
event log that indicates a program or a driver would have been blocked if Device Guard was configured in
Enforcement mode. Adjust Device Guard rules until a high level of confidence has been reached. After the
testing phase has been completed, Device Guard policy can be switched to Enforcement mode.
Build an isolated reference machine when deploying Device Guard
Because the corporate network can contain malware, you should start to configure a reference environment
that is isolated from your main corporate network. After that, you can create a code integrity policy that
includes the trusted applications you want to run on your protected devices.
Use AppLocker when it makes sense
Although AppLocker is not considered a new Device Guard feature, it complements Device Guard
functionality for some scenarios like being able to deny a specific Universal Windows apps for a specific user
or a group of users.
Lock down firmware and configuration
After Windows 10 is installed, lock down firmware boot options access. This prevents a user with physical
access from modifying UEFI settings, disabling Secure Boot, or booting other operating systems. Also, in
order to protect against an administrator trying to disable Device Guard, add a rule in the current Device
Guard policy that will deny and block execution of the C:\Windows\System32\SecConfig.efi tool.
Health attestation is a key feature of Windows 10 that includes client and cloud components to control access to
high-value assets based on a user and their devices identity and compliance with corporate governance policy.
Organizations can choose to detect and report unhealthy devices, or to configure health enforcement rules based
on their needs. Health attestation provides an end-to-end security model and integration points, which vendors
and software developers can use to build and integrate a customized solution.
Related topics
Protect derived domain credentials with Credential Guard
Trusted Platform Module technology overview
Applies to
Windows 10
Windows Server 2016
Device Guard is a combination of enterprise-related hardware and software security features that, when configured
together, will lock a device down so that it can only run trusted applications that you define in your code integrity
policies. If the app isnt trusted it cant run, period. With hardware that meets basic requirements, it also means that
even if an attacker manages to get control of the Windows kernel, he or she will be much less likely to be able to
run malicious executable code. With appropriate hardware, Device Guard can use the new virtualization-based
security in Windows 10 (available in Enterprise and Education desktop SKUs and in all Server SKUs) to isolate the
Code Integrity service from the Microsoft Windows kernel itself. In this case, the Code Integrity service runs
alongside the kernel in a Windows hypervisor-protected container.
This guide explores the individual features in Device Guard as well as how to plan for, configure, and deploy them.
It includes:
Introduction to Device Guard: virtualization-based security and code integrity policies
Requirements and deployment planning guidelines for Device Guard
Optional: Create a code signing certificate for code integrity policies
Deploy code integrity policies: policy rules and file rules
Deploy code integrity policies: steps
Deploy catalog files to support code integrity policies
Related topics
AppLocker overview
Code integrity
Protect derived domain credentials with Credential Guard
Driver compatibility with Device Guard in Windows 10
Dropping the Hammer Down on Malware Threats with Windows 10s Device Guard
Introduction to Device Guard: virtualization-based
security and code integrity policies
Applies to
Windows 10
Windows Server 2016
With thousands of new malicious files created every day, using traditional methods like antivirus solutions
signature-based detection to fight against malwareprovides an inadequate defense against new attacks. Device
Guard on Windows 10 Enterprise changes from a mode where apps are trusted unless blocked by an antivirus or
other security solution, to a mode where the operating system trusts only apps authorized by your enterprise. You
designate these trusted apps by creating code integrity policies.
Like the operating system, code integrity contains two primary components: kernel mode code integrity (KMCI)
and user mode code integrity (UMCI). KMCI has been available in previous versions of the Windows operating
system, and protects the kernel mode from running unsigned drivers. In Windows 10 and Windows Server 2016,
UMCI is also available, to help protect against viruses and malware.
To increase the security level offered by code integrity policies, Device Guard can leverage advanced hardware
features on hardware that supports them. These features include CPU virtualization extensions (called "Intel VT-x"
or "AMD-V") and second-level address translation (SLAT). In addition, hardware that includes input/output
memory management units (IOMMUs) provides even stronger protections. When you enable the features
associated with CPU virtualization extensions and SLAT, the Code Integrity service can run alongside the kernel in
a Windows hypervisor-protected container. The following table provides more information about how Device
Guard and these hardware features can help protect against various threats.
For an overview of the process of deploying Device Guard features, see Planning and getting started on the Device
Guard deployment process.
How Device Guard features help protect against threats

The following table lists security threats and describes the corresponding Device Guard features:
HOW A DEVICE GUARD FEATURE HELPS PROTECT AGAINST THE

SECURITY THREAT IN THE ENTERPRISE THREAT
Exposure to new malware, for which the "signature" is not Code integrity policies: You can maintain a whitelist of
yet known software that is allowed to run (a configurable code integrity
policy), rather than trying to stay ahead of attackers by
maintaining a constantly-updated list of "signatures" of
software that should be blocked. This approach uses the
trust-nothing model well known in mobile device operating
systems.
Only code that is verified by Code Integrity, usually through
the digital signature that you have identified as being from a
trusted signer, is allowed to run. This allows full control over
allowed code in both kernel and user mode.
Specialized hardware required? No security-related

hardware features are required, although code integrity
policies are strengthened by such features, as described in the
last three rows of this table.
Exposure to unsigned code (most malware is unsigned) Code integrity policies, plus catalog files as
needed: Because most malware is unsigned, using a code
integrity policy (which in most cases requires signed code) can
immediately help protect against a large number of threats.
However, many organizations use unsigned line-of-business
(LOB) applications, for which the process of signing might be
difficult. This has changed in Windows 10, because you can
use a tool called Package Inspector to create a catalog of all
deployed and executed binary files for your trusted
applications. After you sign and distribute the catalog, your
trusted applications can be handled by code integrity policies
in the same way as any other signed application. With this
foundation, you can more easily block all unsigned
applications, allowing only signed applications to run.
Specialized hardware required? No security-related

hardware features are required for creating and using code
integrity policies and catalogs. However, code integrity
policies and catalogs are strengthened by the hardware
features, as described in later rows of this table.
Malware that gains access to the kernel and then, from Virtualization-based security (VBS): This is protection that
within the kernel, captures sensitive information or damages uses the hypervisor to help protect the kernel and other parts
the system of the operating system. When VBS is enabled, it strengthens
either the default kernel-mode code integrity policy (which
protects against bad drivers or system files), or the
configurable code integrity policy that you deploy.
With VBS, even if malware gains access to the kernel, the
effects can be severely limited, because the hypervisor can
prevent the malware from executing code. The hypervisor, the
most privileged level of system software, enforces R/W/X
permissions across system memory. Code integrity checks are
performed in a secure environment which is resistant to
attack from kernel mode software, and page permissions for
kernel mode are set and maintained by the hypervisor. Even if
there are vulnerabilities that allow memory modification, like a
buffer overflow, the modified memory cannot be executed.
Specialized hardware required? Yes, VBS requires at least

CPU virtualization extensions and SLAT, as described in
Hardware, firmware, and software requirements for Device
Guard.
DMA-based attacks, for example, attacks launched from a Virtualization-based security (VBS) using IOMMUs: With
malicious device that reads secrets from memory, making the this type of VBS protection, when the DMA-based attack
enterprise more vulnerable to attack makes a memory request, input/output memory
management units (IOMMUs) will evaluate the request and
deny access.
Specialized hardware required? Yes, IOMMUs are a

hardware feature that supports the hypervisor, and if you
choose hardware that includes them, they can help protect
against malicious attempts to access memory.
Exposure to boot kits or to a physically present attacker Universal Extensible Firmware Interface (UEFI) Secure
at boot time Boot: Secure Boot and related methods protect the boot
process and firmware from tampering. This tampering can
come from a physically present attacker or from forms of
malware that run early in the boot process or in kernel after
startup. UEFI is locked down (Boot order, Boot entries, Secure
Boot, Virtualization extensions, IOMMU, Microsoft UEFI CA),
so the settings in UEFI cannot be changed to compromise
Device Guard security.
Specialized hardware required? With UEFI Secure Boot,

the requirements are firmware requirements. For more
information, see Hardware, firmware, and software
requirements for Device Guard.
In this guide, you learn about the individual features found within Device Guard as well as how to plan for,
configure, and deploy them. Device Guard with configurable code integrity is intended for deployment alongside
additional threat-mitigating Windows features such as Credential Guard and AppLocker.

As of Windows 10, version 1703, you can use code integrity policies not only to control applications, but also to
control whether specific plug-ins, add-ins, and modules can run from specific apps (such as a line-of-business
application or a browser). For more information, see Use a code integrity policy to control specific plug-ins, add-
ins, and modules.
Tools for managing Device Guard features

You can easily manage Device Guard features by using familiar enterprise and client-management tools that IT
pros use every day:
Group Policy. Windows 10 provides an administrative template to configure and deploy the configurable
code integrity policies for your organization. This template also allows you to specify which hardware-
based security features you would like to enable and deploy. You can manage these settings along with
your existing Group Policy Objects (GPOs), which makes it simpler to implement Device Guard features. In
addition to these code integrity and hardware-based security features, you can use Group Policy to help
you manage your catalog files.
For a description of catalog files, see the table row describing Exposure to unsigned code in How
Device Guard features help protect against threats, earlier in this topic.
For information about using Group Policy as a deployment tool, see:
Deploy catalog files with Group Policy
Deploy and manage code integrity policies with Group Policy
Microsoft System Center Configuration Manager. You can use System Center Configuration Manager
to simplify deployment and management of catalog files, code integrity policies, and hardware-based
security features, as well as provide version control. For more information, see Deploy catalog files with
System Center Configuration Manager.
Microsoft Intune. In a future release of Microsoft Intune, Microsoft is considering including features that
will support the deployment and management of code integrity policies and catalog files.
Windows PowerShell. You can use Windows PowerShell to create and service code integrity policies. For
more information, see Deploy code integrity policies: steps and Configurable Code Integrity Policy for
Windows PowerShell.
These options provide the same experience you're used to in order to manage your existing enterprise
management solutions.
For more information about the deployment of Device Guard features, see:
Other features that relate to Device Guard

Device Guard with AppLocker
Although AppLocker is not considered a new Device Guard feature, it complements Device Guard functionality
when enforced code integrity cannot be fully implemented or its functionality does not cover every desired
scenario. There are many scenarios in which code integrity policies would be used alongside AppLocker rules. As a
best practice, you should enforce code integrity policies at the most restrictive level possible for your organization,
and then you can use AppLocker to fine-tune the restrictions to an even lower level.
Note One example of how Device Guard functionality can be enhanced by AppLocker is when you want to
limit universal applications. Universal applications have already been validated by Microsoft to be trustworthy
to run, but an organization may not want to allow specific universal applications to run in their environment.
You can accomplish this enforcement by using an AppLocker rule.
AppLocker and Device Guard should run side-by-side in your organization, which offers the best of both security
features at the same time and provides the most comprehensive security to as many devices as possible. In
addition to these features, we recommend that you continue to maintain an enterprise antivirus solution for a
well-rounded enterprise security portfolio.
Device Guard with Credential Guard
Another Windows 10 feature that employs VBS is Credential Guard. Credential Guard provides additional
protection to Active Directory domain users by storing domain credentials within the same type of VBS
virtualization container that hosts code integrity. By isolating these domain credentials from the active user mode
and kernel mode, they have a much lower risk of being stolen. For more information about Credential Guard
(which is not a feature within Device Guard), see Protect derived domain credentials with Credential Guard.
Credential Guard is targeted at resisting pass-the-hash and pass-the-ticket techniques. By employing multifactor
authentication with Credential Guard, organizations can gain additional protection against such threats.
Requirements and deployment planning guidelines
for Device Guard
Applies to
Windows 10
Windows Server 2016
The information in this article is intended for IT professionals, and provides a foundation for Planning and getting
started on the Device Guard deployment process.
Note If you are an OEM, see the requirements information at PC OEM requirements for Device Guard and
Credential Guard.
Hardware, firmware, and software requirements for Device Guard

To deploy Device Guard in a way that uses all of its virtualization-based security (VBS) features, the computers you
are protecting must meet certain hardware, firmware, and software requirements. However, computers lacking
some of the hardware and firmware requirements will still receive some protection when you deploy code integrity
policiesthe difference is that those computers will not be as hardened against certain threats.
For example, hardware that includes CPU virtualization extensions and SLAT will be hardened against malware that
attempts to gain access to the kernel, but without protected BIOS options such as Boot only from internal hard
drive, the computer could be booted (by a malicious person who has physical access) into an operating system on
bootable media. For an outline of how VBS-related hardware strengthens the hardening offered by Device Guard,
see Introduction to Device Guard: virtualization-based security and code integrity policies.
You can deploy Device Guard in phases, and plan these phases in relation to the computer purchases you plan for
your next hardware refresh.
WARNING
Virtualization-based protection of code integrity may be incompatible with some devices and applications. We strongly
recommend testing this configuration in your lab before enabling virtualization-based protection of code integrity on
production systems. Failure to do so may result in unexpected failures up to and including data loss or a blue screen error
(also called a stop error).
The following tables provide more information about the hardware, firmware, and software required for
deployment of various Device Guard features. The tables describe baseline protections, plus protections for
improved security that are associated with hardware and firmware options available in 2015, 2016, and 2017.
Notes
To understand the requirements in the following tables, you will need to be familiar with the main features in
Device Guard: configurable code integrity policies, virtualization-based security (VBS), and Universal Extensible
Firmware Interface (UEFI) Secure Boot. For information about these features, see How Device Guard features
help protect against threats.
Beginning with Windows 10, version 1607, Trusted Platform Module (TPM 2.0) must be enabled by default
on new computers.
Baseline protections
BASELINE PROTECTIONS DESCRIPTION SECURITY BENEFITS
Hardware: 64-bit CPU A 64-bit computer is required for the

Windows hypervisor to provide VBS.
Hardware: CPU virtualization These hardware features are required VBS provides isolation of the secure
extensions, for VBS: kernel from the normal operating
plus extended page tables One of the following virtualization system. Vulnerabilities and zero-days in
extensions: the normal operating system cannot be
VT-x (Intel) or exploited because of this isolation.
AMD-V
And:
Extended page tables, also called
Second Level Address Translation
(SLAT).
Firmware: UEFI firmware version See the following Windows Hardware UEFI Secure Boot helps ensure that the
2.3.1.c or higher with UEFI Secure Compatibility Program requirement: device boots only authorized code. This
Boot System.Fundamentals.Firmware.UEFISec can prevent boot kits and root kits from
ureBoot installing and persisting across reboots.
Firmware: Secure firmware update UEFI firmware must support secure UEFI firmware just like software can
process firmware update found under the have security vulnerabilities that, when
following Windows Hardware found, need to be patched through
Compatibility Program requirement: firmware updates. Patching helps
System.Fundamentals.Firmware.UEFISec prevent root kits from getting installed.
ureBoot.
Software: HVCI compatible drivers See the Windows Hardware HVCI Compatible drivers help ensure
Compatibility Program requirements that VBS can maintain appropriate
under memory permissions. This increases
Filter.Driver.DeviceGuard.DriverCompati resistance to bypassing vulnerable
bility. kernel drivers and helps ensure that
malware cannot run in kernel. Only
code verified through code integrity can
run in kernel mode.
Software: Qualified Windows Windows 10 Enterprise, Windows 10 Support for VBS and for management
operating system Education, Windows Server 2016, or features that simplify configuration of
Windows 10 IoT Enterprise Device Guard.
Important:
Windows Server 2016 running
as a domain controller does not
support Credential Guard. Only
Device Guard is supported in
this configuration.
Important The following tables list additional qualifications for improved security. You can use Device Guard
with hardware, firmware, and software that support baseline protections, even if they do not support
protections for improved security. However, we strongly recommend meeting these additional qualifications to
significantly strengthen the level of security that Device Guard can provide.
Additional qualifications for improved security

The following tables describe additional hardware and firmware qualifications, and the improved security that is
available when these qualifications are met.
Additional security qualifications starting with Windows 10, version 1507, and Windows Server 2016, Technical
Preview 4
PROTECTIONS FOR IMPROVED SECURITY DESCRIPTION SECURITY BENEFITS
Firmware: Securing Boot BIOS password or stronger BIOS password or stronger

Configuration and Management authentication must be supported. authentication helps ensure that only
In the BIOS configuration, BIOS authenticated Platform BIOS
authentication must be set. administrators can change BIOS
There must be support for protected settings. This helps protect against a
BIOS option to configure list of physically present user with BIOS
permitted boot devices (for example, access.
Boot only from internal hard drive) Boot order when locked provides
and boot device order, overriding protection against the computer being
BOOTORDER modification made by booted into WinRE or another
operating system. operating system on bootable media.
In the BIOS configuration, BIOS
options related to security and boot
options (list of permitted boot devices,
boot order) must be secured to prevent
other operating systems from starting
and to prevent changes to the BIOS
settings.
Additional security qualifications starting with Windows 10, version 1607, and Windows Server 2016
Firmware: Hardware Rooted Trust Boot Integrity (Platform Secure Boot) Boot Integrity (Platform Secure Boot)
Platform Secure Boot must be supported. See the Windows from Power-On provides protections
Hardware Compatibility Program against physically present attackers, and
requirements under defense-in-depth against malware.
System.Fundamentals.Firmware.CS.UEFI HSTI 1.1.a provides additional security
SecureBoot.ConnectedStandby assurance for correctly secured silicon
The Hardware Security Test Interface and platform.
(HSTI) 1.1.a must be implemented. See
Hardware Security Testability
Specification.
Firmware: Firmware Update through Firmware must support field updates Helps ensure that firmware updates are
Windows Update through Windows Update and UEFI fast, secure, and reliable.
encapsulation update.
Firmware: Securing Boot Required BIOS capabilities: Ability of Enterprises can choose to allow
Configuration and Management OEM to add ISV, OEM, or Enterprise proprietary EFI drivers/applications to
Certificate in Secure Boot DB at run.
manufacturing time. Removing Microsoft UEFI CA from
Required configurations: Microsoft Secure Boot DB provides full control to
UEFI CA must be removed from Secure enterprises over software that runs
Boot DB. Support for 3rd-party UEFI before the operating system boots.
modules is permitted but should
leverage ISV-provided certificates or
OEM certificate for the specific UEFI
software.
Additional security qualifications starting with Windows 10, version 1703

Firmware: VBS enablement of NX VBS will enable No-Execute (NX) Vulnerabilities in UEFI runtime, if any,
protection for UEFI runtime services protection on UEFI runtime service code will be blocked from compromising VBS
and data memory regions. UEFI runtime (such as in functions like UpdateCapsule
service code must support read-only and SetVariable)
page protections, and UEFI runtime Reduces the attack surface to VBS
service data must not be exceutable. from system firmware.
UEFI runtime service must meet these
requirements:
Implement UEFI 2.6
EFI_MEMORY_ATTRIBUTES_TABLE. All
UEFI runtime service memory (code and
data) must be described by this table.
PE sections need to be page-
aligned in memory (not required for in
non-volitile storage).
The Memory Attributes Table needs
to correctly mark code and data as
RO/NX for configuration by the OS:
All entries must include
attributes EFI_MEMORY_RO,
EFI_MEMORY_XP, or both
No entries may be left with
neither of the above attributes,
indicating memory that is both
exceutable and writable. Memory must
be either readable and executable or
writeable and non-executable.
Notes:
This only applies to UEFI
runtime service memory, and
not UEFI boot service memory.
This protection is applied by
VBS on OS page tables.
Please also note the following:

Do not use sections that are both
writeable and exceutable
Do not attempt to directly modify
executable system memory
Do not use dynamic code
Firmware: Firmware support for SMM The Windows SMM Security Mitigations Protects against potential
protection Table (WSMT) specification contains vulnerabilities in UEFI runtime services,
details of an Advanced Configuration if any, will be blocked from
and Power Interface (ACPI) table that compromising VBS (such as in functions
was created for use with Windows like UpdateCapsule and SetVariable)
operating systems that support Reduces the attack surface to VBS
Windows virtualization-based security from system firmware.
(VBS) features. Blocks additional security attacks
against SMM.
Device Guard deployment in different scenarios: types of devices

Typically, deployment of Device Guard happens best in phases, rather than being a feature that you simply turn
on. The choice and sequence of phases depends on the way various computers and other devices are used in your
organization, and to what degree IT manages those devices. The following table can help you begin to develop a
plan for deploying Device Guard in your organization.
DEVICE GUARD COMPONENTS THAT YOU
HOW DEVICE GUARD RELATES TO THIS CAN USE TO PROTECT THIS KIND OF
TYPE OF DEVICE TYPE OF DEVICE DEVICE
Fixed-workload devices: Perform Device Guard can be deployed fully, and - VBS (hardware-based) protections,
same tasks every day. deployment and ongoing enabled.
Lists of approved applications rarely administration are relatively
change. straightforward. Code integrity policies in enforced
Examples: kiosks, point-of-sale systems, After Device Guard deployment, only mode, with UMCI enabled.
call center computers. approved applications can run. This is
because of protections offered by the
Hypervisor Code Integrity (HVCI)
service.
Fully managed devices: Allowed An initial baseline code integrity policy - VBS (hardware-based) protections,
software is restricted by IT department. can be established and enforced. enabled.
Users can request additional software, Whenever the IT department approves
or install from a list of applications additional applications, it will update the Code integrity policies in enforced
provided by IT department. code integrity policy and (for unsigned mode, with UMCI enabled.
Examples: locked-down, company- LOB applications) the catalog.
owned desktops and laptops. Code integrity policies are supported by
the HVCI service.
Lightly managed devices: Company- Device Guard can be used to help - VBS (hardware-based) protections,
owned, but users are free to install protect the kernel, and to monitor enabled. When enabled with a code
software. (audit) for problem applications rather integrity policy in audit mode only, VBS
Devices are required to run than limiting the applications that can means the hypervisor helps enforce the
organization's antivirus solution and be run. default kernel-mode code integrity
client management tools. policy, which protects against unsigned
drivers or system files.
Code integrity policies, with UMCI

enabled, but running in audit mode
only. This means applications are not
blockedthe policy just logs an event
whenever an application outside the
policy is started.
Bring Your Own Device: Employees Device Guard does not apply. Instead, N/A
are allowed to bring their own devices, you can explore other hardening and
and also use those devices away from security features with MDM-based
work. conditional access solutions, such as
Microsoft Intune.
Device Guard deployment in virtual machines

Device Guard can protect a Hyper-V virtual machine, just as it would a physical machine. The steps to enable
Device Guard are the same from within the virtual machine.
Device Guard protects against malware running in the guest virtual machine. It does not provide additional
protection from the host administrator. From the host, you can disable Device Guard for a virtual machine:
Set-VMSecurity -VMName <VMName> -VirtualizationBasedSecurityOptOut $true
Requirements for running Device Guard in Hyper-V virtual machines

The Hyper-V host must run at least Windows Server 2016 or Windows 10 version 1607.
The Hyper-V virtual machine must be Generation 2, and running at least Windows Server 2016 or Windows 10.
Device Guard and nested virtualization cannot be enabled at the same time.
Virtual Fibre Channel adapters are not compatible with Device Guard. Before attaching a virtual Fibre Channel
Adapter to a virtual machine, you must first opt out of virtualization-based security using Set-VMSecurity.
The AllowFullSCSICommandSet option for pass-through disks is not compatible with Device Guard. Before
configuring a pass-through disk with AllowFullSCSICommandSet, you must first opt out of virtualization-based
security using Set-VMSecurity.
Reviewing your applications: application signing and catalog files

Typically, code integrity policies are configured to use the application's signing certificate as part or all of what
identifies the application as trusted. This means that applications must either use embedded signingwhere the
signature is part of the binaryor catalog signing, where you generate a catalog file from the applications, sign
it, and through the signed catalog file, configure the code integrity policy to recognize the applications as signed.
Catalog files can be very useful for unsigned LOB applications that cannot easily be given an embedded signature.
However, catalogs need to be updated each time an application is updated. In contrast, with embedded signing,
your code integrity policies typically do not have to be updated when an application is updated. For this reason, if
code-signing is or can be included in your in-house application development process, it can simplify the
management of your code integrity policies (compared to using catalog signing).
To obtain signed applications or embed signatures in your in-house applications, you can choose from a variety of
methods:
Using the Windows Store publishing process. All apps that come out of the Microsoft Store are
automatically signed with special signatures that can roll-up to our certificate authority (CA) or to your own.
Using your own digital certificate or public key infrastructure (PKI). ISV's and enterprises can sign their own
Classic Windows applications themselves, adding themselves to the trusted list of signers.
Using a non-Microsoft signing authority. ISV's and enterprises can use a trusted non-Microsoft signing
authority to sign all of their own Classic Windows applications.
To use catalog signing, you can choose from the following options:
Use the Device Guard signing portal available in the Windows Store for Business. The portal is a Microsoft
web service that you can use to sign your Classic Windows applications. For more information, see Device
Guard signing.
Create your own catalog files, which are described in the next section. For information about how creating
catalog files fits into Device Guard deployment, see Planning and getting started on the Device Guard
deployment process.
Catalog files
Catalog files (which you can create in Windows 10 with a tool called Package Inspector) contain information about
all deployed and executed binary files associated with your trusted but unsigned applications. When you create
catalog files, you can also include signed applications for which you do not want to trust the signer but rather the
specific application. After creating a catalog, you must sign the catalog file itself by using enterprise public key
infrastructure (PKI), or a purchased code signing certificate. Then you can distribute the catalog, so that your
trusted applications can be handled by code integrity policies in the same way as any other signed application.
Catalog files are simply Secure Hash Algorithm 2 (SHA2) hash lists of discovered binaries. These binaries hash
values are updated each time an application is updated, which requires the catalog file to be updated also.
After you have created and signed your catalog files, you can configure your code integrity policies to trust the
signer or signing certificate of those files.
Note Package Inspector only works on operating systems that support Device Guard, such as Windows 10
Enterprise, Windows 10 Education, Windows 2016 Server, or Windows Enterprise IoT.
For information about how creating catalog files fits into Device Guard deployment, see Planning and getting
started on the Device Guard deployment process. For procedures for working with catalog files, see Deploy catalog
files to support code integrity policies.
Code integrity policy formats and signing

When you generate a code integrity policy, you are generating a binary-encoded XML document that includes
configuration settings for both the User and Kernel-modes of Windows 10 Enterprise, along with restrictions on
Windows 10 script hosts. You can view your original XML document in a text editor, for example if you want to
check the rule options that are present in the <Rules> section of the file.
We recommend that you keep the original XML file for use when you need to merge the code integrity policy with
another policy or update its rule options. For deployment purposes, the file is converted to a binary format, which
can be done using a simple Windows PowerShell command.
When the code integrity policy is deployed, it restricts the software that can run on a device. The XML document
can be signed, helping to add additional protection against administrative users changing or removing the policy.
Related topics
Planning and getting started on the Device Guard
deployment process
Applies to
Windows 10
Windows Server 2016
This topic provides a roadmap for planning and getting started on the Device Guard deployment process, with
links to topics that provide additional detail. Planning for Device Guard deployment involves looking at both the
end-user and the IT pro impact of your choices. Use the following steps to guide you.
Planning
1. Review requirements, especially hardware requirements for VBS. Review the virtualization-based
security (VBS) features described in How Device Guard features help protect against threats. Then you can
assess your end-user systems to see how many support the VBS features you are interested in, as
described in Hardware, firmware, and software requirements for Device Guard.
2. Group devices by degree of control needed. Group devices according to the table in Device Guard
deployment in different scenarios: types of devices. Do most devices fit neatly into a few categories, or are
they scattered across all categories? Are users allowed to install any application or must they choose from
a list? Are users allowed to use their own peripheral devices?
Deployment is simpler if everything is locked down in the same way, but meeting individual departments
needs, and working with a wide variety of devices, may require a more complicated and flexible
deployment.
3. Review how much variety in software and hardware is needed by roles or departments. When
several departments all use the same hardware and software, you might need to deploy only one code
integrity policy for them. More variety across departments might mean you need to create and manage
more code integrity policies. The following questions can help you clarify how many code integrity policies
to create:
How standardized is the hardware?
This can be relevant because of drivers. You could create a code integrity policy on hardware that
uses a particular set of drivers, and if other drivers in your environment use the same signature,
they would also be allowed to run. However, you might need to create several code integrity
policies on different "reference" hardware, then merge the policies together, to ensure that the
resulting policy recognizes all the drivers in your environment.
What software does each department or role need? Should they be able to install and run other
departments software?
If multiple departments are allowed to run the same list of software, you might be able to merge
several code integrity policies to simplify management.
Are there departments or roles where unique, restricted software is used?
If one department needs to run an application that no other department is allowed, it might require
a separate code integrity policy. Similarly, if only one department must run an old version of an
application (while other departments allow only the newer version), it might require a separate
code integrity policy.
Is there already a list of accepted applications?
A list of accepted applications can be used to help create a baseline code integrity policy.
As of Windows 10, version 1703, it might also be useful to have a list of plug-ins, add-ins, or
modules that you want to allow only in a specific app (such as a line-of-business app). Similarly, it
might be useful to have a list of plug-ins, add-ins, or modules that you want to block in a specific
app (such as a browser).
As part of a threat review process, have you reviewed systems for software that can load arbitrary
DLLs or run code or scripts? In day-to-day operations, your organizations security policy may allow
certain applications, code, or scripts to run on your systems depending on their role and the
context. However, if your security policy requires that you run only trusted applications, code, and
scripts on your systems, you may decide to lock these systems down securely with Device Guard
code integrity policies. You can also fine-tune your control by using Device Guard in combination
with AppLocker, as described in Device Guard with AppLocker.
Legitimate applications from trusted vendors provide valid functionality. However, an attacker
could also potentially use that same functionality to run malicious executable code that could
bypass code integrity policies.
For operational scenarios that require elevated security, certain applications with known Code
Integrity bypasses may represent a security risk if you whitelist them in your code integrity policies.
Other applications where older versions of the application had vulnerabilities also represent a risk.
Therefore, you may want to deny or block such applications from your code integrity policies. For
applications with vulnerabilities, once the vulnerabilities are fixed you can create a rule that only
allows the fixed or newer versions of that application. The decision to allow or block applications
depends on the context and on how the reference system is being used.
Security professionals collaborate with Microsoft continuously to help protect customers. With the
help of their valuable reports, Microsoft has identified a list of known applications that an attacker
could potentially use to bypass Device Guard code integrity policies. Depending on the context, you
may want to block these applications. To view this list of applications and for use case examples,
such as disabling msbuild.exe, see Deploy code integrity policies: steps.
4. Identify LOB applications that are currently unsigned. Although requiring signed code (through code
integrity policies) protects against many threats, your organization might use unsigned LOB applications,
for which the process of signing might be difficult. You might also have applications that are signed, but
you want to add a secondary signature to them. If so, identify these applications, because you will need to
create a catalog file for them. For a basic description of catalog files, see the table in Introduction to Device
Guard: virtualization-based security and code integrity policies. For more background information about
catalog files, see Reviewing your applications: application signing and catalog files.
Getting started on the deployment process

1. Optionally, create a signing certificate for code integrity policies. As you deploy code integrity
policies, you might need to sign catalog files or code integrity policies internally. To do this, you will either
need a publicly issued code signing certificate (that you purchase) or an internal CA. If you choose to use
an internal CA, you will need to create a code signing certificate. For more information, see Optional:
Create a code signing certificate for code integrity policies.
2. Create code integrity policies from golden computers. When you have identified departments or
roles that use distinctive or partly-distinctive sets of hardware and software, you can set up golden
computers containing that software and hardware. In this respect, creating and managing code integrity
policies to align with the needs of roles or departments can be similar to managing corporate images.
From each golden computer, you can create a code integrity policy, and decide how to manage that
policy. You can merge code integrity policies to create a broader policy or a master policy, or you can
manage and deploy each policy individually. For more information, see:
3. Audit the code integrity policy and capture information about applications that are outside the
policy. We recommend that you use audit mode to carefully test each code integrity policy before you
enforce it. With audit mode, no application is blockedthe policy just logs an event whenever an
application outside the policy is started. Later, you can expand the policy to allow these applications, as
needed. For more information, see Audit code integrity policies.
4. Create a catalog file for unsigned LOB applications. Use the Package Inspector tool to create and
sign a catalog file for your unsigned LOB applications. For more information, review step 4 Identify LOB
applications that are currently unsigned, earlier in this list, and see Deploy catalog files to support
code integrity policies. In later steps, you can merge the catalog file's signature into your code integrity
policy, so that applications in the catalog will be allowed by the policy.
5. Capture needed policy information from the event log, and merge information into the existing
policy as needed. After a code integrity policy has been running for a time in audit mode, the event log
will contain information about applications that are outside the policy. To expand the policy so that it
allows for these applications, use Windows PowerShell commands to capture the needed policy
information from the event log, and then merge that information into the existing policy. You can merge
code integrity policies from other sources also, for flexibility in how you create your final code integrity
policies. For more information, see:
Create a code integrity policy that captures audit information from the event log
Merge code integrity policies
6. Deploy code integrity policies and catalog files. After you confirm that you have completed all the
preceding steps, you can begin deploying catalog files and taking code integrity policies out of auditing
mode. We strongly recommend that you begin this process with a test group of users. This provides a final
quality-control validation before you deploy the catalog files and code integrity policies more broadly. For
more information, see:
Enforce code integrity policies
7. Enable desired hardware (VBS) security features. Hardware-based security featuresalso called
virtualization-based security (VBS) featuresstrengthen the protections offered by code integrity policies,
as described in How Device Guard features help protect against threats.
WARNING
Virtualization-based protection of code integrity may be incompatible with some devices and applications. We
strongly recommend testing this configuration in your lab before enabling virtualization-based protection of code
integrity on production systems. Failure to do so may result in unexpected failures up to and including data loss or
a blue screen error (also called a stop error).
For information about enabling VBS features, see Deploy Device Guard: enable virtualization-based
security.
Applies to
Windows 10
Windows Server 2016
This section includes the following topics:
Optional: Create a code signing certificate for code integrity policies
Deploy Managed Installer for Device Guard
To increase the protection for devices that meet certain hardware requirements, you can use virtualization-based
security (VBS) with your code integrity policies.
For requirements, see Hardware, firmware, and software requirements for Device Guard in "Requirements and
deployment planning guidelines for Device Guard."
For steps, see Deploy Device Guard: enable virtualization-based security.
Related topics
Optional: Create a code signing certificate for code
integrity policies
Applies to
Windows 10
Windows Server 2016
As you deploy code integrity policies (part of Device Guard), you might need to sign catalog files or code integrity
policies internally. To do this, you will either need a publicly issued code signing certificate or an internal CA. If you
have purchased a code signing certificate, you can skip this topic and instead follow other topics listed in Deploy
Device Guard: deploy code integrity policies.
If you have not purchased a certificate but have an internal CA, complete these steps to create a code signing
certificate:
1. Open the Certification Authority Microsoft Management Console (MMC) snap-in, and then select your
issuing CA.
2. When connected, right-click Certificate Templates, and then click Manage to open the Certification
Templates Console.
Figure 1. Manage the certificate templates

3. In the navigation pane, right-click the Code Signing certificate, and then click Duplicate Template.
4. On the Compatibility tab, clear the Show resulting changes check box. Select Windows Server 2012
from the Certification Authority list, and then select Windows 8 / Windows Server 2012 from the
Certificate recipient list.
5. On the General tab, specify the Template display name and Template name. This example uses the
name DG Catalog Signing Certificate.
6. On the Request Handling tab, select the Allow private key to be exported check box.
7. On the Extensions tab, select the Basic Constraints check box, and then click Edit.
8. In the Edit Basic Constraints Extension dialog box, select Enable this extension, as shown in Figure 2.
Figure 2. Select constraints on the new template

9. If a certificate manager is required to approve any issued certificates, on the Issuance Requirements tab,
select CA certificate manager approval.
10. On the Subject Name tab, select Supply in the request.
11. On the Security tab, verify that whatever account will be used to request the certificate has the right to
enroll the certificate.
12. Click OK to create the template, and then close the Certificate Template Console.
When this certificate template has been created, you must publish it to the CA published template store. To do so,
complete the following steps:
1. In the Certification Authority MMC snap-in, right-click Certification Templates, point to New, and then
click Certificate Template to Issue, as shown in Figure 3.
Figure 3. Select the new certificate template to issue
A list of available templates to issue appears, including the template you just created.
2. Select the DG Catalog signing certificate, and then click OK.
Now that the template is available to be issued, you must request one from the computer running Windows 10 on
which you create and sign catalog files. To begin, open the MMC, and then complete the following steps:
1. In MMC, from the File menu, click Add/Remove Snap-in. Double-click Certificates, and then select My
user account.
2. In the Certificates snap-in, right-click the Personal store folder, point to All Tasks, and then click Request
New Certificate.
3. Click Next twice to get to the certificate selection list.
4. In the Request Certificate list, select your newly created code signing certificate, and then select the blue
text that requests additional information, as shown in Figure 4.
Figure 4. Get more information for your code signing certificate
5. In the Certificate Properties dialog box, for Type, select Common name. For Value, select
ContosoDGSigningCert, and then click Add. When added, click OK.
6. Enroll and finish.
Note If a certificate manager is required to approve any issued certificates and you selected to require
management approval on the template, the request will need to be approved in the CA before it will be issued
to the client.
This certificate must be installed in the users personal store on the computer that will be signing the catalog files
and code integrity policies. If the signing is going to be taking place on the computer on which you just requested
the certificate, exporting the certificate to a .pfx file will not be required because it already exists in your personal
store. If you are signing on another computer, you will need to export the .pfx certificate with the necessary keys
and properties. To do so, complete the following steps:
1. Right-click the certificate, point to All Tasks, and then click Export.
2. Click Next, and then select Yes, export the private key.
3. Choose the default settings, and then select Export all extended properties.
4. Set a password, select an export path, and then select DGCatSigningCert.pfx as the file name.
When the certificate has been exported, import it into the personal store for the user who will be signing the
catalog files or code integrity policies on the specific computer that will be signing them.
Related topics
Deploy code integrity policies: policy rules and file
rules
Applies to
Windows 10
Windows Server 2016
Code integrity policies provide control over a computer running Windows 10 by specifying whether a driver or
application is trusted and can be run. For an overview of code integrity, see:
How Device Guard features help protect against threats in "Introduction to Device Guard: virtualization-based
security and code integrity policies."
Code integrity policy formats and signing in "Requirements and deployment planning guidelines for Device
Guard."
If you already understand the basics of code integrity policy and want procedures for creating, auditing, and
merging code integrity policies, see Deploy code integrity policies: steps.
This topic includes the following sections:
Overview of the process of creating code integrity policies: Helps familiarize you with the process described in
this and related topics.
Code integrity policy rules: Describes one key element you specify in a policy, the policy rules, which control
options such as audit mode or whether user mode code integrity (UMCI) is enabled in a code integrity policy.
Code integrity file rule levels: Describes the other key element you specify in a policy, the file rules (or file rule
levels), which specify the level at which applications will be identified and trusted.
Example of file rule levels in use: Gives an example of how file rule levels can be applied.
Overview of the process of creating code integrity policies

A common system imaging practice in todays IT organization is to establish a golden image as a reference for
what an ideal system should look like, and then use that image to clone additional company assets. Code integrity
policies follow a similar methodology, that begins with the establishment of a golden computer. As with imaging,
you can have multiple golden computers based on model, department, application set, and so on. Although the
thought process around the creation of code integrity policies is similar to imaging, these policies should be
maintained independently. Assess the necessity of additional code integrity policies based on what should be
allowed to be installed and run and for whom. For more details on doing this assessment, see the planning steps in
Planning and getting started on the Device Guard deployment process.
Note Each computer can have only one code integrity policy at a time. Whichever way you deploy this policy,
it is renamed to SIPolicy.p7b and copied to C:\Windows\System32\CodeIntegrity and, for UEFI computers,
<EFI System Partition>\Microsoft\Boot. Keep this in mind when you create your code integrity policies.
Optionally, code integrity policies can align with your software catalog as well as any IT departmentapproved
applications. One straightforward method to implement code integrity policies is to use existing images to create
one master code integrity policy. You do so by creating a code integrity policy from each image, and then by
merging the policies. This way, what is installed on all of those images will be allowed to run, if the applications are
installed on a computer based on a different image. Alternatively, you may choose to create a base applications
policy and add policies based on the computers role or department. Organizations have a choice of how their
policies are created, merged or serviced, and managed.
If you plan to use an internal CA to sign catalog files or code integrity policies, see the steps in Optional: Create a
code signing certificate for code integrity policies.
Code integrity policy rules

Code integrity policies include policy rules, which control options such as audit mode or whether UMCI is enabled
in a code integrity policy. You can modify these options in a new or existing code integrity policy. (For information
about file rules, which specify the level at which applications will be identified and trusted, see the next section,
Code integrity file rule levels.)
To modify the policy rule options of an existing code integrity policy, use the Set-RuleOption Windows PowerShell
cmdlet. Note the following examples of how to use this cmdlet to add and remove a rule option on an existing
code integrity policy:
To ensure that UMCI is enabled for a code integrity policy that was created with the -UserPEs (user mode)
option, add rule option 0 to an existing policy by running the following command:
Set-RuleOption -FilePath <Path to policy> -Option 0
Note that a policy that was created without the -UserPEs option is empty of user mode executables, that is,
applications. If you enable UMCI (Option 0) for such a policy and then attempt to run an application, Device
Guard will see that the application is not on its list (which is empty of applications), and respond. In audit
mode, the response is logging an event, and in enforced mode, the response is blocking the application. To
create a policy that includes user mode executables (applications), when you run New-CIPolicy , include the
-UserPEs option.
To disable UMCI on an existing code integrity policy, delete rule option 0 by running the following
command:
Set-RuleOption -FilePath <Path to policy> -Option 0 -Delete
You can set several rule options within a code integrity policy. To display a list of rule options, you can type Set-
RuleOption -Help in a Windows PowerShell session. Table 2 describes each rule option.
Note Enabled:Audit Mode is an important rule option. We recommend that you use this option for a period
of time with all new code integrity policies, because it allows you to test them before you enforce them. With
audit mode, no application is blockedthe policy just logs an event whenever an application outside the policy
is started. To expand the policy so that (when enforced) it will allow these applications, you can use Windows
PowerShell commands to capture the needed policy information from the event log, and then merge that
information into the existing policy.
The modeaudit mode or enforced modeis set by including or deleting Enabled:Audit Mode in the code
integrity policy. When this option is deleted, the policy runs in enforced mode.
Table 2. Code integrity policy - policy rule options
RULE OPTION DESCRIPTION
0 Enabled:UMCI Code integrity policies restrict both kernel-mode and user-

mode binaries. By default, only kernel-mode binaries are
restricted. Enabling this rule option validates user mode
executables and scripts.
RULE OPTION DESCRIPTION
1 Enabled:Boot Menu Protection This option is not currently supported.
2 Required:WHQL By default, legacy drivers that are not Windows Hardware

Quality Labs (WHQL) signed are allowed to execute. Enabling
this rule requires that every executed driver is WHQL signed
and removes legacy driver support. Going forward, every new
Windows 10compatible driver must be WHQL certified.
3 Enabled:Audit Mode (Default) Enables the execution of binaries outside of the code integrity
policy but logs each occurrence in the CodeIntegrity event
log, which can be used to update the existing policy before
enforcement. To begin enforcing a code integrity policy, delete
this option.
4 Disabled:Flight Signing If enabled, code integrity policies will not trust flightroot-
signed binaries. This would be used in the scenario in which
organizations only want to run released binaries, not flighted
builds.
5 Enabled:Inherent Default Policy This option is not currently supported.
6 Enabled:Unsigned System Integrity Policy (Default) Allows the policy to remain unsigned. When this option is
removed, the policy must be signed and have
UpdatePolicySigners added to the policy to enable future
policy modifications.
7 Allowed:Debug Policy Augmented This option is not currently supported.
8 Required:EV Signers In addition to being WHQL signed, this rule requires that
drivers must have been submitted by a partner that has an
Extended Verification (EV) certificate. All future Windows 10
and later drivers will meet this requirement.
9 Enabled:Advanced Boot Options Menu The F8 preboot menu is disabled by default for all code
integrity policies. Setting this rule option allows the F8 menu
to appear to physically present users.
10 Enabled:Boot Audit on Failure Used when the code integrity policy is in enforcement mode.
When a driver fails during startup, the code integrity policy
will be placed in audit mode so that Windows will load.
Administrators can validate the reason for the failure in the
CodeIntegrity event log.
Code integrity file rule levels

File rule levels allow administrators to specify the level at which they want to trust their applications. This level of
trust could be as fine-tuned as the hash of each binary or as general as a CA certificate. You specify file rule levels
both when you create a new code integrity policy from a scan and when you create a policy from audit events. In
addition, to combine rule levels found in multiple policies, you can merge the policies. When merged, code
integrity policies combine their file rules, so that any application that would be allowed by either of the original
policies will be allowed by the combined policy.
Each file rule level has its benefit and disadvantage. Use Table 3 to select the appropriate protection level for your
available administrative resources and Device Guard deployment scenario.
Table 3. Code integrity policy - file rule levels
RULE LEVEL DESCRIPTION
Hash Specifies individual hash values for each discovered binary.

Although this level is specific, it can cause additional
administrative overhead to maintain the current product
versions hash values. Each time a binary is updated, the hash
value changes, therefore requiring a policy update.
FileName Specifies individual binary file names. Although the hash

values for an application are modified when updated, the file
names are typically not. This offers less specific security than
the hash level but does not typically require a policy update
when any binary is modified.
SignedVersion This combines the publisher rule with a version number. This
option allows anything from the specified publisher, with a
version at or above the specified version number, to run.
Publisher This is a combination of the PcaCertificate level (typically one

certificate below the root) and the common name (CN) of the
leaf certificate. This rule level allows organizations to trust a
certificate from a major CA (such as Symantec), but only if the
leaf certificate is from a specific company (such as Intel, for
device drivers).
FilePublisher This is a combination of the FileName attribute of the signed

file, plus Publisher (PCA certificate with CN of leaf), plus a
minimum version number. This option trusts specific files from
the specified publisher, with a version at or above the
specified version number.
LeafCertificate Adds trusted signers at the individual signing certificate level.

The benefit of using this level versus the individual hash level
is that new versions of the product will have different hash
values but typically the same signing certificate. Using this
level, no policy update would be needed to run the new
version of the application. However, leaf certificates have
much shorter validity periods than CA certificates, so
additional administrative overhead is associated with updating
the code integrity policy when these certificates expire.
PcaCertificate Adds the highest available certificate in the provided certificate

chain to signers. This is typically one certificate below the root
certificate, because the scan does not validate anything
beyond the certificates included in the provided signature (it
does not go online or check local root stores).
RootCertificate Currently unsupported.
WHQL Trusts binaries if they have been validated and signed by

WHQL. This is primarily for kernel binaries.
WHQLPublisher This is a combination of the WHQL and the CN on the leaf

certificate and is primarily for kernel binaries.
RULE LEVEL DESCRIPTION
WHQLFilePublisher Specifies that the binaries are validated and signed by WHQL,
with a specific publisher (WHQLPublisher), and that the binary
is the specified version or newer. This is primarily for kernel
binaries.
Note When you create code integrity policies with the New-CIPolicy cmdlet, you can specify a primary file
rule level by including the -Level parameter. For discovered binaries that cannot be trusted based on the
primary file rule criteria, use the -Fallback parameter. For example, if the primary file rule level is
PCACertificate but you would like to trust the unsigned applications as well, using the Hash rule level as a
fallback adds the hash values of binaries that did not have a signing certificate.
Example of file rule levels in use

For example, consider some IT professionals in a department that runs many servers. They decide they want their
servers to run only software signed by the providers of their software and drivers, that is, the companies that
provide their hardware, operating system, antivirus, and other important software. They know that their servers
also run an internally written application that is unsigned but is rarely updated. They want to allow this application
to run.
To create the code integrity policy, they build a reference server on their standard hardware, and install all of the
software that their servers are known to run. Then they run New-CIPolicy with -Level Publisher (to allow software
from their software providers, the "Publishers") and -Fallback Hash (to allow the internal, unsigned application).
They enable the policy in auditing mode and gather information about any necessary software that was not
included on the reference server. They merge code integrity policies into the original policy to allow that additional
software to run. Then they enable the code integrity policy in enforced mode for their servers.
As part of normal operations, they will eventually install software updates, or perhaps add software from the same
software providers. Because the "Publisher" remains the same on those updates and software, they will not need to
update their code integrity policy. If they come to a time when the internally-written, unsigned application must be
updated, they must also update the code integrity policy so that the hash in the policy matches the hash of the
updated internal application.
They could also choose to create a catalog that captures information about the unsigned internal application, then
sign and distribute the catalog. Then the internal application could be handled by code integrity policies in the
same way as any other signed application. An update to the internal application would only require that the
catalog be regenerated, signed, and distributed (no restarts would be required).
Related topics
How Device Guard features help protect against threats
Applies to
Windows 10
Windows Server 2016
For an overview of the process described in the following procedures, see Deploy code integrity policies: policy
rules and file rules. To understand how the deployment of code integrity policies fits with other steps in the Device
Guard deployment process, see Planning and getting started on the Device Guard deployment process.
Create a code integrity policy from a golden computer

The process for creating a golden code integrity policy from a reference system is straightforward. This section
outlines the process that is required to successfully create a code integrity policy with Windows PowerShell. First,
for this example, you must initiate variables to be used during the creation process. Rather than using variables,
you can simply use the full file paths in the command. Next, you create the code integrity policy by scanning the
system for installed applications. When created, the policy file is converted to binary format so that Windows can
consume its contents.
NOTE
Before you begin this procedure, make sure that the reference PC is virus and malware-free,and that any software you want
to be scanned is installed on the system before creating the code integrity policy.
Scripting and applications

Each installed software application should be validated as trustworthy before you create a policy. We recommend
that you review the reference PC for software that can load arbitrary DLLs and run code or scripts that could
render the PC more vulnerable. Examples include software aimed at development or scripting such as msbuild.exe
(part of Visual Studio and the .NET Framework) which can be removed if you do not want it to run scripts. You can
remove or disable such software on reference PCs used to create code integrity policies. You can also fine-tune
your control by using Device Guard in combination with AppLocker, as described in Device Guard with AppLocker.
Members of the security community* continuously collaborate with Microsoft to help protect customers. With
the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also
potentially use to bypass Device Guard code integrity policies.
Unless your use scenarios explicitly require them, Microsoft recommends that you block the following
applications. These applications or files can be used by an attacker to circumvent Application Whitelisting policies,
including Device Guard:
bash.exe
bginfo.exe[1]
cdb.exe
csi.exe
dnx.exe
fsi.exe
fsiAnyCpu.exe
kd.exe
ntkd.exe
lxssmanager.dll
msbuild.exe[2]
mshta.exe
ntsd.exe
rcsi.exe
SyncAppVPublishingServer.exe
system.management.automation.dll
windbg.exe
[1] A vulnerability in bginfo.exe has been fixed in the latest version 4.22. If you use BGInfo, for
security, make sure
to download and run the latest version here BGInfo 4.22. Note that BGInfo versions earlier than 4.22 are still
vulnerable and should be blocked.
[2] If you are using your
reference system in a development context and use msbuild.exe to build managed
applications, we recommend that you whitelist msbuild.exe in your code integrity policies. However, if your
reference system is an end user device that is not being used in a development context, we recommend that you
block msbuild.exe.
*Microsoft recognizes the efforts of those in the security community who help us protect customers through
responsible vulnerability disclosure, and extends thanks to the following people:
NAME TWITTER
Casey Smith @subTee
Matt Graeber @mattifestation
Matt Nelson @enigma0x3
Oddvar Moe @Oddvarmoe
Alex Ionescu @aionescu
Nick Landers @monoxgas
NOTE
This application list is fluid and will be updated with the latest vendor information as application vulnerabilities are resolved
and new issues are discovered.
Certain software applications may allow additional code to run by design. These types of applications should be
blocked by your Device Guard policy. In addition, when an application version is upgraded to fix a security
vulnerability or potential Device Guard bypass, you should add deny rules to your code integrity policies for that
applications previous, less secure versions.
Microsoft recommends that you install the latest security updates. The June 2017 Windows updates resolve
several issues in in-box PowerShell modules that allowed an attacker to bypass Device Guard code integrity
policies. These modules cannot be blocked by name or version, and therefore must be blocked by their
corresponding hashes.
Microsoft recommends that you block the following Microsoft-signed applications and PowerShell files by
merging the following policy into your existing policy to add these deny rules using the Merge-CIPolicy cmdlet:
<?xml version="1.0" encoding="utf-8"?>

<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
<VersionEx>10.0.0.0</VersionEx>
<PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>
<PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
<Rules>
<Rule>
<Option>Enabled:Unsigned System Integrity Policy</Option>
</Rule>
<Rule>
<Option>Enabled:Audit Mode</Option>
</Rule>
<Rule>
<Option>Enabled:Advanced Boot Options Menu</Option>
</Rule>
<Rule>
<Option>Required:Enforce Store Applications</Option>
</Rule>
<Rule>
<Option>Enabled:UMCI</Option>
</Rule>
</Rules>

<EKUs />

<FileRules>
<Deny ID="ID_DENY_BGINFO" FriendlyName="bginfo.exe" FileName="BGINFO.Exe"
MinimumFileVersion = "4.21.0.0" />
<Deny ID="ID_DENY_CBD" FriendlyName="cdb.exe" FileName="CDB.Exe" MinimumFileVersion
= "65535.65535.65535.65535" />
<Deny ID="ID_DENY_KD" FriendlyName="kd.exe" FileName="kd.Exe" MinimumFileVersion
= "65535.65535.65535.65535" />
<Deny ID="ID_DENY_NTKD" FriendlyName="ntkd.exe" FileName="ntkd.Exe"
<Deny ID="ID_DENY_WINDBG" FriendlyName="windbg.exe" FileName="windbg.Exe"
<Deny ID="ID_DENY_MSBUILD" FriendlyName="MSBuild.exe" FileName="MSBuild.Exe"
<Deny ID="ID_DENY_CSI" FriendlyName="csi.exe" FileName="csi.Exe" MinimumFileVersion
= "65535.65535.65535.65535" />
<Deny ID="ID_DENY_DNX" FriendlyName="dnx.exe" FileName="dnx.Exe" MinimumFileVersion
= "65535.65535.65535.65535" />
<Deny ID="ID_DENY_RCSI" FriendlyName="rcsi.exe" FileName="rcsi.Exe"
<Deny ID="ID_DENY_NTSD" FriendlyName="ntsd.exe" FileName="ntsd.Exe"
<Deny ID="ID_DENY_LXSS" FriendlyName="LxssManager.dll" FileName="LxssManager.dll"
<Deny ID="ID_DENY_BASH" FriendlyName="bash.exe" FileName="bash.exe"
<Deny ID="ID_DENY_FSI" FriendlyName="fsi.exe" FileName="fsi.exe" MinimumFileVersion
= "65535.65535.65535.65535" />
<Deny ID="ID_DENY_APPVPUBSRV" FriendlyName="SyncAppVPublishingServer.exe"
FileName="SyncAppVPublishingServer.exe" MinimumFileVersion = "65535.65535.65535.65535" />
<Deny ID="ID_DENY_FSI_ANYCPU" FriendlyName="fsiAnyCpu.exe" FileName="fsiAnyCpu.exe"
<Deny ID="ID_DENY_MSHTA" FriendlyName="mshta.exe" FileName="mshta.exe"
<Deny ID="ID_DENY_SMA" FriendlyName="System.Management.Automation.dll"
FileName="System.Management.Automation.dll" MinimumFileVersion = "10.0.16215.999" />
<Deny ID="ID_DENY_D_1" FriendlyName="Powershell 1" Hash="DED853481A176999723413685A79B36DD0F120F9" />

<Deny ID="ID_DENY_D_1" FriendlyName="Powershell 1" Hash="DED853481A176999723413685A79B36DD0F120F9" />
<Deny ID="ID_DENY_D_2" FriendlyName="Powershell 2" Hash="D027E09D9D9828A87701288EFC91D240C0DEC2C3" />
<Deny ID="ID_DENY_D_3" FriendlyName="Powershell 3" Hash="46936F4F0AFE4C87D2E55595F74DDDFFC9AD94EE" />
<Deny ID="ID_DENY_D_4" FriendlyName="Powershell 4" Hash="5090F22BB9C0B168C7F5E9E800784A05AFCCBC4F" />
<Deny ID="ID_DENY_D_5" FriendlyName="Powershell 5" Hash="A920D0706FCEA648D28638E9198BCC368996B8FD" />
<Deny ID="ID_DENY_D_6" FriendlyName="Powershell 6" Hash="93E22F2BA6C8B1C09F100F9C0E3B06FAF2D1DDB6" />
<Deny ID="ID_DENY_D_7" FriendlyName="Powershell 7" Hash="943E307BE7B0B381715CA5CC0FAB7B558025BA80" />
<Deny ID="ID_DENY_D_8" FriendlyName="Powershell 8" Hash="DE6A02520E1D7325025F2761A97D36E407E8490C" />
<Deny ID="ID_DENY_D_9" FriendlyName="Powershell 9" Hash="CC968868EDC6718DA14DDDB11228A04D5D5BD9A5" />
<Deny ID="ID_DENY_D_10" FriendlyName="Powershell 10" Hash="789D0657689DB6F0900A787BEF52A449585A92B5" />
<Deny ID="ID_DENY_D_11" FriendlyName="Powershell 11"
Hash="F29A958287788A6EEDE6035D49EF5CB85EEC40D214FDDE5A0C6CAA65AFC00EEC" />
Hash="84BB081141DA50B3839CD275FF34854F53AECB96CA9AEB8BCD24355C33C1E73E" />
Hash="8D396FEAEED1F0CA709B62B1F27EDC9CCEFF95E3473C923624362A042E91D787" />
Hash="7BF44433D3A606104778F64B11B92C52FC99C4BA570C50B70438275D0B587B8E" />
Hash="6B3CB996EC5129D345830C3D6D5C7C009372FFD9F08837E8B2572AB31E9648A5" />
Hash="C3A5DAB20947CA8FD092E75C25177E7BAE7884CA58710F14827144C09EA1F94B" />
Hash="BE3FFE10CDE8B62C3E8FD4D8198F272B6BD15364A33362BB07A0AFF6731DABA1" />
Hash="75288A0CF0806A68D8DA721538E64038D755BBE74B52F4B63FEE5049AE868AC0" />
Hash="F875E43E12685ECE0BA2D42D55A13798CE9F1FFDE3CAE253D2529F4304811A52" />
Hash="6D89FDD29D50C07801FB01F031CDB96E2E14288F066BD895356AE0517ABB09CE" />
Hash="326669C4A31E2049E3750BCF4287241BB8B555B3670D31A1ACA74C3AC598DF81" />
Hash="38DC1956313B160696A172074C6F5DA9852BF508F55AFB7FA079B98F2849AFB5" />
Hash="C6C073A80A8E76DC13E724B5E66FE4035A19CCA0C1AF3FABBC18E5185D1B66CB" />
Hash="9EA4BD3D8FB8F490E8099E0412F091E545AF028E3C4CAF179324B679124D1742" />
Hash="CD83C3C293EC4D24D3328C74881FA04AAF9CCF73E099631A9EB100BD0F384F58" />
Hash="74E207F539C4EAC648A5507EB158AEE9F6EA401E51808E83E73709CFA0820FDD" />
Hash="148972F670E18790D62D753E01ED8D22B351A57E45544D88ACE380FEDAF24A40" />
Hash="72E4EC687CFE357F3E681A7500B6FF009717A2E9538956908D3B52B9C865C189" />
Hash="F16E605B55774CDFFDB0EB99FAFF43A40622ED2AB1C011D1195878F4B20030BC" />
Hash="BD3139CE7553AC7003C96304F08EAEC2CDB2CC6A869D36D6F1E478DA02D3AA16" />
Hash="71FC552E66327EDAA72D72C362846BD80CB65EECFAE95C4D790C9A2330D95EE6" />
Hash="A1D1AF7675C2596D0DF977F57B54372298A56EE0F3E1FF2D974D387D7F69DD4E" />
Hash="0D905709AB1174F8E12A063F259A52DABE85CAEB8018985F5411F1CE9C6C99C3" />
Hash="939C291D4A2592209EC7664EC832670FA0AC1009F974F47489D866751F4B862F" />
</FileRules>

<Signers />

<SigningScenarios>
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS_1" FriendlyName="Driver Signing Scenarios">
<ProductSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_DENY_KD" />
</FileRulesRef>
</ProductSigners>
</SigningScenario>
</SigningScenario>
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="User Mode Signing Scenarios">
<ProductSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_DENY_BGINFO"/>
<FileRuleRef RuleID="ID_DENY_CBD"/>
<FileRuleRef RuleID="ID_DENY_KD"/>
<FileRuleRef RuleID="ID_DENY_NTKD"/>
<FileRuleRef RuleID="ID_DENY_WINDBG"/>
<FileRuleRef RuleID="ID_DENY_MSBUILD"/>
<FileRuleRef RuleID="ID_DENY_CSI"/>
<FileRuleRef RuleID="ID_DENY_DNX"/>
<FileRuleRef RuleID="ID_DENY_RCSI"/>
<FileRuleRef RuleID="ID_DENY_NTSD"/>
<FileRuleRef RuleID="ID_DENY_LXSS"/>
<FileRuleRef RuleID="ID_DENY_BASH"/>
<FileRuleRef RuleID="ID_DENY_FSI"/>
<FileRuleRef RuleID="ID_DENY_FSI_ANYCPU"/>
<FileRuleRef RuleID="ID_DENY_APPVPUBSRV"/>
<FileRuleRef RuleID="ID_DENY_MSHTA"/>
<FileRuleRef RuleID="ID_DENY_SMA"/>
<FileRuleRef RuleID="ID_DENY_D_1" />
</FileRulesRef>
</ProductSigners>
</SigningScenario>
</SigningScenarios>
<UpdatePolicySigners />
<CiSigners />
<HvciOptions>0</HvciOptions>
</SiPolicy>
To create a code integrity policy, copy each of the following commands into an elevated Windows PowerShell
session, in order:
1. Initialize variables that you will use. The following example commands use InitialScan.xml and
DeviceGuardPolicy.bin for the names of the files that will be created:
$CIPolicyPath=$env:userprofile+"\Desktop\"
$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"
$CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"
2. Use New-CIPolicy to create a new code integrity policy by scanning the system for installed applications:
New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy UserPEs 3> CIPolicyLog.txt
[!Notes]
When you specify the -UserPEs parameter (to include user mode executables in the scan), rule
option 0 Enabled:UMCI is automatically added to the code integrity policy. In contrast, if you do
not specify -UserPEs, the policy will be empty of user mode executables and will only have rules
for kernel mode binaries like drivers, in other words, the whitelist will not include applications. If
you create such a policy and later add rule option 0 Enabled:UMCI, all attempts to start
applications will cause a response from Device Guard. In audit mode, the response is logging an
event, and in enforced mode, the response is blocking the application.
You can add the -Fallback parameter to catch any applications not discovered using the primary
file rule level specified by the -Level parameter. For more information about file rule level
options, see Code integrity file rule levels in Deploy code integrity policies: policy rules and file
rules.
To specify that the code integrity policy scan only a specific drive, include the -ScanPath
parameter followed by a path. Without this parameter, the entire system is scanned.
The preceding example includes 3> CIPolicylog.txt , which redirects warning messages to a text
file, CIPolicylog.txt.
3. Use ConvertFrom-CIPolicy to convert the code integrity policy to a binary format:

ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin
After you complete these steps, the Device Guard binary file (DeviceGuardPolicy.bin) and original .xml file
(IntialScan.xml) will be available on your desktop. You can use the binary version as a code integrity policy or sign
it for additional security.
NOTE
We recommend that you keep the original .xml file of the policy for use when you need to merge the code integrity policy
with another policy or update its rule options. Alternatively, you would have to create a new policy from a new scan for
servicing. For more information about how to merge code integrity policies, see Merge code integrity policies.
We recommend that every code integrity policy be run in audit mode before being enforced. Doing so allows
administrators to discover any issues with the policy without receiving error message dialog boxes. For
information about how to audit a code integrity policy, see the next section, Audit code integrity policies.
Audit code integrity policies

When code integrity policies are run in audit mode, it allows administrators to discover any applications that were
missed during an initial policy scan and to identify any new applications that have been installed and run since the
original policy was created. While a code integrity policy is running in audit mode, any binary that runs and would
have been denied had the policy been enforced is logged in the Applications and Services
Logs\Microsoft\Windows\CodeIntegrity\Operational event log. When these logged binaries have been
validated, they can easily be added to a new code integrity policy. When the new exception policy is created, you
can merge it with your existing code integrity policies.
NOTE
Before you begin this process, you need to create a code integrity policy binary file. If you have not already done so, see
Create a code integrity policy from a golden computer, earlier in this topic, for a step-by-step walkthrough of the process to
create a code integrity policy and convert it to binary format.
To audit a code integrity policy with local policy:

1. Find a *.bin policy file that you have created, for example, the DeviceGuardPolicy.bin file that resulted from
the steps in the earlier section, Create a code integrity policy from a golden computer. Copy the file to
C:\Windows\System32\CodeIntegrity.
2. On the computer you want to run in audit mode, open the Local Group Policy Editor by running
GPEdit.msc.
NOTE
The computer that you will run in audit mode must be clean of viruses or malware. Otherwise, in the process
that you follow after auditing the system, you might unintentionally merge in a code integrity policy that
allows viruses or malware to run.
An alternative method to test a policy is to rename the test file to SIPolicy.p7b and drop it into
C:\Windows\System32\CodeIntegrity, rather than deploy it by using the Local Group Policy Editor.
3. Navigate to Computer Configuration\Administrative Templates\System\Device Guard, and then

select Deploy Code Integrity Policy. Enable this setting by using the appropriate file path, for example,
C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin, as shown in Figure 1.
NOTE
The illustration shows the example file name DeviceGuardPolicy.bin because this name was used earlier in
this topic, in Create a code integrity policy from a golden computer. Also, this policy file does not need to be
copied to every system. You can instead copy the code integrity policies to a file share to which all computer
accounts have access.
Any policy you select here is converted to SIPolicy.p7b when it is deployed to the individual computers.
You might have noticed that the GPO setting references a .p7b file and this policy uses a .bin file. Regardless
of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped onto
the computers running Windows 10. We recommend that you make your code integrity policy names
friendly and allow the system to convert the policy names for you. By doing this, it ensures that the policies
are easily distinguishable when viewed in a share or any other central repository.
Figure 1. Deploy your code integrity policy
4. Restart the reference system for the code integrity policy to take effect.
5. Use the system as you normally would, and monitor code integrity events in the event log. While in audit
mode, any exception to the deployed code integrity policy will be logged in the Applications and Services
Logs\Microsoft\Windows\CodeIntegrity\Operational event log, as shown in Figure 2.
Figure 2. Exceptions to the deployed code integrity policy
You will be reviewing the exceptions that appear in the event log, and making a list of any applications that
should be allowed to run in your environment.
6. If you want to create a catalog file to simplify the process of including unsigned LOB applications in your
code integrity policy, this is a good time to create it. For information, see Deploy catalog files to support
code integrity policies.
Now that you have a code integrity policy deployed in audit mode, you can capture any audit information that
appears in the event log. This is described in the next section.
Create a code integrity policy that captures audit information from the
event log
Use the following procedure after you have been running a computer with a code integrity policy in audit mode
for a period of time. When you are ready to capture the needed policy information from the event log (so that you
can later merge that information into the original code integrity policy), complete the following steps.
1. Review the audit information in the event log. From the code integrity policy exceptions that you see, make
a list of any applications that should be allowed to run in your environment, and decide on the file rule level
that should be used to trust these applications.
Although the Hash file rule level will catch all of these exceptions, it may not be the best way to trust all of
them. For information about file rule levels, see Code integrity file rule levels in "Deploy code integrity
policies: policy rules and file rules."
Your event log might also contain exceptions for applications that you eventually want your code integrity
policy to block. If these appear, make a list of these also, for a later step in this procedure.
2. In an elevated Windows PowerShell session, initialize the variables that will be used. The example filename
shown here is DeviceGuardAuditPolicy.xml:
$CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"
3. Use New-CIPolicy to generate a new code integrity policy from logged audit events. This example uses a
file rule level of Hash and includes 3> CIPolicylog.txt , which redirects warning messages to a text file,
CIPolicylog.txt.
New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy UserPEs 3> CIPolicylog.txt
NOTE
When you create policies from audit events, you should carefully consider the file rule level that you select to trust.
The preceding example uses the Hash rule level, which is the most specific. Any change to the file (such as replacing
the file with a newer version of the same file) will change the Hash value, and require an update to the policy.
4. Find and review the Device Guard audit policy .xml file that you created. If you used the example variables
as shown, the filename will be DeviceGuardAuditPolicy.xml, and it will be on your desktop. Look for the
following:
Any applications that were caught as exceptions, but should be allowed to run in your environment.
These are applications that should be in the .xml file. Leave these as-is in the file.
Any applications that actually should not be allowed to run in your environment. Edit these out of
the .xml file. If they remain in the .xml file, and the information in the file is merged into your existing
code integrity policy, the policy will treat the applications as trusted, and allow them to run.
You can now use this file to update the existing code integrity policy that you ran in audit mode by merging the
two policies. For instructions on how to merge this audit policy with the existing code integrity policy, see the next
section, Merge code integrity policies.
NOTE
You may have noticed that you did not generate a binary version of this policy as you did in Create a code integrity policy
from a golden computer. This is because code integrity policies created from an audit log are not intended to run as stand-
alone policies but rather to update existing code integrity policies.
Use a code integrity policy to control specific plug-ins, add-ins, and

modules
As of Windows 10, version 1703, you can use code integrity policies not only to control applications, but also to
control whether specific plug-ins, add-ins, and modules can run from specific apps (such as a line-of-business
application or a browser):
APPROACH (AS OF WINDOWS 10, VERSION 1703) GUIDELINE
You can work from a list of plug-ins, add-ins, or modules that Use New-CIPolicyRule with the -AppID option.
you want only a specific application to be able to run. Other
applications would be blocked from running them.
In addition, you can work from a list of plug-ins, add-ins, or Use New-CIPolicyRule with the -AppID and -Deny
modules that you want to block in a specific application. options.
Other applications would be allowed to run them.
To work with these options, the typical method is to create a policy that only affects plug-ins, add-ins, and
modules, then merge it into your master policy (merging is described in the next section).
For example, to create a code integrity policy that allows addin1.dll and addin2.dll to run in ERP1.exe, your
organizations enterprise resource planning (ERP) application, but blocks those add-ins in other applications, run
the following commands. Note that in the second command, += is used to add a second rule to the $rule variable:
$rule = New-CIPolicyRule -DriverFilePath '.\temp\addin1.dll' -Level FileName -AppID '.\ERP1.exe'
$rule += New-CIPolicyRule -DriverFilePath '.\temp\addin2.dll' -Level FileName -AppID '.\ERP1.exe'
New-CIPolicy -Rules $rule -FilePath ".\AllowERPAddins.xml" -UserPEs
As another example, to create a code integrity policy that blocks addin3.dll from running in Microsoft Word, run
the following command. You must include the -Deny option to block the specified add-ins in the specifed
application:
$rule = New-CIPolicyRule -DriverFilePath '.\temp\addin3.dll' -Level FileName -Deny -AppID '.\winword.exe'

New-CIPolicy -Rules $rule -FilePath ".\BlockAddins.xml" -UserPEs
Merge code integrity policies

When you develop code integrity policies, you will occasionally need to merge two policies. A common example is
when a code integrity policy is initially created and audited. Another example is when you create a single master
policy by using multiple code integrity policies previously created from golden computers. Because each
computer running Windows 10 can have only one code integrity policy, it is important to properly maintain these
policies. In this example, audit events have been saved into a secondary code integrity policy that you then merge
with the initial code integrity policy.
NOTE
The following example uses several of the code integrity policy .xml files that you created in earlier sections in this topic. You
can follow this process, however, with any two code integrity policies you would like to combine.
To merge two code integrity policies, complete the following steps in an elevated Windows PowerShell session:
1. Initialize the variables that will be used:
$AuditCIPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"
$MergedCIPolicy=$CIPolicyPath+"MergedPolicy.xml"
$CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"
NOTE
The variables in this section specifically expect to find an initial policy on your desktop called InitialScan.xml and an
audit code integrity policy called DeviceGuardAuditPolicy.xml. If you want to merge other code integrity policies,
update the variables accordingly.
2. Use Merge-CIPolicy to merge two policies and create a new code integrity policy:
Merge-CIPolicy -PolicyPaths $InitialCIPolicy,$AuditCIPolicy -OutputFilePath $MergedCIPolicy
3. Use ConvertFrom-CIPolicy to convert the merged code integrity policy to binary format:
ConvertFrom-CIPolicy $MergedCIPolicy $CIPolicyBin
Now that you have created a new code integrity policy (for example, called NewDeviceGuardPolicy.bin), you
can deploy the policy to systems manually or by using Group Policy or Microsoft client management solutions.
For information about how to deploy this new policy with Group Policy, see the Deploy and manage code integrity
policies with Group Policy section.
Enforce code integrity policies

Every code integrity policy is created with audit mode enabled. After you have successfully deployed and tested a
code integrity policy in audit mode and are ready to test the policy in enforced mode, complete the following
steps in an elevated Windows PowerShell session:
NOTE
Every code integrity policy should be tested in audit mode first. For information about how to audit code integrity policies,
see Audit code integrity policies, earlier in this topic.

$EnforcedCIPolicy=$CIPolicyPath+"EnforcedPolicy.xml"
$CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"
NOTE
The initial code integrity policy that this section refers to was created in the Create a code integrity policy from a
golden computer section. If you are using a different code integrity policy, update the CIPolicyPath and
InitialCIPolicy variables.
2. Ensure that rule options 9 (Advanced Boot Options Menu) and 10 (Boot Audit on Failure) are set the
way that you intend for this policy. We strongly recommend that you enable these rule options before you
run any enforced policy for the first time. Enabling these options provides administrators with a pre-boot
command prompt, and allows Windows to start even if the code integrity policy blocks a kernel-mode
driver from running. When ready for enterprise deployment, you can remove these options.
To ensure that these options are enabled in a policy, use Set-RuleOption as shown in the following
commands. You can run these commands even if you're not sure whether options 9 and 10 are already
enabledif so, the commands have no effect.
Set-RuleOption -FilePath $InitialCIPolicy -Option 9
Set-RuleOption -FilePath $InitialCIPolicy -Option 10
3. Copy the initial file to maintain an original copy:

copy $InitialCIPolicy $EnforcedCIPolicy
4. Use Set-RuleOption to delete the audit mode rule option:

Set-RuleOption -FilePath $EnforcedCIPolicy -Option 3 -Delete
NOTE
To enforce a code integrity policy, you delete option 3, the Audit Mode Enabled option. There is no enforced
option that can be placed in a code integrity policy.
5. Use ConvertFrom-CIPolicy to convert the new code integrity policy to binary format:
ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin
Now that this policy is in enforced mode, you can deploy it to your test computers. Rename the policy to
SIPolicy.p7b and copy it to C:\Windows\System32\CodeIntegrity for testing, or deploy the policy through Group
Policy by following the instructions in Deploy and manage code integrity policies with Group Policy. You can also
use other client management software to deploy and manage the policy.
Signing code integrity policies with SignTool.exe

Signed code integrity policies give organizations the highest level of malware protection available in Windows 10.
In addition to their enforced policy rules, signed policies cannot be modified or deleted by a user or administrator
on the computer. These policies are designed to prevent administrative tampering and kernel mode exploit access.
With this in mind, it is much more difficult to remove signed code integrity policies than unsigned ones. Before
you sign and deploy a signed code integrity policy, we recommend that you audit the policy to discover any
blocked applications that should be allowed to run. For more information about how to audit code integrity
policies, see the Audit code integrity policies section.
Signing code integrity policies by using an on-premises CA-generated certificate or a purchased code signing
certificate is straightforward. If you do not currently have a code signing certificate exported in .pfx format
(containing private keys, extensions, and root certificates), see Optional: Create a code signing certificate for code
integrity policies to create one with your on-premises CA.
Before signing code integrity policies for the first time, be sure to enable rule options 9 (Advanced Boot Options
Menu) and 10 (Boot Audit on Failure) to leave troubleshooting options available to administrators. To ensure
that a rule option is enabled, you can run a command such as
Set-RuleOption -FilePath <PathAndFilename> -Option 9 even if you're not sure whether the option is already
enabledif so, the command has no effect. When validated and ready for enterprise deployment, you can remove
these options. For more information about rule options, see Code integrity policy rules in "Deploy code integrity
policies: policy rules and file rules."
NOTE
Signing code integrity policies is the last step in a code integrity deployment. It is much more difficult to remove a signed
code integrity policy than an unsigned one. Before you deploy a signed code integrity policy to deployed client computers,
be sure to test its effect on a subset of computers.
To sign a code integrity policy with SignTool.exe, you need the following components:
SignTool.exe, found in the Windows SDK (Windows 7 or later)
The binary format of the code integrity policy that you generated in the Create a code integrity policy from
a golden computer section or another code integrity policy that you have created
An internal CA code signing certificate or a purchased code signing certificate
If you do not have a code signing certificate, see the Optional: Create a code signing certificate for code integrity
policies section for instructions on how to create one. If you use an alternate certificate or code integrity policy, be
sure to update the following steps with the appropriate variables and certificate so that the commands will
function properly. To sign the existing code integrity policy, copy each of the following commands into an elevated
Windows PowerShell session:
$CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"
NOTE
This example uses the code integrity policy that you created in the Create a code integrity policy from a golden
computer section. If you are signing another policy, be sure to update the $CIPolicyPath and $CIPolicyBin
variables with the correct information.
2. Import the .pfx code signing certificate. Import the code signing certificate that you will use to sign the code
integrity policy into the signing users personal store on the computer that will be doing the signing. In this
example, you use the certificate that was created in Optional: Create a code signing certificate for code
integrity policies.
3. Export the .cer code signing certificate. After the code signing certificate has been imported, export the .cer
version to your desktop. This version will be added to the policy so that it can be updated later.
4. Navigate to your desktop as the working directory:
cd $env:USERPROFILE\Desktop
5. Use Add-SignerRule to add an update signer certificate to the code integrity policy:
Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -
User Update
NOTE
<Path to exported .cer certificate> should be the full path to the certificate that you exported in step 3. Also,
adding update signers is crucial to being able to modify or disable this policy in the future. For more information
about how to disable signed code integrity policies, see the Disable signed code integrity policies within Windows
section.
6. Use Set-RuleOption to remove the unsigned policy rule option:

Set-RuleOption -FilePath $InitialCIPolicy -Option 6 -Delete
7. Use ConvertFrom-CIPolicy to convert the policy to binary format:

ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin
8. Sign the code integrity policy by using SignTool.exe:

<Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256
$CIPolicyBin
NOTE
The <Path to signtool.exe> variable should be the full path to the SignTool.exe utility. ContosoDGSigningCert is
the subject name of the certificate that will be used to sign the code integrity policy. You should import this
certificate to your personal certificate store on the computer you use to sign the policy.
9. Validate the signed file. When complete, the commands should output a signed policy file called
DeviceGuardPolicy.bin.p7 to your desktop. You can deploy this file the same way you deploy an enforced or
non-enforced policy. For information about how to deploy code integrity policies, see Deploy and manage
code integrity policies with Group Policy.
Disable unsigned code integrity policies
There may come a time when an administrator wants to disable a code integrity policy. For unsigned code
integrity policies, this process is simple. Depending on how the code integrity policy was deployed, unsigned
policies can be disabled in one of two ways. If a code integrity policy was manually enabled and copied to the code
integrity folder location, simply delete the file and restart the computer. The following locations can contain
executing code integrity policies:
<EFI System Partition>\Microsoft\Boot\
<OS Volume>\Windows\System32\CodeIntegrity\
If the code integrity policy was deployed by using Group Policy, the GPO that is currently enabling and deploying
the policy must be set to disabled. Then, the code integrity policy will be disabled on the next computer restart.
Disable signed code integrity policies within Windows

Signed policies protect Windows from administrative manipulation as well as malware that has gained
administrative-level access to the system. For this reason, signed code integrity policies are intentionally more
difficult to remove than unsigned policies. They inherently protect themselves from modification or removal and
therefore are difficult even for administrators to remove successfully. If the signed code integrity policy is
manually enabled and copied to the CodeIntegrity folder, to remove the policy, you must complete the following
steps.
NOTE
For reference, signed code integrity policies should be replaced and removed from the following locations:

1. Replace the existing policy with another signed policy that has the 6 Enabled: Unsigned System
Integrity Policy rule option enabled.
Note To take effect, this policy must be signed with a certificate previously added to the
UpdatePolicySigners section of the original signed policy you want to replace.
2. Restart the client computer.

3. Verify that the new signed policy exists on the client.
Note If the signed policy that contains rule option 6 has not been processed on the client, the addition
of an unsigned policy may cause boot failures.
4. Delete the new policy.

If the signed code integrity policy has been deployed using by using Group Policy, you must complete the
following steps:
1. Replace the existing policy in the GPO with another signed policy that has the 6 Enabled: Unsigned
System Integrity Policy rule option enabled.
Note To take effect, this policy must be signed with a certificate previously added to the
UpdatePolicySigners section of the original signed policy you want to replace.

3. Verify that the new signed policy exists on the client.
Note If the signed policy that contains rule option 6 has not been processed on the client, the addition
of an unsigned policy may cause boot failures.
4. Set the GPO to disabled.

5. Delete the new policy.
Disable signed code integrity policies within the BIOS

There may be a time when signed code integrity policies cause a boot failure. Because code integrity policies
enforce kernel mode drivers, it is important that they be thoroughly tested on each software and hardware
configuration before being enforced and signed. Signed code integrity policies are validated in the pre-boot
sequence by using Secure Boot. When you disable the Secure Boot feature in the BIOS, and then delete the file
from the following locations on the operating system disk, it allows the system to boot into Windows:

Code integrity policies can easily be deployed and managed with Group Policy. A Device Guard administrative
template will be available in Windows Server 2016 that allows you to simplify deployment of Device Guard
hardware-based security features and code integrity policies. The following procedure walks you through how to
deploy a code integrity policy called DeviceGuardPolicy.bin to a test OU called DG Enabled PCs by using a GPO
called Contoso GPO Test.
NOTE
This walkthrough requires that you have previously created a code integrity policy and have a computer running Windows
10 on which to test a Group Policy deployment. For more information about how to create a code integrity policy, see
Create a code integrity policy from a golden computer, earlier in this topic.
NOTE
Signed code integrity policies can cause boot failures when deployed. We recommend that signed code integrity policies be
thoroughly tested on each hardware platform before enterprise deployment.
To deploy and manage a code integrity policy with Group Policy:

1. On a domain controller on a client computer on which RSAT is installed, open the GPMC by running
GPMC.MSC or searching for Group Policy Management in Windows Search.
2. Create a new GPO: right-click an OU, for example, the DG Enabled PCs OU, and then click Create a GPO
in this domain, and Link it here, as shown in Figure 3.
Note You can use any OU name. Also, security group filtering is an option when you consider different
ways of combining code integrity policies (or keeping them separate), as discussed in Planning and
getting started on the Device Guard deployment process.
Figure 3. Create a GPO

3. Name new GPO Contoso GPO Test. This example uses Contoso GPO Test as the name of the GPO. You
can choose any name that you prefer for this example.
4. Open the Group Policy Management Editor: right-click the new GPO, and then click Edit.
5. In the selected GPO, navigate to Computer Configuration\Administrative Templates\System\Device Guard.
Right-click Deploy Code Integrity Policy and then click Edit.
Figure 4. Edit the group policy for code integrity

6. In the Display Code Integrity Policy dialog box, select the Enabled option, and then specify the code
integrity policy deployment path.
In this policy setting, you specify either the local path in which the policy will exist on the client computer or
a Universal Naming Convention (UNC) path that the client computers will look to retrieve the latest version
of the policy. For example, with DeviceGuardPolicy.bin on the test computer, the example file path would be
C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin, as shown in Figure 5.
NOTE
The illustration shows the example file name DeviceGuardPolicy.bin because this name was used earlier in this topic,
in Create a code integrity policy from a golden computer. Also, this policy file does not need to be copied to every
computer. You can instead copy the code integrity policies to a file share to which all computer accounts have
access. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers.
Figure 5. Enable the code integrity policy
NOTE
You may have noticed that the GPO setting references a .p7b file and this example uses a .bin file for the policy.
Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped
on the client computer running Windows 10. Make your code integrity policies friendly and allow the system to
convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any
other central repository.
7. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. Restarting the
computer updates the code integrity policy. For information about how to audit code integrity policies, see
the Audit code integrity policies section.
Related topics
Applies to
Windows 10
Windows Server 2016
Catalog files can be important in your deployment of code integrity polices if you have unsigned line-of-business
(LOB) applications for which the process of signing is difficult. To prepare to create code integrity policies that
allow these trusted applications but block unsigned code (most malware is unsigned), you create a catalog file that
contains information about the trusted applications. After you sign and distribute the catalog, your trusted
applications can be handled by code integrity policies in the same way as any other signed application. With this
foundation, you can more easily block all unsigned applications, allowing only signed applications to run.
For more description of catalog files, see Reviewing your applications: application signing and catalog files in
"Requirements and deployment planning guidelines for Device Guard."
Create catalog files

The creation of a catalog file is a necessary step for adding an unsigned application to a code integrity policy.
To create a catalog file, you use a tool called Package Inspector. You must also have a code integrity policy
deployed in audit mode on the computer on which you run Package Inspector, because Package Inspector does
not always detect installation files that have been removed from the computer during the installation process.
Note When you establish a naming convention it makes it easier to detect deployed catalog files in the future.
In this guide, \-Contoso.cat* is used as the example naming convention. For more information about why this
practice is helpful to inventory or detect catalog files, see Inventory catalog files with System Center
Configuration Manager, later in this topic.
1. Be sure that a code integrity policy is currently deployed in audit mode on the computer on which you will
run Package Inspector.
Package Inspector does not always detect installation files that have been removed from the computer
during the installation process. To ensure that these binaries are also trusted, deploy a code integrity policy
in audit mode. You can use the code integrity policy that you created and audited in Create a code integrity
policy from a golden computer and Audit code integrity policies.
Note This process should not be performed on a system with an enforced Device Guard policy, only
with a policy in audit mode. If a policy is currently being enforced, you will not be able to install and run
the application.
2. Start Package Inspector, and then start scanning a local drive, for example, drive C:
PackageInspector.exe Start C:
Note Package inspector can monitor installations on any local drive. Specify the appropriate drive on
the local computer.
3. Copy the installation media to the local drive (typically drive C).
By copying the installation media to the local drive, you ensure that Package Inspector detects and catalogs
the actual installer. If you skip this step, the future code integrity policy may trust the application to run but
not to be installed.
4. Install the application. Install it to the same drive that the application installer is located on (the drive you
are scanning). Also, while Package Inspector is running, do not run any installations or updates that you
don't want to capture in the catalog.
Important Every binary that is run while Package Inspector is running will be captured in the catalog.
Ensure that only trusted applications are run during this time.
5. Start the application.

6. Ensure that product updates are installed, and downloadable content associated with the application is
downloaded.
7. Close and reopen the application.
This step is necessary to ensure that the scan has captured all binaries.
8. As appropriate, with Package Inspector still running, repeat the process for another application that you
want in the catalog. Copy the installation media to the local drive, install the application, ensure it is
updated, and then close and reopen the application.
9. When you have confirmed that the previous steps are complete, use the following commands to generate
the catalog and definition files on your computer's desktop. The filenames used in these example
commands are LOBApp-Contoso.cat (catalog file) and LOBApp.cdf (definition file)substitute different
filenames as appropriate.
For the last command, which stops Package Inspector, be sure to type the drive letter of the drive you have
been scanning, for example, C:.
$ExamplePath=$env:userprofile+"\Desktop"
$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"
$CatDefName=$ExamplePath+"\LOBApp.cdf"
PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName
Note Package Inspector catalogs the hash values for each discovered binary file. If the applications that were
scanned are updated, complete this process again to trust the new binaries hash values.
When finished, the files will be saved to your desktop. You can double-click the *.cat file to see its contents, and
you can view the *.cdf file with a text editor.
To trust this catalog file within a code integrity policy, the catalog must first be signed. Then, the signing certificate
can be added to the code integrity policy, and the catalog file can be distributed to the individual client computers.
For information about signing catalog files by using a certificate and SignTool.exe, a free tool available in the
Windows SDK, see the next section, Catalog signing with SignTool.exe.
For information about adding the signing certificate to a code integrity policy, see Add a catalog signing certificate
to a code integrity policy.
Catalog signing with SignTool.exe

In this section, you sign a catalog file you generated by using PackageInspector.exe, as described in the previous
section, Create catalog files. In this example, you need the following:
SignTool.exe, found in the Windows software development kit (SDKWindows 7 or later)
The catalog file that you generated in the Create catalog files section, or another catalog file that you have
created
An internal certification authority (CA) code signing certificate or purchased code signing certificate
If you do not have a code signing certificate, see Optional: Create a code signing certificate for code integrity
policies for a walkthrough of how to create one. That topic uses an example certificate name of
ContosoDGSigningCert, and the procedure that follows uses that example certificate name to sign the catalog
file that you created in Create catalog files, earlier in this topic. If you are using an alternate certificate or catalog
file, update the following steps with the appropriate variables and certificate.
To sign the existing catalog file, copy each of the following commands into an elevated Windows PowerShell
session.
$ExamplePath=$env:userprofile+"\Desktop"
$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"
Note This example specifies the catalog file you created in the Create catalog files section. If you are
signing another catalog file, update the $ExamplePath and $CatFileName variables with the correct
information.
2. Import the code signing certificate that will be used to sign the catalog file. Import it to the signing users
personal store. This example uses the certificate name from Optional: Create a code signing certificate for
code integrity policies.
3. Sign the catalog file with Signtool.exe:
<path to signtool.exe> sign /n "ContosoDGSigningCert" /fd sha256 /v $CatFileName
Note The <Path to signtool.exe> variable should be the full path to the Signtool.exe utility.
ContosoDGSigningCert represents the subject name of the certificate that you will use to sign the
catalog file. This certificate should be imported to your personal certificate store on the computer on
which you are attempting to sign the catalog file.
Note For additional information about Signtool.exe and all additional switches, visit the MSDN Sign
Tool page.
4. Verify the catalog file digital signature. Right-click the catalog file, and then click Properties. On the Digital
Signatures tab, verify that your signing certificate exists with a sha256 algorithm, as shown in Figure 1.
Figure 1. Verify that the signing certificate exists
5. Copy the catalog file to C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}.
For testing purposes, you can manually copy signed catalog files to their intended folder. For large-scale
implementations, to copy the appropriate catalog files to all desired computers, we recommend that you
use Group Policy File Preferences or an enterprise systems management product such as System Center
Configuration Manager. Doing this also simplifies the management of catalog versions.
Add a catalog signing certificate to a code integrity policy

After the catalog file is signed, add the signing certificate to a code integrity policy, as described in the following
steps.
1. If you have not already verified the catalog file digital signature, right-click the catalog file, and then click
Properties. On the Digital Signatures tab, verify that your signing certificate exists with the algorithm you
expect.
2. If you already have an XML policy file that you want to add the signing certificate to, skip to the next step.
Otherwise, use New-CIPolicy to create a code integrity policy that you will later merge into another policy
(not deploy as-is). This example creates a policy called CatalogSignatureOnly.xml in the location
C:\PolicyFolder:
New-CIPolicy -Level PcaCertificate -FilePath C:\PolicyFolder\CatalogSignatureOnly.xml UserPEs
Note Include the -UserPEs parameter to ensure that the policy includes user mode code integrity.
3. Use Add-SignerRule to add the signing certificate to the code integrity policy, filling in the correct path and
filenames for <policypath> and <certpath> :
Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User
If you used step 2 to create a new code integrity policy, and want information about merging policies together, see
Merge code integrity policies.
Deploy catalog files with Group Policy
To simplify the management of catalog files, you can use Group Policy preferences to deploy catalog files to the
appropriate computers in your organization. The following process walks you through the deployment of a signed
catalog file called LOBApp-Contoso.cat to a test OU called DG Enabled PCs with a GPO called Contoso DG
Catalog File GPO Test.
Note This walkthrough requires that you have previously created a signed catalog file and have a computer
running Windows 10 on which to test a Group Policy deployment. For more information about how to create a
catalog file, see Create catalog files, earlier in this topic. Also, before you begin testing of a catalog file with the
code integrity policy it supports, review Add a catalog signing certificate to a code integrity policy.
To deploy a catalog file with Group Policy:

1. From either a domain controller or a client computer that has Remote Server Administration Tools (RSAT)
installed, open the Group Policy Management Console (GPMC) by running GPMC.MSC or by searching for
Group Policy Management.
2. Create a new GPO: right-click an OU, for example, the DG Enabled PCs OU, and then click Create a GPO
in this domain, and Link it here, as shown in Figure 2.
Note You can use any OU name. Also, security group filtering is an option when you consider different
ways of combining code integrity policies (or keeping them separate), as discussed in Planning and
getting started on the Device Guard deployment process.
Figure 2. Create a new GPO

3. Give the new GPO a name, for example, Contoso DG Catalog File GPO Test, or any name you prefer.
5. Within the selected GPO, navigate to Computer Configuration\Preferences\Windows Settings\Files. Right-
click Files, point to New, and then click File, as shown in Figure 3.
Figure 3. Create a new file
6. Configure the catalog file share.
To use this setting to provide consistent deployment of your catalog file (in this example, LOBApp-
Contoso.cat), the source file should be on a share that is accessible to the computer account of every
deployed computer. This example uses a share (on a computer running Windows 10) called \\Contoso-
Win10\Share. The catalog file being deployed is copied to this share.
7. To keep versions consistent, in the New File Properties dialog box (Figure 4), select Replace from the
Action list so that the newest version is always used.
Figure 4. Set the new file properties

8. In the Source file(s) box, type the name of your accessible share, with the catalog file name included (for
example, \\Contoso-Win10\share\LOBApp-Contoso.cat).
9. In the Destination File box, type a path and file name, for example:
C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\LOBApp-Contoso.cat
For the catalog file name, use the name of the catalog you are deploying.
10. On the Common tab of the New File Properties dialog box, select the Remove this item when it is no
longer applied option. Doing this ensures that the catalog file is removed from every system, in case you
ever need to stop trusting this application.
11. Click OK to complete file creation.
12. Close the Group Policy Management Editor, and then update the policy on the test computer running
Windows 10, by running GPUpdate.exe. When the policy has been updated, verify that the catalog file exists
in C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} on the computer running
Windows 10.
Before you begin testing the deployed catalog file, make sure that the catalog signing certificate has been added to
an appropriate code integrity policy, as described in Add a catalog signing certificate to a code integrity policy.
Deploy catalog files with System Center Configuration Manager

As an alternative to Group Policy, you can use System Center Configuration Manager to deploy catalog files to the
managed computers in your environment. This approach can simplify the deployment and management of
multiple catalog files as well as provide reporting around which catalog each client or collection has deployed. In
addition to the deployment of these files, System Center Configuration Manager can also be used to inventory the
currently deployed catalog files for reporting and compliance purposes. Complete the following steps to create a
new deployment package for catalog files:
Note The following example uses a network share named \\Shares\CatalogShare as a source for the catalog
files. If you have collection specific catalog files, or prefer to deploy them individually, use whichever folder
structure works best for your organization.
1. Open the Configuration Manager console, and select the Software Library workspace.
2. Navigate to Overview\Application Management, right-click Packages, and then click Create Package.
3. Name the package, set your organization as the manufacturer, and select an appropriate version number.
Figure 5. Specify information about the new package
4. Click Next, and then select Standard program as the program type.
5. On the Standard Program page, select a name, and then set the Command Line property to XCopy
\\Shares\CatalogShare C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-
00C04FC295EE} /H /K /E /Y.
6. On the Standard Program page, select the following options (Figure 6):
In Name, type a name such as Contoso Catalog File Copy Program.
In Command line, browse to the program location.
In Startup folder, type C:\Windows\System32.
From the Run list, select Hidden.
From the Program can run list, select Whether or not a user is logged on.
From the Drive mode list, select Runs with UNC name.
Figure 6. Specify information about the standard program
7. Accept the defaults for the rest of the wizard, and then close the wizard.
After you create the deployment package, deploy it to a collection so that the clients will receive the catalog files. In
this example, you deploy the package you just created to a test collection:
1. In the Software Library workspace, navigate to Overview\Application Management\Packages, right-click the
catalog file package, and then click Deploy.
2. On the General page, select the test collection to which the catalog files will be deployed, and then click
Next.
3. On the Content page, click Add to select the distribution point that will serve content to the selected
collection, and then click Next.
4. On the Deployment Settings page, select Required in the Purpose box.
5. On the Scheduling page, click New.
6. In the Assignment Schedule dialog box, select Assign immediately after this event, set the value to As
soon as possible, and then click OK.
7. On the Scheduling page, click Next.
8. On the User Experience page (Figure 7), set the following options, and then click Next:
Select the Software installation check box.
Select the Commit changes at deadline or during a maintenance window (requires restarts)
check box.
Figure 7. Specify the user experience
9. On the Distribution Points page, in the Deployment options box, select Run program from
distribution point, and then click Next.
10. On the Summary page, review the selections, and then click Next.
11. Close the wizard.
Before you begin testing the deployed catalog file, make sure that the catalog signing certificate has been added to
an appropriate code integrity policy, as described in Add a catalog signing certificate to a code integrity policy.
Inventory catalog files with System Center Configuration Manager

When catalog files have been deployed to the computers within your environment, whether by using Group Policy
or System Center Configuration Manager, you can inventory them with the software inventory feature of System
Center Configuration Manager. The following process walks you through the enablement of software inventory to
discover catalog files on your managed systems through the creation and deployment of a new client settings
policy.
Note A standard naming convention for your catalog files will significantly simplify the catalog file software
inventory process. In this example, -Contoso has been added to all catalog file names.
1. Open the Configuration Manager console, and select the Administration workspace.
2. Navigate to Overview\Client Settings, right-click Client Settings, and then click Create Custom Client
Device Settings.
3. Name the new policy, and under Select and then configure the custom settings for client devices,
select the Software Inventory check box, as shown in Figure 8.
Figure 8. Select custom settings
4. In the navigation pane, click Software Inventory, and then click Set Types, as shown in Figure 9.
Figure 9. Set the software inventory

5. In the Configure Client Setting dialog box, click the Start button to open the Inventories File Properties
dialog box.
6. In the Name box, type a name such as *Contoso.cat, and then click Set.
Note When typing the name, follow your naming convention for catalog files.
7. In the Path Properties dialog box, select Variable or path name, and then type
C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} in the box, as shown in
Figure 10.
Figure 10. Set the path properties

8. Click OK.
9. Now that you have created the client settings policy, right-click the new policy, click Deploy, and then
choose the collection on which you would like to inventory the catalog files.
At the time of the next software inventory cycle, when the targeted clients receive the new client settings policy,
you will be able to view the inventoried files in the built-in System Center Configuration Manager reports or
Resource Explorer. To view the inventoried files on a client within Resource Explorer, complete the following steps:
1. Open the Configuration Manager console, and select the Assets and Compliance workspace.
2. Navigate to Overview\Devices, and search for the device on which you want to view the inventoried files.
3. Right-click the computer, point to Start, and then click Resource Explorer.
4. In Resource Explorer, navigate to Software\File Details to view the inventoried catalog files.
Note If nothing is displayed in this view, navigate to Software\Last Software Scan in Resource Explorer to
verify that the client has recently completed a software inventory scan.
Related topics
Deploy Managed Installer for Device Guard
Creating and maintaining application execution control policies has always been challenging and options for
addressing this has been a frequently cited request for customers of AppLocker and Device Guards configurable
code integrity (CI). This is especially true for enterprises with large, ever changing software catalogs.
Windows 10, version 1703 (also known as the Windows 10 Creators Update) provides a new option, known as a
managed installer, that allows IT administrators to automatically authorize applications deployed and installed by a
designated software distribution solution, such as System Center Configuration Manager. A managed installer
helps an IT admin balance security and manageability requirements when employing application execution control
policies by providing an option that does not require specifying explicit rules for software that is being managed
through a software distribution solution.
How does a managed installer work?

A managed installer uses a new rule collection in AppLocker to specify one or more executables that are trusted by
the organization as an authorized source for application deployment. Specifying an executable as a managed
installer will cause Windows to tag files that are written from the executables process (or processes it launches) as
having originated from a trusted installation authority.
Once the IT administrator adds the Allow: Managed Installer option to a configurable CI policy for Device Guard, the
configurable CI component will subsequently check for the presence of the origin information when evaluating
other application execution control rules specified in the policy. If there are no deny rules present for the file, it will
be authorized based on the managed installer origin information.
NOTE
Admins needs to ensure that there is a CI policy in place to allow the system to boot and run any other authorized
applications that may not be deployed through a managed installer.
Examples of CI policies available in C:\Windows\schemas\CodeIntegrity\ExamplePolicies help authorize Windows OS
components, WHQL signed drivers and all Store apps. Admins can reference and customize them as needed for their Device
Guard deployment.
Configuring a managed installer with AppLocker and configurable code

integrity policy
Setting up managed installer tracking and application execution enforcement requires applying both an AppLocker
and configurable CI policy with specific rules and options enabled. There are three primary steps to keep in mind:
Specify managed installers using the Managed Installer rule collection in AppLocker policy
Enable service enforcement in AppLocker policy
Enable the managed installer option in a configurable CI policy
Specify managed installers using the Managed Installer rule collection in AppLocker policy
The identity of the managed installer executable(s) is specified in an AppLocker policy in a Managed Installer rule
collection. Currently the AppLocker policy creation UI and cmdlets do not allow for directly specifying rules for the
Managed Installer rule collection, however a text editor can be used to make the simple changes needed to an EXE
or DLL rule collection policy to specify Type="ManagedInstaller".
An example of a valid Managed Installer rule collection is shown below.
<RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly">

<FilePublisherRule Id="6cc9a840-b0fd-4f86-aca7-8424a22b4b93" Name="CMM - CCMEXEC.EXE, 5.0.0.0+, Microsoft
signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US"
ProductName="SYSTEM CENTER CONFIGURATION MANAGER" BinaryName="CCMEXEC.EXE">
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
<FilePublisherRule Id="780ae2d3-5047-4240-8a57-767c251cbb12" Name="CCM - CCMSETUP.EXE, 5.0.0.0+, Microsoft
signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US"
ProductName="SYSTEM CENTER CONFIGURATION MANAGER" BinaryName="CCMSETUP.EXE">
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
</RuleCollection>
Enable service enforcement in AppLocker policy

Since many installation processes rely on services, it is typically necessary to enable tracking of services. Correct
tracking of services requires the presence of at least one rule in the rule collection a simple audit only rule will
suffice. For example:
<RuleCollection Type="Dll" EnforcementMode="AuditOnly" >

<FilePathRule Id="86f235ad-3f7b-4121-bc95-ea8bde3a5db5" Name="Dummy Rule" Description="" UserOrGroupSid="S-
1-1-0" Action="Deny">
<Conditions>
<FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.dll" />
</Conditions>
</FilePathRule>
<RuleCollectionExtensions>
<ThresholdExtensions>
<Services EnforcementMode="Enabled" />
</ThresholdExtensions>
<RedstoneExtensions>
<SystemApps Allow="Enabled"/>
</RedstoneExtensions>
</RuleCollectionExtensions>
</RuleCollection>
<RuleCollection Type="Exe" EnforcementMode="AuditOnly">
<FilePathRule Id="9420c496-046d-45ab-bd0e-455b2649e41e" Name="Dummy Rule" Description="" UserOrGroupSid="S-
1-1-0" Action="Deny">
<Conditions>
<FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.exe" />
</Conditions>
</FilePathRule>
<RuleCollectionExtensions>
<ThresholdExtensions>
<Services EnforcementMode="Enabled" />
</ThresholdExtensions>
<RedstoneExtensions>
<SystemApps Allow="Enabled"/>
</RedstoneExtensions>
</RuleCollectionExtensions>
</RuleCollection>
Enable the managed installer option in CI policy

In order to enable trust for the binaries laid down by managed installers, the Allow: Managed Installer option must
be specified in your configurable CI policy. . This can be done by using the Set-RuleOption cmdlet. An example of
the managed installer option being set in policy is shown below.
<Rules>
<Rule>
<Option>Enabled:Unsigned System Integrity Policy</Option>
</Rule>
<Rule>
<Option>Enabled:Advanced Boot Options Menu</Option>
</Rule>
<Rule>
<Option>Enabled:UMCI</Option>
</Rule>
<Rule>
<Option>Enabled:Inherit Default Policy</Option>
</Rule>
<Rule>
<Option>Enabled:Managed Installer </Option>
</Rule>
</Rules>
Security considerations with managed installer

Since managed installer is a heuristic-based mechanism, it does not provide the same security guarantees that
explicit allow or deny rules do. It is best suited for deployment to systems where each user is configured as a
standard user and where all software is deployed and installed by a software distribution solution, such as System
Center Configuration Manager.
Users with administrator privileges on the system may be able to circumvent the intent of Device Guard
configurable CI when the managed installer option is allowed. If the authorized managed installer process performs
installations in the context of a user with standard privileges, then it is possible that standard users may be able to
circumvent the intent of Device Guard configurable CI policy. In some cases, the heuristic tracking and authorizing
applications may be active on the first execution of an application that is laid down from a designated managed
installer. Typically, this would occur if the managed installer executes the application directly as part of the
installation process. To avoid this, ensure that the application deployment solution being used as a managed
installer limits running applications as part of installation.
Known limitations with managed installer

Application execution control based on managed installer does not support applications that self-update. If
an application deployed by a managed installer subsequently updates itself, the updated application files will
no longer include the managed installer origin EA information and will not be authorized to run. Enterprises
should deploy and install all application updates using the managed installer. In some cases, it may be
possible to also designate an application binary that performs the self-updates as a managed installer.
Proper review for functionality and security should be performed for the application before using this
method.
Although configurable CI policies can be deployed in both audit and enforced mode, the managed installer
option is currently only recommended for use with policies set to enforced except in lab environments.
Using the managed installer option with configurable CI policies set to audit only may result in unexpected
behavior if the policy is subsequently changed to enforced mode.
Modern apps deployed through a managed installer will not be tracked by the heuristic and will need to be
appropriately authorized in policy.
Executables that extract files and then attempt to execute may fail the heuristic. In some cases, it may be
possible to also designate an application binary that performs such an operation as a managed installer.
Proper review for functionality and security should be performed for the application before using this
method.
The managed installer heuristic does not authorize drivers. The configurable code integrity policy being used
must have rules that allow the necessary drivers to run.
In some cases, the code integrity logs will contain error events for native images generated for .NET
assemblies. Typically, the error is functionally benign as a blocked native image will result in the
corresponding assembly being re-interpreted. Review for functionality and performance for the related
applications using the native images maybe necessary in some cases.
Deploy Device Guard: enable virtualization-based
security
Applies to
Windows 10
Windows Server 2016
Hardware-based security features, also called virtualization-based security or VBS, make up a large part of Device
Guard security offerings. VBS reinforces the most important feature of Device Guard: configurable code integrity.
There are a few steps to configure hardware-based security features in Device Guard:
1. Decide whether to use the procedures in this topic, or to use the Device Guard readiness tool. To
enable VBS, you can download and use the hardware readiness tool on the Microsoft Download Center, or
follow the procedures in this topic.
2. Verify that hardware and firmware requirements are met. Verify that your client computers possess
the necessary hardware and firmware to run these features. A list of requirements for hardware-based
security features is available in Hardware, firmware, and software requirements for Device Guard.
3. Enable the necessary Windows features. There are several ways to enable the Windows features
required for hardware-based security. You can use the Device Guard and Credential Guard hardware
readiness tool, or see the following section, Windows feature requirements for virtualization-based
security.
4. Enable additional features as desired. When the necessary Windows features have been enabled, you
can enable additional hardware-based security features as desired. You can use the Device Guard and
Credential Guard hardware readiness tool, or see Enable virtualization-based security (VBS), later in this
topic.
For information about enabling Credential Guard, see Protect derived domain credentials with Credential Guard.
Windows feature requirements for virtualization-based security and

Device Guard
In addition to the hardware requirements found in Hardware, firmware, and software requirements for Device
Guard, you must confirm that certain operating system features are enabled before you can enable VBS:
Beginning with Windows 10, version 1607 or Windows Server 2016:
Hyper-V Hypervisor, which is enabled automatically. No further action is needed.
With an earlier version of Windows 10:
Hyper-V Hypervisor and Isolated User Mode (shown in Figure 1).
Note You can configure these features by using Group Policy or Deployment Image Servicing and
Management, or manually by using Windows PowerShell or the Windows Features dialog box.
Figure 1. Enable operating system features for VBS, Windows 10, version 1511
Enable Virtualization Based Security (VBS) and Device Guard

There are multiple ways to configure VBS features for Device Guard:
You can use the readiness tool rather than the procedures in this topic.
You can use Group Policy, as described in the procedure that follows.
You can configure VBS manually, as described in Use registry keys to enable VBS and Device Guard, later in
this topic.
Note We recommend that you test-enable these features on a group of test computers before you enable
them on users' computers. If untested, there is a possibility that this feature can cause system instability and
ultimately cause the client operating system to fail.
Use Group Policy to enable VBS and Device Guard

1. To create a new GPO, right-click the OU to which you want to link the GPO, and then click Create a GPO in
this domain, and Link it here.
Figure 2. Create a new OU-linked GPO

2. Give the new GPO a name, for example, Contoso VBS settings GPO Test, or any name you prefer. Ideally,
the name will align with your existing GPO naming convention.
4. Within the selected GPO, navigate to Computer Configuration\Policies\Administrative
Templates\System\Device Guard. Right-click Turn On Virtualization Based Security, and then click Edit.
Figure 3. Enable VBS

5. Select the Enabled button, and then choose a secure boot option, such as Secure Boot, from the Select
Platform Security Level list.
Figure 4. Configure VBS, Secure Boot setting (in Windows 10, version 1607)
Important These settings include Secure Boot and Secure Boot with DMA. In most situations we
recommend that you choose Secure Boot. This option provides secure boot with as much protection
as is supported by a given computers hardware. A computer with input/output memory management
units (IOMMUs) will have secure boot with DMA protection. A computer without IOMMUs will simply
have secure boot enabled.
In contrast, with Secure Boot with DMA, the setting will enable secure bootand VBS itselfonly on
a computer that supports DMA, that is, a computer with IOMMUs. With this setting, any computer
without IOMMUs will not have VBS (hardware-based) protection, although it can have code integrity
policies enabled.
For information about how VBS uses the hypervisor to strengthen protections provided by a code
integrity policy, see How Device Guard features help protect against threats.
6. For Virtualization Based Protection of Code Integrity, select the appropriate option.
WARNING
Virtualization-based protection of code integrity may be incompatible with some devices and applications. We
strongly recommend testing this configuration in your lab before enabling virtualization-based protection of code
integrity on production systems. Failure to do so may result in unexpected failures up to and including data loss or a
blue screen error (also called a stop error).
Select an option as follows:

With Windows 10, version 1607 or Windows Server 2016, choose an appropriate option:
For an initial deployment or test deployment, we recommend Enabled without lock.
When your deployment is stable in your environment, we recommend changing to Enabled with
lock. This option helps protect the registry from tampering, either through malware or by an
unauthorized person.
With earlier versions of Windows 10:
Select the Enable Virtualization Based Protection of Code Integrity check box.
Figure 5. Configure VBS, Lock setting (in Windows 10, version 1607)
7. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. The settings
will take effect upon restart.
8. Check the test computers event log for Device Guard GPOs.
Processed Device Guard policies are logged in event viewer at Applications and Services
Logs\Microsoft\Windows\DeviceGuard-GPEXT\Operational. When the Turn On Virtualization
Based Security policy is successfully processed, event ID 7000 is logged, which contains the selected
settings within the policy.
Note Events will be logged in this event channel only when Group Policy is used to enable Device Guard
features, not through other methods. If other methods such as registry keys are used, Device Guard features
will be enabled but the events wont be logged in this event channel.
Use registry keys to enable VBS and Device Guard

Set the following registry keys to enable VBS and Device Guard. This provides exactly the same set of
configuration options provided by Group Policy.
WARNING
Virtualization-based protection of code integrity (controlled through the registry key HypervisorEnforcedCodeIntegrity)
may be incompatible with some devices and applications. We strongly recommend testing this configuration in your lab
before enabling virtualization-based protection of code integrity on production systems. Failure to do so may result in
unexpected failures up to and including data loss or a blue screen error (also called a stop error).
Important
Among the commands that follow, you can choose settings for Secure Boot and Secure Boot with DMA.
In most situations we recommend that you simply choose Secure Boot. This option provides secure boot
with as much protection as is supported by a given computers hardware. A computer with input/output
memory management units (IOMMUs) will have secure boot with DMA protection. A computer without
IOMMUs will simply have secure boot enabled.
In contrast, with Secure Boot with DMA, the setting will enable secure bootand VBS itselfonly on a
computer that supports DMA, that is, a computer with IOMMUs. With this setting, any computer without
IOMMUs will not have VBS (hardware-based) protection, although it can still have code integrity policies
enabled.
For information about how VBS uses the hypervisor to strengthen protections provided by a code integrity
policy, see How Device Guard features help protect against threats.
All drivers on the system must be compatible with virtualization-based protection of code integrity;
otherwise, your system may fail. We recommend that you enable these features on a group of test
computers before you enable them on users' computers.
For Windows 1607 and above

Recommended settings (to enable virtualization-based protection of Code Integrity policies, without UEFI Lock):
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t

REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD

/d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Locked" /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v

"Enabled" /t REG_DWORD /d 1 /f

"Locked" /t REG_DWORD /d 0 /f
If you want to customize the preceding recommended settings, use the following settings.
To enable VBS

REG_DWORD /d 1 /f
To enable VBS and require Secure boot only (value 1)

/d 1 /f
To enable VBS with Secure Boot and DMA (value 3), in the preceding command, change /d 1 to /d 3.
To enable VBS without UEFI lock (value 0)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Locked" /t REG_DWORD /d 0 /f
To enable VBS with UEFI lock (value 1), in the preceding command, change /d 0 to /d 1.
To enable virtualization-based protection of Code Integrity policies

"Enabled" /t REG_DWORD /d 1 /f
To enable virtualization-based protection of Code Integrity policies without UEFI lock (value 0)

"Locked" /t REG_DWORD /d 0 /f
To enable virtualization-based protection of Code Integrity policies with UEFI lock (value 1), in the
preceding command, change /d 0 to /d 1.
For Windows 1511 and below

Recommended settings (to enable virtualization-based protection of Code Integrity policies, without UEFI Lock):

REG_DWORD /d 1 /f

/d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "HypervisorEnforcedCodeIntegrity" /t REG_DWORD

/d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Unlocked" /t REG_DWORD /d 1 /f
If you want to customize the preceding recommended settings, use the following settings.
To enable VBS (it is always locked to UEFI)

REG_DWORD /d 1 /f
To enable VBS and require Secure boot only (value 1)

/d 1 /f
To enable VBS with Secure Boot and DMA (value 3), in the preceding command, change /d 1 to /d 3.
To enable virtualization-based protection of Code Integrity policies (with the default, UEFI lock)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "HypervisorEnforcedCodeIntegrity" /t REG_DWORD

/d 1 /f
To enable virtualization-based protection of Code Integrity policies without UEFI lock
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Unlocked" /t REG_DWORD /d 1 /f
Validate enabled Device Guard hardware -based security features

Windows 10 and Windows Server 2016 and later have a WMI class for Device Guardrelated properties and
features: Win32_DeviceGuard. This class can be queried from an elevated Windows PowerShell session by using
the following command:
Get-CimInstance ClassName Win32_DeviceGuard Namespace root\Microsoft\Windows\DeviceGuard
Note The Win32_DeviceGuard WMI class is only available on the Enterprise edition of Windows 10.
The output of this command provides details of the available hardware-based security features as well as those
features that are currently enabled. For detailed information about what each property means, refer to Table 1.
Table 1. Win32_DeviceGuard properties
PROPERTIES DESCRIPTION VALID VALUES
AvailableSecurityProperties This field helps to enumerate and 0. If present, no relevant

report state on the relevant security properties exist on the
properties for Device Guard. device.
1. If present, hypervisor
support is available.
2. If present, Secure Boot is
available.
3. If present, DMA
protection is available.
4. If present, Secure
Memory Overwrite is
available.
5. If present, NX protections
are available.
6. If present, SMM
mitigations are available.
Note: 4, 5, and 6 were added as of
Windows 10, version 1607.
InstanceIdentifier A string that is unique to a particular Determined by WMI.

device.
PROPERTIES DESCRIPTION VALID VALUES
RequiredSecurityProperties This field describes the required security 0. Nothing is required.

properties to enable virtualization-
based security. 1. If present, hypervisor
support is needed.
2. If present, Secure Boot is
needed.
3. If present, DMA
protection is needed.
4. If present, Secure
Memory Overwrite is
needed.
5. If present, NX protections
are needed.
6. If present, SMM
mitigations are needed.
Note: 4, 5, and 6 were added as of
Windows 10, version 1607.
SecurityServicesConfigured This field indicates whether the 0. No services configured.

Credential Guard or HVCI service has
been configured. 1. If present, Credential
Guard is configured.
2. If present, HVCI is
configured.
SecurityServicesRunning This field indicates whether the 0. No services running.

Credential Guard or HVCI service is
running. 1. If present, Credential
Guard is running.
2. If present, HVCI is
running.
Version This field lists the version of this WMI The only valid value now is 1.0.
class.
VirtualizationBasedSecurityStatus This field indicates whether VBS is 0. VBS is not enabled.

enabled and running.
1. VBS is enabled but not
running.
2. VBS is enabled and
running.
PSComputerName This field lists the computer name. All valid values for computer name.
Another method to determine the available and enabled Device Guard features is to run msinfo32.exe from an
elevated PowerShell session. When you run this program, the Device Guard properties are displayed at the
bottom of the System Summary section, as shown in Figure 6.
Figure 6. Device Guard properties in the System Summary
Related topics
Encrypted Hard Drive
Applies to
Windows 10
Windows Server 2016
Encrypted Hard Drive uses the rapid encryption that is provided by BitLocker Drive Encryption to enhance data
security and management.
By offloading the cryptographic operations to hardware, Encrypted Hard Drives increase BitLocker performance
and reduce CPU usage and power consumption. Because Encrypted Hard Drives encrypt data quickly, enterprise
devices can expand BitLocker deployment with minimal impact on productivity.
Encrypted Hard Drives are a new class of hard drives that are self-encrypting at a hardware level and allow for full
disk hardware encryption. In Windows 8, Windows Server 2012, and later you can install to these devices without
additional modification.
Some of the benefits of Encrypted Hard Drives include:
Better performance: Encryption hardware, integrated into the drive controller, allows the drive to operate at
full data rate with no performance degradation.
Strong security based in hardware: Encryption is always "on" and the keys for encryption never leave the
hard drive. User authentication is performed by the drive before it will unlock, independently of the operating
system
Ease of use: Encryption is transparent to the user because it is on by default. There is no user interaction
needed to enable encryption. Encrypted Hard Drives are easily erased using on-board encryption key; there is
no need to re-encrypt data on the drive.
Lower cost of ownership: There is no need for new infrastructure to manage encryption keys, since BitLocker
leverages your Active Directory Domain Services infrastructure to store recovery information. Your device
operates more efficiently because processor cycles do not need to be used for the encryption process.
Encrypted Hard Drives are supported natively in the operating system through the following mechanisms:
Identification: The operating system can identify that the drive is an Encrypted Hard Drive device type
Activation: The operating system disk management utility can activate, create and map volumes to
ranges/bands as appropriate
Configuration: The operating system can create and map volumes to ranges/bands as appropriate
API: API support for applications to manage Encrypted Hard Drives independently of BitLocker Drive Encryption
(BDE)
BitLocker support: Integration with the BitLocker Control Panel provides a seamless BitLocker end user
experience.
Warning: Self-Encrypting Hard Drives and Encrypted Hard Drives for Windows are not the same type of
device. Encrypted Hard Drives for Windows require compliance for specific TCG protocols as well as IEEE 1667
compliance; Self-Encrypting Hard Drives do not have these requirements. It is important to confirm the device
type is an Encrypted Hard Drive for Windows when planning for deployment.
If you are a storage device vendor who is looking for more info on how to implement Encrypted Hard Drive, see
the Encrypted Hard Drive Device Guide.
System Requirements
To use Encrypted Hard Drive, the following system requirements apply:
For Encrypted Hard Drives used as data drives:
The drive must be in an uninitialized state.
The drive must be in a security inactive state.
For Encrypted Hard Drives used as startup drives:
The drive must be in an uninitialized state.
The drive must be in a security inactive state.
The computer must be UEFI 2.3.1 based and have the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL
defined. (This protocol is used to allow programs running in the EFI boot services environment to send security
protocol commands to the drive).
The computer must have the Compatibility Support Module (CSM) disabled in UEFI.
The computer must always boot natively from UEFI.
Warning: All Encrypted Hard Drives must be attached to non-RAID controllers to function properly.
Technical overview
Rapid encryption in BitLocker directly addresses the security needs of enterprises while offering significantly
improved performance. In versions of Windows earlier than Windows Server 2012, BitLocker required a two-step
process to complete read/write requests. In Windows Server 2012, Windows 8, or later, Encrypted Hard Drives
offload the cryptographic operations to the drive controller for much greater efficiency. When the operating
system an Encrypted Hard Drive, it activates the security mode. This activation lets the drive controller generate a
media key for every volume that the host computer creates. This media key, which is never exposed outside the
disk, is used to rapidly encrypt or decrypt every byte of data that is sent or received from the disk.
Configuring Encrypted Hard Drives as Startup drives

Configuration of Encrypted Hard Drives as startup drives is done using the same methods as standard hard drives.
These methods include:
Deploy from media: Configuration of Encrypted Hard Drives happens automatically through the installation
process.
Deploy from network: This deployment method involves booting a Windows PE environment and using
imaging tools to apply a Windows image from a network share. Using this method, the Enhanced Storage
optional component needs to be included in the Windows PE image. You can enable this component using
Server Manager, Windows PowerShell, or the DISM command line tool. If this component is not present,
configuration of Encrypted Hard Drives will not work.
Deploy from server: This deployment method involves PXE booting a client with Encrypted Hard Drives
present. Configuration of Encrypted Hard Drives happens automatically in this environment when the Enhanced
Storage component is added to the PXE boot image. During deployment, the TCGSecurityActivationDisabled
setting in unattend.xml controls the encryption behavior of Encrypted Hard Drives.
Disk Duplication: This deployment method involves use of a previously configured device and disk
duplication tools to apply a Windows image to an Encrypted Hard Drive. Disks must be partitioned using at
least Windows 8 or Windows Server 2012 for this configuration to work. Images made using disk duplicators
will not work.
Encrypted Hard Drive Architecture
Encrypted Hard Drives utilize two encryption keys on the device to control the locking and unlocking of data on the
drive. These are the Data Encryption Key (DEK) and the Authentication Key (AK).
The Data Encryption Key is the key used to encrypt all of the data on the drive. The drive generates the DEK and it
never leaves the device. It is stored in an encrypted format at a random location on the drive. If the DEK is changed
or erased, data encrypted using the DEK is irrecoverable.
The Authentication Key is the key used to unlock data on the drive. A hash of the key is stored on drive and
requires confirmation to decrypt the DEK.
When a computer with an Encrypted Hard Drive is in a powered off state, the drive locks automatically. As a
computer powers on, the device remains in a locked state and is only unlocked after the Authentication Key
decrypts the Data Encryption Key. Once the Authentication Key decrypts the Data Encryption Key, read-write
operations can take place on the device.
When writing data to the drive, it passes through an encryption engine before the write operation completes.
Likewise, reading data from the drive requires the encryption engine to decrypt the data before passing that data
back to the user. In the event that the DEK needs to be changed or erased, the data on the drive does not need to
be re-encrypted. A new Authentication Key needs to be created and it will re-encrypt the DEK. Once completed, the
DEK can now be unlocked using the new AK and read-writes to the volume can continue.
Re-configuring Encrypted Hard Drives

Many Encrypted Hard Drive devices come pre-configured for use. If reconfiguration of the drive is required, use the
following procedure after removing all available volumes and reverting the drive to an uninitialized state:
1. Open Disk Management (diskmgmt.msc)
2. Initialize the disk and select the appropriate partition style (MBR or GPT)
3. Create one or more volumes on the disk.
4. Use the BitLocker setup wizard to enable BitLocker on the volume.
Security auditing
Applies to
Windows 10
Topics in this section are for IT professionals and describes the security auditing features in Windows and how
your organization can benefit from using these technologies to enhance the security and manageability of your
network.
Security auditing is one of the most powerful tools that you can use to maintain the integrity of your system. As
part of your overall security strategy, you should determine the level of auditing that is appropriate for your
environment. Auditing should identify attacks (successful or not) that pose a threat to your network, and attacks
against resources that you have determined to be valuable in your risk assessment.
In this section
TOPIC DESCRIPTION
Basic security audit policies Before you implement auditing, you must decide on an
auditing policy. A basic audit policy specifies categories of
security-related events that you want to audit. When this
version of Windows is first installed, all auditing categories are
disabled. By enabling various auditing event categories, you
can implement an auditing policy that suits the security needs
of your organization.
Advanced security audit policies Advanced security audit policy settings are found in Security
Settings\Advanced Audit Policy Configuration\System
Audit Policies and appear to overlap with basic security audit
policies, but they are recorded and applied differently.
Basic security audit policies
Applies to
Windows 10
Before you implement auditing, you must decide on an auditing policy. A basic audit policy specifies categories of
security-related events that you want to audit. When this version of Windows is first installed, all auditing
categories are disabled. By enabling various auditing event categories, you can implement an auditing policy that
suits the security needs of your organization.
The event categories that you can choose to audit are:
Audit account logon events
Audit account management
Audit directory service access
Audit logon events
Audit object access
Audit policy change
Audit privilege use
Audit process tracking
Audit system events
If you choose to audit access to objects as part of your audit policy, you must enable either the audit directory
service access category (for auditing objects on a domain controller), or the audit object access category (for
auditing objects on a member server or workstation). Once you have enabled the object access category, you can
specify the types of access you want to audit for each group or user.
In this section
TOPIC DESCRIPTION
Create a basic audit policy for an event category By defining auditing settings for specific event categories, you
can create an auditing policy that suits the security needs of
your organization. On devices that are joined to a domain,
auditing settings for the event categories are undefined by
default. On domain controllers, auditing is turned on by
default.
Apply a basic audit policy on a file or folder You can apply audit policies to individual files and folders on
your computer by setting the permission type to record
successful access attempts or failed access attempts in the
security log.
View the security event log The security log records each event as defined by the audit
policies you set on each object.
Basic security audit policy settings Basic security audit policy settings are found under Computer
Configuration\Windows Settings\Security Settings\Local
Policies\Audit Policy.
Create a basic audit policy for an event category
Applies to
Windows 10
By defining auditing settings for specific event categories, you can create an auditing policy that suits the security
needs of your organization. On devices that are joined to a domain, auditing settings for the event categories are
undefined by default. On domain controllers, auditing is turned on by default.
To complete this procedure, you must be logged on as a member of the built-in Administrators group.
To define or modify auditing policy settings for an event category for your local computer
1. Open the Local Security Policy snap-in (secpol.msc), and then click Local Policies.
2. Click Audit Policy.
3. In the results pane, double-click an event category that you want to change the auditing policy settings for.
4. Do one or both of the following, and then click OK.
To audit successful attempts, select the Success check box.
To audit unsuccessful attempts, select the Failure check box.
To complete this procedure, you must be logged on as a member of the Domain Admins group.
To define or modify auditing policy settings for an event category for a domain or organizational unit,
when you are on a member server or on a workstation that is joined to a domain
1. Open the Group Policy Management Console (GPMC).
2. In the console tree, double-click Group Policy objects in the forest and domain containing the Default
Domain Policy Group Policy object (GPO) that you want to edit.
3. Right-click the Default Domain Policy GPO, and then click Edit.
4. In the GPMC, go to Computer Configuration, Windows Settings, Security Settings, and then click Audit
Policy.
5. In the results pane, double-click an event category that you want to change the auditing policy settings for.
6. If you are defining auditing policy settings for this event category for the first time, select the Define these
policy settings check box.
7. Do one or both of the following, and then click OK.
To audit successful attempts, select the Success check box.
To audit unsuccessful attempts, select the Failure check box.
To audit object access, enable auditing of the object access event category by following the steps above. Then,
enable auditing on the specific object.
After your audit policy is configured, events will be recorded in the Security log. Open the Security log to view
these events.
The default auditing policy setting for domain controllers is No Auditing. This means that even if auditing is
enabled in the domain, the domain controllers do not inherit auditing policy locally. If you want domain auditing
policy to apply to domain controllers, you must modify this policy setting.
Apply a basic audit policy on a file or folder
Applies to
Windows 10
You can apply audit policies to individual files and folders on your computer by setting the permission type to
record successful access attempts or failed access attempts in the security log. To complete this procedure, you
must be logged on as a member of the built-in Administrators group or you must have been granted the Manage
auditing and security log right.
To apply or modify auditing policy settings for a local file or folder
1. Right-click the file or folder that you want to audit, click Properties, and then click the Security tab.
2. Click Advanced.
3. In the Advanced Security Settings dialog box, click the Auditing tab, and then click Continue.
4. Do one of the following:
To set up auditing for a new user or group, click Add. Click Select a principal, type the name of the user
or group that you want, and then click OK.
To remove auditing for an existing group or user, click the group or user name, click Remove, click OK,
and then skip the rest of this procedure.
To view or change auditing for an existing group or user, click its name, and then click Edit.
5. In the Type box, indicate what actions you want to audit by selecting the appropriate check boxes:
To audit successful events, click Success.
To audit failure events, click Fail.
To audit all events, click All.
Important: Before setting up auditing for files and folders, you must enable object access auditing by defining
auditing policy settings for the object access event category. If you do not enable object access auditing, you
will receive an error message when you set up auditing for files and folders, and no files or folders will be
audited.
After object access auditing is enabled, view the security log in Event Viewer to review the results of your
changes.
You can set up file and folder auditing only on NTFS drives.
Because the security log is limited in size, select the files and folders to be audited carefully. Also, consider the
amount of disk space that you want to devote to the security log. The maximum size for the security log is
defined in Event Viewer.
View the security event log
Applies to
Windows 10
The security log records each event as defined by the audit policies you set on each object.
To view the security log
1. Open Event Viewer.
2. In the console tree, expand Windows Logs, and then click Security. The results pane lists individual security
events.
3. If you want to see more details about a specific event, in the results pane, click the event.
Basic security audit policy settings
Applies to
Windows 10
Basic security audit policy settings are found under Computer Configuration\Windows Settings\Security
Settings\Local Policies\Audit Policy.
In this section
TOPIC DESCRIPTION
Audit account logon events Determines whether to audit each instance of a user logging
on to or logging off from another device in which this device
is used to validate the account.
Audit account management Determines whether to audit each event of account

management on a device.
Audit directory service access Determines whether to audit the event of a user accessing an
Active Directory object that has its own system access control
list (SACL) specified.
Audit logon events Determines whether to audit each instance of a user logging
on to or logging off from a device.
Audit object access Determines whether to audit the event of a user accessing an
object--for example, a file, folder, registry key, printer, and so
forth--that has its own system access control list (SACL)
specified.
Audit policy change Determines whether to audit every incident of a change to

user rights assignment policies, audit policies, or trust policies.
Audit privilege use Determines whether to audit each instance of a user

exercising a user right.
Audit process tracking Determines whether to audit detailed tracking information for
events such as program activation, process exit, handle
duplication, and indirect object access.
Audit system events Determines whether to audit when a user restarts or shuts
down the computer or when an event occurs that affects
either the system security or the security log.
Related topics
Applies to
Windows 10
Determines whether to audit each instance of a user logging on to or logging off from another device in which this
device is used to validate the account.
This security setting determines whether to audit each instance of a user logging on to or logging off from another
computer in which this computer is used to validate the account. Account logon events are generated when a
domain user account is authenticated on a domain controller. The event is logged in the domain controller's
security log. Logon events are generated when a local user is authenticated on a local computer. The event is
logged in the local security log. Account logoff events are not generated.
If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event
type at all. Success audits generate an audit entry when an account logon attempt succeeds. Failure audits generate
an audit entry when an account logon attempt fails. To set this value to No auditing, in the Properties dialog box
for this policy setting, select the Define these policy settings check box and clear the Success and Failure check
boxes.
Default: Success
Configure this audit setting

You can configure this security setting by opening the appropriate policy under Computer Configuration\Windows
Settings\Security Settings\Local Policies\Audit Policy.
LOGON EVENTS DESCRIPTION
672 An authentication service (AS) ticket was successfully issued

and validated.
673 A ticket granting service (TGS) ticket was granted.
674 A security principal renewed an AS ticket or TGS ticket.
675 Preauthentication failed. This event is generated on a Key

Distribution Center (KDC) when a user types in an incorrect
password.
676 Authentication ticket request failed. This event is not

generated in Windows XP or in the Windows Server 2003
family.
677 A TGS ticket was not granted. This event is not generated in
Windows XP or in the Windows Server 2003 family.
678 An account was successfully mapped to a domain account.

681 Logon failure. A domain account logon was attempted. This

event is not generated in Windows XP or in the Windows
Server 2003 family.
682 A user has reconnected to a disconnected terminal server

session.
683 A user disconnected a terminal server session without logging

off.
Related topics
Applies to
Windows 10
Determines whether to audit each event of account management on a device.
Examples of account management events include:
A user account or group is created, changed, or deleted.
A user account is renamed, disabled, or enabled.
A password is set or changed.
type at all. Success audits generate an audit entry when any account management event succeeds. Failure audits
generate an audit entry when any account management event fails. To set this value to No auditing, in the
Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success
and Failure check boxes.
Default:
Success on domain controllers.
No auditing on member servers.

ACCOUNT MANAGEMENT EVENTS DESCRIPTION
624 A user account was created.
627 A user password was changed.
628 A user password was set.
630 A user account was deleted.
631 A global group was created.
632 A member was added to a global group.
633 A member was removed from a global group.
634 A global group was deleted.
635 A new local group was created.

636 A member was added to a local group.
637 A member was removed from a local group.
638 A local group was deleted.
639 A local group account was changed.
641 A global group account was changed.
642 A user account was changed.
643 A domain policy was modified.
644 A user account was auto locked.
645 A computer account was created.
646 A computer account was changed.
647 A computer account was deleted.
648 A local security group with security disabled was created.

Note: SECURITY_DISABLED in the formal name means that
this group cannot be used to grant permissions in access
checks.
649 A local security group with security disabled was changed.
650 A member was added to a security-disabled local security

group.
651 A member was removed from a security-disabled local security

group.
652 A security-disabled local group was deleted.
653 A security-disabled global group was created.
645 A security-disabled global group was changed.
655 A member was added to a security-disabled global group.
656 A member was removed from a security-disabled global

group.
657 A security-disabled global group was deleted.
658 A security-enabled universal group was created.
659 A security-enabled universal group was changed.

660 A member was added to a security-enabled universal group.
661 A member was removed from a security-enabled universal

group.
662 A security-enabled universal group was deleted.
663 A security-disabled universal group was created.
664 A security-disabled universal group was changed.
665 A member was added to a security-disabled universal group.
666 A member was removed from a security-disabled universal

group.
667 A security-disabled universal group was deleted.
668 A group type was changed.
684 Set the security descriptor of members of administrative

groups.
685 Set the security descriptor of members of administrative

groups.
Note: Every 60 minutes on a domain controller a background
thread searches all members of administrative groups (such as
domain, enterprise, and schema administrators) and applies a
fixed security descriptor on them. This event is logged.
Related topics
Applies to
Windows 10
Determines whether to audit the event of a user accessing an Active Directory object that has its own system access
control list (SACL) specified.
By default, this value is set to no auditing in the Default Domain Controller Group Policy object (GPO), and it
remains undefined for workstations and servers where it has no meaning.
type at all. Success audits generate an audit entry when a user successfully accesses an Active Directory object that
has a SACL specified. Failure audits generate an audit entry when a user unsuccessfully attempts to access an
Active Directory object that has a SACL specified. To set this value to No auditing, in the Properties dialog box for
this policy setting, select the Define these policy settings check box and clear the Success and Failure check
boxes.
Note: You can set a SACL on an Active Directory object by using the Security tab in that object's Properties
dialog box. This is the same as Audit object access, except that it applies only to Active Directory objects and not
to file system and registry objects.
Default:
Undefined for a member server.

You can configure this security setting under Computer Configuration\Windows Settings\Security Settings\Local
There is only one directory service access event, which is identical to the Object Access security event message 566.
DIRECTORY SERVICE ACCESS EVENTS DESCRIPTION
566 A generic object operation took place.
Related topics
Audit logon events
Applies to
Windows 10
Determines whether to audit each instance of a user logging on to or logging off from a device.
Account logon events are generated on domain controllers for domain account activity and on local devices for
local account activity. If both account logon and logon audit policy categories are enabled, logons that use a
domain account generate a logon or logoff event on the workstation or server, and they generate an account logon
event on the domain controller. Additionally, interactive logons to a member server or workstation that use a
domain account generate a logon event on the domain controller as the logon scripts and policies are retrieved
when a user logs on. For more info about account logon events, see Audit account logon events.
type at all. Success audits generate an audit entry when a logon attempt succeeds. Failure audits generate an audit
entry when a logon attempt fails.
To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these
policy settings check box and clear the Success and Failure check boxes.
For information about advanced security policy settings for logon events, see the Logon/logoff section in Advanced
security audit policy settings.

528 A user successfully logged on to a computer. For information

about the type of logon, see the Logon Types table below.
529 Logon failure. A logon attempt was made with an unknown

user name or a known user name with a bad password.
530 Logon failure. A logon attempt was made user account tried
to log on outside of the allowed time.
531 Logon failure. A logon attempt was made using a disabled

account.
532 Logon failure. A logon attempt was made using an expired

account.
533 Logon failure. A logon attempt was made by a user who is not
allowed to log on at this computer.
534 Logon failure. The user attempted to log on with a type that is
not allowed.
535 Logon failure. The password for the specified account has
expired.
536 Logon failure. The Net Logon service is not active.
537 Logon failure. The logon attempt failed for other reasons.
538 The logoff process was completed for a user.
539 Logon failure. The account was locked out at the time the
logon attempt was made.
540 A user successfully logged on to a network.
541 Main mode Internet Key Exchange (IKE) authentication was

completed between the local computer and the listed peer
identity (establishing a security association), or quick mode has
established a data channel.
542 A data channel was terminated.
543 Main mode was terminated.
544 Main mode authentication failed because the peer did not
provide a valid certificate or the signature was not validated.
545 Main mode authentication failed because of a Kerberos failure

or a password that is not valid.
546 IKE security association establishment failed because the peer

sent a proposal that is not valid. A packet was received that
contained data that is not valid.
547 A failure occurred during an IKE handshake.
548 Logon failure. The security ID (SID) from a trusted domain

does not match the account domain SID of the client.
549 Logon failure. All SIDs corresponding to untrusted

namespaces were filtered out during an authentication across
forests.
550 Notification message that could indicate a possible denial-of-

service attack.
551 A user initiated the logoff process.
552 A user successfully logged on to a computer using explicit

credentials while already logged on as a different user.
682 A user has reconnected to a disconnected terminal server

session.
683 A user disconnected a terminal server session without logging

off.
When event 528 is logged, a logon type is also listed in the event log. The following table describes each logon
type.
LOGON TYPE LOGON TITLE DESCRIPTION
2 Interactive A user logged on to this computer.
3 Network A user or computer logged on to this

computer from the network.
4 Batch Batch logon type is used by batch

servers, where processes may be
executing on behalf of a user without
their direct intervention.
5 Service A service was started by the Service

Control Manager.
7 Unlock This workstation was unlocked.
8 NetworkCleartext A user logged on to this computer from

the network. The user's password was
passed to the authentication package in
its unhashed form. The built-in
authentication packages all hash
credentials before sending them across
the network. The credentials do not
traverse the network in plaintext (also
called cleartext).
9 NewCredentials A caller cloned its current token and

specified new credentials for outbound
connections. The new logon session has
the same local identity, but uses
different credentials for other network
connections.
10 RemoteInteractive A user logged on to this computer

remotely using Terminal Services or
Remote Desktop.
11 CachedInteractive A user logged on to this computer with

network credentials that were stored
locally on the computer. The domain
controller was not contacted to verify
the credentials.
Related topics
Audit object access
Applies to
Windows 10
Determines whether to audit the event of a user accessing an object--for example, a file, folder, registry key,
printer, and so forth--that has its own system access control list (SACL) specified.
type at all. Success audits generate an audit entry when a user successfully accesses an object that has an
appropriate SACL specified. Failure audits generate an audit entry when a user unsuccessfully attempts to access
an object that has a SACL specified.
To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy
settings check box and clear the Success and Failure check boxes.
Note: You can set a SACL on a file system object using the Security tab in that object's Properties dialog box.
Default: No auditing.

OBJECT ACCESS EVENTS DESCRIPTION
560 Access was granted to an already existing object.
562 A handle to an object was closed.
563 An attempt was made to open an object with the intent to

delete it.
**Note: ** This is used by file systems when the
FILE_DELETE_ON_CLOSE flag is specified in Createfile().
564 A protected object was deleted.
565 Access was granted to an already existing object type.
567 A permission associated with a handle was used.

**Note: ** A handle is created with certain granted
permissions (Read, Write, and so on). When the handle is
used, up to one audit is generated for each of the permissions
that was used.
568 An attempt was made to create a hard link to a file that is

being audited.
569 The resource manager in Authorization Manager attempted

to create a client context.
570 A client attempted to access an object.

Note: An event will be generated for every attempted
operation on the object.
571 The client context was deleted by the Authorization Manager

application.
572 The administrator manager initialized the application.
772 The certificate manager denied a pending certificate request.
773 Certificate Services received a resubmitted certificate request.
774 Certificate Services revoked a certificate.
775 Certificate Services received a request to publish the certificate

revocation list (CRL).
776 Certificate Services published the certificate revocation list

(CRL).
777 A certificate request extension was made.
778 One or more certificate request attributes changed.
779 Certificate Services received a request to shutdown.
780 Certificate Services backup started.
781 Certificate Services backup completed
782 Certificate Services restore started.
783 Certificate Services restore completed.
784 Certificate Services started.
785 Certificate Services stopped.
786 The security permissions for Certificate Services changed.
787 Certificate Services retrieved an archived key.
788 Certificate Services imported a certificate into its database.
789 The audit filter for Certificate Services changed.
790 Certificate Services received a certificate request.

791 Certificate Services approved a certificate request and issued a

certificate.
792 Certificate Services denied a certificate request.
793 Certificate Services set the status of a certificate request to

pending.
794 The certificate manager settings for Certificate Services

changed.
795 A configuration entry changed in Certificate Services.
796 A property of Certificate Services changed.
797 Certificate Services archived a key.
798 Certificate Services imported and archived a key.
799 Certificate Services published the CA certificate to Active

Directory.
800 One or more rows have been deleted from the certificate
database.
801 Role separation enabled.
Related topics
Audit policy change
Applies to
Windows 10
Determines whether to audit every incident of a change to user rights assignment policies, audit policies, or trust
policies.
type at all. Success audits generate an audit entry when a change to user rights assignment policies, audit policies,
or trust policies is successful. Failure audits generate an audit entry when a change to user rights assignment
policies, audit policies, or trust policies fails.
Default:

POLICY CHANGE EVENTS DESCRIPTION
608 A user right was assigned.
609 A user right was removed.
610 A trust relationship with another domain was created.
611 A trust relationship with another domain was removed.
612 An audit policy was changed.
613 An Internet Protocol security (IPSec) policy agent started.
614 An IPSec policy agent was disabled.
615 An IPSec policy agent changed.
616 An IPSec policy agent encountered a potentially serious failure.
617 A Kerberos policy changed.
618 Encrypted Data Recovery policy changed.

620 A trust relationship with another domain was modified.
621 System access was granted to an account.
622 System access was removed from an account.
623 Per user auditing policy was set for a user.
625 Per user audit policy was refreshed.
768 A collision was detected between a namespace element in one

forest and a namespace element in another forest.
Note When a namespace element in one forest overlaps a
namespace element in another forest, it can lead to ambiguity
in resolving a name belonging to one of the namespace
elements. This overlap is also called a collision. Not all
parameters are valid for each entry type. For example, fields
such as DNS name, NetBIOS name, and SID are not valid for
an entry of type 'TopLevelName'.
769 Trusted forest information was added.

Note: This event message is generated when forest trust
information is updated and one or more entries are added.
One event message is generated per added, deleted, or
modified entry. If multiple entries are added, deleted, or
modified in a single update of the forest trust information, all
the generated event messages have a single unique identifier
called an operation ID. This allows you to determine that the
multiple generated event messages are the result of a single
operation. Not all parameters are valid for each entry type. For
example, parameters such as DNS name, NetBIOS name and
SID are not valid for an entry of type "TopLevelName".
770 Trusted forest information was deleted.

771 Trusted forest information was modified.

805 The event log service read the security log configuration for a
session.
Related topics
Audit privilege use
Applies to
Windows 10
Determines whether to audit each instance of a user exercising a user right.
If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit this type of
event at all. Success audits generate an audit entry when the exercise of a user right succeeds. Failure audits
generate an audit entry when the exercise of a user right fails.
Audits are not generated for use of the following user rights, even if success audits or failure audits are specified
for Audit privilege use. Enabling auditing of these user rights tend to generate many events in the security log
which may impede your computer's performance. To audit the following user rights, enable the
FullPrivilegeAuditing registry key.
Bypass traverse checking
Debug programs
Create a token object
Replace process level token
Generate security audits
Back up files and directories
Restore files and directories

PRIVILEGE USE EVENTS DESCRIPTION
576 Specified privileges were added to a user's access token.

Note: This event is generated when the user logs on.
577 A user attempted to perform a privileged system service

operation.
578 Privileges were used on an already open handle to a protected

object.
Related topics
Applies to
Windows 10
Determines whether to audit detailed tracking information for events such as program activation, process exit,
handle duplication, and indirect object access.
type at all. Success audits generate an audit entry when the process being tracked succeeds. Failure audits generate
an audit entry when the process being tracked fails.
Configure this this security setting

PROCESS TRACKING EVENTS DESCRIPTION
592 A new process was created.
593 A process exited.
594 A handle to an object was duplicated.
595 Indirect access to an object was obtained.
596 A data protection master key was backed up.

Note: The master key is used by the CryptProtectData and
CryptUnprotectData routines, and Encrypting File System
(EFS). The master key is backed up each time a new one is
created. (The default setting is 90 days.) The key is usually
backed up to a domain controller.
597 A data protection master key was recovered from a recovery

server.
598 Auditable data was protected.
599 Auditable data was unprotected.
600 A process was assigned a primary token.
601 A user attempted to install a service.

PROCESS TRACKING EVENTS DESCRIPTION
602 A scheduler job was created.
Related topics
Audit system events
Applies to
Windows 10
Determines whether to audit when a user restarts or shuts down the computer or when an event occurs that affects
either the system security or the security log.
type at all. Success audits generate an audit entry when a logon attempt succeeds. Failure audits generate an audit
entry when a logon attempt fails.
Default:

512 Windows is starting up.
513 Windows is shutting down.
514 An authentication package was loaded by the Local Security

Authority.
515 A trusted logon process has registered with the Local Security
Authority.
516 Internal resources allocated for the queuing of security event

messages have been exhausted, leading to the loss of some
security event messages.
517 The audit log was cleared.
518 A notification package was loaded by the Security Accounts

Manager.
519 A process is using an invalid local procedure call (LPC) port in

an attempt to impersonate a client and reply or read from or
write to a client address space.
520 The system time was changed.

Note: This audit normally appears twice.
Related topics
Advanced security audit policies
Applies to
Windows 10
Advanced security audit policy settings are found in Security Settings\Advanced Audit Policy
Configuration\System Audit Policies and appear to overlap with basic security audit policies, but they are
recorded and applied differently. When you apply basic audit policy settings to the local computer by using the
Local Security Policy snap-in, you are editing the effective audit policy, so changes made to basic audit policy
settings will appear exactly as configured in Auditpol.exe. In Windows 7 and later, advanced security audit policies
can be controlled by using Group Policy.
In this section
TOPIC DESCRIPTION
Planning and deploying advanced security audit policies This topic for the IT professional explains the options that
security policy planners must consider and the tasks they
must complete to deploy an effective security audit policy in a
network that includes advanced security audit policies
Advanced security auditing FAQ This topic for the IT professional lists questions and answers
about understanding, deploying, and managing security audit
policies.
Using advanced security auditing options to monitor dynamic This guide explains the process of setting up advanced
access control objects security auditing capabilities that are made possible through
settings and events that were introduced in Windows 8 and
Advanced security audit policy settings This reference for IT professionals provides information about
the advanced audit policy settings that are available in
Windows and the audit events that they generate.
Planning and deploying advanced security audit
policies
Applies to
Windows 10
This topic for the IT professional explains the options that security policy planners must consider and the tasks they
must complete to deploy an effective security audit policy in a network that includes advanced security audit
policies.
Organizations invest a large portion of their information technology budgets on security applications and services,
such as antimalware software, firewalls, and encryption. But no matter how much security hardware or software
you deploy, how tightly you control the rights of users, or how carefully you configure security permissions on
your data, you should not consider the job complete unless you have a well-defined, timely auditing strategy to
track the effectiveness of your defenses and identify attempts to circumvent them.
To be well defined and timely, an auditing strategy must provide useful tracking data for an organization's most
important resources, critical behaviors, and potential risks. In a growing number of organizations, it must also
provide absolute proof that IT operations comply with corporate and regulatory requirements.
Unfortunately, no organization has unlimited resources to monitor every resource and activity on a network. If you
do not plan well, you will likely have gaps in your auditing strategy. However, if you try to audit every resource and
activity, you may find yourself with far too much monitoring data, including thousands of benign audit entries that
an analyst needs to sift through to identify the narrow set of entries that warrant closer examination. This could
cause delays or even prevent auditors from identifying suspicious activity. Thus, too much monitoring can leave an
organization as vulnerable as not enough monitoring.
Here are some features that can help you focus your effort:
Advanced audit policy settings. You can apply and manage detailed audit policy settings through Group
Policy.
"Reason for access" auditing. You can specify and identify the permissions that were used to generate a
particular object access security event.
Global object access auditing. You can define system access control lists (SACLs) for an entire computer file
system or registry.
To deploy these features and plan an effective security auditing strategy, you need to:
Identify your most critical resources and the most important activities that need to be tracked.
Identify the audit settings that can be used to track these activities.
Assess the advantages and potential costs associated with each.
Test these settings to validate your choices.
Develop plans for deploying and managing your audit policy.
About this guide

This document will guide you through the steps needed to plan a security auditing policy that uses Windows
auditing features. This policy must identify and address vital business needs, including:
Network reliability
Regulatory requirements
Protection of the organization's data and intellectual property
Users, including employees, contractors, partners, and customers
Client computers and applications
Servers and the applications and services running on those servers
The audit policy also must identify processes for managing audit data after it has been logged, including:
Collecting, evaluating, and reviewing audit data
Storing and (if required) disposing of audit data
By carefully planning, designing, testing, and deploying a solution based on your organization's business
requirements, you can provide the standardized functionality, security, and management control that your
organization needs.
Understanding the security audit policy design process

The process of designing and deploying a Windows security audit policy involves the following tasks, which are
described in greater detail throughout this document:
Identifying your Windows security audit policy deployment goals
This section helps define the business objectives that will guide your Windows security audit policy. It also
helps you define the resources, users, and computers that will be the focus of your security auditing.
Mapping the security audit policy to groups of users, computers, and resources in your organization
This section explains how to integrate security audit policy settings with domain Group Policy settings for
different groups of users, computers, and resources. In addition, if your network includes multiple versions
of Windows client and server operating systems, it also explains when to use basic audit policy settings and
when to use advanced security audit policy settings.
Mapping your security auditing goals to a security audit policy configuration
This section explains the categories of Windows security auditing settings that are available. It also identifies
individual Windows security auditing policy settings that can be of particular value to address auditing
scenarios.
Planning for security audit monitoring and management
This section helps you plan to collect, analyze, and store Windows audit data. Depending on the number of
computers and types of activity that you want to audit, Windows event logs can fill up quickly. In addition,
this section explains how auditors can access and aggregate event data from multiple servers and desktop
computers. It also explains how to address storage requirements, including how much audit data to store
and how it must be stored.
Deploying the security audit policy
This section provides recommendations and guidelines for the effective deployment of a Windows security
audit policy. Configuring and deploying Windows audit policy settings in a test lab environment can help
you confirm that the settings you have selected will produce the type of audit data you need. However, only
a carefully staged pilot and incremental deployments based on your domain and organizational unit (OU)
structure will enable you to confirm that the audit data you generate can be monitored and that it meets
your organization's audit needs.
Identifying your Windows security audit policy deployment goals
A security audit policy must support and be a critical and integrated aspect of an organization's overall security
design and framework.
Every organization has a unique set of data and network assets (such as customer and financial data and trade
secrets), physical resources (such as desktop computers, portable computers, and servers), and users (which can
include various internal groups such as finance and marketing, and external groups such as partners, customers,
and anonymous users on the website). Not all of these assets, resources, and users justify the cost of an audit. Your
task is to identify which assets, resources, and users provide the strongest justification for the focus of a security
audit.
To create your Windows security audit plan, begin by identifying:
The overall network environment, including the domains, OUs, and security groups.
The resources on the network, the users of those resources, and how those resources are being used.
Regulatory requirements.
Network environment
An organization's domain and OU structure provide a fundamental starting point for thinking about how to apply a
security audit policy because it likely provides a foundation of Group Policy Objects (GPOs) and logical grouping of
resources and activities that you can use to apply the audit settings that you choose. It is also likely that certain
portions of your domain and OU structure already provide logical groups of users, resources, and activities that
justify the time and resources needed to audit them. For information about how to integrate a security audit policy
with your domain and OU structure, see Mapping security audit policy to groups of users, computers, and
resources in your organization later in this document.
In addition to your domain model, you should also find out whether your organization creates and maintains a
systematic threat model. A good threat model can help you identify threats to key components in your
infrastructure, so you can define and apply audit settings that enhance the organization's ability to identify and
counter those threats.
Important: Including auditing within your organization's security plan also makes it possible to budget your
resources on the areas where auditing can achieve the most positive results.
For additional details about how to complete each of these steps and how to prepare a detailed threat model,
download the IT Infrastructure Threat Modeling Guide.
Data and resources
For data and resource auditing, you need to identify the most important types of data and resources (such as
patient records, accounting data, or marketing plans) that can benefit from the closer monitoring that Windows
auditing can provide. Some of these data resources might already be monitored through auditing features in
products such as Microsoft SQL Server and Exchange Server. If so, you may want to consider how Windows
auditing features can enhance the existing audit strategy. As with the domain and OU structure discussed
previously, security auditing should focus on your most critical resources. You also must consider how much audit
data you will be able to manage.
You can record if these resources have high business impact, medium business impact, or low business impact, the
cost to the organization if these data resources are accessed by unauthorized users, and the risk that this access can
pose to the organization. The type of access by users (such as Read, Modify, or Copy) can also pose different levels
of risk to an organization.
Increasingly, data access and use is governed by regulations, and a breach can result in severe penalties and a loss
in credibility for the organization. If regulatory compliance plays a role in how you manage your data, be sure to
also document this information.
The following table provides an example of a resource analysis for an organization.
SECURITY OR
ORGANIZATIONAL REGULATORY
RESOURCE CLASS WHERE STORED UNIT BUSINESS IMPACT REQUIREMENTS
Payroll data Corp-Finance-1 Accounting: High Financial integrity and

Read/Write on Corp- employee privacy
Finance-1
Departmental Payroll
Managers: Write only
on Corp-Finance-1
Patient medical MedRec-2 Doctors and Nurses: High Strict legal and
records Read/Write on regulatory standards
Med/Rec-2
Lab Assistants: Write
only on MedRec-2
Accounting: Read only
on MedRec-2
Consumer health Web-Ext-1 Public Relations Web Low Public education and
information Content Creators: corporate image
Read/Write on Web-
Ext-1
Public: Read only on
Web-Ext-1
Users
Many organizations find it useful to classify the types of users they have and base permissions on this
classification. This same classification can help you identify which user activities should be the subject of security
auditing and the amount of audit data they will generate.
Organizations can create distinctions based on the type of rights and permissions needed by users to perform their
jobs. For example, under the classification Administrators, larger organizations might assign local administrator
responsibilities for a single computer, for specific applications such as Exchange Server or SQL Server, or for an
entire domain. Under Users, permissions and Group Policy settings can apply to as many as all users in an
organization or as few as a subset of the employees in a given department.
Also, if your organization is subject to regulatory requirements, user activities such as accessing medical records or
financial data may need to be audited to verify that you are complying with these requirements.
To effectively audit user activity, begin by listing the different types of users in your organization and the types of
data they need access toin addition to the data they should not have access to.
Also, if external users can access any of your organization's data, be sure to identify them, including if they belong
to a business partner, customer, or general user, the data they have access to, and the permissions they have to
access that data.
The following table illustrates an analysis of users on a network. Although our example contains a single column
titled "Possible auditing considerations," you may want to create additional columns to differentiate between
different types of network activity, such as logon hours and permission use.
GROUPS DATA POSSIBLE AUDITING CONSIDERATIONS

GROUPS DATA POSSIBLE AUDITING CONSIDERATIONS
Account administrators User accounts and security groups Account administrators have full
privileges to create new user accounts,
reset passwords, and modify security
group memberships. We need a
mechanism to monitor these changes.
Members of the Finance OU Financial records Users in Finance have Read/Write access
to critical financial records, but no ability
to change permissions on these
resources. These financial records are
subject to government regulatory
compliance requirements.
External partners Project Z Employees of partner organizations

have Read/Write access to certain
project data and servers relating to
Project Z, but not to other servers or
data on the network.
Computers
Security and auditing requirements and audit event volume can vary considerably for different types of computers
in an organization. These requirements can be based on:
If the computers are servers, desktop computers, or portable computers.
The important applications the computers run, such as Exchange Server, SQL Server, or Forefront Identity
Manager.
Note: If the server applications (including Exchange Server and SQL Server) have audit settings. For
more information about auditing in Exchange Server, see the Exchange 2010 Security Guide. For more
information about auditing in SQL Server 2008, see Auditing (Database Engine). For SQL Server 2012,
see SQL Server Audit (Database Engine).
The operating system versions.
Note: The operating system version determines which auditing options are available and the volume of
audit event data.
The business value of the data.

For example, a web server that is accessed by external users requires different audit settings than a root
certification authority (CA) that is never exposed to the public Internet or even to regular users on the
organization's network.
The following table illustrates an analysis of computers in an organization.
TYPE OF COMPUTER AND APPLICATIONS OPERATING SYSTEM VERSION WHERE LOCATED
Servers hosting Exchange Server Windows Server 2008 R2 ExchangeSrv OU
File servers Windows Server 2012 Separate resource OUs by department

and (in some cases) by location
TYPE OF COMPUTER AND APPLICATIONS OPERATING SYSTEM VERSION WHERE LOCATED
Portable computers Windows Vista and Windows 7 Separate portable computer OUs by
department and (in some cases) by
location
Web servers Windows Server 2008 R2 WebSrv OU
Regulatory requirements
Many industries and locales have strict and specific requirements for network operations and how resources are
protected. In the health care and financial industries, for example, there are strict guidelines for who has access to
records and how they are used. Many countries have strict privacy rules. To identify regulatory requirements, work
with your organization's legal department and other departments responsible for these requirements. Then
consider the security configuration and auditing options that can be used to comply with and verify compliance
with these regulations.
For more info, see the System Center Process Pack for IT GRC.
Mapping the security audit policy to groups of users, computers, and

resources in your organization
By using Group Policy, you can apply your security audit policy to defined groups of users, computers, and
resources. To map a security auditing policy to these defined groups in your organization, you should understand
the following considerations for using Group Policy to apply security audit policy settings:
The policy settings you identify can be applied by using one or more GPOs. To create and edit a GPO, use the
Group Policy Management Console (GPMC). By using the GPMC to link a GPO to selected Active Directory sites,
domains, and OUs, you apply the policy settings in the GPO to the users and computers in those Active
Directory objects. An OU is the lowest-level Active Directory container to which you can assign Group Policy
settings.
For every policy setting that you select, you need to decide whether it should be enforced across the
organization, or whether it should apply only to selected users or computers. You can then combine these audit
policy settings into GPOs and link them to the appropriate Active Directory containers.
By default, options set in GPOs that are linked to higher levels of Active Directory sites, domains, and OUs
are inherited by all OUs at lower levels. However, a GPO that is linked at a lower level can overwrite
inherited policies.
For example, you might use a domain GPO to assign an organization-wide group of audit settings, but want
a certain OU to get a defined group of additional settings. To accomplish this, you can link a second GPO to
that specific lower-level OU. Therefore, a logon audit setting that is applied at the OU level will override a
conflicting logon audit setting that is applied at the domain level (unless you have taken special steps to
apply Group Policy loopback processing).
Audit policies are computer policies. Therefore, they must be applied through GPOs that are applied to
computer OUs, not to user OUs. However, in most cases you can apply audit settings for only specified
resources and groups of users by configuring SACLs on the relevant objects. This enables auditing for a
security group that contains only the users you specify.
For example, you could configure a SACL for a folder called Payroll Data on Accounting Server 1. This can
audit attempts by members of the Payroll Processors OU to delete objects from this folder. The Object
Access\Audit File System audit policy setting applies to Accounting Server 1, but because it requires a
corresponding resource SACL, only actions by members of the Payroll Processors OU on the Payroll Data
folder generates audit events.
Advanced security audit policy settings were introduced in Windows Server 2008 R2 or Windows 7 and can
be applied to those operating systems and later. These advanced audit polices can only be applied by using
Group Policy.
Important: Whether you apply advanced audit policies by using Group Policy or by using logon scripts,
do not use both the basic audit policy settings under Local Policies\Audit Policy and the advanced
settings under Security Settings\Advanced Audit Policy Configuration. Using both basic and
advanced audit policy settings can cause unexpected results in audit reporting.
If you use Advanced Audit Policy Configuration settings or use logon scripts to apply advanced audit
policies, be sure to 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.
The following are examples of how audit policies can be applied to an organization's OU structure:
Apply data activity settings to an OU that contains file servers. If your organization has servers that contain
particularly sensitive data, consider putting them in a separate OU so that you can configure and apply a more
precise audit policy to these servers.
Apply user activity audit policies to an OU that contains all computers in the organization. If your organization
places users in OUs based on the department they work in, consider configuring and applying more detailed
security permissions on critical resources that are accessed by employees who work in more sensitive areas,
such as network administrators or the legal department.
Apply network and system activity audit policies to OUs that contain the organization's most critical servers,
such as domain controllers, CAs, email servers, or database servers.
Mapping your security auditing goals to a security audit policy

configuration
After you identify your security auditing goals, you can begin to map them to a security audit policy configuration.
This audit policy configuration must address your most critical security auditing goals, but it also must address
your organization's constraints, such as the number of computers that need to be monitored, the number of
activities that you want to audit, the number of audit events that your desired audit configuration will generate, and
the number of administrators available to analyze and act upon audit data.
To create your audit policy configuration, you need to:
1. Explore all of the audit policy settings that can be used to address your needs.
2. Choose the audit settings that will most effectively address the audit requirements identified in the previous
section.
3. Confirm that the settings you choose are compatible with the operating systems running on the computers that
you want to monitor.
4. Decide which configuration options (Success, Failure, or both Success and Failure) you want to use for the audit
settings.
5. Deploy the audit settings in a lab or test environment to verify that they meet your desired results in terms of
volume, supportability, and comprehensiveness. Then deploy the audit settings in a pilot production
environment to ensure that your estimates of how much audit data your audit plan will generate are realistic
and that you can manage this data.
Exploring audit policy options
Security audit policy settings in the supported versions of Windows can be viewed and configured in the following
locations:
Security Settings\Local Policies\Audit Policy.
Security Settings\Local Policies\Security Options.
Security Settings\Advanced Audit Policy Configuration. For more information, see Advanced security
audit policy settings.
Choosing audit settings to use
Depending on your goals, different sets of audit settings may be of particular value to you. For example, some
settings under Security Settings\Advanced Audit Policy Configuration can be used to monitor the following
types of activity:
Data and resources
Users
Network
Important: Settings that are described in the Reference might also provide valuable information about activity
audited by another setting. For example, the settings used to monitor user activity and network activity have
obvious relevance to protecting your data resources. Likewise, attempts to compromise data resources have
huge implications for overall network status, and potentially for how well you are managing the activities of
users on the network.
Data and resource activity

For many organizations, compromising the organization's data resources can cause tremendous financial losses, in
addition to lost prestige and legal liability. If your organization has critical data resources that need to be protected
against any breach, the following settings can provide extremely valuable monitoring and forensic data:
Object Access\Audit File Share. This policy setting allows you to track what content was accessed, the source (IP
address and port) of the request, and the user account that was used for the access. The volume of event data
generated by this setting will vary depending on the number of client computers that attempt to access the file
share. On a file server or domain controller, volume may be high due to SYSVOL access by client computers for
policy processing. If you do not need to record routine access by client computers that have permissions on the
file share, you may want to log audit events only for failed attempts to access the file share.
Object Access\Audit File System. This policy setting determines whether the operating system audits user
attempts to access file system objects. Audit events are only generated for objects (such as files and folders)
that have configured SACLs, and only if the type of access requested (such as Write, Read, or Modify) and
the account that is making the request match the settings in the SACL.
If success auditing is enabled, an audit entry is generated each time any account successfully accesses a file
system object that has a matching SACL. If failure auditing is enabled, an audit entry is generated each time
any user unsuccessfully attempts to access a file system object that has a matching SACL. The amount of
audit data generated by the Audit File System policy setting can vary considerably, depending on the
number of objects that have been configured to be monitored.
Note: To audit user attempts to access all file system objects on a computer, use the Global Object
Access Auditing settings Registry (Global Object Access Auditing) or File System (Global Object Access
Auditing).
Object Access\Audit Handle Manipulation. This policy setting determines whether the operating system
generates audit events when a handle to an object is opened or closed. Only objects with configured SACLs
generate these events, and only if the attempted handle operation matches the SACL.
Event volume can be high, depending on how SACLs are configured. When used together with the Audit
File System or Audit Registry policy settings, the Audit Handle Manipulation policy setting can provide
an administrator with useful "reason for access" audit data that details the precise permissions on which the
audit event is based. For example, if a file is configured as a Read-only resource but a user attempts to save
changes to the file, the audit event will log not only the event, but also the permissions that were used (or
attempted to be used) to save the file changes.
Global Object Access Auditing. A growing number of organizations are using security auditing to comply
with regulatory requirements that govern data security and privacy. But demonstrating that strict controls
are being enforced can be extremely difficult. To address this issue, the supported versions of Windows
include two Global Object Access Auditing policy settings, one for the registry and one for the file system.
When you configure these settings, they apply a global system access control SACL on all objects of that
class on a system, which cannot be overridden or circumvented.
Important: The Global Object Access Auditing policy settings must be configured and applied in
conjunction with the Audit File System and Audit Registry audit policy settings in the Object Access
category.
User activity
The settings in the previous section relate to activity involving the files, folders, and network shares that are stored
on a network, and the settings in this section focus on the users, including employees, partners, and customers,
who may try to access those resources.
In the majority of cases, these attempts will be legitimate and a network needs to make vital data readily available
to legitimate users. However in other cases, employees, partners, and others may attempt to access resources that
they have no legitimate reason to access. Security auditing can be used to track a wide variety of user activities on a
particular computer to diagnose and resolve problems for legitimate users and identify and address illegitimate
activities. The following are a few important settings that you should evaluate to track user activity on your
network:
Account Logon\Audit Credential Validation. This is an extremely important policy setting because it enables you
to track every successful and unsuccessful attempt to present credentials for a user logon. In particular, a
pattern of unsuccessful attempts may indicate that a user or application is using credentials that are no longer
valid, or attempting to use a variety of credentials in succession in hope that one of these attempts will
eventually be successful. These events occur on the computer that is authoritative for the credentials. For
domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative.
Detailed Tracking\Audit Process Creation and Detailed Tracking\Audit Process Termination. These policy
settings can enable you to monitor the applications that a user opens and closes on a computer.
DS Access\Audit Directory Service Access and DS Access\Audit Directory Service Changes. These policy settings
provide a detailed audit trail of attempts to access create, modify, delete, move, or undelete objects in Active
Directory Domain Services (AD DS). Only domain administrators have permissions to modify AD DS objects, so
it is extremely important to identify malicious attempts to modify these objects. In addition, although domain
administrators should be among an organization's most trusted employees, the use of Audit Directory
Service Access and Audit Directory Service Changes settings allow you to monitor and verify that only
approved changes are made to AD DS. These audit events are logged only on domain controllers.
Logon/Logoff\Audit Account Lockout. Another common security scenario occurs when a user attempts to log
on with an account that has been locked out. It is important to identify these events and to determine whether
the attempt to use an account that has been locked out is malicious.
Logon/Logoff\Audit Logoff and Logon/Logoff\Audit Logon. Logon and logoff events are essential to
tracking user activity and detecting potential attacks. Logon events are related to the creation of logon
sessions, and they occur on the computer that was accessed. For an interactive logon, events are generated
on the computer that was logged on to. For network logon, such as accessing a shared resource, events are
generated on the computer that hosts the resource that was accessed. Logoff events are generated when
logon sessions are terminated.
Note: There is no failure event for logoff activity because failed logoffs (such as when a system abruptly
shuts down) do not generate an audit record. Logoff events are not 100 percent reliable. For example,
the computer can be turned off without a proper logoff and shutdown, and a logoff event is not
generated.
Logon/Logoff\Audit Special Logon. A special logon has administrator-equivalent rights and can be used to
elevate a process to a higher level. It is recommended to track these types of logons. For more information
about this feature, see article 947223 in the Microsoft Knowledge Base.
Object Access\Audit Certification Services. This policy setting allows you to track and monitor a wide variety of
activities on a computer that hosts Active Directory Certificate Services (AD CS) role services to ensure that only
authorized users are performing or attempting to perform these tasks, and that only authorized or desired tasks
are being performed.
Object Access\Audit File System and Object Access\Audit File Share. These policy settings are described in the
previous section.
Object Access\Audit Handle Manipulation. This policy setting and its role in providing "reason for access" audit
data is described in the previous section.
Object Access\Audit Registry. Monitoring for changes to the registry is one of the most critical means that
an administrator has to ensure malicious users do not make changes to essential computer settings. Audit
events are only generated for objects that have configured SACLs, and only if the type of access that is
requested (such as Write, Read, or Modify) and the account making the request match the settings in the
SACL.
Important: On critical systems where all attempts to change registry settings need to be tracked, you
can combine the Audit Registry policy setting with the Global Object Access Auditing policy settings
to ensure that all attempts to modify registry settings on a computer are tracked.
Object Access\Audit SAM. The Security Accounts Manager (SAM) is a database that is present on computers
running Windows that stores user accounts and security descriptors for users on the local computer.
Changes to user and group objects are tracked by the Account Management audit category. However,
user accounts with the proper user rights could potentially alter the files where the account and password
information is stored in the system, bypassing any Account Management events.
Privilege Use\Audit Sensitive Privilege Use. Privilege Use policy settings and audit events allow you to track
the use of certain rights on one or more systems. If you configure this policy setting, an audit event is generated
when sensitive rights requests are made.
Network activity
The following network activity policy settings allow you to monitor security-related issues that are not necessarily
covered in the data or user activity categories, but that can be equally important for network status and protection.
Account Management. The policy settings in this category can be used to track attempts to create, delete, or
modify user or computer accounts, security groups, or distribution groups. Monitoring these activities
complements the monitoring strategies you select in the user activity and data activity sections.
Account Logon\Audit Kerberos Authentication Service and Account Logon\Audit Kerberos Service Ticket
Operations. Audit policy settings in the Account Logon category monitor activities that relate to the use of
domain account credentials. These policy settings complement the policy settings in the Logon/Logoff
category. The Audit Kerberos Authentication Service policy setting allows you to monitor the status of
and potential threats to the Kerberos service. The Audit Kerberos Service Ticket Operations policy setting
allows you to monitor the use of Kerberos service tickets.
Note: Account Logon policy settings apply only to specific domain account activities, regardless of the
computer that is accessed, whereas Logon/Logoff policy settings apply to the computer that hosts the
resources being accessed.
Account Logon\Audit Other Account Logon Events. This policy setting can be used to track a number of
different network activities, including attempts to create Remote Desktop connections, wired network
connections, and wireless connections.
DS Access. Policy settings in this category allow you to monitor the AD DS role services, which provide account
data, validate logons, maintain network access permissions, and provide other services that are critical to the
secure and proper functioning of a network. Therefore, auditing the rights to access and modify the
configuration of a domain controller can help an organization maintain a secure and reliable network. In
addition, one of the key tasks performed by AD DS is the replication of data between domain controllers.
Logon/Logoff\Audit IPsec Extended Mode, Logon/Logoff\Audit IPsec Main Mode, and Logon/Logoff\Audit IPsec
Quick Mode. Many networks support large numbers of external users, including remote employees and
partners. Because these users are outside the organization's network boundaries, IPsec is often used to help
protect communications over the Internet by enabling network-level peer authentication, data origin
authentication, data integrity, data confidentiality (encryption), and protection against replay attacks. You can
use these settings to ensure that IPsec services are functioning properly.
Logon/Logoff\Audit Network Policy Server. Organizations that use RADIUS (IAS) and Network Access
Protection (NAP) to set and maintain security requirements for external users can use this policy setting to
monitor the effectiveness of these policies and to determine whether anyone is attempting to circumvent these
protections.
Policy Change. These policy settings and events allow you to track changes to important security policies on a
local computer or network. Because policies are typically established by administrators to help secure network
resources, any changes or attempts to change these policies can be an important aspect of security
management for a network.
Policy Change\Audit Audit Policy Change. This policy setting allows you to monitor changes to the audit policy.
If malicious users obtain domain administrator credentials, they can temporarily disable essential security audit
policy settings so that their other activities on the network cannot be detected.
Policy Change\Audit Filtering Platform Policy Change. This policy setting can be used to monitor a large variety
of changes to an organization's IPsec policies.
Policy Change\Audit MPSSVC Rule-Level Policy Change. This policy setting determines if the operating system
generates audit events when changes are made to policy rules for the Microsoft Protection Service
(MPSSVC.exe), which is used by Windows Firewall. Changes to firewall rules are important for understanding
the security state of the computer and how well it is protected against network attacks.
Confirm operating system version compatibility
Not all versions of Windows support advanced audit policy settings or the use of Group Policy to apply and
manage these settings. For more info, see Which editions of Windows support advanced audit policy configuration.
The audit policy settings under Local Policies\Audit Policy overlap with audit policy settings under Security
Settings\Advanced Audit Policy Configuration. However, the advanced audit policy categories and
subcategories make it possible to focus your auditing efforts on the most critical activities while reducing the
amount of audit data that is less important to your organization.
For example, Local Policies\Audit Policy contains a single setting called Audit account logon events. When this
setting is configured, it generates at least 10 types of audit events.
In comparison, the Account Logon category under Security Settings\Advanced Audit Policy Configuration
provides the following advanced settings, which allow you to focus your auditing:
Credential Validation
Kerberos Authentication Service
Kerberos Service Ticket Operations
Other Account Logon Events
These settings allow you to exercise much tighter control over which activities or events generate event data. Some
activities and events will be more important to your organization, so define the scope of your security audit policy
as narrowly as possible.
Success, failure, or both
Whichever event settings you include in your plan, you also have to decide whether you want to log an event when
the activity fails, when an activity succeeds, or both successes and failures. This is an important question, and the
answer will be based on the criticality of the event and the implications of the decision on event volume.
For example, on a file server that is accessed frequently by legitimate users, you may be interested in logging an
event only when an unsuccessful attempt to access data takes place, because this could be evidence of an
unauthorized or malicious user. And in this instance, logging successful attempts to access the server would quickly
fill the event log with benign events.
On the other hand, if the file share has extremely sensitive and valuable information, such as trade secrets, you may
want to log every access attempt, whether successful or unsuccessful, so that you have an audit trail of every user
who accessed the resource.
Planning for security audit monitoring and management

Networks can contain hundreds of servers running critical services or storing critical data, all of which need to be
monitored. The number of client computers on the network can easily range into the tens or even hundreds of
thousands. This may not be an issue if the ratio of servers or client computers per administrator is low. Even if an
administrator who is responsible for auditing security and performance issues has relatively few computers to
monitor, you need to decide how an administrator will obtain event data to review. Following are some options for
obtaining the event data.
Will you keep event data on a local computer until an administrator logs on to review this data? If so, then the
administrator needs to have physical or remote access to the Event Viewer on each client computer or server,
and the remote access and firewall settings on each client computer or server need to be configured to enable
this access. In addition, you need to decide how often an administrator can visit each computer, and adjust the
size of the audit log so that critical information is not deleted if the log reaches its maximum capacity.
Will you collect event data so that it can be reviewed from a central console? If so, there are a number of
computer management products, such as the Audit Collection Services in Operations Manager 2007 and 2012,
which can be used to collect and filter event data. Presumably this solution enables a single administrator to
review larger amounts of data than using the local storage option. But in some cases, this can make it more
difficult to detect clusters of related events that can occur on a single computer.
In addition, whether you choose to leave audit data on an individual computer or consolidate it at a central location,
you need to decide how large the log file should be and what should happen when the log reaches its maximum
size. To configure these options, open Event Viewer, expand Windows Logs, right-click Security, and click
Properties. You can configure the following properties:
Overwrite events as needed (oldest events first). This is the default option, which is an acceptable solution
in most situations.
Archive the log when full, do not overwrite events. This option can be used when all log data needs to be
saved, but it also suggests that you may not be reviewing audit data frequently enough.
Do not overwrite events (Clear logs manually). This option stops the collection of audit data when the log
file reaches its maximum size. Older data is retained at the expense of the most recent audit events. Use this
option only if you do not want to lose any audit data, do not want to create an archive of the event log, and are
committed to reviewing data before the maximum log size is reached.
You can also configure the audit log size and other key management options by using Group Policy settings. You
can configure the event log settings in the following locations within the GPMC: Computer
Configuration\Administrative Templates\Windows Components\Event Log Service\Security. These
options include:
Maximum Log Size (KB). This policy setting specifies the maximum size of the log files. The user interfaces
in the Local Group Policy Editor and Event Viewer allow you to enter values as large as 2 TB. If this setting is
not configured, event logs have a default maximum size of 20 megabytes.
Log Access. This policy setting determines which user accounts have access to log files and what usage
rights are granted.
Retain old events. This policy setting controls event log behavior when the log file reaches its maximum size.
When this policy setting is enabled and a log file reaches its maximum size, new events are not written to the
log and are lost. When this policy setting is disabled and a log file reaches its maximum size, new events
overwrite old events.
Backup log automatically when full. This policy setting controls event log behavior when the log file reaches
its maximum size and takes effect only if the Retain old events policy setting is enabled. If you enable these
policy settings, the event log file is automatically closed and renamed when it is full. A new file is then started. If
you disable or do not configure this policy setting and the Retain old events policy setting is enabled, new
events are discarded and the old events are retained.
In addition, a growing number of organizations are being required to store archived log files for a number of years.
You should consult with regulatory compliance officers in your organization to determine whether such guidelines
apply to your organization. For more information, see the IT Compliance Management Guide.
Deploying the security audit policy

Before deploying the audit policy in a production environment, it is critical that you determine the effects of the
policy settings that you have configured. The first step in assessing your audit policy deployment is to create a test
environment in a lab and use it to simulate the various use scenarios that you have identified to confirm that the
audit settings you have selected are configured correctly and generate the type of results you intend.
However, unless you are able to run fairly realistic simulations of network usage patterns, a lab setup cannot
provide you with accurate information about the volume of audit data that the audit policy settings you selected
will generate and how effective your plan for monitoring audit data will be. To provide this type of information, you
need to conduct one or more pilot deployments. These pilot deployments could involve:
A single OU that contains critical data servers or an OU that contains all desktop computers in a specified
location.
A limited set of security audit policy settings, such as Logon/Logoff and Account Logon.
A combination of limited OUs and audit policy settingsfor example, targeting servers in only the Accounting
OU with Object Access policy settings.
After you have successfully completed one or more limited deployments, you should confirm that the audit data
that is collected is manageable with your management tools and administrators. When you have confirmed that
the pilot deployment is effective, you need to confirm that you have the necessary tools and staff to expand the
deployment to include additional OUs and sets of audit policy settings until the production deployment is
complete.
Advanced security auditing FAQ
Applies to
Windows 10
This topic for the IT professional lists questions and answers about understanding, deploying, and managing
security audit policies.
What is Windows security auditing and why might I want to use it?
What is the difference between audit policies located in Local Policies\Audit Policy and audit policies located in
Advanced Audit Policy Configuration?
What is the interaction between basic audit policy settings and advanced audit policy settings?
How are audit settings merged by Group Policy?
What is the difference between an object DACL and an object SACL?
Why are audit policies applied on a per-computer basis rather than per user?
What are the differences in auditing functionality between versions of Windows?
Can I use advanced audit policy from a domain controller running Windows Server 2003 or Windows 2000
Server?
What is the difference between success and failure events? Is something wrong if I get a failure audit?
How can I set an audit policy that affects all objects on a computer?
How do I figure out why someone was able to access a resource?
How do I know when changes are made to access control settings, by whom, and what the changes were?
How can I roll back security audit policies from the advanced audit policy to the basic audit policy?
How can I monitor if changes are made to audit policy settings?
How can I minimize the number of events that are generated?
What are the best tools to model and manage audit policy?
Where can I find information about all the possible events that I might receive?
Where can I find more detailed information?
What is Windows security auditing and why might I want to use it?
Security auditing is a methodical examination and review of activities that may affect the security of a system. In the
Windows operating systems, security auditing is more narrowly defined as the features and services that enable an
administrator to log and review events for specified security-related activities.
Hundreds of events occur as the Windows operating system and the applications that run on it perform their tasks.
Monitoring these events can provide valuable information to help administrators troubleshoot and investigate
security-related activities.
What is the difference between audit policies located in Local

Policies\Audit Policy and audit policies located in Advanced Audit Policy
Configuration?
The basic security audit policy settings in Security Settings\Local Policies\Audit Policy and the advanced
security audit policy settings in Security Settings\Advanced Audit Policy Configuration\System Audit
Policies appear to overlap, but they are recorded and applied differently. When you apply basic audit policy
settings to the local computer by using the Local Security Policy snap-in (secpol.msc), you are editing the effective
audit policy, so changes made to basic audit policy settings will appear exactly as configured in Auditpol.exe.
There are a number of additional differences between the security audit policy settings in these two locations.
There are nine basic audit policy settings under Security Settings\Local Policies\Audit Policy and settings
under Advanced Audit Policy Configuration. The settings available in Security Settings\Advanced Audit
Policy Configuration address similar issues as the nine basic settings in Local Policies\Audit Policy, but they
allow administrators to be more selective in the number and types of events to audit. For example, the basic audit
policy provides a single setting for account logon, and the advanced audit policy provides four. Enabling the single
basic account logon setting would be 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 that you are
not interested in tracking.
In addition, if you enable success auditing for the basic Audit account logon events setting, only success events
will be logged for all account logonrelated behaviors. In comparison, depending on the needs of your
organization, 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.
The nine basic settings under Security Settings\Local Policies\Audit Policy were introduced in Windows 2000.
Therefore, they are available in all versions of Windows released since then. The advanced audit policy settings
were introduced in Windows Vista and Windows Server 2008. The advanced settings can only be used on
computers running Windows 7, Windows Server 2008, and later.
What is the interaction between basic audit policy settings and

advanced audit policy settings?
Basic audit policy settings are not compatible with advanced audit policy settings that are applied by using Group
Policy. When advanced audit policy settings are applied by using Group Policy, the current computer's audit policy
settings are cleared before the resulting advanced audit policy settings are applied. After you apply advanced audit
policy settings by using Group Policy, you can only reliably set system audit policy for the computer by using the
advanced audit policy settings.
Editing and applying the advanced audit policy settings in Local Security Policy modifies the local Group Policy
Object (GPO), so changes made here may not be exactly reflected in Auditpol.exe if there are policies from other
domain GPOs or logon scripts. Both types of policies can be edited and applied by using domain GPOs, and these
settings will override any conflicting local audit policy settings. However, because the basic audit policy is recorded
in the effective audit policy, that audit policy must be explicitly removed when a change is desired, or it will remain
in the effective audit policy. Policy changes that are applied by using local or domain Group Policy settings are
reflected as soon as the new policy is applied.
Important Whether you apply advanced audit policies by using Group Policy or by using logon scripts, do not
use both the basic audit policy settings under Local Policies\Audit Policy and the advanced settings under
Security Settings\Advanced Audit Policy Configuration. Using both advanced and basic audit policy
settings can cause unexpected results in audit reporting.
If you use Advanced Audit Policy Configuration settings or use logon scripts to apply advanced audit policies, be
sure to 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.
How are audit settings merged by Group Policy?

By default, policy options that are set in GPOs and linked to higher levels of Active Directory sites, domains, and
OUs are inherited by all OUs at lower levels. However, an inherited policy can be overridden by a GPO that is linked
at a lower level.
For example, you might use a domain GPO to assign an organization-wide group of audit settings, but want a
certain OU to get a defined group of additional settings. To accomplish this, you can link a second GPO to that
specific lower-level OU. Therefore, a logon audit setting that is applied at the OU level will override a conflicting
logon audit setting that is applied at the domain level (unless you have taken special steps to apply Group Policy
loopback processing).
The rules that govern how Group Policy settings are applied propagate to the subcategory level of audit policy
settings. This means that audit policy settings configured in different GPOs will be merged if no policy settings
configured at a lower level exist. The following table illustrates this behavior.
SETTING CONFIGURED IN A
SETTING CONFIGURED IN AN DOMAIN GPO (LOWER RESULTING POLICY FOR THE
AUDITING SUBCATEGORY OU GPO (HIGHER PRIORITY) PRIORITY) TARGET COMPUTER
Detailed File Share Auditing Success Failure Success
Process Creation Auditing Disabled Success Disabled
Logon Auditing Success Failure Failure
What is the difference between an object DACL and an object SACL?

All objects in Active Directory Domain Services (AD DS), and all securable objects on a local computer or on the
network, have security descriptors to help control access to the objects. Security descriptors include information
about who owns an object, who can access it and in what way, and what types of access are audited. Security
descriptors contain the access control list (ACL) of an object, which includes all of the security permissions that
apply to that object. An object's security descriptor can contain two types of ACLs:
A discretionary access control list (DACL) that identifies the users and groups who are allowed or denied access
A system access control list (SACL) that controls how access is audited
The access control model that is used in Windows is administered at the object level by setting different levels of
access, or permissions, to objects. If permissions are configured for an object, its security descriptor contains a
DACL with security identifiers (SIDs) for the users and groups that are allowed or denied access.
If auditing is configured for the object, its security descriptor also contains a SACL that controls how the security
subsystem audits attempts to access the object. However, auditing is not completely configured unless a SACL has
been configured for an object and a corresponding Object Access audit policy setting has been configured and
applied.
Why are audit policies applied on a per-computer basis rather than per
user?
In security auditing in Windows, the computer, objects on the computer, and related resources are the primary
recipients of actions by clients including applications, other computers, and users. In a security breach, malicious
users can use alternate credentials to hide their identity, or malicious applications can impersonate legitimate users
to perform undesired tasks. Therefore, the most consistent way to apply an audit policy is to focus on the computer
and the objects and resources on that computer.
In addition, because audit policy capabilities can vary between computers running different versions of Windows,
the best way to ensure that the audit policy is applied correctly is to base these settings on the computer instead of
the user.
However, in cases where you want audit settings to apply only to specified groups of users, you can accomplish this
by configuring SACLs on the relevant objects to enable auditing for a security group that contains only the users
you specify. For example, you can configure a SACL for a folder called Payroll Data on Accounting Server 1. This can
audit attempts by members of the Payroll Processors OU to delete objects from this folder. The Object
Access\Audit File System audit policy setting applies to Accounting Server 1, but because it requires a
corresponding resource SACL, only actions by members of the Payroll Processors OU on the Payroll Data folder
generates audit events.
What are the differences in auditing functionality between versions of

Windows?
Basic audit policy settings are available in all versions of Windows since Windows 2000, and they can be applied
locally or by using Group Policy. Advanced audit policy settings were introduced in Windows Vista and Windows
Server 2008, but the settings can only be applied by using logon scripts in those versions. Advanced audit policy
settings, which were introduced in Windows 7 and Windows Server 2008 R2, can be configured and applied by
using local and domain Group Policy settings.
Can I use advanced audit policies from a domain controller running

Windows Server 2003 or Windows 2000 Server?
To use advanced audit policy settings, your domain controller must be installed on a computer running Windows
Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003
with Service Pack 2 (SP2). Windows 2000 Server is not supported.
What is the difference between success and failure events? Is

something wrong if I get a failure audit?
A success audit event is triggered when a defined action, such as accessing a file share, is completed successfully.
A failure audit event is triggered when a defined action, such as a user logon, is not completed successfully.
The appearance of failure audit events in the event log does not necessarily mean that something is wrong with
your system. For example, if you configure Audit Logon events, a failure event may simply mean that a user
mistyped his or her password.
How can I set an audit policy that affects all objects on a computer?
System administrators and auditors increasingly want to verify that an auditing policy is applied to all objects on a
system. This has been difficult to accomplish because the system access control lists (SACLs) that govern auditing
are applied on a per-object basis. Thus, to verify that an audit policy has been applied to all objects, you would have
to check every object to be sure that no changes have been madeeven temporarily to a single SACL. Introduced
in Windows Server 2008 R2 and Windows 7, security auditing allows administrators to define global object access
auditing policies for the entire file system or for the registry on a computer. The specified SACL is then
automatically applied to every object of that type. This can be useful for verifying that all critical files, folders, and
registry settings on a computer are protected, and for identifying when an issue with a system resource occurs. If a
file or folder SACL and a global object access auditing policy (or a single registry setting SACL and a global object
access auditing policy) are configured on a computer, the effective SACL is derived from combining the file or
folder SACL and the global object access auditing policy. This means that an audit event is generated if an activity
matches either the file or folder SACL or the global object access auditing policy.
How do I figure out why someone was able to access a resource?

Often it is not enough to know simply that an object such as a file or folder was accessed. You may also want to
know why the user was able to access this resource. You can obtain this forensic data by configuring the Audit
Handle Manipulation setting with the Audit File System or with the Audit Registry audit setting.
How do I know when changes are made to access control settings, by

whom, and what the changes were?
To track access control changes on computers running Windows Server 2016, Windows Server 2012 R2, Windows
Server 2012 Windows 7, Windows Server 2008 R2, Windows Vista, or Windows Server 2008, you need to enable
the following settings, which track changes to DACLs:
Audit File System subcategory: Enable for success, failure, or success and failure
Audit Authorization Policy Change setting: Enable for success, failure, or success and failure
A SACL with Write and Take ownership permissions: Apply to the object that you want to monitor
In Windows XP and Windows Server 2003, you need to use the Audit policy change subcategory.
How can I roll back security audit policies from the advanced audit
policy to the basic audit policy?
Applying advanced audit policy settings replaces any comparable basic security audit policy settings. If you
subsequently change the advanced audit policy setting to Not configured, you need to complete the following
steps to restore the original basic security audit policy settings:
1. Set all Advanced Audit Policy subcategories to Not configured.
2. Delete all audit.csv files from the %SYSVOL% folder on the domain controller.
3. Reconfigure and apply the basic audit policy settings.
Unless you complete all of these steps, the basic audit policy settings will not be restored.
How can I monitor if changes are made to audit policy settings?

Changes to security audit policies are critical security events. You can use the Audit Audit Policy Change setting
to determine if the operating system generates audit events when the following types of activities take place:
Permissions and audit settings on the audit policy object are changed
The system audit policy is changed
Security event sources are registered or unregistered
Per-user audit settings are changed
The value of CrashOnAuditFail is modified
Audit settings on a file or registry key are changed
A Special Groups list is changed
How can I minimize the number of events that are generated?

Finding the right balance between auditing enough network and computer activity and auditing too little network
and computer activity can be challenging. You can achieve this balance by identifying the most important
resources, critical activities, and users or groups of users. Then design a security audit policy that targets these
resources, activities, and users. Useful guidelines and recommendations for developing an effective security
auditing strategy can be found in Planning and deploying advanced security audit policies.
What are the best tools to model and manage audit policies?
The integration of advanced audit policy settings with domain Group Policy, introduced in Windows 7 and
Windows Server 2008 R2, is designed to simplify the management and implementation of security audit policies in
an organization's network. As such, tools used to plan and deploy Group Policy Objects for a domain can also be
used to plan and deploy security audit policies. On an individual computer, the Auditpol command-line tool can be
used to complete a number of important audit policyrelated management tasks.
In addition, there are a number of computer management products, such as the Audit Collection Services in the
Microsoft System Center Operations Manager products, which can be used to collect and filter event data.
Where can I find information about all the possible events that I might
receive?
Users who examine the security event log for the first time can be a bit overwhelmed by the number of audit events
that are stored there (which can quickly number in the thousands) and by the structured information that is
included for each audit event. Additional information about these events, and the settings used to generate them,
can be obtained from the following resources:
Windows 8 and Windows Server 2012 Security Event Details
Security Audit Events for Windows 7 and Windows Server 2008 R2
Security Audit Events for Windows Server 2008 and Windows Vista
Advanced security audit policy settings
Where can I find more detailed information?

To learn more about security audit policies, see the following resources:
Planning and deploying advanced security audit policies
Security Monitoring and Attack Detection Planning Guide
Security Audit Events for Windows 7 and Windows Server 2008 R2
Security Audit Events for Windows Server 2008 and Windows Vista
Which editions of Windows support advanced audit
policy configuration
Applies to
Windows 10
This reference topic for the IT professional describes which versions of the Windows operating systems support
advanced security auditing policies.
Versions of the Windows operating system that cannot join a domain do not have access to these features. There is
no difference in security auditing support between 32-bit and 64-bit versions.
Are there any special considerations?

In addition, the following special considerations apply to the various tasks associated with advanced security
auditing enhancements:
Creating an audit policy. To create an advanced security auditing policy, you must use a computer running
any supported version of Windows. You can use the Group Policy Management Console (GPMC) on a computer
running a supported version of the Windows client operating system after installing the Remote Server
Administration Tools.
Applying audit policy settings. If you are using Group Policy to apply the advanced audit policy settings and
global object access settings, client computers must be running any supported version of the Windows server
operating system or Windows client operating system. In addition, only computers running any of these
supported operating systems can provide "reason for access" reporting data.
Developing an audit policy model. To plan advanced security audit settings and global object access
settings, you must use the GPMC that targets a domain controller running a supported version of the Windows
server operating system.
Distributing the audit policy. After a Group Policy Object (GPO) that includes advanced security auditing
settings is developed, it can be distributed by using domain controllers running any Windows Server operating
system. However, if you cannot put client computers running a supported version of the Windows client
operating system into a separate organizational unit (OU), you should use Windows Management
Instrumentation (WMI) filtering to ensure that the advanced security auditing policy settings are applied only to
client computers running a supported version of the Windows client operating system.
Important: Using both the basic auditing policy settings under Local Policies\Audit Policy and the advanced
auditing policy settings under Advanced Audit Policy Configuration can cause unexpected results in audit
reporting. Therefore, the two sets of audit policy settings should not be combined. 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.
Using advanced security auditing options to monitor
dynamic access control objects
Applies to
Windows 10
This guide explains the process of setting up advanced security auditing capabilities that are made possible
through settings and events that were introduced in Windows 8 and Windows Server 2012.
These procedures can be deployed with the advanced security auditing capabilities described in Deploy Security
Auditing with Central Audit Policies (Demonstration Steps).
In this guide
Domain administrators can create and deploy expression-based security audit policies by using file classification
information (resource attributes), user claims, and device claims to target specific users and resources to monitor
potentially significant activities on one or more computers. These policies can be deployed centrally by using
Group Policy, or directly on a computer, in a folder, or in individual files.
In this section
TOPIC DESCRIPTION
Monitor the central access policies that apply on a file server This topic for the IT professional describes how to monitor
changes to the central access policies that apply to a file
server when using advanced security auditing options to
monitor dynamic access control objects. Central access
policies are created on a domain controller and then applied
to file servers through Group Policy management.
Monitor the use of removable storage devices This topic for the IT professional describes how to monitor
attempts to use removable storage devices to access network
resources. It describes how to use advanced security auditing
options to monitor dynamic access control objects.
Monitor resource attribute definitions This topic for the IT professional describes how to monitor
changes to resource attribute definitions when you are using
advanced security auditing options to monitor dynamic access
control objects.
Monitor central access policy and rule definitions This topic for the IT professional describes how to monitor
changes to central access policy and central access rule
definitions when you use advanced security auditing options
to monitor dynamic access control objects.
Monitor user and device claims during sign-in This topic for the IT professional describes how to monitor
user and device claims that are associated with a users
security token when you are using advanced security auditing
options to monitor dynamic access control objects.
TOPIC DESCRIPTION
Monitor the resource attributes on files and folders This topic for the IT professional describes how to monitor
attempts to change settings to the resource attributes on files
when you are using advanced security auditing options to
monitor dynamic access control objects.
Monitor the central access policies associated with files and This topic for the IT professional describes how to monitor
folders changes to the central access policies that are associated with
files and folders when you are using advanced security
auditing options to monitor dynamic access control objects.
Monitor claim types This topic for the IT professional describes how to monitor
changes to claim types that are associated with dynamic
access control when you are using advanced security auditing
options.
Important: This procedure can be configured on computers running any of the supported Windows operating
systems. The other monitoring procedures can be configured only as part of a functioning dynamic access
control deployment.
Related topics
Security auditing
Monitor the central access policies that apply on a file
server
Applies to
Windows 10
This topic for the IT professional describes how to monitor changes to the central access policies that apply to a file
server when using advanced security auditing options to monitor dynamic access control objects. Central access
policies are created on a domain controller and then applied to file servers through Group Policy management.
Use the following procedures to configure and verify security auditing settings that are used to monitor changes to
the set of central access policies on a file server. The following procedures assume that you have configured and
deployed dynamic access control, including central access policies, and claims in your network. If you have not yet
deployed dynamic access control in your network, see Deploy a Central Access Policy (Demonstration Steps).
To configure settings to monitor changes to central access policies
1. Sign in to your domain controller by using domain administrator credentials.
2. In Server Manager, point to Tools, and then click Group Policy Management.
3. In the console tree, right-click the flexible access Group Policy Object, and then click Edit.
4. Double-click Computer Configuration, double-click Security Settings, double-click Advanced Audit
Policy Configuration, double-click Policy Change, and then double-click Other Policy Change Events.
Note: This policy setting monitors policy changes that might not be captured otherwise, such as central
access policy changes or trusted platform module configuration changes.
5. Select the Configure the following audit events check box, select the Success check box (and the Failure
check box, if desired), and then click OK.
After you modify the central access policies on the domain controller, verify that the changes have been applied to
the file server and that the proper events are logged.
To verify changes to the central access policies
2. Open the Group Policy Management Console.
3. Right-click Default domain policy, and then click Edit.
4. Double-click Computer Configuration, double-click Policies, and then double-click Windows Settings.
5. Double-click Security Settings, right-click File system, and then click Manage CAPs.
6. In the wizard that appears, follow the instructions to add a new central access policy (CAP), and then click OK.
7. Use local administrator credentials to sign in to the server that hosts resources that are subject to the central
access policies you changed.
8. Press the Windows key + R, then type cmd to open a Command Prompt window.
Note: If the User Account Control dialog box appears, confirm that the action it displays is what you
want, and then click Yes.
9. Type gpupdate /force, and press ENTER.

10. In Server Manager, click Tools, and then click Event Viewer.
11. Expand Windows Logs, and then click Security. Verify that event 4819 appears in the security log.
Related resource
Using advanced security auditing options to monitor dynamic access control objects
Monitor the use of removable storage devices
Applies to
Windows 10
This topic for the IT professional describes how to monitor attempts to use removable storage devices to access
network resources. It describes how to use advanced security auditing options to monitor dynamic access control
objects.
If you configure this policy setting, an audit event is generated each time a user attempts to copy, move, or save a
resource to a removable storage device.
Use the following procedures to monitor the use of removable storage devices and to verify that the devices are
being monitored.
Note: Your server might function differently based on the version and edition of the operating system that is
installed, your account permissions, and your menu settings.
To configure settings to monitor removable storage devices

3. In the console tree, right-click the flexible access Group Policy Object on the domain controller, and then click
Edit.
4. Double-click Computer Configuration, double-click Security Settings, double-click Advanced Audit Policy
Configuration, double-click Object Access, and then double-click Audit Removable Storage.
6. If you selected the Failure check box, double-click Audit Handle Manipulation, select the Configure the
following audit events check box, and then select Failure.
7. Click OK, and then close the Group Policy Management Editor.
After you configure the settings to monitor removable storage devices, use the following procedure to verify that
the settings are active.
To verify that removable storage devices are monitored
1. Sign in to the computer that hosts the resources that you want to monitor. Press the Windows key + R, and
then type cmd to open a Command Prompt window.
Note: If the User Account Control dialog box appears, confirm that the action it displays is what you
want, and then click Yes.
2. Type gpupdate /force, and press ENTER.

3. Connect a removable storage device to the targeted computer and attempt to copy a file that is protected with
the Removable Storage Audit policy.
5. Expand Windows Logs, and then click Security.
6. Look for event 4663, which logs successful attempts to write to or read from a removable storage device.
Failures will log event 4656. Both events include Task Category = Removable Storage device.
Key information to look for includes the name and account domain of the user who attempted to access the
file, the object that the user is attempting to access, resource attributes of the resource, and the type of
access that was attempted.
Note: We do not recommend that you enable this category on a file server that hosts file shares on a
removable storage device. When Removable Storage Auditing is configured, any attempt to access the
removable storage device will generate an audit event.
Related resource
Monitor resource attribute definitions
Applies to
Windows 10
This topic for the IT professional describes how to monitor changes to resource attribute definitions when you are
using advanced security auditing options to monitor dynamic access control objects. Resource attribute definitions
define the basic properties of resource attributes, such as what it means for a resource to be defined as high
business value. Resource attribute definitions are stored in AD DS under the Resource Properties container.
Changes to these definitions could significantly change the protections that govern a resource, even if the resource
attributes that apply to the resource remain unchanged. Changes can be monitored like any other AD DS object.
For information about monitoring changes to the resource attributes that apply to files, see Monitor the resource
attributes on files and folders.
Use the following procedures to configure settings to monitor changes to resource attribute definitions in AD DS
and to verify the changes. These procedures assume that you have configured and deployed Dynamic Access
Control, including central access policies, claims, and other components, in your network. If you have not yet
deployed Dynamic Access Control in your network, see Deploy a Central Access Policy (Demonstration Steps).
To configure settings to monitor changes to resource attributes

3. In the console tree, right-click the Group Policy Object for the default domain controller, and then click Edit.
4. Double-click Computer Configuration, click Security Settings, expand Advanced Audit Policy
Configuration, expand System Audit Policies, click DS Access, and then double-click Audit directory
service changes.
6. Close the Group Policy Management Editor.
7. Open the Active Directory Administrative Center.
8. Under Dynamic Access Control, right-click Resource Properties, and then click Properties.
9. Click the Security tab, click Advanced to open the Advanced Security Settings dialog box, and then click the
Auditing tab.
10. Click Add, add a security auditing setting for the container, and then close all Security properties dialog boxes.
After you configure settings to monitor changes to resource attributes in AD DS, verify that the changes are being
monitored.
To verify that changes to resource definitions are monitored
3. Under Dynamic Access Control, click Resource Properties, and then double-click a resource attribute.
4. Make changes to this resource attribute.
5. Click OK, and then close the Active Directory Administrative Center.
Related resource
Monitor central access policy and rule definitions
Applies to
Windows 10
This topic for the IT professional describes how to monitor changes to central access policy and central access rule
definitions when you use advanced security auditing options to monitor dynamic access control objects. Central
access policies and rules determine access permissions for multiple files on multiple file servers. Therefore, it is
important to monitor changes to them. Like user claim and device claim definitions, central access policy and rule
definitions reside in Active Directory Domain Services (AD DS), and they can be monitored just like any other object
in Active Directory. Central access policies and rules are critical elements in a Dynamic Access Control deployment.
These policies and rules are stored in AD DS, so they should be less likely to be tampered with than other network
objects. However, it is important to monitor these objects for potential changes in security auditing and to verify
that policies are being enforced.
Use the following procedures to configure settings to monitor changes to central access policy and central access
rule definitions and to verify the changes. These procedures assume that you have configured and deployed
Dynamic Access Control, including central access policies, claims, and other components, in your network. If you
have not yet deployed Dynamic Access Control in your network, see Deploy a Central Access Policy (Demonstration
Steps).
To configure settings to monitor changes to central access policy and rule definitions
3. In the console tree, right-click the default domain controller Group Policy Object, and then click Edit.
service changes.
8. Under Dynamic Access Control, right-click Central Access Policies, and then select Properties.
Auditing tab.
After you configure settings to monitor changes to central access policy and central access rule definitions, verify
that the changes are being monitored.
To verify that changes to central access policy and rule definitions are monitored
3. Under Dynamic Access Control, right-click Central Access Policies, and then click Properties.
Auditing tab.
6. In the Central Access Policies container, add a new central access policy (or select one that exists), click
Properties in the Tasks pane, and then change one or more attributes.
7. Click OK, and then close the Active Directory Administrative Center.
Related resource
Monitor user and device claims during sign-in
Applies to
Windows 10
This topic for the IT professional describes how to monitor user and device claims that are associated with a users
security token when you are using advanced security auditing options to monitor dynamic access control objects.
Device claims are associated with the system that is used to access resources that are protected with Dynamic
Access Control. User claims are attributes that are associated with a user. User claims and device claims are
included in the users security token used at sign-on. For example, information about Department, Company,
Project, or Security clearances might be included in the token.
Use the following procedures to monitor changes to user claims and device claims in the users sign-on token and
to verify the changes. These procedures assume that you have configured and deployed Dynamic Access Control,
including central access policies, claims, and other components, in your network. If you have not yet deployed
Dynamic Access Control in your network, see Deploy a Central Access Policy (Demonstration Steps).
To monitor user and device claims in user logon token

Configuration, expand System Audit Policies, click Logon/Logoff, and then double-click Audit
User/Device claims.
After you configure settings to monitor user and device claims, verify that the changes are being monitored.
To verify that user and device claims in user logon token are monitored
1. With local administrator credentials, sign in to a file server that is subject to the flexible access Group Policy
Object.
2. Open an elevated command prompt, and run the following command:
gpupdate force
3. From a client computer, connect to a file share on the file server as a user who has access permissions to the
file server.
4. On the file server, open Event Viewer, expand Windows Logs, and select the Security log. Look for event 4626,
and confirm that it contains information about user claims and device claims.
Related resource
Monitor the resource attributes on files and folders
Applies to
Windows 10
This topic for the IT professional describes how to monitor attempts to change settings to the resource attributes
on files when you are using advanced security auditing options to monitor dynamic access control objects.
If your organization has a carefully thought out authorization configuration for resources, changes to these
resource attributes can create potential security risks. Examples include:
Changing files that have been marked as high business value to low business value.
Changing the Retention attribute of files that have been marked for retention.
Changing the Department attribute of files that are marked as belonging to a particular department.
Use the following procedures to configure settings to monitor changes to resource attributes on files and folders.
These procedures assume that have configured and deployed central access policies in your network. For more
information about how to configure and deploy central access policies, see Dynamic Access Control: Scenario
Overview .
To monitor changes to resource attributes on files

Configuration, double-click Policy Change, and then double-click Audit Authorization Policy Change.
5. Select the Configure the following audit events check box, select the Success and Failure check boxes, and
then click OK.
After you configure settings to monitor resource attributes on files, verify that the changes are being monitored.
To verify that changes to resource attributes on files are monitored
1. Use administrator credentials to sign in to the server that hosts the resource you want to monitor.
2. From an elevated command prompt, type gpupdate /force, and then press ENTER.
3. Attempt to change resource properties on one or more files and folders.
6. Depending on which resource attributes you attempted to change, you should look for the following events:
Event 4911, which tracks changes to file attributes
Event 4913, which tracks changes to central access policies
Key information to look for includes the name and account domain of the principal attempting to change the
resource attribute, the object that the principal is attempting to modify, and information about the changes
that are being attempted.
Related resource
Monitor the central access policies associated with
files and folders
Applies to
Windows 10
This topic for the IT professional describes how to monitor changes to the central access policies that are associated
with files and folders when you are using advanced security auditing options to monitor dynamic access control
objects.
This security audit policy and the event that it records are generated when the central access policy that is
associated with a file or folder is changed. This security audit policy is useful when an administrator wants to
monitor potential changes on some, but not all, files and folders on a file server.
For info about monitoring potential central access policy changes for an entire file server, see Monitor the central
access policies that apply on a file server.
Use the following procedures to configure settings to monitor central access policies that are associated with files.
These procedures assume that you have configured and deployed Dynamic Access Control in your network. For
more information about how to configure and deploy Dynamic Access Control, see Dynamic Access Control:
Scenario Overview.
To configure settings to monitor central access policies associated with files or folders
Configuration, double-click Policy Change, and then double-click Audit Authorization Policy Change.
6. Enable auditing for a file or folder as described in the following procedure.
To enable auditing for a file or folder
1. Sign in as a member of the local administrators group on the computer that contains the files or folders that you
want to audit.
2. Right-click the file or folder, click Properties, and then click the Security tab.
3. Click Advanced, click the Auditing tab, and then click Continue.
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then
click Yes.
4. Click Add, click Select a principal, type a user name or group name in the format contoso\user1, and then
click OK.
5. In the Auditing Entry for dialog box, select the permissions that you want to audit, such as Full Control or
Delete.
6. Click OK four times to complete the configuration of the object SACL.
7. Open a File Explorer window and select or create a file or folder to audit.
8. Open an elevated command prompt, and run the following command:
gpupdate /force
After you configure settings to monitor changes to the central access policies that are associated with files and
folders, verify that the changes are being monitored.
To verify that changes to central access policies associated with files and folders are monitored
1. Sign in as a member of the local administrators group on the computer that contains the files or folders that you
want to audit.
2. Open a File Explorer window and select the file or folder that you configured for auditing in the previous
procedure.
3. Right-click the file or folder, click Properties, click the Security tab, and then click Advanced.
4. Click the Central Policy tab, click Change, and select a different central access policy (if one is available) or
select No Central Access Policy, and then click OK twice.
Note: You must select a setting that is different than your original setting to generate the audit event.

7. Look for event 4913, which is generated when the central access policy that is associated with a file or folder is
changed. This event includes the security identifiers (SIDs) of the old and new central access policies.
Related resource
Monitor claim types
Applies to
Windows 10
This topic for the IT professional describes how to monitor changes to claim types that are associated with dynamic
access control when you are using advanced security auditing options.
Claim types are one of the basic building blocks of Dynamic Access Control. Claim types can include attributes such
as the departments in an organization or the levels of security clearance that apply to classes of users. You can use
security auditing to track whether claims are added, modified, enabled, disabled, or deleted.
Use the following procedures to configure settings to monitor changes to claim types in AD DS. These procedures
assume that you have configured and deployed Dynamic Access Control, including central access policies, claims,
and other components, in your network. If you have not yet deployed Dynamic Access Control in your network, see
Deploy a Central Access Policy (Demonstration Steps).
To configure settings to monitor changes to claim types

1. Sign in to your domain controller by using domain administrator credential.
3. In the console tree, right-click the default domain controller Group Policy Object, and then click Edit.
service changes.
5. Select the Configure the following audit events check box, select the Success check box (andthe Failure
After you configure settings to monitor changes to claim types in AD DS, verify that the changes are being
monitored.
To verify that changes to claim types are monitored
3. Under Dynamic Access Control, right-click Claim Types, and then click Properties.
Auditing tab.
5. Click Add, add a security auditing setting for the container, and then close all the Security properties dialog
boxes.
6. In the Claim Types container, add a new claim type or select an existing claim type. In the Tasks pane, click
Properties, and then change one or more attributes.
Click OK, and then close the Active Directory Administrative Center.
7. Open Event Viewer on this domain controller, expand Windows Logs, and select the Security log.
Look for event 5137. Key information to look for includes the name of the new attribute that was added, the
type of claim that was created, and the user who created the claim.
Related resource
Applies to
Windows 10
This reference for IT professionals provides information about the advanced audit policy settings that are available
in Windows and the audit events that they generate.
The security audit policy settings under Security Settings\Advanced Audit Policy Configuration can help
your organization audit compliance with important business-related and security-related rules by tracking
precisely defined activities, such as:
A group administrator has modified settings or data on servers that contain finance information.
An employee within a defined group has accessed an important file.
The correct system access control list (SACL) is applied to every file and folder or registry key on a computer or
file share as a verifiable safeguard against undetected access.
You can access these audit policy settings through the Local Security Policy snap-in (secpol.msc) on the local
computer or by using Group Policy.
These advanced audit policy settings allow you to select only the behaviors that you want to monitor. You can
exclude audit results for behaviors that are of little or no concern to you, or behaviors that create an excessive
number of log entries. In addition, because security audit policies can be applied by using domain Group Policy
Objects, audit policy settings can be modified, tested, and deployed to selected users and groups with relative
simplicity. Audit policy settings under Security Settings\Advanced Audit Policy Configuration are available
in the following categories:
Account Logon
Configuring policy settings in this category can help you document attempts to authenticate account data on a
domain controller or on a local Security Accounts Manager (SAM). Unlike Logon and Logoff policy settings and
events, which track attempts to access a particular computer, settings and events in this category focus on the
account database that is used. This category includes the following subcategories:
Audit Credential Validation
Audit Kerberos Authentication Service
Audit Kerberos Service Ticket Operations
Audit Other Logon/Logoff Events
Account Management
The security audit policy settings in this category can be used to monitor changes to user and computer accounts
and groups. This category includes the following subcategories:
Audit Application Group Management
Audit Computer Account Management
Audit Distribution Group Management
Audit Other Account Management Events
Audit Security Group Management
Audit User Account Management
Detailed Tracking
Detailed Tracking security policy settings and audit events can be used to monitor the activities of individual
applications and users on that computer, and to understand how a computer is being used. This category includes
the following subcategories:
Audit DPAPI Activity
Audit PNP activity
Audit Process Creation
Audit Process Termination
Audit RPC Events
DS Access
DS Access security audit policy settings provide a detailed audit trail of attempts to access and modify objects in
Active Directory Domain Services (AD DS). These audit events are logged only on domain controllers. This
category includes the following subcategories:
Audit Detailed Directory Service Replication
Audit Directory Service Access
Audit Directory Service Changes
Audit Directory Service Replication
Logon/Logoff
Logon/Logoff security policy settings and audit events allow you to track attempts to log on to a computer
interactively or over a network. These events are particularly useful for tracking user activity and identifying
potential attacks on network resources. This category includes the following subcategories:
Audit Account Lockout
Audit User/Device Claims
Audit IPsec Extended Mode
Audit Group Membership
Audit IPsec Main Mode
Audit IPsec Quick Mode
Audit Logoff
Audit Logon
Audit Network Policy Server
Audit Special Logon
Object Access
Object Access policy settings and audit events allow you to track attempts to access specific objects or types of
objects on a network or computer. To audit attempts to access a file, directory, registry key, or any other object,
you must enable the appropriate object Aaccess auditing subcategory for success and/or failure events. For
example, the file system subcategory needs to be enabled to audit file operations, and the Registry subcategory
needs to be enabled to audit registry accesses.
Proving that these audit policies are in effect to an external auditor is more difficult. There is no easy way to verify
that the proper SACLs are set on all inherited objects. To address this issue, see Global Object Access Auditing.
This category includes the following subcategories:
Audit Application Generated
Audit Certification Services
Audit Detailed File Share
Audit File Share
Audit File System
Audit Filtering Platform Connection
Audit Filtering Platform Packet Drop
Audit Handle Manipulation
Audit Kernel Object
Audit Other Object Access Events
Audit Registry
Audit Removable Storage
Audit SAM
Audit Central Access Policy Staging
Policy Change
Policy Change audit events allow you to track changes to important security policies on a local system or network.
Because policies are typically established by administrators to help secure network resources, monitoring changes
or attempts to change these policies can be an important aspect of security management for a network. This
Audit Audit Policy Change
Audit Authentication Policy Change
Audit Authorization Policy Change
Audit Filtering Platform Policy Change
Audit MPSSVC Rule-Level Policy Change
Audit Other Policy Change Events
Privilege Use
Permissions on a network are granted for users or computers to complete defined tasks. Privilege Use security
policy settings and audit events allow you to track the use of certain permissions on one or more systems. This
Audit Non-Sensitive Privilege Use
Audit Sensitive Privilege Use
Audit Other Privilege Use Events
System
System security policy settings and audit events allow you to track system-level changes to a computer that are
not included in other categories and that have potential security implications. This category includes the following
subcategories:
Audit IPsec Driver
Audit Other System Events
Audit Security State Change
Audit Security System Extension
Audit System Integrity
Global Object Access Auditing

Global Object Access Auditing policy settings allow administrators to define computer system access control lists
(SACLs) per object type for the file system or for the registry. The specified SACL is then automatically applied to
every object of that type. Auditors will be able to prove that every resource in the system is protected by an audit
policy by viewing the contents of the Global Object Access Auditing policy settings. For example, if auditors see a
policy setting called "Track all changes made by group administrators," they know that this policy is in effect.
Resource SACLs are also useful for diagnostic scenarios. For example, setting the Global Object Access Auditing
policy to log all the activity for a specific user and enabling the policy to track "Access denied" events for the file
system or registry can help administrators quickly identify which object in a system is denying a user access.
Note: If a file or folder SACL and a Global Object Access Auditing policy setting (or a single registry setting
SACL and a Global Object Access Auditing policy setting) are configured on a computer, the effective SACL is
derived from combining the file or folder SACL and the Global Object Access Auditing policy. This means that
an audit event is generated if an activity matches the file or folder SACL or the Global Object Access Auditing
policy.
This category includes the following subcategories:

File System (Global Object Access Auditing)
Registry (Global Object Access Auditing)
Audit Credential Validation
Applies to
Windows 10
Windows Server 2016
Audit Credential Validation determines whether the operating system generates audit events on credentials that
are submitted for a user account logon request.
These events occur on the computer that is authoritative for the credentials as follows:
For domain accounts, the domain controller is authoritative.
For local accounts, the local computer is authoritative.
Event volume:
High on domain controllers.
Low on member servers and workstations.
Because domain accounts are used much more frequently than local accounts in enterprise environments, most of
the Account Logon events in a domain environment occur on the domain controllers that are authoritative for the
domain accounts. However, these events can occur on any computer, and they may occur in conjunction with or
on separate computers from Logon and Logoff events.
The main reason to enable this auditing subcategory is to handle local accounts authentication attempts and, for
domain accounts, NTLM authentication in the domain. It is especially useful for monitoring unsuccessful attempts,
to find brute-force attacks, account enumeration, and potential account compromise events on domain controllers.
STRONGER STRONGER
COMPUTER TYPE GENERAL SUCCESS GENERAL FAILURE SUCCESS FAILURE COMMENTS
STRONGER STRONGER
Domain IF Yes Yes Yes Expected volume

Controller of events is high
for domain
controllers,
because this
subcategory will
generate events
when an
authentication
attempt is made
using any
domain account
and NTLM
authentication.
IF We
recommend
Success auditing
to keep track of
domain-account
authentication
events using the
NTLM protocol.
Expect a high
volume of events.
For
recommendation
s for using and
analyzing the
collected
information, see
the Security
Monitoring
Recommendatio
ns sections. Just
collecting Success
auditing events
in this
subcategory for
future use in case
of a security
incident is not
very useful,
because events in
this subcategory
are not always
informative.
We recommend
Failure auditing,
to collect
information
about failed
authentication
attempts using
domain accounts
and the NTLM
authentication
protocol.
STRONGER STRONGER
Member Server Yes Yes Yes Yes Expected volume

of events is low
for member
servers, because
this subcategory
will generate
events when an
authentication
attempt is made
using a local
account, which
should not
happen too
often.
We recommend
Success auditing,
to keep track of
authentication
events by local
accounts.
We recommend
Failure auditing,
to collect
information
about failed
authentication
attempts by local
accounts.
Workstation Yes Yes Yes Yes Expected volume

of events is low
for workstations,
because this
subcategory will
generate events
when an
authentication
attempt is made
using a local
account, which
should not
happen too
often.
We recommend
Success auditing,
to keep track of
authentication
events by local
accounts.
We recommend
Failure auditing,
to collect
information
about failed
authentication
attempts by local
accounts.
Events List:
4774(S, F): An account was mapped for logon.
4775(F): An account could not be mapped for logon.
4776(S, F): The computer attempted to validate the credentials for an account.
4777(F): The domain controller failed to validate the credentials for an account.
4774(S, F): An account was mapped for logon.
Applies to
Windows 10
Windows Server 2016
Success events do not appear to occur. Failure event has been reported.
Subcategory: Audit Credential Validation
Event Schema:
An account was mapped for logon.
Authentication Package:Schannel
Account UPN:<Acccount>@<Domain>
Mapped Name:<Account>
Required Server Roles: no information.
Minimum OS Version: no information.
Event Versions: 0.
Security Monitoring Recommendations

There is no recommendation for this event in this document.
4775(F): An account could not be mapped for logon.
Applies to
Windows 10
Windows Server 2016
It appears that this event never occurs.
Event Schema:
An account could not be mapped for logon.
Authentication Package:%1
Account Name:%2
Event Versions: 0.

4776(S, F): The computer attempted to validate the
credentials for an account.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time that a
credential validation occurs using NTLM
authentication.
This event occurs only on the computer that
is authoritative for the provided credentials.
For domain accounts, the domain controller
is authoritative. For local accounts, the local
computer is authoritative.
It shows successful and unsuccessful
credential validation attempts.
It shows only the computer name (Source Workstation) from which the authentication attempt was performed
(authentication source). For example, if you authenticate from CLIENT-1 to SERVER-1 using a domain account you
will see CLIENT-1 in the Source Workstation field. Information about the destination computer (SERVER-1) is not
presented in this event.
If a credential validation attempt fails, you will see a Failure event with Error Code parameter value not equal to
0x0.
The main advantage of this event is that on domain controllers you can see all authentication attempts for domain
accounts when NTLM authentication was used.
For monitoring local account logon attempts, it is better to use event 4624: An account was successfully logged
on because it contains more details and is more informative.
This event also generates when a workstation unlock event occurs.
This event does not generate when a domain account logs on locally to a domain controller.
Note For recommendations, see Security Monitoring Recommendations for this event.
Event XML:
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
<EventID>4776</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>14336</Task>
<Opcode>0</Opcode>
<Keywords>0x8010000000000000</Keywords>
<TimeCreated SystemTime="2015-07-25T04:38:11.003163100Z" />
<EventRecordID>165437</EventRecordID>
<Correlation />
<Execution ProcessID="500" ThreadID="532" />
<Channel>Security</Channel>
<Computer>DC01.contoso.local</Computer>
<Security />
</System>
- <EventData>
<Data Name="PackageName">MICROSOFT\_AUTHENTICATION\_PACKAGE\_V1\_0</Data>
<Data Name="TargetUserName">dadmin</Data>
<Data Name="Workstation">WIN81</Data>
<Data Name="Status">0xc0000234</Data>
</EventData>
</Event>
Required Server Roles: no specific requirements.

Minimum OS Version: Windows Server 2008, Windows Vista.
Event Versions: 0.
Field Descriptions:
Authentication Package [Type = UnicodeString]: the name of Authentication Package which was used for
credential validation. It is always MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 for 4776 event.
Note Authentication package is a DLL that encapsulates the authentication logic used to determine
whether to permit a user to log on. Local Security Authority (LSA) authenticates a user logon by sending the
request to an authentication package. The authentication package then examines the logon information and
either authenticates or rejects the user logon attempt.
Logon Account [Type = UnicodeString]: the name of the account that had its credentials validated by the
Authentication Package. Can be user name, computer account name or well-known security principal
account name. Examples:
User example: dadmin
Computer account example: WIN81$
Local System account example: Local
Local Service account example: Local Service
Source Workstation [Type = UnicodeString]: the name of the computer from which the logon attempt
originated.
Error Code [Type = HexInt32]: contains error code for Failure events. For Success events this parameter has
0x0 value. The table below contains most common error codes for this event:
ERROR CODE DESCRIPTION
0xC0000064 The username you typed does not exist. Bad username.
0xC000006A Account logon with misspelled or bad password.
0xC000006D - Generic logon failure.

Some of the potential causes for this:
An invalid username and/or password was used
LAN Manager Authentication Level mismatch between the
source and target computers.
0xC000006F Account logon outside authorized hours.
0xC0000070 Account logon from unauthorized workstation.
0xC0000071 Account logon with expired password.
0xC0000072 Account logon to account disabled by administrator.
0xC0000193 Account logon with expired account.
0xC0000224 Account logon with "Change Password at Next Logon"

flagged.
0xC0000234 Account logon with account locked.
0xc0000371 The local account store does not contain secret material for
the specified account.
0x0 No errors.
Table 1. Winlogon Error Codes.

For 4776(S, F): The computer attempted to validate the credentials for an account.
TYPE OF MONITORING REQUIRED RECOMMENDATION
High-value accounts: You might have high-value domain or Monitor this event with the Logon Account that
local accounts for which you need to monitor each action. corresponds to the high-value account or accounts.
Examples of high-value accounts are database administrators,
built-in local administrator account, domain administrators,
service accounts, domain controller accounts and so on.
Anomalies or malicious actions: You might have specific When you monitor for anomalies or malicious actions, use the
requirements for detecting anomalies or monitoring potential Logon Account value (with other information) to monitor
malicious actions. For example, you might need to monitor for how or when a particular account is being used.
use of an account outside of working hours. To monitor activity of specific user accounts outside of
working hours, monitor the appropriate Logon Account +
Source Workstation pairs.
Non-active accounts: You might have non-active, disabled, Monitor this event with the Logon Account that should
or guest accounts, or other accounts that should never be never be used.
used.
Account whitelist: You might have a specific whitelist of If this event corresponds to a whitelist-only action, review
accounts that are the only ones allowed to perform actions the Logon Account for accounts that are outside the
corresponding to particular events. whitelist.
Restricted-use computers: You might have certain Monitor the target Source Workstation for credential
computers from which certain people (accounts) should not validation requests from the Logon Account that you are
log on. concerned about.
Account naming conventions: Your organization might have Monitor Logon Account for names that dont comply with
specific naming conventions for account names. naming conventions.
If NTLM authentication should not be used for a specific account, monitor for that account. Dont forget that
local logon will always use NTLM authentication if an account logs on to a device where its user account is
stored.
You can use this event to collect all NTLM authentication attempts in the domain, if needed. Dont forget that
local logon will always use NTLM authentication if the account logs on to a device where its user account is
stored.
If a local account should be used only locally (for example, network logon or terminal services logon is not
allowed), you need to monitor for all events where Source Workstation and Computer (where the event
was generated and where the credentials are stored) have different values.
Consider tracking the following errors for the reasons listed:
ERROR TO TRACK WHAT THE ERROR MIGHT INDICATE
User logon with misspelled or bad user account For example, N events in the last N minutes can be an
indicator of an account enumeration attack, especially relevant
for highly critical accounts.
User logon with misspelled or bad password For example, N events in the last N minutes can be an
indicator of a brute-force password attack, especially relevant
User logon outside authorized hours Can indicate a compromised account; especially relevant for
highly critical accounts.
User logon from unauthorized workstation Can indicate a compromised account; especially relevant for
User logon to account disabled by administrator For example, N events in last N minutes can be an indicator of
an account compromise attempt, especially relevant for highly
critical accounts.
User logon with expired account Can indicate an account compromise attempt; especially
relevant for highly critical accounts.
User logon with account locked Can indicate a brute-force password attack; especially relevant
4777(F): The domain controller failed to validate the
credentials for an account.
Applies to
Windows 10
Windows Server 2016
Currently this event doesnt generate. It is a defined event, but it is never invoked by the operating system. 4776
failure event is generated instead.
Audit Kerberos Authentication Service
Applies to
Windows 10
Windows Server 2016
Audit Kerberos Authentication Service determines whether to generate audit events for Kerberos authentication
ticket-granting ticket (TGT) requests.
If you configure this policy setting, an audit event is generated after a Kerberos authentication TGT request.
Success audits record successful attempts and Failure audits record unsuccessful attempts.
Event volume: High on Kerberos Key Distribution Center servers.
This subcategory contains events about issued TGTs and failed TGT requests. It also contains events about failed
Pre-Authentications, due to wrong user password or when the users password has expired.
STRONGER STRONGER
STRONGER STRONGER
Domain Yes Yes Yes Yes We recommend

Controller Success auditing,
because you will
see all Kerberos
Authentication
requests (TGT
requests), which
are a part of
domain account
logons. Also, you
can see the IP
address from
which this
account
requested a TGT,
when TGT was
requested, which
encryption type
was used and so
on.
We recommend
Failure auditing,
because you will
see all failed
requests with
wrong password,
username,
revoked
certificate, and so
on. You will also
be able to detect
Kerberos issues
or possible attack
attempts.
Expected volume
is high on
domain
controllers.
Member Server No No No No This subcategory

makes sense only
on domain
controllers.
Workstation No No No No This subcategory

makes sense only
on domain
controllers.
Events List:
4768(S, F): A Kerberos authentication ticket (TGT) was requested.
4771(F): Kerberos pre-authentication failed.
4772(F): A Kerberos authentication ticket request failed.
4768(S, F): A Kerberos authentication ticket (TGT)
was requested.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Kerberos
Authentication Service
Event Description:
This event generates every
time Key Distribution Center
issues a Kerberos Ticket
Granting Ticket (TGT).
This event generates only on
domain controllers.
If TGT issue fails then you will
see Failure event with Result
Code field not equal to 0x0.
This event doesn't generate
for Result Codes: 0x10, 0x17
and 0x18. Event 4771:
Kerberos pre-authentication
failed. generates instead.
Note For
recommendations, see
Security Monitoring
Recommendations for this
event.
Event XML:
- <System>
<Level>0</Level>
<Task>14339</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetDomainName">CONTOSO.LOCAL</Data>
<Data Name="TargetSid">S-1-5-21-3457937927-2839227994-823803824-1104</Data>
<Data Name="ServiceName">krbtgt</Data>
<Data Name="ServiceSid">S-1-5-21-3457937927-2839227994-823803824-502</Data>
<Data Name="TicketOptions">0x40810010</Data>
<Data Name="Status">0x0</Data>
<Data Name="TicketEncryptionType">0x12</Data>
<Data Name="PreAuthType">15</Data>
<Data Name="IpAddress">::ffff:10.0.0.12</Data>
<Data Name="IpPort">49273</Data>
<Data Name="CertIssuerName">contoso-DC01-CA-1</Data>
<Data Name="CertSerialNumber">1D0000000D292FBE3C6CDDAFA200020000000D</Data>
<Data Name="CertThumbprint">564DFAEE99C71D62ABC553E695BD8DBC46669413</Data>
</EventData>
</Event>
Required Server Roles: Active Directory domain controller.

Minimum OS Version: Windows Server 2008.
Event Versions: 0.
Field Descriptions:
Account Information:
Account Name [Type = UnicodeString]: the name of account, for which (TGT) ticket was requested.
Computer account name ends with $ character.
User account example: dadmin
Supplied Realm Name [Type = UnicodeString]: the name of the Kerberos Realm that Account Name
belongs to. This can appear in a variety of formats, including the following:
Domain NETBIOS name example: CONTOSO
Lowercase full domain name: contoso.local
Uppercase full domain name: CONTOSO.LOCAL
Note A Kerberos Realm is a set of managed nodes that share the same Kerberos database. The Kerberos
database resides on the Kerberos master computer system, which should be kept in a physically secure room.
Active Directory domain is the example of Kerberos Realm in the Microsoft Windows Active Directory world.
User ID [Type = SID]: SID of account for which (TGT) ticket was requested. Event Viewer automatically tries
to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in
the event.
For example: CONTOSO\dadmin or CONTOSO\WIN81$.
NULL SID this value shows in 4768 Failure events.
Note A security identifier (SID) is a unique value of variable length used to identify a trustee (security
principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain
controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that
user from the database and places it in the access token for that user. The system uses the SID in the access
token to identify the user in all subsequent interactions with Windows security. When a SID has been used as
the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For
more information about SIDs, see Security identifiers.
Service Information:
Service Name [Type = UnicodeString]: the name of the service in the Kerberos Realm to which TGT
request was sent. Typically has value krbtgt for TGT requests, which means Ticket Granting Ticket issuing
service.
For Failure events Service Name typically has the following format: krbtgt/REALM_NAME. For
example: krbtgt/CONTOSO.
Service ID [Type = SID]: SID of the service account in the Kerberos Realm to which TGT request was sent.
Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved,
you will see the source data in the event.
Domain controllers have a specific service account (krbtgt) that is used by the Key Distribution Center
(KDC) service to issue Kerberos tickets. It has a built-in, pre-defined SID: S-1-5-21-DOMAIN_IDENTIFIER-
502.
NULL SID this value shows in 4768 Failure events.
Network Information:
Client Address [Type = UnicodeString]: IP address of the computer from which the TGT request was
received. Formats vary, and include the following:
IPv6 or IPv4 address.
::ffff:IPv4_address.
::1 - localhost.
Client Port [Type = UnicodeString]: source port number of client network connection (TGT request
connection).
0 for local (localhost) requests.
Additional information:
Ticket Options [Type = HexInt32]: this is a set of different ticket flags in hexadecimal format.
Example:
Ticket Options: 0x40810010
Binary view: 01000000100000010000000000010000
Using MSB 0 bit numbering we have bit 1, 8, 15 and 27 set = Forwardable, Renewable,
Canonicalize, Renewable-ok.
Note In the table below MSB 0 bit numbering is used, because RFC documents use this style. In MSB 0
style bit numbering begins from left.
The most common values:

0x40810010 - Forwardable, Renewable, Canonicalize, Renewable-ok
0x40810000 - Forwardable, Renewable, Canonicalize
0x60810010 - Forwardable, Forwarded, Renewable, Canonicalize, Renewable-ok
BIT FLAG NAME DESCRIPTION
0 Reserved -
1 Forwardable (TGT only). Tells the ticket-granting

service that it can issue a new TGT
based on the presented TGTwith a
different network address based on the
presented TGT.
2 Forwarded Indicates either that a TGT has been

forwarded or that a ticket was issued
from a forwarded TGT.
3 Proxiable (TGT only). Tells the ticket-granting

service that it can issue tickets with a
network address that differs from the
one in the TGT.
4 Proxy Indicates that the network address in

the ticket is different from the one in
the TGT used to obtain the ticket.
5 Allow-postdate Postdated tickets SHOULD NOT be

supported in KILE (Microsoft Kerberos
Protocol Extension).
6 Postdated Postdated tickets SHOULD NOT be

7 Invalid This flag indicates that a ticket is invalid,

and it must be validated by the KDC
before use. Application servers must
reject tickets which have this flag set.
8 Renewable Used in combination with the End Time

and Renew Till fields to cause tickets
with long life spans to be renewed at
the KDC periodically.
9 Initial Indicates that a ticket was issued using

the authentication service (AS)
exchange and not issued based on a
TGT.
10 Pre-authent Indicates that the client was

authenticated by the KDC before a
ticket was issued. This flag usually
indicates the presence of an
authenticator in the ticket. It can also
flag the presence of credentials taken
from a smart card logon.
11 Opt-hardware-auth This flag was originally intended to

indicate that hardware-supported
authentication was used during pre-
authentication. This flag is no longer
recommended in the Kerberos V5
protocol. KDCs MUST NOT issue a
ticket with this flag set. KDCs SHOULD
NOT preserve this flag if it is set by
another KDC.
12 Transited-policy-checked KILE MUST NOT check for transited

domains on servers or a KDC.
Application servers MUST ignore the
TRANSITED-POLICY-CHECKED flag.
13 Ok-as-delegate The KDC MUST set the OK-AS-

DELEGATE flag if the service account is
trusted for delegation.
14 Request-anonymous KILE not use this flag.
15 Name-canonicalize In order to request referrals the

Kerberos client MUST explicitly request
the "canonicalize" KDC option for the
AS-REQ or TGS-REQ.
16-25 Unused -
26 Disable-transited-check By default the KDC will check the

transited field of a TGT against the
policy of the local realm before it will
issue derivative tickets based on the
TGT. If this flag is set in the request,
checking of the transited field is
disabled. Tickets issued without the
performance of this check will be noted
by the reset (0) value of the
TRANSITED-POLICY-CHECKED flag,
indicating to the application server that
the transited field must be checked
locally. KDCs are encouraged but not
required to honor
the DISABLE-TRANSITED-CHECK
option.
Should not be in use, because
Transited-policy-checked flag is not
supported by KILE.
27 Renewable-ok The RENEWABLE-OK option indicates

that a renewable ticket will be
acceptable if a ticket with the requested
life cannot otherwise be provided, in
which case a renewable ticket may be
issued with a renew-till equal to the
requested end time. The value of the
renew-till field may still be limited by
local limits, or limits selected by the
individual principal or server.
28 Enc-tkt-in-skey No information.
29 Unused -
30 Renew The RENEW option indicates that the

present request is for a renewal. The
ticket provided is encrypted in the
secret key for the server on which it is
valid. This option will only be honored if
the ticket to be renewed has its
RENEWABLE flag set and if the time in
its renew-till field has not passed. The
ticket to be renewed is passed in the
padata field as part of the
authentication header.
31 Validate This option is used only by the ticket-

granting service. The VALIDATE option
indicates that the request is to validate
a postdated ticket. Should not be in
use, because postdated tickets are not
supported by KILE.
Table 2. Kerberos ticket flags.

Note KILE (Microsoft Kerberos Protocol Extension) Kerberos protocol extensions used in Microsoft
operating systems. These extensions provide additional capability for authorization information including
group memberships, interactive logon information, and integrity levels.
Result Code [Type = HexInt32]: hexadecimal result code of TGT issue operation. The Table 3. TGT/TGS issue
error codes. contains the list of the most common error codes for this event.
CODE CODE NAME DESCRIPTION POSSIBLE CAUSES
0x0 KDC_ERR_NONE No error No errors were found.
0x1 KDC_ERR_NAME_EXP Client's entry in KDC No information.

database has expired
0x2 KDC_ERR_SERVICE_EXP Server's entry in KDC No information.

0x3 KDC_ERR_BAD_PVNO Requested Kerberos version No information.

number not supported
0x4 KDC_ERR_C_OLD_MAST_KV Client's key encrypted in old No information.

NO master key
0x5 KDC_ERR_S_OLD_MAST_KV Server's key encrypted in old No information.

NO master key
0x6 KDC_ERR_C_PRINCIPAL_UN Client not found in Kerberos The username doesnt exist.
KNOWN database
0x7 KDC_ERR_S_PRINCIPAL_UN Server not found in This error can occur if the
KNOWN Kerberos database domain controller cannot
find the servers name in
Active Directory. This error is
similar to
KDC_ERR_C_PRINCIPAL_UN
KNOWN except that it
occurs when the server
name cannot be found.
0x8 KDC_ERR_PRINCIPAL_NOT_ Multiple principal entries in This error occurs if duplicate

UNIQUE KDC database principal names exist.
Unique principal names are
crucial for ensuring mutual
authentication. Thus,
duplicate principal names
are strictly forbidden, even
across multiple realms.
Without unique principal
names, the client has no
way of ensuring that the
server it is communicating
with is the correct one.
0x9 KDC_ERR_NULL_KEY The client or server has a No master key was found
null key (master key) for client or server. Usually it
means that administrator
should reset the password
on the account.
0xA KDC_ERR_CANNOT_POSTD Ticket (TGT) not eligible for This error can occur if a
ATE postdating client requests postdating of
a Kerberos ticket. Postdating
is the act of requesting that
a tickets start time be set
into the future.
It also can occur if there is a
time difference between the
client and the KDC.
0xB KDC_ERR_NEVER_VALID Requested start time is later There is a time difference

than end time between the KDC and the
client.
0xC KDC_ERR_POLICY Requested start time is later This error is usually the
than end time result of logon restrictions in
place on a users account.
For example workstation
restriction, smart card
authentication requirement
or logon time restriction.
0xD KDC_ERR_BADOPTION KDC cannot accommodate Impending expiration of a

requested option TGT.
The SPN to which the client
is attempting to delegate
credentials is not in its
Allowed-to-delegate-to list
0xE KDC_ERR_ETYPE_NOTSUPP KDC has no support for In general, this error occurs
encryption type when the KDC or a client
receives a packet that it
cannot decrypt.
0xF KDC_ERR_SUMTYPE_NOSUP KDC has no support for The KDC, server, or client
P checksum type receives a packet for which it
does not have a key of the
appropriate encryption type.
The result is that the
computer is unable to
decrypt the ticket.
0x10 KDC_ERR_PADATA_TYPE_N KDC has no support for Smart card logon is being
OSUPP PADATA type (pre- attempted and the proper
authentication data) certificate cannot be located.
This can happen because
the wrong certification
authority (CA) is being
queried or the proper CA
cannot be contacted.
It can also happen when a
domain controller doesnt
have a certificate installed
for smart cards (Domain
Controller or Domain
Controller Authentication
templates).
This error code cannot occur
in event 4768. A Kerberos
authentication ticket (TGT)
was requested. It occurs in
4771. Kerberos pre-
authentication failed event.
0x11 KDC_ERR_TRTYPE_NO_SUPP KDC has no support for No information.

transited type
0x12 KDC_ERR_CLIENT_REVOKED Clients credentials have This might be because of an

been revoked explicit disabling or because
of other restrictions in place
on the account. For
example: account disabled,
expired, or locked out.
0x13 KDC_ERR_SERVICE_REVOKE Credentials for server have No information.

D been revoked
0x14 KDC_ERR_TGT_REVOKED TGT has been revoked Since the remote KDC may
change its PKCROSS key
while there are PKCROSS
tickets still active, it
SHOULD cache the old
PKCROSS keys until the last
issued PKCROSS ticket
expires. Otherwise, the
remote KDC will respond to
a client with a KRB-ERROR
message of type
KDC_ERR_TGT_REVOKED.
See RFC1510 for more
details.
0x15 KDC_ERR_CLIENT_NOTYET Client not yet validtry No information.

again later
0x16 KDC_ERR_SERVICE_NOTYET Server not yet validtry No information.

again later
0x17 KDC_ERR_KEY_EXPIRED Password has expired The users password has

change password to reset expired.
4771. Kerberos pre-
0x18 KDC_ERR_PREAUTH_FAILED Pre-authentication The wrong password was

information was invalid provided.
4771. Kerberos pre-
0x19 KDC_ERR_PREAUTH_REQUIR Additional pre- This error often occurs in

ED authentication required UNIX interoperability
scenarios. MIT-Kerberos
clients do not request pre-
authentication when they
send a KRB_AS_REQ
message. If pre-
authentication is required
(the default), Windows
systems will send this error.
Most MIT-Kerberos clients
will respond to this error by
giving the pre-
authentication, in which case
the error can be ignored,
but some clients might not
respond in this way.
0x1A KDC_ERR_SERVER_NOMATC KDC does not know about No information.

H the requested server
0x1B KDC_ERR_SVC_UNAVAILABL KDC is unavailable No information.

E
0x1F KRB_AP_ERR_BAD_INTEGRIT Integrity check on decrypted The authenticator was

Y field failed encrypted with something
other than the session key.
The result is that the client
cannot decrypt the resulting
message. The modification
of the message could be the
result of an attack or it
could be because of network
noise.
0x20 KRB_AP_ERR_TKT_EXPIRED The ticket has expired The smaller the value for the
Maximum lifetime for user
ticket Kerberos policy
setting, the more likely it is
that this error will occur.
Because ticket renewal is
automatic, you should not
have to do anything if you
get this message.
0x21 KRB_AP_ERR_TKT_NYV The ticket is not yet valid The ticket presented to the
server is not yet valid (in
relationship to the server
time). The most probable
cause is that the clocks on
the KDC and the client are
not synchronized.
If cross-realm Kerberos
authentication is being
attempted, then you should
verify time synchronization
between the KDC in the
target realm and the KDC in
the client realm, as well.
0x22 KRB_AP_ERR_REPEAT The request is a replay This error indicates that a

specific authenticator
showed up twice the KDC
has detected that this
session ticket duplicates one
that it has already received.
0x23 KRB_AP_ERR_NOT_US The ticket is not for us The server has received a
ticket that was meant for a
different realm.
0x24 KRB_AP_ERR_BADMATCH The ticket and authenticator The KRB_TGS_REQ is being

do not match sent to the wrong KDC.
There is an account
mismatch during protocol
transition.
0x25 KRB_AP_ERR_SKEW The clock skew is too great This error is logged if a client
computer sends a
timestamp whose value
differs from that of the
servers timestamp by more
than the number of minutes
found in the Maximum
tolerance for computer clock
synchronization setting in
Kerberos policy.
0x26 KRB_AP_ERR_BADADDR Network address in network Session tickets MAY include

layer header doesn't match the addresses from which
address inside ticket they are valid. This error can
occur if the address of the
computer sending the ticket
is different from the valid
address in the ticket. A
possible cause of this could
be an Internet Protocol (IP)
address change. Another
possible cause is when a
ticket is passed through a
proxy server or NAT. The
client is unaware of the
address scheme used by the
proxy server, so unless the
program caused the client
to request a proxy server
ticket with the proxy server's
source address, the ticket
could be invalid.
0x27 KRB_AP_ERR_BADVERSION Protocol version numbers When an application

don't match (PVNO) receives a KRB_SAFE
message, it verifies it. If any
error occurs, an error code is
reported for use by the
application.
The message is first checked
by verifying that the
protocol version and type
fields match the current
version and KRB_SAFE,
respectively. A mismatch
generates a
KRB_AP_ERR_BADVERSION.
details.
0x28 KRB_AP_ERR_MSG_TYPE Message type is This message is generated

unsupported when target server finds
that message format is
wrong. This applies to
KRB_AP_REQ, KRB_SAFE,
KRB_PRIV and KRB_CRED
messages.
This error also generated if
use of UDP protocol is being
attempted with User-to-
User authentication.
0x29 KRB_AP_ERR_MODIFIED Message stream modified The authentication data was

and checksum didn't match encrypted with the wrong
key for the intended server.
The authentication data was
modified in transit by a
hardware or software error,
or by an attacker.
The client sent the
authentication data to the
wrong server because
incorrect DNS data caused
the client to send the
request to the wrong server.
The client sent the
wrong server because DNS
data was out-of-date on the
client.
0x2A KRB_AP_ERR_BADORDER Message out of order This event generates for

(possible tampering) KRB_SAFE and KRB_PRIV
messages if an incorrect
sequence number is
included, or if a sequence
number is expected but not
present. See RFC4120 for
more details.
0x2C KRB_AP_ERR_BADKEYVER Specified version of key is This error might be

not available generated on server side
during receipt of invalid
KRB_AP_REQ message. If the
key version indicated by the
Ticket in the KRB_AP_REQ is
not one the server can use
(e.g., it indicates an old key,
and the server no longer
possesses a copy of the old
key), the
KRB_AP_ERR_BADKEYVER
error is returned.
0x2D KRB_AP_ERR_NOKEY Service key not available This error might be

generated on server side
KRB_AP_REQ message.
Because it is possible for the
server to be registered in
multiple realms, with
different keys in each, the
realm field in the
unencrypted portion of the
ticket in the KRB_AP_REQ is
used to specify which secret
key the server should use to
decrypt that ticket. The
KRB_AP_ERR_NOKEY error
code is returned if the server
doesn't have the proper key
to decipher the ticket.
0x2E KRB_AP_ERR_MUT_FAIL Mutual authentication failed No information.
0x2F KRB_AP_ERR_BADDIRECTIO Incorrect message direction No information.

N
0x30 KRB_AP_ERR_METHOD Alternative authentication According RFC4120 this

method required error message is obsolete.
0x31 KRB_AP_ERR_BADSEQ Incorrect sequence number No information.

in message
0x32 KRB_AP_ERR_INAPP_CKSUM Inappropriate type of When KDC receives

checksum in message KRB_TGS_REQ message it
(checksum may be decrypts it, and after that,
unsupported) the user-supplied checksum
in the Authenticator MUST
be verified against the
contents of the request. The
message MUST be rejected
either if the checksums do
not match (with an error
code of
KRB_AP_ERR_MODIFIED) or
if the checksum is not
collision-proof (with an error
code of
KRB_AP_ERR_INAPP_CKSUM
).
0x33 KRB_AP_PATH_NOT_ACCEP Desired path is unreachable No information.

TED
0x34 KRB_ERR_RESPONSE_TOO_B Too much data The size of a ticket is too

IG large to be transmitted
reliably via UDP. In a
Windows environment, this
message is purely
informational. A computer
running a Windows
operating system will
automatically try TCP if UDP
fails.
0x3C KRB_ERR_GENERIC Generic error Group membership has

overloaded the PAC.
Multiple recent password
changes have not
propagated.
Crypto subsystem error
caused by running out of
memory.
SPN too long.
SPN has too many parts.
0x3D KRB_ERR_FIELD_TOOLONG Field is too long for this Each request

implementation (KRB_KDC_REQ) and
response (KRB_KDC_REP or
KRB_ERROR) sent over the
TCP stream is preceded by
the length of the request as
4 octets in network byte
order. The high bit of the
length is reserved for future
expansion and MUST
currently be set to zero. If a
KDC that does not
understand how to interpret
a set high bit of the length
encoding receives a request
with the high order bit of
the length set, it MUST
return a KRB-ERROR
message with the error
KRB_ERR_FIELD_TOOLONG
and MUST close the TCP
stream.
0x3E KDC_ERR_CLIENT_NOT_TRU The client trust failed or is This typically happens when
STED not implemented users smart-card certificate
is revoked or the root
Certification Authority that
issued the smart card
certificate (in a chain) is not
trusted by the domain
controller.
0x3F KDC_ERR_KDC_NOT_TRUSTE The KDC server trust failed The trustedCertifiers field
D or could not be verified contains a list of certification
authorities trusted by the
client, in the case that the
client does not possess the
KDC's public key certificate.
If the KDC has no certificate
signed by any of the
trustedCertifiers, then it
returns an error of type
KDC_ERR_KDC_NOT_TRUSTE
D. See RFC1510 for more
details.
0x40 KDC_ERR_INVALID_SIG The signature is invalid This error is related to

PKINIT. If a PKI trust
relationship exists, the KDC
then verifies the client's
signature on AuthPack (TGT
request signature). If that
fails, the KDC returns an
error message of type
KDC_ERR_INVALID_SIG.
0x41 KDC_ERR_KEY_TOO_WEAK A higher encryption level is If the clientPublicValue field

needed is filled in, indicating that the
client wishes to use Diffie-
Hellman key agreement,
then the KDC checks to see
that the parameters satisfy
its policy. If they do not
(e.g., the prime size is
insufficient for the expected
encryption type), then the
KDC sends back an error
message of type
KDC_ERR_KEY_TOO_WEAK.
0x42 KRB_AP_ERR_USER_TO_USE User-to-user authorization In the case that the client

R_REQUIRED is required application doesn't know
that a service requires user-
to-user authentication, and
requests and receives a
conventional KRB_AP_REP,
the client will send the
KRB_AP_REP request, and
the server will respond with
a KRB_ERROR token as
described in RFC1964, with
a msg-type of
KRB_AP_ERR_USER_TO_USE
R_REQUIRED.
0x43 KRB_AP_ERR_NO_TGT No TGT was presented or In user-to-user

available authentication if the service
does not possess a ticket
granting ticket, it should
return the error
KRB_AP_ERR_NO_TGT.
0x44 KDC_ERR_WRONG_REALM Incorrect domain or Although this error rarely

principal occurs, it occurs when a
client presents a cross-realm
TGT to a realm other than
the one specified in the TGT.
Typically, this results from
incorrectly configured DNS.
Table 3. TGT/TGS issue error codes.
Ticket Encryption Type [Type = HexInt32]: the cryptographic suite that was used for issued TGT.
Table 4. Kerberos encryption types

TYPE TYPE NAME DESCRIPTION
0x1 DES-CBC-CRC Disabled by default starting from

Windows 7 and Windows Server 2008
R2.
0x3 DES-CBC-MD5 Disabled by default starting from

R2.
0x11 AES128-CTS-HMAC-SHA1-96 Supported starting from Windows

Server 2008 and Windows Vista.

0x17 RC4-HMAC Default suite for operating systems

before Windows Server 2008 and
Windows Vista.
0x18 RC4-HMAC-EXP Default suite for operating systems

Windows Vista.
0xFFFFFFFF or 0xffffffff - This type shows in Audit Failure events.
Pre-Authentication Type [Type = UnicodeString]: the code number of pre-Authentication type which was
used in TGT request.
Table 5. Kerberos Pre-Authentication types.

0 - Logon without Pre-Authentication.
2 PA-ENC-TIMESTAMP This is a normal type for standard

password authentication.
11 PA-ETYPE-INFO The ETYPE-INFO pre-authentication

type is sent by the KDC in a KRB-
ERROR indicating a requirement for
additional pre-authentication. It is
usually used to notify a client of which
key to use for the encryption of an
encrypted timestamp for the purposes
of sending a PA-ENC-TIMESTAMP pre-
authentication value.
Never saw this Pre-Authentication Type
in Microsoft Active Directory
environment.
15 PA-PK-AS-REP_OLD Used for Smart Card logon

authentication.
17 PA-PK-AS-REP This type should also be used for Smart

Card authentication, but in certain
Active Directory environments, it is
never seen.
19 PA-ETYPE-INFO2 The ETYPE-INFO2 pre-authentication

Never saw this Pre-Authentication Type
in Microsoft Active Directory
environment.
20 PA-SVR-REFERRAL-INFO Used in KDC Referrals tickets.
138 PA-ENCRYPTED-CHALLENGE Logon using Kerberos Armoring (FAST).

Supported starting from Windows
Server 2012 domain controllers and
Windows 8 clients.
- This type shows in Audit Failure events.
Certificate Information:
Certificate Issuer Name [Type = UnicodeString]: the name of the Certification Authority that issued the
smart card certificate. Populated in Issued by field in certificate.
Certificate Serial Number [Type = UnicodeString]: smart card certificates serial number. Can be found in
Serial number field in the certificate.
Certificate Thumbprint [Type = UnicodeString]: smart card certificates thumbprint. Can be found in
Thumbprint field in the certificate.

For 4768(S, F): A Kerberos authentication ticket (TGT) was requested.
High-value accounts: You might have high-value domain or Monitor this event with the User ID that corresponds to
local accounts for which you need to monitor each action. the high-value account or accounts.
requirements for detecting anomalies or monitoring potential User ID (with other information) to monitor how or when a
malicious actions. For example, you might need to monitor particular account is being used.
for use of an account outside of working hours.
Non-active accounts: You might have non-active, disabled, Monitor this event with the User ID that corresponds to
or guest accounts, or other accounts that should never be the accounts that should never be used.
used.
accounts that are the only ones allowed to perform actions the User ID for accounts that are outside the whitelist.
corresponding to particular events.
External accounts: You might be monitoring accounts from Monitor this event for the Supplied Realm Name
another domain, or external accounts that are not allowed corresponding to another domain or external location.
to perform certain actions (represented by certain specific
events).
Account naming conventions: Your organization might Monitor User ID for names that dont comply with naming
have specific naming conventions for account names. conventions.
You can track all 4768 events where the Client Address is not from your internal IP range or not from
private IP ranges.
If you know that Account Name should be used only from known list of IP addresses, track all Client
Address values for this Account Name in 4768 events. If Client Address is not from the whitelist,
generate the alert.
All Client Address = ::1 means local authentication. If you know the list of accounts which should log on to
the domain controllers, then you need to monitor for all possible violations, where Client Address = ::1
and Account Name is not allowed to log on to any domain controller.
All 4768 events with Client Port field value > 0 and < 1024 should be examined, because a well-known
port was used for outbound connection.
Also consider monitoring the fields shown in the following table, to discover the issues listed:
FIELD ISSUE TO DISCOVER
Certificate Issuer Name Certification authority name is not from your PKI
infrastructure.
Certificate Issuer Name Certification authority name is not authorized to issue smart
card authentication certificates.
Pre-Authentication Type Value is 0, which means that pre-authentication was not

used. All accounts should use Pre-Authentication, except
accounts configured with Do not require Kerberos
preauthentication, which is a security risk. For more
information, see Table 5. Kerberos Pre-Authentication types.
Pre-Authentication Type Value is not 15 when account must use a smart card for
authentication. For more information, see Table 5. Kerberos
Pre-Authentication types.
Pre-Authentication Type Value is not 2 when only standard password authentication is

in use in the organization. For more information, see Table 5.
Kerberos Pre-Authentication types.
Pre-Authentication Type Value is not 138 when Kerberos Armoring is enabled for all
Kerberos communications in the organization. For more
Ticket Encryption Type Value is 0x1 or 0x3, which means the DES algorithm was
used. DES should not be in use, because of low security and
known vulnerabilities. It is disabled by default starting from
Windows 7 and Windows Server 2008 R2. For more
information, see Table 4. Kerberos encryption types.
Ticket Encryption Type Starting with Windows Vista and Windows Server 2008,
monitor for values other than 0x11 and 0x12. These are the
expected values, starting with these operating systems, and
represent AES-family algorithms. For more information, see
Table 4. Kerberos encryption types.
Result Code 0x6 (The username doesn't exist), if you see, for example N
events in last N minutes. This can be an indicator of account
enumeration attack, especially for highly critical accounts.
Result Code 0x7 (Server not found in Kerberos database). This error can
occur if the domain controller cannot find the server's name
in Active Directory.
Result Code 0x8 (Multiple principal entries in KDC database). This will help
you to find duplicate SPNs faster.
Result Code 0x9 (The client or server has a null key (master key)). This
error can help you to identify problems with Kerberos
authentication faster.
Result Code 0xA (Ticket (TGT) not eligible for postdating). Microsoft
systems should not request postdated tickets. These events
could help identify anomaly activity.
Result Code 0xC (Requested start time is later than end time), if you see,
for example N events in last N minutes. This can be an
indicator of an account compromise attempt, especially for
Result Code 0xE (KDC has no support for encryption type). In general, this
error occurs when the KDC or a client receives a packet that it
cannot decrypt. Monitor for these events because this should
not happen in a standard Active Directory environment.
Result Code 0xF (KDC has no support for checksum type). Monitor for
these events because this should not happen in a standard
Active Directory environment.
Result Code 0x12 (Client's credentials have been revoked), if you see, for
example N events in last N minutes. This can be an indicator
of anomaly activity or brute-force attack, especially for highly
critical accounts.
Result Code 0x1F (Integrity check on decrypted field failed). The

authenticator was encrypted with something other than the
session key. The result is that the KDC cannot decrypt the
TGT. The modification of the message could be the result of
an attack or it could be because of network noise.
Result Code 0x22 (The request is a replay). This error indicates that a
specific authenticator showed up twicethe KDC has
detected that this session ticket duplicates one that it has
already received. It could be a sign of attack attempt.
Result Code 0x29 (Message stream modified and checksum didn't match).
The authentication data was encrypted with the wrong key
for the intended server. The authentication data was modified
in transit by a hardware or software error, or by an attacker.
Monitor for these events because this should not happen in a
standard Active Directory environment.
Result Code 0x3C (Generic error). This error can help you more quickly
identify problems with Kerberos authentication.
Result Code 0x3E (The client trust failed or is not implemented). This error
helps you identify logon attempts with revoked certificates
and the situations when the root Certification Authority that
issued the smart card certificate (through a chain) is not
trusted by a domain controller.
Result Code 0x3F, 0x40, 0x41 errors. These errors can help you more
quickly identify smart-card related problems with Kerberos
authentication.
4771(F): Kerberos pre-authentication failed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Kerberos
Authentication Service
Event Description:
This event generates every time the
Key Distribution Center fails to issue a
Kerberos Ticket Granting Ticket (TGT).
This can occur when a domain
controller doesnt have a certificate
installed for smart card authentication
(for example, with a Domain
Controller or Domain Controller
Authentication template), the users
password has expired, or the wrong
password was provided.
This event generates only on domain
controllers.
This event is not generated if Do not
require Kerberos preauthentication
option is set for the account.
Note For recommendations, see

Security Monitoring
Recommendations for this event.
Event XML:
- <System>
<Level>0</Level>
<Task>14339</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ServiceName">krbtgt/CONTOSO.LOCAL</Data>
<Data Name="PreAuthType">15</Data>
<Data Name="CertIssuerName" />
<Data Name="CertSerialNumber" />
<Data Name="CertThumbprint" />
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Security ID [Type = SID]: SID of account object for which (TGT) ticket was requested. Event Viewer
automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see
the source data in the event.
For example: CONTOSO\dadmin or CONTOSO\WIN81$.
Account Name: [Type = UnicodeString]: the name of account, for which (TGT) ticket was requested.
Computer account name ends with $ character.
User account example: dadmin
Service Name [Type = UnicodeString]: the name of the service in the Kerberos Realm to which TGT
request was sent. Typically has one of the following formats:
krbtgt/DOMAIN_NETBIOS_NAME. Example: krbtgt/CONTOSO
krbtgt/DOMAIN_FULL_NAME. Example: krbtgt/CONTOSO.LOCAL
Client Address [Type = UnicodeString]: IP address of the computer from which the TGT request was
::1 - localhost.
Client Port [Type = UnicodeString]: source port number of client network connection (TGT request
connection).
Additional Information:
Ticket Options: [Type = HexInt32]: this is a set of different Ticket Flags in hexadecimal format.
Example:
Binary view: 01000000100000010000000000010000
Using MSB 0 bit numbering we have bit 1, 8, 15 and 27 set = Forwardable, Renewable,
Canonicalize, Renewable-ok.

0 Reserved -

presented TGT.


one in the TGT.



7 Invalid This flag indicates that a ticket is

invalid, and it must be validated by the
KDC before use. Application servers
must reject tickets which have this flag
set.


TGT.


another KDC.



AS-REQ or TGS-REQ.
16-25 Unused -

required to honor
option.
supported by KILE.

acceptable if a ticket with the
requested life cannot otherwise be
provided, in which case a renewable
ticket may be issued with a renew-till
equal to the requested end time. The
value of the renew-till field may still be
limited by local limits, or limits selected
by the individual principal or server.
29 Unused -

valid. This option will only be honored
if the ticket to be renewed has its

supported by KILE.
Table 6. Kerberos ticket flags.
Failure Code [Type = HexInt32]: hexadecimal failure code of failed TGT issue operation. The table below
contains the list of the most common error codes for this event:
This can happen because
the wrong certification
authority (CA) is being
queried or the proper CA
cannot be contacted in
order to get Domain
certificates for the domain
controller.
templates).


Pre-Authentication Type [Type = UnicodeString]: the code of pre-Authentication type which was used in
TGT request.
Table 5. Kerberos Pre-Authentication types.
0 - Logon without Pre-Authentication.
2 PA-ENC-TIMESTAMP This is a normal type for standard

password authentication.
11 PA-ETYPE-INFO The ETYPE-INFO pre-authentication

Never saw this Pre-Authentication
Type in Microsoft Active Directory
environment.
15 PA-PK-AS-REP_OLD Used for Smart Card logon

authentication.
17 PA-PK-AS-REP This type should also be used for Smart

Card authentication, but in certain
Active Directory environments, it is
never seen.
19 PA-ETYPE-INFO2 The ETYPE-INFO2 pre-authentication

Never saw this Pre-Authentication
Type in Microsoft Active Directory
environment.
20 PA-SVR-REFERRAL-INFO Used in KDC Referrals tickets.
138 PA-ENCRYPTED-CHALLENGE Logon using Kerberos Armoring (FAST).

Supported starting from Windows
Server 2012 domain controllers and
Windows 8 clients.
- This type shows in Audit Failure events.
Certificate Information:
Certificate Issuer Name [Type = UnicodeString]: the name of Certification Authority which issued smart
card certificate. Populated in Issued by field in certificate. Always empty for 4771 events.
Certificate Serial Number [Type = UnicodeString]: smart card certificates serial number. Can be found
in Serial number field in the certificate. Always empty for 4771 events.
Certificate Thumbprint [Type = UnicodeString]: smart card certificates thumbprint. Can be found in
Thumbprint field in the certificate. Always empty for 4771 events.

For 4771(F): Kerberos pre-authentication failed.
High-value accounts: You might have high-value domain Monitor this event with the Security ID that corresponds
or local accounts for which you need to monitor each action. to the high-value account or accounts.
Examples of high-value accounts are database
administrators, built-in local administrator account, domain
administrators, service accounts, domain controller accounts
and so on.
Anomalies or malicious actions: You might have specific When you monitor for anomalies or malicious actions, use
requirements for detecting anomalies or monitoring the Security ID (with other information) to monitor how
potential malicious actions. For example, you might need to or when a particular account is being used.
monitor for use of an account outside of working hours.
Non-active accounts: You might have non-active, disabled, Monitor this event with the Security ID that corresponds
or guest accounts, or other accounts that should never be to the accounts that should never be used.
used.
accounts that are the only ones allowed to perform actions the Security ID for accounts that are outside the whitelist.
corresponding to particular events.
Account naming conventions: Your organization might Monitor Subject\Account Name for names that dont
have specific naming conventions for account names. comply with naming conventions.
private IP ranges.
If you know that Account Name should be used only from known list of IP addresses, track all Client
Address values for this Account Name in 4771 events. If Client Address is not from the whitelist,
generate the alert.
All Client Address = ::1 means local authentication. If you know the list of accounts which should log on
to the domain controllers, then you need to monitor for all possible violations, where Client Address = ::1
and Account Name is not allowed to log on to any domain controller.
Also monitor the fields shown in the following table, to discover the issues listed:
Pre-Authentication Type Value is not 15 when account must use a smart card for
authentication. For more information, see Table 5. Kerberos
Pre-Authentication types.
Pre-Authentication Type Value is not 2 when only standard password authentication

is in use in the organization. For more information, see Table
5. Kerberos Pre-Authentication types.
Pre-Authentication Type Value is not 138 when Kerberos Armoring is enabled for all
Kerberos communications in the organization. For more
Result Code 0x10 (KDC has no support for PADATA type (pre-
authentication data)). This error can help you to more quickly
identify smart-card related problems with Kerberos
authentication.
Result Code 0x18 ((Pre-authentication information was invalid), if you see,

for example N events in last N minutes. This can be an
indicator of brute-force attack on the account password,
especially for highly critical accounts.
4772(F): A Kerberos authentication ticket request
failed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Kerberos Authentication Service
Audit Kerberos Service Ticket Operations
Applies to
Windows 10
Windows Server 2016
Audit Kerberos Service Ticket Operations determines whether the operating system generates security audit
events for Kerberos service ticket requests.
Events are generated every time Kerberos is used to authenticate a user who wants to access a protected network
resource. Kerberos service ticket operation audit events can be used to track user activity.
Event volume: Very High on Kerberos Key Distribution Center servers.
This subcategory contains events about issued TGSs and failed TGS requests.
STRONGER STRONGER
STRONGER STRONGER
Domain IF Yes Yes Yes Expected volume

Controller is very high on
domain
controllers.
IF - We
recommend
Success auditing,
because you will
see all Kerberos
Service Ticket
requests (TGS
requests), which
are part of service
use and access
requests by
specific accounts.
Also, you can see
the IP address
from which this
account
requested TGS,
when TGS was
requested, which
encryption type
was used, and so
on. For
recommendation
s for using and
analyzing the
collected
information, see
the Security
Monitoring
Recommendatio
ns sections.
We recommend
Failure auditing,
because you will
see all failed
requests and be
able to
investigate the
reason for failure.
You will also be
able to detect
Kerberos issues
or possible attack
attempts.

makes sense only
on domain
controllers.

makes sense only
on domain
controllers.
Events List:
4769(S, F): A Kerberos service ticket was requested.
4770(S): A Kerberos service ticket was renewed.
4773(F): A Kerberos service ticket request failed.
4769(S, F): A Kerberos service ticket was requested.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Kerberos Service
Ticket Operations
Event Description:
This event generates every time Key
Distribution Center gets a Kerberos
Ticket Granting Service (TGS) ticket
request.
controllers.
If TGS issue fails then you will see
Failure event with Failure Code field
not equal to 0x0.
You will typically see many Failure
events with Failure Code 0x20,
which simply means that a TGS
ticket has expired. These are
informational messages and have
little to no security relevance.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>14337</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">dadmin@CONTOSO.LOCAL</Data>
<Data Name="ServiceName">WIN2008R2$</Data>
<Data Name="LogonGuid">{F85C455E-C66E-205C-6B39-F6C60A7FE453}</Data>
<Data Name="TransmittedServices">-</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Account Name [Type = UnicodeString]: the User Principal Name (UPN) of the account that requested the
ticket. Computer account name ends with $ character in UPN. This field typically has the following value
format: user_account_name@FULL\_DOMAIN\_NAME.
User account example: dadmin@CONTOSO.LOCAL
Computer account example: WIN81$@CONTOSO.LOCAL
This parameter in this event is optional and can be empty in some cases.
Account Domain [Type = UnicodeString]: the name of the Kerberos Realm that Account Name belongs
to. This can appear in a variety of formats, including the following:
Logon GUID [Type = GUID]: a GUID that can help you correlate this event (on a domain controller) with
other events (on the target computer for which the TGS was issued) that can contain the same Logon
GUID. These events are 4624: An account was successfully logged on, 4648(S): A logon was attempted
using explicit credentials and 4964(S): Special groups have been assigned to a new logon.
This parameter might not be captured in the event, and in that case appears as {00000000-0000-0000-
0000-000000000000}.
Note GUID is an acronym for 'Globally Unique Identifier'. It is a 128-bit integer number used to identify
resources, activities or instances.
Service Name [Type = UnicodeString]: the name of the account or computer for which the TGS ticket was
requested.
Service ID [Type = SID]: SID of the account or computer object for which the TGS ticket was requested.
Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved,
you will see the source data in the event.
NULL SID this value shows in Failure events.
Client Address [Type = UnicodeString]: IP address of the computer from which the TGS request was
::1 - localhost.
Client Port [Type = UnicodeString]: source port number of client network connection (TGS request
connection).
Example:
Binary view: 01000000100000010000000000010000
Using MSB 0 bit numbering we have bit 1, 8, 15 and 27 set = Forwardable, Renewable, Canonicalize,
Renewable-ok.

0 Reserved -

presented TGT.


one in the TGT.






TGT.


another KDC.



AS-REQ or TGS-REQ.
16-25 Unused -

required to honor
option.
supported by KILE.

29 Unused -


supported by KILE.
## Table 4. Kerberos encryption types
Ticket Encryption Type: [Type = HexInt32]: the cryptographic suite that was used for issued TGS.

R2.

R2.



Windows Vista.

Windows Vista.
Failure Code [Type = HexInt32]: hexadecimal result code of TGS issue operation. The table below contains the
list of the most common error codes for this event:
0x0 KDC_ERR_NONE No error No errors were found.
0x1 KDC_ERR_NAME_EXP Client's entry in KDC No information.

0x2 KDC_ERR_SERVICE_EXP Server's entry in KDC No information.

0x3 KDC_ERR_BAD_PVNO Requested Kerberos version No information.

number not supported
0x4 KDC_ERR_C_OLD_MAST_KV Client's key encrypted in old No information.

NO master key
0x5 KDC_ERR_S_OLD_MAST_KV Server's key encrypted in old No information.

NO master key
0x6 KDC_ERR_C_PRINCIPAL_UN Client not found in Kerberos The username doesnt exist.
KNOWN database
0x7 KDC_ERR_S_PRINCIPAL_UN Server not found in This error can occur if the
KNOWN Kerberos database domain controller cannot
find the servers name in
Active Directory. This error is
similar to
KDC_ERR_C_PRINCIPAL_UN
KNOWN except that it
occurs when the server
name cannot be found.
0x8 KDC_ERR_PRINCIPAL_NOT_ Multiple principal entries in This error occurs if duplicate

UNIQUE KDC database principal names exist.
Unique principal names are
crucial for ensuring mutual
authentication. Thus,
duplicate principal names
are strictly forbidden, even
across multiple realms.
Without unique principal
names, the client has no way
of ensuring that the server it
is communicating with is the
correct one.
0x9 KDC_ERR_NULL_KEY The client or server has a No master key was found
null key (master key) for client or server. Usually it
means that administrator
should reset the password
on the account.
0xA KDC_ERR_CANNOT_POSTD Ticket (TGT) not eligible for This error can occur if a
ATE postdating client requests postdating of
a Kerberos ticket. Postdating
is the act of requesting that
a tickets start time be set
into the future.
It also can occur if there is a
time difference between the
client and the KDC.
0xB KDC_ERR_NEVER_VALID Requested start time is later There is a time difference

than end time between the KDC and the
client.
0xC KDC_ERR_POLICY Requested start time is later This error is usually the
than end time result of logon restrictions in
place on a users account.
For example workstation
restriction, smart card
authentication requirement
or logon time restriction.
0xD KDC_ERR_BADOPTION KDC cannot accommodate Impending expiration of a

requested option TGT.
The SPN to which the client
is attempting to delegate
credentials is not in its
Allowed-to-delegate-to list
0xE KDC_ERR_ETYPE_NOTSUPP KDC has no support for In general, this error occurs
encryption type when the KDC or a client
receives a packet that it
cannot decrypt.
0xF KDC_ERR_SUMTYPE_NOSUP KDC has no support for The KDC, server, or client
P checksum type receives a packet for which it
does not have a key of the
appropriate encryption type.
The result is that the
computer is unable to
decrypt the ticket.
This can happen because the
wrong certification authority
(CA) is being queried or the
proper CA cannot be
contacted.
templates).
4771. Kerberos pre-
0x11 KDC_ERR_TRTYPE_NO_SUPP KDC has no support for No information.

transited type
0x12 KDC_ERR_CLIENT_REVOKED Clients credentials have This might be because of an

been revoked explicit disabling or because
of other restrictions in place
on the account. For example:
account disabled, expired, or
locked out.
0x13 KDC_ERR_SERVICE_REVOKE Credentials for server have No information.

D been revoked
0x14 KDC_ERR_TGT_REVOKED TGT has been revoked Since the remote KDC may
change its PKCROSS key
while there are PKCROSS
tickets still active, it SHOULD
cache the old PKCROSS keys
until the last issued
PKCROSS ticket expires.
Otherwise, the remote KDC
will respond to a client with
a KRB-ERROR message of
type
KDC_ERR_TGT_REVOKED.
details.
0x15 KDC_ERR_CLIENT_NOTYET Client not yet validtry No information.

again later
0x16 KDC_ERR_SERVICE_NOTYET Server not yet validtry No information.

again later

4771. Kerberos pre-

4771. Kerberos pre-
0x19 KDC_ERR_PREAUTH_REQUIR Additional pre- This error often occurs in

ED authentication required UNIX interoperability
scenarios. MIT-Kerberos
clients do not request pre-
authentication when they
send a KRB_AS_REQ
message. If pre-
authentication is required
(the default), Windows
systems will send this error.
Most MIT-Kerberos clients
will respond to this error by
giving the pre-
authentication, in which case
the error can be ignored,
but some clients might not
respond in this way.
0x1A KDC_ERR_SERVER_NOMATC KDC does not know about No information.

H the requested server
0x1B KDC_ERR_SVC_UNAVAILABL KDC is unavailable No information.

E
0x1F KRB_AP_ERR_BAD_INTEGRIT Integrity check on decrypted The authenticator was

Y field failed encrypted with something
other than the session key.
The result is that the client
cannot decrypt the resulting
message. The modification
of the message could be the
result of an attack or it could
be because of network
noise.
0x20 KRB_AP_ERR_TKT_EXPIRED The ticket has expired The smaller the value for the
Maximum lifetime for user
ticket Kerberos policy
setting, the more likely it is
that this error will occur.
Because ticket renewal is
automatic, you should not
have to do anything if you
get this message.
0x21 KRB_AP_ERR_TKT_NYV The ticket is not yet valid The ticket presented to the
server is not yet valid (in
relationship to the server
time). The most probable
cause is that the clocks on
the KDC and the client are
not synchronized.
If cross-realm Kerberos
authentication is being
attempted, then you should
verify time synchronization
between the KDC in the
target realm and the KDC in
the client realm, as well.
0x22 KRB_AP_ERR_REPEAT The request is a replay This error indicates that a

specific authenticator
showed up twice the KDC
has detected that this
session ticket duplicates one
that it has already received.
0x23 KRB_AP_ERR_NOT_US The ticket is not for us The server has received a
ticket that was meant for a
different realm.
0x24 KRB_AP_ERR_BADMATCH The ticket and authenticator The KRB_TGS_REQ is being

do not match sent to the wrong KDC.
There is an account
mismatch during protocol
transition.
0x25 KRB_AP_ERR_SKEW The clock skew is too great This error is logged if a client
computer sends a
timestamp whose value
differs from that of the
servers timestamp by more
than the number of minutes
found in the Maximum
tolerance for computer clock
synchronization setting in
Kerberos policy.
0x26 KRB_AP_ERR_BADADDR Network address in network Session tickets MAY include

layer header doesn't match the addresses from which
address inside ticket they are valid. This error can
occur if the address of the
computer sending the ticket
is different from the valid
address in the ticket. A
possible cause of this could
be an Internet Protocol (IP)
address change. Another
possible cause is when a
ticket is passed through a
proxy server or NAT. The
client is unaware of the
address scheme used by the
proxy server, so unless the
program caused the client to
request a proxy server ticket
with the proxy server's
source address, the ticket
could be invalid.
0x27 KRB_AP_ERR_BADVERSION Protocol version numbers When an application

don't match (PVNO) receives a KRB_SAFE
message, it verifies it. If any
error occurs, an error code is
reported for use by the
application.
The message is first checked
by verifying that the
protocol version and type
fields match the current
version and KRB_SAFE,
respectively. A mismatch
generates a
KRB_AP_ERR_BADVERSION.
details.
0x28 KRB_AP_ERR_MSG_TYPE Message type is This message is generated

unsupported when target server finds
that message format is
wrong. This applies to
KRB_AP_REQ, KRB_SAFE,
KRB_PRIV and KRB_CRED
messages.
This error also generated if
use of UDP protocol is being
attempted with User-to-
User authentication.
0x29 KRB_AP_ERR_MODIFIED Message stream modified The authentication data was

and checksum didn't match encrypted with the wrong
key for the intended server.
The authentication data was
modified in transit by a
hardware or software error,
or by an attacker.
The client sent the
wrong server because
incorrect DNS data caused
the client to send the
request to the wrong server.
The client sent the
wrong server because DNS
data was out-of-date on the
client.
0x2A KRB_AP_ERR_BADORDER Message out of order This event generates for

(possible tampering) KRB_SAFE and KRB_PRIV
messages if an incorrect
sequence number is
included, or if a sequence
number is expected but not
present. See RFC4120 for
more details.
0x2C KRB_AP_ERR_BADKEYVER Specified version of key is This error might be

not available generated on server side
KRB_AP_REQ message. If the
key version indicated by the
Ticket in the KRB_AP_REQ is
not one the server can use
(e.g., it indicates an old key,
and the server no longer
possesses a copy of the old
key), the
KRB_AP_ERR_BADKEYVER
error is returned.
0x2D KRB_AP_ERR_NOKEY Service key not available This error might be

generated on server side
KRB_AP_REQ message.
Because it is possible for the
server to be registered in
multiple realms, with
different keys in each, the
realm field in the
unencrypted portion of the
ticket in the KRB_AP_REQ is
used to specify which secret
key the server should use to
decrypt that ticket. The
KRB_AP_ERR_NOKEY error
code is returned if the server
doesn't have the proper key
to decipher the ticket.
0x2E KRB_AP_ERR_MUT_FAIL Mutual authentication failed No information.
0x2F KRB_AP_ERR_BADDIRECTIO Incorrect message direction No information.

N
0x30 KRB_AP_ERR_METHOD Alternative authentication According RFC4120 this

method required error message is obsolete.
0x31 KRB_AP_ERR_BADSEQ Incorrect sequence number No information.

in message
0x32 KRB_AP_ERR_INAPP_CKSUM Inappropriate type of When KDC receives

checksum in message KRB_TGS_REQ message it
(checksum may be decrypts it, and after the
unsupported) user-supplied checksum in
the Authenticator MUST be
verified against the contents
of the request, and the
message MUST be rejected if
the checksums do not
match (with an error code of
KRB_AP_ERR_MODIFIED) or
if the checksum is not
collision-proof (with an error
code of
KRB_AP_ERR_INAPP_CKSUM
).
0x33 KRB_AP_PATH_NOT_ACCEP Desired path is unreachable No information.

TED
0x34 KRB_ERR_RESPONSE_TOO_B Too much data The size of a ticket is too

IG large to be transmitted
reliably via UDP. In a
Windows environment, this
message is purely
informational. A computer
running a Windows
operating system will
automatically try TCP if UDP
fails.
0x3C KRB_ERR_GENERIC Generic error Group membership has

overloaded the PAC.
Multiple recent password
changes have not
propagated.
Crypto subsystem error
caused by running out of
memory.
SPN too long.
SPN has too many parts.
0x3D KRB_ERR_FIELD_TOOLONG Field is too long for this Each request

implementation (KRB_KDC_REQ) and
response (KRB_KDC_REP or
KRB_ERROR) sent over the
TCP stream is preceded by
the length of the request as
4 octets in network byte
order. The high bit of the
length is reserved for future
expansion and MUST
currently be set to zero. If a
KDC that does not
understand how to interpret
a set high bit of the length
encoding receives a request
with the high order bit of
the length set, it MUST
return a KRB-ERROR
message with the error
KRB_ERR_FIELD_TOOLONG
and MUST close the TCP
stream.
0x3E KDC_ERR_CLIENT_NOT_TRU The client trust failed or is This typically happens when
STED not implemented users smart-card certificate
is revoked or the root
Certification Authority that
issued the smart card
certificate (in a chain) is not
trusted by the domain
controller.
0x3F KDC_ERR_KDC_NOT_TRUSTE The KDC server trust failed The trustedCertifiers field
D or could not be verified contains a list of certification
authorities trusted by the
client, in the case that the
client does not possess the
KDC's public key certificate.
If the KDC has no certificate
signed by any of the
trustedCertifiers, then it
returns an error of type
KDC_ERR_KDC_NOT_TRUSTE
D. See RFC1510 for more
details.
0x40 KDC_ERR_INVALID_SIG The signature is invalid This error is related to

PKINIT. If a PKI trust
relationship exists, the KDC
then verifies the client's
signature on AuthPack (TGT
request signature). If that
fails, the KDC returns an
error message of type
KDC_ERR_INVALID_SIG.
0x41 KDC_ERR_KEY_TOO_WEAK A higher encryption level is If the clientPublicValue field

needed is filled in, indicating that the
client wishes to use Diffie-
Hellman key agreement,
then the KDC checks to see
that the parameters satisfy
its policy. If they do not (e.g.,
the prime size is insufficient
for the expected encryption
type), then the KDC sends
back an error message of
type
KDC_ERR_KEY_TOO_WEAK.
0x42 KRB_AP_ERR_USER_TO_USE User-to-user authorization In the case that the client

R_REQUIRED is required application doesn't know
that a service requires user-
to-user authentication, and
requests and receives a
conventional KRB_AP_REP,
the client will send the
KRB_AP_REP request, and
the server will respond with
a KRB_ERROR token as
described in RFC1964, with
a msg-type of
KRB_AP_ERR_USER_TO_USER
_REQUIRED.
0x43 KRB_AP_ERR_NO_TGT No TGT was presented or In user-to-user

available authentication if the service
does not possess a ticket
granting ticket, it should
return the error
KRB_AP_ERR_NO_TGT.
0x44 KDC_ERR_WRONG_REALM Incorrect domain or Although this error rarely

principal occurs, it occurs when a
client presents a cross-realm
TGT to a realm other than
the one specified in the TGT.
Typically, this results from
incorrectly configured DNS.
Transited Services [Type = UnicodeString]: this field contains list of SPNs which were requested if Kerberos
delegation was used.
Note Service Principal Name (SPN) is the name by which a client uniquely identifies an instance of a
service. If you install multiple instances of a service on computers throughout a forest, each instance must
have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients
might use for authentication. For example, an SPN always includes the name of the host computer on which
the service instance is running, so a service instance might register an SPN for each name or alias of its host.

For 4769(S, F): A Kerberos service ticket was requested.
High-value accounts: You might have high-value domain or Monitor this event with the Account Information\Account
local accounts for which you need to monitor each action. Name that corresponds to the high-value account or
Examples of high-value accounts are database administrators, accounts.
requirements for detecting anomalies or monitoring potential Account Information\Account Name (with other
malicious actions. For example, you might need to monitor information) to monitor how or when a particular account is
for use of an account outside of working hours. being used.
Non-active accounts: You might have non-active, disabled, Monitor this event with the Account Information\Account
or guest accounts, or other accounts that should never be Name that corresponds to the accounts that should never
used. be used.
External accounts: You might be monitoring accounts from Monitor this event for the Account Information\Account
another domain, or external accounts that are not allowed Domain corresponding to another domain or external
to perform certain actions (represented by certain specific location.
events).
Restricted-use computers or devices: You might have Monitor the target Computer: (or other target device) for
certain computers, machines, or devices on which certain actions performed by the Account Information\Account
people (accounts) should not typically perform any actions. Name that you are concerned about.
Account naming conventions: Your organization might Monitor User ID for names that dont comply with naming
have specific naming conventions for account names. conventions.
If you know that Account Name should never request any tickets for (that is, never get access to) a
particular computer account or service account, monitor for 4769 events with the corresponding Account
Name and Service ID fields.
private IP ranges.
If you know that Account Name should be able to request tickets (should be used) only from a known
whitelist of IP addresses, track all Client Address values for this Account Name in 4769 events. If Client
Address is not from your whitelist of IP addresses, generate the alert.
All Client Address = ::1 means local TGS requests, which means that the Account Name logged on to a
domain controller before making the TGS request. If you have a whitelist of accounts allowed to log on to
domain controllers, monitor events with Client Address = ::1 and any Account Name outside the
whitelist.
Monitor for a Ticket Encryption Type of 0x1 or 0x3, which means the DES algorithm was used. DES
should not be in use, because of low security and known vulnerabilities. It is disabled by default starting
from Windows 7 and Windows Server 2008 R2.
Starting with Windows Vista and Windows Server 2008, monitor for a Ticket Encryption Type other than
0x11 and 0x12. These are the expected values, starting with these operating systems, and represent AES-
family algorithms.
If you have a list of important Failure Codes, monitor for these codes.
4770(S): A Kerberos service ticket was renewed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Kerberos Service Ticket
Operations
Event Description:
This event generates for every Ticket Granting
Service (TGS) ticket renewal.
controllers.
Note For recommendations, see Security

Monitoring Recommendations for this event.
Event XML:
- <System>
<Level>0</Level>
<Task>14337</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">WIN2008R2$@CONTOSO.LOCAL</Data>
<Data Name="ServiceName">krbtgt</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Account Name [Type = UnicodeString]: the User Principal Name (UPN) of the account that requested ticket
renewal. Computer account name ends with $ character in UPN. This field typically has the following value
format: user_account_name@FULL\_DOMAIN\_NAME.
User account example: dadmin@CONTOSO.LOCAL
Computer account example: WIN81$@CONTOSO.LOCAL
Account Domain [Type = UnicodeString]: the name of the Kerberos Realm that Account Name belongs
to. This can appear in a variety of formats, including the following:
Service Name [Type = UnicodeString]: the name of the account or computer for which the TGS ticket was
renewed.
Service ID [Type = SID]: SID of the account or computer object for which the TGS ticket was renewed. Event
Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will
see the source data in the event.
controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user
from the database and places it in the access token for that user. The system uses the SID in the access token to
identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique
identifier for a user or group, it cannot ever be used again to identify another user or group. For more
information about SIDs, see Security identifiers.
Client Address [Type = UnicodeString]: IP address of the computer from which the TGS renewal request
was received. Formats vary, and include the following:
::1 - localhost.
Client Port [Type = UnicodeString]: source port number of client network connection (TGS renewal request
connection).
Example:
Binary view: 01000000100000010000000000010000
Using MSB 0 bit numbering we have bit 1, 8, 15 and 27 set = Forwardable, Renewable, Canonicalize,
Renewable-ok.

0 Reserved -

presented TGT.


one in the TGT.






the authentication service (AS) exchange
and not issued based on a TGT.


protocol. KDCs MUST NOT issue a ticket
with this flag set. KDCs SHOULD NOT
preserve this flag if it is set by another
KDC.



AS-REQ or TGS-REQ.
16-25 Unused -

required to honor
option.
supported by KILE.

29 Unused -


a postdated ticket. Should not be in use,
because postdated tickets are not
supported by KILE.
Ticket Encryption Type: [Type = HexInt32]: the cryptographic suite that was used in renewed TGS.

R2.

R2.



Windows Vista.

Windows Vista.

For 4770(S): A Kerberos service ticket was renewed.
This event typically has informational only purpose.
4773(F): A Kerberos service ticket request failed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Kerberos Service Ticket Operations
Audit Other Account Logon Events
Applies to
Windows 10
Windows Server 2016
General Subcategory Information:
This auditing subcategory does not contain any events. It is intended for future use.
STRONGER STRONGER
Domain No No No No This auditing

Controller subcategory does
not contain any
events. It is
intended for
future use, and
there is no
reason to enable
it.
Member Server No No No No This auditing

subcategory does
not contain any
events. It is
intended for
future use, and
there is no
reason to enable
it.
Workstation No No No No This auditing

subcategory does
not contain any
events. It is
intended for
future use, and
there is no
reason to enable
it.
Audit Application Group Management
Applies to
Windows 10
Windows Server 2016
Audit Application Group Management generates events for actions related to application groups, such as group
creation, modification, addition or removal of group member and some other actions.
Application groups are used by Authorization Manager.
Audit Application Group Management subcategory is out of scope of this document, because Authorization
Manager is very rarely in use and it is deprecated starting from Windows Server 2012.
STRONGER STRONGER
Domain - - - - This subcategory

Controller is outside the
scope of this
document.
Member Server - - - - This subcategory

is outside the
scope of this
document.
Workstation - - - - This subcategory

is outside the
scope of this
document.
4783(S): A basic application group was created.

4784(S): A basic application group was changed.
4785(S): A member was added to a basic application group.
4786(S): A member was removed from a basic application group.
4787(S): A non-member was added to a basic application group.
4788(S): A non-member was removed from a basic application group.
4789(S): A basic application group was deleted.
4790(S): An LDAP query group was created.
4791(S): An LDAP query group was changed.
4792(S): An LDAP query group was deleted.
Audit Computer Account Management
Applies to
Windows 10
Windows Server 2016
Audit Computer Account Management determines whether the operating system generates audit events when a
computer account is created, changed, or deleted.
This policy setting is useful for tracking account-related changes to computers that are members of a domain.
Event volume: Low on domain controllers.
This subcategory allows you to audit events generated by changes to computer accounts such as when a computer
account is created, changed, or deleted.
STRONGER STRONGER
STRONGER STRONGER
Domain Yes No Yes No We recommend

Controller monitoring
changes to critical
computer objects
in Active
Directory, such as
domain
controllers,
administrative
workstations, and
critical servers.
It's especially
important to be
informed if any
critical computer
account objects
are deleted.
Additionally,
events in this
subcategory will
give you
information
about who
deleted, created,
or modified a
computer object,
and when the
action was taken.
Typically volume
of these events is
low on domain
controllers.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.

generates events
only on domain
controllers.

generates events
only on domain
controllers.
Events List:
4741(S): A computer account was created.
4742(S): A computer account was changed.
4743(S): A computer account was deleted.
4741(S): A computer account was created.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Computer Account
Management
Event Description:
This event generates every time a new
computer object is created.
controllers.

Event XML:
- <System>
<Level>0</Level>
<Task>13825</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">WIN81$</Data>
<Data Name="TargetDomainName">CONTOSO</Data>
<Data Name="SubjectUserSid">S-1-5-21-3457937927-2839227994-823803824-1104</Data>
<Data Name="SubjectUserName">dadmin</Data>
<Data Name="SubjectDomainName">CONTOSO</Data>
<Data Name="SubjectLogonId">0xc88b2</Data>
<Data Name="PrivilegeList">-</Data>
<Data Name="SamAccountName">WIN81$</Data>
<Data Name="DisplayName">-</Data>
<Data Name="UserPrincipalName">-</Data>
<Data Name="HomeDirectory">-</Data>
<Data Name="HomePath">-</Data>
<Data Name="ScriptPath">-</Data>
<Data Name="ProfilePath">-</Data>
<Data Name="UserWorkstations">-</Data>
<Data Name="PasswordLastSet">8/12/2015 11:41:39 AM</Data>
<Data Name="AccountExpires">%%1794</Data>
<Data Name="PrimaryGroupId">515</Data>
<Data Name="AllowedToDelegateTo">-</Data>
<Data Name="OldUacValue">0x0</Data>
<Data Name="NewUacValue">0x80</Data>
<Data Name="UserAccountControl">%%2087</Data>
<Data Name="UserParameters">-</Data>
<Data Name="SidHistory">-</Data>
<Data Name="LogonHours">%%1793</Data>
<Data Name="DnsHostName">Win81.contoso.local</Data>
<Data Name="ServicePrincipalNames">HOST/Win81.contoso.local RestrictedKrbHost/Win81.contoso.local HOST/WIN81
RestrictedKrbHost/WIN81</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the create Computer object operation. Event Viewer
automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the
source data in the event.
Account Name [Type = UnicodeString]: the name of the account that requested the create Computer
object operation.
Account Domain [Type = UnicodeString]: subjects domain name. Formats vary, and include the following:
For some well-known security principals, such as LOCAL SERVICE or ANONYMOUS LOGON, the
value of this field is NT AUTHORITY.
Logon ID [Type = HexInt64]: hexadecimal value that can help you correlate this event with recent events
that might contain the same Logon ID, for example, 4624: An account was successfully logged on.
New Computer Account:
Security ID [Type = SID]: SID of created computer account. Event Viewer automatically tries to resolve SIDs
and show the account name. If the SID cannot be resolved, you will see the source data in the event.
Account Name [Type = UnicodeString]: the name of the computer account that was created. For example:
WIN81$
Account Domain [Type = UnicodeString]: domain name of created computer account. Formats vary, and
include the following:
Attributes:
SAM Account Name [Type = UnicodeString]: logon name for account used to support clients and servers
from previous versions of Windows (pre-Windows 2000 logon name). The value of sAMAccountName
attribute of new computer object. For example: WIN81$.
Display Name [Type = UnicodeString]: the value of displayName attribute of new computer object. It is a
name displayed in the address book for a particular account (typically user account). This is usually the
combination of the user's first name, middle initial, and last name. For computer objects, it is optional, and
typically is not set. You can change this attribute by using Active Directory Users and Computers, or through
a script, for example. This parameter might not be captured in the event, and in that case appears as -.
User Principal Name [Type = UnicodeString]: internet-style login name for the account, based on the
Internet standard RFC 822. By convention this should map to the account's email name. This parameter
contains the value of userPrincipalName attribute of new computer object. For computer objects, it is
optional, and typically is not set. You can change this attribute by using Active Directory Users and
Computers, or through a script, for example. This parameter might not be captured in the event, and in that
case appears as -.
Home Directory [Type = UnicodeString]: user's home directory. If homeDrive attribute is set and specifies
a drive letter, homeDirectory should be a UNC path. The path must be a network UNC of the form
\\Server\Share\Directory. This parameter contains the value of homeDirectory attribute of new computer
object. For computer objects, it is optional, and typically is not set. You can change this attribute by using
Active Directory Users and Computers, or through a script, for example. This parameter might not be
captured in the event, and in that case appears as -.
Home Drive [Type = UnicodeString]: specifies the drive letter to which to map the UNC path specified by
homeDirectory accounts attribute. The drive letter must be specified in the form DRIVE_LETTER:. For
example H:. This parameter contains the value of homeDrive attribute of new computer object. For
computer objects, it is optional, and typically is not set. You can change this attribute by using Active
Directory Users and Computers, or through a script, for example. This parameter might not be captured in
the event, and in that case appears as -.
Script Path [Type = UnicodeString]: specifies the path of the account's logon script. This parameter contains
the value of scriptPath attribute of new computer object. For computer objects, it is optional, and typically is
not set. You can change this attribute by using Active Directory Users and Computers, or through a script, for
example. This parameter might not be captured in the event, and in that case appears as -.
Profile Path [Type = UnicodeString]: specifies a path to the account's profile. This value can be a null string,
a local absolute path, or a UNC path. This parameter contains the value of profilePath attribute of new
computer object. For computer objects, it is optional, and typically is not set. You can change this attribute by
using Active Directory Users and Computers, or through a script, for example. This parameter might not be
User Workstations [Type = UnicodeString]: contains the list of NetBIOS or DNS names of the computers
from which the user can logon. Each computer name is separated by a comma. The name of a computer is
the sAMAccountName property of a computer object. This parameter contains the value of
userWorkstations attribute of new computer object. For computer objects, it is optional, and typically is not
set. You can change this attribute by using Active Directory Users and Computers, or through a script, for
example. This parameter might not be captured in the event, and in that case appears as -.
Password Last Set [Type = UnicodeString]: last time the accounts password was modified. For manually
created computer account, using Active Directory Users and Computers snap-in, this field typically has value
<never>. For computer account created during standard domain join procedure this field will contains
time when computer object was created, because password creates during domain join procedure. For
example: 8/12/2015 11:41:39 AM. This parameter contains the value of pwdLastSet attribute of new
computer object.
Account Expires [Type = UnicodeString]: the date when the account expires. This parameter contains the
value of accountExpires attribute of new computer object. For computer objects, it is optional, and typically
is not set. You can change this attribute by using Active Directory Users and Computers, or through a script,
for example. This parameter might not be captured in the event, and in that case appears as -.
Primary Group ID [Type = UnicodeString]: Relative Identifier (RID) of computers object primary group.
Note Relative identifier (RID) is a variable length number that is assigned to objects at creation and
becomes part of the object's Security Identifier (SID) that uniquely identifies an account or group within a
domain.
Typically, Primary Group field for new computer accounts has the following values:
516 (Domain Controllers) for domain controllers.
521 (Read-only Domain Controllers) for read-only domain controllers (RODC).
515 (Domain Computers) for member servers and workstations.
See this article https://support.microsoft.com/en-us/kb/243330 for more information. This parameter
contains the value of primaryGroupID attribute of new computer object.
AllowedToDelegateTo [Type = UnicodeString]: the list of SPNs to which this account can present delegated
credentials. Can be changed using Active Directory Users and Computers management console in Delegation
tab of computer account. Typically it is set to - for new computer objects. This parameter contains the value of
AllowedToDelegateTo attribute of new computer object. See description of AllowedToDelegateTo field for
4742: A computer account was changed event for more details.
service. If you install multiple instances of a service on computers throughout a forest, each instance must have
its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients might use
for authentication. For example, an SPN always includes the name of the host computer on which the service
instance is running, so a service instance might register an SPN for each name or alias of its host.
Old UAC Value [Type = UnicodeString]: specifies flags that control password, lockout, disable/enable, script,
and other behavior for the user or computer account. Old UAC value always 0x0 for new computer
accounts. This parameter contains the previous value of userAccountControl attribute of computer object.
New UAC Value [Type = UnicodeString]: specifies flags that control password, lockout, disable/enable,
script, and other behavior for the user or computer account. This parameter contains the value of
userAccountControl attribute of new computer object.
To decode this value, you can go through the property value definitions in the Table 7. Users or Computers
account UAC flags. from largest to smallest. Compare each property value to the flags value in the event. If the
flags value in the event is greater than or equal to the property value, then the property is "set" and applies to that
event. Subtract the property value from the flags value in the event and note that the flag applies and then go on to
the next flag.
Here's an example: Flags value from event: 0x15
Decoding:
PASSWD_NOTREQD 0x0020
LOCKOUT 0x0010
HOMEDIR_REQUIRED 0x0008
(undeclared) 0x0004
ACCOUNTDISABLE 0x0002
SCRIPT 0x0001
0x0020 > 0x15, so PASSWD_NOTREQD does not apply to this event
0x10 < 0x15, so LOCKOUT applies to this event. 0x15 - 0x10 = 0x5
0x4 < 0x5, so the undeclared value is set. We'll pretend it doesn't mean anything. 0x5 - 0x4 = 0x1
0x2 > 0x1, so ACCOUNTDISABLE does not apply to this event
0x1 = 0x1, so SCRIPT applies to this event. 0x1 - 0x1 = 0x0, we're done.
So this UAC flags value decodes to: LOCKOUT and SCRIPT
User Account Control [Type = UnicodeString]: shows the list of changes in userAccountControl attribute.
You will see a line of text for each change. For new computer accounts, when the object for this account was
created, the userAccountControl value was considered to be 0x0, and then it was changed from 0x0 to
the real value for the account's userAccountControl attribute. See possible values in the table below. In the
User Account Control field text column, you can see the text that will be displayed in the User Account
Control field in 4741 event.
USERACCOUNTCONTRO USERACCOUNTCONTRO USER ACCOUNT

FLAG NAME L IN HEXADECIMAL L IN DECIMAL DESCRIPTION CONTROL FIELD TEXT
SCRIPT 0x0001 1 The logon script will Changes of this flag

be run. do not show in 4741
events.
ACCOUNTDISABLE 0x0002 2 The user account is Account Disabled

disabled. Account Enabled
Undeclared 0x0004 4 This flag is undeclared. Changes of this flag

do not show in 4741
events.
HOMEDIR_REQUIRED 0x0008 8 The home folder is 'Home Directory

required. Required' - Enabled
'Home Directory
Required' - Disabled
LOCKOUT 0x0010 16 Changes of this flag

do not show in 4741
events.
PASSWD_NOTREQD 0x0020 32 No password is 'Password Not

'Password Not
PASSWD_CANT_CHA 0x0040 64 The user cannot Changes of this flag

NGE change the password. do not show in 4741
This is a permission events.
on the user's object.
ENCRYPTED_TEXT_PW 0x0080 128 The user can send an 'Encrypted Text

D_ALLOWED encrypted password. Password Allowed' -
Can be set using Disabled
Store password using 'Encrypted Text
reversible encryption Password Allowed' -
checkbox. Enabled
TEMP_DUPLICATE_AC 0x0100 256 This is an account for Cannot be set for

COUNT users whose primary computer account.
account is in another
domain. This account
provides user access
to this domain, but
not to any domain
that trusts this
domain. This is
sometimes referred to
as a local user
account.
NORMAL_ACCOUNT 0x0200 512 This is a default 'Normal Account' -

account type that Disabled
represents a typical 'Normal Account' -
user. Enabled
INTERDOMAIN_TRUS 0x0800 2048 This is a permit to Cannot be set for

T_ACCOUNT trust an account for a computer account.
system domain that
trusts other domains.
WORKSTATION_TRUS 0x1000 4096 This is a computer 'Workstation Trust

T_ACCOUNT account for a Account' - Disabled
computer that is 'Workstation Trust
running Microsoft Account' - Enabled
Windows NT 4.0
Workstation,
Microsoft Windows
NT 4.0 Server,
Microsoft Windows
2000 Professional, or
Windows 2000 Server
and is a member of
this domain.
SERVER_TRUST_ACCO 0x2000 8192 This is a computer 'Server Trust Account'

UNT account for a domain - Enabled
controller that is a 'Server Trust Account'
member of this - Disabled
domain.
DONT_EXPIRE_PASSW 0x10000 65536 Represents the 'Don't Expire

ORD password, which Password' - Disabled
should never expire 'Don't Expire
on the account. Password' - Enabled
Can be set using
Password never
expires checkbox.
MNS_LOGON_ACCO 0x20000 131072 This is an MNS logon 'MNS Logon Account'

UNT account. - Disabled
'MNS Logon Account'
- Enabled
SMARTCARD_REQUIR 0x40000 262144 When this flag is set, 'Smartcard Required' -

ED it forces the user to Disabled
log on by using a 'Smartcard Required' -
smart card. Enabled
TRUSTED_FOR_DELEG 0x80000 524288 When this flag is set, 'Trusted For

ATION the service account Delegation' - Enabled
(the user or computer 'Trusted For
account) under which Delegation' - Disabled
a service runs is
trusted for Kerberos
delegation. Any such
service can
impersonate a client
requesting the service.
To enable a service for
Kerberos delegation,
you must set this flag
on the
userAccountControl
property of the
service account.
If you enable Kerberos
constraint or
unconstraint
delegation or disable
these types of
delegation in
Delegation tab you
will get this flag
changed.
NOT_DELEGATED 0x100000 1048576 When this flag is set, 'Not Delegated' -

the security context of Disabled
the user is not 'Not Delegated' -
delegated to a service Enabled
even if the service
account is set as
delegation.
Can be set using
Account is sensitive
and cannot be
delegated checkbox.
USE_DES_KEY_ONLY 0x200000 2097152 Restrict this principal 'Use DES Key Only' -
to use only Data Disabled
Encryption Standard 'Use DES Key Only' -
(DES) encryption Enabled
types for keys.
Can be set using Use
Kerberos DES
encryption types for
this account
checkbox.
DONT_REQ_PREAUTH 0x400000 4194304 This account does not 'Don't Require

require Kerberos pre- Preauth' - Disabled
authentication for 'Don't Require
logging on. Preauth' - Enabled
Can be set using Do
not require Kerberos
preauthentication
checkbox.
PASSWORD_EXPIRED 0x800000 8388608 The user's password Changes of this flag

has expired. do not show in 4741
events.
TRUSTED_TO_AUTH_F 0x1000000 16777216 The account is 'Trusted To

OR_DELEGATION enabled for Authenticate For
delegation. This is a Delegation' - Disabled
security-sensitive 'Trusted To
setting. Accounts that Authenticate For
have this option Delegation' - Enabled
enabled should be
tightly controlled. This
setting lets a service
that runs under the
account assume a
client's identity and
authenticate as that
user to other remote
servers on the
network.
If you enable Kerberos
protocol transition
this type of delegation
in Delegation tab you
will get this flag
changed.
PARTIAL_SECRETS_AC 0x04000000 67108864 The account is a read- No information.

COUNT only domain
controller (RODC).
This is a security-
sensitive setting.
Removing this setting
from an RODC
compromises security
on that server.
Table 7. Users or Computers account UAC flags.
User Parameters [Type = UnicodeString]: if you change any setting using Active Directory Users and
Computers management console in Dial-in tab of computers account properties, then you will see <value
changed, but not displayed> in this field in 4742(S): A computer account was changed. This parameter
might not be captured in the event, and in that case appears as -.
SID History [Type = UnicodeString]: contains previous SIDs used for the object if the object was moved
from another domain. Whenever an object is moved from one domain to another, a new SID is created and
becomes the objectSID. The previous SID is added to the sIDHistory property. This parameter contains the
value of sIDHistory attribute of new computer object. This parameter might not be captured in the event,
and in that case appears as -.
Logon Hours [Type = UnicodeString]: hours that the account is allowed to logon to the domain. The value
of logonHours attribute of new computer object. For computer objects, it is optional, and typically is not set.
You can change this attribute by using Active Directory Users and Computers, or through a script, for
example. You will see <value not set> value for new created computer accounts in event 4741.
DNS Host Name [Type = UnicodeString]: name of computer account as registered in DNS. The value of
dNSHostName attribute of new computer object. For manually created computer account objects this field
has value -.
Service Principal Names [Type = UnicodeString]: The list of SPNs, registered for computer account. For
new computer accounts it will typically contain HOST SPNs and RestrictedKrbHost SPNs. The value of
servicePrincipalName attribute of new computer object. For manually created computer objects it is
typically equals -. This is an example of Service Principal Names field for new domain joined
workstation:
HOST/Win81.contoso.local
RestrictedKrbHost/Win81.contoso.local
HOST/WIN81
RestrictedKrbHost/WIN81
Privileges [Type = UnicodeString]: the list of user privileges which were used during the operation, for example,
SeBackupPrivilege. This parameter might not be captured in the event, and in that case appears as -. See full
list of user privileges in the table below:
PRIVILEGE NAME USER RIGHT GROUP POLICY NAME DESCRIPTION
SeAssignPrimaryTokenPrivilege Replace a process-level token Required to assign the primary token of

a process.
With this privilege, the user can initiate
a process to replace the default token
associated with a started subprocess.
SeAuditPrivilege Generate security audits With this privilege, the user can add
entries to the security log.
SeBackupPrivilege Back up files and directories - Required to perform backup

operations.
With this privilege, the user can bypass
file and directory, registry, and other
persistent object permissions for the
purposes of backing up the system.
This privilege causes the system to
grant all read access control to any file,
regardless of the access control list
(ACL) specified for the file. Any access
request other than read is still evaluated
with the ACL. The following access
rights are granted if this privilege is
held:
READ_CONTROL
ACCESS_SYSTEM_SECURITY
FILE_GENERIC_READ
FILE_TRAVERSE
SeChangeNotifyPrivilege Bypass traverse checking Required to receive notifications of

changes to files or directories. This
privilege also causes the system to skip
all traversal access checks.
With this privilege, the user can traverse
directory trees even though the user
may not have permissions on the
traversed directory. This privilege does
not allow the user to list the contents of
a directory, only to traverse directories.
SeCreateGlobalPrivilege Create global objects Required to create named file mapping

objects in the global namespace during
Terminal Services sessions.
SeCreatePagefilePrivilege Create a pagefile With this privilege, the user can create
and change the size of a pagefile.
SeCreatePermanentPrivilege Create permanent shared objects Required to create a permanent object.

This privilege is useful to kernel-mode
components that extend the object
namespace. Components that are
running in kernel mode already have
this privilege inherently; it is not
necessary to assign them the privilege.
SeCreateSymbolicLinkPrivilege Create symbolic links Required to create a symbolic link.
SeCreateTokenPrivilege Create a token object Allows a process to create a token

which it can then use to get access to
any local resources when the process
uses NtCreateToken() or other token-
creation APIs.
When a process requires this privilege,
we recommend using the LocalSystem
account (which already includes the
privilege), rather than creating a
separate user account and assigning
this privilege to it.
SeDebugPrivilege Debug programs Required to debug and adjust the

memory of a process owned by another
account.
With this privilege, the user can attach a
debugger to any process or to the
kernel. Developers who are debugging
their own applications do not need this
user right. Developers who are
debugging new system components
need this user right. This user right
provides complete access to sensitive
and critical operating system
components.
SeEnableDelegationPrivilege Enable computer and user accounts to Required to mark user and computer
be trusted for delegation accounts as trusted for delegation.
With this privilege, the user can set the
Trusted for Delegation setting on a
user or computer object.
The user or object that is granted this
privilege must have write access to the
account control flags on the user or
computer object. A server process
running on a computer (or under a user
context) that is trusted for delegation
can access resources on another
computer using the delegated
credentials of a client, as long as the
account of the client does not have the
Account cannot be delegated
account control flag set.
SeImpersonatePrivilege Impersonate a client after With this privilege, the user can
authentication impersonate other accounts.
SeIncreaseBasePriorityPrivilege Increase scheduling priority Required to increase the base priority of

a process.
With this privilege, the user can use a
process with Write property access to
another process to increase the
execution priority assigned to the other
process. A user with this privilege can
change the scheduling priority of a
process through the Task Manager user
interface.
SeIncreaseQuotaPrivilege Adjust memory quotas for a process Required to increase the quota assigned
to a process.
With this privilege, the user can change
the maximum memory that can be
consumed by a process.
SeIncreaseWorkingSetPrivilege Increase a process working set Required to allocate more memory for
applications that run in the context of
users.
SeLoadDriverPrivilege Load and unload device drivers Required to load or unload a device
driver.
With this privilege, the user can
dynamically load and unload device
drivers or other code in to kernel mode.
This user right does not apply to Plug
and Play device drivers.
SeLockMemoryPrivilege Lock pages in memory Required to lock physical pages in

memory.
process to keep data in physical
memory, which prevents the system
from paging the data to virtual memory
on disk. Exercising this privilege could
significantly affect system performance
by decreasing the amount of available
random access memory (RAM).
SeMachineAccountPrivilege Add workstations to domain With this privilege, the user can create a
computer account.
This privilege is valid only on domain
controllers.
SeManageVolumePrivilege Perform volume maintenance tasks Required to run maintenance tasks on a

volume, such as remote
defragmentation.
SeProfileSingleProcessPrivilege Profile single process Required to gather profiling information

for a single process.
With this privilege, the user can use
performance monitoring tools to
monitor the performance of non-
system processes.
SeRelabelPrivilege Modify an object label Required to modify the mandatory

integrity level of an object.
SeRemoteShutdownPrivilege Force shutdown from a remote system Required to shut down a system using a
network request.
SeRestorePrivilege Restore files and directories Required to perform restore operations.

grant all write access control to any file,
regardless of the ACL specified for the
file. Any access request other than write
is still evaluated with the ACL.
Additionally, this privilege enables you
to set any valid user or group SID as
the owner of a file. The following access
held:
WRITE_DAC
WRITE_OWNER
FILE_GENERIC_WRITE
FILE_ADD_FILE
FILE_ADD_SUBDIRECTORY
DELETE
file, directory, registry, and other
persistent objects permissions when
restoring backed up files and directories
and determines which users can set any
valid security principal as the owner of
an object.
SeSecurityPrivilege Manage auditing and security log Required to perform a number of

security-related functions, such as
controlling and viewing audit events in
security event log.
With this privilege, the user can specify
object access auditing options for
individual resources, such as files, Active
Directory objects, and registry keys.
A user with this privilege can also view
and clear the security log.
SeShutdownPrivilege Shut down the system Required to shut down a local system.
SeSyncAgentPrivilege Synchronize directory service data This privilege enables the holder to read
all objects and properties in the
directory, regardless of the protection
on the objects and properties. By
default, it is assigned to the
Administrator and LocalSystem
accounts on domain controllers.
synchronize all directory service data.
This is also known as Active Directory
synchronization.
SeSystemEnvironmentPrivilege Modify firmware environment values Required to modify the nonvolatile RAM
of systems that use this type of
memory to store configuration
information.
SeSystemProfilePrivilege Profile system performance Required to gather profiling information

for the entire system.
monitor the performance of system
processes.
SeSystemtimePrivilege Change the system time Required to modify the system time.
the time and date on the internal clock
of the computer. Users that are
assigned this user right can affect the
appearance of event logs. If the system
time is changed, events that are logged
will reflect this new time, not the actual
time that the events occurred.
SeTakeOwnershipPrivilege Take ownership of files or other objects Required to take ownership of an object
without being granted discretionary
access. This privilege allows the owner
value to be set only to those values that
the holder may legitimately assign as
the owner of an object.
With this privilege, the user can take
ownership of any securable object in the
system, including Active Directory
objects, files and folders, printers,
registry keys, processes, and threads.
SeTcbPrivilege Act as part of the operating system This privilege identifies its holder as part
of the trusted computer base.
This user right allows a process to
impersonate any user without
authentication. The process can
therefore gain access to the same local
resources as that user.
SeTimeZonePrivilege Change the time zone Required to adjust the time zone
associated with the computer's internal
clock.
SeTrustedCredManAccessPrivilege Access Credential Manager as a trusted Required to access Credential Manager

caller as a trusted caller.
SeUndockPrivilege Remove computer from docking station Required to undock a laptop.

With this privilege, the user can undock
a portable computer from its docking
station without logging on.
SeUnsolicitedInputPrivilege Not applicable Required to read unsolicited input from

a terminal device.
Table 8. User Privileges.

For 4741(S): A computer account was created.
Important For this event, also see Appendix A: Security monitoring recommendations for many audit events.
If your information security monitoring policy requires you to monitor computer account creation, monitor
this event.
Consider whether to track the following fields and values:
FIELD AND VALUE TO TRACK REASON TO TRACK
SAM Account Name: empty or - This field must contain the computer account name. If it is
empty or -, it might indicate an anomaly.
Display Name is not - Typically these fields are - for new computer accounts. Other
User Principal Name is not - values might indicate an anomaly and should be monitored.
Home Directory is not -
Home Drive is not -
Script Path is not -
Profile Path is not -
User Workstations is not -
AllowedToDelegateTo is not -
Password Last Set is <never> This typically means this is a manually created computer
account, which you might need to monitor.
Account Expires is not <never> Typically this field is <never> for new computer accounts.
Other values might indicate an anomaly and should be
monitored.
Primary Group ID is any value other than 515. Typically, the Primary Group ID value is one of the following:
516 for domain controllers
521 for read only domain controllers (RODCs)
515 for servers and workstations (domain computers)
If the Primary Group ID is 516 or 521, it is a new domain
controller or RODC, and the event should be monitored.
If the value is not 516, 521, or 515, it is not a typical value and
should be monitored.
Old UAC Value is not 0x0 Typically this field is 0x0 for new computer accounts. Other
values might indicate an anomaly and should be monitored.
SID History is not - This field will always be set to - unless the account was
migrated from another domain.
Logon Hours value other than <value not set> This should always be <value not set> for new computer
accounts.
Consider whether to track the following account control flags:
USER ACCOUNT CONTROL FLAG TO TRACK INFORMATION ABOUT THE FLAG
'Encrypted Text Password Allowed' Enabled Should not be set for computer accounts. By default, it will not
be set, and it cannot be set in the account properties in Active
Directory Users and Computers.
'Server Trust Account' Enabled Should be enabled only for domain controllers.
'Don't Expire Password' Enabled Should not be enabled for new computer accounts, because
the password automatically changes every 30 days by default.
For computer accounts, this flag cannot be set in the account
properties in Active Directory Users and Computers.
'Smartcard Required' Enabled Should not be enabled for new computer accounts.
'Trusted For Delegation' Enabled Should not be enabled for new member servers and
workstations. It is enabled by default for new domain
controllers.
'Not Delegated' Enabled Should not be enabled for new computer accounts.
'Use DES Key Only' Enabled Should not be enabled for new computer accounts. For
computer accounts, it cannot be set in the account properties
in Active Directory Users and Computers.
'Don't Require Preauth' Enabled Should not be enabled for new computer accounts. For
computer accounts, it cannot be set in the account properties
in Active Directory Users and Computers.
'Trusted To Authenticate For Delegation' Enabled Should not be enabled for new computer accounts by default.
4742(S): A computer account was changed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Computer Account
Management
Event Description:
This event generates every time a computer
object is changed.
controllers.
You might see the same values for
Subject\Security ID and Computer Account
That Was Changed\Security ID in this event.
This usually happens when you reboot a
computer after adding it to the domain (the
change takes effect after the reboot).
For each change, a separate 4742 event will be
generated.
Some changes do not invoke a 4742 event, for
example, changes made using Active Directory
Users and Computers management console in
Managed By tab in computer account
properties.
You might see this event without any changes
inside, that is, where all Changed Attributes
apear as -. This usually happens when a
change is made to an attribute that is not listed
in the event. In this case there is no way to
determine which attribute was changed. For
example, this would happen if you change the
Description of a group object using the Active
Directory Users and Computers administrative console. Also, if the discretionary access control list (DACL) is
changed, a 4742 event will generate, but all attributes will be -.
Important: If you manually change any user-related setting or attribute, for example if you set the
SMARTCARD_REQUIRED flag in userAccountControl for the computer account, then the sAMAccountType of
the computer account will be changed to NORMAL_USER_ACCOUNT and you will get 4738: A user account was
changed instead of 4742 for this computer account. Essentially, the computer account will become a user
account. For NORMAL_USER_ACCOUNT you will always get events from Audit User Account Management
subcategory. We strongly recommend that you avoid changing any user-related settings manually for computer
objects.
Event XML:
- <System>
<Level>0</Level>
<Task>13825</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ComputerAccountChange">-</Data>
<Data Name="TargetUserName">WIN81$</Data>
<Data Name="SubjectLogonId">0x2e80c</Data>
<Data Name="SamAccountName">-</Data>
<Data Name="PasswordLastSet">-</Data>
<Data Name="AccountExpires">-</Data>
<Data Name="PrimaryGroupId">-</Data>
<Data Name="AllowedToDelegateTo">%%1793</Data>
<Data Name="UserAccountControl">%%2093</Data>
<Data Name="LogonHours">-</Data>
<Data Name="DnsHostName">-</Data>
<Data Name="ServicePrincipalNames">-</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the change Computer object operation. Event Viewer
identify the user in all subsequent interactions with Windows security. When a SID has been used as the
unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more
Account Name [Type = UnicodeString]: the name of the account that requested the change Computer
object operation.
Computer Account That Was Changed:
Security ID [Type = SID]: SID of changed computer account. Event Viewer automatically tries to resolve
SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
Account Name [Type = UnicodeString]: the name of the computer account that was changed. For example:
WIN81$
Account Domain [Type = UnicodeString]: domain name of changed computer account. Formats vary, and
Changed Attributes:
Note If attribute was not changed it will have - value.
from previous versions of Windows (pre-Windows 2000 logon name). If the value of sAMAccountName
attribute of computer object was changed, you will see the new value here. For example: WIN8$.
Display Name [Type = UnicodeString]: it is a name displayed in the address book for a particular account
(typically user account). This is usually the combination of the user's first name, middle initial, and last
name. For computer objects, it is optional, and typically is not set. You can change this attribute by using
Active Directory Users and Computers, or through a script, for example. If the value of displayName
attribute of computer object was changed, you will see the new value here.
Internet standard RFC 822. By convention this should map to the account's email name. If the value of
userPrincipalName attribute of computer object was changed, you will see the new value here. For
computer objects, it is optional, and typically is not set. You can change this attribute by using Active
Directory Users and Computers, or through a script, for example.
\\Server\Share\Directory. If the value of homeDirectory attribute of computer object was changed, you will
see the new value here. For computer objects, it is optional, and typically is not set. You can change this
attribute by using Active Directory Users and Computers, or through a script, for example.
example H:. If the value of homeDrive attribute of computer object was changed, you will see the new
value here. For computer objects, it is optional, and typically is not set. You can change this attribute by
using Active Directory Users and Computers, or through a script, for example.
Script Path [Type = UnicodeString]: specifies the path of the accounts logon script. If the value of
scriptPath attribute of computer object was changed, you will see the new value here. For computer
objects, it is optional, and typically is not set. You can change this attribute by using Active Directory Users
and Computers, or through a script, for example.
a local absolute path, or a UNC path. If the value of profilePath attribute of computer object was changed,
you will see the new value here. For computer objects, it is optional, and typically is not set. You can change
this attribute by using Active Directory Users and Computers, or through a script, for example.
the sAMAccountName property of a computer object. If the value of userWorkstations attribute of
computer object was changed, you will see the new value here. For computer objects, it is optional, and
typically is not set. You can change this attribute by using Active Directory Users and Computers, or through
a script, for example.
Password Last Set [Type = UnicodeString]: last time the accounts password was modified. If the value of
pwdLastSet attribute of computer object was changed, you will see the new value here. For example:
8/12/2015 11:41:39 AM. This value will be changed, for example, after manual computer account reset
action or automatically every 30 days by default for computer objects.
Account Expires [Type = UnicodeString]: the date when the account expires. If the value of
accountExpires attribute of computer object was changed, you will see the new value here. For computer
Primary Group ID [Type = UnicodeString]: Relative Identifier (RID) of computers object primary group.
domain.
This field will contain some value if computers object primary group was changed. You can change computers
primary group using Active Directory Users and Computers management console in the Member Of tab of
computer object properties. You will see a RID of new primary group as a field value. For example, 515 (Domain
Computers) for workstations, is a default primary group.
Typical Primary Group values for computer accounts:
516 (Domain Controllers) for domain controllers.
521 (Read-only Domain Controllers) read-only domain controllers (RODC).
515 (Domain Computers) servers and workstations.
See this article https://support.microsoft.com/en-us/kb/243330 for more information. If the value of
primaryGroupID attribute of computer object was changed, you will see the new value here.
AllowedToDelegateTo [Type = UnicodeString]: the list of SPNs to which this account can present
delegated credentials. Can be changed using Active Directory Users and Computers management console in
Delegation tab of computer account. If the SPNs list on Delegation tab of a computer account was
changed, you will see the new SPNs list in AllowedToDelegateTo field (note that you will see the new list
instead of changes) of this event. This is an example of AllowedToDelegateTo:
dcom/WIN2012
dcom/WIN2012.contoso.local
If the value of msDS-AllowedToDelegateTo attribute of computer object was changed, you will see
the new value here.
The value can be <value not set>, for example, if delegation was disabled.
Old UAC Value [Type = UnicodeString]: specifies flags that control password, lockout, disable/enable,
script, and other behavior for the user or computer account. This parameter contains the previous value of
userAccountControl attribute of computer object.
script, and other behavior for the user or computer account. If the value of userAccountControl attribute
of computer object was changed, you will see the new value here.
the next flag.
Decoding:
LOCKOUT 0x0010
(undeclared) 0x0004
SCRIPT 0x0001
You will see a line of text for each change. See possible values in here: Table 7. Users or Computers account
UAC flags.. In the User Account Control field text column, you can see text that will be displayed in the User
Account Control field in 4742 event.
Computers management console in Dial-in tab of computers account properties, then you will see <value
changed, but not displayed> in this field.
becomes the objectSID. The previous SID is added to the sIDHistory property. If the value of sIDHistory
attribute of computer object was changed, you will see the new value here.
Logon Hours [Type = UnicodeString]: hours that the account is allowed to logon to the domain. If the value
of logonHours attribute of computer object was changed, you will see the new value here. For computer
DNS Host Name [Type = UnicodeString]: name of computer account as registered in DNS. If the value of
dNSHostName attribute of computer object was changed, you will see the new value here.
Service Principal Names [Type = UnicodeString]: The list of SPNs, registered for computer account. If the
SPN list of a computer account changed, you will see the new SPN list in Service Principal Names field
(note that you will see the new list instead of changes). If the value of servicePrincipalName attribute of
computer object was changed, you will see the new value here.
Here is an example of Service Principal Names field for new domain joined workstation in event 4742 on
domain controller, after workstation reboots:
HOST/Win81.contoso.local
RestrictedKrbHost/Win81.contoso.local
HOST/WIN81
RestrictedKrbHost/WIN81
TERMSRV/Win81.contoso.local
Privileges [Type = UnicodeString]: the list of user privileges which were used during the operation, for
example, SeBackupPrivilege. This parameter might not be captured in the event, and in that case appears as -.
See full list of user privileges in Table 8. User Privileges..
For 4742(S): A computer account was changed.
If you have critical domain computer accounts (database servers, domain controllers, administration
workstations, and so on) for which you need to monitor each change, monitor this event with the
Computer Account That Was Changed\Security ID that corresponds to the high-value account or
accounts.
If you have computer accounts for which any change in the services list on the Delegation tab should be
monitored, monitor this event when AllowedToDelegateTo is not -. This value means the services list was
changed.
Display Name is not - Typically these fields are - for computer accounts. Other
User Principal Name is not - values might indicate an anomaly and should be monitored.
Home Directory is not -
Home Drive is not -
Script Path is not -
Profile Path is not -
Account Expires is not -
Logon Hours is not -
Password Last Set changes occur more often than usual Changes that are more frequent than the default (typically
once a month) might indicate an anomaly or attack.
Primary Group ID is not 516, 521, or 515 Typically, the Primary Group ID value is one of the following:
516 for domain controllers
521 for read only domain controllers (RODCs)
515 for servers and workstations (domain computers)
Other values should be monitored.
For computer accounts for which the services list (on the If AllowedToDelegateTo is marked <value not set> on
Delegation tab) should not be empty: computers that previously had a services list (on the
AllowedToDelegateTo is marked **<value not set> ** Delegation tab), it means the list was cleared.
Consider whether to track the following account control flags:
'Password Not Required' Enabled Should not be set for computer accounts. Computer accounts
typically require a password by default, except manually
created computer objects.
'Encrypted Text Password Allowed' Enabled Should not be set for computer accounts. By default, it will not
be set, and it cannot be set in the account properties in Active
'Server Trust Account' Enabled Should be enabled only for domain controllers.
'Server Trust Account' Disabled Should not be disabled for domain controllers.
'Don't Expire Password' Enabled Should not be enabled for computer accounts, because the
password automatically changes every 30 days by default. For
computer accounts, this flag cannot be set in the account
properties in Active Directory Users and Computers.
'Smartcard Required' Enabled Should not be enabled for computer accounts.
'Trusted For Delegation' Enabled Means that Kerberos Constraint or Unconstraint delegation
was enabled for the computer account. We recommend
monitoring this to discover whether it is an approved action
(done by an administrator), a mistake, or a malicious action.
'Trusted For Delegation' Disabled Means that Kerberos Constraint or Unconstraint delegation
was disabled for the computer account. We recommend
Also, if you have a list of computer accounts for which
delegation is critical and should not be disabled, monitor this
for those accounts.
'Trusted To Authenticate For Delegation' Enabled Means that Protocol Transition delegation was enabled for the
computer account. We recommend monitoring this to
discover whether it is an approved action (done by an
administrator), a mistake, or a malicious action.
'Trusted To Authenticate For Delegation' Disabled Means that Protocol Transition delegation was disabled for
the computer account. We recommend monitoring this to
discover whether it is an approved action (done by an
Also, if you have a list of computer accounts for which
delegation is critical and should not be disabled, monitor this
for those accounts.
'Not Delegated' Enabled Means that Account is sensitive and cannot be delegated
was selected for the computer account. For computer
accounts, this flag cannot be set using the graphical interface.
We recommend monitoring this to discover whether it is an
approved action (done by an administrator), a mistake, or a
malicious action.
'Use DES Key Only' Enabled Should not be enabled for computer accounts. For computer
accounts, it cannot be set in the account properties in Active
'Don't Require Preauth' - Enabled Should not be enabled for computer accounts. For computer
accounts, it cannot be set in the account properties in Active
4743(S): A computer account was deleted.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Computer
Account Management
Event Description:
This event generates every time a
computer object is deleted.
controllers.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>13825</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">COMPUTERACCOUNT$</Data>
<Data Name="SubjectLogonId">0x3007b</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the delete Computer object operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the delete Computer
object operation.
Target Computer:
Security ID [Type = SID]: SID of deleted computer account. Event Viewer automatically tries to resolve SIDs
Account Name [Type = UnicodeString]: the name of the computer account that was deleted. For example:
WIN81$
Account Domain [Type = UnicodeString]: domain name of deleted computer account. Formats vary, and
list of user privileges in Table 8. User Privileges..

For 4743(S): A computer account was deleted.
If you have critical domain computer accounts (database servers, domain controllers, administration
workstations, and so on) for which you need to monitor each action (especially deletion), monitor this event with
the Target Computer\Security ID or Target Computer\Account Name that corresponds to the high-
value account or accounts.
Audit Distribution Group Management
Applies to
Windows 10
Windows Server 2016
Audit Distribution Group Management determines whether the operating system generates audit events for
specific distribution-group management tasks.
This subcategory generates events only on domain controllers.
Event volume: Low on domain controllers.
This subcategory allows you to audit events generated by changes to distribution groups such as the following:
Distribution group is created, changed, or deleted.
Member is added or removed from a distribution group.
If you need to monitor for group type changes, you need to monitor for 4764: A groups type was changed.
Audit Security Group Management subcategory success auditing must be enabled.
STRONGER STRONGER
STRONGER STRONGER
Domain IF No IF No IF - Typically
Controller actions related to
distribution
groups have low
security
relevance, much
more important
to monitor
Security Group
changes. But if
you want to
monitor for
critical
distribution
groups changes,
such as member
was added to
internal critical
distribution
group
(executives,
administrative
group, for
example), you
need to enable
this subcategory
for Success
auditing.
Typically volume
of these events is
low on domain
controllers.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.

generates events
only on domain
controllers.

generates events
only on domain
controllers.
Events List:
4749(S): A security-disabled global group was created.
4750(S): A security-disabled global group was changed.
4751(S): A member was added to a security-disabled global group.
4752(S): A member was removed from a security-disabled global group.
4753(S): A security-disabled global group was deleted.
4759(S): A security-disabled universal group was created. See event 4749: A security-disabled global group
was created. Event 4759 is the same, but it is generated for a universal distribution group instead of a global
distribution group. All event fields, XML, and recommendations are the same. The type of group is the only
difference.
4760(S): A security-disabled universal group was changed. See event 4750: A security-disabled global group
was changed. Event 4760 is the same, but it is generated for a universal distribution group instead of a global
difference.
4761(S): A member was added to a security-disabled universal group. See event 4751: A member was
added to a security-disabled global group. Event 4761 is the same, but it is generated for a universal distribution
group instead of a global distribution group. All event fields, XML, and recommendations are the same. The type
of group is the only difference.
4762(S): A member was removed from a security-disabled universal group. See event 4752: A member
was removed from a security-disabled global group. Event 4762 is the same, but it is generated for a universal
distribution group instead of a global distribution group. All event fields, XML, and recommendations are the
same. The type of group is the only difference.
4763(S): A security-disabled universal group was deleted. See event 4753: A security-disabled global group
was deleted. Event 4763 is the same, but it is generated for a universal distribution group instead of a global
difference.
4744(S): A security-disabled local group was created. See event 4749: A security-disabled global group was
created. Event 4744 is the same, but it is generated for a local distribution group instead of a global distribution
group. All event fields, XML, and recommendations are the same. The type of group is the only difference.
4745(S): A security-disabled local group was changed. See event 4750: A security-disabled global group was
changed. Event 4745 is the same, but it is generated for a local distribution group instead of a global distribution
4746(S): A member was added to a security-disabled local group. See event 4751: A member was added to
a security-disabled global group. Event 4746 is the same, but it is generated for a local distribution group instead
of a global distribution group. All event fields, XML, and recommendations are the same. The type of group is the
only difference.
4747(S): A member was removed from a security-disabled local group. See event 4752: A member was
removed from a security-disabled global group. Event 4747 is the same, but it is generated for a local
distribution group instead of a global distribution group. All event fields, XML, and recommendations are the
same. The type of group is the only difference.
4748(S): A security-disabled local group was deleted. See event 4753: A security-disabled global group was
deleted. Event 4748 is the same, but it is generated for a local distribution group instead of a global distribution
4749(S): A security-disabled global group was
created.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Distribution Group
Management
Event Description:
security-disabled (distribution) global group
was created.
controllers.

Event XML:
- <System>
<Level>0</Level>
<Task>13827</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">ServiceDesk</Data>
<Data Name="SamAccountName">ServiceDesk</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the create group operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the create group
operation.
Group:
Security ID [Type = SID]: SID of created group. Event Viewer automatically tries to resolve SIDs and show
the group name. If the SID cannot be resolved, you will see the source data in the event.
Group Name [Type = UnicodeString]: the name of the group that was created. For example: ServiceDesk
Group Domain [Type = UnicodeString]: domain name of created group. Formats vary, and include the
following:
Attributes:
SAM Account Name [Type = UnicodeString]: This is a name of new group used to support clients and
servers from previous versions of Windows (pre-Windows 2000 logon name). The value of
sAMAccountName attribute of new group object. For example: ServiceDesk
value of sIDHistory attribute of new group object. This parameter might not be captured in the event, and
in that case appears as -.

For 4749(S): A security-disabled global group was created.
If you need to monitor each time a new distribution group is created, to see who created the group and
when, monitor this event. Typically, this event is used as an informational event, to be reviewed if needed.
If your organization has naming conventions for account names, monitor Attributes\SAM Account
Name for names that dont comply with the naming conventions.
changed.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates every time security-
disabled (distribution) global group is
changed.
controllers.
Some changes do not invoke a 4750 event, for
example, changes made using the Active
Directory Users and Computers management
console in Managed By tab in group account
properties.
If you change the name of the group (SAM
Account Name), you also get 4781: The name
of an account was changed if Audit User
Account Management subcategory success
auditing is enabled.
If you change the group type, you get a change event from the new group type auditing subcategory instead of
4750. If you need to monitor for group type changes, it is better to monitor for 4764: A groups type was
changed. These events are generated for any group type when group type is changed. Audit Security Group
Management subcategory success auditing must be enabled.
From 4750 event you can get information about changes of sAMAccountName and sIDHistory attributes or you
will see that something changed, but will not be able to see what exactly changed.
Event XML:
- <System>
<Level>0</Level>
<Task>13827</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">ServiceDeskMain</Data>
<Data Name="SamAccountName">ServiceDeskMain</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the change group operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the change group
operation.
Group:
Security ID [Type = SID]: SID of changed group. Event Viewer automatically tries to resolve SIDs and show the
group name. If the SID cannot be resolved, you will see the source data in the event.
Note Sometimes you can see the Group\Security ID field contains an old group name in Event Viewer (as
you can see in the event example). That happens because Event Viewer caches names for SIDs that it has
already resolved for the current session.
Note Security ID field has the same value as new group name (Changed Attributes>SAM Account
Name). That is happens because event is generated after name was changed and SID resolves to the new
name. It is always better to use SID instead of group names for queries or filtering of events, because you will
know for sure that this the right object you are looking for or want to monitor.
Group Name [Type = UnicodeString]: the name of the group that was changed. For example: ServiceDesk
Group Domain [Type = UnicodeString]: domain name of changed group. Formats vary, and include the
following:
Built-in groups: Builtin
Changed Attributes:

Note You might see a 4750 event without any changes inside, that is, where all Changed Attributes appear
as -. This usually happens when a change is made to an attribute that is not listed in the event. In this case
there is no way to determine which attribute was changed. For example, this would happen if you change the
Description of a group object using the Active Directory Users and Computers administrative console. Also, if
the discretionary access control list (DACL) is changed, a 4750 event will generate, but all attributes will be -.
SAM Account Name [Type = UnicodeString]: This is a new name of changed group used to support clients
and servers from previous versions of Windows (pre-Windows 2000 logon name). If the value of
sAMAccountName attribute of group object was changed, you will see the new value here. For example:
ServiceDesk.
attribute of group object was changed, you will see the new value here.

For 4750(S): A security-disabled global group was changed.
If you have a list of critical distribution groups in the organization, and need to specifically monitor these
groups for any change, monitor events with the Group\Group Name values that correspond to the
critical distribution groups.
If you need to monitor each time a member is added to a distribution group, to see who added the member
and when, monitor this event. Typically, this event is used as an informational event, to be reviewed if
needed.
4751(S): A member was added to a security-disabled
global group.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
member was added to a security-disabled
(distribution) global group.
controllers.
For every added member you will get separate
4751 event.
You will typically see 4750: A security-
disabled global group was changed. event
without any changes in it prior to 4751 event.

Event XML:
- <System>
<Level>0</Level>
<Task>13827</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="MemberName">CN=Auditor,CN=Users,DC=contoso,DC=local</Data>
<Data Name="MemberSid">S-1-5-21-3457937927-2839227994-823803824-2104</Data>
<Data Name="TargetUserName">ServiceDeskSecond</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the add member to the group operation. Event
Account Name [Type = UnicodeString]: the name of the account that requested the add member to the
group operation.
For some well-known security principals, such as LOCAL SERVICE or ANONYMOUS LOGON, the value of
this field is NT AUTHORITY.
Logon ID [Type = HexInt64]: hexadecimal value that can help you correlate this event with recent events that
might contain the same Logon ID, for example, 4624: An account was successfully logged on.
Member:
Security ID [Type = SID]: SID of account that was added to the group. Event Viewer automatically tries to
resolve SIDs and show the group name. If the SID cannot be resolved, you will see the source data in the
event.
Account Name [Type = UnicodeString]: distinguished name of account that was added to the group. For
example: CN=Auditor,CN=Users,DC=contoso,DC=local. For some well-known security principals, such as
LOCAL SERVICE or ANONYMOUS LOGON, the value of this field is -.
Note The LDAP API references an LDAP object by its distinguished name (DN). A DN is a sequence of
relative distinguished names (RDN) connected by commas.
An RDN is an attribute with an associated value in the form attribute=value; . These are examples of RDNs
attributes:
DC - domainComponent
CN - commonName
OU - organizationalUnitName
O - organizationName
Group:
Security ID [Type = SID]: SID of the group to which new member was added. Event Viewer automatically
tries to resolve SIDs and show the group name. If the SID cannot be resolved, you will see the source data in
the event.
Group Name [Type = UnicodeString]: the name of the group to which new member was added. For
example: ServiceDesk
Group Domain [Type = UnicodeString]: domain name of the group to which new member was added.
Formats vary, and include the following:

For 4751(S): A member was added to a security-disabled global group.
Addition of members to distribution groups: You might If you need to monitor each time a member is added to a
need to monitor the addition of members to distribution distribution group, to see who added the member and when,
groups. monitor this event.
Typically, this event is used as an informational event, to be
reviewed if needed.
High-value distribution groups: You might have a list of Monitor this event with the Group\Group Name values
critical distribution groups in the organization, and need to that correspond to the high-value distribution groups.
specifically monitor these groups for the addition of new
members (or for other changes).
High-value accounts: You might have high-value domain or Monitor this event with the Subject\Security ID and
local accounts for which you need to monitor each action. Member\Security ID that correspond to the high-value
Examples of high-value accounts are database administrators, account or accounts.
requirements for detecting anomalies or monitoring potential Subject\Security ID (with other information) to monitor
use of an account outside of working hours.
Non-active accounts: You might have non-active, disabled, Monitor this event with the Subject\Security ID and
or guest accounts, or other accounts that should never be Member\Security ID that correspond to the accounts that
used. should never be used.
accounts that are the only ones allowed to perform actions the Subject\Security ID for accounts that are outside the
Accounts of different types: You might want to ensure that If this event corresponds to an action you want to monitor for
certain actions are performed only by certain account types, certain account types, review the Subject\Security ID to
for example, local or domain account, machine or user see whether the account type is as expected.
account, vendor or employee account, and so on.
External accounts: You might be monitoring accounts from Monitor this event for the Subject\Account Domain
another domain, or external accounts that are not allowed corresponding to accounts from another domain or external
to perform certain actions (represented by certain specific accounts.
events).
certain computers, machines, or devices on which certain actions performed by the Subject\Security ID that you are
people (accounts) should not typically perform any actions. concerned about.
Account naming conventions: Your organization might have Monitor Subject\Account Name for names that dont
specific naming conventions for account names. comply with naming conventions.
4752(S): A member was removed from a security-
disabled global group.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates every time member was
removed from the security-disabled
(distribution) global group.
controllers.
For every removed member you will get
separate 4752 event.

Event XML:
- <System>
<Level>0</Level>
<Task>13827</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the remove member from the group operation. Event
Account Name [Type = UnicodeString]: the name of the account that requested the remove member
from the group operation.
Member:
Security ID [Type = SID]: SID of account that was removed from the group. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: distinguished name of account that was removed from the group.
For example: CN=Auditor,CN=Users,DC=contoso,DC=local. For some well-known security principals, such
as LOCAL SERVICE or ANONYMOUS LOGON, the value of this field is -.
attributes:
CN - commonName
Group:
Security ID [Type = SID]: SID of the group from which the member was removed. Event Viewer
automatically tries to resolve SIDs and show the group name. If the SID cannot be resolved, you will see the
Group Name [Type = UnicodeString]: the name of the group from which the member was removed. For
Group Domain [Type = UnicodeString]: domain name of the group from which the member was removed.

For 4752(S): A member was removed from a security-disabled global group.
Removal of members from distribution groups: You If you need to monitor each time a member is removed from
might need to monitor the removal of members from a distribution group, to see who removed the member and
distribution groups. when, monitor this event.
reviewed if needed.
High-value distribution groups: You might have a list of Monitor this event with the Group\Group Name values
critical distribution groups in the organization, and need to that correspond to the high-value distribution groups.
specifically monitor these groups for the removal of members
(or for other changes).
Distribution groups with required members: You might Monitor this event with the Group\Group Name that
need to ensure that for certain distribution groups, particular corresponds to the group of interest, and the
members are never removed. Member\Security ID of the members who should not be
removed.
events).
deleted.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
disabled (distribution) global group is deleted.
controllers.

Event XML:
- <System>
<Level>0</Level>
<Task>13827</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the delete group operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the delete group
operation.
Group:
Security ID [Type = SID]: SID of deleted group. Event Viewer automatically tries to resolve SIDs and show
Group Name [Type = UnicodeString]: the name of the group that was deleted. For example: ServiceDesk
Group Domain [Type = UnicodeString]: domain name of deleted group. Formats vary, and include the
following:

For 4753(S): A security-disabled global group was deleted.
If you have a list of critical distribution groups in the organization, and need to specifically monitor these
groups for any change, especially group deletion, monitor events with the Group\Group Name values
that correspond to the critical distribution groups.
If you need to monitor each time a distribution group is deleted, to see who deleted it and when, monitor
this event. Typically, this event is used as an informational event, to be reviewed if needed.
Audit Other Account Management Events
Applies to
Windows 10
Windows Server 2016
Audit Other Account Management Events determines whether the operating system generates user account
management audit events.
Event volume: Typically Low on all types of computers.
This subcategory allows you to audit next events:
The password hash of a user account was accessed. This happens during an Active Directory Management
Tool password migration.
The Password Policy Checking API was called. Password Policy Checking API allows an application to check
password compliance against an application-provided account database or single account and verify that
passwords meet the complexity, aging, minimum length, and history reuse requirements of a password
policy.
STRONGER STRONGER
Domain Yes No Yes No The only reason

Controller to enable Success
auditing on
domain
controllers is to
monitor 4782(S):
The password
hash an account
was accessed.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Member Server No No No No The only event

which is
generated on
Member Servers
is 4793(S): The
Password Policy
Checking API was
called., this event
is a typical
information event
with little to no
security
relevance.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Workstation No No No No The only event

which is
generated on
Workstations is
4793(S): The
Password Policy
Checking API was
called., this event
is a typical
information event
with little to no
security
relevance.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Events List:
4782(S): The password hash an account was accessed.
4793(S): The Password Policy Checking API was called.
4782(S): The password hash an account was accessed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Other Account
Management Events
Event Description:
This event generates on domain controllers
during password migration of an account
using Active Directory Migration Toolkit.
Typically Subject\Security ID is the
SYSTEM account.

Event XML:
- <System>
<Level>0</Level>
<Task>13829</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">Andrei</Data>
<Data Name="SubjectUserSid">S-1-5-18</Data>
<Data Name="SubjectUserName">DC01$</Data>
<Data Name="SubjectLogonId">0x3e7</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested hash migration operation. Event Viewer automatically
tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in
the event.
Account Name [Type = UnicodeString]: the name of the account that requested hash migration operation.
For ANONYMOUS LOGON you will see NT AUTHORITY value for this field.
Target Account:
Account Name [Type = UnicodeString]: the name of the account for which the password hash was
migrated. For example: ServiceDesk
User account example: Andrei
Computer account example: DC01$
Account Domain [Type = UnicodeString]: domain name of the account for which the password hash was
migrated. Formats vary, and include the following:
Domain NETBIOS name example: FABRIKAM
Lowercase full domain name: fabrikam.local
Uppercase full domain name: FABRIKAM.LOCAL

For 4782(S): The password hash an account was accessed.
Monitor for all events of this type, because any actions with accounts password hashes should be planned. If
this action was not planned, investigate the reason for the change.
4793(S): The Password Policy Checking API was
called.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Other Account
Management Events
Event Description:
This event generates each time the Password
Policy Checking API is called.
The Password Policy Checking API allows an
application to check password compliance
against an application-provided account
database or single account and verify that
passwords meet the complexity, aging,
minimum length, and history reuse
requirements of a password policy.
This event, for example, generates during
Directory Services Restore Mode (DSRM)
account password reset procedure to check
new DSRM password.
This event generates on the computer where Password Policy Checking API was called.
Note that starting with Microsoft SQL Server 2005, the SQL Server password policy feature can generate many
4793 events on a SQL Server.
Event XML:
- <System>
<Level>0</Level>
<Task>13829</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectLogonId">0x36f67</Data>
<Data Name="Workstation">DC01</Data>
<Data Name="TargetUserName">-</Data>
</EventData>
</Event>
Required Server Roles: None.

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested Password Policy Checking API operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested Password Policy Checking
API operation.
For local user accounts, this field will contain the name of the computer or device that this account
belongs to, for example: Win81.
Caller Workstation [Type = UnicodeString]: name of the computer from which the Password Policy
Checking API was called. Typically, this is the same computer where this event was generated, for example,
DC01. Computer name here does not contain $ symbol at the end. It also can be an IP address or the DNS
name of the computer.
Provided Account Name (unauthenticated) [Type = UnicodeString]: the name of account, which
password was provided/requested for validation. This parameter might not be captured in the event, and in
that case appears as -.
Status Code [Type = HexInt32]: typically has 0x0 value. Status code is 0x0, no matter meets password
domain Password Policy or not.

For 4793(S): The Password Policy Checking API was called.
Typically this is an informational event, and can give you information about when Password Policy Checking
APIs were invoked, and who invoked them. The Provided Account Name does not always have a value
sometimes its not really possible to determine for which account the password policy check was performed.
Audit Security Group Management
Applies to
Windows 10
Windows Server 2016
Audit Security Group Management determines whether the operating system generates audit events when
specific security group management tasks are performed.
Event volume: Low.
This subcategory allows you to audit events generated by changes to security groups such as the following:
Security group is created, changed, or deleted.
Member is added or removed from a security group.
Group type is changed.
STRONGER STRONGER
Domain Yes No Yes No We recommend

Controller Success auditing
of security
groups, to see
new group
creation events,
changes and
deletion of critical
groups. Also you
will get
information
about new
members of
security groups,
when a member
was removed
from a group and
when security
group
membership was
enumerated.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Member Server Yes No Yes No We recommend

Success auditing
of security
groups, to see
new group
creation events,
changes and
groups. Also you
will get
information
about new
members of
security groups,
when a member
was removed
from a group and
when security
group
membership was
enumerated.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Workstation Yes No Yes No We recommend

Success auditing
of security
groups, to see
new group
creation events,
changes and
groups. Also you
will get
information
about new
members of
security groups,
when a member
was removed
from a group and
when security
group
membership was
enumerated.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Events List:
4731(S): A security-enabled local group was created.
4732(S): A member was added to a security-enabled local group.
4733(S): A member was removed from a security-enabled local group.
4734(S): A security-enabled local group was deleted.
4735(S): A security-enabled local group was changed.
4764(S): A groups type was changed.
4799(S): A security-enabled local group membership was enumerated.
4727(S): A security-enabled global group was created. See event 4731: A security-enabled local group was
created. Event 4727 is the same, but it is generated for a global security group instead of a local security group.
All event fields, XML, and recommendations are the same. The type of group is the only difference.
Important: this event generates only for domain groups, so the Local sections in event 4731 do not apply.
4737(S): A security-enabled global group was changed. See event 4735: A security-enabled local group was
changed. Event 4737 is the same, but it is generated for a global security group instead of a local security
4728(S): A member was added to a security-enabled global group. See event 4732: A member was added
to a security-enabled local group. Event 4728 is the same, but it is generated for a global security group instead
of a local security group. All event fields, XML, and recommendations are the same. The type of group is the only
difference.
4729(S): A member was removed from a security-enabled global group. See event 4733: A member was
removed from a security-enabled local group. Event 4729 is the same, but it is generated for a global security
group instead of a local security group. All event fields, XML, and recommendations are the same. The type of
group is the only difference.
4730(S): A security-enabled global group was deleted. See event 4734: A security-enabled local group was
deleted. Event 4730 is the same, but it is generated for a global security group instead of a local security group.
All event fields, XML, and recommendations are the same. The type of group is the only difference.
4754(S): A security-enabled universal group was created. See event 4731: A security-enabled local group
was created.. Event 4754 is the same, but it is generated for a universal security group instead of a local security
4755(S): A security-enabled universal group was changed. See event 4735: A security-enabled local group
was changed.. Event 4737 is the same, but it is generated for a universal security group instead of a local
security group. All event fields, XML, and recommendations are the same. The type of group is the only difference.
4756(S): A member was added to a security-enabled universal group. See event 4732: A member was
added to a security-enabled local group.. Event 4756 is the same, but it is generated for a universal security
group instead of a local security group. All event fields, XML, and recommendations are the same. The type of
group is the only difference.
4757(S): A member was removed from a security-enabled universal group. See event 4733: A member
was removed from a security-enabled local group.. Event 4757 is the same, but it is generated for a universal
security group instead of a local security group. All event fields, XML, and recommendations are the same. The
type of group is the only difference.
4758(S): A security-enabled universal group was deleted. See event 4734: A security-enabled local group
was deleted.. Event 4758 is the same, but it is generated for a universal security group instead of a local security
4731(S): A security-enabled local group was created.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Security Group
Management
Event Description:
security-enabled (security) local group was
created.
This event generates on domain controllers,
member servers, and workstations.

Monitoring Recommendations for this
event.
Event XML:
- <System>
<Level>0</Level>
<Task>13826</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">AccountOperators</Data>
<Data Name="SubjectLogonId">0x3031e</Data>
<Data Name="SamAccountName">AccountOperators</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the create group operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the create group
operation.
Account Domain [Type = UnicodeString]: subjects domain or computer name. Formats vary, and include
the following:
New Group:
Security ID [Type = SID]: SID of created group. Event Viewer automatically tries to resolve SIDs and show
Group Name [Type = UnicodeString]: the name of the group that was created. For example: ServiceDesk
Group Domain [Type = UnicodeString]: domain or computer name of the created group. Formats vary,
and include the following:
For a local group, this field will contain the name of the computer to which this new group belongs,
for example: Win81.
Attributes:
SAM Account Name [Type = UnicodeString]: This is a name of new group used to support clients and
servers from previous versions of Windows (pre-Windows 2000 logon name). The value of
sAMAccountName attribute of new group object. For example: ServiceDesk. For local groups it is simply a
name of new group.
value of sIDHistory attribute of new group object. This parameter might not be captured in the event, and
in that case appears as -. For local groups it is not applicable and always has - value.

For 4731(S): A security-enabled local group was created.
If you need to monitor each time a new security group is created, to see who created the group and when,
monitor this event.
If you need to monitor the creation of local security groups on different servers, and you use Windows
Event Forwarding to collect events in a central location, check New Group\Group Domain. It should not
be the name of the domain, but instead should be the computer name.
4732(S): A member was added to a security-enabled
local group.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
member was added to a security-enabled
(security) local group.
This event generates on domain
controllers, member servers, and
workstations.
For every added member you will get
enabled local group was changed. event
without any changes in it prior to 4732
event.

for this event.
Event XML:
- <System>
<Level>0</Level>
<Task>13826</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="MemberName">CN=eadmin,CN=Users,DC=contoso,DC=local</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the add member to the group operation. Event
Account Name [Type = UnicodeString]: the name of the account that requested the add member to the
group operation.
the following:
Member:
Security ID [Type = SID]: SID of account that was added to the group. Event Viewer automatically tries to
resolve SIDs and show the group name. If the SID cannot be resolved, you will see the source data in the
event.
Account Name [Type = UnicodeString]: distinguished name of account that was added to the group. For
example: CN=Auditor,CN=Users,DC=contoso,DC=local. For local groups this field typically has - value,
even if new member is a domain account. For some well-known security principals, such as LOCAL SERVICE
or ANONYMOUS LOGON, the value of this field is -.
attributes:
CN - commonName
Group:
Security ID [Type = SID]: SID of the group to which new member was added. Event Viewer automatically
the event.
Group Name [Type = UnicodeString]: the name of the group to which new member was added. For
Group Domain [Type = UnicodeString]: domain or computer name of the group to which the new
member was added. Formats vary, and include the following:
for example: Win81.

For 4732(S): A member was added to a security-enabled local group.
Addition of members to local or domain security If you need to monitor each time a member is added to a
groups: You might need to monitor the addition of members local or domain security group, to see who added the
to local or domain security groups. member and when, monitor this event.
reviewed if needed.
High-value local or domain security groups: You might Monitor this event with the Group\Group Name values
have a list of critical local or domain security groups in the that correspond to the high-value local or domain security
organization, and need to specifically monitor these groups groups.
for the addition of new members (or for other changes).
Examples of critical local or domain groups are built-in local
administrators group, domain admins, enterprise admins, and
so on.
events).
Mismatch between type of account (user or computer) Monitor the type of account added to the group to see if it
and the group it was added to: You might want to monitor matches what the group is intended for.
to ensure that a computer account was not added to a group
intended for users, or a user account was not added to a
group intended for computers.
4733(S): A member was removed from a security-
enabled local group.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates every time member
was removed from security-enabled
(security) local group.
This event generates on domain
controllers, member servers, and
workstations.
For every removed member you will get
enabled local group was changed. event
without any changes in it prior to 4733
event.

for this event.
Event XML:
- <System>
<Level>0</Level>
<Task>13826</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the remove member from the group operation.
Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you
will see the source data in the event.
Account Name [Type = UnicodeString]: the name of the account that requested the remove member
from the group operation.
the following:
Member:
Security ID [Type = SID]: SID of account that was removed from the group. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: distinguished name of account that was removed from the group.
For example: CN=Auditor,CN=Users,DC=contoso,DC=local. For local groups this field typically has -
value, even if removed member is a domain account. For some well-known security principals, such as
LOCAL SERVICE or ANONYMOUS LOGON, the value of this field is -.
attributes:
CN - commonName
Group:
Security ID [Type = SID]: SID of the group from which the member was removed. Event Viewer
automatically tries to resolve SIDs and show the group name. If the SID cannot be resolved, you will see the
Group Name [Type = UnicodeString]: the name of the group from which the member was removed. For
Group Domain [Type = UnicodeString]: domain or computer name of the group from which the member
was removed. Formats vary, and include the following:
For a local group, this field will contain the name of the computer to which this new group belongs, for
example: Win81.

For 4733(S): A member was removed from a security-enabled local group.
Removal of members from local or domain security If you need to monitor each time a member is removed from
groups: You might need to monitor the removal of members a local or domain security group, to see who added the
from local or domain security groups. member and when, monitor this event.
reviewed if needed.
High-value local or domain security groups: You might Monitor this event with the Group\Group Name values
have a list of critical local or domain security groups in the that correspond to the high-value local or domain security
organization, and need to specifically monitor these groups groups.
for the removal of members (or for other changes).
Examples of critical local or domain groups are built-in local
administrators group, domain admins, enterprise admins, and
so on.
Local or domain security groups with required Monitor this event with the Group\Group Name that
members: You might need to ensure that for certain local or corresponds to the group of interest, and the
domain security groups, particular members are never Member\Security ID of the members who should not be
removed. removed.
events).
4734(S): A security-enabled local group was deleted.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
enabled (security) local group is deleted.

event.
Event XML:
- <System>
<Level>0</Level>
<Task>13826</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the delete group operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the delete group
operation.
the following:
Group:
Security ID [Type = SID]: SID of deleted group. Event Viewer automatically tries to resolve SIDs and show
Group Name [Type = UnicodeString]: the name of the group that was deleted. For example: ServiceDesk
Group Domain [Type = UnicodeString]: domain or computer name of the deleted group. Formats vary,
for example: Win81.

For 4734(S): A security-enabled local group was deleted.
If you have a list of critical local or domain security groups in the organization, and need to specifically
monitor these groups for any change, especially group deletion, monitor events with the Group\Group
Name values that correspond to the critical local or domain security groups. Examples of critical local or
domain groups are built-in local administrators group, domain admins, enterprise admins, and so on.
If you need to monitor each time a local or domain security group is deleted, to see who deleted it and
when, monitor this event. Typically, this event is used as an informational event, to be reviewed if needed.
4735(S): A security-enabled local group was
changed.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates every time a security-
enabled (security) local group is changed.
Some changes do not invoke a 4735 event,
for example, changes made using Active
Directory Users and Computers management
console in Managed By tab in group account
properties.
If you change the name of the group (SAM
Account Name), you also get 4781: The
name of an account was changed if Audit
User Account Management subcategory
success auditing is enabled.
If you change the group type, you get a
change event from the new group type auditing subcategory instead of 4735. If you need to monitor for group
type changes, it is better to monitor for 4764: A groups type was changed. These events are generated for any
group type when group type is changed. Audit Security Group Management subcategory success auditing must
be enabled.
From 4735 event you can get information about changes of sAMAccountName and sIDHistory attributes or
you will see that something changed, but will not be able to see what exactly changed.
Event XML:
- <System>
<Level>0</Level>
<Task>13826</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">AccountOperators\_NEW</Data>
<Data Name="SamAccountName">AccountOperators\_NEW</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the change group operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the change group
operation.
the following:
Group:
Security ID [Type = SID]: SID of changed group. Event Viewer automatically tries to resolve SIDs and show the
group name. If the SID cannot be resolved, you will see the source data in the event.
Note Sometimes you can see the Group\Security ID field contains an old group name in Event Viewer (as
you can see in the event example). That happens because Event Viewer caches names for SIDs that it has
already resolved for the current session.
Note Security ID field has the same value as new group name (Changed Attributes>SAM Account
Name). That is happens because event is generated after name was changed and SID resolves to the new
name. It is always better to use SID instead of group names for queries or filtering of events, because you will
know for sure that this the right object you are looking for or want to monitor.
Group Name [Type = UnicodeString]: the name of the group that was changed. For example: ServiceDesk
Group Domain [Type = UnicodeString]: domain or computer name of the changed group. Formats vary,
for example: Win81.
Changed Attributes:
You might see a 4735 event without any changes inside, that is, where all Changed Attributes apear as -. This
usually happens when a change is made to an attribute that is not listed in the event. In this case there is no way
to determine which attribute was changed. For example, this would happen if you change the Description of a
group object using the Active Directory Users and Computers administrative console. Also, if the discretionary
access control list (DACL) is changed, a 4735 event will generate, but all attributes will be -.
SAM Account Name [Type = UnicodeString]: This is a new name of changed group used to support
clients and servers from previous versions of Windows (pre-Windows 2000 logon name). If the value of
sAMAccountName attribute of group object was changed, you will see the new value here. For example:
ServiceDesk. For local groups it is simply a new name of the group, if it was changed.
attribute of group object was changed, you will see the new value here. For local groups it is not applicable
and always has - value.

For 4735(S): A security-enabled local group was changed.
If you have a list of critical local or domain security groups in the organization, and need to specifically
monitor these groups for any change, monitor events with the Group\Group Name values that
correspond to the critical local or domain security groups.
If you need to monitor each time a member is added to a local or domain security group, to see who added
the member and when, monitor this event. Typically, this event is used as an informational event, to be
reviewed if needed.
4764(S): A groups type was changed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit
Security Group
Management
Event Description:
This event generates
every time groups type
is changed.
This event generates for
both security and
distribution groups.
only on domain
controllers.
Note For
Security Monitoring
Recommendations for
this event.
Event XML:
- <System>
<Level>0</Level>
<Task>13826</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="GroupTypeChange">Security Enabled Local Group Changed to Security Disabled Local Group.</Data>
<Data Name="TargetUserName">CompanyAuditors</Data>
<Data Name="SubjectLogonId">0x38200</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the change group type operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the change group type
operation.
the following:
Change Type [Type = UnicodeString]: contains three parts: <Param1> Changed To <Param2>.. These two
parameters can have the following values (they cannot have the same value at the same time):
Security Disabled Local Group
Security Disabled Universal Group
Security Disabled Global Group
Security Enabled Local Group
Security Enabled Universal Group
Security Enabled Global Group
Group:
Security ID [Type = SID]: SID of changed group. Event Viewer automatically tries to resolve SIDs and show
Group Name [Type = UnicodeString]: the name of the group, which type was changed. For example:
ServiceDesk
Group Domain [Type = UnicodeString]: domain or computer name of the changed group. Formats vary,
for example: Win81.

For 4764(S): A groups type was changed.
If you have a list of critical local or domain groups in the organization, and need to specifically monitor
these groups for any change, especially group type change, monitor events with the Group\Group
Name values that correspond to the critical distribution groups. Examples of critical local or domain
groups are built-in local administrators group, domain admins, enterprise admins, critical distribution
groups, and so on.
If you need to monitor each time any groups type is changed, to see who changed it and when, monitor
this event. Typically, this event is used as an informational event, to be reviewed if needed.
4799(S): A security-enabled local group membership
was enumerated.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates when a process enumerates
the members of a security-enabled local group
on the computer or device.
This event doesn't generate when group
members were enumerated using Active
Directory Users and Computers snap-in.

Event XML:
- <System>
<Level>0</Level>
<Task>13826</Task>
<Opcode>0</Opcode>
<Correlation ActivityID="{CBAEDE08-1CF0-0000-50DE-AECBF01CD101}" />
<Computer>WIN10-1.contoso.local</Computer>
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">Administrators</Data>
<Data Name="TargetDomainName">Builtin</Data>
<Data Name="TargetSid">S-1-5-32-544</Data>
<Data Name="SubjectLogonId">0x72d9d</Data>
<Data Name="CallerProcessId">0xc80</Data>
<Data Name="CallerProcessName">C:\\Windows\\System32\\mmc.exe</Data>
</EventData>
</Event>
Required Server Roles: none.

Minimum OS Version: Windows Server 2016, Windows 10.
Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the enumerate security-enabled local group members
operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be
resolved, you will see the source data in the event.
Account Name [Type = UnicodeString]: the name of the account that requested the enumerate security-
enabled local group members operation.
the following:
Group:
Security ID [Type = SID]: SID of the group which members were enumerated. Event Viewer automatically
tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data
in the event.
Group Name [Type = UnicodeString]: the name of the group which members were enumerated.
Group Domain [Type = UnicodeString]: groups domain or computer name. Formats vary, and
For Builtin groups this field has Builtin value.
For a local group, this field will contain the name of the computer to which this group belongs, for
example: Win81.
Process Information:
Process ID [Type = Pointer]: hexadecimal Process ID of the process that enumerated the members of the
group. Process ID (PID) is a number used by the operating system to uniquely identify an active process. To
see the PID for a specific process you can, for example, use Task Manager (Details tab, PID column):
If you convert the hexadecimal value to decimal, you can compare it to the values in Task Manager.
You can also correlate this process ID with a process ID in other events, for example, 4688: A new process has been
created Process Information\New Process ID.
Process Name [Type = UnicodeString]: full path and the name of the executable for the process.

For 4799(S): A security-enabled local group membership was enumerated.
If you have a list of critical local security groups in the organization, and need to specifically monitor these
groups for any access (in this case, enumeration of group membership), monitor events with the
Group\Group Name values that correspond to the critical local security groups. Examples of critical local
groups are built-in local administrators, built-in backup operators, and so on.
If you need to monitor each time the membership is enumerated for a local or domain security group, to see
who enumerated the membership and when, monitor this event. Typically, this event is used as an
informational event, to be reviewed if needed.
Audit User Account Management
Applies to
Windows 10
Windows Server 2016
Audit User Account Management determines whether the operating system generates audit events when
specific user account management tasks are performed.
Event volume: Low.
This policy setting allows you to audit changes to user accounts. Events include the following:
A user account is created, changed, deleted, renamed, disabled, enabled, locked out or unlocked.
A user accounts password is set or changed.
A security identifier (SID) is added to the SID History of a user account, or fails to be added.
The Directory Services Restore Mode password is configured.
Permissions on administrative user accounts are changed.
A user's local group membership was enumerated.
Credential Manager credentials are backed up or restored.
Some events in this subcategory, for example 4722, 4725, 4724, and 4781, are also generated for computer
accounts.
STRONGER STRONGER
STRONGER STRONGER
Domain Yes Yes Yes Yes This subcategory

Controller contains many
useful events for
monitoring,
especially for
critical domain
accounts, such as
domain admins,
service accounts,
database admins,
and so on.
We recommend
Failure auditing,
mostly to see
invalid password
change and reset
attempts for
domain
accounts, DSRM
account
password change
failures, and
failed SID History
add attempts.
Member Server Yes Yes Yes Yes We recommend

monitoring all
changes related
to local user
accounts,
especially built-in
local
Administrator
and other critical
accounts.
We recommend
Failure auditing,
mostly to see
invalid password
change and reset
attempts for
local accounts.
Workstation Yes Yes Yes Yes We recommend

monitoring all
changes related
to local user
accounts,
especially built-in
local
Administrator
and other critical
accounts.
We recommend
Failure auditing,
mostly to see
invalid password
change and reset
attempts for
local accounts.
Events List:
4720(S): A user account was created.
4722(S): A user account was enabled.
4723(S, F): An attempt was made to change an account's password.
4724(S, F): An attempt was made to reset an account's password.
4725(S): A user account was disabled.
4726(S): A user account was deleted.
4738(S): A user account was changed.
4740(S): A user account was locked out.
4765(S): SID History was added to an account.
4766(F): An attempt to add SID History to an account failed.
4767(S): A user account was unlocked.
4780(S): The ACL was set on accounts which are members of administrators groups.
4781(S): The name of an account was changed.
4794(S, F): An attempt was made to set the Directory Services Restore Mode administrator password.
4798(S): A user's local group membership was enumerated.
5376(S): Credential Manager credentials were backed up.
5377(S): Credential Manager credentials were restored from a backup.
4720(S): A user account was created.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit User Account
Management
Event Description:
This event generates every time a new user
object is created.

Event XML:
- <System>
<Level>0</Level>
<Task>13824</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">ksmith</Data>
<Data Name="SubjectLogonId">0x30dc2</Data>
<Data Name="SamAccountName">ksmith</Data>
<Data Name="DisplayName">Ken Smith</Data>
<Data Name="UserPrincipalName">ksmith@contoso.local</Data>
<Data Name="PasswordLastSet">%%1794</Data>
<Data Name="AccountExpires">%%1794</Data>
<Data Name="PrimaryGroupId">513</Data>
<Data Name="UserAccountControl">%%2080 %%2082 %%2084</Data>
<Data Name="LogonHours">%%1793</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the create user account operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the create user account
operation.
the following:
New Account:
Security ID [Type = SID]: SID of created user account. Event Viewer automatically tries to resolve SIDs and
show the account name. If the SID cannot be resolved, you will see the source data in the event.
Account Name [Type = UnicodeString]: the name of the user account that was created. For example:
dadmin.
Account Domain [Type = UnicodeString]: domain name of created user account. Formats vary, and include
the following:
For local accounts, this field will contain the name of the computer to which this new account belongs,
for example: Win81.
Attributes:
from previous versions of Windows (pre-Windows 2000 logon name). The value of sAMAccountName
attribute of new user object. For example: ksmith. For local account this field contains the name of new user
account.
Display Name [Type = UnicodeString]: the value of displayName attribute of new user object. It is a name
displayed in the address book for a particular account .This is usually the combination of the user's first
name, middle initial, and last name. For example, Ken Smith. You can change this attribute by using Active
Directory Users and Computers, or through a script, for example. Local accounts contain Full Name
attribute in this field, but for new local accounts this field typically has value <value not set>.
Internet standard RFC 822. By convention this should map to the account's email name. This parameter
contains the value of userPrincipalName attribute of new user object. For example, ksmith@contoso.local.
For local users this field is not applicable and has value -. You can change this attribute by using Active
Directory Users and Computers, or through a script, for example.
\\Server\Share\Directory. This parameter contains the value of homeDirectory attribute of new user object.
For new local accounts this field typically has value <value not set>. You can change this attribute by
using Active Directory Users and Computers, or through a script, for example. This parameter might not be
example H:. This parameter contains the value of homeDrive attribute of new user object. You can
change this attribute by using Active Directory Users and Computers, or through a script, for example. This
parameter might not be captured in the event, and in that case appears as -. For new local accounts this
field typically has value <value not set>.
Script Path [Type = UnicodeString]: specifies the path of the accounts logon script. This parameter contains
the value of scriptPath attribute of new user object. You can change this attribute by using Active Directory
Users and Computers, or through a script, for example. This parameter might not be captured in the event,
and in that case appears as -. For new local accounts this field typically has value <value not set>.
a local absolute path, or a UNC path. This parameter contains the value of profilePath attribute of new user
object. You can change this attribute by using Active Directory Users and Computers, or through a script, for
example. This parameter might not be captured in the event, and in that case appears as -. For new local
accounts this field typically has value <value not set>.
the sAMAccountName property of a user object. This parameter contains the value of userWorkstations
attribute of new user object. You can change this attribute by using Active Directory Users and Computers,
or through a script, for example. This parameter might not be captured in the event, and in that case appears
as -. For local users this field is not applicable and typically has value <value not set>.
Password Last Set [Type = UnicodeString]: last time the accounts password was modified. For manually
created user account, using Active Directory Users and Computers snap-in, this field typically has value
<never>. This parameter contains the value of pwdLastSet attribute of new user object.
Account Expires [Type = UnicodeString]: the date when the account expires. This parameter contains the
value of accountExpires attribute of new user object. You can change this attribute by using Active
Directory Users and Computers, or through a script, for example. This parameter might not be captured in
the event, and in that case appears as -. For manually created local and domain user accounts this field
typically has value <never>.
Primary Group ID [Type = UnicodeString]: Relative Identifier (RID) of users object primary group.
domain.
Typically, Primary Group field for new user accounts has the following values:
513 (Domain Users. For local accounts this RID means Users) for domain and local users.
See this article https://support.microsoft.com/en-us/kb/243330 for more information. This parameter
contains the value of primaryGroupID attribute of new user object.
Allowed To Delegate To [Type = UnicodeString]: the list of SPNs to which this account can present delegated
credentials. Can be changed using Active Directory Users and Computers management console in Delegation
tab of user account, if this account has at least one SPN registered. This parameter contains the value of
AllowedToDelegateTo attribute of new user object. For local user accounts this field is not applicable and
typically has value -. For new domain user accounts it is typically has value -. See description of
AllowedToDelegateTo field for 4738(S): A user account was changed. event for more details.
Old UAC Value [Type = UnicodeString]: specifies flags that control password, lockout, disable/enable, script,
and other behavior for the user account. Old UAC value always 0x0 for new user accounts. This
parameter contains the previous value of userAccountControl attribute of user object.
script, and other behavior for the user account. This parameter contains the value of userAccountControl
attribute of new user object.
the next flag.
Decoding:
LOCKOUT 0x0010
(undeclared) 0x0004
SCRIPT 0x0001
You will see a line of text for each change. For new user accounts, when the object for this account was created,
the userAccountControl value was considered to be 0x0, and then it was changed from 0x0 to the real
value for the account's userAccountControl attribute. See possible values in the table below. In the User
Account Control field text column, you can see the text that will be displayed in the User Account Control field
in 4720 event.

SCRIPT 0x0001 1 The logon script will Changes of this flag

be run. do not show in 4720
events.
ACCOUNTDISABLE 0x0002 2 The user account is Account Disabled

disabled. Account Enabled
Undeclared 0x0004 4 This flag is Changes of this flag

undeclared. do not show in 4720
events.
HOMEDIR_REQUIRED 0x0008 8 The home folder is 'Home Directory

'Home Directory
LOCKOUT 0x0010 16 Changes of this flag

do not show in 4720
events.
PASSWD_NOTREQD 0x0020 32 No password is 'Password Not

'Password Not
PASSWD_CANT_CHA 0x0040 64 The user cannot Changes of this flag

NGE change the password. do not show in 4720
This is a permission events.
on the user's object.
ENCRYPTED_TEXT_PW 0x0080 128 The user can send an 'Encrypted Text

D_ALLOWED encrypted password. Password Allowed' -
Can be set using Disabled
Store password using 'Encrypted Text
reversible encryption Password Allowed' -
checkbox. Enabled
TEMP_DUPLICATE_AC 0x0100 256 This is an account for Cannot be set for

COUNT users whose primary computer account.
account is in another
domain. This account
provides user access
to this domain, but
not to any domain
that trusts this
domain. This is
sometimes referred to
as a local user
account.
NORMAL_ACCOUNT 0x0200 512 This is a default 'Normal Account' -

account type that Disabled
represents a typical 'Normal Account' -
user. Enabled
INTERDOMAIN_TRUS 0x0800 2048 This is a permit to Cannot be set for

T_ACCOUNT trust an account for a computer account.
system domain that
trusts other domains.
WORKSTATION_TRUS 0x1000 4096 This is a computer 'Workstation Trust

T_ACCOUNT account for a Account' - Disabled
computer that is 'Workstation Trust
running Microsoft Account' - Enabled
Windows NT 4.0
Workstation,
Microsoft Windows
NT 4.0 Server,
Microsoft Windows
2000 Professional, or
Windows 2000 Server
and is a member of
this domain.
SERVER_TRUST_ACCO 0x2000 8192 This is a computer 'Server Trust Account'

UNT account for a domain - Enabled
controller that is a 'Server Trust Account'
member of this - Disabled
domain.
DONT_EXPIRE_PASSW 0x10000 65536 Represents the 'Don't Expire

ORD password, which Password' - Disabled
should never expire 'Don't Expire
on the account. Password' - Enabled
Can be set using
Password never
expires checkbox.
MNS_LOGON_ACCO 0x20000 131072 This is an MNS logon 'MNS Logon Account'

UNT account. - Disabled
'MNS Logon Account'
- Enabled
SMARTCARD_REQUIR 0x40000 262144 When this flag is set, 'Smartcard Required' -

ED it forces the user to Disabled
log on by using a 'Smartcard Required' -
smart card. Enabled
TRUSTED_FOR_DELEG 0x80000 524288 When this flag is set, 'Trusted For

ATION the service account Delegation' - Enabled
(the user or computer 'Trusted For
account) under which Delegation' - Disabled
a service runs is
delegation. Any such
service can
impersonate a client
requesting the
service. To enable a
service for Kerberos
delegation, you must
set this flag on the
userAccountControl
property of the
service account.
If you enable
Kerberos constraint or
unconstraint
these types of
delegation in
Delegation tab you
will get this flag
changed.
NOT_DELEGATED 0x100000 1048576 When this flag is set, 'Not Delegated' -

the security context of Disabled
the user is not 'Not Delegated' -
delegated to a service Enabled
even if the service
account is set as
delegation.
Can be set using
Account is sensitive
and cannot be
delegated checkbox.
USE_DES_KEY_ONLY 0x200000 2097152 Restrict this principal 'Use DES Key Only' -
to use only Data Disabled
Encryption Standard 'Use DES Key Only' -
(DES) encryption Enabled
types for keys.
Can be set using Use
Kerberos DES
encryption types for
this account
checkbox.
DONT_REQ_PREAUTH 0x400000 4194304 This account does not 'Don't Require

require Kerberos pre- Preauth' - Disabled
authentication for 'Don't Require
logging on. Preauth' - Enabled
Can be set using Do
not require Kerberos
preauthentication
checkbox.
PASSWORD_EXPIRED 0x800000 8388608 The user's password Changes of this flag

has expired. do not show in 4720
events.
TRUSTED_TO_AUTH_F 0x1000000 16777216 The account is 'Trusted To

OR_DELEGATION enabled for Authenticate For
delegation. This is a Delegation' - Disabled
security-sensitive 'Trusted To
setting. Accounts that Authenticate For
have this option Delegation' - Enabled
enabled should be
tightly controlled. This
setting lets a service
that runs under the
account assume a
client's identity and
authenticate as that
user to other remote
servers on the
network.
If you enable
Kerberos protocol
transition delegation
or disable this type of
delegation in
Delegation tab you
will get this flag
changed.
PARTIAL_SECRETS_AC 0x04000000 67108864 The account is a read- No information.

COUNT only domain
controller (RODC).
This is a security-
sensitive setting.
Removing this setting
from an RODC
compromises security
on that server.
For new, manually created, domain or local user accounts typical flags are:
Account Disabled
'Password Not Required' - Enabled
'Normal Account' Enabled
After new user creation event you will typically see couple of 4738: A user account was changed. events
with new flags:
'Password Not Required' Disabled
Account Enabled
Computers management console in Dial-in tab of users account properties, then you will see <value
changed, but not displayed> in this field in 4738: A user account was changed. This parameter might
not be captured in the event, and in that case appears as -. For new local accounts this field typically has
value <value not set>.
value of sIDHistory attribute of new user object. This parameter might not be captured in the event, and in
that case appears as -.
Logon Hours [Type = UnicodeString]: hours that the account is allowed to logon to the domain. The value
of logonHours attribute of new user object. You can change this attribute by using Active Directory Users
and Computers, or through a script, for example. You will typically see <value not set> value for new
manually created user accounts in event 4720. For new local accounts this field is not applicable and
typically has value All.

For 4720(S): A user account was created.
Some organizations monitor every 4720 event.

SAM Account Name is empty or - This field must contain the user account name. If it is empty or
-, it might indicate an anomaly.
User Principal Name is empty or - Typically this field should not be empty for new user accounts.
If it is empty or -, it might indicate an anomaly.
Home Directory is not - Typically these fields are - for new user accounts. Other values
Home Drive is not - might indicate an anomaly and should be monitored.
Script Path is not - For local accounts these fields should display <value not
Profile Path is not - set>.
Password Last Set is <never> This typically means this is a manually created user account,
which you might need to monitor.
Password Last Set is a time in the future This might indicate an anomaly.
Account Expires is not <never> Typically this field is <never> for new user accounts. Other
values might indicate an anomaly and should be monitored.
Primary Group ID is not 513 Typically, the Primary Group value is 513 for domain and
local users. Other values should be monitored.
Allowed To Delegate To is not - Typically this field is - for new user accounts. Other values
might indicate an anomaly and should be monitored.
Old UAC Value is not 0x0 Typically this field is 0x0 for new user accounts. Other values
might indicate an anomaly and should be monitored.
Logon Hours value other than <value not set> or** All** This should always be <value not set> for new domain user
accounts, and All for new local user accounts.
Consider whether to track the following user account control flags:
'Normal Account' Disabled Should not be disabled for user accounts.
'Encrypted Text Password Allowed' Enabled By default, these flags should not be enabled for new user
'Smartcard Required' Enabled accounts created with the Active Directory Users and
'Not Delegated' Enabled Computers snap-in.
'Use DES Key Only' Enabled
'Don't Require Preauth' Enabled
'Trusted To Authenticate For Delegation' Enabled
'Server Trust Account' Enabled Should never be enabled for user accounts. Applies only to
domain controller (computer) accounts.
'Don't Expire Password' Enabled Should be monitored for critical accounts, or all accounts if
your organization does not allow this flag. By default, this flag
should not be enabled for new user accounts created with the
Active Directory Users and Computers snap-in.
'Trusted For Delegation' Enabled By default, this flag should not be enabled for new user
accounts created with the Active Directory Users and
Computers snap-in. It is enabled by default only for new
domain controllers.
4722(S): A user account was enabled.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates every time user or
computer object is enabled.
For user accounts, this event generates on
domain controllers, member servers, and
workstations.
For computer accounts, this event generates
only on domain controllers.

Event XML:
- <System>
<Level>0</Level>
<Task>13824</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">Auditor</Data>
<Data Name="SubjectLogonId">0x30d5f</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the enable account operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the enable account
operation.
the following:
Target Account:
Security ID [Type = SID]: SID of account that was enabled. Event Viewer automatically tries to resolve SIDs
Account Name [Type = UnicodeString]: the name of the account that was enabled.
Account Domain [Type = UnicodeString]: target accounts domain or computer name. Formats vary, and

For 4722(S): A user account was enabled.
If you have a high-value domain or local account for which you need to monitor every change, monitor all
4722 events with the Target Account\Security ID that corresponds to the account.
If you have domain or local accounts that should never be enabled, you can monitor all 4722 events with
the Target Account\Security ID fields that correspond to the accounts.
We recommend monitoring all 4722 events for local accounts, because these accounts usually do not
change often. This is especially relevant for critical servers, administrative workstations, and other high value
assets.
4723(S, F): An attempt was made to change an
account's password.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates every time a user
attempts to change his or her password.
workstations.
For domain accounts, a Failure event generates
if new password fails to meet the password
policy.
For local accounts, a Failure event generates if
new password fails to meet the password
policy or old password is wrong.
For domain accounts if old password was
wrong, then 4771: Kerberos pre-
authentication failed or 4776: The computer attempted to validate the credentials for an account will be
generated on domain controller if specific subcategories were enabled on it.
Typically you will see 4723 events with the same Subject\Security ID and Target Account\Security ID fields,
which is normal behavior.
Event XML:
- <System>
<Level>0</Level>
<Task>13824</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectLogonId">0x1a9b76</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made an attempt to change Targets Account password. Event
Account Name [Type = UnicodeString]: the name of the account that made an attempt to change Targets
Account password.
the following:
Target Account: account for which the password change was requested.
Security ID [Type = SID]: SID of account for which the password change was requested. Event Viewer
Account Name [Type = UnicodeString]: the name of the account for which the password change was
requested.

For 4723(S, F): An attempt was made to change an account's password.
If you have a high-value domain or local user account for which you need to monitor every password
change attempt, monitor all 4723 events with the Target Account\Security ID that corresponds to the
account.
If you have domain or local accounts for which the password should never be changed, you can monitor all
4724(S, F): An attempt was made to reset an
account's password.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates every time an account
attempted to reset the password for another
account.
workstations.
For domain accounts, a Failure event
generates if the new password fails to meet
the password policy.
A Failure event does NOT generate if user gets
Access Denied while doing the password
reset procedure.
This event also generates if a computer account reset procedure was performed.
For local accounts, a Failure event generates if the new password fails to meet the local password policy.
Event XML:
- <System>
<Level>0</Level>
<Task>13824</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">User1</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made an attempt to reset Targets Account password. Event
Account Name [Type = UnicodeString]: the name of the account that made an attempt to reset Targets
Account password.
the following:
Target Account: account for which password reset was requested.
Security ID [Type = SID]: SID of account for which password reset was requested. Event Viewer
Account Name [Type = UnicodeString]: the name of the account for which password reset was requested.

For 4724(S, F): An attempt was made to reset an account's password.
If you have a high-value domain or local user account for which you need to monitor every password reset
attempt, monitor all 4724 events with the Target Account\Security ID that corresponds to the account.
If you have domain or local accounts for which the password should never be reset, you can monitor all
We recommend monitoring all 4724 events for local accounts, because their passwords usually do not
change often. This is especially relevant for critical servers, administrative workstations, and other high
value assets.
4725(S): A user account was disabled.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates every time user or
computer object is disabled.
workstations.

Event XML:
- <System>
<Level>0</Level>
<Task>13824</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the disable account operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the disable account
operation.
the following:
Target Account:
Security ID [Type = SID]: SID of account that was disabled. Event Viewer automatically tries to resolve SIDs
Account Name [Type = UnicodeString]: the name of the account that was disabled.

For 4725(S): A user account was disabled.
If you have domain or local accounts that should never be disabled (for example, service accounts), you can
monitor all 4725 events with the Target Account\Security ID that corresponds to the account.
We recommend monitoring all 4725 events for local accounts, because these accounts usually do not
change often. This is especially relevant for critical servers, administrative workstations, and other high value
assets.
4726(S): A user account was deleted.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates every time user object
was deleted.

Event XML:
- <System>
<Level>0</Level>
<Task>13824</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the delete user account operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the delete user account
operation.
the following:
Target Account:
Security ID [Type = SID]: SID of account that was deleted. Event Viewer automatically tries to resolve SIDs
Account Name [Type = UnicodeString]: the name of the account that was deleted.

For 4726(S): A user account was deleted.
If you have a high-value domain or local account for which you need to monitor every change (or deletion),
monitor all 4726 events with the Target Account\Security ID that corresponds to the account.
If you have a domain or local account that should never be deleted (for example, service accounts), monitor
all 4726 events with the Target Account\Security ID that corresponds to the account.
We recommend monitoring all 4726 events for local accounts, because these accounts typically are not
deleted often. This is especially relevant for critical servers, administrative workstations, and other high
value assets.
4738(S): A user account was changed.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates every time user object is
changed.
For each change, a separate 4738 event will
be generated.
You might see this event without any changes
inside, that is, where all Changed Attributes
apear as -. This usually happens when a
change is made to an attribute that is not
listed in the event. In this case there is no way
to determine which attribute was changed.
For example, if the discretionary access
control list (DACL) is changed, a 4738 event
will generate, but all attributes will be -.
Some changes do not invoke a 4738 event.

event.
Event XML:
- <System>
<Level>0</Level>
<Task>13824</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="Dummy">-</Data>
<Data Name="SubjectLogonId">0x30dc2</Data>
<Data Name="SamAccountName">-</Data>
<Data Name="PasswordLastSet">-</Data>
<Data Name="AccountExpires">-</Data>
<Data Name="PrimaryGroupId">-</Data>
<Data Name="UserAccountControl">%%2050 %%2089</Data>
<Data Name="LogonHours">-</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the change user account operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the change user account
operation.
the following:
Target Account:
Security ID [Type = SID]: SID of account that was changed. Event Viewer automatically tries to resolve SIDs
Account Name [Type = UnicodeString]: the name of the account that was changed.
Changed Attributes:
If attribute was not changed it will have value.
Unfortunately, for local accounts, all fields, except changed attributes, will have previous values populated. Also,
the User Account Control field will have values only if it was modified. Changed attributes will have new values,
but it is hard to understand which attribute was really changed.
from previous versions of Windows (pre-Windows 2000 logon name). If the value of sAMAccountName
attribute of user object was changed, you will see the new value here. For example: ladmin. For local
accounts, this field always has some valueif the account's attribute was not changed it will contain the
current value of the attribute.
Display Name [Type = UnicodeString]: it is a name, displayed in the address book for a particular account.
This is usually the combination of the user's first name, middle initial, and last name. You can change this
attribute by using Active Directory Users and Computers, or through a script, for example. If the value of
displayName attribute of user object was changed, you will see the new value here. For local accounts, this
field always has some valueif the account's attribute was not changed it will contain the current value of
the attribute.
Internet standard RFC 822. By convention this should map to the account's email name. If the value of
userPrincipalName attribute of user object was changed, you will see the new value here. You can change
this attribute by using Active Directory Users and Computers, or through a script, for example. For local
accounts, this field is not applicable and always has - value.
Home Directory [Type = UnicodeString]: user's home directory. If homeDrive attribute is set and
specifies a drive letter, homeDirectory should be a UNC path. The path must be a network UNC of the
form \\Server\Share\Directory. If the value of homeDirectory attribute of user object was changed, you
will see the new value here. You can change this attribute by using Active Directory Users and Computers,
or through a script, for example. For local accounts, this field always has some valueif the account's
attribute was not changed it will contain the current value of the attribute.
example H:. If the value of homeDrive attribute of user object was changed, you will see the new value
here. You can change this attribute by using Active Directory Users and Computers, or through a script, for
example. For local accounts, this field always has some valueif the account's attribute was not changed it
will contain the current value of the attribute.
Script Path [Type = UnicodeString]: specifies the path of the accounts logon script. If the value of
scriptPath attribute of user object was changed, you will see the new value here. You can change this
attribute by using Active Directory Users and Computers, or through a script, for example. For local
Profile Path [Type = UnicodeString]: specifies a path to the account's profile. This value can be a null
string, a local absolute path, or a UNC path. If the value of profilePath attribute of user object was
changed, you will see the new value here. You can change this attribute by using Active Directory Users and
Computers, or through a script, for example. For local accounts, this field always has some valueif the
account's attribute was not changed it will contain the current value of the attribute.
the sAMAccountName property of a computer object. If the value of userWorkstations attribute of user
object was changed, you will see the new value here. You can change this attribute by using Active
Directory Users and Computers, or through a script, for example. For local accounts, this field is not
applicable and always appears as <value not set>.
Password Last Set [Type = UnicodeString]: last time the accounts password was modified. If the value of
pwdLastSet attribute of user object was changed, you will see the new value here. For example: 8/12/2015
11:41:39 AM. This value will be changed, for example, after manual user account password reset. For local
Account Expires [Type = UnicodeString]: the date when the account expires. If the value of
accountExpires attribute of user object was changed, you will see the new value here. . For example,
9/21/2015 12:00:00 AM. You can change this attribute by using Active Directory Users and Computers, or
through a script, for example. For local accounts, this field always has some valueif the account's attribute
was not changed it will contain the current value of the attribute.
Primary Group ID [Type = UnicodeString]: Relative Identifier (RID) of users object primary group.
domain.
This field will contain some value if users object primary group was changed. You can change users primary
group using Active Directory Users and Computers management console in the Member Of tab of user object
properties. You will see a RID of new primary group as a field value. For example, RID 513 (Domain Users) is a
default primary group for users.
Typical Primary Group values for user accounts:
513 (Domain Users. For local accounts this RID means Users) for domain and local users.
See this article https://support.microsoft.com/en-us/kb/243330 for more information. If the value of
primaryGroupID attribute of user object was changed, you will see the new value here.
AllowedToDelegateTo [Type = UnicodeString]: the list of SPNs to which this account can present
delegated credentials. Can be changed using Active Directory Users and Computers management console
in Delegation tab of user account, if at least one SPN is registered for user account. If the SPNs list on
Delegation tab of a user account was changed, you will see the new SPNs list in AllowedToDelegateTo
field (note that you will see the new list instead of changes) of this event. This is an example of
AllowedToDelegateTo:
dcom/WIN2012
dcom/WIN2012.contoso.local
If the value of msDS-AllowedToDelegateTo attribute of user object was changed, you will see the
new value here.
The value can be <value not set>, for example, if delegation was disabled.
For local accounts, this field is not applicable and always has - value.
service. If you install multiple instances of a service on computers throughout a forest, each instance must
have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients
might use for authentication. For example, an SPN always includes the name of the host computer on which
the service instance is running, so a service instance might register an SPN for each name or alias of its host.
Old UAC Value [Type = UnicodeString]: specifies flags that control password, lockout, disable/enable,
script, and other behavior for the user account. This parameter contains the previous value of
userAccountControl attribute of user object.
script, and other behavior for the user account. If the value of userAccountControl attribute of user object
was changed, you will see the new value here.
event. Subtract the property value from the flags value in the event and note that the flag applies and then go on
to the next flag.
Decoding:
LOCKOUT 0x0010
(undeclared) 0x0004
SCRIPT 0x0001
User Account Control [Type = UnicodeString]: shows the list of changes in userAccountControl
attribute. You will see a line of text for each change. See possible values in here: Table 7. Users or
Computers account UAC flags.. In the User Account Control field text column, you can see the text that
will be displayed in the User Account Control field in 4738 event.
Computers management console in Dial-in tab of users account properties, then you will see <value
changed, but not displayed> in this field. For local accounts, this field is not applicable and always has
<value not set> value.
attribute of user object was changed, you will see the new value here.
Logon Hours [Type = UnicodeString]: hours that the account is allowed to logon to the domain. If the
value of logonHours attribute of user object was changed, you will see the new value here. You can
change this attribute by using Active Directory Users and Computers, or through a script, for example. Here
is an example of this field:
Sunday 12:00 AM - 7:00 PM
Sunday 9:00 PM -Monday 1:00 PM
Monday 2:00 PM -Tuesday 6:00 PM
Tuesday 8:00 PM -Wednesday 10:00 AM
For local accounts this field is not applicable and typically has value All.

For 4738(S): A user account was changed.
Some organizations monitor every 4738 event.

If you have critical user computer accounts (for example, domain administrator accounts or service
accounts) for which you need to monitor each change, monitor this event with the Target
Account\Account Name that corresponds to the critical account or accounts.
If you have user accounts for which any change in the services list on the Delegation tab should be
monitored, monitor this event when AllowedToDelegateTo is not -. This value means the services list was
changed.
Consider whether to track the following fields:
FIELD TO TRACK REASON TO TRACK
Display Name We recommend monitoring all changes for these fields for
User Principal Name critical domain and local accounts.
Home Directory
Home Drive
Script Path
Profile Path
User Workstations
Password Last Set
Account Expires
Primary Group ID
Logon Hours
Primary Group ID is not 513 Typically, the Primary Group value is 513 for domain and
local users. Other values should be monitored.
For user accounts for which the services list (on the If AllowedToDelegateTo is marked <value not set> on
Delegation tab) should not be empty: user accounts that previously had a services list (on the
AllowedToDelegateTo is marked **<value not set> ** Delegation tab), it means the list was cleared.
Consider whether to track the following user account control flags:
'Normal Account' Disabled Should not be disabled for user accounts.
'Password Not Required' Enabled Should not typically be enabled for user accounts because it
weakens security for the account.
'Encrypted Text Password Allowed' Enabled Should not typically be enabled for user accounts because it
weakens security for the account.
'Server Trust Account' Enabled Should never be enabled for user accounts. Applies only to
domain controller (computer) accounts.
'Don't Expire Password' Enabled Should be monitored for critical accounts, or all accounts if
your organization does not allow this flag.
'Smartcard Required' Enabled Should be monitored for critical accounts.
'Password Not Required' Disabled Should be monitored for all accounts where the setting
should be Enabled.
'Encrypted Text Password Allowed' Disabled Should be monitored for all accounts where the setting
should be Enabled.
'Don't Expire Password' Disabled Should be monitored for all accounts where the setting
should be Enabled.
'Smartcard Required' Disabled Should be monitored for all accounts where the setting
should be Enabled.
'Trusted For Delegation' Enabled Means that Kerberos Constraint or Unconstraint delegation
was enabled for the user account. We recommend monitoring
this to discover whether it is an approved action (done by an
'Trusted For Delegation' Disabled Means that Kerberos Constraint or Unconstraint delegation
was disabled for the user account. We recommend
Also, if you have a list of user accounts for which delegation is
critical and should not be disabled, monitor this for those
accounts.
'Trusted To Authenticate For Delegation' Enabled Means that Protocol Transition delegation was enabled for
the user account. We recommend monitoring this to discover
whether it is an approved action (done by an administrator), a
mistake, or a malicious action.
'Trusted To Authenticate For Delegation' Disabled Means that Protocol Transition delegation was disabled for
the user account. We recommend monitoring this to discover
whether it is an approved action (done by an administrator), a
mistake, or a malicious action.
Also, if you have a list of user accounts for which delegation is
critical and should not be disabled, monitor this for those
accounts.
'Not Delegated' Enabled Means that Account is sensitive and cannot be delegated
was checked for the user account. We recommend monitoring
this to discover whether it is an approved action (done by an
'Not Delegated' Disabled Should be monitored for all accounts where the setting
should be Enabled. Means that Account is sensitive and
cannot be delegated was unchecked for the user account.
We recommend monitoring this to discover whether it is an
approved action (done by an administrator), a mistake, or a
malicious action.
'Use DES Key Only' Enabled Should not typically be enabled for user accounts because it
weakens security for the accounts Kerberos authentication.
'Don't Require Preauth' Enabled Should not be enabled for user accounts because it weakens
security for the accounts Kerberos authentication.
'Use DES Key Only' Disabled Should be monitored for all accounts where the setting
should be Enabled.
'Don't Require Preauth' Disabled Should be monitored for all accounts where the setting
should be Enabled.
4740(S): A user account was locked out.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates every time a user account
is locked out.
workstations.

Event XML:
- <System>
<Level>0</Level>
<Task>13824</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetDomainName">WIN81</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that performed the lockout operation. Event Viewer automatically tries
to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the
event.
Account Name [Type = UnicodeString]: the name of the account that performed the lockout operation.
Account Domain [Type = UnicodeString]: domain or computer name. Formats vary, and include the
following:
Account That Was Locked Out:
Security ID [Type = SID]: SID of account that was locked out. Event Viewer automatically tries to resolve
Account Name [Type = UnicodeString]: the name of the account that was locked out.
Caller Computer Name [Type = UnicodeString]: the name of computer account from which logon attempt
was received and after which target account was locked out. For example: WIN81.

For 4740(S): A user account was locked out.
Because this event is typically triggered by the SYSTEM account, we recommend that you report it whenever
Subject\Security ID is not SYSTEM.
If you have high-value domain or local accounts (for example, domain administrator accounts) for which
you need to monitor every lockout, monitor all 4740 events with the Account That Was Locked Out
\Security ID values that correspond to the accounts.
4740 events with the Account That Was Locked Out \Security ID that corresponds to the account.
If the user account Account That Was Locked Out\Security ID should not be used (for authentication
attempts) from the Additional Information\Caller Computer Name, then trigger an alert.
Monitor for all 4740 events where Additional Information\Caller Computer Name is not from your
domain. However, be aware that even if the computer is not in your domain you will get the computer name
instead of an IP address in the 4740 event.
4765(S): SID History was added to an account.
Applies to
Windows 10
Windows Server 2016
This event generates when SID History was added to an account.
See more information about SID History here: https://technet.microsoft.com/en-
us/library/cc779590(v=ws.10).aspx.
There is no example of this event in this document.
Subcategory: Audit User Account Management
Event Schema:
SID History was added to an account.
Subject:
Security ID:%6
Account Name:%7
Account Domain:%8
Logon ID:%9
Target Account:
Security ID:%5
Account Name:%3
Account Domain:%4
Source Account:
Security ID:%2
Account Name:%1
Privileges:%10
SID List:%11

Event Versions: 0.
4766(F): An attempt to add SID History to an account
failed.
Applies to
Windows 10
Windows Server 2016
This event generates when an attempt to add SID History to an account failed.
See more information about SID History here: https://technet.microsoft.com/en-
Event Schema:
An attempt to add SID History to an account failed.
Subject:
Security ID:-
Account Name:%5
Account Domain:%6
Logon ID:%7
Target Account:
Security ID:%4
Account Name:%2
Account Domain:%3
Source Account:
Account Name:%1
Privileges:%8

Event Versions: 0.
4767(S): A user account was unlocked.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates every time a user account
is unlocked.
workstations.

Event XML:
- <System>
<Level>0</Level>
<Task>13824</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>
Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that performed the unlock operation. Event Viewer automatically tries
event.
Account Name [Type = UnicodeString]: the name of the account that performed the unlock operation.
the following:
Target Account:
Security ID [Type = SID]: SID of account that was unlocked. Event Viewer automatically tries to resolve SIDs
Account Name [Type = UnicodeString]: the name of the account that was unlocked.
For 4767(S): A user account was unlocked.
We recommend monitoring all 4767 events for local accounts.

4780(S): The ACL was set on accounts which are
members of administrators groups.
Applies to
Windows 10
Windows Server 2016
Every hour, the domain controller that holds the primary domain controller (PDC) Flexible Single Master Operation
(FSMO) role compares the ACL on all security principal accounts (users, groups, and machine accounts) present for
its domain in Active Directory and that are in administrative or security-sensitive groups and which have
AdminCount attribute = 1 against the ACL on the AdminSDHolder object. If the ACL on the principal account differs
from the ACL on the AdminSDHolder object, then the ACL on the principal account is reset to match the ACL on the
AdminSDHolder object and this event is generated.
For some reason, this event doesnt generate on some OS versions.
Event Schema:
The ACL was set on accounts which are members of administrators groups.
Subject:
Security ID:%4
Account Name:%5
Account Domain:%6
Logon ID:%7
Target Account:
Security ID:%3
Account Name:%1
Account Domain:%2
Privileges:%8

Event Versions: 0.

Monitor for this event and investigate why the objects ACL was changed.
4781(S): The name of an account was changed.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates every time a user or
computer account name (sAMAccountName
attribute) is changed.
workstations.

Event XML:
- <System>
<Level>0</Level>
<Task>13824</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="OldTargetUserName">Admin</Data>
<Data Name="NewTargetUserName">MainAdmin</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that performed the change account name operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that performed the change account
name operation.
the following:
Target Account:
Security ID [Type = SID]: SID of account on which the name was changed. Event Viewer automatically tries
to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in
the event.
Old Account Name [Type = UnicodeString]: old name of target account.
New Account Name [Type = UnicodeString]: new name of target account.

For 4781(S): The name of an account was changed.
If you have high-value user or computer accounts (or local user accounts) for which you need to monitor each
change to the accounts, monitor this event with the Target Account\Security ID that corresponds to the
high-value accounts.
4794(S, F): An attempt was made to set the Directory
Services Restore Mode administrator password.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time Directory
Services Restore Mode (DSRM) administrator
password is changed.
controllers.

Event XML:
- <System>
<Level>0</Level>
<Task>13824</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="Workstation">DC01</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made an attempt to set Directory Services Restore Mode
administrator password. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID
cannot be resolved, you will see the source data in the event.
Account Name [Type = UnicodeString]: the name of the account that made an attempt to set Directory
Services Restore Mode administrator password.
the following:
Caller Workstation [Type = UnicodeString]: the name of computer account from which Directory Services
Restore Mode (DSRM) administrator password change request was received. For example: DC01. If the
change request was sent locally (from the same server) this field will have the same name as the computer
account.
Status Code [Type = HexInt32]: for Success events it has 0x0 value.

For 4794(S, F): An attempt was made to set the Directory Services Restore Mode administrator password.
Always monitor 4794 events and trigger alerts when they occur.
4798(S): A user's local group membership was
enumerated.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates when a process enumerates
a user's security-enabled local groups on a
computer or device.

Event XML:
- <System>
<Level>0</Level>
<Task>13824</Task>
<Opcode>0</Opcode>
<Correlation ActivityID="{CBAEDE08-1CF0-0000-50DE-AECBF01CD101}" />
<Computer>WIN10-1.contoso.local</Computer>
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">Administrator</Data>
<Data Name="TargetDomainName">WIN10-1</Data>
<Data Name="SubjectLogonId">0x72d9d</Data>
<Data Name="CallerProcessId">0xc80</Data>
<Data Name="CallerProcessName">C:\\Windows\\System32\\mmc.exe</Data>
</EventData>
</Event>
Required Server Roles: none.

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the enumerate user's security-enabled local groups
Account Name [Type = UnicodeString]: the name of the account that requested the enumerate user's
security-enabled local groups operation.
the following:
User:
Security ID [Type = SID]: SID of the account whose groups were enumerated. Event Viewer automatically
tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data
in the event.
Account Name [Type = UnicodeString]: the name of the account whose groups were enumerated.
Account Domain [Type = UnicodeString]: groups domain or computer name. Formats vary, and include
the following:
For a local group, this field will contain the name of the computer to which this group belongs, for
example: Win81.
Process ID [Type = Pointer]: hexadecimal Process ID of the process that enumerated the members of the
group. Process ID (PID) is a number used by the operating system to uniquely identify an active process. To
You can also correlate this process ID with a process ID in other events, for example, 4688: A new process has been
created Process Information\New Process ID.

For 4798(S): A user's local group membership was enumerated.
If you have high value domain or local accounts for which you need to monitor each enumeration of their
group membership, or any access attempt, monitor events with the Subject\Security ID that
corresponds to the high value account or accounts.
If you have a pre-defined Process Name for the process reported in this event, monitor all events with
Process Name not equal to your defined value.
You can monitor to see if Process Name is not in a standard folder (for example, not in System32 or
Program Files) or is in a restricted folder (for example, Temporary Internet Files).
If you have a pre-defined list of restricted substrings or words in process names (for example, mimikatz
or cain.exe), check for these substrings in Process Name.
5376(S): Credential Manager credentials were backed
up.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates every time the user
(Subject) successfully backs up the credential
manager database.
Typically this can be done by clicking Back up
Credentials in Credential Manager in the
Control Panel.

Event XML:
- <System>
<Level>0</Level>
<Task>13824</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectLogonId">0x30d7c</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that performed the backup operation. Event Viewer automatically tries
event.
Account Name [Type = UnicodeString]: the name of the account that performed the backup operation.
the following:

For 5376(S): Credential Manager credentials were backed up.
Every 5376 event should be recorded for all local and domain accounts, because this action (back up Credential
Manager) is very rarely used by users and can indicate a virus, or other harmful or malicious activity.
5377(S): Credential Manager credentials were
restored from a backup.
Applies to
Windows 10
Windows Server 2016
Management
Event Description:
This event generates every time the user
(Subject) successfully restores the credential
manager database.
Typically this can be done by clicking Restore
Credentials in Credential Manager in the
Control Panel.

Event XML:
- <System>
<Level>0</Level>
<Task>13824</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that performed the restore operation. Event Viewer automatically tries
event.
Account Name [Type = UnicodeString]: the name of the account that performed the restore operation.
the following:

For 5377(S): Credential Manager credentials were restored from a backup.
Every 5377 event should be recorded for all local and domain accounts, because this action (restore Credential
Manager credentials from a backup) is very rarely used by users, and can indicate a virus, or other harmful or
malicious activity.
Audit DPAPI Activity
Applies to
Windows 10
Windows Server 2016
Audit DPAPI Activity determines whether the operating system generates audit events when encryption or
decryption calls are made into the data protection application interface (DPAPI).
Event volume: Low.
STRONGER STRONGER
Domain IF IF IF IF IF Events in this

Controller subcategory
typically have an
informational
purpose and it is
difficult to detect
any malicious
activity using
these events. Its
mainly used for
DPAPI
troubleshooting.
Member Server IF IF IF IF IF Events in this

subcategory
typically have an
informational
purpose and it is
difficult to detect
any malicious
activity using
these events. Its
mainly used for
DPAPI
troubleshooting.
Workstation IF IF IF IF IF Events in this

subcategory
typically have an
informational
purpose and it is
difficult to detect
any malicious
activity using
these events. Its
mainly used for
DPAPI
troubleshooting.
Events List:
4692(S, F): Backup of data protection master key was attempted.
4693(S, F): Recovery of data protection master key was attempted.
4694(S, F): Protection of auditable protected data was attempted.
4695(S, F): Unprotection of auditable protected data was attempted.
4692(S, F): Backup of data protection master key was
attempted.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit DPAPI Activity
Event Description:
This event generates every time that a backup
is attempted for the DPAPI Master Key.
When a computer is a member of a domain,
DPAPI has a backup mechanism to allow
unprotection of the data. When a Master Key is
generated, DPAPI communicates with a domain
controller. Domain controllers have a domain-
wide public/private key pair, associated solely
with DPAPI. The local DPAPI client gets the
domain controller public key from a domain
controller by using a mutually authenticated
and privacy protected RPC call. The client
encrypts the Master Key with the domain
controller public key. It then stores this backup Master Key along with the Master Key protected by the user's
password.
Periodically, a domain-joined machine will try to send an RPC request to a domain controller to back up the users
master key so that the user can recover secrets in case his or her password has to be reset. Although the user's keys
are stored in the user profile, a domain controller must be contacted to encrypt the master key with a domain
recovery key.
This event also generates every time a new DPAPI Master Key is generated, for example.
This event generates on domain controllers, member servers, and workstations.
Failure event generates when a Master Key backup operation fails for some reason.
Event XML:
- <System>
<Level>0</Level>
<Task>13314</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectUserName">ladmin</Data>
<Data Name="SubjectLogonId">0x30c08</Data>
<Data Name="MasterKeyId">16cfaea0-dbe3-4d92-9523-d494edb546bc</Data>
<Data Name="RecoveryServer" />
<Data Name="RecoveryKeyId">806a0350-aeb1-4c56-91f9-ef16cf759291</Data>
<Data Name="FailureReason">0x0</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested backup operation. Event Viewer automatically tries to
resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
Account Name [Type = UnicodeString]: the name of the account that requested backup operation.
the following:
Key Information:
Key Identifier [Type = UnicodeString]: unique identifier of a master key which backup was created. The
Master Key is used, with some additional data, to generate an actual symmetric session key to
encrypt\decrypt the data using DPAPI. All of user's Master Keys are located in user profile ->
%APPDATA%\Roaming\Microsoft\Windows\Protect\%SID% folder. The name of every Master Key file is its
ID.
Recovery Server [Type = UnicodeString]: the name (typically DNS name) of the computer that you
contacted to back up your Master Key. For domain joined machines, its typically a name of a domain
controller. This parameter might not be captured in the event, and in that case will be empty.
Recovery Key ID [Type = UnicodeString]: unique identifier of a recovery key. The recovery key is generated
when a user chooses to create a Password Reset Disk (PRD) from the user's Control Panel or when first
Master Key is generated. First, DPAPI generates a RSA public/private key pair, which is the recovery key. In
this field you will see unique Recovery key ID which was used for Master key backup operation.
For Failure events this field is typically empty.
Status Information:
Status Code [Type = HexInt32]: hexadecimal unique status code of performed operation. For Success events
this field is typically 0x0. To see the meaning of status code you need to convert it to decimal value and us
net helpmsg STATUS_CODE command to see the description for specific STATUS_CODE. Here is an example
of net helpmsg command output for status code 0x3A:
[Net helpmsg 58 illustration](..images/net-helpmsg-58.png)

For 4692(S, F): Backup of data protection master key was attempted.
This event is typically an informational event and it is difficult to detect any malicious activity using this event.
Its mainly used for DPAPI troubleshooting.
4693(S, F): Recovery of data protection master key
was attempted.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time that recovery
is attempted for a DPAPI Master Key.
While unprotecting data, if DPAPI cannot use
the Master Key protected by the user's
password, it sends the backup Master Key to a
domain controller by using a mutually
authenticated and privacy protected RPC call.
The domain controller then decrypts the
Master Key with its private key and sends it
back to the client by using the same protected
RPC call. This protected RPC call is used to
ensure that no one listening on the network
can get the Master Key.
Failure event generates when a Master Key restore operation fails for some reason.
Event XML:
- <System>
<Level>0</Level>
<Task>13314</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="MasterKeyId">0445c766-75f0-4de7-82ad-d9d97aad59f6</Data>
<Data Name="RecoveryReason">0x5c005c</Data>
<Data Name="RecoveryServer">DC01.contoso.local</Data>
<Data Name="RecoveryKeyId" />
<Data Name="FailureId">0x380000</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the recover operation. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: the name of the account that requested the recover operation.
the following:
Key Information:
Key Identifier [Type = UnicodeString]: unique identifier of a master key which was recovered. The Master
Key is used, with some additional data, to generate an actual symmetric session key to encrypt\decrypt the
data using DPAPI. All of user's Master Keys are located in user profile ->
%APPDATA%\Roaming\Microsoft\Windows\Protect\%SID% folder. The name of every Master Key file is its
ID.
Recovery Server [Type = UnicodeString]: the name (typically DNS name) of the computer that you
contacted to recover your Master Key. For domain joined machines, its typically a name of a domain
controller.
Note In this event Recovery Server field contains information from Recovery Reason field.
Recovery Key ID [Type = UnicodeString]: unique identifier of a recovery key. The recovery key is generated
when a user chooses to create a Password Reset Disk (PRD) from the user's Control Panel or when first
Master Key is generated. First, DPAPI generates a RSA public/private key pair, which is the recovery key. In
this field you will see unique Recovery key ID which was used for Master key recovery operation. This
parameter might not be captured in the event, and in that case will be empty.
Recovery Reason [Type = HexInt32]: hexadecimal code of recovery reason.
Note In this event Recovery Reason field contains information from Recovery Server field.
Status Information:
Status Code [Type = HexInt32]: hexadecimal unique status code. For Success events this field is typically
0x380000.

For 4693(S, F): Recovery of data protection master key was attempted.
This event is typically an informational event and it is difficult to detect any malicious activity using this
event. Its mainly used for DPAPI troubleshooting.
For domain joined computers, Recovery Reason should typically be a domain controller DNS name.
4694(S, F): Protection of auditable protected data was
attempted.
Applies to
Windows 10
Windows Server 2016
This event generates if DPAPI CryptProtectData() function was used with CRYPTPROTECT_AUDIT flag (dwFlags)
enabled.
Event Schema:
Protection of auditable protected data was attempted.
Subject:
Security ID:%1
Account Name:%2
Account Domain:%3
Logon ID:%4
Protected Data:
Data Description:%6
Key Identifier:%5
Protected Data Flags:%7
Protection Algorithms:%8
Status Information:
Status Code:%9

Event Versions: 0.

4695(S, F): Unprotection of auditable protected data
was attempted.
Applies to
Windows 10
Windows Server 2016
This event generates if DPAPI CryptUnprotectData() function was used to unprotect auditable data that was
encrypted using CryptProtectData() function with CRYPTPROTECT_AUDIT flag (dwFlags) enabled.
Event Schema:
Unprotection of auditable protected data was attempted.
Subject:
Security ID:%1
Account Name:%2
Account Domain:%3
Logon ID:%4
Protected Data:
Data Description:%6
Key Identifier:%5
Protected Data Flags:%7
Protection Algorithms:%8
Status Information:
Status Code:%9

Event Versions: 0.

Audit PNP Activity
Applies to
Windows 10
Windows Server 2016
Audit PNP Activity determines when Plug and Play detects an external device.
A PnP audit event can be used to track down changes in system hardware and will be logged on the machine
where the change took place. For example, when a keyboard is plugged into a computer, a PnP event is triggered.
Event volume: Varies, depending on how the computer is used. Typically Low.
STRONGER STRONGER
Domain Yes No Yes No This subcategory

Controller will help identify
when and which
Plug and Play
device was
attached,
enabled, disabled
or restricted by
device installation
policy.
You can track, for
example, whether
a USB flash drive
or stick was
attached to a
domain
controller, which
is typically not
allowed.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Member Server Yes No Yes No This subcategory

will help identify
when and which
Plug and Play
device was
attached,
enabled, disabled
or restricted by
device installation
policy.
You can track, for
example, whether
a USB flash drive
or stick was
attached to a
critical server,
which is typically
not allowed.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Workstation Yes No Yes No This subcategory

will help identify
when and which
Plug and Play
device was
attached,
enabled, disabled
or restricted by
device installation
policy.
You can track, for
example, whether
a USB flash drive
or stick was
attached to an
administrative
workstation or
VIP workstation.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Events List:
6416(S): A new external device was recognized by the System
6419(S): A request was made to disable a device
6420(S): A device was disabled.
6421(S): A request was made to enable a device.
6422(S): A device was enabled.
6423(S): The installation of this device is forbidden by system policy.
6424(S): The installation of this device was allowed, after having previously been forbidden by policy.
6416(S): A new external device was recognized by the
System.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit PNP Activity
Event Description:
This event generates every time a new external
device is recognized by a system.
This event generates, for example, when a new
external device is connected or enabled.

Event XML:
- <System>
<Level>0</Level>
<Task>13316</Task>
<Opcode>0</Opcode>
<Correlation />
<Computer>DESKTOP-NFC0HVN</Computer>
<Security />
</System>
- <EventData>
<Data Name="SubjectUserName">DESKTOP-NFC0HVN$</Data>
<Data Name="SubjectDomainName">WORKGROUP</Data>
<Data Name="DeviceId">SCSI\\Disk&Ven\_Seagate&Prod\_Expansion\\000000</Data>
<Data Name="DeviceDescription">Seagate Expansion SCSI Disk Device</Data>
<Data Name="ClassId">{4D36E967-E325-11CE-BFC1-08002BE10318}</Data>
<Data Name="ClassName">DiskDrive</Data>
<Data Name="VendorIds">SCSI\\DiskSeagate\_Expansion\_\_\_\_\_\_\_0636
SCSI\\DiskSeagate\_Expansion\_\_\_\_\_\_\_ SCSI\\DiskSeagate\_ SCSI\\Seagate\_Expansion\_\_\_\_\_\_\_0
Seagate\_Expansion\_\_\_\_\_\_\_0 GenDisk</Data>
<Data Name="CompatibleIds">SCSI\\Disk SCSI\\RAW</Data>
<Data Name="LocationInformation">Bus Number 0, Target Id 0, LUN 0</Data>
</EventData>
</Event>

Event Versions:
0 - Windows 10.
1 - Windows 10 [Version 1511].
Added Device ID field.
Added Device Name field.
Added Class Name field.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that registered the new device. Event Viewer automatically tries to
Account Name [Type = UnicodeString]: the name of the account that registered the new device.
the following:
Device ID [Type = UnicodeString] [Version 1]: Device instance path attribute of device. To see device
properties, start Device Manager, open specific device properties, and click Details:
Device Name [Type = UnicodeString] [Version 1]: Device description attribute of device. To see device
Class ID [Type = UnicodeString]: Class Guid attribute of device. To see device properties, start Device Manager,
open specific device properties, and click Details:
Class Name [Type = UnicodeString] [Version 1]: Class attribute of device. To see device properties, start Device
Manager, open specific device properties, and click Details:
Vendor IDs [Type = UnicodeString]: Hardware Ids attribute of device. To see device properties, start Device
Compatible IDs [Type = UnicodeString]: Compatible Ids attribute of device. To see device properties, start
Device Manager, open specific device properties, and click Details:
Location Information [Type = UnicodeString]: Location information attribute of device. To see device

For 6416(S): A new external device was recognized by the System.
You can use this event to track the events and event information shown in the following table by using the
listed fields:
EVENT AND EVENT INFORMATION TO MONITOR FIELD TO USE
Device recognition events, Device Instance Path Device ID
Device recognition events, Device Description Device Name
Device recognition events, Class GUID Class ID
Device recognition events, Hardware IDs Vendor IDs

Device recognition events, Compatible IDs Compatible IDs
Device recognition events, Location information Location Information

6419(S): A request was made to disable a device.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time
when someone made a request to
disable a device.
This event doesnt mean that device
was disabled.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>13316</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectDomainName">DESKTOP-NFC0HVN</Data>
<Data Name="SubjectLogonId">0x3fcc7</Data>
<Data Name="DeviceId">USB\\VID\_138A&PID\_0017\\FFBC12C950A0</Data>
<Data Name="DeviceDescription">Synaptics FP Sensors (WBF) (PID=0017)</Data>
<Data Name="ClassId">{53D29EF7-377C-4D14-864B-EB3A85769359}</Data>
<Data Name="ClassName">Biometric</Data>
<Data Name="HardwareIds">USB\\VID\_138A&PID\_0017&REV\_0078 USB\\VID\_138A&PID\_0017</Data>
<Data Name="CompatibleIds">USB\\Class\_FF&SubClass\_00&Prot\_00 USB\\Class\_FF&SubClass\_00
USB\\Class\_FF</Data>
<Data Name="LocationInformation">Port\_\#0002.Hub\_\#0004</Data>
</EventData>
</Event>

Minimum OS Version: Windows 10 [Version 1511].
Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made the request. Event Viewer automatically tries to resolve SIDs
Account Name [Type = UnicodeString]: the name of the account that made the request.
the following:
Device ID [Type = UnicodeString]: Device instance path attribute of device. To see device properties, start
Device Name [Type = UnicodeString]: Device description attribute of device. To see device properties, start
Class Name [Type = UnicodeString]: Class attribute of device. To see device properties, start Device Manager,
Hardware IDs [Type = UnicodeString]: Hardware Ids attribute of device. To see device properties, start Device

For 6419(S): A request was made to disable a device.
You can use this event to track the events and event information shown in the following table by using the listed
fields:
Device disable requests, Device Instance Path Device ID
Device disable requests, Device Description Device Name
Device disable requests, Class GUID Class ID
Device disable requests, Hardware IDs Hardware IDs
Device disable requests, Compatible IDs Compatible IDs
Device disable requests, Location information Location Information

6420(S): A device was disabled.
Applies to
Windows 10
Windows Server 2016
Event Description:
specific device was disabled.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>13316</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="DeviceId">USB\\VID\_138A&PID\_0017\\ffbc12c950a0</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that disabled the device. Event Viewer automatically tries to resolve
Account Name [Type = UnicodeString]: the name of the account that disabled the device.
the following:

For 6420(S): A device was disabled.
fields:
Device disable events, Device Instance Path Device ID
Device disable events, Device Description Device Name
Device disable events, Class GUID Class ID
Device disable events, Hardware IDs Hardware IDs
Device disable events, Compatible IDs Compatible IDs
Device disable events, Location information Location Information

6421(S): A request was made to enable a device.
Applies to
Windows 10
Windows Server 2016
Event Description:
when someone made a request to
enable a device.
This event doesnt mean that device
was enabled.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>13316</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectDomainName">DESKTOP-NFC0HVN</Data>
<Data Name="SubjectLogonId">0x3fcc7</Data>
<Data Name="DeviceId">USB\\VID\_138A&PID\_0017\\FFBC12C950A0</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made the request. Event Viewer automatically tries to resolve SIDs
Account Name [Type = UnicodeString]: the name of the account that made the request.
the following:

For 6421(S): A request was made to enable a device.
fields:
Device enable requests, Device Instance Path Device ID
Device enable requests, Device Description Device Name
Device enable requests, Class GUID Class ID
Device enable requests, Hardware IDs Hardware IDs
Device enable requests, Compatible IDs Compatible IDs
Device enable requests, Location information Location Information

6422(S): A device was enabled.
Applies to
Windows 10
Windows Server 2016
Event Description:
specific device was enabled.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>13316</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="DeviceId">USB\\VID\_138A&PID\_0017\\ffbc12c950a0</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that enabled the device. Event Viewer automatically tries to resolve
Account Name [Type = UnicodeString]: the name of the account that enabled the device.
the following:

For 6422(S): A device was enabled.
You can use this event to track the events and event information shown in the following table by using the
listed fields:
Device enable events, Device Instance Path Device ID
Device enable events, Device Description Device Name
Device enable events, Class GUID Class ID
Device enable events, Hardware IDs Hardware IDs

Device enable events, Compatible IDs Compatible IDs
Device enable events, Location information Location Information

6423(S): The installation of this device is forbidden by
system policy.
Applies to
Windows 10
Windows Server 2016
Event Description:
installation of this device is
forbidden by system policy.
Device installation restriction group
policies are located here:
\Computer
Configuration\Administrative
Templates\System\Device
Installation\Device Installation
Restrictions. If one of the policies
restricts installation of a specific
device, this event will be generated.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>13316</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="DeviceId">USB\\VID\_04F3&PID\_012D\\7&1E3A8971&0&2</Data>
<Data Name="DeviceDescription">Touchscreen</Data>
<Data Name="ClassId">{00000000-0000-0000-0000-000000000000}</Data>
<Data Name="ClassName" />
<Data Name="HardwareIds">USB\\VID\_04F3&PID\_012D&REV\_0013 USB\\VID\_04F3&PID\_012D</Data>
<Data Name="CompatibleIds">USB\\Class\_03&SubClass\_00&Prot\_00 USB\\Class\_03&SubClass\_00
USB\\Class\_03</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that forbids the device installation. Event Viewer automatically tries to
Account Name [Type = UnicodeString]: the name of the account that forbids the device installation.
the following:

For 6423(S): The installation of this device is forbidden by system policy.
If you want to track device installation policy violations then you need to track every event of this type.
You can use this event to track the policy violations and related information shown in the following table by
using the listed fields:
POLICY VIOLATION AND RELATED INFORMATION TO MONITOR FIELD TO USE
Device installation policy violations, Device Instance Path Device ID
Device installation policy violations, Device Description Device Name
Device installation policy violations, Class GUID Class ID
Device installation policy violations, Hardware IDs Hardware IDs

POLICY VIOLATION AND RELATED INFORMATION TO MONITOR FIELD TO USE
Device installation policy violations, Compatible IDs Compatible IDs
Device installation policy violations, Location information Location Information

6424(S): The installation of this device was allowed,
after having previously been forbidden by policy.
Applies to
Windows 10
Windows Server 2016
This event occurs rarely, and in some situations may be difficult to reproduce.
Event Versions: 0.

Audit Process Creation
Applies to
Windows 10
Windows Server 2016
Audit Process Creation determines whether the operating system generates audit events when a process is created
(starts).
These audit events can help you track user activity and understand how a computer is being used. Information
includes the name of the program or the user that created the process.
Event volume: Low to Medium, depending on system usage.
This subcategory allows you to audit events generated when a process is created or starts. The name of the
application and user that created the process is also audited.
STRONGER STRONGER
STRONGER STRONGER
Domain Yes No Yes No It is typically

Controller useful to collect
Success auditing
information for
this subcategory
for forensic
investigations, to
find information
who, when and
with which
options\paramet
ers ran specific
process.
Additionally, you
can analyse
process creation
events for
elevated
credentials use,
potential
malicious process
names and so on.
The event
volume is
typically
medium-high
level, depending
on the process
activity on the
computer.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Member Server Yes No Yes No It is typically

useful to collect
Success auditing
information for
this subcategory
for forensic
investigations, to
find information
who, when and
with which
options\paramet
ers ran specific
process.
Additionally, you
can analyse
process creation
events for
elevated
credentials use,
potential
malicious process
names and so on.
The event
volume is
typically
medium-high
level, depending
on the process
activity on the
computer.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Workstation Yes No Yes No It is typically

useful to collect
Success auditing
information for
this subcategory
for forensic
investigations, to
find information
who, when and
with which
options\paramet
ers ran specific
process.
Additionally, you
can analyse
process creation
events for
elevated
credentials use,
potential
malicious process
names and so on.
The event
volume is
typically
medium-high
level, depending
on the process
activity on the
computer.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Events List:
4688(S): A new process has been created.
4696(S): A primary token was assigned to process.
4688(S): A new process has been created.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Process Creation
Event Description:
process starts.

event.
Event XML:
- <System>
<Level>0</Level>
<Task>13312</Task>
<Opcode>0</Opcode>
<Correlation />
<Computer>WIN-GG82ULGC9GO.contoso.local</Computer>
<Security />
</System>
- <EventData>
<Data Name="SubjectUserName">WIN-GG82ULGC9GO$</Data>
<Data Name="NewProcessId">0x2bc</Data>
<Data Name="NewProcessName">C:\\Windows\\System32\\rundll32.exe</Data>
<Data Name="TokenElevationType">%%1938</Data>
<Data Name="ProcessId">0xe74</Data>
<Data Name="CommandLine" />
<Data Name="TargetUserSid">S-1-5-21-1377283216-344919071-3415362939-1104</Data>
<Data Name="TargetLogonId">0x4a5af0</Data>
<Data Name="ParentProcessName">C:\\Windows\\explorer.exe</Data>
<Data Name="MandatoryLabel">S-1-16-8192</Data>
</EventData>
</Event>

Event Versions:
0 - Windows Server 2008, Windows Vista.
1 - Windows Server 2012 R2, Windows 8.1.
Added Process Command Line field.
2 - Windows 10.
Subject renamed to Creator Subject.
Added Target Subject section.
Added Mandatory Label field.
Added Creator Process Name field.
Field Descriptions:
Creator Subject [Value for versions 0 and 1 Subject]:
Security ID [Type = SID]: SID of account that requested the create process operation. Event Viewer
automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will
Note A security identifier (SID) is a unique value of variable length used to identify a trustee
(security principal). Each account has a unique SID that is issued by an authority, such as an Active
Directory domain controller, and stored in a security database. Each time a user logs on, the system
retrieves the SID for that user from the database and places it in the access token for that user. The
system uses the SID in the access token to identify the user in all subsequent interactions with Windows
security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used
again to identify another user or group. For more information about SIDs, see Security identifiers.
Account Name [Type = UnicodeString]: the name of the account that requested the create process
operation.
Account Domain [Type = UnicodeString]: subjects domain or computer name. Formats vary, and
For some well-known security principals, such as LOCAL SERVICE or ANONYMOUS LOGON,
the value of this field is NT AUTHORITY.
For local user accounts, this field will contain the name of the computer or device that this
account belongs to, for example: Win81.
Logon ID [Type = HexInt64]: hexadecimal value that can help you correlate this event with recent
events that might contain the same Logon ID, for example, 4624: An account was successfully
logged on.
Target Subject [Version 2]:
Note This event includes the principal of the process creator, but this is not always sufficient if the
target context is different from the creator context. In that situation, the subject specified in the process
termination event does not match the subject in the process creation event even though both events
refer to the same process ID. Therefore, in addition to including the creator of the process, we will also
include the target principal when the creator and target do not share the same logon.
Security ID [Type = SID] [Version 2]: SID of target account. Event Viewer automatically tries to resolve
Note A security identifier (SID) is a unique value of variable length used to identify a trustee
(security principal). Each account has a unique SID that is issued by an authority, such as an Active
Directory domain controller, and stored in a security database. Each time a user logs on, the system
retrieves the SID for that user from the database and places it in the access token for that user. The
system uses the SID in the access token to identify the user in all subsequent interactions with Windows
security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used
again to identify another user or group. For more information about SIDs, see Security identifiers.
Account Name [Type = UnicodeString] [Version 2]: the name of the target account.
Account Domain [Type = UnicodeString] [Version 2]: target accounts domain or computer name.
Logon ID [Type = HexInt64] [Version 2]: hexadecimal value that can help you correlate this event
with recent events that might contain the same Logon ID, for example, 4624: An account was
successfully logged on.
New Process ID [Type = Pointer]: hexadecimal Process ID of the new process. Process ID (PID) is a
number used by the operating system to uniquely identify an active process. To see the PID for a
specific process you can, for example, use Task Manager (Details tab, PID column):
New Process Name [Type = UnicodeString]: full path and the name of the executable for the new
process.
Token Elevation Type [Type = UnicodeString]**: **
TokenElevationTypeDefault (1): Type 1 is a full token with no privileges removed or
groups disabled. A full token is only used if User Account Control is disabled or if the user is
the built-in Administrator account (for which UAC disabled by default), service account or local
system account.
TokenElevationTypeFull (2): Type 2 is an elevated token with no privileges removed or
groups disabled. An elevated token is used when User Account Control is enabled and the
user chooses to start the program using Run as administrator. An elevated token is also used
when an application is configured to always require administrative privilege or to always
require maximum privilege, and the user is a member of the Administrators group.
TokenElevationTypeLimited (3): Type 3 is a limited token with administrative privileges
removed and administrative groups disabled. The limited token is used when User Account
Control is enabled, the application does not require administrative privilege, and the user does
not choose to start the program using Run as administrator.
Mandatory Label [Version 2] [Type = SID]: SID of integrity label which was assigned to the new
process. Can have one of the following values:
SID RID RID LABEL MEANING
S-1-16-0 0x00000000 SECURITY_MANDATORY_ Untrusted.

UNTRUSTED_RID
S-1-16-4096 0x00001000 SECURITY_MANDATORY_L Low integrity.

OW_RID
S-1-16-8192 0x00002000 SECURITY_MANDATORY_ Medium integrity.

MEDIUM_RID
S-1-16-8448 0x00002100 SECURITY_MANDATORY_ Medium high integrity.

MEDIUM_PLUS_RID
S-1-16-12288 0X00003000 SECURITY_MANDATORY_ High integrity.

HIGH_RID
S-1-16-16384 0x00004000 SECURITY_MANDATORY_S System integrity.

YSTEM_RID
S-1-16-20480 0x00005000 SECURITY_MANDATORY_P Protected process.

ROTECTED_PROCESS_RID
Creator Process ID [Type = Pointer]: hexadecimal Process ID of the process which ran the new process.
You can also correlate this process ID with a process ID in other events, for example, 4688: A new
process has been created Process Information\New Process ID.
Creator Process Name [Version 2] [Type = UnicodeString]: full path and the name of the executable
for the process.
Process Command Line [Version 1, 2] [Type = UnicodeString]: contains the name of executable and
arguments which were passed to it. You must enable Administrative Templates\System\Audit
Process Creation\Include command line in process creation events group policy to include
command line in process creation events:
By default Process Command Line field is empty.

For 4688(S): A new process has been created.
High-value accounts: You might have high-value Monitor all events with the Creator Subject\Security
domain or local accounts for which you need to monitor ID or Target Subject\Security ID that corresponds to
each action. the high-value account or accounts.
administrators, built-in local administrator account,
domain administrators, service accounts, domain
controller accounts and so on.
Anomalies or malicious actions: You might have When you monitor for anomalies or malicious actions, use
specific requirements for detecting anomalies or the Creator Subject\Security ID or Target
monitoring potential malicious actions. For example, you Subject\Security ID (with other information) to monitor
might need to monitor for use of an account outside of how or when a particular account is being used.
working hours.
Non-active accounts: You might have non-active, Monitor all events with the Creator Subject\Security
disabled, or guest accounts, or other accounts that should ID or Target Subject\Security ID that corresponds to
never be used. the accounts that should never be used.
Account whitelist: You might have a specific whitelist of If this event corresponds to a whitelist-only action,
accounts that are the only ones allowed to perform review the Creator Subject\Security ID and Target
actions corresponding to particular events. Subject\Security ID for accounts that are outside the
whitelist.
Accounts of different types: You might want to ensure If this event corresponds to an action you want to
that certain actions are performed only by certain account monitor for certain account types, review the Creator
types, for example, local or domain account, machine or Subject\Security ID or Target Subject\Security ID
user account, vendor or employee account, and so on. to see whether the account type is as expected.
External accounts: You might be monitoring accounts Monitor the specific events for the Creator
from another domain, or external accounts that are not Subject\Security ID or Target Subject\Security ID
allowed to perform certain actions (represented by certain corresponding to accounts from another domain or
specific events). external accounts.
certain computers, machines, or devices on which certain actions performed by the Creator Subject\Security ID
people (accounts) should not typically perform any or Target Subject\Security ID that you are concerned
actions. about.
Account naming conventions: Your organization might Monitor Creator Subject\Security ID or Target
have specific naming conventions for account names. Subject\Security ID for names that dont comply with
naming conventions.
If you have a pre-defined New Process Name or Creator Process Name for the process
reported in this event, monitor all events with New Process Name or Creator Process Name
not equal to your defined value.
You can monitor to see if New Process Name or Creator Process Name is not in a standard
folder (for example, not in System32 or Program Files) or is in a restricted folder (for example,
Temporary Internet Files).
If you have a pre-defined list of restricted substrings or words in process names (for example
mimikatz or cain.exe), check for these substrings in New Process Name or Creator
Process Name.
It can be unusual for a process to run using a local account in either Creator Subject\Security ID or
in Target Subject\Security ID.
Monitor for Token Elevation Type with value TokenElevationTypeDefault (1) when
Subject\Security ID lists a real user account, for example when Account Name doesnt contain the
$ symbol. Typically this means that UAC is disabled for this account for some reason.
Monitor for Token Elevation Type with value TokenElevationTypeDefault (2) on standard
workstations, when Subject\Security ID lists a real user account, for example when Account Name
doesnt contain the $ symbol. This means that a user ran a program using administrative privileges.
You can also monitor for Token Elevation Type with value TokenElevationTypeDefault (2) on
standard workstations, when a computer object was used to run the process, but that computer
object is not the same computer where the event occurs.
If you need to monitor all new processes with a specific Mandatory Label, for example S-1-16-20480
(Protected process), check the Mandatory Label in this event.
4696(S): A primary token was assigned to process.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Process Creation
Event Description:
This event generates every time a process runs
using the non-current access token, for example,
UAC elevated token, RUN AS different user
actions, scheduled task with defined user,
services, and so on.
IMPORTANT: this event is deprecated starting
from Windows 7 and Windows 2008 R2.

Event XML:
- <System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
<Level>0</Level>
<Task>13312</Task>
<Opcode>0</Opcode>
<Correlation />
<Computer>Win2008.contoso.local</Computer>
<Security />
</System>
- <EventData>
<Data Name="SubjectUserName">WIN2008$</Data>
<Data Name="TargetUserSid">S-1-5-18</Data>
<Data Name="TargetLogonId">0x1c8c5</Data>
<Data Name="TargetProcessId">0xf40</Data>
<Data Name="TargetProcessName">C:\\Windows\\System32\\WerFault.exe</Data>
<Data Name="ProcessId">0x698</Data>
<Data Name="ProcessName">C:\\Windows\\System32\\svchost.exe</Data>
</EventData>
</Event>
Required Server Roles: this event is deprecated starting from Windows 7 and Windows 2008 R2.
Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the assign token to process operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the assign token to
process operation.
the following:
Process ID [Type = Pointer]: hexadecimal Process ID of the process which started the new process with the
new security token. Process ID (PID) is a number used by the operating system to uniquely identify an active
process. To see the PID for a specific process you can, for example, use Task Manager (Details tab, PID
column):
You can also correlate this process ID with a process ID in other events, for example, 4688: A new process
has been created Process Information\New Process ID.
Process Name [Type = UnicodeString]: full path and the name of the executable for the process which ran
the new process with new security token.
Target Process:
Target Process ID [Type = Pointer]: hexadecimal Process ID of the new process with new security token. If you
convert the hexadecimal value to decimal, you can compare it to the values in Task Manager.
You can also correlate this process ID with a process ID in other events, for example, 4688: A new process has
been created Process Information\New Process ID.
Target Process Name [Type = UnicodeString]: full path and the name of the executable for the new process.
New Token Information:
Security ID [Type = SID]: SID of account through which the security token will be assigned to the new process.
Account Name [Type = UnicodeString]: the name of the account through which the security token will be
assigned to the new process.
the following:

For 4696(S): A primary token was assigned to process.
High-value accounts: You might have high-value domain or Monitor this event with the Subject\Security ID or New
local accounts for which you need to monitor each action. Token Information\Security ID that corresponds to the
Examples of high-value accounts are database administrators, high-value account or accounts.
requirements for detecting anomalies or monitoring potential Subject\Security ID or New Token
malicious actions. For example, you might need to monitor for Information\Security ID (with other information) to
use of an account outside of working hours. monitor how or when a particular account is being used.
Non-active accounts: You might have non-active, disabled, Monitor this event with the Subject\Security ID or New
or guest accounts, or other accounts that should never be Token Information\Security ID that corresponds to the
used. accounts that should never be used.
accounts that are the only ones allowed to perform actions the Subject\Security ID and New Token
corresponding to particular events. Information\Security ID for accounts that are outside the
whitelist.
certain actions are performed only by certain account types, certain account types, review the Subject\Security ID or
for example, local or domain account, machine or user New Token Information\Security ID to see whether the
account, vendor or employee account, and so on. account type is as expected.
External accounts: You might be monitoring accounts from Monitor this event for the Subject\Security ID or New
another domain, or external accounts that are not allowed to Token Information\Security ID corresponding to accounts
perform certain actions (represented by certain specific from another domain or external accounts.
events).
certain computers, machines, or devices on which certain actions performed by the Subject\Security ID or New
people (accounts) should not typically perform any actions. Token Information\Security ID that you are concerned
about.
Account naming conventions: Your organization might have Monitor Subject\Security ID or New Token
specific naming conventions for account names. Information\Security ID for names that dont comply with
naming conventions.
If you have a pre-defined Process Name or Target Process Name for the process reported in this
event, monitor all events with Process Name or Target Process Name not equal to your defined value.
You can monitor to see if Process Name or Target Process Name is not in a standard folder (for
example, not in System32 or Program Files) or is in a restricted folder (for example, Temporary Internet
Files).
or cain.exe), check for these substrings in Process Name or Target Process Name.
It can be uncommon if process runs using local account.
Audit Process Termination
Applies to
Windows 10
Windows Server 2016
Audit Process Termination determines whether the operating system generates audit events when process has
exited.
Success audits record successful attempts and Failure audits record unsuccessful attempts.
This policy setting can help you track user activity and understand how the computer is used.
Event volume: Low to Medium, depending on system usage.
STRONGER STRONGER
Domain No No IF No IF - This
typically is not as
important as
Audit Process
Creation
subcategory.
Using this
subcategory you
can, for example
get information
about for how
long process was
run in correlation
with 4688 event.
If you have a list
of critical
processes that
run on some
computers, you
can enable this
subcategory to
monitor for
termination of
these critical
processes.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Member Server No No IF No IF - This

subcategory
typically is not as
important as
Audit Process
Creation
subcategory.
Using this
subcategory you
can, for example
get information
about for how
long process was
run in correlation
with 4688 event.
If you have a list
of critical
processes that
run on some
computers, you
can enable this
subcategory to
monitor for
termination of
these critical
processes.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Workstation No No IF No IF - This
subcategory
typically is not as
important as
Audit Process
Creation
subcategory.
Using this
subcategory you
can, for example
get information
about for how
long process was
run in correlation
with 4688 event.
If you have a list
of critical
processes that
run on some
computers, you
can enable this
subcategory to
monitor for
termination of
these critical
processes.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Events List:
4689(S): A process has exited.
4689(S): A process has exited.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Process Termination
Event Description:
This event generates every time a process has
exited.

Event XML:
- <System>
<Level>0</Level>
<Task>13313</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ProcessId">0xfb0</Data>
<Data Name="ProcessName">C:\\Windows\\System32\\notepad.exe</Data>
</EventData>
</Event>
Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the terminate process operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the terminate process
operation.
the following:
Process ID [Type = Pointer]: hexadecimal Process ID of the ended/terminated process. Process ID (PID) is a
number used by the operating system to uniquely identify an active process. To see the PID for a specific
process you can, for example, use Task Manager (Details tab, PID column):
You can also correlate this process ID with a process ID in other events, for example, 4688(S): A new
process has been created New Process ID on this computer.
Process Name [Type = UnicodeString]: full path and the executable name of the exited/terminated process.
Exit Status [Type = HexInt32]: hexadecimal exit code of exited/terminated process. This exit code is unique
for every application, check application documentation for more details. The exit code value for a process
reflects the specific convention implemented by the application developer for that process.

For 4689(S): A process has exited.
If you have a critical processes list for the computer, with the requirement that these processes must always
run and not stop, you can monitor Process Name field in 4689 events for these process names.
Audit RPC Events
Applies to
Windows 10
Windows Server 2016
Audit RPC Events determines whether the operating system generates audit events when inbound remote
procedure call (RPC) connections are made.
STRONGER STRONGER
Domain No No No No Events in this

occur rarely.
Member Server No No No No Events in this

subcategory
occur rarely.
Workstation No No No No Events in this

subcategory
occur rarely.
Events List:
5712(S): A Remote Procedure Call (RPC) was attempted.
5712(S): A Remote Procedure Call (RPC) was
attempted.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit RPC Events
Event Schema:
A Remote Procedure Call (RPC) was attempted.
Subject:
SID:%1
Name:%2
Account Domain:%3
LogonId:%4
PID:%5 Name:%6
Remote IP Address:%7
Remote Port:%8
RPC Attributes:
Interface UUID:%9
Protocol Sequence:%10
Authentication Service:%11
Authentication Level:%12

Event Versions: 0.
Audit Detailed Directory Service Replication
Applies to
Windows 10
Windows Server 2016
Audit Detailed Directory Service Replication determines whether the operating system generates audit events that
contain detailed tracking information about data that is replicated between domain controllers.
This audit subcategory can be useful to diagnose replication issues.
Event volume: These events can create a very high volume of event data on domain controllers.
STRONGER STRONGER
Domain No No IF IF IF - Events in this

typically have an
informational
purpose and it is
difficult to detect
any malicious
activity using
these events. Its
mainly used for
Active Directory
replication
troubleshooting.

makes sense only
on domain
controllers.

makes sense only
on domain
controllers.
Events List:
4928(S, F): An Active Directory replica source naming context was established.
4929(S, F): An Active Directory replica source naming context was removed.
4930(S, F): An Active Directory replica source naming context was modified.
4931(S, F): An Active Directory replica destination naming context was modified.
4934(S): Attributes of an Active Directory object were replicated.
4935(F): Replication failure begins.
4936(S): Replication failure ends.
4937(S): A lingering object was removed from a replica.
4928(S, F): An Active Directory replica source naming
context was established.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Detailed Directory Service
Replication
Event Description:
This event generates every time a new Active
Directory replica source naming context is
established.
Failure event generates if an error occurs
(Status Code != 0).

Event XML:
- <System>
<Level>0</Level>
<Task>14083</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="DestinationDRA">CN=NTDS Settings,CN=DC01,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=contoso,DC=local</Data>
<Data Name="SourceDRA">CN=NTDS Settings,CN=WIN2012R2,CN=Servers,CN=Default-First-Site-
<Data Name="SourceAddr">ddec0cff-6ceb-4a59-b13f-1724c38a0970.\_msdcs.contoso.local</Data>
<Data Name="NamingContext">DC=ForestDnsZones,DC=contoso,DC=local</Data>
<Data Name="Options">368</Data>
<Data Name="StatusCode">0</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Destination DRA [Type = UnicodeString]: destination directory replication agent distinguished name.
Note The Directory Replication Agent (DRA) handles replication between domain controllers. The Directory
Replication Agent uses the connection objects in the topology map to find out those partners that are relevant
when replicating changes to directory partitions. The DRA sends a replication request to the partners of a
domain controller when the domain controller needs to update its copy of Active Directory.
Source DRA [Type = UnicodeString]: source directory replication agent distinguished name.
attributes:
CN - commonName
Source Address [Type = UnicodeString]: DNS record of the server from which information or an update
was received.
Naming Context [Type = UnicodeString]: naming context to replicate.
Note The Directory Tree of Active Directory tree is partitioned to allow sections to be distributed (replicated) to
domain controllers in different domains within the forest. Each domain controller stores a copy of a specific
part of the directory tree, called a Naming Context also known as Directory Partition. Naming Context is
replicated as a unit to other domain controllers in the forest that contain a replica of the same sub tree. A
Naming Context is also called a Directory Partition.
Options [Type = UInt32]: decimal value of DRS Options.
Status Code [Type = UInt32]: if there are no issues or errors, the status code will be 0. If an error happened,
you will receive Failure event and Status Code will not be equal to 0. You can check error code meaning
here: https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx

For 4928(S, F): An Active Directory replica source naming context was established.
Monitor for Source Address field, because the source of new replication (new DRA) must be authorized for
this action. If you find any unauthorized DRA you should trigger an event.
This event is typically used for Active Directory replication troubleshooting.
context was removed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Detailed Directory
Service Replication
Event Description:
This event generates every time Active
Directory replica source naming context
was removed.
Failure event generates if an error
occurs (Status Code != 0).

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>14083</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SourceDRA">-</Data>
<Data Name="SourceAddr">2d361dd6-fc22-4d9d-b876-ec582b836458.\_msdcs.contoso.local</Data>
<Data Name="NamingContext">DC=contoso,DC=local</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
attributes:
CN - commonName
Source Address [Type = UnicodeString]: DNS record of the server from which the remove request was
received.
Naming Context [Type = UnicodeString]: naming context which was removed.


For 4929(S, F): An Active Directory replica source naming context was removed.
Monitor for Source Address field, because the source of the request must be authorized for this action. If
you find any unauthorized DRA you should trigger an event.
context was modified.
Applies to
Windows 10
Windows Server 2016
Replication
Event Description:
Directory replica source naming context was
modified.
Failure event generates if an error occurs
(Status Code != 0).
It is not possible to understand what exactly
was modified from this event.

Event XML:
- <System>
<Level>0</Level>
<Task>14083</Task>
<Opcode>0</Opcode>
<Correlation />
<Computer>Win2012r2.corp.contoso.local</Computer>
<Security />
</System>
- <EventData>
<Data Name="DestinationDRA">CN=NTDS Settings,CN=WIN2012R2,CN=Servers,CN=Default-First-Site-
<Data Name="SourceDRA">-</Data>
<Data Name="SourceAddr">edf0bef9-1f73-4df3-8991-f6ec2d4ef3ae</Data>
<Data Name="NamingContext">CN=Schema,CN=Configuration,DC=contoso,DC=local</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Source DRA [Type = UnicodeString]: source directory replication agent distinguished name. Typically equals -
for this event.
attributes:
CN - commonName
Source Address [Type = UnicodeString]: DNS record of computer from which the modification request was
received.
Naming Context [Type = UnicodeString]: naming context which was modified.


For 4930(S, F): An Active Directory replica source naming context was modified.
Monitor for Source Address field, because the source of the request must be authorized for this action. If
you find any unauthorized DRA you should trigger an event.
4931(S, F): An Active Directory replica destination
naming context was modified.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Detailed Directory
Service Replication
Event Description:
Directory replica destination naming
context was modified.
Failure event generates if an error
occurs (Status Code != 0).
It is not possible to understand what
exactly was modified from this event.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>14083</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="DestinationDRA">ddec0cff-6ceb-4a59-b13f-1724c38a0970.\_msdcs.contoso.local</Data>
<Data Name="SourceDRA">CN=NTDS Settings,CN=DC01,CN=Servers,CN=Default-First-Site-
<Data Name="SourceAddr">-</Data>
<Data Name="NamingContext">DC=ForestDnsZones,DC=contoso,DC=local</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
attributes:
CN - commonName
Destination Address [Type = UnicodeString]: DNS record of computer to which the modification request
was sent.
Naming Context [Type = UnicodeString]: naming context which was modified.


For 4931(S, F): An Active Directory replica destination naming context was modified.
4934(S): Attributes of an Active Directory object were
replicated.
Applies to
Windows 10
Windows Server 2016
This event generates when attributes of an Active Directory object were replicated.
Subcategory: Audit Detailed Directory Service Replication
Event Schema:
Attributes of an Active Directory object were replicated.
Session ID:%1
Object:%2
Attribute:%3
Type of change:%4
New Value:%5
USN:%6
Status Code:%7
Event Versions: 0.

4935(F): Replication failure begins.
Applies to
Windows 10
Windows Server 2016
Replication
Event Description:
This event generates when Active Directory
replication failure begins.

Event XML:
- <System>
<Level>0</Level>
<Task>14083</Task>
<Opcode>0</Opcode>
<Correlation />
<Computer>Win2012r2.contoso.local</Computer>
<Security />
</System>
- <EventData>
<Data Name="ReplicationEvent">1</Data>
<Data Name="AuditStatusCode">8419</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Replication Event [Type = UInt32]: there is no detailed information about this field in this document.
Audit Status Code [Type = UInt32]: there is no detailed information about this field in this document.

For 4935(F): Replication failure begins.
4936(S): Replication failure ends.
Applies to
Windows 10
Windows Server 2016
This event generates when Active Directory replication failure ends.
Event Schema:
Replication failure ends.
Replication Event:%1
Audit Status Code:%2
Replication Status Code:%3
Event Versions: 0.

4937(S): A lingering object was removed from a
replica.
Applies to
Windows 10
Windows Server 2016
This event generates when a lingering object was removed from a replica.
Event Schema:
A lingering object was removed from a replica.
Destination DRA:%1
Source DRA:%2
Object:%3
Options:%4
Status Code:%5
Event Versions: 0.

Audit Directory Service Access
Applies to
Windows 10
Windows Server 2016
Audit Directory Service Access determines whether the operating system generates audit events when an Active
Directory Domain Services (AD DS) object is accessed.
Event volume: High on servers running AD DS role services.
This subcategory allows you to audit when an Active Directory Domain Services (AD DS) object is accessed. It also
generates Failure events if access was not granted.
STRONGER STRONGER
STRONGER STRONGER
Domain No Yes No Yes It is better to

Controller track changes to
Active Directory
objects through
the Audit
Directory Service
Changes
subcategory.
However, Audit
Directory Service
Changes doesnt
give you
information
about failed
access attempts,
so we
recommend
Failure auditing
in this
subcategory to
track failed access
attempts to
Active Directory
objects.
For
recommendation
s for using and
analyzing the
collected
information, see
the Security
Monitoring
Recommendatio
ns sections. Also,
develop an Active
Directory
auditing policy
(SACL design for
specific classes,
operation types
which need to be
monitored for
specific
Organizational
Units, and so on)
so you can audit
only the access
attempts that are
made to specific
important
objects.

makes sense only
on domain
controllers.
STRONGER STRONGER

makes sense only
on domain
controllers.
Events List:
4662(S, F): An operation was performed on an object.
4661(S, F): A handle to an object was requested.
4662(S, F): An operation was performed on an
object.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Directory Service
Access
Event Description:
This event generates every time when
an operation was performed on an
Active Directory object.
This event generates only if appropriate
SACL was set for Active Directory object
and performed operation meets this
SACL.
If operation failed then Failure event
will be generated.
You will get one 4662 for each
operation type which was performed.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>14080</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectServer">DS</Data>
<Data Name="ObjectType">%{bf967a86-0de6-11d0-a285-00aa003049e2}</Data>
<Data Name="ObjectName">%{38b3d2e6-9948-4dc1-ae90-1605d5eab9a2}</Data>
<Data Name="OperationType">Object Access</Data>
<Data Name="HandleId">0x0</Data>
<Data Name="AccessList">%%1537</Data>
<Data Name="AccessMask">0x10000</Data>
<Data Name="Properties">%%1537 {bf967a86-0de6-11d0-a285-00aa003049e2}</Data>
<Data Name="AdditionalInfo">-</Data>
<Data Name="AdditionalInfo2" />
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the operation. Event Viewer automatically tries to
resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the
event.
Account Name [Type = UnicodeString]: the name of the account that requested the operation.
the following:
Object:
Object Server [Type = UnicodeString]: has DS value for this event.
Object Type [Type = UnicodeString]: type or class of the object that was accessed. Some of the common
Active Directory object types and classes are:
container for containers.
user for users.
group for groups.
domainDNS for domain object.
groupPolicyContainer for group policy objects.
For all possible values of Object Type open Active Directory Schema snap-in (see how to enable this
snap-in: https://technet.microsoft.com/en-us/library/Cc755885(v=WS.10).aspx) and navigate to
Active Directory Schema\Classes. Or use this document: https://msdn.microsoft.com/en-
us/library/cc221630.aspx
Object Name [Type = UnicodeString]: distinguished name of the object that was accessed.
attributes:
CN - commonName
Handle ID [Type = Pointer]: hexadecimal value of a handle to Object Name. This field can help you correlate
this event with other events that might contain the same Handle ID, for example, 4661: A handle to an object
was requested. This parameter might not be captured in the event, and in that case appears as 0x0.
Operation:
Operation Type [Type = UnicodeString]: the type of operation which was performed on an object. Typically
has Object Access value for this event.
Accesses [Type = UnicodeString]: the type of access used for the operation. See Table 9. Active Directory
Access Codes and Rights. for more information.
Access Mask [Type = HexInt32]: hexadecimal mask for the type of access used for the operation. See Table
9. Active Directory Access Codes and Rights. for more information.
ACCESS MASK ACCESS NAME DESCRIPTION
0x1 Create Child The right to create child objects of the

object.
0x2 Delete Child The right to delete child objects of the

object.
0x4 List Contents The right to list child objects of this

object.
0x8 SELF The right to perform an operation

controlled by a validated write access
right.
0x10 Read Property The right to read properties of the

object.
0x20 Write Property The right to write properties of the

object.
0x40 Delete Tree Delete all children of this object,

regardless of the permissions of the
children. It is indicates that Use Delete
Subtree server control check box was
checked during deletion. This operation
means that all objects within the
subtree, including all delete-protected
objects, will be deleted.
0x80 List Object The right to list a particular object.
0x100 Control Access Access allowed only after extended

rights checks supported by the object
are performed.
The right to perform an operation
controlled by an extended access right.
0x10000 DELETE The right to delete the object.

DELETE also generated when object was
moved.
0x20000 READ_CONTROL The right to read data from the security

descriptor of the object, not including
the data in the SACL.
0x40000 WRITE_DAC The right to modify the discretionary

access-control list (DACL) in the object
security descriptor.
ACCESS MASK ACCESS NAME DESCRIPTION
0x80000 WRITE_OWNER The right to assume ownership of the

object. The user must be an object
trustee. The user cannot transfer the
ownership to other users.
0x100000 SYNCHRONIZE The right to use the object for

synchronization. This enables a thread
to wait until the object is in the signaled
state.
0x1000000 ADS_RIGHT_ACCESS_SYSTEM_SECURIT The right to get or set the SACL in the

Y object security descriptor.
0x80000000 ADS_RIGHT_GENERIC_READ The right to read permissions on this

object, read all the properties on this
object, list this object name when the
parent container is listed, and list the
contents of this object if it is a
container.
0x40000000 ADS_RIGHT_GENERIC_WRITE The right to read permissions on this

object, write all the properties on this
object, and perform all validated writes
to this object.
0x20000000 ADS_RIGHT_GENERIC_EXECUTE The right to read permissions on, and

list the contents of, a container object.
0x10000000 ADS_RIGHT_GENERIC_ALL The right to create or delete child

objects, delete a subtree, read and write
properties, examine child objects and
the object itself, add and remove the
object from the directory, and read or
write with an extended right.
Table 9. Active Directory Access Codes and Rights.
Properties [Type = UnicodeString]: first part is the type of access that was used. Typically has the same
value as Accesses field.
Second part is a tree of GUID values of Active Directory classes or property sets, for which operation was
performed.
To translate this GUID, use the following procedure:

Perform the following LDAP search using LDP.exe tool:
Base DN: CN=Schema,CN=Configuration,DC=XXX,DC=XXX
Filter: (&(objectClass=*)(schemaIDGUID=GUID))
Perform the following operations with the GUID before using it in a search request:
We have this GUID to search for: bf967a86-0de6-11d0-a285-00aa003049e2
Take first 3 sections bf967a86-0de6-11d0.
For each of these 3 sections you need to change (Invert) the order of bytes, like this
867a96bf-e60d-d011
Add the last 2 sections without transformation: 867a96bf-e60d-d011-a285-
00aa003049e2
Delete - : 867a96bfe60dd011a28500aa003049e2
Divide bytes with backslashes: \86\7a\96\bf\e6\0d\d0\11\a2\85\00\aa\00\30\49\e2
Filter example: (&(objectClass=*)
(schemaIDGUID=\86\7a\96\bf\e6\0d\d0\11\a2\85\00\aa\00\30\49\e2))
Scope: Subtree
Attributes: schemaIDGUID
Sometimes GUID refers to pre-defined Active Directory Property Sets, you can find GUID (Rights-GUID field),
property set name and details here: https://msdn.microsoft.com/en-us/library/ms683990(v=vs.85).aspx.
Here is an example of decoding of Properties field:
PROPERTIES TRANSLATION
{bf967a86-0de6-11d0-a285-00aa003049e2} Computer
{91e647de-d96f-4b70-9557-d63ff4f3ccd8} Private-Information property set
{6617e4ac-a2f1-43ab-b60c-11fbd1facf05} ms-PKI-RoamingTimeStamp
{b3f93023-9239-4f7c-b99c-6745d87adbc2} ms-PKI-DPAPIMasterKeys
{b8dfa744-31dc-4ef1-ac7c-84baf7ef9da7} ms-PKI-AccountCredentials
Parameter 1 [Type = UnicodeString]: there is no information about this field in this document.
Parameter 2 [Type = UnicodeString]: there is no information about this field in this document.

For 4662(S, F): An operation was performed on an object.
If you need to monitor operations attempts to specific Active Directory classes, monitor for Object Type
field with specific class name. For example, we recommend that you monitor all operations attempts to
domainDNS class.
If you need to monitor operations attempts to specific Active Directory objects, monitor for Object Name
field with specific object name. For example, we recommend that you monitor all operations attempts to
CN=AdminSDHolder,CN=System,DC=domain,DC=com object.
Some access types are more important to monitor, for example:
Write Property
Control Access
DELETE
WRITE_DAC
WRITE_OWNER
You can decide to monitor these (or one of these) access types for specific Active Directory objects.
To do so, monitor for Accesses field with specific access type.
If you need to monitor operations attempts to specific Active Directory properties, monitor for Properties
field with specific property GUID.
Do not forget that Failure attempts are also very important to audit. Decide where you want to monitor
Failure attempts based on previous recommendations.
Applies to
Windows 10
Windows Server 2016
Subcategories: Audit Directory Service Access
and Audit SAM
Event Description:
This event indicates that a handle was
requested for either an Active Directory object
or a Security Account Manager (SAM) object.
If access was declined, then Failure event is
generated.
This event generates only if Success auditing is
enabled for the Audit Handle Manipulation
subcategory.

Event XML:
- <System>
<Level>0</Level>
<Task>14080</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectServer">Security Account Manager</Data>
<Data Name="ObjectType">SAM\_DOMAIN</Data>
<Data Name="ObjectName">DC=contoso,DC=local</Data>
<Data Name="HandleId">0xdd64d36870</Data>
<Data Name="TransactionId">{00000000-0000-0000-0000-000000000000}</Data>
<Data Name="AccessMask">0x2d</Data>
<Data Name="PrivilegeList"></Data>
<Data Name="Properties">-</Data>
<Data Name="RestrictedSidCount">2949165</Data>
<Data Name="ProcessId">0x9000a000d002d</Data>
<Data Name="ProcessName">{bf967a90-0de6-11d0-a285-00aa003049e2} %%5400 {ccc2dc7d-a6ad-4a7a-8846-c04e3cc53501}
</Data>
</EventData>
</Event>
Required Server Roles: For an Active Directory object, the domain controller role is required. For a SAM object,
there is no required role.
Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested a handle to an object. Event Viewer automatically tries
event.
Account Name [Type = UnicodeString]: the name of the account that requested a handle to an object.
the following:
For some well-known security principals, such as LOCAL SERVICE or ANONYMOUS LOGON, the value
of this field is NT AUTHORITY.
Object:
Object Server [Type = UnicodeString]: has Security Account Manager value for this event.
Object Type [Type = UnicodeString]: the type or class of the object that was accessed. The following list
contains possible values for this field:
SAM_ALIAS - a local group.
SAM_GROUP - a group that is not a local group.
SAM_USER - a user account.
SAM_DOMAIN - a domain. For Active Directory events, this is the typical value.
SAM_SERVER - a computer account.
Object Name [Type = UnicodeString]: the name of an object for which access was requested. Depends on
Object Type. This event can have the following format:
SAM_ALIAS SID of the group.
SAM_GROUP - SID of the group.
SAM_USER - SID of the account.
SAM_DOMAIN distinguished name of the accessed object.
SAM_SERVER - distinguished name of the accessed object.
attributes:
CN - commonName
this event with other events that might contain the same Handle ID, for example, 4662: An operation was
performed on an object. This parameter might not be captured in the event, and in that case appears as 0x0.
Process ID [Type = Pointer]: hexadecimal Process ID of the process that requested the handle. Process ID
(PID) is a number used by the operating system to uniquely identify an active process. To see the PID for a
Access Request Information:
Transaction ID [Type = GUID]: unique GUID of the transaction. This field can help you correlate this event
with other events that might contain the same the Transaction ID, such as 4660(S): An object was deleted.
0000-000000000000}.
Accesses [Type = UnicodeString]: the list of access rights which were requested by Subject\Security ID.
These access rights depend on Object Type. See Table 13. File access codes. for more information about
file access rights. For information about SAM object access right use https://technet.microsoft.com/ or other
informational resources.
Access Mask [Type = HexInt32]: hexadecimal mask for the operation that was requested or performed. See
Table 13. File access codes. for more information about file access rights. For information about SAM object
access right use https://technet.microsoft.com/ or other informational resources.
Privileges Used for Access Check [Type = UnicodeString]: the list of user privileges which were used
during the operation, for example, SeBackupPrivilege. This parameter might not be captured in the event,
and in that case appears as -. See full list of user privileges in the table below:


a process.

operations.
held:
READ_CONTROL
FILE_GENERIC_READ
FILE_TRAVERSE




SeCreateTokenPrivilege Create a token object Allows a process to create a token which

it can then use to get access to any local
resources when the process uses
NtCreateToken() or other token-
creation APIs.

account.
components.

a process.
interface.
to a process.
users.
driver.

memory.
computer account.
controllers.

defragmentation.

monitor the performance of non-system
processes.

network request.

to set any valid user or group SID as the
owner of a file. The following access
held:
WRITE_DAC
WRITE_OWNER
FILE_GENERIC_WRITE
FILE_ADD_FILE
DELETE
an object.

security event log.
synchronization.
of systems that use this type of memory
to store configuration information.

processes.
clock.



a terminal device.
Properties [Type = UnicodeString]: depends on Object Type. This field can be empty or contain the list of
the object properties that were accessed. See more detailed information in 4661: A handle to an object was
requested from Audit SAM subcategory.
Restricted SID Count [Type = UInt32]: Number of restricted SIDs in the token. Applicable to only specific
Object Types.
For 4661(S, F): A handle to an object was requested.
You can get almost the same information from 4662: An operation was performed on an object. There are no
additional recommendations for this event in this document.
Audit Directory Service Changes
Applies to
Windows 10
Windows Server 2016
Audit Directory Service Changes determines whether the operating system generates audit events when changes
are made to objects in Active Directory Domain Services (AD DS).
Auditing of directory service objects can provide information about the old and new properties of the objects that
were changed.
Audit events are generated only for objects with configured system access control lists (SACLs), and only when
they are accessed in a manner that matches their SACL settings. Some objects and properties do not cause audit
events to be generated due to settings on the object class in the schema.
This subcategory only logs events on domain controllers.
Event volume: High on domain controllers.
This subcategory triggers events when an Active Directory object was modified, created, undeleted, moved, or
deleted.
STRONGER STRONGER
STRONGER STRONGER
Domain Yes No Yes No It is important to

Controller track actions
related to high
value or critical
Active Directory
objects, for
example, changes
to
AdminSDHolder
container or
Domain Admins
group objects.
This subcategory
shows you what
actions were
performed. If you
want to track
failed access
attempts for
Active Directory
objects you need
to take a look at
Audit Directory
Service Access
subcategory.
For
recommendation
s for using and
analyzing the
collected
information, see
the Security
Monitoring
Recommendatio
ns sections. Also,
develop an Active
Directory
auditing policy
(SACL design for
specific classes,
operation types
which need to be
monitored for
specific
Organizational
Units, and so on)
so you can audit
only the access
attempts that are
made to specific
important
objects.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER

makes sense only
on domain
controllers.

makes sense only
on domain
controllers.
Events List:
5136(S): A directory service object was modified.
5137(S): A directory service object was created.
5138(S): A directory service object was undeleted.
5139(S): A directory service object was moved.
5141(S): A directory service object was deleted.
5136(S): A directory service object was modified.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Directory Service Changes
Event Description:
This event generates every time an Active
Directory object is modified.
To generate this event, the modified object
must have an appropriate entry in SACL: the
Write action auditing for specific attributes.
For a change operation you will typically see
two 5136 events for one action, with different
Operation\Type fields: Value Deleted and
then Value Added. Value Deleted event
typically contains previous value and Value
Added event contains new value.

Event XML:
- <System>
<Level>0</Level>
<Task>14081</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="OpCorrelationID">{02647639-8626-43CE-AFE6-7AA1AD657739}</Data>
<Data Name="AppCorrelationID">-</Data>
<Data Name="DSName">contoso.local</Data>
<Data Name="DSType">%%14676</Data>
<Data Name="ObjectDN">CN=Sergey,CN=Builtin,DC=contoso,DC=local</Data>
<Data Name="ObjectGUID">{4FE80A66-5F93-4F73-B215-68678058E613}</Data>
<Data Name="ObjectClass">user</Data>
<Data Name="AttributeLDAPDisplayName">userAccountControl</Data>
<Data Name="AttributeSyntaxOID">2.5.5.9</Data>
<Data Name="AttributeValue">512</Data>
<Data Name="OperationType">%%14675</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the modify object operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the modify object
operation.
the following:
Directory Service:
Name [Type = UnicodeString]: the name of the Active Directory domain where the modified object is
located.
Type [Type = UnicodeString]: has Active Directory Domain Services value for this event.
Object:
DN [Type = UnicodeString]: distinguished name of the object that was modified.
attributes:
CN - commonName
GUID [Type = GUID]: each Active Directory object has globally unique identifier (GUID), which is a 128-bit
value that is unique not only in the enterprise but also across the world. GUIDs are assigned to every object
created by Active Directory. Each object's GUID is stored in its Object-GUID (objectGUID) property.
Active Directory uses GUIDs internally to identify objects. For example, the GUID is one of an object's
properties that is published in the global catalog. Searching the global catalog for a User object's GUID will
yield results if the user has an account somewhere in the enterprise. In fact, searching for any object by
Object-GUID might be the most reliable way of finding the object you want to find. The values of other
object properties can change, but the Object-GUID never changes. When an object is assigned a GUID, it
keeps that value for life.
Event Viewer automatically resolves GUID field to real object.
Filter: (&(objectClass=*)(objectGUID=GUID))
We have this GUID to search for: a6b34ab5-551b-4626-b8ee-2b36b3ee6672
Take first 3 sections a6b34ab5-551b-4626.
For each of these 3 sections you need to change (Invert) the order of bytes, like
this b54ab3a6-1b55-2646
Add the last 2 sections without transformation: b54ab3a6-1b55-2646-b8ee-
2b36b3ee6672
Delete - : b54ab3a61b552646b8ee2b36b3ee6672
Divide bytes with backslashes:
\b5\4a\b3\a6\1b\55\26\46\b8\ee\2b\36\b3\ee\66\72
Filter example: (&(objectClass=*)(objectGUID =
\b5\4a\b3\a6\1b\55\26\46\b8\ee\2b\36\b3\ee\66\72))
Scope: Subtree
Attributes: objectGUID
Class [Type = UnicodeString]: class of the object that was modified. Some of the common Active Directory
object classes:
user for users.
group for groups.
For all possible values of this field open Active Directory Schema snap-in (see how to enable this
Attribute:
LDAP Display Name [Type = UnicodeString]: the object attribute that was modified.
Note LDAP Display Name is the name used by LDAP clients, such as the ADSI LDAP provider, to read and write
the attribute by using the LDAP protocol.
Syntax (OID) [Type = UnicodeString]: The syntax for an attribute defines the storage representation, byte
ordering, and matching rules for comparisons of property types. Whether the attribute value must be a string, a
number, or a unit of time is also defined. Every attribute of every object is associated with exactly one syntax.
The syntaxes are not represented as objects in the schema, but they are programmed to be understood by
Active Directory. The allowable syntaxes in Active Directory are predefined.
OID SYNTAX NAME DESCRIPTION
2.5.5.0 Undefined Not a legal syntax.

OID SYNTAX NAME DESCRIPTION
2.5.5.1 Object(DN-DN) The fully qualified name of an object in

the directory.
2.5.5.2 String(Object-Identifier) The object identifier.
2.5.5.3 Case-Sensitive String General String.
2.5.5.4 CaseIgnoreString(Teletex) Differentiates uppercase and lowercase.
2.5.5.5 String(Printable), String(IA5) Teletex. Does not differentiate

uppercase and lowercase.
2.5.5.6 String(Numeric) Printable string or IA5-String.
2.5.5.7 Object(DN-Binary) Both character sets are case-sensitive.
2.5.5.8 Boolean A sequence of digits.
2.5.5.9 Integer, Enumeration A distinguished name plus a binary

large object.
2.5.5.10 String(Octet) TRUE or FALSE values.
2.5.5.11 String(UTC-Time), String(Generalized- A 32-bit number or enumeration.

Time)
2.5.5.12 String(Unicode) A string of bytes.
2.5.5.13 Object(Presentation-Address) UTC Time or Generalized-Time.
2.5.5.14 Object(DN-String) Unicode string.
2.5.5.15 String(NT-Sec-Desc) Presentation address.
2.5.5.16 LargeInteger A DN-String plus a Unicode string.
2.5.5.17 String(Sid) A Microsoft Windows NT Security

descriptor.
Table 10. LDAP Attribute Syntax OIDs.
Value [Type = UnicodeString]: the value which was added or deleted, depending on the Operation\Type field.
Operation:
Type [Type = UnicodeString]: type of performed operation.
Value Added new value added.
Value Deleted value deleted (typically Value Deleted is a part of change operation).
Correlation ID [Type = GUID]: multiple modifications are often executed as one operation via LDAP. This value
allows you to correlate all the modification events that comprise the operation. Just look for other events from
current subcategory with the same Correlation ID, for example 5137: A directory service object was created.
and 5139: A directory service object was moved.
Application Correlation ID [Type = UnicodeString]: always has - value. Not in use.

For 5136(S): A directory service object was modified.
If you need to monitor modifications to specific Active Directory objects, monitor for DN field with specific
object name. For example, we recommend that you monitor all modifications to
CN=AdminSDHolder,CN=System,DC=domain,DC=com object.
If you need to monitor modifications to specific Active Directory classes, monitor for Class field with specific
class name. For example, we recommend that you monitor all modifications to domainDNS class.
If you need to monitor modifications to specific Active Directory attributes, monitor for LDAP Display
Name field with specific attribute name.
It is better to monitor Operation\Type = Value Added events, because you will see the new value of
attribute. At the same time you can correlate to previous Operation\Type = Value Deleted event with the
same Correlation ID to see the previous value.
5137(S): A directory service object was created.
Applies to
Windows 10
Windows Server 2016
Event Description:
Directory object is created.
This event only generates if the parent object
has a particular entry in its SACL: the Create
action, auditing for specific classes or objects.
An example is the Create Computer
objects action auditing for the organizational
unit.

Event XML:
- <System>
<Level>0</Level>
<Task>14081</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="OpCorrelationID">{4EAD68FF-7229-42A4-8C73-AAB57169858B}</Data>
<Data Name="ObjectDN">cn=Win2000,CN=Users,DC=contoso,DC=local</Data>
<Data Name="ObjectGUID">{41D5F7AF-64A2-4985-9A4B-70DAAFC7CCE6}</Data>
<Data Name="ObjectClass">computer</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the create object operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the create object
operation.
the following:
Directory Service:
Name [Type = UnicodeString]: the name of an Active Directory domain, where new object is created.
Object:
DN [Type = UnicodeString]: distinguished name of the object that was created.
attributes:
CN - commonName
this b54ab3a6-1b55-2646
2b36b3ee6672
\b5\4a\b3\a6\1b\55\26\46\b8\ee\2b\36\b3\ee\66\72
\b5\4a\b3\a6\1b\55\26\46\b8\ee\2b\36\b3\ee\66\72))
Scope: Subtree
Class [Type = UnicodeString]: class of the object that was created. Some of the common Active Directory
object classes:
user for users.
group for groups.
Operation:
current subcategory with the same Correlation ID, for example 5136: A directory service object was
modified. and 5139: A directory service object was moved.

For 5137(S): A directory service object was created.
If you need to monitor creation of Active Directory objects with specific classes, monitor for Class field with
specific class name. For example, we recommend that you monitor all new group policy objects creations:
groupPolicyContainer class.
You must set correct auditing access lists (SACLs) for specific classes within Active Directory container to
get 5137. There is no reason to audit all creation events for all types of Active Directory objects; find the
most important locations (organizational units, folders, etc.) and monitor for creation of specific classes only
(user, computer, group, etc.).
5138(S): A directory service object was undeleted.
Applies to
Windows 10
Windows Server 2016

Event Description:
This event generates every time an Active Directory object is undeleted. It happens, for example, when an Active
Directory object was restored from the Active Directory Recycle Bin.
This event only generates if the container to which the Active Directory object was restored has a particular entry in
its SACL: the Create action, auditing for specific classes or objects. An example is the Create User objects
action.
Event XML:
- <System>
<Level>0</Level>
<Task>14081</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="OpCorrelationID">{3E2B5ECF-4C35-4C3F-8D82-B8D6F477D846}</Data>
<Data Name="SubjectLogonId">0x3be49</Data>
<Data Name="OldObjectDN">CN=Andrei\\0ADEL:53511188-bc98-4995-9d78-2d40143c9711,CN=Deleted
Objects,DC=contoso,DC=local</Data>
<Data Name="NewObjectDN">CN=Andrei,CN=Users,DC=contoso,DC=local</Data>
<Data Name="ObjectGUID">{53511188-BC98-4995-9D78-2D40143C9711}</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested that the object be undeleted or restored. Event Viewer
Account Name [Type = UnicodeString]: name of account that requested that the object be undeleted or
restored.
the following:
Directory Service:
Name [Type = UnicodeString]: the name of an Active Directory domain, where the object was undeleted.
Object:
Old DN [Type = UnicodeString]: Old distinguished name of undeleted object. It will points to Active Directory
Recycle Bin folder, in case if it was restored from it.
attributes:
CN - commonName
New DN [Type = UnicodeString]: New distinguished name of undeleted object. The Active Directory
container to which the object was restored.
this b54ab3a6-1b55-2646
2b36b3ee6672
\b5\4a\b3\a6\1b\55\26\46\b8\ee\2b\36\b3\ee\66\72
\b5\4a\b3\a6\1b\55\26\46\b8\ee\2b\36\b3\ee\66\72))
Scope: Subtree
Class [Type = UnicodeString]: class of the object that was undeleted. Some of the common Active Directory
object classes:
user for users.
group for groups.
Operation:

For 5138(S): A directory service object was undeleted.
If you need to monitor undelete operations (restoration) of Active Directory objects with specific classes,
monitor for Class field with specific class name.
It may be a good idea to monitor all undelete events, because the operation is not performed very often.
Confirm that there is a reason for the object to be undeleted.
5139(S): A directory service object was moved.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Directory Service
Changes
Event Description:
This event generates every time an
Active Directory object is moved.
This event only generates if the
destination object has a particular
entry in its SACL: the Create action,
auditing for specific classes or objects.
An example is the Create Computer
objects action, auditing for the
organizational unit.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>14081</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="OpCorrelationID">{67A42C05-A70D-4348-AF19-E883CB1FCA9C}</Data>
<Data Name="OldObjectDN">CN=NewUser,CN=Builtin,DC=contoso,DC=local</Data>
<Data Name="NewObjectDN">CN=NewUser,CN=Users,DC=contoso,DC=local</Data>
<Data Name="ObjectGUID">{06713960-9CC3-4B5D-A594-35883A04F934}</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the move object operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the move object
operation.
the following:
Directory Service:
Name [Type = UnicodeString]: the name of an Active Directory domain, where the object was moved.
Object:
Old DN [Type = UnicodeString]: Old distinguished name of moved object.
attributes:
CN - commonName
New DN [Type = UnicodeString]: New distinguished name of moved object. The Active Directory container
to which the object was moved.
this b54ab3a6-1b55-2646
2b36b3ee6672
\b5\4a\b3\a6\1b\55\26\46\b8\ee\2b\36\b3\ee\66\72
\b5\4a\b3\a6\1b\55\26\46\b8\ee\2b\36\b3\ee\66\72))
Scope: Subtree
Class [Type = UnicodeString]: class of the object that was moved. Some of the common Active Directory
object classes:
user for users.
group for groups.
Operation:
and 5141: A directory service object was deleted.

For 5139(S): A directory service object was moved.
If you need to monitor movement of Active Directory objects with specific classes, monitor for Class field
with specific class name.
You must set correct auditing access lists (SACLs) for specific classes within Active Directory container to
get 5139. There is no reason to audit all movement events for all types of Active Directory objects, you need
to find the most important locations (organizational units, folders, etc.) and monitor for movement of
specific classes only to these locations (user, computer, group, etc.).
5141(S): A directory service object was deleted.
Applies to
Windows 10
Windows Server 2016
Event Description:
Directory object is deleted.
This event only generates if the deleted object
has a particular entry in its SACL: the Delete
action, auditing for specific objects.

Event XML:
- <System>
<Level>0</Level>
<Task>14081</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="OpCorrelationID">{C8A9000C-C618-4EE9-87FF-F852C0564F18}</Data>
<Data Name="ObjectDN">CN=WIN2003,CN=Users,DC=contoso,DC=local</Data>
<Data Name="ObjectGUID">{CA15B875-AFB1-4E5A-86B2-96E61DE09110}</Data>
<Data Name="ObjectClass">computer</Data>
<Data Name="TreeDelete">%%14679</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the delete object operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the delete object
operation.
the following:
Directory Service:
Name [Type = UnicodeString]: the name of an Active Directory domain, where the object was deleted.
Object:
DN [Type = UnicodeString]: distinguished name of the object that was deleted.
attributes:
CN - commonName
Event Viewer automatically resolves GUID field to real object. For deleted objects GUID will be resolved to
new destination of object, for example: OU=My\0ADEL:cc94c0d7-dd53-4061-9791-
e53478dbbc3b,CN=Deleted Objects,DC=contoso,DC=local.
this b54ab3a6-1b55-2646
2b36b3ee6672
\b5\4a\b3\a6\1b\55\26\46\b8\ee\2b\36\b3\ee\66\72
\b5\4a\b3\a6\1b\55\26\46\b8\ee\2b\36\b3\ee\66\72))
Scope: Subtree
Class [Type = UnicodeString]: class of the object that was deleted. Some of the common Active Directory
object classes:
user for users.
group for groups.
Operation:
Tree Delete [Type = UnicodeString]:
Yes Delete Subtree operation was performed. It happens, for example, if Use Delete Subtree
server control check box was checked during delete operation using Active Directory Users and
Computers management console.
No delete operation was performed without Delete Subtree server control.

For 5141(S): A directory service object was deleted.
If you need to monitor deletion of Active Directory objects with specific classes, monitor for Class field with
specific class name. For example, we recommend that you monitor for group policy objects deletions:
groupPolicyContainer class.
If you need to monitor deletion of specific Active Directory objects, monitor for DN field with specific object
name. For example, if you have critical Active Directory objects which should not be deleted, monitor for
their deletion.
Audit Directory Service Replication
Applies to
Windows 10
Windows Server 2016
Audit Directory Service Replication determines whether the operating system generates audit events when
replication between two domain controllers begins and ends.
Event volume: Medium on domain controllers.
STRONGER STRONGER
Domain No No IF IF IF - Events in this

typically have an
informational
purpose and it is
difficult to detect
any malicious
activity using
these events. Its
mainly used for
Active Directory
replication
troubleshooting.

makes sense only
on domain
controllers.

makes sense only
on domain
controllers.
Events List:
4932(S): Synchronization of a replica of an Active Directory naming context has begun.
4933(S, F): Synchronization of a replica of an Active Directory naming context has ended.
4932(S): Synchronization of a replica of an Active
Directory naming context has begun.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Directory Service Replication

Event Description:
This event generates every time synchronization of a replica of an Active Directory naming context has begun.
Event XML:
- <System>
<Level>0</Level>
<Task>14082</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SessionID">48</Data>
<Data Name="StartUSN">20869</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Note The Directory Replication Agent (DRA) handles replication between domain controllers. The
Directory Replication Agent uses the connection objects in the topology map to find out those partners that are
relevant when replicating changes to directory partitions. The DRA sends a replication request to the partners
of a domain controller when the domain controller needs to update its copy of Active Directory.
attributes:
CN - commonName


Session ID [Type = UInt32]: unique identifier of replication session. Using this field you can find 4932:
Synchronization of a replica of an Active Directory naming context has begun. and 4933: Synchronization
of a replica of an Active Directory naming context has ended. events for the same session.
Start USN [Type = UnicodeString]: Naming Contexts USN number before replication begins.
Note Active Directory replication does not depend on time to determine what changes need to be propagated.
It relies instead on the use of update sequence numbers (USNs) that are assigned by a counter that is local
to each domain controller. Because these USN counters are local, it is easy to ensure that they are reliable and
never "run backward" (that is, decrease in value). The trade-off is that it is meaningless to compare a USN
assigned on one domain controller to a USN assigned on a different domain controller. The replication system
is designed with this restriction in mind.

For 4932(S): Synchronization of a replica of an Active Directory naming context has begun.
Monitor for Source Address field, because the source of replication (DRA) must be authorized for this
action. If you find any unauthorized DRA you should trigger an event.
4933(S, F): Synchronization of a replica of an Active
Directory naming context has ended.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Directory Service Replication

Event Description:
This event generates every time synchronization of a replica of an Active Directory naming context has ended.
Failure event occurs when synchronization of a replica of an Active Directory naming context failed.
Event XML:
- <System>
<Level>0</Level>
<Task>14082</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SessionID">40</Data>
<Data Name="EndUSN">20869</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Note The Directory Replication Agent (DRA) handles replication between domain controllers. The
Directory Replication Agent uses the connection objects in the topology map to find out those partners that are
relevant when replicating changes to directory partitions. The DRA sends a replication request to the partners
of a domain controller when the domain controller needs to update its copy of Active Directory.
attributes:
CN - commonName

Note The Directory Tree of Active Directory tree is partitioned to allow sections to be distributed (replicated)
to domain controllers in different domains within the forest. Each domain controller stores a copy of a specific

Session ID [Type = UInt32]: unique identifier of replication session. Using this field you can find 4932:
Synchronization of a replica of an Active Directory naming context has begun. and 4933: Synchronization
of a replica of an Active Directory naming context has ended. events for the same session.
End USN [Type = UInt32]: Naming Contexts USN number after replication ends.
Note Active Directory replication does not depend on time to determine what changes need to be propagated.
It relies instead on the use of update sequence numbers (USNs) that are assigned by a counter that is local
to each domain controller. Because these USN counters are local, it is easy to ensure that they are reliable and
never "run backward" (that is, decrease in value). The trade-off is that it is meaningless to compare a USN
assigned on one domain controller to a USN assigned on a different domain controller. The replication system
is designed with this restriction in mind.
you will receive Failure event and Status Code will not be equal to 0. You can check error code meaning here:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx

For 4933(S, F): Synchronization of a replica of an Active Directory naming context has ended.
Monitor for Source Address field, because the source of replication (DRA) must be authorized for this
action. If you find any unauthorized DRA you should trigger an event.
Audit Account Lockout
Applies to
Windows 10
Windows Server 2016
Audit Account Lockout enables you to audit security events that are generated by a failed attempt to log on to an
account that is locked out.
If you configure this policy setting, an audit event is generated when an account cannot log on to a computer
because the account is locked out. Success audits record successful attempts and failure audits record unsuccessful
attempts.
Account lockout events are essential for understanding user activity and detecting potential attacks.
Event volume: Low.
This subcategory failure logon attempts, when account was already locked out.
STRONGER STRONGER
Domain No Yes No Yes We recommend

Controller tracking account
lockouts,
especially for high
value domain or
local accounts
(database
administrators,
built-in local
administrator
account, domain
administrators,
service accounts,
domain controller
accounts, and so
on).
This subcategory
doesnt have
Success events,
so there is no
recommendation
to enable Success
auditing for this
subcategory.
STRONGER STRONGER
Member Server No Yes No Yes We recommend

tracking account
lockouts,
especially for high
value domain or
local accounts
(database
administrators,
built-in local
administrator
account, domain
administrators,
service accounts,
domain controller
accounts, and so
on).
This subcategory
doesnt have
Success events,
so there is no
recommendation
to enable Success
auditing for this
subcategory.
Workstation No Yes No Yes We recommend

tracking account
lockouts,
especially for high
value domain or
local accounts
(database
administrators,
built-in local
administrator
account, domain
administrators,
service accounts,
domain controller
accounts, and so
on).
This subcategory
doesnt have
Success events,
so there is no
recommendation
to enable Success
auditing for this
subcategory.
Events List:
4625(F): An account failed to log on.
Applies to
Windows 10
Windows Server 2016
Subcategories: Audit Account Lockout and
Audit Logon
Event Description:
This event generates if an account logon
attempt failed when the account was already
locked out. It also generates for a logon attempt
after which the account was locked out.
It generates on the computer where logon
attempt was made, for example, if logon
attempt was made on users workstation, then
event will be logged on this workstation.

Event XML:
- <System>
<Level>0</Level>
<Task>12546</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="FailureReason">%%2307</Data>
<Data Name="SubStatus">0x0</Data>
<Data Name="LogonType">2</Data>
<Data Name="LogonProcessName">User32</Data>
<Data Name="AuthenticationPackageName">Negotiate</Data>
<Data Name="WorkstationName">DC01</Data>
<Data Name="LmPackageName">-</Data>
<Data Name="KeyLength">0</Data>
<Data Name="ProcessId">0x1bc</Data>
<Data Name="ProcessName">C:\\Windows\\System32\\winlogon.exe</Data>
<Data Name="IpAddress">127.0.0.1</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that reported information about logon failure. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that reported information about logon
failure.
the following:
Logon Type [Type = UInt32]: the type of logon which was performed. Table 11. Windows Logon Types contains
the list of possible values for this field.



Control Manager.

called cleartext).

connections.

Remote Desktop.

the credentials.
Table: Windows Logon Types
Account For Which Logon Failed:

Security ID [Type = SID]: SID of the account that was specified in the logon attempt. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: the name of the account that was specified in the logon attempt.
following:
Failure Information:
Failure Reason [Type = UnicodeString]: textual explanation of Status field value. For this event it typically
has Account locked out value.
Status [Type = HexInt32]: the reason why logon failed. For this event it typically has 0xC0000234 value.
The most common status codes are listed in Table 12. Windows logon status codes.
STATUS\SUB-STATUS CODE DESCRIPTION
0XC000005E There are currently no logon servers available to service the

logon request.
0xC0000064 User logon with misspelled or bad user account
0xC000006A User logon with misspelled or bad password
0XC000006D This is either due to a bad username or authentication

information
0XC000006E Unknown user name or bad password.
0xC000006F User logon outside authorized hours
0xC0000070 User logon from unauthorized workstation
0xC0000071 User logon with expired password
0xC0000072 User logon to account disabled by administrator
0XC00000DC Indicates the Sam Server was in the wrong state to perform
the desired operation.
0XC0000133 Clocks between DC and other computer too far out of sync
0XC000015B The user has not been granted the requested logon type (aka
logon right) at this machine
0XC000018C The logon request failed because the trust relationship

between the primary domain and the trusted domain failed.
0XC0000192 An attempt was made to logon, but the Netlogon service was
not started.
0xC0000193 User logon with expired account
0XC0000224 User is required to change password at next logon
0XC0000225 Evidently a bug in Windows and not a risk
0xC0000234 User logon with account locked
0XC00002EE Failure Reason: An Error occurred during Logon
0XC0000413 Logon Failure: The machine you are logging onto is protected
by an authentication firewall. The specified account is not
allowed to authenticate to the machine.
0x0 Status OK.
Table: Windows logon status codes.

Note To see the meaning of other status\sub-status codes you may also check for status code in the Window
header file ntstatus.h in Windows SDK.
More information: https://dev.windows.com/en-us/downloads
Sub Status [Type = HexInt32]: additional information about logon failure. The most common sub-status codes
listed in the Table 12. Windows logon status codes..
Caller Process ID [Type = Pointer]: hexadecimal Process ID of the process that attempted the logon. Process
ID (PID) is a number used by the operating system to uniquely identify an active process. To see the PID for a
Caller Process Name [Type = UnicodeString]: full path and the name of the executable for the process.
Workstation Name [Type = UnicodeString]: machine name from which logon attempt was performed.
Source Network Address [Type = UnicodeString]: IP address of machine from which logon attempt was
performed.
IPv6 address or ::ffff:IPv4 address of a client.
::1 or 127.0.0.1 means localhost.
Source Port [Type = UnicodeString]: source port which was used for logon attempt from remote machine.
0 for interactive logons.
Detailed Authentication Information:
Logon Process [Type = UnicodeString]: the name of the trusted logon process that was used for the logon
attempt. See event 4611: A trusted logon process has been registered with the Local Security Authority
description for more information.
Authentication Package [Type = UnicodeString]: The name of the authentication package which was used
for the logon authentication process. Default packages loaded on LSA startup are located in
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig registry key. Other packages can be loaded at
runtime. When a new package is loaded a 4610: An authentication package has been loaded by the Local
Security Authority (typically for NTLM) or 4622: A security package has been loaded by the Local Security
Authority (typically for Kerberos) event is logged to indicate that a new package has been loaded along with
the package name. The most common authentication packages are:
NTLM NTLM-family Authentication
Kerberos Kerberos authentication.
Negotiate the Negotiate security package selects between Kerberos and NTLM protocols. Negotiate
selects Kerberos unless it cannot be used by one of the systems involved in the authentication or the
calling application did not provide sufficient information to use Kerberos.
Transited Services [Type = UnicodeString] [Kerberos-only]: the list of transmitted services. Transmitted
services are populated if the logon was a result of a S4U (Service For User) logon process. S4U is a Microsoft
extension to the Kerberos Protocol to allow an application service to obtain a Kerberos service ticket on
behalf of a user most commonly done by a front-end website to access an internal resource on behalf of a
user. For more information about S4U, see https://msdn.microsoft.com/en-us/library/cc246072.aspx
Package Name (NTLM only) [Type = UnicodeString]: The name of the LAN Manager sub-package (NTLM-
family protocol name) that was used during the logon attempt. Possible values are:
NTLM V1
NTLM V2
LM
Only populated if Authentication Package = NTLM.
Key Length [Type = UInt32]: the length of NTLM Session Security key. Typically it has 128 bit or 56 bit
length. This parameter is always 0 if Authentication Package = Kerberos, because it is not applicable
for Kerberos protocol. This field will also have 0 value if Kerberos was negotiated using Negotiate
authentication package.

For 4625(F): An account failed to log on.
If you have a pre-defined list of restricted substrings or words in process names (for example, mimikatz or
cain.exe), check for these substrings in Process Name.
If Subject\Account Name is a name of service account or user account, it may be useful to investigate
whether that account is allowed (or expected) to request logon for Account For Which Logon
Failed\Security ID.
To monitor for a mismatch between the logon type and the account that uses it (for example, if Logon Type
4-Batch or 5-Service is used by a member of a domain administrative group), monitor Logon Type in this
event.
If you have a high-value domain or local account for which you need to monitor every lockout, monitor all
4625 events with the Subject\Security ID that corresponds to the account.
We recommend monitoring all 4625 events for local accounts, because these accounts typically should not
be locked out. This is especially relevant for critical servers, administrative workstations, and other high value
assets.
We recommend monitoring all 4625 events for service accounts, because these accounts should not be
locked out or prevented from functioning. This is especially relevant for critical servers, administrative
workstations, and other high value assets.
If your organization restricts logons in the following ways, you can use this event to monitor accordingly:
If the Account For Which Logon Failed \Security ID should never be used to log on from the
specific Network Information\Workstation Name.
If a specific account, such as a service account, should only be used from your internal IP address list
(or some other list of IP addresses). In this case, you can monitor for Network Information\Source
Network Address and compare the network address with your list of IP addresses.
If a particular version of NTLM is always used in your organization. In this case, you can use this event
to monitor Package Name (NTLM only), for example, to find events where Package Name (NTLM
only) does not equal NTLM V2.
If NTLM is not used in your organization, or should not be used by a specific account (New
Logon\Security ID). In this case, monitor for all events where Authentication Package is NTLM.
If the Authentication Package is NTLM. In this case, monitor for Key Length not equal to 128,
because all Windows operating systems starting with Windows 2000 support 128-bit Key Length.
If Logon Process is not from a trusted logon processes list.
Monitor for all events with the fields and values in the following table:
FIELD VALUE TO MONITOR FOR
Failure Information\Status or 0XC000005E There are currently no logon servers available

Failure Information\Sub Status to service the logon request.
This is typically not a security issue but it can be an
infrastructure or availability issue.
Failure Information\Status or 0xC0000064 User logon with misspelled or bad user

Failure Information\Sub Status account.
Especially if you get a number of these in a row, it can be a
sign of user enumeration attack.
Failure Information\Status or 0xC000006A User logon with misspelled or bad password

Failure Information\Sub Status for critical accounts or service accounts.
Especially watch for a number of such events in a row.
Failure Information\Status or 0XC000006D This is either due to a bad username or

Failure Information\Sub Status authentication information for critical accounts or service
accounts.
Failure Information\Status or 0xC000006F User logon outside authorized hours.

Failure Information\Sub Status
Failure Information\Status or 0xC0000070 User logon from unauthorized workstation.

Failure Information\Status or 0xC0000072 User logon to account disabled by

Failure Information\Sub Status administrator.
Failure Information\Status or 0XC000015B The user has not been granted the requested
Failure Information\Sub Status logon type (aka logon right) at this machine.
Failure Information\Status or 0XC0000192 An attempt was made to logon, but the

Failure Information\Sub Status Netlogon service was not started.
Failure Information\Status or 0xC0000193 User logon with expired account.

Failure Information\Status or 0XC0000413 Logon Failure: The machine you are logging
Failure Information\Sub Status onto is protected by an authentication firewall. The specified
account is not allowed to authenticate to the machine.
Audit User/Device Claims
Applies to
Windows 10
Windows Server 2016
Audit User/Device Claims allows you to audit user and device claims information in the accounts logon token.
Events in this subcategory are generated on the computer on which a logon session is created. For an interactive
logon, the security audit event is generated on the computer that the user logged on to.
For a network logon, such as accessing a shared folder on the network, the security audit event is generated on the
computer hosting the resource.
Important: Audit Logon subcategory must also be enabled in order to get events from this subcategory.
Event volume:
Low on a client computer.
Medium on a domain controller or network servers.
STRONGER STRONGER
Domain IF No IF No IF if claims are

Controller in use in your
organization and
you need to
monitor
user/device
claims, enable
Success auditing
for this
subcategory.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Member Server IF No IF No IF if claims are

in use in your
organization and
you need to
monitor
user/device
claims, enable
Success auditing
for this
subcategory.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Workstation IF No IF No IF if claims are

in use in your
organization and
you need to
monitor
user/device
claims, enable
Success auditing
for this
subcategory.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Events List:
4626(S): User/Device claims information.
4626(S): User/Device claims information.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit User/Device
Claims
Event Description:
This event generates for new
account logons and contains
user/device claims which were
associated with a new logon
session.
This event does not generate if
the user/device doesnt have
claims.
For computer account logons
you will also see device claims
listed in the User Claims field.
You will typically get 4624: An
account was successfully logged
on and after it a 4626 event
with the same information in
Subject, Logon Type and New
Logon sections.
This event generates on the
computer to which the logon
was performed (target
computer). For example, for
Interactive logons it will be the
same computer.
Note For recommendations,

see Security Monitoring Recommendations for this event.
Event XML:
- <System>
<Level>0</Level>
<Task>12553</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectUserName">-</Data>
<Data Name="SubjectDomainName">-</Data>
<Data Name="TargetLogonId">0x136f7b</Data>
<Data Name="EventIdx">1</Data>
<Data Name="EventCountTotal">1</Data>
<Data Name="UserClaims">ad://ext/cn:88d2b96fdb2b4c49 <%%1818> : "dadmin" ad://ext/Department:88d16a8edaa8c66b
<%%1818> : "IT"</Data>
<Data Name="DeviceClaims">-</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that reported information about claims. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: the name of the account that reported information about claims.
the following:
Logon Type [Type = UInt32]: the type of logon which was performed. The table below contains the list of possible
values for this field:



Control Manager.

called cleartext).

connections.

Remote Desktop.

the credentials.
New Logon:
Security ID [Type = SID]: SID of account for which logon was performed. Event Viewer automatically tries to
event.
Account Name [Type = UnicodeString]: the name of the account for which logon was performed.
the following:
Event in sequence [Type = UInt32]: If is there is not enough space in one event to put all claims, you will see 1 of
N in this field and additional events will be generated. Typically this field has 1 of 1 value.
User Claims [Type = UnicodeString]: list of user claims for new logon session. This field contains user claims if
user account was logged in and device claims if computer account was logged in. Here is an example how to parse
the entrance of this field:
ad://ext/cn:88d2b96fdb2b4c49 <String> : dadmin
cn claim display name.
88d2b96fdb2b4c49 unique claim ID.
<String> - claim type.
dadmin claim value.
Device Claims [Type = UnicodeString]: list of device claims for new logon session. For user accounts this field
typically has - value. For computer accounts this field has device claims listed.

For 4626(S): User/Device claims information.
Typically this action is reported by the NULL SID account, so we recommend reporting all events with
Subject\Security ID not equal NULL SID.
If you need to monitor account logons with specific claims, you can monitor for 4626 and check User
Claims\Device Claims fields.
If you have specific requirements, such as:
Users with specific claims should not access specific computers;
Computer account should not have specific claims;
User account should not have specific claims;
Claim should not be empty
And so on
You can monitor for 4626 and check User Claims\Device Claims fields.
If you need to monitor computer/user logon attempts only and you dont need information about claims,
then it is better to monitor 4624: An account was successfully logged on.
Audit Group Membership
Applies to
Windows 10
Windows Server 2016
Audit Group Membership enables you to audit group memberships when they are enumerated on the client
computer.
This policy allows you to audit the group membership information in the user's logon token. Events in this
subcategory are generated on the computer on which a logon session is created.
For an interactive logon, the security audit event is generated on the computer that the user logged on to. For a
network logon, such as accessing a shared folder on the network, the security audit event is generated on the
computer hosting the resource.
You must also enable the Audit Logon subcategory.
Multiple events are generated if the group membership information cannot fit in a single security audit event
Event volume:
Medium on a domain controller or network servers.
STRONGER STRONGER
STRONGER STRONGER
Domain Yes No Yes No Group

Controller membership
information for
logged in user
can help to
detect that
member of
specific domain
or local group
logged in to the
machine (for
example, member
of database
administrators,
built-in local
administrators,
domain
administrators,
service accounts
group or other
high value
groups).
For
recommendation
s for using and
analyzing the
collected
information, see
the Security
Monitoring
Recommendatio
ns sections.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Member Server Yes No Yes No Group

membership
information for
logged in user
can help to
detect that
member of
specific domain
or local group
logged in to the
machine (for
example, member
of database
administrators,
built-in local
administrators,
domain
administrators,
service accounts
group or other
high value
groups).
For
recommendation
s for using and
analyzing the
collected
information, see
the Security
Monitoring
Recommendatio
ns sections.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Workstation Yes No Yes No Group

membership
information for
logged in user
can help to
detect that
member of
specific domain
or local group
logged in to the
machine (for
example, member
of database
administrators,
built-in local
administrators,
domain
administrators,
service accounts
group or other
high value
groups).
For
recommendation
s for using and
analyzing the
collected
information, see
the Security
Monitoring
Recommendatio
ns sections.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Events List:
4627(S): Group membership information.
4627(S): Group membership information.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Group Membership
Event Description:
This event generates with 4624(S): An account was successfully logged on and shows the list of groups that the
logged-on account belongs to.
You must also enable the Success audit for Audit Logon subcategory to get this event.
Multiple events are generated if the group membership information cannot fit in a single security audit event.
Event XML:
- <System>
<Level>0</Level>
<Task>12554</Task>
<Opcode>0</Opcode>
<Correlation ActivityID="{913FBE70-1CE6-0000-67BF-3F91E61CD101}" />
<Security />
</System>
- <EventData>
<Data Name="TargetLogonId">0x569860</Data>
<Data Name="EventIdx">1</Data>
<Data Name="EventCountTotal">1</Data>
<Data Name="GroupMembership">%{S-1-5-21-1377283216-344919071-3415362939-513} %{S-1-1-0} %{S-1-5-32-544} %{S-1-
5-32-545} %{S-1-5-32-554} %{S-1-5-2} %{S-1-5-11} %{S-1-5-15} %{S-1-5-21-1377283216-344919071-3415362939-512} %
{S-1-5-21-1377283216-344919071-3415362939-572} %{S-1-5-64-10} %{S-1-16-12288}</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that reported information about successful logon or invokes it. Event
Account Name [Type = UnicodeString]: the name of the account that reported information about
successful logon or invokes it.
the following:
that might contain the same Logon ID, for example, 4672(S): Special privileges assigned to new logon.
Logon Type [Type = UInt32]: the type of logon which was performed. The table below contains the list of possible



Control Manager.


called cleartext).

connections.

Remote Desktop.

the credentials.
New Logon:
Security ID [Type = SID]: SID of account for which logon was performed. Event Viewer automatically tries to
Account Name [Type = UnicodeString]: the name of the account for which logon was performed.
the following:
that might contain the same Logon ID, for example, 4672(S): Special privileges assigned to new logon.
Event in sequence [Type = UInt32]: If is there is not enough space in one event to put all groups, you will see 1
of N in this field and additional events will be generated. Typically this field has 1 of 1 value.
Group Membership [Type = UnicodeString]: the list of group SIDs which logged account belongs to (member of).
Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will

For 4627(S): Group membership information.
Typically this action is reported by the NULL SID account, so we recommend reporting all events with
Subject\Security ID not equal NULL SID.
If you need to track that a member of a specific group logged on to a computer, check the Group
Membership field.
Audit IPsec Extended Mode
Applies to
Windows 10
Windows Server 2016
Audit IPsec Extended Mode allows you to audit events generated by Internet Key Exchange protocol (IKE) and
Authenticated Internet Protocol (AuthIP) during Extended Mode negotiations.
Audit IPsec Extended Mode subcategory is out of scope of this document, because this subcategory is mainly used
for IPsec Extended Mode troubleshooting.
STRONGER STRONGER
Domain IF IF IF IF IF - This
Controller subcategory is
mainly used for
IPsec Extended
Mode
troubleshooting,
or for tracing or
monitoring IPsec
Extended Mode
operations.
Member Server IF IF IF IF IF - This

subcategory is
mainly used for
IPsec Extended
Mode
troubleshooting,
or for tracing or
monitoring IPsec
Extended Mode
operations.
Workstation IF IF IF IF IF - This
subcategory is
mainly used for
IPsec Extended
Mode
troubleshooting,
or for tracing or
monitoring IPsec
Extended Mode
operations.
4978: During Extended Mode negotiation, IPsec received an invalid

negotiation packet. If this problem persists, it could indicate a network
issue or an attempt to modify or replay this negotiation.
4979: IPsec Main Mode and Extended Mode security associations were
established.
established.
established.
established.
4983: An IPsec Extended Mode negotiation failed. The corresponding
Main Mode security association has been deleted.
4984: An IPsec Extended Mode negotiation failed. The corresponding
Main Mode security association has been deleted.
Audit IPsec Main Mode
Applies to
Windows 10
Windows Server 2016
Audit IPsec Main Mode allows you to audit events generated by Internet Key Exchange protocol (IKE) and
Authenticated Internet Protocol (AuthIP) during Main Mode negotiations.
Audit IPsec Main Mode subcategory is out of scope of this document, because this subcategory is mainly used for
IPsec Main Mode troubleshooting.
STRONGER STRONGER
mainly used for
IPsec Main Mode
troubleshooting,
or for tracing or
monitoring IPsec
Main Mode
operations.

subcategory is
mainly used for
IPsec Main Mode
troubleshooting,
or for tracing or
monitoring IPsec
Main Mode
operations.
subcategory is
mainly used for
IPsec Main Mode
troubleshooting,
or for tracing or
monitoring IPsec
Main Mode
operations.
4646: Security ID: %1

4650: An IPsec Main Mode security association was established.
Extended Mode was not enabled. Certificate authentication was not
used.
4651: An IPsec Main Mode security association was established.
Extended Mode was not enabled. A certificate was used for
authentication.
4652: An IPsec Main Mode negotiation failed.
4653: An IPsec Main Mode negotiation failed.
4655: An IPsec Main Mode security association ended.
4976: During Main Mode negotiation, IPsec received an invalid
5049: An IPsec Security Association was deleted.
5453: An IPsec negotiation with a remote computer failed because the
IKE and AuthIP IPsec Keying Modules (IKEEXT) service is not started.
Audit IPsec Quick Mode
Applies to
Windows 10
Windows Server 2016
Audit IPsec Quick Mode allows you to audit events generated by Internet Key Exchange protocol (IKE) and
Authenticated Internet Protocol (AuthIP) during Quick Mode negotiations.
Audit IPsec Quick Mode subcategory is out of scope of this document, because this subcategory is mainly used for
IPsec Quick Mode troubleshooting.
STRONGER STRONGER
mainly used for
IPsec Quick
Mode
troubleshooting,
or for tracing or
monitoring IPsec
Quick Mode
operations.

subcategory is
mainly used for
IPsec Quick
Mode
troubleshooting,
or for tracing or
monitoring IPsec
Quick Mode
operations.
subcategory is
mainly used for
IPsec Quick
Mode
troubleshooting,
or for tracing or
monitoring IPsec
Quick Mode
operations.
4977: During Quick Mode negotiation, IPsec received an invalid

5451: An IPsec Quick Mode security association was established.
5452: An IPsec Quick Mode security association ended.
Audit Logoff
Applies to
Windows 10
Windows Server 2016
Audit Logoff determines whether the operating system generates audit events when logon sessions are
terminated.
These events occur on the computer that was accessed. In the case of an interactive logon, these events are
generated on the computer that was logged on to.
There is no failure event in this subcategory because failed logoffs (such as when a system abruptly shuts down)
do not generate an audit record.
Logon events are essential to understanding user activity and detecting potential attacks. Logoff events are not 100
percent reliable. For example, the computer can be turned off without a proper logoff and shutdown; in this case, a
logoff event is not generated.
Event volume: Low.
This subcategory allows you to audit events generated by the closing of a logon session. These events occur on the
computer that was accessed. For an interactive logoff the security audit event is generated on the computer that
the user account logged on to.
STRONGER STRONGER
STRONGER STRONGER
Domain No No Yes No This subcategory

Controller typically
generates huge
amount of
4634(S): An
account was
logged off.
events which,
typically has little
security
relevance. It is
more important
to audit Logon
events using
Audit Logon
subcategory,
rather than
Logoff events.
Enable Success
audit if you want
to track, for
example, for how
long session was
active (in
correlation with
Audit Logon
events) and when
user actually
logged off.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Member Server No No Yes No This subcategory

typically
generates huge
amount of
4634(S): An
account was
logged off.
events which,
security
relevance. It is
more important
to audit Logon
events using
Audit Logon
subcategory,
rather than
Logoff events.
Enable Success
audit if you want
to track, for
example, for how
long session was
active (in
correlation with
Audit Logon
events) and when
user actually
logged off.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Workstation No No Yes No This subcategory

typically
generates huge
amount of
4634(S): An
account was
logged off.
events which,
security
relevance. It is
more important
to audit Logon
events using
Audit Logon
subcategory,
rather than
Logoff events.
Enable Success
audit if you want
to track, for
example, for how
long session was
active (in
correlation with
Audit Logon
events) and when
user actually
logged off.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Events List:
4634(S): An account was logged off.
4647(S): User initiated logoff.
4634(S): An account was logged off.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Logoff
Event Description:
This event shows that logon session was
terminated and no longer exists.
The main difference between 4647: User
initiated logoff. and 4647 event is that 4647
event is generated when logoff procedure was
initiated by specific account using logoff
function, and 4634 event shows that session
was terminated and no longer exists.
4647 is more typical for Interactive and
RemoteInteractive logon types when user
was logged off using standard methods. You
will typically see both 4647 and 4634 events
when logoff procedure was initiated by user.
It may be positively correlated with a 4624: An account was successfully logged on. event using the Logon ID
value. Logon IDs are only unique between reboots on the same computer.
Event XML:
- <System>
<Level>0</Level>
<Task>12545</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetUserSid">S-1-5-90-1</Data>
<Data Name="TargetUserName">DWM-1</Data>
<Data Name="TargetDomainName">Window Manager</Data>
<Data Name="TargetLogonId">0x1a0992</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that was logged off. Event Viewer automatically tries to resolve SIDs
Account Name [Type = UnicodeString]: the name of the account that was logged off.
the following:
Logon Type [Type = UInt32]: the type of logon which was used. The table below contains the list of possible



Control Manager.

called cleartext).

connections.

Remote Desktop.

the credentials.

For 4634(S): An account was logged off.
If a particular Logon Type should not be used by a particular account (for example if Logon Type 4-Batch or
5-Service is used by a member of a domain administrative group), monitor this event for such actions.
4647(S): User initiated logoff.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Logoff
Event Description:
This event is generated when a logoff is
initiated. No further user-initiated activity can
occur. This event can be interpreted as a logoff
event.
The main difference with 4634(S): An account
was logged off. event is that 4647 event is
generated when logoff procedure was initiated
by specific account using logoff function, and
4634 event shows that session was terminated
and no longer exists.
4647 is more typical for Interactive and
RemoteInteractive logon types when user
was logged off using standard methods. You will typically see both 4647 and 4634 events when logoff procedure
was initiated by user.
It may be positively correlated with a 4624: An account was successfully logged on. event using the Logon ID
value. Logon IDs are only unique between reboots on the same computer.
Event XML:
- <System>
<Level>0</Level>
<Task>12545</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetLogonId">0x29b379</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the logoff operation. Event Viewer automatically tries
event.
Account Name [Type = UnicodeString]: the name of the account that requested the logoff operation.
the following:

For 4647(S): User initiated logoff.
Audit Logon
Applies to
Windows 10
Windows Server 2016
Audit Logon determines whether the operating system generates audit events when a user attempts to log on
to a computer.
These events are related to the creation of logon sessions and occur on the computer that was accessed. For an
interactive logon, events are generated on the computer that was logged on to. For a network logon, such as
accessing a share, events are generated on the computer that hosts the resource that was accessed.
The following events are recorded:
Logon success and failure.
Logon attempts by using explicit credentials. This event is generated when a process attempts to log on
an account by explicitly specifying that account's credentials. This most commonly occurs in batch
configurations such as scheduled tasks, or when using the RunAs command.
Security identifiers (SIDs) are filtered.
Logon events are essential to tracking user activity and detecting potential attacks.
Event volume:
Medium on a domain controllers or network servers.
STRONGER STRONGER
Domain Yes Yes Yes Yes Audit Logon

Controller events, for
example, will give
you information
about which
account, when,
using which
Logon Type,
from which
machine logged
on to this
machine.
Failure events
will show you
failed logon
attempts and
the reason why
these attempts
failed.
STRONGER STRONGER
Member Server Yes Yes Yes Yes Audit Logon

events, for
example, will give
you information
about which
account, when,
using which
Logon Type,
from which
machine logged
on to this
machine.
Failure events
will show you
failed logon
attempts and
the reason why
these attempts
failed.
Workstation Yes Yes Yes Yes Audit Logon

events, for
example, will give
you information
about which
account, when,
using which
Logon Type,
from which
machine logged
on to this
machine.
Failure events
will show you
failed logon
attempts and
the reason why
these attempts
failed.
Events List:
4624(S): An account was successfully logged on.
4648(S): A logon was attempted using explicit credentials.
4675(S): SIDs were filtered.
4624(S): An account was successfully
logged on.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit
Logon
Event Description:
This event
generates when a
logon session is
created (on
destination
machine). It
generates on the
computer that was
accessed, where the
session was
created.
Note For
recommendations, see Security Monitoring Recommendations for this event.
Event XML:
- <System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-
A5BA-3E3B0328C30D}" />
<Level>0</Level>
<Task>12544</Task>
<Opcode>0</Opcode>
<Correlation ActivityID="{00D66690-1CDF-0000-AC66-D600DF1CD101}" />
<Computer>WIN-GG82ULGC9GO</Computer>
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">Administrator</Data>
<Data Name="TargetDomainName">WIN-GG82ULGC9GO</Data>
<Data Name="TargetLogonId">0x8dcdc</Data>
<Data Name="WorkstationName">WIN-GG82ULGC9GO</Data>
<Data Name="LogonGuid">{00000000-0000-0000-0000-000000000000}</Data>
<Data Name="ProcessId">0x44c</Data>
<Data Name="ImpersonationLevel">%%1833</Data>
<Data Name="RestrictedAdminMode">-</Data>
<Data Name="TargetOutboundUserName">-</Data>
<Data Name="TargetOutboundDomainName">-</Data>
<Data Name="VirtualAccount">%%1843</Data>
<Data Name="TargetLinkedLogonId">0x0</Data>
<Data Name="ElevatedToken">%%1842</Data>
</EventData>
</Event>

Event Versions:
1 - Windows Server 2012, Windows 8.
Added Impersonation Level field.
2 Windows 10.
Added Logon Information: section.
Logon Type moved to Logon Information: section.
Added Restricted Admin Mode field.
Added Virtual Account field.
Added Elevated Token field.
Added Linked Logon ID field.
Added Network Account Name field.
Added Network Account Domain field.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that reported information about
successful logon or invokes it. Event Viewer automatically tries to resolve SIDs and
show the account name. If the SID cannot be resolved, you will see the source data
in the event.
Note A security identifier (SID) is a unique value of variable length used to

identify a trustee (security principal). Each account has a unique SID that is issued
by an authority, such as an Active Directory domain controller, and stored in a
security database. Each time a user logs on, the system retrieves the SID for that
user from the database and places it in the access token for that user. The system
uses the SID in the access token to identify the user in all subsequent interactions
with Windows security. When a SID has been used as the unique identifier for a
user or group, it cannot ever be used again to identify another user or group. For
Account Name [Type = UnicodeString]: the name of the account that reported
information about successful logon.
Account Domain [Type = UnicodeString]: subjects domain or computer
name. Formats vary, and include the following:
For some well-known security principals, such as LOCAL SERVICE or
ANONYMOUS LOGON, the value of this field is NT AUTHORITY.
For local user accounts, this field will contain the name of the computer
or device that this account belongs to, for example: Win81.
Logon ID [Type = HexInt64]: hexadecimal value that can help you correlate
this event with recent events that might contain the same Logon ID, for
example, 4672(S): Special privileges assigned to new logon.
Logon Information [Version 2]**: **
Logon Type [Version 0, 1, 2] [Type = UInt32]: the type of logon which was
performed. The table below contains the list of possible values for this field.
Logon types and descriptions

2 Interactive A user logged on to this

computer.
3 Network A user or computer logged

on to this computer from the
network.
4 Batch Batch logon type is used by

batch servers, where
processes may be executing
on behalf of a user without
5 Service A service was started by the

Service Control Manager.
7 Unlock This workstation was

unlocked.
8 NetworkCleartext A user logged on to this

The user's password was
passed to the authentication
package in its unhashed
form. The built-in
authentication packages all
hash credentials before
sending them across the
network. The credentials do
not traverse the network in
plaintext (also called
cleartext).
9 NewCredentials A caller cloned its current

token and specified new
credentials for outbound
connections. The new logon
session has the same local
identity, but uses different
credentials for other network
connections.
10 RemoteInteractive A user logged on to this

computer remotely using
Terminal Services or Remote
Desktop.
11 CachedInteractive A user logged on to this

computer with network
credentials that were stored
locally on the computer. The
domain controller was not
contacted to verify the
credentials.
Restricted Admin Mode [Version 2] [Type = UnicodeString]: Only populated

for RemoteInteractive logon type sessions. This is a Yes/No flag indicating if
the credentials provided were passed using Restricted Admin mode. Restricted
Admin mode was added in Win8.1/2012R2 but this flag was added to the
event in Win10.
Reference: http://blogs.technet.com/b/kfalde/archive/2013/08/14/restricted-
admin-mode-for-rdp-in-windows-8-1-2012-r2.aspx.
If not a RemoteInteractive logon, then this will be "-" string.
Virtual Account [Version 2] [Type = UnicodeString]: a Yes or No flag,
which indicates if the account is a virtual account (e.g., "Managed Service
Account"), which was introduced in Windows 7 and Windows Server 2008 R2
to provide the ability to identify the account that a given Service uses, instead
of just using "NetworkService".
Elevated Token [Version 2] [Type = UnicodeString]: a Yes or No flag. If
Yes then the session this event represents is elevated and has administrator
privileges.
Impersonation Level [Version 1, 2] [Type = UnicodeString]: can have one of these
four values:
SecurityAnonymous (displayed as empty string): The server process cannot
obtain identification information about the client, and it cannot impersonate
the client. It is defined with no value given, and thus, by ANSI C rules, defaults
to a value of zero.
SecurityIdentification (displayed as "Identification"): The server process can
obtain information about the client, such as security identifiers and privileges,
but it cannot impersonate the client. This is useful for servers that export their
own objects, for example, database products that export tables and views.
Using the retrieved client-security information, the server can make access-
validation decisions without being able to use other services that are using the
client's security context.
SecurityImpersonation (displayed as "Impersonation"): The server process can
impersonate the client's security context on its local system. The server cannot
impersonate the client on remote systems. This is the most common type.
SecurityDelegation (displayed as "Delegation"): The server process can
impersonate the client's security context on remote systems.
New Logon:
Security ID [Type = SID]: SID of account for which logon was performed. Event
Viewer automatically tries to resolve SIDs and show the account name. If the SID
Note A security identifier (SID) is a unique value of variable length used to

identify a trustee (security principal). Each account has a unique SID that is issued
by an authority, such as an Active Directory domain controller, and stored in a
security database. Each time a user logs on, the system retrieves the SID for that
user from the database and places it in the access token for that user. The system
uses the SID in the access token to identify the user in all subsequent interactions
with Windows security. When a SID has been used as the unique identifier for a
user or group, it cannot ever be used again to identify another user or group. For
Account Name [Type = UnicodeString]: the name of the account for which
logon was performed.
Account Domain [Type = UnicodeString]: subjects domain or computer
name. Formats vary, and include the following:
For some well-known security principals, such as LOCAL SERVICE or
ANONYMOUS LOGON, the value of this field is NT AUTHORITY.
For local user accounts, this field will contain the name of the computer
or device that this account belongs to, for example: Win81.
Logon ID [Type = HexInt64]: hexadecimal value that can help you correlate
this event with recent events that might contain the same Logon ID, for
example, 4672(S): Special privileges assigned to new logon.
Linked Logon ID [Version 2] [Type = HexInt64]: A hexadecimal value of the
paired logon session. If there is no other logon session associated with this
logon session, then the value is 0x0.
Network Account Name [Version 2] [Type = UnicodeString]: User name that
will be used for outbound (network) connections. Valid only for
NewCredentials logon type.
If not NewCredentials logon, then this will be a "-" string.
Network Account Domain [Version 2] [Type = UnicodeString]: Domain for
the user that will be used for outbound (network) connections. Valid only for
NewCredentials logon type.
If not NewCredentials logon, then this will be a "-" string.
Logon GUID [Type = GUID]: a GUID that can help you correlate this event with
another event that can contain the same Logon GUID, 4769(S, F): A Kerberos
service ticket was requested event on a domain controller.
It also can be used for correlation between a 4624 event and several other
events (on the same computer) that can contain the same Logon GUID,
4648(S): A logon was attempted using explicit credentials and 4964(S):
Special groups have been assigned to a new logon.
This parameter might not be captured in the event, and in that case appears as
{00000000-0000-0000-0000-000000000000}.
Note GUID is an acronym for 'Globally Unique Identifier'. It is a 128-bit integer

number used to identify resources, activities or instances.
Caller Process ID [Type = Pointer]: hexadecimal Process ID of the process that
attempted the logon. Process ID (PID) is a number used by the operating
system to uniquely identify an active process. To see the PID for a specific
If you convert the hexadecimal value to decimal, you can compare it to the
values in Task Manager.
You can also correlate this process ID with a process ID in other events, for
example, 4688: A new process has been created Process Information\New
Process ID.
Caller Process Name [Type = UnicodeString]: full path and the name of the
executable for the process.
Workstation Name [Type = UnicodeString]: machine name from which logon
attempt was performed.
Source Network Address [Type = UnicodeString]: IP address of machine
from which logon attempt was performed.
Source Port [Type = UnicodeString]: source port which was used for logon
attempt from remote machine.
Logon Process [Type = UnicodeString]: the name of the trusted logon process
that was used for the logon. See event 4611: A trusted logon process has been
registered with the Local Security Authority description for more information.
Authentication Package [Type = UnicodeString]: The name of the
authentication package which was used for the logon authentication process.
Default packages loaded on LSA startup are located in
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig registry key. Other
packages can be loaded at runtime. When a new package is loaded a 4610: An
authentication package has been loaded by the Local Security Authority
(typically for NTLM) or 4622: A security package has been loaded by the Local
Security Authority (typically for Kerberos) event is logged to indicate that a
new package has been loaded along with the package name. The most
common authentication packages are:
Negotiate the Negotiate security package selects between Kerberos
and NTLM protocols. Negotiate selects Kerberos unless it cannot be
used by one of the systems involved in the authentication or the calling
application did not provide sufficient information to use Kerberos.
Transited Services [Type = UnicodeString] [Kerberos-only]: the list of
transmitted services. Transmitted services are populated if the logon was a
result of a S4U (Service For User) logon process. S4U is a Microsoft extension
to the Kerberos Protocol to allow an application service to obtain a Kerberos
service ticket on behalf of a user most commonly done by a front-end
website to access an internal resource on behalf of a user. For more
information about S4U, see https://msdn.microsoft.com/en-
Package Name (NTLM only) [Type = UnicodeString]: The name of the LAN
Manager sub-package (NTLM-family protocol name) that was used during
logon. Possible values are:
NTLM V1
NTLM V2
LM
Key Length [Type = UInt32]: the length of NTLM Session Security key.
Typically it has 128 bit or 56 bit length. This parameter is always 0 if
Authentication Package = Kerberos, because it is not applicable for
Kerberos protocol. This field will also have 0 value if Kerberos was negotiated
using Negotiate authentication package.

For 4624(S): An account was successfully logged on.
High-value accounts: You might have high- Monitor this event with the New
value domain or local accounts for which you Logon\Security ID that corresponds to the
need to monitor each action. high-value account or accounts.
administrators, built-in local administrator
account, domain administrators, service
accounts, domain controller accounts and so
on.
Anomalies or malicious actions: You might When you monitor for anomalies or malicious
have specific requirements for detecting actions, use the New Logon\Security ID
anomalies or monitoring potential malicious (with other information) to monitor how or
actions. For example, you might need to when a particular account is being used.
monitor for use of an account outside of
working hours.
Non-active accounts: You might have non- Monitor this event with the New
active, disabled, or guest accounts, or other Logon\Security ID that corresponds to the
accounts that should never be used. accounts that should never be used.
Account whitelist: You might have a specific If this event corresponds to a whitelist-only
whitelist of accounts that are the only ones action, review the New Logon\Security ID
allowed to perform actions corresponding to for accounts that are outside the whitelist.
particular events.
Accounts of different types: You might If this event corresponds to an action you
want to ensure that certain actions are want to monitor for certain account types,
performed only by certain account types, for review the New Logon\Security ID to see
example, local or domain account, machine or whether the account type is as expected.
user account, vendor or employee account,
and so on.
External accounts: You might be monitoring Monitor this event for the Subject\Account
accounts from another domain, or external Domain corresponding to accounts from
accounts that are not allowed to perform another domain or external accounts.
certain actions (represented by certain specific
events).
Restricted-use computers or devices: You Monitor the target Computer: (or other
might have certain computers, machines, or target device) for actions performed by the
devices on which certain people (accounts) New Logon\Security ID that you are
should not typically perform any actions. concerned about.
Account naming conventions: Your Monitor Subject\Account Name for

organization might have specific naming names that dont comply with naming
conventions for account names. conventions.
Because this event is typically triggered by the SYSTEM account, we

recommend that you report it whenever Subject\Security ID is not
SYSTEM.
If Restricted Admin mode must be used for logons by certain accounts, use
this event to monitor logons by New Logon\Security ID in relation to
Logon Type=10 and Restricted Admin Mode=Yes. If Restricted
Admin Mode=No for these accounts, trigger an alert.
If you need to monitor all logon events for accounts with administrator
privileges, monitor this event with Elevated Token=Yes.
If you need to monitor all logon events for managed service accounts and
group managed service accounts, monitor for events with Virtual
Account=Yes.
To monitor for a mismatch between the logon type and the account that uses it
(for example, if Logon Type 4-Batch or 5-Service is used by a member of a
domain administrative group), monitor Logon Type in this event.
If your organization restricts logons in the following ways, you can use this
event to monitor accordingly:
If the user account New Logon\Security ID should never be used to
log on from the specific Computer:.
If New Logon\Security ID credentials should not be used from
Workstation Name or Source Network Address.
If a specific account, such as a service account, should only be used from
your internal IP address list (or some other list of IP addresses). In this
case, you can monitor for Network Information\Source Network
Address and compare the network address with your list of IP
addresses.
If a particular version of NTLM is always used in your organization. In
this case, you can use this event to monitor Package Name (NTLM
only), for example, to find events where Package Name (NTLM only)
does not equal NTLM V2.
If NTLM is not used in your organization, or should not be used by a
specific account (New Logon\Security ID). In this case, monitor for all
events where Authentication Package is NTLM.
If the Authentication Package is NTLM. In this case, monitor for Key
Length not equal to 128, because all Windows operating systems
starting with Windows 2000 support 128-bit Key Length.
If you monitor for potentially malicious software, or software that is not
authorized to request logon actions, monitor this event for Process Name.
If you have a trusted logon processes list, monitor for a Logon Process that is
not from the list.
Applies to
Windows 10
Windows Server 2016
Subcategories: Audit Account Lockout and
Audit Logon
Event Description:
This event generates if an account logon
attempt failed when the account was already
locked out. It also generates for a logon
attempt after which the account was locked
out.
It generates on the computer where logon
attempt was made, for example, if logon
attempt was made on users workstation,
then event will be logged on this workstation.

event.
Event XML:
- <System>
<Level>0</Level>
<Task>12546</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="FailureReason">%%2307</Data>
<Data Name="SubStatus">0x0</Data>
<Data Name="WorkstationName">DC01</Data>
<Data Name="ProcessId">0x1bc</Data>
<Data Name="ProcessName">C:\\Windows\\System32\\winlogon.exe</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that reported information about logon failure. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that reported information about logon
failure.
the following:
Logon Type [Type = UInt32]: the type of logon which was performed. Table 11. Windows Logon Types contains
the list of possible values for this field.



Control Manager.
8 NetworkCleartext A user logged on to this computer

from the network. The user's password
was passed to the authentication
package in its unhashed form. The
built-in authentication packages all
hash credentials before sending them
across the network. The credentials do
not traverse the network in plaintext
(also called cleartext).

connections.

Remote Desktop.

the credentials.
Table: Windows Logon Types
Account For Which Logon Failed:

Security ID [Type = SID]: SID of the account that was specified in the logon attempt. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that was specified in the logon attempt.
following:
Failure Reason [Type = UnicodeString]: textual explanation of Status field value. For this event it typically
has Account locked out value.
Status [Type = HexInt32]: the reason why logon failed. For this event it typically has 0xC0000234 value.
The most common status codes are listed in Table 12. Windows logon status codes.
0XC000005E There are currently no logon servers available to service the

logon request.
0xC0000064 User logon with misspelled or bad user account
0xC000006A User logon with misspelled or bad password
0XC000006D This is either due to a bad username or authentication

information
0XC000006E Unknown user name or bad password.
0xC000006F User logon outside authorized hours
0xC0000070 User logon from unauthorized workstation
0xC0000071 User logon with expired password
0xC0000072 User logon to account disabled by administrator
0XC00000DC Indicates the Sam Server was in the wrong state to perform
the desired operation.
0XC0000133 Clocks between DC and other computer too far out of sync
0XC000015B The user has not been granted the requested logon type (aka
logon right) at this machine
0XC000018C The logon request failed because the trust relationship

between the primary domain and the trusted domain failed.
0XC0000192 An attempt was made to logon, but the Netlogon service

was not started.
0xC0000193 User logon with expired account
0XC0000224 User is required to change password at next logon
0XC0000225 Evidently a bug in Windows and not a risk
0xC0000234 User logon with account locked
0XC00002EE Failure Reason: An Error occurred during Logon
0XC0000413 Logon Failure: The machine you are logging onto is protected
by an authentication firewall. The specified account is not
allowed to authenticate to the machine.
0x0 Status OK.
Table: Windows logon status codes.

Note To see the meaning of other status\sub-status codes you may also check for status code in the Window
header file ntstatus.h in Windows SDK.
More information: https://dev.windows.com/en-us/downloads
Sub Status [Type = HexInt32]: additional information about logon failure. The most common sub-status codes
listed in the Table 12. Windows logon status codes..
Caller Process ID [Type = Pointer]: hexadecimal Process ID of the process that attempted the logon.
Process ID (PID) is a number used by the operating system to uniquely identify an active process. To see
the PID for a specific process you can, for example, use Task Manager (Details tab, PID column):
Caller Process Name [Type = UnicodeString]: full path and the name of the executable for the process.
Workstation Name [Type = UnicodeString]: machine name from which logon attempt was performed.
Source Network Address [Type = UnicodeString]: IP address of machine from which logon attempt was
performed.
Source Port [Type = UnicodeString]: source port which was used for logon attempt from remote machine.
Logon Process [Type = UnicodeString]: the name of the trusted logon process that was used for the logon
attempt. See event 4611: A trusted logon process has been registered with the Local Security Authority
description for more information.
Authentication Package [Type = UnicodeString]: The name of the authentication package which was
used for the logon authentication process. Default packages loaded on LSA startup are located in
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig registry key. Other packages can be loaded at
runtime. When a new package is loaded a 4610: An authentication package has been loaded by the Local
Security Authority (typically for NTLM) or 4622: A security package has been loaded by the Local Security
Authority (typically for Kerberos) event is logged to indicate that a new package has been loaded along
with the package name. The most common authentication packages are:
Negotiate the Negotiate security package selects between Kerberos and NTLM protocols.
Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the
authentication or the calling application did not provide sufficient information to use Kerberos.
Transited Services [Type = UnicodeString] [Kerberos-only]: the list of transmitted services. Transmitted
services are populated if the logon was a result of a S4U (Service For User) logon process. S4U is a
Microsoft extension to the Kerberos Protocol to allow an application service to obtain a Kerberos service
ticket on behalf of a user most commonly done by a front-end website to access an internal resource on
behalf of a user. For more information about S4U, see https://msdn.microsoft.com/en-
Package Name (NTLM only) [Type = UnicodeString]: The name of the LAN Manager sub-package
(NTLM-family protocol name) that was used during the logon attempt. Possible values are:
NTLM V1
NTLM V2
LM
Key Length [Type = UInt32]: the length of NTLM Session Security key. Typically it has 128 bit or 56 bit
length. This parameter is always 0 if Authentication Package = Kerberos, because it is not
applicable for Kerberos protocol. This field will also have 0 value if Kerberos was negotiated using
Negotiate authentication package.

For 4625(F): An account failed to log on.
If Subject\Account Name is a name of service account or user account, it may be useful to investigate
whether that account is allowed (or expected) to request logon for Account For Which Logon
Failed\Security ID.
To monitor for a mismatch between the logon type and the account that uses it (for example, if Logon
Type 4-Batch or 5-Service is used by a member of a domain administrative group), monitor Logon Type
in this event.
If you have a high-value domain or local account for which you need to monitor every lockout, monitor all
4625 events with the Subject\Security ID that corresponds to the account.
We recommend monitoring all 4625 events for local accounts, because these accounts typically should not
be locked out. This is especially relevant for critical servers, administrative workstations, and other high
value assets.
We recommend monitoring all 4625 events for service accounts, because these accounts should not be
locked out or prevented from functioning. This is especially relevant for critical servers, administrative
workstations, and other high value assets.
If your organization restricts logons in the following ways, you can use this event to monitor accordingly:
If the Account For Which Logon Failed \Security ID should never be used to log on from the
specific Network Information\Workstation Name.
If a specific account, such as a service account, should only be used from your internal IP address list
(or some other list of IP addresses). In this case, you can monitor for Network Information\Source
Network Address and compare the network address with your list of IP addresses.
If a particular version of NTLM is always used in your organization. In this case, you can use this
event to monitor Package Name (NTLM only), for example, to find events where Package Name
(NTLM only) does not equal NTLM V2.
If NTLM is not used in your organization, or should not be used by a specific account (New
Logon\Security ID). In this case, monitor for all events where Authentication Package is NTLM.
If the Authentication Package is NTLM. In this case, monitor for Key Length not equal to 128,
because all Windows operating systems starting with Windows 2000 support 128-bit Key Length.
If Logon Process is not from a trusted logon processes list.
Monitor for all events with the fields and values in the following table:
Failure Information\Status or 0XC000005E There are currently no logon servers available

Failure Information\Sub Status to service the logon request.
Failure Information\Status or 0xC0000064 User logon with misspelled or bad user

Failure Information\Sub Status account.
Especially if you get a number of these in a row, it can be a
sign of user enumeration attack.
Failure Information\Status or 0xC000006A User logon with misspelled or bad password

Failure Information\Sub Status for critical accounts or service accounts.
Failure Information\Status or 0XC000006D This is either due to a bad username or

Failure Information\Sub Status authentication information for critical accounts or service
accounts.
Failure Information\Status or 0xC000006F User logon outside authorized hours.

Failure Information\Status or 0xC0000070 User logon from unauthorized workstation.

Failure Information\Status or 0xC0000072 User logon to account disabled by

Failure Information\Sub Status administrator.
Failure Information\Status or 0XC000015B The user has not been granted the requested
Failure Information\Sub Status logon type (aka logon right) at this machine.
Failure Information\Status or 0XC0000192 An attempt was made to logon, but the

Failure Information\Sub Status Netlogon service was not started.
Failure Information\Status or 0xC0000193 User logon with expired account.

Failure Information\Status or 0XC0000413 Logon Failure: The machine you are logging
Failure Information\Sub Status onto is protected by an authentication firewall. The specified
account is not allowed to authenticate to the machine.
4648(S): A logon was attempted using explicit
credentials.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Logon
Event Description:
This event is generated when a process
attempts an account logon by explicitly
specifying that accounts credentials.
This most commonly occurs in batch-
type configurations such as scheduled
tasks, or when using the RUNAS
command.
It is also a routine event which
periodically occurs during normal
operating system activity.

for this event.
Event XML:
- <System>
<Level>0</Level>
<Task>12544</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">ladmin</Data>
<Data Name="TargetLogonGuid">{0887F1E4-39EA-D53C-804F-31D568A06274}</Data>
<Data Name="TargetServerName">localhost</Data>
<Data Name="TargetInfo">localhost</Data>
<Data Name="IpAddress">::1</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the new logon session with explicit credentials. Event
Account Name [Type = UnicodeString]: the name of the account that requested the new logon session
with explicit credentials.
the following:
Logon GUID [Type = GUID]: a GUID that can help you correlate this event with another event that can
contain the same Logon GUID, 4769(S, F): A Kerberos service ticket was requested event on a domain
controller.
It also can be used for correlation between a 4648 event and several other events (on the same computer)
that can contain the same Logon GUID, 4624(S): An account was successfully logged on and 4964(S):
0000-000000000000}.
Account Whose Credentials Were Used:

Account Name [Type = UnicodeString]: the name of the account whose credentials were used.
the following:
controller.
that can contain the same Logon GUID, 4624(S): An account was successfully logged on and 4964(S):
0000-000000000000}.
Target Server:
Target Server Name [Type = UnicodeString]: the name of the server on which the new process was run.
Has localhost value if the process was run locally.
Additional Information [Type = UnicodeString]: there is no detailed information about this field in this
document.
Process ID [Type = Pointer]: hexadecimal Process ID of the process which was run using explicit credentials.
Process ID (PID) is a number used by the operating system to uniquely identify an active process. To see the
PID for a specific process you can, for example, use Task Manager (Details tab, PID column):
Network Address [Type = UnicodeString]: IP address of machine from which logon attempt was
performed.
Port [Type = UnicodeString]: source port which was used for logon attempt from remote machine.

For 4648(S): A logon was attempted using explicit credentials.
The following table is similar to the table in Appendix A: Security monitoring recommendations for many audit
events, but also describes ways of monitoring that use Account Whose Credentials Were Used\Security ID.
High-value accounts: You might have high value domain or Monitor this event with the Subject\Security ID or
local accounts for which you need to monitor each action. Account Whose Credentials Were Used\Security ID that
Examples of high value accounts are database administrators, correspond to the high value account or accounts.
requirements for detecting anomalies or monitoring potential Subject\Security ID and Account Whose Credentials
malicious actions. For example, you might need to monitor for Were Used\Security ID (with other information) to monitor
use of an account outside of working hours. how or when a particular account is being used.
Non-active accounts: You might have non-active, disabled, Monitor this event with the Subject\Security ID or
or guest accounts, or other accounts that should never be Account Whose Credentials Were Used\Security ID that
used. correspond to the accounts that should never be used.
accounts that are allowed to perform actions corresponding the Subject\Security ID and Account Whose
to particular events. Credentials Were Used\Security ID for accounts that are
outside the whitelist.
External accounts: You might be monitoring accounts from Monitor for the Subject\Account Domain or Account
another domain, or external accounts that are not allowed Whose Credentials Were Used\Security ID corresponding
to perform the action corresponding to this event. to accounts from another domain or external accounts.
certain computers, machines, or devices on which certain actions performed by the Subject\Security ID or Account
people (accounts) should not typically perform any actions. Whose Credentials Were Used\Security ID that you are
concerned about.
For example, you might monitor to ensure that Account
Whose Credentials Were Used\Security ID is not used to
log on to a certain computer.
Account naming conventions: Your organization might Monitor Subject\Account Name and Account Whose
have specific naming conventions for account names. Credentials Were Used\Security ID for names that dont
comply with naming conventions.
If Subject\Security ID should not know or use credentials for Account Whose Credentials Were
Used\Account Name, monitor this event.
If credentials for Account Whose Credentials Were Used\Account Name should not be used from
Network Information\Network Address, monitor this event.
Check that Network Information\Network Address is from internal IP address list. For example, if you
know that a specific account (for example, a service account) should be used only from specific IP addresses,
you can monitor for all events where Network Information\Network Address is not one of the allowed
IP addresses.
4675(S): SIDs were filtered.
Applies to
Windows 10
Windows Server 2016
This event generates when SIDs were filtered for specific Active Directory trust.
See more information about SID filtering here: https://technet.microsoft.com/en-

Subcategory: Audit Logon
Event Schema:
SIDs were filtered.
Target Account:
Security ID:%1
Account Name:%2
Account Domain:%3
Trust Information:
Trust Direction:%4
Trust Attributes:%5
Trust Type:%6
TDO Domain SID:%7
Filtered SIDs:%8

Event Versions: 0.
If you need to monitor all SID filtering events/operations for specific or all Active Directory trusts, you can use
this event to get all required information.
Audit Network Policy Server
Applies to
Windows 10
Windows Server 2016
Audit Network Policy Server allows you to audit events generated by RADIUS (IAS) and Network Access Protection
(NAP) activity related to user access requests. These requests can be Grant, Deny, Discard, Quarantine, Lock, and
Unlock.
If you configure this subcategory, an audit event is generated for each IAS and NAP user access request.
This subcategory generates events only if NAS or IAS role is installed on the server.
NAP events can be used to help understand the overall health of the network.
Event volume: Medium to High on servers that are running Network Policy Server (NPS).
Role-specific subcategories are outside the scope of this document.
STRONGER STRONGER
Domain IF IF IF IF IF if a server
Controller has the Network
Policy Server
(NPS) role
installed and you
need to monitor
access requests
and other NPS-
related events,
enable this
subcategory.
Member Server IF IF IF IF IF if a server

has the Network
Policy Server
(NPS) role
installed and you
need to monitor
access requests
and other NPS-
related events,
enable this
subcategory.
Workstation No No No No Network Policy

Server (NPS) role
cannot be
installed on client
OS.
6272: Network Policy Server granted access to a user.

6273: Network Policy Server denied access to a user.
6274: Network Policy Server discarded the request for a user.
6275: Network Policy Server discarded the accounting request for a
user.
6276: Network Policy Server quarantined a user.
6277: Network Policy Server granted access to a user but put it on
probation because the host did not meet the defined health policy.
6278: Network Policy Server granted full access to a user because the
host met the defined health policy.
6279: Network Policy Server locked the user account due to repeated
failed authentication attempts.
6280: Network Policy Server unlocked the user account.
Applies to
Windows 10
Windows Server 2016
Audit Other Logon/Logoff Events determines whether Windows generates audit events for other logon or logoff
events.
These other logon or logoff events include:
A Remote Desktop session connects or disconnects.
A workstation is locked or unlocked.
A screen saver is invoked or dismissed.
A replay attack is detected. This event indicates that a Kerberos request was received twice with identical
information. This condition could also be caused by network misconfiguration.
A user is granted access to a wireless network. It can be either a user account or the computer account.
A user is granted access to a wired 802.1x network. It can be either a user account or the computer account.
Logon events are essential to understanding user activity and detecting potential attacks.
Event volume: Low.
STRONGER STRONGER
STRONGER STRONGER

Controller Success auditing,
to track possible
Kerberos replay
attacks, terminal
session connect
and disconnect
actions, network
authentication
events, and some
other events.
Volume of these
events is typically
very low.
Failure events will
show you when
requested
credentials
CredSSP
delegation was
disallowed by
policy. The
volume of these
events is very low
typically you
will not get any
of these events.

Success auditing,
to track possible
terminal session
connect and
disconnect
actions, network
authentication
events, and some
other events.
Volume of these
events is typically
very low.
Failure events will
show you when
requested
credentials
CredSSP
delegation was
disallowed by
policy. The
volume of these
events is very low
typically you
will not get any
of these events.
STRONGER STRONGER

Success auditing,
to track possible
terminal session
connect and
disconnect
actions, network
authentication
events, and some
other events.
Volume of these
events is typically
very low.
Failure events will
show you when
requested
credentials
CredSSP
delegation was
disallowed by
policy. The
volume of these
events is very low
typically you
will not get any
of these events.
Events List:
4649(S): A replay attack was detected.
4778(S): A session was reconnected to a Window Station.
4779(S): A session was disconnected from a Window Station.
4800(S): The workstation was locked.
4801(S): The workstation was unlocked.
4802(S): The screen saver was invoked.
4803(S): The screen saver was dismissed.
5378(F): The requested credentials delegation was disallowed by policy.
5632(S): A request was made to authenticate to a wireless network.
5633(S): A request was made to authenticate to a wired network.
4649(S): A replay attack was detected.
Applies to
Windows 10
Windows Server 2016
This event generates on domain controllers when KRB_AP_ERR_REPEAT Kerberos response was sent to the client.
Domain controllers cache information from recently received tickets. If the server name, client name, time, and
microsecond fields from the Authenticator match recently seen entries in the cache, it will return
KRB_AP_ERR_REPEAT. You can read more about this in RFC-1510. One potential cause for this is a misconfigured
network device between the client and server that could send the same packet(s) repeatedly.
Subcategory: Audit Other Logon/Logoff Events
Event Schema:
A replay attack was detected.
Subject:
Security ID:%1
Account Name:%2
Account Domain:%3
Logon ID:%4
Credentials Which Were Replayed:
Account Name:%5
Account Domain:%6
Process ID:%12
Process Name:%13
Workstation Name:%10
Request Type:%7
Logon Process:%8
Authentication Package:%9
Transited Services:%11
This event indicates that a Kerberos replay attack was detected- a request was received twice with identical
information. This condition could be caused by network misconfiguration."
Event Versions: 0.

For 4649(S): A replay attack was detected.
This event can be a sign of Kerberos replay attack or, among other things, network device configuration or
routing problems. In both cases, we recommend triggering an alert and investigating the reason the event was
generated.
4778(S): A session was reconnected to a Window
Station.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event is generated when a user reconnects
to an existing Terminal Services session, or
when a user switches to an existing desktop
using Fast User Switching.
This event also generates when user
reconnects to virtual host Hyper-V Enhanced
Session, for example.

Event XML:
- <System>
<Level>0</Level>
<Task>12551</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="AccountName">ladmin</Data>
<Data Name="AccountDomain">CONTOSO</Data>
<Data Name="LogonID">0x1e01f6</Data>
<Data Name="SessionName">RDP-Tcp\#6</Data>
<Data Name="ClientName">WIN81</Data>
<Data Name="ClientAddress">10.0.0.100</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Account Name [Type = UnicodeString]: the name of the account for which the session was reconnected.
the following:
Session:
Session Name [Type = UnicodeString]: the name of the session to which the user was reconnected.
Examples:
RDP-Rcp#N, where N is a number of session typical RDP session name.
Console console session, typical for Fast User Switching.
31C5CE94259D4006A9E4#3 example of Hyper-V Enhanced Session session name.
You can see the list of current sessions using query session command in command prompt.
Example of output (see SESSIONNAME column):
Client Name [Type = UnicodeString]: computer name from which the user was reconnected. Has
Unknown value for console session.
Client Address [Type = UnicodeString]: IP address of the computer from which the user was reconnected.
Has LOCAL value for console session.

For 4778(S): A session was reconnected to a Window Station.
High-value accounts: You might have high-value domain or Monitor this event with the Subject\Account Name that
requirements for detecting anomalies or monitoring potential Subject\Account Name (with other information) to
malicious actions. For example, you might need to monitor for monitor how or when a particular account is being used.
Non-active accounts: You might have non-active, disabled, Monitor this event with the Subject\Account Name that
or guest accounts, or other accounts that should never be corresponds to the accounts that should never be used.
used.
accounts that are the only ones allowed to perform actions the Subject\Account Name for accounts that are outside
corresponding to particular events. the whitelist.
certain actions are performed only by certain account types, certain account types, review the Subject\Account Name
for example, local or domain account, machine or user to see whether the account type is as expected.
another domain, or external accounts that are not allowed to corresponding to accounts from another domain or external
perform certain actions (represented by certain specific accounts.
events).
certain computers, machines, or devices on which certain actions performed by the Subject\Account Name that you
people (accounts) should not typically perform any actions. are concerned about.
If Fast User Switching is disabled on workstations or specific computers, then monitor for any event with
Session Name = Console.
If Remote Desktop Connections are not allowed for specific users (Subject\Account Name) or disabled on
some computers, then monitor for Session Name = RDP-Tcp# (substring).
If a specific computer or device (Client Name or Client Address) should never connect to this computer
(Computer), monitor for any event with that Client Name or Client Address.
Check that Additional Information\Client Address is from internal IP addresses list.
4779(S): A session was disconnected from a Window
Station.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event is generated when a user
disconnects from an existing Terminal Services
session, or when a user switches away from an
existing desktop using Fast User Switching.
This event also generated when user
disconnects from virtual host Hyper-V
Enhanced Session, for example.

Event XML:
- <System>
<Level>0</Level>
<Task>12551</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="AccountName">ladmin</Data>
<Data Name="AccountDomain">CONTOSO</Data>
<Data Name="LogonID">0x1e01f6</Data>
<Data Name="SessionName">RDP-Tcp\#3</Data>
<Data Name="ClientName">WIN81</Data>
<Data Name="ClientAddress">10.0.0.100</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Account Name [Type = UnicodeString]: the name of the account for which the session was disconnected.
the following:
Session:
Session Name [Type = UnicodeString]: the name of disconnected session. Examples:
RDP-Rcp#N, where N is a number of session typical RDP session name.
Console console session, typical for Fast User Switching.
31C5CE94259D4006A9E4#3 example of Hyper-V Enhanced Session session name.
You can see the list of current sessions using query session command in command prompt.
Example of output (see SESSIONNAME column):
Client Name [Type = UnicodeString]: machine name from which the session was disconnected. Has
Unknown value for console session.
Client Address [Type = UnicodeString]: IP address of the computer from which the session was
disconnected.
Has LOCAL value for console session.

For 4779(S): A session was disconnected from a Window Station.
High-value accounts: You might have high-value domain or Monitor this event with the Subject\Account Name that
requirements for detecting anomalies or monitoring potential Subject\Account Name (with other information) to
malicious actions. For example, you might need to monitor for monitor how or when a particular account is being used.
Non-active accounts: You might have non-active, disabled, Monitor this event with the Subject\Account Name that
used.
accounts that are the only ones allowed to perform actions the Subject\Account Name for accounts that are outside
corresponding to particular events. the whitelist.
certain actions are performed only by certain account types, certain account types, review the Subject\Account Name
for example, local or domain account, machine or user to see whether the account type is as expected.
events).
certain computers, machines, or devices on which certain actions performed by the Subject\Account Name that you
people (accounts) should not typically perform any actions. are concerned about.
For example, you might have computers to which connections If you have a target Computer: (or other target device) to
should not be made from certain accounts or addresses. which connections should not be made from certain accounts
or addresses, monitor this event for the corresponding Client
Name or Client Address.
If Fast User Switching is disabled on workstations or specific computers, then monitor for any event with
Session Name = Console.
If Remote Desktop Connections are not allowed for specific users (Subject\Account Name) or disabled on
some computers, then monitor for Session Name = RDP-Tcp# (substring).
To ensure that connections are made only from your internal IP address list, monitor the Additional
Information\Client Address in this event.
4800(S): The workstation was locked.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event is generated when a workstation
was locked.

Event XML:
- <System>
<Level>0</Level>
<Task>12551</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SessionId">3</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the lock workstation operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the lock workstation
operation.
the following:
Session ID [Type = UInt32]: unique ID of locked session. You can see the list of current session IDs using
query session command in command prompt. Example of output (see ID column):

For 4800(S): The workstation was locked.
Typically this is an informational event, and can give you information about when a machine was locked, and
which account was used to lock it.
4801(S): The workstation was unlocked.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event is generated when workstation was
unlocked.

Event XML:
- <System>
<Level>0</Level>
<Task>12551</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the unlock workstation operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the unlock workstation
operation.
the following:
Session ID [Type = UInt32]: unique ID of unlocked session. You can see the list of current session IDs using
query session command in command prompt. Example of output (see ID column):

For 4801(S): The workstation was unlocked.
Typically this is an informational event, and can give you information about when a machine was unlocked, and
which account was used to unlock it.
4802(S): The screen saver was invoked.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event is generated when screen saver was
invoked.

Event XML:
- <System>
<Level>0</Level>
<Task>12551</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the invoke screensaver operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the invoke screensaver
operation.
the following:
Session ID [Type = UInt32]: unique ID of a session for which screen saver was invoked. You can see the list
of current session IDs using query session command in command prompt. Example of output (see ID
column):

For 4802(S): The screen saver was invoked.
Typically this is an informational event, and can give you information about when a screen saver was invoked on
a machine, and which account invoked it.
4803(S): The screen saver was dismissed.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event is generated when screen saver was
dismissed.

Event XML:
- <System>
<Level>0</Level>
<Task>12551</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the dismiss screensaver operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the dismiss screensaver
operation.
the following:
Session ID [Type = UInt32]: unique ID of a session for which screen saver was dismissed. You can see the
list of current session IDs using query session command in command prompt. Example of output (see ID
column):

For 4803(S): The screen saver was dismissed.
Typically this is an informational event, and can give you information about when a screen saver was dismissed
on a machine, and which account dismissed it.
5378(F): The requested credentials delegation was
disallowed by policy.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates requested CredSSP
credentials delegation was disallowed by
CredSSP delegation policy.
It typically occurs when CredSSP delegation for
WinRM double-hop session was not set
properly.

Event XML:
- <System>
<Level>0</Level>
<Task>12551</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectLogonId">0x2b1e04</Data>
<Data Name="Package">CREDSSP</Data>
<Data Name="UserUPN">dadmin@contoso</Data>
<Data Name="TargetServer">WSMAN/dc01.contoso.local</Data>
<Data Name="CredType">%%8098</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested credentials delegation. Event Viewer automatically tries
event.
Account Name [Type = UnicodeString]: the name of the account that requested credentials delegation.
the following:
Credential Delegation Information:
Security Package [Type = UnicodeString]: the name of Security Package which was used. Always CREDSSP
for this event.
User's UPN [Type = UnicodeString]: UPN of the account for which delegation was requested.
Target Server [Type = UnicodeString]: SPN of the target service for which delegation was requested.
Credential Type [Type = UnicodeString]: types of credentials which were presented for delegation:
CREDENTIALS TYPE DESCRIPTION
Default credentials The credentials obtained when the user first logs on to
Windows.
Fresh credentials The credentials that the user is prompted for when executing
an application.
Saved credentials The credentials that are saved using Credential Manager.

For 5378(F): The requested credentials delegation was disallowed by policy.
If you have defined CredSSP delegation policy, then this event will show you policy violations. We
recommend collecting these events and investigating every policy violation.
This event also can be used for CredSSP delegation troubleshooting.
5632(S, F): A request was made to authenticate to a
wireless network.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates when 802.1x authentication
attempt was made for wireless network.
It typically generates when network adapter
connects to new wireless network.

Event XML:
- <System>
<Level>0</Level>
<Task>12551</Task>
<Opcode>0</Opcode>
<Correlation />
<Computer>XXXXXXX.redmond.corp.microsoft.com</Computer>
<Security />
</System>
- <EventData>
<Data Name="SSID">Nokia</Data>
<Data Name="Identity">host/XXXXXXXX.redmond.corp.microsoft.com</Data>
<Data Name="PeerMac">18:64:72:F3:33:91</Data>
<Data Name="LocalMac">02:1A:C5:14:59:C9</Data>
<Data Name="IntfGuid">{2BB33827-6BB6-48DB-8DE6-DB9E0B9F9C9B}</Data>
<Data Name="ReasonCode">0x0</Data>
<Data Name="ReasonText">The operation was successful.</Data>
<Data Name="ErrorCode">0x0</Data>
<Data Name="EAPReasonCode">0x0</Data>
<Data Name="EapRootCauseString" />
<Data Name="EAPErrorCode">0x0</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = UnicodeString]: User Principal Name (UPN) or another type of account identifier for which
802.1x authentication request was made.
Note User principal name (UPN) format is used to specify an Internet-style name, such as
UserName@Example.Microsoft.com.
Account Name [Type = UnicodeString]: the name of the account for which 802.1x authentication request
was made.
the following:
Name (SSID) [Type = UnicodeString]: SSID of the wireless network to which authentication request was sent.
Note A service set identifier (SSID) is a sequence of characters that uniquely names a wireless local area
network (WLAN). An SSID is sometimes referred to as a "network name." This name allows stations to connect
to the desired network when multiple independent networks operate in the same physical area.
Interface GUID [Type = GUID]: GUID of the network interface which was used for authentication request.
You can see interfaces GUID using the following commands:

netsh lan show interfaces for wired interfaces.
netsh wlan show interfaces for wireless interfaces.
Local MAC Address [Type = UnicodeString]: local interfaces MAC-address.

Peer MAC Address [Type = UnicodeString]: peers (typically access point) MAC-address.
Reason Code [Type = UnicodeString]: contains Reason Text (explanation of Reason Code) and Reason Code
for wireless authentication results. See more information about reason codes for wireless authentication
here: https://msdn.microsoft.com/en-us/library/windows/desktop/dd877212(v=vs.85).aspx,
https://technet.microsoft.com/en-us/library/cc727747(v=ws.10).aspx.
Error Code [Type = HexInt32]: there is no information about this field in this document.
EAP Reason Code [Type = HexInt32]: there is no information about this field in this document. See
additional information here: https://technet.microsoft.com/en-us/library/dd197570(v=ws.10).aspx.
EAP Root Cause String [Type = UnicodeString]: there is no information about this field in this document.
EAP Error Code [Type = HexInt32]: there is no information about this field in this document.

For 5632(S, F): A request was made to authenticate to a wireless network.
5633(S, F): A request was made to authenticate to a
wired network.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Other
Logon/Logoff Events
Event Description:
This event generates when 802.1x
authentication attempt was made
for wired network.
It typically generates when network
adapter connects to new wired
network.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>12551</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="InterfaceName">Microsoft Hyper-V Network Adapter</Data>
<Data Name="Identity">-</Data>
<Data Name="ReasonCode">0x70003</Data>
<Data Name="ReasonText">The network does not support authentication</Data>
<Data Name="ErrorCode">0x0</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = UnicodeString]: User Principal Name (UPN) of account for which 802.1x authentication
request was made.
Note User principal name (UPN) format is used to specify an Internet-style name, such as
UserName@Example.Microsoft.com.
Account Name [Type = UnicodeString]: the name of the account for which 802.1x authentication request
was made.
the following:
Interface:
Name [Type = UnicodeString]: the name (description) of network interface which was used for authentication
request. You can get the list of all available network adapters using ipconfig /all command. See Description
row for every network adapter:
Reason Code [Type = UnicodeString]: contains Reason Text (explanation of Reason Code) and Reason Code
for wired authentication results. See more information about reason codes for wired authentication here:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd877212(v=vs.85).aspx,
https://technet.microsoft.com/en-us/library/cc727747(v=ws.10).aspx.
Error Code [Type = HexInt32]: unique EAP error code.

For 5633(S, F): A request was made to authenticate to a wired network.
Audit Special Logon
Applies to
Windows 10
Windows Server 2016
Audit Special Logon determines whether the operating system generates audit events under special sign on (or log
on) circumstances.
This subcategory allows you to audit events generated by special logons such as the following:
The use of a special logon, which is a logon that has administrator-equivalent privileges and can be used to
elevate a process to a higher level.
A logon by a member of a Special Group. Special Groups enable you to audit events generated when a
member of a certain group has logged on to your network. You can configure a list of group security
identifiers (SIDs) in the registry. If any of those SIDs are added to a token during logon and the subcategory
is enabled, an event is logged.
Event volume:
Medium on a domain controllers or network servers.
STRONGER STRONGER
Domain Yes No Yes No This subcategory

Controller is very important
because of
Special Groups
related events,
you must enable
this subcategory
for Success audit
if you use this
feature.
At the same time
this subcategory
allows you to
track account
logon sessions to
which sensitive
privileges were
assigned.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Member Server Yes No Yes No This subcategory

is very important
because of
Special Groups
related events,
you must enable
this subcategory
for Success audit
if you use this
feature.
At the same time
this subcategory
allows you to
track account
logon sessions to
which sensitive
privileges were
assigned.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Workstation Yes No Yes No This subcategory

is very important
because of
Special Groups
related events,
you must enable
this subcategory
for Success audit
if you use this
feature.
At the same time
this subcategory
allows you to
track account
logon sessions to
which sensitive
privileges were
assigned.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Events List:
4964(S): Special groups have been assigned to a new logon.
4672(S): Special privileges assigned to new logon.
4964(S): Special groups have been assigned to a new
logon.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Special Logon
Event Description:
This event occurs when an account that is a
member of any defined Special Group logs in.

event.
Event XML:
- <System>
<Level>0</Level>
<Task>12548</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectLogonId">0xd972e</Data>
<Data Name="TargetUserName">ladmin</Data>
<Data Name="TargetLogonId">0x139faf</Data>
<Data Name="TargetLogonGuid">{B03B6192-09AE-E77F-DD10-2DC430766040}</Data>
<Data Name="SidList">%{S-1-5-21-3457937927-2839227994-823803824-512}</Data>
</EventData>
</Event>

Event Versions: 0.
Note Special Groups is a new feature in Windows Vista and in Windows Server 2008. The Special Groups
feature lets the administrator find out when a member of a certain group logs on to the computer. The Special
Groups feature lets an administrator set a list of group security identifiers (SIDs) in the registry.
> To add Special Groups perform the following actions:

> 1. Open Registry Editor.
> 2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Audit
> 3. On the Edit menu, point to New, and then click String Value.
> 4. Type SpecialGroups, and then press ENTER.
> 5. Right-click SpecialGroups, and then click Modify.
> 6. In the Value date box, type the group SIDs, and then click OK.
> A semicolon character (;) can be used to delimit the SID list. For example, you can use the following string that
contains a semicolon to delimit two SIDs:
> S-1-5-32-544;S-1-5-32-123-54-65
> For more information see: http://blogs.technet.com/b/askds/archive/2008/03/11/special-groups-auditing-via-
group-policy-preferences.aspx
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested logon for New Logon account. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested logon for New Logon
account.
the following:
controller.
that can contain the same Logon GUID, 4648(S): A logon was attempted using explicit credentials and
0000-000000000000}.
New Logon:
Security ID [Type = SID]: SID of account that performed the logon. Event Viewer automatically tries to
event.
Account Name [Type = UnicodeString]: the name of the account that performed the logon.
the following:
controller.
that can contain the same Logon GUID, 4648(S): A logon was attempted using explicit credentials and
0000-000000000000}.
Special Groups Assigned [Type = UnicodeString]: the list of special group SIDs, which New
Logon\Security ID is a member of.

For 4964(S): Special groups have been assigned to a new logon.
Generally speaking, every 4964 event should be monitored, because the purpose of Special Groups is to define
a list of critical or important groups (Domain Admins, Enterprise Admins, service account groups, and so on)
and trigger an event every time a member of these groups logs on to a computer. For example, you can
monitor for every Domain Administrators logon to a non-administrative workstation.
4672(S): Special privileges assigned to new logon.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Special Logon
Event Description:
This event generates for new account logons
if any of the following sensitive privileges are
assigned to the new logon session:
SeTcbPrivilege - Act as part of the
operating system
SeBackupPrivilege - Back up files and
directories
SeCreateTokenPrivilege - Create a token
object
SeDebugPrivilege - Debug programs
SeEnableDelegationPrivilege - Enable
computer and user accounts to be trusted
for delegation
SeAuditPrivilege - Generate security audits
SeImpersonatePrivilege - Impersonate a client after authentication
SeLoadDriverPrivilege - Load and unload device drivers
SeSecurityPrivilege - Manage auditing and security log
SeSystemEnvironmentPrivilege - Modify firmware environment values
SeAssignPrimaryTokenPrivilege - Replace a process-level token
SeRestorePrivilege - Restore files and directories,
SeTakeOwnershipPrivilege - Take ownership of files or other objects
You typically will see many of these events in the event log, because every logon of SYSTEM (Local System)
account triggers this event.
Event XML:
- <System>
<Level>0</Level>
<Task>12548</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="PrivilegeList">SeTcbPrivilege SeSecurityPrivilege SeTakeOwnershipPrivilege SeLoadDriverPrivilege
SeBackupPrivilege SeRestorePrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeEnableDelegationPrivilege
SeImpersonatePrivilege</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account to which special privileges were assigned. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: the name of the account to which special privileges were
assigned.
the following:
Privileges [Type = UnicodeString]: the list of sensitive privileges, assigned to the new logon. The following table
contains the list of possible privileges for this event:
SeAssignPrimaryTokenPrivilege Replace a process-level token Required to assign the primary token

of a process.

operations.
request other than read is still
evaluated with the ACL. The following
access rights are granted if this privilege
is held:
READ_CONTROL
FILE_GENERIC_READ
FILE_TRAVERSE

creation APIs.

account.
With this privilege, the user can attach
a debugger to any process or to the
components.
driver.

held:
WRITE_DAC
WRITE_OWNER
FILE_GENERIC_WRITE
FILE_ADD_FILE
DELETE
an object.

security event log.
SeSystemEnvironmentPrivilege Modify firmware environment values Required to modify the nonvolatile

RAM of systems that use this type of
information.
value to be set only to those values
that the holder may legitimately assign
as the owner of an object.
ownership of any securable object in
the system, including Active Directory

For 4672(S): Special privileges assigned to new logon.
Monitor for this event where Subject\Security ID is not one of these well-known security principals:
LOCAL SYSTEM, NETWORK SERVICE, LOCAL SERVICE, and where Subject\Security ID is not an
administrative account that is expected to have the listed Privileges.
If you have a list of specific privileges which should never be granted, or granted only to a few accounts (for
example, SeDebugPrivilege), use this event to monitor for those Privileges.
If you are required to monitor any of the sensitive privileges in the Event Description for this event, search for
those specific privileges in the event.
Audit Application Generated
Applies to
Windows 10
Windows Server 2016
Audit Application Generated generates events for actions related to Authorization Manager applications.
Audit Application Generated subcategory is out of scope of this document, because Authorization Manager is very
rarely in use and it is deprecated starting from Windows Server 2012.
STRONGER STRONGER
Domain IF IF IF IF IF if you use

Controller Authorization
Manager in your
environment and
you need to
monitor events
related to
Authorization
Manager
applications,
enable this
subcategory.
Member Server IF IF IF IF IF if you use

Authorization
Manager in your
environment and
you need to
monitor events
related to
Authorization
Manager
applications,
enable this
subcategory.
Workstation IF IF IF IF IF if you use

Authorization
Manager in your
environment and
you need to
monitor events
related to
Authorization
Manager
applications,
enable this
subcategory.
Events List:
4665: An attempt was made to create an application client context.
4666: An application attempted an operation.
4667: An application client context was deleted.
4668: An application was initialized.
Audit Certification Services
Applies to
Windows 10
Windows Server 2016
Audit Certification Services determines whether the operating system generates events when Active Directory
Certificate Services (AD CS) operations are performed.
Examples of AD CS operations include:
AD CS starts, shuts down, is backed up, or is restored.
Certificate revocation list (CRL)-related tasks are performed.
Certificates are requested, issued, or revoked.
Certificate manager settings for AD CS are changed.
The configuration and properties of the certification authority (CA) are changed.
AD CS templates are modified.
Certificates are imported.
A CA certificate is published to Active Directory Domain Services.
Security permissions for AD CS role services are modified.
Keys are archived, imported, or retrieved.
The OCSP Responder Service is started or stopped.
Monitoring these operational events is important to ensure that AD CS role services are functioning properly.
Event volume: Low to medium on servers that provide AD CS role services.
Role-specific subcategories are outside the scope of this document.
STRONGER STRONGER
Domain IF IF IF IF IF if a server
Controller has the Active
Directory
Certificate
Services (AD CS)
role installed and
you need to
monitor AD CS
related events,
enable this
subcategory.
STRONGER STRONGER
Member Server IF IF IF IF IF if a server

has the Active
Directory
Certificate
Services (AD CS)
role installed and
you need to
monitor AD CS
related events,
enable this
subcategory.
Workstation No No No No Active Directory

Certificate
Services (AD CS)
role cannot be
installed on client
OS.
4868: The certificate manager denied a pending certificate request.

4869: Certificate Services received a resubmitted certificate request.
4870: Certificate Services revoked a certificate.
4871: Certificate Services received a request to publish the certificate
revocation list (CRL).
4872: Certificate Services published the certificate revocation list (CRL).
4873: A certificate request extension changed.
4874: One or more certificate request attributes changed.
4875: Certificate Services received a request to shut down.
4876: Certificate Services backup started.
4877: Certificate Services backup completed.
4878: Certificate Services restore started.
4879: Certificate Services restore completed.
4880: Certificate Services started.
4881: Certificate Services stopped.
4882: The security permissions for Certificate Services changed.
4883: Certificate Services retrieved an archived key.
4884: Certificate Services imported a certificate into its database.
4885: The audit filter for Certificate Services changed.
4886: Certificate Services received a certificate request.
4887: Certificate Services approved a certificate request and issued a
certificate.
4888: Certificate Services denied a certificate request.
4889: Certificate Services set the status of a certificate request to
pending.
4890: The certificate manager settings for Certificate Services changed.
4891: A configuration entry changed in Certificate Services.
4892: A property of Certificate Services changed.
4893: Certificate Services archived a key.
4894: Certificate Services imported and archived a key.
4895: Certificate Services published the CA certificate to Active
Directory Domain Services.
4896: One or more rows have been deleted from the certificate
database.
4897: Role separation enabled.
4898: Certificate Services loaded a template.
Audit Detailed File Share
Applies to
Windows 10
Windows Server 2016
Audit Detailed File Share allows you to audit attempts to access files and folders on a shared folder.
The Detailed File Share setting logs an event every time a file or folder is accessed, whereas the File Share setting
only records one event for any connection established between a client and file share. Detailed File Share audit
events include detailed information about the permissions or other criteria used to grant or deny access.
There are no system access control lists (SACLs) for shared folders. If this policy setting is enabled, access to all
shared files and folders on the system is audited.
Event volume:
High on file servers.
High on domain controllers because of SYSVOL network access required by Group Policy.
STRONGER STRONGER
Domain No Yes No Yes Audit Success for

Controller this subcategory
on domain
controllers
typically will lead
to very high
volume of events,
especially for
SYSVOL share.
We recommend
monitoring
Failure access
attempts: the
volume should
not be very high.
You will be able
to see who was
not able to get
access to a file or
folder on a
network share on
a computer.
STRONGER STRONGER
Member Server IF Yes IF Yes IF If a server

has shared
network folders
which typically
get many access
requests (File
Server, for
example), the
volume of events
might be very
high. If you really
need to track all
successful access
events for every
file or folder
located on a
shared folder,
enable Success
auditing or use
the Audit File
System
subcategory,
although that
subcategory
excludes some
information in
Audit Detailed
File Share, for
example, the
clients IP
address.
The volume of
Failure events for
member servers
should not be
very high (if they
are not File
Servers). With
Failure auditing,
you will be able
to see who was
not able to get
access to a file or
folder on a
network share on
this computer.
STRONGER STRONGER
Workstation IF Yes IF Yes IF If a

workstation has
shared network
folders which
typically get
many access
requests, the
volume of events
might be very
high. If you really
need to track all
successful access
events for every
file or folder
located on a
shared folder,
enable Success
auditing or use
Audit File System
subcategory,
although that
subcategory
excludes some
information in
Audit Detailed
File Share, for
example, the
clients IP
address.
The volume of
Failure events for
workstations
should not be
very high. With
Failure auditing,
you will be able
to see who was
not able to get
access to a file or
folder on a
network share on
this computer.
Events List:
5145(S, F): A network share object was checked to see whether client can be granted desired access.
5145(S, F): A network share object was checked to see
whether client can be granted desired access.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit
Detailed File Share
Event Description:
time network share object
(file or folder) was
accessed.
Important: Failure events
are generated only when
access is denied at the file
share level. No events are
generated if access was
denied on the file system
(NTFS) level.
Note For
Security Monitoring
Recommendations for
this event.
Event XML:
- <System>
<Level>0</Level>
<Task>12811</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectLogonId">0x38d34</Data>
<Data Name="ObjectType">File</Data>
<Data Name="IpAddress">fe80::31ea:6c3c:f40d:1973</Data>
<Data Name="ShareName">\\\\\*\\Documents</Data>
<Data Name="ShareLocalPath">\\??\\C:\\Documents</Data>
<Data Name="RelativeTargetName">Bginfo.exe</Data>
<Data Name="AccessList">%%1541 %%4416 %%4423</Data>
<Data Name="AccessReason">%%1541: %%1801 D:(A;;FA;;;WD) %%4416: %%1801 D:(A;;FA;;;WD) %%4423: %%1801 D:
(A;;FA;;;WD)</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested access to network share object. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested access to network share
object.
the following:
Object Type [Type = UnicodeString]: The type of an object that was accessed during the operation. Always
File for this event.
The following table contains the list of the most common Object Types:
DIRECTORY EVENT TIMER DEVICE
Mutant Type File Token
Thread Section WindowStation DebugObject
FilterCommunicationPort EventPair Driver IoCompletion
Controller SymbolicLink WmiGuid Process
Profile Desktop KeyedEvent Adapter
Key WaitablePort Callback Semaphore
Job Port FilterConnectionPort ALPC Port
Source Address [Type = UnicodeString]: source IP address from which access was performed.
Source Port [Type = UnicodeString]: source TCP or UDP port which was used from remote or local machine
to request the access.
0 for local access attempts.
Share Information:
Share Name [Type = UnicodeString]: the name of accessed network share. The format is: \\*\SHARE_NAME.
Share Path [Type = UnicodeString]: the full system (NTFS) path for accessed share. The format is: \\??
\PATH. Can be empty, for example for Share Name: \\*\IPC$.
Relative Target Name [Type = UnicodeString]: relative name of the accessed target file or folder. This file-
path is relative to the network share. If access was requested for the share itself, then this field appears as \.
Access Mask [Type = HexInt32]: the sum of hexadecimal values of requested access rights. See Table 13.
File access codes. for different hexadecimal values for access rights.
These access rights depend on Object Type.
Table of file access codes

HEX VALUE,
ACCESS SCHEMA VALUE DESCRIPTION
ReadData (or ListDirectory) 0x1, ReadData - For a file object, the right
%%4416 to read the corresponding file data. For
a directory object, the right to read the
corresponding directory data.
ListDirectory - For a directory, the
right to list the contents of the
directory.
WriteData (or AddFile) 0x2, WriteData - For a file object, the right
%%4417 to write data to the file. For a directory
object, the right to create a file in the
directory (FILE_ADD_FILE).
AddFile - For a directory, the right to
create a file in the directory.
AppendData (or AddSubdirectory or 0x4, AppendData - For a file object, the

CreatePipeInstance) %%4418 right to append data to the file. (For
local files, write operations will not
overwrite existing data if this flag is
specified without FILE_WRITE_DATA.)
For a directory object, the right to
create a subdirectory
(FILE_ADD_SUBDIRECTORY).
AddSubdirectory - For a directory, the
right to create a subdirectory.
CreatePipeInstance - For a named
pipe, the right to create a pipe.
ReadEA 0x8, The right to read extended file

%%4419 attributes.
WriteEA 0x10, The right to write extended file

%%4420 attributes.
Execute/Traverse 0x20, Execute - For a native code file, the

%%4421 right to execute the file. This access
right given to scripts may cause the
script to be executable, depending on
the script interpreter.
Traverse - For a directory, the right to
traverse the directory. By default, users
are assigned the
BYPASS_TRAVERSE_CHECKING
privilege, which ignores the
FILE_TRAVERSE access right. See the
remarks in File Security and Access
Rights for more information.
HEX VALUE,
DeleteChild 0x40, For a directory, the right to delete a

%%4422 directory and all the files it contains,
including read-only files.
ReadAttributes 0x80, The right to read file attributes.

%%4423
WriteAttributes 0x100, The right to write file attributes.

%%4424
DELETE 0x10000, The right to delete the object.

%%1537
READ_CONTROL 0x20000, The right to read the information in the

%%1538 object's security descriptor, not
including the information in the system
access control list (SACL).
WRITE_DAC 0x40000, The right to modify the discretionary

%%1539 access control list (DACL) in the object's
WRITE_OWNER 0x80000, The right to change the owner in the

%%1540 object's security descriptor
SYNCHRONIZE 0x100000, The right to use the object for

%%1541 synchronization. This enables a thread
state. Some object types do not support
this access right.
ACCESS_SYS_SEC 0x1000000, The ACCESS_SYS_SEC access right

%%1542 controls the ability to get or set the
SACL in an object's security descriptor.
Table 13. File access codes.
Access Check Results [Type = UnicodeString]: the list of access check results. The format of the result is:
REQUESTED_ACCESS: RESULT ACE_WHICH_ ALLOWED_OR_DENIED_ACCESS.

REQUESTED_ACCESS the name of requested access. See Table of file access codes, earlier in this topic.
RESULT:
Granted by if access was granted.
Denied by if access was denied.
ACE_WHICH_ ALLOWED_OR_DENIED_ACCESS: the Security Descriptor Definition Language (SDDL) value for
Access Control Entry (ACE), which granted or denied access.
Note The ** Security Descriptor Definition Language (SDDL)** defines string elements for enumerating
information contained in the security descriptor.
Example:
O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)
(A;;07;;;BA)S:ARAI(AU;SAFA;DCLCRPCRSDWDWO;;;WD)
O: = Owner. SID of specific security principal, or reserved (pre-defined) value, for example: BA
(BUILTIN_ADMINISTRATORS), WD (Everyone), SY (LOCAL_SYSTEM), etc. See the list of possible values in the
table below.
SDDL values for Access Control Entry

VALUE DESCRIPTION VALUE DESCRIPTION
"AO" Account operators "PA" Group Policy administrators
"RU" Alias to allow previous "IU" Interactively logged-on user

Windows 2000
"AN" Anonymous logon "LA" Local administrator
"AU" Authenticated users "LG" Local guest
"BA" Built-in administrators "LS" Local service account
"BG" Built-in guests "SY" Local system
"BO" Backup operators "NU" Network logon user
"BU" Built-in users "NO" Network configuration

operators
"CA" Certificate server "NS" Network service account

administrators
"CG" Creator group "PO" Printer operators
"CO" Creator owner "PS" Personal self
"DA" Domain administrators "PU" Power users
"DC" Domain computers "RS" RAS servers group
"DD" Domain controllers "RD" Terminal server users
"DG" Domain guests "RE" Replicator
"DU" Domain users "RC" Restricted code
"EA" Enterprise administrators "SA" Schema administrators
"ED" Enterprise domain "SO" Server operators

controllers
"WD" Everyone "SU" Service logon user
G: = Primary Group.
D: = DACL Entries.
S: = SACL Entries.
DACL/SACL entry format:
entry_type:inheritance_flags(ace_type;ace_flags;rights;object_guid;inherit_object_guid;account_sid)
Example: D:(A;;FA;;;WD)
entry_type:
D - DACL
S - SACL
inheritance_flags:
"P - SDDL_PROTECTED, Inheritance from containers that are higher in the folder hierarchy are blocked.
"AI" - SDDL_AUTO_INHERITED, Inheritance is allowed, assuming that "P" Is not also set.
"AR" - SDDL_AUTO_INHERIT_REQ, Child objects inherit permissions from this object.
ace_type:
"A" - ACCESS ALLOWED
"D" - ACCESS DENIED
"OA" - OBJECT ACCESS ALLOWED: only applies to a subset of the object(s).
"OD" - OBJECT ACCESS DENIED: only applies to a subset of the object(s).
"AU" - SYSTEM AUDIT
"A" - SYSTEM ALARM
"OU" - OBJECT SYSTEM AUDIT
"OL" - OBJECT SYSTEM ALARM
ace_flags:
"CI" - CONTAINER INHERIT: Child objects that are containers, such as directories, inherit the ACE as an explicit ACE.
"OI" - OBJECT INHERIT: Child objects that are not containers inherit the ACE as an explicit ACE.
"NP" - NO PROPAGATE: only immediate children inherit this ace.
"IO" - INHERITANCE ONLY: ace doesnt apply to this object, but may affect children via inheritance.
"ID" - ACE IS INHERITED
"SA" - SUCCESSFUL ACCESS AUDIT
"FA" - FAILED ACCESS AUDIT
rights: A hexadecimal string which denotes the access mask or reserved value, for example: FA (File All Access),
FX (File Execute), FW (File Write), etc.
Generic access rights Directory service access

rights
"GA" GENERIC ALL "RC" Read Permissions
"GR" GENERIC READ "SD" Delete
"GW" GENERIC WRITE "WD" Modify Permissions
"GX" GENERIC EXECUTE "WO" Modify Owner
File access rights "RP" Read All Properties
"FA" FILE ALL ACCESS "WP" Write All Properties
"FR" FILE GENERIC READ "CC" Create All Child Objects
"FW" FILE GENERIC WRITE "DC" Delete All Child Objects
"FX" FILE GENERIC EXECUTE "LC" List Contents
Registry key access rights "SW" All Validated Writes
"KA" "LO" "LO" List Object
"K" KEY READ "DT" Delete Subtree
"KW" KEY WRITE "CR" All Extended Rights
"KX" KEY EXECUTE
object_guid: N/A
inherit_object_guid: N/A
account_sid: SID of specific security principal, or reserved value, for example: AN (Anonymous), WD (Everyone),
SY (LOCAL_SYSTEM), etc. See the table above for more details.
For more information about SDDL syntax, see these articles: https://msdn.microsoft.com/en-
us/library/cc230374.aspx, https://msdn.microsoft.com/en-us/library/windows/hardware/aa374892(v=vs.85).aspx.

For 5145(S, F): A network share object was checked to see whether client can be granted desired access.
Monitor this event if the Network Information\Source Address is not from your internal IP range.
Monitor this event if the Network Information\Source Address should not be able to connect with the
specific computer (Computer:).
If you have critical files or folders on specific network shares, for which you need to monitor access attempts
(Success and Failure), monitor for specific Share Information\Share Name and Share
Information\Relative Target Name.
If you have domain or local accounts that should only be able to access a specific list of shared files or
folders, you can monitor for access attempts outside the allowed list.
We recommend that you monitor for these Access Request Information\Accesses rights (especially for
Failure):
WriteData (or AddFile)
AppendData (or AddSubdirectory or CreatePipeInstance)
WriteEA
DeleteChild
WriteAttributes
DELETE
WRITE_DAC
WRITE_OWNER
Audit File Share
Applies to
Windows 10
Windows Server 2016
Audit File Share allows you to audit events related to file shares: creation, deletion, modification, and access
attempts. Also, it shows failed SMB SPN checks.
There are no system access control lists (SACLs) for shares; therefore, after this setting is enabled, access to all
shares on the system will be audited.
Combined with File System auditing, File Share auditing enables you to track what content was accessed, the
source (IP address and port) of the request, and the user account that was used for the access.
Event volume:
High on file servers.
High on domain controllers because of SYSVOL network access required by Group Policy.
STRONGER STRONGER

for domain
controllers,
because its
important to
track deletion,
creation, and
modification
events for
network shares.
We recommend
Failure auditing
to track failed
SMB SPN checks
and failed access
attempts to
network shares.
STRONGER STRONGER

Success auditing
to track deletion,
creation,
modification, and
access attempts
to network share
objects.
We recommend
Failure auditing
to track failed
SMB SPN checks
and failed access
attempts to
network shares.

Success auditing
to track deletion,
creation,
modification and
access attempts
to network share
objects.
We recommend
Failure auditing
to track failed
SMB SPN checks
and failed access
attempts to
network shares.
Events List:
5140(S, F): A network share object was accessed.
5142(S): A network share object was added.
5143(S): A network share object was modified.
5144(S): A network share object was deleted.
5168(F): SPN check for SMB/SMB2 failed.
5140(S, F): A network share object was accessed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit File Share
Event Description:
This event generates every time network share
object was accessed.
This event generates once per session, when
first access attempt was made.

Event XML:
- <System>
<Level>0</Level>
<Task>12808</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ShareLocalPath">\\??\\C:\\Documents</Data>
</EventData>
</Event>

Event Versions:
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested access to network share object. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested access to network share
object.
the following:
Source Address [Type = UnicodeString]: source IP address from which access was performed.
Source Port [Type = UnicodeString]: source TCP or UDP port which was used from remote or local machine
to request the access.
0 for local access attempts.
Share Information:
Share Name [Type = UnicodeString]: the name of accessed network share. The format is: \\*\SHARE_NAME.
Share Path [Type = UnicodeString]: the full system (NTFS) path for accessed share. The format is: \\??
\PATH. Can be empty, for example for Share Name: \\*\IPC$.
Access Mask [Type = HexInt32]: the sum of hexadecimal values of requested access rights. See Table 13.
File access codes. for different hexadecimal values for access rights. Has always 0x1 value for this event.
These access rights depend on Object Type. Has always ReadData (or ListDirectory) value for this
event.

For 5140(S, F): A network share object was accessed.
If you have high-value computers for which you need to monitor all access to all shares or specific shares
(Share Name), monitor this event. For example, you could monitor share C$ on domain controllers.
Monitor this event if the Network Information\Source Address is not from your internal IP range.
Monitor this event if the Network Information\Source Address should not be able to connect with the
specific computer (Computer:).
If you need to monitor access attempts to local shares from a specific IP address (Network
Information\Source Address), use this event.
If you need to monitor for specific Access Types (for example, ReadData or WriteData), for all or specific
shares (Share Name), monitor this event for the Access Type.
5142(S): A network share object was added.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time network share
object was added.

Event XML:
- <System>
<Level>0</Level>
<Task>12808</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ShareLocalPath">C:\\Documents</Data>
</EventData>
</Event>

Minimum OS Version: Windows Server 2008 R2, Windows 7.
Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the add network share object operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the add network share
object operation.
the following:
Share Information:
Share Name [Type = UnicodeString]: the name of the added share object. The format is: \\*\SHARE_NAME.
Share Path [Type = UnicodeString]: the full system (NTFS) path for the added share object. The format is:
\\??\PATH.

For 5142(S): A network share object was added.
If you have high-value computers for which you need to monitor creation of new file shares, monitor this
event. For example, you could monitor domain controllers.
We recommend checking Share Path, because it should not point to system directories, such as
C:\Windows or C:\, or to critical local folders which contain private or high value information.
5143(S): A network share object was modified.
Applies to
Windows 10
Windows Server 2016

Event Description:
This event generates every time network share object was modified.
Event XML:
- <System>
<Level>0</Level>
<Task>12808</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectType">Directory</Data>
<Data Name="OldRemark">N/A</Data>
<Data Name="NewRemark">N/A</Data>
<Data Name="OldMaxUsers">0xffffffff</Data>
<Data Name="NewMaxUsers">0xffffffff</Data>
<Data Name="OldShareFlags">0x800</Data>
<Data Name="NewShareFlags">0x800</Data>
<Data Name="OldSD">O:S-1-5-21-3457937927-2839227994-823803824-1104G:DAD:(A;OICI;FA;;;BA)(A;OICI;FA;;;WD)
</Data>
<Data Name="NewSD">O:BAG:DAD:(D;;FA;;;S-1-5-21-3457937927-2839227994-823803824-1104)(A;OICI;FA;;;WD)
(A;OICI;FA;;;BA)</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the modify network share object operation. Event
Account Name [Type = UnicodeString]: the name of the account that requested the modify network share
object operation.
the following:
Share Information:
Object Type [Type = UnicodeString]: The type of an object that was modified. Always Directory for this
event.
Share Name [Type = UnicodeString]: the name of the modified share object. The format is:
\\*\SHARE_NAME
Share Path [Type = UnicodeString]: the full system (NTFS) path for the added share object. The format is:
\\??\PATH. Can be empty, for example for Share Name: \\*\IPC$.
Old Remark [Type = UnicodeString]: the old value of network share Comments: field. Has N/A value if
it is not set.
New Remark [Type = UnicodeString]: the new value of network share Comments: field. Has N/A value
if it is not set.
Old MaxUsers [Type = HexInt32]: old hexadecimal value of Limit the number of simultaneous user to:
field. Has 0xFFFFFFFF value if the number of connections is unlimited.
New Maxusers [Type = HexInt32]: new hexadecimal value of Limit the number of simultaneous user
to: field. Has 0xFFFFFFFF value if the number of connections is unlimited.
Old ShareFlags [Type = HexInt32]: old hexadecimal value of Offline Settings caching settings window
flags.
New ShareFlags [Type = HexInt32]: new hexadecimal value of Offline Settings caching settings window
flags.
Old SD [Type = UnicodeString]: the old Security Descriptor Definition Language (SDDL) value for network
share security descriptor.
New SD [Type = UnicodeString]: the new Security Descriptor Definition Language (SDDL) value for network
share security descriptor.
Example:
table below:

Windows 2000

operators

administrators

controllers
G: = Primary Group.
D: = DACL Entries.
S: = SACL Entries.
entry_type:
D - DACL
S - SACL
inheritance_flags:
ace_type:
"D" - ACCESS DENIED
"AU" - SYSTEM AUDIT
"A" - SYSTEM ALARM
ace_flags:

rights
"KX" KEY EXECUTE
object_guid: N/A

For 5143(S): A network share object was modified.
If you have high-value computers for which you need to monitor all modifications to all shares or specific shares
(Share Name), monitor this event. For example, you could monitor all changes to the SYSVOL share on
domain controllers.
5144(S): A network share object was deleted.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time a network
share object is deleted.

Event XML:
- <System>
<Level>0</Level>
<Task>12808</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the delete network share object operation. Event
Account Name [Type = UnicodeString]: the name of the account that requested the delete network share
object operation.
the following:
Share Information:
Share Name [Type = UnicodeString]: the name of the deleted share object. The format is: \\*\SHARE_NAME
Share Path [Type = UnicodeString]: the full system (NTFS) path for the deleted share object. The format is:
\\??\PATH.

For 5144(S): A network share object was deleted.
If you have critical network shares for which you need to monitor all changes (especially, the deletion of that
share), monitor for specific Share Information\Share Name.
If you have high-value computers for which you need to monitor all changes (especially, deletion of file
shares), monitor for all 5144 events on these computers. For example, you could monitor file shares on
domain controllers.
5168(F): SPN check for SMB/SMB2 failed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit File
Share
Event Description:
This event generates when
SMB SPN check fails.
It often happens because of
NTLMv1 or LM protocols
usage from client side when
Microsoft Network Server:
Server SPN target name
validation level group policy
set to Require from client
on server side. SPN only sent
to server when NTLMv2 or
Kerberos protocols are used,
and after that SPN can be
validated.
Event XML:
- <System>
<Level>0</Level>
<Task>12808</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectLogonId">0xd0cd4</Data>
<Data Name="SpnName">N/A</Data>
<Data Name="ErrorCode">0xc0000022</Data>
<Data Name="ServerNames">CONTOSO;contoso.local;DC01.contoso.local;DC01;LocalHost;</Data>
<Data Name="ConfiguredNames">N/A</Data>
<Data Name="IpAddresses">127.0.0.1;::1;10.0.0.10;;fe80::31ea:6c3c:f40d:1973;;fe80::5efe:10.0.0.10;</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account for which SPN check operation was failed. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: the name of the account for which SPN check operation was failed.
the following:
SPN:
SPN Name [Type = UnicodeString]: SPN which was used to access the server. If SPN was not provided, then the
value will be N/A.
Error Code [Type = HexInt32]: hexadecimal error code, for example 0xC0000022 = STATUS_ACCESS_DENIED.
You can find description for all SMB error codes here: https://msdn.microsoft.com/en-us/library/ee441884.aspx.
Server Information:
Server Names [Type = UnicodeString]: information about possible server names to use to access the target
server (NETBIOS, DNS, localhost, etc.).
Configured Names [Type = UnicodeString]: information about the names which were provided for
validation. If no information was provided the value will be N/A.
IP Addresses [Type = UnicodeString]: information about possible IP addresses to use to access the target
server (IPv4, IPv6).

For 5168(F): SPN check for SMB/SMB2 failed.
We recommend monitoring for any 5168 event, because it can be a sign of a configuration issue or a malicious
authentication attempt.
Audit File System
Applies to
Windows 10
Windows Server 2016
Audit File System determines whether the operating system generates audit events when users attempt to
access file system objects.
Audit events are generated only for objects that have configured system access control lists (SACLs), and only
if the type of access requested (such as Write, Read, or Modify) and the account making the request match the
settings in the SACL.
If success auditing is enabled, an audit entry is generated each time any account successfully accesses a file
system object that has a matching SACL. If failure auditing is enabled, an audit entry is generated each time
any user unsuccessfully attempts to access a file system object that has a matching SACL.
These events are essential for tracking activity for file objects that are sensitive or valuable and require extra
monitoring.
Event volume: Varies, depending on how file system SACLs are configured.
No audit events are generated for the default file system SACLs.
This subcategory allows you to audit user attempts to access file system objects, file system object deletion and
permissions change operations and hard link creation actions.
Only one event, 4658: The handle to an object was closed, depends on the Audit Handle Manipulation
subcategory (Success auditing must be enabled). All other events generate without any additional
configuration.
GENERAL STRONGER STRONGER

COMPUTER TYPE SUCCESS GENERAL FAILURE SUCCESS FAILURE COMMENTS
Domain IF IF IF IF We strongly
Controller recommend that
you develop a
File System
Security
Monitoring
policy and define
appropriate
SACLs for file
system objects
for different
operating
system
templates and
roles. Do not
enable this
subcategory if
you have not
planned how to
use and analyze
the collected
information. It is
also important
to delete non-
effective, excess
SACLs.
Otherwise the
auditing log will
be overloaded
with useless
information.
Failure events
can show you
unsuccessful
attempts to
access specific
file system
objects.
Consider
enabling this
subcategory for
critical
computers first,
after you
develop a File
System Security
Monitoring
policy for them.
Member Server IF IF IF IF
Workstation IF IF IF IF
Events List:
4658(S): The handle to an object was closed.
4660(S): An object was deleted.
4663(S): An attempt was made to access an object.
4664(S): An attempt was made to create a hard link.
4985(S): The state of a transaction has changed.
5051(-): A file was virtualized.
4670(S): Permissions on an object were changed.
Applies to
Windows 10
Windows Server 2016
Subcategories: Audit File System, Audit Kernel Object, Audit Registry, and Audit Removable Storage
Event Description:
This event indicates that specific access was requested for an object. The object could be a file system, kernel, or
registry object, or a file system object on removable storage or a device.
If access was declined, a Failure event is generated.
This event generates only if the objects SACL has the required ACE to handle the use of specific access rights.
This event shows that access was requested, and the results of the request, but it doesnt show that the operation
was performed. To see that the operation was performed, check 4663(S): An attempt was made to access an
object.
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectServer">Security</Data>
<Data Name="ObjectName">C:\\Documents\\HBI Data.txt</Data>
<Data Name="AccessList">%%1538 %%1541 %%4416 %%4417 %%4418 %%4419 %%4420 %%4423 %%4424</Data>
<Data Name="AccessReason">%%1538: %%1804 %%1541: %%1809 %%4416: %%1809 %%4417: %%1809 %%4418: %%1802 D:
(D;;LC;;;S-1-5-21-3457937927-2839227994-823803824-1104) %%4419: %%1809 %%4420: %%1809 %%4423: %%1811 D:
(A;OICI;FA;;;S-1-5-21-3457937927-2839227994-823803824-1104) %%4424: %%1809</Data>
<Data Name="AccessMask">0x12019f</Data>
<Data Name="ResourceAttributes">S:AI(RA;ID;;;;WD;("Impact\_MS",TI,0x10020,3000))</Data>
</EventData>
</Event>

Event Versions:
Added Resource Attributes field.
Added Access Reasons field.
Field Descriptions:
Subject:
event.
the following:
Object:
Object Server [Type = UnicodeString]: has Security value for this event.
Object Type [Type = UnicodeString]: The type of an object that was accessed during the operation.

Object Name [Type = UnicodeString]: name and other identifying information for the object for which
access was requested. For example, for a file, the path would be included.
Handle ID [Type = Pointer]: hexadecimal value of a handle to Object Name. This field can help you
correlate this event with other events that might contain the same Handle ID, for example, 4663(S): An
attempt was made to access an object. This parameter might not be captured in the event, and in that case
appears as 0x0.
Resource Attributes [Type = UnicodeString] [Version 1]: attributes associated with the object. For some
objects, the field does not apply and - is displayed.
For example, for a file, the following might be displayed: S:AI(RA;ID;;;;WD;("Impact_MS",TI,0x10020,3000))
Impact_MS: Resource Property ID.
3000: Recourse Property Value.
Process ID [Type = Pointer]: hexadecimal Process ID of the process through which the access was requested.
with other events that might contain the same Transaction ID, such as 4660(S): An object was deleted.
0000-000000000000}.
Accesses [Type = UnicodeString]: the list of access rights which were requested by Subject\Security ID. These
access rights depend on Object Type. The following table contains information about the most common access
rights for file system objects. Access rights for registry objects are often similar to file system objects, but the
table contains a few notes about how they vary.
HEXADECIMAL VALUE,
(For registry objects, this is Query key a directory object, the right to read the
value.) corresponding directory data.
directory.
(For registry objects, this is Set key object, the right to create a file in the
value.) directory (FILE_ADD_FILE).
HEXADECIMAL VALUE,


(For registry objects, this is Enumerate %%4419 attributes.
sub-keys.)

%%4420 attributes.

%%4421 right to execute the file. This access right
given to scripts may cause the script to
be executable, depending on the script
interpreter.
are assigned the


%%4423

%%4424

%%1537


HEXADECIMAL VALUE,


this access right.

Table 14. File System objects access rights.
Access Reasons [Type = UnicodeString] [Version 1]: the list of access check results. The format of this varies,
depending on the object. For kernel objects, this field does not apply.
Access Mask [Type = HexInt32]: hexadecimal mask for the requested or performed operation. For more
information, see the preceding table.
Privileges Used for Access Check [Type = UnicodeString]: the list of user privileges which were used during
the operation, for example, SeBackupPrivilege. This parameter might not be captured in the event, and in that
case appears as -. See full list of user privileges in the table below:

a process.

operations.
held:
READ_CONTROL
FILE_GENERIC_READ
FILE_TRAVERSE




creation APIs.

account.
components.

a process.
interface.
to a process.
users.
driver.

memory.
computer account.
controllers.

defragmentation.

processes.

network request.

held:
WRITE_DAC
WRITE_OWNER
FILE_GENERIC_WRITE
FILE_ADD_FILE
DELETE
an object.

security event log.
synchronization.

processes.
clock.



a terminal device.
Object Types.

For kernel objects, this event and other auditing events have little to no security relevance and are hard to parse or
analyze. There is no recommendation for auditing them, unless you know exactly what you need to monitor at the
Kernel objects level.
For other types of objects, the following recommendations apply.
If Object Name is a sensitive or critical object for which you need to monitor any access attempt, monitor all
4656 events.
If Object Name is a sensitive or critical object for which you need to monitor specific access attempts (for
example, only write actions), monitor for all 4656 events with the corresponding Access Request
Information\Accesses values.
If you need to monitor files and folders with specific Resource Attribute values, monitor for all 4656 events
with specific Resource Attributes field values.
For file system objects, we recommend that you monitor these Access Request Information\Accesses
rights (especially for Failure events):
WriteEA
DeleteChild
WriteAttributes
DELETE
WRITE_DAC
WRITE_OWNER
Applies to
Windows 10
Windows Server 2016
Subcategories: Audit File System, Audit Handle
Manipulation, Audit Kernel Object, Audit
Registry, and Audit Removable Storage
Event Description:
This event generates when the handle to an
object is closed. The object could be a file
system, kernel, or registry object, or a file
system object on removable storage or a
device.
enabled for Audit Handle Manipulation
subcategory.
Typically this event is needed if you need to
know how long the handle to the object was
open. Otherwise, it might not have any security
relevance.
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="HandleId">0x18a8</Data>
<Data Name="ProcessId">0xef0</Data>
<Data Name="ProcessName">C:\\Windows\\explorer.exe</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the close objects handle operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the close objects handle
operation.
the following:
Object:
appears as 0x0.
Process ID [Type = Pointer]: hexadecimal Process ID of the process that requested that the handle be closed.

For 4658(S): The handle to an object was closed.
Typically this event has little to no security relevance and is hard to parse or analyze. There is no
recommendation for this event, unless you know exactly what you need to monitor with it.
This event can be used to track all actions or operations related to a specific object handle.
Applies to
Windows 10
Windows Server 2016
Subcategories: Audit File System, Audit Kernel
Object, and Audit Registry
Event Description:
This event generates when an object was
deleted. The object could be a file system,
kernel, or registry object.
This event generates only if Delete" auditing is
set in objects SACL.
This event doesnt contain the name of the
deleted object (only the Handle ID). It is better
to use 4663(S): An attempt was made to
access an object with DELETE access to track
object deletion.
The advantage of this event is that its
generated only during real delete operations. In
contrast, 4663(S): An attempt was made to
access an object also generates during other
actions, such as object renaming.
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
operation.
the following:
Object:
appears as 0x0.
Process ID [Type = Pointer]: hexadecimal Process ID of the process that deleted the object. Process ID (PID)
is a number used by the operating system to uniquely identify an active process. To see the PID for a specific
with other events that might contain the same Transaction ID, such as 4656(S, F): A handle to an object
was requested.
0000-000000000000}.
For 4660(S): An object was deleted.
This event doesnt contains the name of deleted object (only Handle ID). It is better to use 4663(S): An
attempt was made to access an object. events with DELETE access to track object deletion actions.
For kernel objects, this event and other auditing events have little to no security relevance and are hard to
parse or analyze. There is no recommendation for auditing them, unless you know exactly what you need to
monitor at the Kernel objects level.
Applies to
Windows 10
Windows Server 2016
Subcategories: Audit File System,
Audit Kernel Object, Audit Registry,
and Audit Removable Storage
Event Description:
This event indicates that a specific
operation was performed on an
object. The object could be a file
system, kernel, or registry object, or
a file system object on removable
storage or a device.
This event generates only if objects
SACL has required ACE to handle
specific access right use.
The main difference with 4656: A
handle to an object was requested.
event is that 4663 shows that
access right was used instead of
just requested and 4663 doesnt
have Failure events.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="HandleId">0x1bc</Data>
<Data Name="AccessList">%%4417 %%4418</Data>
</EventData>
</Event>

Event Versions:
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made an attempt to access an object. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: the name of the account that made an attempt to access an object.
the following:
Object:
Object Type [Type = UnicodeString]: The type of object that was accessed during the operation.
Handle ID [Type = Pointer]: hexadecimal value of a handle to Object Name. This field can be used for
correlation with other events, for example with Handle ID field in 4656(S, F): A handle to an object was
requested. This parameter might not be captured in the event, and in that case appears as 0x0.
Process ID [Type = Pointer]: hexadecimal Process ID of the process that accessed the object. Process ID (PID)
Accesses [Type = UnicodeString]: the list of access rights which were used by Subject\Security ID. These
HEX VALUE,
directory.


sub-keys.)

%%4420 attributes.

interpreter.
are assigned the

HEX VALUE,

%%4423

%%4424

%%1537




this access right.


For 4663(S): An attempt was made to access an object.
If you have critical file system objects for which you need to monitor all access attempts, monitor this event
for Object Name.
If you have critical file system objects for which you need to monitor certain access attempts (for example,
write actions), monitor this event for Object Name in relation to Access Request Information\Accesses.
If you have file system objects with specific attributes, for which you need to monitor access attempts,
monitor this event for Resource Attributes.
If Object Name is a sensitive or critical registry key for which you need to monitor specific access attempts
(for example, only write actions), monitor for all 4663 events with the corresponding Access Request
Information\Accesses.
For file system objects, we recommend that you monitor for these Access Request Information\Accesses
rights:
WriteEA
DeleteChild
WriteAttributes
DELETE
WRITE_DAC
WRITE_OWNER
4664(S): An attempt was made to create a hard link.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit File System
Event Description:
This event generates when an NTFS hard link
was successfully created.

Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="FileName">C:\\notepad.exe</Data>
<Data Name="LinkName">C:\\Docs\\My.exe</Data>
</EventData>
</Event>
Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made an attempt to create the hard link. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that made an attempt to create the hard
link.
the following:
Link Information:
File Name [Type = UnicodeString]: the name of a file or folder that new hard link refers to.
Link Name [Type = UnicodeString]: full path name with new hard link file name.
0000-000000000000}.

For 4664(S): An attempt was made to create a hard link.
We recommend monitoring for any 4664 event, because this action is not typical for normal operating system
behavior and can be a sign of malicious activity.
Applies to
Windows 10
Windows Server 2016
Subcategories: Audit File System, Audit Non
Sensitive Privilege Use, Audit Other Privilege
Use Events, and Audit Sensitive Privilege Use
Event Description:
This is an informational event from file
system Transaction Manager.

event.
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TransactionId">{17EF5E21-5E2C-11E5-810F-00155D987005}</Data>
<Data Name="NewState">52</Data>
<Data Name="ResourceManager">{5F5ED427-FCCA-11E3-BD73-B54AB417B853}</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account through which the state of the transaction was changed. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that changed the state of the transaction.
following:
Transaction Information:
RM Transaction ID [Type = GUID]: unique GUID of the transaction. This field can help you correlate this event
with other events that might contain the same Transaction ID, such as 4656(S, F): A handle to an object was
requested.
New State [Type = UInt32]: identifier of the new state of the transaction.
Resource Manager [Type = GUID]: unique GUID-Identifier of the Resource Manager which associated with
this transaction.
Process ID [Type = Pointer]: hexadecimal Process ID of the process through which the state of the
transaction was changed. Process ID (PID) is a number used by the operating system to uniquely identify an
active process. To see the PID for a specific process you can, for example, use Task Manager (Details tab, PID
column):

For 4985(S): The state of a transaction has changed.
This event typically has no security relevance and used for Transaction Manager troubleshooting.
5051(-): A file was virtualized.
Applies to
Windows 10
Windows Server 2016
This event should be generated when file was virtualized using LUAFV.
This event occurs very rarely during standard LUAFV file virtualization.
Subcategory: Audit File System
Event Schema:
A file was virtualized.
Subject:
Security ID:%1%
Account Name:%2
Account Domain:%3
Logon ID:%4
Object:
File Name:%5
Virtual File Name:%6
Process ID:%7
Process Name%8

Event Versions: 0.

Applies to
Windows 10
Windows Server 2016
Subcategories: Audit File System, Audit
Registry, Audit Authentication Policy Change,
and Audit Authorization Policy Change
Event Description:
This event generates when the permissions for
an object are changed. The object could be a file
system, registry, or security token object.
This event does not generate if the SACL
(Auditing ACL) was changed.
Before this event can generate, certain ACEs
might need to be set in the objects SACL. For
example, for a file system object, it generates
only if Change Permissions" and/or "Take
Ownership are set in the objects SACL. For a
registry key, it generates only if Write DAC"
and/or "Write Owner are set in the objects
SACL.

Event XML:
- <System>
<Level>0</Level>
<Task>13570</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectName">C:\\Documents\\netcat-1.11</Data>
<Data Name="HandleId">0x3f0</Data>
<Data Name="OldSd">D:AI(A;OICIID;FA;;;S-1-5-21-3457937927-2839227994-823803824-2104)(A;OICIID;FA;;;S-1-5-21-
3457937927-2839227994-823803824-1104)(A;OICIID;FA;;;SY)(A;OICIID;FA;;;BA)</Data>
<Data Name="NewSd">D:ARAI(A;OICI;FA;;;WD)(A;OICIID;FA;;;S-1-5-21-3457937927-2839227994-823803824-2104)
(A;OICIID;FA;;;S-1-5-21-3457937927-2839227994-823803824-1104)(A;OICIID;FA;;;SY)(A;OICIID;FA;;;BA)</Data>
<Data Name="ProcessId">0xdb0</Data>
<Data Name="ProcessName">C:\\Windows\\System32\\dllhost.exe</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the change objects permissions operation. Event
Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see
Account Name [Type = UnicodeString]: the name of the account that requested the change objects
permissions operation.
the following:
Object:
permissions were changed. For example, for a file, the path would be included. For Token objects, this field
typically equals -.
appears as 0x0.
Process:
Process ID [Type = Pointer]: hexadecimal Process ID of the process through which the permissions were
changed. Process ID (PID) is a number used by the operating system to uniquely identify an active process.
To see the PID for a specific process you can, for example, use Task Manager (Details tab, PID column):
Permissions Change:
Original Security Descriptor [Type = UnicodeString]: the old Security Descriptor Definition Language
(SDDL) value for the object.
New Security Descriptor [Type = UnicodeString]: the new Security Descriptor Definition Language (SDDL)
value for the object.
Example:
table below:

Windows 2000


operators

administrators

controllers
G: = Primary Group.
D: = DACL Entries.
S: = SACL Entries.
entry_type:
D - DACL
S - SACL
inheritance_flags:
ace_type:
"D" - ACCESS DENIED
"AU" - SYSTEM AUDIT
"A" - SYSTEM ALARM
ace_flags:

rights

"KX" KEY EXECUTE
object_guid: N/A

For 4670(S): Permissions on an object were changed.
For token objects, this is typically an informational event, and at the same time it is difficult to identify which token's
permission were changed. For token objects, there are no monitoring recommendations for this event in this
document.
For file system and registry objects, the following recommendations apply.
If you have critical registry objects for which you need to monitor all modifications (especially permissions
changes and owner changes), monitor for the specific Object\Object Name.
If you have high-value computers for which you need to monitor all changes for all or specific objects (for
example, file system or registry objects), monitor for all 4670 events on these computers. For example, you
could monitor the ntds.dit file on domain controllers.
Audit Filtering Platform Connection
Applies to
Windows 10
Windows Server 2016
Audit Filtering Platform Connection determines whether the operating system generates audit events when
connections are allowed or blocked by the Windows Filtering Platform.
Windows Filtering Platform (WFP) enables independent software vendors (ISVs) to filter and modify TCP/IP
packets, monitor or authorize connections, filter Internet Protocol security (IPsec)-protected traffic, and filter
remote procedure calls (RPCs).
This subcategory contains Windows Filtering Platform events about blocked and allowed connections, blocked
and allowed port bindings, blocked and allowed port listening actions, and blocked to accept incoming
connections applications.
Event volume: High.
STRONGER STRONGER
STRONGER STRONGER
Domain No Yes IF Yes Success auditing

Controller for this
subcategory
typically
generates a very
high volume of
events, for
example, one
event for every
connection that
was made to the
system. It is
much more
important to
audit Failure
events (blocked
connections, for
example). For
recommendation
s for using and
analyzing the
collected
information, see
the Security
Monitoring
Recommendatio
ns sections.
IF - Enable
Success audit in
case you need to
monitor
successful
outbound or
inbound
connections to
and from
untrusted IP
addresses on
high value
computers or
devices.
STRONGER STRONGER
Member Server No Yes IF Yes Success auditing

for this
subcategory
typically
generates a very
high volume of
events, for
example, one
event for every
connection that
was made to the
system. It is
much more
important to
audit Failure
events (blocked
connections, for
example). For
recommendation
s for using and
analyzing the
collected
information, see
the Security
Monitoring
Recommendatio
ns sections.
IF - Enable
Success audit in
case you need to
monitor
successful
outbound or
inbound
connections to
and from
untrusted IP
addresses on
high value
computers or
devices.
STRONGER STRONGER
Workstation No Yes IF Yes Success auditing

for this
subcategory
typically
generates a very
high volume of
events, for
example, one
event for every
connection that
was made to the
system. It is
much more
important to
audit Failure
events (blocked
connections, for
example). For
recommendation
s for using and
analyzing the
collected
information, see
the Security
Monitoring
Recommendatio
ns sections.
IF - Enable
Success audit in
case you need to
monitor
successful
outbound or
inbound
connections to
and from
untrusted IP
addresses on
high value
computers or
devices.
Events List:
5031(F): The Windows Firewall Service blocked an application from accepting incoming connections on the
network.
5150(-): The Windows Filtering Platform blocked a packet.
5151(-): A more restrictive Windows Filtering Platform filter has blocked a packet.
5154(S): The Windows Filtering Platform has permitted an application or service to listen on a port for
incoming connections.
5155(F): The Windows Filtering Platform has blocked an application or service from listening on a port for
5156(S): The Windows Filtering Platform has permitted a connection.
5157(F): The Windows Filtering Platform has blocked a connection.
5158(S): The Windows Filtering Platform has permitted a bind to a local port.
5159(F): The Windows Filtering Platform has blocked a bind to a local port.
5031(F): The Windows Firewall Service blocked an
application from accepting incoming connections on
the network.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Filtering Platform
Connection
Event Description:
This event generates when an application was
blocked from accepting incoming connections
on the network by Windows Filtering Platform.
If you dont have any firewall rules (Allow or
Deny) in Windows Firewall for specific
applications, you will get this event from
Windows Filtering Platform layer, because by
default this layer is denying any incoming
connections.
Event XML:
- <System>
<Level>0</Level>
<Task>12810</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="Profiles">Domain</Data>
<Data Name="Application">C:\\documents\\listener.exe</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Profiles [Type = UnicodeString]: network profile using which application was blocked. Possible values:
Domain
Public
Private
Application [Type = UnicodeString]: full path and file name of executable file for blocked application.

For 5031(F): The Windows Firewall Service blocked an application from accepting incoming connections on the
network.
You can use this event to detect applications for which no Windows Firewall rules were created.
If you have a pre-defined application which should be used to perform the operation that was reported by
this event, monitor events with Application not equal to your defined application.
You can monitor to see if Application is not in a standard folder (for example, not in System32 or
If you have a pre-defined list of restricted substrings or words in application names (for example,
mimikatz or cain.exe), check for these substrings in Application.
5150(-): The Windows Filtering Platform blocked a
packet.
Applies to
Windows 10
Windows Server 2016
This event is logged if the Windows Filtering Platform MAC filter blocked a packet.
Subcategory: Audit Filtering Platform Connection
Event Schema:
The Windows Filtering Platform has blocked a packet.
Direction:%1
Source Address:%2
Destination Address:%3
EtherType:%4
MediaType:%5
InterfaceType:%6
VlanTag:%7
Filter Information:
Filter Run-Time ID:%8

Layer Name:%9
*Layer Run-Time ID:%10 *

Event Versions: 0.

5151(-): A more restrictive Windows Filtering Platform
filter has blocked a packet.
Applies to
Windows 10
Windows Server 2016
This event is logged if a more restrictive Windows Filtering Platform MAC filter has blocked a packet.
Event Schema:
A more restrictive Windows Filtering Platform filter has blocked a packet.
Direction:%1
Source Address:%2
Destination Address:%3
EtherType:%4
MediaType:%5
InterfaceType:%6
VlanTag:%7
Filter Information:

Layer Name:%9
*Layer Run-Time ID:%10 *

Event Versions: 0.

5154(S): The Windows Filtering Platform has
permitted an application or service to listen on a port
for incoming connections.
Applies to
Windows 10
Windows Server 2016
Connection
Event Description:
Windows Filtering Platform permits an
application or service to listen on a port.

for this event.
Event XML:
- <System>
<Level>0</Level>
<Task>12810</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ProcessId">4152</Data>
<Data Name="Application">\\device\\harddiskvolume2\\documents\\listener.exe</Data>
<Data Name="SourceAddress">0.0.0.0</Data>
<Data Name="SourcePort">4444</Data>
<Data Name="Protocol">6</Data>
<Data Name="FilterRTID">0</Data>
<Data Name="LayerName">%%14609</Data>
<Data Name="LayerRTID">40</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Application Information:
Process ID [Type = Pointer]: hexadecimal Process ID of the process which was permitted to listen on the
port. Process ID (PID) is a number used by the operating system to uniquely identify an active process. To
Application Name [Type = UnicodeString]: full path and the name of the executable for the process.
Logical disk is displayed in format \device\harddiskvolume#. You can get all local volume numbers by using
diskpart utility. The command to get volume numbers using diskpart is list volume:
Source Address [Type = UnicodeString]: local IP address on which application requested to listen on the
port.
IPv4 Address
IPv6 Address
:: - all IP addresses in IPv6 format
0.0.0.0 - all IP addresses in IPv4 format
127.0.0.1 , ::1 - localhost
Source Port [Type = UnicodeString]: source TCP\UDP port number which was requested for listening by
application.
Protocol [Type = UInt32]: protocol number. For example:
6 TCP.
17 UDP.
More information about possible values for this field: https://technet.microsoft.com/en-
us/library/cc959827.aspx.
Filter Information:
Filter Run-Time ID [Type = UInt64]: unique filter ID which allows application to listen on the specific port.
By default Windows firewall won't prevent a port from being listened by an application and if this
application doesnt match any filters you will get value 0 in this field.
To find specific Windows Filtering Platform filter by ID you need to execute the following command: netsh
wfp show filters. As result of this command filters.xml file will be generated. You need to open this file
and find specific substring with required filter ID (<filterId>), for example:
Layer Name [Type = UnicodeString]: Application Layer Enforcement layer name.
Layer Run-Time ID [Type = UInt64]: Windows Filtering Platform layer identifier. To find specific Windows
Filtering Platform layer ID you need to execute the following command: netsh wfp show state. As result of
this command wfpstate.xml file will be generated. You need to open this file and find specific substring
with required layer ID (<layerId>), for example:
For 5154(S): The Windows Filtering Platform has permitted an application or service to listen on a port for
If you have a whitelist of applications that are associated with certain operating systems or server roles,
and that are expected to listen on specific ports, monitor this event for Application Name and other
relevant information.
If a certain application is allowed to listen only on specific port numbers, monitor this event for
Application Name and Network Information\Source Port.
If a certain application is allowed to listen only on a specific IP address, monitor this event for Application
Name and Network Information\Source Address.
If a certain application is allowed to use only TCP or UDP protocols, monitor this event for Application
Name and the protocol number in Network Information\Protocol.
Typically this event has an informational purpose.
5155(F): The Windows Filtering Platform has blocked
an application or service from listening on a port for
Applies to
Windows 10
Windows Server 2016
By default Windows firewall won't prevent a port from being listened by an application. In the other word,
Windows system will not generate Event 5155 by itself.
You can add your own filters using the WFP APIs to block listen to reproduce this event:
https://msdn.microsoft.com/en-us/library/aa364046(v=vs.85).aspx.
There is no event example in this document.
Event Schema:
The Windows Filtering Platform has blocked an application or service from listening on a port for incoming
connections.
Process ID:%1
Application Name:%2
Source Address:%3
Source Port:%4
Protocol:%5
Filter Information:

Layer Name:%7
Layer Run-Time ID:%8

Event Versions: 0.
If you use Windows Filtering Platform APIs to block application or services from listening on a port, then you
can use this event for troubleshooting and monitoring.
permitted a connection.
Applies to
Windows 10
Windows Server 2016
Connection
Event Description:
This event generates when Windows
Filtering Platform has allowed a
connection.

for this event.
Event XML:
- <System>
<Level>0</Level>
<Task>12810</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ProcessID">4556</Data>
<Data Name="Direction">%%14592</Data>
<Data Name="DestAddress">10.0.0.100</Data>
<Data Name="DestPort">49278</Data>
<Data Name="RemoteUserID">S-1-0-0</Data>
<Data Name="RemoteMachineID">S-1-0-0</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Process ID [Type = Pointer]: hexadecimal Process ID of the process which received the connection. Process
ID (PID) is a number used by the operating system to uniquely identify an active process. To see the PID for a
Direction [Type = UnicodeString]: direction of allowed connection.
Inbound for inbound connections.
Outbound for unbound connections.
Source Address [Type = UnicodeString]: local IP address on which application received the connection.
IPv4 Address
IPv6 Address
127.0.0.1 , ::1 - localhost
Source Port [Type = UnicodeString]: port number on which application received the connection.
Destination Address [Type = UnicodeString]: IP address from which connection was received or initiated.
IPv4 Address
IPv6 Address
127.0.0.1 , ::1 - localhost
Destination Port [Type = UnicodeString]: port number which was used from remote machine to initiate
connection.
Protocol [Type = UInt32]: number of protocol which was used.
SERVICE PROTOCOL NUMBER
Internet Control Message Protocol (ICMP) 1
Transmission Control Protocol (TCP) 6
User Datagram Protocol (UDP) 17
General Routing Encapsulation (PPTP data over GRE) 47
Authentication Header (AH) IPSec 51
Encapsulation Security Payload (ESP) IPSec 50
Exterior Gateway Protocol (EGP) 8
Gateway-Gateway Protocol (GGP) 3
Host Monitoring Protocol (HMP) 20
Internet Group Management Protocol (IGMP) 88
MIT Remote Virtual Disk (RVD) 66
OSPF Open Shortest Path First 89
PARC Universal Packet Protocol (PUP) 12
Reliable Datagram Protocol (RDP) 27
Reservation Protocol (RSVP) QoS 46
Filter Information:
Filter Run-Time ID [Type = UInt64]: unique filter ID which allowed the connection.
For 5156(S): The Windows Filtering Platform has permitted a connection.
Check that Source Address is one of the addresses assigned to the computer.
If the computer or device should not have access to the Internet, or contains only applications that dont
connect to the Internet, monitor for 5156 events where Destination Address is an IP address from the
Internet (not from private IP ranges).
If you know that the computer should never contact or be contacted by certain network IP addresses,
monitor for these addresses in Destination Address.
If you have a whitelist of IP addresses that the computer or device is expected to contact or be contacted
by, monitor for IP addresses in Destination Address that are not in the whitelist.
If you need to monitor all inbound connections to a specific local port, monitor for 5156 events with that
Source Port.
Monitor for all connections with a Protocol Number that is not typical for this device or compter, for
example, anything other than 1, 6, or 17.
If the computers communication with Destination Address should always use a specific Destination
Port, monitor for any other Destination Port.
a connection.
Applies to
Windows 10
Windows Server 2016
Connection
Event Description:
Filtering Platform has blocked a
connection.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>12810</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ProcessID">4556</Data>
<Data Name="RemoteUserID">S-1-0-0</Data>
<Data Name="RemoteMachineID">S-1-0-0</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Process ID [Type = Pointer]: hexadecimal Process ID of the process that attempted to create the connection.
Direction [Type = UnicodeString]: direction of blocked connection.
Source Address [Type = UnicodeString]: local IP address on which application received the connection.
IPv4 Address
IPv6 Address
127.0.0.1 , ::1 - localhost
Source Port [Type = UnicodeString]: port number on which application received the connection.
Destination Address [Type = UnicodeString]: IP address from which connection was received or initiated.
IPv4 Address
IPv6 Address
127.0.0.1 , ::1 - localhost
Destination Port [Type = UnicodeString]: port number which was used from remote machine to initiate
connection.
Filter Information:
Filter Run-Time ID [Type = UInt64]: unique filter ID which blocked the connection.
For 5157(F): The Windows Filtering Platform has blocked a connection.
If the` computer or device should not have access to the Internet, or contains only applications that dont
Source Port.
permitted a bind to a local port.
Applies to
Windows 10
Windows Server 2016
Connection
Event Description:
Windows Filtering Platform permits an
application or service to bind to a local
port.

for this event.
Event XML:
- <System>
<Level>0</Level>
<Task>12810</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Process ID [Type = Pointer]: hexadecimal Process ID of the process which was permitted to bind to the local
port. Process ID (PID) is a number used by the operating system to uniquely identify an active process. To
Source Address [Type = UnicodeString]: local IP address on which application was bind the port.
IPv4 Address
IPv6 Address
127.0.0.1 , ::1 - localhost
Source Port [Type = UnicodeString]: port number which application was bind.

Filter Information:
Filter Run-Time ID [Type = UInt64]: unique filter ID which allows application to bind the port. By default
Windows firewall won't prevent a port from being binded by an application and if this application doesnt
match any filters you will get value 0 in this field.

For 5158(S): The Windows Filtering Platform has permitted a bind to a local port.
If you need to monitor all actions with a specific local port, monitor for 5158 events with that Source Port.
example, anything other than 6 or 17.
a bind to a local port.
Applies to
Windows 10
Windows Server 2016
This event is logged if the Windows Filtering Platform has blocked a bind to a local port.
Event Schema:
The Windows Filtering Platform has blocked a bind to a local port.
Process ID:%1
Application Name:%2
Source Address:%3
Source Port:%4
Protocol:%5
Filter Information:

Layer Name:%7

Event Versions: 0.

Audit Filtering Platform Packet Drop
Applies to
Windows 10
Windows Server 2016
Audit Filtering Platform Packet Drop determines whether the operating system generates audit events when
packets are dropped by the Windows Filtering Platform.
packets, monitor or authorize connections, filter Internet Protocol security (IPsec)-protected traffic, and filter remote
procedure calls (RPCs).
A high rate of dropped packets may indicate that there have been attempts to gain unauthorized access to
computers on your network.
Event volume: High.
STRONGER STRONGER
Domain No No No No Failure events

Controller volume typically
is very high for
this subcategory
and typically used
for
troubleshooting.
If you need to
monitor blocked
connections, it is
better to use
5157(F): The
Windows Filtering
Platform has
blocked a
connection,
because it
contains almost
the same
information and
generates per-
connection, not
per-packet.
There is no
recommendation
to enable Success
auditing, because
Success events in
this subcategory
rarely occur.
STRONGER STRONGER
Member Server No No No No Failure events

volume typically
is very high for
this subcategory
and typically used
for
troubleshooting.
If you need to
monitor blocked
connections, it is
better to use
5157(F): The
Windows Filtering
Platform has
blocked a
connection,
because it
contains almost
the same
information and
generates per-
connection, not
per-packet.
There is no
recommendation
to enable Success
auditing, because
Success events in
this subcategory
rarely occur.
STRONGER STRONGER
Workstation No No No No Failure events

volume typically
is very high for
this subcategory
and typically used
for
troubleshooting.
If you need to
monitor blocked
connections, it is
better to use
5157(F): The
Windows Filtering
Platform has
blocked a
connection,
because it
contains almost
the same
information and
generates per-
connection, not
per-packet.
There is no
recommendation
to enable Success
auditing, because
Success events in
this subcategory
rarely occur.
Events List:
5152(F): The Windows Filtering Platform blocked a packet.
5153(S): A more restrictive Windows Filtering Platform filter has blocked a packet.
5152(F): The Windows Filtering Platform blocked a
packet.
Applies to
Windows 10
Windows Server 2016
Packet Drop
Event Description:
Filtering Platform has blocked a
network packet.
This event is generated for every
received network packet.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>12809</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Process ID [Type = Pointer]: hexadecimal Process ID of the process to which blocked network packet was
sent. Process ID (PID) is a number used by the operating system to uniquely identify an active process. To
Direction [Type = UnicodeString]: direction of blocked connection.
Source Address [Type = UnicodeString]: local IP address on which application received the packet.
IPv4 Address
IPv6 Address
127.0.0.1 , ::1 - localhost
Source Port [Type = UnicodeString]: port number on which application received the packet.
Destination Address [Type = UnicodeString]: IP address from which packet was received or initiated.
IPv4 Address
IPv6 Address
127.0.0.1 , ::1 - localhost
Destination Port [Type = UnicodeString]: port number which was used from remote machine to send the
packet.
Filter Information:
Filter Run-Time ID [Type = UInt64]: unique filter ID which blocked the packet.
For 5152(F): The Windows Filtering Platform blocked a packet.
If the computer or device should not have access to the Internet, or contains only applications that dont
Source Port.
5153(S): A more restrictive Windows Filtering Platform
filter has blocked a packet.
Applies to
Windows 10
Windows Server 2016
This event is logged if a more restrictive Windows Filtering Platform filter has blocked a packet.
Subcategory: Audit Filtering Platform Packet Drop
Event Schema:
A more restrictive Windows Filtering Platform filter has blocked a packet.
Process ID:%1
Application Name:%2
Source Address:%3
Source Port:%4
Protocol:%5
Filter Information:

Layer Name:%7

Event Versions: 0.

Audit Handle Manipulation
Applies to
Windows 10
Windows Server 2016
Audit Handle Manipulation enables generation of 4658: The handle to an object was closed in Audit File
System, Audit Kernel Object, Audit Registry, Audit Removable Storage and Audit SAM subcategories, and shows
objects handle duplication and close actions.
Event volume: High.
STRONGER STRONGER
Domain No No No No Typically,
Controller information
about the
duplication or
closing of an
object handle has
little to no
security
relevance and is
hard to parse or
analyze.
There is no
recommendation
to enable this
subcategory for
Success or Failure
auditing, unless
you know exactly
what you need
to monitor in
Objects Handles
level.
STRONGER STRONGER
Member Server No No No No Typically,

information
about the
duplication or
closing of an
object handle has
little to no
security
relevance and is
hard to parse or
analyze.
There is no
recommendation
to enable this
subcategory for
Success or Failure
auditing, unless
you know exactly
what you need
to monitor in
Objects Handles
level.
Workstation No No No No Typically,
information
about the
duplication or
closing of an
object handle has
little to no
security
relevance and is
hard to parse or
analyze.
There is no
recommendation
to enable this
subcategory for
Success or Failure
auditing, unless
you know exactly
what you need
to monitor in
Objects Handles
level.
Events List:
4690(S): An attempt was made to duplicate a handle to an object.

This event doesnt generate in this subcategory, but you can use this subcategory to enable it. For a description
of the event, see 4658(S): The handle to an object was closed in the Audit File System subcategory.
4690(S): An attempt was made to duplicate a handle
to an object.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Handle Manipulation
Event Description:
This event generates if an attempt was made to
duplicate a handle to an object.

Event XML:
- <System>
<Level>0</Level>
<Task>12807</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SourceHandleId">0x438</Data>
<Data Name="SourceProcessId">0x674</Data>
<Data Name="TargetHandleId">0xd9c</Data>
<Data Name="TargetProcessId">0x4</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made an attempt to duplicate a handle to an object. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that made an attempt to duplicate a
handle to an object.
the following:
Source Handle Information:
Source Handle ID [Type = Pointer]: hexadecimal value of a handle which was duplicated. This field can help
you correlate this event with other events, for example 4663: An attempt was made to access an object in
Audit File System, Audit Kernel Object, Audit Registry, Audit Removable Storage or Audit SAM subcategories.
Source Process ID [Type = Pointer]: hexadecimal Process ID of the process which opened the Source
Handle ID before it was duplicated. Process ID (PID) is a number used by the operating system to uniquely
identify an active process. To see the PID for a specific process you can, for example, use Task Manager
(Details tab, PID column):
New Handle Information:
Target Handle ID [Type = Pointer]: hexadecimal value of the new handle (the copy of Source Handle ID).
This field can help you correlate this event with other events, for example 4663: An attempt was made to
access an object in Audit File System, Audit Kernel Object, Audit Registry, Audit Removable Storage or Audit
SAM subcategories.
Target Process ID [Type = Pointer]: hexadecimal Process ID of the process which opened the Target
Handle ID. Process ID (PID) is a number used by the operating system to uniquely identify an active process.
has been created Process Information\New Process ID field.

For 4690(S): An attempt was made to duplicate a handle to an object.
Audit Kernel Object
Applies to
Windows 10
Windows Server 2016
Audit Kernel Object determines whether the operating system generates audit events when users attempt to
access the system kernel, which includes mutexes and semaphores.
Only kernel objects with a matching system access control list (SACL) generate security audit events. The audits
generated are usually useful only to developers.
Typically, kernel objects are given SACLs only if the AuditBaseObjects or AuditBaseDirectories auditing options
are enabled.
The Audit: Audit the access of global system objects policy setting controls the default SACL of kernel objects.
Event volume: High.
STRONGER STRONGER
Domain No No No No Typically Kernel

Controller object auditing
events have little
to no security
relevance and
are hard to parse
or analyze. Also,
the volume of
these events is
typically very
high.
There is no
recommendation
to enable this
subcategory,
unless you know
exactly what you
need to monitor
at the Kernel
objects level.
STRONGER STRONGER
Member Server No No No No Typically Kernel

object auditing
events have little
to no security
relevance and
are hard to parse
or analyze. Also,
the volume of
these events is
typically very
high.
There is no
recommendation
to enable this
subcategory,
unless you know
exactly what you
need to monitor
at the Kernel
objects level.
Workstation No No No No Typically Kernel

object auditing
events have little
to no security
relevance and
are hard to parse
or analyze. Also,
the volume of
these events is
typically very
high.
There is no
recommendation
to enable this
subcategory,
unless you know
exactly what you
need to monitor
at the Kernel
objects level.
Events List:
Applies to
Windows 10
Windows Server 2016
Event Description:
This event indicates that specific access was requested for an object. The object could be a file system, kernel, or
registry object, or a file system object on removable storage or a device.
This event shows that access was requested, and the results of the request, but it doesnt show that the operation
was performed. To see that the operation was performed, check 4663(S): An attempt was made to access an
object.
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
(D;;LC;;;S-1-5-21-3457937927-2839227994-823803824-1104) %%4419: %%1809 %%4420: %%1809 %%4423: %%1811 D:
(A;OICI;FA;;;S-1-5-21-3457937927-2839227994-823803824-1104) %%4424: %%1809</Data>
</EventData>
</Event>

Event Versions:
Field Descriptions:
Subject:
event.
the following:
Object:

appears as 0x0.
0000-000000000000}.
Accesses [Type = UnicodeString]: the list of access rights which were requested by Subject\Security ID. These
HEXADECIMAL VALUE,
directory.
HEXADECIMAL VALUE,


sub-keys.)

%%4420 attributes.

interpreter.
are assigned the


%%4423

%%4424

%%1537


HEXADECIMAL VALUE,


this access right.

Access Reasons [Type = UnicodeString] [Version 1]: the list of access check results. The format of this varies,
depending on the object. For kernel objects, this field does not apply.
Privileges Used for Access Check [Type = UnicodeString]: the list of user privileges which were used during
the operation, for example, SeBackupPrivilege. This parameter might not be captured in the event, and in that
case appears as -. See full list of user privileges in the table below:

a process.

operations.
held:
READ_CONTROL
FILE_GENERIC_READ
FILE_TRAVERSE




creation APIs.

account.
components.

a process.
interface.
to a process.
users.
driver.

memory.
computer account.
controllers.

defragmentation.

processes.

network request.

held:
WRITE_DAC
WRITE_OWNER
FILE_GENERIC_WRITE
FILE_ADD_FILE
DELETE
an object.

security event log.
synchronization.

processes.
clock.



a terminal device.
Object Types.

If Object Name is a sensitive or critical object for which you need to monitor any access attempt, monitor all
4656 events.
If Object Name is a sensitive or critical object for which you need to monitor specific access attempts (for
example, only write actions), monitor for all 4656 events with the corresponding Access Request
If you need to monitor files and folders with specific Resource Attribute values, monitor for all 4656 events
with specific Resource Attributes field values.
For file system objects, we recommend that you monitor these Access Request Information\Accesses
rights (especially for Failure events):
WriteEA
DeleteChild
WriteAttributes
DELETE
WRITE_DAC
WRITE_OWNER
Applies to
Windows 10
Windows Server 2016
Subcategories: Audit File System, Audit Handle
Manipulation, Audit Kernel Object, Audit
Registry, and Audit Removable Storage
Event Description:
device.
enabled for Audit Handle Manipulation
subcategory.
open. Otherwise, it might not have any security
relevance.
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Account Name [Type = UnicodeString]: the name of the account that requested the close objects handle
operation.
the following:
Object:
appears as 0x0.
Process ID [Type = Pointer]: hexadecimal Process ID of the process that requested that the handle be closed.

Applies to
Windows 10
Windows Server 2016
Subcategories: Audit File System, Audit Kernel
Object, and Audit Registry
Event Description:
This event generates only if Delete" auditing is
set in objects SACL.
deleted object (only the Handle ID). It is better
to use 4663(S): An attempt was made to
access an object with DELETE access to track
object deletion.
generated only during real delete operations. In
contrast, 4663(S): An attempt was made to
access an object also generates during other
actions, such as object renaming.
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
operation.
the following:
Object:
appears as 0x0.
Process ID [Type = Pointer]: hexadecimal Process ID of the process that deleted the object. Process ID (PID)
was requested.
0000-000000000000}.
Applies to
Windows 10
Windows Server 2016
Subcategories: Audit File System,
Audit Kernel Object, Audit Registry,
and Audit Removable Storage
Event Description:
This event indicates that a specific
operation was performed on an
object. The object could be a file
system, kernel, or registry object, or
a file system object on removable
storage or a device.
This event generates only if objects
SACL has required ACE to handle
specific access right use.
The main difference with 4656: A
handle to an object was requested.
event is that 4663 shows that
access right was used instead of
just requested and 4663 doesnt
have Failure events.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions:
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made an attempt to access an object. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: the name of the account that made an attempt to access an object.
the following:
Object:
Handle ID [Type = Pointer]: hexadecimal value of a handle to Object Name. This field can be used for
correlation with other events, for example with Handle ID field in 4656(S, F): A handle to an object was
requested. This parameter might not be captured in the event, and in that case appears as 0x0.
Process ID [Type = Pointer]: hexadecimal Process ID of the process that accessed the object. Process ID (PID)
Accesses [Type = UnicodeString]: the list of access rights which were used by Subject\Security ID. These
HEX VALUE,
directory.


sub-keys.)

%%4420 attributes.

interpreter.
are assigned the

HEX VALUE,

%%4423

%%4424

%%1537




this access right.


If you have critical file system objects for which you need to monitor all access attempts, monitor this event
for Object Name.
If you have critical file system objects for which you need to monitor certain access attempts (for example,
write actions), monitor this event for Object Name in relation to Access Request Information\Accesses.
If Object Name is a sensitive or critical registry key for which you need to monitor specific access attempts
For file system objects, we recommend that you monitor for these Access Request Information\Accesses
rights:
WriteEA
DeleteChild
WriteAttributes
DELETE
WRITE_DAC
WRITE_OWNER
Audit Other Object Access Events
Applies to
Windows 10
Windows Server 2016
Audit Other Object Access Events allows you to monitor operations with scheduled tasks, COM+ objects and
indirect object access requests.
Event volume: Low.
STRONGER STRONGER

first of all
because of
scheduled tasks
events.
We recommend
Failure auditing
to get events
about possible
ICMP DoS attack.

Success auditing
first of all
because of
scheduled tasks
events.
We recommend
Failure auditing
to get events
about possible
ICMP DoS attack.

Success auditing
first of all
because of
scheduled tasks
events.
We recommend
Failure auditing
to get events
about possible
ICMP DoS attack.
Events List:
4671(-): An application attempted to access a blocked ordinal through the TBS.
4691(S): Indirect access to an object was requested.
5148(F): The Windows Filtering Platform has detected a DoS attack and entered a defensive mode; packets
associated with this attack will be discarded.
5149(F): The DoS attack has subsided and normal processing is being resumed.
4698(S): A scheduled task was created.
4699(S): A scheduled task was deleted.
4700(S): A scheduled task was enabled.
4701(S): A scheduled task was disabled.
4702(S): A scheduled task was updated.
5888(S): An object in the COM+ Catalog was modified.
5889(S): An object was deleted from the COM+ Catalog.
5890(S): An object was added to the COM+ Catalog.
4671(-): An application attempted to access a blocked
ordinal through the TBS.
Applies to
Windows 10
Windows Server 2016
Currently this event doesnt generate. It is a defined event, but it is never invoked by the operating system.
Subcategory: Audit Other Object Access Events
4691(S): Indirect access to an object was requested.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Other Object Access
Events
Event Description:
This event indicates that indirect access to
an object was requested.
These events are generated for ALPC
Ports access request actions.

for this event.
Event XML:
- <System>
<Level>0</Level>
<Task>12804</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectType">ALPC Port</Data>
<Data Name="ObjectName">\\Sessions\\2\\Windows\\DwmApiPort</Data>
<Data Name="ProcessId">0xe60</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested an access to the object. Event Viewer automatically tries
event.
Account Name [Type = UnicodeString]: the name of the account that requested an access to the object.
the following:
Object:
Object Type [Type = UnicodeString]: The type of an object for which access was requested.
Object Name [Type = UnicodeString]: full path and name of the object for which access was requested.
These access rights depend on Object Type. Table 13. File access codes. contains information about the
most common access rights for file system objects. For information about ALPC ports access rights, use
https://technet.microsoft.com/ or other informational resources.
Table 13. File access codes. for more information about file access rights. For information about ALPC ports
access rights, use https://technet.microsoft.com/ or other informational resources.

For 4691(S): Indirect access to an object was requested.
recommendation for this event, unless you know exactly what you need to monitor with ALPC Ports.
5148(F): The Windows Filtering Platform has detected
a DoS attack and entered a defensive mode; packets
associated with this attack will be discarded.
Applies to
Windows 10
Windows Server 2016
In most circumstances, this event occurs very rarely. It is designed to be generated when an ICMP DoS attack starts
or was detected.
Event Schema:
The Windows Filtering Platform has detected a DoS attack and entered a defensive mode; packets associated with
this attack will be discarded.
Type:%1

Event Versions: 0.

This event can be a sign of ICMP DoS attack or, among other things, hardware or network device related
problems. In both cases, we recommend triggering an alert and investigating the reason the event was
generated.
5149(F): The DoS attack has subsided and normal
processing is being resumed.
Applies to
Windows 10
Windows Server 2016
In most circumstances, this event occurs very rarely. It is designed to be generated when an ICMP DoS attack
ended.
Event Schema:
The DoS attack has subsided and normal processing is being resumed.
Type:%1
Packets Discarded:%2

Event Versions: 0.

This event can be a sign of ICMP DoS attack or, among other things, hardware or network device related
problems. In both cases, we recommend triggering an alert and investigating the reason the event was
generated.
4698(S): A scheduled task was created.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time a new scheduled task is
created.
Note For recommendations, see Security Monitoring

Event XML:
- <System>
<Level>0</Level>
<Task>12804</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectLogonId">0x364eb</Data>
<Data Name="TaskName">\\Microsoft\\StartListener</Data>
<Data Name="TaskContent"><?xml version="1.0" encoding="UTF-16"?> <Task version="1.2"
xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task"> <RegistrationInfo> <Date>2015-09-
22T19:03:06.9258653</Date> <Author>CONTOSO\\dadmin</Author> </RegistrationInfo> <Triggers /> <Principals>
<Principal id="Author"> <RunLevel>LeastPrivilege</RunLevel> <UserId>CONTOSO\\dadmin</UserId>
<LogonType>InteractiveToken</LogonType> </Principal> </Principals> <Settings>
<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>true</StopIfGoingOnBatteries> <AllowHardTerminate>true</AllowHardTerminate>
<StartWhenAvailable>false</StartWhenAvailable> <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
<IdleSettings> <StopOnIdleEnd>true</StopOnIdleEnd> <RestartOnIdle>false</RestartOnIdle> </IdleSettings>
<AllowStartOnDemand>true</AllowStartOnDemand> <Enabled>true</Enabled> <Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle> <WakeToRun>false</WakeToRun> <ExecutionTimeLimit>P3D</ExecutionTimeLimit>
<Priority>7</Priority> </Settings> <Actions Context="Author"> <Exec>
<Command>C:\\Documents\\listener.exe</Command> </Exec> </Actions> </Task></Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the create scheduled task operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the create scheduled task
operation.
the following:
Task Information:
Task Name [Type = UnicodeString]: new scheduled task name. The format of this value is
\task_path\task_name, where task_path is a path in Microsoft Task Scheduler tree starting from Task
Scheduler Library node:
Task Content [Type = UnicodeString]: the XML content of the new task. For more information about the XML
format for scheduled tasks, see XML Task Definition Format.

For 4698(S): A scheduled task was created.
We recommend monitoring all scheduled task creation events, especially on critical computers or devices.
Scheduled tasks are often used by malware to stay in the system after reboot or for other malicious actions.
Monitor for new tasks located in the Task Scheduler Library root node, that is, where Task Name looks
like \TASK_NAME. Scheduled tasks that are created manually or by malware are often located in the Task
Scheduler Library root node.
In the new task, if the Task Content: XML contains <LogonType>Password</LogonType> value, trigger
an alert. In this case, the password for the account that will be used to run the scheduled task will be saved in
Credential Manager in cleartext format, and can be extracted using Administrative privileges.
4699(S): A scheduled task was deleted.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time a scheduled task was
deleted.

Event XML:
- <System>
<Level>0</Level>
<Task>12804</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TaskName">\\Microsoft\\My</Data>
<LogonType>Password</LogonType> </Principal> </Principals> <Settings>
<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>true</StopIfGoingOnBatteries> <AllowHardTerminate>false</AllowHardTerminate>
<RunOnlyIfIdle>false</RunOnlyIfIdle> <WakeToRun>false</WakeToRun> <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
<Command>C:\\Windows\\notepad.exe</Command> </Exec> </Actions> </Task></Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the delete scheduled task operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the delete scheduled task
operation.
the following:
Task Information:
Task Name [Type = UnicodeString]: deleted scheduled task name. The format of this value is
Task Content [Type = UnicodeString]: the XML of the deleted task. Here XML Task Definition Format you can
read more about the XML format for scheduled tasks.

For 4699(S): A scheduled task was deleted.
We recommend monitoring all scheduled task deletion events, especially on critical computers or devices.
Scheduled tasks are often used by malware to stay in the system after reboot or for other malicious actions.
However, this event does not often happen.
Monitor for deleted tasks located in the Task Scheduler Library root node, that is, where Task Name looks
like \TASK_NAME. Scheduled tasks that are created manually or by malware are often located in the Task
Scheduler Library root node. Deletion of such tasks can be a sign of malicious activity.
If a highly critical scheduled task exists on some computers, and it should never be deleted, monitor for
4699 events with the corresponding Task Name.
4700(S): A scheduled task was enabled.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time a scheduled task is
enabled.

Event XML:
- <System>
<Level>0</Level>
<Task>12804</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the enable scheduled task operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the enable scheduled
task operation.
the following:
Task Information:
Task Name [Type = UnicodeString]: enabled scheduled task name. The format of this value is
Task Content [Type = UnicodeString]: the XML of the enabled task. Here XML Task Definition Format you can

For 4700(S): A scheduled task was enabled.
If a highly critical scheduled task exists on some computers, and for some reason it should never be enabled,
monitor for 4700 events with the corresponding Task Name.
4701(S): A scheduled task was disabled.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time a scheduled task is
disabled.

Event XML:
- <System>
<Level>0</Level>
<Task>12804</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<AllowStartOnDemand>true</AllowStartOnDemand> <Enabled>false</Enabled> <Hidden>false</Hidden>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the enable scheduled task operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the enable scheduled
task operation.
the following:
Task Information:
Task Name [Type = UnicodeString]: disabled scheduled task name. The format of this value is
Task Content [Type = UnicodeString]: the XML of the disabled task. Here XML Task Definition Format you can

For 4701(S): A scheduled task was disabled.
If a highly critical scheduled task exists on some computers, and it should never be disabled, monitor for 4701
events with the corresponding Task Name.
4702(S): A scheduled task was updated.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time scheduled task was
updated/changed.

Event XML:
- <System>
<Level>0</Level>
<Task>12804</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TaskContentNew"><?xml version="1.0" encoding="UTF-16"?> <Task version="1.2"
<Principal id="Author"> <RunLevel>HighestAvailable</RunLevel> <UserId>CONTOSO\\dadmin</UserId>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the change/update scheduled task operation. Event
Account Name [Type = UnicodeString]: the name of the account that requested the change/update
scheduled task operation.
the following:
Task Information:
Task Name [Type = UnicodeString]: updated/changed scheduled task name. The format of this value is
Task New Content [Type = UnicodeString]: the new XML for the updated task. Here XML Task Definition
Format you can read more about the XML format for scheduled tasks.

For 4702(S): A scheduled task was updated.
Monitor for updated scheduled tasks located in the Task Scheduler Library root node, that is, where Task
Name looks like \TASK_NAME. Scheduled tasks that are created manually or by malware are often located
in the Task Scheduler Library root node.
In the updated scheduled task, if the Task Content: XML contains <LogonType>Password</LogonType>
value, trigger an alert. In this case, the password for the account that will be used to run the scheduled task
will be saved in Credential Manager in cleartext format, and can be extracted using Administrative privileges.
5888(S): An object in the COM+ Catalog was
modified.
Applies to
Windows 10
Windows Server 2016
Events
Event Description:
This event generates when the object in
COM+ Catalog was modified.
For some reason this event belongs to Audit
System Integrity subcategory, but generation
of this event enables in this subcategory.

event.
Event XML:
- <System>
<Level>0</Level>
<Task>12290</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectUserDomainName">CONTOSO</Data>
<Data Name="SubjectLogonId">222443</Data>
<Data Name="ObjectCollectionName">Applications</Data>
<Data Name="ObjectIdentifyingProperties">ID = {1D34B2DC-0E43-4040-BA7B-2F1C181FD86A} AppPartitionID =
{41E90F3E-56C1-4633-81C3-6E8BAC8BDD70}</Data>
<Data Name="ModifiedObjectProperties">Name = 'COMApp' -> 'COMApp-New' cCOL\_SecurityDescriptor = '<Opaque>' ->
'<Opaque>'</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the modify/change object operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the modify/change
object operation.
the following:
Object:
COM+ Catalog Collection [Type = UnicodeString]: the name of COM+ collection in which the object was
modified. Here is the list of possible collection values with descriptions:
COLLECTION DESCRIPTION
ApplicationCluster Contains a list of the servers in the application cluster.
ApplicationInstances Contains an object for each instance of a running COM+

application.
Applications Contains an object for each COM+ application installed on the

local computer.
Components Contains an object for each component in the application to

which it is related.
ComputerList Contains a list of the computers found in the Computers

folder of the Component Services administration tool.
DCOMProtocols Contains a list of the protocols to be used by DCOM. It

contains an object for each protocol.
ErrorInfo Retrieves extended error information regarding methods that

deal with multiple objects.
EventClassesForIID Retrieves information regarding event classes.
FilesForImport Retrieves information from its MSI file about an application

that can be imported.
InprocServers Contains a list of the in-process servers registered with the

system. It contains an object for each component.
InterfacesForComponent Contains an object for each interface exposed by the

component to which the collection is related.
LegacyComponents Contains an object for each unconfigured component in the

application to which it is related.
LegacyServers Identical to the InprocServers collection except that this

collection also includes local servers.
LocalComputer Contains a single object that holds computer level settings

information for the computer whose catalog you are
accessing.
MethodsForInterface Contains an object for each method on the interface to which

the collection is related.
Partitions Used to specify the applications contained in each partition.
PartitionUsers Used to specify the users contained in each partition.
PropertyInfo Retrieves information about the properties that a specified

collection supports.
PublisherProperties Contains an object for each publisher property for the parent
SubscriptionsForComponent collection.
RelatedCollectionInfo Retrieves information about other collections related to the

collection from which it is called.
Roles Contains an object for each role assigned to the application to

RolesForComponent Contains an object for each role assigned to the component to

which the collection is related.
RolesForInterface Contains an object for each role assigned to the interface to

RolesForMethod Contains an object for each role assigned to the method to

RolesForPartition Contains an object for each role assigned to the partition to

Root Contains the top-level collections on the catalog.
SubscriberProperties Contains an object for each subscriber property for the parent
SubscriptionsForComponent Contains an object for each subscription for the parent

Components collection.
TransientPublisherProperties Contains an object for each publisher property for the parent
TransientSubscriptions collection.
TransientSubscriberProperties Contains an object for each subscriber property for the parent
TransientSubscriptions Contains an object for each transient subscription.
UsersInPartitionRole Contains an object for each user in the partition role to which
UsersInRole Contains an object for each user in the role to which the
collection is related.
WOWInprocServers Contains a list of the in-process servers registered with the

system for 32-bit components on 64-bit computers.
WOWLegacyServers Identical to the LegacyServers collection except that this

collection is drawn from the 32-bit registry on 64-bit
computers.
Object Name [Type = UnicodeString]: object-specific fields with the names and identifiers for the modified
object. It depends on COM+ Catalog Collection value, for example, if COM+ Catalog Collection =
Applications, then you can find that:
ID - A GUID representing the application. This property is returned when the Key property method is
called on an object of this collection.
AppPartitionID - A GUID representing the application partition ID.
Object Properties Modified [Type = UnicodeString]: the list of objects (Object Name) properties which
were modified.
The items have the following format: Property_Name = OLD_VALUE -> NEW_VALUE
Check description for specific COM+ Catalog Collection to see the list of objects properties and
descriptions.

For 5888(S): An object in the COM+ Catalog was modified.
If you have a specific COM+ object for which you need to monitor all modifications, monitor all 5888 events
with the corresponding Object Name.
5889(S): An object was deleted from the COM+
Catalog.
Applies to
Windows 10
Windows Server 2016
Events
Event Description:
This event generates when the object in the
COM+ Catalog was deleted.
For some reason this event belongs to
Audit System Integrity subcategory, but
generation of this event enables in this
subcategory.

event.
Event XML:
- <System>
<Level>0</Level>
<Task>12290</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectCollectionName">Applications</Data>
<Data Name="ObjectIdentifyingProperties">ID = {1D34B2DC-0E43-4040-BA7B-2F1C181FD86A} AppPartitionID =
{41E90F3E-56C1-4633-81C3-6E8BAC8BDD70}</Data>
<Data Name="ObjectProperties">Name = COMApp-New ApplicationProxyServerName = ProcessType = 2 CommandLine =
ServiceName = <null> RunAsUserType = 1 Identity = Interactive User Description = IsSystem = N Authentication =
4 ShutdownAfter = 3 RunForever = N Password = \*\*\*\*\*\*\*\* Activation = Local Changeable = Y Deleteable = Y
CreatedBy = AccessChecksLevel = 1 ApplicationAccessChecksEnabled = 1 cCOL\_SecurityDescriptor = <Opaque>
ImpersonationLevel = 3 AuthenticationCapability = 64 CRMEnabled = 0 3GigSupportEnabled = 0 QueuingEnabled = 0
QueueListenerEnabled = N EventsEnabled = 1 ProcessFlags = 0 ThreadMax = 0 ApplicationProxy = 0 CRMLogFile =
DumpEnabled = 0 DumpOnException = 0 DumpOnFailfast = 0 MaxDumpCount = 5 DumpPath =
%systemroot%\\system32\\com\\dmp IsEnabled = 1 AppPartitionID = {41E90F3E-56C1-4633-81C3-6E8BAC8BDD70}
ConcurrentApps = 1 RecycleLifetimeLimit = 0 RecycleCallLimit = 0 RecycleActivationLimit = 0 RecycleMemoryLimit
= 0 RecycleExpirationTimeout = 15 QCListenerMaxThreads = 0 QCAuthenticateMsgs = 0 ApplicationDirectory =
SRPTrustLevel = 262144 SRPEnabled = 0 SoapActivated = 0 SoapVRoot = SoapMailTo = SoapBaseUrl = Replicable =
1</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
operation.
the following:
Object:
COM+ Catalog Collection [Type = UnicodeString]: the name of COM+ collection in which COM+ object was
deleted. Here is the list of possible collection values with descriptions:

application.
Applications Contains an object for each COM+ application installed on the

local computer.










accessing.




RolesForComponent Contains an object for each role assigned to the component to







computers.
Object Name [Type = UnicodeString]: object-specific fields with the names and identifiers for the deleted
Object Details [Type = UnicodeString]: the list of deleted objects (Object Name) properties.
The items have the following format: Property_Name = VALUE
descriptions.

For 5889(S): An object was deleted from the COM+ Catalog.
If you have a specific COM+ object for which you need to monitor all modifications (especially delete
operations), monitor all 5889 events with the corresponding Object Name.
5890(S): An object was added to the COM+ Catalog.
Applies to
Windows 10
Windows Server 2016
Events
Event Description:
This event generates when new object was
added to the COM+ Catalog.
For some reason this event belongs to Audit
System Integrity subcategory, but generation
of this event enables in this subcategory.

Event XML:
- <System>
<Level>0</Level>
<Task>12290</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectCollectionName">Roles</Data>
<Data Name="ObjectIdentifyingProperties">ApplId = {1D34B2DC-0E43-4040-BA7B-2F1C181FD86A} Name =
CreatorOwner</Data>
<Data Name="ObjectProperties">Description =</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the add object operation. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: the name of the account that requested the add object
operation.
the following:
Object:
COM+ Catalog Collection [Type = UnicodeString]: the name of COM+ collection to which the new object was
added. Here is the list of possible collection values with descriptions:

application.
Applications Contains an object for each COM+ application installed on

the local computer.










accessing.




RolesForComponent Contains an object for each role assigned to the component

to which the collection is related.






computers.
Object Name [Type = UnicodeString]: object-specific fields with the names and identifiers for the new
Object Details [Type = UnicodeString]: the list of new objects (Object Name) properties.
The items have the following format: Property_Name = VALUE
descriptions.

For 5890(S): An object was added to the COM+ Catalog.
If you need to monitor for creation of new COM+ objects within specific COM+ collection, monitor all 5890
events with the corresponding COM+ Catalog Collection field value.
Audit Registry
Applies to
Windows 10
Windows Server 2016
Audit Registry allows you to audit attempts to access registry objects. A security audit event is generated only
for objects that have system access control lists (SACLs) specified, and only if the type of access requested,
such as Read, Write, or Modify, and the account making the request match the settings in the SACL.
If success auditing is enabled, an audit entry is generated each time any account successfully accesses a
registry object that has a matching SACL. If failure auditing is enabled, an audit entry is generated each time
any user unsuccessfully attempts to access a registry object that has a matching SACL.
Event volume: Low to Medium, depending on how registry SACLs are configured.

Domain IF IF IF IF We strongly
Controller recommend that
you develop a
Registry Objects
Security
Monitoring
policy and define
appropriate
SACLs for
registry objects
for different
operating
system
templates and
roles. Do not
enable this
subcategory if
you have not
planned how to
use and analyze
the collected
information. It is
also important
to delete non-
effective, excess
SACLs.
Otherwise the
auditing log will
be overloaded
with useless
information.
Failure events
can show you
unsuccessful
attempts to
access specific
registry objects.
Consider
enabling this
subcategory for
critical
computers first,
after you
develop a
Registry Objects
Security
Monitoring
policy for them.
Member Server IF IF IF IF
Workstation IF IF IF IF
Events List:
4657(S): A registry value was modified.
5039(-): A registry key was virtualized.
4663(S): An attempt was made to access an
object.
Applies to
Windows 10
Windows Server 2016
Subcategories: Audit File
System, Audit Kernel Object,
Audit Registry, and Audit
Removable Storage
Event Description:
This event indicates that a
specific operation was
performed on an object. The
object could be a file system,
kernel, or registry object, or a
file system object on
removable storage or a
device.
This event generates only if
objects SACL has required
ACE to handle specific access
right use.
The main difference with
4656: A handle to an object
was requested. event is that
4663 shows that access right
was used instead of just
requested and 4663 doesnt have Failure events.
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions:
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made an attempt to access an object. Event Viewer
principal). Each account has a unique SID that is issued by an authority, such as an Active Directory
domain controller, and stored in a security database. Each time a user logs on, the system retrieves the
SID for that user from the database and places it in the access token for that user. The system uses the
SID in the access token to identify the user in all subsequent interactions with Windows security. When a
SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify
another user or group. For more information about SIDs, see Security identifiers.
Account Name [Type = UnicodeString]: the name of the account that made an attempt to access an
object.
events that might contain the same Logon ID, for example, 4624: An account was successfully logged
on.
Object:
Object Name [Type = UnicodeString]: name and other identifying information for the object for
which access was requested. For example, for a file, the path would be included.
Handle ID [Type = Pointer]: hexadecimal value of a handle to Object Name. This field can be used
for correlation with other events, for example with Handle ID field in 4656(S, F): A handle to an
object was requested. This parameter might not be captured in the event, and in that case appears as
0x0.
Resource Attributes [Type = UnicodeString] [Version 1]: attributes associated with the object. For
some objects, the field does not apply and - is displayed.
For example, for a file, the following might be displayed: S:AI(RA;ID;;;;WD;
("Impact_MS",TI,0x10020,3000))
Process ID [Type = Pointer]: hexadecimal Process ID of the process that accessed the object. Process
ID (PID) is a number used by the operating system to uniquely identify an active process. To see the
Accesses [Type = UnicodeString]: the list of access rights which were used by Subject\Security ID.
These access rights depend on Object Type. The following table contains information about the most
common access rights for file system objects. Access rights for registry objects are often similar to file
system objects, but the table contains a few notes about how they vary.
HEX VALUE,
%%4416 to read the corresponding file data.
(For registry objects, this is Query For a directory object, the right to
key value.) read the corresponding directory
data.
directory.
WriteData (or AddFile) 0x2, WriteData - For a file object, the

%%4417 right to write data to the file. For a
(For registry objects, this is Set key directory object, the right to create a
value.) file in the directory (FILE_ADD_FILE).

AddSubdirectory - For a directory,
the right to create a subdirectory.

(For registry objects, this is %%4419 attributes.
Enumerate sub-keys.)

%%4420 attributes.

Traverse - For a directory, the right
to traverse the directory. By default,
users are assigned the
HEX VALUE,


%%4423

%%4424

%%1537
READ_CONTROL 0x20000, The right to read the information in

%%1538 the object's security descriptor, not
including the information in the
system access control list (SACL).

%%1539 access control list (DACL) in the
object's security descriptor.


to wait until the object is in the
signaled state. Some object types do
not support this access right.

SACL in an object's security
descriptor.

Important For this event, also see Appendix A: Security monitoring recommendations for many audit
events.
If you have critical file system objects for which you need to monitor all access attempts, monitor this
event for Object Name.
If you have critical file system objects for which you need to monitor certain access attempts (for
example, write actions), monitor this event for Object Name in relation to Access Request
If Object Name is a sensitive or critical registry key for which you need to monitor specific access
attempts (for example, only write actions), monitor for all 4663 events with the corresponding Access
Request Information\Accesses.
If you have a pre-defined Process Name for the process reported in this event, monitor all events
with Process Name not equal to your defined value.
You can monitor to see if Process Name is not in a standard folder (for example, not in System32
or Program Files) or is in a restricted folder (for example, Temporary Internet Files).
If you have a pre-defined list of restricted substrings or words in process names (for example,
mimikatz or cain.exe), check for these substrings in Process Name.
For file system objects, we recommend that you monitor for these Access Request
Information\Accesses rights:
WriteEA
DeleteChild
WriteAttributes
DELETE
WRITE_DAC
WRITE_OWNER
Applies to
Windows 10
Windows Server 2016
Event Description:
This event indicates that specific access was requested for an object. The object could be a file system, kernel,
or registry object, or a file system object on removable storage or a device.
This event shows that access was requested, and the results of the request, but it doesnt show that the
operation was performed. To see that the operation was performed, check 4663(S): An attempt was made to
access an object.
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
(D;;LC;;;S-1-5-21-3457937927-2839227994-823803824-1104) %%4419: %%1809 %%4420: %%1809 %%4423: %%1811 D:
(A;OICI;FA;;;S-1-5-21-3457937927-2839227994-823803824-1104) %%4424: %%1809</Data>
</EventData>
</Event>

Event Versions:
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested a handle to an object. Event Viewer automatically
tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source
data in the event.
principal). Each account has a unique SID that is issued by an authority, such as an Active Directory
domain controller, and stored in a security database. Each time a user logs on, the system retrieves the
SID for that user from the database and places it in the access token for that user. The system uses the
SID in the access token to identify the user in all subsequent interactions with Windows security. When a
SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify
another user or group. For more information about SIDs, see Security identifiers.
events that might contain the same Logon ID, for example, 4624: An account was successfully logged
on.
Object:

Object Name [Type = UnicodeString]: name and other identifying information for the object for
which access was requested. For example, for a file, the path would be included.
attempt was made to access an object. This parameter might not be captured in the event, and in that
case appears as 0x0.
Resource Attributes [Type = UnicodeString] [Version 1]: attributes associated with the object. For
some objects, the field does not apply and - is displayed.
For example, for a file, the following might be displayed: S:AI(RA;ID;;;;WD;
("Impact_MS",TI,0x10020,3000))
Process ID [Type = Pointer]: hexadecimal Process ID of the process through which the access was
requested. Process ID (PID) is a number used by the operating system to uniquely identify an active
column):
Transaction ID [Type = GUID]: unique GUID of the transaction. This field can help you correlate this
event with other events that might contain the same Transaction ID, such as 4660(S): An object was
deleted.
This parameter might not be captured in the event, and in that case appears as {00000000-0000-
0000-0000-000000000000}.
These access rights depend on Object Type. The following table contains information about the most
common access rights for file system objects. Access rights for registry objects are often similar to file
system objects, but the table contains a few notes about how they vary.
HEXADECIMAL VALUE,
%%4416 to read the corresponding file data.
(For registry objects, this is Query For a directory object, the right to
key value.) read the corresponding directory
data.
directory.
HEXADECIMAL VALUE,
WriteData (or AddFile) 0x2, WriteData - For a file object, the

%%4417 right to write data to the file. For a
(For registry objects, this is Set key directory object, the right to create a
value.) file in the directory (FILE_ADD_FILE).

AddSubdirectory - For a directory,
the right to create a subdirectory.

(For registry objects, this is %%4419 attributes.
Enumerate sub-keys.)

%%4420 attributes.

Traverse - For a directory, the right
to traverse the directory. By default,
users are assigned the


%%4423

%%4424

%%1537
HEXADECIMAL VALUE,
READ_CONTROL 0x20000, The right to read the information in

%%1538 the object's security descriptor, not
including the information in the
system access control list (SACL).

%%1539 access control list (DACL) in the
object's security descriptor.


to wait until the object is in the
signaled state. Some object types do
not support this access right.

SACL in an object's security
descriptor.
Access Reasons [Type = UnicodeString] [Version 1]: the list of access check results. The format of this
varies, depending on the object. For kernel objects, this field does not apply.
Access Mask [Type = HexInt32]: hexadecimal mask for the requested or performed operation. For
more information, see the preceding table.

of a process.
initiate a process to replace the
default token associated with a
started subprocess.

operations.
bypass file and directory, registry, and
other persistent object permissions
for the purposes of backing up the
system.
grant all read access control to any
file, regardless of the access control
list (ACL) specified for the file. Any
access request other than read is still
access rights are granted if this
privilege is held:
READ_CONTROL
FILE_GENERIC_READ
FILE_TRAVERSE

privilege also causes the system to
skip all traversal access checks.
traverse directory trees even though
the user may not have permissions
on the traversed directory. This
privilege does not allow the user to
list the contents of a directory, only to
traverse directories.
SeCreateGlobalPrivilege Create global objects Required to create named file

mapping objects in the global
namespace during Terminal Services
sessions.
SeCreatePermanentPrivilege Create permanent shared objects Required to create a permanent

object.
necessary to assign them the
privilege.


creation APIs.
When a process requires this
privilege, we recommend using the
LocalSystem account (which already
includes the privilege), rather than
creating a separate user account and
assigning this privilege to it.

memory of a process owned by
another account.
attach a debugger to any process or
to the kernel. Developers who are
debugging their own applications do
not need this user right. Developers
who are debugging new system
components need this user right. This
user right provides complete access
to sensitive and critical operating
system components.
SeEnableDelegationPrivilege Enable computer and user accounts Required to mark user and computer
to be trusted for delegation accounts as trusted for delegation.
With this privilege, the user can set
the Trusted for Delegation setting
on a user or computer object.
privilege must have write access to
the account control flags on the user
or computer object. A server process
running on a computer (or under a
user context) that is trusted for
delegation can access resources on
another computer using the
delegated credentials of a client, as
long as the account of the client does
not have the Account cannot be
delegated account control flag set.
SeIncreaseBasePriorityPrivilege Increase scheduling priority Required to increase the base priority

of a process.
execution priority assigned to the
other process. A user with this
privilege can change the scheduling
priority of a process through the Task
Manager user interface.
SeIncreaseQuotaPrivilege Adjust memory quotas for a process Required to increase the quota
assigned to a process.
change the maximum memory that
can be consumed by a process.
users.
driver.
drivers or other code in to kernel
mode. This user right does not apply
to Plug and Play device drivers.

memory.
from paging the data to virtual
memory on disk. Exercising this
privilege could significantly affect
system performance by decreasing
the amount of available random
access memory (RAM).
SeMachineAccountPrivilege Add workstations to domain With this privilege, the user can create
a computer account.
controllers.
SeManageVolumePrivilege Perform volume maintenance tasks Required to run maintenance tasks on

a volume, such as remote
defragmentation.
SeProfileSingleProcessPrivilege Profile single process Required to gather profiling

information for a single process.
system processes.

SeRemoteShutdownPrivilege Force shutdown from a remote Required to shut down a system

system using a network request.
SeRestorePrivilege Restore files and directories Required to perform restore

operations. This privilege causes the
system to grant all write access
control to any file, regardless of the
ACL specified for the file. Any access
request other than write is still
evaluated with the ACL. Additionally,
this privilege enables you to set any
valid user or group SID as the owner
of a file. The following access rights
are granted if this privilege is held:
WRITE_DAC
WRITE_OWNER
FILE_GENERIC_WRITE
FILE_ADD_FILE
DELETE
bypass file, directory, registry, and
other persistent objects permissions
when restoring backed up files and
directories and determines which
users can set any valid security
principal as the owner of an object.

controlling and viewing audit events
in security event log.
specify object access auditing options
for individual resources, such as files,
Active Directory objects, and registry
keys.
A user with this privilege can also
view and clear the security log.
SeSyncAgentPrivilege Synchronize directory service data This privilege enables the holder to
read all objects and properties in the
synchronization.

information.
SeSystemProfilePrivilege Profile system performance Required to gather profiling

information for the entire system.
processes.
change the time and date on the
internal clock of the computer. Users
that are assigned this user right can
affect the appearance of event logs. If
the system time is changed, events
that are logged will reflect this new
time, not the actual time that the
events occurred.
SeTakeOwnershipPrivilege Take ownership of files or other Required to take ownership of an

objects object without being granted
discretionary access. This privilege
allows the owner value to be set only
to those values that the holder may
legitimately assign as the owner of an
object.
SeTcbPrivilege Act as part of the operating system This privilege identifies its holder as
part of the trusted computer base.
therefore gain access to the same
local resources as that user.
associated with the computer's
internal clock.
SeTrustedCredManAccessPrivilege Access Credential Manager as a Required to access Credential

trusted caller Manager as a trusted caller.
SeUndockPrivilege Remove computer from docking Required to undock a laptop.

station With this privilege, the user can
undock a portable computer from its
docking station without logging on.
SeUnsolicitedInputPrivilege Not applicable Required to read unsolicited input

from a terminal device.
Object Types.
Important For this event, also see Appendix A: Security monitoring recommendations for many audit
events.
If you have a pre-defined Process Name for the process reported in this event, monitor all events
with Process Name not equal to your defined value.
You can monitor to see if Process Name is not in a standard folder (for example, not in System32
or Program Files) or is in a restricted folder (for example, Temporary Internet Files).
If you have a pre-defined list of restricted substrings or words in process names (for example,
mimikatz or cain.exe), check for these substrings in Process Name.
If Object Name is a sensitive or critical object for which you need to monitor any access attempt,
monitor all 4656 events.
If Object Name is a sensitive or critical object for which you need to monitor specific access attempts
If you need to monitor files and folders with specific Resource Attribute values, monitor for all 4656
events with specific Resource Attributes field values.
For file system objects, we recommend that you monitor these Access Request
Information\Accesses rights (especially for Failure events):
WriteEA
DeleteChild
WriteAttributes
DELETE
WRITE_DAC
WRITE_OWNER
Applies to
Windows 10
Windows Server 2016
Handle Manipulation, Audit Kernel Object,
Audit Registry, and Audit Removable Storage
Event Description:
device.
This event generates only if Success auditing
is enabled for Audit Handle Manipulation
subcategory.
open. Otherwise, it might not have any
security relevance.
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Account Name [Type = UnicodeString]: the name of the account that requested the close objects
handle operation.
the following:
Object:
appears as 0x0.
Process ID [Type = Pointer]: hexadecimal Process ID of the process that requested that the handle be
closed. Process ID (PID) is a number used by the operating system to uniquely identify an active process. To

Applies to
Windows 10
Windows Server 2016
Kernel Object, and Audit Registry
Event Description:
This event generates only if Delete" auditing
is set in objects SACL.
deleted object (only the Handle ID). It is
better to use 4663(S): An attempt was made
to access an object with DELETE access to
track object deletion.
generated only during real delete operations.
In contrast, 4663(S): An attempt was made
to access an object also generates during
other actions, such as object renaming.
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
operation.
the following:
Object:
appears as 0x0.
Process ID [Type = Pointer]: hexadecimal Process ID of the process that deleted the object. Process ID
was requested.
0000-000000000000}.
parse or analyze. There is no recommendation for auditing them, unless you know exactly what you need
to monitor at the Kernel objects level.
4657(S): A registry value was modified.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Registry
Event Description:
This event generates when a registry key value
was modified. It doesnt generate when a
registry key was modified.
This event generates only if Set Value"
auditing is set in registry keys SACL.

Event XML:
- <System>
<Level>0</Level>
<Task>12801</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectName">\\REGISTRY\\MACHINE</Data>
<Data Name="ObjectValueName">Name\_New</Data>
<Data Name="OperationType">%%1905</Data>
<Data Name="OldValueType">%%1873</Data>
<Data Name="OldValue" />
<Data Name="NewValueType">%%1873</Data>
<Data Name="NewValue">Andrei</Data>
<Data Name="ProcessId">0xce4</Data>
<Data Name="ProcessName">C:\\Windows\\regedit.exe</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the modify registry value operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the modify registry value
operation.
the following:
Object:
Object Name [Type = UnicodeString]: full path and name of the registry key which value was modified. The
format is: \REGISTRY\HIVE\PATH where:
HIVE:
HKEY_LOCAL_MACHINE = \REGISTRY\MACHINE
HKEY_CURRENT_USER = \REGISTRY\USER\[USER_SID], where [USER_SID] is the SID of
current user.
HKEY_CLASSES_ROOT = \REGISTRY\MACHINE\SOFTWARE\Classes
HKEY_USERS = \REGISTRY\USER
HKEY_CURRENT_CONFIG = \REGISTRY\MACHINE\SYSTEM\ControlSet001\Hardware
Profiles\Current
PATH path to the registry key.
Object Value Name [Type = UnicodeString]: the name of modified registry key value.
correlate this event with other events that might contain the same Handle ID, for example, 4656: A handle
to an object was requested. This parameter might not be captured in the event, and in that case appears as
0x0.
Operation Type [Type = UnicodeString]: the type of performed operation with registry key value. Most
common operations are:
New registry value created
Registry value deleted
Existing registry value modified
Process ID [Type = Pointer]: hexadecimal Process ID of the process through which the registry key value
was modified. Process ID (PID) is a number used by the operating system to uniquely identify an active
column):
Change Information:
Old Value Type [Type = UnicodeString]: old type of changed registry key value. Registry key value types:
VALUE TYPE DESCRIPTION
REG_SZ String
REG_BINARY Binary
REG_DWORD DWORD (32-bit) Value
REG_QWORD QWORD (64-bit) Value
REG_MULTI_SZ Multi-String Value
REG_EXPAND_SZ Expandable String Value
Old Value [Type = UnicodeString]: old value for changed registry key value.
New Value Type [Type = UnicodeString]: new type of changed registry key value. See table above for
possible values.
New Value [Type = UnicodeString]: new value for changed registry key value.

For 4657(S): A registry value was modified.
If Object Name is a sensitive or critical registry key for which you need to monitor any modification of its
values, monitor all 4657 events.
If Object Name has specific values (Object Value Name) and you need to monitor modifications of these
values, monitor for all 4657 events.
5039(-): A registry key was virtualized.
Applies to
Windows 10
Windows Server 2016
This event should be generated when registry key was virtualized using LUAFV.
This event occurs very rarely during during standard LUAFV registry key virtualization.
Subcategory: Audit Registry
Event Schema:
A registry key was virtualized.
Subject:
Security ID:%1%
Account Name:%2
Account Domain:%3
Logon ID:%4
Object:
Key Name:%5
Virtual Key Name:%6
Process ID:%7
Process Name%8

Event Versions: 0.

Applies to
Windows 10
Windows Server 2016
Event Description:
SACL.

Event XML:
- <System>
<Level>0</Level>
<Task>13570</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
the following:
Object:
typically equals -.
appears as 0x0.
Process:
Permissions Change:
Example:
table below:

Windows 2000


operators

administrators

controllers
G: = Primary Group.
D: = DACL Entries.
S: = SACL Entries.
entry_type:
D - DACL
S - SACL
inheritance_flags:
ace_type:
"D" - ACCESS DENIED
"AU" - SYSTEM AUDIT
"A" - SYSTEM ALARM
ace_flags:

rights

"KX" KEY EXECUTE
object_guid: N/A

document.
Audit Removable Storage
Applies to
Windows 10
Windows Server 2016
Audit Removable Storage allows you to audit user attempts to access file system objects on a removable
storage device. A security audit event is generated for all objects and all types of access requested, with no
dependency on objects SACL.
STRONGER STRONGER
STRONGER STRONGER
Domain Yes Yes Yes Yes This subcategory

Controller will help identify
when and which
files or folders
were accessed or
modified on
removable
devices.
It is often useful
to track actions
with removable
storage devices
and the files or
folders on them,
because
malicious
software very
often uses
removable
devices as a
method to get
into the system.
At the same
time, you will be
able to track
which files were
written or
executed from a
removable
storage device.
You can track,
for example,
actions with files
or folders on
USB flash drives
or sticks that
were inserted
into domain
controllers or
high value
servers, which is
typically not
allowed.
We recommend
Failure auditing
to track failed
access attempts.
Member Server Yes Yes Yes Yes
Workstation Yes Yes Yes Yes
Events List:
Audit SAM
Applies to
Windows 10
Windows Server 2016
Audit SAM, which enables you to audit events that are generated by attempts to access Security Account Manager
(SAM) objects.
The Security Account Manager (SAM) is a database that is present on computers running Windows operating
systems that stores user accounts and security descriptors for users on the local computer.
SAM objects include the following:
SAM_ALIAS: A local group
SAM_GROUP: A group that is not a local group
SAM_USER: A user account
SAM_DOMAIN: A domain
SAM_SERVER: A computer account
If you configure this policy setting, an audit event is generated when a SAM object is accessed. Success audits
record successful attempts, and failure audits record unsuccessful attempts.
Only a SACL for SAM_SERVER can be modified.
Changes to user and group objects are tracked by the Account Management audit category. However, user
accounts with enough privileges could potentially alter the files in which the account and password information is
stored in the system, bypassing any Account Management events.
Event volume: High on domain controllers.
For information about reducing the number of events generated in this subcategory, see KB841001.
STRONGER STRONGER
Domain - - - - There is no
Controller recommendation
for this
subcategory in
this document,
unless you know
exactly what you
need to monitor
at Security
Account
Manager level.
STRONGER STRONGER
Member Server - - - - There is no

recommendation
for this
subcategory in
this document,
unless you know
exactly what you
need to monitor
at Security
Account
Manager level.
Workstation - - - - There is no
recommendation
for this
subcategory in
this document,
unless you know
exactly what you
need to monitor
at Security
Account
Manager level.
Events List:
Applies to
Windows 10
Windows Server 2016
Subcategories: Audit Directory Service Access
and Audit SAM
Event Description:
This event indicates that a handle was
requested for either an Active Directory object
or a Security Account Manager (SAM) object.
If access was declined, then Failure event is
generated.
This event generates only if Success auditing
is enabled for the Audit Handle Manipulation
subcategory.

Event XML:
- <System>
<Level>0</Level>
<Task>14080</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectServer">Security Account Manager</Data>
<Data Name="ObjectType">SAM\_DOMAIN</Data>
<Data Name="ObjectName">DC=contoso,DC=local</Data>
<Data Name="HandleId">0xdd64d36870</Data>
<Data Name="AccessMask">0x2d</Data>
<Data Name="PrivilegeList"></Data>
<Data Name="Properties">-</Data>
<Data Name="ProcessId">0x9000a000d002d</Data>
<Data Name="ProcessName">{bf967a90-0de6-11d0-a285-00aa003049e2} %%5400 {ccc2dc7d-a6ad-4a7a-8846-c04e3cc53501}
</Data>
</EventData>
</Event>
Required Server Roles: For an Active Directory object, the domain controller role is required. For a SAM object,
there is no required role.
Event Versions: 0.
Field Descriptions:
Subject:
event.
the following:
Object:
Object Server [Type = UnicodeString]: has Security Account Manager value for this event.
Object Type [Type = UnicodeString]: the type or class of the object that was accessed. The following list
contains possible values for this field:
SAM_ALIAS - a local group.
SAM_GROUP - a group that is not a local group.
SAM_USER - a user account.
SAM_DOMAIN - a domain. For Active Directory events, this is the typical value.
SAM_SERVER - a computer account.
Object Name [Type = UnicodeString]: the name of an object for which access was requested. Depends on
Object Type. This event can have the following format:
SAM_ALIAS SID of the group.
SAM_GROUP - SID of the group.
SAM_USER - SID of the account.
SAM_DOMAIN distinguished name of the accessed object.
SAM_SERVER - distinguished name of the accessed object.
attributes:
CN - commonName
this event with other events that might contain the same Handle ID, for example, 4662: An operation was
performed on an object. This parameter might not be captured in the event, and in that case appears as 0x0.
Process ID [Type = Pointer]: hexadecimal Process ID of the process that requested the handle. Process ID
with other events that might contain the same the Transaction ID, such as 4660(S): An object was
deleted.
0000-000000000000}.
These access rights depend on Object Type. See Table 13. File access codes. for more information about
file access rights. For information about SAM object access right use https://technet.microsoft.com/ or other
informational resources.
Table 13. File access codes. for more information about file access rights. For information about SAM
object access right use https://technet.microsoft.com/ or other informational resources.

of a process.

operations.
is held:
READ_CONTROL
FILE_GENERIC_READ
FILE_TRAVERSE

the user may not have permissions on
the traversed directory. This privilege
does not allow the user to list the
contents of a directory, only to traverse
directories.




creation APIs.

account.
components.

a process.
interface.
users.
driver.

memory.
computer account.
controllers.

defragmentation.

system processes.

SeRemoteShutdownPrivilege Force shutdown from a remote system Required to shut down a system using
a network request.

held:
WRITE_DAC
WRITE_OWNER
FILE_GENERIC_WRITE
FILE_ADD_FILE
DELETE
an object.

security event log.
synchronization.

information.

processes.
clock.



a terminal device.
Properties [Type = UnicodeString]: depends on Object Type. This field can be empty or contain the list of
the object properties that were accessed. See more detailed information in 4661: A handle to an object was
requested from Audit SAM subcategory.
Object Types.
You can get almost the same information from 4662: An operation was performed on an object. There are no
additional recommendations for this event in this document.
Audit Central Access Policy Staging
Applies to
Windows 10
Windows Server 2016
Audit Central Access Policy Staging allows you to audit access requests where a permission granted or denied by a
proposed policy differs from the current central access policy on an object.
If you configure this policy setting, an audit event is generated each time a user accesses an object and the
permission granted by the current central access policy on the object differs from that granted by the proposed
policy. The resulting audit event is generated as follows:
Success audits, when configured, record access attempts when the current central access policy grants
access, but the proposed policy denies access.
Failure audits, when configured, record access attempts when:
The current central access policy does not grant access, but the proposed policy grants access.
A principal requests the maximum access rights they are allowed and the access rights granted by the
current central access policy are different than the access rights granted by the proposed policy.
STRONGER STRONGER
Domain IF No IF No IF - Enable this

Controller subcategory if
you need to test
or troubleshoot
Dynamic Access
Control Proposed
Central Access
Policies.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Member Server IF No IF No IF - Enable this

subcategory if
you need to test
or troubleshoot
Dynamic Access
Control Proposed
Central Access
Policies.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Workstation IF No IF No IF - Enable this

subcategory if
you need to test
or troubleshoot
Dynamic Access
Control Proposed
Central Access
Policies.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Events List:
4818(S): Proposed Central Access Policy does not grant the same access permissions as the current Central
Access Policy.
4818(S): Proposed Central Access Policy does not
grant the same access permissions as the current
Central Access Policy.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Central Policy Staging

Event Description:
This event generates when Dynamic Access Control Proposed Central Access Policy is enabled and access was not
granted by Proposed Central Access Policy.
Event XML:
- <System>
<Level>0</Level>
<Task>12813</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectUserName">Auditor</Data>
<Data Name="SubjectLogonId">0x1e5f21</Data>
<Data Name="ObjectName">C:\\Finance Documents\\desktop.ini</Data>
<Data Name="HandleId">0xc64</Data>
<Data Name="ProcessName" />
<Data Name="AccessReason">%%1538: %%1801 D:(A;ID;0x1200a9;;;BU) %%1541: %%1801 D:(A;ID;0x1200a9;;;BU) %%4416:
%%1801 D:(A;ID;0x1200a9;;;BU) %%4419: %%1801 D:(A;ID;0x1200a9;;;BU) %%4423: %%1801 D:(A;ID;0x1200a9;;;BU)
</Data>
<Data Name="StagingReason">%%1538: %%1814Finance Documents Rule %%1541: %%1814Finance Documents Rule %%4416:
%%1814Finance Documents Rule %%4419: %%1814Finance Documents Rule %%4423: %%1814Finance Documents Rule</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made an access request. Event Viewer automatically tries to
Account Name [Type = UnicodeString]: the name of the account that made an access request.
the following:
Object:
Object Name [Type = UnicodeString]: full path and name of the file or folder for which access was
requested.
appears as 0x0.
Current Central Access Policy results:
Access Reasons [Type = UnicodeString]: the list of access check results for Current Access Policy. The format of
the result is:
REQUESTED_ACCESS: RESULT ACE_WHICH_PROVIDED_OR_DENIED_ACCESS.

The possible REQUESTED_ACCESS values are listed in the table below.
Table of file access codes

ACCESS HEXADECIMAL VALUE DESCRIPTION
ReadData (or ListDirectory) 0x1 ReadData - For a file object, the right
to read the corresponding file data. For
directory.
WriteData (or AddFile) 0x2 WriteData - For a file object, the right
to write data to the file. For a directory
AppendData (or AddSubdirectory or 0x4 AppendData - For a file object, the

CreatePipeInstance) right to append data to the file. (For
ReadEA 0x8 The right to read extended file

attributes.
WriteEA 0x10 The right to write extended file

attributes.
Execute/Traverse 0x20 Execute - For a native code file, the

right to execute the file. This access
are assigned the
DeleteChild 0x40 For a directory, the right to delete a

directory and all the files it contains,
ReadAttributes 0x80 The right to read file attributes.
WriteAttributes 0x100 The right to write file attributes.
DELETE 0x10000 The right to delete the object.
READ_CONTROL 0x20000 The right to read the information in the

object's security descriptor, not
WRITE_DAC 0x40000 The right to modify the discretionary

access control list (DACL) in the object's
WRITE_OWNER 0x80000 The right to change the owner in the

object's security descriptor
SYNCHRONIZE 0x100000 The right to use the object for

this access right.
ACCESS_SYS_SEC 0x1000000 The ACCESS_SYS_SEC access right

controls the ability to get or set the
RESULT:
Granted by
Denied by
Granted by ACE on parent folder
Not granted due to missing after this sentence you will typically see missing user rights, for example
SeSecurityPrivilege.
Unknown or unchecked
ACE_WHICH_PROVIDED_OR_DENIED_ACCESS:
Ownership if access was granted because of ownership of an object.
User Right name, for example SeSecurityPrivilege.
The Security Descriptor Definition Language (SDDL) value for the Access Control Entry (ACE) that
granted or denied access.
Proposed Central Access Policy results that differ from the current Central Access Policy results:
Access Reasons [Type = UnicodeString]: the list of access check results for Proposed Central Access Policy.
Here you will see only denied requests. The format of the result is:
REQUESTED_ACCESS: NOT Granted by RULE_NAME Rule.

The possible REQUESTED_ACCESS values are listed in the table below:
ReadData (or ListDirectory) 0x1 ReadData - For a file object, the right
to read the corresponding file data. For
directory.
WriteData (or AddFile) 0x2 WriteData - For a file object, the right
to write data to the file. For a directory
AppendData (or AddSubdirectory or 0x4 AppendData - For a file object, the

CreatePipeInstance) right to append data to the file. (For
ReadEA 0x8 The right to read extended file

attributes.
WriteEA 0x10 The right to write extended file

attributes.
Execute/Traverse 0x20 Execute - For a native code file, the

right to execute the file. This access
are assigned the
DeleteChild 0x40 For a directory, the right to delete a

directory and all the files it contains,
ReadAttributes 0x80 The right to read file attributes.
WriteAttributes 0x100 The right to write file attributes.
DELETE 0x10000 The right to delete the object.
READ_CONTROL 0x20000 The right to read the information in the

object's security descriptor, not
WRITE_DAC 0x40000 The right to modify the discretionary

access control list (DACL) in the object's
WRITE_OWNER 0x80000 The right to change the owner in the

object's security descriptor
SYNCHRONIZE 0x100000 The right to use the object for

this access right.
ACCESS_SYS_SEC 0x1000000 The ACCESS_SYS_SEC access right

controls the ability to get or set the
RULE_NAME: the name of Central Access Rule which denied the access.

For 4818(S): Proposed Central Access Policy does not grant the same access permissions as the current Central
Access Policy.
This event typically used for troubleshooting and testing of Proposed Central Access Policies for Dynamic Access
Control.
Audit Audit Policy Change
Applies to
Windows 10
Windows Server 2016
Audit Audit Policy Change determines whether the operating system generates audit events when changes are
made to audit policy.
Event volume: Low.
STRONGER STRONGER
Domain Yes No Yes No Almost all events

Controller in this
subcategory have
security relevance
and should be
monitored.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Member Server Yes No Yes No Almost all events

in this
subcategory have
security relevance
and should be
monitored.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Workstation Yes No Yes No Almost all events

in this
subcategory have
security relevance
and should be
monitored.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Changes to audit policy that are audited include:

Changing permissions and audit settings on the audit policy object (by using auditpol /set /sd command).
Changing the system audit policy.
Registering and unregistering security event sources.
Changing per-user audit settings.
Changing the value of CrashOnAuditFail.
Changing audit settings on an object (for example, modifying the system access control list (SACL) for a file
or registry key).
Note SACL change auditing is performed when a SACL for an object has changed and the Policy Change
category is configured. Discretionary access control list (DACL) and owner change auditing are performed
when Object Access auditing is configured and the object's SACL is set for auditing of the DACL or owner
change.
Changing anything in the Special Groups list.

The following events will be enabled with Success auditing in this subcategory:
4902(S): The Per-user audit policy table was created.
4907(S): Auditing settings on object were changed.
4904(S): An attempt was made to register a security event source.
4905(S): An attempt was made to unregister a security event source.
All other events in this subcategory will be logged regardless of the "Audit Policy Change" setting.
Events List:
4715(S): The audit policy (SACL) on an object was changed.
4719(S): System audit policy was changed.
4906(S): The CrashOnAuditFail value has changed.
4908(S): Special Groups Logon table modified.
4912(S): Per User Audit Policy was changed.
4904(S): An attempt was made to register a security event source.
4905(S): An attempt was made to unregister a security event source.
Applies to
Windows 10
Windows Server 2016
Event Description:
SACL.

Event XML:
- <System>
<Level>0</Level>
<Task>13570</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
the following:
Object:
typically equals -.
appears as 0x0.
Process:
Permissions Change:
Example:
table below:

Windows 2000


operators

administrators

controllers
G: = Primary Group.
D: = DACL Entries.
S: = SACL Entries.
entry_type:
D - DACL
S - SACL
inheritance_flags:
ace_type:
"D" - ACCESS DENIED
"AU" - SYSTEM AUDIT
"A" - SYSTEM ALARM
ace_flags:

rights

"KX" KEY EXECUTE
object_guid: N/A

document.
4715(S): The audit policy (SACL) on an object was
changed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Policy Change

Event Description:
This event generates every time local audit policy security descriptor changes.
This event is always logged regardless of the "Audit Policy Change" sub-category setting.
Event XML:
- <System>
<Level>0</Level>
<Task>13568</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectLogonId">0x11ae30</Data>
<Data Name="OldSd">D:(A;;DCSWRPDTRC;;;BA)(D;;DCSWRPDTRC;;;SY)S:NO\_ACCESS\_CONTROL</Data>
<Data Name="NewSd">D:(A;;DCSWRPDTRC;;;BA)(A;;DCSWRPDTRC;;;SY)S:NO\_ACCESS\_CONTROL</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the change local audit policy security descriptor
(SACL) operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID
Account Name [Type = UnicodeString]: the name of the account that requested the change local audit
policy security descriptor (SACL) operation.
the following:
Audit Policy Change:
(SDDL) value for the audit policy.
New Security Descriptor [Type = UnicodeString]: new Security Descriptor Definition Language (SDDL)
value for the audit policy.
Example:
table below:

Windows 2000

operators

administrators


controllers
G: = Primary Group.
D: = DACL Entries.
S: = SACL Entries.
entry_type:
D - DACL
S - SACL
inheritance_flags:
ace_type:
"D" - ACCESS DENIED
"AU" - SYSTEM AUDIT
"A" - SYSTEM ALARM
ace_flags:

rights
"KX" KEY EXECUTE
object_guid: N/A

For 4715(S): The audit policy (SACL) on an object was changed.
Monitor for all events of this type, especially on high value assets or computers, because any change of the local
audit policy security descriptor should be planned. If this action was not planned, investigate the reason for the
change.
4719(S): System audit policy was changed.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates when the computer's
audit policy changes.
This event is always logged regardless of the
"Audit Policy Change" sub-category setting.

event.
Event XML:
- <System>
<Level>0</Level>
<Task>13568</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="CategoryId">%%8274</Data>
<Data Name="SubcategoryId">%%12807</Data>
<Data Name="SubcategoryGuid">{0CCE9223-69AE-11D9-BED3-505054503030}</Data>
<Data Name="AuditPolicyChanges">%%8448, %%8450</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made a change to local audit policy. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: the name of the account that made a change to local audit policy.
the following:
Audit Policy Change:
Category: the name of auditing Category which subcategory was changed. Possible values:
Account Logon
Account Management
Detailed Tracking
DS Access
Logon/Logoff
Object Access
Policy Change
Privilege Use
System
Subcategory: the name of auditing Subcategory which was changed. Possible values:
CREDENTIAL VALIDATION PROCESS TERMINATION NETWORK POLICY SERVER
Kerberos Authentication Service RPC Events Other Logon/Logoff Events
Kerberos Service Ticket Operations Detailed Directory Service Replication Special Logon
Other Logon/Logoff Events Directory Service Access Application Generated
Application Group Management Directory Service Changes Certification Services
Computer Account Management Directory Service Replication Detailed File Share
Distribution Group Management Account Lockout File Share
Other Account Management Events IPsec Extended Mode File System
Security Group Management IPsec Main Mode Filtering Platform Connection
User Account Management IPsec Quick Mode Filtering Platform Packet Drop
DPAPI Activity Logoff Handle Manipulation
Process Creation Logon Kernel Object
Other Object Access Events Filtering Platform Policy Change IPsec Driver
CREDENTIAL VALIDATION PROCESS TERMINATION NETWORK POLICY SERVER
Registry MPSSVC Rule-Level Policy Change Other System Events
SAM Other Policy Change Events Security State Change
Policy Change Non-Sensitive Privilege Use Security System Extension
Authentication Policy Change Sensitive Privilege Use System Integrity
Authorization Policy Change Other Privilege Use Events Plug and Play Events
Group Membership
Subcategory GUID: the unique subcategory GUID. To see Subcategory GUIDs you can use this command:
auditpol /list /subcategory:* /v.
Changes: changes which were made for Subcategory. Possible values:

Success removed
Failure removed
Success added
Failure added
It can be also a combination of any of the items above, separated by coma.

For 4719(S): System audit policy was changed.
Monitor for all events of this type, especially on high value assets or computers, because any change in local
audit policy should be planned. If this action was not planned, investigate the reason for the change.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit
Policy Change
Event Description:
when the Global
Object Access Auditing
policy is changed on a
computer.
Separate events will be
generated for
Registry and File
system policy
changes.
Note For
recommendations,
see Security
Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>13568</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectServer">LSA</Data>
<Data Name="ObjectType">Global SACL</Data>
<Data Name="ObjectName">Key</Data>
<Data Name="OldSd" />
<Data Name="NewSd">S:(AU;SA;RC;;;S-1-5-21-3457937927-2839227994-823803824-1104)</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made a change to Global Object Access Auditing policy. Event
Account Name [Type = UnicodeString]: the name of the account that made a change to Global Object
Access Auditing policy.
the following:
Object:
Object Server [Type = UnicodeString]: has LSA value for this event.
Object Type [Type = UnicodeString]: The type of an object to which this event applies. Always Global
SACL for this event.
Profile Desktop KeyedEvent Central Access Policies
Key WaitablePort Callback Global SACL
Job Port FilterConnectionPort
ALPC Port Semaphore Adapter
**Object Name: **
Key if Registry Global Object Access Auditing policy was changed.
File if File system Global Object Access Auditing policy was changed.
Auditing Settings:
(SDDL) value for the Global Object Access Auditing policy. Empty if Global Object Access Auditing policy
SACL was not set.
value for the Global Object Access Auditing policy.
Example:
table below:

Windows 2000

operators

administrators

controllers
G: = Primary Group.
D: = DACL Entries.
S: = SACL Entries.
entry_type:
D - DACL
S - SACL
inheritance_flags:
ace_type:
"D" - ACCESS DENIED
"AU" - SYSTEM AUDIT
"A" - SYSTEM ALARM
ace_flags:

rights

"KX" KEY EXECUTE
object_guid: N/A

For 4817(S): Auditing settings on object were changed.
If you use Global Object Access Auditing policies, then this event should be always monitored, especially on
high value assets or computers. If this change was not planned, investigate the reason for the change.
If you dont use Global Object Access Auditing policies, then this event should be always monitored because
it indicates use of Global Object Access Auditing policies outside of your standard procedures.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates during system startup if
Per-user audit policy is defined on the
computer.

Event XML:
- <System>
<Level>0</Level>
<Task>13568</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="PuaCount">1</Data>
<Data Name="PuaPolicyId">0x703e</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Number of Elements [Type = UInt32]: number of users for which Per-user policies were defined (number of
unique users). You can get the list of users for which Per-user policies are defined using auditpol /list /user
command:
Policy ID [Type = HexInt64]: unique per-User Audit Policy hexadecimal identifier.

For 4902(S): The Per-user audit policy table was created.
If you dont expect to see any per-User Audit Policies enabled on specific computers (Computer), monitor
for these events.
If you dont use per-User Audit Policies in your network, monitor for these events.
Typically this is an informational event and has little to no security relevance.
4906(S): The CrashOnAuditFail value has changed.
Applies to
Windows 10
Windows Server 2016
Event Description:
CrashOnAuditFail audit flag value was
modified.
More information about CrashOnAuditFail
flag can be found here.

Event XML:
- <System>
<Level>0</Level>
<Task>13568</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="CrashOnAuditFailValue">1</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
New Value of CrashOnAuditFail [Type = UInt32]: contains new value of CrashOnAuditFail flag. Possible values
are:
0 - The feature is off. The system does not halt, even when it cannot record events in the Security Log.
1 - The feature is on. The system halts when it cannot record an event in the Security Log.
2 - The feature is on and has been triggered. The system halted because it could not record an auditable
event in the Security Log. Only members of the Administrators group can log on.

For 4906(S): The CrashOnAuditFail value has changed.
Any changes of CrashOnAuditFail audit flag that are reported by this event must be monitored, and an alert
should be triggered. If this change was not planned, investigate the reason for the change.
Applies to
Windows 10
Windows Server 2016

Event Description:
This event generates when the SACL of an object (for example, a registry key or file) was changed.
This event doesn't generate for Active Directory objects.
Event XML:
- <System>
<Level>0</Level>
<Task>13568</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectLogonId">0x138eb0</Data>
<Data Name="ObjectType">Key</Data>
<Data Name="ObjectName">\\REGISTRY\\MACHINE\\SYSTEM\\ControlSet001\\Services\\EventLog\\Internet
Explorer</Data>
<Data Name="OldSd">S:AI</Data>
<Data Name="NewSd">S:ARAI(AU;CISA;KA;;;S-1-5-21-3457937927-2839227994-823803824-1104)</Data>
<Data Name="ProcessName">C:\\Windows\\regedit.exe</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made a change to objects auditing settings. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that made a change to objects auditing
settings.
the following:
Object:
Profile Desktop KeyedEvent SC_MANAGER OBJECT
Key WaitablePort Callback
Object Name [Type = UnicodeString]: full path and name of the object for which the SACL was modified.
Depends on Object Type. Here are some examples:
The format for Object Type = Key is: \REGISTRY\HIVE\PATH where:
HIVE:
HKEY_LOCAL_MACHINE = \REGISTRY\MACHINE
HKEY_CURRENT_USER = \REGISTRY\USER\[USER_SID], where [USER_SID] is the SID of
current user.
HKEY_CLASSES_ROOT = \REGISTRY\MACHINE\SOFTWARE\Classes
HKEY_USERS = \REGISTRY\USER
HKEY_CURRENT_CONFIG = \REGISTRY\MACHINE\SYSTEM\ControlSet001\Hardware
Profiles\Current
PATH path to the registry key.
The format for Object Type = File is: full path and name of the file or folder for which SACL was
modified.
to an object was requested. Event for registry keys or with Handle ID field in 4656(S, F): A handle to an
object was requested. Event for file system objects. This parameter might not be captured in the event, and
in that case appears as 0x0.
Process ID [Type = Pointer]: hexadecimal Process ID of the process through which the objects SACL was
Auditing Settings:
Example:
table below:

Windows 2000

operators

administrators

controllers
G: = Primary Group.
D: = DACL Entries.
S: = SACL Entries.
entry_type:
D - DACL
S - SACL
inheritance_flags:
ace_type:
"D" - ACCESS DENIED
"AU" - SYSTEM AUDIT
"A" - SYSTEM ALARM
ace_flags:

rights

"KX" KEY EXECUTE
object_guid: N/A

For 4907(S): Auditing settings on object were changed.
If you need to monitor events related to specific Windows object types (Object Type), for example File or
Key, monitor this event for the corresponding Object Type.
If you need to monitor all SACL changes for specific files, folders, registry keys, or other object types,
monitor for Object Name field value which has specific object name.
If you have critical file or registry objects and you need to monitor all modifications (especially changes in
SACL), monitor for specific Object\Object Name.
If you have high-value computers for which you need to monitor all changes for all or specific file or registry
objects, monitor for all 4907 events on these computers.
4908(S): Special Groups Logon table modified.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time Special Groups
logon table was modified.
This event also generates during system
startup.
More information about Special Groups
auditing can be found here:
http://blogs.technet.com/b/askds/archive/2008/03/11/special-groups-auditing-via-group-policy-preferences.aspx
https://support.microsoft.com/en-us/kb/947223
Event XML:
- <System>
<Level>0</Level>
<Task>13568</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SidList">%{S-1-5-21-3457937927-2839227994-823803824-512}</Data>
</EventData>
</Event>
Event Versions: 0.
Field Descriptions:
Special Groups [Type = UnicodeString]: contains current list of SIDs (groups or accounts) which are members of
Special Groups. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Lsa\Audit\SpecialGroups registry value contains

current list of SIDs which are included in Special Groups:

For 4908(S): Special Groups Logon table modified.
If you use the Special Groups feature, then this event should be always monitored, especially on high value
assets or computers. If this change was not planned, investigate the reason for the change.
If you dont use the Special Groups feature, then this event should be always monitored because it indicates
use of the Special Groups feature outside of your standard procedures.
4912(S): Per User Audit Policy was changed.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time Per User
Audit Policy was changed.
This event is always logged regardless of
the "Audit Policy Change" sub-category
setting.

event.
Event XML:
- <System>
<Level>0</Level>
<Task>13568</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectLogonId">0x11ae30</Data>
<Data Name="CategoryId">%%8276</Data>
<Data Name="SubcategoryId">%%13312</Data>
<Data Name="SubcategoryGuid">{0CCE922B-69AE-11D9-BED3-505054503030}</Data>
<Data Name="AuditPolicyChanges">%%8452</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made a change to per-user audit policy. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that made a change to per-user audit
policy.
the following:
Policy For Account:
Security ID [Type = SID]: SID of account for which the Per User Audit Policy was changed. Event Viewer
Policy Change Details:
Category [Type = UnicodeString]: the name of auditing category which subcategory state was changed.
Possible values are:
Account Logon
Account Management
Detailed Tracking
DS Access
Logon/Logoff
Object Access
Policy Change
Privilege Use
System
Subcategory [Type = UnicodeString]: the name of auditing subcategory which state was changed. Possible
values:
AUDIT CREDENTIAL VALIDATION AUDIT PROCESS TERMINATION AUDIT OTHER LOGON/LOGOFF EVENTS
Audit Kerberos Authentication Service Audit RPC Events Audit Special Logon
Audit Kerberos Service Ticket Audit Detailed Directory Service Audit Application Generated
Operations Replication
Audit Other Logon/Logoff Events Audit Directory Service Access Audit Certification Services
Audit Application Group Management Audit Directory Service Changes Audit Detailed File Share
Audit Computer Account Management Audit Directory Service Replication Audit File Share
Audit Distribution Group Management Audit Account Lockout Audit File System
AUDIT CREDENTIAL VALIDATION AUDIT PROCESS TERMINATION AUDIT OTHER LOGON/LOGOFF EVENTS
Audit Other Account Management Audit IPsec Extended Mode Audit Filtering Platform Connection
Events
Audit Security Group Management Audit IPsec Main Mode Audit Filtering Platform Packet Drop
Audit User Account Management Audit IPsec Quick Mode Audit Handle Manipulation
Audit DPAPI Activity Audit Logoff Audit Kernel Object
Audit Process Creation Audit Logon Audit IPsec Driver
Audit Other Object Access Events Audit Filtering Platform Policy Change Audit Other System Events
Audit Registry Audit MPSSVC Rule-Level Policy Audit Security State Change
Change
Audit SAM Audit Other Policy Change Events Audit Security System Extension
Audit Policy Change Audit Non-Sensitive Privilege Use Audit System Integrity
Audit Authentication Policy Change Audit Sensitive Privilege Use Audit PNP Activity
Audit Authorization Policy Change Audit Other Privilege Use Events
Group Membership Audit Network Policy Server
Subcategory GUID [Type = GUID]: the unique GUID of changed subcategory.
To see subcategory GUID you can use the following command: auditpol /list /subcategory:* /v:
Changes [Type = UnicodeString]: changes which were made for the subcategory. Possible values are:
Success include removed
Success include added
Failure include removed
Failure include added
Success exclude removed
Success exclude added
Failure exclude removed
Failure exclude added

For 4912(S): Per User Audit Policy was changed.
If you use the Per-user audit feature, then this event should be always monitored, especially on high value
assets or computers. If this change was not planned, investigate the reason for the change.
If you dont use the Per-user audit feature, then this event should be always monitored because it indicates
use of the Per-user audit feature outside of your standard procedures.
4904(S): An attempt was made to register a security
event source.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time a new security
event source is registered.
You can typically see this event during system
startup, if specific roles (Internet Information
Services, for example) are installed in the
system.

Event XML:
- <System>
<Level>0</Level>
<Task>13568</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="AuditSourceName">FSRM Audit</Data>
<Data Name="EventSourceId">0x1cc4e</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made an attempt to register a security event source. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that made an attempt to register a
security event source.
the following:
Process:
Process ID [Type = Pointer]: hexadecimal Process ID of the process that attempted to register the security
event source. Process ID (PID) is a number used by the operating system to uniquely identify an active
column):
Event Source:
Source Name [Type = UnicodeString]: the name of registered security event source. You can see all
registered security event source names in this registry path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Security. Here is an example:
Event Source ID [Type = HexInt64]: the unique hexadecimal identifier of registered security event source.

For 4904(S): An attempt was made to register a security event source.
If you have a pre-defined list of allowed security event sources for specific computers or computer types,
then you can use this event and check whether Event Source\Source Nameis in your defined list.
4905(S): An attempt was made to unregister a
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time a security
event source is unregistered.
You typically see this event if specific roles
were removed, for example, Internet
Information Services.

Event XML:
- <System>
<Level>0</Level>
<Task>13568</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="AuditSourceName">IIS-METABASE</Data>
<Data Name="EventSourceId">0x20c15f</Data>
<Data Name="ProcessId">0xd90</Data>
<Data Name="ProcessName">-</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made an attempt to unregister a security event source. Event
Account Name [Type = UnicodeString]: the name of the account that made an attempt to unregister a
the following:
Process ID [Type = Pointer]: hexadecimal Process ID of the process that attempted to unregister the security
event source. Process ID (PID) is a number used by the operating system to uniquely identify an active
column):
Event Source:
Source Name [Type = UnicodeString]: the name of unregistered security event source. You can see all
registered security event source names in this registry path:
Event Source ID [Type = HexInt64]: the unique hexadecimal identifier of unregistered security event source.

For 4905(S): An attempt was made to unregister a security event source.
If you have a list of critical security event sources which should never have been unregistered, then you can
use this event and check the Event Source\Source Name.
Audit Authentication Policy Change
Applies to
Windows 10
Windows Server 2016
Audit Authentication Policy Change determines whether the operating system generates audit events when
changes are made to authentication policy.
Changes made to authentication policy include:
Creation, modification, and removal of forest and domain trusts.
Changes to Kerberos policy under Computer Configuration\Windows Settings\Security Settings\Account
Policies\Kerberos Policy.
When any of the following user logon rights is granted to a user or group:
Access this computer from the network
Allow logon locally
Allow logon through Remote Desktop
Logon as a batch job
Logon as a service
Namespace collision, such as when an added trust collides with an existing namespace name.
This setting is useful for tracking changes in domain-level and forest-level trust and privileges that are granted to
user accounts or groups.
Event volume: Low.
STRONGER STRONGER
STRONGER STRONGER
Domain Yes No Yes No On domain

Controller controllers, it is
important to
enable Success
audit for this
subcategory to
be able to get
information
related to
operations with
domain and
forest trusts,
changes in
Kerberos policy
and some other
events included
in this
subcategory.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Member Server Yes No Yes No On member

servers it is
important to
enable Success
audit for this
subcategory to
be able to get
information
related to
changes in user
logon rights
policies and
password policy
changes.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Workstation Yes No Yes No On workstations

it is important to
enable Success
audit for this
subcategory to
be able to get
information
related to
changes in user
logon rights
policies and
password policy
changes.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Events List:
4670(S): Permissions on an object were changed
4706(S): A new trust was created to a domain.
4707(S): A trust to a domain was removed.
4716(S): Trusted domain information was modified.
4713(S): Kerberos policy was changed.
4717(S): System security access was granted to an account.
4718(S): System security access was removed from an account.
4739(S): Domain Policy was changed.
4864(S): A namespace collision was detected.
4865(S): A trusted forest information entry was added.
4866(S): A trusted forest information entry was removed.
4867(S): A trusted forest information entry was modified.
4706(S): A new trust was created to a domain.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Authentication Policy
Change
Event Description:
This event generates when a new trust was
created to a domain.
This event is generated only on domain
controllers.

Event XML:
- <System>
<Level>0</Level>
<Task>13569</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="DomainName">corp.contoso.local</Data>
<Data Name="DomainSid">S-1-5-21-2226861337-2836268956-2433141405</Data>
<Data Name="SubjectLogonId">0x3e99d6</Data>
<Data Name="TdoType">2</Data>
<Data Name="TdoDirection">3</Data>
<Data Name="TdoAttributes">32</Data>
<Data Name="SidFilteringEnabled">%%1796</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the create domain trust operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the create domain trust
operation.
the following:
Trusted Domain:
Domain Name [Type = UnicodeString]: the name of new trusted domain.
Domain ID [Type = SID]: SID of new trusted domain. Event Viewer automatically tries to resolve SIDs and
show the account name. If the SID cannot be resolved, you will see the source data in the event.
Trust Information:
Trust Type [Type = UInt32]: the type of new trust. The following table contains possible values for this field:
VALUE ATTRIBUTE VALUE DESCRIPTION
1 TRUST_TYPE_DOWNLEVEL The domain controller of the trusted

domain is a computer running an
operating system earlier than Windows
2000.
2 TRUST_TYPE_UPLEVEL The domain controller of the trusted

domain is a computer running Windows
2000 or later.
3 TRUST_TYPE_MIT The trusted domain is running a non-

Windows, RFC4120-compliant Kerberos
distribution. This type of trust is
distinguished in that (1) a SID is not
required for the TDO, and (2) the
default key types include the DES-CBC
and DES-CRC encryption types (see
[RFC4120] section 8.1).
4 TRUST_TYPE_DCE The trusted domain is a DCE realm.

Historical reference, this value is not
used in Windows.
Trust Direction [Type = UInt32]: the direction of new trust. The following table contains possible values for this
field:
0 TRUST_DIRECTION_DISABLED The trust relationship exists, but it has

been disabled.
1 TRUST_DIRECTION_INBOUND The trusted domain trusts the primary

domain to perform operations such as
name lookups and authentication.
2 TRUST_DIRECTION_OUTBOUND The primary domain trusts the trusted

3 TRUST_DIRECTION_BIDIRECTIONAL Both domains trust one another for

operations such as name lookups and
authentication.
Trust Attributes [Type = UInt32]: the decimal value of attributes for new trust. You need convert decimal value
to hexadecimal and find it in the table below. The following table contains possible values for this field:
0x1 TRUST_ATTRIBUTE_NON_TRANSITIVE If this bit is set, then the trust cannot be

used transitively. For example, if domain
A trusts domain B, which in turn trusts
domain C, and the A<-->B trust has
this attribute set, then a client in
domain A cannot authenticate to a
server in domain C over the A<-->B<--
>C trust linkage.
0x2 TRUST_ATTRIBUTE_UPLEVEL_ONLY If this bit is set in the attribute, then

only Windows 2000 operating system
and newer clients may use the trust link.
Netlogon does not consume trust
objects that have this flag set.
0x4 TRUST_ATTRIBUTE_QUARANTINED_DO If this bit is set, the trusted domain is

MAIN quarantined and is subject to the rules
of SID Filtering as described in [MS-
PAC] section 4.1.2.2.
0x8 TRUST_ATTRIBUTE_FOREST_TRANSITIVE If this bit is set, the trust link is a cross-

forest trust [MS-KILE] between the root
domains of two forests, both of which
are running in a forest functional level
of DS_BEHAVIOR_WIN2003 or greater.
Only evaluated on Windows Server
2003 operating system, Windows
Server 2008 operating system,
Windows Server 2008 R2 operating
system, Windows Server 2012
operating system, Windows Server
2012 R2 operating system, and
Windows Server 2016 operating
system.
Can only be set if forest and trusted
forest are running in a forest functional
level of DS_BEHAVIOR_WIN2003 or
greater.
0x10 TRUST_ATTRIBUTE_CROSS_ORGANIZATI If this bit is set, then the trust is to a

ON domain or forest that is not part of the
organization. The behavior controlled by
this bit is explained in [MS-KILE] section
3.3.5.7.5 and [MS-APDS] section 3.1.5.
2003, Windows Server 2008, Windows
Server 2008 R2, Windows Server 2012,
Windows Server 2012 R2, and Windows
Server 2016.
greater.
0x20 TRUST_ATTRIBUTE_WITHIN_FOREST If this bit is set, then the trusted domain

is within the same forest.
Server 2016.
0x40 TRUST_ATTRIBUTE_TREAT_AS_EXTERNA If this bit is set, then a cross-forest trust

L to a domain is to be treated as an
external trust for the purposes of SID
Filtering. Cross-forest trusts are more
stringently filtered than external trusts.
This attribute relaxes those cross-forest
trusts to be equivalent to external
trusts. For more information on how
each trust type is filtered, see [MS-PAC]
section 4.1.2.2.
Server 2016.
Only evaluated if SID Filtering is used.
Only evaluated on cross-forest trusts
having
TRUST_ATTRIBUTE_FOREST_TRANSITIVE.
greater.
0x80 TRUST_ATTRIBUTE_USES_RC4_ENCRYPT This bit is set on trusts with the

ION trustType set to TRUST_TYPE_MIT,
which are capable of using RC4 keys.
Historically, MIT Kerberos distributions
supported only DES and 3DES keys
([RFC4120], [RFC3961]). MIT 1.4.1
adopted the RC4HMAC encryption type
common to Windows 2000 [MS-KILE],
so trusted domains deploying later
versions of the MIT distribution
required this bit. For more information,
see "Keys and Trusts", section 6.1.6.9.1.
Only evaluated on TRUST_TYPE_MIT
0x200 TRUST_ATTRIBUTE_CROSS_ORGANIZATI If this bit is set, tickets granted under

ON_NO_TGT_DELEGATION this trust MUST NOT be trusted for
delegation. The behavior controlled by
this bit is as specified in [MS-KILE]
section 3.3.5.7.5.
Only supported on Windows Server
2012, Windows Server 2012 R2, and
0x400 TRUST_ATTRIBUTE_PIM_TRUST If this bit and the TATE bit are set, then
a cross-forest trust to a domain is to be
treated as Privileged Identity
Management trust for the purposes of
SID Filtering. For more information on
how each trust type is filtered, see [MS-
Evaluated only on Windows Server
2016
Evaluated only if SID Filtering is used.
Evaluated only on cross-forest trusts
having
Can be set only if the forest and the
trusted forest are running in a forest
functional level of
DS_BEHAVIOR_WINTHRESHOLD or
greater.
SID Filtering [Type = UnicodeString]: SID Filtering state for the new trust:
Enabled
Disabled

For 4706(S): A new trust was created to a domain.
Any changes related to Active Directory domain trusts (especially creation of the new trust) must be monitored
and alerts should be triggered. If this change was not planned, investigate the reason for the change.
4707(S): A trust to a domain was removed.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
This event generates when a domain trust was
removed.
controllers.

Event XML:
- <System>
<Level>0</Level>
<Task>13569</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="DomainName">FABRIKAM</Data>
<Data Name="SubjectLogonId">0x3e99d6</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the remove domain trust operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the remove domain trust
operation.
the following:
Domain Information:
Domain Name [Type = UnicodeString]: the name of removed trusted domain.
Domain ID [Type = SID]: SID of removed trusted domain. Event Viewer automatically tries to resolve SIDs

For 4707(S): A trust to a domain was removed.
Any changes related to Active Directory domain trusts (especially trust removal) must be monitored and alerts
4716(S): Trusted domain information was modified.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
This event generates when the trust was
modified.
controllers.

Event XML:
- <System>
<Level>0</Level>
<Task>13569</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="DomainName">-</Data>
<Data Name="TdoType">2</Data>
<Data Name="TdoDirection">3</Data>
<Data Name="TdoAttributes">32</Data>
<Data Name="SidFilteringEnabled">-</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the modify domain trust settings operation. Event
Account Name [Type = UnicodeString]: the name of the account that requested the modify domain trust
settings operation.
the following:
Trusted Domain:
Domain Name [Type = UnicodeString]: the name of changed trusted domain. If this attribute was not
changed, then it will have - value.
Domain ID [Type = SID]: SID of changed trusted domain. Event Viewer automatically tries to resolve SIDs
New Trust Information:
Trust Type [Type = UInt32]: the type of new trust. If this attribute was not changed, then it will have - value or
its old value. The following table contains possible values for this field:
1 TRUST_TYPE_DOWNLEVEL The domain controller of the trusted

domain is a computer running an
operating system earlier than Windows
2000.
2 TRUST_TYPE_UPLEVEL The domain controller of the trusted

domain is a computer running Windows
2000 or later.
3 TRUST_TYPE_MIT The trusted domain is running a non-

Windows, RFC4120-compliant Kerberos
distribution. This type of trust is
distinguished in that (1) a SID is not
required for the TDO, and (2) the
default key types include the DES-CBC
and DES-CRC encryption types (see
[RFC4120] section 8.1).
4 TRUST_TYPE_DCE The trusted domain is a DCE realm.

Historical reference, this value is not
used in Windows.
Trust Direction [Type = UInt32]: the direction of new trust. If this attribute was not changed, then it will have -
value or its old value. The following table contains possible values for this field:
0 TRUST_DIRECTION_DISABLED The trust relationship exists, but it has

been disabled.
1 TRUST_DIRECTION_INBOUND The trusted domain trusts the primary

2 TRUST_DIRECTION_OUTBOUND The primary domain trusts the trusted

3 TRUST_DIRECTION_BIDIRECTIONAL Both domains trust one another for

operations such as name lookups and
authentication.
Trust Attributes [Type = UInt32]: the decimal value of attributes for new trust. You need convert decimal value
to hexadecimal and find it in the table below. If this attribute was not changed, then it will have - value or its
old value. The following table contains possible values for this field:
0x1 TRUST_ATTRIBUTE_NON_TRANSITIVE If this bit is set, then the trust cannot be

used transitively. For example, if domain
A trusts domain B, which in turn trusts
domain C, and the A<-->B trust has
this attribute set, then a client in
domain A cannot authenticate to a
server in domain C over the A<-->B<--
>C trust linkage.
0x2 TRUST_ATTRIBUTE_UPLEVEL_ONLY If this bit is set in the attribute, then

only Windows 2000 operating system
and newer clients may use the trust link.
Netlogon does not consume trust
objects that have this flag set.
0x4 TRUST_ATTRIBUTE_QUARANTINED_DO If this bit is set, the trusted domain is

MAIN quarantined and is subject to the rules
of SID Filtering as described in [MS-
0x8 TRUST_ATTRIBUTE_FOREST_TRANSITIVE If this bit is set, the trust link is a cross-

forest trust [MS-KILE] between the root
domains of two forests, both of which
are running in a forest functional level
of DS_BEHAVIOR_WIN2003 or greater.
2003 operating system, Windows
Server 2008 operating system,
system, Windows Server 2012
operating system, Windows Server
2012 R2 operating system, and
Windows Server 2016 operating
system.
greater.
0x10 TRUST_ATTRIBUTE_CROSS_ORGANIZATI If this bit is set, then the trust is to a

ON domain or forest that is not part of the
organization. The behavior controlled by
this bit is explained in [MS-KILE] section
3.3.5.7.5 and [MS-APDS] section 3.1.5.
Server 2016.
greater.
0x20 TRUST_ATTRIBUTE_WITHIN_FOREST If this bit is set, then the trusted domain

is within the same forest.
Server 2016.
0x40 TRUST_ATTRIBUTE_TREAT_AS_EXTERNA If this bit is set, then a cross-forest trust

L to a domain is to be treated as an
external trust for the purposes of SID
Filtering. Cross-forest trusts are more
stringently filtered than external trusts.
This attribute relaxes those cross-forest
trusts to be equivalent to external
trusts. For more information on how
each trust type is filtered, see [MS-PAC]
section 4.1.2.2.
Server 2016.
Only evaluated if SID Filtering is used.
Only evaluated on cross-forest trusts
having
greater.
0x80 TRUST_ATTRIBUTE_USES_RC4_ENCRYPT This bit is set on trusts with the

ION trustType set to TRUST_TYPE_MIT,
which are capable of using RC4 keys.
Historically, MIT Kerberos distributions
supported only DES and 3DES keys
([RFC4120], [RFC3961]). MIT 1.4.1
adopted the RC4HMAC encryption type
common to Windows 2000 [MS-KILE],
so trusted domains deploying later
versions of the MIT distribution
required this bit. For more information,
see "Keys and Trusts", section 6.1.6.9.1.
Only evaluated on TRUST_TYPE_MIT
0x200 TRUST_ATTRIBUTE_CROSS_ORGANIZATI If this bit is set, tickets granted under

ON_NO_TGT_DELEGATION this trust MUST NOT be trusted for
delegation. The behavior controlled by
this bit is as specified in [MS-KILE]
section 3.3.5.7.5.
Only supported on Windows Server
2012, Windows Server 2012 R2, and
0x400 TRUST_ATTRIBUTE_PIM_TRUST If this bit and the TATE bit are set, then
a cross-forest trust to a domain is to be
treated as Privileged Identity
Management trust for the purposes of
SID Filtering. For more information on
how each trust type is filtered, see [MS-
Evaluated only on Windows Server
2016
Evaluated only if SID Filtering is used.
Evaluated only on cross-forest trusts
having
Can be set only if the forest and the
trusted forest are running in a forest
functional level of
DS_BEHAVIOR_WINTHRESHOLD or
greater.
SID Filtering [Type = UnicodeString]: SID Filtering state for the new trust:
Enabled
Disabled
If this attribute was not changed, then it will have - value or its old value.

For 4716(S): Trusted domain information was modified.
Any changes in Active Directory domain trust settings must be monitored and alerts should be triggered. If this
change was not planned, investigate the reason for the change.
4713(S): Kerberos policy was changed.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
This event generates when Kerberos
policy was changed.
controllers.

for this event.
Event XML:
- <System>
<Level>0</Level>
<Task>13569</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="KerberosPolicyChange">KerMaxT: 0x10c388d000 (0x861c46800); KerMaxR: 0x19254d38000 (0xc92a69c000);
</Data>
</EventData>
</Event>
Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made a change to Kerberos policy. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: the name of the account that made a change to Kerberos policy.
the following:
Changes Made [Type = UnicodeString]: '--' means no changes, otherwise each change is shown as:
Parameter_Name: new_value (old_value). Here is a list of possible parameter names:
PARAMETER NAME DESCRIPTION
KerProxy 1. Maximum tolerance for computer clock synchronization.

To convert the KerProxy to minutes you need to:
Convert the value to decimal value.
Divide value by 600000000.
KerMaxR 1. Maximum lifetime for user ticket renewal.

To convert the KerProxy to days you need to:
PARAMETER NAME DESCRIPTION
KerMaxT 1. Maximum lifetime for user ticket.

To convert the KerMaxT to hours you need to:
KerMinT 1. Maximum lifetime for service ticket.

To convert the KerMinT to minutes you need to:
KerOpts - Enforce user logon restrictions:

0x80 Enabled
0x0 - Disabled
This event shows changes in Kerberos policy. Here is location of Kerberos policies in Group Policy management
console:

For 4713(S): Kerberos policy was changed.
Any changes in Kerberos policy reported by current event must be monitored and an alert should be triggered.
If this change was not planned, investigate the reason for the change.
4717(S): System security access was granted to an
account.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
This event generates every time local logon
user right policy is changed and logon right
was granted to an account.
You will see unique event for every user if
logon user rights were granted to multiple
accounts.

Event XML:
- <System>
<Level>0</Level>
<Task>13569</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="AccessGranted">SeInteractiveLogonRight</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made a change to local logon right user policy. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that made a change to local logon right
user policy.
the following:
Account Modified:
Account Name [Type = SID]: the SID of the security principal for which logon right was granted. Event Viewer
**Access Granted: **
Access Right [Type = UnicodeString]: the name of granted logon right. This event generates only for logon
rights, which are as follows:
VALUE GROUP POLICY NAME
SeNetworkLogonRight Access this computer from the network
SeRemoteInteractiveLogonRight Allow logon through Terminal Services
SeDenyNetworkLogonRight Deny access to this computer from the network
SeDenyBatchLogonRight Deny logon as a batch job
SeDenyServiceLogonRight Deny logon as a service
SeDenyInteractiveLogonRight Deny logon locally
SeDenyRemoteInteractiveLogonRight Deny logon through Terminal Services
SeBatchLogonRight Log on as a batch job
SeServiceLogonRight Log on as a service
SeInteractiveLogonRight Log on locally

For 4717(S): System security access was granted to an account.
Actions typically performed by the SYSTEM account: This Because this event is typically triggered by the SYSTEM
event and certain other events should be monitored to see if account, we recommend that you report it whenever
they are triggered by any account other than SYSTEM. Subject\Security ID is not SYSTEM.
local accounts for which you need to monitor each action. Account Modified\Account Name that correspond to the
Non-active accounts: You might have non-active, disabled, Monitor this event with the Subject\Security ID that
used.
If you have specific user logon rights policies, for example, a
whitelist of accounts that can log on to certain computers,
monitor this event to confirm that any Access Right was
granted only to the appropriate Account Modified\Account
Name.
certain actions are performed only by certain account types, certain account types, review the Subject\Security ID and
for example, local or domain account, machine or user Account Modified\Account Name to see whether the
For example, if non-service accounts should never be granted
certain logon rights (for example, SeServiceLogonRight),
monitor this event for those accounts and rights.
events).
people (accounts) should perform only limited actions, or no concerned about. Also be sure to check Account
actions at all. Modified\Account Name to see whether logon rights
should be granted to that account.
For high-value servers or other computers, we recommend
that you track this event and investigate whether the specific
Access Right should be granted to Account
Modified\Account Name in each case.
Logon rights that should be restricted: You might have a Monitor this event and compare the Access Right to your
list of user logon rights that you want to monitor (for example, list of restricted rights.
SeServiceLogonRight).
4718(S): System security access was removed from an
account.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
This event generates every time local logon
user right policy is changed and logon right
was removed from an account.
You will see unique event for every user if
logon user rights were removed for multiple
accounts.

Event XML:
- <System>
<Level>0</Level>
<Task>13569</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="AccessRemoved">SeInteractiveLogonRight</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made a change to local logon right user policy. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that made a change to local logon right
user policy.
the following:
Account Modified:
Account Name [Type = SID]: the SID of the security principal for which logon right was removed. Event Viewer
**Access Removed: **
Access Right [Type = UnicodeString]: the name of removed logon right. This event generates only for logon
rights, which are as follows:
VALUE GROUP POLICY NAME
SeNetworkLogonRight Access this computer from the network
SeRemoteInteractiveLogonRight Allow logon through Terminal Services
SeDenyNetworkLogonRight Deny access to this computer from the network
SeDenyBatchLogonRight Deny logon as a batch job
SeDenyServiceLogonRight Deny logon as a service
SeDenyInteractiveLogonRight Deny logon locally
SeDenyRemoteInteractiveLogonRight Deny logon through Terminal Services
SeBatchLogonRight Log on as a batch job
SeServiceLogonRight Log on as a service
SeInteractiveLogonRight Log on locally

For 4718(S): System security access was removed from an account.
local accounts for which you need to monitor each action. Account Modified\Account Name that correspond to the
Non-active accounts: You might have non-active, disabled, Monitor this event with the Subject\Security ID that
used.
If you have specific user logon rights policies, for example, a
whitelist of accounts that can log on to certain computers,
monitor this event to confirm that it was appropriate that the
Access Right was removed from Account
Modified\Account Name.
for example, local or domain account, machine or user Account Modified\Account Name to see whether the
For example, if critical remote network service accounts have
user logon rights which should never be removed (for
example, SeNetworkLogonRight), monitor this event for the
Account Modified\Account Name and the appropriate
rights.
As another example, if non-service accounts should never be
granted certain logon rights (for example,
SeServiceLogonRight), you might monitor this event,
because a right can be removed only after it was previously
granted.
events).
people (accounts) should perform only limited actions, or no concerned about. Also be sure to check Account
actions at all. Modified\Account Name to see whether logon rights
should be removed from that account.
Access Right should be removed from Account
Modified\Account Name in each case.
Logon rights that should be restricted: You might have a - Monitor this event and compare the Access Right to your
list of user logon rights that you want to monitor (for example, list of restricted rights.
SeServiceLogonRight). Monitor this event to discover the removal of a right that
Deny rights that should not be removed: Your should never have been granted, so that you can investigate
organization might use Deny rights that should not be further.
removed, for example, SeDenyRemoteInteractiveLogonRight. You can also monitor this event to discover the removal of
Deny rights. When these rights are removed, it could be an
approved action, done by mistake, or part of malicious activity.
These rights include:
SeDenyNetworkLogonRight:
SeDenyBatchLogonRight
SeDenyServiceLogonRight
SeDenyInteractiveLogonRight
SeDenyRemoteInteractiveLogonRight
4739(S): Domain Policy was changed.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
This event generates when one of the following
changes was made to local computer security
policy:
Computers \Security Settings\Account
Policies\Account Lockout Policy settings
were modified.
Computer's \Security Settings\Account
Policies\Password Policy settings were
modified.
"Network security: Force logoff when logon
hours expire" group policy setting was
changed.
Domain functional level was changed or
some other attributes changed (see details
in event description).

Event XML:
- <System>
<Level>0</Level>
<Task>13569</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="DomainPolicyChanged">Password Policy</Data>
<Data Name="DomainName">CONTOSO</Data>
<Data Name="MinPasswordAge">-</Data>
<Data Name="MaxPasswordAge">-</Data>
<Data Name="ForceLogoff">-</Data>
<Data Name="LockoutThreshold">-</Data>
<Data Name="LockoutObservationWindow">-</Data>
<Data Name="LockoutDuration">-</Data>
<Data Name="PasswordProperties">-</Data>
<Data Name="MinPasswordLength">-</Data>
<Data Name="PasswordHistoryLength">13</Data>
<Data Name="MachineAccountQuota">-</Data>
<Data Name="MixedDomainMode">-</Data>
<Data Name="DomainBehaviorVersion">-</Data>
<Data Name="OemInformation">-</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Change Type [Type = UnicodeString]: the type of change which was made. The format is policy_name
modified. These are some possible values of policy_name:
VALUE GROUP POLICY NAME \ DESCRIPTION
Lockout Policy Computers \Security Settings\Account Policies\Account

Lockout Policy settings were modified.
Password Policy Computer's \Security Settings\Account Policies\Password

Policy settings were modified.
Logoff Policy "Network security: Force logoff when logon hours expire"
group policy setting was changed.
VALUE GROUP POLICY NAME \ DESCRIPTION
- Machine Account Quota (ms-DS-MachineAccountQuota)

domain attribute was modified.
Subject:
Security ID [Type = SID]: SID of account that made a change to specific local policy. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: the name of the account that made a change to specific local policy.
the following:
Domain:
Domain Name [Type = UnicodeString]: the name of domain for which policy changes were made.
Domain ID [Type = SID]: the SID of domain for which policy changes were made. Event Viewer automatically
the event.
Changed Attributes: For attributes which were not changed the value will be -.
Min. Password Age [Type = UnicodeString]: \Security Settings\Account Policies\Password Policy\Minimum
password age group policy. Numeric value.
Max. Password Age [Type = UnicodeString]: \Security Settings\Account Policies\Password
Policy\Maximum password age group policy. Numeric value.
Force Logoff [Type = UnicodeString]: \Security Settings\Local Policies\Security Options\Network security:
Force logoff when logon hours expire group policy.
Lockout Threshold [Type = UnicodeString]: \Security Settings\Account Policies\Account Lockout
Policy\Account lockout threshold group policy. Numeric value.
Lockout Observation Window [Type = UnicodeString]: \Security Settings\Account Policies\Account
Lockout Policy\Reset account lockout counter after group policy. Numeric value.
Lockout Duration [Type = UnicodeString]: \Security Settings\Account Policies\Account Lockout
Policy\Account lockout duration group policy. Numeric value.
Password Properties [Type = UnicodeString]:
VALUE GROUP POLICY SETTINGS
0 \Security Settings\Account Policies\Password Policy\Store

passwords using reversible encryption - Disabled.
\Security Settings\Account Policies\Password Policy\Password
must meet complexity requirements Disabled.

passwords using reversible encryption - Disabled.
must meet complexity requirements Enabled.

passwords using reversible encryption - Enabled.
must meet complexity requirements Disabled.

passwords using reversible encryption - Enabled.
must meet complexity requirements Enabled.
Min. Password Length [Type = UnicodeString]: \Security Settings\Account Policies\Password

Policy\Minimum password length group policy. Numeric value.
Password History Length [Type = UnicodeString]: \Security Settings\Account Policies\Password
Policy\Enforce password history group policy. Numeric value.
Machine Account Quota [Type = UnicodeString]: ms-DS-MachineAccountQuota domain attribute was
modified. Numeric value.
Mixed Domain Mode [Type = UnicodeString]: there is no information about this field in this document.
Domain Behavior Version [Type = UnicodeString]: msDS-Behavior-Version domain attribute was
modified. Numeric value. Possible values:
DOMAIN CONTROLLER OPERATING

SYSTEMS THAT ARE ALLOWED IN THE
VALUE IDENTIFIER DOMAIN
0 DS_BEHAVIOR_WIN2000 Windows 2000 Server operating system

Windows Server 2003 operating system
system
system
DOMAIN CONTROLLER OPERATING
SYSTEMS THAT ARE ALLOWED IN THE
VALUE IDENTIFIER DOMAIN
1 DS_BEHAVIOR_WIN2003_WITH_MIXED Windows Server 2003

_DOMAINS Windows Server 2008
Windows Server 2012
Windows Server 2016
2 DS_BEHAVIOR_WIN2003 Windows Server 2003

Windows Server 2008
Windows Server 2012
Windows Server 2016

Windows Server 2012
Windows Server 2016
4 DS_BEHAVIOR_WIN2008R2 Windows Server 2008 R2

Windows Server 2012
Windows Server 2016

Windows Server 2016
6 DS_BEHAVIOR_WIN2012R2 Windows Server 2012 R2

Windows Server 2016
7 DS_BEHAVIOR_WINTHRESHOLD Windows Server 2016
OEM Information [Type = UnicodeString]: there is no information about this field in this document.
list of user privileges in the table below:

a process.

operations.
held:
READ_CONTROL
FILE_GENERIC_READ
FILE_TRAVERSE




creation APIs.

account.
components.

a process.
interface.
to a process.
users.
driver.

memory.
computer account.
controllers.

defragmentation.

system processes.

network request.

held:
WRITE_DAC
WRITE_OWNER
FILE_GENERIC_WRITE
FILE_ADD_FILE
DELETE
an object.

security event log.
synchronization.
information.

processes.
clock.



a terminal device.

For 4739(S): Domain Policy was changed.
Any settings changes to Account Lockout Policy, Password Policy, or Network security: Force logoff
when logon hours expire, plus any domain functional level and attributes changes that are reported by
this event, must be monitored and an alert should be triggered. If this change was not planned, investigate the
reason for the change.
4864(S): A namespace collision was detected.
Applies to
Windows 10
Windows Server 2016
This event is generated when a namespace collision was detected.
Subcategory: Audit Authentication Policy Change
Event Schema:
A namespace collision was detected.
Target Type:%1
Target Name:%2
Forest Root:%3
Top Level Name:%4
DNS Name:%5
NetBIOS Name:%6
Security ID:%7
*New Flags:%8 *
Event Versions: 0.

4865(S): A trusted forest information entry was
added.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
This event generates when new trusted forest
information entry was added.
controllers.

Event XML:
- <System>
<Level>0</Level>
<Task>13569</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ForestRoot">Fabrikam.local</Data>
<Data Name="ForestRootSid">S-1-5-21-2703072690-1374247579-2643703677</Data>
<Data Name="OperationId">0x648620</Data>
<Data Name="EntryType">2</Data>
<Data Name="Flags">0</Data>
<Data Name="TopLevelName">-</Data>
<Data Name="DnsName">Fabrikam.local</Data>
<Data Name="NetbiosName">FABRIKAM</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the add a trusted forest information entry operation.
Account Name [Type = UnicodeString]: the name of the account that requested the add a trusted forest
information entry operation.
the following:
Trust Information:
Forest Root [Type = UnicodeString]: the name of the Active Directory forest for which trusted forest
information entry was added.
Forest Root SID [Type = SID]: the SID of the Active Directory forest for which trusted forest information entry
was added. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be
Operation ID [Type = HexInt64]: unique hexadecimal identifier of the operation. You can correlate this event
with other events (4866(S): A trusted forest information entry was removed, 4867(S): A trusted forest
information entry was modified.) using this field.
Entry Type [Type = UInt32]: the type of added entry:
VALUE TYPE NAME DESCRIPTION
0 ForestTrustTopLevelName The DNS name of the trusted forest.

The structure used for this record type
is equivalent to LSA_UNICODE_STRING
1 ForestTrustTopLevelNameEx This type commonly used for name

suffix exceptions. The structure used for
this record type is equivalent to
LSA_UNICODE_STRING.
2 ForestTrustDomainInfo This field specifies a record containing

identification and name information
Flags [Type = UInt32]: The following table specifies the possible flags.
Some flag values are reused for different forest record types. See the Meaning column for more
information.
VALUE TRUST TYPE MEANING
0 - No flags were set.
1 ForestTrustTopLevelNameEx The top-level name trust record is

ForestTrustTopLevelName disabled during initial creation.
ForestTrustDomainInfo The domain information trust record is

disabled by the domain administrator.

ForestTrustTopLevelName disabled by the domain administrator.

disabled due to a conflict.

ForestTrustTopLevelName disabled due to a conflict.

8 ForestTrustDomainInfo The domain information trust record is

Top Level Name [Type = UnicodeString]: the name of the new trusted forest information entry.
DNS Name [Type = UnicodeString]: DNS name of the trust partner. This parameter might not be captured
in the event, and in that case appears as -.
NetBIOS Name [Type = UnicodeString]: NetBIOS name of the trust partner. This parameter might not be
Domain SID [Type = SID]: SID of the trust partner. This parameter might not be captured in the event, and
in that case appears as NULL SID.

For 4865(S): A trusted forest information entry was added.
Any changes related to Active Directory forest trusts (especially creation of the new trust) must be monitored
and alerts should be triggered. If this change was not planned, investigate the reason for the change.
removed.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
This event generates when the trusted forest
information entry was removed.
controllers.

Event XML:
- <System>
<Level>0</Level>
<Task>13569</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the remove a trusted forest information entry
Account Name [Type = UnicodeString]: the name of the account that requested the remove a trusted
forest information entry operation.
the following:
Trust Information:
information entry was removed.
was removed. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be
with other events (4865(S): A trusted forest information entry was added, 4867(S): A trusted forest information
entry was modified.) using this field.
Entry Type [Type = UInt32]: the type of removed entry:


LSA_UNICODE_STRING.

information.







Top Level Name [Type = UnicodeString]: the name of the removed trusted forest information entry.

For 4866(S): A trusted forest information entry was removed.
Any changes related to Active Directory forest trusts (especially trust removal) must be monitored and alerts
modified.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
This event generates the trusted forest
information entry was modified.
controllers.
This event contains new values only, it doesnt
contains old values and it doesnt show you
which trust attributes were modified.

Event XML:
- <System>
<Level>0</Level>
<Task>13569</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the modify/change a trusted forest information entry
Account Name [Type = UnicodeString]: the name of the account that requested the modify/change a
trusted forest information entry operation.
the following:
Trust Information:
information entry was modified.
was modified. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be
with other events (4865(S): A trusted forest information entry was added, 4866(S): A trusted forest information
entry was removed) using this field.
Entry Type [Type = UInt32]: the type of modified entry:


LSA_UNICODE_STRING.

information.







Top Level Name [Type = UnicodeString]: the name of the modified trusted forest information entry.

For 4867(S): A trusted forest information entry was modified.
Any changes in Active Directory forest trust settings must be monitored and alerts should be triggered. If this
change was not planned, investigate the reason for the change.
Audit Authorization Policy Change
Applies to
Windows 10
Windows Server 2016
Audit Authorization Policy Change allows you to audit assignment and removal of user rights in user right
policies, changes in security token object permission, resource attributes changes and Central Access Policy
changes for file system objects.
STRONGER STRONGER
Domain IF No IF No IF With Success

Controller auditing for this
subcategory, you
can get
information
related to
changes in user
rights policies, or
changes of
resource
attributes or
Central Access
Policy applied to
file system
objects.
However, if you
are using an
application or
system service
that makes
changes to
system privileges
through the
AdjustPrivilegesT
oken API, we do
not recommend
Success auditing
because of the
high volume of
event 4703(S): A
user right was
adjusted that
may be
generated. As of
Windows 10,
event 4703 is
generated by
applications or
services that
dynamically
adjust token
privileges. An
example of such
an application is
an application is
STRONGER STRONGER System Center
COMPUTER TYPE GENERAL SUCCESS GENERAL FAILURE SUCCESS FAILURE Configuration
COMMENTS
Manager, which
makes WMI
queries at
recurring
intervals and
quickly generates
a large number
of 4703 events
(with the WMI
activity listed as
coming from
svchost.exe).
If one of your
applications or
services is
generating a
large number of
4703 events, you
might find that
your event-
management
software has
filtering logic that
can automatically
discard the
recurring events,
which would
make it easier to
work with
Success auditing
for this category.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Member Server IF No IF No IF With Success

auditing for this
subcategory, you
can get
information
related to
changes in user
rights policies, or
changes of
resource
attributes or
Central Access
Policy applied to
file system
objects.
However, if you
are using an
application or
system service
that makes
changes to
system privileges
through the
through the
STRONGER STRONGER AdjustPrivilegesT
COMPUTER TYPE GENERAL SUCCESS GENERAL FAILURE SUCCESS FAILURE oken API, we do
COMMENTS
not recommend
Success auditing
because of the
high volume of
event 4703(S): A
user right was
adjusted that
may be
generated. As of
Windows 10,
event 4703 is
generated by
applications or
services that
dynamically
adjust token
privileges. An
example of such
an application is
System Center
Configuration
Manager, which
makes WMI
queries at
recurring
intervals and
quickly generates
a large number
of 4703 events
(with the WMI
activity listed as
coming from
svchost.exe).
If one of your
applications or
services is
generating a
large number of
4703 events, you
might find that
your event-
management
software has
filtering logic that
can automatically
discard the
recurring events,
which would
make it easier to
work with
Success auditing
for this category.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Workstation IF No IF No IF With Success

auditing for this
auditing for this
STRONGER STRONGER subcategory, you
COMPUTER TYPE GENERAL SUCCESS GENERAL FAILURE SUCCESS FAILURE can get
COMMENTS
information
related to
changes in user
rights policies, or
changes of
resource
attributes or
Central Access
Policy applied to
file system
objects.
However, if you
are using an
application or
system service
that makes
changes to
system privileges
through the
AdjustPrivilegesT
oken API, we do
not recommend
Success auditing
because of the
high volume of
event 4703(S): A
user right was
adjusted that
may be
generated. As of
Windows 10,
event 4703 is
generated by
applications or
services that
dynamically
adjust token
privileges. An
example of such
an application is
System Center
Configuration
Manager, which
makes WMI
queries at
recurring
intervals and
quickly generates
a large number
of 4703 events
(with the WMI
activity listed as
coming from
svchost.exe).
If one of your
applications or
services is
generating a
large number of
4703 events, you
might find that
your event-
management
software has
STRONGER STRONGER
COMPUTER TYPE GENERAL SUCCESS GENERAL FAILURE SUCCESS FAILURE filtering
COMMENTS logic that
can automatically
discard the
recurring events,
which would
make it easier to
work with
Success auditing
for this category.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Events List:
4703(S): A user right was adjusted.
4704(S): A user right was assigned.
4705(S): A user right was removed.
4911(S): Resource attributes of the object were changed.
4913(S): Central Access Policy on the object was changed.
Event volume: Medium to High.
4703(S): A user right was adjusted.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Authorization Policy Change
Event Description:
This event generates when token privileges were
enabled or disabled for a specific accounts token.
As of Windows 10, event 4703 is also logged by
applications or services that dynamically adjust
token privileges. An example of such an application
is System Center Configuration Manager, which
makes WMI queries at recurring intervals and
quickly generates a large number of 4703 events
(with the WMI activity listed as coming from
svchost.exe). If you are using an application or
system service that makes changes to system
privileges through the AdjustPrivilegesToken API,
you might need to disable Success auditing for this
subcategory (Audit Authorization Policy Change),
or work with a very high volume of event 4703.

Token privileges provide the ability to take certain

system-level actions that you only need to do at particular moments. For example, anybody can restart a
computer, but the operating system doesnt enable that privilege by default. Instead, the privilege is enabled when
you click Shutdown. You can check the current state of the users token privileges using the whoami /priv
command:
Event XML:
- <System>
<Level>0</Level>
<Task>13570</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">WIN-GG82ULGC9GO$</Data>
<Data Name="TargetLogonId">0x3e7</Data>
<Data Name="EnabledPrivilegeList">SeAssignPrimaryTokenPrivilege SeIncreaseQuotaPrivilege SeSecurityPrivilege
SeTakeOwnershipPrivilege SeLoadDriverPrivilege SeSystemtimePrivilege SeBackupPrivilege SeRestorePrivilege
SeShutdownPrivilege SeSystemEnvironmentPrivilege SeUndockPrivilege SeManageVolumePrivilege</Data>
<Data Name="DisabledPrivilegeList">-</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the enable or disable operation for Target
Account privileges. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID
Account Name [Type = UnicodeString]: the name of the account that requested the enable or disable
operation for Target Account privileges.
the following:
Target Account:
Security ID [Type = SID]: SID of account for which privileges were enabled or disabled. Event Viewer
Account Name [Type = UnicodeString]: the name of the account for which privileges were enabled or
disabled.
the following:
Process ID [Type = Pointer]: hexadecimal Process ID of the process that enabled or disabled token
privileges. Process ID (PID) is a number used by the operating system to uniquely identify an active process.
Enabled Privileges [Type = UnicodeString]: the list of enabled user rights. This event generates only for user
rights, not logon rights. Here is the list of possible user rights:

of a process.

operations.
is held:
READ_CONTROL
FILE_GENERIC_READ
FILE_TRAVERSE

the user may not have permissions on
the traversed directory. This privilege
does not allow the user to list the
contents of a directory, only to traverse
directories.



creation APIs.

account.
components.

a process.
interface.
users.
driver.

memory.
computer account.
controllers.

defragmentation.

system processes.

SeRemoteShutdownPrivilege Force shutdown from a remote system Required to shut down a system using
a network request.

held:
WRITE_DAC
WRITE_OWNER
FILE_GENERIC_WRITE
FILE_ADD_FILE
DELETE
an object.

security event log.
synchronization.

information.

processes.
clock.



a terminal device.
Disabled Privileges [Type = UnicodeString]: the list of disabled user rights. See possible values in the table
above.

For 4703(S): A user right was adjusted.
As of Windows 10, event 4703 is generated by applications or services that dynamically adjust token privileges. An
example of such an application is System Center Configuration Manager, which makes WMI queries at recurring
intervals and quickly generates a large number of 4703 events (with the WMI activity listed as coming from
svchost.exe). If you are using an application or system service that makes changes to system privileges through the
AdjustPrivilegesToken API, you might need to disable Success auditing for this subcategory, Audit Authorization
Policy Change, or work with a very high volume of event 4703.
Otherwise, see the recommendations in the following table.
High-value accounts: You might have high-value domain or Monitor this event with the Subject\Security ID that
Non-active accounts: You might have non-active, disabled, Monitor this event with the Subject\Security ID or
or guest accounts, or other accounts that should never be Target Account\Security ID that correspond to the
used. accounts that should never be used.
corresponding to particular events. whitelist. Also check the Target Account\Security ID and
Enabled Privileges to see what was enabled.
events).
people (accounts) should perform only limited actions, or no concerned about.
actions at all. Also check Target Account\Security ID to see whether
the change in privileges should be made on that computer for
that account.
User rights that should be restricted or monitored: You Monitor this event and compare the Enabled Privileges to
might have a list of user rights that you want to restrict or your list of user rights. Trigger an alert for user rights that
monitor. should not be enabled, especially on high-value servers or
other computers.
For example, you might have SeDebugPrivilege on a list of
user rights to be restricted.
4704(S): A user right was assigned.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Authorization Policy
Change
Event Description:
This event generates every time local user right
policy is changed and user right was assigned
to an account.
You will see unique event for every user.

Event XML:
- <System>
<Level>0</Level>
<Task>13570</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="PrivilegeList">SeAuditPrivilege SeIncreaseWorkingSetPrivilege</Data>
</EventData>
</Event>
Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made a change to local user right policy. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that made a change to local user right
policy.
the following:
Target Account:
Account Name [Type = SID]: the SID of security principal for which user rights were assigned. Event Viewer
**New Right: **
User Right [Type = UnicodeString]: the list of assigned user rights. This event generates only for user rights, not
logon rights. Here is the list of possible user rights:


a process.

operations.
held:
READ_CONTROL
FILE_GENERIC_READ
FILE_TRAVERSE





creation APIs.

account.
components.

a process.
interface.
to a process.
users.
driver.

memory.
computer account.
controllers.

defragmentation.

system processes.

network request.

held:
WRITE_DAC
WRITE_OWNER
FILE_GENERIC_WRITE
FILE_ADD_FILE
DELETE
an object.

security event log.
synchronization.
information.

processes.
clock.



a terminal device.

For 4704(S): A user right was assigned.
Non-active accounts: You might have non-active, disabled, Monitor this event with the Subject\Security ID or Target
or guest accounts, or other accounts that should never be Account\ Account Name that correspond to the accounts
used. that should never be used.
corresponding to particular events. whitelist. Also check the Target Account\Account Name
and New Right to see what was enabled.
events).
people (accounts) should perform only limited actions, or no concerned about.
actions at all. Also check Target Account\ Account Name to see
whether the change in rights should be made on that
computer for that account.
User rights that should be restricted or monitored: You Monitor this event and compare the New Right\User Right
might have a list of user rights that you want to restrict or to your list of user rights, to see whether the right should be
monitor. assigned to Target Account\Account Name. Trigger an
alert for user rights that should not be enabled, especially on
high-value servers or other computers.
For example, your list of restricted rights might say that only
administrative accounts should have SeAuditPrivilege. As
another example, your list might say that no accounts should
have SeTcbPrivilege or SeDebugPrivilege.
4705(S): A user right was removed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Authorization Policy
Change
Event Description:
This event generates every time local user right
policy is changed and user right was removed
from an account.
You will see unique event for every user.

Event XML:
- <System>
<Level>0</Level>
<Task>13570</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="PrivilegeList">SeTimeZonePrivilege</Data>
</EventData>
</Event>
Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that made a change to local user right policy. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that made a change to local user right
policy.
the following:
Target Account:
Account Name [Type = SID]: the SID of security principal for which user rights were removed. Event Viewer
**Removed Right: **
User Right [Type = UnicodeString]: the list of removed user rights. This event generates only for user rights, not
logon rights. Here is the list of possible user rights:


a process.

operations.
held:
READ_CONTROL
FILE_GENERIC_READ
FILE_TRAVERSE





creation APIs.

account.
components.

a process.
interface.
to a process.
users.
driver.

memory.
computer account.
controllers.

defragmentation.

system processes.

network request.

held:
WRITE_DAC
WRITE_OWNER
FILE_GENERIC_WRITE
FILE_ADD_FILE
DELETE
an object.

security event log.
synchronization.
information.

processes.
clock.



a terminal device.

For 4705(S): A user right was removed.
Non-active accounts: You might have non-active, disabled, Monitor this event with the Subject\Security ID or Target
or guest accounts, or other accounts that should never be Account\Account Name that correspond to the accounts
used. that should never be used.
If you have specific user rights policies, for example, a whitelist
of accounts that can perform certain actions, monitor this
event to confirm that it was appropriate that the Removed
Right was removed from Target Account\Account Name.
for example, local or domain account, machine or user Target Account\Account Name to see whether the
For example, if some accounts have critical user rights which
should never be removed, monitor this event for the Target
Account\Account Name and the appropriate rights.
As another example, if non-administrative accounts should
never be granted certain user rights (for example,
SeAuditPrivilege), you might monitor this event, because a
right can be removed only after it was previously granted.
events).
people (accounts) should perform only limited actions, or no concerned about. Also be sure to check Target
actions at all. Account\Account Name to see whether user rights should
be removed from that account (or whether that account
should have any rights on that computer).
Removed Right should be removed from Target
Account\Account Name in each case.
User rights that should be restricted: You might have a list Monitor this event and compare the Removed Right to
of user rights that you want to monitor. your list of restricted rights.
Monitor this event to discover the removal of a right that
should never have been granted (for example, SeTcbPrivilege),
so that you can investigate further.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates when the permissions
for an object are changed. The object could
be a file system, registry, or security token
object.
SACL.

event.
Event XML:
- <System>
<Level>0</Level>
<Task>13570</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
the following:
Object:
typically equals -.
appears as 0x0.
Process:
Permissions Change:
New Security Descriptor [Type = UnicodeString]: the new Security Descriptor Definition Language
Example:
(BUILTIN_ADMINISTRATORS), WD (Everyone), SY (LOCAL_SYSTEM), etc. See the list of possible values in
the table below:

Windows 2000


operators

administrators

controllers
G: = Primary Group.
D: = DACL Entries.
S: = SACL Entries.
entry_type:
D - DACL
S - SACL
inheritance_flags:
ace_type:
"D" - ACCESS DENIED
"AU" - SYSTEM AUDIT
"A" - SYSTEM ALARM
ace_flags:
"CI" - CONTAINER INHERIT: Child objects that are containers, such as directories, inherit the ACE as an explicit
ACE.

rights

"KX" KEY EXECUTE
object_guid: N/A
account_sid: SID of specific security principal, or reserved value, for example: AN (Anonymous), WD
(Everyone), SY (LOCAL_SYSTEM), etc. See the table above for more details.
us/library/cc230374.aspx, https://msdn.microsoft.com/en-
us/library/windows/hardware/aa374892(v=vs.85).aspx.

For token objects, this is typically an informational event, and at the same time it is difficult to identify which
token's permission were changed. For token objects, there are no monitoring recommendations for this event in
this document.
4911(S): Resource attributes of the object were
changed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit
Authorization Policy Change
Event Description:
This event generates when
resource attributes of the file
system object were changed.
Resource attributes for file or
folder can be changed, for
example, using Windows File
Explorer (objects Properties-
>Classification tab).
Note For recommendations,

see Security Monitoring
Recommendations for this
event.
Event XML:
- <System>
<Level>0</Level>
<Task>13570</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectName">C:\\Audit Files\\HBI Data.txt</Data>
<Data Name="HandleId">0x49c</Data>
<Data Name="NewSd">S:ARAI(RA;ID;;;;WD;("Impact\_MS",TI,0x10020,3000))</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that changed the resource attributes of the file system object. Event
Account Name [Type = UnicodeString]: the name of the account that changed the resource attributes of
the file system object.
the following:
Object:
Object Name [Type = UnicodeString]: full path and/or name of the object for which resource attributes were
changed.
this event with other events that might contain the same Handle ID, for example, 4663(S): An attempt was
made to access an object. This parameter might not be captured in the event, and in that case appears as 0x0.
Process ID [Type = Pointer]: hexadecimal Process ID of the process through which the resource attributes of
the file system object were changed. Process ID (PID) is a number used by the operating system to uniquely
identify an active process. To see the PID for a specific process you can, for example, use Task Manager
(Details tab, PID column):
Resource Attributes:
Original Security Descriptor [Type = UnicodeString]: the Security Descriptor Definition Language (SDDL)
value for the old resource attributes.
For example: S:AI(RA;ID;;;;WD;("Impact_MS",TI,0x10020,3000))
If no resource attributes were set to the object, then SDDL will not contain any attributes, for example S:AI.
New Security Descriptor [Type = UnicodeString]: the Security Descriptor Definition Language (SDDL) value
for the new resource attributes. See more information in Resource Attributes\Original Security Descriptor
field section for this event.
Example:
table below:

Windows 2000

operators

administrators


controllers
G: = Primary Group.
D: = DACL Entries.
S: = SACL Entries.
entry_type:
D - DACL
S - SACL
inheritance_flags:
ace_type:
"D" - ACCESS DENIED
"AU" - SYSTEM AUDIT
"A" - SYSTEM ALARM
ace_flags:

rights
"KX" KEY EXECUTE
object_guid: N/A

For 4911(S): Resource attributes of the object were changed.
If you need to monitor all changes to specific files or folders (in this case, changes to resource attributes),
monitor for the Object Name that corresponds to the file or folder.
You can track changes when, for example, a file was marked as High Impact, or was changed from High
Impact to Medium Impact, or a resource was marked as a data type for a specific department and so on. This
event can help track changes and resource attribute assignments, which you can see in Original Security
Descriptor and New Security Descriptor fields.
4913(S): Central Access Policy on the object was
changed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Authorization Policy Change

Event Description:
This event generates when a Central Access Policy on a file system object is changed.
This event always generates, regardless of the objects SACL settings.
Event XML:
- <System>
<Level>0</Level>
<Task>13570</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectName">C:\\Audit Files\\HBI Data.txt</Data>
<Data Name="HandleId">0x3d4</Data>
<Data Name="NewSd">S:ARAI(SP;ID;;;;S-1-17-1442530252-1178042555-1247349694-2318402534)</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that changed the Central Access Policy on the object. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that changed the Central Access Policy on
the object.
the following:
Object:
Object Name [Type = UnicodeString]: full path and/or name of the object on which the Central Access Policy
was changed.
this event with other events that might contain the same Handle ID, for example, 4663(S): An attempt was
made to access an object. This parameter might not be captured in the event, and in that case appears as 0x0.
Process:
Process ID [Type = Pointer]: hexadecimal Process ID of the process using which Central Access Policy was
has been created Process Information\New Process ID field.
Central Policy ID:
Original Security Descriptor [Type = UnicodeString]: the Security Descriptor Definition Language (SDDL)
value for the old Central Policy ID (for the policy that was formerly applied to the object).
SDDL contains Central Access Policy SID, here is an example: S:ARAI(SP;ID;;;;S-1-17-1442530252-
1178042555-1247349694-2318402534), Central Access Policy SID here is S-1-17-1442530252-
1178042555-1247349694-2318402534. To resolve this SID to the real Central Access Policy name you
need to do the following:
1. Find Central Access Policy Active Directory object in: CN=Central Access Policies,CN=Claims
Configuration,CN=Services,CN=Configuration,DC=XXX,DC=XX Active Directory container.
2. Open objects Properties.
3. Find msAuthz-CentralAccessPolicyID attribute.
4. Convert hexadecimal value to SID (string). Here you can see more information about how to perform this
action: https://social.technet.microsoft.com/Forums/scriptcenter/en-US/11585f2c-ed0d-4c2b-a2b6-
ef2aa07b3745/how-to-convert-sid.
<img src="images/adsi-edit.png" alt="ADSI Edit illustration" width="763" height="454" hspace=10" align="left"
/>
If no Central Access Policies were applied to the object, then SDDL will not contain any SIDs, for example S:AI.
New Security Descriptor [Type = UnicodeString]: the Security Descriptor Definition Language (SDDL) value
for the new Central Policy ID (for the policy that has been applied to the object). See more information in
Central Policy ID\Original Security Descriptor field section for this event.
Example:
table below:

Windows 2000

operators

administrators

controllers
G: = Primary Group.
D: = DACL Entries.
S: = SACL Entries.
entry_type:
D - DACL
S - SACL
inheritance_flags:
ace_type:
"D" - ACCESS DENIED
"AU" - SYSTEM AUDIT
"A" - SYSTEM ALARM
ace_flags:

rights
"KX" KEY EXECUTE
object_guid: N/A

For 4913(S): Central Access Policy on the object was changed.
If you need to monitor all changes to specific files or folders (in this case, changes to the Central Access
Policy), monitor for the Object Name that corresponds to the file or folder.
If you have specific files, folders, or entire systems to which a specific Central Access Policy should be
applied, you can monitor this event and compare the Central Access Policy SID in New Security
Descriptor to see if it matches the expected policy.
Audit Filtering Platform Policy Change
Applies to
Windows 10
Windows Server 2016
Audit Filtering Platform Policy Change allows you to audit events generated by changes to the Windows Filtering
Platform (WFP), such as the following:
IPsec services status.
Changes to IPsec policy settings.
Changes to Windows Filtering Platform Base Filtering Engine policy settings.
Changes to WFP providers and engine.
packets, monitor or authorize connections, filter Internet Protocol security (IPsec)-protected traffic, and filter remote
procedure calls (RPCs).
This subcategory is outside the scope of this document.
STRONGER STRONGER
Domain - - - - This subcategory

Controller is outside the
scope of this
document.
Member Server - - - - This subcategory

is outside the
scope of this
document.
Workstation - - - - This subcategory

is outside the
scope of this
document.
4709(S): IPsec Services was started.

4710(S): IPsec Services was disabled.
4711(S): May contain any one of the following:
4712(F): IPsec Services encountered a potentially serious failure.
5040(S): A change has been made to IPsec settings. An Authentication
Set was added.
Set was modified.
Set was deleted.
5043(S): A change has been made to IPsec settings. A Connection
Security Rule was added.
Security Rule was modified.
Security Rule was deleted.
5046(S): A change has been made to IPsec settings. A Crypto Set was
added.
modified.
deleted.
5440(S): The following callout was present when the Windows Filtering
Platform Base Filtering Engine started.
5441(S): The following filter was present when the Windows Filtering
Platform Base Filtering Engine started.
5442(S): The following provider was present when the Windows
Filtering Platform Base Filtering Engine started.
5443(S): The following provider context was present when the
Windows Filtering Platform Base Filtering Engine started.
5444(S): The following sub-layer was present when the Windows
Filtering Platform Base Filtering Engine started.
5446(S): A Windows Filtering Platform callout has been changed.
5448(S): A Windows Filtering Platform provider has been changed.
5449(S): A Windows Filtering Platform provider context has been
changed.
5450(S): A Windows Filtering Platform sub-layer has been changed.
5456(S): PAStore Engine applied Active Directory storage IPsec policy
on the computer.
5457(F): PAStore Engine failed to apply Active Directory storage IPsec
policy on the computer.
5458(S): PAStore Engine applied locally cached copy of Active Directory
storage IPsec policy on the computer.
5459(F): PAStore Engine failed to apply locally cached copy of Active
Directory storage IPsec policy on the computer.
5460(S): PAStore Engine applied local registry storage IPsec policy on
the computer.
5461(F): PAStore Engine failed to apply local registry storage IPsec
policy on the computer.
5462(F): PAStore Engine failed to apply some rules of the active IPsec
policy on the computer. Use the IP Security Monitor snap-in to
diagnose the problem.
5463(S): PAStore Engine polled for changes to the active IPsec policy
and detected no changes.
5464(S): PAStore Engine polled for changes to the active IPsec policy,
detected changes, and applied them to IPsec Services.
5465(S): PAStore Engine received a control for forced reloading of IPsec
policy and processed the control successfully.
5466(F): PAStore Engine polled for changes to the Active Directory
IPsec policy, determined that Active Directory cannot be reached, and
will use the cached copy of the Active Directory IPsec policy instead.
Any changes made to the Active Directory IPsec policy since the last
poll could not be applied.
5467(F): PAStore Engine polled for changes to the Active Directory
IPsec policy, determined that Active Directory can be reached, and
found no changes to the policy. The cached copy of the Active
Directory IPsec policy is no longer being used.
5468(S): PAStore Engine polled for changes to the Active Directory
IPsec policy, determined that Active Directory can be reached, found
changes to the policy, and applied those changes. The cached copy of
the Active Directory IPsec policy is no longer being used.
5471(S): PAStore Engine loaded local storage IPsec policy on the
computer.
5472(F): PAStore Engine failed to load local storage IPsec policy on the
computer.
5473(S): PAStore Engine loaded directory storage IPsec policy on the
computer.
5474(F): PAStore Engine failed to load directory storage IPsec policy on
the computer.
5477(F): PAStore Engine failed to add quick mode filter.
Audit MPSSVC Rule-Level Policy Change
Applies to
Windows 10
Windows Server 2016
Audit MPSSVC Rule-Level Policy Change determines whether the operating system generates audit events when
changes are made to policy rules for the Microsoft Protection Service (MPSSVC.exe).
The Microsoft Protection Service, which is used by Windows Firewall, is an integral part of the computers threat
protection against malware. The tracked activities include:
Active policies when the Windows Firewall service starts.
Changes to Windows Firewall rules.
Changes to the Windows Firewall exception list.
Changes to Windows Firewall settings.
Rules ignored or not applied by the Windows Firewall service.
Changes to Windows Firewall Group Policy settings.
Changes to firewall rules are important for understanding the security state of the computer and how well it is
protected against network attacks.
Event volume: Medium.
STRONGER STRONGER
Domain Yes Yes Yes Yes Success events

Controller shows you
changes in
Windows Firewall
rules and
settings, active
configuration
and rules after
Windows Firewall
Service startup
and default
configuration
restore actions.
Failure events
may help to
identify
configuration
problems with
Windows Firewall
rules or settings.
STRONGER STRONGER
Member Server Yes Yes Yes Yes Success events

shows you
changes in
Windows Firewall
rules and
settings, active
configuration
and rules after
Windows Firewall
Service startup
and default
configuration
restore actions.
Failure events
may help to
identify
configuration
problems with
Windows Firewall
rules or settings.
Workstation Yes Yes Yes Yes Success events

shows you
changes in
Windows Firewall
rules and
settings, active
configuration
and rules after
Windows Firewall
Service startup
and default
configuration
restore actions.
Failure events
may help to
identify
configuration
problems with
Windows Firewall
rules or settings.
Events List:
4944(S): The following policy was active when the Windows Firewall started.
4945(S): A rule was listed when the Windows Firewall started.
4946(S): A change has been made to Windows Firewall exception list. A rule was added.
4947(S): A change has been made to Windows Firewall exception list. A rule was modified.
4948(S): A change has been made to Windows Firewall exception list. A rule was deleted.
4949(S): Windows Firewall settings were restored to the default values.
4950(S): A Windows Firewall setting has changed.
4951(F): A rule has been ignored because its major version number was not recognized by Windows
Firewall.
4952(F): Parts of a rule have been ignored because its minor version number was not recognized by
Windows Firewall. The other parts of the rule will be enforced.
4953(F): A rule has been ignored by Windows Firewall because it could not parse the rule.
4954(S): Windows Firewall Group Policy settings have changed. The new settings have been applied.
4956(S): Windows Firewall has changed the active profile.
4957(F): Windows Firewall did not apply the following rule:
4958(F): Windows Firewall did not apply the following rule because the rule referred to items not
configured on this computer:
4944(S): The following policy was active when the
Windows Firewall started.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit MPSSVC Rule-Level Policy
Change
Event Description:
This event generates every time Windows
Firewall service starts.
This event shows Windows Firewall settings
that were in effect when the Windows Firewall
service started.

Event XML:
- <System>
<Level>0</Level>
<Task>13571</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="GroupPolicyApplied">No</Data>
<Data Name="Profile">Public</Data>
<Data Name="OperationMode">Off</Data>
<Data Name="RemoteAdminEnabled">Disabled</Data>
<Data Name="MulticastFlowsEnabled">Enabled</Data>
<Data Name="LogDroppedPacketsEnabled">Disabled</Data>
<Data Name="LogSuccessfulConnectionsEnabled">Disabled</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Group Policy Applied [Type = UnicodeString]: it always has No value for this event. This field should show
information about: was Group Policy applied for Windows Firewall when it starts or not.
Profile Used [Type = UnicodeString]: shows the active profile name for the moment Windows Firewall service
starts. It always has value Public for this event, because when this event generates, the active profile is not
switched to Domain or Private. Typically you will see 4956(S): Windows Firewall has changed the active
profile after this event, which will tell you the real active profile.
Operational mode [Type = UnicodeString]:
On if Firewall state: setting was set to On for Public profile.
Off - if Firewall state: setting was set to Off for Public profile.
Allow Remote Administration [Type = UnicodeString]: looks like this setting is connected to Windows Firewall:
Allow remote administration exception Group Policy setting, but it is always Disabled, no matter which option is
set for Windows Firewall: Allow remote administration exception Group Policy.
Allow Unicast Responses to Multicast/Broadcast Traffic [Type = UnicodeString]:
Enabled - if Allow unicast response: Settings configuration was set to Yes for Public profile.
Disabled - if Allow unicast response: Settings configuration was set to No for Public profile.
Security Logging:
Log Dropped Packets [Type = UnicodeString]:
Enabled if Log dropped packets: Logging configuration was set to Yes for Public profile.
Disabled - if Log dropped packets: Logging configuration was set to No for Public profile.
Log Successful Connections [Type = UnicodeString]:
Enabled - if Log successful connections: Logging configuration was set to Yes for Public
profile.
Disabled - if Log dropped packets: Logging configuration was set to No for Public profile.

For 4944(S): The following policy was active when the Windows Firewall started.
If you have a standard or baseline for Windows Firewall settings defined for Public profile (which can be the
same as for Domain, for example), monitor this event and check whether the settings reported by the event
are still the same as were defined in your standard or baseline.
Unfortunately this event shows configuration only for Public profile, but you can still compare all the
settings with your organization's Windows Firewall baseline for Public profile on different computers and
trigger an alert if the configuration is not the same.
4945(S): A rule was listed when the Windows Firewall
started.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
Firewall service starts.
This event shows the inbound and/or
outbound rule which was listed when the
Windows Firewall started and applied for
Public profile.
This event generates per rule.

Event XML:
- <System>
<Level>0</Level>
<Task>13571</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ProfileUsed">Public</Data>
<Data Name="RuleId">NPS-NPSSvc-In-RPC</Data>
<Data Name="RuleName">Network Policy Server (RPC)</Data>
</EventData>
</Event>
Event Versions: 0.
Field Descriptions:
Profile used [Type = UnicodeString]: the name of the profile that the rule belongs to. It always has value Public,
because this event shows rules only for Public profile.
Rule:
Rule ID [Type = UnicodeString]: the unique firewall rule identifier.
To see the unique ID of the rule you need to navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallP
olicy\FirewallRules registry key and you will see the list of Windows Firewall rule IDs (Name column)
with parameters:
Rule Name [Type = UnicodeString]: the name of the rule which was listed when the Windows Firewall started.
You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management
console (wf.msc), check Name column:

For 4945(S): A rule was listed when the Windows Firewall started.
Unfortunately this event shows rules only for Public profile, but you still can compare this list with your
organization's Windows Firewall baseline for Public profile rules on different computers, and trigger an alert
if the configuration is not the same.
4946(S): A change has been made to Windows
Firewall exception list. A rule was added.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
This event generates when new rule was locally
added to Windows Firewall.
This event doesn't generate when new rule was
added via Group Policy.

Event XML:
- <System>
<Level>0</Level>
<Task>13571</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ProfileChanged">All</Data>
<Data Name="RuleId">{F2649D59-1355-4E3C-B886-CDD08B683199}</Data>
<Data Name="RuleName">Allow All Rule</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Profile Changed [Type = UnicodeString]: the list of profiles to which new rule was applied. Examples:
All
Domain,Public
Domain,Private
Private,Public
Public
Domain
Private
Added Rule:
Rule ID [Type = UnicodeString]: the unique new firewall rule identifier.
with parameters:
Rule Name [Type = UnicodeString]: the name of the rule which was added. You can see the name of Windows
Firewall rule using Windows Firewall with Advanced Security management console (wf.msc), check Name
column:

For 4946(S): A change has been made to Windows Firewall exception list. A rule was added.
This event can be helpful in case you want to monitor all creations of new Firewall rules which were done locally.
Firewall exception list. A rule was modified.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
This event generates when Windows Firewall
rule was modified.
This event doesn't generate when Firewall rule
was modified via Group Policy.

Event XML:
- <System>
<Level>0</Level>
<Task>13571</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Profile Changed [Type = UnicodeString]: the list of profiles to which changed rule is applied. Examples:
All
Domain,Public
Domain,Private
Private,Public
Public
Domain
Private
Modified Rule:
Rule ID [Type = UnicodeString]: the unique identifier for modified firewall rule.
with parameters:
Rule Name [Type = UnicodeString]: the name of the rule which was modified. You can see the name of
Windows Firewall rule using Windows Firewall with Advanced Security management console (wf.msc), check
Name column:

For 4947(S): A change has been made to Windows Firewall exception list. A rule was modified.
This event can be helpful in case you want to monitor all Firewall rules modifications which were done locally.
Firewall exception list. A rule was deleted.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
rule was deleted.
This event doesn't generate when the rule was
deleted via Group Policy.

Event XML:
- <System>
<Level>0</Level>
<Task>13571</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Profile Changed [Type = UnicodeString]: the list of profiles to which deleted rule was applied. Examples:
All
Domain,Public
Domain,Private
Private,Public
Public
Domain
Private
Deleted Rule:
Rule ID [Type = UnicodeString]: the unique identifier for deleted firewall rule.
with parameters:
Rule Name [Type = UnicodeString]: the name of the rule which was deleted. You can see the name of Windows
column:

For 4948(S): A change has been made to Windows Firewall exception list. A rule was deleted.
This event can be helpful in case you want to monitor all deletions of Firewall rules which were done locally.
4949(S): Windows Firewall settings were restored to
the default values.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
settings were locally restored to the default
configuration.

Event XML:
- <System>
<Level>0</Level>
<Task>13571</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
<EventData />
</Event>

Event Versions: 0.

For 4949(S): Windows Firewall settings were restored to the default values.
You shouldnt see this event during normal Windows Firewall operations, because it should be intentionally
done by user or software. This event should be always monitored and an alert should be triggered, especially
on critical computers or devices.
This event can be helpful in case you want to monitor all changes of Firewall rules which were done locally,
especially restores to default configuration.
4950(S): A Windows Firewall setting has changed.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
local setting was changed.
This event doesn't generate when Windows
Firewall setting was changed via Group Policy.

Event XML:
- <System>
<Level>0</Level>
<Task>13571</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ProfileChanged">Domain</Data>
<Data Name="SettingType">Default Outbound Action</Data>
<Data Name="SettingValue">Block</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Changed Profile [Type = UnicodeString]: the name of profile in which setting was changed. Possible values are:
Public
Domain
Private
New Setting:
Type [Type = UnicodeString]: the name of the setting which was modified. You can use netsh advfirewall
command to see or set Windows Firewall settings, for example, to see settings for current\active Windows
Firewall profile you need to execute netsh advfirewall show currentprofile command:
Value [Type = UnicodeString]: new value of modified setting.

For 4950(S): A Windows Firewall setting has changed.
If you have a standard or baseline for Windows Firewall settings defined, monitor this event and check
whether the settings reported by the event are still the same as were defined in your standard or baseline.
This event can be helpful in case you want to monitor all changes in Windows Firewall settings which were
done locally.
4951(F): A rule has been ignored because its major
version number was not recognized by Windows
Firewall.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
When you create or edit a Windows Firewall
rule, the settings that you can include depend
upon the version of Windows you use when
creating the rule. As new settings are added to
later versions of Windows or to service packs
for existing versions of Windows, the version
number of the rules processing engine is
updated, and that version number is stamped
into rules that are created by using that version
of Windows. For example, Windows Vista
produces firewall rules that are stamped with
version "v2.0". Future versions of Windows might use "v2.1", or "v3.0" to indicate, respectively, minor or major
changes and additions.
If you create a firewall rule on a newer version of Windows that references firewall settings that are not available on
earlier versions of Windows, and then try to deploy that rule to computers running the earlier version of Windows,
the firewall engine produces this error to indicate that it cannot process the rule.
The only solution is to remove the incompatible rule, and then deploy a compatible rule.
Event XML:
- <System>
<Level>0</Level>
<Task>13571</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="Profile">All</Data>
<Data Name="RuleId">{08CBB349-D158-46BE-81E1-2ABC59BDD523}</Data>
<Data Name="RuleName">-</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Profile [Type = UnicodeString]: the name of the profile of the ignored rule. Possible values are:
All
Domain,Public
Domain,Private
Private,Public
Public
Domain
Private
Ignored Rule:
ID [Type = UnicodeString]: the unique identifier for ignored firewall rule.
with parameters:
Name [Type = UnicodeString]: the name of the rule which was ignored. You can see the name of Windows
column:

For 4951(F): A rule has been ignored because its major version number was not recognized by Windows Firewall.
This event can be a sign of software issues, Windows Firewall registry errors or corruption, or Group Policy
setting misconfigurations. We recommend monitoring this event and investigating the reason for the condition.
Typically this event indicates configuration issues, not security issues.
4952(F): Parts of a rule have been ignored because its
minor version number was not recognized by
Windows Firewall. The other parts of the rule will be
enforced.
Applies to
Windows 10
Windows Server 2016
When you create or edit a Windows Firewall rule, the settings that you can include depend upon the version of
Windows you use when creating the rule. As new settings are added to later versions of Windows or to service
packs for existing versions of Windows, the version number of the rules processing engine is updated, and that
version number is stamped into rules that are created by using that version of Windows. For example, Windows
Vista produces firewall rules that are stamped with version "v2.0". Future versions of Windows might use "v2.1", or
"v3.0" to indicate, respectively, minor or major changes and additions.
If you create a firewall rule on a newer version of Windows that references firewall settings that are not available on
earlier versions of Windows, and then try to deploy that rule to computers running the earlier version of Windows,
the firewall engine produces this error to indicate that it cannot process the rule.
The only solution is to remove the incompatible rule, and then deploy a compatible rule.
Subcategory: Audit MPSSVC Rule-Level Policy Change
Event Schema:
Parts of a rule have been ignored because its minor version number was not recognized by Windows Firewall. The
other parts of the rule will be enforced.
%t
Profile:%t%1
Partially Ignored Rule:
%tID:%t%2
%tName:%t%3
Event Versions: 0.

4953(F): Windows Firewall ignored a rule because it
could not be parsed.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
This event generates if Windows Firewall was
not able to parse Windows Firewall rule for
some reason.
It can happen if Windows Firewall rule registry
entry was corrupted.

Event XML:
- <System>
<Level>0</Level>
<Task>13571</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="Profile">All</Data>
<Data Name="ReasonForRejection">An error occurred.</Data>
<Data Name="RuleId">{08CBB349-D158-46BE-81E1-2ABC59BDD523}</Data>
<Data Name="RuleName">-</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Profile [Type = UnicodeString]: the name of the profile of the ignored rule. Possible values are:
All
Domain,Public
Domain,Private
Private,Public
Public
Domain
Private
Reason for Rejection [Type = UnicodeString]: the reason, why the rule was ignored.
Rule:
ID [Type = UnicodeString]: the unique identifier for ignored firewall rule.
with parameters:
Name [Type = UnicodeString]: the name of the rule which was ignored. You can see the name of Windows
column:
For 4953(F): Windows Firewall ignored a rule because it could not be parsed.
4954(S): Windows Firewall Group Policy settings have
changed. The new settings have been applied.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
Firewall group policy is changed, locally or
from Active Directory Group Policy.
This event generates every time local Group
Policy is refreshed, even if no Windows Firewall
settings were modified or presented.

Event XML:
- <System>
<Level>0</Level>
<Task>13571</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
<EventData />
</Event>

Event Versions: 0.
For 4954(S): Windows Firewall Group Policy settings have changed. The new settings have been applied.
Unfortunately this event generates every time local Group Policy is refreshed and does not indicate that settings
really were modified. Typically this event can be ignored.
4956(S): Windows Firewall has changed the active
profile.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
has changed the active profile.

Event XML:
- <System>
<Level>0</Level>
<Task>13571</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ActiveProfile">Domain</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
New Active Profile [Type = UnicodeString]: the name of the new active profile. Possible values are:
Domain
Public
Private

For 4956(S): Windows Firewall has changed the active profile.
For domain joined machines you could monitor for all events where New Active Profile doesnt equal
Domain. This indicates that the computer was connected to another non-domain network.
4957(F): Windows Firewall did not apply the following
rule.
Applies to
Windows 10
Windows Server 2016
Change
Event Description:
starts or apply new rule, and the rule cannot be
applied for some reason.

Event XML:
- <System>
<Level>0</Level>
<Task>13571</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="RuleId">CoreNet-Teredo-In</Data>
<Data Name="RuleName">Core Networking - Teredo (UDP-In)</Data>
<Data Name="RuleAttr">Local Port</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Rule Information:
ID [Type = UnicodeString]: the unique identifier for not applied firewall rule.
with parameters:
Name [Type = UnicodeString]: the name of the rule which was not applied. You can see the name of Windows
column:
Error Information:
Reason [Type = UnicodeString]: the reason why the rule was not applied.

For 4957(F): Windows Firewall did not apply the following rule.
4958(F): Windows Firewall did not apply the following
rule because the rule referred to items not configured
on this computer.
Applies to
Windows 10
Windows Server 2016
Windows Firewall with Advanced Security processed a rule that contains parameters that cannot be resolved on the
local computer. The rule is therefore not enforceable on the computer and so is excluded from the runtime state of
the firewall. This is not necessarily an error. Examine the rule for applicability on the computers to which it was
applied.
Subcategory: Audit MPSSVC Rule-Level Policy Change
Event Schema:
Windows Firewall did not apply the following rule because the rule referred to items not configured on this
computer: Rule Information: %tID:%t%1 %tName:%t%2 Error Information: %tError:%t%3 %tReason:%t%4
Event Versions: 0.

Audit Other Policy Change Events
Applies to
Windows 10
Windows Server 2016
Audit Other Policy Change Events contains events about EFS Data Recovery Agent policy changes, changes in
Windows Filtering Platform filter, status on Security policy settings updates for local Group Policy settings,
Central Access Policy changes, and detailed troubleshooting events for Cryptographic Next Generation (CNG)
operations.
Event volume: Low.
STRONGER STRONGER
STRONGER STRONGER
Domain IF Yes IF Yes IF - We do not

Controller recommend
Success auditing
because of event
5447: A
Windows
Filtering Platform
filter has been
changedthis
event generates
many times
during group
policy updates
and typically is
used for
troubleshooting
purposes for
Windows
Filtering Platform
filters. But you
would still need
to enable Success
auditing for this
subcategory if,
for example, you
must monitor
changes in Boot
Configuration
Data or Central
Access Policies.
We recommend
Failure auditing,
to detect errors
in applied
Security settings
which came from
Group Policy,
and failure
events related to
Cryptographic
Next Generation
(CNG) functions.
STRONGER STRONGER
Member Server IF Yes IF Yes IF - We do not

recommend
Success auditing
because of event
5447: A
Windows
Filtering Platform
filter has been
changedthis
event generates
many times
during group
policy updates
and typically is
used for
troubleshooting
purposes for
Windows
Filtering Platform
filters. But you
would still need
to enable Success
auditing for this
subcategory if,
for example, you
must monitor
changes in Boot
Configuration
Data or Central
Access Policies.
We recommend
Failure auditing,
to detect errors
in applied
Security settings
which came from
Group Policy,
and failure
events related to
Cryptographic
Next Generation
(CNG) functions.
STRONGER STRONGER
Workstation IF Yes IF Yes IF - We do not

recommend
Success auditing
because of event
5447: A
Windows
Filtering Platform
filter has been
changedthis
event generates
many times
during group
policy updates
and typically is
used for
troubleshooting
purposes for
Windows
Filtering Platform
filters. But you
would still need
to enable Success
auditing for this
subcategory if,
for example, you
must monitor
changes in Boot
Configuration
Data or Central
Access Policies.
We recommend
Failure auditing,
to detect errors
in applied
Security settings
which came from
Group Policy,
and failure
events related to
Cryptographic
Next Generation
(CNG) functions.
Events List:
4714(S): Encrypted data recovery policy was changed.
4819(S): Central Access Policies on the machine have been changed.
4826(S): Boot Configuration Data loaded.
4909(-): The local policy settings for the TBS were changed.
4910(-): The group policy settings for the TBS were changed.
5063(S, F): A cryptographic provider operation was attempted.
5064(S, F): A cryptographic context operation was attempted.
5065(S, F): A cryptographic context modification was attempted.
5066(S, F): A cryptographic function operation was attempted.
5067(S, F): A cryptographic function modification was attempted.
5068(S, F): A cryptographic function provider operation was attempted.
5069(S, F): A cryptographic function property operation was attempted.
5070(S, F): A cryptographic function property modification was attempted.
5447(S): A Windows Filtering Platform filter has been changed.
6144(S): Security policy in the group policy objects has been applied successfully.
6145(F): One or more errors occurred while processing security policy in the group policy objects.
4714(S): Encrypted data recovery policy was changed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Other Policy Change
Events
Event Description:
This event generates when a Data Recovery
Agent group policy for Encrypting File System
(EFS) has changed.
This event generates when a Data Recovery
Agent certificate or Data Recovery Agent policy
was changed for the computer or device.
In the background, this event generates when
the
\HKLM\Software\Policies\Microsoft\SystemCertificates\EFS\EfsBlob registry value is changed during a Group
Policy update.
Event XML:
- <System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
<Level>0</Level>
<Task>13573</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <ProcessingErrorData>
<ErrorCode>13</ErrorCode>
<DataItemName>SubjectUserSid</DataItemName>
<EventPayload />
</ProcessingErrorData>
</Event>
Event Versions: 0.

For 4714(S): Encrypted data recovery policy was changed.
We recommend monitoring this event and if the change was not planned, investigate the reason for the change.
4819(S): Central Access Policies on the machine have
been changed.
Applies to
Windows 10
Windows Server 2016
Events
Event Description:
This event generates when Central Access
Policy on the machine have been changed.
For example, it generates when a new Central
Access Policy was applied to the machine via
Group Policy.

Event XML:
- <System>
<Level>0</Level>
<Task>13573</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectType">Central Access Policies</Data>
<Data Name="AddedCAPs">Main POlicy</Data>
<Data Name="DeletedCAPs" />
<Data Name="ModifiedCAPs" />
<Data Name="AsIsCAPs" />
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that changed the Central Access Policies on the machine. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that changed the Central Access Policies
on the machine.
following:
Object:
Object Server [Type = UnicodeString]: has LSA value for this event.
Object Type [Type = UnicodeString]: The type of an object to which this event applies. Always Central
Access Policies for this event.
Profile Desktop KeyedEvent Central Access Policies
CAPs Added [Type = UnicodeString]: the list of added Central Access Policies. Empty if no Central Access Policies
were added.
CAPs Deleted [Type = UnicodeString]: the list of deleted Central Access Policies. Empty if no Central Access
Policies were deleted.
CAPs Modified [Type = UnicodeString]: the list of modified Central Access Policies. Empty if no Central Access
Policies were modified.
CAPs As-Is [Type = UnicodeString]: the list of non-modified Central Access Policies.

For 4819(S): Central Access Policies on the machine have been changed.
This event can help you to track modifications, additions and deletions of Central Access Policies if it is
required by your security monitoring policy.
4826(S): Boot Configuration Data loaded.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Other Policy Change Events
Event Description:
This event generates every time system starts
and load current Boot Configuration Data (BCD)
settings.
"Audit Other Policy Change Events" sub-category
setting.

Event XML:
- <System>
<Level>0</Level>
<Task>13573</Task>
<Opcode>0</Opcode>
<Correlation />
<Computer>WIN10-1</Computer>
<Security />
</System>
- <EventData>
<Data Name="LoadOptions">-</Data>
<Data Name="AdvancedOptions">%%1843</Data>
<Data Name="ConfigAccessPolicy">%%1846</Data>
<Data Name="RemoteEventLogging">%%1843</Data>
<Data Name="KernelDebug">%%1843</Data>
<Data Name="VsmLaunchType">%%1848</Data>
<Data Name="TestSigning">%%1843</Data>
<Data Name="FlightSigning">%%1843</Data>
<Data Name="DisableIntegrityChecks">%%1843</Data>
<Data Name="HypervisorLoadOptions">-</Data>
<Data Name="HypervisorLaunchType">%%1848</Data>
<Data Name="HypervisorDebug">%%1843</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that reported this event. Event Viewer automatically tries to resolve
SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event. Always
S-1-5-18 for this event.
Account Name [Type = UnicodeString]: the name of the account that reported this event. Always - for this
event.
Account Domain [Type = UnicodeString]: subjects domain or computer name. Always - for this event.
General Settings:
Load Options [Type = UnicodeString]: there is no information about this field in this document.
Advanced Options [Type = UnicodeString]: shows whether Windows is configured for system boot to the
legacy menu (F8 menu) on the next boot (Yes or No). You can enable advanced boot using bcdedit /set
onetimeadvancedoptions yes command.
Configuration Access Policy [Type = UnicodeString]: there is no information about this field in this
document.
System Event Logging [Type = UnicodeString]: there is no information about this field in this document.
Kernel Debugging [Type = UnicodeString]: shows whether Windows kernel debugging is enabled or not
(Yes or No). You can enable kernel debugging using bcdedit /debug on command.
VSM Launch Type [Type = UnicodeString]: there is no information about this field in this document.
Signature Settings:
Test Signing [Type = UnicodeString]: shows whether Windows test signing is enabled or not (Yes or No). You
can disable test signing using bcdedit /set testsigning off command.
Note This parameter controls whether Windows 8.1, Windows 8, Windows 7, Windows Server 2008, or
Windows Vista will load any type of test-signed kernel-mode code. This option is not set by default, which
means test-signed kernel-mode drivers on 64-bit versions of Windows 8.1, Windows 8, Windows 7, Windows
Server 2008, and Windows Vista will not load by default. After you run the BCDEdit command, restart the
computer so that the change takes effect. For more information, see Introduction to Test-Signing.
Flight Signing [Type = UnicodeString]: shows whether Windows flight signing (which allows flight-signed
code signing certificates) is enabled or not (Yes or No). You can disable flight signing using bcdedit /set
flightsigning off command.
Disable Integrity Checks [Type = UnicodeString]: shows whether Windows integrity check is disabled or
not (Yes or No). You can disable integrity checks using bcdedit /set nointegritychecks on command.
HyperVisor Settings:
HyperVisor Load Options [Type = UnicodeString]: shows hypervisor loadoptions. See more information
here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff542202(v=vs.85).aspx.
HyperVisor Launch Type [Type = UnicodeString]: shows the hypervisor launch options (Off or Auto). If
you are setting up a debugger to debug Hyper-V on a target computer, set this option to Auto on the target
computer. For more information, see Attaching to a Target Computer Running Hyper-V. Information about
Hyper-V technology is available on Microsoft TechNet web site.
HyperVisor Debugging [Type = UnicodeString]: shows whether the hypervisor debugger is enabled or not
(Yes or No). For information about hypervisor debugging, see Attaching to a Target Computer Running
Hyper-V.

For 4826(S): Boot Configuration Data loaded.
If you have a standard or baseline for Boot Configuration Data settings defined, monitor this event and check
whether the settings reported by the event are still the same as were defined in your standard or baseline.
4909(-): The local policy settings for the TBS were
changed.
Applies to
Windows 10
Windows Server 2016
4910(-): The group policy settings for the TBS were
changed.
Applies to
Windows 10
Windows Server 2016
5063(S, F): A cryptographic provider operation was
attempted.
Applies to
Windows 10
Windows Server 2016
This event generates in BCryptUnregisterProvider() and BCryptRegisterProvider() functions. These are
Cryptographic Next Generation (CNG) functions.
This event generates when cryptographic provider was registered or unregistered.
For more information about Cryptographic Next Generation (CNG) visit these pages:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa376214(v=vs.85).aspx
http://www.microsoft.com/en-us/download/details.aspx?id=1251
This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
Event Schema:
A cryptographic provider operation was attempted.
Subject:
Security ID:%1
Account Name:%2
Account Domain:%3
Logon ID:%4
Cryptographic Provider:
Name:%5
Module:%6
Operation:%7
Return Code:%8
Event Versions: 0.

Typically this event is required for detailed monitoring of CNG-related cryptographic functions. If you need to
monitor or troubleshoot actions related to specific cryptographic functions, review this event to see if it provides
the information you need.
5064(S, F): A cryptographic context operation was
attempted.
Applies to
Windows 10
Windows Server 2016
This event generates in BCryptCreateContext() and BCryptDeleteContext() functions. These are Cryptographic Next
Generation (CNG) functions.
This event generates when cryptographic context was created or deleted.
Event Schema:
A cryptographic context operation was attempted.
Subject:
Security ID:%1
Account Name:%2
Account Domain:%3
Logon ID:%4
Configuration Parameters:
Scope:%5
Context:%6
Operation:%7
Return Code:%8
Event Versions: 0.

5065(S, F): A cryptographic context modification was
attempted.
Applies to
Windows 10
Windows Server 2016
This event generates in BCryptConfigureContext() function. This is a Cryptographic Next Generation (CNG) function.
This event generates when configuration information was changed for existing CNG context.
Event Schema:
A cryptographic context modification was attempted.
Subject:
Security ID:%1
Account Name:%2
Account Domain:%3
Logon ID:%4
Scope:%5
Context:%6
Change Information:
Old Value:%7
New Value:%8
Return Code:%9
Event Versions: 0.

5066(S, F): A cryptographic function operation was
attempted.
Applies to
Windows 10
Windows Server 2016
This event generates in BCryptAddContextFunction() and BCryptRemoveContextFunction() functions. These are
Cryptographic Next Generation (CNG) functions.
This event generates when cryptographic function was added or removed from the list of functions that are
supported by an existing CNG context.
Event Schema:
A cryptographic function operation was attempted.
Subject:
Security ID:%1
Account Name:%2
Account Domain:%3
Logon ID:%4
Scope:%5
Context:%6
Interface:%7
Function:%8
Position:%9
Operation:%10
Return Code:%11
Event Versions: 0.

5067(S, F): A cryptographic function modification was
attempted.
Applies to
Windows 10
Windows Server 2016
This event generates in BCryptConfigureContextFunction() function. This is a Cryptographic Next Generation (CNG)
function.
This event generates when configuration information for the cryptographic function of an existing CNG context was
changed.
Event Schema:
A cryptographic function modification was attempted.
Subject:
Security ID:%1
Account Name:%2
Account Domain:%3
Logon ID:%4
Scope:%5
Context:%6
Interface:%7
Function:%8
Change Information:
Old Value:%9
New Value:%10
Return Code:%11
Event Versions: 0.

5068(S, F): A cryptographic function provider
operation was attempted.
Applies to
Windows 10
Windows Server 2016
This event generates in BCryptAddContextFunctionProvider() and BCryptRemoveContextFunctionProvider()
functions. These are Cryptographic Next Generation (CNG) functions.
Event Schema:
A cryptographic function provider operation was attempted.
Subject:
Security ID:%1
Account Name:%2
Account Domain:%3
Logon ID:%4
Scope:%5
Context:%6
Interface:%7
Function:%8
Provider:%9
Position:%10
Operation:%11
Return Code:%12
Event Versions: 0.

5069(S, F): A cryptographic function property
operation was attempted.
Applies to
Windows 10
Windows Server 2016
This event generates in BCryptSetContextFunctionProperty() function. This is a Cryptographic Next Generation
(CNG) function.
This event generates when named property for a cryptographic function in an existing CNG context was added or
removed.
Event Schema:
A cryptographic function property operation was attempted.
Subject:
Security ID:%1
Account Name:%2
Account Domain:%3
Logon ID:%4
Scope:%5
Context:%6
Interface:%7
Function:%8
Property:%9
Operation:%10
Value:%11
Return Code:%12
Event Versions: 0.

5070(S, F): A cryptographic function property
modification was attempted.
Applies to
Windows 10
Windows Server 2016
This event generates in BCryptSetContextFunctionProperty() function. This is a Cryptographic Next Generation
(CNG) function.
This event generates when named property for a cryptographic function in an existing CNG context was updated.
Event Schema:
A cryptographic function property modification was attempted.
Subject:
Security ID:%1
Account Name:%2
Account Domain:%3
Logon ID:%4
Scope:%5
Context:%6
Interface:%7
Function:%8
Property:%9
Change Information:
Old Value:%10
New Value:%11
Return Code:%12
Event Versions: 0.

5447(S): A Windows Filtering Platform filter has been
changed.
Applies to
Windows 10
Windows Server 2016
Events
Event Description:
This event generates every time a
Windows Filtering Platform filter has
been changed.
It typically generates during Group
Policy update procedures.

for this event.
Event XML:
- <System>
<Level>0</Level>
<Task>13573</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="UserSid">S-1-5-19</Data>
<Data Name="UserName">NT AUTHORITY\\LOCAL SERVICE</Data>
<Data Name="ProviderKey">{DECC16CA-3F33-4346-BE1E-8FB4AE0F3D62}</Data>
<Data Name="ProviderName">Microsoft Corporation</Data>
<Data Name="ChangeType">%%16385</Data>
<Data Name="FilterKey">{91334E6D-FFAB-40F1-8C43-5554965C228D}</Data>
<Data Name="FilterName">Port Scanning Prevention Filter</Data>
<Data Name="FilterType">%%16388</Data>
<Data Name="FilterId">100100</Data>
<Data Name="LayerKey">{AC4A9833-F69D-4648-B261-6DC84835EF39}</Data>
<Data Name="LayerName">Inbound Transport v4 Discard Layer</Data>
<Data Name="LayerId">13</Data>
<Data Name="Weight">13835058055315718144</Data>
<Data Name="Conditions">Condition ID: {632ce23b-5167-435c-86d7-e903684aa80c} Match value: No flags set
Condition value: 0x00000003</Data>
<Data Name="Action">%%16391</Data>
<Data Name="CalloutKey">{EDA08606-2494-4D78-89BC-67837C03B969}</Data>
<Data Name="CalloutName">WFP Built-in Silent Drop Transport v4 Discard Layer Callout</Data>
</EventData>
</Event>

Event Versions: 0.

For 5447(S): A Windows Filtering Platform filter has been changed.
This event mainly used for Windows Filtering Platform troubleshooting and typically has little to no security
relevance.
6144(S): Security policy in the group policy objects
has been applied successfully.
Applies to
Windows 10
Windows Server 2016
Events
Event Description:
This event generates every time settings from
the Security Settings section in the group
policy object are applied successfully to a
computer, without any errors. This event
generates on the target computer itself.
It is a routine event which shows you the list of
Group Policy Objects that include Security
Settings policies, and that were applied to the
computer.
This event generates every time Group Policy is applied to the computer.
Event XML:
- <System>
<Level>0</Level>
<Task>13573</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ErrorCode">0</Data>
<Data Name="GPOList">{8AB9311A-E5FB-4A5A-8FB7-027D1B877D6D} DC Main Policy</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Return Code [Type = UInt32]: always has 0 value for this event.
GPO List [Type = UnicodeString]: the list of Group Policy Objects that include Security Settings policies, and that
were applied to the computer. The format of the list item is: GROUP_POLICY_GUID GROUP_POLICY_NAME.
You can find specific GROUP_POLICY_GUID using Get-GPO PowerShell cmdlet with Name
GROUP_POLICY_NAME parameter. Row Id is the GUID of the Group Policy:

For 6144(S): Security policy in the group policy objects has been applied successfully.
If you have a pre-defined list of Group Policy Objects which contain Security Settings and must be applied to
specific computers, then you can compare the list from this event with your list and in case of any difference
trigger an alert.
This event is mostly an informational event.
6145(F): One or more errors occurred while
processing security policy in the group policy objects.
Applies to
Windows 10
Windows Server 2016
Events
Event Description:
This event generates every time settings
from the Security Settings section in the
group policy object are applied to a
computer with one or more errors. This
event generates on the target computer
itself.
This event generates, for example, if the SID
of a security principal which was included in
one of the Group Policy settings cannot be
resolved or translated to the real account
name.
Event XML:
- <System>
<Level>0</Level>
<Task>13573</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="GPOList">{6AC1786C-016F-11D2-945F-00C04fB984F9} Default Domain Controllers Policy {31B2F340-016D-
11D2-945F-00C04FB984F9} Default Domain Policy</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Error Code [Type = UInt32]: specific error code which shows the error which happened during Group Policy
processing. You can find the meaning of specific error code here: https://msdn.microsoft.com/en-
us/library/windows/desktop/ms681381(v=vs.85).aspx. For example, error code 1332 means that no mapping
between account names and security IDs was done.
GPO List [Type = UnicodeString]: the list of Group Policy Objects that include Security Settings policies, and that
were applied with errors to the computer. The format of the list item is: GROUP_POLICY_GUID
GROUP_POLICY_NAME.
You can find specific GROUP_POLICY_GUID using Get-GPO PowerShell cmdlet with Name
GROUP_POLICY_NAME parameter. Row Id is the GUID of the Group Policy:
For 6145(F): One or more errors occurred while processing security policy in the group policy objects.
This event indicates that Group Policy Objects which were applied to the computer or device had some
errors during processing. If you see this event, we recommend checking settings in the GPOs from GPO List
and resolving the cause of the errors.
If you have a pre-defined list of Group Policy Objects that contain Security Settings and that must be applied
to specific computers, check this event to see if errors occurred when the Security Settings were applied. If
so, you can review the error codes and investigate the cause of the failure.
Typically this event has an informational purpose and the reason is configuration errors in Group Policys
security settings.
This event might be used for Group Policy troubleshooting purposes.
Audit Sensitive Privilege Use
Applies to
Windows 10
Windows Server 2016
Audit Sensitive Privilege Use contains events that show the usage of sensitive privileges. This is the list of
sensitive privileges:
Act as part of the operating system
Back up files and directories
Restore files and directories
Debug programs
Enable computer and user accounts to be trusted for delegation
Impersonate a client after authentication
Load and unload device drivers
Manage auditing and security log
Modify firmware environment values
Replace a process-level token
Take ownership of files or other objects
The use of two privileges, Back up files and directories and Restore files and directories, generate events only
if the Audit: Audit the use of Backup and Restore privilege Group Policy setting is enabled on the computer or
device. We do not recommend enabling this Group Policy setting because of the high number of events recorded.
This subcategory also contains informational events from the file system Transaction Manager.
If you configure this policy setting, an audit event is generated when sensitive privilege requests are made.
Success audits record successful attempts, and failure audits record unsuccessful attempts.
Event volume: High.
STRONGER STRONGER
STRONGER STRONGER

Controller tracking Success
and Failure for
this subcategory
of events,
especially if the
sensitive
privileges were
used by a user
account.

tracking Success
and Failure for
this subcategory
of events,
especially if the
sensitive
privileges were
used by a user
account.

tracking Success
and Failure for
this subcategory
of events,
especially if the
sensitive
privileges were
used by a user
account.
Events List:
4673(S, F): A privileged service was called.
4674(S, F): An operation was attempted on a privileged object.
Note For some reason event 4985(S): The state of a transaction has changed" from Audit File System
subcategory generates also in this subcategory. See description of event 4985 in Audit File System
subcategory.
Applies to
Windows 10
Windows Server 2016
Subcategories: Audit Sensitive Privilege Use
and Audit Non Sensitive Privilege Use
Event Description:
This event generates when an attempt was
made to perform privileged system service
operations.
This event generates, for example, when
SeSystemtimePrivilege,
SeCreateGlobalPrivilege, or SeTcbPrivilege
privilege was used.
Failure event generates when service call
attempt fails.

Event XML:
- <System>
<Level>0</Level>
<Task>13056</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectServer">NT Local Security Authority / Authentication Service</Data>
<Data Name="Service">LsaRegisterLogonProcess()</Data>
<Data Name="PrivilegeList">SeTcbPrivilege</Data>
<Data Name="ProcessId">0x1f0</Data>
<Data Name="ProcessName">C:\\Windows\\System32\\lsass.exe</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested privileged operation. Event Viewer automatically tries to
Account Name [Type = UnicodeString]: the name of the account that requested privileged operation.
the following:
Service:
Server [Type = UnicodeString]: contains the name of the Windows subsystem calling the routine.
Subsystems examples are:
Security
Security Account Manager
NT Local Security Authority / Authentication Service
SC Manager
Win32 SystemShutdown module
LSA
Service Name [Type = UnicodeString] [Optional]: supplies a name of the privileged subsystem service or
function. For example, "RESET RUNTIME LOCAL SECURITY" might be specified by a Local Security
Authority service used to update the local security policy database or LsaRegisterLogonProcess() might
be specified by a NT Local Security Authority / Authentication Service used to register new logon
process.
Process:
Process ID [Type = Pointer]: hexadecimal Process ID of the process that attempted to call the privileged
service. Process ID (PID) is a number used by the operating system to uniquely identify an active process. To
Service Request Information:
Privileges [Type = UnicodeString]: the list of user privileges which were requested. The possible privileges
depend on the subcategory, either Audit Non Sensitive Privilege Use or Audit Sensitive Privilege Use, as
shown in the following two tables:
PRIVILEGE NAME:
SUBCATEGORY OF EVENT USER RIGHT GROUP POLICY NAME DESCRIPTION
Audit Non Sensitive Privilege Use SeChangeNotifyPrivilege: Required to receive notifications of

Bypass traverse checking changes to files or directories. This
Audit Non Sensitive Privilege Use SeCreateGlobalPrivilege: Required to create named file mapping
Create global objects objects in the global namespace during
Audit Non Sensitive Privilege Use SeCreatePagefilePrivilege: With this privilege, the user can create
Create a pagefile and change the size of a pagefile.
Audit Non Sensitive Privilege Use SeCreatePermanentPrivilege: Required to create a permanent object.
Create permanent shared objects This privilege is useful to kernel-mode
Audit Non Sensitive Privilege Use SeCreateSymbolicLinkPrivilege: Required to create a symbolic link.
Create symbolic links
Audit Non Sensitive Privilege Use SeIncreaseBasePriorityPrivilege: Required to increase the base priority of
Increase scheduling priority a process.
interface.
Audit Non Sensitive Privilege Use SeIncreaseQuotaPrivilege: Required to increase the quota assigned
Adjust memory quotas for a process to a process.
Audit Non Sensitive Privilege Use SeIncreaseWorkingSetPrivilege: Required to allocate more memory for
Increase a process working set applications that run in the context of
users.
PRIVILEGE NAME:
Audit Non Sensitive Privilege Use SeLockMemoryPrivilege: Required to lock physical pages in
Lock pages in memory memory.
Audit Non Sensitive Privilege Use SeMachineAccountPrivilege: With this privilege, the user can create a
Add workstations to domain computer account.
controllers.
Audit Non Sensitive Privilege Use SeManageVolumePrivilege: Required to run maintenance tasks on a
Perform volume maintenance tasks volume, such as remote
defragmentation.
Audit Non Sensitive Privilege Use SeProfileSingleProcessPrivilege: Required to gather profiling information
Profile single process for a single process.
processes.
Audit Non Sensitive Privilege Use SeRelabelPrivilege: Required to modify the mandatory
Modify an object label integrity level of an object.
Audit Non Sensitive Privilege Use SeRemoteShutdownPrivilege: Required to shut down a system using a
Force shutdown from a remote system network request.
Audit Non Sensitive Privilege Use SeShutdownPrivilege: Required to shut down a local system.
Shut down the system
Audit Non Sensitive Privilege Use SeSyncAgentPrivilege: This privilege enables the holder to read
Synchronize directory service data all objects and properties in the
synchronization.
Audit Non Sensitive Privilege Use SeSystemProfilePrivilege: Required to gather profiling information
Profile system performance for the entire system.
processes.
PRIVILEGE NAME:
Audit Non Sensitive Privilege Use SeSystemtimePrivilege: Required to modify the system time.
Change the system time With this privilege, the user can change
appearance of event logs.
If the system time is changed, events
that are logged will reflect this new time,
not the actual time that the events
occurred.
Audit Non Sensitive Privilege Use SeTimeZonePrivilege: Required to adjust the time zone
Change the time zone associated with the computer's internal
clock.
Audit Non Sensitive Privilege Use SeTrustedCredManAccessPrivilege: Required to access Credential Manager
Access Credential Manager as a trusted as a trusted caller.
caller
Audit Non Sensitive Privilege Use SeUndockPrivilege: Required to undock a laptop.

Remove computer from docking station With this privilege, the user can undock
PRIVILEGE NAME:
Audit Sensitive Privilege Use SeAssignPrimaryTokenPrivilege: Required to assign the primary token of
Replace a process-level token a process. With this privilege, the user
can initiate a process to replace the
default token associated with a started
subprocess.
Audit Sensitive Privilege Use SeAuditPrivilege: With this privilege, the user can add
Generate security audits entries to the security log.
Audit Sensitive Privilege Use SeCreateTokenPrivilege: Allows a process to create a token which
Create a token object it can then use to get access to any local
creation APIs. When a process requires
this privilege, we recommend using the
PRIVILEGE NAME:
Audit Sensitive Privilege Use SeDebugPrivilege: Required to debug and adjust the
Debug programs memory of a process owned by another
account. With this privilege, the user can
attach a debugger to any process or to
the kernel. Developers who are
user right provides complete access to
sensitive and critical operating system
components.
Audit Sensitive Privilege Use SeImpersonatePrivilege: With this privilege, the user can
Impersonate a client after impersonate other accounts.
authentication
Audit Sensitive Privilege Use SeLoadDriverPrivilege: Required to load or unload a device

Load and unload device drivers driver. With this privilege, the user can
Audit Sensitive Privilege Use SeLockMemoryPrivilege: Required to lock physical pages in

Lock pages in memory memory. With this privilege, the user
can use a process to keep data in
physical memory, which prevents the
system from paging the data to virtual
memory on disk. Exercising this privilege
could significantly affect system
performance by decreasing the amount
of available random access memory
(RAM).
Audit Sensitive Privilege Use SeSystemEnvironmentPrivilege: Required to modify the nonvolatile RAM
Modify firmware environment values of systems that use this type of memory
Audit Sensitive Privilege Use SeTcbPrivilege: This privilege identifies its holder as part
Act as part of the operating system of the trusted computer base. This user
right allows a process to impersonate
any user without authentication. The
process can therefore gain access to the
same local resources as that user.
PRIVILEGE NAME:
Audit Sensitive Privilege Use SeEnableDelegationPrivilege: Required to mark user and computer
Enable computer and user accounts to accounts as trusted for delegation. With
be trusted for delegation this privilege, the user can set the
user or computer object. The user or
object that is granted this privilege must
have write access to the account control
flags on the user or computer object. A
server process running on a computer
(or under a user context) that is trusted
for delegation can access resources on
another computer using the delegated

For 4673(S, F): A privileged service was called.
administrative account that is expected to have the listed Privileges. Especially monitor Failure events.
If you need to monitor events related to specific Windows subsystems (Service\Server), for example NT
Local Security Authority / Authentication Service or Security Account Manager, monitor this event
for the corresponding Service\Server.
If you need to monitor events related to specific Windows security services or functions (Service\Service
Name), for example LsaRegisterLogonProcess(), monitor this event for the corresponding
Service\Service Name.
For a specific Subject\Security ID, if there is a defined list of allowed privileges, monitor for Privileges
that it should not be able to use.
If you have a list of specific user rights which should never be used, or used only by a few accounts (for
example, SeDebugPrivilege), trigger an alert for those Privileges.
If you have a list of specific user rights for which every use must be reported or monitored (for example,
SeRemoteShutdownPrivilege), trigger an alert for those Privileges.
4674(S, F): An operation was attempted on a
privileged object.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates when an attempt is made
to perform privileged operations on a protected
subsystem object after the object is already
opened.
SeShutdownPrivilege,
SeRemoteShutdownPrivilege, or
SeSecurityPrivilege is used.
Failure event generates when operation
attempt fails.

Event XML:
- <System>
<Level>0</Level>
<Task>13056</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectUserName">LOCAL SERVICE</Data>
<Data Name="SubjectDomainName">NT AUTHORITY</Data>
<Data Name="ObjectType">-</Data>
<Data Name="ObjectName">-</Data>
<Data Name="AccessMask">16777216</Data>
<Data Name="PrivilegeList">SeSecurityPrivilege</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested privileged operation. Event Viewer automatically tries to
the following:
Object:
Object Server [Type = UnicodeString] [Optional]: Contains the name of the Windows subsystem calling the
routine. Subsystems examples are:
Security
SC Manager
LSA
Object Type [Type = UnicodeString] [Optional]: The type of an object that was accessed during the
operation.
Object Name [Type = UnicodeString] [Optional]: the name of the object that was accessed during the
operation.
Object Handle [Type = Pointer]: hexadecimal value of a handle to Object Name. This field can help you
correlate this event with other events that might contain the same Handle ID, for example, 4656: A handle to
an object was requested event in appropriate/other subcategory. This parameter might not be captured in
the event, and in that case appears as 0x0.
Process ID [Type = Pointer]: hexadecimal Process ID of the process that attempted the operation on the
privileged object. Process ID (PID) is a number used by the operating system to uniquely identify an active
column):
Requested Operation:
Desired Access [Type = UnicodeString]: The desired access mask. This mask depends on Object Server and
Object Type parameters values. The value of this parameter is in decimal format. There is no detailed
information about this parameter in this document. If Desired Access is not presented, then this parameter
will have 0 value.
depend on the subcategory, either Audit Non Sensitive Privilege Use or Audit Sensitive Privilege Use,
as shown in the following two tables:
PRIVILEGE NAME:

PRIVILEGE NAME:
interface.
users.
Add workstations to domain computer account. This privilege is valid
PRIVILEGE NAME:
defragmentation.
processes.
synchronization.
processes.
clock.
caller
PRIVILEGE NAME:

PRIVILEGE NAME:
Replace a process-level token a process.
Audit Sensitive Privilege Use SeBackupPrivilege: - Required to perform backup

Back up files and directories operations.
purposes of backing up the system. This
privilege causes the system to grant all
read access control to any file,
with the ACL.
The following access rights are granted
if this privilege is held:
READ_CONTROL
FILE_GENERIC_READ
FILE_TRAVERSE
Audit Sensitive Privilege Use SeCreateTokenPrivilege: Allows a process to create a token which
Create a token object it can then use to get access to any local
creation APIs.
PRIVILEGE NAME:
account.
need this user right.
This user right provides complete access
system components.
authentication

Load and unload device drivers driver.

PRIVILEGE NAME:
Audit Sensitive Privilege Use SeRestorePrivilege: Required to perform restore operations.

Restore files and directories This privilege causes the system to
held:
WRITE_DAC
WRITE_OWNER
FILE_GENERIC_WRITE
FILE_ADD_FILE
DELETE
an object.
Audit Sensitive Privilege Use SeSecurityPrivilege: Required to perform a number of

Manage auditing and security log security-related functions, such as
security event log.
Directory objects, and registry keys. A
user with this privilege can also view
Modify firmware environment values of systems that use this type of memory
Audit Sensitive Privilege Use SeTakeOwnershipPrivilege: Required to take ownership of an object

Take ownership of files or other objects without being granted discretionary

For 4674(S, F): An operation was attempted on a privileged object.
Monitor for this event where Subject\Security ID is not one of these well-known security principals: LOCAL
SYSTEM, NETWORK SERVICE, LOCAL SERVICE, and where Subject\Security ID is not an administrative
account that is expected to have the listed Privileges. Especially monitor Failure events.
If you need to monitor events related to specific Windows subsystems (Object Server), for example LSA or
Security Account Manager, monitor this event for the corresponding Object Server.
If you know that specific Subject\Security ID should only be able to use the privileges in a pre-defined list,
monitor for events in which Subject\Security ID used Privileges that are not on that list.
Applies to
Windows 10
Windows Server 2016
Event Description:

event.
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
following:
requested.
this transaction.
column):

Audit Non Sensitive Privilege Use
Applies to
Windows 10
Windows Server 2016
Audit Non Sensitive Privilege Use contains events that show usage of non-sensitive privileges. This is the list of
non-sensitive privileges:
Access Credential Manager as a trusted caller
Add workstations to domain
Adjust memory quotas for a process
Change the system time
Change the time zone
Create a page file
Create global objects
Create permanent shared objects
Force shutdown from a remote system
Increase a process working set
Increase scheduling priority
Lock pages in memory
Modify an object label
Perform volume maintenance tasks
Profile single process
Profile system performance
Remove computer from docking station
Synchronize directory service data
This subcategory also contains informational events from filesystem Transaction Manager.
If you configure this policy setting, an audit event is generated when a non-sensitive privilege is called. Success
audits record successful attempts, and failure audits record unsuccessful attempts.
Event volume: Very High.
STRONGER STRONGER
Domain No IF No IF We do not
Controller recommend
Success auditing
because the
volume of events
is very high and
typically they are
not as important
as events from
Audit Sensitive
Privilege Use
subcategory.
IF You can
enable Failure
auditing if you
need information
about failed
attempts to use
non-sensitive
privileges, for
example,
SeShutdownPri
vilege or
SeRemoteShutd
ownPrivilege.
Member Server No IF No IF We do not

recommend
Success auditing
because the
volume of events
is very high and
typically they are
not as important
as events from
Audit Sensitive
Privilege Use
subcategory.
IF You can
enable Failure
auditing if you
need information
about failed
attempts to use
non-sensitive
privileges, for
example,
SeShutdownPri
vilege or
SeRemoteShutd
ownPrivilege.
STRONGER STRONGER
Workstation No IF No IF We do not
recommend
Success auditing
because the
volume of events
is very high and
typically they are
not as important
as events from
Audit Sensitive
Privilege Use
subcategory.
IF You can
enable Failure
auditing if you
need information
about failed
attempts to use
non-sensitive
privileges, for
example,
SeShutdownPri
vilege or
SeRemoteShutd
ownPrivilege.
Events List:
4674(S, F): An operation was attempted on a privileged object.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates when an attempt was
made to perform privileged system service
operations.
SeSystemtimePrivilege,
SeCreateGlobalPrivilege, or SeTcbPrivilege
privilege was used.
Failure event generates when service call
attempt fails.

Event XML:
- <System>
<Level>0</Level>
<Task>13056</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="ObjectServer">NT Local Security Authority / Authentication Service</Data>
<Data Name="Service">LsaRegisterLogonProcess()</Data>
<Data Name="PrivilegeList">SeTcbPrivilege</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested privileged operation. Event Viewer automatically tries
event.
the following:
Service:
Server [Type = UnicodeString]: contains the name of the Windows subsystem calling the routine.
Subsystems examples are:
Security
SC Manager
LSA
Service Name [Type = UnicodeString] [Optional]: supplies a name of the privileged subsystem service or
function. For example, "RESET RUNTIME LOCAL SECURITY" might be specified by a Local Security
Authority service used to update the local security policy database or LsaRegisterLogonProcess() might
be specified by a NT Local Security Authority / Authentication Service used to register new logon
process.
Process:
Process ID [Type = Pointer]: hexadecimal Process ID of the process that attempted to call the privileged
service. Process ID (PID) is a number used by the operating system to uniquely identify an active process. To
Service Request Information:
depend on the subcategory, either Audit Non Sensitive Privilege Use or Audit Sensitive Privilege Use, as
shown in the following two tables:
PRIVILEGE NAME:

interface.
users.
PRIVILEGE NAME:
Add workstations to domain computer account.
controllers.
defragmentation.
system processes.
synchronization.
processes.
PRIVILEGE NAME:
appearance of event logs.
If the system time is changed, events
that are logged will reflect this new
time, not the actual time that the
events occurred.
clock.
caller

PRIVILEGE NAME:
Replace a process-level token a process. With this privilege, the user
can initiate a process to replace the
default token associated with a started
subprocess.
Audit Sensitive Privilege Use SeCreateTokenPrivilege: Allows a process to create a token

Create a token object which it can then use to get access to
creation APIs. When a process requires
this privilege, we recommend using the
PRIVILEGE NAME:
account. With this privilege, the user
can attach a debugger to any process
or to the kernel. Developers who are
user right provides complete access to
sensitive and critical operating system
components.
authentication

Load and unload device drivers driver. With this privilege, the user can

Lock pages in memory memory. With this privilege, the user
can use a process to keep data in
physical memory, which prevents the
system from paging the data to virtual
memory on disk. Exercising this privilege
could significantly affect system
performance by decreasing the amount
of available random access memory
(RAM).
Modify firmware environment values of systems that use this type of
information.
Audit Sensitive Privilege Use SeTcbPrivilege: This privilege identifies its holder as part
Act as part of the operating system of the trusted computer base. This user
right allows a process to impersonate
any user without authentication. The
process can therefore gain access to the
same local resources as that user.
PRIVILEGE NAME:
Audit Sensitive Privilege Use SeEnableDelegationPrivilege: Required to mark user and computer
Enable computer and user accounts to accounts as trusted for delegation. With
be trusted for delegation this privilege, the user can set the
user or computer object. The user or
object that is granted this privilege
must have write access to the account
control flags on the user or computer
object. A server process running on a
computer (or under a user context) that
is trusted for delegation can access
resources on another computer using
the delegated credentials of a client, as
long as the account of the client does
not have the Account cannot be
delegated account control flag set.

For 4673(S, F): A privileged service was called.
administrative account that is expected to have the listed Privileges. Especially monitor Failure events.
If you need to monitor events related to specific Windows subsystems (Service\Server), for example NT
Local Security Authority / Authentication Service or Security Account Manager, monitor this event
for the corresponding Service\Server.
If you need to monitor events related to specific Windows security services or functions (Service\Service
Name), for example LsaRegisterLogonProcess(), monitor this event for the corresponding
Service\Service Name.
For a specific Subject\Security ID, if there is a defined list of allowed privileges, monitor for Privileges
that it should not be able to use.
4674(S, F): An operation was attempted on a
privileged object.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates when an attempt is made
to perform privileged operations on a
protected subsystem object after the object is
already opened.
SeShutdownPrivilege,
SeRemoteShutdownPrivilege, or
SeSecurityPrivilege is used.
Failure event generates when operation
attempt fails.

Event XML:
- <System>
<Level>0</Level>
<Task>13056</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectUserName">LOCAL SERVICE</Data>
<Data Name="SubjectDomainName">NT AUTHORITY</Data>
<Data Name="ObjectType">-</Data>
<Data Name="ObjectName">-</Data>
<Data Name="AccessMask">16777216</Data>
<Data Name="PrivilegeList">SeSecurityPrivilege</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested privileged operation. Event Viewer automatically tries
event.
the following:
Object:
Object Server [Type = UnicodeString] [Optional]: Contains the name of the Windows subsystem calling the
routine. Subsystems examples are:
Security
SC Manager
LSA
Object Type [Type = UnicodeString] [Optional]: The type of an object that was accessed during the
operation.
Object Name [Type = UnicodeString] [Optional]: the name of the object that was accessed during the
operation.
Object Handle [Type = Pointer]: hexadecimal value of a handle to Object Name. This field can help you
to an object was requested event in appropriate/other subcategory. This parameter might not be captured
in the event, and in that case appears as 0x0.
Process ID [Type = Pointer]: hexadecimal Process ID of the process that attempted the operation on the
privileged object. Process ID (PID) is a number used by the operating system to uniquely identify an active
column):
Requested Operation:
Desired Access [Type = UnicodeString]: The desired access mask. This mask depends on Object Server
and Object Type parameters values. The value of this parameter is in decimal format. There is no detailed
information about this parameter in this document. If Desired Access is not presented, then this parameter
will have 0 value.
depend on the subcategory, either Audit Non Sensitive Privilege Use or Audit Sensitive Privilege Use,
as shown in the following two tables:
PRIVILEGE NAME:

PRIVILEGE NAME:
interface.
users.
Add workstations to domain computer account. This privilege is valid
PRIVILEGE NAME:
defragmentation.
system processes.
Audit Non Sensitive Privilege Use SeRemoteShutdownPrivilege: Required to shut down a system using
Force shutdown from a remote system a network request.
synchronization.
processes.
clock.
caller
PRIVILEGE NAME:

PRIVILEGE NAME:
Replace a process-level token a process.
Audit Sensitive Privilege Use SeBackupPrivilege: - Required to perform backup

Back up files and directories operations.
purposes of backing up the system. This
privilege causes the system to grant all
read access control to any file,
evaluated with the ACL.
The following access rights are granted
if this privilege is held:
READ_CONTROL
FILE_GENERIC_READ
FILE_TRAVERSE
Audit Sensitive Privilege Use SeCreateTokenPrivilege: Allows a process to create a token

Create a token object which it can then use to get access to
creation APIs.
PRIVILEGE NAME:
account.
need this user right.
This user right provides complete access
system components.
authentication

Load and unload device drivers driver.

PRIVILEGE NAME:
Audit Sensitive Privilege Use SeRestorePrivilege: Required to perform restore operations.

Restore files and directories This privilege causes the system to
held:
WRITE_DAC
WRITE_OWNER
FILE_GENERIC_WRITE
FILE_ADD_FILE
DELETE
an object.
Audit Sensitive Privilege Use SeSecurityPrivilege: Required to perform a number of

Manage auditing and security log security-related functions, such as
security event log.
Directory objects, and registry keys. A
user with this privilege can also view
Audit Sensitive Privilege Use SeSystemEnvironmentPrivilege: Required to modify the nonvolatile

Modify firmware environment values RAM of systems that use this type of
information.
Audit Sensitive Privilege Use SeTakeOwnershipPrivilege: Required to take ownership of an object

Take ownership of files or other objects without being granted discretionary

For 4674(S, F): An operation was attempted on a privileged object.
Monitor for this event where Subject\Security ID is not one of these well-known security principals: LOCAL
SYSTEM, NETWORK SERVICE, LOCAL SERVICE, and where Subject\Security ID is not an administrative
account that is expected to have the listed Privileges. Especially monitor Failure events.
If you need to monitor events related to specific Windows subsystems (Object Server), for example LSA
or Security Account Manager, monitor this event for the corresponding Object Server.
If you know that specific Subject\Security ID should only be able to use the privileges in a pre-defined list,
monitor for events in which Subject\Security ID used Privileges that are not on that list.
Applies to
Windows 10
Windows Server 2016
Event Description:

event.
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
following:
requested.
this transaction.
column):

Audit Other Privilege Use Events
Applies to
Windows 10
Windows Server 2016
This auditing subcategory should not have any events in it, but for some reason Success auditing will enable
generation of event 4985(S): The state of a transaction has changed.
STRONGER STRONGER
Domain No No No No This auditing

doesnt have any
informative
events inside.
Member Server No No No No This auditing

subcategory
doesnt have any
informative
events inside.
Workstation No No No No This auditing

subcategory
doesnt have any
informative
events inside.
Events List:
Applies to
Windows 10
Windows Server 2016
Non Sensitive Privilege Use, Audit Other
Privilege Use Events, and Audit Sensitive
Privilege Use
Event Description:

event.
Event XML:
- <System>
<Level>0</Level>
<Task>12800</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
following:
requested.
this transaction.
column):

Audit IPsec Driver
Applies to
Windows 10
Windows Server 2016
Audit IPsec Driver allows you to audit events generated by IPSec driver such as the following:
Startup and shutdown of the IPsec services.
Network packets dropped due to integrity check failure.
Network packets dropped due to replay check failure.
Network packets dropped due to being in plaintext.
Network packets received with incorrect Security Parameter Index (SPI). This may indicate that either the
network card is not working correctly or the driver needs to be updated.
Inability to process IPsec filters.
A high rate of packet drops by the IPsec filter driver may indicate attempts to gain access to the network by
unauthorized systems.
Failure to process IPsec filters poses a potential security risk because some network interfaces may not get the
protection that is provided by the IPsec filter.
This subcategory is outside the scope of this document.
STRONGER STRONGER
Domain - - - - There is no
Controller recommendation
for this
subcategory in
this document,
unless you know
exactly what you
need to monitor
at IPsec Driver
level.
Member Server - - - - There is no

recommendation
for this
subcategory in
this document,
unless you know
exactly what you
need to monitor
at IPsec Driver
level.
STRONGER STRONGER
Workstation - - - - There is no
recommendation
for this
subcategory in
this document,
unless you know
exactly what you
need to monitor
at IPsec Driver
level.
4960(S): IPsec dropped an inbound packet that failed an integrity

check. If this problem persists, it could indicate a network issue or that
packets are being modified in transit to this computer. Verify that the
packets sent from the remote computer are the same as those received
by this computer. This error might also indicate interoperability
problems with other IPsec implementations.
4961(S): IPsec dropped an inbound packet that failed a replay check. If
this problem persists, it could indicate a replay attack against this
computer.
4962(S): IPsec dropped an inbound packet that failed a replay check.
The inbound packet had too low a sequence number to ensure it was
not a replay.
4963(S): IPsec dropped an inbound clear text packet that should have
been secured. This is usually due to the remote computer changing its
IPsec policy without informing this computer. This could also be a
spoofing attack attempt.
4965(S): IPsec received a packet from a remote computer with an
incorrect Security Parameter Index (SPI). This is usually caused by
malfunctioning hardware that is corrupting packets. If these errors
persist, verify that the packets sent from the remote computer are the
same as those received by this computer. This error may also indicate
interoperability problems with other IPsec implementations. In that
case, if connectivity is not impeded, then these events can be ignored.
5478(S): IPsec Services has started successfully.
5479(): IPsec Services has been shut down successfully. The shutdown
of IPsec Services can put the computer at greater risk of network attack
or expose the computer to potential security risks.
5480(F): IPsec Services failed to get the complete list of network
interfaces on the computer. This poses a potential security risk because
some of the network interfaces may not get the protection provided by
the applied IPsec filters. Use the IP Security Monitor snap-in to
diagnose the problem.
5483(F): IPsec Services failed to initialize RPC server. IPsec Services
could not be started.
5484(F): IPsec Services has experienced a critical failure and has been
shut down. The shutdown of IPsec Services can put the computer at
greater risk of network attack or expose the computer to potential
security risks.
5485(F): IPsec Services failed to process some IPsec filters on a plug-
and-play event for network interfaces. This poses a potential security
risk because some of the network interfaces may not get the protection
provided by the applied IPsec filters. Use the IP Security Monitor snap-
in to diagnose the problem.
Audit Other System Events
Applies to
Windows 10
Windows Server 2016
Audit Other System Events contains Windows Firewall Service and Windows Firewall driver start and stop
events, failure events for these services and Windows Firewall Service policy processing failures.
Audit Other System Events determines whether the operating system audits various system events.
The system events in this category include:
Startup and shutdown of the Windows Firewall service and driver.
Security policy processing by the Windows Firewall service.
Cryptography key file and migration operations.
BranchCache events.
Event volume: Low.
STRONGER STRONGER

Controller enabling Success
and Failure
auditing because
you will be able
to get Windows
Firewall Service
and Windows
Firewall Driver
status events.

enabling Success
and Failure
auditing because
you will be able
to get Windows
Firewall Service
and Windows
Firewall Driver
status events.
STRONGER STRONGER

enabling Success
and Failure
auditing because
you will be able
to get Windows
Firewall Service
and Windows
Firewall Driver
status events.
Events List:
5024(S): The Windows Firewall Service has started successfully.
5025(S): The Windows Firewall Service has been stopped.
5027(F): The Windows Firewall Service was unable to retrieve the security policy from the local storage.
The service will continue enforcing the current policy.
5028(F): The Windows Firewall Service was unable to parse the new security policy. The service will
continue with currently enforced policy.
5029(F): The Windows Firewall Service failed to initialize the driver. The service will continue to enforce
the current policy.
5030(F): The Windows Firewall Service failed to start.
5032(F): Windows Firewall was unable to notify the user that it blocked an application from accepting
incoming connections on the network.
5033(S): The Windows Firewall Driver has started successfully.
5034(S): The Windows Firewall Driver was stopped.
5035(F): The Windows Firewall Driver failed to start.
5037(F): The Windows Firewall Driver detected critical runtime error. Terminating.
5058(S, F): Key file operation.
5059(S, F): Key migration operation.
6400(-): BranchCache: Received an incorrectly formatted response while discovering availability of
content.
6401(-): BranchCache: Received invalid data from a peer. Data discarded.
6402(-): BranchCache: The message to the hosted cache offering it data is incorrectly formatted.
6403(-): BranchCache: The hosted cache sent an incorrectly formatted response to the client.
6404(-): BranchCache: Hosted cache could not be authenticated using the provisioned SSL certificate.
6405(-): BranchCache: %2 instance(s) of event id %1 occurred.
6406(-): %1 registered to Windows Firewall to control filtering for the following: %2
6407(-): 1%
6408(-): Registered product %1 failed and Windows Firewall is now controlling the filtering for %2
6409(-): BranchCache: A service connection point object could not be parsed.
5024(S): The Windows Firewall Service has started
successfully.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Other System Events
Event Description:
(MpsSvc) service has started successfully.
This event is typically logged during operating
system startup process.

Event XML:
- <System>
<Level>0</Level>
<Task>12292</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
<EventData />
</Event>

Event Versions: 0.

For 5024(S): The Windows Firewall Service has started successfully.
Typically this event has an informational purpose. Its logged during operating system startup process.
You should not see this event after system startup, so we recommend that you monitor it when it occurs
outside the system startup process.
5025(S): The Windows Firewall Service has been
stopped.
Applies to
Windows 10
Windows Server 2016
Event Description:
(MpsSvc) service has been stopped.
system shutdown process.

Event XML:
- <System>
<Level>0</Level>
<Task>12292</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
<EventData />
</Event>

Event Versions: 0.

For 5025(S): The Windows Firewall Service has been stopped.
Typically this event has an informational purpose. Its logged during operating system shutdown process.
5027(F): The Windows Firewall Service was unable to
retrieve the security policy from the local storage. The
service will continue enforcing the current policy.
Applies to
Windows 10
Windows Server 2016
Event Description:
This error indicates one of two situations, low
memory resources or Windows Firewall group
policy registry corruption.
Typically if this event occurs it indicates that
Windows Firewall service was not able to start.
It typically occurs with 5028(S): The Windows
Firewall Service was unable to parse the new
security policy. The service will continue with
currently enforced policy.
Event XML:
- <System>
<Level>0</Level>
<Task>12292</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>
Event Versions: 0.
Field Descriptions:
Error Code [Type = UInt32]: unique error code. For information about error codes meanings for this event use

For 5027(F): The Windows Firewall Service was unable to retrieve the security policy from the local storage. The
service will continue enforcing the current policy.
This event can be a sign of software or operating system issues, Windows Firewall registry errors or corruption,
or Group Policy setting misconfigurations. We recommend monitoring this event and investigating the reason
for the condition. Typically this event indicates configuration issues, not security issues.
5028(F): The Windows Firewall Service was unable to
parse the new security policy. The service will
continue with currently enforced policy.
Applies to
Windows 10
Windows Server 2016
Event Description:
This error indicates one of two situations, low
memory resources or Windows Firewall group
policy registry corruption.
Typically if this event occurs it indicates that
Windows Firewall service was not able to start.
It typically occurs with 5027(S): The Windows
Firewall Service was unable to retrieve the
security policy from the local storage. The
service will continue enforcing the current
policy.
Event XML:
- <System>
<Level>0</Level>
<Task>12292</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Error Code [Type = UInt32]: unique error code. For information about error codes meanings for this event use

For 5028(F): The Windows Firewall Service was unable to parse the new security policy. The service will continue
with currently enforced policy.
This event can be a sign of software or operating system issues, Windows Firewall registry errors or corruption,
or Group Policy setting misconfigurations. We recommend monitoring this event and investigating the reason
for the condition. Typically this event indicates configuration issues, not security issues.
5029(F): The Windows Firewall Service failed to
initialize the driver. The service will continue to
enforce the current policy.
Applies to
Windows 10
Windows Server 2016
Windows logs an error if either the Windows Firewall service or its driver fails to start, or if they unexpectedly
terminate. The error message indicates the cause of the service failure by including an error code in the text of the
message.
Event Schema:
The Windows Firewall service failed to initialize the driver. Windows Firewall will continue to enforce the current
policy.
Error Code:%1
Event Versions: 0.

This event can be a sign of software or operating system issues, or a sign of malicious activity that corrupted
Windows Firewall Driver. We recommend monitoring this event and investigating the reason for the condition.
5030(F): The Windows Firewall Service failed to start.
Applies to
Windows 10
Windows Server 2016
Windows logs this event if the Windows Firewall service fails to start, or if it unexpectedly terminates. The error
message indicates the cause of the service failure by including an error code in the text of the message.
This event doesn't generate during Windows Firewall service failures if Windows Firewall policy is
incorrect\corrupted or one of the service dependencies was not started.
Event Schema:
The Windows Firewall service failed to start.
Error Code:%1
Event Versions: 0.

5032(F): Windows Firewall was unable to notify the
user that it blocked an application from accepting
Applies to
Windows 10
Windows Server 2016
Windows Firewall with Advanced Security can be configured to notify the user when an application is blocked by
the firewall, and ask if the application should continue to be blocked in the future.
This event generates if Windows Firewall was unable to notify the user that it blocked an application from accepting
Event Schema:
Windows Firewall was unable to notify the user that it blocked an application from accepting incoming
connections on the network.
Error Code:%1
Event Versions: 0.

5033(S): The Windows Firewall Driver has started
successfully.
Applies to
Windows 10
Windows Server 2016
Event Description:
driver (Windows Firewall Authorization Driver
service) has started successfully.
system startup process.

Event XML:
- <System>
<Level>0</Level>
<Task>12292</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
<EventData />
</Event>

Event Versions: 0.

For 5033(S): The Windows Firewall Driver has started successfully.
Typically this event has an informational purpose. Its logged during operating system startup process.
5034(S): The Windows Firewall Driver was stopped.
Applies to
Windows 10
Windows Server 2016
Event Description:
driver (Windows Firewall Authorization Driver
service) was stopped.
This event is NOT logged during the operating
system shutdown process.

Event XML:
- <System>
<Level>0</Level>
<Task>12292</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
<EventData />
</Event>

Event Versions: 0.

For 5034(S): The Windows Firewall Driver was stopped.
This event is NOT logged during the operating system shutdown process.
You should not see this event during normal operating system operations, so we recommend that when it
occurs, you investigate why the Windows Firewall driver was stopped.
5035(F): The Windows Firewall Driver failed to start.
Applies to
Windows 10
Windows Server 2016
Windows logs this event if Windows Firewall driver fails to start, or if it unexpectedly terminates. The error message
indicates the cause of the failure by including an error code in the text of the message.
Event Schema:
The Windows Firewall Driver failed to start.
Error Code:%1
Event Versions: 0.

5037(F): The Windows Firewall Driver detected critical
runtime error. Terminating.
Applies to
Windows 10
Windows Server 2016
Windows logs this event if Windows Firewall driver fails to start, or if it unexpectedly terminates. The error message
indicates the cause of the failure by including an error code in the text of the message.
Event Schema:
The Windows Firewall Driver detected a critical runtime error, terminating.
Error Code:%1
Event Versions: 0.

5058(S, F): Key file operation.
Applies to
Windows 10
Windows Server 2016

Event Description:
This event generates when an operation (read, write, delete, and so on) was performed on a file that contains a KSP
key by using a Key Storage Provider (KSP). This event generates only if one of the following KSPs were used:
Microsoft Software Key Storage Provider
Microsoft Smart Card Key Storage Provider
You can see these events, for example, during certificate renewal or export operations using KSP.
Event XML:
- <System>
<Level>0</Level>
<Task>12292</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SubjectLogonId">0x38e2d</Data>
<Data Name="ProviderName">Microsoft Software Key Storage Provider</Data>
<Data Name="AlgorithmName">ECDH\_P521</Data>
<Data Name="KeyName">le-SuperAdmin-5e350d8e-ae46-458c-bac0-d8f3279c944e</Data>
<Data Name="KeyType">%%2500</Data>
<Data
Name="KeyFilePath">C:\\Users\\dadmin\\AppData\\Roaming\\Microsoft\\Crypto\\Keys\\c0a496c6786f0d25e8624fee96e4e5
80\_7a1bf91d-ebdd-449c-825d-c97f2f47cd01</Data>
<Data Name="Operation">%%2459</Data>
<Data Name="ReturnCode">0x0</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested key file operation. Event Viewer automatically tries to
Account Name [Type = UnicodeString]: the name of the account that requested key file operation.
the following:
Cryptographic Parameters:
Provider Name [Type = UnicodeString]: the name of KSP through which the operation was performed. Can
have one of the following values:
Algorithm Name [Type = UnicodeString]: the name of cryptographic algorithm through which the key was
used or accessed. For Read persisted key from file operation, this typically has UNKNOWN value. Can
also have one of the following values:
RSA algorithm created by Ron Rivest, Adi Shamir, and Leonard Adleman.
DSA Digital Signature Algorithm.
DH Diffie-Hellman.
ECDH_P521 Elliptic Curve Diffie-Hellman algorithm with 512-bit key length.
ECDSA_P256 Elliptic Curve Digital Signature Algorithm with 256-bit key length.
Key Name [Type = UnicodeString]: the name of the key (key container) with which operation was
performed. For example, to get the list of Key Names for certificates for logged in user you can use certutil
-store -user my command and check Key Container parameter in the output. Here is an output example:
Key Type [Type = UnicodeString]: can have one of the following values:
User key. users cryptographic key.
Machine key. machines cryptographic key.
Key File Operation Information:
File Path [Type = UnicodeString]: full path and filename of the key file on which the operation was
performed.
Operation [Type = UnicodeString]: performed operation. Examples:
Write persisted key to file.
Read persisted key from file.
Delete key file.
Return Code [Type = HexInt32]: has 0x0 value for Success events. For failure events, provides a
hexadecimal error code number.

For 5058(S, F): Key file operation.
Typically this event is required for detailed monitoring of KSP-related actions with cryptographic keys. If you
need to monitor actions related to specific cryptographic keys (Key Name) or a specific Operation, such as
Delete key file, create monitoring rules and use this event as an information source.
5059(S, F): Key migration operation.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates when a
cryptographic key is exported or
imported using a Key Storage Provider
(KSP). This event generates only if one of
the following KSPs were used:
Microsoft Software Key Storage
Provider
Microsoft Smart Card Key Storage
Provider

for this event.
Event XML:
- <System>
<Level>0</Level>
<Task>12292</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="KeyName">le-SuperAdmin-795fd6c1-2fae-4bef-a6bc-4f4d464bc083</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested key migration operation. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: the name of the account that requested key migration operation.
the following:
DH Diffie-Hellman.
Operation [Type = UnicodeString]: performed operation. Examples:
Export of persistent cryptographic key. typically generates during key read operations, which
means that the key was taken for read purposes. But it also generates during real key export
operations (export certificate with private key, for example).
Import of persistent cryptographic key. key import operation was performed (import
certificate with private key, for example).

For 5059(S, F): Key migration operation.
Export of persistent cryptographic key, create monitoring rules and use this event as an information
source.
6400(-): BranchCache: Received an incorrectly
formatted response while discovering availability of
content.
Applies to
Windows 10
Windows Server 2016
BranchCache events are outside the scope of this document.
Event Schema:
BranchCache: Received an incorrectly formatted response while discovering availability of content.
*IP address of the client that sent this response:%1 *
Event Versions: 0.

6401(-): BranchCache: Received invalid data from a
peer. Data discarded.
Applies to
Windows 10
Windows Server 2016
Event Schema:
*BranchCache: Received invalid data from a peer. Data discarded. *
IP address of the client that sent this data:%1
Event Versions: 0.

6402(-): BranchCache: The message to the hosted
cache offering it data is incorrectly formatted.
Applies to
Windows 10
Windows Server 2016
Event Schema:
*BranchCache: The message to the hosted cache offering it data is incorrectly formatted. *
IP address of the client that sent this message: %1
Event Versions: 0.

6403(-): BranchCache: The hosted cache sent an
incorrectly formatted response to the client.
Applies to
Windows 10
Windows Server 2016
Event Schema:
*BranchCache: The hosted cache sent an incorrectly formatted response to the clients message to offer it data. *
Domain name of the hosted cache is:%1
Event Versions: 0.

6404(-): BranchCache: Hosted cache could not be
authenticated using the provisioned SSL certificate.
Applies to
Windows 10
Windows Server 2016
Event Schema:
*BranchCache: Hosted cache could not be authenticated using the provisioned SSL certificate. *
Domain name of the hosted cache:%1
Error Code:%2
Event Versions: 0.

6405(-): BranchCache: %2 instance(s) of event id %1
occurred.
Applies to
Windows 10
Windows Server 2016
Event Schema:
BranchCache: %2 instance(s) of event id %1 occurred.
Event Versions: 0.

6406(-): %1 registered to Windows Firewall to control
filtering for the following: %2.
Applies to
Windows 10
Windows Server 2016
Event Schema:
%1 registered to Windows Firewall to control filtering for the following:
%2.
Event Versions: 0.

6407(-): 1%.
Applies to
Windows 10
Windows Server 2016
Event Schema:
%1
Event Versions: 0.

6408(-): Registered product %1 failed and Windows
Firewall is now controlling the filtering for %2.
Applies to
Windows 10
Windows Server 2016
Event Schema:
Registered product %1 failed and Windows Firewall is now controlling the filtering for %2.
Event Versions: 0.

6409(-): BranchCache: A service connection point
object could not be parsed.
Applies to
Windows 10
Windows Server 2016
Event Schema:
*BranchCache: A service connection point object could not be parsed. *
SCP object GUID: %1
Event Versions: 0.

Audit Security State Change
Applies to
Windows 10
Windows Server 2016
Audit Security State Change contains Windows startup, recovery, and shutdown events, and information about
changes in system time.
Event volume: Low.
STRONGER STRONGER
Domain Yes No Yes No The volume of

Controller events in this
subcategory is
very low and all
of them are
important events
and have security
relevance.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Member Server Yes No Yes No The volume of

events in this
subcategory is
very low and all
of them are
important events
and have security
relevance.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Workstation Yes No Yes No The volume of

events in this
subcategory is
very low and all
of them are
important events
and have security
relevance.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Events List:
4608(S): Windows is starting up.
4616(S): The system time was changed.
4621(S): Administrator recovered system from CrashOnAuditFail.
Note Event 4609(S): Windows is shutting down currently doesnt generate. It is a defined event, but it is
never invoked by the operating system.
4608(S): Windows is starting up.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Security State Change
Event Description:
This event is logged when LSASS.EXE process
starts and the auditing subsystem is initialized.
It typically generates during operating system
startup process.

Event XML:
- <System>
<Level>0</Level>
<Task>12288</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
<EventData />
</Event>

Event Versions: 0.

For 4608(S): Windows is starting up.
With this event, you can track system startup events.
4616(S): The system time was changed.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Security State
Change
Event Description:
system time was changed.
This event is always logged
regardless of the "Audit Security
State Change" sub-category setting.
You will typically see these events
with Subject\Security ID =
LOCAL SERVICE, these are normal
time correction actions.

Security Monitoring
Event XML:
- <System>
<Level>0</Level>
<Task>12288</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="PreviousTime">2015-10-09T05:04:30.000941900Z</Data>
<Data Name="NewTime">2015-10-09T05:04:30.000000000Z</Data>
<Data Name="ProcessName">C:\\Windows\\WinSxS\\amd64\_microsoft-windows-com-surrogate-
core\_31bf3856ad364e35\_6.3.9600.16384\_none\_25a8f00faa8f185c\\dllhost.exe</Data>
</EventData>
</Event>

Event Versions:
1 - Windows Server 2008 R2, Windows 7.
Added Process Information section.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested the change system time operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested the change system time
operation.
the following:
Process Information [Version 1]:
Process ID [Type = Pointer] [Version 1]: hexadecimal Process ID of the process that changed the system
time. Process ID (PID) is a number used by the operating system to uniquely identify an active process. To
Name [Type = UnicodeString] [Version 1]: full path and the name of the executable for the process.
Previous Time [Type = FILETIME]: previous time in UTC time zone. The format is YYYY-MM-
DDThh:mm:ss.nnnnnnnZ:
Y - years
M - months
D - days
T - the beginning of the time element, as specified in ISO 8601.
h - hours
m - minutes
s - seconds
n - fractional seconds
Z - the zone designator for the zero UTC offset. "09:30 UTC" is therefore represented as "09:30Z". "14:45:15
UTC" would be "14:45:15Z".
New Time [Type = FILETIME]: new time that was set in UTC time zone. The format is YYYY-MM-
DDThh:mm:ss.nnnnnnnZ:
Y - years
M - months
D - days
T - the beginning of the time element, as specified in ISO 8601.
h - hours
m - minutes
s - seconds
n - fractional seconds
Z - the zone designator for the zero UTC offset. "09:30 UTC" is therefore represented as "09:30Z". "14:45:15
UTC" would be "14:45:15Z".

For 4616(S): The system time was changed.
Report all Subject\Security ID not equals LOCAL SERVICE, which means that the time change was not
made not by Windows Time service.
Report all Process Information\Name not equals C:\Windows\System32\svchost.exe (path to
svchost.exe can be different, you can search for svchost.exe substring), which means that the time change
was not made not by Windows Time service.
4621(S): Administrator recovered system from
CrashOnAuditFail.
Applies to
Windows 10
Windows Server 2016
This event is logged after a system reboots following CrashOnAuditFail. It generates when CrashOnAuditFail = 2.
Subcategory: Audit Security State Change
Event Schema:
Administrator recovered system from CrashOnAuditFail. Users who are not administrators will now be allowed to
log on. Some auditable activity might not have been recorded.
Value of CrashOnAuditFail:%1
This event is logged after a system reboots following CrashOnAuditFail.
Event Versions: 0.

We recommend triggering an alert for any occurrence of this event. The event shows that the system halted
because it could not record an auditable event in the Security Log, as described in CrashOnAuditFail.
If your computers dont have the CrashOnAuditFail flag enabled, then this event will be a sign that some
settings are not set to baseline settings or were changed.
Audit Security System Extension
Applies to
Windows 10
Windows Server 2016
Audit Security System Extension contains information about the loading of an authentication package, notification
package, or security package, plus information about trusted logon process registration events.
Changes to security system extensions in the operating system include the following activities:
Security extension code is loaded (for example, an authentication, notification, or security package). Security
extension code registers with the Local Security Authority and will be used and trusted to authenticate
logon attempts, submit logon requests, and be notified of any account or password changes. Examples of
this extension code are Security Support Providers, such as Kerberos and NTLM.
A service is installed. An audit log is generated when a service is registered with the Service Control
Manager. The audit log contains information about the service name, binary, type, start type, and service
account.
Attempts to install or load security system extensions or services are critical system events that could indicate a
security breach.
Event volume: Low.
STRONGER STRONGER
STRONGER STRONGER
Domain Yes No Yes No The main reason

Controller why we
recommend
Success auditing
for this
subcategory is
4697(S): A
service was
installed in the
system.
For other events
we strongly
recommend
monitoring a
whitelist of
allowed security
extensions
(authenticated
packages, logon
processes,
notification
packages, and
security
packages).
Otherwise it's
hard to pull
useful
information from
these events,
except event
4611 which
typically should
have SYSTEM as
value for
Subject field.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Member Server Yes No Yes No The main reason

why we
recommend
Success auditing
for this
subcategory is
4697(S): A
service was
installed in the
system.
For other events
we strongly
recommend
monitoring a
whitelist of
allowed security
extensions
(authenticated
packages, logon
processes,
notification
packages, and
security
packages).
Otherwise it's
hard to pull
useful
information from
these events,
except event
4611 which
typically should
display SYSTEM
for the Subject
field.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
STRONGER STRONGER
Workstation Yes No Yes No The main reason

why we
recommend
Success auditing
for this
subcategory is
4697(S): A
service was
installed in the
system.
For other events
we strongly
recommend
monitoring a
whitelist of
allowed security
extensions
(authenticated
packages, logon
processes,
notification
packages, and
security
packages).
Otherwise it's
hard to pull
useful
information from
these events,
except event
4611 which
typically should
display SYSTEM
for the Subject
field.
This subcategory
doesnt have
Failure events, so
there is no
recommendation
to enable Failure
auditing for this
subcategory.
Events List:
4610(S): An authentication package has been loaded by the Local Security Authority.
4611(S): A trusted logon process has been registered with the Local Security Authority.
4614(S): A notification package has been loaded by the Security Account Manager.
4622(S): A security package has been loaded by the Local Security Authority.
4697(S): A service was installed in the system.
4610(S): An authentication package has been loaded
by the Local Security Authority.
Applies to
Windows 10
Windows Server 2016
Subcategory: Audit Security System Extension

Event Description:
This event generates every time Authentication Package has been loaded by the Local Security Authority (LSA).
Each time the system starts, the LSA loads the Authentication Package DLLs from
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages registry value
and performs the initialization sequence for every package located in these DLLs.
Event XML:
- <System>
<Level>0</Level>
<Task>12289</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="AuthenticationPackageName">C:\\Windows\\system32\\msv1\_0.DLL :
MICROSOFT\_AUTHENTICATION\_PACKAGE\_V1\_0</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Authentication Package Name [Type = UnicodeString]: the name of loaded Authentication Package. The format
is: DLL_PATH_AND_NAME: AUTHENTICATION_PACKAGE_NAME.
By default the only one Authentication Package loaded by Windows 10 is
MICROSOFT_AUTHENTICATION_PACKAGE_V1_0.

For 4610(S): An authentication package has been loaded by the Local Security Authority.
Report all Authentication Package Name not equals C:\Windows\system32\msv1_0.DLL :
MICROSOFT_AUTHENTICATION_PACKAGE_V1_0, because by default this is the only Authentication
Package loaded by Windows 10.
Typically this event has an informational purpose. If you have a pre-defined list of allowed Authentication
Packages in the system, then you can check whether Authentication Package Name is in your defined
list.
4611(S): A trusted logon process has been registered
with the Local Security Authority.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event indicates that a logon process has
registered with the Local Security Authority
(LSA). Also, logon requests will now be
accepted from this source.
At the technical level, the event does not come
from the registration of a trusted logon
process, but from a confirmation that the
process is a trusted logon process. If it is a
trusted logon process, the event generates.
A logon process is a trusted part of the
operating system that handles the overall
logon function for different logon methods
(network, interactive, etc.).
You typically see these events during operating system startup or user logon and authentication actions.
Event XML:
- <System>
<Level>0</Level>
<Task>12289</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="LogonProcessName">Winlogon</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that registered the trusted logon process. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: the name of the account that registered the trusted logon process.
the following:
Logon Process Name [Type = UnicodeString]: the name of registered logon process.

For 4611(S): A trusted logon process has been registered with the Local Security Authority.
Because this event is typically triggered by the SYSTEM account, we recommend that you report it
whenever Subject\Security ID is not SYSTEM.
Typically this event has an informational purpose. If you defined the list of allowed Logon Processes in the
system, then you can check is Logon Process Name field value in the whitelist or not.
4614(S): A notification package has been loaded by
the Security Account Manager.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time a Notification
Package has been loaded by the Security
Account Manager.
In reality, starting with Windows Vista, a
notification package should be interpreted as
afs Password Filter.
Password Filters are DLLs that are loaded or
called when passwords are set or changed.
Each time a system starts, it loads the notification package DLLs from
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages registry value and
performs the initialization sequence for every package.
Event XML:
- <System>
<Level>0</Level>
<Task>12289</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="NotificationPackageName">WDIGEST</Data>
</EventData>
</Event>
Event Versions: 0.
Field Descriptions:
Notification Package Name [Type = UnicodeString]: the name of loaded Notification Package.

For 4614(S): A notification package has been loaded by the Security Account Manager.
Typically this event has an informational purpose. If you defined the list of allowed Notification Packages in the
system, then you can check is Notification Package Name field value in the whitelist or not.
4622(S): A security package has been loaded by the
Local Security Authority.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates every time Security
Package has been loaded by the Local Security
Authority (LSA).
Security Package is the software
implementation of a security protocol
(Kerberos, NTLM, for example). Security
packages are contained in security support
provider DLLs or security support
provider/authentication package DLLs.
Each time the system starts, the LSA loads the Security Package DLLs from
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages registry
value and performs the initialization sequence for every package located in these DLLs.
It is also possible to add security package dynamically using AddSecurityPackage function, not only during system
startup process.
Event XML:
- <System>
<Level>0</Level>
<Task>12289</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="SecurityPackageName">C:\\Windows\\system32\\kerberos.DLL : Kerberos</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Security Package Name [Type = UnicodeString]: the name of loaded Security Package. The format is:
DLL_PATH_AND_NAME: SECURITY_PACKAGE_NAME.
These are some Security Package DLLs loaded by default in Windows 10:
C:\Windows\system32\schannel.DLL : Microsoft Unified Security Protocol Provider
C:\Windows\system32\schannel.DLL : Schannel
C:\Windows\system32\cloudAP.DLL : CloudAP
C:\Windows\system32\wdigest.DLL : WDigest
C:\Windows\system32\pku2u.DLL : pku2u
C:\Windows\system32\tspkg.DLL : TSSSP
C:\Windows\system32\msv1_0.DLL : NTLM
C:\Windows\system32\kerberos.DLL : Kerberos
C:\Windows\system32\negoexts.DLL : NegoExtender
C:\Windows\system32\lsasrv.dll : Negotiate

For 4622(S): A security package has been loaded by the Local Security Authority.
Typically this event has an informational purpose. If you defined the list of allowed Security Packages in the
system, then you can check is Security Package Name field value in the whitelist or not.
4697(S): A service was installed in the system.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates when new service was
installed in the system.

Event XML:
- <System>
<Level>0</Level>
<Task>12289</Task>
<Opcode>0</Opcode>
<Correlation ActivityID="{913FBE70-1CE6-0000-67BF-3F91E61CD101}" />
<Security />
</System>
- <EventData>
<Data Name="ServiceName">AppHostSvc</Data>
<Data Name="ServiceFileName">%windir%\\system32\\svchost.exe -k apphost</Data>
<Data Name="ServiceType">0x20</Data>
<Data Name="ServiceStartType">2</Data>
<Data Name="ServiceAccount">localSystem</Data>
</EventData>
</Event>
Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that was used to install the service. Event Viewer automatically tries to
event.
Account Name [Type = UnicodeString]: the name of the account that was used to install the service.
the following:
Service Name [Type = UnicodeString]: the name of installed service.
Service File Name [Type = UnicodeString]: This is the fully rooted path to the file that the Service Control
Manager will execute to start the service. If command-line parameters are specified as part of the image
path, those are logged.
Note that this is the path to the file when the service is created. If the path is changed afterwards, the
change is not logged. This would have to be tracked via Process Create events.
Service Type [Type = HexInt32]: Indicates the type of service that was registered with the Service Control
Manager. It can be one of the following:
VALUE SERVICE TYPE DESCRIPTION
0x1 Kernel Driver A Kernel device driver such as a hard

disk or other low-level hardware device
driver.
0x2 File System Driver A file system driver, which is also a

Kernel device driver.
0x8 Recognizer Driver A file system driver used during startup

to determine the file systems present
on the system.
0x10 Win32 Own Process A Win32 program that can be started

by the Service Controller and that
obeys the service control protocol. This
type of Win32 service runs in a process
by itself (this is the most common).
0x20 Win32 Share Process A Win32 service that can share a

process with other Win32 services.
(see: http://msdn.microsoft.com/en-
us/library/windows/desktop/ms685967(
v=vs.85).aspx
0x110 Interactive Own Process A service that should be run as a

standalone process and can
communicate with the desktop.
(see: http://msdn.microsoft.com/en-
us/library/windows/desktop/ms683502(
v=vs.85).aspx)
0x120 Interactive Share Process A service that can share address space
with other services of the same type
and can communicate with the desktop.
Service Start Type [Type = HexInt32]: The service start type can have one of the following values (see:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682450(v=vs.85).aspx):
0 Boot A device driver started by the system

loader. This value is valid only for driver
services.
1 System A device driver started by the

IoInitSystem() function. This value is
valid only for driver services.
2 Automatic A service started automatically by the

service control manager during system
startup.
2 Automatic Delayed A service started after all auto-start

services have started, plus a delay.
Delayed Auto Start services are started
one at a time in a serial fashion.
3 Manual Manual start. A service started by the

service control manager when a process
calls the StartService function.
4 Disabled A service that cannot be started.

Attempts to start the service result in
the error code
ERROR_SERVICE_DISABLED.
Most services installed are configured to Auto Load, so that they start automatically after Services.exe process is
started.
Service Account [Type = UnicodeString]: The security context that the service will run as when started.
Note that this is what was configured when the service was installed, if the account is changed later that is
not logged.
The service account parameter is only populated if the service type is a "Win32 Own Process" or "Win32
Share Process" (displayed as "User Mode Service."). Kernel drivers do not have a service account name
logged.
If a service (Win32 Own/Share process) is installed but no account is supplied, then LocalSystem is used.
The token performing the logon is inspected, and if it has a SID then that SID value is populated in the event
(in the System/Security node), if not, then it is blank.

For 4697(S): A service was installed in the system.
We recommend monitoring for this event, especially on high value assets or computers, because a new
service installation should be planned and expected. Unexpected service installation should trigger an alert.
Monitor for all events where Service File Name is not located in %windir% or Program
Files/Program Files (x86) folders. Typically new services are located in these folders.
Report all Service Type equals 0x1, 0x2 or 0x8. These service types start first and have almost
unlimited access to the operating system from the beginning of operating system startup. These types are
very rarely installed.
Report all Service Start Type equals 0 or 1. These service start types are used by drivers, which have
unlimited access to the operating system.
Report all Service Start Type equals 4. It is not common to install a new service in the Disabled state.
Report all Service Account not equals localSystem, localService or networkService to identify
services which are running under a user account.
Audit System Integrity
Applies to
Windows 10
Windows Server 2016
Audit System Integrity determines whether the operating system audits events that violate the integrity of the
security subsystem.
Activities that violate the integrity of the security subsystem include the following:
Audited events are lost due to a failure of the auditing system.
A process uses an invalid local procedure call (LPC) port in an attempt to impersonate a client, reply to a
client address space, read to a client address space, or write from a client address space.
A remote procedure call (RPC) integrity violation is detected.
A code integrity violation with an invalid hash value of an executable file is detected.
Cryptographic tasks are performed.
Violations of security subsystem integrity are critical and could indicate a potential security attack.
Event volume: Low.
STRONGER STRONGER
STRONGER STRONGER
Domain Yes Yes Yes Yes The main reason

Controller why we
recommend
Success auditing
for this
subcategory is to
be able to get
RPC integrity
violation errors
and auditing
subsystem errors
(event 4612).
However, if you
are planning to
manually invoke
4618(S): A
monitored
security event
pattern has
occurred, then
you also need to
enable Success
auditing for this
subcategory.
The main reason
why we
recommend
Failure auditing
for this
subcategory is to
be able to get
Code Integrity
failure events.
STRONGER STRONGER
Member Server Yes Yes Yes Yes The main reason

why we
recommend
Success auditing
for this
subcategory is to
be able to get
RPC integrity
violation errors
and auditing
subsystem errors
(event 4612).
However, if you
are planning to
manually invoke
4618(S): A
monitored
security event
pattern has
occurred, then
you also need to
enable Success
auditing for this
subcategory.
The main reason
why we
recommend
Failure auditing
for this
subcategory is to
be able to get
Code Integrity
failure events.
STRONGER STRONGER
Workstation Yes Yes Yes Yes The main reason

why we
recommend
Success auditing
for this
subcategory is to
be able to get
RPC integrity
violation errors
and auditing
subsystem errors
(event 4612).
However, if you
are planning to
manually invoke
4618(S): A
monitored
security event
pattern has
occurred, then
you also need to
enable Success
auditing for this
subcategory.
The main reason
why we
recommend
Failure auditing
for this
subcategory is to
be able to get
Code Integrity
failure events.
Events List:
4612(S): Internal resources allocated for the queuing of audit messages have been exhausted, leading to
the loss of some audits.
4615(S): Invalid use of LPC port.
4618(S): A monitored security event pattern has occurred.
4816(S): RPC detected an integrity violation while decrypting an incoming message.
5038(F): Code integrity determined that the image hash of a file is not valid. The file could be corrupt due
to unauthorized modification or the invalid hash could indicate a potential disk device error.
5056(S): A cryptographic self-test was performed.
5062(S): A kernel-mode cryptographic self-test was performed.
5057(F): A cryptographic primitive operation failed.
5060(F): Verification operation failed.
5061(S, F): Cryptographic operation.
6281(F): Code Integrity determined that the page hashes of an image file are not valid. The file could be
improperly signed without page hashes or corrupt due to unauthorized modification. The invalid hashes
could indicate a potential disk device error.
6410(F): Code integrity determined that a file does not meet the security requirements to load into a
process.
4612(S): Internal resources allocated for the queuing
of audit messages have been exhausted, leading to
the loss of some audits.
Applies to
Windows 10
Windows Server 2016
This event is generated when audit queues are filled and events must be discarded. This most commonly occurs
when security events are being generated faster than they are being written to disk.
This event doesn't generate when the event log service is stopped or event log is full and events retention is
disabled.
Subcategory: Audit System Integrity
Event Schema:
*Internal resources allocated for the queuing of audit messages have been exhausted, leading to the loss of some
audits. *
*Number of audit messages discarded: %1 *
This event is generated when audit queues are filled and events must be discarded. This most commonly occurs
when security events are being generated faster than they are being written to disk, or when the auditing system
loses connectivity to the event log, such as when the event log service is stopped.
Event Versions: 0.

This event can be a sign of hardware issues or lack of system resources (for example, RAM). We recommend
monitoring this event and investigating the reason for the condition.
4615(S): Invalid use of LPC port.
Applies to
Windows 10
Windows Server 2016
Event Schema:
Invalid use of LPC port.
Subject:
Security ID%1
Account Name:%2
Account Domain:%3
Logon ID:%4
PID:%7
Name:%8
Invalid Use:%5
LPC Server Port Name:%6
*Windows Local Security Authority (LSA) communicates with the Windows kernel using Local Procedure Call (LPC)
ports. If you see this event, an application has inadvertently or intentionally accessed this port which is reserved
exclusively for LSAs use. The application (process) should be investigated to ensure that it is not attempting to
tamper with this communications channel." *
Event Versions: 0.

4618(S): A monitored security event pattern has
occurred.
Applies to
Windows 10
Windows Server 2016
This event can be generated (invoked) only externally using the following command:
%windir%\system32\rundll32 %windir%\system32\authz.dll,AuthziGenerateAdminAlertAudit
OrgEventId ComputerName UserSid UserName UserDomain UserLogonId EventCount Duration
Account must have SeAuditPrivilege (Generate security audits) to be able to generate this event.
UserSid is resolved when viewing the event in event viewer.
Only OrgEventID, ComputerName, and EventCount are requiredothers are optional. Fields not
specified appear with - in the event description field.
If a field doesnt match the expected data type, the event is not generated. (i.e., if EventCount = XYZ then
no event is generated.)
UserSid, UserName, and UserDomain are not related to each other (think SubjectUser fields, where they
are)
Parameters are space delimited, even if a parameter is enclosed in double-quotes.
Here are the expected data types for the parameters:
PARAMETER EXPECTED DATA TYPE
OrgEventID Ulong
ComputerName String
UserSid SID (in string format)
UserName String
UserDomain String
UserLogonID Luid (a ULongLong converted to Hex in the event)
EventCount Ulong
Duration String
Event XML:
- <System>
<Level>0</Level>
<Task>12290</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="EventId">4624</Data>
<Data Name="ComputerName">DC01.contoso.local</Data>
<Data Name="TargetUserDomain">CONTOSO</Data>
<Data Name="TargetLogonId">0x1</Data>
<Data Name="EventCount">10</Data>
<Data Name="Duration">Hour"</Data>
</EventData>
</Event>

Event Versions: 0.

For 4618(S): A monitored security event pattern has occurred.
This event can be invoked only manually/intentionally, it is up to you how interpret this event depends on
information you put inside of it.
4816(S): RPC detected an integrity violation while
decrypting an incoming message.
Applies to
Windows 10
Windows Server 2016
This message generates if RPC detected an integrity violation while decrypting an incoming message.
Event Schema:
RPC detected an integrity violation while decrypting an incoming message.
Peer Name: %1
Protocol Sequence: %2
Security Error: %3
Event Versions: 0.

We recommend monitoring for this event, especially on high value assets or computers, because it can be a sign
of a software or configuration issue, or a malicious action.
5038(F): Code integrity determined that the image
hash of a file is not valid. The file could be corrupt
due to unauthorized modification or the invalid hash
Applies to
Windows 10
Windows Server 2016
The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device
error.
This event generates by Code Integrity feature, if signature of a file is not valid.
Code Integrity is a feature that improves the security of the operating system by validating the integrity of a driver
or system file each time it is loaded into memory. Code Integrity detects whether an unsigned driver or system file
is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run
by a user account with administrative permissions. On x64-based versions of the operating system, kernel-mode
drivers must be digitally signed.
Event Schema:
Code integrity determined that the image hash of a file is not valid. The file could be corrupt due to unauthorized
modification or the invalid hash could indicate a potential disk device error.
File Name: %filepath\filename%

5056(S): A cryptographic self-test was performed.
Applies to
Windows 10
Windows Server 2016
This event generates in CNG Self-Test function. This is a Cryptographic Next Generation (CNG) function.
https://msdn.microsoft.com/en-us/library/windows/desktop/bb204775(v=vs.85).aspx
Event Schema:
A cryptographic self test was performed.
Subject:
Security ID%1
Account Name:%2
Account Domain:%3
Logon ID:%4
Module:%5
Return Code:%6
Event Versions: 0.

Typically this event is required for detailed monitoring of CNG-related actions with cryptographic keys. If you
need to monitor or troubleshoot actions related to specific cryptographic keys and operations, review this event
to see if it provides the information you need.
5062(S): A kernel-mode cryptographic self-test was
performed.
Applies to
Windows 10
Windows Server 2016
This event occurs rarely, and in some situations may be difficult to reproduce.
Event Schema:
A kernel-mode cryptographic self test was performed.
Module:%1
Return Code:%2
Event Versions: 0.

5057(F): A cryptographic primitive operation failed.
Applies to
Windows 10
Windows Server 2016
This event generates in case of CNG primitive operation failure.
Event Schema:
A cryptographic primitive operation failed.
Subject:
Security ID%1
Account Name:%2
Account Domain:%3
Logon ID:%4
Provider Name:%5
Algorithm Name%6
Reason:%7
Return Code:%8

Event Versions: 0.
5060(F): Verification operation failed.
Applies to
Windows 10
Windows Server 2016
This event generates in case of CNG verification operation failure.
Event Schema:
Verification operation failed.
Subject:
Security ID%1
Account Name:%2
Account Domain:%3
Logon ID:%4
Provider Name:%5
Algorithm Name%6
Key Name:%7
Key Type:%8
Reason:%7
Return Code:%8

Event Versions: 0.

5061(S, F): Cryptographic operation.
Applies to
Windows 10
Windows Server 2016
Event Description:
This event generates when a
cryptographic operation (open key, create
key, create key, and so on) was performed
using a Key Storage Provider (KSP). This
event generates only if one of the
following KSPs were used:
Microsoft Software Key Storage
Provider
Microsoft Smart Card Key Storage
Provider

for this event.
Event XML:
- <System>
<Level>0</Level>
<Task>12290</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <EventData>
<Data Name="KeyName">le-SuperAdmin-795fd6c1-2fae-4bef-a6bc-4f4d464bc083</Data>
</EventData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that requested specific cryptographic operation. Event Viewer
Account Name [Type = UnicodeString]: the name of the account that requested specific cryptographic
operation.
the following:
DH Diffie-Hellman.
Cryptographic Operation:
Operation [Type = UnicodeString]: performed operation. Possible values:
Open Key. open existing cryptographic key.
Create Key. create new cryptographic key.
Delete Key. delete existing cryptographic key.
Sign hash. cryptographic signing operation.
Secret agreement.
Key Derivation. key derivation operation.
Encrypt. encryption operation.
Decrypt. decryption operation.

For 5061(S, F): Cryptographic operation.
Delete Key, create monitoring rules and use this event as an information source.
6281(F): Code Integrity determined that the page
hashes of an image file are not valid. The file could be
improperly signed without page hashes or corrupt
due to unauthorized modification. The invalid hashes
Applies to
Windows 10
Windows Server 2016
The file could be improperly signed without page hashes or corrupt due to unauthorized modification. The invalid
hashes could indicate a potential disk device error.
This event generates when code Integrity determined that the page hashes of an image file are not valid. The file
could be improperly signed without page hashes or corrupt due to unauthorized modification. This event also
generates when signing certificate was revoked. The invalid hashes could indicate a potential disk device error.
Event Schema:
Code Integrity determined that the page hashes of an image file are not valid. The file could be improperly signed
without page hashes or corrupt due to unauthorized modification. The invalid hashes could indicate a potential
disk device error.
File Name:%1
Event Versions: 0.

6410(F): Code integrity determined that a file does
not meet the security requirements to load into a
process.
Applies to
Windows 10
Windows Server 2016
This event generates due to writable shared sections being present in a file image.
Event Schema:
Code integrity determined that a file does not meet the security requirements to load into a process. This could be
due to the use of shared sections or other issues.
File Name:%1
Minimum OS Version: Windows Server 2012 R2, Windows 8.1.
Event Versions: 0.

Other Events
Applies to
Windows 10
Windows Server 2016
Events in this section generate automatically and are enabled by default.
Events List:
1100(S): The event logging service has shut down.
1102(S): The audit log was cleared.
1104(S): The security log is now full.
1105(S): Event log automatic backup.
1108(S): The event logging service encountered an error while processing an incoming event published
from %1
1100(S): The event logging service has shut down.
Applies to
Windows 10
Windows Server 2016
Subcategory: Other Events
Event Description:
Event Log service has shut down.
It also generates during normal system
shutdown.
This event doesnt generate during emergency
system reset.

Event XML:
- <System>
<Provider Name="Microsoft-Windows-Eventlog" Guid="{fc65ddd8-d6ef-4962-83d5-6e5cfe9ce148}" />
<Level>4</Level>
<Task>103</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <UserData>
<ServiceShutdown xmlns="http://manifests.microsoft.com/win/2004/08/windows/eventlog" />
</UserData>
</Event>

Event Versions: 0.
For 1100(S): The event logging service has shut down.
With this event, you can track system shutdowns and restarts.
This event also can be a sign of malicious action when someone tried to shut down the Log Service to cover
his or her activity.
1102(S): The audit log was cleared.
Applies to
Windows 10
Windows Server 2016
Event Description:
Security audit log was cleared.

Event XML:
- <System>
<Level>4</Level>
<Task>104</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <UserData>
- <LogFileCleared xmlns="http://manifests.microsoft.com/win/2004/08/windows/eventlog">
<SubjectUserSid>S-1-5-21-3457937927-2839227994-823803824-1104</SubjectUserSid>
<SubjectUserName>dadmin</SubjectUserName>
<SubjectDomainName>CONTOSO</SubjectDomainName>
<SubjectLogonId>0x55cd1d</SubjectLogonId>
</LogFileCleared>
</UserData>
</Event>

Event Versions: 0.
Field Descriptions:
Subject:
Security ID [Type = SID]: SID of account that cleared the system security audit log. Event Viewer automatically
the event.
Account Name [Type = UnicodeString]: the name of the account that cleared the system security audit log.
the following:

For 1102(S): The audit log was cleared.
Typically you should not see this event. There is no need to manually clear the Security event log in most cases.
We recommend monitoring this event and investigating why this action was performed.
1104(S): The security log is now full.
Applies to
Windows 10
Windows Server 2016
Event Description:
security log becomes full.
This event generates, for example, if the
maximum size of Security Event Log file was
reached and event log retention method is: Do
not overwrite events (Clear logs manually).

Event XML:
- <System>
<Level>2</Level>
<Task>101</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <UserData>
<FileIsFull xmlns="http://manifests.microsoft.com/win/2004/08/windows/eventlog" />
</UserData>
</Event>

Event Versions: 0.

If the Security event log retention method is set to Do not overwrite events (Clear logs manually), then this
event will indicate that log file is full and you need to perform immediate actions, for example, archive the log or
clear it.
1105(S): Event log automatic backup.
Applies to
Windows 10
Windows Server 2016
Event Description:
time Windows security log
becomes full and new event
log file was created.
This event generates, for
example, if the maximum size
of Security Event Log file was
reached and event log
retention method is: Archive
the log when full, do not overwrite events.
Event XML:
- <System>
<Level>4</Level>
<Task>105</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <UserData>
- <AutoBackup xmlns="http://manifests.microsoft.com/win/2004/08/windows/eventlog">
<BackupPath>C:\\Windows\\System32\\Winevt\\Logs\\Archive-Security-2015-10-16-00-50-12-621.evtx</BackupPath>
</AutoBackup>
</UserData>
</Event>

Event Versions: 0.
Field Descriptions:
Log [Type = UnicodeString]: the name of the log which was archived (new event log file was created and previous
event log was archived). Always Security for Security Event Logs.
File: [Type = FILETIME]: full path and filename of archived log file.
The format of archived log file name is: Archive-LOG_FILE_NAME-YYYY-MM-DD-hh-mm-ss-nnn.evtx. Where:
LOG_FILE_NAME the name of archived file.
Y years.
M months.
D days.
h hours.
m minutes.
s seconds.
n fractional seconds.
The time in this event is always in GMT+0/UTC+0 time zone.

For 1105(S): Event log automatic backup.
Typically its an informational event and no actions are needed. But if your baseline settings are not set to
Archive the log when full, do not overwrite events, then this event will be a sign that some settings are not set to
baseline settings or were changed.
1108(S): The event logging service encountered an
error while processing an incoming event published
from %1.
Applies to
Windows 10
Windows Server 2016
Subcategory: Other
Events
Event Description:
when event logging
service encountered an
error while processing
an incoming event.
It typically generates
when logging service
will not be able to
correctly write the
event to the event log
or some parameters
were not passed to
logging service to log
the event correctly. You will typically see a defective or incorrect event before 1108.
For example, event 1108 might be generated after an incorrect 4703 event:
Event XML:
- <System>
<Level>2</Level>
<Task>101</Task>
<Opcode>0</Opcode>
<Correlation />
<Security />
</System>
- <UserData>
- <EventProcessingFailure xmlns="http://manifests.microsoft.com/win/2004/08/windows/eventlog">
<Error Code="15005" />
<PublisherID>Microsoft-Windows-Security-Auditing</PublisherID>
</EventProcessingFailure>
</UserData>
</Event>

Event Versions: 0.
Field Descriptions:
%1 [Type = UnicodeString]: the name of security event source from which event was received for processing. You
can see all registered security event source names in this registry path:
For 1108(S): The event logging service encountered an error while processing an incoming event published from
%1.
We recommend monitoring for all events of this type and checking what the cause of the error was.
Appendix A: Security monitoring
recommendations for many audit events
Applies to
Windows 10
Windows Server 2016
This document, the Advanced security audit policy settings reference, provides
information about individual audit events, and lists them within audit categories and
subcategories. However, there are many events for which the following overall
recommendations apply. There are links throughout this document from the
Recommendations sections of the relevant events to this appendix.
High-value accounts: You might have high- Monitor relevant events for the
value domain or local accounts for which you Subject\Security ID that corresponds to the
need to monitor each action. high-value account or accounts.
administrators, built-in local administrator
account, domain administrators, service
accounts, domain controller accounts and so
on.
Anomalies or malicious actions: You might When you monitor for anomalies or malicious
have specific requirements for detecting actions, use the Subject\Security ID (with
anomalies or monitoring potential malicious other information) to monitor how or when a
actions. For example, you might need to particular account is being used.
monitor for use of an account outside of
working hours.
Non-active accounts: You might have non- Monitor relevant events for the
active, disabled, or guest accounts, or other Subject\Security ID that corresponds to the
accounts that should never be used. accounts that should never be used.
Account whitelist: You might have a specific Monitor the relevant events for
whitelist of accounts that are the only ones Subject\Security ID accounts that are
allowed to perform actions corresponding to outside the whitelist of accounts.
particular events.
Accounts of different types: You might want Identify events that correspond to the actions
to ensure that certain actions are performed you want to monitor, and for those events,
only by certain account types, for example, local review the Subject\Security ID to see
or domain account, machine or user account, whether the account type is as expected.
vendor or employee account, and so on.
External accounts: You might be monitoring Monitor the specific events for the
accounts from another domain, or external Subject\Account Domain corresponding to
accounts that are not allowed to perform accounts from another domain or external
certain actions (represented by certain specific accounts.
events).
Restricted-use computers or devices: You Monitor the target Computer: (or other target
might have certain computers, machines, or device) for actions performed by the
devices on which certain people (accounts) Subject\Security ID that you are concerned
should not typically perform any actions. about.
Account naming conventions: Your Monitor Subject\Account Name for names

organization might have specific naming that dont comply with naming conventions.
conventions for account names.
Registry (Global Object Access Auditing)
Applies to
Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, Registry (Global Object
Access Auditing), which enables you to configure a global system access control list (SACL) on the registry of a
computer.
If you select the Configure security check box on this policys property page, you can add a user or group to the
global SACL. This enables you to define computer system access control lists (SACLs) per object type for the
registry. The specified SACL is then automatically applied to every registry object type.
This policy setting must be used in combination with the Registry security policy setting under Object Access. For
more info, see Audit Registry.
Related topics
File System (Global Object Access Auditing)
Applies to
Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, File System (Global Object
Access Auditing), which enables you to configure a global system access control list (SACL) on the file system for
an entire computer.
If you select the Configure security check box on the policys property page, you can add a user or group to the
global SACL. This enables you to define computer system access control lists (SACLs) per object type for the file
system. The specified SACL is then automatically applied to every file system object type.
If both a file or folder SACL and a global SACL are configured on a computer, the effective SACL is derived by
combining the file or folder SACL and the global SACL. This means that an audit event is generated if an activity
matches either the file or folder SACL or the global SACL. This policy setting must be used in combination with the
File System security policy setting under Object Access. For more information, see Audit File System.
Related topics
Applies to
Windows 10
This reference topic describes the common scenarios, architecture, and processes for security settings.
Security policy settings are rules that administrators configure on a computer or multiple devices for the purpose
of protecting resources on a device or network. The Security Settings extension of the Local Group Policy Editor
snap-in allows you to define security configurations as part of a Group Policy Object (GPO). The GPOs are linked to
Active Directory containers such as sites, domains, or organizational units, and they enable you to manage security
settings for multiple devices from any device joined to the domain. Security settings policies are used as part of
your overall security implementation to help secure domain controllers, servers, clients, and other resources in
your organization.
Security settings can control:
User authentication to a network or device.
The resources that users are permitted to access.
Whether to record a users or groups actions in the event log.
Membership in a group.
To manage security configurations for multiple devices, you can use one of the following options:
Edit specific security settings in a GPO.
Use the Security Templates snap-in to create a security template that contains the security policies you want to
apply, and then import the security template into a Group Policy Object. A security template is a file that
represents a security configuration, and it can be imported to a GPO, applied to a local device, or used to
analyze security.
For more info about managing security configurations, see Administer security policy settings.
The Security Settings extension of the Local Group Policy Editor includes the following types of security policies:
Account Policies. These polices are defined on devices; they affect how user accounts can interact with the
computer or domain. Account policies include the following types of policies:
Password Policy. These policies determine settings for passwords, such as enforcement and lifetimes.
Password policies are used for domain accounts.
Account Lockout Policy. These policies determine the conditions and length of time that an account
will be locked out of the system. Account lockout policies are used for domain or local user accounts.
Kerberos Policy. These policies are used for domain user accounts; they determine Kerberos-related
settings, such as ticket lifetimes and enforcement.
Local Policies. These policies apply to a computer and include the following types of policy settings:
Audit Policy. Specify security settings that control the logging of security events into the Security
log on the computer, and specifies what types of security events to log (success, failure, or both).
Note: For devices running Windows 7 and later, we recommend to use the settings under
Advanced Audit Policy Configuration rather than the Audit Policy settings under Local Policies.
User Rights Assignment. Specify the users or groups that have logon rights or privileges on a
device
Security Options. Specify security settings for the computer, such as Administrator and Guest Account
names; access to floppy disk drives and CD-ROM drives; installation of drivers; logon prompts; and so on.
Windows Firewall with Advanced Security. Specify settings to protect the device on your network by
using a stateful firewall that allows you to determine which network traffic is permitted to pass between
your device and the network.
Network List Manager Policies. Specify settings that you can use to configure different aspects of how
networks are listed and displayed on one device or on many devices.
Public Key Policies. Specify settings to control Encrypting File System, Data Protection, and BitLocker Drive
Encryption in addition to certain certificate paths and services settings.
Software Restriction Policies. Specify settings to identify software and to control its ability to run on your
local device, organizational unit, domain, or site.
Application Control Policies. Specify settings to control which users or groups can run particular applications
in your organization based on unique identities of files.
IP Security Policies on Local Computer. Specify settings to ensure private, secure communications over IP
networks through the use of cryptographic security services. IPsec establishes trust and security from a source
IP address to a destination IP address.
Advanced Audit Policy Configuration. Specify settings that control the logging of security events into the
security log on the device. The settings under Advanced Audit Policy Configuration provide finer control over
which activities to monitor as opposed to the Audit Policy settings under Local Policies.
Policy-based security settings management

The Security Settings extension to Group Policy provides an integrated policy-based management infrastructure to
help you manage and enforce your security policies.
You can define and apply security settings policies to users, groups, and network servers and clients through
Group Policy and Active Directory Domain Services (AD DS). A group of servers with the same functionality can be
created (for example, a Microsoft Web (IIS) server), and then Group Policy Objects can be used to apply common
security settings to the group. If more servers are added to this group later, many of the common security settings
are automatically applied, reducing deployment and administrative labor.
Common scenarios for using security settings policies
Security settings policies are used to manage the following aspects of security: accounts policy, local policy, user
rights assignment, registry values, file and registry Access Control Lists (ACLs), service startup modes, and more.
As part of your security strategy, you can create GPOs with security settings policies configured specifically for the
various roles in your organization, such as domain controllers, file servers, member servers, clients, and so on.
You can create an organizational unit (OU) structure that groups devices according to their roles. Using OUs is the
best method for separating specific security requirements for the different roles in your network. This approach
also allows you to apply customized security templates to each class of server or computer. After creating the
security templates, you create a new GPO for each of the OUs, and then import the security template (.inf file) into
the new GPO.
Importing a security template to a GPO ensures that any accounts to which the GPO is applied automatically
receive the templates security settings when the Group Policy settings are refreshed. On a workstation or server,
the security settings are refreshed at regular intervals (with a random offset of at most 30 minutes), and, on a
domain controller, this process occurs every few minutes if changes have occurred in any of the GPO settings that
apply. The settings are also refreshed every 16 hours, whether or not any changes have occurred.
Note: These refresh settings vary between versions of the operating system and can be configured.
By using Group Policybased security configurations in conjunction with the delegation of administration, you can
ensure that specific security settings, rights, and behavior are applied to all servers and computers within an OU.
This approach makes it simple to update a number of servers with any additional changes required in the future.
Dependencies on other operating system technologies
For devices that are members of a Windows Server 2008 or later domain, security settings policies depend on the
following technologies:
The Windows-based directory service, AD DS, stores information about objects on a network and makes this
information available to administrators and users. By using AD DS, you can view and manage network
objects on the network from a single location, and users can access permitted network resources by using a
single logon.
Group Policy
The infrastructure within AD DS that enables directory-based configuration management of user and
computer settings on devices running Windows Server. By using Group Policy, you can define
configurations for groups of users and computers, including policy settings, registry-based policies,
software installation, scripts, folder redirection, Remote Installation Services, Internet Explorer maintenance,
and security.
Domain Name System (DNS)
A hierarchical naming system used for locating domain names on the Internet and on private TCP/IP
networks. DNS provides a service for mapping DNS domain names to IP addresses, and IP addresses to
domain names. This allows users, computers, and applications to query DNS to specify remote systems by
fully qualified domain names rather than by IP addresses.
Winlogon
A part of the Windows operating system that provides interactive logon support. Winlogon is designed
around an interactive logon model that consists of three components: the Winlogon executable, a credential
provider, and any number of network providers.
Setup
Security configuration interacts with the operating system setup process during a clean installation or
upgrade from earlier versions of Windows Server.
Security Accounts Manager (SAM)
A Windows service used during the logon process. SAM maintains user account information, including
groups to which a user belongs.
Local Security Authority (LSA)
A protected subsystem that authenticates and logs users onto the local system. LSA also maintains
information about all aspects of local security on a system, collectively known as the Local Security Policy of
the system.
Windows Management Instrumentation (WMI)
A feature of the Microsoft Windows operating system, WMI is the Microsoft implementation of Web-Based
Enterprise Management (WBEM), which is an industry initiative to develop a standard technology for
accessing management information in an enterprise environment. WMI provides access to information
about objects in a managed environment. Through WMI and the WMI application programming interface
(API), applications can query for and make changes to static information in the Common Information Model
(CIM) repository and dynamic information maintained by the various types of providers.
Resultant Set of Policy (RSoP)
An enhanced Group Policy infrastructure that uses WMI in order to make it easier to plan and debug policy
settings. RSoP provides public methods that expose what an extension to Group Policy would do in a what-if
situation, and what the extension has done in an actual situation. This allows administrators to easily
determine the combination of policy settings that apply to, or will apply to, a user or device.
Service Control Manager (SCM)
Used for configuration of service startup modes and security.
Registry
Used for configuration of registry values and security.
File system
Used for configuration of security.
File system conversions
Security is set when an administrator converts a file system from FAT to NTFS.
Microsoft Management Console (MMC)
The user interface for the Security Settings tool is an extension of the Local Group Policy Editor MMC snap-
in.
Security settings policies and Group Policy
The Security Settings extension of the Local Group Policy Editor is part of the Security Configuration Manager tool
set. The following components are associated with Security Settings: a configuration engine; an analysis engine; a
template and database interface layer; setup integration logic; and the secedit.exe command-line tool. The security
configuration engine is responsible for handling security configuration editor-related security requests for the
system on which it runs. The analysis engine analyzes system security for a given configuration and saves the
result. The template and database interface layer handles reading and writing requests from and to the template or
database (for internal storage). The Security Settings extension of the Local Group Policy Editor handles Group
Policy from a domain-based or local device. The security configuration logic integrates with setup and manages
system security for a clean installation or upgrade to a more recent Windows operating system. Security
information is stored in templates (.inf files) or in the Secedit.sdb database.
The following diagram shows Security Settings and related features.
Security Settings Policies and Related Features
Scesrv.dll
Provides the core security engine functionality.
Scecli.dll
Provides the client-side interfaces to the security configuration engine and provides data to Resultant Set of
Policy (RSoP).
Wsecedit.dll
The Security Settings extension of Local Group Policy Editor. scecli.dll is loaded into wsecedit.dll to support
the Security Settings user interface.
Gpedit.dll
The Local Group Policy Editor MMC snap-in.
Security Settings extension architecture

The Security Settings extension of the Local Group Policy Editor is part of the Security Configuration Manager
tools, as shown in the following diagram.
Security Settings Architecture
The security settings configuration and analysis tools include a security configuration engine, which provides local
computer (non-domain member) and Group Policybased configuration and analysis of security settings policies.
The security configuration engine also supports the creation of security policy files. The primary features of the
security configuration engine are scecli.dll and scesrv.dll.
The following list describes these primary features of the security configuration engine and other Security
Settingsrelated features.
scesrv.dll
This .dll is hosted in services.exe and runs under local system context. scesrv.dll provides core Security
Configuration Manager functionality, such as import, configure, analyze, and policy propagation.
Scesrv.dll performs configuration and analysis of various security-related system parameters by calling
corresponding system APIs, including LSA, SAM, and the registry.
Scesrv.dll exposes APIs such as import, export, configure, and analyze. It checks that the request is made
over LRPC (Windows XP) and fails the call if it is not.
Communication between parts of the Security Settings extension occurs by using the following methods:
Component Object Model (COM) calls
Local Remote Procedure Call (LRPC)
Lightweight Directory Access Protocol (LDAP)
Active Directory Service Interfaces (ADSI)
Server Message Block (SMB)
Win32 APIs
Windows Management Instrumentation (WMI) calls
On domain controllers, scesrv.dll receives notifications of changes made to SAM and the LSA that need to be
synchronized across domain controllers. Scesrv.dll incorporates those changes into the Default Domain
Controller Policy GPO by using in-process scecli.dll template modification APIs. Scesrv.dll also performs
configuration and analysis operations.
Scecli.dll
This is the client-side interface or wrapper to scesrv.dll. scecli.dll is loaded into Wsecedit.dll to support MMC
snap-ins. It is used by Setup to configure default system security and security of files, registry keys, and
services installed by the Setup API .inf files.
The command-line version of the security configuration and analysis user interfaces, secedit.exe, uses
scecli.dll.
Scecli.dll implements the client-side extension for Group Policy.
Scesrv.dll uses scecli.dll to download applicable Group Policy files from SYSVOL in order to apply Group
Policy security settings to the local device.
Scecli.dll logs application of security policy into WMI (RSoP).
Scesrv.dll policy filter uses scecli.dll to update Default Domain Controller Policy GPO when changes are
made to SAM and LSA.
Wsecedit.dll
The Security Settings extension of the Group Policy Object Editor snap-in. You use this tool to configure
security settings in a Group Policy Object for a site, domain, or organizational unit. You can also use Security
Settings to import security templates to a GPO.
Secedit.sdb
This is a permanent system database used for policy propagation including a table of persistent settings for
rollback purposes.
User databases
A user database is any database other than the system database created by administrators for the purposes
of configuration or analysis of security.
.Inf Templates
These are text files that contain declarative security settings. They are loaded into a database before
configuration or analysis. Group Policy security policies are stored in .inf files on the SYSVOL folder of
domain controllers, where they are downloaded (by using file copy) and merged into the system database
during policy propagation.
Security settings policy processes and interactions

For a domain-joined device, where Group Policy is administered, security settings are processed in conjunction
with Group Policy. Not all settings are configurable.
Group Policy processing
When a computer starts and a user logs on, computer policy and user policy are applied according to the following
sequence:
1. The network starts. Remote Procedure Call System Service (RPCSS) and Multiple Universal Naming Convention
Provider (MUP) start.
2. An ordered list of Group Policy Objects is obtained for the device. The list might depend on these factors:
Whether the device is part of a domain and, therefore, subject to Group Policy through Active Directory.
The location of the device in Active Directory.
Whether the list of Group Policy Objects has changed. If the list of Group Policy Objects has not changed,
no processing is done.
3. Computer policy is applied. These are the settings under Computer Configuration from the gathered list.
This is a synchronous process by default and occurs in the following order: local, site, domain, organizational
unit, child organizational unit, and so on. No user interface appears while computer policies are processed.
4. Startup scripts run. This is hidden and synchronous by default; each script must complete or time out before the
next one starts. The default time-out is 600 seconds. You can use several policy settings to modify this behavior.
5. The user presses CTRL+ALT+DEL to log on.
6. After the user is validated, the user profile loads; it is governed by the policy settings that are in effect.
7. An ordered list of Group Policy Objects is obtained for the user. The list might depend on these factors:
Whether the user is part of a domain and, therefore, subject to Group Policy through Active Directory.
Whether loopback policy processing is enabled, and if so, the state (Merge or Replace) of the loopback
policy setting.
The location of the user in Active Directory.
Whether the list of Group Policy Objects has changed. If the list of Group Policy Objects has not changed,
no processing is done.
8. User policy is applied. These are the settings under User Configuration from the gathered list. This is
synchronous by default and in the following order: local, site, domain, organizational unit, child
organizational unit, and so on. No user interface appears while user policies are processed.
9. Logon scripts run. Group Policybased logon scripts are hidden and asynchronous by default. The user object
script runs last.
10. The operating system user interface that is prescribed by Group Policy appears.
Group Policy Objects storage
A Group Policy Object (GPO) is a virtual object that is identified by a Globally Unique Identifier (GUID) and stored at
the domain level. The policy setting information of a GPO is stored in the following two locations:
Group Policy containers in Active Directory.
The Group Policy container is an Active Directory container that contains GPO properties, such as version
information, GPO status, plus a list of other component settings.
Group Policy templates in a domains system volume folder (SYSVOL).
The Group Policy template is a file system folder that includes policy data specified by .admx files, security
settings, script files, and information about applications that are available for installation. The Group Policy
template is located in the SYSVOL folder in the domain\Policies subfolder.
The GROUP_POLICY_OBJECT structure provides information about a GPO in a GPO list, including the version
number of the GPO, a pointer to a string that indicates the Active Directory portion of the GPO, and a pointer to a
string that specifies the path to the file system portion of the GPO.
Group Policy processing order
Group Policy settings are processed in the following order:
1. Local Group Policy Object.
Each device running a Windows operating system beginning with Windows XP has exactly one Group Policy
Object that is stored locally.
2. Site.
Any Group Policy Objects that have been linked to the site are processed next. Processing is synchronous
and in an order that you specify.
3. Domain.
Processing of multiple domain-linked Group Policy Objects is synchronous and in an order you speciy.
4. Organizational units.
Group Policy Objects that are linked to the organizational unit that is highest in the Active Directory
hierarchy are processed first, then Group Policy Objects that are linked to its child organizational unit, and
so on. Finally, the Group Policy Objects that are linked to the organizational unit that contains the user or
device are processed.
At the level of each organizational unit in the Active Directory hierarchy, one, many, or no Group Policy Objects can
be linked. If several Group Policy Objects are linked to an organizational unit, their processing is synchronous and
in an order that you specify.
This order means that the local Group Policy Object is processed first, and Group Policy Objects that are linked to
the organizational unit of which the computer or user is a direct member are processed last, which overwrites the
earlier Group Policy Objects.
This is the default processing order and administrators can specify exceptions to this order. A Group Policy Object
that is linked to a site, domain, or organizational unit (not a local Group Policy Object) can be set to Enforced with
respect to that site, domain, or organizational unit, so that none of its policy settings can be overridden. At any site,
domain, or organizational unit, you can mark Group Policy inheritance selectively as Block Inheritance. Group
Policy Object links that are set to Enforced are always applied, however, and they cannot be blocked.
Security settings policy processing
In the context of Group Policy processing, security settings policy is processed in the following order.
1. During Group Policy processing, the Group Policy engine determines which security settings policies to apply.
2. If security settings policies exist in a GPO, Group Policy invokes the Security Settings client-side extension.
3. The Security Settings extension downloads the policy from the appropriate location such as a specific domain
controller.
4. The Security Settings extension merges all security settings policies according to precedence rules. The
processing is according to the Group Policy processing order of local, site, domain, and organizational unit
(OU), as described earlier in the Group Policy processing order section. If multiple GPOs are in effect for a
given device and there are no conflicting policies, then the policies are cumulative and are merged.
This example uses the Active Directory structure shown in the following figure. A given computer is a
member of OU2, to which the GroupMembershipPolGPO GPO is linked. This computer is also subject to
the UserRightsPolGPO GPO, which is linked to OU1, higher in the hierarchy. In this case, no conflicting
policies exist so the device receives all of the policies contained in both the UserRightsPolGPO and the
GroupMembershipPolGPO GPOs.
Multiple GPOs and Merging of Security Policy
5. The resultant security policies are stored in secedit.sdb, the security settings database. The security engine
gets the security template files and imports them to secedit.sdb.
6. The security settings policies are applied to devices. The following figure illustrates the security settings policy
processing.
Security Settings Policy Processing
Merging of security policies on domain controllers
Password policies, Kerberos, and some security options are only merged from GPOs that are linked at the root
level on the domain. This is done to keep those settings synchronized across all domain controllers in the domain.
The following security options are merged:
Network Security: Force logoff when logon hours expire
Accounts: Administrator account status
Accounts: Guest account status
Accounts: Rename administrator account
Accounts: Rename guest account
Another mechanism exists that allows security policy changes made by administrators by using net accounts to be
merged into the Default Domain Policy GPO. User rights changes that are made by using Local Security Authority
(LSA) APIs are filtered into the Default Domain Controllers Policy GPO.
Special considerations for domain controllers
If an application is installed on a primary domain controller (PDC) with operations master role (also known as
flexible single master operations or FSMO) and the application makes changes to user rights or password policy,
these changes must be communicated to ensure that synchronization across domain controllers occurs. Scesrv.dll
receives a notification of any changes made to the security account manager (SAM) and LSA that need to be
synchronized across domain controllers and then incorporates the changes into the Default Domain Controller
Policy GPO by using scecli.dll template modification APIs.
When security settings are applied
After you have edited the security settings policies, the settings are refreshed on the computers in the
organizational unit linked to your Group Policy Object in the following instances:
When a device is restarted.
Every 90 minutes on a workstation or server and every 5 minutes on a domain controller. This refresh interval is
configurable.
By default, Security policy settings delivered by Group Policy are also applied every 16 hours (960 minutes)
even if a GPO has not changed.
Persistence of security settings policy
Security settings can persist even if a setting is no longer defined in the policy that originally applied it.
Security settings might persist in the following cases:
The setting has not been previously defined for the device.
The setting is for a registry security object.
The settings are for a file system security object.
All settings applied through local policy or through a Group Policy Object are stored in a local database on your
computer. Whenever a security setting is modified, the computer saves the security setting value to the local
database, which retains a history of all the settings that have been applied to the computer. If a policy first defines a
security setting and then no longer defines that setting, then the setting takes on the previous value in the
database. If a previous value does not exist in the database then the setting does not revert to anything and
remains defined as is. This behavior is sometimes referred to as tattooing.
Registry and file security settings will maintain the values applied through Group Policy until that setting is set to
other values.
Permissions required for policy to apply
Both Apply Group Policy and Read permissions are required to have the settings from a Group Policy Object apply
to users or groups, and computers.
Filtering security policy
By default, all GPOs have Read and Apply Group Policy both Allowed for the Authenticated Users group. The
Authenticated Users group includes both users and computers. Security settings policies are computer-based. To
specify which client computers will or will not have a Group Policy Object applied to them, you can deny them
either the Apply Group Policy or Read permission on that Group Policy Object. Changing these permissions allows
you to limit the scope of the GPO to a specific set of computers within a site, domain, or OU.
Note: Do not use security policy filtering on a domain controller as this would prevent security policy from
applying to it.
Migration of GPOs containing security settings
In some situations, you might want to migrate GPOs from one domain environment to another environment. The
two most common scenarios are test-to-production migration, and production-to-production migration. The GPO
copying process has implications for some types of security settings.
Data for a single GPO is stored in multiple locations and in various formats; some data is contained in Active
Directory and other data is stored on the SYSVOL share on the domain controllers. Certain policy data might be
valid in one domain but might be invalid in the domain to which the GPO is being copied. For example, Security
Identifiers (SIDs) stored in security policy settings are often domain-specific. So copying GPOs is not as simple as
taking a folder and copying it from one device to another.
The following security policies can contain security principals and might require some additional work to
successfully move them from one domain to another.
User rights assignment
Restricted groups
Services
File system
Registry
The GPO DACL, if you choose to preserve it during a copy operation
To ensure that data is copied correctly, you can use Group Policy Management Console (GPMC). When migrating a
GPO from one domain to another, GPMC ensures that all relevant data is properly copied. GPMC also offers
migration tables, which can be used to update domain-specific data to new values as part of the migration process.
GPMC hides much of the complexity involved in the migrating GPO operations, and it provides simple and reliable
mechanisms for performing operations such as copy and backup of GPOs.
In this section
TOPIC DESCRIPTION
Administer security policy settings This article discusses different methods to administer security
policy settings on a local device or throughout a small- or
medium-sized organization.
Configure security policy settings Describes steps to configure a security policy setting on the
local device, on a domain-joined device, and on a domain
controller.
Security policy settings reference This reference of security settings provides information about
how to implement and manage security policies, including
setting options and security considerations.
Administer security policy settings
Applies to
Windows 10
This article discusses different methods to administer security policy settings on a local device or throughout a
small- or medium-sized organization.
Security policy settings should be used as part of your overall security implementation to help secure domain
controllers, servers, client devices, and other resources in your organization.
Security settings policies are rules that you can configure on a device, or multiple devices, for the purpose of
protecting resources on a device or network. The Security Settings extension of the Local Group Policy Editor snap-
in (Gpedit.msc) allows you to define security configurations as part of a Group Policy Object (GPO). The GPOs are
linked to Active Directory containers such as sites, domains, and organizational units, and they enable
administrators to manage security settings for multiple computers from any device joined to the domain.
Security settings can control:
User authentication to a network or device.
The resources that users are permitted to access.
Whether to record a users or groups actions in the event log.
Membership in a group.
For info about each setting, including descriptions, default settings, and management and security considerations,
see Security policy settings reference.
To manage security configurations for multiple computers, you can use one of the following options:
Edit specific security settings in a GPO.
Use the Security Templates snap-in to create a security template that contains the security policies you want to
apply, and then import the security template into a Group Policy Object. A security template is a file that
represents a security configuration, and it can be imported to a GPO, or applied to a local device, or it can be
used to analyze security.
Whats changed in how settings are administered?

Over time, new ways to manage security policy settings have been introduced, which include new operating
system features and the addition of new settings. The following table lists different means by which security policy
settings can be administered.
TOOL OR FEATURE DESCRIPTION AND USE
Security Policy snap-in Secpol.msc

MMC snap-in designed to manage only security policy
settings.
TOOL OR FEATURE DESCRIPTION AND USE
Security editor command line tool Secedit.exe

Configures and analyzes system security by comparing
your current configuration to specified security templates.
Security Compliance Manager Tool download

A Solution Accelerator that helps you plan, deploy,
operate, and manage your security baselines for Windows
client and server operating systems, and Microsoft
applications.
Security Configuration Wizard Scw.exe

SCW is a role-based tool available on servers only: You
can use it to create a policy that enables services, firewall
rules, and settings that are required for a selected server
to perform specific roles.
Security Configuration Manager tool This tool set allows you to create, apply, and edit the
security for your local device, organizational unit, or
domain.
Group Policy Gpmc.msc and Gpedit.msc

The Group Policy Management Console uses the Group
Policy Object editor to expose the local Security options,
which can then be incorporated into Group Policy Objects
for distribution throughout the domain. The Local Group
Policy Editor performs similar functions on the local
device.
Software Restriction Policies Gpedit.msc

See Administer Software Restriction Policies. Software Restriction Policies (SRP) is a Group Policy-based
feature that identifies software programs running on
computers in a domain, and it controls the ability of those
programs to run.
AppLocker Gpedit.msc
See Administer AppLocker. Prevents malicious software (malware) and unsupported
applications from affecting computers in your
environment, and it prevents users in your organization
from installing and using unauthorized applications.
Using the Local Security Policy snap-in

The Local Security Policy snap-in (Secpol.msc) restricts the view of local policy objects to the following policies and
features:
Account Policies
Local Policies
Windows Firewall with Advanced Security
Network List Manager Policies
Public Key Policies
Software Restriction Policies
Application Control Policies
IP Security Policies on Local Computer
Advanced Audit Policy Configuration
Policies set locally might be overwritten if the computer is joined to the domain.
The Local Security Policy snap-in is part of the Security Configuration Manager tool set. For info about other tools
in this tool set, see Working with the Security Configuration Manager in this topic.
Using the secedit command-line tool

The secedit command-line tool works with security templates and provides six primary functions:
The Configure parameter helps you resolve security discrepancies between devices by applying the correct
security template to the errant server.
The Analyze parameter compares the servers security configuration with the selected template.
The Import parameter allows you to create a database from an existing template. The Security Configuration
and Analysis tool does this also.
The Export parameter allows you to export the settings from a database into a security settings template.
The Validate parameter allows you to validate the syntax of each or any lines of text that you created or added
to a security template. This ensures that if the template fails to apply syntax, the template will not be the issue.
The Generate Rollback parameter saves the servers current security settings into a security template so it can
be used to restore most of the servers security settings to a known state. The exceptions are that, when applied,
the rollback template will not change access control list entries on files or registry entries that were changed by
the most recently applied template.
Using the Security Compliance Manager

The Security Compliance Manager is a downloadable tool that helps you plan, deploy, operate, and manage your
security baselines for Windows client and server operating systems, and for Microsoft applications. It contains a
complete database of recommended security settings, methods to customize your baselines, and the option to
implement those settings in multiple formatsincluding XLS, GPOs, Desired Configuration Management (DCM)
packs, or Security Content Automation Protocol (SCAP). The Security Compliance Manager is used to export the
baselines to your environment to automate the security baseline deployment and compliance verification process.
To administer security policies by using the Security Compliance Manager
1. Download the most recent version. You can find out more info on the Microsoft Security Guidance blog.
2. Read the relevant security baseline documentation that is included in this tool.
3. Download and import the relevant security baselines. The installation process steps you through baseline
selection.
4. Open the Help and follow instructions how to customize, compare, or merge your security baselines before
deploying those baselines.
Using the Security Configuration Wizard

The Security Configuration Wizard (SCW) guides you through the process of creating, editing, applying, or rolling
back a security policy. A security policy that you create with SCW is an .xml file that, when applied, configures
services, network security, specific registry values, and audit policy. SCW is a role-based tool: You can use it to
create a policy that enables services, firewall rules, and settings that are required for a selected server to perform
specific roles. For example, a server might be a file server, a print server, or a domain controller.
The following are considerations for using SCW:
SCW disables unnecessary services and provides Windows Firewall with Advanced Security support.
Security policies that are created with SCW are not the same as security templates, which are files with an .inf
extension. Security templates contain more security settings than those that can be set with SCW. However, it is
possible to include a security template in an SCW security policy file.
You can deploy security policies that you create with SCW by using Group Policy.
SCW does not install or uninstall the features necessary for the server to perform a role. You can install server
role-specific features through Server Manager.
SCW detects server role dependencies. If you select a server role, it automatically selects dependent server
roles.
All apps that use the IP protocol and ports must be running on the server when you run SCW.
In some cases, you must be connected to the Internet to use the links in the SCW help. > Note The SCW is
available only on Windows Server and only applicable to server installations.
The SCW can be accessed through Server Manager or by running scw.exe. The wizard steps you through server
security configuration to:
Create a security policy that can be applied to any server on your network.
Edit an existing security policy.
Apply an existing security policy.
Roll back the last applied security policy.
The Security Policy Wizard configures services and network security based on the servers role, as well as
configures auditing and registry settings.
For more information about SCW, including procedures, see Security Configuration Wizard.
Working with the Security Configuration Manager

The Security Configuration Manager tool set allows you to create, apply, and edit the security for your local device,
organizational unit, or domain.
For procedures on how to use the Security Configuration Manager, see Security Configuration Manager.
The following table lists the features of the Security Configuration Manager.
SECURITY CONFIGURATION MANAGER TOOLS DESCRIPTION
Security Configuration and Analysis Defines a security policy in a template. These templates
can be applied to Group Policy or to your local computer.
Security templates Defines a security policy in a template. These templates

can be applied to Group Policy or to your local computer.
Security Settings extension to Group Policy Edits individual security settings on a domain, site, or
organizational unit.
Local Security Policy Edits individual security settings on your local computer.
SECURITY CONFIGURATION MANAGER TOOLS DESCRIPTION
Secedit Automates security configuration tasks at a command

prompt.
Security Configuration and Analysis

Security Configuration and Analysis is an MMC snap-in for analyzing and configuring local system security.
Security analysis
The state of the operating system and apps on a device is dynamic. For example, you may need to temporarily
change security levels so that you can immediately resolve an administration or network issue. However, this
change can often go unreversed. This means that a computer may no longer meet the requirements for enterprise
security.
Regular analysis enables you to track and ensure an adequate level of security on each computer as part of an
enterprise risk management program. You can tune the security levels and, most importantly, detect any security
flaws that may occur in the system over time.
Security Configuration and Analysis enables you to quickly review security analysis results. It presents
recommendations alongside of current system settings and uses visual flags or remarks to highlight any areas
where the current settings do not match the proposed level of security. Security Configuration and Analysis also
offers the ability to resolve any discrepancies that analysis reveals.
Security configuration
Security Configuration and Analysis can also be used to directly configure local system security. Through its use of
personal databases, you can import security templates that have been created with Security Templates and apply
these templates to the local computer. This immediately configures the system security with the levels specified in
the template.
Security templates
With the Security Templates snap-in for Microsoft Management Console, you can create a security policy for your
device or for your network. It is a single point of entry where the full range of system security can be taken into
account. The Security Templates snap-in does not introduce new security parameters, it simply organizes all
existing security attributes into one place to ease security administration.
Importing a security template to a Group Policy Object eases domain administration by configuring security for a
domain or organizational unit at once.
To apply a security template to your local device, you can use Security Configuration and Analysis or the secedit
command-line tool.
Security templates can be used to define:
Account Policies
Password Policy
Account Lockout Policy
Kerberos Policy
Local Policies
Audit Policy
User Rights Assignment
Security Options
Event Log: Application, system, and security Event Log settings
Restricted Groups: Membership of security-sensitive groups
System Services: Startup and permissions for system services
Registry: Permissions for registry keys
File System: Permissions for folders and files
Each template is saved as a text-based .inf file. This enables you to copy, paste, import, or export some or all of the
template attributes. With the exceptions of Internet Protocol security and public key policies, all security attributes
can be contained in a security template.
Security settings extension to Group Policy
Organizational units, domains, and sites are linked to Group Policy Objects. The security settings tool allows you
change the security configuration of the Group Policy Object, in turn, affecting multiple computers. With security
settings, you can modify the security settings of many devices, depending on the Group Policy Object you modify,
from just one device joined to a domain.
Security settings or security policies are rules that are configured on a device or multiple device for protecting
resources on a device or network. Security settings can control:
How users are authenticated to a network or device
What resources users are authorized to use.
Whether or not a user's or group's actions are recorded in the event log.
Group membership.
You can change the security configuration on multiple computers in two ways:
Create a security policy by using a security template with Security Templates, and then import the template
through security settings to a Group Policy Object.
Change a few select settings with security settings.
Local Security Policy
A security policy is a combination of security settings that affect the security on a device. You can use your local
security policy to edit account policies and local policies on your local device
With the local security policy, you can control:
Who accesses your device.
What resources users are authorized to use on your device.
Whether or not a users or group's actions are recorded in the event log.
If your local device is joined to a domain, you are subject to obtaining a security policy from the domain's policy or
from the policy of any organizational unit that you are a member of. If you are getting a policy from more than one
source, conflicts are resolved in the following order of precedence.
1. Organizational unit policy
2. Domain policy
3. Site policy
4. Local computer policy
If you modify the security settings on your local device by using the local security policy, then you are directly
modifying the settings on your device. Therefore, the settings take effect immediately, but this may only be
temporary. The settings will actually remain in effect on your local device until the next refresh of Group Policy
security settings, when the security settings that are received from Group Policy will override your local settings
wherever there are conflicts.
Using the Security Configuration Manager
For procedures on how to use the Security Configuration Manager, see Security Configuration Manager How To.
This section contains information in this topic about:
Applying security settings
Importing and exporting security templates
Analyzing security and viewing results
Resolving security discrepancies
Automating security configuration tasks
Applying security settings
Once you have edited the security settings, the settings are refreshed on the computers in the organizational unit
linked to your Group Policy Object:
When a device is restarted, the settings on that device will be refreshed.
To force a device to refresh its security settings as well as all Group Policy settings, use gpupdate.exe.
Precedence of a policy when more than one policy is applied to a computer
For security settings that are defined by more than one policy, the following order of precedence is observed:
1. Organizational Unit Policy
2. Domain Policy
3. Site Policy
4. Local computer Policy
For example, a workstation that is joined to a domain will have its local security settings overridden by the domain
policy wherever there is a conflict. Likewise, if the same workstation is a member of an Organizational Unit, the
settings applied from the Organizational Unit's policy will override both the domain and local settings. If the
workstation is a member of more than one Organizational Unit, then the Organizational Unit that immediately
contains the workstation has the highest order of precedence.
Note Use gpresult.exe to find out what policies are applied to a device and in what order. For domain accounts,
there can be only one account policy that includes password policies, account lockout policies, and Kerberos
policies.
Persistence in security settings

Security settings may still persist even if a setting is no longer defined in the policy that originally applied it.
Persistence in security settings occurs when:
The setting has not been previously defined for the device.
The setting is for a registry object.
The setting is for a file system object.
All settings applied through local policy or a Group Policy Object are stored in a local database on your device.
Whenever a security setting is modified, the computer saves the security setting value to the local database, which
retains a history of all the settings that have been applied to the device. If a policy first defines a security setting
and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous
value does not exist in the database, then the setting does not revert to anything and remains defined as is. This
behavior is sometimes called "tattooing."
Registry and file settings will maintain the values applied through policy until that setting is set to other values.
Filtering security settings based on group membership
You can also decide what users or groups will or will not have a Group Policy Object applied to them regardless of
what computer they have logged onto by denying them either the Apply Group Policy or Read permission on that
Group Policy Object. Both of these permissions are needed to apply Group Policy.
Importing and exporting security templates
Security Configuration and Analysis provides the ability to import and export security templates into or from a
database.
If you have made any changes to the analysis database, you can save those settings by exporting them into a
template. The export feature provides the ability to save the analysis database settings as a new template file. This
template file can then be used to analyze or configure a system, or it can be imported to a Group Policy Object.
Analyzing security and viewing results
Security Configuration and Analysis performs security analysis by comparing the current state of system security
against an analysis database. During creation, the analysis database uses at least one security template. If you
choose to import more than one security template, the database will merge the various templates and create one
composite template. It resolves conflicts in order of import; the last template that is imported takes precedence.
Security Configuration and Analysis displays the analysis results by security area, using visual flags to indicate
problems. It displays the current system and base configuration settings for each security attribute in the security
areas. To change the analysis database settings, right-click the entry, and then click Properties.
VISUAL FLAG MEANING
Red X The entry is defined in the analysis database and on the

system, but the security setting values do not match.
Green check mark The entry is defined in the analysis database and on the
system and the setting values match.
Question mark The entry is not defined in the analysis database and,
therefore, was not analyzed.
If an entry is not analyzed, it may be that it was not
defined in the analysis database or that the user who is
running the analysis may not have sufficient permission to
perform analysis on a specific object or area.
Exclamation point This item is defined in the analysis database, but does not
exist on the actual system. For example, there may be a
restricted group that is defined in the analysis database
but does not actually exist on the analyzed system.
No highlight The item is not defined in the analysis database or on the

system.
If you choose to accept the current settings, the corresponding value in the base configuration is modified to match
them. If you change the system setting to match the base configuration, the change will be reflected when you
configure the system with Security Configuration and Analysis.
To avoid continued flagging of settings that you have investigated and determined to be reasonable, you can
modify the base configuration. The changes are made to a copy of the template.
Resolving security discrepancies
You can resolve discrepancies between analysis database and system settings by:
Accepting or changing some or all of the values that are flagged or not included in the configuration, if you
determine that the local system security levels are valid due to the context (or role) of that computer. These
attribute values are then updated in the database and applied to the system when you click Configure
Computer Now.
Configuring the system to the analysis database values, if you determine the system is not in compliance with
valid security levels.
Importing a more appropriate template for the role of that computer into the database as the new base
configuration and applying it to the system. Changes to the analysis database are made to the stored template
in the database, not to the security template file. The security template file will only be modified if you either
return to Security Templates and edit that template or export the stored configuration to the same template file.
You should use Configure Computer Now only to modify security areas not affected by Group Policy settings,
such as security on local files and folders, registry keys, and system services. Otherwise, when the Group Policy
settings are applied, it will take precedence over local settingssuch as account policies. In general, do not use
Configure Computer Now when you are analyzing security for domain-based clients, since you will have to
configure each client individually. In this case, you should return to Security Templates, modify the template,
and reapply it to the appropriate Group Policy Object.
Automating security configuration tasks
By calling the secedit.exe tool at a command prompt from a batch file or automatic task scheduler, you can use it to
automatically create and apply templates, and analyze system security. You can also run it dynamically from a
command prompt. Secedit.exe is useful when you have multiple devices on which security must be analyzed or
configured, and you need to perform these tasks during off-hours.
Working with Group Policy tools

Group Policy is an infrastructure that allows you to specify managed configurations for users and computers
through Group Policy settings and Group Policy Preferences. For Group Policy settings that affect only a local
device or user, you can use the Local Group Policy Editor. You can manage Group Policy settings and Group Policy
Preferences in an Active Directory Domain Services (AD DS) environment through the Group Policy Management
Console (GPMC). Group Policy management tools also are included in the Remote Server Administration Tools
pack to provide a way for you to administer Group Policy settings from your desktop.
Network List Manager policies
Applies to
Windows 10
Network List Manager policies are security settings that you can use to configure different aspects of how networks
are listed and displayed on one device or on many devices.
To configure Network List Manager Policies for one device, you can use the Microsoft Management Console (MMC)
with the Group Policy Object Editor snap-in, and edit the local computer policy. The Network List Manager Policies
are located at the following path in Group Policy Object Editor: Computer Configuration | Windows Settings |
Security Settings | Network List Manager Policies
To configure Network List Manager Policies for many computers, such as for all of the Domain Computers in an
Active Directory domain, follow Group Policy documentation to learn how to edit the policies for the object that you
require. The path to the Network List Manager Policies is the same as the path listed above.
Policy settings for Network List Manager Policies
The following policy settings are provided for Network List Manager Policies. These policy settings are located in
the details pane of the Group Policy Object Editor, in Network Name.
Unidentified Networks
This policy setting allows you to configure the Network Location, including the location type and the user
permissions, for networks that Windows cannot identify due to a network issue or a lack of identifiable characters in
the network information received by the operating system from the network. A network location identifies the type
of network that a computer is connected to and automatically sets the appropriate firewall settings for that location.
You can configure the following items for this policy setting:
Location type. For this item, the following options are available:
Not configured. If you select this option, this policy setting does not apply a location type to unidentified
network connections.
Private. If you select this option, this policy setting applies a location type of Private to unidentified
network connections. A private network, such as a home or work network, is a location type that
assumes that you trust the other computers on the network. Do not select this item if there is a
possibility that an active, unidentified network is in a public place.
Public. If you select this option, this policy setting applies a location type of Public to unidentified
network connections. A public network, such as a wireless network at an airport or coffee shop, is a
location type that assumes that you do not trust the other computers on the network.
User permissions. For this item, the following options are available:
Not configured. If you select this option, this policy setting does not specify whether users can change
the location for unidentified network connections.
User can change location. If you select this option, this policy setting allows users to change an
unidentified network connection location from Private to Public or from Public to Private.
User cannot change location. If you select this option, this policy setting does not allow users to
change the location of an unidentified network connection.
Identifying Networks
This policy setting allows you to configure the Network Location for networks that are in a temporary state while
Windows works to identify the network and location type. A network location identifies the type of network that a
computer is connected to and automatically sets the appropriate firewall settings for that location. You can
configure the following items for this policy setting:
Location type. For this item, the following options are available:
Not configured. If you select this option, this policy setting does not apply a location type to network
connections that are in the process of being identified by Windows.
Private. If you select this option, this policy setting applies a location type of Private to network
connections that are in the process of being identified. A private network, such as a home or work
network, is a location type that assumes that you trust the other devices on the network. Do not select this
item if there is a possibility that an active, unidentified network is in a public place.
Public. If you select this option, this policy setting applies a location type of Public to network
connections that are in the process of being identified by Windows. A public network, such as a wireless
network at an airport or coffee shop, is a location type that assumes that you do not trust the other
devices on the network.
All Networks
This policy setting allows you to specify the User Permissions that control whether users can change the network
name, location, or icon, for all networks to which the user connects. You can configure the following items for this
policy setting:
Network name. For this item, the following options are available:
the network name for all network connections.
User can change name. If you select this option, users can change the network name for all networks to
which they connect.
User cannot change name. If you select this option, users cannot change the network name for any
networks to which they connect.
Network location. For this item, the following options are available:
the location for all network connections.
User can change location. If you select this option, this policy setting allows users to change all network
locations from Private to Public or from Public to Private.
User cannot change location. If you select this option, this policy setting does not allow users to
change the location for any networks to which they connect.
Network icon. For this item, the following options are available:
the network icon for all network connections.
User can change icon. If you select this option, this policy setting allows users to change the network
icon for all networks to which the user connects.
User cannot change icon. If you select this option, this policy setting does not allow users to change the
network icon for any networks to which the user connects.
Applies to
Windows 10
Describes steps to configure a security policy setting on the local device, on a domain-joined device, and on a
domain controller.
You must have Administrators rights on the local device, or you must have the appropriate permissions to update
a Group Policy Object (GPO) on the domain controller to perform these procedures.
When a local setting is inaccessible, it indicates that a GPO currently controls that setting.
To configure a setting using the Local Security Policy console

1. To open Local Security Policy, on the Start screen, type secpol.msc, and then press ENTER.
2. Under Security Settings of the console tree, do one of the following:
Click Account Policies to edit the Password Policy or Account Lockout Policy.
Click Local Policies to edit an Audit Policy, a User Rights Assignment, or Security Options.
3. When you find the policy setting in the details pane, double-click the security policy that you want to
modify.
4. Modify the security policy setting, and then click OK.
NOTE
Some security policy settings require that the device be restarted before the setting takes effect.
Any change to the user rights assignment for an account becomes effective the next time the owner of the
account logs on.
To configure a security policy setting using the Local Group Policy

Editor console
You must have the appropriate permissions to install and use the Microsoft Management Console (MMC), and to
update a Group Policy Object (GPO) on the domain controller to perform these procedures.
1. Open the Local Group Policy Editor (gpedit.msc).
2. In the console tree, click Computer Configuration, click Windows Settings, and then click Security
Settings.
Click Account Policies to edit the Password Policy or Account Lockout Policy.
Click Local Policies to edit an Audit Policy, a User Rights Assignment, or Security Options.
4. In the details pane, double-click the security policy setting that you want to modify.
NOTE
If this security policy has not yet been defined, select the Define these policy settings check box.
NOTE
If you want to configure security settings for many devices on your network, you can use the Group Policy Management
Console.
To configure a setting for a domain controller

The following procedure describes how to configure a security policy setting for only a domain controller (from
the domain controller).
1. To open the domain controller security policy, in the console tree, locate GroupPolicyObject [ComputerName]
Policy, click Computer Configuration, click Windows Settings, and then click Security Settings.
Double-click Account Policies to edit the Password Policy, Account Lockout Policy, or Kerberos
Policy.
Click Local Policies to edit the Audit Policy, a User Rights Assignment, or Security Options.
3. In the details pane, double-click the security policy that you want to modify.
NOTE
If this security policy has not yet been defined, select the Define these policy settings check box.
IMPORTANT
Always test a newly created policy in a test organizational unit before you apply it to your network.
When you change a security setting through a GPO and click OK, that setting will take effect the next time you refresh
the settings.
Related topics
Applies to
Windows 10
This reference of security settings provides information about how to implement and manage security policies,
including setting options and security considerations.
This reference focuses on those settings that are considered security settings. This reference examines only the
settings and features in the Windows operating systems that can help organizations secure their enterprises
against malicious software threats. Management features and those security features that you cannot configure
are not described in this reference.
Each policy setting described contains referential content such as a detailed explanation of the settings, best
practices, default settings, differences between operating system versions, policy management considerations, and
security considerations that include a discussion of vulnerability, countermeasures, and potential impact of those
countermeasures.
In this section
TOPIC DESCRIPTION
Account Policies An overview of account policies in Windows and provides links

to policy descriptions.
Audit Policy Provides information about basic audit policies that are
available in Windows and links to information about each
setting.
Security Options Provides an introduction to the settings under Security

Options of the local security policies and links to information
about each setting.
Advanced security audit policy settings Provides information about the advanced security audit policy
settings that are available in Windows and the audit events
that they generate.
User Rights Assignment Provides an overview and links to information about the User
Rights Assignment security policy settings user rights that are
available in Windows.
Account Policies
Applies to
Windows 10
An overview of account policies in Windows and provides links to policy descriptions.
All account policies settings applied by using Group Policy are applied at the domain level. Default values are
present in the built-in default domain controller policy for Password Policy settings, Account Lockout Policy
settings, and Kerberos Policy settings. The domain account policy becomes the default local account policy of any
device that is a member of the domain. If these policies are set at any level below the domain level in Active
Directory Domain Services (AD DS), they affect only local accounts on member servers.
Note: Each domain can have only one account policy. The account policy must be defined in the default domain
policy or in a new policy that is linked to the root of the domain and given precedence over the default domain
policy, which is enforced by the domain controllers in the domain. These domain-wide account policy settings
(Password Policy, Account Lockout Policy, and Kerberos Policy) are enforced by the domain controllers in the
domain; therefore, domain controllers always retrieve the values of these account policy settings from the
default domain policy Group Policy Object (GPO).
The only exception is when another account policy is defined for an organizational unit (OU). The account policy
settings for the OU affect the local policy on any computers that are contained in the OU. For example, if an OU
policy defines a maximum password age that differs from the domain-level account policy, the OU policy will be
applied and enforced only when users log on to the local computer. The default local computer policies apply only
to computers that are in a workgroup or in a domain where neither an OU account policy nor a domain policy
applies.
In this section
TOPIC DESCRIPTION
Password Policy An overview of password policies for Windows and links to

information for each policy setting.
Account Lockout Policy Describes the Account Lockout Policy settings and links to
information about each policy setting.
Kerberos Policy Describes the Kerberos Policy settings and provides links to
policy setting descriptions.
Related topics
Password Policy
Applies to
Windows 10
An overview of password policies for Windows and links to information for each policy setting.
In many operating systems, the most common method to authenticate a user's identity is to use a secret
passphrase or password. A secure network environment requires all users to use strong passwords, which have at
least eight characters and include a combination of letters, numbers, and symbols. These passwords help prevent
the compromise of user accounts and administrative accounts by unauthorized users who use manual methods or
automated tools to guess weak passwords. Strong passwords that are changed regularly reduce the likelihood of a
successful password attack.
Introduced in Windows Server 2008 R2 and Windows Server 2008, Windows supports fine-grained password
policies. This feature provides organizations with a way to define different password and account lockout policies
for different sets of users in a domain. Fine-grained password policies apply only to user objects (or inetOrgPerson
objects if they are used instead of user objects) and global security groups.
To apply a fine-grained password policy to users of an OU, you can use a shadow group. A shadow group is a
global security group that is logically mapped to an OU to enforce a fine-grained password policy. You add users
of the OU as members of the newly created shadow group and then apply the fine-grained password policy to this
shadow group. You can create additional shadow groups for other OUs as needed. If you move a user from one
OU to another, you must update the membership of the corresponding shadow groups.
Fine-grained password policies include attributes for all the settings that can be defined in the default domain
policy (except Kerberos settings) in addition to account lockout settings. When you specify a fine-grained
password policy, you must specify all of these settings. By default, only members of the Domain Admins group can
set fine-grained password policies. However, you can also delegate the ability to set these policies to other users.
The domain must be running at least Windows Server 2008 R2 or Windows Server 2008 to use fine-grained
password policies. Fine-grained password policies cannot be applied to an organizational unit (OU) directly.
You can enforce the use of strong passwords through an appropriate password policy. There are password policy
settings that control the complexity and lifetime of passwords, such as the Passwords must meet complexity
requirements policy setting.
You can configure the password policy settings in the following location by using the Group Policy Management
Console:
Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy
If individual groups require distinct password policies, these groups should be separated into another domain or
forest, based on additional requirements.
The following topics provide a discussion of password policy implementation and best practices considerations,
policy location, default values for the server type or GPO, relevant differences in operating system versions,
security considerations (including the possible vulnerabilities of each setting), countermeasures that you can take,
and the potential impact for each setting.
In this section
TOPIC DESCRIPTION
Enforce password history Describes the best practices, location, values, policy
management, and security considerations for the Enforce
password history security policy setting.
Maximum password age Describes the best practices, location, values, policy
management, and security considerations for the Maximum
password age security policy setting.
Minimum password age Describes the best practices, location, values, policy
management, and security considerations for the Minimum
Minimum password length Describes the best practices, location, values, policy
management, and security considerations for the Minimum
password length security policy setting.
Password must meet complexity requirements Describes the best practices, location, values, and security
considerations for the Password must meet complexity
requirements security policy setting.
Store passwords using reversible encryption Describes the best practices, location, values, and security
considerations for the Store passwords using reversible
encryption security policy setting.
Related topics
Enforce password history
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Enforce
password history security policy setting.
Reference
The Enforce password history policy setting determines the number of unique new passwords that must be
associated with a user account before an old password can be reused. Password reuse is an important concern in
any organization. Many users want to reuse the same password for their account over a long period of time. The
longer the same password is used for a particular account, the greater the chance that an attacker will be able to
determine the password through brute force attacks. If users are required to change their password, but they can
reuse an old password, the effectiveness of a good password policy is greatly reduced.
Specifying a low number for Enforce password history allows users to continually use the same small number of
passwords repeatedly. If you do not also set Minimum password age, users can change their password as many
times in a row as necessary to reuse their original password.
Possible values
User-specified number from 0 through 24
Not defined
Best practices
Set Enforce password history to 24. This will help mitigate vulnerabilities that are caused by password reuse.
Set Maximum password age to expire passwords between 60 and 90 days. Try to expire the passwords between
major business cycles to prevent work loss.
Configure Minimum password age so that you do not allow passwords to be changed immediately.
Location
Default values
The following table lists the actual and effective default policy values. Default values are also listed on the policys
property page.
SERVER TYPE OR GPO DEFAULT VALUE
Default domain policy 24 passwords remembered
Default domain controller policy Not defined
Stand-alone server default settings 0 passwords remembered
Domain controller effective default settings 24 passwords remembered

Member server effective default settings 24 passwords remembered
Effective GPO default settings on client computers 24 passwords remembered
Policy management
This section describes features, tools, and guidance to help you manage this policy.
Restart requirement
None. Changes to this policy become effective without a device restart when they are saved locally or distributed
This section describes how an attacker might exploit a feature or its configuration, how to implement the
countermeasure, and the possible negative consequences of countermeasure implementation.
Vulnerability
The longer a user uses the same password, the greater the chance that an attacker can determine the password
through brute force attacks. Also, any accounts that may have been compromised remain exploitable for as long as
the password is left unchanged. If password changes are required but password reuse is not prevented, or if users
continually reuse a small number of passwords, the effectiveness of a good password policy is greatly reduced.
If you specify a low number for this policy setting, users can use the same small number of passwords repeatedly. If
you do not also configure the Minimum password age policy setting, users might repeatedly change their
passwords until they can reuse their original password.
Note: After an account has been compromised, a simple password reset might not be enough to restrict a
malicious user because the malicious user might have modified the user's environment so that the password is
changed back to a known value automatically at a certain time. If an account has been compromised, it is best
to delete the account and assign the user a new account after all affected systems have been restored to normal
operations and verified that they are no longer compromised.
Countermeasure
Configure the Enforce password history policy setting to 24 (the maximum setting) to help minimize the number
of vulnerabilities that are caused by password reuse.
For this policy setting to be effective, you should also configure effective values for the Minimum password age
and Maximum password age policy settings.
Potential impact
The major impact of configuring the Enforce password history setting to 24 is that users must create a new
password every time they are required to change their old one. If users are required to change their passwords to
new unique values, there is an increased risk of users who write their passwords somewhere so that they do not
forget them. Another risk is that users may create passwords that change incrementally (for example, password01,
password02, and so on) to facilitate memorization, but this makes them easier for an attacker to guess. Also, an
excessively low value for the Maximum password age policy setting is likely to increase administrative overhead
because users who forget their passwords might ask the Help Desk to reset them frequently.
Related topics
Password Policy
Maximum password age
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Maximum
Reference
The Maximum password age policy setting determines the period of time (in days) that a password can be used
before the system requires the user to change it. You can set passwords to expire after a number of days between
1 and 999, or you can specify that passwords never expire by setting the number of days to 0. If Maximum
password age is between 1 and 999 days, the minimum password age must be less than the maximum password
age. If Maximum password age is set to 0, Minimum password age can be any value between 0 and 998 days.
Note: Setting Maximum password age to -1 is equivalent to 0, which means it never expires. Setting it to
any other negative number is equivalent to setting it to Not Defined.
Possible values
User-specified number of days between 0 and 999
Not defined
Best practices
Set Maximum password age to a value between 30 and 90 days, depending on your environment. This way, an
attacker has a limited amount of time in which to compromise a user's password and have access to your network
resources.
Location
Default values
property page.
SERVER TYPE OR GROUP POLICY OBJECT (GPO) DEFAULT VALUE
Default domain policy 42 days
Stand-alone server default settings 42 days
Domain controller effective default settings 42 days
Member server effective default settings 42 days
Effective GPO default settings on client computers 42 days

Policy management
Restart requirement
None. Changes to this policy become effective without a computer restart when they are saved locally or
distributed through Group Policy.
Vulnerability
The longer a password exists, the higher the likelihood that it will be compromised by a brute force attack, by an
attacker gaining general knowledge about the user, or by the user sharing the password. Configuring the
Maximum password age policy setting to 0 so that users are never required to change their passwords is a
major security risk because that allows a compromised password to be used by the malicious user for as long as
the valid user is authorized access.
Countermeasure
Configure the Maximum password age policy setting to a value that is suitable for your organization's business
requirements.
Potential impact
If the Maximum password age policy setting is too low, users are required to change their passwords very often.
Such a configuration can reduce security in the organization because users might keep their passwords in an
unsecured location or lose them. If the value for this policy setting is too high, the level of security within an
organization is reduced because it allows potential attackers more time in which to discover user passwords or to
use compromised accounts.
Related topics
Password Policy
Minimum password age
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Minimum
Reference
The Minimum password age policy setting determines the period of time (in days) that a password can be used
before the system requires the user to change it. You can set passwords to expire after a number of days between
1 and 999, or you can specify that passwords never expire by setting the number of days to 0. If Maximum
password age is between 1 and 999 days, the minimum password age must be less than the maximum password
age. If Maximum password age is set to 0, Minimum password age can be any value between 0 and 998 days.
Possible values
User-specified number of days between 0 and 998
Not defined
Best practices
Set Minimum password age to a value of 2 days. Setting the number of days to 0 allows immediate password
changes, which is not recommended.
If you set a password for a user and you want that user to change the administrator-defined password, you must
select the User must change password at next logon check box. Otherwise, the user will not be able to change
the password until the number of days specified by Minimum password age.
Location
Default values
property page.
Default domain policy 1 day
Stand-alone server default settings 0 days
Domain controller effective default settings 1 day
Member server effective default settings 1 day
Effective GPO default settings on client computers 1 day

Policy management
Restart requirement
Vulnerability
Users may have favorite passwords that they like to use because they are easy to remember and they believe that
their password choice is secure from compromise. Unfortunately, passwords can be compromised and if an
attacker is targeting a specific individual user account, with knowledge of data about that user, reuse of old
passwords can cause a security breach.
To address password reuse, you must use a combination of security settings. Using this policy setting with the
Enforce password history policy setting prevents the easy reuse of old passwords. For example, if you configure
the Enforce password history policy setting to ensure that users cannot reuse any of their last 12 passwords, but
you do not configure the Minimum password age policy setting to a number that is greater than 0, users could
change their password 13 times in a few minutes and reuse their original password. You must configure this
policy setting to a number that is greater than 0 for the Enforce password history policy setting to be effective.
Countermeasure
Configure the Minimum password age policy setting to a value of at least 2 days. Users should know about this
limitation and contact the Help Desk if they need to change their password during that two-day period. If you
configure the number of days to 0, immediate password changes would be allowed, which we do not recommend.
Potential impact
If you set a password for a user but wants that user to change the password when the user first logs on, the
administrator must select the User must change password at next logon check box, or the user cannot change
the password until the next day.
Related topics
Password Policy
Minimum password length
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Minimum
password length security policy setting.
Reference
The Minimum password length policy setting determines the least number of characters that can make up a
password for a user account. You can set a value of between 1 and 14 characters, or you can establish that no
password is required by setting the number of characters to 0.
Possible values
User-specified number of characters between 0 and 14
Not defined
Best practices
Set Minimum password length to at least a value of 8. If the number of characters is set to 0, no password is
required. In most environments, an eight-character password is recommended because it is long enough to
provide adequate security and still short enough for users to easily remember. This value will help provide
adequate defense against a brute force attack. Adding complexity requirements will help reduce the possibility of a
dictionary attack. For more info, see Password must meet complexity requirements.
Permitting short passwords reduces security because short passwords can be easily broken with tools that perform
dictionary or brute force attacks against the passwords. Requiring very long passwords can result in mistyped
passwords that might cause an account lockout and subsequently increase the volume of Help Desk calls.
In addition, requiring extremely long passwords can actually decrease the security of an organization because users
might be more likely to write down their passwords to avoid forgetting them. However, if users are taught that they
can use passphrases (sentences such as "I want to drink a $5 milkshake"), they should be much more likely to
remember.
Location
Default values
property page.
Default domain policy 7 characters
Stand-alone server default settings 0 characters

Domain controller effective default settings 7 characters
Member server effective default settings 7 characters
Effective GPO default settings on client computers 0 characters
Policy management
Restart requirement
Vulnerability
Types of password attacks include dictionary attacks (which attempt to use common words and phrases) and brute
force attacks (which try every possible combination of characters). Also, attackers sometimes try to obtain the
account database so they can use tools to discover the accounts and passwords.
Countermeasure
Configure the **** policy setting to a value of 8 or more. If the number of characters is set to 0, no password will be
required.
In most environments, we recommend an eight-character password because it is long enough to provide adequate
security, but not too difficult for users to easily remember. This configuration provides adequate defense against a
brute force attack. Using the Password must meet complexity requirements policy setting in addition to the
Minimum password length setting helps reduce the possibility of a dictionary attack.
Note: Some jurisdictions have established legal requirements for password length as part of establishing
security regulations.
Potential impact
Requirements for extremely long passwords can actually decrease the security of an organization because users
might leave the information in an unsecured location or lose it. If very long passwords are required, mistyped
passwords could cause account lockouts and increase the volume of Help Desk calls. If your organization has issues
with forgotten passwords due to password length requirements, consider teaching your users about passphrases,
which are often easier to remember and, due to the larger number of character combinations, much harder to
discover.
Related topics
Password Policy
Password must meet complexity requirements
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Password must meet
complexity requirements security policy setting.
Reference
The Passwords must meet complexity requirements policy setting determines whether passwords must meet
a series of guidelines that are considered important for a strong password. Enabling this policy setting requires
passwords to meet the following requirements:
1. Passwords may not contain the user's samAccountName (Account Name) value or entire displayName (Full
Name value). Both checks are not case sensitive.
The samAccountName is checked in its entirety only to determine whether it is part of the password. If the
samAccountName is less than three characters long, this check is skipped. The displayName is parsed for
delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs. If any of these
delimiters are found, the displayName is split and all parsed sections (tokens) are confirmed to not be
included in the password. Tokens that are less than three characters are ignored, and substrings of the
tokens are not checked. For example, the name "Erin M. Hagens" is split into three tokens: "Erin", "M", and
"Hagens". Because the second token is only one character long, it is ignored. Therefore, this user could not
have a password that included either "erin" or "hagens" as a substring anywhere in the password.
2. The password contains characters from three of the following categories:
Uppercase letters of European languages (A through Z, with diacritic marks, Greek and Cyrillic
characters)
Lowercase letters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic
characters)
Base 10 digits (0 through 9)
Non-alphanumeric characters (special characters) (for example, !, $, #, %)
Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase.
This includes Unicode characters from Asian languages.
Complexity requirements are enforced when passwords are changed or created.
The rules that are included in the Windows Server password complexity requirements are part of Passfilt.dll, and
they cannot be directly modified.
Enabling the default Passfilt.dll may cause some additional Help Desk calls for locked-out accounts because users
might not be used to having passwords that contain characters other than those found in the alphabet. However,
this policy setting is liberal enough that all users should be able to abide by the requirements with a minor
learning curve.
Additional settings that can be included in a custom Passfilt.dll are the use of nonupper-row characters. Upper-
row characters are those that are typed by holding down the SHIFT key and typing any of the digits from 1 through
10.
Possible values
Enabled
Disabled
Not defined
Best practices
Set Passwords must meet complexity requirements to Enabled. This policy setting, combined with a minimum
password length of 8, ensures that there are at least 218,340,105,584,896 different possibilities for a single
password. This makes a brute force attack difficult, but still not impossible.
The use of ALT key character combinations can greatly enhance the complexity of a password. However, requiring
all users in an organization to adhere to such stringent password requirements can result in unhappy users and an
extremely busy Help Desk. Consider implementing a requirement in your organization to use ALT characters in the
range from 0128 through 0159 as part of all administrator passwords. (ALT characters outside of this range can
represent standard alphanumeric characters that do not add additional complexity to the password.)
Passwords that contain only alphanumeric characters are easy to compromise by using publicly available tools. To
prevent this, passwords should contain additional characters and meet complexity requirements.
Location
Default values
property page.
Default domain policy Enabled
Default domain controller policy Enabled
Stand-alone server default settings Disabled
Domain controller effective default settings Enabled
Member server effective default settings Enabled
Effective GPO default settings on client computers Disabled
Vulnerability
Passwords that contain only alphanumeric characters are extremely easy to discover with several publicly available
tools.
Countermeasure
Configure the Passwords must meet complexity requirements policy setting to Enabled and advise users to
use a variety of characters in their passwords.
When combined with a Minimum password length of 8, this policy setting ensures that the number of different
possibilities for a single password is so great that it is difficult (but not impossible) for a brute force attack to
succeed. (If the Minimum password length policy setting is increased, the average amount of time necessary for a
successful attack also increases.)
Potential impact
If the default password complexity configuration is retained, additional Help Desk calls for locked-out accounts
could occur because users might not be accustomed to passwords that contain non-alphabetical characters, or
they might have problems entering passwords that contain accented characters or symbols on keyboards with
different layouts. However, all users should be able to comply with the complexity requirement with minimal
difficulty.
If your organization has more stringent security requirements, you can create a custom version of the Passfilt.dll
file that allows the use of arbitrarily complex password strength rules. For example, a custom password filter might
require the use of non-upper-row symbols. (Upper-row symbols are those that require you to press and hold the
SHIFT key and then press any of the digits between 1 and 0.) A custom password filter might also perform a
dictionary check to verify that the proposed password does not contain common dictionary words or fragments.
The use of ALT key character combinations can greatly enhance the complexity of a password. However, such
stringent password requirements can result in additional Help Desk requests. Alternatively, your organization
could consider a requirement for all administrator passwords to use ALT characters in the 01280159 range. (ALT
characters outside of this range can represent standard alphanumeric characters that would not add additional
complexity to the password.)
Related topics
Password Policy
Store passwords using reversible encryption
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Store passwords using
reversible encryption security policy setting.
Reference
The Store password using reversible encryption policy setting provides support for applications that use
protocols that require the user's password for authentication. Storing encrypted passwords in a way that is
reversible means that the encrypted passwords can be decrypted. A knowledgeable attacker who is able to break
this encryption can then log on to network resources by using the compromised account. For this reason, never
enable Store password using reversible encryption for all users in the domain unless application requirements
outweigh the need to protect password information.
If you use the Challenge Handshake Authentication Protocol (CHAP) through remote access or Internet
Authentication Services (IAS), you must enable this policy setting. CHAP is an authentication protocol that is used
by remote access and network connections. Digest Authentication in Internet Information Services (IIS) also
requires that you enable this policy setting.
Possible values
Enabled
Disabled
Not defined
Best practices
Set the value for Store password using reversible encryption to Disabled. If you use CHAP through remote
access or IAS, or Digest Authentication in IIS, you must set this value to Enabled. This presents a security risk when
you apply the setting by using Group Policy on a user-by-user basis because it requires opening the appropriate
user account object in Active Directory Users and Computers.
Note: Do not enable this policy setting unless business requirements outweigh the need to protect password
information.
Location
Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\
Default values
property page.
Default domain policy Disabled
Default domain controller policy Disabled

Domain controller effective default settings Disabled
Member server effective default settings Disabled
Vulnerability
Enabling this policy setting allows the operating system to store passwords in a format that can weaken your
overall security.
Countermeasure
Disable the Store password using reversible encryption policy setting.
Potential impact
If your organization uses CHAP through remote access or IAS, or Digest Authentication in IIS, you must configure
this policy setting to Enabled. This presents a security risk when you apply the setting through Group Policy on a
user-by-user basis because it requires the appropriate user account object to be opened in Active Directory Users
and Computers.
Related topics
Password Policy
Applies to
Windows 10
Describes the Account Lockout Policy settings and links to information about each policy setting.
Someone who attempts to use more than a few unsuccessful passwords while trying to log on to your system
might be a malicious user who is attempting to determine an account password by trial and error. Windows
domain controllers keep track of logon attempts, and domain controllers can be configured to respond to this type
of potential attack by disabling the account for a preset period of time. Account Lockout Policy settings control the
threshold for this response and the actions to be taken after the threshold is reached. The Account Lockout Policy
settings can be configured in the following location in the Group Policy Management Console: Computer
Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy.
The following topics provide a discussion of each policy setting's implementation and best practices
considerations, policy location, default values for the server type or Group Policy Object (GPO), relevant differences
in operating system versions, and security considerations (including the possible vulnerabilities of each policy
setting), countermeasures that you can implement, and the potential impact of implementing the countermeasures.
In this section
TOPIC DESCRIPTION
Account lockout duration Describes the best practices, location, values, and security
considerations for the Account lockout duration security
policy setting.
Account lockout threshold Describes the best practices, location, values, and security
considerations for the Account lockout threshold security
policy setting.
Reset account lockout counter after Describes the best practices, location, values, and security
considerations for the Reset account lockout counter after
security policy setting.
Related topics
Account lockout duration
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Account lockout duration
Reference
The Account lockout duration policy setting determines the number of minutes that a locked-out account
remains locked out before automatically becoming unlocked. The available range is from 1 through 99,999
minutes. A value of 0 specifies that the account will be locked out until an administrator explicitly unlocks it. If
Account lockout threshold is set to a number greater than zero, Account lockout duration must be greater
than or equal to the value of Reset account lockout counter after. This policy setting is dependent on the Account
lockout threshold policy setting that is defined, and it must be greater than or equal to the value specified for the
Reset account lockout counter after policy setting.
Possible values
A user-defined number of minutes from 0 through 99,999
Not defined
If Account lockout threshold is configured, after the specified number of failed attempts, the account will be locked
out. If th Account lockout duration is set to 0, the account will remain locked until an administrator unlocks it
manually.
It is advisable to set Account lockout duration to approximately 30 minutes. To specify that the account will
never be locked out, set the value to 0. To configure the value for this policy setting so that it never automatically
unlocks the account might seem like a good idea; however, doing so can increase the number of requests that your
organizations Help Desk receives to unlock accounts that were locked by mistake.
Location
Default values
property page.
Default domain policy Not defined
Stand-alone server default settings Not applicable
Domain controller effective default settings Not defined
Member server effective default settings Not defined

Client computer effective default settings Not applicable
More than a few unsuccessful password submissions during an attempt to log on to a computer might represent
an attacker's attempts to determine an account password by trial and error. The Windows and Windows Server
operating systems can track logon attempts, and you can configure the operating system to disable the account for
a preset period of time after a specified number of failed attempts. Account lockout policy settings control the
threshold for this response and what action to take after the threshold is reached.
Vulnerability
A denial-of-service (DoS) condition can be created if an attacker abuses the Account lockout threshold policy
setting and repeatedly attempts to log on with a specific account. After you configure the Account lockout
threshold policy setting, the account will be locked out after the specified number of failed attempts. If you
configure the Account lockout duration policy setting to 0, the account remains locked until you unlock it
manually.
Countermeasure
Configure the Account lockout duration policy setting to an appropriate value for your environment. To specify
that the account will remain locked until you manually unlock it, configure the value to 0. When the Account
lockout duration policy setting is configured to a nonzero value, automated attempts to guess account passwords
are delayed for this interval before resuming attempts against a specific account. Using this setting in combination
with the Account lockout threshold policy setting makes automated password guessing attempts more difficult.
Potential impact
Configuring the Account lockout duration policy setting to 0 so that accounts cannot be automatically unlocked
can increase the number of requests that your organization's Help Desk receives to unlock accounts that were
locked by mistake.
Related topics
Account lockout threshold
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Account lockout threshold
Reference
The Account lockout threshold policy setting determines the number of failed sign-in attempts that will cause a
user account to be locked. A locked account cannot be used until you reset it or until the number of minutes
specified by the Account lockout duration policy setting expires. You can set a value from 1 through 999 failed
sign-in attempts, or you can specify that the account will never be locked by setting the value to 0. If Account
lockout threshold is set to a number greater than zero, Account lockout duration must be greater than or
equal to the value of Reset account lockout counter after.
Failed password attempts on workstations or member servers that have been locked by using CTRL+ALT+DELETE
or password-protected screen savers do not count as failed sign-in attempts unless Interactive logon: Require
Domain Controller authentication to unlock workstation is set to Enabled. If Interactive logon: Require Domain
Controller authentication to unlock workstation is enabled, repeated failed password attempts to unlock the
workstation will count against the account lockout threshold.
Brute force password attacks can be automated to try thousands or even millions of password combinations for
any or all user accounts. Limiting the number of failed sign-ins that can be performed nearly eliminates the
effectiveness of such attacks. However, it is important to note that a denial-of-service (DoS) attack could be
performed on a domain that has an account lockout threshold configured. A malicious user could
programmatically attempt a series of password attacks against all users in the organization. If the number of
attempts is greater than the value of Account lockout threshold, the attacker could potentially lock every
account.
Possible values
It is possible to configure the following values for the Account lockout threshold policy setting:
A user-defined number from 0 through 999
Not defined
Because vulnerabilities can exist when this value is configured and when it is not, organizations should weigh their
identified threats and the risks that they are trying to mitigate. For information these settings, see
Countermeasure in this topic
Best practices
The threshold that you select is a balance between operational efficiency and security, and it depends on your
organization's risk level. To allow for user error and to thwart brute force attacks, a setting above 4 and below 10
could be an acceptable starting point for your organization.
Important: Implementation of this policy setting is dependent on your operational environment; threat
vectors, deployed operating systems, and deployed apps. For more information, see Implementation
considerations in this topic.
Location
Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy
Default values
The following table lists the actual and effective default policy values. Default values are also listed on the property
page for the policy setting.
Default domain policy 0 invalid sign-in attempts
Stand-alone server default settings 0 invalid sign-in attempts
Domain controller effective default settings 0 invalid sign-in attempts
Member server effective default settings 0 invalid sign-in attempts
Effective GPO default settings on client computers 0 invalid sign-in attempts
Policy management
This section describes features and tools that are available to help you manage this policy setting.
Restart requirements
None. Changes to this policy setting become effective without a computer restart when they are saved locally or
Implementation considerations
Implementation of this policy setting is dependent on your operational environment. You should consider threat
vectors, deployed operating systems, and deployed apps, for example:
The likelihood of an account theft or a DoS attack is based on the security design for your systems and
environment. You should set the account lockout threshold in consideration of the known and perceived risk of
those threats.
When negotiating encryption types between clients, servers, and domain controllers, the Kerberos protocol can
automatically retry account sign-in attempts that count toward the threshold limits that you set in this policy
setting. In environments where different versions of the operating system are deployed, encryption type
negotiation increases.
Not all apps that are used in your environment effectively manage how many times a user can attempt to sign-
in. For instance, if a connection drops repeatedly when a user is running the app, all subsequent failed sign-in
attempts count toward the account lockout threshold.
Vulnerability
Brute force password attacks can use automated methods to try millions of password combinations for any user
account. The effectiveness of such attacks can be almost eliminated if you limit the number of failed sign-in
attempts that can be performed. However, a DoS attack could be performed on a domain that has an account
lockout threshold configured. An attacker could programmatically attempt a series of password attacks against all
users in the organization. If the number of attempts is greater than the account lockout threshold, the attacker
might be able to lock every account without needing any special privileges or being authenticated in the network.
Note: Offline password attacks are not countered by this policy setting.
Countermeasure
Because vulnerabilities can exist when this value is configured and when it is not configured, two distinct
countermeasures are defined. Organizations should weigh the choice between the two, based on their identified
threats and the risks that they want to mitigate. The two countermeasure options are:
Configure the Account lockout threshold setting to 0. This configuration ensures that accounts will not be
locked, and it will prevent a DoS attack that intentionally attempts to lock accounts. This configuration also
helps reduce Help Desk calls because users cannot accidentally lock themselves out of their accounts. Because
it does not prevent a brute force attack, this configuration should be chosen only if both of the following
criteria are explicitly met:
The password policy setting requires all users to have complex passwords of 8 or more characters.
A robust audit mechanism is in place to alert administrators when a series of failed sign-ins occur in the
environment.
Configure the Account lockout threshold policy setting to a sufficiently high value to provide users with
the ability to accidentally mistype their password several times before the account is locked, but ensure that
a brute force password attack still locks the account.
A good recommendation for such a configuration is 50 invalid sign-in attempts, which prevents accidental
account lockouts and reduces the number of Help Desk calls, but does not prevent a DoS attack. We
recommend this option if your organization cannot implement complex password requirements and an
audit policy that alerts administrators to a series of failed sign-in attempts. Using this type of policy must
be accompanied by a process to unlock locked accounts. It must be possible to implement this policy
whenever it is needed to help mitigate massive lockouts caused by an attack on your systems.
Potential impact
If this policy setting is enabled, a locked account is not usable until it is reset by an administrator or until the
account lockout duration expires. Enabling this setting will likely generate a number of additional Help Desk calls.
If you configure the Account lockout threshold policy setting to 0, there is a possibility that an malicious user's
attempt to discover passwords with a brute force password attack might go undetected if a robust audit
mechanism is not in place.
If you configure this policy setting to a number greater than 0, an attacker can easily lock any accounts for which
the account name is known. This is especially dangerous considering that no credentials other than access to the
network are necessary to lock the accounts.
Related topics
Reset account lockout counter after
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Reset account lockout counter
after security policy setting.
Reference
The Reset account lockout counter after policy setting determines the number of minutes that must elapse
from the time a user fails to log on before the failed logon attempt counter is reset to 0. If Account lockout
threshold is set to a number greater than zero, this reset time must be less than or equal to the value of Account
lockout duration.
A disadvantage to setting this too high is that users lock themselves out for an inconveniently long period if they
exceed the account lockout threshold through logon errors. Users may make excessive Help Desk calls.
Possible values
Not defined
Best practices
You need to determine the threat level for your organization and balance that against the cost of your Help
Desk support for password resets. Each organization will have specific requirements.
Location
Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy
Default values
property page.
Stand-alone server default settings Not applicable
Client computer effective default settings Not applicable
Vulnerability
Users can accidentally lock themselves out of their accounts if they mistype their password multiple times.
Countermeasure
Configure the Reset account lockout counter after policy setting to 30.
Potential impact
If you do not configure this policy setting or if the value is configured to an interval that is too long, an attacker
could attempt to log on to each user's account numerous times and lock out their accounts, a denial-of-service
(DoS) attack might succeed, or administrators might have to manually unlock all locked-out accounts. If you
configure this policy setting to a reasonable value, users can perform new attempts to log on after a failed logon
within a reasonable time, without making brute force attacks feasible at high speeds. Be sure that you notify users
of the values that are used for this policy setting so that they wait for the lockout timer to expire before they call
the Help Desk.
Related topics
Kerberos Policy
Applies to
Windows 10
Describes the Kerberos Policy settings and provides links to policy setting descriptions.
The Kerberos version 5 authentication protocol provides the default mechanism for authentication services and the
authorization data necessary for a user to access a resource and perform a task on that resource. By reducing the
lifetime of Kerberos tickets, you reduce the risk of a legitimate user's credentials being stolen and successfully used
by an attacker. However, this also increases the authorization overhead. In most environments, these settings
should not need to be changed.
These policy settings are located in \Computer Configuration\Windows Settings\Security Settings\Account
Policies\Kerberos Policy.
The following topics provide a discussion of implementation and best practices considerations, policy location,
default values for the server type or GPO, relevant differences in operating system versions, security
considerations (including the possible settings vulnerabilities of each setting), countermeasures you can take, and
the potential impact for each setting.
In this section
TOPIC DESCRIPTION
Enforce user logon restrictions Describes the best practices, location, values, policy
management, and security considerations for the Enforce
user logon restrictions security policy setting.
Maximum lifetime for service ticket Describes the best practices, location, values, policy
lifetime for service ticket security policy setting.
Maximum lifetime for user ticket Describes the best practices, location, values, policy
lifetime for user ticket policy setting.
Maximum lifetime for user ticket renewal Describes the best practices, location, values, policy
lifetime for user ticket renewal security policy setting.
Maximum tolerance for computer clock synchronization Describes the best practices, location, values, policy
tolerance for computer clock synchronization security
Related topics
Enforce user logon restrictions
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Enforce user
logon restrictions security policy setting.
Reference
The Enforce user logon restrictions policy setting determines whether the Kerberos V5 Key Distribution Center
(KDC) validates every request for a session ticket against the user rights policy of the user account. Validating each
request for a session ticket is optional because the extra step takes time, and that can slow network access to
services.
The possible values for this Group Policy setting are:
Enabled
Disabled
Not defined
Best practices
If this policy setting is disabled, users might be granted session tickets for services that they do not have the
right to use.
We recommend to set Enforce user logon restrictions to Enabled.
Location
Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy
Default Values
property page.
Default Domain Policy Enabled
Default Domain Controller Policy Not defined
Stand-Alone Server Default Settings Not applicable
DC Effective Default Settings Enabled
Member Server Effective Default Settings Not applicable
Client Computer Effective Default Settings Not applicable
Policy management
A restart of the device is not required for this policy setting to be effective.
Group Policy
Client devices will get the new setting during the next scheduled and successful Group Policy refresh. But for
domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local device,
the Security Configuration Engine will refresh this setting in about five minutes.
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on
the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
Vulnerability
If you disable this policy setting, users could receive session tickets for services that they no longer have the right to
use because the right was removed after they logged on.
Countermeasure
Enable the Enforce user logon restrictions setting.
Potential impact
None. This is the default configuration.
Related topics
Kerberos Policy
Maximum lifetime for service ticket
Applies to
Windows 10
lifetime for service ticket security policy setting.
Reference
The Maximum lifetime for service ticket policy setting determines the maximum number of minutes that a
granted session ticket can be used to access a particular service. The value must be 10 minutes or greater, and it
must be less than or equal to the value of the Maximum lifetime for service ticket policy setting.
A user-defined number of minutes from 10 through 99,999, or 0 (in which case service tickets do not expire).
Not defined.
If a client presents an expired session ticket when it requests a connection to a server, the server returns an error
message. The client must request a new session ticket from the Kerberos V5 KDC. After a connection is
authenticated, however, it no longer matters whether the session ticket remains valid. Session tickets are used only
to authenticate new connections with servers. Ongoing operations are not interrupted if the session ticket that
authenticated the connection expires during the connection.
If the value for this policy setting is too high, users might be able to access network resources outside of their logon
hours. In addition, users whose accounts have been disabled might be able to continue accessing network services
by using valid service tickets that were issued before their account was disabled. If the value is set to 0, service
tickets never expire.
Best practices
It is advisable to set Maximum lifetime for service ticket to 600 minutes.
Location
Default values
property page.
Default Domain Policy 600 minutes
DC Effective Default Settings 600 minutes

Policy management
This policy setting is configured on the domain controller.
Group Policy
Client computers will get the new setting during the next scheduled and successful Group Policy refresh. But for
Vulnerability
If you configure the value for the Maximum lifetime for service ticket setting too high, users might be able to
access network resources outside of their logon hours. Also, users whose accounts were disabled might continue to
have access to network services with valid service tickets that were issued before their accounts were disabled.
Countermeasure
Configure the Maximum lifetime for service ticket setting to 600 minutes.
Potential impact
Related topics
Kerberos Policy
Maximum lifetime for user ticket
Applies to
Windows 10
lifetime for user ticket policy setting.
Reference
The Maximum lifetime for user ticket policy setting determines the maximum amount of time (in hours) that a
users ticket-granting ticket can be used. When a users ticket-granting ticket expires, a new one must be requested
or the existing one must be renewed.
A user-defined number of hours from 0 through 99,999
Not defined
If the value for this policy setting is too high, users might be able to access network resources outside of their logon
hours, or users whose accounts have been disabled might be able to continue to access network services by using
valid service tickets that were issued before their account was disabled. If the value is set to 0, ticket-granting tickets
never expire.
Best practices
It is advisable to set Maximum lifetime for user ticket to 10 hours.
Location
Default Values
property page.
Default Domain Policy 10 hours
Domain Controller Effective Default Settings 10 hours
Policy management
A restart of the computer is not required for this policy setting to be effective.
Group Policy
domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local
computer, the Security Configuration Engine will refresh this setting in about five minutes.
Vulnerability
If you configure the value for the Maximum lifetime for user ticket setting too high, users might be able to
access network resources outside of their logon hours. Also, users whose accounts were disabled might continue to
have access to network services with valid user tickets that were issued before their accounts were disabled. If you
configure this value too low, ticket requests to the KDC may affect the performance of your KDC and present an
opportunity for a DoS attack.
Countermeasure
Configure the Maximum lifetime for user ticket setting with a value between 4 and 10 hours.
Potential impact
Reducing this setting from the default value reduces the likelihood that the ticket-granting ticket will be used to
access resources that the user does not have rights to. However, it requires more frequent requests to the KDC for
ticket-granting tickets on behalf of users. Most KDCs can support a value of four hours without too much additional
burden.
Related topics
Kerberos Policy
Maximum lifetime for user ticket renewal
Applies to
Windows 10
lifetime for user ticket renewal security policy setting.
Reference
The Maximum lifetime for user ticket renewal policy setting determines the period of time (in days) during
which a users ticket-granting ticket can be renewed.
A user-defined number of days from 0 through 99,999
Not defined
Best practices
If the value for this policy setting is too high, users may be able to renew very old user ticket-granting tickets.
If the value is 0, ticket-granting tickets never expire.
It is advisable to set Maximum lifetime for user ticket renewal to 7 days.
Location
Default values
property page.
Default Domain Policy 7 days
Domain Controller Effective Default Settings 7 days
Policy management
Group Policy
Vulnerability
If the value for the Maximum lifetime for user ticket renewal setting is too high, users might be able to renew
very old user tickets.
Countermeasure
Configure the Maximum lifetime for user ticket renewal setting to 7 days.
Potential impact
Related topics
Kerberos Policy
Maximum tolerance for computer clock
synchronization
Applies to
Windows 10
tolerance for computer clock synchronization security policy setting.
Reference
This security setting determines the maximum time difference (in minutes) that Kerberos V5 tolerates between the
time on the client clock and the time on the domain controller that provides Kerberos authentication.
To prevent "replay attacks," the Kerberos v5 protocol uses time stamps as part of its protocol definition. For time
stamps to work properly, the clocks of the client and the domain controller need to be in sync as much as possible.
In other words, both devices must be set to the same time and date. Because the clocks of two computers are often
out of sync, you can use this policy setting to establish the maximum acceptable difference to the Kerberos protocol
between a client clock and domain controller clock. If the difference between a client computer clock and the
domain controller clock is less than the maximum time difference that is specified in this policy, any time stamp
that is used in a session between the two devices is considered to be authentic.
Not defined
Best practices
It is advisable to set Maximum tolerance for computer clock synchronization to a value of 5 minutes.
Location
Default values
property page.
Default Domain Policy 5 minutes
Domain Controller Effective Default Settings 5 minutes

Policy management
Group Policy
Vulnerability
To prevent "replay attacks" (which are attacks in which an authentication credential is resubmitted by a malicious
user or program to gain access to a protected resource), the Kerberos protocol uses time stamps as part of its
definition. For time stamps to work properly, the clocks of the client computer and the domain controller need to be
closely synchronized. Because the clocks of two computers are often not synchronized, administrators can use this
policy to establish the maximum acceptable difference to the Kerberos protocol between a client computer clock
and a domain controller clock. If the difference between the client computer clock and the domain controller clock
is less than the maximum time difference specified in this setting, any time stamp that is used in a session between
the two computers is considered to be authentic.
Countermeasure
Configure the Maximum tolerance for computer clock synchronization setting to 5 minutes.
Potential impact
Related topics
Kerberos Policy
Audit Policy
Applies to
Windows 10
Provides information about basic audit policies that are available in Windows and links to information about each
setting.
The security audit policy settings under Security Settings\Local Policies\Audit Policy provide broad security
audit capabilities for client devices and servers that cannot use advanced security audit policy settings.
The basic audit policy settings under Security Settings\Local Policies\Audit Policy are:
Audit logon events
Audit object access
Audit policy change
Audit privilege use
Audit system events
Related topics
Security auditing
Security Options
Applies to
Windows 10
Provides an introduction to the settings under Security Options of the local security policies and links
to information about each setting.
The Security Options contain the following groupings of security policy settings that allow you to
configure the behavior of the local computer. Some of these policies can be included in a Group Policy
Object and distributed over your organization.
If you edit policy settings locally on a device, you will affect the settings on only that one device. If you
configure the settings in a Group Policy Object (GPO), the settings apply to all devices that are subject to
that GPO.
For info about setting security policies, see Configure security policy settings.
In this section
TOPIC DESCRIPTION
Accounts: Administrator account status Describes the best practices, location, values, and
security considerations for the Accounts:
Administrator account status security policy setting.
Accounts: Block Microsoft accounts Describes the best practices, location, values,
management, and security considerations for the
Accounts: Block Microsoft accounts security policy
setting.
Accounts: Guest account status Describes the best practices, location, values, and
security considerations for the Accounts: Guest
account status security policy setting.
Accounts: Limit local account use of blank passwords to Describes the best practices, location, values, and
console logon only security considerations for the Accounts: Limit local
account use of blank passwords to console logon
only security policy setting.
Accounts: Rename administrator account This security policy reference topic for the IT
professional describes the best practices, location,
values, and security considerations for this policy
setting.
Accounts: Rename guest account Describes the best practices, location, values, and
security considerations for the Accounts: Rename
guest account security policy setting.
Audit: Audit the access of global system objects Describes the best practices, location, values, and
security considerations for the Audit: Audit the access
of global system objects security policy setting.
TOPIC DESCRIPTION
Audit: Audit the use of Backup and Restore privilege Describes the best practices, location, values, and
security considerations for the Audit: Audit the use of
Backup and Restore privilege security policy setting.
Audit: Force audit policy subcategory settings (Windows Describes the best practices, location, values, and
Vista or later) to override audit policy category settings security considerations for the Audit: Force audit
policy subcategory settings (Windows Vista or
later) to override audit policy category settings
Audit: Shut down system immediately if unable to log Describes the best practices, location, values,
security audits management practices, and security considerations for
the Audit: Shut down system immediately if unable
to log security audits security policy setting.
DCOM: Machine Access Restrictions in Security Describes the best practices, location, values, and
Descriptor Definition Language (SDDL) syntax security considerations for the DCOM: Machine Access
Restrictions in Security Descriptor Definition
Language (SDDL) syntax policy setting.
DCOM: Machine Launch Restrictions in Security Describes the best practices, location, values, and
Descriptor Definition Language (SDDL) syntax security considerations for the DCOM: Machine
Launch Restrictions in Security Descriptor Definition
Language (SDDL) syntax security policy setting.
Devices: Allow undock without having to log on Describes the best practices, location, values, and
security considerations for the Devices: Allow undock
without having to log on security policy setting.
Devices: Allowed to format and eject removable media Describes the best practices, location, values, and
security considerations for the Devices: Allowed to
format and eject removable media security policy
setting.
Devices: Prevent users from installing printer drivers Describes the best practices, location, values, and
security considerations for the Devices: Prevent users
from installing printer drivers security policy setting.
Devices: Restrict CD-ROM access to locally logged-on Describes the best practices, location, values, and
user only security considerations for the Devices: Restrict CD-
ROM access to locally logged-on user only security
policy setting.
Devices: Restrict floppy access to locally logged-on user Describes the best practices, location, values, and
only security considerations for the Devices: Restrict
floppy access to locally logged-on user only
Domain controller: Allow server operators to schedule Describes the best practices, location, values, and
tasks security considerations for the Domain controller:
Allow server operators to schedule tasks security
policy setting.
TOPIC DESCRIPTION
Domain controller: LDAP server signing requirements Describes the best practices, location, values, and
security considerations for the Domain controller:
LDAP server signing requirements security policy
setting.
Domain controller: Refuse machine account password Describes the best practices, location, values, and
changes security considerations for the Domain controller:
Refuse machine account password changes security
policy setting.
Domain member: Digitally encrypt or sign secure Describes the best practices, location, values, and
channel data (always) security considerations for the Domain member:
Digitally encrypt or sign secure channel data
(always) security policy setting.
Domain member: Digitally encrypt secure channel data Describes the best practices, location, values, and
(when possible) security considerations for the Domain member:
Digitally encrypt secure channel data (when
possible) security policy setting.
Domain member: Digitally sign secure channel data Describes the best practices, location, values, and
(when possible) security considerations for the Domain member:
Digitally sign secure channel data (when possible)
Domain member: Disable machine account password Describes the best practices, location, values, and
changes security considerations for the Domain member:
Disable machine account password changes security
policy setting.
Domain member: Maximum machine account password Describes the best practices, location, values, and
age security considerations for the Domain member:
Maximum machine account password age security
policy setting.
Domain member: Require strong (Windows 2000 or Describes the best practices, location, values, and
later) session key security considerations for the Domain member:
Require strong (Windows 2000 or later) session key
Interactive logon: Display user information when the Describes the best practices, location, values, and
session is locked security considerations for the Interactive logon:
Display user information when the session is locked
Interactive logon: Don't display last signed-in Describes the best practices, location, values, and
security considerations for the Interactive logon:
Don't display last signed-in security policy setting.
Interactive logon: Don't display username at sign-in Describes the best practices, location, values, and
security considerations for the Interactive logon: Do
not display username at sign-in security policy
setting.
TOPIC DESCRIPTION
Interactive logon: Do not require CTRL+ALT+DEL Describes the best practices, location, values, and
security considerations for the Interactive logon: Do
not require CTRL+ALT+DEL security policy setting.
Interactive logon: Machine account lockout threshold Describes the best practices, location, values,
Interactive logon: Machine account lockout
threshold security policy setting.
Interactive logon: Machine inactivity limit Describes the best practices, location, values,
Interactive logon: Machine inactivity limit security
policy setting.
Interactive logon: Message text for users attempting to Describes the best practices, location, values,
log on management, and security considerations for the
Interactive logon: Message text for users
attempting to log on security policy setting.
Interactive logon: Message title for users attempting to Describes the best practices, location, values, policy
log on management and security considerations for the
Interactive logon: Message title for users
attempting to log on security policy setting.
Interactive logon: Number of previous logons to cache Describes the best practices, location, values, policy
(in case domain controller is not available) management and security considerations for the
Interactive logon: Number of previous logons to
cache (in case domain controller is not available)
Interactive logon: Prompt user to change password Describes the best practices, location, values, policy
before expiration management and security considerations for the
Interactive logon: Prompt user to change password
before expiration security policy setting.
Interactive logon: Require Domain Controller Describes the best practices, location, values, policy
authentication to unlock workstation management, and security considerations for the
Interactive logon: Require Domain Controller
authentication to unlock workstation security policy
setting.
Interactive logon: Require smart card Describes the best practices, location, values, policy
management and security considerations for the
Interactive logon: Require smart card security policy
setting.
Interactive logon: Smart card removal behavior Describes the best practices, location, values, policy
Interactive logon: Smart card removal behavior
Microsoft network client: Digitally sign communications Describes the best practices, location, values, policy
(always) management and security considerations for the
Microsoft network client: Digitally sign
communications (always) security policy setting.
TOPIC DESCRIPTION
Microsoft network client: Digitally sign communications Describes the best practices, location, values, and
(if server agrees) security considerations for the Microsoft network
client: Digitally sign communications (if server
agrees) security policy setting.
Microsoft network client: Send unencrypted password Describes the best practices, location, values, policy
to third-party SMB servers management and security considerations for the
Microsoft network client: Send unencrypted
password to third-party SMB servers security policy
setting.
Microsoft network server: Amount of idle time required Describes the best practices, location, values, and
before suspending session security considerations for the Microsoft network
server: Amount of idle time required before
suspending session security policy setting.
Microsoft network server: Attempt S4U2Self to obtain Describes the best practices, location, values,
claim information management, and security considerations for the
Microsoft network server: Attempt S4U2Self to
obtain claim information security policy setting.
Microsoft network server: Digitally sign communications Describes the best practices, location, values, policy
(always) management and security considerations for the
Microsoft network server: Digitally sign
communications (always) security policy setting.
Microsoft network server: Digitally sign communications Describes the best practices, location, values, policy
(if client agrees) management and security considerations for the
communications (if client agrees) security policy
setting.
Microsoft network server: Disconnect clients when Describes the best practices, location, values, and
logon hours expire security considerations for the Microsoft network
server: Disconnect clients when logon hours expire
Microsoft network server: Server SPN target name Describes the best practices, location, and values, policy
validation level management and security considerations for the
Microsoft network server: Server SPN target name
validation level security policy setting.
Network access: Allow anonymous SID/Name Describes the best practices, location, values, policy
translation management and security considerations for the
Network access: Allow anonymous SID/Name
translation security policy setting.
Network access: Do not allow anonymous enumeration Describes the best practices, location, values, and
of SAM accounts security considerations for the Network access: Do
not allow anonymous enumeration of SAM
accounts security policy setting.
Network access: Do not allow anonymous enumeration Describes the best practices, location, values, and
of SAM accounts and shares security considerations for the Network access: Do
not allow anonymous enumeration of SAM
accounts and shares security policy setting.
TOPIC DESCRIPTION
Network access: Do not allow storage of passwords and Describes the best practices, location, values, policy
credentials for network authentication management and security considerations for the
Network access: Do not allow storage of passwords
and credentials for network authentication security
policy setting.
Network access: Let Everyone permissions apply to Describes the best practices, location, values, policy
anonymous users management and security considerations for the
Network access: Let Everyone permissions apply to
anonymous users security policy setting.
Network access: Named Pipes that can be accessed Describes the best practices, location, values, policy
anonymously management and security considerations for the
Network access: Named Pipes that can be accessed
anonymously security policy setting.
Network access: Remotely accessible registry paths Describes the best practices, location, values, policy
Network access: Remotely accessible registry paths
Network access: Remotely accessible registry paths and Describes the best practices, location, values, and
subpaths security considerations for the Network access:
Remotely accessible registry paths and subpaths
Network access: Restrict anonymous access to Named Describes the best practices, location, values, policy
Pipes and Shares management and security considerations for the
Network access: Restrict anonymous access to
Named Pipes and Shares security policy setting.
Network access: Restrict clients allowed to make remote Describes the best practices, location, values, policy
calls to SAM management and security considerations for the
Network access: Restrict clients allowed to make
remote calls to SAM security policy setting.
Network access: Shares that can be accessed Describes the best practices, location, values, policy
anonymously management and security considerations for the
Network access: Shares that can be accessed
anonymously security policy setting.
Network access: Sharing and security model for local Describes the best practices, location, values, policy
accounts management and security considerations for the
Network access: Sharing and security model for
local accounts security policy setting.
Network security: Allow Local System to use computer Describes the location, values, policy management, and
identity for NTLM security considerations for the Network security:
Allow Local System to use computer identity for
NTLM security policy setting.
Network security: Allow LocalSystem NULL session Describes the best practices, location, values, and
fallback security considerations for the Network security:
Allow LocalSystem NULL session fallback security
policy setting.
TOPIC DESCRIPTION
Network security: Allow PKU2U authentication requests Describes the best practices, location, and values for the
to this computer to use online identities Network Security: Allow PKU2U authentication
requests to this computer to use online identities
Network security: Configure encryption types allowed Describes the best practices, location, values and
for Kerberos Win7 only security considerations for the Network security:
Configure encryption types allowed for Kerberos
Win7 only security policy setting.
Network security: Do not store LAN Manager hash Describes the best practices, location, values, policy
value on next password change management and security considerations for the
Network security: Do not store LAN Manager hash
value on next password change security policy
setting.
Network security: Force logoff when logon hours expire Describes the best practices, location, values, policy
Network security: Force logoff when logon hours
expire security policy setting.
Network security: LAN Manager authentication level Describes the best practices, location, values, policy
Network security: LAN Manager authentication
level security policy setting.
Network security: LDAP client signing requirements This security policy reference topic for the IT
professional describes the best practices, location,
values, policy management and security considerations
for this policy setting. This information applies to
computers running at least the Windows Server 2008
operating system.
Network security: Minimum session security for NTLM Describes the best practices, location, values, policy
SSP based (including secure RPC) clients management and security considerations for the
Network security: Minimum session security for
NTLM SSP based (including secure RPC) clients
Network security: Minimum session security for NTLM Describes the best practices, location, values, policy
SSP based (including secure RPC) servers management and security considerations for the
Network security: Minimum session security for
NTLM SSP based (including secure RPC) servers
Network security: Restrict NTLM: Add remote server Describes the best practices, location, values,
exceptions for NTLM authentication management aspects, and security considerations for
the Network security: Restrict NTLM: Add remote
server exceptions for NTLM authentication security
policy setting.
Network security: Restrict NTLM: Add server exceptions Describes the best practices, location, values,
in this domain management aspects, and security considerations for
the Network security: Restrict NTLM: Add server
exceptions in this domain security policy setting.
TOPIC DESCRIPTION
Network security: Restrict NTLM: Audit incoming NTLM Describes the best practices, location, values,
traffic management aspects, and security considerations for
the Network Security: Restrict NTLM: Audit
incoming NTLM traffic security policy setting.
Network security: Restrict NTLM: Audit NTLM Describes the best practices, location, values,
authentication in this domain management aspects, and security considerations for
the Network Security: Restrict NTLM: Audit NTLM
authentication in this domain security policy setting.
Network security: Restrict NTLM: Incoming NTLM traffic Describes the best practices, location, values,
management aspects, and security considerations for
the Network Security: Restrict NTLM: Incoming
NTLM traffic security policy setting.
Network security: Restrict NTLM: NTLM authentication Describes the best practices, location, values,
in this domain management aspects, and security considerations for
the Network Security: Restrict NTLM: NTLM
authentication in this domain security policy setting.
Network security: Restrict NTLM: Outgoing NTLM traffic Describes the best practices, location, values,
to remote servers management aspects, and security considerations for
the Network Security: Restrict NTLM: Outgoing
NTLM traffic to remote servers security policy
setting.
Recovery console: Allow automatic administrative logon Describes the best practices, location, values, policy
Recovery console: Allow automatic administrative
logon security policy setting.
Recovery console: Allow floppy copy and access to all Describes the best practices, location, values, policy
drives and folders management and security considerations for the
Recovery console: Allow floppy copy and access to
all drives and folders security policy setting.
Shutdown: Allow system to be shut down without Describes the best practices, location, values, policy
having to lg on management and security considerations for the
Shutdown: Allow system to be shut down without
having to log on security policy setting.
Shutdown: Clear virtual memory pagefile Describes the best practices, location, values, policy
Shutdown: Clear virtual memory pagefile security
policy setting.
System cryptography: Force strong key protection for Describes the best practices, location, values, policy
user keys stored on the computer management and security considerations for the
System cryptography: Force strong key protection
for user keys stored on the computer security policy
setting.
System cryptography: Use FIPS compliant algorithms This security policy reference topic for the IT
for encryption, hashing, and signing professional describes the best practices, location,
values, policy management and security considerations
for this policy setting.
TOPIC DESCRIPTION
System objects: Require case insensitivity for non- Describes the best practices, location, values, policy
Windows subsystems management and security considerations for the
System objects: Require case insensitivity for non-
Windows subsystems security policy setting.
System objects: Strengthen default permissions of Describes the best practices, location, values, policy
internal system objects (e.g. Symbolic Links) management and security considerations for the
System objects: Strengthen default permissions of
internal system objects (e.g. Symbolic Links)
System settings: Optional subsystems Describes the best practices, location, values, policy
System settings: Optional subsystems security policy
setting.
System settings: Use certificate rules on Windows Describes the best practices, location, values, policy
executables for Software Restriction Policies management and security considerations for the
System settings: Use certificate rules on Windows
executables for Software Restriction Policies
User Account Control: Admin Approval Mode for the Describes the best practices, location, values, policy
Built-in Administrator account management and security considerations for the User
Account Control: Admin Approval Mode for the
Built-in Administrator account security policy setting.
User Account Control: Allow UIAccess applications to Describes the best practices, location, values, and
prompt for elevation without using the secure desktop security considerations for the User Account Control:
Allow UIAccess applications to prompt for
elevation without using the secure desktop security
policy setting.
User Account Control: Behavior of the elevation prompt Describes the best practices, location, values, policy
for administrators in Admin Approval Mode management and security considerations for the User
Account Control: Behavior of the elevation prompt
for administrators in Admin Approval Mode
User Account Control: Behavior of the elevation prompt Describes the best practices, location, values, policy
for standard users management and security considerations for the User
Account Control: Behavior of the elevation prompt
for standard users security policy setting.
User Account Control: Detect application installations Describes the best practices, location, values, policy
and prompt for elevation management and security considerations for the User
Account Control: Detect application installations
and prompt for elevation security policy setting.
User Account Control: Only elevate executables that are Describes the best practices, location, values, policy
signed and validated management and security considerations for the User
Account Control: Only elevate executables that are
signed and validated security policy setting.
TOPIC DESCRIPTION
User Account Control: Only elevate UIAccess Describes the best practices, location, values, policy
applications that are installed in secure locations management and security considerations for the User
Account Control: Only elevate UIAccess
applications that are installed in secure locations
User Account Control: Run all administrators in Admin Describes the best practices, location, values, policy
Approval Mode management and security considerations for the User
Account Control: Run all administrators in Admin
Approval Mode security policy setting.
User Account Control: Switch to the secure desktop Describes the best practices, location, values, policy
when prompting for elevation management and security considerations for the User
Account Control: Switch to the secure desktop
when prompting for elevation security policy setting.
User Account Control: Virtualize file and registry write Describes the best practices, location, values, policy
failures to per-user locations management and security considerations for the User
Account Control: Virtualize file and registry write
failures to per-user locations security policy setting.
Related topics
Accounts: Administrator account status
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Accounts: Administrator
account status security policy setting.
Reference
This security setting determines whether the local Administrator account is enabled or disabled.
The following conditions prevent disabling the Administrator account, even if this security setting is disabled.
1. The Administrator account is currently in use
2. The Administrators group has no other members
3. All other members of the Administrators group are:
a. Disabled
b. Listed in the Deny log on locally User Rights Assignment
If the Administrator account is disabled, you cannot enable it if the password does not meet requirements. In this
case, another member of the Administrators group must reset the password.
Possible values
Enabled
Disabled
Not defined
By default, this setting is Not defined on domain controllers and Enabled on stand-alone servers.
Best practices
Disabling the administrator account can become a maintenance issue under certain circumstances. For example,
in a domain environment, if the secure channel that constitutes your connection fails for any reason, and there is
no other local administrator account, you must restart the computer in safe mode to fix the problem that broke
your connection status.
Location
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Default values
The following table lists the actual and effective default values for this policy. Default values are also listed on the
policys property page.
Default Domain Policy Not defined

Stand-Alone Server Default Settings Enabled
Member Server Effective Default Settings Enabled
Client Computer Effective Default Settings Disabled
Policy management
Disabling the administrator account can become a maintenance issue under certain circumstances. Reasons that an
organization might consider disabling the built-in administrator account include:
For some organizations, periodically changing the passwords for local accounts can be a daunting management
challenge.
By default, the administrator account cannot be lockedno matter how many failed attempts to sign in a user
accrues. This makes it a prime target for brute-force, password-guessing attacks.
This account has a well-known security identifier (SID). Some non-Microsoft tools allow you to authenticate over
the network by specifying the SID rather than the account name. This means that even if you rename the
administrator account, a malicious user could start a brute-force attack by using the SID.
Restart requirement
Safe mode considerations
When you start a device in safe mode, the disabled administrator account is enabled only if the computer is non-
domain joined and there are no other active local administrator accounts. If the computer is joined to a domain, the
disabled administrator account is not enabled. If the administrator account is disabled, you can still access the
computer by using safe mode with the current administrative credentials. For example, if a failure occurs using a
secure channel with a domain-joined computer, and there is no other local administrator account, you must restart
the device in safe mode to fix the failure.
How to access a disabled Administrator account
You can use the following methods to access a disabled Administrator account:
When there is only one local administrator account that is disabled, start the device in safe mode (locally or over
a network), and sign in by using the credentials for the administrator account on that computer.
When there are local administrator accounts in addition to the built-in account, start the computer in safe mode
(locally or over a network), and sign in by using the credentials for the administrator account on that device. An
alternate method is to sign in to Windows by using another local Administrator account that was created.
When multiple domain-joined servers have a disabled local Administrator account that can be accessed in safe
mode, you can remotely run psexec by using the following command: net user administrator /active: no.
Vulnerability
The built-in administrator account cannot be locked out no matter how many failed logons it accrues, which makes
it a prime target for brute-force attacks that attempt to guess passwords. Also, this account has a well-known
security identifier (SID), and there are non-Microsoft tools that allow authentication by using the SID rather than the
account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute-force
attack by using the SID to log on. All other accounts that are members of the Administrator's group have the
safeguard of locking out the account if the number of failed logons exceeds its configured maximum.
Countermeasure
Disable the Accounts: Administrator account status setting so that the built-in Administrator account cannot be
used in a normal system startup. If it is very difficult to maintain a regular schedule for periodic password changes
for local accounts, you can disable the built-in administrator account instead of relying on regular password
changes to protect it from attack.
Potential impact
Maintenance issues can arise under certain circumstances if you disable the administrator account. For example, if
the secure channel between a member computer and the domain controller fails in a domain environment for any
reason and there is no other local administrator account, you must restart in safe mode to fix the problem that
caused the secure channel to fail. If the current administrator password does not meet the password requirements,
you cannot enable the administrator account after it is disabled. If this situation occurs, another member of the
administrators group must set the password on the administrator account.
Related topics
Security Options
Accounts: Block Microsoft accounts
Applies to
Windows 10
Describes the best practices, location, values, management, and security considerations for the Accounts: Block
Microsoft accounts security policy setting.
Reference
This policy setting prevents users from adding new Microsoft accounts on a device.
If you click the Users cant add Microsoft accounts setting option, users will not be able to switch a local account
to a Microsoft account, or connect a domain account to a Microsoft account to drive sync, roaming, or other
background services. This is the preferred option if you need to limit the use of Microsoft accounts in your
enterprise. Users will still be able to add app-specific Microsoft accounts for use with consumer apps. To block this
use, turn off the ability to install consumer apps or the Store.
If you click the Users cant add or log on with Microsoft accounts setting option, existing Microsoft account
users will not be able to log on to Windows. Selecting this option might make it impossible for an existing
administrator to log on to a computer and manage the system.
If you disable or do not configure this policy (recommended), users will be able to use Microsoft accounts with
Windows.
Possible values
This policy is disabled
Users cant add Microsoft accounts
Users cant add or log on with Microsoft accounts
By default, this setting is not defined on domain controllers and disabled on stand-alone servers.
Best practices
By disabling or not configuring this policy setting on the client computer, users will be able to use their
Microsoft account, local account, or domain account for their sign-in session to Windows. It also enables the
user to connect a local or domain account to a Microsoft account. This provides a convenient option for your
users.
If you need to limit the use of Microsoft accounts in your organization, click the Users cant add Microsoft
accounts setting option so that users will not be able to create new Microsoft accounts on a computer, switch a
local account to a Microsoft account, or connect a domain account to a Microsoft account.
Location
Default values
Stand-Alone Server Default Settings Disabled
DC Effective Default Settings Disabled
Member Server Effective Default Settings Disabled
Policy management
This section describes features and tools that are available to help you manage this policy.
Restart requirement
countermeasure, and the possible negative consequences of the countermeasure implementation.
Vulnerability
Although Microsoft accounts are password-protected, they also have the potential of greater exposure outside of
the enterprise. Additionally, if the owner of a Microsoft account is not easily distinguishable, auditing and forensics
become more difficult.
Countermeasure
Require only domain accounts in your enterprise by limiting the use of Microsoft accounts. Click the Users cant
add Microsoft accounts setting option so that users will not be able to create new Microsoft accounts on a device,
switch a local account to a Microsoft account, or connect a domain account to a Microsoft account.
Potential impact
Establishing greater control over accounts in your organization can give you more secure management capabilities,
including procedures around password resets.
Related topics
Security Options
Accounts: Guest account status - security policy
setting
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Accounts: Guest account status
Reference
The Accounts: Guest account status policy setting determines whether the Guest account is enabled or disabled.
This account allows unauthenticated network users to gain access to the system by logging on as a Guest with no
password. Unauthorized users can access any resources that are accessible to the Guest account over the network.
This means that any network shared folders with permissions that allow access to the Guest account, the Guests
group, or the Everyone group will be accessible over the network. This can lead to the exposure or corruption of
data.
Possible values
Enabled
Disabled
Not defined
Best practices
Set Accounts: Guest account status to Disabled so that the built-in Guest account is no longer usable. All network
users will have to authenticate before they can access shared resources on the system. If the Guest account is
disabled and Network access: Sharing and security model for local accounts is set to Guest only, network logons
such as those performed by the SMB Servicewill fail.
Location
Default values

Vulnerability
The default Guest account allows unauthenticated network users to log on as a Guest with no password. These
unauthorized users could access any resources that are accessible to the Guest account over the network. This
capability means that any shared folders with permissions that allow access to the Guest account, the Guests group,
or the Everyone group are accessible over the network, which could lead to the exposure or corruption of data.
Countermeasure
Disable the Accounts: Guest account status setting so that the built-in Guest account cannot be used.
Potential impact
All network users must be authenticated before they can access shared resources. If you disable the Guest account
and the Network Access: Sharing and Security Model option is set to Guest Only, network logons, such as
those performed by the Microsoft Network Server (SMB Service), fail. This policy setting should have little impact
on most organizations because it is the default setting starting with Windows Vista and Windows Server 2003.
Related topics
Security Options
Accounts: Limit local account use of blank passwords
to console logon only
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Accounts: Limit local account
use of blank passwords to console logon only security policy setting.
Reference
The Accounts: Limit local account use of blank passwords to console logon only policy setting determines
whether remote interactive logons by network services such as Remote Desktop Services, Telnet, and File Transfer
Protocol (FTP) are allowed for local accounts that have blank passwords. If this policy setting is enabled, a local
account must have a nonblank password to be used to perform an interactive or network logon from a remote
client.
This policy setting does not affect interactive logons that are performed physically at the console or logons that use
domain accounts. It is possible for non-Microsoft applications that use remote interactive logons to bypass this
policy setting. Blank passwords are a serious threat to computer security and they should be forbidden through
both corporate policy and suitable technical measures. Nevertheless, if a user with the ability to create new
accounts creates one that has bypassed your domain-based password policy settings, that account might have a
blank password. For example, a user could build a stand-alone system, create one or more accounts with blank
passwords, and then join the computer to the domain. The local accounts with blank passwords would still function.
Anyone who knows the account name can then use accounts with blank passwords to log on to systems.
Devices that are not in physically secure locations should always enforce strong password policies for all local user
accounts. Otherwise, anyone with physical access to the device can log on by using a user account that does not
have a password. This is especially important for portable devices.
If you apply this security policy to the Everyone group, no one will be able to log on through Remote Desktop
Services.
Possible values
Enabled
Disabled
Not defined
Best practices
It is advisable to set Accounts: Limit local account use of blank passwords to console logon only to
Enabled.
Location
Default values
Client Computer Effective Default Settings Enabled
Policy management
Restart requirement
Policy conflict considerations
The policy as distributed through the GPO takes precedence over the locally configured policy setting on a
computer joined to a domain. On the domain controller, use ADSI Edit or the dsquery command to determine
effective minimum password length.
Group Policy
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed
through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be
configured on the local device by using the Local Security Policy snap-in.
Vulnerability
Blank passwords are a serious threat to computer security, and they should be forbidden through organizational
policy and suitable technical measures. Starting with Windows Server 2003, the default settings for Active Directory
domains require complex passwords of at least seven characters, and eight characters starting with Windows
Server 2008. However, if users with the ability to create new accounts bypass your domain-based password
policies, they could create accounts with blank passwords. For example, a user could build a stand-alone computer,
create one or more accounts with blank passwords, and then join the computer to the domain. The local accounts
with blank passwords would still function. Anyone who knows the name of one of these unprotected accounts
could then use it to log on.
Countermeasure
Enable the Accounts: Limit local account use of blank passwords to console logon only setting.
Potential impact
Related topics
Security Options
Accounts: Rename administrator account
Applies to
Windows 10
This security policy reference topic for the IT professional describes the best practices, location, values, and security
considerations for this policy setting.
Reference
The Accounts: Rename administrator account policy setting determines whether a different account name is
associated with the security identifier (SID) for the administrator account.
Because the administrator account exists on all Windows 10 for desktop editions (Home, Pro, Enterprise, and
Education), renaming the account makes it slightly more difficult for attackers to guess this user name and
password combination.
Rename the Administrator account by specifying a value for the Accounts: Rename administrator account
policy setting.
Possible values
User-defined text
Not defined
Best practices
Be sure to inform users who are authorized to use this account of the new account name.
Location
Default values
Stand-Alone Server Default Settings Administrator
DC Effective Default Settings Administrator
Member Server Effective Default Settings Administrator
Client Computer Effective Default Settings Administrator
Policy management
Restart requirement
None.
Group Policy
Vulnerability
The Administrator account exists on all versions Windows 10 for desktop editions. If you rename this account, it is
slightly more difficult for unauthorized persons to guess this privileged user name and password combination.
Beginning with Windows Vista, the person who installs the operating system specifies an account that is the first
member of the Administrator group and has full rights to configure the computer so this countermeasure is
applied by default on new installations. If a device is upgraded from a previous version of Windows, the account
with the name administrator is retained with all the rights and privileges that were defined for the account in the
previous installation.
The built-in administrator account cannot be locked out, regardless of how many times an attacker might use a bad
password. This capability makes the administrator account a popular target for brute-force attacks that attempt to
guess passwords. The value of this countermeasure is lessened because this account has a well-known SID, and
there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore,
even if you rename the Administrator account, an attacker could launch a brute-force attack by using the SID to log
on.
Countermeasure
Specify a new name in the Accounts: Rename administrator account setting to rename the Administrator
account.
Potential impact
You must provide users who are authorized to use this account with the new account name. (The guidance for this
setting assumes that the Administrator account was not disabled.)
Related topics
Security Options
Accounts: Rename guest account - security policy
setting
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Accounts: Rename guest
account security policy setting.
Reference
The Accounts: Rename guest account policy setting determines whether a different account name is associated
with the security identifier (SID) for the Guest account.
Possible values
User-defined text
Guest
Best practices
1. For devices in unsecured locations, renaming the account makes it more difficult for unauthorized users to
guess it.
2. For computers in secured or trusted locations, keeping the name of the account as Guest provides consistency
among devices
Location
Computer Configuration\Windows Settings\Security Settings
Default values
Default Domain Policy Guest
Default Domain Controller Policy Guest
Stand-Alone Server Default Settings Guest
DC Effective Default Settings Guest
Member Server Effective Default Settings Guest
Client Computer Effective Default Settings User-defined text
Policy management
Restart requirement
None.
Group Policy
Vulnerability
The guest account exists in all Windows server and client operating system versions beginning with Windows
Server 2003 and Windows XP Professional. Because the account name is well known, it provides a vector for a
malicious user to get access to network resources and attempt to elevate privileges or install software that could be
used for a later attack on your system.
Countermeasure
Specify a new name in the Accounts: Rename guest account setting to rename the Guest account. If you rename
this account, it is slightly more difficult for unauthorized persons to guess this privileged user name and password
combination.
Potential impact
There should be little impact because the Guest account is disabled by default in Windows 2000 Server, Windows
Server 2003, and Windows XP. For later operating systems, the policy is enabled with Guest as the default.
Related topics
Security Options
Audit: Audit the access of global system objects
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Audit: Audit the access of
global system objects security policy setting.
Reference
If you enable this policy setting, a default system access control list (SACL) is applied when the device creates
system objects such as mutexes, events, semaphores, and MS-DOS devices. If you also enable the Audit object
access audit setting, access to these system objects is audited.
Global system objects, also known as "base system objects" or "base named objects," are temporary kernel objects
that have had names assigned to them by the application or system component that created them. These objects
are most commonly used to synchronize multiple applications or multiple parts of a complex application. Because
they have names, these objects are global in scope and, therefore, visible to all processes on the device. These
objects all have a security descriptor; but typically, they do not have a NULL SACL. If you enable this policy setting
and it takes effect at startup time, the kernel assigns a SACL to these objects when they are created.
The threat is that a globally visible named object, if incorrectly secured, might be acted on by a malicious program
that knows the name of the object. For instance, if a synchronization object such as a mutex has a poorly
constructed discretionary access control list (DACL), a malicious program can access that mutex by name and cause
the program that created it to malfunction. However, the risk of this occurring is very low.
Enabling this policy setting can generate a large number of security events, especially on busy domain controllers
and application servers. This might cause servers to respond slowly and force the security log to record numerous
events of little significance. Auditing for access to global system objects is an all-or-nothing affair; there is no way
to filter which events get recorded and which do not. Even if an organization has the resources to analyze events
generated when this policy setting is enabled, it is unlikely to have the source code or a description of what each
named object is used for; therefore, it is unlikely that many organizations could benefit from enabling this policy
setting.
Possible values
Enabled
Disabled
Not defined
Best practices
Use the advanced security audit policy option, Audit Kernel Object in Advanced Security Audit Policy
Settings\Object Access, to reduce the number of unrelated audit events that you generate.
Location
Default values
Policy management
Restart requirement
A restart of the computer is required before this policy will be effective when changes to this policy are saved
locally or distributed through Group Policy.
Group Policy
All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the
Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational
unit (OU).
Auditing
To audit attempts to access global system objects, you can use one of two security audit policy settings:
Audit Kernel Object in Advanced Security Audit Policy Settings\Object Access
Audit object access under Security Settings\Local Policies\Audit Policy
If possible, use the Advanced Security Audit Policy option to reduce the number of unrelated audit events that you
generate.
If the Audit Kernel Object setting is configured, the following events are generated:
EVENT ID EVENT MESSAGE
4659 A handle to an object was requested with intent to delete.
4660 An object was deleted.
4661 A handle to an object was requested.
4663 An attempt was made to access an object.
If the Audit Kernel Object setting is configured, the following events are generated:
560 Access was granted to an already existing object.

562 A handle to an object was closed.
563 An attempt was made to open an object with the intent to

delete it.
**Note: **This is used by file systems when the
FILE_DELETE_ON_CLOSE flag is specified in Createfile()
564 A protected object was deleted.
565 Access was granted to an already existing object type.
567 A permission associated with a handle was used.

Note: A handle is created with certain granted permissions
(Read, Write, and so on). When the handle is used, up to one
audit is generated for each of the permissions that was used.
569 The resource manager in Authorization Manager attempted to

create a client context.
570 A client attempted to access an object.

**Note: ** An event will be generated for every attempted
operation on the object.
Vulnerability
A globally visible named object, if incorrectly secured, could be acted upon by malicious software by using the
name of the object. For instance, if a synchronization object such as a mutex had a poorly chosen discretionary
access control list (DACL), malicious software could access that mutex by name and cause the program that created
it to malfunction. However, the risk of such an occurrence is very low.
Countermeasure
Enable the Audit: Audit the access of global system objects setting.
Potential impact
If you enable the Audit: Audit the access of global system objects setting, a large number of security events
could be generated, especially on busy domain controllers and application servers. Such an occurrence could cause
servers to respond slowly and force the Security log to record numerous events of little significance. This policy
setting can only be enabled or disabled, and there is no way to choose which events are recorded from this setting.
Even organizations that have the resources to analyze events that are generated by this policy setting are not likely
to have the source code or a description of what each named object is used for. Therefore, it is unlikely that most
organizations would benefit by enabling this policy setting. To reduce the number of audit events generated, use
the advanced audit policy.
Related topics
Security Options
Audit: Audit the use of Backup and Restore privilege
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Audit: Audit the use of Backup
and Restore privilege security policy setting.
Reference
The Audit: Audit the use of Backup and Restore privilege policy setting determines whether to audit the use of
all user rights, including Backup and Restore, when the Audit privilege use policy setting is configured. Enabling
both policy settings generates an audit event for every file that is backed up or restored.
Possible values
Enabled
Disabled
Not defined
Best practices
Set Audit: Audit the use of Backup and Restore privilege to Disabled. Enabling this policy setting can
generate a large number of security events, which might cause servers to respond slowly and force the security
event log to record numerous events of little significance.
Location
Default values
Policy management
Restart requirement
Auditing
Enabling this policy setting in conjunction with the Audit privilege use policy setting records any instance of user
rights that are being exercised in the security log. If Audit privilege use is enabled but Audit: Audit the use of
Backup and Restore privilege is disabled, when users use backup or restore user rights, those events will not be
audited.
Enabling this policy setting when the Audit privilege use policy setting is also enabled generates an audit event
for every file that is backed up or restored. This can help you to track down an administrator who is accidentally or
maliciously restoring data in an unauthorized manner.
Alternately, you can use the advanced audit policy, Audit Sensitive Privilege Use, which can help you manage the
number of events generated.
Vulnerability
When the backup and restore function is used, it creates a copy of the file system that is identical to the target of
the backup. Making regular backup and restore volumes is an important part of your incident response plan.
However, a malicious user could use a legitimate backup copy to gain access to information or to impersonate a
legitimate network resource to compromise your enterprise.
Countermeasure
Enable the Audit: Audit the use of Backup and Restore privilege setting. Alternatively, implement automatic
log backup by configuring the AutoBackupLogFiles registry key. If you enable this option when the Audit
privilege use setting is also enabled, an audit event is generated for every file that is backed up or restored. This
information could help you to identify an account that was used to accidentally or maliciously restore data in an
unauthorized manner. For more information about configuring this key, see Microsoft Knowledge Base article
100879.
Potential impact
If you enable this policy setting, a large number of security events could be generated, which could cause servers to
respond slowly and force the security event log to record numerous events of little significance. If you increase the
security event log size to reduce the chances of a system shutdown, an excessively large log file may affect system
performance.
Related topics
Security Options
Audit: Force audit policy subcategory settings
(Windows Vista or later) to override audit policy
category settings
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Audit: Force audit policy
subcategory settings (Windows Vista or later) to override audit policy category settings security policy
setting.
Reference
You can manage your audit policy in a more precise way by using audit policy subcategories.
There are over 40 auditing subcategories that provide precise details about activities on a device. For info about
these subcategories, see the Advanced security audit policy settings.
Possible values
Enabled
Disabled
Best practices
Leave the setting enabled. This provides the ability to audit events at the category level without revising a policy.
Location
Default values
Policy management
Restart requirement
Group Policy
unit (OU).
Auditing
To manage an audit policy by using subcategories without requiring a change to Group Policy, the
SCENoApplyLegacyAuditPolicy registry value , prevents the application of category-level audit policy from Group
Policy and from the Local Security Policy administrative tool.
If the category level audit policy that is set here is not consistent with the events that are currently being generated,
the cause might be that this registry key is set.
Command-line tools
You can use auditpol.exe to display and manage audit policies from a command prompt.
Vulnerability
Prior to the introduction of auditing subcategories in Windows Vista, it was difficult to track events at a per-system
or per-user level. The larger event categories created too many events, and the key information that needed to be
audited was difficult to find.
Countermeasure
Enable audit policy subcategories as needed to track specific events.
Potential impacts
If you attempt to modify an audit setting by using Group Policy after enabling this setting through the command-
line tools, the Group Policy audit setting is ignored in favor of the custom policy setting. To modify audit settings by
using Group Policy, you must first disable the SCENoApplyLegacyAuditPolicy key.
Important: Be very cautious about audit settings that can generate a large volume of traffic. For example, if you
enable success or failure auditing for all of the Privilege Use subcategories, the high volume of audit events that
are generated can make it difficult to find other types of entries in the security event log. Such a configuration
could also have a significant impact on system performance.
Related topics
Security Options
Audit: Shut down system immediately if unable to log
security audits
Applies to
Windows 10
Describes the best practices, location, values, management practices, and security considerations for the Audit:
Shut down system immediately if unable to log security audits security policy setting.
Reference
The Audit: Shut down system immediately if unable to log security audits policy setting determines whether
the system shuts down if it is unable to log security events. This policy setting is a requirement for Trusted
Computer System Evaluation Criteria (TCSEC)-C2 and Common Criteria certification to prevent auditable events
from occurring if the audit system is unable to log those events. Microsoft has chosen to meet this requirement by
halting the system and displaying a Stop message in the case of a failure of the auditing system. Enabling this
policy setting stops the system if a security audit cannot be logged for any reason. Typically, an event fails to be
logged when the security audit log is full and the value of Retention method for security log is Do not
overwrite events (clear log manually) or Overwrite events by days.
With Audit: Shut down system immediately if unable to log security audits set to Enabled, if the security
log is full and an existing entry cannot be overwritten, the following Stop message appears:
STOP: C0000244 {Audit Failed}

An attempt to generate a security audit failed.
To recover, you must log on, archive the log (optional), clear the log, and reset this option as desired.
If the computer is unable to record events to the security log, critical evidence or important troubleshooting
information might not be available for review after a security incident.
Possible values
Enabled
Disabled
Not defined
Best practices
Depending on your security audit requirements, you can enable the Audit: Shut down system immediately if
unable to log security audits setting to ensure that security auditing information is captured for review.
However, enabling this setting will increase the number of events logged.
Location
Default values
Default Domain Controler Policy Not defined
Policy management
This section describes features and tools that are available to help you manage this policy. The administrative
burden of enabling this policy setting can be very high, especially if you also set the Retention method for
security log to Do not overwrite events (clear log manually). This setting turns a repudiation threat (a backup
operator could deny that they backed up or restored data) into a denial-of-service threat, because a server can be
forced to shut down if it is overwhelmed with logon events and other security events that are written to the security
log. Additionally, because the shutdown is not graceful, it is possible that irreparable damage to the operating
system, applications, or data could result. Although the NTFS file system will guarantee that the file system's
integrity will be maintained during a sudden system shutdown, it cannot guarantee that every data file for every
application will still be in a usable form when the system is restarted.
Restart requirement
Group Policy
Modifying this setting may affect compatibility with clients, services, and applications.
Vulnerability
If the computer is unable to record events to the security event log, critical evidence or important troubleshooting
information may not be available for review after a security incident. Also, an attacker could potentially generate a
large volume of security event log events to purposely force a shutdown.
Countermeasure
Enable the Audit: Shut down system immediately if unable to log security audits setting to ensure that
security auditing information is captured for review.
Potential impact
If you enable this policy setting, the administrative burden can be significant, especially if you also configure the
Retention method for the Security log to Do not overwrite events (clear log manually). This configuration
causes a repudiation threat (a backup operator could deny that they backed up or restored data) to become a
denial of service (DoS) vulnerability because a server could be forced to shut down if it is overwhelmed with logon
events and other security events that are written to the security event log. Also, because the shutdown is abrupt, it
is possible that irreparable damage to the operating system, applications, or data could result. Although the NTFS
file system maintains its integrity when this type of computer shutdown occurs, there is no guarantee that every
data file for every application will still be in a usable form when the device restarts.
Related topics
Security Options
DCOM: Machine Access Restrictions in Security
Descriptor Definition Language (SDDL) syntax
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the DCOM: Machine Access
Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting.
Reference
This policy setting allows you to define additional computer-wide controls that govern access to all Distributed
Component Object Model (DCOM)based applications on a device. These controls restrict call, activation, or launch
requests on the device. A simple way to think about these access controls is as an additional access check that is
performed against a device-wide access control list (ACL) on each call, activation, or launch of any COM-based
server. If the access check fails, the call, activation, or launch request is denied. (This check is in addition to any
access check that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard
that must be passed to access any COM-based server. This policy setting controls access permissions to cover call
rights.
These device-wide ACLs provide a way to override weak security settings that are specified by an application
through the CoInitializeSecurity function or application-specific security settings. They provide a minimum security
standard that must be passed, regardless of the settings of the specific server.
These ACLs also provide a centralized location for an administrator to set a general authorization policy that applies
to all COM-based servers on the device.
This policy setting allows you to specify an ACL in two different ways. You can type the security descriptor in SDDL,
or you can grant or deny Local Access and Remote Access permissions to users and groups. We recommend that
you use the built-in user interface to specify the ACL contents that you want to apply with this setting. The default
ACL settings vary, depending on the version of Windows you are running.
Possible values
User-defined input of the SDDL representation of the groups and privileges
When you specify the users or groups that are to be given permissions, the security descriptor field is
populated with the Security Descriptor Definition Language representation of those groups and privileges.
Users and groups can be given explicit Allow or Deny privileges for local access and remote access.
Blank
This represents how the local security policy deletes the policy enforcement key. This value deletes the policy
and then sets it as Not defined. The Blank value is set by using the ACL editor to empty the list, and then
pressing OK.
Location
Default values
Default Domain Policy Blank
Default Domain Controller Policy Blank
Stand-Alone Server Default Settings Blank
DC Effective Default Settings Not defined
Member Server Effective Default Settings Not defined
Client Computer Effective Default Settings Not defined
Policy management
Restart requirement
Group Policy
The registry settings that are created as a result of enabling the DCOM: Machine Access Restrictions in Security
Descriptor Definition Language (SDDL) syntax policy setting take precedence over the previous registry
settings when this policy setting was configured. The Remote Procedure Call (RPC) service checks the new registry
keys in the Policies section for the computer restrictions, and these registry entries take precedence over the
existing registry keys under OLE. This means that previously existing registry settings are no longer effective, and if
you make changes to the existing settings, device access permissions for users are not changed. Use care in
configuring the list of users and groups.
If the administrator is denied permission to access DCOM applications due to the changes made to DCOM in the
Windows operating system, the administrator can use the DCOM: Machine Access Restrictions in Security
Descriptor Definition Language (SDDL) syntax policy setting to manage DCOM access to the computer. The
administrator can use this setting to specify which users and groups can access the DCOM application on the
computer locally and remotely. This will restore control of the DCOM application to the administrator and users. To
do this, open the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL)
syntax setting, and click Edit Security. Specify the users or groups you want to include and the computer access
permissions for those users or groups. This defines the setting and sets the appropriate SDDL value.
Vulnerability
Many COM applications include some security-specific code (for example, to call CoInitializeSecurity), but they use
weak settings that allow unauthenticated access to the process. Administrators cannot override these settings to
force stronger security in earlier versions of Windows without modifying the application. An attacker could attempt
to exploit weak security in an individual application by attacking it through COM calls.
Also, the COM infrastructure includes the Remote Procedure Call Services (RPCSS), a system service that runs
during and after computer startup. This service manages activation of COM objects and the running object table
and provides helper services to DCOM remoting. It exposes RPC interfaces that can be called remotely. Because
some COM-based servers allow unauthenticated remote access, these interfaces can be called by anyone, including
unauthenticated users. As a result, RPCSS can be attacked by malicious users who use remote, unauthenticated
computers.
Countermeasure
To protect individual COM-based applications or services, set the DCOM: Machine Access Restrictions in
Security Descriptor Definition Language (SDDL) syntax setting to an appropriate device-wide ACL.
Potential impact
Windows implements default COM ACLs when they are installed. Modifying these ACLs from the default may
cause some applications or components that communicate by using DCOM to fail. If you implement a COM-based
server and you override the default security settings, confirm that the application-specific call permissions that ACL
assigns are the correct permissions for appropriate users. If it does not, you must change your application-specific
permission ACL to provide appropriate users with activation rights so that applications and Windows components
that use DCOM do not fail.
Related topics
Security Options
DCOM: Machine Launch Restrictions in Security
Descriptor Definition Language (SDDL) syntax
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the DCOM: Machine Launch
Restrictions in Security Descriptor Definition Language (SDDL) syntax security policy setting.
Reference
This policy setting is similar to the DCOM: Machine Access Restrictions in Security Descriptor Definition Language
(SDDL) syntax setting in that it allows you to define additional computer-wide controls that govern access to all
DCOMbased applications on a device. However, the ACLs that are specified in this policy setting control local and
remote COM launch requests (not access requests) on the device. A simple way to think about this access control is
as an additional access check that is performed against a device-wide ACL on each launch of any COM-based
server. If the access check fails, the call, activation, or launch request is denied. (This check is in addition to any
access check that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard
that must be passed to launch any COM-based server. The DCOM: Machine Access Restrictions in Security
Descriptor Definition Language (SDDL) syntax policy setting differs in that it provides a minimum access check that
is applied to attempts to access an already launched COM-based server.
These device-wide ACLs provide a way to override weak security settings that are specified by an application
through CoInitializeSecurity or application-specific security settings. They provide a minimum security standard
that must be passed, regardless of the settings of the specific COM-based server. These ACLs provide a centralized
location for an administrator to set a general authorization policy that applies to all COM-based servers. The
DCOM: Machine Launch Restrictions in the Security Descriptor Definition Language (SDDL) syntax setting
allows you to specify an ACL in two ways. You can type the security descriptor in SDDL, or you can grant or deny
Local Access and Remote Access permissions to users and groups. We recommend that you use the built-in user
interface to specify the ACL contents that you want to apply with this setting. The default ACL settings vary,
depending on the version of Windows you are running.
Possible values
Blank
This represents how the local security policy deletes the policy enforcement key. This value deletes the policy
and then sets it to Not defined. The Blank value is set by using the ACL editor to empty the list, and then
pressing OK.
User-defined input of the SDDL representation of the groups and privileges
When you specify the users or groups that are to be given permission, the security descriptor field is
populated with the Security Descriptor Definition Language representation of those groups and privileges.
Users and groups can be given explicit Allow or Deny privileges on both local access and remote access.
Location
Default values
Default Domain Policy Blank
Default Domain Controller Policy Blank
Stand-Alone Server Default Settings Blank
Policy management
Restart requirement
Group Policy
The registry settings that are created as a result of this policy take precedence over the previous registry settings in
this area. The Remote Procedure Call (RPC) service (RpcSs) checks the new registry keys in the Policies section for
the computer restrictions; these entries take precedence over the existing registry keys under OLE.
If you are denied access to activate and launch DCOM applications due to the changes made to DCOM in the
Windows operating system, this policy setting can be used to control the DCOM activation and launch to the device.
You can specify which users and groups can launch and activate DCOM applications on the device locally and
remotely by using the DCOM: Machine Launch Restrictions in Security Descriptor Definition Language
(SDDL) syntax policy setting. This restores control of the DCOM application to the administrator and specified
users. To do this, open the DCOM: Machine Launch Restrictions in Security Descriptor Definition Language
(SDDL) syntax setting, and click Edit Security. Specify the groups that you want to include and the device launch
permissions for those groups. This defines the setting and sets the appropriate SDDL value.
Vulnerability
Many COM applications include some security-specific code (for example, to call CoInitializeSecurity), but they use
weak settings that allow unauthenticated access to the process. You cannot override these settings to force stronger
security in earlier versions of Windows without modifying the application. An attacker could attempt to exploit
weak security in an individual application by attacking it through COM calls.
Also, the COM infrastructure includes the Remote Procedure Call Service (RPCSS), a system service that runs
during computer startup and always runs after that. This service manages activation of COM objects and the
running object table and provides helper services to DCOM remoting. It exposes RPC interfaces that can be called
remotely. Because some COM-based servers allow unauthenticated remote component activation, these interfaces
can be called by anyone, including unauthenticated users. As a result, RPCSS can be attacked by malicious users
using remote, unauthenticated computers.
Countermeasure
To protect individual COM-based applications or services, set this policy setting to an appropriate computer-wide
ACL.
Potential impact
Windows implements default COM ACLs when they are installed. Modifying these ACLs from the default may cause
some applications or components that communicate by using DCOM to fail. If you implement a COM-based server
and you override the default security settings, confirm that the application-specific launch permissions ACL assigns
include activation permissions to appropriate users. If it does not, you must change your application-specific launch
permission ACL to provide appropriate users with activation rights so that applications and Windows components
that use DCOM do not fail.
Related topics
Security Options
Devices: Allow undock without having to log on
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Devices: Allow undock without
having to log on security policy setting.
Reference
This policy setting enables or disables the ability of a user to remove a portable device from a docking station
without logging on. If you enable this policy setting, users can press a docked portable device's physical eject
button to safely undock the device. If you disable this policy setting, the user must log on to receive permission to
undock the device. Only users who have the Remove Computer from Docking Station privilege can obtain this
permission.
Note: Disabling this policy setting only reduces theft risk for portable devices that cannot be mechanically
undocked. Devices that can be mechanically undocked can be physically removed by the user whether or not
they use the Windows undocking functionality.
Enabling this policy setting means that anyone with physical access to a device that has been placed in its docking
station can remove the computer and possibly tamper with it. For devices that do not have docking stations, this
policy setting has no impact. However, for users with a mobile computer that is normally docked while they are in
the office, this policy setting will help lower the risk of equipment theft or a malicious user gaining physical access
to these devices
Possible values
Enabled
Disabled
Not defined
Best practices
It is advisable to disable the Devices: Allow undock without having to log on policy setting. Users who have
docked their devices will have to log on to the local console before they can undock their systems.
Location
Default values

Policy management
Restart requirement
Vulnerability
If this policy setting is enabled, anyone with physical access to portable computers in docking stations could
remove them and possibly tamper with them.
Countermeasure
Disable the Devices: Allow undock without having to log on setting.
Potential impact
Users who have docked their device must log on to the local console before they can undock their computers. For
devices that do not have docking stations, this policy setting has no impact.
Related topics
Security Options
Devices: Allowed to format and eject removable
media
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Devices: Allowed to format and
eject removable media security policy setting.
Reference
This policy setting determines who is allowed to format and eject removable media.
Users can move removable disks to a different device where they have administrative user rights and then take
ownership of any file, assign themselves full control, and view or modify any file. The advantage of configuring this
policy setting is diminished by the fact that most removable storage devices will eject media with the press of a
button.
Possible values
Administrators
Administrators and Power Users
Administrators and Interactive Users (not applicable to Windows Server 2008 R2 or Windows 7 and later)
Not defined
Best practices
It is advisable to set Allowed to format and eject removable media to Administrators. Only administrators
will be able to eject NTFS-formatted removable media.
Location
Default values
Stand-Alone Server Default Settings Administrators
DC Effective Default Settings Administrators
Member Server Effective Default Settings Administrators

Policy management
Restart requirement
Vulnerability
Users could move data on removable disks to a different computer where they have administrative privileges. The
user could then take ownership of any file, grant themselves full control, and view or modify any file. The fact that
most removable storage devices eject media when a mechanical button is pressed diminishes the advantage of this
policy setting.
Countermeasure
Configure the Devices: Allowed to format and eject removable media setting to Administrators.
Potential impact
Only administrators can format and eject removable media. If users are in the habit of using removable media for
file transfers and storage, they must be informed of the change in policy.
Related topics
Security Options
Devices: Prevent users from installing printer drivers
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Devices: Prevent users from
installing printer drivers security policy setting.
Reference
For a device to print to a network printer, the driver for that network printer must be installed locally. The Devices:
Prevent users from installing printer drivers policy setting determines who can install a printer driver as part of
adding a network printer. When you set the value to Enabled, only Administrators and Power Users can install a
printer driver as part of adding a network printer. Setting the value to Disabled allows any user to install a printer
driver as part of adding a network printer. This setting prevents unprivileged users from downloading and
installing an untrusted printer driver.
This setting has no impact if you have configured a trusted path for downloading drivers. When using trusted
paths, the print subsystem attempts to use the trusted path to download the driver. If the trusted path download
succeeds, the driver is installed on behalf of any user. If the trusted path download fails, the driver is not installed
and the network printer is not added.
Although it might be appropriate in some organizations to allow users to install printer drivers on their own
workstations, this is not suitable for servers. Installing a printer driver on a server can cause the system to become
less stable. Only administrators should have this user right on servers. A malicious user might deliberately try to
damage the system by installing inappropriate printer drivers.
Possible values
Enabled
Disabled
Not defined
Best practices
It is advisable to set Devices: Prevent users from installing printer drivers to Enabled. Only users in the
Administrative, Power User, or Server Operator groups will be able to install printers on servers. If this policy
setting is enabled, but the driver for a network printer already exists on the local computer, users can still add
the network printer. This policy setting does not affect a user's ability to add a local printer.
Location
Default values

Policy management
Restart requirement
Vulnerability
It may be appropriate in some organizations to allow users to install printer drivers on their own workstations.
However, you should allow only administrators, not users, to do so on servers because printer driver installation on
a server may unintentionally cause the computer to become less stable. A malicious user could install inappropriate
printer drivers in a deliberate attempt to damage the computer, or a user might accidentally install malicious
software that masquerades as a printer driver.
Countermeasure
Enable the Devices: Prevent users from installing printer drivers setting.
Potential impact
Only members of the Administrator, Power Users, or Server Operator groups can install printers on the servers. If
this policy setting is enabled but the driver for a network printer already exists on the local computer, users can still
add the network printer.
Related topics
Security Options
Devices: Restrict CD-ROM access to locally logged-
on user only
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Devices: Restrict CD-ROM
access to locally logged-on user only security policy setting.
Reference
This policy setting determines whether a CD is accessible to local and remote users simultaneously. If you enable
this policy setting, only the interactively logged-on user is allowed to access removable CDs. If this policy setting is
enabled and no one is logged on interactively, the CD can be accessed over the network.
The security benefit of enabling this policy setting is small because it only prevents network users from accessing
the drive when someone is logged on to the local console of the system at the same time. Additionally, CD drives
are not automatically made available as network shared drives; you must deliberately choose to share the drive.
This is important when administrators are installing software or copying data from a CD-ROM, and they do not
want network users to be able to execute the applications or view the data.
If this policy setting is enabled, users who connect to the server over the network will not be able to use any CD
drives that are installed on the server when anyone is logged on to the local console of the server. Enabling this
policy setting is not suitable for a system that serves as a CD jukebox for network users.
Possible values
Enabled
Disabled
Not defined
Best practices
Best practices are dependent on your security and user accessibility requirements for CD drives.
Location
Default values

Policy management
Restart requirement
Vulnerability
A remote user could potentially access a mounted CD that contains sensitive information. This risk is small because
CD drives are not automatically made available as shared drives; you must deliberately choose to share the drive.
However, you can deny network users the ability to view data or run applications from removable media on the
server.
Countermeasure
Enable the Devices: Restrict CD-ROM drive access to locally logged-on user only setting.
Potential impact
Users who connect to the server over the network cannot use any CD drives that are installed on the server when
anyone is logged on to the local console of the server. System tools that require access to the CD drive will fail. For
example, the Volume Shadow Copy service attempts to access all CD and floppy disk drives that are present on the
computer when it initializes, and if the service cannot access one of these drives, it fails. This condition causes the
Windows Backup tool to fail if volume shadow copies were specified for the backup job. Any non-Microsoft backup
products that use volume shadow copies also fail. This policy setting would not be suitable for a computer that
serves as a CD jukebox for network users.
Related topics
Security Options
Devices: Restrict floppy access to locally logged-on
user only
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Devices: Restrict floppy access
to locally logged-on user only security policy setting.
Reference
This policy setting determines whether removable floppy disks are accessible to local and remote users
simultaneously. Enabling this policy setting allows only the interactively logged-on user to access removable floppy
disks. If this policy setting is enabled and no one is logged on interactively, the floppy disk can be accessed over the
network.
The security benefit of enabling this policy setting is small because it only prevents network users from accessing
the floppy disk drive when someone is logged on to the local console of the system at the same time. Additionally,
floppy disk drives are not automatically made available as network shared drives; you must deliberately choose to
share the drive. This becomes important when you are installing software or copying data from a floppy disk and
they do not want network users to be able to execute the applications or view the data.
If this policy setting is enabled, users who connect to the server over the network will not be able to use any floppy
disk drives that are installed on the server when anyone is logged on to the local console of the server.
Possible values
Enabled
Disabled
Not defined
Best practices
Best practices are dependent on your security and user accessibility requirements for CD drives.
Location
Default values

Policy management
Restart requirement
Vulnerability
A remote user could potentially access a mounted floppy disk that contains sensitive information. This risk is small
because floppy disk drives are not automatically shared; administrators must deliberately choose to share the drive.
However, you can deny network users the ability to view data or run applications from removable media on the
server.
Countermeasure
Enable the Devices: Restrict floppy access to locally logged-on user only setting.
Potential impact
Users who connect to the server over the network cannot use any floppy disk drives that are installed on the device
when anyone is logged on to the local console of the server. System tools that require access to floppy disk drives
fail. For example, the Volume Shadow Copy service attempts to access all CD-ROM and floppy disk drives that are
present on the computer when it initializes, and if the service cannot access one of these drives, it fails. This
condition causes the Windows Backup tool to fail if volume shadow copies were specified for the backup job. Any
non-Microsoft backup products that use volume shadow copies also fail.
Related topics
Security Options
Domain controller: Allow server operators to
schedule tasks
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Domain controller: Allow server
operators to schedule tasks security policy setting.
Reference
This policy setting determines whether server operators can use theat command to submit jobs. If you enable this
policy setting, jobs that are created by server operators by means of the at command run in the context of the
account that runs the Task Scheduler service. By default, that is the Local System account.
Note: This security option setting affects only the scheduler tool for the at command. It does not affect the Task
Scheduler tool.
Enabling this policy setting means jobs that are created by server operators through the at command will be
executed in the context of the account that is running that serviceby default, that is the Local System account. This
means that server operators can perform tasks that the Local System account is able to do, but server operators
would normally not be able to do, such as add their account to the local Administrators group.
The impact of enabling this policy setting should be small for most organizations. Users, including those in the
Server Operators group, will still be able to create jobs by using the Task Scheduler Wizard, but those jobs will run
in the context of the account that the user authenticates with when setting up the job.
Possible values
Enabled
Disabled
Not defined
Best practices
Best practices for this policy are dependent on your security and operational requirements for task scheduling.
Location
Default values

Stand-Alone Server Default Settings Not defined
Policy management
Restart requirement
Command-line tools
The at command schedules commands and programs to run on a computer at a specified time and date. The
Schedule service must be running to use the at command.
Vulnerability
Tasks that run under the context of the Local System account can affect resources that are at a higher privilege level
than the user account that scheduled the task.
Countermeasure
Disable the Domain controller: Allow server operators to schedule tasks setting.
Potential impact
The impact should be small for most organizations. Users (including those in the Server Operators group) can still
create jobs by means of the Task Scheduler snap-in. However, those jobs run in the context of the account that the
user authenticates with when setting up the job.
Related topics
Security Options
Domain controller: LDAP server signing requirements
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Domain controller: LDAP server
signing requirements security policy setting.
Reference
This policy setting determines whether the Lightweight Directory Access Protocol (LDAP) server requires LDAP
clients to negotiate data signing.
Unsigned network traffic is susceptible to man-in-the-middle attacks, where an intruder captures packets between
the server and the client device and modifies them before forwarding them to the client device. In the case of an
LDAP server, this means that a malicious user can cause a client device to make decisions based on false records
from the LDAP directory. You can lower the risk of a malicious user accomplishing this in a corporate network by
implementing strong physical security measures to protect the network infrastructure. Furthermore, implementing
Internet Protocol security (IPsec) Authentication Header mode, which provides mutual authentication and packet
integrity for IP traffic, can make all types of man-in-the-middle attacks extremely difficult.
This setting does not have any impact on LDAP simple bind through SSL (LDAP TCP/636).
If signing is required, then LDAP simple binds not using SSL are rejected (LDAP TCP/389).
Caution: If you set the server to Require signature, you must also set the client device. Not setting the client
device results in loss of connection with the server.
Possible values
None. Data signatures are not required to bind with the server. If the client computer requests data signing, the
server supports it.
Require signature. The LDAP data-signing option must be negotiated unless Transport Layer Security/Secure
Sockets Layer (TLS/SSL) is in use.
Not defined.
Best practices
It is advisable to set Domain controller: LDAP server signing requirements to Require signature. Clients
that do not support LDAP signing will be unable to execute LDAP queries against the domain controllers.
Location
Default values

DC Effective Default Settings None
Member Server Effective Default Settings None
Client Computer Effective Default Settings None
Policy management
Restart requirement
Vulnerability
Unsigned network traffic is susceptible to man-in-the-middle attacks. In such attacks, an intruder captures packets
between the server and the client device, modifies them, and then forwards them to the client device. Where LDAP
servers are concerned, an attacker could cause a client device to make decisions that are based on false records
from the LDAP directory. To lower the risk of such an intrusion in an organization's network, you can implement
strong physical security measures to protect the network infrastructure. You could also implement Internet Protocol
security (IPsec) Authentication Header mode, which performs mutual authentication and packet integrity for IP
traffic to make all types of man-in-the-middle attacks extremely difficult.
Countermeasure
Configure the Domain controller: LDAP server signing requirements setting to Require signature.
Potential impact
Client device that do not support LDAP signing cannot run LDAP queries against the domain controllers.
Related topics
Security Options
Domain controller: Refuse machine account password
changes
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Domain controller: Refuse
machine account password changes security policy setting.
Reference
This policy setting enables or disables blocking a domain controller from accepting password change requests for
machine accounts. By default, devices joined to the domain change their machine account passwords every 30
days. If enabled, the domain controller will refuse machine account password change requests.
Possible values
Enabled
When enabled, this setting does not allow a domain controller to accept any changes to a machine account's
password.
Disabled
When disabled, this setting allows a domain controller to accept any changes to a machine account's
password.
Not defined
Same as Disabled.
Best practices
Enabling this policy setting on all domain controllers in a domain prevents domain members from changing
their machine account passwords. This, in turn, leaves those passwords susceptible to attack. Make sure that this
conforms to your overall security policy for the domain.
Location
Default values

Policy management
Restart requirement
Vulnerability
If you enable this policy setting on all domain controllers in a domain, domain members cannot change their
machine account passwords, and those passwords are more susceptible to attack.
Countermeasure
Disable the Domain controller: Refuse machine account password changes setting.
Potential impact
Related topics
Security Options
Domain member: Digitally encrypt or sign secure
channel data (always)
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Domain member: Digitally
encrypt or sign secure channel data (always) security policy setting.
Reference
This setting determines whether all secure channel traffic that is initiated by the domain member meets minimum
security requirements. Specifically, it determines whether all secure channel traffic that is initiated by the domain
member must be signed or encrypted. Logon information that is transmitted over the secure channel is always
encrypted regardless of whether the encryption of all other secure channel traffic is negotiated.
The following policy settings determine whether a secure channel can be established with a domain controller
that is not capable of signing or encrypting secure channel traffic:
Domain member: Digitally encrypt or sign secure channel data (always)
Domain member: Digitally encrypt secure channel data (when possible)
Domain member: Digitally sign secure channel data (when possible)
Setting Domain member: Digitally encrypt or sign secure channel data (always) to Enabled prevents
establishing a secure channel with any domain controller that cannot sign or encrypt all secure channel data.
To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, Windows-
based computers create a communication channel through NetLogon called secure channels. These channels
authenticate machine accounts. They also authenticate user accounts when a remote user connects to a network
resource and the user account exists in a trusted domain. This is called pass-through authentication, and it allows
a device running Windows othat has joined a domain to have access to the user account database in its domain
and in any trusted domains.
To enable the Domain member: Digitally encrypt or sign secure channel data (always) policy setting on a
member workstation or server, all domain controllers in the domain that the member belongs to must be capable
of signing or encrypting all secure-channel data.
Enabling the Domain member: Digitally encrypt or sign secure channel data (always) policy setting
automatically enables the Domain member: Digitally sign secure channel data (when possible) policy setting.
When a device joins a domain, a machine account is created. After joining the domain, the device uses the
password for that account to create a secure channel with the domain controller for its domain every time it
restarts. This secure channel is used to perform operations such as NTLM pass-through authentication and LSA
SID/name Lookup. Requests that are sent on the secure channel are authenticatedand sensitive information
such as passwords are encryptedbut the integrity of the channel is not checked, and not all information is
encrypted. If a system is set to always encrypt or sign secure channel data, a secure channel cannot be established
with a domain controller that is not capable of signing or encrypting all secure channel traffic. If the computer is
configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the
level of encryption and signing is negotiated.
Possible values
Enabled
The policy Domain member: Digitally sign secure channel data (when possible) is assumed to be enabled
regardless of its current setting. This ensures that the domain member attempts to negotiate at least
signing of the secure channel traffic.
Disabled
The encryption and signing of all secure channel traffic is negotiated with the domain controller, in which
case the level of signing and encryption depends on the version of the domain controller and the settings
of the following policies:
1. Domain member: Digitally encrypt secure channel data (when possible)
2. Domain member: Digitally sign secure channel data (when possible)
Not defined
Best practices
Set Domain member: Digitally encrypt or sign secure channel data (always) to Enabled.
Set Domain member: Digitally encrypt secure channel data (when possible) to Enabled.
Set Domain member: Digitally sign secure channel data (when possible) to Enabled.
Note: You can enable the policy settings Domain member: Digitally encrypt secure channel data (when
possible) and Domain member: Digitally sign secure channel data (when possible) on all devices in the
domain that support these policy settings without affecting earlier-version clients and applications.
Location
Default values
Default Domain Controller Policy Enabled
Policy management
Restart requirement
Group Policy
Distribution of this policy through Group Policy overrides the Local Security Policy setting.
Vulnerability
When a device joins a domain, a machine account is created. After it joins the domain, the device uses the
restarts. Requests that are sent on the secure channel are authenticatedand sensitive information such as
passwords are encryptedbut the channel is not integrity-checked, and not all information is encrypted. If a
device is configured to always encrypt or sign secure channel data but the domain controller cannot sign or
encrypt any portion of the secure channel data, the computer and domain controller cannot establish a secure
channel. If the device is configured to encrypt or sign secure channel data, when possible, a secure channel can be
established, but the level of encryption and signing is negotiated.
Countermeasure
Select one of the following settings as appropriate for your environment to configure the computers in your
domain to encrypt or sign secure channel data.
Potential impact
Digital encryption and signing of the secure channel is a good idea because the secure channel protects domain
credentials as they are sent to the domain controller.
Related topics
Security Options
Domain member: Digitally encrypt secure channel
data (when possible)
Applies to
Windows 10
encrypt secure channel data (when possible) security policy setting.
Reference
This setting determines whether all secure channel traffic that is initiated by the domain member meets minimum
security requirements. Specifically, it determines whether all secure channel traffic that is initiated by the domain
member must be encrypted. Logon information that is transmitted over the secure channel is always encrypted
regardless of whether the encryption of all other secure channel traffic is negotiated.
In addition to this policy setting, the following policy settings determine whether a secure channel can be
established with a domain controller that is not capable of signing or encrypting secure channel traffic:
authenticate machine accounts. They also authenticate user accounts when a remote user connects to a network
a computer running the Windows operating system that has joined a domain to have access to the user account
database in its domain and in any trusted domains.
Enabling the Domain member: Digitally encrypt or sign secure channel data (always) policy setting automatically
enables the Domain member: Digitally sign secure channel data (when possible) policy setting.
When a device joins a domain, a machine account is created. After joining the domain, the device uses the
restarts. This secure channel is used to perform operations such as NTLM pass through authentication and LSA
SID/name Lookup. Requests that are sent on the secure channel are authenticatedand sensitive information
such as passwords are encryptedbut the integrity of the channel is not checked, and not all information is
encrypted. If a system is set to always encrypt or sign secure channel data, a secure channel cannot be established
with a domain controller that is not capable of signing or encrypting all secure channel traffic. If the computer is
Possible values
Enabled
The domain member will request encryption of all secure channel traffic. If the domain controller supports
encryption of all secure channel traffic, then all secure channel traffic will be encrypted. Otherwise, only
logon information that is transmitted over the secure channel will be encrypted.
Disabled
The domain member will not attempt to negotiate secure channel encryption.
Note: If the security policy setting Domain member: Digitally encrypt or sign secure channel data
(always) is enabled, this setting will be overwritten.
Not defined
Best practices
Set Domain member: Digitally sign secure channel data (when possible) to Enabled.
Location
Default values
Policy management
Restart requirement
Group Policy
Distribution of this policy through Group Policy does not override the Local Security Policy setting.
Vulnerability
channel. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can
be established, but the level of encryption and signing is negotiated.
Countermeasure
Select one of the following settings as appropriate for your environment to configure the computers in your
domain to encrypt or sign secure channel data:
Potential impact
Digital signing of the secure channel is a good idea because it protects domain credentials as they are sent to the
domain controller.
Related topics
Security Options
Domain member: Digitally sign secure channel data
(when possible)
Applies to
Windows 10
sign secure channel data (when possible) security policy setting.
Reference
This setting determines whether all secure channel traffic that is initiated by the domain member meets
minimum security requirements. Specifically, it determines whether all secure channel traffic that is initiated by
the domain member must be signed. Logon information that is transmitted over the secure channel is always
encrypted regardless of whether the encryption of all other secure channel traffic is negotiated.
The following policy settings determine whether a secure channel can be established with a domain controller
that is not capable of signing or encrypting secure channel traffic:
authenticate computer accounts. They also authenticate user accounts when a remote user connects to a network
a computer running the Windows operating system that has joined a domain to have access to the user account
database in its domain and in any trusted domains.
Enabling the Domain member: Digitally encrypt or sign secure channel data (always) policy setting automatically
enables the Domain member: Digitally sign secure channel data (when possible) policy setting. When a
device joins a domain, a machine account is created. After joining the domain, the device uses the password for
that account to create a secure channel with the domain controller for its domain every time it restarts. This
secure channel is used to perform operations such as NTLM pass through authentication and LSA SID/name
Lookup. Requests that are sent on the secure channel are authenticatedand sensitive information such as
passwords are encryptedbut the integrity of the channel is not checked, and not all information is encrypted. If
a system is set to always encrypt or sign secure channel data, a secure channel cannot be established with a
domain controller that is not capable of signing or encrypting all secure channel traffic. If the computer is
Possible values
Enabled
The domain member will request signing of all secure channel traffic. If the domain controller supports
signing of all secure channel traffic, then all secure channel traffic will be signed which ensures that it
cannot be tampered with in transit.
Disabled
Signing will not be negotiated unless the policy Domain member: Digitally encrypt or sign secure channel
data (always) is enabled.
Not defined
Best practices
Set Domain member: Digitally sign secure channel data (when possible) to Enabled. >Note: You can
enable the other two policy settings, Domain member: Domain member: Digitally encrypt secure channel data
(when possible) and Domain member: Digitally sign secure channel data (when possible), on all
devices joined to the domain that support these policy settings without affecting earlier-version clients and
applications.
Location
Default values
Policy management
Restart requirement
Group Policy
Distribution of this policy through Group Policy does not override the Local Security Policy setting.
Vulnerability
channel. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel
can be established, but the level of encryption and signing is negotiated.
Countermeasure
Because these policies are closely related and useful depending on your environment, select one of the following
settings as appropriate to configure the devices in your domain to encrypt or sign secure channel data when
possible.
Potential impact
Digital signing of the secure channel is a good idea because the secure channel protects domain credentials as
they are sent to the domain controller.
Related topics
Security Options
Domain member: Disable machine account password
changes
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Domain member: Disable
machine account password changes security policy setting.
Reference
The Domain member: Disable machine account password changes policy setting determines whether a
domain member periodically changes its machine account password. Setting its value to Enabled prevents the
domain member from changing the machine account password. Setting it to Disabled allows the domain member
to change the machine account password as specified by the value of the Domain member: Maximum machine
account password age policy setting, which is every 30 days by default.
By default, devices that belong to a domain are automatically required to change the passwords for their accounts
every 30 days. Devices that are no longer able to automatically change their machine password are at risk of a
malicious user determining the password for the system's domain account. Verify that the Domain member:
Disable machine account password changes option is set to Disabled.
Possible values
Enabled
Disabled
Best practices
1. Do not enable this policy setting. Machine account passwords are used to establish secure channel
communications between members and domain controllers and between the domain controllers within the
domain. After it is established, the secure channel transmits sensitive information that is necessary for making
authentication and authorization decisions.
2. Do not use this policy setting in an attempt to support dual-boot scenarios that use the same machine account.
If you want to dual-boot installations that are joined to the same domain, give the two installations different
computer names. This policy setting was added to the Windows operating system to make it easier for
organizations that stockpile pre-built computers that are put into production months later; those devices do not
have to be rejoined to the domain.
Location
Default values
Default Domain Policy Disabled

Default Domain Controller Policy Disabled
Policy management
Restart requirement
Vulnerability
By default, devices running Windows Server that belong to a domain automatically change their passwords for
their accounts every certain number of days, typically 30. If you disable this policy setting, devices that run
Windows Server retain the same passwords as their machine accounts. Devices that cannot automatically change
their account password are at risk from an attacker who could determine the password for the machine's domain
account.
Countermeasure
Verify that the Domain member: Disable machine account password changes setting is configured to
Disabled.
Potential impact
Related topics
Security Options
Domain member: Maximum machine account
password age
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Domain member: Maximum
machine account password age security policy setting.
Reference
The Domain member: Maximum machine account password age policy setting determines the maximum
allowable age for a machine account password.
In Active Directorybased domains, each device has an account and password, just like every user. By default, the
domain members automatically change their domain password every 30 days. Increasing this interval significantly,
or setting it to 0 so that the device no longer change their passwords, gives a malicious user more time to
undertake a brute-force password-guessing attack against one of the machine accounts.
Possible values
User-defined number of days between 0 and 999
Not defined.
Best practices
1. It is often advisable to set Domain member: Maximum machine account password age to about 30 days.
2. Some organizations pre-build devices and then store them for later use or ship them to remote locations. If the
machine's account has expired, it will no longer be able to authenticate with the domain. Devices that cannot
authenticate with the domain must be removed from the domain and rejoined to it. For this reason, some
organizations might want to create a special organizational unit (OU) for computers that are prebuilt, and
configure the value for this policy setting to a larger number of days.
Location
Default values
Stand-Alone Server Default Settings 30 days
DC Effective Default Settings 30 days

Member Server Effective Default Settings 30 days
Client Computer Effective Default Settings 30 days
Policy management
Restart requirement
Vulnerability
In Active Directorybased domains, each device has an account and password, just as every user does. By default,
the domain members automatically change their domain password every 30 days. If you increase this interval
significantly, or set it to 0 so that the computers no longer change their passwords, an attacker has more time to
undertake a brute-force attack to guess the password of one or more computer accounts.
Countermeasure
Configure the Domain member: Maximum machine account password age setting to 30 days.
Potential impact
Related topics
Security Options
Domain member: Require strong (Windows 2000 or
later) session key
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Domain member: Require
strong (Windows 2000 or later) session key security policy setting.
Reference
The Domain member: Require strong (Windows 2000 or later) session key policy setting determines whether
a secure channel can be established with a domain controller that is not capable of encrypting secure channel traffic
with a strong, 128-bit session key. Enabling this policy setting prevents establishing a secure channel with any
domain controller that cannot encrypt secure channel data with a strong key. Disabling this policy setting allows
64-bit session keys.
Whenever possible, you should take advantage of these stronger session keys to help protect secure channel
communications from eavesdropping and session-hijacking network attacks. Eavesdropping is a form of hacking in
which network data is read or altered in transit. The data can be modified to hide or change the name of the sender,
or it can be redirected.
Possible values
Enabled
When enabled on a member workstation or server, all domain controllers in the domain that the member
belongs to must be capable of encrypting secure channel data with a strong, 128-bit key. This means that all
such domain controllers must be running at least Windows 2000 Server.
Disabled
Allows 64-bit session keys to be used.
Not defined.
Best practices
It is advisable to set Domain member: Require strong (Windows 2000 or later) session key to Enabled.
Enabling this policy setting ensures that all outgoing secure channel traffic will require a strong encryption key.
Disabling this policy setting requires that key strength be negotiated. Only enable this option if the domain
controllers in all trusted domains support strong keys. By default, this value is disabled.
Location
Default values
| Server type or GPO
DEFAULT VALUE
Default Domain Policy
Default Domain Controller Policy
Stand-Alone Server Default Settings
DC Effective Default Settings
Member Server Effective Default Settings
Client Computer Effective Default Settings
Policy management
Restart requirement
Group Policy
Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.
You will you be able to join devices that do not support this policy setting to domains where the domain controllers
have this policy setting enabled.
Vulnerability
Session keys that are used to establish secure channel communications between domain controllers and member
computers are much stronger starting with Windows 2000.
Whenever possible, you should take advantage of these stronger session keys to help protect secure channel
communications from attacks that attempt to hijack network sessions and eavesdrop. (Eavesdropping is a form of
hacking in which network data is read or altered in transit. The data can be modified to hide or change the sender,
or be redirected.)
Countermeasure
Enable the Domain member: Require strong (Windows 2000 or later) session key setting.
If you enable this policy setting, all outgoing secure channel traffic requires a strong encryption key. If you disable
this policy setting, the key strength is negotiated. You should enable this policy setting only if the domain
controllers in all trusted domains support strong keys. By default, this policy setting is disabled.
Potential impact
Devices that do not support this policy setting cannot join domains in which the domain controllers have this policy
setting enabled.
Related topics
Security Options
Interactive logon: Display user information when the
session is locked
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Interactive logon: Display user
information when the session is locked security policy setting.
Reference
This security setting controls whether details such as email address or domain\username appear with the
username on the sign-in screen. For clients that run Windows 10 version 1511 and 1507 (RTM), this setting works
similarly to previous versions of Windows. However, because of a new Privacy setting introduced in Windows 10
version 1607, this security setting affects those clients differently.
Changes beginning with Windows 10 version 1607
Beginning with Windows 10 version 1607, new functionality was added to Windows 10 to hide username details
such as email address by default, with the ability to change the default to show the details. This functionality is
controlled by a new Privacy setting in Settings > Accounts > Sign-in options. The Privacy setting is off by
default, which hides the details.
The Interactive logon: Display user information when the session is locked Group Policy setting controls the
same functionality.
This setting has these possible values:
User display name, domain and user names
For a local logon, the user's full name is displayed. If the user signed in using a Microsoft account, the user's
email address is displayed. For a domain logon, the domain\username is displayed. This has the same effect
as turning on the Privacy setting.
User display name only
The full name of the user who locked the session is displayed. This has the same effect as turning off the
Privacy setting.
Do not display user information
No names are displayed. Beginning with Windows 10 version 1607, this option is not supported. If this
option is chosen, the full name of the user who locked the session is displayed instead. This change makes
this setting consistent with the functionality of the new Privacy setting. To display no user information,
enable the Group Policy setting Interactive logon: Don't display last signed-in.
Blank.
Default setting. This translates to Not defined, but it will display the users full name in the same manner as
the option User display name only. When an option is set, you cannot reset this policy to blank, or not
defined.
Hotfix for Windows 10 version 1607
Clients that run Windows 10 version 1607 will not show details on the sign-in screen even if the User display
name, domain and user names option is chosen because the Privacy setting is off. If the Privacy setting is
turned on, details will show.
The Privacy setting cannot be changed for clients in bulk. Instead, apply KB 4013429 to clients that run Windows
10 version 1607 so they behave similarly to previous versions of Windows. Clients that run later versions of
Windows 10 do not require a hotfix.
There are related Group Policy settings:
Computer Configuration\Policies\Administrative Templates\System\Logon\Block user from showing
account details on sign-in prevents users from showing account details on the sign-in screen.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Dont
display last signed-in prevents the username of the last user to sign in from being shown.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Dont
display username at sign-in prevents the username from being shown at Windows sign-in and immediately
after credentials are entered and before the desktop appears.
Interaction with related Group Policy settings
For all versions of Windows 10, only the user display name is shown by default.
If Block user from showing account details on sign-in is enabled, then only the user display name is shown
regardless of any other Group Policy settings. Users will not be able to show details.
If Block user from showing account details on sign-in is not enabled, then you can set Interactive logon:
Display user information when the session is locked to User display name, domain and user names to
show additional details such as domain\username. In this case, clients that run Windows 10 version 1607 need KB
4013429 applied. Users will not be able to hide additional details.
If Block user from showing account details on sign-in is not enabled and Dont display last signed-in is
enabled, the username will not be shown.
Best practices
Your implementation of this policy depends on your security requirements for displayed logon information. If you
run computers that store sensitive data, with monitors displayed in unsecured locations, or if you have computers
with sensitive data that are remotely accessed, revealing logged on users full names or domain account names
might contradict your overall security policy.
Depending on your security policy, you might also want to enable the Interactive logon: Do not display last user
name policy.
Location
Default values

Stand-alone server default settings Not defined
Domain controller effective default settings User display name, domain and user names
Member server effective default settings User display name, domain and user names
Effective GPO default settings on client computers User display name, domain and user names
Policy management
Restart requirement
None
Group Policy
configured on the local computer by using the Local Security Policy snap-in.
Vulnerability
When a computer displays the Secure Desktop in an unsecured area, certain user information can be readily
available to anyone looking at the monitor, either physically or through a remote connection. The displayed user
information could include the domain user account name or the full name of the user who locked the session or
who had logged on last.
Countermeasure
Enabling this policy setting allows the operating system to hide certain user information from being displayed on
the Secure Desktop (after the device has been booted or when the session has been locked by using
CTRL+ALT+DEL). However, user information is displayed if the Switch user feature is used so that the logon tiles
are displayed for each logged on user.
You might also want to enable the Interactive logon: Do not display last signed-in policy, which will prevent the
Windows operating system from displaying the logon name and logon tile of the last user to logon.
Related topics
Security Options
Interactive logon: Don't display last signed-in
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Interactive logon: Don't
display last signed-in security policy setting. Before Windows 10 version 1703, this policy setting was named
Interactive logon:Do not display last user name.
Reference
This security policy setting determines whether the name of the last user to log on to the device is displayed on the
Secure Desktop.
If this policy is enabled, the full name of the last user to successfully log on is not displayed on the Secure Desktop,
nor is the users logon tile displayed. Additionally, if the Switch user feature is used, the full name and logon tile
are not displayed. The logon screen requests a qualified domain account name (or local user name) and password.
If this policy is disabled, the full name of the last user to log on is displayed, and the users logon tile is displayed.
This behavior is the same when the Switch user feature is used.
Possible values
Enabled
Disabled
Not defined
Best practices
have devices that store sensitive data, with monitors displayed in unsecured locations, or if you have devices with
sensitive data that are remotely accessed, revealing logged on users full names or domain account names might
contradict your overall security policy.
Location
Default values

Policy management
Restart requirement
None.
Group Policy
Vulnerability
An attacker with access to the console (for example, someone with physical access or someone who can connect to
the device through Remote Desktop Session Host) could view the name of the last user who logged on. The
attacker could then try to guess the password, use a dictionary, or use a brute-force attack to try to log on.
Countermeasure
Enable the Interactive logon: Do not display last user name setting.
Potential impact
Users must always type their user names and passwords when they log on locally or to the domain. The logon tiles
of all logged on users are not displayed.
Related topics
Security Options
Interactive logon: Don't display username at sign-in
Applies to
Windows Server 2003, Windows Vista, Windows XP, Windows Server 2008, Windows 7, Windows 8.1, Windows
Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8, Windows 10
Describes the best practices, location, values, and security considerations for the Interactive logon: Don't display
username at sign-in security policy setting.
Reference
A new policy setting has been introduced in Windows 10 starting with Windows 10 version 1703. This security
policy setting determines whether the username is displayed during sign in. This setting only affects the Other user
tile.
If the policy is enabled and a user signs in as Other user, the full name of the user is not displayed during sign-in.
In the same context, if users type their email address and password at the sign in screen and press Enter, the
displayed text Other user remains unchanged, and is no longer replaced by the users first and last name, as in
previous versions of Windows 10. Additionally,if users enter their domain user name and password and click
Submit, their full name is not shown until the Start screen displays.
If the policy is disabled and a user signs in as Other user, the Other user text is replaced by the users first and
last name during sign-in.
Possible values
Enabled
Disabled
Not defined
Best practices
have devices that store sensitive data, with monitors displayed in unsecured locations, or if you have devices with
sensitive data that are remotely accessed, revealing logged on users full names or domain account names might
contradict your overall security policy.
Location
Default values

Effective GPO default settings on client computers Not defined
Policy management
Restart requirement
None.
Group Policy
Vulnerability
An attacker with access to the console (for example, someone with physical access or someone who can connect to
the device through Remote Desktop Session Host) could view the name of the last user who logged on. The
attacker could then try to guess the password, use a dictionary, or use a brute-force attack to try to log on.
Countermeasure
Enable the Interactive logon: Don't display user name at sign-in setting.
Potential impact
Users must always type their usernames and passwords when they log on locally or to the domain. The logon tiles
of all logged on users are not displayed.
Related topics
Security Options
Interactive logon: Do not require CTRL+ALT+DEL
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Interactive logon: Do not
require CTRL+ALT+DEL security policy setting.
Reference
This security setting determines whether pressing CTRL+ALT+DEL is required before a user can log on.
If this policy setting is enabled on a device, a user is not required to press CTRL+ALT+DEL to log on. Not having to
press CTRL+ALT+DEL leaves users susceptible to attacks that attempt to intercept the users' passwords. Requiring
CTRL+ALT+DEL before users log on ensures that users are communicating by means of a trusted path when
entering their passwords.
If this policy is disabled, any user is required to press CTRL+ALT+DEL before logging on to the Windows operating
system (unless they are using a smart card for logon).
Microsoft developed this feature to make it easier for users with certain types of physical impairments to log on to
device running the Windows operating system; however, not having to press the CTRL+ALT+DELETE key
combination leaves users susceptible to attacks that attempt to intercept their passwords. Requiring
CTRL+ALT+DELETE before users log on ensures that users are communicating by means of a trusted path when
entering their passwords.
A malicious user might install malware that looks like the standard logon dialog box for the Windows operating
system, and capture a user's password. The attacker can then log on to the compromised account with whatever
level of user rights that user has.
Possible values
Enabled
Disabled
Not defined
Best practices
It is advisable to set Disable CTRL+ALT+DEL requirement for logon to Not configured.
Location
Default values

Policy management
Restart requirement
Beginning with Windows Server 2008 and Windows Vista, the CTRL+ALT+DELETE key combination is required to
authenticate if this policy is disabled.
Group Policy
Vulnerability
This setting makes it easier for users with certain types of physical impairments to log on to devices that run the
Windows operating system. However, if users are not required to press CTRL+ALT+DEL, they are susceptible to
attacks that attempt to intercept their passwords. If CTRL+ALT+DEL is required before logon, user passwords are
communicated by means of a trusted path.
If this setting is enabled, an attacker could install malware that looks like the standard logon dialog box in the
Windows operating system, and capture the user's password. The attacker would then be able to log on to the
compromised account with whatever level of privilege that user has.
Countermeasure
Disable the Interactive logon: Do not require CTRL+ALT+DEL setting.
Potential impact
Unless they use a smart card to log on, users must simultaneously press the three keys before the logon dialog box
is displayed.
Related topics
Security Options
Interactive logon: Machine account lockout threshold
Applies to
Windows 10
Describes the best practices, location, values, management, and security considerations for the Interactive logon:
Machine account lockout threshold security policy setting.
Reference
Beginning with Windows Server 2012 and Windows 8, the Interactive logon: Machine account threshold
security policy setting enforces the lockout policy on those computers that have BitLocker enabled to protect
operating system volumes.
The security setting allows you to set a threshold for the number of failed logon attempts that causes the device to
be locked by using BitLocker. This means, if the specified maximum number of failed logon attempts is exceeded,
the device will invalidate the Trusted Platform Module (TPM) protector and any other protector except the 48-digit
recovery password, and then reboot. During Device Lockout mode, the computer or device only boots into the
touch-enabled Windows Recovery Environment (WinRE) until an authorized user enters the recovery password to
restore full access.
Failed password attempts on workstations or member servers that have been locked by using either
Ctrl+Alt+Delete or password-protected screen savers count as failed logon attempts.
Possible values
You can set the invalid logon attempts value between 1 and 999. Values from 1 to 3 are interpreted as 4. If you
set the value to 0, or leave blank, the computer or device will never be locked as a result of this policy setting.
Best practices
Use this policy setting in conjunction with your other failed account logon attempts policy. For example, if the
Account lockout threshold policy setting is set at 4, then setting Interactive logon: Machine account lockout
threshold at 6 allows the user to restore access to resources without having to restore access to the device
resulting from a BitLocker lock out.
Location
Default values

Policy management
Restart requirement
A restart is required for changes to this policy to become effective when they are saved locally or distributed
Group Policy
Because this policy setting was introduced in Windows Server 2012 and Windows 8, it can only be set locally on
those devices that contain this policy setting, but it can be set and distributed through Group Policy to any
computer running the Windows operating system that supports Group Policy and is BitLocker-enabled.
When setting this policy, consider the Account lockout threshold policy setting, which determines the number of
failed logon attempts that will cause a user account to be locked out.
Vulnerability
This policy setting helps protect a BitLocker-encrypted device from attackers attempting to brute-force guess the
Windows sign-in password. If not set, then attackers can attempt innumerable passwords, if no other account
protection mechanisms are in place.
Countermeasure
Use this policy setting in conjunction with your other failed account logon attempts policy. For example, if the
Account lockout threshold policy setting is set at 4, then setting Interactive logon: Machine account lockout
threshold at 6 allows the user to restore access to resources without having to restore access to the device
resulting from a BitLocker lock out.
Potential impact
If not set, the device could be compromised by an attacker using brute-force password cracking software.
If set too low, productivity might be hindered because users who become locked out will be unable to access the
device without providing the 48-digit BitLocker recovery password.
Related topics
Security Options
Interactive logon: Machine inactivity limit
Applies to
Windows 10
Machine inactivity limit security policy setting.
Reference
Beginning with Windows Server 2012 and Windows 8, Windows detects user-input inactivity of a sign-in (logon)
session by using the security policy setting Interactive logon: Machine inactivity limit. If the amount of inactive
time exceeds the inactivity limit set by this policy, then the users session locks by invoking the screen saver. This
policy setting allows you to control the locking time by using Group Policy.
Possible values
The automatic lock of the device is set in elapsed seconds of inactivity, which can range from zero (0) to 599,940
seconds (166.65 hours).
If no value (blank) or zero (0) is present in the Machine will be locked after input field, then the policy setting is
disabled and no action is taken on user-input inactivity for the session.
Best practices
Set the time for elapsed user-input inactivity based on the devices usage and location requirements. For example, if
the device or device is in a public area, you might want to have the device automatically lock after a short period of
inactivity to prevent unauthorized access. However, if the device is used by an individual or group of trusted
individuals, such as in a restricted manufacturing area, automatically locking the device might hinder productivity.
Location
Default values

Policy management
Restart requirement
Restart is required for changes to this policy to become effective when they are saved locally or distributed through
Group Policy.
Group Policy
Because this policy setting was introduced in Windows Server 2012 and Windows 8, it can only be set locally on
those computers that contain this policy setting, but it can be set and distributed through Group Policy to any
computer running the Windows operating system that supports Group Policy.
Vulnerability
This policy setting helps you prevent unauthorized access to devices under your control when the currently signed-
in user leaves without deliberately locking the desktop. In versions earlier than Windows Server 2012 and Windows
8, the desktop-locking mechanism was set on individual computers in Personalization in Control Panel.
Countermeasure
Set the time for elapsed user-input inactivity time by using the security policy setting Interactive logon: Machine
inactivity limit based on the devices usage and location requirements.
Potential impact
This security policy setting can limit unauthorized access to unsecured computers; however, that requirement must
be balanced with the productivity requirements of the intended user.
Related topics
Security Options
Interactive logon: Message text for users attempting
to log on
Applies to
Windows 10
Message text for users attempting to log on security policy setting.
Reference
The Interactive logon: Message text for users attempting to log on and Interactive logon: Message title for
users attempting to log on policy settings are closely related. Interactive logon: Message text for users
attempting to log on specifies a text message to be displayed to users when they log on. Interactive logon:
Message title for users attempting to log on specifies a title to appear in the title bar of the window that contains
the text message. This text is often used for legal reasonsfor example, to warn users about the ramifications of
misusing company information, or to warn them that their actions might be audited.
Not using this warning-message policy setting leaves your organization legally vulnerable to trespassers who
unlawfully penetrate your network. Legal precedents have established that organizations that display warnings to
users who connect to their servers over a network have a higher rate of successfully prosecuting trespassers.
When these policy settings are configured, users will see a dialog box before they can log on to the server console.
Possible values
The possible values for this setting are:
User-defined text
Not defined
Best practices
It is advisable to set Interactive logon: Message text for users attempting to log on to a value similar
to one of the following:
1. IT IS AN OFFENSE TO CONTINUE WITHOUT PROPER AUTHORIZATION.
2. This system is restricted to authorized users. Individuals who attempt unauthorized access will be
prosecuted. If you are unauthorized, terminate access now. Click OK to indicate your acceptance of this
information. >Important: Any warning that you display in the title or text should be approved by
representatives from your organization's legal and human resources departments.
Location
Default values
Policy management
This section describes different requirements to help you manage this policy.
Restart requirement
There are two policy settings that relate to logon displays:
Interactive logon: Message text for users attempting to log on
Interactive logon: Message title for users attempting to log on
The first policy setting specifies a text message that displays to users when they log on, and the second policy
setting specifies a title for the title bar of the text message window. Many organizations use this text for legal
purposes; for example, to warn users about the ramifications of misuse of company information, or to warn them
that their actions may be audited.
Vulnerability
Users often do not understand the importance of security practices. However, the display of a warning message
before logon may help prevent an attack by warning malicious or uninformed users about the consequences of
their misconduct before it happens. It may also help reinforce corporate policies by notifying employees of
appropriate policies during the logon process.
Countermeasure
Configure the Interactive logon: Message text for users attempting to log on and Interactive logon: Message
title for users attempting to log on settings to an appropriate value for your organization.
Note: Any warning message that displays should be approved by your organization's legal and human
resources representatives.
Potential impact
Users see a message in a dialog box before they can log on to the server console.
Related topics
Security Options
Interactive logon: Message title for users attempting
to log on
Applies to
Windows 10
Describes the best practices, location, values, policy management and security considerations for the Interactive
logon: Message title for users attempting to log on security policy setting.
Reference
This security setting allows you to specify a title that appears in the title bar of the window that contains the
Interactive logon: Message title for users attempting to log on. This text is often used for legal reasonsfor
example, to warn users about the ramifications of misusing company information, or to warn them that their
actions might be audited.
The Interactive logon: Message title for users attempting to log on and Interactive logon: Message text for
users attempting to log on policy settings are closely related. Interactive logon: Message title for users
attempting to log on specifies a message title to be displayed to users when they log on.
Not using this warning-message policy setting leaves your organization legally vulnerable to trespassers who
unlawfully penetrate your network. Legal precedents have established that organizations that display warnings to
users who connect to their servers over a network have a higher rate of successfully prosecuting trespassers.
When these policy settings are configured, users will see a dialog box before they can log on to the server console.
Possible values
User-defined title
Not defined
Best practices
1. It is advisable to set Interactive logon: Message title for users attempting to log on to a value similar
to one the following:
RESTRICTED SYSTEM
or
WARNING: This system is restricted to authorized users.
2. Set the policy Interactive logon: Message text for users attempting to log on to reinforce the meaning of the
messages title.
Location
Default values
Policy management
Restart requirement
There are two policy settings that relate to logon displays:
Interactive logon: Message text for users attempting to log on
Interactive logon: Message title for users attempting to log on
The first policy setting specifies a text message that displays to users when they log on, and the second policy
setting specifies a title for the title bar of the text message window. Many organizations use this text for legal
purposes; for example, to warn users about the ramifications of misuse of company information, or to warn them
that their actions may be audited.
Vulnerability
Users often do not understand the importance of security practices. However, the display of a warning message
with an appropriate title before logon may help prevent an attack by warning malicious or uninformed users
about the consequences of their misconduct before it happens. It may also help reinforce corporate policies by
notifying employees of appropriate policies during the logon process.
Countermeasure
Configure the Interactive logon: Message text for users attempting to log on and Interactive logon: Message
title for users attempting to log on settings to an appropriate value for your organization.
Note: Any warning message that displays should be approved by your organization's legal and human
resources representatives.
Potential impact
Users see a message in a dialog box before they can log on to the server console.
Related topics
Security Options
Interactive logon: Number of previous logons to
cache (in case domain controller is not available)
Applies to
Windows 10
logon: Number of previous logons to cache (in case domain controller is not available) security policy
setting.
Reference
The Interactive logon: Number of previous logons to cache (in case domain controller is not available)
policy setting determines whether a user can log on to a Windows domain by using cached account information.
Logon information for domain accounts can be cached locally so that, if a domain controller cannot be contacted
on subsequent logons, a user can still log on. This policy setting determines the number of unique users whose
logon information is cached locally.
If a domain controller is unavailable and a user's logon information is cached, the user is prompted with the
following message:
A domain controller for your domain could not be contacted. You have been logged on using cached account
information. Changes to your profile since you last logged on might not be available.
If a domain controller is unavailable and a user's logon information is not cached, the user is prompted with this
message:
The system cannot log you on now because the domain DOMAIN NAME is not available.
The value of this policy setting indicates the number of users whose logon information the server caches locally. If
the value is 10, the server caches logon information for 10 users. When an eleventh user logs on to the device, the
server overwrites the oldest cached logon session.
Users who access the server console will have their logon credentials cached on that server. A malicious user who
is able to access the file system of the server can locate this cached information and use a brute-force attack to
determine user passwords. Windows mitigates this type of attack by encrypting the information and keeping the
cached credentials in the system's registries, which are spread across numerous physical locations.
Possible values
A user-defined number from 0 through 50
Not defined
Best practices
It is advisable to set Interactive logon: Number of previous logons to cache (in case domain controller is
not available) to 0. Setting this value to 0 disables the local caching of logon information. Additional
countermeasures include enforcing strong password policies and physically securing the computers. If the value is
set to 0, users will be unable to log on to any computers if there is no domain controller available to authenticate
them. Organizations might want to set Interactive logon: Number of previous logons to cache (in case
domain controller is not available) to 2 for end-user systems, especially for mobile users. Setting this value to
2 means that the user's logon information will still be in the cache even if a member of the IT department has
recently logged on to their device to perform system maintenance. This way, those users will be able to log on to
their devices when they are not connected to the corporate network.
Location
Default values
Stand-Alone Server Default Settings 10 logons
DC Effective Default Settings 10 logons
Member Server Effective Default Settings 10 logons
Client Computer Effective Default Settings 10 logons
Policy management
Restart requirement
None
Group Policy
Vulnerability
The number that is assigned to this policy setting indicates the number of users whose logon information is cache
locally by the servers. If the number is set to 10, the server caches logon information for 10 users. When an
eleventh user logs on to the device, the server overwrites the oldest cached logon session.
Users who access the server console have their logon credentials cached on that server. An attacker who is able to
access the file system of the server could locate this cached information and use a brute force attack to attempt to
determine user passwords.
To mitigate this type of attack, Windows encrypts the information and obscures its physical location.
Countermeasure
Configure the Interactive logon: Number of previous logons to cache (in case domain controller is not
available) setting to 0, which disables the local caching of logon information. Additional countermeasures include
enforcement of strong password policies and physically secure locations for the computers.
Potential impact
Users cannot log on to any devices if there is no domain controller available to authenticate them. Organizations
can configure this value to 2 for end-user computers, especially for mobile users. A configuration value of 2 means
that the user's logon information is still in the cache, even if a member of the IT department has recently logged on
to the device to perform system maintenance. This method allows users to log on to their computers when they
are not connected to the organization's network.
Related topics
Security Options
Interactive logon: Prompt user to change password
before expiration
Applies to
Windows 10
logon: Prompt user to change password before expiration security policy setting.
Reference
The Interactive logon: Prompt user to change password before expiration policy setting determines how
many days in advance users are warned that their passwords are about to expire. With this advance warning, the
user has time to construct a password that is sufficiently strong.
Possible values
A user-defined number of days from 0 through 999.
Not defined.
Best practices
1. Configure user passwords to expire periodically. Users will need warning that their passwords are going to
expire, or they might inadvertently get locked out of the system. This could lead to confusion for users who
access the network locally, or make it impossible for users who access the network through dial-up or virtual
private network (VPN) connections to log on.
2. Set Interactive logon: Prompt user to change password before expiration to 5 days. When their password
expiration date is 5 or fewer days away, users will see a dialog box each time they log on to the domain.
3. Do not set the value to 0, which results in displaying the password expiration warning every time the user logs
on.
Location
Default values
Stand-Alone Server Default Settings 5 days
DC Effective Default Settings 5 days
Member Server Effective Default Settings 5 days

Client Computer Effective Default Settings 5 days
Policy management
Restart requirement
None.
Group Policy
Vulnerability
If user passwords are configured to expire periodically in your organization, users need to be warned when this is
about to happen, or they may be locked out of the device inadvertently when their passwords expire. This condition
could lead to confusion for users who access the network locally, or make it impossible for users to access your
organization's network through dial-up or virtual private network (VPN) connections.
Countermeasure
Configure the Interactive logon: Prompt user to change password before expiration setting to 5 days.
Potential impact
Users see a dialog-box prompt to change their password each time that they log on to the domain when their
password is configured to expire in 5 or fewer days.
Related topics
Security Options
Interactive logon: Require Domain Controller
authentication to unlock workstation
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Interactive
logon: Require Domain Controller authentication to unlock workstation security policy setting.
Reference
Unlocking a locked device requires logon information. For domain accounts, the Interactive logon: Require
Domain Controller authentication to unlock workstation policy setting determines whether it is necessary to
contact a domain controller to unlock a device. Enabling this policy setting requires a domain controller to
authenticate the domain account that is being used to unlock the device. Disabling this policy setting allows a user
to unlock the device without the computer verifying the logon information with a domain controller. However, if
Interactive logon: Number of previous logons to cache (in case domain controller is not available) is set to a value
greater than zero, the user's cached credentials will be used to unlock the system.
The device caches (locally in memory) the credentials of any users who have been authenticated. The device uses
these cached credentials to authenticate anyone who attempts to unlock the console.
When cached credentials are used, any changes that have recently been made to the account (such as user rights
assignments, account lockout, or the account being disabled) are not considered or applied after this authentication
process. This means not only that user rights are not updated, but more importantly that disabled accounts are still
able to unlock the console of the system.
It is advisable to set Interactive logon: Require Domain Controller authentication to unlock workstation to
Enabled and set Interactive logon: Number of previous logons to cache (in case domain controller is not available)
to 0. When the console of a device is locked by a user or automatically by a screen saver time-out, the console can
only be unlocked if the user is able to re-authenticate to the domain controller. If no domain controller is available,
users cannot unlock their devices.
Possible values
Enabled
Disabled
Not defined
Best practices
Set Interactive logon: Require Domain Controller authentication to unlock workstation to Enabled and
set Interactive logon: Number of previous logons to cache (in case domain controller is not available) to 0.
When the console of a device is locked by a user or automatically by a screen saver time-out, the console can
only be unlocked if the user is able to re-authenticate to the domain controller. If no domain controller is
available, users cannot unlock their devices.
Location
Default values
Policy management
Restart requirement
None
Group Policy
Vulnerability
By default, the device caches locally in memory the credentials of any users who are authenticated. The device uses
these cached credentials to authenticate anyone who attempts to unlock the console. When cached credentials are
used, any changes that have recently been made to the accountsuch as user rights assignments, account lockout,
or the account being disabledare not considered or applied after the account is authenticated. User privileges are
not updated, and disabled accounts are still able to unlock the console of the device
Countermeasure
Configure the Interactive logon: Require Domain Controller authentication to unlock workstation setting
to Enabled and configure the Interactive logon: Number of previous logons to cache (in case domain controller is
not available) setting to 0.
Potential impact
When the console on a device is locked by a user or automatically by a screen-saver timeout, the console can be
unlocked only if the user can re-authenticate to the domain controller. If no domain controller is available, users
cannot unlock their workstations. If you configure the Interactive logon: Number of previous logons to cache (in
case domain controller is not available) setting to 0, users whose domain controllers are unavailable (such as
mobile or remote users) cannot log on.
Related topics
Security Options
Interactive logon: Require smart card - security policy
setting
Applies to
Windows 10
logon: Require smart card security policy setting.
Reference
The Interactive logon: Require smart card policy setting requires users to log on to a device by using a smart
card.
Requiring users to use long, complex passwords for authentication enhances network security, especially if the
users must change their passwords regularly. This reduces the chance that a malicious user will be able to guess a
user's password through a brute-force attack. Using smart cards rather than passwords for authentication
dramatically increases security because, with today's technology, it is nearly impossible for a malicious user to
impersonate another user. Smart cards that require personal identification numbers (PINs) provide two-factor
authentication: the user who attempts to log on must possess the smart card and know its PIN. A malicious user
who captures the authentication traffic between the user's device and the domain controller will find it extremely
difficult to decrypt the traffic: even if they do, the next time the user logs on to the network, a new session key will
be generated for encrypting traffic between the user and the domain controller.
Possible values
Enabled
Disabled
Not defined
Best practices
Set Interactive logon: Require smart card to Enabled. All users will have to use smart cards to log on to the
network. This means that the organization must have a reliable public key infrastructure (PKI) in place, and
provide smart cards and smart card readers for all users.
Location
Default values

Policy management
Restart requirement
None.
Group Policy
Vulnerability
It can be difficult to make users choose strong passwords, and even strong passwords are vulnerable to brute-force
attacks if an attacker has sufficient time and computing resources.
Countermeasure
For users with access to computers that contain sensitive data, issue smart cards to users and configure the
Interactive logon: Require smart card setting to Enabled.
Potential impact
All users of a device with this setting enabled must use smart cards to log on locally. This means that the
organization must have a reliable public key infrastructure (PKI) as well as smart cards and smart card readers for
these users. These requirements are significant challenges because expertise and resources are required to plan for
and deploy these technologies. Active Directory Certificate Services (AD CS) can be used to implement and manage
certificates. You can use automatic user and device enrollment and renewal on the client.
Related topics
Security Options
Interactive logon: Smart card removal behavior
Applies to
Windows 10
logon: Smart card removal behavior security policy setting.
Reference
This policy setting determines what happens when the smart card for a logged-on user is removed from the smart
card reader.
If smart cards are used for authentication, the device should automatically lock itself when the card is removed
that way, if users forget to manually lock their devices when they are away from them, malicious users cannot gain
access.
If you select Force Logoff in the property sheet for this policy setting, the user is automatically logged off when the
smart card is removed. Users will have to reinsert their smart cards and reenter their PINs when they return to their
workstations.
Possible values
No Action
Lock Workstation
If you select this, the workstation is locked when the smart card is removed, allowing users to leave the area,
take their smart card with them, and still maintain a protected session.
Force Logoff
If you select this, the user is automatically logged off when the smart card is removed.
Disconnect if a remote Remote Desktop Services session
If you select this, removal of the smart card disconnects the session without logging the user off. This allows
the user to insert the smart card and resume the session later, or at another smart card reader-equipped
computer, without having to log on again. If the session is local, this policy functions identically to Lock
Workstation.
Not Defined
Best practices
Set Interactive logon: Smart card removal behavior to Lock Workstation. If you select Lock Workstation
in the property sheet for this policy setting, the workstation is locked when the smart card is removed. This
allows users to leave the area, take their smart card with them, and still maintain a protected session.
Location
Default values
Stand-Alone Server Default Settings No Action
DC Effective Default Settings No Action
Member Server Effective Default Settings No Action
Client Computer Effective Default Settings No Action
Policy management
Restart requirement
None
Group Policy
Vulnerability
Users sometimes forget to lock their workstations when they are away from them, allowing the possibility for
malicious users to access their devices. If smart cards are used for authentication, the device should automatically
lock itself when the card is removed to ensure that only the user with the smart card is accessing resources by
using those credentials.
Countermeasure
Configure the Interactive logon: Smart card removal behavior setting to Lock Workstation.
If you select Lock Workstation for this policy setting, the device locks when the smart card is removed. Users can
leave the area, take their smart card with them, and still maintain a protected session. This behavior is similar to the
setting that requires users to log on when resuming work on the device after the screen saver has started.
If you select Force Logoff for this policy setting, the user is automatically logged off when the smart card is
removed. This setting is useful when a device is deployed as a public access point, such as a kiosk or other type of
shared device
Potential impact
If you select Force Logoff, users must insert their smart cards and enter their PINs when they return to their
workstations.
Related topics
Security Options
communications (always)
Applies to
Windows 10
Describes the best practices, location, values, policy management and security considerations for the Microsoft
network client: Digitally sign communications (always) security policy setting.
Reference
The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking
operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB
packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines
whether SMB packet signing must be negotiated before further communication with the Server service is
permitted.
Implementation of digital signatures in high-security networks helps prevent the impersonation of client
computers and servers, which is known as "session hijacking." But misuse of these policy settings is a common
error that can cause data loss or problems with data access or security.
If server-side SMB signing is required, a client device will not be able to establish a session with that server, unless
it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and
domain controllers. Similarly, if client-side SMB signing is required, that client device will not be able to establish a
session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only
on domain controllers.
If server-side SMB signing is enabled, SMB packet signing will be negotiated with client computers that have SMB
signing enabled.
Using SMB packet signing can impose up to a 15 percent performance degradation on file service transactions.
There are three other policy settings that relate to packet-signing requirements for Server Message Block (SMB)
communications:
Microsoft network server: Digitally sign communications (always)
Microsoft network client: Digitally sign communications (if server agrees)
Microsoft network server: Digitally sign communications (if client agrees)
Possible values
Enabled
Disabled
Not defined
Best practices
1. Configure the following security policy settings as follows:
Disable Microsoft network client: Digitally sign communications (always).
Disable Microsoft network server: Digitally sign communications (always).
Enable Microsoft network client: Digitally sign communications (if server agrees).
Enable Microsoft network server: Digitally sign communications (if client agrees).
2. Alternately, you can set all of these policy settings to Enabled, but enabling them can cause slower
performance on client devices and prevent them from communicating with legacy SMB applications and
operating systems.
Location
Default values
Policy management
Restart requirement
Vulnerability
Session hijacking uses tools that allow attackers who have access to the same network as the client device or
server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned
Server Message Block (SMB) packets and then modify the traffic and forward it so that the server might perform
objectionable actions. Alternatively, the attacker could pose as the server or client computer after legitimate
authentication, and gain unauthorized access to data.
SMB is the resource-sharing protocol that is supported by many Windows operating systems. It is the basis of
NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either
side fails the authentication process, data transmission does not take place.
Countermeasure
Configure the settings as follows:
In highly secure environments, we recommend that you configure all of these settings to Enabled. However, that
configuration may cause slower performance on client devices and prevent communications with earlier SMB
applications and operating systems.
Note: An alternative countermeasure that could protect all network traffic is to implement digital signatures
with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to
minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing.
Potential impact
Implementations of the SMB file and print-sharing protocol support mutual authentication. This prevents session
hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing
provides this authentication by placing a digital signature into each SMB, which is then verified by the client and
the server.
Implementation of SMB signing may negatively affect performance because each packet must be signed and
verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server
that is serving as a domain controller, file server, print server, and application server, performance may be
substantially slowed. Additionally, if you configure devices to ignore all unsigned SMB communications, older
applications and operating systems cannot connect. However, if you completely disable all SMB signing,
computers are vulnerable to session-hijacking attacks.
Related topics
Security Options
communications (if server agrees)
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Microsoft network client:
Digitally sign communications (if server agrees) security policy setting.
Reference
The Server Message Block (SMB) protocol provides the basis for Microsoft file and print sharing and many other
networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that
modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting
determines whether SMB packet signing must be negotiated before further communication with the Server
service is permitted.
Implementation of digital signatures in high-security networks helps to prevent the impersonation of client
If server-side SMB signing is required, a client computer will not be able to establish a session with that server,
unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations,
servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device will not be able
to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is
enabled only on domain controllers.
If server-side SMB signing is enabled, SMB packet signing will be negotiated with client computers that have SMB
signing enabled.
communications:
Microsoft network client: Digitally sign communications (always)
Possible values
Enabled
Disabled
Not defined
Best practices
Enable Microsoft Network Client: Digitally Sign Communications (If Server Agrees).
operating systems.
Location
Default values
Policy management
Restart requirement
Vulnerability
Session hijacking uses tools that allow attackers who have access to the same network as the client or server to
interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned Server
Message Block (SMB) packets and then modify the traffic and forward it so that the server might perform
objectionable actions. Alternatively, the attacker could pose as the server or client device after legitimate
authentication and gain unauthorized access to data.
Countermeasure
In highly secure environments we recommend that you configure all of these settings to Enabled. However, that
Potential impact
the server.
verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server
that is serving as a domain controller, file server, print server, and application server, performance may be
substantially slowed. Additionally, if you configure devices to ignore all unsigned SMB communications, older
applications and operating systems cannot connect. However, if you completely disable all SMB signing, devices
are vulnerable to session-hijacking attacks.
Related topics
Security Options
Microsoft network client: Send unencrypted password
to third-party SMB servers
Applies to
Windows 10
network client: Send unencrypted password to third-party SMB servers security policy setting.
Reference
The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking
operations, such as remote Windows administration. This policy setting allows or prevents the SMB redirector to
send plaintext passwords to a non-Microsoft server service that does not support password encryption during
authentication.
Possible values
Enabled
The Server Message Block (SMB) redirector is allowed to send plaintext passwords to a non-Microsoft server
service that does not support password encryption during authentication.
Disabled
The Server Message Block (SMB) redirector only sends encrypted passwords to non-Microsoft SMB server
services. If those server services do not support password encryption, the authentication request will fail.
Not defined
Best practices
It is advisable to set Microsoft network client: Send unencrypted password to connect to third-party
SMB servers to Disabled.
Location
Default values

Policy management
Restart requirement
Vulnerability
If you enable this policy setting, the server can transmit plaintext passwords across the network to other computers
that offer SMB services. These other devices might not use any of the SMB security mechanisms that are included
with Windows Server 2003 or later.
Countermeasure
Disable the Microsoft network client: Send unencrypted password to connect to third-party SMB servers
setting.
Potential impact
Some older applications may not be able to communicate with the servers in your organization by means of the
SMB protocol.
Related topics
Security Options
Microsoft network server: Amount of idle time
required before suspending session
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Microsoft network server:
Amount of idle time required before suspending session security policy setting.
Reference
Each Server Message Block (SMB) session consumes server resources. Establishing numerous null sessions will
cause the server to slow down or possibly fail. A malicious user might repeatedly establish SMB sessions until the
server stops responding; at this point, SMB services will become slow or unresponsive.
The Microsoft network server: Amount of idle time required before suspending session policy setting
determines the amount of continuous idle time that must pass in an SMB session before the session is suspended
due to inactivity. You can use this policy setting to control when a device suspends an inactive SMB session. The
session is automatically reestablished when client device activity resumes.
Possible values
For this policy setting, a value of 0 means to disconnect an idle session as quickly as is reasonably possible.
The maximum value is 99999, which is 208 days. In effect, this value disables the policy.
Not defined
Best practices
It is advisable to set this policy to 15 minutes. There will be little impact because SMB sessions will be
reestablished automatically if the client resumes activity.
Location
Default values

Policy management
Restart requirement
Vulnerability
Each SMB session consumes server resources, and numerous null sessions slow the server or possibly cause it to
fail. An attacker could repeatedly establish SMB sessions until the server's SMB services become slow or
unresponsive.
Countermeasure
The default behavior on a server mitigates this threat by design.
Potential impact
There is little impact because SMB sessions are reestablished automatically if the client computer resumes activity.
Related topics
Security Options
Microsoft network server: Attempt S4U2Self to obtain
claim information
Applies to
Windows 10
Describes the best practices, location, values, management, and security considerations for the Microsoft network
server: Attempt S4U2Self to obtain claim information security policy setting.
Reference
This security setting supports client devices running a version of Windows prior to Windows 8 that are trying to
access a file share that requires user claims. This setting determines whether the local file server will attempt to use
Kerberos Service-for-User-to-Self (S4U2Self) functionality to obtain a network client principals claims from the
clients account domain. This setting should only be enabled if the file server is using user claims to control access
to files, and if the file server will support client principals whose accounts might be in a domain that has client
computers and domain controllers running a version of Windows prior to Windows 8 or Windows Server 2012.
When enabled, this security setting causes the Windows file server to examine the access token of an authenticated
network client principal and determines if claim information is present. If claims are not present, the file server will
then use the Kerberos S4U2Self feature to attempt to contact a Windows Server 2012 domain controller in the
clients account domain and obtain a claims-enabled access token for the client principal. A claims-enabled token
might be needed to access files or folders that have claim-based access control policy applied.
If this setting is disabled, the Windows file server will not attempt to obtain a claim-enabled access token for the
client principal.
Possible values
Default
The Windows file server will examine the access token of an authenticated network client principal and
determine if claim information is present.
Enabled
Same as Default.
Disabled
Not defined
Same as Disabled.
Best practices
This setting should be set to Default so that the file server can automatically evaluate whether claims are needed
for the user. You should explicitly configure this setting to Enabled only if there are local file access policies that
include user claims.
Location
Default values
Policy management
Restart requirement
Group Policy
This setting should only be enabled if the file server is using user claims to control access to files, and if the file
server will support client principals whose accounts might be in a domain that has client computers and domain
controllers running a version of Windows prior to Windows 8 or Windows Server 2012.
Vulnerability
None. Enabling this policy setting allows you take advantage of features in Windows Server 2012 and Windows 8
and later for specific scenarios to use claims-enabled tokens to access files or folders that have claim-based access
control policy applied on Windows operating systems prior to Windows Server 2012 and Windows 8.
Countermeasure
Not applicable.
Potential impact
None.
Related topics
Security Options
communications (always)
Applies to
Windows 10
network server: Digitally sign communications (always) security policy setting.
Reference
The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other
For this policy to take effect on computers running Windows 2000, client-side packet signing must also be
enabled. To enable client-side SMB packet signing, set Microsoft network client: Digitally sign communications (if
server agrees). Devices that have this policy set will not be able to communicate with devices that do not have
server-side packet signing enabled. By default, server-side packet signing is enabled only on domain controllers.
Server-side packet signing can be enabled on devices by setting Microsoft network server: Digitally sign
communications (if client agrees).
If server-side SMB signing is required, a client device will not be able to establish a session with that server,
to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is
enabled only on domain controllers.
If server-side SMB signing is enabled, SMB packet signing will be negotiated with client devices that have SMB
signing enabled.
communications:
Possible values
Enabled
Disabled
Not defined
Best practices
operating systems.
Location
Default values
Policy management
Restart requirement
Vulnerability
objectionable actions. Alternatively, the attacker could pose as the server or client device after legitimate
Countermeasure
Potential impact
the server.
verified. If these settings are enabled on a server that is performing multiple roles, such as a small business
server that is serving as a domain controller, file server, print server, and application server, performance may be
substantially slowed. Additionally, if you configure computers to ignore all unsigned SMB communications, older
applications and operating systems cannot connect. However, if you completely disable all SMB signing, devices
are vulnerable to session-hijacking attacks.
Related topics
Security Options
communications (if client agrees)
Applies to
Windows 10
network server: Digitally sign communications (if client agrees) security policy setting.
Reference
The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other
If server-side SMB signing is required, a client device will not be able to establish a session with that server,
to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing
is enabled only on domain controllers.
If server-side SMB signing is enabled, SMB packet signing will be negotiated with client computers that have
SMB signing enabled.
communications:
Possible values
Enabled
Disabled
Not defined
Best practices
Enable Microsoft network server: Digitally sign communications (always).
Enable Microsoft Network Server: Digitally Sign Communications (If Client Agrees).
operating systems.
Location
Default values
Policy management
Restart requirement
Vulnerability
objectionable actions. Alternatively, the attacker could pose as the server or client computer after legitimate
NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If
either side fails the authentication process, data transmission does not take place.
Countermeasure
Potential impact
SMB file and print-sharing protocol support mutual authentication. This prevents session hijacking attacks and
supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this
authentication by placing a digital signature into each SMB, which is then verified by the client and the server.
verified. If these settings are enabled on a server that is performing multiple roles, such as a small business
server that is serving as a domain controller, file server, print server, and application server, performance may be
substantially slowed. Additionally, if you configure computers to ignore all unsigned SMB communications, older
applications and operating systems cannot connect. However, if you completely disable all SMB signing,
computers are vulnerable to session-hijacking attacks.
Related topics
Security Options
Microsoft network server: Disconnect clients when
logon hours expire
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Microsoft network server:
Disconnect clients when logon hours expire security policy setting.
Reference
This policy setting enables or disables the forced disconnection of users who are connected to the local device
outside their user account's valid logon hours. It affects the SMB component. If you enable this policy setting, client
computer sessions with the SMB service are forcibly disconnected when the client's logon hours expire. If you
disable this policy setting, established client device sessions are maintained after the client device's logon hours
expire.
Possible values
Enabled
Client device sessions with the SMB service are forcibly disconnected when the client device's logon hours
expire. If logon hours are not used in your organization, enabling this policy setting will have no impact.
Disabled
The system maintains an established client device session after the client device's logon hours have expired.
Not defined
Best practices
If you enable this policy setting, you should also enable Network security: Force logoff when logon hours expire.
Location
Default values

Policy management
Restart requirement
Group Policy
Vulnerability
If your organization configures logon hours for users, it makes sense to enable this policy setting. Otherwise, users
who should not have access to network resources outside of their logon hours can continue to use those resources
with sessions that were established during allowed hours.
Countermeasure
Enable the Microsoft network server: Disconnect clients when logon hours expire setting.
Potential impact
If logon hours are not used in your organization, this policy setting has no impact. If logon hours are used, existing
user sessions are forcibly terminated when their logon hours expire.
Related topics
Security Options
Microsoft network server: Server SPN target name
validation level
Applies to
Windows 10
Describes the best practices, location, and values, policy management and security considerations for the
Microsoft network server: Server SPN target name validation level security policy setting.
Reference
This policy setting controls the level of validation that a server with shared folders or printers performs on the
service principal name (SPN) that is provided by the client device when the client device establishes a session by
using the Server Message Block (SMB) protocol. The level of validation can help prevent a class of attacks against
SMB services (referred to as SMB relay attacks). This setting affects both SMB1 and SMB2.
Servers that use SMB provide availability to their file systems and other resources, such as printers, to networked
client devices. Most servers that use SMB validate user access to resources by using NT Domain authentication
(NTLMv1 and NTLMv2) and the Kerberos protocol.
Possible values
The options for validation levels are:
Off
The SPN from a SMB client is not required or validated by the SMB server.
Accept if provided by client
The SMB server will accept and validate the SPN provided by the SMB client and allow a session to be
established if it matches the SMB servers list of SPNs. If the SPN does not match, the session request for
that SMB client will be denied.
Required from client
The SMB client must send a SPN name in session setup, and the SPN name provided must match the SMB
server that is being requested to establish a connection. If no SPN is provided by the client device, or the
SPN provided does not match, the session is denied.
The default setting is Off.
Best practices
This setting affects the server SMB behavior, and its implementation should be carefully evaluated and tested to
prevent disruptions to file and print serving capabilities.
Note: All Windows operating systems support a client-side SMB component and a server-side SMB
component.
Location
Default values
Default domain policy Off
Default domain controller policy Off
Stand-alone server default settings Off
Domain controller effective default settings Validation level check not implemented
Member server effective default settings Validation level check not implemented
Effective GPO default settings on client computers Validation level check not implemented
Policy management
Restart requirement
None.
Group Policy
Vulnerability
This policy setting controls the level of validation that a server with shared folders or printers performs on the
service principal name (SPN) that is provided by the client device when the client device establishes a session by
using the SMB protocol. The level of validation can help prevent a class of attacks against SMB servers (referred to
as SMB relay attacks). This setting will affect both SMB1 and SMB2.
Countermeasure
For countermeasures that are appropriate to your environment, see Possible values above.
Potential impact
All Windows operating systems support a client-side SMB component and a server-side SMB component. This
setting affects the server SMB behavior, and its implementation should be carefully evaluated and tested to prevent
disruptions to file and print serving capabilities.
Because the SMB protocol is widely deployed, setting the options to Accept if provided by client or Required
from client will prevent some clients from successfully authenticating to some servers in your environment.
Related topics
Security Options
Network access: Allow anonymous SID/Name
translation
Applies to
Windows 10
Describes the best practices, location, values, policy management and security considerations for the Network
access: Allow anonymous SID/Name translation security policy setting.
Reference
This policy setting enables or disables the ability of an anonymous user to request security identifier (SID) attributes
for another user.
If this policy setting is enabled, a user might use the well-known Administrators SID to get the real name of the
built-in Administrator account, even if the account has been renamed. That person might then use the account
name to initiate a brute-force password-guessing attack.
Possible values
Enabled
An anonymous user can request the SID attribute for another user. An anonymous user with knowledge of
an administrator's SID could contact a computer that has this policy enabled and use the SID to get the
administrator's name. This setting affects the SID-to-name translation as well as the name-to-SID translation
Disabled
Prevents an anonymous user from requesting the SID attribute for another user.
Not defined
Best practices
Set this policy to Disabled. This is the default value on member computers; therefore, it will have no impact on
them. The default value for domain controllers is Enabled.
Location
Default values
Default Domain Controller Policy Note defined

Operating system version differences

The default value of this setting has changed between operating systems as follows:
The default on domain controllers running Windows Server 2003 R2 or earlier was set to Enabled.
The default on domain controllers running Windows Server 2008 and later is set to Disabled.
Policy management
Restart requirement
Group Policy
Modifying this setting may affect compatibility with client computers, services, and applications.
Vulnerability
If this policy setting is enabled, a user with local access could use the well-known Administrator's SID to learn the
real name of the built-in Administrator account, even if it has been renamed. That person could then use the
account name to initiate a password-guessing attack.
Countermeasure
Disable the Network access: Allow anonymous SID/Name translation setting.
Potential impact
Disabled is the default configuration for this policy setting on member devices; therefore, it has no impact on them.
The default configuration for domain controllers is Enabled.
Related topics
Security Options
Network access: Do not allow anonymous
enumeration of SAM accounts
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Network access: Do not allow
anonymous enumeration of SAM accounts security policy setting.
Reference
This policy setting determines which additional permissions will be assigned for anonymous connections to the
device. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain
accounts and network shares. This is convenient, for example, when an administrator wants to give access to users
in a trusted domain that does not maintain a reciprocal trust.
This policy setting has no impact on domain controllers.
Possible values
Enabled
Disabled
No additional permissions can be assigned by the administrator for anonymous connections to the device.
Anonymous connections will rely on default permissions.
Not defined
Location
Default values

Policy management
Restart requirement
Policy conflicts
Even with this policy setting enabled, anonymous users will have access to resources with permissions that
explicitly include the built-in group, ANONYMOUS LOGON (on systems earlier than Windows Server 2008 and
Windows Vista).
Group Policy
This policy has no impact on domain controllers.
Vulnerability
An unauthorized user could anonymously list account names and use the information to perform social
engineering attacks or attempt to guess passwords. Social engineering attackers try to deceive users in some way
to obtain passwords or some form of security information.
Countermeasure
Enable the Network access: Do not allow anonymous enumeration of SAM accounts setting.
Potential impact
It is impossible to grant access to users of another domain across a one-way trust because administrators in the
trusting domain are unable to enumerate lists of accounts in the other domain. Users who access file and print
servers anonymously are unable to list the shared network resources on those servers; the users must be
authenticated before they can view the lists of shared folders and printers.
Related topics
Security Options
Network access: Do not allow anonymous
enumeration of SAM accounts and shares
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Network access: Do not allow
anonymous enumeration of SAM accounts and shares security policy setting.
Reference
This policy setting determines which additional permissions will be assigned for anonymous connections to the
device. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain
accounts and network shares. This is convenient, for example, when an administrator wants to give access to users
in a trusted domain that does not maintain a reciprocal trust. However, even with this policy setting enabled,
anonymous users will have access to resources with permissions that explicitly include the built-in group,
ANONYMOUS LOGON.
This policy setting has no impact on domain controllers. Misuse of this policy setting is a common error that can
cause data loss or problems with data access or security.
Possible values
Enabled
Disabled
No additional permissions can be assigned by the administrator for anonymous connections to the device.
Anonymous connections will rely on default permissions. However, an unauthorized user could
anonymously list account names and use the information to attempt to guess passwords or perform social-
engineering attacks.
Not defined
Location
Default values

Policy management
Restart requirement
Policy conflicts
Even with this policy setting enabled, anonymous users will have access to resources with permissions that
explicitly include the built-in group, ANONYMOUS LOGON (on systems earlier than Windows Server 2008 and
Windows Vista).
Group Policy
This policy has no impact on domain controllers.
Vulnerability
An unauthorized user could anonymously list account names and shared resources and use the information to
attempt to guess passwords or perform social-engineering attacks.
Countermeasure
Enable the Network access: Do not allow anonymous enumeration of SAM accounts and shares setting.
Potential impact
It is impossible to grant access to users of another domain across a one-way trust because administrators in the
trusting domain are unable to enumerate lists of accounts in the other domain. Users who access file and print
servers anonymously are unable to list the shared network resources on those servers; the users must be
authenticated before they can view the lists of shared folders and printers.
Related topics
Security Options
Network access: Do not allow storage of passwords
and credentials for network authentication
Applies to
Windows 10
access: Do not allow storage of passwords and credentials for network authentication security policy
setting.
Reference
This security setting determines whether Credential Manager saves passwords and credentials for later use when it
gains domain authentication.
Possible values
Enabled
Credential Manager does not store passwords and credentials on the device
Disabled
Credential Manager will store passwords and credentials on this computer for later use for domain
authentication.
Not defined
Best practices
It is a recommended practice to disable the ability of the Windows operating system to cache credentials on any
device where credentials are not needed. Evaluate your servers and workstations to determine the requirements.
Cached credentials are designed primarily to be used on laptops that require domain credentials when
disconnected from the domain.
Location
Default values

Policy management
Restart requirement
A restart of the device is required before this policy will be effective when changes to this policy are saved locally or
Group Policy
Vulnerability
Passwords that are cached can be accessed by the user when logged on to the device. Although this information
may sound obvious, a problem can arise if the user unknowingly runs malicious software that reads the passwords
and forwards them to another, unauthorized user.
Note: The chances of success for this exploit and others that involve malicious software are reduced
significantly for organizations that effectively implement and manage an enterprise antivirus solution
combined with sensible software restriction policies.
Regardless of what encryption algorithm is used to encrypt the password verifier, a password verifier can be
overwritten so that an attacker can authenticate as the user to whom the verifier belongs. Therefore, the
administrator's password may be overwritten. This procedure requires physical access to the device. Utilities exist
that can help overwrite the cached verifier. By using one of these utilities, an attacker can authenticate by using the
overwritten value.
Overwriting the administrator's password does not help the attacker access data that is encrypted by using that
password. Also, overwriting the password does not help the attacker access any Encrypting File System (EFS) data
that belongs to other users on that device. Overwriting the password does not help an attacker replace the verifier,
because the base keying material is incorrect. Therefore, data that is encrypted by using Encrypting File System or
by using the Data Protection API (DPAPI) will not decrypt.
Countermeasure
Enable the Network access: Do not allow storage of passwords and credentials for network authentication
setting.
To limit the number of changed domain credentials that are stored on the computer, set the cachedlogonscount
registry entry. By default, the operating system caches the verifier for each unique user's ten most recent valid
logons. This value can be set to any value between 0 and 50. By default, all versions of the Windows operating
system remember 10 cached logons, except Windows Server 2008 and later, which are set at 25.
When you try to log on to a domain from a Windows-based client device, and a domain controller is unavailable,
you do not receive an error message. Therefore, you may not notice that you logged on with cached domain
credentials. You can set a notification of logon that uses cached domain credentials with the ReportDC registry
entry.
Potential impact
Users are forced to type passwords whenever they log on to their Microsoft Account or other network resources
that are not accessible to their domain account. This policy setting should have no impact on users who access
network resources that are configured to allow access with their Active Directorybased domain account.
Related topics
Security Options
Network access: Let Everyone permissions apply to
anonymous users
Applies to
Windows 10
access: Let Everyone permissions apply to anonymous users security policy setting.
Reference
This policy setting determines what additional permissions are granted for anonymous connections to the device. If
you enable this policy setting, anonymous users can enumerate the names of domain accounts and shared folders
and perform certain other activities. This capability is convenient, for example, when an administrator wants to
grant access to users in a trusted domain that does not maintain a reciprocal trust.
By default, the token that is created for anonymous connections does not include the Everyone SID. Therefore,
permissions that are assigned to the Everyone group do not apply to anonymous users.
Possible values
Enabled
The Everyone SID is added to the token that is created for anonymous connections, and anonymous users
can access any resource for which the Everyone group has been assigned permissions.
Disabled
The Everyone SID is removed from the token that is created for anonymous connections.
Not defined
Best practices
Set this policy to Disabled.
Location
Computer Configuration\Windows Settings\Security Settings\Local Polices\Security Options
Default values

Policy management
Restart requirement
Vulnerability
An unauthorized user could anonymously list account names and shared resources and use the information to
attempt to guess passwords, perform social engineering attacks, or launch DoS attacks.
Countermeasure
Disable the Network access: Let Everyone permissions apply to anonymous users setting.
Potential impact
Related topics
Security Options
Network access: Named Pipes that can be accessed
anonymously
Applies to
Windows 10
access: Named Pipes that can be accessed anonymously security policy setting.
Reference
This policy setting determines which communication sessions, or pipes, have attributes and permissions that allow
anonymous access.
Restricting access over named pipes such as COMNAP and LOCATOR helps prevent unauthorized access to the
network.
Possible values
User-defined list of shared folders
Not defined
Best practices
Set this policy to a null value; that is, enable the policy setting, but do not enter named pipes in the text box. This
will disable null session access over named pipes, and applications that rely on this feature or on
unauthenticated access to named pipes will no longer function.
Location
Default values
Default Domain Controller Policy Netlogon, samr, lsarpc
Stand-Alone Server Default Settings Null
DC Effective Default Settings Netlogon, samr, lsarpc

Policy management
This section describes different features and tools available to help you manage this policy.
Restart requirement
Group Policy
For this policy setting to take effect, you must also enable the Network access: Restrict anonymous access to
Named Pipes and Shares setting.
Vulnerability
You can restrict access over named pipes such as COMNAP and LOCATOR to help prevent unauthorized access to
the network. The following list describes available named pipes and their purpose. These pipes were granted
anonymous access in earlier versions of Windows and some legacy applications may still use them.
NAMED PIPE PURPOSE
COMNAP SNABase named pipe. Systems network Architecture (SNA) is a

collection of network protocols that were originally developed
for IBM mainframe computers.
COMNODE SNA Server named pipe.
SQL\QUERY Default named pipe for SQL Server.
SPOOLSS Named pipe for the Print Spooler service.
EPMAPPER End Point Mapper named pipe.
LOCATOR Remote Procedure Call Locator service named pipe.
TrlWks Distributed Link Tracking Client named pipe.
TrkSvr Distributed Link Tracking Server named pipe.
Countermeasure
Configure the Network access: Named Pipes that can be accessed anonymously setting to a null value
(enable the setting but do not specify named pipes in the text box).
Potential impact
This configuration disables null-session access over named pipes, and applications that rely on this feature or on
unauthenticated access to named pipes no longer function. This may break trust between Windows Server 2003
domains in a mixed mode environment.
Related topics
Security Options
Applies to
Windows 10
access: Remotely accessible registry paths security policy setting.
Reference
This policy setting determines which registry paths are accessible when an application or process references the
WinReg key to determine access permissions.
The registry is a database for device configuration information, much of which is sensitive. A malicious user can use
the registry to facilitate unauthorized activities. To reduce the risk of this happening, suitable access control lists
(ACLs) are assigned throughout the registry to help protect it from access by unauthorized users.
To allow remote access, you must also enable the Remote Registry service.
Possible values
User-defined list of paths
Not Defined
Best practices
Set this policy to a null value; that is, enable the policy setting but do not enter any paths in the text box. Remote
management tools, such as the Microsoft Baseline Security Analyzer and Configuration Manager, require
remote access to the registry. Removing the default registry paths from the list of accessible paths might cause
these and other management tools to fail.
Location
Default values
Stand-Alone Server Default Settings See the following registry key combination
DC Effective Default Settings See the following registry key combination
Member Server Effective Default Settings See the following registry key combination
Client Computer Effective Default Settings See the following registry key combination
The combination of all the following registry keys apply to the previous settings:
1. System\CurrentControlSet\Control\ProductOptions
2. System\CurrentControlSet\Control\Server Applications
3. Software\Microsoft\Windows NT\CurrentVersion
Policy management
Restart requirement
Vulnerability
An attacker could use information in the registry to facilitate unauthorized activities. To reduce the risk of such an
attack, suitable ACLs are assigned throughout the registry to help protect it from access by unauthorized users.
Countermeasure
Configure the Network access: Remotely accessible registry paths setting to a null value (enable the setting,
but do not enter any paths in the text box).
Potential impact
Remote management tools such as the Microsoft Baseline Security Analyzer (MBSA) and Configuration Manager
require remote access to the registry to properly monitor and manage those computers. If you remove the default
registry paths from the list of accessible ones, such remote management tools could fail.
Note: If you want to allow remote access, you must also enable the Remote Registry service.
Related topics
Security Options
and subpaths
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Network access: Remotely
accessible registry paths and subpaths security policy setting.
Reference
This policy setting determines which registry paths and subpaths are accessible when an application or process
references the WinReg key to determine access permissions.
The registry is a database for device configuration information, much of which is sensitive. A malicious user can use
it to facilitate unauthorized activities. The chance of this happening is reduced by the fact that the default ACLs that
are assigned throughout the registry are fairly restrictive, and they help protect it from access by unauthorized
users.
To allow remote access, you must also enable the Remote Registry service.
Possible values
User-defined list of paths
Not Defined
Best practices
Set this policy to a null value; that is, enable the policy setting, but do not enter any paths in the text box. Remote
management tools, such as the Microsoft Baseline Security Analyzer and Configuration Manager, require
remote access to the registry. Removing the default registry paths from the list of accessible paths might cause
these and other management tools to fail.
Location
Default values
Stand-Alone Server Default Settings See the following registry key combination
DC Effective Default Settings See the following registry key combination

Member Server Effective Default Settings See the following registry key combination
Client Computer Effective Default Settings See the following registry key combination
The combination of all the following registry keys apply to the previous settings:
1. System\CurrentControlSet\Control\Print\Printers
2. System\CurrentControlSet\Services\Eventlog
3. Software\Microsoft\OLAP Server
4. Software\Microsoft\Windows NT\CurrentVersion\Print
5. Software\Microsoft\Windows NT\CurrentVersion\Windows
6. System\CurrentControlSet\Control\ContentIndex
7. System\CurrentControlSet\Control\Terminal Server
8. System\CurrentControlSet\Control\Terminal Server\UserConfig
9. System\CurrentControlSet\Control\Terminal Server\DefaultUserConfiguration
10. Software\Microsoft\Windows NT\CurrentVersion\Perflib
11. System\CurrentControlSet\Services\SysmonLog
Policy management
Restart requirement
Vulnerability
The registry contains sensitive device configuration information that could be used by an attacker to facilitate
unauthorized activities. The fact that the default ACLs that are assigned throughout the registry are fairly restrictive
and help to protect the registry from access by unauthorized users reduces the risk of such an attack.
Countermeasure
Configure the Network access: Remotely accessible registry paths and sub-paths setting to a null value
(enable the setting but do not enter any paths in the text box).
Potential impact
Remote management tools such as MBSA and Configuration Manager require remote access to the registry to
properly monitor and manage those computers. If you remove the default registry paths from the list of accessible
ones, such remote management tools could fail.
Note: If you want to allow remote access, you must also enable the Remote Registry service.
Related topics
Security Options
Network access: Restrict anonymous access to
Named Pipes and Shares
Applies to
Windows 10
access: Restrict anonymous access to Named Pipes and Shares security policy setting.
Reference
This policy setting enables or disables the restriction of anonymous access to only those shared folders and pipes
that are named in the Network access: Named pipes that can be accessed anonymously and Network access:
Shares that can be accessed anonymously settings. The setting controls null session access to shared folders on
your computers by adding RestrictNullSessAccess with the value 1 in the registry key
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters. This registry
value toggles null session shared folders on or off to control whether the Server service restricts unauthenticated
clients' access to named resources.
Null sessions are a weakness that can be exploited through the various shared folders on the devices in your
environment.
Possible values
Enabled
Disabled
Not defined
Best practices
Set this policy to Enabled. Enabling this policy setting restricts null session access to unauthenticated users to all
server pipes and shared folders except those listed in the NullSessionPipes and NullSessionShares registry
entries.
Location
Default values

Policy management
Restart requirement
Vulnerability
Null sessions are a weakness that can be exploited through shared folders (including the default shared folders) on
devices in your environment.
Countermeasure
Enable the Network access: Restrict anonymous access to Named Pipes and Shares setting.
Potential impact
You can enable this policy setting to restrict null-session access for unauthenticated users to all server pipes and
shared folders except those that are listed in the NullSessionPipes and NullSessionShares entries.
Related topics
Security Options
Network access: Restrict clients allowed to make remote
calls to SAM
Applies to
Windows 10, version 1607 and later
Windows 10, version 1511 with KB 4103198 installed
Windows 10, version 1507 with KB 4012606 installed
Windows 8.1 with KB 4102219 installed
Windows 7 with KB 4012218 installed
Windows Server 2016
Windows Server 2012 R2 withKB 4012219 installed
Windows Server 2012 with KB 4012220 installed
Windows Server 2008 R2 with KB 4012218 installed
The Network access: Restrict clients allowed to make remote calls to SAM security policy setting controls which users
can enumerate users and groups in the local Security Accounts Manager (SAM) database and Active Directory. The setting was
first supported by Windows 10 version 1607 and Windows Server 2016 (RTM) and can be configured on earlier Windows
client and server operating systems by installing updates from the the KB articles listed in Applies to section of this topic.
This topic describes the default values for this security policy setting in different versions of Windows. By default, computers
beginning with Windows 10 version 1607 and Windows Server 2016 are more restrictive than earlier versions of Windows.
This means that if you have a mix of computers, such as member servers that run both Windows Server 2016 and Windows
Server 2012 R2, the servers that run Windows Server 2016 may fail to enumerate accounts by default where the servers that
run Windows Server 2012 R2 succeed.
This topic also covers related events, and how to enable audit mode before constraining the security principals that are allowed
to remotely enumerate users and groups so that your environment remains secure without impacting application
compatibility.
Reference
The SAMRPC protocol makes it possible for a low privileged user to query a machine on a network for data. For example, a
user can use SAMRPC to enumerate users, including privileged accounts such as local or domain administrators, or to
enumerate groups and group memberships from the local SAM and Active Directory. This information can provide important
context and serve as a starting point for an attacker to compromise a domain or networking environment.
To mitigate this risk, you can configure the Network access: Restrict clients allowed to make remote calls to SAM
security policy setting to force the security accounts manager (SAM) to do an access check against remote calls. The access
check allows or denies remote RPC connections to SAM and Active Directory for users and groups that you define.
By default, the Network access: Restrict clients allowed to make remote calls to SAM security policy setting is not
defined. If you define it, you can edit the default Security Descriptor Definition Language (SDDL) string to explicitly allow or
deny users and groups to make remote calls to the SAM. If the policy setting is left blank after the policy is defined, the policy is
not enforced.
The default security descriptor on computers beginning with Windows 10 version 1607 and Windows Server 2016 allows only
the local (built-in) Administrators group remote access to SAM on non-domain controllers, and allows Everyone access on
domain controllers. You can edit the default security descriptor to allow or deny other users and groups, including the built-in
Administrators.
The default security descriptor on computers that run earlier versions of Windows does not restrict any remote calls to SAM,
but an administrator can edit the security descriptor to enforce restrictions. This less restrictive default allows for testing the
impact of enabling restrictions on existing applications.
Policy and Registry Names
Policy Name Network access: Restrict clients allowed to make remote calls to SAM
Location Computer Configuration|Windows Settings|Security Settings|Local

Policies|Security Options
Possible values
- Not defined
- Defined, along with the security descriptor for users and groups
who are allowed or denied to use SAMRPC to remotely access either
the local SAM or Active Directory.
Registry location HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\RestrictRemoteSam
Registry type REG_SZ
Registry value A string that will contain the SDDL of the security descriptor to be
deployed.
The Group Policy setting is only available on computers that run Windows Server 2016 or Windows 10, version 1607 and later.
This is the only option to configure this setting by using a user interface (UI).
On computers that run earlier versions of Windows, you need to edit the registry setting directly or use Group Policy
Preferences. To avoid setting it manually in this case, you can configure the GPO itself on a computer that runs Windows Server
2016 or Windows 10, version 1607 or later and have it apply to all computers within the scope of the GPO because the same
registry key exists on every computer after the corresponding KB is installed.
NOTE
This policy is implemented similarly to other "Network access" policies in that there is a single policy element at the registry path listed.
There is no notion of a local policy versus an enterprise policy; there is just one policy setting and whichever writes last wins.
For example, suppose a local administrator configures this setting as part of a local policy using the Local Security Policy snap-in
(Secpol.msc), which edits that same registry path. If an enterprise administrator configures this setting as part of an enterprise GPO, that
enterprise GPO will overwrite the same registry path.
Default values
Beginning with Windows 10, version 1607 and Windows Server 2016, computers have hard-coded and more restrictive default
values than earlier versions of Windows. The different default values help strike a balance where recent Windows versions are
more secure by default and older versions dont undergo any disruptive behavior changes. Administrators can test whether
applying the same restriction earlier versions of Windows will cause compatibility problems for existing applications before
implementing this security policy setting in a production environment.
In other words, the hotfix in each KB article provides the necessary code and functionality, but you need to configure the
restriction after you install the hotfixno restrictions are enabled by default after the hotfix is installed on earlier versions of
Windows.
DEFAULT SDDL TRANSLATED SDDL COMMENTS
Windows Server 2016 domain - Everyone has read permissions

controller (reading Active to preserve compatibility.
Directory)
Earlier domain controller - - No access check is performed by

default.
DEFAULT SDDL TRANSLATED SDDL COMMENTS
Windows 10, version 1607 non- (O:SYG:SYD:(A;;RC;;;BA) Owner: NTAUTHORITY/SYSTEM Grants RC access
domain controller (WellKnownGroup) (S-1-5-18) (READ_CONTROL, also known
Primary group: as STANDARD_RIGHTS_READ)
NTAUTHORITY/SYSTEM only to members of the local
(WellKnownGroup) (S-1-5-18) (built-in) Administrators group.
DACL:
Revision: 0x02
Size: 0x0020
Ace Count: 0x001
Ace[00]-----------------------
--
AceType:0x00
(ACCESS_ALLOWED_ACE_TYPE
)
AceSize:0x0018
InheritFlags:0x00
Access Mask:0x00020000
AceSid:
BUILTIN\Administrators (Alias)
(S-1-5-32-544)
SACL: Not present
Earlier non-domain controller - - No access check is performed by

default.
Policy management
This section explains how to configure audit-only mode, how to analyze related events that are logged when the Network
access: Restrict clients allowed to make remote calls to SAM security policy setting is enabled, and how to configure
event throttling to prevent flooding the event log.
Audit only mode
Audit only mode configures the SAMRPC protocol to do the access check against the currently configured security descriptor
but will not fail the call if the access check fails. Instead, the call will be allowed, but SAMRPC will log an event describing what
would have happened if the feature had been enabled. This provides administrators a way to test their applications before
enabling the policy in production. Audit only mode is not configured by default. To configure it, add the following registry
setting.
REGISTRY DETAILS
Path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Setting RestrictRemoteSamAuditOnlyMode
Data Type REG_DWORD
Value 1
Notes This setting cannot be added or removed by using predefined Group

Policy settings.
Administrators may create a custom policy to set the registry value if
needed.
SAM responds dynamically to changes in this registry value without a
reboot.
You can use the Events 16962 - 16969 Reader script to parse the
event logs, as explained in the next section.
Related events
There are corresponding events that indicate when remote calls to the SAM are restricted, what accounts attempted to read
from the SAM database, and more. The following workflow is recommended to identify applications that may be affected by
restricting remote calls to SAM:
1. Dump event logs to a common share.
2. Parse them with the Events 16962 - 16969 Reader script.
3. Review Event IDs 16962 to 16969, as listed in the following table, in the System log with event source Directory-Service-
SAM.
4. Identify which security contexts are enumerating users or groups in the SAM database.
5. Prioritize the callers, determine if they should be allowed or not, then include the allowed callers in the SDDL string.
EVENT ID EVENT MESSAGE TEXT EXPLANATION
16962 "Remote calls to the SAM database are Emit event when registry SDDL is absent,
being restricted using the default security causing fallback to default hard-coded SDDL
descriptor: %1.%n " (event should include a copy of the default
SDDL).
%2- "Default SD String:"
16963 Message Text: "Remote calls to the SAM Emit event when a new SDDL is read from
database are being restricted using the the registry (either on startup or change)
configured registry security descriptor: and is considered valid. The event includes
%1.%n" the source and a copy of the queried SDDL.
%1 - "Registry SD String:"
16964 "The registry security descriptor is Emit event when registry SDDL is mal-
malformed: %1.%n Remote calls to the SAM formed, causing fallback to default hard-
database are being restricted using the coded SDDL (event should include a copy of
default security descriptor: %2.%n" the default SDDL).
%1- "Malformed SD String:"

%2- "Default SD String:"
16965 Message Text: "A remote call to the SAM Emit event when access is denied to a
database has been denied.%nClient SID: remote client. Event should include identity
%1%n Network address: %2%n" and network address of the client.
%1- "Client SID:" %2- "Client Network

Address
16966 Audit Mode is enabled- Emit event whenever training mode (see
16968) is enabled or disabled.
Message Text: "Audit only mode is now
enabled for remote calls to the SAM
database. SAM will log an event for clients
who would have been denied access in
normal mode. %n"
16967 Audit Mode is disabled- Emit event whenever training mode (see
16968) is enabled or disabled.
Message Text: "Audit only mode is now
disabled for remote calls to the SAM
database.%n For more information"
16968 Message Text: "Audit only mode is currently Emit event when access would have been
enabled for remote calls to the SAM denied to a remote client, but was allowed
database.%n The following client would have through due to training mode being
been normally denied access:%nClient SID: enabled. Event should include identity and
%1 from network address: %2. %n" network address of the client.
%1- "Client SID:"
%2- "Client Network Address:"
EVENT ID EVENT MESSAGE TEXT EXPLANATION
16969 Message Text: "%2 remote calls to the SAM Throttling may be necessary for some
database have been denied in the past %1 events due to expected high volume on
seconds throttling window.%n some servers causing the event log to wrap.
"%1- "Throttle window:"
%2- "Suppressed Message Count:" Note: There is no throttling of events when
audit mode is enabled. Environments with a
large number of low-privilege and
anonymous querying of the remote
database may see large numbers of events
logged to the System log. For more info, see
the Event Throttling section.
Compare the security context attempting to remotely enumerate accounts with the default security descriptor. Then edit the
security descriptor to add accounts that require remote access.
Event Throttling
A busy server can flood event logs with events related to the remote enumeration access check. To prevent this, access-denied
events are logged once every 15 minutes by default. The length of this period is controlled by the following registry value.
REGISTRY PATH SYSTEM\CURRENTCONTROLSET\CONTROL\LSA\
Setting RestrictRemoteSamEventThrottlingWindow
Data Type DWORD
Value seconds
Reboot Required? No
Notes Default is 900 seconds 15mins.

The throttling uses a suppressed events counter which starts at 0
and gets incremented during the throttling window.
For example, X events were suppressed in the last 15 minutes.
The counter is restarted after the event 16969 is logged.
Restart requirement
Restarts are not required to enable, disable or modify the Network access: Restrict clients allowed to make remote calls
to SAM security policy setting, including audit only mode. Changes become effective without a device restart when they are
saved locally or distributed through Group Policy.
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and
the possible negative consequences of countermeasure implementation.
Vulnerability
The SAMRPC protocol has a default security posture that makes it possible for low-privileged attackers to query a machine on
the network for data that is critical to their further hacking and penetration plans.
The following example illustrates how an attacker might exploit remote SAM enumeration:
1. A low-privileged attacker gains a foothold on a network.
2. The attacker then queries all machines on the network to determine which ones have a highly privileged domain user
configured as a local administrator on that machine.
3. If the attacker can then find any other vulnerability on that machine that allows taking it over, the attacker can then squat on
the machine waiting for the high-privileged user to logon and then steal or impersonate those credentials.
Countermeasure
You can mitigate this vulnerability by enabling the Network access: Restrict clients allowed to make remote calls to SAM
security policy setting and configuring the SDDL for only those accounts that are explicitly allowed access.
Potential impact
If the policy is defined, admin tools, scripts and software that formerly enumerated users, groups and group membership may
fail. To identify accounts that may be affected, test this setting in audit only mode.
Related Topics
Security Options
SAMRi10 - Hardening SAM Remote Access in Windows 10/Server 2016
Network access: Shares that can be accessed
anonymously
Applies to
Windows 10
access: Shares that can be accessed anonymously security policy setting.
Reference
This policy setting determines which shared folders can be accessed by anonymous users.
Possible values
User-defined list of shared folders
Not Defined
Best practices
Set this policy to a null value. There should be little impact because this is the default value. All users will have to
be authenticated before they can access shared resources on the server.
Location
Default values
Policy management
Restart requirement
Vulnerability
Any shared folders that are listed can be accessed by any network user, which could lead to the exposure or
corruption of sensitive data.
Countermeasure
Configure the Network access: Shares that can be accessed anonymously setting to a null value.
Potential impact
There should be little impact because this is the default configuration. Only authenticated users have access to
shared resources on the server.
Related topics
Security Options
Network access: Sharing and security model for local
accounts
Applies to
Windows 10
access: Sharing and security model for local accounts security policy setting.
Reference
This policy setting determines how network logons that use local accounts are authenticated. If you configure this
policy setting to Classic, network logons that use local account credentials authenticate with those credentials. If
you configure this policy setting to Guest only, network logons that use local accounts are automatically mapped to
the Guest account. The Classic model provides precise control over access to resources, and it enables you to grant
different types of access to different users for the same resource. Conversely, the Guest only model treats all users
equally, and they all receive the same level of access to a given resource, which can be either Read Only or Modify.
Note: This policy setting does not affect network logons that use domain accounts. Nor does this policy setting
affect interactive logons that are performed remotely through services such as Telnet or Remote Desktop
Services. When the device is not joined to a domain, this policy setting also tailors the Sharing and Security
tabs in Windows Explorer to correspond to the sharing and security model that is being used.
When the value of this policy setting is Guest only - local users authenticate as Guest, any user who can access
your device over the network does so with Guest user rights. This means that they will probably be unable to write
to shared folders. Although this does increase security, it makes it impossible for authorized users to access shared
resources on those systems. When the value is Classic - local users authenticate as themselves, local accounts
must be password-protected; otherwise, anyone can use those user accounts to access shared system resources.
Possible values
Classic - Local users authenticate as themselves
Guest only - Local users authenticate as Guest
Not defined
Best practices
1. For network servers, set this policy to Classic - local users authenticate as themselves.
2. On end-user systems, set this policy to Guest only - local users authenticate as Guest.
Location
Default values
Stand-Alone Server Default Settings Classic (local users authenticate as themselves)
DC Effective Default Settings Classic (local users authenticate as themselves)
Member Server Effective Default Settings Classic (local users authenticate as themselves)
Client Computer Effective Default Settings Classic (local users authenticate as themselves)
Policy management
Restart requirement
Group Policy
Vulnerability
With the Guest only model, any user who can authenticate to your device over the network does so with Guest
privileges, which probably means that they do not have Write access to shared resources on that device. Although
this restriction does increase security, it makes it more difficult for authorized users to access shared resources on
those computers because ACLs on those resources must include access control entries (ACEs) for the Guest
account. With the Classic model, local accounts should be password protected. Otherwise, if Guest access is
enabled, anyone can use those user accounts to access shared system resources.
Countermeasure
For network servers, configure the Network access: Sharing and security model for local accounts setting to
Classic local users authenticate as themselves. On end-user computers, configure this policy setting to Guest
only local users authenticate as guest.
Potential impact
Related topics
Security Options
Network security: Allow Local System to use
computer identity for NTLM
Applies to
Windows 10
Describes the location, values, policy management, and security considerations for the Network security: Allow
Local System to use computer identity for NTLM security policy setting.
Reference
When services connect to devices that are running versions of the Windows operating system earlier than
Windows Vista or Windows Server 2008, services that run as Local System and use SPNEGO (Negotiate) that revert
to NTLM will authenticate anonymously. In Windows Server 2008 R2 and Windows 7 and later, if a service
connects to a computer running Windows Server 2008 or Windows Vista, the system service uses the computer
identity.
When a service connects with the device identity, signing and encryption are supported to provide data protection.
(When a service connects anonymously, a system-generated session key is created, which provides no protection,
but it allows applications to sign and encrypt data without errors. Anonymous authentication uses a NULL session,
which is a session with a server in which no user authentication is performed; and therefore, anonymous access is
allowed.)
Possible values
| Setting | Windows Server 2008 and Windows Vista | At least Windows Server 2008 R2 and Windows 7 | | - | - | |
Enabled | Services running as Local System that use Negotiate will use the computer identity. This might cause
some authentication requests between Windows operating systems to fail and log an error.| Services running as
Local System that use Negotiate will use the computer identity. This is the default behavior. | | Disabled| Services
running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously.
This is the default behavior.| Services running as Local System that use Negotiate when reverting to NTLM
authentication will authenticate anonymously.| |Neither|Services running as Local System that use Negotiate when
reverting to NTLM authentication will authenticate anonymously. | Services running as Local System that use
Negotiate will use the computer identity. This might cause some authentication requests between Windows
operating systems to fail and log an error.|
Location
Default values

Domain controller effective default settings Not applicable
Member server effective default settings Not applicable
Policy management
Restart requirement
The policy Network security: Allow LocalSystem NULL session fallback, if enabled, will allow NTLM or Kerberos
authentication to be used when a system service attempts authentication. This will increase the success of
interoperability at the expense of security.
The anonymous authentication behavior is different for Windows Server 2008 and Windows Vista than later
versions of Windows. Configuring and applying this policy setting on those systems might not produce the same
results.
Group Policy
Vulnerability
When a service connects to computers running versions of Windows earlier than Windows Vista or Windows
Server 2008, services that run as Local System and use SPNEGO (Negotiate) that revert to NTLM will use NULL
session. In Windows Server 2008 R2 and Windows 7 and later, if a service connects to a computer running
Windows Server 2008 or Windows Vista, the system service uses the computer identity.
When a service connects with the computer identity, signing and encryption are supported to provide data
protection. When a service connects with a NULL session, a system-generated session key is created, which
provides no protection, but it allows applications to sign and encrypt data without errors.
Countermeasure
You can configure the Network security: Allow Local System to use computer identity for NTLM security
policy setting to allow Local System services that use Negotiate to use the computer identity when reverting to
NTLM authentication.
Potential impact
If you do not configure this policy setting on Windows Server 2008 and Windows Vista, services running as Local
System that use the default credentials will use the NULL session and revert to NTLM authentication for Windows
operating systems earlier than Windows Vista or Windows Server 2008. Beginning with Windows Server 2008 R2
and Windows 7, the system allows Local System services that use Negotiate to use the computer identity when
reverting to NTLM authentication.
Related topics
Security Options
Network security: Allow LocalSystem NULL session
fallback
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the Network security: Allow
LocalSystem NULL session fallback security policy setting.
Reference
This policy affects session security during the authentication process between devices running Windows Server
2008 R2 and Windows 7 and later and those devices running earlier versions of the Windows operating system.
For computers running Windows Server 2008 R2 and Windows 7 and later, services running as Local System
require a service principal name (SPN) to generate the session key. However, if Network security: Allow Local
System to use computer identity for NTLM is set to disabled, services running as Local System will fall back to
using NULL session authentication when they transmit data to servers running versions of Windows earlier than
Windows Vista or Windows Server 2008. NULL session does not establish a unique session key for each
authentication; and thus, it cannot provide integrity or confidentiality protection. The setting Network security:
Allow LocalSystem NULL session fallback determines whether services that request the use of session security
are allowed to perform signature or encryption functions with a well-known key for application compatibility.
Possible values
Enabled
When a service running as Local System connects with a NULL session, a system-generated session key is
created, which provides no protection but allows applications to sign and encrypt data without errors. This
increases application compatibility, but it degrades the level of security.
Disabled
When a service running as Local System connects with a NULL session, session security will be unavailable.
Calls seeking encryption or signing will fail. This setting is more secure, but at the risk of degrading
application incompatibility. Calls that are using the device identity instead of a NULL session will still have
full use of session security.
Not defined. When this policy is not defined, the default takes effect. This is Enabled for versions of the
Windows operating system earlier than Windows Server 2008 R2 and Windows 7, and it is Disabled
otherwise.
Best practices
When services connect with the device identity, signing and encryption are supported to provide data protection.
When services connect with a NULL session, this level of data protection is not provided. However, you will need to
evaluate your environment to determine the Windows operating system versions that you support. If this policy is
enabled, some services may not be able to authenticate.
This policy applies to Windows Server 2008 and Windows Vista (SP1 and later). When your environment no longer
requires support for Windows NT 4, this policy should be disabled. By default, it is disabled in Windows 7 and
Windows Server 2008 R2 and later.
Location
Default values
Domain controller effective default settings Not applicable
Member server effective default settings Not applicable
Effective GPO default settings on client computers Not applicable
Vulnerability
If this setting is Enabled, when a service connects with a NULL session, a system-generated session key is created,
which provides no protection but allows applications to sign and encrypt data without errors. Data that is intended
to be protected might be exposed.
Countermeasure
You can configure the computer to use the computer identity for Local System with the policy Network security:
Allow Local System to use computer identity for NTLM. If that is not possible, this policy can be used to
prevent data from being exposed in transit if it was protected with a well-known key.
Potential impact
If you enable this policy, services that use NULL session with Local System could fail to authenticate because they
will be prohibited from using signing and encryption.
Related topics
Security Options
Network security: Allow PKU2U authentication
requests to this computer to use online identities
Applies to
Windows 10
Describes the best practices, location, and values for the Network Security: Allow PKU2U authentication
requests to this computer to use online identities security policy setting.
Reference
Starting with Windows Server 2008 R2 and Windows 7, the Negotiate Security Support Provider (SSP) supports an
extension SSP, Negoexts.dll. This extension SSP is treated as an authentication protocol by the Windows operating
system, and it supports SSPs from Microsoft, including PKU2U. You can also develop or add other SSPs.
When devices are configured to accept authentication requests by using online IDs, Negoexts.dll calls the PKU2U
SSP on the computer that is used to log on. The PKU2U SSP obtains a local certificate and exchanges the policy
between the peer computers. When validated on the peer computer, the certificate within the metadata is sent to
the logon peer for validation. It associates the user's certificate to a security token, and then the logon process
completes.
Note: The ability to link online IDs can be performed by anyone with an account that has standard users
credentials through Credential Manager.
This policy is not configured by default on domain-joined devices. This would disallow the online identities to be
able to authenticate to the domain-joined computers in Windows 7 and later.
Possible values
Enabled
This will allow authentication to successfully complete between the two (or more) computers that have
established a peer relationship through the use on online IDs. The PKU2U SSP obtains a local certificate and
exchanges the policy between the peer devices. When validated on the peer computer, the certificate within
the metadata is sent to the logon peer for validation. It associates the user's certificate to a security token,
and then the logon process completes.
Disabled
This will prevent online IDs from being used to authenticate the user to another computer in a peer-to-peer
relationship.
Not set. Not configuring this policy prevents online IDs from being used to authenticate the user. This is the
default on domain-joined devices
Best practices
Within a domain, domain accounts should be used for authentication. Set this policy to Disabled or do not
configure this policy to exclude online identities from being used to authenticate.
Location
Default values
Vulnerability
Enabling this policy setting allows a users account on one computer to be associated with an online identity, such
as Microsoft Account, so that account can log on to a peer device (if the peer device is likewise configured) without
the use of a Windows logon account (domain or local). Although this is beneficial for workgroups or home groups,
using this feature in a domain-joined environment might circumvent your established security policies.
Countermeasure
Set this policy to Disabled or do not configure this security policy for domain-joined devices.
Potential impact
If you do not set or disable this policy, the PKU2U protocol will not be used to authenticate between peer devices,
which forces users to follow domain defined access control policies. If you enable this policy, you will allow your
users to authenticate by using local certificates between systems that are not part of a domain that uses PKU2U.
This will allow users to share resources between devices
Related topics
Security Options
Network security: Configure encryption types allowed
for Kerberos Win7 only
Applies to
Windows 10
Describes the best practices, location, values and security considerations for the Network security: Configure
encryption types allowed for Kerberos Win7 only security policy setting.
Reference
This policy setting allows you to set the encryption types that the Kerberos protocol is allowed to use. If it is not
selected, the encryption type will not be allowed. This setting might affect compatibility with client computers or
services and applications. Multiple selections are permitted.
For more information, see article 977321 in the Microsoft Knowledge Base.
The following table lists and explains the allowed encryption types.
ENCRYPTION TYPE DESCRIPTION AND VERSION SUPPORT
DES_CBC_CRC Data Encryption Standard with Cipher Block Chaining using

the Cyclic Redundancy Check function
Supported in Windows 2000 Server, Windows XP, Windows
Server 2003, Windows Vista, and Windows Server 2008. The
Windows 7 and Windows Server 2008 R2 operating systems
do not support DES
DES_CBC_MD5 Data Encryption Standard with Cipher Block Chaining using

the Message-Digest algorithm 5 checksum function
Server 2003, Windows Vista, and Windows Server 2008. The
Windows 7 and Windows Server 2008 R2 operating systems
do not support DES by default.
RC4_HMAC_MD5 Rivest Cipher 4 with Hashed Message Authentication Code

using the Message-Digest algorithm 5 checksum function
Server 2003, Windows Vista, Windows Server 2008, Windows
7, and Windows Server 2008 R2.
AES128_HMAC_SHA1 Advanced Encryption Standard in 128 bit cipher block with

Hashed Message Authentication Code using the Secure Hash
Algorithm (1).
Not supported in Windows 2000 Server, Windows XP, or
Windows Server 2003. Supported in Windows Vista, Windows
Server 2008, Windows 7, and Windows Server 2008 R2.
ENCRYPTION TYPE DESCRIPTION AND VERSION SUPPORT
AES256_HMAC_SHA1 Advanced Encryption Standard in 256 bit cipher block with

Hashed Message Authentication Code using the Secure Hash
Algorithm (1).
Not supported in Windows 2000 Server, Windows XP, or
Windows Server 2003. Supported in Windows Vista, Windows
Server 2008, Windows 7, and Windows Server 2008 R2.
Future encryption types Reserved by Microsoft for additional encryption types that
might be implemented.
Possible values
The encryption type options include:
DES_CBC_CRC
DES_CBC_MD5
RC4_HMAC_MD5
AES128_HMAC_SHA1
AES256_HMAC_SHA1
Future encryption types
As of the release of Windows 7 and Windows Server 2008 R2, this is reserved by Microsoft for additional
encryption types that might be implemented.
Best practices
You must analyze your environment to determine which encryption types will be supported and then select those
that meet that evaluation.
Location
Default values
Domain controller effective default settings None of these encryption types that are available in this policy
are allowed.
Member server effective default settings None of these encryption types that are available in this policy
are allowed.
Effective GPO default settings on client computers None of these encryption types that are available in this policy
are allowed.
Vulnerability
Windows Server 2008 R2 and Windows 7 do not support the DES cryptographic suites because stronger ones are
available. To enable Kerberos interoperability with non-Windows versions of the Kerberos protocol, these suites can
be enabled. However, doing so might open attack vectors on computers running Windows Server 2008 R2 and
Windows 7. You can also disable DES for your computers running Windows Vista and Windows Server 2008.
Countermeasure
Do not configure this policy. This will force the computers running Windows Server 2008 R2 and Windows 7 to use
the AES or RC4 cryptographic suites.
Potential impact
If you do not select any of the encryption types, computers running Windows Server 2008 R2 and Windows 7
might have Kerberos authentication failures when connecting with computers running non-Windows versions of
the Kerberos protocol.
If you do select any encryption type, you will lower the effectiveness of encryption for Kerberos authentication but
you will improve interoperability with computers running older versions of Windows. Contemporary non-Windows
implementations of the Kerberos protocol support RC4 and AES 128-bit and AES 256-bit encryption. Most
implementations, including the MIT Kerberos protocol and the Windows Kerberos protocol, are deprecating DES
encryption.
Related topics
Security Options
Network security: Do not store LAN Manager hash
value on next password change
Applies to
Windows 10
security: Do not store LAN Manager hash value on next password change security policy setting.
Reference
This policy setting determines whether LAN Manager is prevented from storing hash values for the new password
the next time the password is changed. Hash values are a representation of the password after the encryption
algorithm is applied that corresponds to the format that is specified by the algorithm. To decrypt the hash value, the
encryption algorithm must be determined and then reversed. The LAN Manager hash is relatively weak and prone
to attack compared to the cryptographically stronger NTLM hash. Because the LM hash is stored on the local device
in the security database, the passwords can be compromised if the security database, Security Accounts Manager
(SAM), is attacked.
By attacking the SAM file, attackers can potentially gain access to user names and password hashes. Attackers can
use a password-cracking tool to determine what the password is. After they have access to this information, they
can use it to gain access to resources on your network by impersonating users. Enabling this policy setting will not
prevent these types of attacks, but it will make them much more difficult.
Possible values
Enabled
Disabled
Not defined
Best practices
1. Set Network security: Do not store LAN Manager hash value on next password change to Enabled.
2. Require all users to set new passwords the next time they log on to the domain so that LAN Manager hashes are
removed.
Location
Default values

Policy management
Restart requirement
Vulnerability
The SAM file can be targeted by attackers who seek access to user names and password hashes. Such attacks use
special tools to discover passwords, which can then be used to impersonate users and gain access to resources on
your network. These types of attacks are not prevented by enabling this policy setting because LAN Manager
hashes are much weaker than NTLM hashes, but it is much more difficult for these attacks to succeed.
Countermeasure
Enable the Network security: Do not store LAN Manager hash value on next password change setting.
Require all users to set new passwords the next time they log on to the domain so that LAN Manager hashes are
removed.
Potential impact
Some non-Microsoft applications might not be able to connect to the system.
Related topics
Security Options
Network security: Force logoff when logon hours
expire
Applies to
Windows 10
security: Force logoff when logon hours expire security policy setting.
Reference
This security setting determines whether to disconnect users who are connected to the local device outside their
user account's valid logon hours. This setting affects the Server Message Block (SMB) component.
This policy setting does not apply to administrator accounts, but it behaves as an account policy. For domain
accounts, there can be only one account policy. The account policy must be defined in the Default Domain Policy,
and it is enforced by the domain controllers that make up the domain. A domain controller always pulls the
account policy from the Default Domain Policy Group Policy Object (GPO), even if there is a different account policy
that is applied to the organizational unit that contains the domain controller. By default, workstations and servers
that are joined to a domain (for example, member devices) also receive the same account policy for their local
accounts. However, local account policies for member devices can be different from the domain account policy by
defining an account policy for the organizational unit that contains the member devices. Kerberos settings are not
applied to member devices.
Possible values
Enabled
When enabled, this policy causes client sessions with the SMB server to be forcibly disconnected when the
client's logon hours expire.
Disabled
When disabled, this policy allows for the continuation of an established client session after the client's logon
hours have expired.
Not defined
Best practices
Set Network security: Force logoff when logon hours expire to Enabled. SMB sessions will be terminated
on member servers when a user's logon time expires, and the user will be unable to log on to the system until
their next scheduled access time begins.
Location
Default values
Default Domain Policy Disabled
Policy management
Restart requirement
Vulnerability
If you disable this policy setting, users can remain connected to the computer outside of their allotted logon hours.
Countermeasure
Enable the Network security: Force logoff when logon hours expire setting. This policy setting does not apply
to administrator accounts.
Potential impact
When a user's logon time expires, SMB sessions terminate. The user cannot log on to the device until the next
scheduled access time commences.
Related topics
Security Options
Network security: LAN Manager authentication level
Applies to
Windows 10
security: LAN Manager authentication level security policy setting.
Reference
This policy setting determines which challenge or response authentication protocol is used for network logons.
LAN Manager (LM) includes client computer and server software from Microsoft that allows users to link personal
devices together on a single network. Network capabilities include transparent file and print sharing, user security
features, and network administration tools. In Active Directory domains, the Kerberos protocol is the default
authentication protocol. However, if the Kerberos protocol is not negotiated for some reason, Active Directory uses
LM, NTLM, or NTLM version 2 (NTLMv2).
LAN Manager authentication includes the LM, NTLM, and NTLMv2 variants, and it is the protocol that is used to
authenticate all client devices running the Windows operating system when they perform the following operations:
Join a domain
Authenticate between Active Directory forests
Authenticate to domains based on earlier versions of the Windows operating system
Authenticate to computers that do not run Windows operating systems, beginning with Windows 2000
Authenticate to computers that are not in the domain
Possible values
Send LM & NTLM responses
Send LM & NTLM - use NTLMv2 session security if negotiated
Send NTLM responses only
Send NTLMv2 responses only
Send NTLMv2 responses only. Refuse LM
Send NTLMv2 responses only. Refuse LM & NTLM
Not Defined
The Network security: LAN Manager authentication level setting determines which challenge/response
authentication protocol is used for network logons. This choice affects the authentication protocol level that clients
use, the session security level that the computers negotiate, and the authentication level that servers accept. The
following table identifies the policy settings, describes the setting, and identifies the security level used in the
corresponding registry setting if you choose to use the registry to control this setting instead of the policy setting.
SETTING DESCRIPTION REGISTRY SECURITY LEVEL
Send LM & NTLM responses Client devices use LM and NTLM 0

authentication, and they never use
NTLMv2 session security. Domain
controllers accept LM, NTLM, and
NTLMv2 authentication.
SETTING DESCRIPTION REGISTRY SECURITY LEVEL
Send LM & NTLM use NTLMv2 Client devices use LM and NTLM 1
session security if negotiated authentication, and they use NTLMv2
session security if the server supports it.
Domain controllers accept LM, NTLM,
and NTLMv2 authentication.
Send NTLM response only Client devices use NTLMv1 2

authentication, and they use NTLMv2
Send NTLMv2 response only Client devices use NTLMv2 3

authentication, and they use NTLMv2
Send NTLMv2 response only. Refuse Client devices use NTLMv2 4

LM authentication, and they use NTLMv2
Domain controllers refuse to accept LM
authentication, and they will accept only
NTLM and NTLMv2 authentication.
Send NTLMv2 response only. Refuse Client devices use NTLMv2 5

LM & NTLM authentication, and they use NTLMv2
Domain controllers refuse to accept LM
and NTLM authentication, and they will
accept only NTLMv2 authentication.
Best practices
Best practices are dependent on your specific security and authentication requirements.
Location
Default values
Stand-Alone Server Default Settings Send NTLMv2 response only
DC Effective Default Settings Send NTLMv2 response only
Member Server Effective Default Settings Send NTLMv2 response only

Policy management
Restart requirement
Group Policy
Modifying this setting may affect compatibility with client devices, services, and applications.
Vulnerability
In Windows 7 and Windows Vista, this setting is undefined. In Windows Server 2008 R2 and later, this setting is
configured to Send NTLMv2 responses only.
Countermeasure
Configure the Network security: LAN Manager Authentication Level setting to Send NTLMv2 responses
only. Microsoft and a number of independent organizations strongly recommend this level of authentication when
all client computers support NTLMv2.
Potential impact
Client devices that do not support NTLMv2 authentication cannot authenticate in the domain and access domain
resources by using LM and NTLM.
Related topics
Security Options
Network security: LDAP client signing requirements
Applies to
Windows 10
This security policy reference topic for the IT professional describes the best practices, location, values, policy
management and security considerations for this policy setting. This information applies to computers running at
least the Windows Server 2008 operating system.
Reference
This policy setting determines the level of data signing that is requested on behalf of client devices that issue LDAP
BIND requests. The levels of data signing are described in the following list:
None. The LDAP BIND request is issued with the caller-specified options.
Negotiate signing. If Transport Layer Security/Secure Sockets Layer (TLS/SSL) has not been started, the LDAP
BIND request is initiated with the LDAP data signing option set in addition to the caller-specified options. If
TLS/SSL has been started, the LDAP BIND request is initiated with the caller-specified options.
Require signing. This level is the same as Negotiate signing. However, if the LDAP server's intermediate
saslBindInProgress response does not indicate that LDAP traffic signing is required, the caller is returned a
message that the LDAP BIND command request failed.
Possible values
None
Negotiate signing
Require signature
Not Defined
Best practices
Set Domain controller: LDAP server signing requirements to Require signature. If you set the server to
require LDAP signatures, you must also set the client devices to do so. Not setting the client devices will prevent
client computers from communicating with the server. This can cause many features to fail, including user
authentication, Group Policy, and logon scripts.
Location
Default values

Stand-Alone Server Default Settings Negotiate signing
DC Effective Default Settings Negotiate signing
Member Server Effective Default Settings Negotiate signing
Client Computer Effective Default Settings Negotiate signing
Policy management
Restart requirement
Group Policy
Modifying this setting may affect compatibility with client devices, services, and applications.
Vulnerability
Unsigned network traffic is susceptible to man-in-the-middle attacks in which an intruder captures the packets
between the client computer and server, modifies them, and then forwards them to the server. For an LDAP server,
this susceptibility means that an attacker could cause a server to make decisions that are based on false or altered
data from the LDAP queries. To lower this risk in your network, you can implement strong physical security
measures to protect the network infrastructure. Also, you can make all types of man-in-the-middle attacks
extremely difficult if you require digital signatures on all network packets by means of IPsec authentication headers.
Countermeasure
Configure the Network security: LDAP server signing requirements setting to Require signature.
Potential impact
If you configure the server to require LDAP signatures, you must also configure the client computers. If you do not
configure the client devices, they cannot communicate with the server, which could cause many features to fail,
including user authentication, Group Policy, and logon scripts.
Related topics
Security Options
Network security: Minimum session security for NTLM
SSP based (including secure RPC) clients
Applies to
Windows 10
security: Minimum session security for NTLM SSP based (including secure RPC) clients security policy
setting.
Reference
This policy setting allows a client device to require the negotiation of 128-bit encryption or NTLMv2 session
security. These values are dependent on the Network security: LAN Manager Authentication Level policy
setting value.
Possible values
Require NTLMv2 session security
The connection fails if the NTLMv2 protocol is not negotiated.
Require 128-bit encryption
The connection fails if strong encryption (128-bit) is not negotiated.
Best practices
Practices in setting this policy are dependent on your security requirements.
Location
Default values
Stand-Alone Server Default Settings Require 128-bit encryption
DC Effective Default Settings Require 128-bit encryption
Member Server Effective Default Settings Require 128-bit encryption
Client Computer Effective Default Settings Require 128-bit encryption

Policy management
Restart requirement
Policy conflicts
The settings for this security policy are dependent on the Network security: LAN Manager Authentication
Level policy setting value. For info about this policy, see Network security: LAN Manager authentication level.
Vulnerability
Network traffic that uses the NTLM Security Support Provider (NTLM SSP) could be exposed such that an attacker
who has gained access to the network can create man-in-the-middle attacks.
Countermeasure
Enable all options that are available for the Network security: Minimum session security for NTLM SSP based
(including secure RPC) clients policy setting.
Potential impact
Client devices that enforce these settings cannot communicate with older servers that do not support them.
Related topics
Security Options
Network security: Minimum session security for NTLM
SSP based (including secure RPC) servers
Applies to
Windows 10
security: Minimum session security for NTLM SSP based (including secure RPC) servers security policy
setting.
Reference
This policy setting allows a client device to require the negotiation of 128-bit encryption or NTLMv2 session
security. These values are dependent on the Network security: LAN Manager authentication level policy setting
value.
Setting all of these values for this policy setting will help protect network traffic that uses the NTLM Security
Support Provider (NTLM SSP) from being exposed or tampered with by a malicious user who has gained access to
the same network. That is, these settings help protect against man-in-the-middle attacks.
Possible values
Require 128-bit encryption. The connection fails if strong encryption (128-bit) is not negotiated.
Require NTLMv2 session security. The connection fails if the NTLMv2 protocol is not negotiated.
Not Defined.
Best practices
Enable all values that are available for this security policy. Legacy client devices that do not support these policy
settings will be unable to communicate with the server.
Location
Default values
Stand-Alone Server Default Settings Require 128-bit encryption
DC Effective Default Settings Require 128-bit encryption
Member Server Effective Default Settings Require 128-bit encryption

Client Computer Effective Default Settings Require 128-bit encryption
Policy management
Restart requirement
Policy dependencies
The settings for this security policy are dependent on the Network security: LAN Manager authentication level
setting value.
Vulnerability
Network traffic that uses the NTLM Security Support Provider (NTLM SSP) could be exposed such that an attacker
who has gained access to the network can create man-in-the-middle attacks.
Countermeasure
Enable all options that are available for the Network security: Minimum session security for NTLM SSP based
(including secure RPC) servers policy setting.
Potential impact
Older client devices that do not support these security settings cannot communicate with the computer on which
this policy is set.
Related topics
Security Options
Network security: Restrict NTLM: Add remote server
exceptions for NTLM authentication
Applies to
Windows 10
Describes the best practices, location, values, management aspects, and security considerations for the Network
security: Restrict NTLM: Add remote server exceptions for NTLM authentication security policy setting.
Reference
The Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication policy
setting allows you to create an exception list of remote servers to which client devices are allowed to use NTLM
authentication if the Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers policy setting is
configured.
If you configure this policy setting, you can define a list of remote servers to which client devices are allowed to use
NTLM authentication.
If you do not configure this policy setting, no exceptions will be applied, and if Network security: Restrict NTLM:
Outgoing NTLM traffic to remote servers is enabled, NTLM authentication attempts from the client devices will fail.
List the NetBIOS server names that are used by the applications as the naming format, one per line. To ensure
exceptions, the names that are used by all applications need to be in the list. A single asterisk (*) can be used
anywhere in the string as a wildcard character.
Possible values
User-defined list of remote servers
When you enter a list of remote servers to which clients are allowed to use NTLM authentication, the policy
is defined and enabled.
Not defined
If you do not configure this policy setting by defining a list of servers, the policy is undefined and no
exceptions will be applied.
Best practices
1. First enforce the Network Security: Restrict NTLM: Audit incoming NTLM traffic or Network Security: Restrict
NTLM: Audit NTLM authentication in this domain policy setting and then review the operational event log to
understand which servers are involved in these authentication attempts so you can decide which servers to
exempt.
2. After you have set the server exception list, enforce the Network Security: Restrict NTLM: Audit incoming
NTLM traffic or Network Security: Restrict NTLM: Audit NTLM authentication in this domain policy setting
and then review the operational event log again before setting the policies to block NTLM traffic.
Location
Default values
Client computer effective default settings Not defined
Policy management
This section describes the features and tools that are available to help you manage this policy.
Restart requirement
Group Policy
Setting and deploying this policy through Group Policy takes precedence over the setting on the local device. If the
Group Policy setting is set to Not Configured, local settings will apply.
Auditing
View the operational event log to see if your server exception list is functioning as intended. Audit and block events
are recorded on this device in the operational event log located in Applications and Services
Log\Microsoft\Windows\NTLM.
There are no security audit policies that can be configured to view output from this policy.
Vulnerability
When it has been determined that the NTLM authentication protocol should not be used from a client device to any
remote servers because you are required to use a more secure protocol such as Kerberos, there might be some
client applications that still use NTLM. If so, and you set Network Security: Restrict NTLM: Outgoing NTLM traffic to
remote servers to any of the deny options, those applications will fail because the outbound NTLM authentication
traffic from the client computer will be blocked.
If you define an exception list of servers to which client devices are allowed to use NTLM authentication, then
NTLM authentication traffic will continue to flow between those client applications and servers. The servers then
are vulnerable to any malicious attack that takes advantage of security weaknesses in NTLM.
Countermeasure
When you use Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers in audit-only mode, you
can determine by reviewing which client applications are making NTLM authentication requests to the remote
servers in your environment. When assessed, you will have to determine on a case-by-case basis if NTLM
authentication still minimally meets your security requirements. If not, the client application has to be upgraded to
use something other than NTLM authentication.
Potential impact
Defining a list of servers for this policy setting will enable NTLM authentication traffic from the client application
that uses those servers, and this might result in a security vulnerability.
If this list is not defined and Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers is enabled,
then client applications that use NTLM will fail to authenticate to those servers that they have previously used.
Related topics
Security Options
Network security: Restrict NTLM: Add server
exceptions in this domain
Applies to
Windows 10
security: Restrict NTLM: Add server exceptions in this domain security policy setting.
Reference
The Network security: Restrict NTLM: Add server exceptions in this domain policy setting allows you to
create an exception list of servers in this domain to which client device are allowed to use NTLM pass-through
authentication if any of the deny options are set in the Network Security: Restrict NTLM: NTLM authentication in
this domain policy setting.
If you configure this policy setting, you can define a list of servers in this domain to which client devices are
allowed to use NTLM authentication.
If you do not configure this policy setting, no exceptions will be applied, and if Network Security: Restrict NTLM:
NTLM authentication in this domain is enabled, all NTLM authentication attempts in the domain will fail.
List the NetBIOS server names as the naming format, one per line. A single asterisk (*) can be used anywhere in the
string as a wildcard character.
Possible values
User-defined list of servers
When you enter a list of servers in this domain to which clients are allowed to use NTLM authentication, the
policy is defined and enabled.
Not defined
If you do not configure this policy setting by defining a list of servers, the policy is undefined and no
exceptions will be applied.
Best practices
1. First enforce the Network Security: Restrict NTLM: Audit NTLM authentication in this domain policy
setting, and then review the operational event log to understand what domain controllers are involved in these
authentication attempts so you can decide which servers to exempt.
2. After you have set the server exception list, enforce the Network Security: Restrict NTLM: Audit NTLM
authentication in this domain policy setting, and then review the operational event log again before setting
the policies to block NTLM traffic.
Location
Default values
Policy management
Restart requirement
None. Changes to this policy become effective without a restart when saved locally or distributed through Group
Policy.
Group Policy
Setting and deploying this policy via Group Policy takes precedence over the setting on the local device. If the
Group Policy is set to Not Configured, local settings will apply.
Auditing
View the operational event log to see if your server exception list is functioning as intended. Audit and block events
are recorded on this computer in the operational event log located in Applications and Services
There are no security audit policies that can be configured to view output from this policy.
Vulnerability
When it has been determined that the NTLM authentication protocol should not be used within a domain because
you are required to use a more secure protocol such as Kerberos, there might be some NTLM authentication traffic
that is still present in the domain. If so, and you set Network Security: Network Security: Restrict NTLM: NTLM
authentication in this domain to any of the deny options, any NTLM authentication request will fail because the
pass-through member server will block the NTLM request.
If you define an exception list of servers in this domain to which client computers are allowed to use NTLM pass-
through authentication, then NTLM authentication traffic will continue to flow between those servers, which make
them vulnerable to any malicious attack that takes advantage of security weaknesses in NTLM.
Countermeasure
When you use Network Security: Restrict NTLM: NTLM authentication in this domain in audit-only mode,
you can determine by reviewing which client applications are making NTLM authentication requests to the pass-
through authentication servers. When assessed, you will have to determine on a case-by-case basis if NTLM
authentication still minimally meets your security requirements.
Potential impact
Defining a list of servers for this policy setting will enable NTLM authentication traffic between those servers might
result in a security vulnerability.
If this list is not defined and Network Security: Restrict NTLM: NTLM authentication in this domain is
enabled, then NTLM authentication will fail on those pass-through servers in the domain that they have previously
used
Related topics
Security Options
Network security: Restrict NTLM: Audit incoming
NTLM traffic
Applies to
Windows 10
Security: Restrict NTLM: Audit incoming NTLM traffic security policy setting.
Reference
The Network Security: Restrict NTLM: Audit incoming NTLM traffic policy setting allows you to audit
incoming NTLM traffic.
When this audit policy is enabled within Group Policy, it is enforced on any server where that Group Policy is
distributed. The events will be recorded in the operational event log located in Applications and Services
Log\Microsoft\Windows\NTLM. Using an audit event collection system can help you collect the events for
analysis more efficiently.
When you enable this policy on a server, only authentication traffic to that server will be logged.
When you enable this audit policy, it functions in the same way as the Network Security: Restrict NTLM: Incoming
NTLM traffic policy, but it does not actually block any traffic. Therefore, you can use it effectively to understand the
authentication traffic in your environment, and when you are ready to block that traffic, you can enable the
Network Security: Restrict NTLM: Incoming NTLM traffic policy setting and select Deny all accounts or Deny all
domain accounts.
Possible values
Disable
The server on which this policy is set will not log events for incoming NTLM traffic.
Enable auditing for domain accounts
The server on which this policy is set will log events for NTLM pass-through authentication requests only for
accounts in the domain that would be blocked when the Network Security: Restrict NTLM: Incoming NTLM
traffic policy setting is set to Deny all domain accounts.
Enable auditing for all accounts
The server on which this policy is set will log events for all NTLM authentication requests that would be
blocked when the Network Security: Restrict NTLM: Incoming NTLM traffic policy setting is set to Deny all
accounts.
Not defined
This is the same as Disable, and it results in no auditing of NTLM traffic.
Best practices
Depending on your environment and the duration of your testing, monitor the log size regularly.
Location
Default values
Policy management
Restart requirement
Policy.
Group Policy
Setting and deploying this policy using Group Policy takes precedence over the setting on the local device. If the
Auditing
View the operational event log to see if this policy is functioning as intended. Audit and block events are recorded
on this computer in the operational event log located in Applications and Services
There are no security audit event policies that can be configured to view output from this policy.
NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB relay, man-in-the-
middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment
forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or
different authentication mechanisms, such as smart cards.
Vulnerability
Enabling this policy setting will reveal through logging which servers and client computers within your network or
domain handle NTLM traffic. The identity of these devices can be used in malicious ways if NTLM authentication
traffic is compromised. The policy setting does not prevent or mitigate any vulnerability because it is for audit
purposes only.
Countermeasure
Restrict access to the log files when this policy setting is enabled in your production environment.
Potential impact
If you do not enable or configure this policy setting, no NTLM authentication traffic information will be logged. If
you do enable this policy setting, only auditing functions will occur; no security enhancements will be
implemented.
Related topics
Security Options
Network security: Restrict NTLM: Audit NTLM
authentication in this domain
Applies to
Windows 10
Security: Restrict NTLM: Audit NTLM authentication in this domain security policy setting.
Reference
The Network Security: Restrict NTLM: Audit NTLM authentication in this domain policy setting allows you
to audit on the domain controller NTLM authentication in that domain.
When you enable this policy setting on the domain controller, only authentication traffic to that domain controller
will be logged.
When you enable this audit policy, it functions in the same way as the Network Security: Restrict NTLM: NTLM
authentication in this domain policy setting, but it does not actually block any traffic. Therefore, you can use it
effectively to understand the authentication traffic to your domain controllers and when you are ready to block
that traffic, you can enable the Network Security: Restrict NTLM: NTLM authentication in this domain policy
setting and select Deny for domain accounts to domain servers, Deny for domain servers, or Deny for
domain accounts.
Possible values
Disable
The domain controller on which this policy is set will not log events for incoming NTLM traffic.
Enable for domain accounts to domain servers
The domain controller on which this policy is set will log events for NTLM authentication logon attempts for
accounts in the domain to domain servers when NTLM authentication would be denied because the
Network security: Restrict NTLM: NTLM authentication in this domain policy setting is set to Deny
for domain accounts to domain servers.
Enable for domain accounts
The domain controller will log events for NTLM authentication logon attempts that use domain accounts
when NTLM authentication would be denied because the Network security: Restrict NTLM: NTLM
authentication in this domain policy setting is set to Deny for domain accounts.
Not defined
This is the same as Disable and results in no auditing of NTLM traffic.
Best practices
Depending on your environment and the duration of your testing, monitor the operational event log size regularly.
Location
Default values
Policy management
Restart requirement
Policy.
Group Policy
Auditing
NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB replay, man-in-
the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment
Vulnerability
Enabling this policy setting will reveal through logging which devices within your network or domain handle NTLM
traffic. The identity of these devices can be used in malicious ways if NTLM authentication traffic is compromised.
The policy setting does not prevent or mitigate any vulnerability because it is for audit purposes only.
Countermeasure
Restrict access to the log files when this policy setting is enabled in your production environment.
Potential impact
If you do not enable or configure this policy setting, no NTLM authentication traffic information will be logged. If
you do enable this policy setting, only auditing functions will occur; no security enhancements will be
implemented.
Related topics
Security Options
Network security: Restrict NTLM: Incoming NTLM
traffic
Applies to
Windows 10
Security: Restrict NTLM: Incoming NTLM traffic security policy setting.
Reference
The Network Security: Restrict NTLM: Incoming NTLM traffic policy setting allows you to deny or allow
incoming NTLM traffic from client computers, other member servers, or a domain controller.
Possible values
Allow all
The server will allow all NTLM authentication requests.
Deny all domain accounts
The server will deny NTLM authentication requests for domain logon, return an NTLM blocked error
message to the client device, and log the error, but the server will allow local account logon.
Deny all accounts
The server will deny NTLM authentication requests from all incoming traffic (whether domain account
logon or local account logon), return an NTLM blocked error message to the client device, and log the error.
Not defined
This is the same as Allow all, and the server will allow all NTLM authentication requests.
Best practices
If you select Deny all domain accounts or Deny all accounts, incoming NTLM traffic to the member server will
be restricted. It is better to set the Network Security: Restrict NTLM: Audit Incoming NTLM traffic policy
setting and then review the Operational log to understand what authentication attempts are made to the member
servers, and subsequently what client applications are using NTLM.
Location
Default values

Policy management
Restart requirement
Policy.
Group Policy
Auditing
There are no Security Audit Event policies that can be configured to view event output from this policy.
the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your
environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5
protocol, or different authentication mechanisms, such as smart cards.
Vulnerability
Malicious attacks on NTLM authentication traffic that result in a compromised server can occur only if the server
handles NTLM requests. If those requests are denied, brute force attacks on NTLM are eliminated.
Countermeasure
When it has been determined that the NTLM authentication protocol should not be used within a network because
you are required to use a more secure protocol such as Kerberos, you can select one of several options that this
security policy setting offers to restrict NTLM usage.
Potential impact
If you configure this policy setting, numerous NTLM authentication requests could fail within your network, which
could degrade productivity. Before implementing this change through this policy setting, set Network security:
Restrict NTLM: Audit Incoming NTLM traffic to the same option so that you can review the log for the
potential impact, perform an analysis of servers, and create an exception list of servers to exclude from this policy
setting Network security: Restrict NTLM: Add server exceptions in this domain.
Related topics
Security Options
Network security: Restrict NTLM: NTLM
authentication in this domain
Applies to
Windows 10
Security: Restrict NTLM: NTLM authentication in this domain security policy setting.
Reference
The Network Security: Restrict NTLM: NTLM authentication in this domain policy setting allows you to deny
or allow NTLM authentication within a domain from this domain controller. This policy setting does not affect
interactive logon to this domain controller.
Possible values
Disable
The domain controller will allow all NTLM pass-through authentication requests within the domain.
Deny for domain accounts to domain servers
The domain controller will deny all NTLM authentication logon attempts using accounts from this domain to
all servers in the domain. The NTLM authentication attempts will be blocked and will return an NTLM
blocked error unless the server name is on the exception list in the Network security: Restrict NTLM: Add
server exceptions in this domain policy setting.
NTLM can be used if the users are connecting to other domains. This depends on if any Restrict NTLM
policies have been set on those domains.
Deny for domain accounts
Only the domain controller will deny all NTLM authentication logon attempts from domain accounts and
will return an NTLM blocked error unless the server name is on the exception list in the Network security:
Restrict NTLM: Add server exceptions in this domain policy setting.
Deny for domain servers
The domain controller will deny NTLM authentication requests to all servers in the domain and will return
an NTLM blocked error unless the server name is on the exception list in the Network security: Restrict
NTLM: Add server exceptions in this domain policy setting. Servers that are not joined to the domain
will not be affected if this policy setting is configured.
Deny all
The domain controller will deny all NTLM pass-through authentication requests from its servers and for its
accounts and return an NTLM blocked error unless the server name is on the exception list in the Network
security: Restrict NTLM: Add server exceptions in this domain policy setting.
Not defined
The domain controller will allow all NTLM authentication requests in the domain where the policy is
deployed.
Best practices
If you select any of the deny options, incoming NTLM traffic to the domain will be restricted. First, set the Network
Security: Restrict NTLM: Audit NTLM authentication in this domain policy setting, and then review the
Operational log to understand what authentication attempts are made to the member servers. You can then add
those member server names to a server exception list by using the Network security: Restrict NTLM: Add server
exceptions in this domain policy setting.
Location
Default values
Default domain policy Not configured
Default domain controller policy Not configured
Stand-alone server default settings Not configured
Domain controller effective default settings Not configured
Member server effective default settings Not configured
Client computer effective default settings Not configured
Policy management
Restart requirement
Policy.
Group Policy
Auditing
the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment
Vulnerability
Malicious attacks on NTLM authentication traffic resulting in a compromised server or domain controller can occur
only if the server or domain controller handles NTLM requests. If those requests are denied, this attack vector is
eliminated.
Countermeasure
you are required to use a more secure protocol such as the Kerberos protocol, then you can select one of several
options that this security policy setting offers to restrict NTLM usage within the domain.
Potential impact
If you configure this policy setting, numerous NTLM authentication requests could fail within the domain, which
could degrade productivity. Before implementing this change through this policy setting, set Network security:
Restrict NTLM: Audit NTLM authentication in this domain to the same option so that you can review the log
for the potential impact, perform an analysis of servers, and create an exception list of servers to exclude from this
policy setting by using Network security: Restrict NTLM: Add server exceptions in this domain.
Related topics
Security Options
Network security: Restrict NTLM: Outgoing NTLM
traffic to remote servers
Applies to
Windows 10
Security: Restrict NTLM: Outgoing NTLM traffic to remote servers security policy setting.
Reference
The Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers policy setting allows you to
deny or audit outgoing NTLM traffic from a computer running Windows 7, Windows Server 2008, or later to any
remote server running the Windows operating system.
Warning: Modifying this policy setting may affect compatibility with client computers, services, and
applications.
Possible values
Allow all
The device can authenticate identities to a remote server by using NTLM authentication because no
restrictions exist.
Audit all
The device that sends the NTLM authentication request to a remote server logs an event for each request.
This allows you to identify those servers that receive NTLM authentication requests from the client device
Deny all
The device cannot authenticate any identities to a remote server by using NTLM authentication. You can
use the Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication policy
setting to define a list of remote servers to which client devices are allowed to use NTLM authentication
while denying others. This setting will also log an event on the device that is making the authentication
request.
Not defined
This is the same as Allow all, and the device will allow all NTLM authentication requests when the policy is
deployed.
Best practices
If you select Deny all, the client device cannot authenticate identities to a remote server by using NTLM
authentication. First, select Audit all and then review the operational event log to understand which servers are
involved in these authentication attempts. You can then add those server names to a server exception list by using
the Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication policy setting.
Location
Default values
Policy management
Restart requirement
Policy.
Group Policy
Auditing
There are no security audit event policies that can be configured to view event output from this policy.
the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your
environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5
protocol, or different authentication mechanisms, such as smart cards.
Vulnerability
Malicious attacks on NTLM authentication traffic that result in a compromised server or domain controller can
occur only if the server or domain controller handles NTLM requests. If those requests are denied, this attack
vector is eliminated.
Countermeasure
you are required to use a more secure protocol such as Kerberos, then you can select from several options to
restrict NTLM usage to servers.
Potential impact
If you configure this policy setting to deny all requests, numerous NTLM authentication requests to remote
servers could fail, which could degrade productivity. Before implementing this restriction through this policy
setting, select Audit all so that you can review the log for the potential impact, perform an analysis of servers, and
create an exception list of servers to exclude from this policy setting by using Network security: Restrict NTLM:
Add remote server exceptions for NTLM authentication .
Related topics
Security Options
Recovery console: Allow automatic administrative
logon
Applies to
Windows 10
Describes the best practices, location, values, policy management and security considerations for the Recovery
console: Allow automatic administrative logon security policy setting.
Reference
This policy setting determines whether the built-in Administrator account password must be provided before
access to the device is granted. If you enable this setting, the built-in Administrator account is automatically logged
on to the computer at the Recovery Console; no password is required.
The Recovery Console can be very useful when troubleshooting and repairing systems that cannot be restarted.
However, enabling this policy setting so a user can automatically log on to the console is dangerous. Anyone can
walk up to the server, shut it down by disconnecting the power, reboot it, select Recovery Console from the
Restart menu, and then assume full control of the server.
Possible values
Enabled
The built-in Administrator account is automatically logged on to the computer at the Recovery Console; no
password is required
Disabled
Automatic administrative logon is not allowed.
Not defined
Automatic administrative logon is not allowed.
Best practices
Set Recovery Console: Allow automatic administrative logon to Disabled. This requires a user to enter a
user name and password to access the Recovery Console account.
Location
Default values

Policy management
Restart requirement
Group Policy
Setting and deploying this policy using Group Policy takes precedence over the setting on the local device
Policy conflicts
None.
Vulnerability
The Recovery Console can be very useful when you must troubleshoot and repair device that do not start. However,
allowing automatic logon to the Recovery Console can make it possible for someone to assume full control of the
server.
Countermeasure
Disable the Recovery console: Allow automatic administrative logon setting.
Potential impact
Users must enter a user name and password to access the Recovery Console.
Related topics
Security Options
Recovery console: Allow floppy copy and access to all
drives and folders
Applies to
Windows 10
Describes the best practices, location, values, policy management and security considerations for the Recovery
console: Allow floppy copy and access to all drives and folders security policy setting.
Reference
This policy setting enables or disables the Recovery Console SET command, which allows you to set the following
Recovery Console environment variables.
AllowWildCards. Enables wildcard support for some commands, such as the DEL command.
AllowAllPaths. Allows access to all files and folders on the device.
AllowRemovableMedia. Allows files to be copied to removable media, such as a floppy disk.
NoCopyPrompt. Suppresses the prompt that typically displays before an existing file is overwritten.
You might forget to remove removable media, such as CD or floppy disk, with sensitive data or applications that a
malicious user could then steal. Or you could accidentally leave a startup disk in the computer after using the
Recovery Console. If the device is restarted for any reason and the BIOS has been configured to boot from the
removable media before the hard disk drive, the server will start from the removable disk. This causes the server's
network services to be unavailable.
Possible values
Enabled
Disabled
Not defined
Best practices
Set Recovery Console: Allow floppy copy and access to drives and folders to Disabled. Users who have
started a server by using the Recovery Console and logged in with the built-in Administrator account will not be
able to copy files and folders to a floppy disk.
Location
Default values

Policy management
Restart requirement
Group Policy
Setting and deploying this policy using Group Policy takes precedence over the setting on the local device.
Policy conflicts
None.
Command-line tools
Enabling this security option makes the Recovery Console SET command available, which allows you to set the
following Recovery Console environment variables:
AllowWildCards: Enable wildcard support for some commands (such as the DEL command).
AllowAllPaths: Allow access to all files and folders on the device.
AllowRemovableMedia: Allow files to be copied to removable media, such as a floppy disk.
NoCopyPrompt: Do not prompt when overwriting an existing file.
Vulnerability
An attacker who can cause the system to restart into the Recovery Console could steal sensitive data and leave no
audit or access trail.
Countermeasure
Disable the Recovery console: Allow floppy copy and access to drives and folders setting.
Potential impact
Users who have started a server through the Recovery Console and logged in with the built-in Administrator
account cannot copy files and folders to a floppy disk.
Related topics
Security Options
Shutdown: Allow system to be shut down without
having to log on
Applies to
Windows 10
Describes the best practices, location, values, policy management and security considerations for the Shutdown:
Allow system to be shut down without having to log on security policy setting.
Reference
This policy setting determines whether a device can be shut down without having to log on to Windows. If you
enable this policy setting, the Shut Down option is available on the logon screen in Windows. If you disable this
policy setting, the Shut Down option is removed from the logon screen. This configuration requires that users are
able to log on to the device successfully and that they have the Shut down the system user right before they can
perform a shutdown.
Users who can access the console locally can shut down the system. Attackers or misguided users can connect to
the server by using Remote Desktop Services, and then shut it down or restart it without having to identify
themselves. A malicious user might also cause a temporary denial-of-service condition by walking up to the local
console and restarting the server, or shutting down the server and thus rendering unavailable all its applications
and services.
Possible values
Enabled
The shut down command is available on the logon screen.
Disabled
The shut down option is removed from the logon screen and users must have the Shut down the system
user right before they can perform a shutdown.
Not defined
Best practices
1. On servers, set this policy to Disabled. You must log on to servers to shut them down or restart them.
2. On client devices, set this policy to Enabled and define the list of those with the right to shut them down or
restart them with the User Rights Assignment policy Shut down the system.
Location
Default values
Policy management
Restart requirement
Group Policy
For info about the User Rights Assignment policy, Shut down the system, see Shut down the system.
Vulnerability
Users who can access the console locally could shut down the device
Attackers who have access to the local console could restart the server, which would cause a temporary DoS
condition. Attackers could also shut down the server and leave all of its applications and services unavailable.
Countermeasure
Disable the Shutdown: Allow system to be shut down without having to log on setting.
Potential impact
You must log on to servers to shut them down or restart them.
Related topics
Security Options
Shutdown: Clear virtual memory pagefile
Applies to
Windows 10
Describes the best practices, location, values, policy management and security considerations for the Shutdown:
Clear virtual memory pagefile security policy setting.
Reference
This policy setting determines whether the virtual memory paging file is cleared when the device is shut down.
Virtual memory support uses a system paging file to swap pages of memory to disk when they are not used. On a
running device, this paging file is opened exclusively by the operating system, and it is well protected. However,
devices that are configured to allow other operating systems to start should verify that the system paging file is
cleared as the device shuts down. This confirmation ensures that sensitive information from process memory that
might be placed in the paging file is not available to an unauthorized user who manages to directly access the
paging file after shutdown.
Important information that is kept in real memory might be written periodically to the paging file. This helps
devices handle multitasking functions. A malicious user who has physical access to a server that has been shut
down can view the contents of the paging file. The attacker can move the system volume into a different computer
and then analyze the contents of the paging file. This is a time-consuming process, but it can expose data that is
cached from RAM to the paging file. A malicious user who has physical access to the server can bypass this
countermeasure by simply unplugging the server from its power source.
Possible values
Enabled
The system paging file is cleared when the system shuts down normally. Also, this policy setting forces the
computer to clear the hibernation file (hiberfil.sys) when hibernation is disabled on a portable device.
Disabled
Not defined
Best practices
Set this policy to Enabled. This causes Windows to clear the paging file when the system is shut down.
Depending on the size of the paging file, this process might take several minutes before the system completely
shuts down. This delay in shutting down the server is especially noticeable on servers with large paging files. For
a server with 2 gigabytes (GB) of RAM and a 2-GB paging file, this setting can add more than 30 minutes to the
shutdown process. For some organizations, this downtime violates their internal service level agreements. Use
caution when implementing this countermeasure in your environment.
Location
Default values
Policy management
Restart requirement
Vulnerability
Important information that is kept in real memory may be written periodically to the paging file to help Windows
handle multitasking functions. An attacker who has physical access to a server that has been shut down could view
the contents of the paging file. The attacker could move the system volume into a different device and then analyze
the contents of the paging file. Although this process is time consuming, it could expose data that is cached from
random access memory (RAM) to the paging file.
Caution: An attacker who has physical access to the device could bypass this countermeasure by unplugging
the computer from its power source.
Countermeasure
Enable the Shutdown: Clear virtual memory page file setting. This configuration causes the operating system to
clear the paging file when the device is shut down. The amount of time that is required to complete this process
depends on the size of the page file. Because the process overwrites the storage area that is used by the page file
several times, it could be several minutes before the device completely shuts down.
Potential impact
It takes longer to shut down and restart the device, especially on devices with large paging files. For a device with 2
gigabytes (GB) of RAM and a 2-GB paging file, this policy setting could increase the shutdown process by more
than 30 minutes. For some organizations this downtime violates their internal service level agreements. Therefore,
use caution before you implement this countermeasure in your environment.
Related topics
Security Options
System cryptography: Force strong key protection for
user keys stored on the computer
Applies to
Windows 10
Describes the best practices, location, values, policy management and security considerations for the System
cryptography: Force strong key protection for user keys stored on the computer security policy setting.
Reference
This policy setting determines whether users can use private keys, such as their Secure/Multipurpose Internet Mail
Extensions (S/MIME) key, without a password.
Configuring this policy setting so that users must provide a password every time they use a key (in addition to their
domain password) makes it more difficult for a malicious user to access locally-stored user keys, even if the
attacker takes control of the user's device and determines their logon password.
Possible values
User input is not required when new keys are stored and used
User is prompted when the key is first used
User must enter a password each time they use a key
Not defined
Best practices
Set this policy to User must enter a password each time they use a key. Users must enter their password
every time they access a key that is stored on their computer. For example, if users use an S/MIME certificate to
digitally sign their email, they will be forced to enter the password for that certificate every time they send a
signed email message. For some organizations, the overhead that is caused by using this value might be too
high, but they should set the value at a minimum to User is prompted when the key is first used.
Location
Default values

Policy management
Restart requirement
Vulnerability
If a user's account is compromised or the user's device is inadvertently left unsecured, the malicious user can use
the keys that are stored for the user to access protected resources.
Countermeasure
Configure the System cryptography: Force strong key protection for user keys stored on the computer
setting to User must enter a password each time they use a key so that users must provide a password that is
distinct from their domain password every time they use a key. This configuration makes it more difficult for an
attacker to access locally stored user keys, even if the attacker takes control of the user's computer and determines
the logon password.
Potential impact
Users must type their password every time they access a key that is stored on their device. For example, if users use
an S/MIME certificate to digitally sign their email, they are forced to type the password for that certificate every
time they send a signed email message. For some organizations, the overhead that is involved by using this
configuration may be too high. At a minimum, this setting should be set to User is prompted when the key is
first used.
Related topics
Security Options
System cryptography: Use FIPS compliant algorithms
for encryption, hashing, and signing
Applies to
Windows 10
management and security considerations for this policy setting.
Reference
The Federal Information Processing Standard (FIPS) 140 is a security implementation that is designed for certifying
cryptographic software. Windows implements these certified algorithms to meet the requirements and standards
for cryptographic modules for use by departments and agencies of the United States federal government.
TLS/SSL
This policy setting determines whether the TLS/SSL security provider supports only the FIPS-compliant strong
cipher suite known as TLS_RSA_WITH_3DES_EDE_CBC_SHA, which means that the provider only supports the TLS
protocol as a client computer and as a server, if applicable. It uses only the Triple Data Encryption Standard (3DES)
encryption algorithm for the TLS traffic encryption, only the Rivest-Shamir-Adleman (RSA) public key algorithm for
the TLS key exchange and authentication, and only the Secure Hash Algorithm version 1 (SHA-1) hashing algorithm
for the TLS hashing requirements.
Encrypting File System (EFS)
For the EFS service, this policy setting supports the 3DES and Advanced Encryption Standard (AES) encryption
algorithms for encrypting file data supported by the NTFS file system. To encrypt file data, by default EFS uses the
Advanced Encryption Standard (AES) algorithm with a 256-bit key in the Windows Server 2003, Windows Vista,
and later, and it uses a DESX algorithm in Windows XP.
Remote Desktop Services (RDS)
For encrypting Remote Desktop Services network communication, this policy setting supports only the Triple DES
encryption algorithm.
BitLocker
For BitLocker, this policy setting needs to be enabled before any encryption key is generated. Recovery passwords
created on Windows Server 2012 R2 and Windows 8.1 and later when this policy is enabled are incompatible with
BitLocker on operating systems prior to Windows Server 2012 R2 and Windows 8.1; BitLocker will prevent the
creation or use of recovery passwords on these systems, so recovery keys should be used instead. Additionally, if a
data drive is password-protected, it can be accessed by a FIPS-compliant computer after the password is supplied,
but the drive will be read-only.
Possible values
Enabled
Disabled
Not defined
Best practices
For use with TLS, set this policy to Enabled. Client devices with this policy setting enabled will be unable to
communicate through digitally encrypted or signed protocols with servers that do not support these algorithms.
Client devices that are connected to the network and do not support these algorithms cannot use servers that
require the algorithms for network communications. If you enable this policy setting, you must also configure
Internet Explorer to use TLS.
Location
Default values
Operating system version differences

When this setting is enabled, the Encrypting File System (EFS) service supports only the Triple DES encryption
algorithm for encrypting file data. By default, the Windows Vista and the Windows Server 2003 implementation of
EFS uses the Advanced Encryption Standard (AES) with a 256-bit key. The Windows XP implementation uses DESX.
When this setting is enabled, BitLocker generates recovery password or recovery keys applicable to versions listed
in the following:
OPERATING SYSTEMS APPLICABILITY
Windows 10, Windows 8.1, and Windows Server 2012 R2 When created on these operating systems, the recovery
password cannot be used on other systems listed in this table.
Windows Server 2012 and Windows 8 When created on these operating systems, the recovery key
can be used on other systems listed in this table as well.
Windows Server 2008 R2 and Windows 7 When created on these operating systems, the recovery key
Windows Server 2008 and Windows Vista When created on these operating systems, the recovery key
Policy management
Restart requirement
Group Policy
Vulnerability
You can enable this policy setting to ensure that the device uses the most powerful algorithms that are available for
digital encryption, hashing, and signing. Use of these algorithms minimize the risk of compromise of digitally
encrypted or signed data by an unauthorized user.
Countermeasure
Enable the System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing
setting.
Potential impact
Client devices that have this policy setting enabled cannot communicate by means of digitally encrypted or signed
protocols with servers that do not support these algorithms. Network clients that do not support these algorithms
cannot use servers that require them for network communications. For example, many Apache-based Web servers
are not configured to support TLS. If you enable this setting, you must also configure Internet Explorer to use TLS.
This policy setting also affects the encryption level that is used for the Remote Desktop Protocol (RDP). The Remote
Desktop Connection tool uses the RDP protocol to communicate with servers that run Terminal Services and client
computers that are configured for remote control; RDP connections fail if both devices are not configured to use
the same encryption algorithms.
Related topics
Security Options
System objects: Require case insensitivity for non-
Windows subsystems
Applies to
Windows 10
objects: Require case insensitivity for non-Windows subsystems security policy setting.
Reference
This policy setting determines whether case insensitivity is enforced for all subsystems. The Microsoft Win32
subsystem is not case sensitive; however, the kernel supports case sensitivity for other subsystems, such as
Portable Operating System Interface for UNIX (POSIX). Enabling this policy setting enforces case insensitivity for all
directory objects, symbolic links, and input/output (I/O) objects, including file objects. Disabling this policy setting
does not allow the Win32 subsystem to become case sensitive.
Because Windows is case insensitive but the POSIX subsystem will support case sensitivity, if this policy setting is
not enforced, it is possible for a user of that subsystem to create a file with the same name as another file but with a
different mix of capital letters. That might confuse users when they try to access these files by using normal Win32
tools, because only one of the files will be available.
Possible values
Enabled
Case insensitivity is enforced for all directory objects, symbolic links, and IO objects, including file objects.
Disabled
Will not allow the Win32 subsystem to become case sensitive.
Not defined
Best practices
Set this policy to Enabled. All subsystems will be forced to observe case insensitivity. However, this might
confuse users who are familiar with one of the UNIX-based operating systems and are used to a case sensitive
operating system.
Location
Default values

Policy management
Restart requirement
Vulnerability
Because Windows is case insensitive but the POSIX subsystem supports case sensitivity, failure to enable this policy
setting makes it possible for a user of that subsystem to create a file with the same name as another file but with a
different mix of uppercase and lowercase letters. Such a situation could potentially confuse users when they try to
access such files from normal Win32 tools because only one of the files is available.
Countermeasure
Enable the System objects: Require case insensitivity for non-Windows subsystems setting.
Potential impact
All subsystems are forced to observe case insensitivity. This configuration may confuse users who are familiar with
any UNIX-based operating systems that are case sensitive.
Related topics
Security Options
System objects: Strengthen default permissions of
internal system objects (e.g. Symbolic Links)
Applies to
Windows 10
objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links) security policy
setting.
Reference
This policy setting determines the strength of the default discretionary access control list (DACL) for objects.
Windows maintains a global list of shared system resources such as MS-DOS device names, mutexes, and
semaphores. By using this list, processes can locate and share objects. Each type of object is created with a default
DACL that specifies who can access the objects with what permissions. Enabling this policy setting strengthens the
default DACL and allows users who are not administrators to read, but not to modify, shared objects that they did
not create.
Possible values
Enabled
Disabled
Not defined
Best practices
It is advisable to set this policy to Enabled.
Location
Computer Configuration\Windows Settings\Security Settings\ Local Policies\Security Options
Default values

Policy management
Restart requirement
Vulnerability
This policy setting is enabled by default to protect against a known vulnerability that can be used with hard links or
symbolic links. Hard links are actual directory entries in the file system. With hard links, the same data in a file
system can be referred to by different file names. Symbolic links are text files that provide a pointer to the file that
is interpreted and followed by the operating system as a path to another file or directory. Because symbolic links
are a separate file, they can exist independently of the target location. If a symbolic link is deleted, its target location
remains unaffected. When this setting is disabled, it is possible for a malicious user to destroy a data file by creating
a link that looks like a temporary file that the system automatically creates, such as a sequentially named log file,
but it points to the data file that the malicious user wants to eradicate. When the system writes the files with that
name, the data is overwritten. Enabling System objects: Strengthen default permissions of internal system
objects (e.g., Symbolic Links) prevents an attacker from exploiting programs that create files with predictable
names by not allowing them to write to objects that they did not create.
Countermeasure
Enable the System objects: Strengthen default permissions of global system objects (for example,
Symbolic Links) setting.
Potential impact
Related topics
Security Options
System settings: Optional subsystems
Applies to
Windows 10
settings: Optional subsystems security policy setting.
Reference
This policy setting determines which subsystems support your applications. You can use this security setting to
specify as many subsystems as your environment demands.
The subsystem introduces a security risk that is related to processes that can potentially persist across logons. If a
user starts a process and then logs out, the next user who logs on to the system might access the process that the
previous user started. This is dangerous, because the process started by the first user can retain that user's system
user rights; therefore, anything that the second user does using that process is performed with the user rights of
the first user. This makes it difficult to trace who creates processes and objects, which is essential for post-security
incident forensics.
Possible values
User-defined list of subsystems
Not defined
Best practices
Set this policy setting to a null value. The default value is POSIX, so applications that rely on the POSIX
subsystem will no longer run. For example, Microsoft Services for UNIX 3.0 installs an updated version of the
POSIX subsystem. Reset this policy setting in Group Policy for any servers that use Services for UNIX 3.0.
Location
Default values
Stand-Alone Server Default Settings POSIX
DC Effective Default Settings POSIX
Member Server Effective Default Settings POSIX
Client Computer Effective Default Settings POSIX

Policy management
Restart requirement
Vulnerability
The POSIX subsystem is an Institute of Electrical and Electronic Engineers (IEEE) standard that defines a set of
operating system services. The POSIX subsystem is required if the server supports applications that use that
subsystem.
The POSIX subsystem introduces a security risk that relates to processes that can potentially persist across logons.
If a user starts a process and then logs out, there is a potential that the next user who logs on to the computer could
access the previous user's process. This would allow the second user to take actions on the process by using the
privileges of the first user.
Countermeasure
Configure the System settings: Optional subsystems setting to a null value. The default value is POSIX.
Potential impact
Applications that rely on the POSIX subsystem no longer operate. For example, Microsoft Services for UNIX (SFU)
installs an updated version of the POSIX subsystem that is required, so you must reconfigure this setting in Group
Policy for any servers that use SFU.
Related topics
Security Options
System settings: Use certificate rules on Windows
executables for Software Restriction Policies
Applies to
Windows 10
settings: Use certificate rules on Windows executables for Software Restriction Policies security policy
setting.
Reference
This policy setting determines whether digital certificates are processed when software restriction policies are
enabled and a user or process attempts to run software with an .exe file name extension. This security setting
enables or disables certificate rules (which are a type of software restriction policy). With a software restriction
policy, you can create a certificate rule that allows or disallows Microsoft Authenticode-signed software to run,
based on the digital certificate that is associated with the software. For certificate rules to work in software
restriction policies, you must enable this security setting.
Possible values
Enabled
Disabled
Not defined
Best practices
Set this policy to Enabled. Enabling certificate rules results in software restriction policies checking a certificate
revocation list (CRL) to make sure that the software's certificate and signature are valid. When you start signed
programs, this setting can decrease system performance. You can disable CRLs by editing the software
restriction policies in the desired GPO. In the Trusted Publishers Properties dialog box, clear the Publisher
and Timestamp check boxes.
Location
Default values

Policy management
Restart requirement
Vulnerability
Without the use of software restriction policies, users and device might be exposed to unauthorized software that
could include malware.
Countermeasure
Enable the System settings: Use certificate rules on Windows executables for Software Restriction Policies
setting.
Potential impact
If you enable certificate rules, software restriction policies check a certificate revocation list (CRL) to verify that the
software's certificate and signature are valid. This checking process may negatively affect performance when signed
programs start. To disable this feature, you can edit the software restriction policies in the appropriate GPO. In the
Trusted Publishers Properties dialog box, clear the Publisher and Timestamp check boxes.
Related topics
Security Options
User Account Control: Admin Approval Mode for the
Built-in Administrator account
Applies to
Windows 10
Describes the best practices, location, values, policy management and security considerations for the User Account
Control: Admin Approval Mode for the Built-in Administrator account security policy setting.
Reference
This policy setting determines the behavior of Admin Approval Mode for the built-in administrator account. When
the Admin Approval Mode is enabled, the local administrator account functions like a standard user account, but it
has the ability to elevate privileges without logging on by using a different account. In this mode, any operation that
requires elevation of privilege displays a prompt that allows the administrator to permit or deny the elevation of
privilege. If Admin Approval Mode is not enabled, the built-in Administrator account logs on in Windows XP Mode,
and it runs all applications by default with full administrative privileges. By default, this setting is set to Disabled.
Note: If a computer is upgraded from a previous version of the Windows operating system, and the
administrator account is the only account on the computer, the built-in administrator account remains enabled,
and this setting is also enabled.
Possible values
Enabled
The built-in administrator account logs on in Admin Approval Mode so that any operation that requires
elevation of privilege displays a prompt that provides the administrator the option to permit or deny the
elevation of privilege.
Disabled
The built-in administrator account logs on in Windows XP Mode, and it runs all applications by default with
full administrative privileges.
Best practices
Do not enable the built-in administrator account on the client computer, but use the standard user account and
User Account Control (UAC).
Location
Default values

Policy management
Restart requirement
Vulnerability
One of the risks of the User Account Control (UAC) feature is that it is intended to mitigate malicious software
running under elevated credentials without the user or administrator being aware of its activity. An attack vector for
malicious programs is to discover the password of the administrator account because that user account was
created for all installations of the Windows. To address this risk, the built-in administrator account is disabled in
computers running at least Windows Vista. In computers running at least Windows Server 2008, the administrator
account is enabled, and the password must be changed the first time the Administrator logs on. In a default
installation of a computer running at least Windows Vista, accounts with administrative control over the computer
are initially set up in one of two ways:
If the computer is not joined to a domain, the first user account you create has the equivalent permissions as a
local administrator.
If the computer is joined to a domain, no local administrator accounts are created. The enterprise or domain
administrator must log on to the computer and create a local administrator account if one is warranted.
Countermeasure
Enable the User Account Control: Admin Approval Mode for the Built-in Administrator account setting if
you have the built-in Administrator account enabled.
Potential impact
Users who log on by using the local administrator account are prompted for consent whenever a program requests
an elevation in privilege.
Related topics
Security Options
User Account Control: Allow UIAccess applications to
prompt for elevation without using the secure
desktop
Applies to
Windows 10
Describes the best practices, location, values, and security considerations for the User Account Control: Allow
UIAccess applications to prompt for elevation without using the secure desktop security policy setting.
Reference
This security setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically
disable the secure desktop for elevation prompts that are used by a standard user.
Note: This setting does not change the behavior of the UAC elevation prompt for administrators.
Background
User Interface Privilege Isolation (UIPI) implements restrictions in the Windows subsystem that prevent lower-
privilege applications from sending messages or installing hooks in higher-privilege processes. Higher-privilege
applications are permitted to send messages to lower-privilege processes. UIPI does not interfere with or change
the behavior of messages between applications at the same privilege (or integrity) level.
Microsoft UI Automation is the current model to support accessibility requirements in the Windows operating
systems. Applications that are designed to support an accessible user experience control the behavior of other
Windows applications on behalf of the user. When all applications on the automation client computer and server
are running as a standard user (that is, at a medium integrity level), the UIPI restrictions do not interfere with the
Microsoft UI automation model.
However, there might be times when an administrative user runs an application with elevated privilege based on
UAC in Admin Approval Mode. Microsoft UI Automation cannot drive the UI graphics of elevated applications on
the desktop without the ability to bypass the restrictions that UIPI implements. The ability to bypass UIPI restrictions
across privilege levels is available for UI automation programs by using UIAccess.
If an application presents a UIAccess attribute when it requests privileges, the application is stating a requirement to
bypass UIPI restrictions for sending messages across privilege levels. Devices implement the following policy
checks before starting an application with UIAccess privilege.
1. The application must have a digital signature that can be verified by using a digital certificate that is associated
with the Trusted Root Certification Authorities store on the local computer.
2. The application must be installed in a local folder that is writeable only by administrators, such as the
Program Files directory. The allowed directories for UI automation applications are:
a. %ProgramFiles% and its subdirectories.
b. %WinDir% and its subdirectories, except a few subdirectories that are excluded because standard users
have write access.
Resulting behavior
When this setting is enabled, UIAccess programs (including Windows Remote Assistance) can automatically disable
the secure desktop for elevation prompts. Unless you have also disabled elevation prompts, the prompts appear on
the interactive user's desktop instead of on the secure desktop. The prompts also appear on the remote
administrator's view of the desktop during a Windows Remote Assistance session, and the remote administrator
can provide the appropriate credentials for elevation.
If you disable this setting, the secure desktop can only be disabled by the user of the interactive desktop or by
disabling the User Account Control: Switch to the secure desktop when prompting for elevation setting, which by
default is enabled.
Possible values
Enabled
UIA programs can automatically disable the secure desktop for elevation prompts, and unless you have also
disabled elevation prompts, the prompts appear on the interactive user's desktop instead of on the secure
desktop. Prompts will also appear on the remote administrator's view of the desktop during a Windows
Remote Assistance session, and the remote administrator can provide the appropriate credentials for
elevation.
Disabled
The secure desktop can be disabled only by the user of the interactive desktop or by disabling the User
Account Control: Switch to the secure desktop when prompting for elevation policy setting.
Best practices
Best practices are dependent on your security policies and your remote operational requirements.
Location
Default values
Policy management
Restart requirement
Group Policy
unit (OU).
Policy interactions
If you plan to enable this setting, you should also review the effect of the User Account Control: Behavior of the
elevation prompt for standard users setting. If it is configured as Automatically deny elevation requests,
elevation requests are not presented to the user. If you disable this setting, the secure desktop can only be disabled
by the user of the interactive desktop or by disabling the User Account Control: Switch to the secure desktop when
prompting for elevation setting, which by default is enabled.
Vulnerability
UIA programs are designed to interact with Windows and application programs on behalf of a user. This setting
allows UIA programs to bypass the secure desktop to increase usability in certain cases, but it allows elevation
requests to appear on the regular interactive desktop instead of on the secure desktop. This increases the risk that a
malicious program could intercept data that is being transferred between the UI and the application. Because UIA
programs must be able to respond to prompts regarding security issues, such as the UAC elevation prompt, UIA
programs must be highly trusted. To be considered trusted, a UIA program must be digitally signed. By default, UIA
programs can be run only from the following protected paths:
..\Program Files\ (and subfolders)
..\Program Files (x86)\ (and subfolders, in 64-bit versions of Windows only)
..\Windows\System32\
The requirement to be in a protected path can be disabled by the User Account Control: Only elevate UIAccess
applications that are installed in secure locations setting. Although this setting applies to any UIA program, it is
used primarily in certain Windows Remote Assistance scenarios.
Countermeasure
Disable the User Account Control: Allow UIAccess applications to prompt for elevation without using the
secure desktop setting.
Potential impact
If a user requests remote assistance from an administrator and the remote assistance session is established,
elevation prompts appear on the interactive user's secure desktop and the administrator's remote session is
paused. To avoid pausing the remote administrators session during elevation requests, the user can select the
"Allow IT Expert to respond to User Account Control prompts" check box when setting up the remote assistance
session. However, selecting this check box requires that the interactive user respond to an elevation prompt on the
secure desktop. If the interactive user is a standard user, the user does not have the required credentials to allow
elevation.
Related topics
Security Options
User Account Control: Behavior of the elevation
prompt for administrators in Admin Approval Mode
Applies to
Windows 10
Control: Behavior of the elevation prompt for administrators in Admin Approval Mode security policy
setting.
Reference
This policy setting determines the behavior of the elevation prompt for accounts that have administrative
credentials.
Possible values
Elevate without prompting
Assumes that the administrator will permit an operation that requires elevation, and additional consent or
credentials are not required.
Note: Selecting Elevate without prompting minimizes the protection that is provided by UAC. We do
not recommend selecting this value unless administrator accounts are tightly controlled and the
operating environment is highly secure.
Prompt for credentials on the secure desktop

When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a
privileged user name and password. If the user enters valid credentials, the operation continues with the
user's highest available privilege.
Prompt for consent on the secure desktop
When an operation requires elevation of privilege, the user is prompted on the secure desktop to select
Permit or Deny. If the user selects Permit, the operation continues with the user's highest available
privilege.
Prompt for credentials
An operation that requires elevation of privilege prompts the administrator to type the user name and
password. If the administrator enters valid credentials, the operation continues with the applicable privilege.
Prompt for consent
An operation that requires elevation of privilege prompts the administrator to select Permit or Deny. If the
administrator selects Permit, the operation continues with the administrator's highest available privilege.
Prompt for consent for non-Windows binaries
This is the default. When an operation for a non-Microsoft application requires elevation of privilege, the
user is prompted on the secure desktop to select Permit or Deny. If the user selects Permit, the operation
continues with the user's highest available privilege.
Best practices
Selecting the option Elevate without prompting minimizes the protection that is provided by UAC. We do not
recommend selecting this value unless administrator accounts are tightly controlled and the operating
environment is highly secure.
Location
Default values
Policy management
Restart requirement
Group Policy
unit (OU).
Vulnerability
One of the risks that the UAC feature tries to mitigate is that of malicious software running under elevated
credentials without the user or administrator being aware of its activity. This setting raises awareness to the
administrator of elevated privilege operations, and it permits the administrator to prevent a malicious program
from elevating its privilege when the program attempts to do so.
Countermeasure
Configure the User Account Control: Behavior of the elevation prompt for administrators in Admin
Approval Mode setting to Prompt for consent.
Potential impact
Administrators should be made aware that they will be prompted for consent when all binaries attempt to run.
Related topics
Security Options
User Account Control: Behavior of the elevation
prompt for standard users
Applies to
Windows 10
Describes the best practices, location, values, policy management and security considerations for the User
Account Control: Behavior of the elevation prompt for standard users security policy setting.
Reference
This policy setting determines the behavior of the elevation prompt for standard users.
Possible values
Automatically deny elevation requests
This option returns an Access denied error message to standard users when they try to perform an
operation that requires elevation of privilege. Most organizations that run desktops as standard users
configure this policy to reduce Help Desk calls.
Prompt for credentials on the secure desktop
This is the default. When an operation requires elevation of privilege, the user is prompted on the secure
desktop to enter a different user name and password. If the user enters valid credentials, the operation
continues with the applicable privilege.
Prompt for credentials
An operation that requires elevation of privilege prompts the user to type an administrative user name and
password. If the user enters valid credentials, the operation continues with the applicable privilege.
Best practices
1. Configure the User Account Control: Behavior of the elevation prompt for standard users to
Automatically deny elevation requests. This setting requires the user to log on with an administrative
account to run programs that require elevation of privilege.
2. As a security best practice, standard users should not have knowledge of administrative passwords. However, if
your users have both standard and administrator-level accounts, set Prompt for credentials so that the users
do not choose to always log on with their administrator accounts, and they shift their behavior to use the
standard user account.
Location
Default values
Stand-Alone Server Default Settings Prompt for credentials on the secure desktop
DC Effective Default Settings Prompt for credentials on the secure desktop
Member Server Effective Default Settings Prompt for credentials on the secure desktop
Client Computer Effective Default Settings Prompt for credentials on the secure desktop
Policy management
Restart requirement
Group Policy
unit (OU).
Vulnerability
One of the risks that the UAC feature tries to mitigate is that of malicious programs running under elevated
credentials without the user or administrator being aware of their activity. This setting raises awareness to the user
that a program requires the use of elevated privilege operations, and it requires that the user supply administrative
credentials for the program to run.
Countermeasure
Configure the User Account Control: Behavior of the elevation prompt for standard users to Automatically
deny elevation requests. This setting requires the user to log on with an administrative account to run programs
that require elevation of privilege. As a security best practice, standard users should not have knowledge of
administrative passwords. However, if your users have both standard and administrator-level accounts, we
recommend setting Prompt for credentials so that the users do not choose to always log on with their
administrator accounts, and they shift their behavior to use the standard user account.
Potential impact
Users must provide administrative passwords to run programs with elevated privileges. This could cause an
increased load on IT staff while the programs that are affected are identified and standard operating procedures
are modified to support least privilege operations.
Related topics
Security Options
User Account Control: Detect application installations
and prompt for elevation
Applies to
Windows 10
Control: Detect application installations and prompt for elevation security policy setting.
Reference
This policy setting determines the behavior of application installation detection for the entire system. Some
software might attempt to install itself after being given permission to run. The user may give permission for the
program to run because the program is trusted. Then the user is prompted to install an unknown component. This
security policy provides another way to identify and stop these attempted software installations before they can do
damage.
Possible values
Enabled
Application installation packages that require an elevation of privilege to install are detected and the user is
prompted for administrative credentials.
Disabled
Application installation packages that require an elevation of privilege to install are not detected and the user
is not prompted for administrative credentials.
Best practices
1. Installer detection is unnecessary when enterprises run standard user desktops that capitalize on delegated
installation technologies like Group Policy Software Install (GPSI) or Configuration Manager. Therefore you can
set this security policy to Disabled.
2. Enable the User Account Control: Detect application installations and prompt for elevation setting so
standard users must provide administrative credentials before software is installed.
Location
Default values

Policy management
Restart requirement
Vulnerability
Some malicious software might attempt to install itself after being given permission to run, for example, malicious
software with a trusted application shell. The user may give permission for the program to run because the
program is trusted. Then the user is prompted to install an unknown component. This policy provides another way
to trap the software before it can do damage.
Countermeasure
Enable the User Account Control: Detect application installations and prompt for elevation setting.
Potential impact
Users must provide administrative passwords to install programs.
Related topics
Security Options
User Account Control: Only elevate executables that
are signed and validated
Applies to
Windows 10
Control: Only elevate executables that are signed and validated security policy setting.
Reference
This policy setting enforces public key infrastructure (PKI) signature checks on any interactive application that
requests elevation of privilege. You can control the apps that are allowed to run through the population of
certificates in the local computer's Trusted Publishers store.
A trusted publisher is a certificate issuer that the computers user has chosen to trust and that has certificate details
that have been added to the store of trusted publishers.
Windows maintains certificates in certificate stores. These stores can be represented by containers in the file system
or the registry, or they can be implemented as physical stores such as smart cards. Certificate stores are associated
with the computer object or they are owned by a distinct user who has a security context and profile on that
computer. In addition, services can have certificate stores. A certificate store will often contain numerous
certificates, possibly issued from a number of different certification authorities (CAs). When certificate path
discovery is initiated, Windows attempts to locate the issuing CA for the certificates, and it builds a certificate path
to the trusted root certificate. Intermediate certificates are included as part of the application protocol or are picked
up from Group Policy or through URLs that are specified in the Authority Information Access (AIA) extension. When
the path is built, each certificate in the path is verified for validity with respect to various parameters, such as name,
time, signature, revocation status, and other constraints.
Possible values
Enabled
Enforces the PKI certificate chain validation of a given executable file before it is permitted to run.
Disabled
Does not enforce PKI certificate chain validation before a given executable file is permitted to run.
Best practices
Best practices are dependent on your security and performance goals.
Location
Default values
Policy management
Restart requirement
Group Policy
unit (OU).
Vulnerability
Intellectual property, personally identifiable information, and other confidential data are normally manipulated by
applications on the computer, and elevated credentials are required to access the information. Users and
administrators inherently trust applications that are used with these information sources, and they provide their
credentials. If one of these applications is replaced by a rogue application that appears identical to the trusted
application, the confidential data could be compromised and the user's administrative credentials would also be
compromised.
Countermeasure
Enable the User Account Control: Only elevate executables that are signed and validated.
Potential impact
Enabling this setting requires that you have a PKI infrastructure and that your enterprise administrators have
populated the Trusted Publishers store with the certificates for the allowed applications. Some older applications
are not signed, and they cannot be used in an environment that is hardened with this setting. You should carefully
test your applications in a preproduction environment before implementing this setting. Control over the
applications that are installed on the desktops and the hardware that joins your domain should provide similar
protection from the vulnerability that is addressed by this setting. Additionally, the level of protection that is
provided by this setting is not an assurance that all rogue applications will be found.
Related topics
Security Options
User Account Control: Only elevate UIAccess
applications that are installed in secure locations
Applies to
Windows 10
Account Control: Only elevate UIAccess applications that are installed in secure locations security policy
setting.
Reference
This policy setting enforces the requirement that apps that request running with a UIAccess integrity level (by
means of a marking of UIAccess=true in their app manifest), must reside in a secure location on the file system.
Relatively secure locations are limited to the following directories:
\Program Files\ including subdirectories
\Windows\system32\
\Program Files (x86)\ including subdirectories for 64-bit versions of Windows
Note: Windows enforces a PKI signature check on any interactive application that requests running with a
UIAccess integrity level, regardless of the state of this security setting.
Background
User Interface Privilege Isolation (UIPI) implements restrictions in the Windows subsystem that prevent lower-
privilege applications from sending messages or installing hooks in higher-privilege processes. Higher-privilege
applications are permitted to send messages to lower-privilege processes. UIPI does not interfere with or change
the behavior of messages between applications at the same privilege (or integrity) level.
Microsoft UI Automation is the current model to support accessibility requirements in the Windows operating
systems. Applications that are designed to support an accessible user experience control the behavior of other
Windows applications on behalf of the user. When all applications on the automation client computer and server
are running as a standard user (that is, at a medium integrity level), the UIPI restrictions do not interfere with the
Microsoft UI automation model.
However, there might be times when an administrative user runs an application with elevated privilege based on
UAC in Admin Approval Mode. Microsoft UI Automation cannot drive the UI graphics of elevated applications on
the desktop without the ability to bypass the restrictions that UIPI implements. The ability to bypass UIPI
restrictions across privilege levels is available for UI automation programs by using UIAccess.
If an application presents a UIAccess attribute when it requests privileges, the application is stating a requirement
to bypass UIPI restrictions for sending messages across privilege levels. Devices implement the following policy
checks before starting an application with UIAccess privilege.
1. The application must have a digital signature that can be verified by using a digital certificate that is associated
with the Trusted Root Certification Authorities store on the local device
2. The application must be installed in a local folder that is writeable only by administrators, such as the
Program Files directory. The allowed directories for UI automation applications are:
a. %ProgramFiles% and its subdirectories.
b. %WinDir% and its subdirectories, except a few subdirectories that are excluded because standard users
have write access.
Possible values
Enabled
An application can start with UIAccess integrity only if it resides in a secure location in the file system.
Disabled
An application can start with UIAccess integrity even if it does not reside in a secure location in the file
system.
Best practices
Set this policy to Enabled to permit applications that are located in one of the designated secure directories to
run with UIAccess integrity.
Location
Default values
Policy management
Restart requirement
None. Changes to this policy become effective without a device restart when they aresaved locally or distributed
Group Policy
unit (OU).
Vulnerability
UIAccess integrity allows an application to bypass User Interface Privilege Isolation (UIPI) restrictions when an
application is elevated in privilege from a standard user to an administrator. When this setting is enabled, an
application that has the UIAccess flag set to true in its manifest can interchange information with applications that
are running at a higher privilege level, such as logon prompts and privilege elevation prompts. This ability is
required to support accessibility features such as screen readers that are transmitting user interfaces to alternative
forms, but it is not required by most applications. A process that is started with UIAccess rights has the following
abilities:
Set the foreground window.
Drive any application window by using the SendInput function.
Use read input for all integrity levels by using low-level hooks, raw input, GetKeyState, GetAsyncKeyState, and
GetKeyboardInput.
Set journal hooks.
Use AttachThreadInput to attach a thread to a higher integrity input queue.
Countermeasure
Enable the User Account Control: Only elevate UIAccess applications that are installed in secure locations
setting.
Potential impact
If the application that requests UIAccess meets the UIAccess setting requirements, computers running at least the
Windows Vista operating system start the application with the ability to bypass most of the UIPI restrictions. If the
application does not meet the security restrictions, the application is started without UIAccess rights, and it can
interact only with applications at the same or lower privilege level.
Related topics
Security Options
User Account Control: Run all administrators in
Admin Approval Mode
Applies to
Windows 10
Control: Run all administrators in Admin Approval Mode security policy setting.
Reference
This policy setting determines the behavior of all User Account Control (UAC) policies for the entire system. This is
the setting that turns UAC on or off.
Possible values
Enabled
Admin Approval Mode and all other UAC policies are dependent on this option being enabled. Changing this
setting requires restarting the system.
Disabled
Admin Approval Mode and all related UAC policies are disabled.
Note: If this security setting is configured to Disabled, the Security Center notifies the user that the
overall security of the operating system has been reduced.
Best practices
Enable this policy to allow all other UAC features and policies to function.
Location
Default values

Policy management
Restart requirement
A restart of the computer is required before this policy will be effective when changes to this policy are saved
locally or distributed through Group Policy.
Group Policy
unit (OU).
Vulnerability
This is the setting that turns UAC on or off. If this setting is disabled, UAC is not used, and any security benefits and
risk mitigations that are dependent on UAC are not present on the computer.
Countermeasure
Enable the User Account Control: Run all users, including administrators, as standard users setting.
Potential impact
Users and administrators must learn to work with UAC prompts and adjust their work habits to use least privilege
operations.
Related topics
Security Options
User Account Control: Switch to the secure desktop
when prompting for elevation
Applies to
Windows 10
Account Control: Switch to the secure desktop when prompting for elevation security policy setting.
Reference
This policy setting determines whether the elevation request prompts on the interactive user desktop or on the
secure desktop.
The secure desktop presents the logon UI and restricts functionality and access to the system until the logon
requirements are satisfied.
The secure desktops primary difference from the user desktop is that only trusted processes running as SYSTEM
are allowed to run here (that is, nothing is running at the users privilege level). The path to get to the secure
desktop from the user desktop must also be trusted through the entire chain.
Possible values
Enabled
All elevation requests by default go to the secure desktop.
Disabled
All elevation requests go to the interactive user desktop.
Best practices
Enable the User Account Control: Switch to the secure desktop when prompting for elevation setting.
The secure desktop helps protect against input and output spoofing by presenting the credentials dialog box in
a protected section of memory that is accessible only by trusted system processes.
Location
Default values

Policy management
Restart requirement
Group Policy
unit (OU).
Vulnerability
Elevation prompt dialog boxes can be spoofed, causing users to disclose their passwords to malicious software.
Mouse cursors can be spoofed by hiding the real cursor and replacing it with an offset so the cursor is actually
pointing to the Allow button.
Countermeasure
Enable the User Account Control: Switch to the secure desktop when prompting for elevation setting. The
secure desktop helps protect against input and output spoofing by presenting the credentials dialog box in a
protected section of memory that is accessible only by trusted system processes.
Potential impact
Related topics
Security Options
User Account Control: Virtualize file and registry
write failures to per-user locations
Applies to
Windows 10
Control: Virtualize file and registry write failures to per-user locations security policy setting.
Reference
This policy setting enables or disables the redirection of the write failures of earlier applications to defined locations
in the registry and the file system. This feature mitigates applications that historically ran as administrator and
wrote runtime application data to %ProgramFiles%, %Windir%, %Windir%\system32, or
HKEY_LOCAL_MACHINE\Software\.
This feature can be disabled for applications on devices running at least Windows Vista because it is unnecessary.
Possible values
Enabled
Setting this value facilitates the runtime redirection of application write failures to defined user locations for
the file system and the registry.
Disabled
Applications that write data to protected locations fail.
Best practices
1. If you run applications that are not Windows Vista-compliant, enable this security policy to prevent the
possibility that these older applications could write data to unsecure locations.
2. If you only run at least Windows Vistacompliant applications, this feature is unnecessary so you can disable this
policy.
Location
\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Default values

Policy management
Restart requirement
Group Policy
unit (OU).
Vulnerability
Earlier applications might not write data to secure locations.
Countermeasure
Enable the User Account Control: Virtualize file and registry write failures to per-user locations setting.
Potential impact
Related topics
Security Options
Applies to
Windows 10
Provides information about the advanced security audit policy settings that are available in Windows and the audit
events that they generate.
The security audit policy settings under Security Settings\Advanced Audit Policy Configuration can help your
organization audit compliance with important business-related and security-related rules by tracking precisely
defined activities, such as:
A group administrator has modified settings or data on servers that contain finance information.
An employee within a defined group has accessed an important file.
The correct system access control list (SACL) is applied to every file and folder or registry key on a computer or
file share as a verifiable safeguard against undetected access.
You can access these audit policy settings through the Local Security Policy snap-in (secpol.msc) on the local device
or by using Group Policy.
These Advanced Audit policy settings allow you to select only the behaviors that you want to monitor. You can
exclude audit results for behaviors that are of little or no concern to you, or behaviors that create an excessive
number of log entries. In addition, because security audit policies can be applied by using domain Group Policy
Objects, audit policy settings can be modified, tested, and deployed to selected users and groups with relative
simplicity.
For more info, see Advanced security audit policies.
Applies to
Windows 10
Provides an overview and links to information about the User Rights Assignment security policy settings user
rights that are available in Windows. User rights govern the methods by which a user can log on to a system.
User rights are applied at the local device level, and they allow users to perform tasks on a device or in a
domain. User rights include logon rights and permissions. Logon rights control who is authorized to log on to
a device and how they can log on. User rights permissions control access to computer and domain resources,
and they can override permissions that have been set on specific objects. User rights are managed in Group
Policy under the User Rights Assignment item.
Each user right has a constant name and a Group Policy name associated with it. The constant names are
used when referring to the user right in log events. You can configure the user rights assignment settings in
the following location within the Group Policy Management Console (GPMC) under Computer
Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment, or on the
local device by using the Local Group Policy Editor (gpedit.msc).
For information about setting security policies, see Configure security policy settings.
The following table links to each security policy setting and provides the constant name for each. Setting
descriptions contain reference information, best practices for configuring the policy setting, default values,
differences between operating system versions, and considerations for policy management and security.
GROUP POLICY SETTING CONSTANT NAME
Access Credential Manager as a trusted caller SeTrustedCredManAccessPrivilege
Access this computer from the network SeNetworkLogonRight
Act as part of the operating system SeTcbPrivilege
Add workstations to domain SeMachineAccountPrivilege
Adjust memory quotas for a process SeIncreaseQuotaPrivilege
Allow log on locally SeInteractiveLogonRight
Allow log on through Remote Desktop Services SeRemoteInteractiveLogonRight
Back up files and directories SeBackupPrivilege
Bypass traverse checking SeChangeNotifyPrivilege
Change the system time SeSystemtimePrivilege
Change the time zone SeTimeZonePrivilege

Create a pagefile SeCreatePagefilePrivilege
Create a token object SeCreateTokenPrivilege
Create global objects SeCreateGlobalPrivilege
Create permanent shared objects SeCreatePermanentPrivilege
Create symbolic links SeCreateSymbolicLinkPrivilege
Debug programs SeDebugPrivilege
Deny access to this computer from the network SeDenyNetworkLogonRight
Deny log on as a batch job SeDenyBatchLogonRight
Deny log on as a service SeDenyServiceLogonRight
Deny log on locally SeDenyInteractiveLogonRight
Deny log on through Remote Desktop Services SeDenyRemoteInteractiveLogonRight
Enable computer and user accounts to be trusted for SeEnableDelegationPrivilege

delegation
Force shutdown from a remote system SeRemoteShutdownPrivilege
Generate security audits SeAuditPrivilege
Impersonate a client after authentication SeImpersonatePrivilege
Increase a process working set SeIncreaseWorkingSetPrivilege
Increase scheduling priority SeIncreaseBasePriorityPrivilege
Load and unload device drivers SeLoadDriverPrivilege
Lock pages in memory SeLockMemoryPrivilege
Log on as a batch job SeBatchLogonRight
Log on as a service SeServiceLogonRight
Manage auditing and security log SeSecurityPrivilege
Modify an object label SeRelabelPrivilege
Modify firmware environment values SeSystemEnvironmentPrivilege
Perform volume maintenance tasks SeManageVolumePrivilege

Profile single process SeProfileSingleProcessPrivilege
Profile system performance SeSystemProfilePrivilege
Remove computer from docking station SeUndockPrivilege
Replace a process level token SeAssignPrimaryTokenPrivilege
Restore files and directories SeRestorePrivilege
Shut down the system SeShutdownPrivilege
Synchronize directory service data SeSyncAgentPrivilege
Take ownership of files or other objects SeTakeOwnershipPrivilege
Related topics
Access Credential Manager as a trusted caller
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Access
Credential Manager as a trusted caller security policy setting.
Reference
The Access Credential Manager as a trusted caller policy setting is used by Credential Manager during backup
and restore. No accounts should have this privilege because it is assigned only to the Winlogon service. Saved
credentials of users may be compromised if this privilege is given to other entities.
Constant: SeTrustedCredManAccessPrivilege
Possible values
User-defined list of accounts
Not defined
Best practices
Do not modify this policy setting from the default.
Location
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment
Default values
Policy management
Any change to the user rights assignment for an account becomes effective the next time the owner of the account
logs on.
Group Policy
Vulnerability
If an account is given this user right, the user of the account may create an application that calls into Credential
Manager and is returned the credentials for another user.
Countermeasure
Do not define the Access Credential Manager as a trusted caller policy setting for any accounts besides
Credential Manager.
Potential impact
None. Not defined is the default configuration.
Related topics
Access this computer from the network - security
policy setting
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Access this
computer from the network security policy setting.
Reference
The Access this computer from the network policy setting determines which users can connect to the device
from the network. This capability is required by a number of network protocols, including Server Message Block
(SMB)-based protocols, NetBIOS, Common Internet File System (CIFS), and Component Object Model Plus (COM+).
Users, devices, and service accounts gain or lose the Access this computer from network user right by being
explicitly or implicitly added or removed from a security group that has been granted this user right. For example, a
user account or a machine account may be explicitly added to a custom security group or a built-in security group,
or it may be implicitly added by Windows to a computed security group such as Domain Users, Authenticated
Users, or Enterprise Domain Controllers. By default, user accounts and machine accounts are granted the Access
this computer from network user right when computed groups such as Authenticated Users, and for domain
controllers, the Enterprise Domain Controllers group, are defined in the default domain controllers Group Policy
Object (GPO).
Constant: SeNetworkLogonRight
Possible values
Not defined
Best practices
On desktop devices or member servers, grant this right only to users and administrators.
On domain controllers, grant this right only to authenticated users, enterprise domain controllers, and
administrators.
This setting includes the Everyone group to ensure backward compatibility. Upon Windows upgrade, after you
have verified that all users and groups are correctly migrated, you should remove the Everyone group and use
the Authenticated Users group instead.
Location
Default values
The following table lists the actual and effective default policy values for the most recent supported versions of
Windows. Default values are also listed on the policys property page.
SERVER TYPE OF GPO DEFAULT VALUE

SERVER TYPE OF GPO DEFAULT VALUE
Default domain controller policy Everyone, Administrators, Authenticated Users, Enterprise

Domain Controllers, Pre-Windows 2000 Compatible Access
Stand-alone server default settings Everyone, Administrators, Users, Backup Operators
Domain controller effective default settings Everyone, Administrators, Authenticated Users, Enterprise
Domain Controllers, Pre-Windows 2000 Compatible Access
Member server effective default settings Everyone, Administrators, Users, Backup Operators
Client computer effective default settings Everyone, Administrators, Users, Backup Operators
Policy management
When modifying this user right, the following actions might cause users and services to experience network access
issues:
Removing the Enterprise Domain Controllers security group
Removing the Authenticated Users group or an explicit group that allows users, computers, and service accounts
the user right to connect to computers over the network
Removing all user and machine accounts
logs on.
Group Policy
Vulnerability
Users who can connect from their device to the network can access resources on target devices for which they have
permission. For example, the Access this computer from the network user right is required for users to connect
to shared printers and folders. If this user right is assigned to the Everyone group, anyone in the group can read
the files in those shared folders. This situation is unlikely because the groups created by a default installation of at
least Windows Server 2008 R2 or Windows 7 do not include the Everyone group. However, if a device is upgraded
and the original device includes the Everyone group as part of its defined users and groups, that group is
transitioned as part of the upgrade process and is present on the device.
Countermeasure
Restrict the Access this computer from the network user right to only those users and groups who require
access to the computer. For example, if you configure this policy setting to the Administrators and Users groups,
users who log on to the domain can access resources that are shared from servers in the domain if members of the
Domain Users group are included in the local Users group.
Note If you are using IPsec to help secure network communications in your organization, ensure that a group
that includes machine accounts is given this right. This right is required for successful computer authentication.
Assigning this right to Authenticated Users or Domain Computers meets this requirement.
Potential impact
If you remove the Access this computer from the network user right on domain controllers for all users, no one
can log on to the domain or use network resources. If you remove this user right on member servers, users cannot
connect to those servers through the network. If you have installed optional components such as ASP.NET or
Internet Information Services (IIS), you may need to assign this user right to additional accounts that are required
by those components. It is important to verify that authorized users are assigned this user right for the devices that
they need to access the network.
Related topics
Act as part of the operating system
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Act as part
of the operating system security policy setting.
Reference
The Act as part of the operating system policy setting determines whether a process can assume the identity of
any user and thereby gain access to the resources that the user is authorized to access. Typically, only low-level
authentication services require this user right. Potential access is not limited to what is associated with the user by
default. The calling process may request that arbitrary additional privileges be added to the access token. The
calling process may also build an access token that does not provide a primary identity for auditing in the system
event logs. Constant: SeTcbPrivilege
Possible values
Not defined
Best practices
Do not assign this right to any user accounts. Only assign this user right to trusted users.
If a service requires this user right, configure the service to log on by using the local System account, which
inherently includes this user right. Do not create a separate account and assign this user right to it.
Location
Default values
Policy management
logs on.
Group Policy
Vulnerability
The Act as part of the operating system user right is extremely powerful. Users with this user right can take
complete control of the device and erase evidence of their activities.
Countermeasure
Restrict the Act as part of the operating system user right to as few accounts as possibleit should not even be
assigned to the Administrators group under typical circumstances. When a service requires this user right,
configure the service to log on with the Local System account, which inherently includes this privilege. Do not
create a separate account and assign this user right to it.
Potential impact
There should be little or no impact because the Act as part of the operating system user right is rarely needed
by any accounts other than the Local System account.
Related topics
Add workstations to domain
Applies to
Windows 10
Describes the best practices, location, values, policy management and security considerations for the Add
workstations to domain security policy setting.
Reference
This policy setting determines which users can add a device to a specific domain. For it to take effect, it must be
assigned so that it applies to at least one domain controller. A user who is assigned this user right can add up to ten
workstations to the domain. Adding a machine account to the domain allows the device to participate in Active
Directory-based networking.
Constant: SeMachineAccountPrivilege
Possible values
Not Defined
Best practices
Configure this setting so that only authorized members of the IT team are allowed to add devices to the domain.
Location
Computer Configuration\Windows Settings\Security Settings\User Rights Assignment\
Default values
By default, this setting allows access for Authenticated Users on domain controllers, and it is not defined on stand-
alone servers.
Default Domain Policy Not Defined
Default Domain Controller Policy Not Defined
Stand-Alone Server Default Settings Not Defined
Domain Controller Effective Default Settings Authenticated Users
Member Server Effective Default Settings Not Defined
Client Computer Effective Default Settings Not Defined
Policy management
Users can also join a computer to a domain if they have the Create Computer Objects permission for an
organizational unit (OU) or for the Computers container in the directory. Users who are assigned this permission
can add an unlimited number of devices to the domain regardless of whether they have the Add workstations to
domain user right.
Furthermore, machine accounts that are created by means of the Add workstations to domain user right have
Domain Administrators as the owner of the machine account. Machine accounts that are created by means of
permissions on the computers container use the creator as the owner of the machine account. If a user has
permissions on the container and also has the Add workstation to domain user right, the device is added based
on the computer container permissions rather than the user right.
logs on.
Group Policy
This policy has the following security considerations:
Vulnerability
The Add workstations to domain user right presents a moderate vulnerability. Users with this right could add a
device to the domain that is configured in a way that violates organizational security policies. For example, if your
organization does not want its users to have administrative privileges on their devices, users could install Windows
on their computers and then add the computers to the domain. The user would know the password for the local
administrator account, could log on with that account, and then add a personal domain account to the local
Administrators group.
Countermeasure
Configure this setting so that only authorized members of the IT team are allowed to add computers to the domain.
Potential impact
For organizations that have never allowed users to set up their own computers and add them to the domain, this
countermeasure has no impact. For those that have allowed some or all users to configure their own devices, this
countermeasure forces the organization to establish a formal process for these procedures going forward. It does
not affect existing computers unless they are removed from and then added to the domain.
Related topics
Adjust memory quotas for a process
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Adjust
memory quotas for a process security policy setting.
Reference
This privilege determines who can change the maximum memory that can be consumed by a process. This
privilege is useful for system tuning on a group or user basis.
This user right is defined in the Default Domain Controller Group Policy Object (GPO) and in the local security
policy of workstations and servers.
Constant: SeIncreaseQuotaPrivilege
Possible values
Not Defined
Best practices
1. Restrict the Adjust memory quotas for a process user right to only users who require the ability to adjust
memory quotas to perform their jobs.
2. If this user right is necessary for a user account, it can be assigned to a local machine account instead of to a
domain account.
Location
Computer Configuration\Windows Settings\Security Settings\User Rights Assignment\
Default values
By default, members of the Administrators, Local Service, and Network Service groups have this right.
property page.
Default Domain Policy Administrators

Local Service
Network Service
Default Domain Controller Policy Administrators

Local Service
Network Service

Local Service
Network Service
Domain Controller Effective Default Settings Administrators

Local Service
Network Service

Local Service
Network Service
Client Computer Effective Default Settings Administrators

Local Service
Network Service
Policy management
logs on.
Group Policy
Vulnerability
A user with the Adjust memory quotas for a process privilege can reduce the amount of memory that is
available to any process, which could cause business-critical network applications to become slow or to fail. This
privilege could be used by a malicious user to start a denial-of-service (DoS) attack.
Countermeasure
Restrict the Adjust memory quotas for a process user right to users who require it to perform their jobs, such as
application administrators who maintain database management systems or domain administrators who manage
the organization's directory and its supporting infrastructure.
Potential impact
Organizations that have not restricted users to roles with limited privileges may find it difficult to impose this
countermeasure. Also, if you have installed optional components such as ASP.NET or IIS, you may need to assign
the Adjust memory quotas for a process user right to additional accounts that are required by those
components. IIS requires that this privilege be explicitly assigned to the IWAM_<ComputerName>, Network
Service, and Service accounts. Otherwise, this countermeasure should have no impact on most computers. If this
user right is necessary for a user account, it can be assigned to a local computer account instead of to a domain
account.
Related topics
Allow log on locally - security policy setting
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Allow log on
locally security policy setting.
Reference
This policy setting determines which users can start an interactive session on the device. Users must have this user
right to log on over a Remote Desktop Services session that is running on a Windows-based member device or
domain controller.
Note: Users who do not have this right are still able to start a remote interactive session on the device if they
have the Allow logon through Remote Desktop Services right.
Constant: SeInteractiveLogonRight
Possible values
Not Defined
By default, the members of the following groups have this right on workstations and servers:
Administrators
Backup Operators
Users
By default, the members of the following groups have this right on domain controllers:
Account Operators
Administrators
Backup Operators
Print Operators
Server Operators
Best practices
1. Restrict this user right to legitimate users who must log on to the console of the device.
2. If you selectively remove default groups, you can limit the abilities of users who are assigned to specific
administrative roles in your organization.
Location
Default values
Default Domain Controller Policy Account Operators

Administrators
Backup Operators
Print Operators
Server Operators

Backup Operators
Users
Domain Controller Effective Default Settings Account Operators

Administrators
Backup Operators
Print Operators
Server Operators

Backup Operators
Users

Backup Operators
Users
Policy management
Restarting the device is not required to implement this change.
logs on.
Modifying this setting might affect compatibility with clients, services, and applications. Use caution when removing
service accounts that are used by components and by programs on member devices and on domain controllers in
the domain from the default domain controller's policy. Also use caution when removing users or security groups
that log on to the console of member devices in the domain, or removing service accounts that are defined in the
local Security Accounts Manager (SAM) database of member devices or of workgroup devices. If you want to grant
a user account the ability to log on locally to a domain controller, you must make that user a member of a group
that already has the Allowed logon locally system right or grant the right to that user account. The domain
controllers in the domain share the Default Domain Controllers Group Policy Object (GPO). When you grant an
account the Allow logon locally right, you are allowing that account to log on locally to all domain controllers in
the domain. If the Users group is listed in the Allow log on locally setting for a GPO, all domain users can log on
locally. The Users built-in group contains Domain Users as a member.
Group Policy
Group Policy settings are applied through GPOs in the following order, which will overwrite settings on the local
computer at the next Group Policy update:
Vulnerability
Any account with the Allow log on locally user right can log on to the console of the device. If you do not restrict
this user right to legitimate users who must log on to the console of the computer, unauthorized users could
download and run malicious software to elevate their privileges.
Countermeasure
For domain controllers, assign the Allow log on locally user right only to the Administrators group. For other
server roles, you may choose to add Backup Operators in addition to Administrators. For end-user computers, you
should also assign this right to the Users group. Alternatively, you can assign groups such as Account Operators,
Server Operators, and Guests to the Deny log on locally user right.
Potential impact
If you remove these default groups, you could limit the abilities of users who are assigned to specific administrative
roles in your environment. If you have installed optional components such as ASP.NET or IIS, you may need to
assign the Allow log on locally user right to additional accounts that are required by those components. IIS
requires that this user right be assigned to the IUSR_<ComputerName> account. You should confirm that
delegated activities are not adversely affected by any changes that you make to the Allow log on locally user
rights assignments.
Related topics
Allow log on through Remote Desktop Services
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Allow log on
through Remote Desktop Services security policy setting.
Reference
This policy setting determines which users or groups can access the logon screen of a remote device through a
Remote Desktop Services connection. It is possible for a user to establish a Remote Desktop Services connection to
a particular server but not be able to log on to the console of that same server.
Constant: SeRemoteInteractiveLogonRight
Possible values
Not Defined
Best practices
To control who can open a Remote Desktop Services connection and log on to the device, add users to or
remove users from the Remote Desktop Users group.
Location
Default values
By default, members of the Administrators group have this right on domain controllers, workstations, and servers.
The Remote Desktops Users group also has this right on workstations and servers. The following table lists the
actual and effective default policy values. Default values are also listed on the policys property page.

Remote Desktop Users


Policy management
Group Policy
To use Remote Desktop Services to successfully log on to a remote device, the user or group must be a member of
the Remote Desktop Users or Administrators group and be granted the Allow log on through Remote Desktop
Services right. It is possible for a user to establish an Remote Desktop Services session to a particular server, but
not be able to log on to the console of that same server.
To exclude users or groups, you can assign the Deny log on through Remote Desktop Services user right to
those users or groups. However, be careful when you use this method because you could create conflicts for
legitimate users or groups that have been allowed access through the Allow log on through Remote Desktop
Services user right.
For more information, see Deny log on through Remote Desktop Services.
logs on.
Group Policy settings are applied through GPOs in the following order, which will overwrite settings on the local
computer at the next Group Policy update:
Vulnerability
Any account with the Allow log on through Remote Desktop Services user right can log on to the remote
console of the device. If you do not restrict this user right to legitimate users who must log on to the console of the
computer, unauthorized users could download and run malicious software to elevate their privileges.
Countermeasure
For domain controllers, assign the Allow log on through Remote Desktop Services user right only to the
Administrators group. For other server roles and devices, add the Remote Desktop Users group. For servers that
have the Remote Desktop (RD) Session Host role service enabled and do not run in Application Server mode,
ensure that only authorized IT personnel who must manage the computers remotely belong to these groups.
Caution: For RD Session Host servers that run in Application Server mode, ensure that only users who require
access to the server have accounts that belong to the Remote Desktop Users group because this built-in group
has this logon right by default.
Alternatively, you can assign the Deny log on through Remote Desktop Services user right to groups such as
Account Operators, Server Operators, and Guests. However, be careful when you use this method because you
could block access to legitimate administrators who also belong to a group that has the Deny log on through
Remote Desktop Services user right.
Potential impact
Removal of the Allow log on through Remote Desktop Services user right from other groups (or membership
changes in these default groups) could limit the abilities of users who perform specific administrative roles in your
environment. You should confirm that delegated activities are not adversely affected.
Related topics
Back up files and directories - security policy setting
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Back up files
and directories security policy setting.
Reference
This user right determines which users can bypass file and directory, registry, and other persistent object
permissions for the purposes of backing up the system. This user right is effective only when an application
attempts access through the NTFS backup application programming interface (API) through a backup tool such as
NTBACKUP.EXE. Otherwise, standard file and directory permissions apply.
This user right is similar to granting the following permissions to the user or group you have selected on all files
and folders on the system:
List Folder/Read Data
Read Attributes
Read Extended Attributes
Read Permissions
Default on workstations and servers:
Administrators
Backup Operators
Default on domain controllers:
Administrators
Backup Operators
Server Operators
Constant: SeBackupPrivilege
Possible values
Not Defined
Best practices
1. Restrict the Back up files and directories user right to members of the IT team who must back up
organizational data as part of their daily job responsibilities. Because there is no way to be sure that a user is
backing up data, stealing data, or copying data to be distributed, only assign this user right to trusted users.
2. If you are using backup software that runs under specific service accounts, only these accounts (and not the IT
staff) should have the Back up files and directories user right.
Location
Default values
By default, this right is granted to Administrators and Backup Operators on workstations and servers. On domain
controllers, Administrators, Backup Operators, and Server Operators have this right.
property page.

Backup Operators
Server Operators

Backup Operators

Backup Operators
Server Operators

Backup Operators

Backup Operators
Policy management
logs on.
Group Policy
Vulnerability
Users who can back up data from a device could take the backup media to a non-domain computer on which they
have administrative privileges, and then restore the data. They could take ownership of the files and view any
unencrypted data that is contained within the backup set.
Countermeasure
Restrict the Back up files and directories user right to members of the IT team who must back up organizational
data as part of their daily job responsibilities. If you are using backup software that runs under specific service
accounts, only these accounts (and not the IT staff) should have the Back up files and directories user right.
Potential impact
Changes in the membership of the groups that have the Back up files and directories user right could limit the
abilities of users who are assigned to specific administrative roles in your environment. You should confirm that
authorized backup administrators can still perform backup operations.
Related topics
Applies to
Windows 10
Learn more about what features and functionality are supported in each Windows edition at Compare
Windows 10 Editions.
Describes the best practices, location, values, policy management, and security considerations for the Bypass
traverse checking security policy setting.
Reference
This policy setting determines which users (or a process that acts on behalf of the users account) have permission
to navigate an object path in the NTFS file system or in the registry without being checked for the Traverse Folder
special access permission. This user right does not allow the user to list the contents of a folder. It only allows the
user to traverse folders to access permitted files or subfolders.
Constant: SeChangeNotifyPrivilege
Possible values
Not Defined
Best practices
1. Use accessbased enumeration when you want to prevent users from seeing any folder or file to which they do
not have access.
2. Use the default settings of this policy in most cases. If you change the settings, verify your intent through testing.
Location
Default values
property page.

Authenticated Users
Everyone
Local Service
Network Service
Pre-Windows 2000 Compatible Access

Backup Operators
Users
Everyone
Local Service
Network Service

Authenticated Users
Everyone
Local Service
Network Service
Pre-Windows 2000 Compatible Access

Backup Operators
Users
Everyone
Local Service
Network Service

Backup Operators
Users
Everyone
Local Service
Network Service
Policy management
Permissions to files and folders are controlled though the appropriate configuration of file system access control
lists (ACLs).The ability to traverse the folder does not provide any Read or Write permissions to the user.
logs on.
Group Policy
Vulnerability
The default configuration for the Bypass traverse checking setting is to allow all users to bypass traverse
checking. Permissions to files and folders are controlled though the appropriate configuration of file system access
control lists (ACLs) because the ability to traverse the folder does not provide any Read or Write permissions to the
user. The only scenario in which the default configuration could lead to a mishap would be if the administrator who
configures permissions does not understand how this policy setting works. For example, the administrator might
expect that users who are unable to access a folder are unable to access the contents of any child folders. Such a
situation is unlikely, and, therefore, this vulnerability presents little risk.
Countermeasure
Organizations that are extremely concerned about security may want to remove the Everyone group, and perhaps
the Users group, from the list of groups that have the Bypass traverse checking user right. Taking explicit control
over traversal assignments can be an effective way to limit access to sensitive information. Accessbased
enumeration can also be used. If you use accessbased enumeration, users cannot see any folder or file to which
they do not have access. For more info about this feature, see Access-based Enumeration.
Potential impact
The Windows operating systems and many applications were designed with the expectation that anyone who can
legitimately access the computer will have this user right. Therefore, we recommend that you thoroughly test any
changes to assignments of the Bypass traverse checking user right before you make such changes to production
systems. In particular, IIS requires this user right to be assigned to the Network Service, Local Service, IIS_WPG,
IUSR_<ComputerName>, and IWAM_<ComputerName> accounts. (It must also be assigned to the ASPNET
account through its membership in the Users group.) We recommend that you leave this policy setting at its default
configuration.
Related topics
Change the system time - security policy setting
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Change the
system time security policy setting.
Reference
This policy setting determines which users can adjust the time on the device's internal clock. This right allows the
computer user to change the date and time associated with records in the event logs, database transactions, and
the file system. This right is also required by the process that performs time synchronization. This setting does not
impact the users ability to change the time zone or other display characteristics of the system time. For info about
assigning the right to change the time zone, see Change the time zone.
Constant: SeSystemtimePrivilege
Possible values
Not Defined
Best practices
Restrict the Change the system time user right to users with a legitimate need to change the system time.
Location
Default values
By default, members of the Administrators and Local Service groups have this right on workstations and servers.
Members of the Administrators, Server Operators, and Local Service groups have this right on domain controllers.
property page.

Server Operators
Local Service

Local Service

Server Operators
Local Service

Local Service

Local Service
Policy management
This section describes features, tools and guidance to help you manage this policy.
logs on.
Group Policy
Vulnerability
Users who can change the time on a computer could cause several problems. For example:
Time stamps on event log entries could be made inaccurate
Time stamps on files and folders that are created or modified could be incorrect
Computers that belong to a domain might not be able to authenticate themselves
Users who try to log on to the domain from devices with inaccurate time might not be able to authenticate.
Also, because the Kerberos authentication protocol requires that the requester and authenticator have their clocks
synchronized within an administrator-defined skew period, an attacker who changes a device's time may cause that
computer to be unable to obtain or grant Kerberos protocol tickets.
The risk from these types of events is mitigated on most domain controllers, member servers, and end-user
computers because the Windows Time Service automatically synchronizes time with domain controllers in the
following ways:
All desktop client devices and member servers use the authenticating domain controller as their inbound time
partner.
All domain controllers in a domain nominate the primary domain controller (PDC) emulator operations master
as their inbound time partner.
All PDC emulator operations masters follow the hierarchy of domains in the selection of their inbound time
partner.
The PDC emulator operations master at the root of the domain is authoritative for the organization. Therefore,
we recommend that you configure this computer to synchronize with a reliable external time server.
This vulnerability becomes much more serious if an attacker is able to change the system time and then stop the
Windows Time Service or reconfigure it to synchronize with a time server that is not accurate.
Countermeasure
Restrict the Change the system time user right to users with a legitimate need to change the system time, such as
members of the IT team.
Potential impact
There should be no impact because time synchronization for most organizations should be fully automated for all
computers that belong to the domain. Computers that do not belong to the domain should be configured to
synchronize with an external source, such as a web service.
Related topics
Change the time zone - security policy setting
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Change the
time zone security policy setting.
Reference
This policy setting determines which users can adjust the time zone that is used by the device for displaying the
local time, which includes the device's system time plus the time zone offset.
Constant: SeTimeZonePrivilege
Possible values
Not Defined
Best practices
None.
Location
Default values

Users

Users

Users

Users

Users
Policy management
Any change to the account for this user right assignment becomes effective the next time the account logs on.
Group Policy
Vulnerability
Changing the time zone represents little vulnerability because the system time is not affected. This setting merely
enables users to display their preferred time zone while being synchronized with domain controllers in different
time zones.
Countermeasure
Countermeasures are not required because system time is not affected by this setting.
Potential impact
None.
Related topics
Create a pagefile - security policy setting
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Create a
pagefile security policy setting.
Reference
Windows designates a section of the hard drive as virtual memory known as the page file, or more specifically, as
pagefile.sys. It is used to supplement the computers Random Access Memory (RAM) to improve performance for
programs and data that are used frequently. Although the file is hidden from browsing, you can manage it using
the system settings.
This policy setting determines which users can create and change the size of a page file. It determines whether
users can specify a page file size for a particular drive in the Performance Options box located on the Advanced
tab of the System Properties dialog box or through using internal application interfaces (APIs).
Constant: SeCreatePagefilePrivilege
Possible values
Administrators
Best practices
Restrict the Create a pagefile user right to Administrators, which is the default.
Location
Default values
By default, members of the Administrators group have this right.
Default Domain Policy Administrators

Policy management
logs on.
Group Policy
Vulnerability
Users who can change the page file size could make it extremely small or move the file to a highly fragmented
storage volume, which could cause reduced device performance.
Countermeasure
Restrict the Create a pagefile user right to members of the Administrators group.
Potential impact
None. Restricting this right to members of the Administrators group is the default configuration.
Related topics
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Create a
token object security policy setting.
Reference
This policy setting determines which accounts a process can use to create a token, and which accounts it can then
use to gain access to local resources when the process uses NtCreateToken() or other token-creation APIs.
When a user logs on to the local device or connects to a remote device through a network, Windows builds the
users access token. Then the system examines the token to determine the level of the user's privileges. When you
revoke a privilege, the change is immediately recorded, but the change is not reflected in the user's access token
until the next time the user logs on or connects.
Constant: SeCreateTokenPrivilege
Possible values
Not Defined
Best practices
This user right is used internally by the operating system. Unless it is necessary, do not assign this user right to a
user, group, or process other than Local System.
Location
Default values
This user right is used internally by the operating system. By default, it is not assigned to any user groups.
property page.
Domain Controller Effective Default Settings Local System
Member Server Effective Default Settings Local System

Client Computer Effective Default Settings Local System
Policy management
logs on.
Group Policy
Vulnerability
Caution: A user account that is given this user right has complete control over the system, and it can lead to
the system being compromised. We highly recommend that you do not assign this right to any user accounts.
Windows examines a user's access token to determine the level of the user's privileges. Access tokens are built
when users log on to the local device or connect to a remote device over a network. When you revoke a privilege,
the change is immediately recorded, but the change is not reflected in the user's access token until the next time the
user logs on or connects. Users with the ability to create or modify tokens can change the level of access for any
account on a computer if they are currently logged on. They could escalate their privileges or create a DoS
condition.
Countermeasure
Do not assign the Create a token object user right to any users. Processes that require this user right should use
the Local System account, which already includes it, instead of a separate user account that has this user right
assigned.
Potential impact
None. Not Defined is the default configuration.
Related topics
Create global objects
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Create
global objects security policy setting.
Reference
This policy setting determines which users can create global objects that are available to all sessions. Users can still
create objects that are specific to their own session if they do not have this user right.
A global object is an object that is created to be used by any number of processes or threads, even those not started
within the users session. Remote Desktop Services uses global objects in its processes to facilitate connections and
access.
Constant: SeCreateGlobalPrivilege
Possible values
Default accounts listed below
Best practices
Do not assign any user accounts this right.
Location
Default values
By default, members of the Administrators group have this right, as do Local Service and Network Service accounts
on the supported versions of Windows. Service is included for backwards compatibility with earlier versions of
Windows.
property page.

Local Service
Network Service
Service

Local Service
Network Service
Service

Local Service
Network Service
Service

Local Service
Network Service
Service

Local Service
Network Service
Service
Policy management
A restart of the device is not required for this policy setting to take effect.
logs on.
Group Policy
Vulnerability
Caution: A user account that is given this user right has complete control over the system, and it can lead to
the system being compromised. We highly recommend that you do not assign this right to any user accounts.
Windows examines a user's access token to determine the level of the user's privileges. Access tokens are built
when users log on to the local device or connect to a remote device over a network. When you revoke a privilege,
the change is immediately recorded, but the change is not reflected in the user's access token until the next time the
user logs on or connects. Users with the ability to create or modify tokens can change the level of access for any
currently logged on account. They could escalate their privileges or create a denial-of-service (DoS) condition.
Countermeasure
Do not assign the Create a token object user right to any users. Processes that require this user right should use
the Local System account, which already includes it, instead of a separate user account with this user right assigned.
Potential impact
None. Not Defined is the default domain policy configuration.
Related topics
Create permanent shared objects
Applies to
Windows 10
permanent shared objects security policy setting.
Reference
This user right determines which accounts can be used by processes to create a directory object by using the object
manager. Directory objects include Active Directory objects, files and folders, printers, registry keys, processes, and
threads. Users who have this capability can create permanent shared objects, including devices, semaphores, and
mutexes. This user right is useful to kernel-mode components that extend the object namespace. Because
components that are running in kernel-mode inherently have this user right assigned to them, it is not necessary to
specifically assign it.
Constant: SeCreatePermanentPrivilege
Possible values
Not Defined
Best practices
Users who have the Create permanent shared objects user right could create new shared objects and expose
sensitive data to the network. Therefore, do not assign this right to any users.
Location
Default values
By default, LocalSystem is the only account that has this right.
Domain Controller Effective Default Settings LocalSystem
Member Server Effective Default Settings LocalSystem
Client Computer Effective Default Settings LocalSystem

Policy management
logs on.
Group Policy
Vulnerability
Users who have the Create permanent shared objects user right could create new shared objects and expose
sensitive data to the network.
Countermeasure
Do not assign the Create permanent shared objects user right to any users. Processes that require this user right
should use the System account, which already includes this user right, instead of a separate user account.
Potential impact
None. Not Defined is the default configuration.
Related topics
Applies to
Windows 10
symbolic links security policy setting.
Reference
This user right determines if users can create a symbolic link from the device they are logged on to.
A symbolic link is a file-system object that points to another file-system object. The object that is pointed to is called
the target. Symbolic links are transparent to users. The links appear as normal files or directories, and they can be
acted upon by the user or application in exactly the same manner. Symbolic links are designed to aid in migration
and application compatibility with UNIX operating systems. Microsoft has implemented symbolic links to function
just like UNIX links.
Warning: This privilege should only be given to trusted users. Symbolic links can expose security
vulnerabilities in applications that aren't designed to handle them. Constant: SeCreateSymbolicLinkPrivilege
Possible values
Not Defined
Best practices
This user right should only be given to trusted users. Symbolic links can expose security vulnerabilities in
applications that are not designed to handle them.
Location
Default values
property page.

Policy management
logs on.
Group Policy
Command-line tools
This setting can be used in conjunction with a symbolic link file system setting that can be manipulated with the
command-line tool to control the kinds of symlinks that are allowed on the device. For more info, type fsutil
behavior set symlinkevalution /? at the command prompt.
Vulnerability
Users who have the Create symbolic links user right could inadvertently or maliciously expose your system to
symbolic link attacks. Symbolic link attacks can be used to change the permissions on a file, to corrupt data, to
destroy data, or as a DoS attack.
Countermeasure
Do not assign the Create symbolic links user right to standard users. Restrict this right to trusted administrators.
You can use the fsutil command to establish a symbolic link file system setting that controls the kind of symbolic
links that can be created on a computer.
Potential impact
Related topics
Debug programs
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Debug
programs security policy setting.
Reference
This policy setting determines which users can attach to or open any process, even those they do not own.
Developers who are debugging their own applications do not need to be assigned this user right. Developers who
are debugging new system components need this user right. This user right provides access to sensitive and critical
operating-system components.
Constant: SeDebugPrivilege
Possible values
Not defined
Best practices
Assign this user right only to trusted users to reduce security vulnerabilities.
Location
Default values
Policy management
logs on.
Group Policy
Vulnerability
The Debug programs user right can be exploited to capture sensitive device information from system memory or
to access and modify kernel or application structures. Some attack tools exploit this user right to extract hashed
passwords and other private security information or to insert malware. By default, the Debug programs user right
is assigned only to administrators, which helps mitigate risk from this vulnerability.
Countermeasure
Remove the accounts of all users and groups that do not require the Debug programs user right.
Potential impact
If you revoke this user right, no one can debug programs. However, typical circumstances rarely require this
capability on production devices. If an issue arises that requires an application to be debugged on a production
server, you can move the server to a different organizational unit (OU) temporarily and assign the Debug
programs user right to a separate Group Policy for that OU.
Related topics
Deny access to this computer from the network
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Deny access
to this computer from the network security policy setting.
Reference
This security setting determines which users are prevented from accessing a device over the network.
Constant: SeDenyNetworkLogonRight
Possible values
Guest
Best practices
Because all Active Directory Domain Services programs use a network logon for access, use caution when you
assign this user right on domain controllers.
Location
Default values
By default, this setting is Guest on domain controllers and on stand-alone servers.
property page.
Default Domain Controller Policy Guest
Stand-Alone Server Default Settings Guest
Domain Controller Effective Default Settings Guest
Member Server Effective Default Settings Guest
Client Computer Effective Default Settings Guest
Policy management
This section describes features and tools available to help you manage this policy.
This policy setting supersedes the Access this computer from the network policy setting if a user account is
subject to both policies.
logs on.
Group Policy
Vulnerability
Users who can log on to the device over the network can enumerate lists of account names, group names, and
shared resources. Users with permission to access shared folders and files can connect over the network and
possibly view or modify data.
Countermeasure
Assign the Deny access to this computer from the network user right to the following accounts:
Anonymous logon
Built-in local Administrator account
Local Guest account
All service accounts
An important exception to this list is any service accounts that are used to start services that must connect to the
device over the network. For example, lets say you have configured a shared folder for web servers to access, and
you present content within that folder through a website. You may need to allow the account that runs IIS to log on
to the server with the shared folder from the network. This user right is particularly effective when you must
configure servers and workstations on which sensitive information is handled because of regulatory compliance
concerns.
Potential impact
If you configure the Deny access to this computer from the network user right for other accounts, you could
limit the abilities of users who are assigned to specific administrative roles in your environment. You should verify
that delegated tasks are not negatively affected.
Related topics
Deny log on as a batch job
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Deny log on
as a batch job security policy setting.
Reference
This policy setting determines which accounts are prevented from logging on by using a batch-queue tool to
schedule and start jobs automatically in the future. The ability to log on by using a batch-queue tool is needed for
any account that is used to start scheduled jobs by means of the Task Scheduler.
Constant: SeDenyBatchLogonRight
Possible values
Not defined
Best practices
1. When you assign this user right, thoroughly test that the effect is what you intended.
2. Within a domain, modify this setting on the applicable Group Policy Object (GPO).
3. Deny log on as a batch job prevents administrators or operators from using their personal accounts to
schedule tasks, which helps with business continuity when that person transitions to other positions or
responsibilities.
Location
Default values
Domain Controller Effective Default Settings Not defined

Policy management
logs on.
This policy setting might conflict with and negate the Log on as a batch job setting.
Group Policy
On a domain-joined device, including the domain controller, this policy can be overwritten by a domain policy,
which will prevent you from modifying the local policy setting.
For example, if you are trying to configure Task Scheduler on your domain controller, check the Settings tab of your
two domain controller policy and domain policy GPOs in the Group Policy Management Console (GPMC). Verify
the targeted account is not present in the Deny log on as a batch job
User Rights Assignment and also correctly configured in the Log on as a batch job setting.
Vulnerability
Accounts that have the Deny log on as a batch job user right could be used to schedule jobs that could consume
excessive computer resources and cause a denial-of-service condition.
Countermeasure
Assign the Deny log on as a batch job user right to the local Guest account.
Potential impact
If you assign the Deny log on as a batch job user right to other accounts, you could deny the ability to perform
required job activities to users who are assigned specific administrative roles. You should confirm that delegated
tasks are not affected adversely.
Related topics
Deny log on as a service
Applies to
Windows 10
as a service security policy setting.
Reference
This policy setting determines which users are prevented from logging on to the service applications on a device.
A service is an application type that runs in the system background without a user interface. It provides core
operating system features, such as web serving, event logging, file serving, printing, cryptography, and error
reporting.
Constant: SeDenyServiceLogonRight
Possible values
Not defined
Best practices
1. When you assign this user right, thoroughly test that the effect is what you intended.
2. Within a domain, modify this setting on the applicable Group Policy Object (GPO).
Location
Default values
Policy management
logs on.
Group Policy
On a domain-joined device, including the domain controller, this policy can be overwritten by a domain policy,
which will prevent you from modifying the local policy setting.
This policy setting might conflict with and negate the Log on as a service setting.
Vulnerability
Accounts that can log on to a service application could be used to configure and start new unauthorized services,
such as a keylogger or other malware. The benefit of the specified countermeasure is somewhat reduced by the fact
that only users with administrative rights can install and configure services, and an attacker who has already
attained that level of access could configure the service to run by using the System account.
Countermeasure
We recommend that you not assign the Deny log on as a service user right to any accounts. This is the default
configuration. Organizations that are extremely concerned about security might assign this user right to groups
and accounts when they are certain that they will never need to log on to a service application.
Potential impact
If you assign the Deny log on as a service user right to specific accounts, services may not start and a denial-of-
service condition could result.
Related topics
Deny log on locally
Applies to
Windows 10
locally security policy setting.
Reference
This policy setting determines which users are prevented from logging on directly at the device's console.
Constant: SeDenyInteractiveLogonRight
Possible values
Not defined
Best practices
1. Assign the Deny log on locally user right to the local guest account to restrict access by potentially
unauthorized users.
2. Test your modifications to this policy setting in conjunction with the Allow log on locally policy setting to
determine if the user account is subject to both policies.
Location
Default values
Policy management
logs on.
If you apply this policy setting to the Everyone group, no one will be able to log on locally.
Group Policy
This policy setting supersedes the Allow log on locally policy setting if a user account is subject to both policies.
Vulnerability
Any account with the ability to log on locally could be used to log on at the console of the device. If this user right is
not restricted to legitimate users who must log on to the console of the device, unauthorized users might
download and run malicious software that elevates their user rights.
Countermeasure
Assign the Deny log on locally user right to the local Guest account. If you have installed optional components
such as ASP.NET, you may want to assign this user right to additional accounts that are required by those
components.
Potential impact
If you assign the Deny log on locally user right to additional accounts, you could limit the abilities of users who
are assigned to specific roles in your environment. However, this user right should explicitly be assigned to the
ASPNET account on device that are configured with the Web Server role. You should confirm that delegated
activities are not adversely affected.
Related topics
Deny log on through Remote Desktop Services
Applies to
Windows 10
through Remote Desktop Services security policy setting.
Reference
This policy setting determines which users are prevented from logging on to the device through a Remote Desktop
connection through Remote Desktop Services. It is possible for a user to establish a Remote Desktop connection to
a particular server, but not be able to log on to the console of that server.
Constant: SeDenyRemoteInteractiveLogonRight
Possible values
Not defined
Best practices
To control who can open a Remote Desktop connection and log on to the device, add the user account to or
remove user accounts from the Remote Desktop Users group.
Location
Default values
Policy management
logs on.
The Remote System property controls settings for Remote Desktop Services (Allow or prevent remote
connections to the computer) and for Remote Assistance (Allow Remote Assistance connections to this
computer).
Group Policy
This policy setting supersedes the Allow log on through Remote Desktop Services policy setting if a user account is
subject to both policies.
Group Policy settings are applied in the following order. They overwrite settings on the local device at the next
Group Policy update.
4. Organizational unit policy settings
Vulnerability
Any account with the right to log on through Remote Desktop Services could be used to log on to the remote
console of the device. If this user right is not restricted to legitimate users who need to log on to the console of the
computer, malicious users might download and run software that elevates their user rights.
Countermeasure
Assign the Deny log on through Remote Desktop Services user right to the built-in local guest account and all
service accounts. If you have installed optional components, such as ASP.NET, you may want to assign this user
right to additional accounts that are required by those components.
Potential impact
If you assign the Deny log on through Remote Desktop Services user right to other groups, you could limit the
abilities of users who are assigned to specific administrative roles in your environment. Accounts that have this
user right cannot connect to the device through Remote Desktop Services or Remote Assistance. You should
confirm that delegated tasks are not negatively affected.
Related topics
Enable computer and user accounts to be trusted for
delegation
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Enable
computer and user accounts to be trusted for delegation security policy setting.
Reference
This policy setting determines which users can set the Trusted for Delegation setting on a user or computer
object. Security account delegation provides the ability to connect to multiple servers, and each server change
retains the authentication credentials of the original client. Delegation of authentication is a capability that client
and server applications use when they have multiple tiers. It allows a public-facing service to use client credentials
to authenticate to an application or database service. For this configuration to be possible, the client and the server
must run under accounts that are trusted for delegation.
Only administrators who have the Enable computer and user accounts to be trusted for delegation credential
can set up delegation. Domain admins and Enterprise admins have this credential. The procedure to allow a user to
be trusted for delegation depends on the functionality level of the domain.
The user or machine object that is granted this right must have write access to the account control flags. A server
process running on a device (or under a user context) that is trusted for delegation can access resources on another
computer by using the delegated credentials of a client. However, the client account must have Write access to the
account control flags on the object.
Constant: SeEnableDelegationPrivilege
Possible values
Not defined
Best practices
There is no reason to assign this user right to anyone on member servers and workstations that belong to a
domain because it has no meaning in those contexts. It is only relevant on domain controllers and stand-alone
devices.
Location
Default values

Policy management
This section describes features, tools and guidance to help you manage this policy.
Modifying this setting might affect compatibility with clients, services, and applications.
logs on.
Group Policy
Vulnerability
Misuse of the Enable computer and user accounts to be trusted for delegation user right could allow
unauthorized users to impersonate other users on the network. An attacker could exploit this privilege to gain
access to network resources and make it difficult to determine what has happened after a security incident.
Countermeasure
The Enable computer and user accounts to be trusted for delegation user right should be assigned only if
there is a clear need for its functionality. When you assign this right, you should investigate the use of constrained
delegation to control what the delegated accounts can do. On domain controllers, this right is assigned to the
Administrators group by default.
Note: There is no reason to assign this user right to anyone on member servers and workstations that belong
to a domain because it has no meaning in those contexts. It is only relevant on domain controllers and stand-
alone computers.
Potential impact
Related topics
Force shutdown from a remote system
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Force
shutdown from a remote system security policy setting.
Reference
This security setting determines which users are allowed to shut down a device from a remote location on the
network. This allows members of the Administrators group or specific users to manage computers (for tasks such
as a restart) from a remote location.
Constant: SeRemoteShutdownPrivilege
Possible values
Administrators
Best practices
Explicitly restrict this user right to members of the Administrators group or other specifically assigned roles that
require this capability, such as non-administrative operations staff.
Location
Default values
By default this setting is Administrators and Server Operators on domain controllers and Administrators on stand-
alone servers.

Server Operators

Server Operators

Policy management
logs on.
This policy setting must be applied on the computer that is being accessed remotely.
Group Policy
Vulnerability
Any user who can shut down a device could cause a denial-of-service condition to occur. Therefore, this user right
should be tightly restricted.
Countermeasure
Restrict the Force shutdown from a remote system user right to members of the Administrators group or other
specifically assigned roles that require this capability, such as non-administrative operations staff.
Potential impact
On a domain controller, if you remove the Force shutdown from a remote system user right from the Server
Operator group, you could limit the abilities of users who are assigned to specific administrative roles in your
environment. You should confirm that delegated activities are not adversely affected.
Related topics
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Generate
security audits security policy setting.
Reference
This policy setting determines which accounts can be used by a process to generate audit records in the security
event log. The Local Security Authority Subsystem Service (LSASS) writes events to the log. You can use the
information in the security event log to trace unauthorized device access.
Constant: SeAuditPrivilege
Possible values
Local Service
Network Service
Best practices
Because the audit log can potentially be an attack vector if an account is compromised, ensure that only the
Local Service and Network Service accounts have the Generate security audits user right assigned to them.
Location
Default values
By default, this setting is Local Service and Network Service on domain controllers and stand-alone servers.
Default Domain Controller Policy Local Service

Network Service
Stand-Alone Server Default Settings Local Service

Network Service
Domain Controller Effective Default Settings Local Service

Network Service
Member Server Effective Default Settings Local Service

Network Service
Client Computer Effective Default Settings Local Service

Network Service
Policy management
logs on.
Misuse of this user right can result in the generation of many auditing events, potentially hiding evidence of an
attack or causing a denial-of-service (DoS) if the Audit: Shut down system immediately if unable to log security
audits security policy setting is enabled.
Group Policy
Vulnerability
A malicious user could use accounts that can write to the Security log to fill that log with meaningless events. If the
computer is configured to overwrite events as needed, malicious users could use this method to remove evidence
of their unauthorized activities. If the computer is configured to shut down when it is unable to write to the Security
log, and it is not configured to automatically back up the log files, this method could be used to create a DoS
condition.
Countermeasure
Ensure that only the Local Service and Network Service accounts have the Generate security audits user right
assigned to them.
Potential impact
None. Restricting the Generate security audits user right to the Local Service and Network Service accounts is the
default configuration.
Related topics
Impersonate a client after authentication
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Impersonate
a client after authentication security policy setting.
Reference
This policy setting determines which programs are allowed to impersonate a user or another specified account and
act on behalf of the user. If this user right is required for this type of impersonation, an unauthorized user cannot
cause a client to connect (for example, by remote procedure call (RPC) or named pipes) to a service that they have
created to impersonate that client. (Such an action could elevate the unauthorized user's permissions to
administrative or system levels.)
Impersonation is the ability of a thread to run in a security context that is different from the context of the process
that owns the thread. Impersonation is designed to meet the security requirements of client/server applications.
When running in a client's security context, a service "is" the client, to some degree. One of the service's threads
uses an access token representing the client's credentials to obtain access to the objects to which the client has
access. The primary reason for impersonation is to cause access checks to be performed against the client's identity.
Using the client's identity for access checks can cause access to be either restricted or expanded, depending on
what the client has permission to do.
Services that are started by the Service Control Manager have the built-in Service group added by default to their
access tokens. COM servers that are started by the COM infrastructure and configured to run under a specific
account also have the Service group added to their access tokens. As a result, these processes are assigned this user
right when they are started.
Constant: SeImpersonatePrivilege
Possible values
Default values
Not defined
Best practices
A user can impersonate an access token if any of the following conditions exist:
The access token that is being impersonated is for this user.
The user in this session logged on to the network with explicit credentials to create the access token.
The requested level is less than Impersonate, such as Anonymous or Identify.
Because of these factors, users do not usually need to have this user right assigned.
Location
Default values
By default, this setting is Administrators, Local Service, Network Service, and Service on domain controllers and
stand-alone servers.
property page.

Local Service
Network Service
Service

Local Service
Network Service
Service

Local Service
Network Service
Service

Local Service
Network Service
Service

Local Service
Network Service
Service
Policy management
logs on.
Group Policy
Vulnerability
An attacker with the Impersonate a client after authentication user right could create a service, mislead a client
into connecting to the service, and then impersonate that computer to elevate the attacker's level of access to that
of the device.
Countermeasure
On member servers, ensure that only the Administrators and Service groups (Local Service, Network Service, and
Service) have the Impersonate a client after authentication user right assigned to them.
Potential impact
In most cases, this configuration has no impact. If you have installed optional components such as ASP.NET or IIS,
you may need to assign the Impersonate a client after authentication user right to additional accounts that are
required by those components, such as IUSR_<ComputerName>, IIS_WPG, ASP.NET, or IWAM_<ComputerName>.
Related topics
Increase a process working set
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Increase a
process working set security policy setting.
Reference
This policy setting determines which users can increase or decrease the size of the working set of a process. The
working set of a process is the set of memory pages currently visible to the process in physical RAM. These pages
are resident, and they are available for an application to use without triggering a page fault. The minimum and
maximum working set sizes affect the virtual memory paging behavior of a process.
Constant: SeIncreaseWorkingSetPrivilege
Possible values
Not Defined
Best practices
You should make users aware that adverse performance issues may occur if they modify this security setting.
Location
Default values
By default, standard users have this right.
property page.
Default Domain Controller Policy Users
Stand-Alone Server Default Settings Users
Domain Controller Effective Default Settings Users
Member Server Effective Default Settings Users
Client Computer Effective Default Settings Users
Policy management
logs on.
Group Policy
Vulnerability
Increasing the working set size for a process decreases the amount of physical memory that is available to the rest
of the system.
Countermeasure
Increase users awareness about the impact of increasing the working set of a process and how to recognize that
their system is adversely affected if they change this setting.
Potential impact
None. Allowing standard users to increase the working set of a process is the default configuration.
Related topics
Increase scheduling priority
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Increase
scheduling priority security policy setting.
Reference
This policy setting determines which user accounts can increase the base priority class of a process. It is not a
privileged operation to increase relative priority within a priority class. This user right is not required by
administrative tools that are supplied with the operating system, but it might be required by software development
tools.
Specifically, this security setting determines which accounts can use a process with Write Property access to
another process to increase the run priority that is assigned to the other process. A user with this privilege can
change the scheduling priority of a process through the Task Manager user interface.
Constant: SeIncreaseBasePriorityPrivilege
Possible values
Not defined
Administrators
Best practices
Allow the default value, Administrators, as the only account responsible for controlling process scheduling
priorities.
Location
Default values
By default this setting is Administrators on domain controllers and on stand-alone servers.
property page.

Policy management
logs on.
Group Policy
Vulnerability
A user who is assigned this user right could increase the scheduling priority of a process to Real-Time, which would
leave little processing time for all other processes and could lead to a denial-of-service condition.
Countermeasure
Verify that only Administrators have the Increase scheduling priority user right assigned to them.
Potential impact
None. Restricting the Increase scheduling priority user right to members of the Administrators group is the
Related topics
Load and unload device drivers
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Load and
unload device drivers security policy setting.
Reference
This policy setting determines which users can dynamically load and unload device drivers. This user right is not
required if a signed driver for the new hardware already exists in the driver.cab file on the device. Device drivers
run as highly privileged code. Windows supports the Plug and Play specifications that define how a computer can
detect and configure newly added hardware, and then automatically install the device driver. Prior to Plug and Play,
users needed to manually configure devices before attaching them to the device. This model allows a user to plug
in the hardware, then Windows searches for an appropriate device driver package and automatically configures it
to work without interfering with other devices.
Because device driver software runs as if it is a part of the operating system with unrestricted access to the entire
computer, it is critical that only known and authorized device drivers be permitted.
Constant: SeLoadDriverPrivilege
Possible values
Default values
Not Defined
Best practices
Because of the potential security risk, do not assign this user right to any user, group, or process that you do not
want to take over the system.
Location
Default values
By default this setting is Administrators and Print Operators on domain controllers and Administrators on stand-
alone servers.
property page.

Print Operators

Print Operators
Policy management
logs on.
Group Policy
Vulnerability
Device drivers run as highly privileged code. A user who has the Load and unload device drivers user right could
unintentionally install malware that masquerades as a device driver. Administrators should exercise care and install
only drivers with verified digital signatures.
Note: You must have this user right or be a member of the local Administrators group to install a new driver
for a local printer or to manage a local printer and configure defaults for options such as duplex printing.
Countermeasure
Do not assign the Load and unload device drivers user right to any user or group other than Administrators on
member servers. On domain controllers, do not assign this user right to any user or group other than Domain
Admins.
Potential impact
If you remove the Load and unload device drivers user right from the Print Operators group or other accounts,
you could limit the abilities of users who are assigned to specific administrative roles in your environment. You
should ensure that delegated tasks are not negatively affected.
Related topics
Lock pages in memory
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Lock pages
in memory security policy setting.
Reference
This policy setting determines which accounts can use a process to keep data in physical memory, which prevents
the computer from paging the data to virtual memory on a disk.
Normally, an application running on Windows can negotiate for more physical memory, and in response to the
request, the application begins to move the data from RAM (such as the data cache) to a disk. When the pageable
memory is moved to a disk, more RAM is free for the operating system to use.
Enabling this policy setting for a specific account (a user account or a process account for an application) prevents
paging of the data. Thereby, the amount of memory that Windows can reclaim under pressure is limited. This could
lead to performance degradation.
Note: By configuring this policy setting, the performance of the Windows operating system will differ
depending on if applications are running on 32-bit or 64-bit systems, and if they are virtualized images.
Performance will also differ between earlier and later versions of the Windows operating system.
Constant: SeLockMemoryPrivilege
Possible values
Not defined
Best practices
Best practices are dependent on the platform architecture and the applications running on those platforms.
Location
Default values

Policy management
logs on.
Group Policy
Vulnerability
Users with the Lock pages in memory user right could assign physical memory to several processes, which could
leave little or no RAM for other processes and result in a denial-of-service condition.
Countermeasure
Do not assign the Lock pages in memory user right to any accounts.
Potential impact
Related topics
Log on as a batch job
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Log on as a
batch job security policy setting.
Reference
This policy setting determines which accounts can log on by using a batch-queue tool such as the Task Scheduler
service. When you use the Add Scheduled Task Wizard to schedule a task to run under a particular user name and
password, that user is automatically assigned the Log on as a batch job user right. When the scheduled time
arrives, the Task Scheduler service logs on the user as a batch job instead of as an interactive user, and the task
runs in the user's security context.
Constant: SeBatchLogonRight
Possible values
Default values
Not Defined
Best practices
Use discretion when assigning this right to specific users for security reasons. The default settings are sufficient
in most cases.
Location
Default values
By default, this setting is for Administrators, Backup Operators, and Performance Log Users on domain controllers
and on stand-alone servers.
property page.

Backup Operators
Performance Log Users

Backup Operators

Backup Operators

Backup Operators
Policy management
logs on.
Group Policy
Task Scheduler automatically grants this right when a user schedules a task. To override this behavior use the Deny
log on as a batch job User Rights Assignment setting.
Group Policy settings are applied in the following order, which will overwrite settings on the local computer at the
next Group Policy update:
Vulnerability
The Log on as a batch job user right presents a low-risk vulnerability. For most organizations, the default settings
are sufficient. Members of the local Administrators group have this right by default.
Countermeasure
You should allow the computer to manage this user right automatically if you want to allow scheduled tasks to run
for specific user accounts. If you do not want to use the Task Scheduler in this manner, configure the Log on as a
batch job user right for only the Local Service account.
For IIS servers, you should configure this policy locally instead of through domainbased Group Policy settings so
that you can ensure the local IUSR_<ComputerName> and IWAM_<ComputerName> accounts have this user
right.
Potential impact
If you configure the Log on as a batch job setting by using domain-based Group Policy settings, the computer
cannot assign the user right to accounts that are used for scheduled jobs in the Task Scheduler. If you install
optional components such as ASP.NET or IIS, you may need to assign this user right to additional accounts that are
required by those components. For example, IIS requires assignment of this user right to the IIS_WPG group and
the IUSR_<ComputerName>, ASPNET, and IWAM_<ComputerName> accounts. If this user right is not assigned to
this group and these accounts, IIS cannot run some COM objects that are necessary for proper functionality.
Related topics
Log on as a service
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Log on as a
service security policy setting.
Reference
This policy setting determines which service accounts can register a process as a service. Running a process under a
service account circumvents the need for human intervention.
Constant: SeServiceLogonRight
Possible values
Not Defined
Best practices
Minimize the number of accounts that are granted this user right.
Location
Default values
By default this setting is Network Service on domain controllers and Network Service on stand-alone servers.
property page.
Domain Controller Effective Default Settings Network Service
Member Server Effective Default Settings Network Service
Client Computer Effective Default Settings Network Service
Policy management
logs on.
Group Policy
The policy setting Deny logon as a service supersedes this policy setting if a user account is subject to both
policies.
Group Policy settings are applied in the following order, which will overwrite settings on the local device at the next
Group Policy update:
Vulnerability
The Log on as a service user right allows accounts to start network services or services that run continuously on a
computer, even when no one is logged on to the console. The risk is reduced by the fact that only users with
administrative privileges can install and configure services. An attacker who has already attained that level of access
could configure the service to run with the Local System account.
Countermeasure
By definition, the Network Service account has the Log on as a service user right. This right is not granted through
the Group Policy setting. You should minimize the number of other accounts that are granted this user right.
Potential impact
On most computers, restricting the Log on as a service user right to the Local System, Local Service, and Network
Service built-in accounts is the default configuration, and there is no negative impact. However, if you have installed
optional components such as ASP.NET or IIS, you may need to assign the Log on as a service user right to
additional accounts that are required by those components. IIS requires that this user right be explicitly granted to
the ASPNET user account.
Related topics
Manage auditing and security log
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Manage
auditing and security log security policy setting.
Reference
This policy setting determines which users can specify object access audit options for individual resources such as
files, Active Directory objects, and registry keys. These objects specify their system access control lists (SACL). A
user who is assigned this user right can also view and clear the Security log in Event Viewer. For more info about
the Object Access audit policy, see Audit object access.
Constant: SeSecurityPrivilege
Possible values
Administrators
Not Defined
Best practices
1. Before removing this right from a group, investigate whether applications are dependent on this right.
2. Generally, assigning this user right to groups other than Administrators is not necessary.
Location
Default values

Policy management
logs on.
Audits for object access are not performed unless you enable them by using the Local Group Policy Editor, the
Group Policy Management Console (GPMC), or the Auditpol command-line tool.
For more information about the Object Access audit policy, see Audit object access.
Group Policy
Vulnerability
Anyone with the Manage auditing and security log user right can clear the Security log to erase important
evidence of unauthorized activity.
Countermeasure
Ensure that only the local Administrators group has the Manage auditing and security log user right.
Potential impact
Restricting the Manage auditing and security log user right to the local Administrators group is the default
configuration.
Warning: If groups other than the local Administrators group have been assigned this user right, removing this
user right might cause performance issues with other applications. Before removing this right from a group,
investigate whether applications are dependent on this right.
Related topics
Modify an object label
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Modify an
object label security policy setting.
Reference
This privilege determines which user accounts can modify the integrity label of objects, such as files, registry keys,
or processes owned by other users. Processes running under a user account can modify the label of an object
owned by that user to a lower level without this privilege.
The integrity label is used by the Windows Integrity Controls (WIC) feature, which was introduced in Windows
Server 2008 and Windows Vista. WIC keeps lower integrity processes from modifying higher integrity processes by
assigning one of six possible labels to objects on the system. Although similar to NTFS file and folder permissions,
which are discretionary controls on objects, the WIC integrity levels are mandatory controls that are put in place
and enforced by the operating system. The following list describes the integrity levels from lowest to highest:
Untrusted Default assignment for processes that are logged on anonymously.
Low Default assignment for processes that interact with the Internet.
Medium Default assignment for standard user accounts and any object that is not explicitly designated with a
lower or higher integrity level.
High Default assignment for administrator accounts and processes that request to run using administrative
rights.
System Default assignment for Windows kernel and core services.
Installer Used by setup programs to install software. It is important that only trusted software is installed on
computers because objects that are assigned the Installer integrity level can install, modify, and uninstall all
other objects.
Constant: SeRelabelPrivilege
Possible values
Not Defined
Best practices
Do not give any group this user right.
Location
Default values
By default this setting is Not defined on domain controllers and on stand-alone servers.
Policy management
logs on.
Group Policy
Vulnerability
Anyone with the Modify an object label user right can change the integrity level of a file or process so that it
becomes elevated or decreased to a point where it can be deleted by lower integrity processes. Either of these
states effectively circumvents the protection that is offered by Windows Integrity Controls and makes your system
vulnerable to attacks by malicious software.
If malicious software is set with an elevated integrity level such as Trusted Installer or System, administrator
accounts do not have sufficient integrity levels to delete the program from the system. In that case, use of the
Modify an object label right is mandated so that the object can be re-labeled. However, the re-labeling must
occur by using a process that is at the same or a higher level of integrity than the object that you are attempting to
re-label.
Countermeasure
Do not give any group this right. If necessary, implement it for a constrained period of time to a trusted individual
to respond to a specific organizational need.
Potential impact
Related topics
Modify firmware environment values
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Modify
firmware environment values security policy setting.
Reference
This security setting determines who can modify firmware environment values. Firmware environment values are
settings that are stored in the nonvolatile RAM of non-x86-based computers. The effect of the setting depends on
the processor.
On x86-based computers, the only firmware environment value that can be modified by assigning this user right is
the Last Known Good Configuration setting, which should only be modified by the system.
On Itanium-based computers, boot information is stored in nonvolatile RAM. Users must be assigned this user
right to run bootcfg.exe and to change the Default Operating System setting using the Startup and Recovery
feature on the Advanced tab of System Properties.
The exact setting for firmware environment values is determined by the boot firmware. The location of these values
is also specified by the firmware. For example, on a UEFI-based system, NVRAM contains firmware environment
values that specify system boot settings.
On all computers, this user right is required to install or upgrade Windows.
Constant: SeSystemEnvironmentPrivilege
Possible values
Administrators
Not Defined
Best practices
Ensure that only the local Administrators group is assigned the Modify firmware environment values user
right.
Location
Default values
property page.

Default Domain Controller Policy Adminstrators
Stand-Alone Server Default Settings Adminstrators
Domain Controller Effective Default Settings Adminstrators
Member Server Effective Default Settings Adminstrators
Client Computer Effective Default Settings Adminstrators
Policy management
logs on.
This security setting does not affect who can modify the system environment values and user environment values
that are displayed on the Advanced tab of System Properties.
Group Policy
Vulnerability
Anyone who is assigned the Modify firmware environment values user right could configure the settings of a
hardware component to cause it to fail, which could lead to data corruption or a denial-of-service condition.
Countermeasure
Ensure that only the local Administrators group is assigned the Modify firmware environment values user right.
Potential impact
None. Restricting the Modify firmware environment values user right to the members of the local
Administrators group is the default configuration.
Related topics
Perform volume maintenance tasks
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Perform
volume maintenance tasks security policy setting.
Reference
This policy setting determines which users can perform volume or disk management tasks, such as defragmenting
an existing volume, creating or removing volumes, and running the Disk Cleanup tool.
Use caution when assigning this user right. Users with this user right can explore disks and extend files in to
memory that contains other data. When the extended files are opened, the user might be able to read and modify
the acquired data.
Constant: SeManageVolumePrivilege
Possible values
Not Defined
Best practices
Ensure that only the local Administrators group is assigned the Perform volume maintenance tasks user
right.
Location
Default values
property page.

Policy management
logs on.
Group Policy
Vulnerability
A user who is assigned the Perform volume maintenance tasks user right could delete a volume, which could
result in the loss of data or a denial-of- service condition. Also, disk maintenance tasks can be used to modify data
on the disk, such as user rights assignments that might lead to escalation of privileges.
Countermeasure
Ensure that only the local Administrators group is assigned the Perform volume maintenance tasks user right.
Potential impact
None. Restricting the Perform volume maintenance tasks user right to the local Administrators group is the
Related topics
Profile single process
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Profile
single process security policy setting.
Reference
This policy setting determines which users can view a sample performance of an application process. Typically, you
do not need this user right to use the performance reporting tools included in the operating system. However, you
do need this user right if the systems monitor components are configured to collect data through Windows
Management Instrumentation (WMI).
Constant: SeProfileSingleProcessPrivilege
Possible values
Administrators
Not Defined
Best practices
This right should not be granted to individual users. It should be granted only for trusted applications that
monitor other programs.
Location
Default values
property page.

Policy management
logs on.
Group Policy
Vulnerability
The Profile single process user right presents a moderate vulnerability. Attackers with this user right could
monitor a computer's performance to help identify critical processes that they might want to attack directly.
Attackers may be able to determine what processes run on the computer so that they could identify
countermeasures that they may need to avoid, such as anti-virus software or an intrusion-detection system. They
could also identify other users who are logged on to a computer.
Countermeasure
Ensure that only the local Administrators group is assigned the Profile single process user right.
Potential impact
If you remove the Profile single process user right from the Power Users group or other accounts, you could limit
the abilities of users who are assigned to specific administrative roles in your environment. You should ensure that
delegated tasks are not negatively affected.
Related topics
Profile system performance
Applies to
Windows 10
management, and security considerations for the Profile system performance security policy setting.
Reference
This security setting determines which users can use Windows performance monitoring tools to monitor the
performance of system processes.
Constant: SeSystemProfilePrivilege
Possible values
Administrators
Not defined
Best practices
Ensure that only the local Administrators group is assigned the Profile system performance user right.
Location
Default values
Policy management
logs on.
Depending on your version of Windows and your environment, you might need to add this user right to the Local
System account or the Local Service account if you encounter access errors when you use the Administrators
account.
Group Policy
Vulnerability
The Profile system performance user right poses a moderate vulnerability. Attackers with this user right could
monitor a computer's performance to help identify critical processes that they might want to attack directly.
Attackers might also be able to determine what processes are active on the computer so that they could identify
countermeasures to avoid, such as anti-virus software or an intrusion detection system.
Countermeasure
Ensure that only the local Administrators group is assigned the Profile system performance user right.
Potential impact
None. Restricting the Profile system performance user right to the local Administrators group is the default
configuration.
Related topics
Remove computer from docking station - security
policy setting
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Remove
computer from docking station security policy setting.
Reference
This security setting determines whether a user can undock a portable device from its docking station without
logging on. This policy setting only affects scenarios that involve a portable computer and its docking station.
If this user right is assigned to the users account (or if the user is a member of the assigned group), the user must
log on before removing the portable device from its docking station. Otherwise, as a security measure, the user will
not be able to log on after the device is removed from the docking station. If this policy is not assigned, the user
may remove the portable device from its docking station without logging on, and then have the ability to start and
log on to the device afterwards in its undocked state.
Constant: SeUndockPrivilege
Possible values
Not Defined
Best practices
Assign this user right to only those accounts that are permitted to use the portable device.
Location
Default values
Although this portable device scenario does not normally apply to servers, by default this setting is Administrators
on domain controllers and on stand-alone servers.
property page.

Policy management
logs on.
Group Policy
Vulnerability
Anyone who has the Remove computer from docking station user right can log on and then remove a portable
device from its docking station. If this setting is not defined, it has the same effect as if everyone was granted this
right. However, the value of implementing this countermeasure is reduced by the following factors:
If attackers can restart the device, they could remove it from the docking station after the BIOS starts but before
the operating system starts.
This setting does not affect servers because they typically are not installed in docking stations.
An attacker could steal the device and the docking station together.
Devices that can be mechanically undocked can be physically removed by the user whether or not they use the
Windows undocking functionality.
Countermeasure
Ensure that only the local Administrators group and the user account to which the device is allocated are assigned
the Remove computer from docking station user right.
Potential impact
By default, only members of the local Administrators group are granted this right. Other user accounts must be
explicitly granted this user right as necessary. If your organization's users are not members of the local
Administrators groups on their portable devices, they cannot remove their portable devices from their docking
stations if they do not first shut down the device. Therefore, you may want to assign the Remove computer from
docking station privilege to the local Users group for portable devices.
Related topics
Replace a process level token
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Replace a
process level token security policy setting.
Reference
This policy setting determines which parent processes can replace the access token that is associated with a child
process.
Specifically, the Replace a process level token setting determines which user accounts can call the
CreateProcessAsUser() application programming interface (API) so that one service can start another. An example
of a process that uses this user right is Task Scheduler, where the user right is extended to any processes that can
be managed by Task Scheduler.
An access token is an object that describes the security context of a process or thread. The information in a token
includes the identity and privileges of the user account that is associated with the process or thread. With this user
right, every child process that runs on behalf of this user account would have its access token replaced with the
process level token.
Constant: SeAssignPrimaryTokenPrivilege
Possible values
Defaults
Not defined
Best practices
For member servers, ensure that only the Local Service and Network Service accounts have the Replace a
process level token user right.
Location
Default values
By default this setting is Network Service and Local Service on domain controllers and on stand-alone servers.
Default Domain Controller Policy Network Service

Local Service
Stand-Alone Server Default Settings Network Service

Local Service
Domain Controller Effective Default Settings Network Service

Local Service
Member Server Effective Default Settings Network Service

Local Service
Client Computer Effective Default Settings Network Service

Local Service
Policy management
logs on.
Group Policy
Vulnerability
Users with the Replace a process level token user right can start processes as another user if they know the
users credentials.
Countermeasure
For member servers, ensure that only the Local Service and Network Service accounts have the Replace a process
level token user right.
Potential impact
On most computers, restricting the Replace a process level token user right to the Local Service and the Network
Service built-in accounts is the default configuration, and there is no negative impact. However, if you have installed
optional components such as ASP.NET or IIS, you may need to assign the Replace a process level token user
right to additional accounts. For example, IIS requires that the Service, Network Service, and
IWAM_<ComputerName> accounts be explicitly granted this user right.
Related topics
Restore files and directories - security policy setting
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Restore files
and directories security policy setting.
Reference
This security setting determines which users can bypass file, directory, registry, and other persistent object
permissions when they restore backed up files and directories, and it determines which users can set valid security
principals as the owner of an object.
Granting this user right to an account is similar to granting the account the following permissions to all files and
folders on the system:
Traverse folder / execute file
Write
Constant: SeRestorePrivilege
Possible values
Defaults
Not Defined
Best practices
Users with this user right can overwrite registry settings, hide data, and gain ownership of system objects, so
only assign this user right to trusted users.
Location
Default values
By default, this right is granted to the Administrators, Backup Operators, and Server Operators groups on domain
controllers, and to the Administrators and Backup Operators groups on stand-alone servers.
property page.

Backup Operators
Server Operators

Backup Operators

Backup Operators
Server Operators

Backup Operators

Backup Operators
Policy management
logs on.
Group Policy
Vulnerability
An attacker with the Restore files and directories user right could restore sensitive data to a computer and
overwrite data that is more recent, which could lead to loss of important data, data corruption, or a denial-of-
service condition. Attackers could overwrite executable files that are used by legitimate administrators or system
services with versions that include malicious software to grant themselves elevated privileges, compromise data, or
install programs that provide continued access to the device
Note: Even if the following countermeasure is configured, an attacker could restore data to a computer in a
domain that is controlled by the attacker. Therefore, it is critical that organizations carefully protect the media
that are used to back up data.
Countermeasure
Ensure that only the local Administrators group is assigned the Restore files and directories user right unless
your organization has clearly defined roles for backup and for restore personnel.
Potential impact
If you remove the Restore files and directories user right from the Backup Operators group and other accounts,
users who are not members of the local Administrators group cannot load data backups. If restoring backups is
delegated to a subset of IT staff in your organization, you should verify that this change does not negatively affect
the ability of your organization's personnel to do their jobs.
Related topics
Shut down the system - security policy setting
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Shut down
the system security policy setting.
Reference
This security setting determines if a user who is logged on locally to a device can shut down Windows.
Shutting down domain controllers makes them unavailable to perform functions such as processing logon
requests, processing Group Policy settings, and answering Lightweight Directory Access Protocol (LDAP) queries.
Shutting down domain controllers that have been assigned operations master roles (also known as flexible single
master operations or FSMO roles) can disable key domain functionality; for example, processing logon requests for
new passwords, which is performed by the primary domain controller (PDC) emulator master.
The Shut down the system user right is required to enable hibernation support, to set the power management
settings, and to cancela shutdown.
Constant: SeShutdownPrivilege
Possible values
A user-defined list of accounts
Defaults
Not defined
Best practices
1. Ensure that only Administrators and Backup Operators have the Shut down the system user right on member
servers, and that only Administrators have the user right on domain controllers. Removing these default groups
might limit the abilities of users who are assigned to specific administrative roles in your environment. Ensure
that their delegated tasks will not be negatively affected.
2. The ability to shut down domain controllers should be limited to a very small number of trusted administrators.
Even though a system shutdown requires the ability to log on to the server, you should be very careful about
the accounts and groups that you allow to shut down a domain controller.
Location
Default values
By default this setting is Administrators, Backup Operators, Server Operators, and Print Operators on domain
controllers, and Administrators and Backup Operators on stand-alone servers.

Backup Operators
Server Operators
Print Operators

Backup Operators

Backup Operators
Server Operators
Print Operators

Backup Operators

Backup Operators
Users
Policy management
logs on.
Group Policy
This user right does not have the same effect as Force shutdown from a remote system. For more information,
see Force shutdown from a remote system.
Vulnerability
The ability to shut down domain controllers should be limited to a very small number of trusted administrators.
Although the Shut down the system user right requires the ability to log on to the server, you should be very
careful about which accounts and groups you allow to shut down a domain controller.
When a domain controller is shut down, it is no longer available to process logon requests, process Group Policy
settings, and answer Lightweight Directory Access Protocol (LDAP) queries. If you shut down domain controllers
that possess operations master roles, you can disable key domain functionality, such as processing logon requests
for new passwords, which is performed by the PDC master.
For other server roles, especially those where non-administrators have rights to log on to the server (such as RD
Session Host servers), it is critical that this user right be removed from users that do not have a legitimate reason
to restart the servers.
Countermeasure
Ensure that only the Administrators and Backup Operators groups are assigned the Shut down the system user
right on member servers, and ensure that only the Administrators group is assigned the user right on domain
controllers.
Potential impact
The impact of removing these default groups from the Shut down the system user right could limit the delegated
abilities of assigned roles in your environment. You should confirm that delegated activities are not adversely
affected.
Related topics
Synchronize directory service data
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Synchronize
directory service data security policy setting.
Reference
This policy setting determines which users and groups have authority to synchronize all directory service data,
regardless of the protection for objects and properties. This privilege is required to use LDAP directory
synchronization (dirsync) services. Domain controllers have this user right inherently because the synchronization
process runs in the context of the System account on domain controllers.
Constant: SeSyncAgentPrivilege
Possible values
Not defined
Best practices
Ensure that no accounts are assigned the Synchronize directory service data user right. Only domain
controllers need this privilege, which they inherently have.
Location
Default values
By default this setting is not defined on domain controllers and on stand-alone servers.
property page.
Domain Controller Effective Default Settings Enabled
Policy management
logs on.
Group Policy
Vulnerability
The Synchronize directory service data user right affects domain controllers (only domain controllers should be
able to synchronize directory service data). Domain controllers have this user right inherently because the
synchronization process runs in the context of the System account on domain controllers. Attackers who have this
user right can view all information that is stored within the directory. They could then use some of that information
to facilitate additional attacks or expose sensitive data, such as direct telephone numbers or physical addresses.
Countermeasure
Ensure that no accounts are assigned the Synchronize directory service data user right.
Potential impact
Related topics
Take ownership of files or other objects
Applies to
Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Take
ownership of files or other objects security policy setting.
Reference
This policy setting determines which users can take ownership of any securable object in the device, including
Active Directory objects, NTFS files and folders, printers, registry keys, services, processes, and threads.
Every object has an owner, whether the object resides in an NTFS volume or Active Directory database. The owner
controls how permissions are set on the object and to whom permissions are granted.
By default, the owner is the person who or the process which created the object. Owners can always change
permissions to objects, even when they are denied all access to the object.
Constant: SeTakeOwnershipPrivilege
Possible values
Not defined
Best practices
Assigning this user right can be a security risk. Because owners of objects have full control of them, only assign
this user right to trusted users.
Location
Default values
property page.

Policy management
logs on.
Ownership can be taken by:
An administrator. By default, the Administrators group is given the Take ownership of files or other objects
user right.
Anyone or any group who has the Take ownership user right on the object.
A user who has the Restore files and directories user right.
Ownership can be transferred in the following ways:
The current owner can grant the Take ownership user right to another user if that user is a member of a group
defined in the current owner's access token. The user must take ownership to complete the transfer.
An administrator can take ownership.
A user who has the Restore files and directories user right can double-click Other users and groups and
choose any user or group to assign ownership to.
Group Policy
Vulnerability
Any users with the Take ownership of files or other objects user right can take control of any object, regardless
of the permissions on that object, and then make any changes that they want to make to that object. Such changes
could result in exposure of data, corruption of data, or a denial-of-service condition.
Countermeasure
Ensure that only the local Administrators group has the Take ownership of files or other objects user right.
Potential impact
None. Restricting the Take ownership of files or other objects user right to the local Administrators group is the
Related topics
Applies to
Windows 10
Windows Server 2016
Trusted Platform Module (TPM) technology is designed to provide hardware-based, security-related functions. A
TPM chip is a secure crypto-processor that helps you with actions such as generating, storing, and limiting the use
of cryptographic keys. The following topics provide details.
TOPIC DESCRIPTION
Trusted Platform Module Overview Provides an overview of the Trusted Platform Module (TPM)
and how Windows uses it for access control and
authentication.
TPM fundamentals Provides background about how a TPM can work with
cryptographic keys. Also describes technologies that work
with the TPM, such as TPM-based virtual smart cards.
TPM Group Policy settings Describes TPM services that can be controlled centrally by
using Group Policy settings.
Back up the TPM recovery information to AD DS For Windows 10, version 1511 and Windows 10, version
1507 only, describes how to back up a computers TPM
information to Active Directory Domain Services.
Manage TPM commands Describes methods by which a local or domain administrator

can block or allow specific TPM commands.
Manage TPM lockout Describes how TPM lockout works (to help prevent tampering
or malicious attacks), and outlines ways to work with TPM
lockout settings.
Change the TPM owner password In most cases, applies to Windows 10, version 1511 and
Windows 10, version 1507 only. Tells how to change the TPM
owner password.
View status, clear, or troubleshoot the TPM Describes actions you can take through the TPM snap-in,
TPM.msc: view TPM status, troubleshoot TPM initialization,
and clear keys from the TPM. Also, for TPM 1.2 and Windows
10, version 1507 or 1511, describes how to turn the TPM on
or off.
Understanding PCR banks on TPM 2.0 devices Provides background about what happens when you switch
PCR banks on TPM 2.0 devices.
TPM recommendations Discusses aspects of TPMs such as the difference between

TPM 1.2 and 2.0, and the Windows 10 features for which a
TPM is required or recommended.
Trusted Platform Module Technology Overview
Applies to
Windows 10
Windows Server 2016
This topic for the IT professional describes the Trusted Platform Module (TPM) and how Windows uses it for access
control and authentication.
Feature description
Trusted Platform Module (TPM) technology is designed to provide hardware-based, security-related functions. A
TPM chip is a secure crypto-processor that is designed to carry out cryptographic operations. The chip includes
multiple physical security mechanisms to make it tamper resistant, and malicious software is unable to tamper
with the security functions of the TPM. Some of the key advantages of using TPM technology are that you can:
Generate, store, and limit the use of cryptographic keys.
Use TPM technology for platform device authentication by using the TPMs unique RSA key, which is
burned into itself.
Help ensure platform integrity by taking and storing security measurements.
The most common TPM functions are used for system integrity measurements and for key creation and use.
During the boot process of a system, the boot code that is loaded (including firmware and the operating system
components) can be measured and recorded in the TPM. The integrity measurements can be used as evidence for
how a system started and to make sure that a TPM-based key was used only when the correct software was used
to boot the system.
TPM-based keys can be configured in a variety of ways. One option is to make a TPM-based key unavailable
outside the TPM. This is good to mitigate phishing attacks because it prevents the key from being copied and used
without the TPM. TPM-based keys can also be configured to require an authorization value to use them. If too
many incorrect authorization guesses occur, the TPM will activate its dictionary attack logic and prevent further
authorization value guesses.
Different versions of the TPM are defined in specifications by the Trusted Computing Group (TCG). For more
information, consult the TCG Web site.
Automatic initialization of the TPM with Windows 10
Starting with Windows 10, the operating system automatically initializes and takes ownership of the TPM. This
means that in most cases, we recommend that you avoid configuring the TPM through the TPM management
console, TPM.msc. There are a few exceptions, mostly related to resetting or performing a clean installation on a
PC. For more information, see Clear all the keys from the TPM.
In certain specific enterprise scenarios limited to Windows 10, versions 1507 and 1511, Group Policy might be
used to back up the TPM owner authorization value in Active Directory. Because the TPM state persists across
operating system installations, this TPM information is stored in a location in Active Directory that is separate from
computer objects.
Practical applications
Certificates can be installed or created on computers that are using the TPM. After a computer is provisioned, the
RSA private key for a certificate is bound to the TPM and cannot be exported. The TPM can also be used as a
replacement for smart cards, which reduces the costs associated with creating and disbursing smart cards.
Automated provisioning in the TPM reduces the cost of TPM deployment in an enterprise. New APIs for TPM
management can determine if TPM provisioning actions require physical presence of a service technician to
approve TPM state change requests during the boot process.
Antimalware software can use the boot measurements of the operating system start state to prove the integrity of
a computer running Windows 10 or Windows Server 2016. These measurements include the launch of Hyper-V to
test that datacenters using virtualization are not running untrusted hypervisors. With BitLocker Network Unlock, IT
administrators can push an update without concerns that a computer is waiting for PIN entry.
The TPM has several Group Policy settings that might be useful in certain enterprise scenarios. For more info, see
TPM Group Policy Settings.

For more info on new and changed functionality for Trusted Platform Module in Windows 10, see What's new in
Trusted Platform Module?.
Device health attestation

Device health attestation enables enterprises to establish trust based on hardware and software components of a
managed device. With device heath attestation, you can configure an MDM server to query a health attestation
service that will allow or deny a managed device access to a secure resource.
Some things that you can check on the device are:
Is Data Execution Prevention supported and enabled?
Is BitLocker Drive Encryption supported and enabled?
Is SecureBoot supported and enabled?
NOTE
The device must be running Windows 10 and it must support at least TPM 2.0.
Supported versions
TPM VERSION WINDOWS 10 WINDOWS SERVER 2016
TPM 1.2 X X
TPM 2.0 X X
Related topics
Trusted Platform Module (list of topics)
TPM Cmdlets in Windows PowerShell
Prepare your organization for BitLocker: Planning and Policies - TPM configurations
TPM fundamentals
Applies to
Windows 10
Windows Server 2016
This topic for the IT professional provides a description of the components of the Trusted Platform Module (TPM
1.2 and TPM 2.0) and explains how they are used to mitigate dictionary attacks.
A Trusted Platform Module (TPM) is a microchip designed to provide basic security-related functions, primarily
involving encryption keys. The TPM is usually installed on the motherboard of a computer, and it communicates
with the remainder of the system by using a hardware bus.
Computers that incorporate a TPM can create cryptographic keys and encrypt them so that they can only be
decrypted by the TPM. This process, often called wrapping or binding a key, can help protect the key from
disclosure. Each TPM has a master wrapping key, called the storage root key, which is stored within the TPM itself.
The private portion of a storage root key or endorsement key that is created in a TPM is never exposed to any other
component, software, process, or user.
You can specify whether encryption keys that are created by the TPM can be migrated or not. If you specify that
they can be migrated, the public and private portions of the key can be exposed to other components, software,
processes, or users. If you specify that encryption keys cannot be migrated, the private portion of the key is never
exposed outside the TPM.
Computers that incorporate a TPM can also create a key that has not only been wrapped, but is also tied to certain
platform measurements. This type of key can be unwrapped only when those platform measurements have the
same values that they had when the key was created. This process is referred to as sealing the key to the TPM.
Decrypting the key is called unsealing. The TPM can also seal and unseal data that is generated outside the TPM.
With this sealed key and software, such as BitLocker Drive Encryption, you can lock data until specific hardware or
software conditions are met.
With a TPM, private portions of key pairs are kept separate from the memory that is controlled by the operating
system. Keys can be sealed to the TPM, and certain assurances about the state of a system (assurances that define
the trustworthiness of a system) can be made before the keys are unsealed and released for use. Because the TPM
uses its own internal firmware and logic circuits to process instructions, it does not rely on the operating system,
and it is not exposed to vulnerabilities that might exist in the operating system or application software.
For info about which versions of Windows support which versions of the TPM, see Trusted Platform Module
technology overview. The features that are available in the versions are defined in specifications by the Trusted
Computing Group (TCG). For more info, see the Trusted Platform Module page on the Trusted Computing Group
website: Trusted Platform Module.
The following sections provide an overview of the technologies that support the TPM:
Measured Boot with support for attestation
TPM-based Virtual Smart Card
TPM-based certificate storage
TPM Cmdlets
Physical presence interface
Endorsement keys
TPM Key Attestation
Anti-hammering
The following topic describes the TPM Services that can be controlled centrally by using Group Policy settings: TPM
Group Policy Settings.
Measured Boot with support for attestation

The Measured Boot feature provides antimalware software with a trusted (resistant to spoofing and tampering) log
of all boot components. Antimalware software can use the log to determine whether components that ran before it
are trustworthy versus infected with malware. It can also send the Measured Boot logs to a remote server for
evaluation. The remote server can initiate remediation actions by interacting with software on the client or through
out-of-band mechanisms, as appropriate.
TPM-based Virtual Smart Card

The Virtual Smart Card emulates the functionality of traditional smart cards, but Virtual Smart Cards use the TPM
chip that is available on an organizations computers, rather than requiring the use of a separate physical smart
card and reader. This greatly reduces the management and deployment cost of smart cards in an enterprise. To the
end user, the Virtual Smart Card is always available on the computer. If a user needs to use more than one
computer, a Virtual Smart Card must be issued to the user for each computer. A computer that is shared among
multiple users can host multiple Virtual Smart Cards, one for each user.
TPM-based certificate storage

The TPM can be used to protect certificates and RSA keys. The TPM key storage provider (KSP) provides easy,
convenient use of the TPM as a way of strongly protecting private keys. The TPM KSP can be used to generate keys
when an organization enrolls for certificates, and the KSP is managed by templates in the UI. The TPM can also be
used to protect certificates that are imported from an outside source. TPM-based certificates can be used exactly as
standard certificates with the added functionality that the certificate can never leave the TPM from which the keys
were generated. The TPM can now be used for crypto-operations through Cryptography API: Next Generation
(CNG). For more info, see Cryptography API: Next Generation.
TPM Cmdlets
You can manage the TPM using Windows PowerShell. For details, see TPM Cmdlets in Windows PowerShell.
Physical presence interface

For TPM 1.2, the TCG specifications for TPMs require physical presence (typically, pressing a key) for turning the
TPM on, turning it off, or clearing it. These actions typically cannot be automated with scripts or other automation
tools unless the individual OEM supplies them.

For TPM 1.2, there are multiple possible states. Windows 10 automatically initializes the TPM, which brings it to an
enabled, activated, and owned state.
Endorsement keys
Endorsement keys
For a TPM to be usable by a trusted application, it must contain an endorsement key, which is an RSA key pair. The
private half of the key pair is held inside the TPM, and it is never revealed or accessible outside the TPM.
Key attestation
TPM key attestation allows a certification authority to verify that a private key is actually protected by a TPM and
that the TPM is one that the certification authority trusts. Endorsement keys which have been proven valid can be
used to bind the user identity to a device. Moreover, the user certificate with a TPM attested key provides higher
security assurance backed up by the non-exportability, anti-hammering, and isolation of keys provided by a TPM.
Anti-hammering
When a TPM processes a command, it does so in a protected environment, for example, a dedicated
microcontroller on a discrete chip or a special hardware-protected mode on the main CPU. A TPM can be used to
create a cryptographic key that is not disclosed outside the TPM, but is able to be used in the TPM after the correct
authorization value is provided.
TPMs have anti-hammering protection that is designed to prevent brute force attacks, or more complex dictionary
attacks, that attempt to determine authorization values for using a key. The basic approach is for the TPM to allow
only a limited number of authorization failures before it prevents more attempts to use keys and locks. Providing a
failure count for individual keys is not technically practical, so TPMs have a global lockout when too many
authorization failures occur.
Because many entities can use the TPM, a single authorization success cannot reset the TPMs anti-hammering
protection. This prevents an attacker from creating a key with a known authorization value and then using it to
reset the TPMs protection. Generally, TPMs are designed to forget about authorization failures after a period of
time so the TPM does not enter a lockout state unnecessarily. A TPM owner password can be used to reset the
TPMs lockout logic.
TPM 2.0 anti-hammering
TPM 2.0 has well defined anti-hammering behavior. This is in contrast to TPM 1.2 for which the anti-hammering
protection was implemented by the manufacturer, and the logic varied widely throughout the industry.
WARNING
For the purposes of this topic, Windows 8 Certified Hardware also pertains to Windows 8.1 systems. The following references
to Windows include these supported Windows versions.
For Windows 8 Certified Hardware systems with TPM 2.0, the TPM is configured by Windows to lock after 32
authorization failures and to forget one authorization failure every two hours. This means that a user could quickly
attempt to use a key with the wrong authorization value 32 times. For each of the 32 attempts, the TPM records if
the authorization value was correct or not. This inadvertently causes the TPM to enter a locked state after 32 failed
attempts.
Attempts to use a key with an authorization value for the next two hours would not return success or failure;
instead the response indicates that the TPM is locked. After two hours, one authorization failure is forgotten and
the number of authorization failures remembered by the TPM drops to 31, so the TPM leaves the locked state and
returns to normal operation. With the correct authorization value, keys could be used normally if no authorization
failures occur during the next two hours. If a period of 64 hours elapses with no authorization failures, the TPM
does not remember any authorization failures, and 32 failed attempts could occur again.
Windows 8 Certification does not require TPM 2.0 systems to forget about authorization failures when the system
is fully powered off or when the system has hibernated. Windows does require that authorization failures are
forgotten when the system is running normally, in a sleep mode, or in low power states other than off. If a
Windows system with TPM 2.0 is locked, the TPM leaves lockout mode if the system is left on for two hours.
The anti-hammering protection for TPM 2.0 can be fully reset immediately by sending a reset lockout command to
the TPM and providing the TPM owner password. By default, Windows automatically provisions TPM 2.0 and
stores the TPM owner password for use by system administrators.
In some enterprise situations, the TPM owner authorization value is configured to be stored centrally in Active
Directory, and it is not stored on the local system. An administrator can launch the TPM MMC and choose to reset
the TPM lockout time. If the TPM owner password is stored locally, it is used to reset the lockout time. If the TPM
owner password is not available on the local system, the administrator needs to provide it. If an administrator
attempts to reset the TPM lockout state with the wrong TPM owner password, the TPM does not allow another
attempt to reset the lockout state for 24 hours.
TPM 2.0 allows some keys to be created without an authorization value associated with them. These keys can be
used when the TPM is locked. For example, BitLocker with a default TPM-only configuration is able to use a key in
the TPM to start Windows, even when the TPM is locked.
Rationale behind the Windows 8.1 and Windows 8 defaults
Windows relies on the TPM 2.0 anti-hammering protection for multiple features. The defaults that are selected for
Windows 8 balance trade-offs for different scenarios. For example, when BitLocker is used with a TPM plus PIN
configuration, it needs the number of PIN guesses to be limited over time. If the computer is lost, someone could
make only 32 PIN guesses immediately, and then only one more guess every two hours. This totals about 4415
guesses per year. This makes a good standard for system administrators to determine how many PIN characters to
use for BitLocker deployments.
The Windows TPM-based smart card, which is a virtual smart card, can be configured to allow sign in to the
system. In contrast with physical smart cards, the sign-in process uses a TPM-based key with an authorization
value. The following list shows the advantages of virtual smart cards:
Physical smart cards can enforce lockout for only the physical smart card PIN, and they can reset the lockout
after the correct PIN is entered. With a virtual smart card, the TPMs anti-hammering protection is not reset
after a successful authentication. The allowed number of authorization failures before the TPM enters
lockout includes many factors.
Hardware manufacturers and software developers have the option to use the security features of the TPM to
meet their requirements.
The intent of selecting 32 failures as the lock-out threshold is so users rarely lock the TPM (even when
learning to type new passwords or if they frequently lock and unlock their computers). If users lock the TPM,
they must to wait two hours or use some other credential to sign in, such as a user name and password.
Related topics
TPM WMI providers
How Windows 10 uses the Trusted Platform Module
The Windows 10 operating system improves most existing security features in the operating system and adds
groundbreaking new security features such as Device Guard and Windows Hello for Business. It places hardware-
based security deeper inside the operating system than previous Windows versions had done, maximizing platform
security while increasing usability. To achieve many of these security enhancements, Windows 10 makes extensive
use of the Trusted Platform Module (TPM). This article offers a brief overview of the TPM, describes how it works,
and discusses the benefits that TPM brings to Windows 10as well as the cumulative security impact of running
Windows 10 on a PC that contains a TPM.
See also:
Windows 10 Specifications
TPM Fundamentals
TPM Recommendations
TPM Overview
The TPM is a cryptographic module that enhances computer security and privacy. Protecting data through
encryption and decryption, protecting authentication credentials, and proving which software is running on a
system are basic functionalities associated with computer security. The TPM helps with all these scenarios and
more.
Historically, TPMs have been discrete chips soldered to a computers motherboard. Such implementations allow the
computers original equipment manufacturer (OEM) to evaluate and certify the TPM separate from the rest of the
system. Although discrete TPM implementations are still common, they can be problematic for integrated devices
that are small or have low power consumption. Some newer TPM implementations integrate TPM functionality into
the same chipset as other platform components while still providing logical separation similar to discrete TPM
chips.
TPMs are passive: they receive commands and return responses. To realize the full benefit of a TPM, the OEM must
carefully integrate system hardware and firmware with the TPM to send it commands and react to its responses.
TPMs were originally designed to provide security and privacy benefits to a platforms owner and users, but newer
versions can provide security and privacy benefits to the system hardware itself. Before it can be used for advanced
scenarios, a TPM must be provisioned. Windows 10 automatically provisions a TPM, but if the user reinstalls the
operating system, he or she may need to tell the operating system to explicitly provision the TPM again before it
can use all the TPMs features.
The Trusted Computing Group (TCG) is the nonprofit organization that publishes and maintains the TPM
specification. The TCG exists to develop, define, and promote vendor-neutral, global industry standards that
support a hardware-based root of trust for interoperable trusted computing platforms. The TCG also publishes the
TPM specification as the international standard ISO/IEC 11889, using the Publicly Available Specification
Submission Process that the Joint Technical Committee 1 defines between the International Organization for
Standardization (ISO) and the International Electrotechnical Commission (IEC).
OEMs implement the TPM as a component in a trusted computing platform, such as a PC, tablet, or phone. Trusted
computing platforms use the TPM to support privacy and security scenarios that software alone cannot achieve. For
example, software alone cannot reliably report whether malware is present during the system startup process. The
close integration between TPM and platform increases the transparency of the startup process and supports
evaluating device health by enabling reliable measuring and reporting of the software that starts the device.
Implementation of a TPM as part of a trusted computing platform provides a hardware root of trustthat is, it
behaves in a trusted way. For example, if a key stored in a TPM has properties that disallow exporting the key, that
key truly cannot leave the TPM.
The TCG designed the TPM as a low-cost, mass-market security solution that addresses the requirements of
different customer segments. There are variations in the security properties of different TPM implementations just
as there are variations in customer and regulatory requirements for different sectors. In public-sector procurement,
for example, some governments have clearly defined security requirements for TPMs, whereas others do not.
Certification programs for TPMsand technology in generalcontinue to evolve as the speed of innovation
increases. Although having a TPM is clearly better than not having a TPM, Microsofts best advice is to determine
your organizations security needs and research any regulatory requirements associated with procurement for your
industry. The result is a balance between scenarios used, assurance level, cost, convenience, and availability.
TPM in Windows 10
The security features of Windows 10 combined with the benefits of a TPM offer practical security and privacy
benefits. The following sections start with major TPM-related security features in Windows 10 and go on to
describe how key technologies use the TPM to enable or increase security.
Platform Crypto Provider

Windows includes a cryptography framework called Cryptographic API: Next Generation (CNG), the basic approach
of which is to implement cryptographic algorithms in different ways but with a common application programming
interface (API). Applications that use cryptography can use the common API without knowing the details of how an
algorithm is implemented much less the algorithm itself.
Although CNG sounds like a mundane starting point, it illustrates some of the advantages that a TPM provides.
Underneath the CNG interface, Windows or third parties supply a cryptographic provider (that is, an
implementation of an algorithm) implemented as software libraries alone or in a combination of software and
available system hardware or third-party hardware. If implemented through hardware, the cryptographic provider
communicates with the hardware behind the software interface of CNG.
The Platform Crypto Provider, introduced in the Windows 8 operating system, exposes the following special TPM
properties, which software-only CNG providers cannot offer or cannot offer as effectively:
Key protection. The Platform Crypto Provider can create keys in the TPM with restrictions on their use. The
operating system can load and use the keys in the TPM without copying the keys to system memory, where they
are vulnerable to malware. The Platform Crypto Provider can also configure keys that a TPM protects so that they
are not removable. If a TPM creates a key, the key is unique and resides only in that TPM. If the TPM imports a key,
the Platform Crypto Provider can use the key in that TPM, but that TPM is not a source for making additional copies
of the key or enabling the use of copies elsewhere. In sharp contrast, software solutions that protect keys from
copying are subject to reverse-engineering attacks, in which someone figures out how the solution stores keys or
makes copies of keys while they are in memory during use.
Dictionary attack protection. Keys that a TPM protects can require an authorization value such as a PIN. With
dictionary attack protection, the TPM can prevent attacks that attempt a large number of guesses to determine the
PIN. After too many guesses, the TPM simply returns an error saying no more guesses are allowed for a period of
time. Software solutions might provide similar features, but they cannot provide the same level of protection,
especially if the system restarts, the system clock changes, or files on the hard disk that count failed guesses are
rolled back. In addition, with dictionary attack protection, authorization values such as PINs can be shorter and
easier to remember while still providing the same level of protection as more complex values when using software
solutions.
These TPM features give Platform Crypto Provider distinct advantages over software-based solutions. A practical
way to see these benefits in action is when using certificates on a Windows 10 device. On platforms that include a
TPM, Windows can use the Platform Crypto Provider to provide certificate storage. Certificate templates can specify
that a TPM use the Platform Crypto Provider to protect the key associated with a certificate. In mixed environments,
where some computers might not have a TPM, the certificate template could simply prefer the Platform Crypto
Provider over the standard Windows software provider. If a certificate is configured as not able to be exported, the
private key for the certificate is restricted and cannot be exported from the TPM. If the certificate requires a PIN, the
PIN gains the TPMs dictionary attack protection automatically.
Virtual Smart Card

Smart cards are highly secure physical devices that typically store a single certificate and the corresponding private
key. Users insert a smart card into a built-in or USB card reader and enter a PIN to unlock it. Windows can then
access the cards certificate and use the private key for authentication or to unlock BitLocker protected data
volumes. Smart cards are popular because they provide two-factor authentication that requires both something the
user has (that is, the smart card) and something the user knows (such as the smart card PIN). Smart cards are
difficult to use, however, because they require purchase and deployment of both smart cards and smart card
readers.
In Windows, the Virtual Smart Card feature allows the TPM to mimic a permanently inserted smart card. The TPM
becomes something the user has but still requires a PIN. Although physical smart cards limit the number of PIN
attempts before locking the card and requiring a reset, a virtual smart card relies on the TPMs dictionary attack
protection to prevent too many PIN guesses.
For TPM-based virtual smart cards, the TPM protects the use and storage of the certificate private key so that it
cannot be copied when it is in use or stored and used elsewhere. Using a component that is part of the system
rather than a separate physical smart card can reduce total cost of ownership because it eliminates lost card and
card left at home scenarios while still delivering the benefits of smart cardbased multifactor authentication. For
users, virtual smart cards are simple to use, requiring only a PIN to unlock. Virtual smart cards support the same
scenarios that physical smart cards support, including signing in to Windows or authenticating for resource access.
Windows Hello for Business

Windows Hello for Business provides authentication methods intended to replace passwords, which can be difficult
to remember and easily compromised. In addition, user name - password solutions for authentication often reuse
the same user name password combinations on multiple devices and services; if those credentials are
compromised, they are compromised in many places. Windows Hello for Business provisions devices one by one
and combines the information provisioned on each device (i.e., the cryptographic key) with additional information
to authenticate users. On a system that has a TPM, the TPM can protect the key. If a system does not have a TPM,
software-based techniques protect the key. The additional information the user supplies can be a PIN value or, if
the system has the necessary hardware, biometric information, such as fingerprint or facial recognition. To protect
privacy, the biometric information is used only on the provisioned device to access the provisioned key: it is not
shared across devices.
The adoption of new authentication technology requires that identity providers and organizations deploy and use
that technology. Windows Hello for Business lets users authenticate with their existing Microsoft account, an Active
Directory account, a Microsoft Azure Active Directory account, or even non-Microsoft Identity Provider Services or
Relying Party Services that support Fast ID Online V2.0 authentication.
Identity providers have flexibility in how they provision credentials on client devices. For example, an organization
might provision only those devices that have a TPM so that the organization knows that a TPM protects the
credentials. The ability to distinguish a TPM from malware acting like a TPM requires the following TPM capabilities
(see Figure 1):
Endorsement key. The TPM manufacturer can create a special key in the TPM called an endorsement key. An
endorsement key certificate, signed by the manufacturer, says that the endorsement key is present in a TPM that
that manufacturer made. Solutions can use the certificate with the TPM containing the endorsement key to confirm
a scenario really involves a TPM from a specific TPM manufacturer (instead of malware acting like a TPM.
Attestation identity key. To protect privacy, most TPM scenarios do not directly use an actual endorsement key.
Instead, they use attestation identity keys, and an identity certificate authority (CA) uses the endorsement key and
its certificate to prove that one or more attestation identity keys actually exist in a real TPM. The identity CA issues
attestation identity key certificates. More than one identity CA will generally see the same endorsement key
certificate that can uniquely identify the TPM, but any number of attestation identity key certificates can be created
to limit the information shared in other scenarios.
Figure 1: TPM Cryptographic Key Management

For Windows Hello for Business, Microsoft can fill the role of the identity CA. Microsoft services can issue an
attestation identity key certificate for each device, user, and identify provider to ensure that privacy is protected and
to help identity providers ensure that device TPM requirements are met before Windows Hello for Business
credentials are provisioned.
BitLocker Drive Encryption

BitLocker provides full-volume encryption to protect data at rest. The most common device configuration splits the
hard drive into several volumes. The operating system and user data reside on one volume that holds confidential
information, and other volumes hold public information such as boot components, system information and
recovery tools. (These other volumes are used infrequently enough that they do not need to be visible to users.)
Without additional protections in place, if the volume containing the operating system and user data is not
encrypted, someone can boot another operating system and easily bypass the intended operating systems
enforcement of file permissions to read any user data.
In the most common configuration, BitLocker encrypts the operating system volume so that if the computer or
hard disk is lost or stolen when powered off, the data on the volume remains confidential. When the computer is
turned on, starts normally, and proceeds to the Windows logon prompt, the only path forward is for the user to log
on with his or her credentials, allowing the operating system to enforce its normal file permissions. If something
about the boot process changes, howeverfor example, a different operating system is booted from a USB device
the operating system volume and user data cannot be read and are not accessible. The TPM and system firmware
collaborate to record measurements of how the system started, including loaded software and configuration details
such as whether boot occurred from the hard drive or a USB device. BitLocker relies on the TPM to allow the use of
a key only when startup occurs in an expected way. The system firmware and TPM are carefully designed to work
together to provide the following capabilities:
Hardware root of trust for measurement. A TPM allows software to send it commands that record
measurements of software or configuration information. This information can be calculated using a hash algorithm
that essentially transforms a lot of data into a small, statistically unique hash value. The system firmware has a
component called the Core Root of Trust for Measurement (CRTM) that is implicitly trusted. The CRTM
unconditionally hashes the next software component and records the measurement value by sending a command
to the TPM. Successive components, whether system firmware or operating system loaders, continue the process
by measuring any software components they load before running them. Because each components measurement
is sent to the TPM before it runs, a component cannot erase its measurement from the TPM. (However,
measurements are erased when the system is restarted.) The result is that at each step of the system startup
process, the TPM holds measurements of boot software and configuration information. Any changes in boot
software or configuration yield different TPM measurements at that step and later steps. Because the system
firmware unconditionally starts the measurement chain, it provides a hardware-based root of trust for the TPM
measurements. At some point in the startup process, the value of recording all loaded software and configuration
information diminishes and the chain of measurements stops. The TPM allows for the creation of keys that can be
used only when the platform configuration registers that hold the measurements have specific values.
Key used only when boot measurements are accurate. BitLocker creates a key in the TPM that can be used
only when the boot measurements match an expected value. The expected value is calculated for the step in the
startup process when Windows Boot Manager runs from the operating system volume on the system hard drive.
Windows Boot Manager, which is stored unencrypted on the boot volume, needs to use the TPM key so that it can
decrypt data read into memory from the operating system volume and startup can proceed using the encrypted
operating system volume. If a different operating system is booted or the configuration is changed, the
measurement values in the TPM will be different, the TPM will not let Windows Boot Manager use the key, and the
startup process cannot proceed normally because the data on the operating system cannot be decrypted. If
someone tries to boot the system with a different operating system or a different device, the software or
configuration measurements in the TPM will be wrong and the TPM will not allow use of the key needed to decrypt
the operating system volume. As a failsafe, if measurement values change unexpectedly, the user can always use
the BitLocker recovery key to access volume data. Organizations can configure BitLocker to store the recovery key
in Active Directory Domain Services (AD DS).
Device hardware characteristics are important to BitLocker and its ability to protect data. One consideration is
whether the device provides attack vectors when the system is at the logon screen. For example, if the Windows
device has a port that allows direct memory access so that someone can plug in hardware and read memory, an
attacker can read the operating system volumes decryption key from memory while at the Windows logon screen.
To mitigate this risk, organizations can configure BitLocker so that the TPM key requires both the correct software
measurements and an authorization value. The system startup process stops at Windows Boot Manager, and the
user is prompted to enter the authorization value for the TPM key or insert a USB device with the value. This
process stops BitLocker from automatically loading the key into memory where it might be vulnerable, but has a
less desirable user experience.
Newer hardware and Windows 10 work better together to disable direct memory access through ports and reduce
attack vectors. The result is that organizations can deploy more systems without requiring users to enter additional
authorization information during the startup process. The right hardware allows BitLocker to be used with the
TPM-only configuration giving users a single sign-on experience without having to enter a PIN or USB key during
boot.
Device Encryption
Device Encryption is the consumer version of BitLocker, and it uses the same underlying technology. How it works
is if a customer logs on with a Microsoft account and the system meets InstantGo hardware requirements,
BitLocker Drive Encryption is enabled automatically in Windows 10. The recovery key is backed up in the Microsoft
cloud and is accessible to the consumer through his or her Microsoft account. The InstantGo hardware
requirements inform Windows 10 that the hardware is appropriate for deploying Device Encryption and allows use
of the TPM-only configuration for a simple consumer experience. In addition, InstantGo hardware is designed to
reduce the likelihood that measurement values change and prompt the customer for the recovery key.
For software measurements, Device Encryption relies on measurements of the authority providing software
components (based on code signing from manufacturers such as OEMs or Microsoft) instead of the precise hashes
of the software components themselves. This permits servicing of components without changing the resulting
measurement values. For configuration measurements, the values used are based on the boot security policy
instead of the numerous other configuration settings recorded during startup. These values also change less
frequently. The result is that Device Encryption is enabled on appropriate hardware in a user-friendly way while
also protecting data.
Measured Boot
Windows 8 introduced Measured Boot as a way for the operating system to record the chain of measurements of
software components and configuration information in the TPM through the initialization of the Windows
operating system. In previous Windows versions, the measurement chain stopped at the Windows Boot Manager
component itself, and the measurements in the TPM were not helpful for understanding the starting state of
Windows.
The Windows boot process happens in stages and often involves third-party drivers to communicate with vendor-
specific hardware or implement antimalware solutions. For software, Measured Boot records measurements of the
Windows kernel, Early-Launch Anti-Malware drivers, and boot drivers in the TPM. For configuration settings,
Measured Boot records security-relevant information such as signature data that antimalware drivers use and
configuration data about Windows security features (e.g., whether BitLocker is on or off).
Measured Boot ensures that TPM measurements fully reflect the starting state of Windows software and
configuration settings. If security settings and other protections are set up correctly, they can be trusted to maintain
the security of the running operating system thereafter. Other scenarios can use the operating systems starting
state to determine whether the running operating system should be trusted.
TPM measurements are designed to avoid recording any privacy-sensitive information as a measurement. As an
additional privacy protection, Measured Boot stops the measurement chain at the initial starting state of Windows.
Therefore, the set of measurements does not include details about which applications are in use or how Windows is
being used. Measurement information can be shared with external entities to show that the device is enforcing
adequate security policies and did not start with malware.
The TPM provides the following way for scenarios to use the measurements recorded in the TPM during boot:
Remote Attestation. Using an attestation identity key, the TPM can generate and cryptographically sign a
statement (orquote) of the current measurements in the TPM. Windows 10 can create unique attestation identity
keys for various scenarios to prevent separate evaluators from collaborating to track the same device. Additional
information in the quote is cryptographically scrambled to limit information sharing and better protect privacy. By
sending the quote to a remote entity, a device can attest which software and configuration settings were used to
boot the device and initialize the operating system. An attestation identity key certificate can provide further
assurance that the quote is coming from a real TPM. Remote attestation is the process of recording measurements
in the TPM, generating a quote, and sending the quote information to another system that evaluates the
measurements to establish trust in a device. Figure 2 illustrates this process.
When new security features are added to Windows, Measured Boot adds security-relevant configuration
information to the measurements recorded in the TPM. Measured Boot enables remote attestation scenarios that
reflect the system firmware and the Windows initialization state.
Figure 2: Process used to create evidence of boot software and configuration using a TPM
Health Attestation
Some Windows 10 improvements help security solutions implement remote attestation scenarios. Microsoft
provides a Health Attestation service, which can create attestation identity key certificates for TPMs from different
manufacturers as well as parse measured boot information to extract simple security assertions, such as whether
BitLocker is on or off. The simple security assertions can be used to evaluate device health.
Mobile device management (MDM) solutions can receive simple security assertions from the Microsoft Health
Attestation service for a client without having to deal with the complexity of the quote or the detailed TPM
measurements. MDM solutions can act on the security information by quarantining unhealthy devices or blocking
access to cloud services such as Microsoft Office 365.
Credential Guard
Credential Guard is a new feature in Windows 10 that helps protect Windows credentials in organizations that have
deployed AD DS. Historically, a users credentials (e.g., logon password) were hashed to generate an authorization
token. The user employed the token to access resources that he or she was permitted to use. One weakness of the
token model is that malware that had access to the operating system kernel could look through the computers
memory and harvest all the access tokens currently in use. The attacker could then use harvested tokens to log on
to other machines and collect more credentials. This kind of attack is called a pass the hash attack, a malware
technique that infects one machine to infect many machines across an organization.
Similar to the way Microsoft Hyper-V keeps virtual machines (VMs) separate from one another, Credential Guard
uses virtualization to isolate the process that hashes credentials in a memory area that the operating system kernel
cannot access. This isolated memory area is initialized and protected during the boot process so that components
in the larger operating system environment cannot tamper with it. Credential Guard uses the TPM to protect its
keys with TPM measurements, so they are accessible only during the boot process step when the separate region is
initialized; they are not available for the normal operating system kernel. The local security authority code in the
Windows kernel interacts with the isolated memory area by passing in credentials and receiving single-use
authorization tokens in return.
The resulting solution provides defense in depth, because even if malware runs in the operating system kernel, it
cannot access the secrets inside the isolated memory area that actually generates authorization tokens. The
solution does not solve the problem of key loggers because the passwords such loggers capture actually pass
through the normal Windows kernel, but when combined with other solutions, such as smart cards for
authentication, Credential Guard greatly enhances the protection of credentials in Windows 10.
Conclusion
The TPM adds hardware-based security benefits to Windows 10. When installed on hardware that includes a TPM,
Window 10 delivers remarkably improved security benefits. The following table summarizes the key benefits of the
TPMs major features.
FEATURE BENEFITS WHEN USED ON A SYSTEM WITH A TPM
Platform Crypto Provider If the machine is compromised, the private key associated
with the certificate cannot be copied off the device.
The TPMs dictionary attack mechanism protects PIN
values to use a certificate.
Virtual Smart Card Achieve security similar to that of physical smart cards
without deploying physical smart cards or card readers.
Windows Hello for Business Credentials provisioned on a device cannot be copied

elsewhere.
Confirm a devices TPM before credentials are provisioned.
BitLocker Drive Encryption Multiple options are available for enterprises to protect
data at rest while balancing security requirements with
different device hardware.
Device Encryption With a Microsoft account and the right hardware,

consumers devices seamlessly benefit from data-at-rest
protection.
Measured Boot A hardware root of trust contains boot measurements

that help detect malware during remote attestation.
Health Attestation MDM solutions can easily perform remote attestation and
evaluate client health before granting access to resources or
cloud services such as Office 365.
Credential Guard Defense in depth increases so that even if malware has

administrative rights on one machine, it is significantly more
difficult to compromise additional machines in an organization.
Although some of the aforementioned features have additional hardware requirements (e.g., virtualization
support), the TPM is a cornerstone of Windows 10 security. Microsoft and other industry stakeholders continue to
improve the global standards associated with TPM and find more and more applications that use it to provide
tangible benefits to customers. Microsoft has included support for most TPM features in its version of Windows for
the Internet of Things (IoT) called Windows 10 IoT Core. IoT devices that might be deployed in insecure physical
locations and connected to cloud services like Azure IoT Hub for management can use the TPM in innovative ways
to address their emerging security requirements.
Applies to
Windows 10
Windows Server 2016
This topic for the IT professional describes the Trusted Platform Module (TPM) Services that can be controlled
centrally by using Group Policy settings.
The TPM Services Group Policy settings are located at:
Computer Configuration\Administrative Templates\System\Trusted Platform Module Services\
Configure the system to use legacy Dictionary Attack Prevention Parameters setting for TPM 2.0
Introduced in Windows 10, version 1703, this policy setting configures the TPM to use the Dictionary Attack
Prevention Parameters (lockout threshold and recovery time) to the values that were used for Windows 10
Version 1607 and below. Setting this policy will take effect only if: a) the TPM was originally prepared using a
version of Windows after Windows 10 Version 1607, and b) the System has a TPM 2.0.
Note that enabling this policy will only take effect after the TPM maintenance task runs (which typically happens
after a system restart). Once this policy has been enabled on a system and has taken effect (after a system restart),
disabling it will have no impact and the system's TPM will remain configured using the legacy Dictionary Attack
Prevention parameters, regardless of the value of this group policy. The only way for the disabled setting of this
policy to take effect on a system where it was once enabled is to: a) disable it from group policy and b) clear the
TPM on the system.
The following Group Policy settings were introduced in Window 10:
Configure the list of blocked TPM commands
This policy setting allows you to manage the Group Policy list of Trusted Platform Module (TPM) commands that
are blocked by Windows.
If you enable this policy setting, Windows will block the specified commands from being sent to the TPM on the
computer. TPM commands are referenced by a command number. For example, command number 129 is
TPM_OwnerReadInternalPub, and command number 170 is TPM_FieldUpgrade. To find the command
number that is associated with each TPM command, at the command prompt, type tpm.msc to open the TPM
Management Console and navigate to the Command Management section.
If you disable or do not configure this policy setting, only those TPM commands that are specified through the
default or local lists can be blocked by Windows. The default list of blocked TPM commands is preconfigured by
Windows.
You can view the default list by typing tpm.msc at the command prompt, navigating to the Command
Management section, and exposing the On Default Block List column.
The local list of blocked TPM commands is configured outside of Group Policy by running the TPM
Management Console or scripting using the Win32_Tpm interface.
For information how to enforce or ignore the default and local lists of blocked TPM commands, see
Ignore the default list of blocked TPM commands
Ignore the local list of blocked TPM commands
Ignore the default list of blocked TPM commands
This policy setting allows you to enforce or ignore the computer's default list of blocked Trusted Platform Module
(TPM) commands.
The default list of blocked TPM commands is preconfigured by Windows. You can view the default list by typing
tpm.msc at the command prompt to open the TPM Management Console, navigating to the Command
Management section, and exposing the On Default Block List column. Also see the related policy setting,
Configure the list of blocked TPM commands.
If you enable this policy setting, the Windows operating system will ignore the computer's default list of blocked
TPM commands, and it will block only those TPM commands that are specified by Group Policy or the local list.
If you disable or do not configure this policy setting, Windows will block the TPM commands in the default list, in
addition to the commands that are specified by Group Policy and the local list of blocked TPM commands.
Ignore the local list of blocked TPM commands
This policy setting allows you to enforce or ignore the computer's local list of blocked Trusted Platform Module
(TPM) commands.
The local list of blocked TPM commands is configured outside of Group Policy by typing tpm.msc at the
command prompt to open the TPM Management Console, or scripting using the Win32_Tpm interface. (The
default list of blocked TPM commands is preconfigured by Windows.) Also see the related policy setting,
Configure the list of blocked TPM commands.
If you enable this policy setting, the Windows operating system will ignore the computer's local list of blocked
TPM commands, and it will block only those TPM commands that are specified by Group Policy or the default list.
If you disable or do not configure this policy setting, Windows will block the TPM commands in the local list, in
addition to the commands that are specified in Group Policy and the default list of blocked TPM commands.
Configure the level of TPM owner authorization information available to the operating system
This policy setting configures how much of the TPM owner authorization information is stored in the registry of
the local computer. Depending on the amount of TPM owner authorization information that is stored locally, the
Windows operating system and TPM-based applications can perform certain actions in the TPM that require TPM
owner authorization without requiring the user to enter the TPM owner password.
IMPORTANT
This policy setting is not available in the Windows 10, version 1607 and Windows Server 2016 and later versions of the
ADMX files.
There are three TPM owner authentication settings that are managed by the Windows operating system. You can
choose a value of Full, Delegate, or None.
Full This setting stores the full TPM owner authorization, the TPM administrative delegation blob, and the
TPM user delegation blob in the local registry. With this setting, you can use the TPM without requiring
remote or external storage of the TPM owner authorization value. This setting is appropriate for scenarios
that do not require you to reset the TPM anti-hammering logic or change the TPM owner authorization
value. Some TPM-based applications may require that this setting is changed before features that depend
on the TPM anti-hammering logic can be used.
Delegated This setting stores only the TPM administrative delegation blob and the TPM user delegation
blob in the local registry. This setting is appropriate for use with TPM-based applications that depend on
the TPM antihammering logic. This is the default setting in Windows.
None This setting provides compatibility with previous operating systems and applications. You can also
use it for scenarios when TPM owner authorization cannot be stored locally. Using this setting might cause
issues with some TPM-based applications.
NOTE
If the operating system managed TPM authentication setting is changed from Full to Delegated, the full TPM owner
authorization value will be regenerated, and any copies of the previously set TPM owner authorization value will be invalid.
Registry information
Registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\TPM
DWORD: OSManagedAuthLevel
The following table shows the TPM owner authorization values in the registry.
VALUE DATA SETTING
0 None
2 Delegated
4 Full
If you enable this policy setting, the Windows operating system will store the TPM owner authorization in the
registry of the local computer according to the TPM authentication setting you choose.
If you disable or do not configure this policy setting, and the Turn on TPM backup to Active Directory Domain
Services policy setting is also disabled or not configured, the default setting is to store the full TPM authorization
value in the local registry. If this policy is disabled or not configured, and the Turn on TPM backup to Active
Directory Domain Services policy setting is enabled, only the administrative delegation and the user delegation
blobs are stored in the local registry.
Standard User Lockout Duration
This policy setting allows you to manage the duration in minutes for counting standard user authorization failures
for Trusted Platform Module (TPM) commands requiring authorization. An authorization failure occurs each time a
standard user sends a command to the TPM and receives an error response that indicates an authorization failure
occurred. Authorization failures that are older than the duration you set are ignored. If the number of TPM
commands with an authorization failure within the lockout duration equals a threshold, a standard user is
prevented from sending commands that require authorization to the TPM.
The TPM is designed to protect itself against password guessing attacks by entering a hardware lockout mode
when it receives too many commands with an incorrect authorization value. When the TPM enters a lockout mode,
it is global for all users (including administrators) and for Windows features such as BitLocker Drive Encryption.
This setting helps administrators prevent the TPM hardware from entering a lockout mode by slowing the speed
at which standard users can send commands that require authorization to the TPM.
For each standard user, two thresholds apply. Exceeding either threshold prevents the user from sending a
command that requires authorization to the TPM. Use the following policy settings to set the lockout duration:
Standard User Individual Lockout Threshold This value is the maximum number of authorization failures
that each standard user can have before the user is not allowed to send commands that require
authorization to the TPM.
Standard User Total Lockout Threshold This value is the maximum total number of authorization failures
that all standard users can have before all standard users are not allowed to send commands that require
authorization to the TPM.
An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the TPM
Management Console (tpm.msc). Each time an administrator resets the TPM's hardware lockout logic, all prior
standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM
normally.
If you do not configure this policy setting, a default value of 480 minutes (8 hours) is used.
Standard User Individual Lockout Threshold
This policy setting allows you to manage the maximum number of authorization failures for each standard user
for the Trusted Platform Module (TPM). This value is the maximum number of authorization failures that each
standard user can have before the user is not allowed to send commands that require authorization to the TPM. If
the number of authorization failures for the user within the duration that is set for the Standard User Lockout
Duration policy setting equals this value, the standard user is prevented from sending commands that require
authorization to the Trusted Platform Module (TPM).
This setting helps administrators prevent the TPM hardware from entering a lockout mode by slowing the speed
at which standard users can send commands that require authorization to the TPM.
An authorization failure occurs each time a standard user sends a command to the TPM and receives an error
response indicating an authorization failure occurred. Authorization failures older than the duration are ignored.
normally.
If you do not configure this policy setting, a default value of 4 is used. A value of zero means that the operating
system will not allow standard users to send commands to the TPM, which might cause an authorization failure.
Standard User Total Lockout Threshold
This policy setting allows you to manage the maximum number of authorization failures for all standard users for
the Trusted Platform Module (TPM). If the total number of authorization failures for all standard users within the
duration that is set for the Standard User Lockout Duration policy equals this value, all standard users are
prevented from sending commands that require authorization to the Trusted Platform Module (TPM).
This setting helps administrators prevent the TPM hardware from entering a lockout mode because it slows the
speed standard users can send commands requiring authorization to the TPM.
An authorization failure occurs each time a standard user sends a command to the TPM and receives an error
response indicating an authorization failure occurred. Authorization failures older than the duration are ignored.
normally.
If you do not configure this policy setting, a default value of 9 is used. A value of zero means that the operating
system will not allow standard users to send commands to the TPM, which might cause an authorization failure.
IMPORTANT
The Turn on TPM backup to Active Directory Domain Services is not available in the Windows 10, version 1607 and
Windows Server 2016 and later versions of the ADMX files.
If you enable this policy setting, TPM owner information will be automatically and silently backed up to AD DS
when you use Windows to set or change a TPM owner password. When this policy setting is enabled, a TPM
owner password cannot be set or changed unless the computer is connected to the domain and the AD DS backup
succeeds.
If you disable or do not configure this policy setting, TPM owner information will not be backed up to AD DS.
Related topics
Back up the TPM recovery information to AD DS
Applies to
Windows 10, version 1511
Does not apply to
Windows 10, version 1607 or later
With Windows 10, versions 1511 and 1507, you can back up a computers Trusted Platform Module (TPM)
information to Active Directory Domain Services (AD DS). By doing this, you can use AD DS to administer the TPM
from a remote computer. The procedure is the same as it was for Windows 8.1. For more information, see Backup
the TPM Recovery Information to AD DS.
Related topics
Manage TPM commands
Applies to
Windows 10
Windows Server 2016
This topic for the IT professional describes how to manage which Trusted Platform Module (TPM) commands are
available to domain users and to local users.
After a computer user takes ownership of the TPM, the TPM owner can limit which TPM commands can be run by
creating a list of blocked TPM commands. The list can be created and applied to all computers in a domain by using
Group Policy, or a list can be created for individual computers by using the TPM MMC. Because some hardware
vendors might provide additional commands or the Trusted Computing Group may decide to add commands in
the future, the TPM MMC also supports the ability to block new commands.
Domain administrators can configure a list of blocked TPM commands by using Group Policy. Local administrators
cannot allow TPM commands that are blocked through Group Policy. For more information about this Group Policy
setting, see TPM Group Policy settings.
Local administrators can block commands by using the TPM MMC, and commands on the default block list are also
blocked unless the Group Policy settings are changed from the default settings.
Two policy settings control the enforcement which allows TPM commands to run. For more information about
these policy settings, see TPM Group Policy settings.
The following procedures describe how to manage the TPM command lists. You must be a member of the local
Administrators group.
To block TPM commands by using the Local Group Policy Editor
1. Open the Local Group Policy Editor (gpedit.msc). If the User Account Control dialog box appears, confirm
that the action it displays is what you want, and then click Yes.
NOTE
Administrators with appropriate rights in a domain can configure a Group Policy Object (GPO) that can be applied
through Active Directory Domain Services (AD DS).
2. In the console tree, under Computer Configuration, expand Administrative Templates, and then expand
System.
3. Under System, click Trusted Platform Module Services.
4. In the details pane, double-click Configure the list of blocked TPM commands.
5. Click Enabled, and then click Show.
6. For each command that you want to block, click Add, enter the command number, and then click OK.
NOTE
For a list of commands, see links in the TPM Specification.
7. After you have added numbers for each command that you want to block, click OK twice.
8. Close the Local Group Policy Editor.
To block or allow TPM commands by using the TPM MMC
1. Open the TPM MMC (tpm.msc)
2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and
then click Yes.
3. In the console tree, click Command Management. A list of TPM commands is displayed.
4. In the list, select a command that you want to block or allow.
5. Under Actions, click Block Selected Command or Allow Selected Command as needed. If Allow
Selected Command is unavailable, that command is currently blocked by Group Policy.
To block new commands
1. Open the TPM MMC (tpm.msc).
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and
then click Yes.
2. In the console tree, click Command Management. A list of TPM commands is displayed.
3. In the Action pane, click Block New Command. The Block New Command dialog box is displayed.
4. In the Command Number text box, type the number of the new command that you want to block, and then
click OK. The command number you entered is added to the blocked list.
Use the TPM cmdlets

Related topics
Manage TPM lockout
Applies to
Windows 10
Windows Server 2016
This topic for the IT professional describes how to manage the lockout feature for the Trusted Platform Module
(TPM) in Windows.
About TPM lockout

The TPM will lock itself to prevent tampering or malicious attacks. TPM lockout often lasts for a variable amount of
time or until the computer is turned off. While the TPM is in lockout mode, it generally returns an error message
when it receives commands that require an authorization value. One exception is that the TPM always allows the
owner at least one attempt to reset the TPM lockout when it is in lockout mode.
TPM ownership is taken upon first boot by Windows. By default, Windows does not retain the TPM owner
password.
In some cases, encryption keys are protected by a TPM by requiring a valid authorization value to access the key. A
common example is configuring BitLocker Drive Encryption to use the TPM plus PIN key protector. In this scenario,
the user must type the correct PIN during the boot process to access the volume encryption key protected by the
TPM. To prevent malicious users or software from discovering authorization values, TPMs implement protection
logic. The protection logic is designed to slow or stop responses from the TPM if it detects that an entity might be
trying to guess authorization values.
TPM 1.2
The industry standards from the Trusted Computing Group (TCG) specify that TPM manufacturers must implement
some form of protection logic in TPM 1.2 and TPM 2.0 chips. TPM 1.2 devices implement different protection
mechanisms and behavior. In general, the TPM chip takes exponentially longer to respond if incorrect authorization
values are sent to the TPM. Some TPM chips may not store failed attempts over time. Other TPM chips may store
every failed attempt indefinitely. Therefore, some users may experience increasingly longer delays when they
mistype an authorization value that is sent to the TPM. This can prevent them from using the TPM for a period of
time.
TPM 2.0
TPM 2.0 devices have standardized lockout behavior which is configured by Windows. TPM 2.0 devices have a
maximum count threshold and a healing time. Windows configures the maximum count to be 32 and the healing
time to be 2 hours. This means that every continuous two hours of powered on operation without an event which
increases the counter will cause the counter to decrease by 1.
If your TPM has entered lockout mode or is responding slowly to commands, you can reset the lockout value by
using the following procedures. Resetting the TPM lockout requires the TPM owners authorization. This value is no
longer retained by default starting with Windows 10 version 1607.
Reset the TPM lockout by using the TPM MMC

NOTE
This procedure is only available if you have configured Windows to retain the TPM Owner Password. By default, this
password is not available in Windows 10 starting with version 1607.
The following procedure explains the steps to reset the TPM lockout by using the TPM MMC.
To reset the TPM lockout
2. In the Action pane, click Reset TPM Lockout to start the Reset TPM Lockout Wizard.
3. Choose one of the following methods to enter the TPM owner password:
If you saved your TPM owner password to a .tpm file, click I have the owner password file, and
then type the path to the file, or click Browse to navigate to the file location.
If you want to manually enter your TPM owner password, click I want to enter the owner
password, and then type the password in the text box provided.
NOTE
If you enabled BitLocker and your TPM at the same time, and you printed your BitLocker recovery password when
you turned on BitLocker, your TPM owner password may have printed with it.
Use Group Policy to manage TPM lockout settings

The TPM Group Policy settings in the following list are located at:
Computer Configuration\Administrative Templates\System\Trusted Platform Module Services\
Standard User Lockout Duration
This policy setting allows you to manage the duration in minutes for counting standard user authorization
failures for TPM commands that require authorization. An authorization failure occurs each time a user
sends a command to the TPM and receives an error message that indicates an authorization failure
occurred. Authorization failures that are older than the duration you set are ignored. If the number of TPM
commands with an authorization failure within the lockout duration equals a threshold, the user is
prevented from sending commands to the TPM that require authorization.
Standard User Individual Lockout Threshold
This policy setting allows you to manage the maximum number of authorization failures for the TPM for
each user. This value is the maximum number of authorization failures that each user can have before the
user is not allowed to send commands to the TPM that require authorization. If the number of authorization
failures equals the duration that is set for the policy setting, the user is prevented from sending commands
to the TPM that require authorization.
Standard User Total Lockout Threshold
This policy setting allows you to manage the maximum number of authorization failures for the TPM for all
standard users. If the total number of authorization failures for all users equals the duration that is set for
the policy, all users are prevented from sending commands to the TPM that require authorization.
For information about mitigating dictionary attacks that use the lockout settings, see TPM fundamentals.
Use the TPM cmdlets
Related topics
Applies to
This topic for the IT professional describes how to change the password or PIN for the owner of the Trusted
Platform Module (TPM) that is installed on your system.
About the TPM owner password

Starting with Windows 10, version 1607, Windows will not retain the TPM owner password when provisioning the
TPM. The password will be set to a random high entropy value and then discarded.
IMPORTANT
Although the TPM owner password is not retained starting with Windows 10, version 1607, you can change a default
registry key to retain it. However, we strongly recommend that you do not make this change. To retain the TPM owner
password, set the registry key 'HKLM\Software\Policies\Microsoft\TPM' [REG_DWORD] 'OSManagedAuthLevel' to 4. The
default value for this key is 2, and unless it is changed to 4 before the TPM is provisioned, the owner password will not be
saved.
Only one owner password exists for each TPM. The TPM owner password allows the ability to enable, disable, or
clear the TPM without having physical access to the computer, for example, by using the command-line tools
remotely. The TPM owner password also allows manipulation of the TPM dictionary attack logic. Taking ownership
of the TPM is performed by Windows as part of the provisioning process on each boot. Ownership can change
when you share the password or clear your ownership of the TPM so someone else can initialize it.
Without the owner password you can still perform all the preceding actions by means of a physical presence
confirmation from UEFI.
Other TPM management options
Instead of changing your owner password, you can also use the following options to manage your TPM:
Clear the TPM If you want to invalidate all of the existing keys that have been created since you took
ownership of the TPM, you can clear it. For important precautions for this process, and instructions for
completing it, see Clear all the keys from the TPM.
Turn off the TPM With TPM 1.2 and Windows 10, versions 1507 and 1511, you can turn off the TPM. Do
this if you want to keep all existing keys and data intact and disable the services that are provided by the
TPM. For more info, see Turn off the TPM.

With Windows 10, version 1507 or 1511, if you have opted specifically to preserve the TPM owner password, you
can use the saved password to change to a new password.
To change to a new TPM owner password, in TPM.msc, click Change Owner Password, and follow the
instructions. You will be prompted to provide the owner password file or to type the password. Then you can create
a new password, either automatically or manually, and save the password in a file or as a printout.
Use the TPM cmdlets
Related topics
View status, clear, or troubleshoot the TPM
Applies to
Windows 10
Windows Server 2016
This topic for the IT professional describes actions you can take through the Trusted Platform Module (TPM) snap-
in, TPM.msc:
View the status of the TPM
Troubleshoot TPM initialization
Clear all the keys from the TPM
With TPM 1.2 and Windows 10, version 1507 or 1511, you can also take the following actions:
Turn on or turn off the TPM
For information about the TPM cmdlets, see TPM Cmdlets in Windows PowerShell.
About TPM initialization and ownership

Starting with Windows 10, the operating system automatically initializes and takes ownership of the TPM. This is a
change from previous operating systems, where you would initialize the TPM and create an owner password.
Therefore, with Windows 10, in most cases, we recommend that you avoid configuring the TPM through TPM.msc.
The one exception is that in certain circumstances you might use TPM.msc to clear the TPM. For more information,
see Clear all the keys from the TPM, later in this topic.
View the status of the TPM

To view the status of the TPM, open the TPM Management console (TPM.msc). In the center pane, find the Status
box.
In most cases, the status will be Ready. If the status is ready but with reduced functionality, see Clear all the
keys from the TPM, later in this topic.
If the status is Not ready, you can try the steps in Clear all the keys from the TPM, later in this topic. If this does not
bring it to a Ready state, contact the manufacturer, and see the troubleshooting suggestions in the next section.
Troubleshoot TPM initialization

If you find that Windows is not able to initialize the TPM automatically, review the following information:
You can try clearing the TPM to the factory default values and allowing Windows to re-initialize it. For
important precautions for this process, and instructions for completing it, see Clear all the keys from the
TPM, later in this topic.
If the TPM is a TPM 2.0 and is not detected by Windows, verify that your computer hardware contains a
Unified Extensible Firmware Interface (UEFI) that is Trusted Computing Group-compliant. Also, ensure that in
the UEFI settings, the TPM has not been disabled or hidden from the operating system.
If you have TPM 1.2 with Windows 10, version 1507 or 1511, the TPM might be turned off, and need to be
turned back on, as described in Turn on the TPM. When it is turned back on, Windows will re-initialize it.
If you are attempting to set up BitLocker with the TPM, check which TPM driver is installed on the computer.
We recommend always using one of the TPM drivers that is provided by Microsoft and is protected with
BitLocker. If a non-Microsoft TPM driver is installed, it may prevent the default TPM driver from loading and
cause BitLocker to report that a TPM is not present on the computer. If you have a non-Microsoft driver
installed, remove it and then allow the operating system to initialize the TPM.
Troubleshoot network connection issues for Windows 10, versions 1507 and 1511
If you have Windows 10, version 1507 or 1511, the initialization of the TPM cannot complete when your computer
has network connection issues and both of the following conditions exist:
An administrator has configured your computer to require that TPM recovery information be saved in Active
Directory Domain Services (AD DS). This requirement can be configured through Group Policy.
A domain controller cannot be reached. This can occur on a computer that is currently disconnected from
the network, separated from the domain by a firewall, or experiencing a network component failure (such as
an unplugged cable or a faulty network adapter).
If these issues occur, an error message appears, and you cannot complete the initialization process. To avoid this
issue, allow Windows to initialize the TPM while you are connected to the corporate network and you can contact a
domain controller.
Troubleshoot systems with multiple TPMs
Some systems may have multiple TPMs and the active TPM may be toggled in UEFI. Windows 10 does not support
this behavior. If you switch TPMs, Windows might not properly detect or interact with the new TPM. If you plan to
switch TPMs you should toggle to the new TPM, clear it, and reinstall Windows. For more information, see Clear all
the keys from the TPM, later in this topic.
For example, toggling TPMs will cause BitLocker to enter recovery mode. We strongly recommend that, on systems
with two TPMs, one TPM is selected to be used and the selection is not changed.
Clear all the keys from the TPM

With Windows 10, in most cases, we recommend that you avoid configuring the TPM through TPM.msc. The one
exception is that you can use TPM.msc to clear the TPM, for example, as a troubleshooting step, or as a final
preparation before a clean installation of a new operating system. Preparing for a clean installation in this way
helps ensure that the new operating system can fully deploy any TPM-based functionality that it includes, for
example, attestation. However, even if the TPM is not cleared before a new operating system is installed, most TPM
functionality will probably work correctly.
Clearing the TPM resets it to an unowned state. After you clear the TPM, the Windows 10 operating system will
automatically re-initialize it and take ownership again.
WARNING
Clearing the TPM can result in data loss. For more information, see the next section, Precautions to take before clearing the
TPM.
There are several ways to clear the TPM:

Clear the TPM as part of a complete reset of the computer: You might want to remove all files from the
computer and completely reset it, for example, in preparation for a clean installation. To do this, we
recommend that you use the Reset option in Settings. When you perform a reset and use the Remove
everything option, it will clear the TPM as part of the reset. You might be prompted to press a key before
the TPM can be cleared. For more information, see the Reset this PC section in Recovery options in
Windows 10.
Clear the TPM to fix reduced functionality or Not ready TPM status: If you open TPM.msc and see
that the TPM status is something other than Ready, you can can try using TPM.msc to clear the TPM and fix
the status. However, be sure to review the precautions in the next section.
Precautions to take before clearing the TPM
Clearing the TPM can result in data loss. To protect against such loss, review the following precautions:
Clearing the TPM causes you to lose all created keys associated with the TPM, and data protected by those
keys, such as a virtual smart card or a login PIN. Make sure that you have a backup and recovery method for
any data that is protected or encrypted by the TPM.
Do not clear the TPM on a device you do not own, such as a work or school PC, without being instructed to
do so by your IT administrator.
If you want to temporarily suspend TPM operations and you have TPM 1.2 with Windows 10, version 1507
or 1511, you can turn off the TPM. For more information, see Turn off the TPM, later in this topic.
Always use functionality in the operating system (such as TPM.msc) to the clear the TPM. Do not clear the
TPM directly from UEFI.
Because your TPM security hardware is a physical part of your computer, before clearing the TPM, you
might want to read the manuals or instructions that came with your computer, or search the manufacturer's
website.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.
To clear the TPM
2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and
then click Yes.
3. Under Actions, click Clear TPM.
4. You will be prompted to restart the computer. During the restart, you might be prompted by the UEFI to
press a button to confirm that you wish to clear the TPM.
5. After the PC restarts, your TPM will be automatically prepared for use by Windows 10.
Turn on or turn off the TPM (available only with TPM 1.2 with Windows
10, version 1507 or 1511)
Normally, the TPM is turned on as part of the TPM initialization process. You do not normally need to turn the TPM
on or off. However, if necessary you can do so by using the TPM MMC.
Turn on the TPM
If you want to use the TPM after you have turned it off, you can use the following procedure to turn on the TPM.
To turn on the TPM (TPM 1.2 with Windows 10, version 1507 or 1511 only)
2. In the Action pane, click Turn TPM On to display the Turn on the TPM Security Hardware page. Read the
instructions on this page.
3. Click Shutdown (or Restart), and then follow the UEFI screen prompts.
After the computer restarts, but before you sign in to Windows, you will be prompted to accept the
reconfiguration of the TPM. This ensures that the user has physical access to the computer and that
malicious software is not attempting to make changes to the TPM.
Turn off the TPM
If you want to stop using the services that are provided by the TPM, you can use the TPM MMC to turn off the TPM.
To turn off the TPM (TPM 1.2 with Windows 10, version 1507 or 1511 only)
2. In the Action pane, click Turn TPM Off to display the Turn off the TPM security hardware page.
3. In the Turn off the TPM security hardware dialog box, select a method to enter your owner password and
turning off the TPM:
If you saved your TPM owner password on a removable storage device, insert it, and then click I have
the owner password file. In the Select backup file with the TPM owner password dialog box,
click Browse to locate the .tpm file that is saved on your removable storage device, click Open, and
then click Turn TPM Off.
If you do not have the removable storage device with your saved TPM owner password, click I want
to enter the password. In the Type your TPM owner password dialog box, type your password
(including hyphens), and then click Turn TPM Off.
If you did not save your TPM owner password or no longer know it, click I do not have the TPM
owner password, and follow the instructions that are provided in the dialog box and subsequent
UEFI screens to turn off the TPM without entering the password.
Change the TPM Owner Password (available only with Windows 10, version 1607 and earlier versions)
If you have the owner password available, you can use TPM.msc to change the TPM Owner Password.
2. In the Action pane, click Change the Owner Password
If you saved your TPM owner password on a removable storage device, insert it, and then click I have
the owner password file. In the Select backup file with the TPM owner password dialog box,
click Browse to locate the .tpm file that is saved on your removable storage device, click Open, and
then click Turn TPM Off.
If you do not have the removable storage device with your saved TPM owner password, click I want
to enter the password. In the Type your TPM owner password dialog box, type your password
(including hyphens), and then click Turn TPM Off.
This capability was fully removed from TPM.msc in later versions of Windows.
Use the TPM cmdlets

Related topics
Understanding PCR banks on TPM 2.0 devices
Applies to
Windows 10
Windows Server 2016
For steps on how to switch PCR banks on TPM 2.0 devices on your PC, you should contact your OEM or UEFI
vendor. This topic provides background about what happens when you switch PCR banks on TPM 2.0 devices.
A Platform Configuration Register (PCR) is a memory location in the TPM that has some unique properties. The size
of the value that can be stored in a PCR is determined by the size of a digest generated by an associated hashing
algorithm. A SHA-1 PCR can store 20 bytes the size of a SHA-1 digest. Multiple PCRs associated with the same
hashing algorithm are referred to as a PCR bank.
To store a new value in a PCR, the existing value is extended with a new value as follows: PCR[N] = HASHalg(
PCR[N] || ArgumentOfExtend )
The existing value is concatenated with the argument of the TPM Extend operation. The resulting concatenation is
then used as input to the associated hashing algorithm, which computes a digest of the input. This computed digest
becomes the new value of the PCR.
The TCG PC Client Platform TPM Profile Specification defines the inclusion of at least one PCR bank with 24
registers. The only way to reset the first 16 PCRs is to reset the TPM itself. This restriction helps ensure that the
value of those PCRs can only be modified via the TPM Extend operation.
Some TPM PCRs are used as checksums of log events. The log events are extended in the TPM as the events occur.
Later, an auditor can validate the logs by computing the expected PCR values from the log and comparing them to
the PCR values of the TPM. Since the first 16 TPM PCRs cannot be modified arbitrarily, a match between an
expected PCR value in that range and the actual TPM PCR value provides assurance of an unmodified log.
How does Windows 10 use PCRs?

To bind the use of a TPM based key to a certain state of the PC, the key can be sealed to an expected set of PCR
values. For instance, PCRs 0 through 7 have a well-defined value after the boot process when the OS is loaded.
When the hardware, firmware, or boot loader of the machine changes, the change can be detected in the PCR
values. Windows 10 uses this capability to make certain cryptographic keys only available at certain times during
the boot process. For instance, the BitLocker key can be used at a certain point in the boot, but not before or after.
It is important to note that this binding to PCR values also includes the hashing algorithm used for the PCR. For
instance, a key can be bound to a specific value of the SHA-1 PCR[12], if using SHA-256 PCR banks, even with the
same system configuration. Otherwise, the PCR values will not match.
What happens when PCR banks are switched?

When the PCR banks are switched, the algorithm used to compute the hashed values stored in the PCRs during
extend operations is changed. For the same input, each hash algorithm will return a different cryptographic
signature for the same inputs.
As a result, if the currently used PCR bank is switched all keys that have been bound to the previous PCR values will
no longer work. For example, if you had a key bound to the SHA-1 value of PCR[12] and subsequently changed the
PCR banks to SHA-256, the banks wouldnt match, and you would be unable to use that key. The BitLocker key is
secured using the PCR banks and Windows 10 will not be able to unseal it if the PCR banks are switched while
BitLocker is enabled.
What can I do to switch PCRs when BitLocker is already active?

Before switching PCR banks you should suspend or disable BitLocker or have your recovery key ready. For steps
on how to switch PCR banks on your PC, you should contact your OEM or UEFI vendor.
Related topics
TPM recommendations
Applies to
Applies to
Windows 10
Windows Server 2016
This topic provides recommendations for Trusted Platform Module (TPM) technology for Windows 10.
For a basic feature description of TPM, see the Trusted Platform Module Technology Overview.
TPM design and implementation

Traditionally, TPMs have been discrete chips soldered to a computers motherboard. Such implementations allow
the computers original equipment manufacturer (OEM) to evaluate and certify the TPM separate from the rest of
the system. Although discrete TPM implementations are still common, they can be problematic for integrated
devices that are small or have low power consumption. Some newer TPM implementations integrate TPM
functionality into the same chipset as other platform components while still providing logical separation similar to
discrete TPM chips.
TPMs are passive: they receive commands and return responses. To realize the full benefit of a TPM, the OEM must
carefully integrate system hardware and firmware with the TPM to send it commands and react to its responses.
TPMs were originally designed to provide security and privacy benefits to a platforms owner and users, but newer
versions can provide security and privacy benefits to the system hardware itself. Before it can be used for advanced
scenarios, however, a TPM must be provisioned. Windows 10 automatically provisions a TPM, but if the user is
planning to reinstall the operating system, he or she may need to clear the TPM before reinstalling so that
Windows can take full advantage of the TPM.
The Trusted Computing Group (TCG) is the nonprofit organization that publishes and maintains the TPM
specification. The TCG exists to develop, define, and promote vendor-neutral, global industry standards that
support a hardware-based root of trust for interoperable trusted computing platforms. The TCG also publishes the
TPM specification as the international standard ISO/IEC 11889, using the Publicly Available Specification
Submission Process that the Joint Technical Committee 1 defines between the International Organization for
Standardization (ISO) and the International Electrotechnical Commission (IEC).
OEMs implement the TPM as a component in a trusted computing platform, such as a PC, tablet, or phone. Trusted
computing platforms use the TPM to support privacy and security scenarios that software alone cannot achieve.
For example, software alone cannot reliably report whether malware is present during the system startup process.
The close integration between TPM and platform increases the transparency of the startup process and supports
evaluating device health by enabling reliable measuring and reporting of the software that starts the device.
Implementation of a TPM as part of a trusted computing platform provides a hardware root of trustthat is, it
behaves in a trusted way. For example, if a key stored in a TPM has properties that disallow exporting the key, that
key truly cannot leave the TPM.
The TCG designed the TPM as a low-cost, mass-market security solution that addresses the requirements of
different customer segments. There are variations in the security properties of different TPM implementations just
as there are variations in customer and regulatory requirements for different sectors. In public-sector procurement,
for example, some governments have clearly defined security requirements for TPMs whereas others do not.
TPM 1.2 vs. 2.0 comparison
From an industry standard, Microsoft has been an industry leader in moving and standardizing on TPM 2.0, which
has many key realized benefits across algorithms, crypto, hierarchy, root keys, authorization and NV RAM.
Why TPM 2.0?

TPM 2.0 products and systems have important security advantages over TPM 1.2, including:
The TPM 1.2 spec only allows for the use of RSA and the SHA-1 hashing algorithm.
For security reasons, some entities are moving away from SHA-1. Notably, NIST has required many federal
agencies to move to SHA-256 as of 2014, and technology leaders, including Microsoft and Google have
announced they will remove support for SHA-1 based signing or certificates in 2017.
TPM 2.0 enables greater crypto agility by being more flexible with respect to cryptographic algorithms.
TPM 2.0 supports newer algorithms, which can improve drive signing and key generation
performance. For the full list of supported algorithms, see the TCG Algorithm Registry. Some TPMs
do not support all algorithms.
For the list of algorithms that Windows supports in the platform cryptographic storage provider, see
CNG Cryptographic Algorithm Providers.
TPM 2.0 achieved ISO standardization (ISO/IEC 11889:2015).
Use of TPM 2.0 may help eliminate the need for OEMs to make exception to standard configurations
for certain countries and regions.
TPM 2.0 offers a more consistent experience across different implementations.
TPM 1.2 implementations vary in policy settings. This may result in support issues as lockout policies
vary.
TPM 2.0 lockout policy is configured by Windows, ensuring a consistent dictionary attack protection
guarantee.
While TPM 1.2 parts are discrete silicon components which are typically soldered on the motherboard, TPM
2.0 is available as a discrete (dTPM) silicon component in a single semiconductor package, an integrated
component incorporated in one or more semiconductor packages - alongside other logic units in the same
package(s) - and as a firmware (fTPM) based component running in a trusted execution environment (TEE)
on a general purpose SoC.
Discrete, Integrated or Firmware TPM?

There are three implementation options for TPMs:
Discrete TPM chip as a separate component in its own semiconductor package
Integrated TPM solution, using dedicated hardware integrated into one or more semiconductor packages
alongside, but logically separate from, other components
Firmware TPM solution, running the TPM in firmware in a Trusted Execution mode of a general purpose
computation unit
Windows uses any compatible TPM in the same way. Microsoft does not take a position on which way a TPM
should be implemented and there is a wide ecosystem of available TPM solutions which should suit all needs.
Is there any importance for TPM for consumers?

For end consumers, TPM is behind the scenes but is still very relevant. TPM is used for Windows Hello, Windows
Hello for Business and in the future, will be a component of many other key security features in Windows. TPM
secures the PIN, helps encrypt passwords, and builds on our overall Windows 10 experience story for security as a
critical pillar. Using Windows on a system with a TPM enables a deeper and broader level of security coverage.
TPM 2.0 Compliance for Windows 10

Windows 10 for desktop editions (Home, Pro, Enterprise, and Education)
Since July 28, 2016, all new device models, lines or series (or if you are updating the hardware configuration of
a existing model, line or series with a major update, such as CPU, graphic cards) must implement and enable by
default TPM 2.0 (details in section 3.7 of the Minimum hardware requirements page). The requirement to
enable TPM 2.0 only applies to the manufacturing of new devices. For TPM recommendations for specific
Windows features, see TPM and Windows Features.
IoT Core
TPM is optional on IoT Core.
Windows Server 2016
TPM is optional for Windows Server SKUs unless the SKU meets the additional qualification (AQ) criteria for the
Host Guardian Services scenario in which case TPM 2.0 is required.
TPM and Windows Features

The following table defines which Windows features require TPM support.
WINDOWS FEATURES WINDOWS 10 TPM 1.2 WINDOWS 10 TPM 2.0 DETAILS
Measured Boot Required Required Measured boot requires

TPM 1.2 or 2.0 and UEFI
Secure Boot.
Bitlocker Required Required TPM 1.2 or later required or

a removable USB memory
device such as a flash drive.
Please note that TPM 2.0
requires UEFI Secure Boot in
order for BitLocker to work
properly.
Passport: Domain AADJ Join Required Required Supports both versions of

TPM, but requires TPM with
HMAC and EK certificate for
key attestation support.
Passport: MSA or Local Required Required TPM 2.0 is required with

Account HMAC and EK certificate for
key attestation support.
Device Encryption Not Applicable Required TPM 2.0 is required for all
InstantGo devices.
Device Guard / Configurable Not Applicable Required Beginning with Windows 10,
Code Integrity version 1607, Trusted
Platform Module (TPM 2.0)
must be enabled by default
on new computers.
WINDOWS FEATURES WINDOWS 10 TPM 1.2 WINDOWS 10 TPM 2.0 DETAILS
Credential Guard Required Required For Windows 10, version

1511, TPM 1.2 or 2.0 is
highly recommended. If you
don't have a TPM installed,
Credential Guard will still be
enabled, but the keys used
to encrypt Credential Guard
will not be protected by the
TPM.
Device Health Attestation Required Required
Windows Hello / Windows Not Required Recommended Whenever possible,

Hello for Business Microsoft recommends the
use of TPM hardware. The
TPM protects against a
variety of known and
potential attacks, including
PIN brute-force attacks. How
keys are protected
UEFI Secure Boot Not Required Recommended
Platform Key Storage Required Required

provider
Virtual Smart Card Required Required
Certificate storage (TPM Required Required

bound)
OEM Status on TPM 2.0 system availability and certified parts

Government customers and enterprise customers in regulated industries may have acquisition standards that
require use of common certified TPM parts. As a result, OEMs, who provide the devices, may be required to use
only certified TPM components on their commercial class systems. For more information, contact your OEM or
hardware vendor.
Related topics
1 min to read
Edit O nline
Windows 10 Mobile security guide
Applies to Windows 10 Mobile, version 1511 and Windows Mobile, version 1607
This guide provides a detailed description of the most important security features in the Windows 10 Mobile
operating systemidentity access and control, data protection, malware resistance, and app platform security.
Smartphones now serve as a primary productivity tool for business workers and, just like desktops or laptops, need
to be secured against malware and data theft. Protecting these devices can be challenging due to the wide range of
device operating systems and configurations and the fact that many employees use their own personal devices. IT
needs to secure corporate assets on every device, but also ensure the privacy of the users personal apps and data.
Windows 10 Mobile addresses these security concerns directly, whether workers are using personal or corporate-
owned devices. It uses the same security technologies as the Windows 10 operating system to help protect against
known and emerging security threats across the spectrum of attack vectors. These technologies include:
Windows Hello for Business Enhanced identity and access control features ensure that only authorized users
can access corporate data and resources. Windows Hello simplifies multifactor authentication (MFA)
deployment and use, offering PIN, companion device, and biometric authentication methods.
Windows Information Protection Automatic data separation keeps corporate information from being shared
with personal data and apps.
Malware resistance Multi-layered protections built into the device hardware, startup processes, and app
platform help reduce the threat of malware that can compromise employee devices.
This guide helps IT administrators better understand the security features in Windows 10 Mobile, which can be
used to improve protection against unauthorized access, data leakage, and malware.
In this article:
Windows Hello for Business
Windows Information Protection
Malware resistance
Windows Hello
Windows 10 Mobile includes Windows Hello, a simple, yet powerful, multifactor authentication solution that
confirms a users identity before allowing access to corporate confidential information and resources. Multifactor
authentication is a more secure alternative to password-based device security. Users dislike having to enter long,
complex passwords particularly on a mobile device touch screen that corporate policy requires they change
frequently. This leads to poor security practices like password reuse, written down passwords, or weak password
creation.
Windows Hello offers a simple, cost-effective way to deploy multifactor authentication across your organization.
Unlike smart cards, it does not require public key infrastructure or the implementation of additional hardware.
Workers use a PIN, a companion device (like Microsoft Band), or biometrics to validate their identity for accessing
corporate resources on their Azure Active Directory (Azure AD) registered Windows 10 Mobile device.
Because Windows Hello is supported across all Windows 10 devices, organizations can uniformly implement
multifactor authentication across their environment. Deploying Windows Hello on Windows 10 Mobile devices
does require Azure AD (sold separately), but you can use Azure AD Connect to synchronize with your on-premises
Active Directory services.
Windows Hello supports iris scan, fingerprint, and facial recognition-based authentication for devices that have
biometric sensors.
Note: When Windows 10 first shipped, it included Microsoft Passport and Windows Hello, which worked
together to provide multifactor authentication. To simplify deployment and improve supportability, Microsoft
has combined these technologies into a single solution under the Windows Hello name. Customers who have
already deployed these technologies will not experience any change in functionality. Customers who have yet
to evaluate Windows Hello will find it easier to deploy due to simplified policies, documentation, and semantics.
Secured credentials
Windows Hello eliminates the use of passwords for login, reducing the risk that an attacker will steal and reuse a
users credentials. Windows 10 Mobile devices are required to have a Trusted Platform Module (TPM), a microchip
that enables advanced security features. The TPM creates encryption keys that are wrapped with the TPMs own
storage root key, which is itself stored within the TPM to prevent credentials from being compromised. Encryption
keys created by the TPM can only be decrypted by the same TPM, which protects the key material from attackers
who want to capture and reuse it.
To compromise Windows Hello credentials, an attacker would need access to the physical device, and then find a
way to spoof the users biometric identity or guess his or her PIN. All of this would have to be accomplished before
TPM brute-force resistance capabilities lock the mobile device, the theft-protection mechanism kicks in, or the user
or corporate administrator remotely wipes the device. With TPM-based protection, an attackers window of
opportunity for compromising a users credentials is greatly reduced.
Support for biometrics
Biometrics help prevent credential theft and make it easier for users to login to their devices. Users always have
their biometric identity with them there is nothing to forget, lose, or leave behind. Attackers would need to have
both access to the users device and be able to impersonate the users biometric identity to gain access to
corporate resources, which is far more difficult than stealing a password.
Windows Hello supports three biometric sensor scenarios:
Facial recognition uses special IR cameras to reliably tell the difference between a photograph or scan and a
living person. Several vendors are shipping external cameras that incorporate this technology, and major
manufacturers are already shipping laptops with integrated facial-recognition technology. Both Surface Pro 4
and Surface Book support this technology.
Fingerprint recognition uses a sensor to scan the users fingerprint. Although fingerprint readers have been
available for computers running the Windows operating system for years, the detection, anti-spoofing, and
recognition algorithms in Windows 10 are more advanced than in previous Windows versions. Most existing
fingerprint readers (whether external to or integrated into laptops or USB keyboards) that support the Windows
Biometric Framework will work with Windows Hello.
Iris scanning uses cameras designed to scan the users iris, the colorful and highly detailed portion of the eye.
Because the data must be accurate, iris scanning uses a combination of an IR light source and a high-quality
camera. Microsoft Lumia 950 and 950 XL devices support this technology.
Users must create an unlock PIN while they enroll a biometric gesture. The device uses this PIN as a fallback
mechanism in situations where it cannot capture the biometric gesture.
All three of these biometric factors face, finger, and iris are unique to an individual. To capture enough data to
uniquely identify an individual, a biometric scanner might initially capture images in multiple conditions or with
additional details. For example, an iris scanner will capture images of both eyes or both eyes with and without
eyeglasses or contact lenses.
Spoofing biometric data is often a big concern in enterprise environments. Microsoft employs several anti-
spoofing techniques in Windows 10 Mobile that verify the trustworthiness of the biometric device, as well as guard
against intentional collision with stored biometric measurements. These techniques help improve the false-
acceptance rate (the rate at which spoofed biometric data is accepted as authentic) while maintaining the overall
usability and manageability of MFA.
The biometric image collected at enrollment is converted into an algorithmic form that cannot be converted back
into the original image. Only the algorithmic form is kept; the actual biometric image is removed from the device
after conversion. Windows 10 Mobile devices both encrypt the algorithmic form of the biometric data and bind the
encrypted data to the device, both of which help prevent someone from removing the data from the phone. As a
result, the biometric information that Windows Hello uses is a local gesture and doesnt roam among the users
devices.
Companion devices
A Windows Hello companion device enables a physical device, like a wearable, to serve as a factor for validating the
users identity before granting them access to their credentials. For instance, when the user has physical possession
of a companion device they can easily, possibly even automatically, unlock their PC and authenticate with apps and
websites. This type of device can be useful for smartphones or tablets that dont have integrated biometric sensors
or for industries where users need a faster, more convenient sign-in experience, such as retail.
In some cases, the companion device for Windows Hello enables a physical device, like a phone, wearable, or other
types of device to store all of the users credentials. Storage of the credentials on a mobile device makes it possible
to use them on any supporting device, like a kiosk or family PC, and eliminates the need to enroll Windows Hello
on each device. Companion devices also help enable organizations to meet regulatory requirements, such as
Federal Information Processing Standard (FIPS) Publication 140-2, (FIPS 140-2).
Standards-based approach
The Fast Identity Online (FIDO) Alliance is a nonprofit organization that works to address the lack of interoperability
among strong authentication devices and the problems users face in creating and remembering multiple user
names and passwords. FIDO standards help reduce reliance on passwords to authenticate users of online services
securely, allowing any business network, app, website, or cloud application to interface with a broad variety of
existing and future FIDO-enabled devices and operating system platforms.
In 2014, Microsoft joined the board of the FIDO Alliance. The FIDO 1.0 specifications, published in December 2014,
provide for two types of authentications: password-less (known as UAF) and second factor (U2F). The FIDO Alliance
is working on a set of 2.0 proposals that incorporate the best ideas from its U2F and UAF FIDO 1.0 standards.
Microsoft has contributed Windows Hello technology to the FIDO 2.0 specification workgroup for review and
feedback and continues to work with the FIDO Alliance as the FIDO 2.0 specification moves forward.
Interoperability of FIDO products is a hallmark of FIDO authentication. Microsoft believes that bringing a FIDO
solution to market will help solve a critical need for both enterprises and consumers.
Windows Information Protection

Enterprises have seen huge growth in the convergence of personal and corporate data storage. Personal data is
frequently stored on corporate devices and vice versa. This fluidity increases the potential for sensitive corporate
data to be accidentally compromised.
Inadvertent disclosure is rapidly becoming the biggest source of confidential data leakage as organizations allow
personal devices to access corporate resources. Its easy to imagine that an employee using work email on their
personal phone could unintentionally save an attachment containing sensitive company information to personal
cloud storage, which could be shared with unauthorized people. This accidental sharing of corporate data is just
one example of the challenges common to using mobile devices in the workplace. To prevent this type of data
leakage, most solutions require users to login with a separate username and password to a container that stores all
corporate apps and data, an experience that degrades user productivity.
Windows 10 Mobile includes Windows Information Protection to transparently keep corporate data secure and
personal data private. Because corporate data is always protected, users cannot inadvertently copy it or share it
with unauthorized users or apps. Key features include:
Automatically tag personal and corporate data.
Protect data while its at rest on local or removable storage.
Control which apps can access corporate data.
Control which apps can access a virtual private network (VPN) connection.
Prevent users from copying corporate data to public locations.
Help ensure business data is inaccessible when the device is in a locked state.
Enlightened apps
Third-party data loss protection solutions usually require developers to wrap their apps. However, Windows
Information Protection builds this intelligence right into Windows 10 Mobile so most apps require nothing extra to
prevent inappropriate corporate data sharing.
Windows Information Protection classifies apps into two categories: enlightened and unenlightened. Enlighted
apps can differentiate between corporate and personal data, correctly determining which to protect based on
internal policies. Corporate data will be encrypted on the managed device and attempts to copy/paste or share this
information with non-corporate apps or users will fail. Unenlightened apps, when marked as corporate-managed,
consider all data corporate and encrypt everything by default.
When you do not want all data encrypted by default because it would create a poor user experience developers
should consider enlightening apps by adding code and compiling them using the Windows Information Protection
application programming interfaces. The most likely candidates for enlightenment are apps that:
Dont use common controls for saving files.
Dont use common controls for text boxes.
Work on personal and enterprise data simultaneously (e.g., contact apps that display personal and enterprise
data in a single view or a browser that displays personal and enterprise web pages on tabs within a single
instance).
In many cases, most apps dont require enlightenment for them to use Windows Information Protection. Simply
adding them to the allow list is the only step you need to take. Line-of-Business (LOB) apps are a good example of
where this works well because they only handle corporate data.
When is app enlightenment required?
Required
App needs to work with both personal and enterprise data.
Recommended
App handles only corporate data, but needs to modify a file (such as a configuration file) in order to
launch, uninstall itself, update etc. Without enlightenment you wouldnt be able to properly revoke these
apps.
App needs to access enterprise data, while protection under lock is activated.
Not required
App handles only corporate data
App handles only personal data
Data leakage control
To configure Windows Information Protection in a Mobile Device Management (MDM) solution that supports it,
simply add authorized apps to the allow list. When a device running Windows 10 Mobile enrolls in the MDM
solution, unauthorized apps will not have access to enterprise data.
Windows Information Protection works seamlessly until users try to access enterprise data with or paste enterprise
data into unauthorized apps or locations on the web. For example, copying enterprise data from an authorized app
to another authorized app works as usual, but Window Information Protection can block users from copying
enterprise data from an authorized app to an unauthorized app. Likewise, it will block users from using an
unauthorized app to open a file that contains enterprise data.
The extent to which users will be prevented from copying and pasting data from authorized apps to unauthorized
apps or locations on the web depends on which protection level is set:
Block. Windows Information Protection blocks users from completing the operation.
Override. Windows Information Protection notifies users that the operation is inappropriate but allows them to
override the policy, although it logs the operation in the audit log.
Audit. Windows Information Protection does not block or notify users but logs the operation in the audit log.
Off. Windows Information Protection does not block or notify users and does not log operations in the audit
log.
Data separation
Most third-party solutions require an app wrapper that directs enterprise data into a password-protected container
and keeps personal data outside the container. Depending on the implementation, this may require two different
versions of the same apps to be running on the device: one for personal data and another for enterprise data.
Windows Information Protection provides data separation without requiring a container or special version of an
app to access business or personal data. There is no separate login required to see your corporate data or open
your corporate applications. Windows Information Protection identifies enterprise data and encrypts it to only
enterprise use. Data separation is automatic and seamless.
Encryption
Windows 10 Mobile uses device encryption, based on BitLocker technology, to encrypt all internal storage,
including operating systems and data storage partitions. The user can activate device encryption, or the IT
department can activate and enforce encryption for company-managed devices through MDM tools. When device
encryption is turned on, all data stored on the phone is encrypted automatically. A Windows 10 Mobile device with
encryption turned on helps protect the confidentiality of data stored even if the device is lost or stolen. The
combination of Windows Hello lock and data encryption makes it extremely difficult for an unauthorized party to
retrieve sensitive information from the device.
You can customize how device encryption works to meet your unique security requirements. Device encryption
even enables you to define your own cipher suite. For example, you can specify the algorithm and key size that
Windows 10 Mobile uses for data encryption, which Transport Layer Security (TLS) cipher suites are permitted, and
whether Federal Information Processing Standard (FIPS) policy is enabled. The list below shows the policies you
can change to customize device encryption on Windows 10 Mobile devices.
Cryptography
Allow FIPS Algorithm: This policy enables or disable the FIPS policy. A restart is needed to enforce this
policy. The default value is disabled.
TLS Cipher Suite: This policy contains a list of the cryptographic cipher algorithms allowed for Secure
Sockets Layer connections.
BitLocker
Encryption Method: Configures the BitLocker Drive Encryption Method and cipher strength. The default
value is AES-CBC 128-bit. If the device cannot use the value specified, it will use another one.
To help make the device even more secured against outside interference, Windows 10 Mobile also now includes
protection-under-lock. That means that encryption keys are removed from memory whenever a device is locked.
Apps are unable to access sensitive data while the device is in a locked state, so hackers and malware have no way
to find and co-opt keys. Everything is locked up tight with the TPM until the user unlocks the device with Windows
Hello.
Government Certifications
Windows 10 Mobile supports both FIPS 140 standards for cryptography and Common Criteria The FIPS 140
certification validates the effectiveness of the cryptographic algorithms used in Windows 10 Mobile. Microsoft has
also received Common Criteria certification for Windows 10 Mobile running on Lumia 950, 950 XL, 550, 635, as
well as Surface Pro 4, giving customers assurance that securety functionality is implemented properly.
Malware resistance
The best way to fight malware is prevention. Windows 10 Mobile provides strong malware resistance through
secured hardware, startup process defenses, core operating system architecture, and application-level protections.
The table below outlines how Windows 10 Mobile mitigates specific malware threats.
THREAT WINDOWS 10 MOBILE MITIGATION
Firmware bootkits replace the firmware with All certified devices include Unified Extensible Firmware (UEFI) with
malware. Secure Boot, which requires signed firmware for updates to UEFI and
Option ROMs.
Bootkits start malware before Windows UEFI with Secure Boot verifies Windows bootloader integrity to help
starts. ensure that no malicious operating system can start before Windows.
System or driver rootkits (typically malicious Windows Trusted Boot verifies Windows boot components, including
software that hides from the operating Microsoft drivers. Measured Boot runs in parallel with Trusted Boot and
system) start kernel- level malware while can provide information to a remote server that verifies the boot state
Windows is starting, before antimalware of the device to help ensure that Trusted Boot and other boot
solutions can start. components successfully checked the system.
An app infects other apps or the operating All Windows 10 Mobile apps run inside an AppContainer that isolates
system with malware. them from all other processes and sensitive operating system
components. Apps cannot access any resources outside their
AppContainer.
An unauthorized app or malware attempts All Windows 10 Mobile apps must come from Windows Store or
to start on the device. Windows Store for Business. Device Guard enforces administrative
policies to select exactly which apps are allowed to run.
User-level malware exploits a vulnerability in Improvements to address space layout randomization (ASLR), Data
the system or an application and owns the Execution Prevention (DEP), the heap architecture, and memory-
device. management algorithms reduce the likelihood that vulnerabilities can
enable successful exploits.
Protected Processes isolates non-trusted processes from each other
and from sensitive operating system components.
Users access a dangerous website without The SmartScreen URL Reputation feature prevents users from going to
knowledge of the risk. a malicious website that may try to exploit the browser and take control
of the device.
Malware exploits a vulnerability in a browser Microsoft Edge is an app built on the Universal Windows Platform
add-on. (UWP) that does not run legacy binary extensions, including Microsoft
ActiveX and browser helper objects frequently used for toolbars, which
eliminates these risks.
THREAT WINDOWS 10 MOBILE MITIGATION
A website that includes malicious code Microsoft Edge includes Enhanced Protected Mode, which uses
exploits a vulnerability in the web browser to AppContainer-based sandboxing to help protect the system against
run malware on the client device. vulnerabilities that at attacker may discover in the extensions running in
the browser (for example, Adobe Flash, Java) or the browser itself.
Note: The Windows 10 Mobile devices use a System on a Chip (SoC) design provided by SoC vendors such as
Qualcomm. With this architecture, the SoC vendor and device manufacturers provide the pre-UEFI bootloaders
and the UEFI environment. The UEFI environment implements the UEFI Secure Boot standard described in
section 27 of the UEFI specification, which can be found at www.uefi.org/specs. This standard describes the
process by which all UEFI drivers and applications are validated against keys provisioned into a UEFI-based
device before they are executed.
UEFI with Secure Boot

When a Windows 10 Mobile device starts, it begins the process of loading the operating system by locating the
bootloader in the devices storage system. Without safeguards in place, the phone might simply hand control over
to the bootloader without even determining whether its a trusted operating system or malware.
UEFI is a standards-based solution that offers a modern-day replacement for the BIOS. In fact, it provides the same
functionality as BIOS while adding security features and other advanced capabilities. Like BIOS, UEFI initializes
devices, but UEFI components with the Secure Boot feature (version 2.3.1 or later) also helps to ensure that only
trusted firmware in Option ROMs, UEFI apps, and operating system bootloaders can start on the mobile phone.
UEFI can run internal integrity checks that verify the firmwares digital signature before running it. Because only the
mobile phones manufacturer has access to the digital certificate required to create a valid firmware signature, UEFI
has protection against firmware-based malware that loads before Windows 10 Mobile and to try and hide its
malicious behavior from the operating system. Firmware-based malware of this nature is typically called bootkits.
When a mobile device with UEFI and Secure Boot starts, the UEFI firmware verifies the bootloaders digital
signature to verify that no one has modified it after it was digitally signed. The firmware also verifies that a trusted
authority issued the bootloaders digital signature. This check helps to ensure that the system starts only after
checking that the bootloader is both trusted and unmodified since signing.
All Windows 10 Mobile devices always have Secure Boot enabled. In addition, they trust only the Windows
operating system signature. Neither Windows 10 Mobile, apps, or even malware can change the UEFI
configuration. For more information about UEFI with Secure Boot, read Protecting the pre-OS environment with
UEFI
A Trusted Platform Module (TPM) is a tamper-resistant cryptographic module that enhances the security and
privacy of computing platforms. The TPM is incorporated as a component in a trusted computing platform like a
PC, tablet, or smartphone. A trusted computing platform is specially designed to work with the TPM to support
privacy and security scenarios that software alone cannot achieve. A TPM is required to receive Windows 10 Mobile
device hardware certification.
A proper implementation of a TPM as part of a trusted computing platform provides a hardware root of trust,
meaning that the hardware behaves in a trusted way. For example, if you create a key in a TPM with the property
that no one can export that key from the TPM, the key absolutely cannot leave the TPM. The close integration of a
TPM with a platform increases the transparency of the boot process and supports device health scenarios by
enabling a reliable report of the software used to start a platform.
The following list describes key functionality that a TPM provides in Windows 10 Mobile:
Managing cryptographic keys. A TPM can create, store, and permit the use of keys in defined ways. Windows
10 Mobile uses the TPM to protect the encryption keys for BitLocker volumes, virtual smart cards, certificates,
and various other keys.
Safeguarding and reporting integrity measurements. Windows 10 Mobile uses the TPM to record and help
protect integrity-related measurements of select hardware and Windows boot components for the Measured
Boot feature. In this scenario, Measured Boot measures each component from firmware up through the
drivers and then stores those measurements in the devices TPM. From here, you can test the measurement
log remotely so that a separate system verifies the boot state of the Windows 10 Mobile device.
Proving a TPM is really a TPM. Managing cryptographic keys and measuring integrity are so central to
protecting privacy and security that a TPM must differentiate itself from malware masquerading as a TPM.
Windows 10 Mobile supports TPM implementations that comply with the 2.0 standard. The TPM 2.0 standard
includes several improvements that make it superior to the 1.2 standard, the most notable of which is
cryptographic agility. TPM 1.2 is restricted to a fixed set of encryption and hash algorithms. When the TPM 1.2
standard appeared in the early 2000s, the security community considered these algorithms cryptographically
strong. Since then, advances in cryptographic algorithms and cryptanalysis attacks have increased expectations for
stronger cryptography. TPM 2.0 supports additional algorithms that offer stronger cryptographic protection, as
well as the ability to plug-in algorithms that certain geographies or industries may prefer. It also opens the
possibility for inclusion of future algorithms without changing the TPM component itself.
Many assume that original equipment manufacturers (OEMs) must implant a TPM in hardware on a motherboard
as a discrete module, but TPM can also be effective when implemented in firmware. Windows 10 Mobile supports
only firmware TPM that complies with the 2.0 standard. Windows does not differentiate between discrete and
firmware-based solutions because both must meet the same implementation and security requirements. Therefore,
any Windows 10 feature that can take advantage of TPM can be used with Windows 10 Mobile.
Microsoft requires TPM 2.0 on devices running any version of Windows 10 Mobile. For more information, see
minimum hardware requirements
Several Windows 10 Mobile security features require TPM:

Virtual smart cards
Measured Boot
Health attestation (requires TPM 2.0 or later)
Still other features will use the TPM if it is available. For example, Windows Hello does not require TPM but uses it if
its available. Organizations can configure policy to require TPM for Windows Hello.
Biometrics
Windows 10 Mobile makes biometrics a core security feature. Microsoft has fully integrated biometrics into the
Windows 10 Mobile security components, not just tacked it on top of the platform (as was the case in previous
versions of Windows). This is a big change. Earlier biometric implementations were largely front-end methods that
simplified authentication. Under the hood, the system used biometrics to access a password, which it then used for
authentication behind the scenes. Biometrics may have provided convenience, but not necessarily enterprise-grade
authentication.
Microsoft has been evangelizing the importance of enterprise-grade biometric sensors to the OEMs that create
Windows 10 Mobile devices. These facial-recognition and iris-scanning sensors are fully supported by Windows
Hello.
In the future, Microsoft expects OEMs to produce even more advanced enterprise-grade biometric sensors and to
continue integrating them into mobile devices. As a result, biometrics will become a commonplace authentication
method as part of an MFA system.
Trusted Boot
UEFI with Secure Boot uses hardware technologies to help protect users from bootkits. Secure Boot can validate the
integrity of the device, firmware, and bootloader. After the bootloader launches, users must rely on the operating
system to protect the integrity of the remainder of the system.
When UEFI with Secure Boot verifies that it trusts the bootloader and starts Windows 10 Mobile, the Windows
Trusted Boot feature protects the rest of the startup process by verifying that all Windows startup components are
trustworthy (e.g., signed by a trusted source) and have integrity. The bootloader verifies the digital signature of the
Windows kernel before loading it. The Windows kernel, in turn, verifies every other component of the Windows
startup process, including the boot drivers, and startup files.
Measured Boot
In earlier versions of Windows, the biggest challenge with rootkits and bootkits was that they could frequently be
undetectable to the client. Because they often started before Windows defenses and the antimalware solution and
they had system-level privileges rootkits and bootkits could completely disguise themselves while continuing to
access system resources. Although UEFI with Secure Boot and Trusted Boot could prevent most rootkits and
bootkits, intruders could still potentially exploit a few attack vectors (e.g., if someone compromised the signature
used to sign a boot component, such as a non-Microsoft driver, and used it to sign a malicious one).
Windows 10 Mobile implements the Measured Boot feature, which uses the TPM hardware component to record a
series of measurements for critical startup-related components, including firmware, Windows boot components,
and drivers. Because Measured Boot uses the hardware-based security capabilities of TPM, which isolates and
protects the measurement data against malware attacks, the log data is well protected against even sophisticated
attacks.
Measured Boot focuses on acquiring the measurement data and protecting it against tampering. To provide more
complete security, it must be coupled with a service that can analyze the data to determine device health.
Device Health Attestation
Device Health Attestation (DHA) is a new feature in Windows 10 Mobile that helps prevent low-level malware
infections. DHA uses a devices TPM and firmware to measure the critical security properties of the devices BIOS
and Windows startup processes. These measurements are made in such a way that even on a system infected with
kernel-level malware or a rootkit, an attacker is unlikely to spoof the properties.
You can use DHA with Microsoft Intune (sold separately) or a third-party MDM solution to combine hardware-
measured security properties with other device properties and gain an overall view of the devices health and
compliance state. This integration can be useful in a variety of scenarios, including detecting jailbroken devices,
monitoring device compliance, generating compliance reports, alerting users or administrators, initiating corrective
action on the device, and managing conditional access to resources such as Office 365.
The example that follows shows how Windows 10 protective measures integrate and work with Intune and third-
party MDM solutions. It demonstrates how the phone security architecture in Windows 10 Mobile can help you
monitor and verify compliance and how the security and trust rooted in the device hardware can protect end-to-
end corporate resources.
When a user turns a phone on:
1. The Secure Boot feature in Windows 10 Mobile helps protect the startup sequence, allows the device to boot
into a defined and trusted configuration, and loads a factory-trusted boot loader.
2. Windows 10 Mobile Trusted Boot takes control when the Secure Boot process is complete, verifying the digital
signature of the Windows kernel and the components that are loaded and executed during the startup process.
3. In parallel to steps 1 and 2, the phones TPM runs independently in a hardware-protected security zone (isolated
from the boot execution path, which monitors boot activities). It creates a protected, tamper-evident audit trail,
signed with a secret that only the TPM can access.
4. Devices that are DHA-enabled send a copy of this audit trail to the Microsoft Health Attestation service (HAS) in
a protected, tamper-resistant, and tamper-evident communication channel.
5. HAS reviews the audit trails, issues an encrypted and signed report, and forwards it to the device.
6. From your DHA-enabled MDM solution, you can review the report in a protected, tamper-resistant, and tamper-
evident communication channel to assess whether the device is running in a compliant (healthy) state, allow
access, or trigger corrective action aligned with the organizations security needs and policies. Because this
solution can detect and prevent low-level malware that may be extremely difficult to detect any other way,
Microsoft recommends that you consider implementing a DHA-enabled MDM system like Intune. It can take
advantage of the Windows 10 Mobile cloud-based health attestation server feature to detect and block devices
infected with advanced malware.
Device Guard
Device Guard is a feature set that consists of both hardware and software system integrityhardening features.
These features revolutionize Windows operating system security by moving the entire operating system to a trust-
nothing model.
All apps on Windows 10 Mobile must be digitally signed and come from Windows Store or a trusted enterprise
store. Device Guard implements policies that further restrict this. By default, Device Guard supports all apps from
Windows Store. You can create policies that define the apps that can and cannot run on the Windows 10 Mobile
device. If the app does not have a digital signature, is prevented by policy, or does not come from a trusted store, it
will not run on Windows 10 Mobile.
Advanced hardware features, described above, drive these security offerings. By integrating these hardware
features further into the core operating system, Windows 10 Mobile can use them in new ways. To deliver this
additional security, Device Guard requires UEFI with Secure Boot.
Address Space Layout Randomization
One of the most common techniques used by attackers to gain access to a system is to find a vulnerability in a
privileged process that is already running, guess or find a location in memory where important system code and
data reside, and overwrite that information with a malicious payload. In the early days of operating systems, any
malware that could write directly to the system memory could do such a thing; the malware would simply
overwrite system memory in well-known and predictable locations.
Address Space Layout Randomization (ASLR) makes that type of attack much more difficult because it randomizes
how and where important data is stored in memory. With ASLR, it is more difficult for malware to find the specific
location it needs to attack. The below diagram illustrates how ASLR works, showing how the locations of different
critical Windows components can change in memory between restarts.
Microsoft has substantively improved the ASLR implementation in Windows 10 Mobile over previous versions,
applying it across the entire system rather than only in specific apps. With 64bit system and application processes
that can take advantage of a vastly increased memory space, it is even more difficult for malware to predict where
Windows 10 Mobile stores vital data. When used on systems that have TPMs, ASLR memory randomization
becomes increasingly unique across devices, adding additional degrees of difficulty for repurposing successful
exploits to another system.
Data Execution Prevention
Malware depends on its ability to insert a malicious payload into memory with the hope that an unsuspecting user
will execute it later. While ASLR makes that more difficult, Windows 10 Mobile extends that protection to prevent
malware from running if written to an area that you have allocated solely for the storage of information. Data
Execution Prevention (DEP) substantially reduces the range of memory that malicious code can use for its benefit.
DEP uses the No execute bit on modern CPUs to mark blocks of memory as read-only so that malware cant use
those blocks to execute malicious code. All Windows 10 and Windows 10 Mobile devices support DEP.
Windows heap
The heap is a location in memory that Windows uses to store dynamic application data. Microsoft continues to
improve on earlier Windows heap designs by further mitigating the risk of heap exploits that an attacker could use.
Windows 10 Mobile has made several important improvements to the security of the heap over previous versions
of Windows:
Internal data structures that the heap uses are better protected against memory corruption.
Heap memory allocations have randomized locations and sizes, making it more difficult for an attacker to
predict the location of critical memory to overwrite. Specifically, Windows 10 Mobile adds a random offset to
the address of a newly allocated heap, making the allocation much less predictable.
Windows 10 Mobile uses guard pages before and after blocks of memory as tripwires. If an attacker attempts
to write past a block of memory (a common technique known as a buffer overflow), the attacker will have to
overwrite a guard page. Any attempt to modify a guard page is considered a memory corruption, and Windows
10 Mobile responds by instantly terminating the app.
Memory reservations
Microsoft reserves the lowest 64 KB of process memory for the operating system. Apps are no longer allowed to
allocate that portion of the memory, making it more difficult for malware to overwrite critical system data
structures in memory.
Control Flow Guard
When Windows loads applications into memory, it allocates space to those applications based on the size of the
code, requested memory, and other factors. When an application begins to execute code, it calls additional code
located in other memory addresses. The relationships among the code locations are well known they are written
in the code itself. However, until Windows 10 Mobile, the operating system didnt enforce the flow among these
locations, giving attackers the opportunity to change the flow to meet their needs. In other words, an application
exploit takes advantage of this behavior by running code that the application may not typically run.
Windows 10 Mobile mitigates this kind of threat through Control Flow Guard (CFG). When a trusted application
that its creator compiled to use CFG calls code, CFG verifies that the code location called is trusted for execution. If
CFG doesnt trust the location, it immediately terminates the application as a potential security risk.
You cannot configure CFG; rather, an application developer can take advantage of CFG by configuring it when he or
she compiles the application. Because browsers are a key entry point for attacks, Microsoft Edge takes full
advantage of CFG.
Protected Processes
Unfortunately, no device is immune to malware. Despite all the best preventative controls, malware can eventually
find a way to infect any operating system or hardware platform. So, although prevention with a defense-in-depth
strategy is important, additional malware controls are required. If malware is running on a system, you need to
limit what it can do Protected Processes prevents untrusted processes from tampering with those that have been
specially signed. Protected Processes defines levels of trust for processes: it prevents less trusted processes from
interacting with and therefore attacking more trusted processes. Windows 10 Mobile uses Protected Processes
broadly throughout the operating system.
AppContainer
The Windows 10 Mobile security model is based on the principle of least privilege and uses isolation to achieve it.
Every app and even portions of the operating system itself run inside their own isolated sandbox called an
AppContainer a secured isolation boundary within which an app and its processes can run. Each AppContainer is
defined and implemented through a security policy.
The security policy of a specific AppContainer defines the operating system capabilities that apps have access to
from within the AppContainer, such as geographical location information, camera, microphone, networking, or
sensors.
A set of default permissions are granted to all AppContainers, including access to a unique, isolated storage
location. Access to other capabilities can be declared within the app code itself. Unlike traditional desktop
applications, access to additional capabilities and privileges cannot be requested at run time.
The AppContainer concept is advantageous because it provides:
Attack surface reduction. Apps can access only those capabilities that are declared in the application code and
needed to perform their functions.
User consent and control. Capabilities that apps use are automatically published to the app details page in the
Windows Store. App access to capabilities that may expose sensitive information automatically prompt the user
to acknowledge and provide consent.
App isolation. Communication between Windows apps is tightly controlled. Apps are isolated from one
another and can communicate only by using predefined communication channels and data types.
Apps receive the minimal privileges they need to perform their legitimate tasks. This means that even if a malicious
attacker exploits an app, the potential damage is limited because the app cannot elevate its privileges and is
contained within its AppContainer. Windows Store displays the permissions that the app requires along with the
apps age rating and publisher.
The combination of Device Guard and AppContainer help to prevent unauthorized apps from running. In the event
malware slips into the app ecosystem, the AppContainer helps to constrain the app and limit potential damage. The
Windows 10 Mobile trust-nothing model doesnt assume that any component is perfect. However, potential
vulnerabilities in apps, AppContainers, and Windows 10 Mobile itself could give an attacker a chance to
compromise a system. For this reason, redundant vulnerability mitigations are needed. The next several topics
describe some of the redundant mitigations in Windows 10 Mobile.
Microsoft Edge
The web browser is a critical component of any security strategy. It is the users interface to the Internet, an
environment teeming with malicious sites and potentially dangerous content. Most users cannot perform at least
part of their job without a browser, and many users are completely reliant on one. This reality has made the
browser the number one pathway from which malicious hackers initiate their attacks.
Windows 10 Mobile includes Microsoft Edge, an entirely new web browser that goes beyond browsing with
features like Reading View. Microsoft Edge is more secure than previous Microsoft web browsers in several ways:
Microsoft Edge on Windows 10 Mobile does not support extensions. Microsoft Edge has built-in PDF
viewing capability.
Microsoft Edge is designed as a UWP app. It is inherently compartmentalized and runs in an AppContainer
that sandboxes the browser from the system, data, and other apps.
Microsoft Edge simplifies security configuration tasks. Because Microsoft Edge uses a simplified
application structure and a single sandbox configuration, fewer security settings are required. In addition,
Microsoft established Microsoft Edge default settings that align with security best practices, making it more
secure by design.
Summary
Windows 10 Mobile provides security on personal and corporate-owned devices to protect against unauthorized
access, data leakage, and malware threats. All of the features covered in this paper multifactor authentication,
data separation, and malware resistance are seamlessly incorporated into the operating system. This means
enterprises are protected without compromising the productivity and ease of use that drives users to bring mobile
devices into the workplace.
Revision History
November 2015 Updated for Windows 10 Mobile (version 1511)
July 2016 Updated for Windows 10 Mobile Anniversary Update (version 1607)
Change history for device security
This topic lists new and updated topics in the Device security documentation.
August 2017
NEW OR CHANGED TOPIC DESCRIPTION
BitLocker: Management recommendations for enterprises New BitLocker security topic.
July 2017
How Windows 10 uses the Trusted Platform Module New TPM security topic.
May 2017
BitLocker Group Policy settings Changed startup PIN minimun length from 4 to 6.
Network access: Restrict clients allowed to make remote calls New security policy setting.
to SAM
March 2017
Requirements and deployment planning guidelines for Device Updated to include additional security qualifications starting
Guard with Windows 10, version 1703.

Windows 10

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Windows 10

Caricato da

Copyright:

Formati disponibili

Table of Contents

AppLocker Describes AppLocker, and can help you decide if your

BitLocker Provides information about BitLocker, which is a data

When to use AppLocker

Using AppLocker on Server Core

SETTING DEFAULT VALUE

Accounts created None

Authentication method Not applicable

Management interfaces AppLocker can be managed by using a Microsoft

Ports opened None

Protocols used Not applicable

Scheduled Tasks Appidpolicyconverter.exe is put in a scheduled task to be run

Security Policies None required. AppLocker creates security policies.

System Services required Application Identity service (appidsvc) runs under

Storage of credentials None

Administer AppLocker This topic for IT professionals provides links to specific

Using the MMC snap-ins to administer AppLocker

Using Windows PowerShell to administer AppLocker

Maintaining AppLocker policies by using Group Policy

Maintaining AppLocker policies by using the Local Security Policy snap-

Editing an AppLocker policy by using Group Policy

Step 3: Use AppLocker to modify and test the rule

Editing an AppLocker policy by using the Local Security Policy snap-in

Step 2: Identify and modify the rule to change, delete, or add

Step 1: Enable the Audit only enforcement setting

Step 2: Configure the Application Identity service to start

Step 3: Test the policy

Step 4: Analyze AppLocker events

Step 5: Modify the AppLocker policy

Step 6: Repeat policy testing, analysis, and policy modification

Background and prerequisites

Step 1: Retrieve the AppLocker policy

Step 2: Alter the enforcement setting

Step 3: Update the policy

Step 4: Monitor the effect of the policy

AppLocker Windows PowerShell cmdlets

Using AppLocker and Software Restriction Policies in the same domain

APPLICATION CONTROL FUNCTION SRP APPLOCKER

Optimization of Group Policy

To review AppLocker events with Get-AppLockerFileInformation

View the AppLocker Log in Event Viewer

Understanding Packaged apps and Packaged app installers for

Using AppLocker to manage packaged apps

Enforce rules Rules are enforced.

RULE COLLECTION ASSOCIATED FILE FORMATS

Executable files .exe

Windows Installer files .msi

Packaged apps and packaged app installers .appx

DLL files .dll

OPTION THE PUBLISHER CONDITION ALLOWS OR DENIES

Publisher, product name, file name, and file version Exactly

WINDOWS DIRECTORY OR DISK APPLOCKER PATH VARIABLE WINDOWS ENVIRONMENT VARIABLE

Windows %WINDIR% %SystemRoot%

System32 %SYSTEM32% %SystemDirectory%

Windows installation directory %OSDRIVE% %SystemDrive%

Program Files %PROGRAMFILES% %ProgramFiles% and

Removable media (for example, a CD or %REMOVABLE%

Removable storage device (for example, %HOT%

AppLocker rule behavior

DLL rule collection

SELECTION DESCRIPTION EXAMPLE

SELECTION DESCRIPTION EXAMPLE

To use the Set-AppLockerPolicy cmdlet, first import the Applocker modules:

PS C:\Users\Administrator> import-module AppLocker