Identity - Access PDF

Contents
Identity and Access

Solutions and Scenario Guides
Dynamic Access Control: Scenario Overview
Scenario: Central Access Policy
Deploy a Central Access Policy (Demonstration Steps)
Scenario: File Access Auditing
Plan for File Access Auditing
Deploy Security Auditing with Central Audit Policies (Demonstration Steps)
Scenario: Access-Denied Assistance
Deploy Access-Denied Assistance (Demonstration Steps)
Scenario: Classification-Based Encryption for Office Documents
Deploy Encryption of Office Files (Demonstration Steps)
Scenario: Get Insight into Your Data by Using Classification
Deploy Automatic File Classification (Demonstration Steps)
Scenario: Implement Retention of Information on File Servers
Deploy Implementing Retention of Information on File Servers Demonstration
Steps
Deploy Claims Across Forests
Deploy Claims Across forests (Demonstration Steps)
Claims Transformation Rules Language
Appendix A: Dynamic Access Control Glossary
Appendix B: Setting Up the Test Environment
Active Directory Domain Services
What's new in Active Directory Domain Services
AD DS Getting started
Active Directory Domain Services Overview
Active Directory Administrative Center
AD Recycle Bin, Fine-Grained Password Policy, and PowerShell History
Advanced AD DS Management Using Active Directory Administrative Center
Active Directory Domain Services Virtualization
Introduction to Active Directory Domain Services (AD DS) Virtualization (Level
100)
Virtualized Domain Controller Technical Reference (Level 300)
Virtualized Domain Controller Architecture
Virtualized Domain Controller Deployment and Configuration
Virtualized Domain Controllers using Hyper-V
Virtualized Domain Controller Troubleshooting
Virtualized Domain Controller Technical Reference appendix
Virtualized Domain Controller additional Resources
Virtualized Domain Controller Cloning Test Guidance for Application Vendors
Support for using Hyper-V Replica for virtualized domain controllers
Windows Time Service and AD DS
AD DS Design and Planning
Understanding AD DS Design
Identifying Your AD DS Design and Deployment Requirements
AD DS Design Requirements
AD DS Deployment Requirements
Mapping Your Requirements to an AD DS Deployment Strategy
Deploying AD DS in a New Organization
Deploying AD DS in a Windows Server 2003 Organization
Deploying AD DS in a Windows 2000 Organization
Designing the Logical Structure
Understanding the Active Directory Logical model
Identifying the Deployment Project Participants
Creating a Forest Design
Identifying Forest Design Requirements
Determining the Number of Forests Required
Creating a Domain Design
Reviewing the Domain models
Determining the Number of Domains Required
Determining Whether to Upgrade Existing Domains or Deploy New Domains
Assigning Domain Names
Selecting the Forest Root Domain
Creating a DNS Infrastructure Design
Reviewing DNS Concepts
DNS and AD DS
Assigning the DNS for AD DS Owner Role
Integrating AD DS into an Existing DNS Infrastructure
Appendix A: DNS Inventory
Creating an Organizational Unit Design
Reviewing OU Design Concepts
Delegating Administration by Using OU Objects
Finding additional Resources for Logical Structure Design
Designing the Site Topology
Understanding Active Directory Site Topology
Site Functions
Site Topology Owner Role
Active Directory Replication Concepts
Collecting Network Information
Planning Domain Controller Placement
Planning Forest Root Domain Controller Placement
Planning regional Domain Controller Placement
Planning Global Catalog Server Placement
Planning Operations Master Role Placement
Creating a Site Design
Creating a Site Link Design
Setting Site Link Properties
Creating a Site Link Bridge Design
Finding additional Resources for Windows Server 2008 Active Directory Site
Topology Design
Appendix A: Locations and Subnet Prefixes
Enabling Advanced Features for AD DS
Windows Server Functional Levels
Identifying Your Functional Level Upgrade
Finding additional Resources for Enabling Advanced Features
Evaluating AD DS Deployment Strategy Examples
Appendix A: Reviewing Key AD DS Terms
AD DS Deployment
What's New in Active Directory Domain Services Installation and Removal
Upgrade Domain Controllers to Windows Server 2016
Upgrade Domain Controllers to Windows Server 2012 R2 and Windows Server
2012
AD DS Simplified Administration
Simplified Administration appendix
Install Active Directory Domain Services
Install a New Windows Server Active Directory Forest
Install a Replica Windows Server 2012 Domain Controller in an Existing Domain
Install a New Windows Server Active Directory Child or tree Domain
Install a Windows Server 2012 Active Directory Read-Only Domain Controller
(RODC)
Demoting Domain Controllers
AD DS metadata cleanup
AD DS Installation and removal Wizard Page Descriptions
Changes Made by Adprep
Schema Updates
Read-Only Domain Controller Updates
Domain-Wide Updates
Forest-Wide Updates
Troubleshooting Domain Controller Deployment
AD DS Operations
AD Forest Recovery Guide
AD Forest Recovery - Prerequisites
AD Forest Recovery - Steps for Recovery
AD Forest Recovery - Identify the Problem
AD Forest Recovery - Perform Initial Recovery
AD Forest Recovery - Procedures
AD Forest Recovery - FAQ
AD Forest Recovery - Recovering a single domain with multidomain forest
AD Forest Recovery - Virtualization
AD Forest Recovery - Windows Server 2003
Best Practices for Securing Active Directory
Executive Summary
Introduction
Avenues to compromise
Attractive Accounts for Credential Theft
Reducing the Active Directory attack Surface
Implementing Least-Privilege Administrative models
Implementing Secure Administrative Hosts
Securing Domain Controllers Against attack
Monitoring Active Directory for Signs of compromise
Audit Policy Recommendations
Planning for compromise
Maintaining a more Secure Environment
Appendices
Appendix B: Privileged Accounts and Groups in Active Directory
Appendix C: Protected Accounts and Groups in Active Directory
Appendix D: Securing Built-In Administrator Accounts in Active Directory
Appendix E: Securing Enterprise Admins Groups in Active Directory
Appendix F: Securing Domain Admins Groups in Active Directory
Appendix G: Securing Administrators Groups in Active Directory
Appendix H: Securing Local Administrator Accounts and Groups
Appendix I: Creating Management Accounts for Protected Accounts and Groups
in Active Directory
Appendix L: Events to Monitor
Appendix M: Document Links and Recommended Reading
Active Directory Replication and Topology Management Using Windows
powershell
Introduction to Active Airectory Replication and Topology Management Using
Windows PowerShell (Level 100)
Advanced Active Directory Replication and Topology Management Using
Windows powershell (Level 200)
Managing RID Issuance
Active Directory Domain Services component Updates
Identity component updates
SPN and UPN uniqueness
Winlogon Automatic Restart Sign-On (ARSO)
TPM Key attestation
CA Backup and Restore Windows powershell cmdlets
Command line process auditing
Directory Services component updates
How to Configure Protected Accounts
How LDAP Server Cookies Are Handled
AD DS Troubleshooting
Configuring a computer for Troubleshooting
Troubleshooting Active Directory Replication Problems
Additional Resources
Active Directory Federation Services
AD FS Overview
What's new in Active Directory Federation Services
AD FS Scenarios for Developers
AD FS 2016 Requirements
AD FS Design
AD FS Design Guide
AD FS Design Guide in Windows Server 2012 R2
Identify Your AD FS Deployment Goals
Plan Your AD FS Deployment Topology
AD FS Requirements
AD FS Design Guide in Windows Server 2012
Identifying Your AD FS Deployment Goals
Mapping Your Deployment Goals to an AD FS Design
Determine Your AD FS Deployment Topology
Planning Your Deployment
Planning Federation Server Placement
Planning Federation Server Proxy Placement
Planning for AD FS Server Capacity
Appendix A: Reviewing AD FS Requirements
AD FS Deployment
AD FS Deployment Guide
Best Practices for Securing AD FS
Plan Device-based Conditional Access on-Premises
Required updates for AD FS and WAP
Set up Geographic Redundancy with SQL Server Replication
Set up the lab environment for AD FS in Windows Server 2012 R2
Upgrading to AD FS in Windows Server 2016 using a WID database
Deploy AD FS in Azure
AD FS in Azure with Azure Traffic Manager
Upgrading to AD FS in Windows Server 2016 using a SQL database
Deploy Azure AD Connect Health to Monitor your on-premises identity
infrastructure in the cloud
Windows Server 2016 and 2012 R2 AD FS Deployment Guide
Deploying a Federation Server Farm
Join a computer to a Domain
Enroll an SSL Certificate for AD FS
Install the AD FS Role Service
Configure a Federation Server
Configure a federation server with Device registration Service
Configure Corporate DNS for the Federation Service and DRS
Verify your Windows Server 2012 R2 Federation Server Is Operational
Deploying Federation Server Proxies
Azure Active Directory Connect
Windows Server 2012 AD FS Deployment Guide
Planning to Deploy AD FS
Implementing Your AD FS Design Plan
Checklist: Implementing a Web SSO Design
Checklist: Implementing a Federated Web SSO Design
Configure Partner Organizations
Checklist: Configure the Account Partner Organization
Checklist: Configure the Resource Partner Organization
Add an attribute Store
Create a Claims Provider Trust Using Federation Metadata
Create a Relying Party Trust Using Federation Metadata
Add a Claim Description
Configure Client computers to Trust the Account Federation Server
Distribute Certificates to Client computers by Using Group Policy
Configuring Claim Rules
Checklist: Creating Claim Rules for a Claims Provider Trust
Checklist: Creating Claim Rules for a Relying Party Trust
Create a Rule to Pass Through or filter an Incoming Claim
Create a Rule to Send an AD FS 1.x compatible Claim
Create a Rule to Permit All Users
Create a Rule to Permit or Deny Users Based on an Incoming Claim
Create a Rule to Send LDAP attributes as Claims
Create a Rule to Send Group Membership as a Claim
Create a Rule to Transform an Incoming Claim
Create a Rule to Send an Authentication Method Claim
Create a Rule to Send Claims Using a Custom Rule
Deploying Federation Servers
Checklist: Setting Up a Federation Server
Add a Host (A) Resource Record to Corporate DNS for a Federation Server
Manually Configure a Service Account for a Federation Server Farm
Install the Federation Service Role Service
Create the First Federation Server in a Federation Server Farm
Create a Stand-Alone Federation Server
Add a Federation Server to a Federation Server Farm
Add a Token-Signing Certificate
Add a Token-Decrypting Certificate
Set a Service Communications Certificate
Verify That a Federation Server Is Operational
Checklist: Setting Up a Federation Server Proxy
Join a computer to a Domain
Configure Name Resolution for a Federation Server Proxy in a DNS Zone That
Serves Only the Perimeter Network
Configure Name Resolution for a Federation Server Proxy in a DNS Zone That
Serves Both the Perimeter Network and Internet Clients
Export the Private Key Portion of a Server Authentication Certificate
Import a Server Authentication Certificate to the Default Web Site
Install the Federation Service Proxy Role Service
Configure a computer for the Federation Server Proxy Role
Verify That a Federation Server Proxy Is Operational
Configure Performance Monitoring
Interoperating with AD FS 1.x
Checklist: Configuring AD FS to Consume Claims from AD FS 1.x
Checklist: Configuring AD FS to Send Claims to an AD FS 1.x Federation
Service
Checklist: Configuring AD FS to Send Claims to an AD FS 1.x Claims-Aware
Web Agent
Create a Relying Party Trust Manually
Create a Claims Provider Trust Manually
Create a Rule to Send an AD FS 1.x compatible Claim
Deploy Azure AD Connect Health
Migrate Active Directory Federation Services Role Services to Windows Server
2012 R2
Prepare to Migrate the AD FS Federation Server
Migrate the AD FS Federation Server
Migrate the AD FS Federation Server Proxy
Verfiy the AD FS Migration to Windows Server 2012 R2
Migrate Active Directory Federation Services Role Services to Windows Server
2012
Prepare to Migrate the AD FS 2.0 Federation Server
Prepare to Migrate the AD FS 2.0 Stand Alone or Single Node Farm Server
Prepare to Migrate the AD FS 2.0 WID Farm
Prepare to Migrate the AD FS 2.0 SQL Farm
Prepare to Migrate the AD FS 2.0 Federation Server Proxy
Migrate the AD FS 2.0 Federation Server
Migrate the AD FS 2.0 Stand Alone or Single Node Farm Server
Migrate the AD FS 2.0 WID Farm
Migrate the AD FS 2.0 SQL Farm
Migrate the AD FS 2.0 Federation Server Proxy
Migrate the AD FS 1.1 Web Agents
AD FS Development
Custom Id Tokens in AD FS
AD FS On-behalf-of Authentication in Windows Server 2016
Enabling OpenId Connect with AD FS 2016
Enabling Oauth Confidential Clients with AD FS 2016
Single log-out for OpenID Connect with AD FS
Single Page Application with AD FS
Build a native client application using OAuth public clients with AD FS
AD FS Operations
AD FS Access Control Policies
Access Control Policies in AD FS for Windows Server 2016
Access Control Policies in AD FS for Windows Server 2012 R2
Access Control Policies in AD FS 2.0
Additional Authentication methods in AD FS 2019
AD FS Prompt login parameter support
AD FS Paginated sign-in
AD FS 2016 Single Sign On Settings
AD FS Rapid Restore Tool
AD FS support for alternate hostname binding for certificate authentication
AD FS user sign-in customization
Add an attribute Store
Compound authentication and AD DS claims in AD FS
Configure AD FS for user certificate authentication
Configure AD FS 2016 and Azure MFA
Configure AD FS Extranet Soft Lockout Protection
Configure AD FS Extranet Smart Lockout Protection
Configure AD FS Extranet Banned IPs
Configure AD FS to authenticate users stored in LDAP directories
Configure AD FS to Send Password Expiry Claims
Configure additional Authentication Methods for AD FS
Configure Authentication Policies
Configure Claim Rules
Configure Device-based Conditional Access on-Premises
Configure intranet forms-based authentication for devices that do not support
WIA
Configuring Alternate Login ID
Create a Claims Provider Trust
Create a Non-Claims Aware Relying Party Trust
Create a Relying Party Trust
Device Authentication Controls in AD FS
Improved interoperability with SAML 2.0
Join to Workplace from Any Device for SSO and Seamless Second Factor
Authentication Across company Applications
Manage Risk with additional Multi-Factor Authentication for Sensitive Applications
Manage Risk with Conditional Access Control
Managing SSL Certificates in AD FS and WAP 2016
Managing SSL Protocols in AD FS
Set up an AD FS lab environment
Walkthrough Guide: Manage Risk with additional Multi-Factor Authentication for
Sensitive Applications
Walkthrough Guide: Manage Risk with Conditional Access Control
Walkthrough: Workplace Join with a Windows Device
Walkthrough: Workplace Join with an iOS Device
Walkthrough: Workplace Join with an Android Device
AD FS Troubleshooting
AD FS Help Diagnostics Analyzer
Azure
Certificates
Claims syntax
DNS
Endpoints
Fiddler trace(WS-Fed)
Fiddler
Initiated SignOn
Integrated Windows Auth
Logging
Loops
SQL
AD FS Technical Reference
User privacy and AD FS
AD FS and certificate KeySpec property information
Auditing Enhancements to AD FS in Windows Server
Understanding Key AD FS Concepts
The Role of attribute Stores
The Role of the AD FS Configuration Database
The Role of Claims
The Role of Claim Rules
The Role of the Claims Engine
The Role of the Claims Pipeline
The Role of the Claim Rule Language
Determine the type of Claim Rule Template to Use
How URIs Are Used in AD FS
Device registration Technical Reference
AD FS Password Attack Protection
AD FS 2016 FAQ
Securing Privileged Access
Privileged Access Workstations
Securing Privileged Access Reference Material
Software Restriction Policies
Software Restriction Policies Technical Overview
Administer Software Restriction Policies
Determine Allow-Deny list and Application Inventory for Software Restriction
Policies
Work with Software Restriction Policies Rules
Use software restriction policies to help protect your computer against an email virus
Troubleshoot Software Restriction Policies
 T IP
Looking for information about older versions of Windows Server? Check out our other Windows Server libraries on
docs.microsoft.com. You can also search this site for specific information.
Access and Identity technologies enable secure Active Directory environments on-premises and in cloud-only and hybrid
deployments where some applications and services are hosted in the cloud and others are hosted on premises.
What's new?
Find out what's new in Active Directory Federation Services
Privileged Access Management for Active Directory Domain Services & AD DS

Privileged Access Management (PAM ) for Active Directory Domain Services (AD DS ) is a solution that is based on
Microsoft Identity Manager (MIM ) and Windows Server.
Windows 10 for the enterprise: Ways to use devices for work

Windows 10 provides you the ability to leverage Azure Active Directory. Windows 10 devices can be connected to Azure
AD, and users can sign in to Windows with Azure AD accounts or add their Azure ID to gain access to business apps and
resources.

Detailed documentation on all of the features available for AD DS in Windows Server.

Detailed documentation on all of the features available for AD FS in Windows Server.

Secure access to company resources from any location on any device
Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications
Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications
6/19/2017 • 2 minutes to read • Edit Online
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
With Microsoft's access and information protection solutions, you can deploy and configure access to corporate
resources across your on-premises environment and cloud applications. And you can do it while protecting
corporate information.
Access and Information Protection
GUIDE HOW CAN THIS GUIDE HELP YOU
Secure access to company resources from any location on any This guide shows how to allow employees to use personal and
device company devices to securely access corporate applications and
data.
Join to Workplace from Any Device for SSO and Seamless Employees can access applications and data everywhere, on
Second Factor Authentication Across Company Applications any device. Employees can use Single Sign-On in browser
applications or enterprise applications. Administrators can
control who has access to company resources that are based
on application, user, device, and location.
Manage Risk with Additional Multi-Factor Authentication for In this scenario, you enable MFA based on the user's group
Sensitive Applications membership data for a specific application. In other words, you
will set up an authentication policy on your federation server
to require MFA when users that belong to a certain group
request access to a specific application that is hosted on a web
server.
Manage Risk with Conditional Access Control Access control in AD FS is implemented with issuance
authorization claim rules that are used to issue a permit or
deny claims that will determine whether a user or a group of
users will be allowed to access AD FS-secured resources or not.
Authorization rules can only be set on relying party trusts.
In Windows Server 2012 , you can apply data governance across your file servers to control who can access
information and to audit who has accessed information. Dynamic Access Control lets you:
Identify data by using automatic and manual classification of files. For example, you could tag data in file
servers across the organization.
Control access to files by applying safety-net policies that use central access policies. For example, you could
define who can access health information within the organization.
Audit access to files by using central audit policies for compliance reporting and forensic analysis. For
example, you could identify who accessed highly sensitive information.
Apply Rights Management Services (RMS ) protection by using automatic RMS encryption for sensitive
Microsoft Office documents. For example, you could configure RMS to encrypt all documents that contain
Health Insurance Portability and Accountability Act (HIPAA) information.
The Dynamic Access Control feature set is based on infrastructure investments that can be used further by partners
and line-of-business applications, and the features can provide great value for organizations that use Active
Directory. This infrastructure includes:
A new authorization and audit engine for Windows that can process conditional expressions and central
policies.
Kerberos authentication support for user claims and device claims.
Improvements to the File Classification Infrastructure (FCI).
RMS extensibility support so partners can provide solutions that encrypt non-Microsoft files.
In this scenario
The following scenarios and guidance are included as part of this content set:
Dynamic Access Control Content Roadmap

SCENARIO EVALUATE PLAN DEPLOY OPERATE
Scenario: Central Dynamic Access Plan: A Central Access Deploy a Central - Modeling a central
Access Policy Control: Scenario Policy Deployment Access Policy access policy
Overview (Demonstration Steps)
Creating Central - Process to map a
access policies for files Deploy Claims Across business request to a Deploy Claims Across
allow organizations to Forests central access policy Forests
centrally deploy and - Delegating of (Demonstration Steps)
manage authorization administration for
policies that include Dynamic Access
conditional Control
expressions using - Exception
user claims, device Mechanisms for
claims, and resource Planning Central
properties. These Access Policies
polices are based on
compliance and Best Practices for
business regulatory Using User Claims
requirements. These
policies are created - Choosing the right
and hosted in Active configuration to
Directory, therefore enable claims in your
making it easier to user domain
manage and deploy. - Operations to
enable user claims
Deploying Claims - Considerations for
Across Forests using user claims in
the file server
In Windows Server discretionary ACLs
2012 , the AD DS without using Central
maintains a 'claims Access Policies
dictionary' in each
forest and all claim Using Device Claims
types in use within and Device Security
the forest are defined Groups
at the Active
Directory forest level. - Considerations for
There are many using static device
scenarios where a claims
principal may need to - Operations to
traverse a trust enable device claims
boundary. This
scenario describes Tools for Deployment
how a claim traverses
a trust boundary. - Data Classification
Toolkit
Scenario: File Scenario: File Access Plan for File Access Deploy Security - Monitor the Central
Access Auditing Auditing Auditing Auditing with Central Access Policies that
Audit Policies Apply on a File Server
Security auditing is (Demonstration Steps) - Monitor the Central
one of the most Access Policies
powerful tools to help Associated with Files
maintain the security and Folders
of an enterprise. One - Monitor the
of the key goals of Resource Attributes
security audits is on Files and Folders
regulatory - Monitor Claim Types
compliance. For - Monitor User and
example, industry Device Claims During
standards such as Sign-in
Sarbanes Oxley, - Monitor Central
HIPAA, and Payment Access Policy and Rule
Card Industry (PCI) Definitions
require enterprises to - Monitor Resource
follow a strict set of Attribute Definitions
rules related to data - Monitor the Use of
security and privacy. Removable Storage
Security audits help Devices.
establish the presence
or absence of such
policies; thereby, they
prove compliance or
noncompliance with
these standards.
Additionally, security
audits help detect
anomalous behavior,
identify and mitigate
gaps in security policy,
and deter
irresponsible behavior
by creating a record
of user activity that
can be used for
forensic analysis.
Scenario: Access- Scenario: Access- Plan for Access- Deploy Access-Denied

Denied Assistance Denied Assistance Denied Assistance Assistance
(Demonstration Steps)
Today, when users try - Determine the
to access a remote file access-denied
on the file server, the assistance model
only indication that - Determine who
they would get is that should handle access
access is denied. This requests
generates requests to - Customize the
helpdesk or IT access-denied
administrators that assistance message
need to figure out - Plan for exceptions
what the issue is and - Determine how
often the access-denied
administrators have a assistance is deployed
hard time getting the
appropriate context
from users which
makes it harder to
resolve the issue.
In Windows Server
2012 , the goal is to
try and help the
information worker
and business owner
of the data to deal
with the access
denied issue before IT
gets involved and
when IT gets involved,
provide all the right
information for a
quick resolution. One
of the challenges in
achieving this goal is
that there is no
central way to deal
with access denied
and every application
deals with it
differently and thus in
Windows Server 2012
, one of the goals is to
improve the access-
denied experience for
Windows Explorer.
Scenario: Scenario: Plan to deploy for Deploy Encryption of

Classification-Based Classification-Based classification-based Office Files
Encryption for Encryption for Office encryption of (Demonstration Steps)
Office Documents Documents documents
Protection of sensitive
information is mainly
about mitigating risk
for the organization.
Various compliance
regulations, such as
HIPAA or Payment
Card Industry Data
Security Standard
(PCI-DSS), dictate
encryption of
information, and
there are numerous
business reasons to
encrypt sensitive
business information.
However, encrypting
information is
expensive, and it
might impair business
productivity. Thus,
organizations tend to
have different
approaches and
priorities for
encrypting their
information.
To support this
scenario, Windows
Server 2012 provides
the ability to
automatically encrypt
sensitive Windows
Office files based on
their classification.
This is done through
file management
tasks that invoke
Active Directory
Rights Management
Server (AD RMS)
protection for
sensitive documents a
few seconds after the
file is identified as
being a sensitive file
on the file server.
Scenario: Get Scenario: Get Insight Plan for Automatic Deploy Automatic File
Insight into Your into Your Data by File Classification Classification
Data by Using Using Classification (Demonstration Steps)
Classification
Reliance on data and

storage resources has
continued to grow in
importance for most
organizations. IT
administrators face
the growing challenge
of overseeing larger
and more complex
storage
infrastructures while
simultaneously being
tasked with the
responsibility to
ensure total cost of
ownership is
maintained at
reasonable levels.
Managing storage
resources is not just
about the volume or
availability of data
anymore, but also
about the
enforcement of
company policies and
knowing how storage
is consumed to
enable efficient
utilization and
compliance to
mitigate risk. File
Classification
Infrastructure
provides insight into
your data by
automating
classification
processes so that you
can manage your
data more effectively.
The following
classification methods
are available with File
Classification
Infrastructure:
manual,
programmatically, and
automatic. This
scenario focuses on
the automatic file
classification method.
Scenario: Scenario: Implement Plan for Retention of Deploy Implementing

Implement Retention of Information on File Retention of
Retention of Information on File Servers Information on File
Information on File Servers Servers
Servers (Demonstration Steps)
A retention period is
the amount of time
that a document
should be kept before
it is expired.
Depending on the
organization, the
retention period can
be different. You can
classify files in a folder
as having a short,
medium, or long-term
retention period and
then assign the
timeframe for each
period. You may want
to keep a file
indefinitely by putting
it on legal hold.
File Classification
Infrastructure and File
Server Resource
Manager uses file
management tasks
and file classification
to apply retention
periods for a set of
files. You can assign a
retention period on a
folder and then use a
file management task
to configure how long
an assigned retention
period is to last.
When the files in the
folder are about to
expire, the owner of
the file gets a
notification email. You
can also classify a file
as being on legal hold
so that the file
management task will
not expire the file.
NOTE
Dynamic Access Control is not supported on ReFS (Resilient File System).
See also
CONTENT TYPE REFERENCES
Product evaluation - Dynamic Access Control Reviewers Guide

- Dynamic Access Control Developer Guidance
Planning - Planning a Central Access Policy Deployment

- Plan for File Access Auditing
Deployment - Active Directory Deployment

- File and Storage Services Deployment
Operations Dynamic Access Control PowerShell Reference
Tools and settings Data Classification Toolkit
Community resources Directory Services Forum

Scenario: Central Access Policy
Central access policies for files enable organizations to centrally deploy and manage authorization policies that
include conditional expressions that use user groups, user claims, device claims, and resource properties. (Claims
are assertions about the attributes of the object with which they are associated). For example, to access high-
business-impact (HBI) data, a user must be a full-time employee, obtain access from a managed device, and log on
with a smart card. These policies are defined and hosted in Active Directory Domain Services (AD DS ).
Organizational access policies are driven by compliance and business regulatory requirements. For example, if an
organization has a business requirement to restrict access to personally identifiable information (PII) in files to only
the file owner and members of the human resources (HR ) department who are allowed to view PII information,
this policy applies to PII files wherever they are located on file servers across the organization. In this example, you
need to be able to:
Identify and mark the files that contain PII.
Identify the group of HR members who are allowed to view PII information.
Create a central access policy that applies to all files that contain PII wherever they are located on file servers
across the organization.
The initiative to deploy and enforce an authorization policy can come for many reasons and apply to multiple levels
of the organization. The following are some example policy types:
Organization-wide authorization policy. Most commonly initiated from the information security office,
this authorization policy is driven by compliance or a high-level organization requirements, and it is relevant
across the organization. For example, HBI files are accessible to only full-time employees.
Departmental authorization policy. Each department in an organization has some special data-handling
requirements that they want to enforce. For example, the finance department might want to limit access to
finance servers to the finance employees.
Specific data-management policy. This policy usually relates to compliance and business requirements,
and it is targeted at protecting the correct access to the information that is being managed. For example,
financial institutions might implement information walls so that analysts do not access brokerage
information and brokers do not access analysis information.
Need-to-know policy. This authorization policy type is typically used in conjunction with the previous
policy types. For example, vendors should be able to access and edit only files that pertain to a project they
are working on.
Real-life environments also teach us that every authorization policy needs to have exceptions so that organizations
can quickly react when important business needs arise. For example, executives who cannot find their smart cards
and need quick access to HBI information can call the Help Desk to get a temporary exception to access that
information.
Central access policies act as security umbrellas that an organization applies across its servers. These policies
enhance (but do not replace) the local access policies or discretionary access control lists (DACL ) that are applied to
files and folders. For example, if a DACL on a file allows access to a specific user, but a central policy that is applied
to the file restricts access to the same user, the user cannot obtain access to the file. If the central access policy
allows access, but the DACL does not allow access, the user cannot obtain access to the file.
A central access policy rule has the following logical parts:
Applicability. A condition that defines which data the policy applies to, such as
Resource.BusinessImpact=High.
Access conditions. A list of one or more access control entries (ACEs) that define who can access the data,
such as Allow | Full Control | User.EmployeeType=FTE.
Exceptions. An additional list of one or more ACEs that define an exception for the policy, such as
MemberOf(HBIExceptionGroup).
The following two figures show the workflow in central access and audit policies.
Figure 1 Central access and audit policy concepts
Figure 2 Central access policy workflow

The central authorization policy combines the following components:
A list of centrally defined access rules that target specific types of information, such as HBI or PII.
A centrally defined policy that contains a list of rules.
A policy identifier that is assigned to each file on the file servers to point to a specific central access policy
that should be applied during the access authorization.
The following figure demonstrates how you can combine policies into policy lists to centrally control access to files.
Figure 3 Combining policies
In this scenario
The following guidance is available to you for central access policies:
Plan a Central Access Policy deployment
Roles and features included in this scenario

The following table lists the roles and features that are part of this scenario and describes how they support it.
ROLE/FEATURE HOW IT SUPPORTS THIS SCENARIO
Active Directory Domain Services role AD DS in Windows Server 2012 introduces a claims-based
authorization platform that enables the creation of user claims
and device claims, compound identity, (user plus device claims),
new central access policy (CAP) models, and the use of file-
classification information in authorization decisions.
File and Storage Services Server role File and Storage Services provides technologies that help you
set up and manage one or more file servers that provide
central locations on your network where you can store files
and share them with users. If your network users need access
to the same files and applications, or if centralized backup and
file management are important to your organization, you
should set up one or more computers as a file server by
adding the File and Storage Services role and the appropriate
role services to the computers.
Windows client computer Users can access files and folders on the network through the
client computer.
In this scenario, the finance department security operations is working with central information security to specify
the need for a central access policy so that they can protect archived finance information stored on file servers. The
archived finance information from each country can be accessed as read-only by finance employees from the same
country. A central finance admin group can access the finance information from all countries.
Deploying a central access policy includes the following phases:
PHASE DESCRIPTION
Plan: Identify the need for policy and the configuration Identify the need for a policy and the configuration required
required for deployment for deployment.
Implement: Configure the components and policy Configure the components and policy.
Deploy the central access policy Deploy the policy.
Maintain: Change and stage the policy Policy changes and staging.
Set up a test environment

Before you begin, you need to set up lab to test this scenario. The steps for setting up the lab are explained in detail
in Appendix B: Setting Up the Test Environment.
Plan: Identify the need for policy and the configuration required for
deployment
This section provides the high-level series of steps that aid in the planning phase of your deployment.
STEP EXAMPLE
1.1 Business determines that a central To protect finance information that is

access policy is needed stored on file servers, the finance
department security operations is
working with central information
security to specify the need for a central
access policy.
1.2 Express the access policy Finance documents should only be read
by members of the Finance department.
Members of the Finance department
should only access documents in their
own country. Only Finance
Administrators should have write-
access. An exception will be allowed for
members of the FinanceException
group. This group will have Read access.
STEP EXAMPLE
1.3 Express the access policy in Windows Targeting:

Server 2012 constructs
- Resource.Department Contains
Finance
Access rules:
- Allow read
User.Country=Resource.Country AND
User.department =
Resource.Department
- Allow Full control
User.MemberOf(FinanceAdmin)
Exception:
Allow read memberOf(FinanceException)
1.4 Determine the file properties required Tag files with:

for the policy
- Department
- Country
1.5 Determine the claim types and groups Claim types:

required for the policy
- Country
- Department
User groups:
- FinanceAdmin
- FinanceException
1.6 Determine the servers on which to Apply the policy on all finance file
apply this policy servers.
Implement: Configure the components and policy

This section presents an example that deploys a central access policy for finance documents.
NO STEP EXAMPLE
2.1 Create claim types Create the following claim types:
- Department
- Country
2.2 Create resource properties Create and enable the following

resource properties:
- Department
- Country
2.3 Configure a central access rule Create a Finance Documents rule that
includes the policy determined in the
previous section.
NO STEP EXAMPLE
2.4 Configure a central access policy (CAP) Create a CAP called Finance Policy and
add the Finance Documents rule to that
CAP.
2.5 Target central access policy to the file Publish the Finance Policy CAP to the
servers file servers.
2.6 Enable KDC Support for claims, Enable KDC Support for claims,
compound authentication and Kerberos compound authentication and Kerberos
armoring. armoring for contoso.com.
In the following procedure, you create two claim types: Country and Department.
To create claim types
1. Open Server DC1 in Hyper-V Manager and log on as contoso\administrator, with the password
pass@word1.
2. Open Active Directory Administrative Center.
3. Click the Tree View icon, expand Dynamic Access Control, and then select Claim Types.
Right-click Claim Types, click New, and then click Claim Type.
TIP
You can also open a Create Claim Type: window from the Tasks pane. On the Tasks pane, click New, and then click
Claim Type.
4. In the Source Attribute list, scroll down the list of attributes, and click department. This should populate
the Display name field with department. Click OK.
5. In Tasks pane, click New, and then click Claim Type.
6. In the Source Attribute list, scroll down the list of attributes, and then click the c attribute (Country-Name).
In the Display name field, type country.
7. In the Suggested Values section, select The following values are suggested:, and then click Add.
8. In the Value and Display name fields, type US, and then click OK.
9. Repeat the above step. In the Add a suggest value dialog box, type JP in the Value and Display name
fields, and then click OK.
*Windows PowerShell equivalent commands*

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure.
Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because
of formatting constraints.
New-ADClaimType country -SourceAttribute c -SuggestedValues:@((New-Object

Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry("US","US","")), (New-Object
Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry("JP","JP","")))
New-ADClaimType department -SourceAttribute department
TIP
You can use the Windows PowerShell History Viewer in Active Directory Administrative Center to look up the Windows
PowerShell cmdlets for each procedure you perform in Active Directory Administrative Center. For more information, see
Windows PowerShell History Viewer
The next step is to create resource properties. In the following procedure you create a resource property that is
automatically added to the Global Resource Properties list on the domain controller, so that it is available to the file
server.
To create and enable pre-created resource properties
1. In the left pane of Active Directory Administrative Center, click Tree View. Expand Dynamic Access
Control, and then select Resource Properties.
2. Right-click Resource Properties, click New, and then click Reference Resource Property.
TIP
You can also choose a resource property from the Tasks pane. Click New and then click Reference Resource
Property.
3. In Select a claim type to share its suggested values list, click country.
4. In the Display name field, type country, and then click OK.
5. Double-click the Resource Properties list, scroll down to the Department resource property. Right-click,
and then click Enable. This will enable the built-in Department resource property.
6. In the Resource Properties list on the navigation pane of the Active Directory Administrative Center, you
will now have two enabled resource properties:
Country
Department

New-ADResourceProperty Country -IsSecured $true -ResourcePropertyValueType MS-DS-MultivaluedChoice -

SharesValuesWith country
Set-ADResourceProperty Department_MS -Enabled $true
Add-ADResourcePropertyListMember "Global Resource Property List" -Members Country
Add-ADResourcePropertyListMember "Global Resource Property List" -Members Department_MS
The next step is to create central access rules that define who can access resources. In this scenario the business
rules are:
Finance documents can be read only by members of the Finance department.
Members of the Finance department can access only documents in their own country.
Only Finance Administrators can have Write access.
We will allow an exception for members of the FinanceException group. This group will have Read access.
The administrator and document owner will still have full access.
Or to express the rules with Windows Server 2012 constructs:
Targeting: Resource.Department Contains Finance
Access Rules:
Allow Read User.Country=Resource.Country AND User.department = Resource.Department
Allow Full control User.MemberOf(FinanceAdmin)
Allow Read User.MemberOf(FinanceException)
To create a central access rule
1. In the left pane of the Active Directory Administrative Center, click Tree View, select Dynamic Access
Control, and then click Central Access Rules.
2. Right-click Central Access Rules, click New, and then click Central Access Rule.
3. In the Name field, type Finance Documents Rule.
4. In the Target Resources section, click Edit, and in the Central Access Rule dialog box, click Add a
condition. Add the following condition:
[Resource] [Department] [Equals] [Value] [Finance], and then click OK.
5. In the Permissions section, select Use following permissions as current permissions, click Edit, and in
the Advanced Security Settings for Permissions dialog box click Add.
NOTE
Use the following permissions as proposed permissions option lets you create the policy in staging. For more
information on how to do this refer to the Maintain: Change and stage the policy section in this topic.
6. In the Permission entry for Permissions dialog box, click Select a principal, type Authenticated Users,
and then click OK.
7. In the Permission Entry for Permissions dialog box, click Add a condition, and add the following
conditions:
[User] [country] [Any of] [Resource] [country]
Click Add a condition.
[And]
Click [User] [Department] [Any of] [Resource] [Department]. Set the Permissions to Read.
8. Click OK, and then click Add. Click Select a principal, type FinanceAdmin, and then click OK.
9. Select the Modify, Read and Execute, Read, Write permissions, and then click OK.
10. Click Add, click Select a principal, type FinanceException, and then click OK. Select the permissions to
be Read and Read and Execute.
11. Click OK three times to finish and return to Active Directory Administrative Center.
The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding
procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several
lines here because of formatting constraints.
$countryClaimType = Get-ADClaimType country
$departmentClaimType = Get-ADClaimType department
$countryResourceProperty = Get-ADResourceProperty Country
$departmentResourceProperty = Get-ADResourceProperty Department
$currentAcl = "O:SYG:SYD:AR(A;;FA;;;OW)(A;;FA;;;BA)(A;;0x1200a9;;;S-1-5-21-1787166779-1215870801-2157059049-
1113)(A;;0x1301bf;;;S-1-5-21-1787166779-1215870801-2157059049-1112)(A;;FA;;;SY)(XA;;0x1200a9;;;AU;((@USER." +
$countryClaimType.Name + " Any_of @RESOURCE." + $countryResourceProperty.Name + ") && (@USER." +
$departmentClaimType.Name + " Any_of @RESOURCE." + $departmentResourceProperty.Name + ")))"
$resourceCondition = "(@RESOURCE." + $departmentResourceProperty.Name + " Contains {`"Finance`"})"
New-ADCentralAccessRule "Finance Documents Rule" -CurrentAcl $currentAcl -ResourceCondition $resourceCondition
IMPORTANT
In the above cmdlet example, the security identifiers (SIDs) for the group FinanceAdmin and users is determined at creation
time and will be different in your example. For example, the provided SID value (S-1-5-21-1787166779-1215870801-
2157059049-1113) for the FinanceAdmins needs to be replaced with the actual SID for the FinanceAdmin group that you
would need to create in your deployment. You can use Windows PowerShell to look up the SID value of this group, assign
that value to a variable, and then use the variable here. For more information, see Windows PowerShell Tip: Working with
SIDs.
You should now have a central access rule that allows people to access documents from the same country and the
same department. The rule allows the FinanceAdmin group to edit the documents, and it allows the
FinanceException group to read the documents. This rule targets only documents classified as Finance.
To add a central access rule to a central access policy
1. In the left pane of the Active Directory Administrative Center, click Dynamic Access Control, and then click
Central Access Policies.
2. In the Tasks pane, click New, and then click Central Access Policy.
3. In Create Central Access Policy:, type Finance Policy in the Name box.
4. In Member central access rules, click Add.
5. Double-click the Finance Documents Rule to the add it to the Add the following central access rules
list , and then click OK.
6. Click OK to finish. You should now have a central access policy named Finance Policy.
New-ADCentralAccessPolicy "Finance Policy" Add-ADCentralAccessPolicyMember

-Identity "Finance Policy"
-Member "Finance Documents Rule"
To apply the central access policy across file servers by using Group Policy
1. On the Start screen, in the Search box, type Group Policy Management. Double-click Group Policy
Management.
TIP
If the Show Administrative tools setting is disabled, the Administrative Tools folder and its contents will not
appear in the Settings results.
TIP
In your production environment, you should create a File Server Organization Unit (OU) and add all your file servers
to this OU, to which you want to apply this policy. You can then create a group policy and add this OU to that policy..
2. In this step, you edit the group policy object you created in Build the domain controller section in the Test
Environment to include the central access policy that you created. In the Group Policy Management Editor,
navigate to and select the organizational unit in the domain (contoso.com in this example): Group Policy
Management, Forest: contoso.com, Domains, contoso.com, Contoso, FileServerOU.
3. Right-click FlexibleAccessGPO, and then click Edit.
4. In the Group Policy Management Editor window, navigate to Computer Configuration, expand Policies,
expand Windows Settings, and click Security Settings.
5. Expand File System, right-click Central Access Policy, and then click Manage Central access policies.
6. In the Central Access Policies Configuration dialog box, add Finance Policy, and then click OK.
7. Scroll down to Advanced Audit Policy Configuration, and expand it.
8. Expand Audit Policies, and select Object Access.
9. Double-click Audit Central Access Policy Staging. Select all three check boxes and then click OK. This
step allows the system to receive audit events related to Central Access Staging Policies.
10. Double-click Audit File System Properties. Select all three check boxes then click OK.
11. Close the Group Policy Management Editor. You have now included the central access policy to the Group
Policy.
For a domain's domain controllers to provide claims or device authorization data, the domain controllers need to be
configured to support dynamic access control.
To enable support for claims and compound authentication for contoso.com
1. Open Group Policy Management, click contoso.com, and then click Domain Controllers.
2. Right-click Default Domain Controllers Policy, and then click Edit.
3. In the Group Policy Management Editor window, double-click Computer Configuration, double-click
Policies, double-click Administrative Templates, double-click System, and then double-click KDC.
4. Double-click KDC Support for claims, compound authentication and Kerberos armoring. In the KDC
Support for claims, compound authentication and Kerberos armoring dialog box, click Enabled and
select Supported from the Options drop-down list. (You need to enable this setting to use user claims in
central access policies.)
5. Close Group Policy Management.
6. Open a command prompt and type gpupdate /force .
Deploy the central access policy

STEP EXAMPLE
3.1 Assign the CAP to the appropriate Assign the central access policy to the
shared folders on the file server. appropriate shared folder on the file
server.
3.2 Verify that access is appropriately Check the access for users from
configured. different countries and departments.
In this step you will assign the central access policy to a file server. You will log onto a file server that is receiving
the central access policy that you created the previous steps and assign the policy to a shared folder.
To assign a central access policy to a file server
1. In Hyper-V Manager, connect to server FILE1. Log on to the server by using contoso\administrator with the
password: pass@word1.
2. Open an elevated command prompt and type: gpupdate /force. This ensures that your Group Policy
changes take effect on your server.
3. You also need to refresh the Global Resource Properties from Active Directory. Open an elevated Windows
PowerShell window and type Update-FSRMClassificationpropertyDefinition . Click ENTER, and then close
Windows PowerShell.
TIP
You can also refresh the Global Resource Properties by logging on to the file server. To refresh the Global Resource
Properties from the file server, do the following
1. Logon to File Server FILE1 as contoso\administrator, using the password pass@word1.
2. Open File Server Resource Manager. To open File Server Resource Manager, click Start, type file server resource
manager, and then click File Server Resource Manager.
3. In the File Server Resource Manager, click File Classification Management , right-click Classification Properties
and then click Refresh.
4. Open Windows Explorer, and in the left pane, click drive D. Right-click the Finance Documents folder, and
click Properties.
5. Click the Classification tab, click Country, and then select US in the Value field.
6. Click Department, then select Finance in the Value field and then click Apply.
NOTE
Remember that the central access policy was configured to target files for the Department of Finance. The previous
steps mark all documents in the folder with the Country and Department attributes.
7. Click the Security tab, and then click Advanced. Click the Central Policy tab.
8. Click Change, select Finance Policy from the drop-down menu, and then click Apply. You can see the
Finance Documents Rule listed in the policy. Expand the item to view all of the permissions that you set
when you created the rule in Active Directory.
9. Click OK to return to Windows Explorer.
In the next step, you ensure that access is appropriately configured. User accounts need to have the appropriate
Department attribute set (set this using Active Directory Administrative Center). The simplest way to view the
effective results of the new policy is to use the Effective Access tab in Windows Explorer. The Effective Access
tab shows the access rights for a given user account.
To examine the access for various users
1. In Hyper-V Manager, connect to server FILE1. Log on to the server by using contoso\administrator.
Navigate to D:\ in Windows Explorer. Right-click the Finance Documents folder, and then click Properties.
2. Click the Security tab, click Advanced, and then click the Effective Access tab.
3. To examine the permissions for a user, click Select a user, type the user's name, and then click View
effective access to see the effective access rights. For example:
Myriam Delesalle (MDelesalle) is in the Finance department and should have Read access to the
folder.
Miles Reid (MReid) is a member of the FinanceAdmin group and should have Modify access to the
folder.
Esther Valle (EValle) is not in the Finance department; however, she is a member of the
FinanceException group and should have Read access.
Maira Wenzel (MWenzel) is not in the Finance department and is not a member of either the
FinanceAdmin or FinanceException group. She should not have any access to the folder.
Notice that the last column named Access limited by in the effective access window. This column tells you
which gates are effecting the person's permissions. In this case, the Share and NTFS permissions allow all
users full control. However, the central access policy restricts access based on the rules you configured
earlier.
Maintain: Change and stage the policy
Number Step Example
4.1 Configure Device Claims for Clients Set the group policy setting to enable
device claims
4.2 Enable a claim for devices. Enable the country claim type for
devices.
4.3 Add a staging policy to the existing Modify the Finance Documents Rule to
central access rule that you would like add a staging policy.
to modify.
4.4 View the results of the staging policy. Check for Ester Velle's permissions.
To set up group policy setting to enable claims for devices

1. Log on to DC1, open Group Policy Management, click contoso.com, click Default Domain Policy, right-
click and select Edit.
2. In the Group Policy Management Editor window, navigate to Computer Configuration, Policies,
Administrative Templates, System, Kerberos.
3. Select Kerberos client support for claims, compound authentication and Kerberos armoring and
click Enable.
To enable a claim for devices
1. Open Server DC1 in Hyper-V Manager and log on as contoso\Administrator, with the password
pass@word1.
2. From the Tools menu, open Active Directory Administrative Center.
3. Click Tree View, expand Dynamic Access Control, double-click Claim Types, and double-click the
country claim.
4. In Claims of this type can be issued for the following classes, select the Computer check box. Click OK.
Both the User and Computer check boxes should now be selected. The country claim can now be used with
devices in addition to users.
The next step is to create a staging policy rule. Staging policies can be used to monitor the effects of a new policy
entry before you enable it. In the following step, you will create a staging policy entry and monitor the effect on
your shared folder.
To create a staging policy rule and add it to the central access policy
1. Open Server DC1 in Hyper-V Manager and log on as contoso\Administrator, with the password
pass@word1.
2. Open Active Directory Administrative Center.
3. Click Tree View, expand Dynamic Access Control, and select Central Access Rules.
4. Right-click Finance Documents Rule, and then click Properties.
5. In the Proposed Permissions section, select the Enable permission staging configuration check box,
click Edit, and then click Add. In the Permission Entry for Proposed Permissions window, click the
Select a Principal link, type Authenticated Users, and then click OK.
6. Click the Add a condition link and add the following condition:
[User] [country] [Any of] [Resource] [Country].
7. Click Add a condition again, and add the following condition:
[And]
[Device] [country] [Any of] [Resource] [Country]
8. Click Add a condition again, and add the following condition.
[And]
[User] [Group] [Member of any] [Value](FinanceException)
9. To set the FinanceException, group, click Add items and in the Select User, Computer, Service Account,
or Group window, type FinanceException.
10. Click Permissions, select Full Control, and click OK.
11. In the Advance Security Settings for Proposed Permissions window, select FinanceException and click
Remove.
12. Click OK two times to finish.

Set-ADCentralAccessRule
-Identity:
"CN=FinanceDocumentsRule,CN=CentralAccessRules,CN=ClaimsConfiguration,CN=Configuration,DC=Contoso.com"
-ProposedAcl: "O:SYG:SYD:AR(A;;FA;;;BA)(A;;FA;;;SY)(A;;0x1301bf;;;S-1-21=1426421603-1057776020-1604)"
-Server: "WIN-2R92NN8VKFP.Contoso.com"
NOTE
In the above cmdlet example, the Server value reflects the Server in the test lab environment. You can use the Windows
PowerShell History Viewer to look up the Windows PowerShell cmdlets for each procedure you perform in Active Directory
Administrative Center. For more information, see Windows PowerShell History Viewer
In this proposed permissions set, members of the FinanceException group will have Full Access to files from their
own country when they access them through a device from the same country as the document. Audit entries are
available in the File Servers security log when someone from the Finance department attempts to access files.
However, security settings are not enforced until the policy is promoted from staging.
In the next procedure, you verify the results of the staging policy. You access the shared folder with a user name
that has permissions based on the current rule. Esther Valle (EValle) is a member of FinanceException, and she
currently has Read rights. According to our staging policy, EValle should not have any rights.
To verify the results of the staging policy
1. Connect to the File Server FILE1 in Hyper-V Manager and log on as contoso\administrator, with the
password pass@word1.
2. Open a Command Prompt window and type gpupdate /force. This ensures that your Group Policy
changes will take effect on your server.
3. In Hyper-V Manager, connect to server CLIENT1. Log off the user who is currently logged on. Restart the
virtual machine, CLIENT1. Then log on to the computer by using contoso\EValle pass@word1.
4. Double-click the desktop shortcut to \\FILE1\Finance Documents. EValle should still have access to the files.
Switch back to FILE1.
5. Open Event Viewer from the shortcut on the desktop. Expand Windows Logs, and then select Security.
Open the entries with Event ID 4818under the Central Access Policy Staging task category. You will see
that EValle was allowed access; however, according to the staging policy, the user would have been denied
access.
Next Steps
If you have a central server management system such as System Center Operations Manager, you can also
configuring monitoring for events. This allows Administrators to monitor the effects of central access policies
before enforcing them.
Security Auditing is one of the most powerful tools to help maintain the security of an enterprise. One of the key
goals of security audits is regulatory compliance. Industry standards such as Sarbanes Oxley, Health Insurance
Portability and Accountability Act (HIPAA), and Payment Card Industry (PCI) require enterprises to follow a strict
set of rules related to data security and privacy. Security audits help establish the presence of such policies and
prove compliance with these standards. Additionally, security audits help detect anomalous behavior, identify and
mitigate gaps in security policies, and deter irresponsible behavior by creating a trail of user activity that can be
used for forensic analysis.
Audit policy requirements are typically driven at the following levels:
Information security. File access audit trails are often used for forensic analysis and intrusion detection.
Being able to get targeted events about access to high-value information lets organizations considerably
improve their response time and investigation accuracy.
Organizational policy. For example, organizations regulated by PCI standards could have a central policy
to monitor access to all files that are marked as containing credit card information and personally identifiable
information (PII).
Departmental policy. For example, the finance department may require that the ability to modify certain
finance documents (such as a quarterly earnings report) be restricted to the finance department, and thus
the department would want to monitor all other attempts to change these documents.
Business policy. For example, business owners may want to monitor all unauthorized attempts to view data
that belongs to their projects.
Additionally, the compliance department may want to monitor all changes to central authorization policies and
policy constructs such as user, computer, and resource attributes.
One of the biggest considerations of security audits is the cost of collecting, storing, and analyzing audit events. If
the audit policies are too broad, the volume of audit events collected rises, and this increases costs. If the audit
policies are too narrow, you risk missing important events.
With Windows Server 2012 , you can author audit policies by using claims and resource properties. This leads to
richer, more targeted, and easier-to-manage audit policies. It enables scenarios that, until now, were impossible or
too difficult to perform. The following are examples of audit policies that administrators can author:
Audit everyone who does not have a high-security clearance and tries to access an HBI document. For
example, Audit | Everyone | All-Access | Resource.BusinessImpact=HBI AND User.SecurityClearance!=High.
Audit all vendors when they try to access documents that are related to projects that they are not working
on. For example, Audit | Everyone | All-Access | User.EmploymentStatus=Vendor AND User.Project
Not_AnyOf Resource.Project.
These policies help regulate the volume of audit events and limit them to only the most relevant data or users.
After administrators have created and applied the audit policies, the next consideration for them is gleaning
meaningful information from the audit events that they collected. Expression-based audit events help reduce the
volume of audits. However, users need a way to query these events for meaningful information and ask questions
such as, "Who is accessing my HBI data?" or "Was there an unauthorized attempt to access sensitive data?"
Windows Server 2012 enhances existing data access events with user, computer, and resource claims. These events
are generated on a per-server basis. To provide a full view of events across the organization, Microsoft is working
with partners to provide event collection and analysis tools, such as the Audit Collection Services in System Center
Operation Manager .
Figure 4 shows an overview of a central audit policy.
Figure 4 Central auditing experiences

Setting up and consuming security audits typically involves the following general steps:
1. Identify the correct set of data and users to monitor
2. Create and apply appropriate audit policies
3. Collect and analyze audit events
4. Manage and monitor the policies that were created
In this scenario
The following topics provide additional guidance for this scenario:
Deploy Security Auditing with Central Audit Policies (Demonstration Steps)

Active Directory Doman Services role AD DS in Windows Server 2012 introduces a claims-based
authorization platform that enables creating user claims and
device claims, compound identity, (user plus device claims),
new central access policies (CAP) model, and the use of file
classification information in authorization decisions.
File and Storage Services role File servers in Windows Server 2012 provide a user interface
where administrators can view the effective permissions for
users for a file or folder and troubleshoot access issues and
grant access as required.
The information in this topic explains the security auditing enhancements that are introduced in Windows Server
2012 and new audit settings that you should consider as you deploy Dynamic Access Control in your enterprise.
The actual audit policy settings that you deploy will depend on your goals, which can include regulatory
compliance, monitoring, forensic analysis, and troubleshooting.
NOTE
Detailed information about how to plan and deploy an overall security auditing strategy for your enterprise is explained in
Planning and Deploying Advanced Security Audit Policies. For more information about configuring and deploying a security
audit policy, see the Advanced Security Audit Policy Step-by-Step Guide.
The following security auditing capabilities in Windows Server 2012 can be used with Dynamic Access Control to
extend your overall security auditing strategy.
Expression-based audit policies. Dynamic Access Control enables you to create targeted audit policies by
using expressions based on user, computer, and resource claims. For example, you could create an audit
policy to track all Read and Write operations on files classified as high-business impact by employees who
do not have a high-security clearance. Expression-based audit policies can be authored directly for a file or
folder or centrally through Group Policy. For more information, see Group Policy using Global Object Access
Auditing.
Additional information from object access auditing. File access auditing is not new to Windows Server
2012 . With the right audit policy in place, the Windows and Windows Server operating systems generate an
audit event each time a user accesses a file. Existing File Access events (4656, 4663) contain information
about the attributes of the file that was accessed. This information can be used by event log filtering tools to
help you identify the most relevant audit events. For more information, see Audit Handle Manipulation and
Audit Security Accounts Manager.
More information from user logon events. With the right audit policy in place, Windows operating
systems generate an audit event every time a user signs in to a computer locally or remotely. In Windows
Server 2012 or Windows 8, you can also monitor user and device claims associated with a user's security
token. Examples can include Department, Company, Project, and Security clearances.Event 4626 contains
information about these user claims and device claims, which can be leveraged by audit log management
tools to correlate user logon events with object access events to enable event filtering based on file attributes
and user attributes. For more information about user logon auditing, see Audit Logon.
Change tracking for new types of securable objects. Tracking changes to securable objects can be
important in the following scenarios:
Change tracking for central access policies and central access rules. Central access policies and
central access rules define the central policy that can be used to control access to critical resources.
Any change to these can directly impact the file access permissions that are granted to users on
multiple computers. Therefore, tracking changes to central access policies and central access rules can
be important for your organization. Because central access policies and central access rules are stored
in Active Directory Domain Services (AD DS ), you can audit attempts to modify them, like auditing
changes to any other securable object in AD DS. For more information, see Audit Directory Service
Access.
Change tracking for definitions in the claim dictionary. Claim definitions include the claim
name, description, and possible values. Any change to the claim definition can impact the access
permissions on critical resources. Therefore, tracking changes to claim definitions can be important to
your organization. Like central access policies and central access rules, claim definitions are stored in
AD DS; therefore, they can be audited like any another securable object in AD DS. For more
information, see Audit Directory Service Access.
Change tracking for file attributes. File attributes determine which central access rule applies to
the file. A change to the file attributes can potentially impact the access restrictions on the file.
Therefore, it can be important to track changes to file attributes. You can track changes to file
attributes on any computer by configuring the authorization policy change auditing policy. For more
information, see Authorization Policy Change auditing and Object Access auditing for File Systems. In
Windows Server 2012 , Event 4911 differentiates file attribute policy changes from other
authorization policy change events.
Chang tracking for the central access policy associated with a file. Event 4913 displays the
security identifiers (SIDs) of the old and new central access policies. Each central access policy also
has a user friendly name that can be looked up using this security identifier. For more information, see
Authorization Policy Change auditing.
Change tracking for user and computer attributes. Like files, user and computer objects can have
attributes, and changes to these attributes can impact the user's ability to access files. Therefore, it can
be valuable to track changes to user or computer attributes. User and computer objects are stored in
AD DS; therefore, changes to their attributes can be audited. For more information, see DS Access.
Policy change staging. Changes to central access policies can impact the access control decisions on all
computers where the policies are enforced. A loose policy could grant more access than desired, and an
overly restrictive policy could generate an excessive number of Help Desk calls. As a result, it can be
extremely valuable to verify changes to a central access policy before enforcing the change. For that purpose,
Windows Server 2012 introduces the concept of "staging." Staging enables users to verify their proposed
policy changes before enforcing them. To use policy staging, proposed policies are deployed with the
enforced policies, but staged policies do not actually grant or deny permissions. Instead, Windows Server
2012 logs an audit event (4818) any time the result of the access check that uses the staged policy is
different from the result of an access check that uses the enforced policy.
Deploy Security Auditing with Central Audit Policies
(Demonstration Steps)
In this scenario, you will audit access to files in the Finance Documents folder by using the Finance Policy that you
created in Deploy a Central Access Policy (Demonstration Steps). If a user who is not authorized to access the
folder attempts to access it, the activity is captured in the event viewer.
The following steps are required to test this scenario.
TASK DESCRIPTION
Configure Global Object Access In this step, you configure the global object access policy on
the domain controller.
Update Group Policy Settings Sign in to the file server and apply the Group Policy update.
Verify that the global object access policy has been applied View the relevant events in the event viewer. The events
should include metadata for the country and document type.
Configure global object access policy

In this step, you configure the global object access policy in the domain controller.
To configure a global object access policy
1. Sign in to the domain controller DC1 as contoso\administrator with the password pass@word1.
2. In Server Manager, point to Tools, and then click Group Policy Management.
3. In the console tree, double-click Domains, double-click contoso.com, click Contoso, and then double-click
File Servers.
4. Right-click FlexibleAccessGPO, and click Edit.
5. Double-click Computer Configuration, double-click Policies, and then double-click Windows Settings.
6. Double-click Security Settings, double-click Advanced Audit Policy Configuration, and then double-
click Audit Policies.
7. Double-click Object Access, and then double-click Audit File System.
8. Select the Configure the following events check box, select the Success and Failure check boxes, and
then click OK.
9. In the navigation pane, double-click Global Object Access Auditing, and then double-click File system.
10. Select the Define this policy setting check box, and click Configure.
11. In the Advanced Security Settings for Global File SACL box, click Add, then click Select a principal,
type Everyone, and then click OK.
12. In the Auditing Entry for Global File SACL box, select Full control in the Permissions box.
13. In the Add a condition: section, click Add a condition and in the drop-down lists select
[Resource] [Department] [Any of] [Value] [Finance].
14. Click OK three times to complete the configuration of the global object access audit policy setting.
15. In the navigation pane, click Object Access, and in the results pane, double-click Audit Handle
Manipulation. Click Configure the following audit events, Success, and Failure, click OK, and then
close the flexible access GPO.
Update Group Policy settings

In this step, you update the Group Policy settings after you have created the audit policy.
To update Group Policy settings
1. Sign in to the file server, FILE1 as contoso\Administrator, with the password pass@word1.
2. 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.
3. Type gpupdate /force and then press ENTER.
Verify that the global object access policy has been applied
After the Group Policy settings have been applied, you can verify that the audit policy settings were applied
correctly.
To verify that the global object access policy has been applied
1. Sign in to client computer, CLIENT1 as Contoso\MReid. Browse to the folder HYPERLINK
"file:///\\\\ID_AD_FILE1\\Finance" \\ FILE1\Finance Documents, and modify Word Document 2.
2. Sign in to the file server, FILE1 as contoso\administrator. Open Event Viewer, browse to Windows Logs,
select Security, and confirm that your activities resulted in audit events 4656 and 4663 (even though you
did not set explicit auditing SACLs on the files or folders that you created, modified, and deleted).
IMPORTANT
A new logon event is generated on the computer where the resource is located, on behalf of the user for whom effective
access is being checked. When analyzing security audit logs for user sign-in activity, to differentiate between logon events that
are generated because of effective access and those generated because of an interactive network user sign in, the
Impersonation Level information is included. When the logon event is generated because of effective access, the
Impersonation Level will be Identity. A network interactive user sign in typically generates a logon event with the
Impersonation Level = Impersonation or Delegation.
See also
Users will get an access-denied message when they try to access shared files and folders on a file server for which
they do not have permissions. Administrators often do not have the appropriate context to troubleshoot the access
issue, which makes it hard to resolve the issue.
Scenario description
Access-denied assistance is a new feature in Windows Server 2012 , which provides the following ways to
troubleshoot issues that are related to access to files and folders:
Self-assistance. If a user can determine the issue and remediate the problem so that they can get the
requested access, the impact to the business is low, and no special exceptions are needed in the central
access policy. Access-denied assistance provides an access-denied message that file server administrators
can customize with information specific to their organizations. For example, an administrator could set the
message so that users can request access from a data owner without involving the file server administrator.
Assistance by the data owner. You can define a distribution list for shared folders, and configure it so that
the folder owner receives an email notification when a user needs access. If the data owner does not know
how to help the user get access, the owner can forward this information to the file server administrator.
Assistance by the file server administrator. This type of assistance is available when the user cannot fix
an issue and the data owner cannot help. Windows Server 2012 provides a user interface where file server
administrators can view the effective permissions for a user on a file or folder so that it is easier to
troubleshoot access issues.
Access-denied assistance in Windows Server 2012 provides file server administrators the relevant access details so
that they can determine the issue and appropriate tools so that they can make configuration changes to satisfy the
access request. For example, a user might follow this process to access a file that they currently do not have access
to:
The user attempts to read a file in the \\financeshares shared folder, but the server displays an access-denied
message.
Windows Server 2012 displays the access-denied assistance information to the user with an option to
request assistance.
If the user requests access to the resource, the server sends an email with the access request information to
the folder owner.
You can find planning information for configuring access-denied assistance in Plan for Access-Denied Assistance.
You can find steps about configuring access-denied assistance in Deploy Access-Denied Assistance (Demonstration
Steps).
In this scenario
This scenario is part of the Dynamic Access Control scenario. For additional information about Dynamic Access
Control, see:
Practical applications
Access-denied assistance in Windows Server 2012 contributes to Dynamic Access Control by giving users the
ability to request access to shared files and folders directly from an access-denied message.
Features included in this scenario

The following table lists the features that are part of this scenario and describes how they support it.
FEATURE HOW IT SUPPORTS THIS SCENARIO
File Server Resource Manager Overview Access-denied assistance can be configured by using the File
Server Resource Manager console on the file server.
File and Storage Services Overview File Server Resource Manager is a File and Storage Services
role service, and it is comprised of a set of features that can be
used to administer the file servers on your network.
Deploy Access-Denied Assistance (Demonstration
Steps)
This topic explains how to configure access-denied assistance, and verify that it is working properly.
In this document
Step 1: Configure access-denied assistance
Step 2: Configure the email notification settings
Step 3: Verify that access-denied assistance is configured correctly
NOTE
This topic includes sample Windows PowerShell cmdlets that you can use to automate some of the procedures described. For
more information, see Using Cmdlets.
Step 1: Configure access-denied assistance

You can configure access-denied assistance within a domain by using Group Policy, or you can configure the
assistance individually on each file server by using the File Server Resource Manager console. You can also change
the access-denied message for a specific shared folder on a file server.
You can configure access-denied assistance for the domain by using Group Policy as follows:
Do this step using Windows PowerShell
To configure access-denied assistance by using Group Policy
1. Open Group Policy Management. In Server Manager, click Tools, and then click Group Policy
Management.
2. Right-click the appropriate Group Policy, and then click Edit.
3. Click Computer Configuration, click Policies, click Administrative Templates, click System, and then
click Access-Denied Assistance.
4. Right-click Customize message for Access Denied errors, and then click Edit.
5. Select the Enabled option.
6. Configure the following options:
a. In the Display the following message to users who are denied access box, type a message that
users will see when they are denied access to a file or folder.
You can add macros to the message that will insert customized text. The macros include:
[Original File Path] The original file path that was accessed by the user.
[Original File Path Folder] The parent folder of the original file path that was accessed by the
user.
[Admin Email] The administrator email recipient list.
[Data Owner Email] The data owner email recipient list.
b. Select the Enable users to request assistance check box.
c. Leave the remaining default settings.

Set-GPRegistryValue -Name "Name of GPO" -key "HKLM\Software\Policies\Microsoft\Windows\ADR\AccessDenied" -

ValueName AllowEmailRequests -Type DWORD -value 1
ValueName GenerateLog -Type DWORD -value 1
ValueName IncludeDeviceClaims -Type DWORD -value 1
ValueName IncludeUserClaims -Type DWORD -value 1
ValueName PutAdminOnTo -Type DWORD -value 1
ValueName PutDataOwnerOnTo -Type DWORD -value 1
ValueName ErrorMessage -Type MultiString -value "Type the text that the user will see in the error message
dialog box."
ValueName Enabled -Type DWORD -value 1
Alternatively, you can configure access-denied assistance individually on each file server by using the File Server
Resource Manager console.
To configure access-denied assistance by using File Server Resource Manager
1. Open File Server Resource Manager. In Server Manager, click Tools, and then click File Server Resource
Manager.
2. Right-click File Server Resource Manager (Local), and then click Configure Options.
3. Click the Access-Denied Assistance tab.
4. Select the Enable access-denied assistance check box.
5. In the Display the following message to users who are denied access to a folder or file box, type a
message that users will see when they are denied access to a file or folder.
[Original File Path Folder] The parent folder of the original file path that was accessed by the user.
6. Click Configure email requests, select the Enable users to request assistance check box, and then click
OK.
7. Click Preview if you want to see how the error message will look to the user.
8. Click OK.

Set-FSRMAdrSetting -Event "AccessDenied" -DisplayMessage "Type the text that the user will see in the error
message dialog box." -Enabled:$true -AllowRequests:$true
After you configure the access-denied assistance, you must enable it for all file types by using Group Policy.
To configure access-denied assistance for all file types by using Group Policy
1. Open Group Policy Management. In Server Manager, click Tools, and then click Group Policy
Management.
2. Right-click the appropriate Group Policy, and then click Edit.
3. Click Computer Configuration, click Policies, click Administrative Templates, click System, and then
click Access-Denied Assistance.
4. Right-click Enable access-denied assistance on client for all file types, and then click Edit.
5. Click Enabled, and then click OK.

Set-GPRegistryValue -Name "Name of GPO" -key "HKLM\SOFTWARE\Policies\Microsoft\Windows\Explore" -ValueName

EnableShellExecuteFileStreamCheck -Type DWORD -value 1
You can also specify a separate access-denied message for each shared folder on a file server by using the File
Server Resource Manager console.
To specify a separate access-denied message for a shared folder by using File Server Resource Manager
Manager.
2. Expand File Server Resource Manager (Local), and then click Classification Management.
3. Right-click Classification Properties, and then click Set Folder Management Properties.
4. In the Property box, click Access-Denied Assistance Message, and then click Add.
5. Click Browse, and then choose the folder that should have the custom access-denied message.
6. In the Value box, type the message that should be presented to the users when they cannot access a
resource within that folder.
[Original File Path Folder] The parent folder of the original file path that was accessed by the user.
7. Click OK, and then click Close.

Set-FSRMMgmtProperty -Namespace "folder path" -Name "AccessDeniedMessage_MS" -Value "Type the text that the
user will see in the error message dialog box."
Step 2: Configure the email notification settings

You must configure the email notification settings on each file server that will send the access-denied assistance
messages.
Manager.
2. Right-click File Server Resource Manager (Local), and then click Configure Options.
3. Click the Email Notifications tab.
4. Configure the following settings:
In the SMTP server name or IP address box, type the name of IP address of the SMTP server in
your organization.
In the Default administrator recipients and Default 'From' e-mail address boxes, type the email
address of the file server administrator.
5. Click Send Test E -mail to ensure that the email notifications are configured correctly.
6. Click OK.

set-FSRMSetting -SMTPServer "server1" -AdminEmailAddress "fileadmin@contoso.com" -FromEmailAddress

"fileadmin@contoso.com"
Step 3: Verify that access-denied assistance is configured correctly

You can verify that the access-denied assistance is configured correctly by having a user who is running Windows 8
try to access a share or a file in that share that they do not have access to. When the access-denied message
appears, the user should see a Request Assistance button. After clicking the Request Assistance button, the user
can specify a reason for access and then send an email to the folder owner or file server administrator. The folder
owner or file server administrator can verify for you that the email arrived and contains the appropriate details.
IMPORTANT
If you want to verify access-denied assistance by having a user who is running Windows Server 2012 , you must install the
Desktop Experience before connecting to the file share.
See also
Plan for Access-Denied Assistance
Scenario: Classification-Based Encryption for Office
Documents
Protection of sensitive information is mainly about mitigating risk for the organization. Various compliance
regulations, such as the Health Insurance Portability and Accountability Act (HIPAA) and Payment Card Industry
Data Security Standard (PCI-DSS ), dictate encryption of information, and there are numerous business reasons to
encrypt sensitive business information. However, encrypting information is expensive, and it might impair business
productivity. Thus, organizations tend to have different approaches and priorities for encrypting their information.
Windows Server 2012 provides the ability to automatically encrypt sensitive Microsoft Office files, based on their
classification. This is done through file management tasks that invoke Active Directory Rights Management
Services (AD RMS ) protection for sensitive documents a few seconds after the file is identified as being a sensitive
file on the file server. This is facilitated by continuous file management tasks on the file server.
AD RMS encryption provides another layer of protection for files. Even if a person with access to a sensitive file
inadvertently sends that file through email, the file is protected by the AD RMS encryption. Users who want to
access the file must first authenticate themselves to an AD RMS server to receive the decryption key. The following
figure shows this process.
Figure 6 Classification-based RMS protection

Support for non-Microsoft file formats is available through non-Microsoft vendors. After a file has been protected
by AD RMS encryption, data management features such as search- or content-based classification are no longer
available for that file.
In this scenario
Following is the guidance that is available for this scenario:
Planning Considerations for Encryption of Office Documents
Deploy Encryption of Office Files (Demonstration Steps)

Active Directory Domain Services role (AD DS) AD DS provides a distributed database that stores and
manages information about network resources and
application-specific data from directory-enabled applications.
In this scenario, AD DS in Windows Server 2012 introduces a
claims-based authorization platform that enables the creation
of user claims and device claims, compound identity (user plus
device claims), a new central access policies model, and the use
of file-classification information in authorization decisions.
File and Storage Services role File and Storage Services provides technologies to help you set
up and manage one or more file servers that provide central
File Server Resource Manager locations on your network where you can store files and share
them with users. If your network users need access to the
same files and applications, or if centralized backup and file
management are important to your organization, you should
set up one or more computers as a file server by adding the
File and Storage Services role and the appropriate role services
to the computers. In this scenario, file server administrators
can configure file management tasks that invoke AD RMS
protection for sensitive documents a few seconds after the file
is identified as being a sensitive file on the file server
(continuous file management tasks on the file server).
Active Directory Rights Management Services (AD RMS) role AD RMS enables individuals and administrators (through
Information Rights Management (IRM) policies) to specify
access permissions to documents, workbooks, and
presentations. This helps prevent sensitive information from
being printed, forwarded, or copied by unauthorized people.
After permission for a file has been restricted by using IRM,
the access and usage restrictions are enforced no matter
where the information is, because the permission to a file is
stored in the document file itself. In this scenario, AD RMS
encryption provides another layer of protection for files. Even
if a person with access to a sensitive file inadvertently sends
that file through email, the file is protected by the AD RMS
encryption. Users who want to access the file must first
authenticate themselves to an AD RMS server to receive the
decryption key.
Deploy Encryption of Office Files (Demonstration
Steps)
Contoso's Finance Department has a number of file servers that store their documents. These documents can be
general documentation or they can have a high-business impact (HBI). For example, any document that contains
confidential information is deemed, by Contoso, to have a high-business impact. Contoso wants to ensure that all
their documentation has a minimum amount of protection and that their HBI documentation is restricted to the
appropriate people. To accomplish this, Contoso is exploring using the File Classification Infrastructure (FCI) and
AD RMS that is available in Windows Server 2012 . By using FCI, Contoso will classify all of the documents on
their file server, based on the content, and then use AD RMS to apply the appropriate rights policy.
In this scenario, you'll perform the following steps:
TASK DESCRIPTION
Enable resource properties Enable the Impact and Personally Identifiable Information
resource properties.
Create classification rules Create the following classification rules: HBI Classification
Rule and PII Classification Rule.
Use file management tasks to automatically protect Create a file management task that automatically used AD
documents with AD RMS RMS to protect documents with high personally identifiable
information (PII). Only members of the FinanceAdmin group
will have access to documents that contain high PII.
View the results Examine the classification of documents and observe how they
change as you change the content in the document. Also
verify how the document gets protected by AD RMS.
Verify AD RMS protection Verify that the document is protected with AD RMS.
Step 1: Enable resource properties

To enable resource properties
1. In Hyper-V Manager, connect to server ID_AD_DC1. Sign in to the server by using Contoso\Administrator
with the password pass@word1.
2. Open Active Directory Administrative Center, and click Tree View.
3. Expand DYNAMIC ACCESS CONTROL, and select Resource Properties.
4. Scroll down to the Impact property in the Display name column. Right-click Impact, and then click
Enable.
5. Scroll down to the Personally Identifiable Information property in the Display name column. Right-
click Personally Identifiable Information, and then click Enable.
6. To publish the resource properties in the Global Resource List, in the left pane, click Resource Property
Lists, and then double-click Global Resource Property List.
7. Click Add, and then scroll down to and click Impact to add it to the list. Do the same for Personally
Identifiable Information. Click OK twice to finish.

Set-ADResourceProperty -Enabled:$true -Identity:"CN=Impact_MS,CN=Resource Properties,CN=Claims

Configuration,CN=Services,CN=Configuration,DC=contoso,DC=com"
Set-ADResourceProperty -Enabled:$true -Identity:"CN=PII_MS,CN=Resource Properties,CN=Claims
Configuration,CN=Services,CN=Configuration,DC=contoso,DC=com"
Step 2: Create classification rules

This step explains how to create the High Impact classification rule. This rule will search the content of documents
and if the string "Contoso Confidential" is found, it will classify this document as having high-business impact. This
classification will override any previously assigned classification of low -business impact.
You will also create a High PII rule. This rule searches the content of documents, and if a Social Security number is
found, it classifies the document as having high PII.
To create the high-impact classification rule
1. In Hyper-V Manager, connect to server ID_AD_FILE1. Sign in to the server by using Contoso\Administrator
2. You need to refresh the Global Resource Properties from Active Directory. Open Windows PowerShell and
type: Update-FSRMClassificationPropertyDefinition , and then press ENTER. Close Windows PowerShell.
3. Open File Server Resource Manager. To open File Server Resource Manager, click Start, type file server
resource manager, and then click File Server Resource Manager.
4. In the left pane of File Server Resource Manager, expand Classification Management, and then select
Classification Rules.
5. In the Actions pane, click Configure Classification Schedule. On the Automatic Classification tab,
select Enable fixed schedule, select a Day of the week, and then select the Allow continuous
classification for new files check box. Click OK.
6. In the Actions pane, click Create Classification Rule. This opens the Create Classification Rule dialog
box.
7. In the Rule name box, type High Business Impact.
8. In the Description box, type Determines if the document has a high business impact based on the
presence of the string "Contoso Confidential"
9. On the Scope tab, click Set Folder Management Properties, select Folder Usage, click Add, then click
Browse, browse to D:\Finance Documents as the path, click OK, and then choose a property value named
Group Files and click Close. Once management properties are set, on the Rule Scope tab select Group
Files.
10. Click the Classification tab. Under Choose a method to assign the property to files, select Content
Classifier from the drop-down list.
11. Under Choose a property to assign to files, select Impact from the drop-down list.
12. Under Specify a value, select High from the drop-down list.
13. Click Configure under Parameters. In the Classification Parameters dialog box, in the Expression Type
list, select String. In the Expression box, type: Contoso Confidential, and then click OK.
14. Click the Evaluation Type tab. Click Re-evaluate existing property values, click Overwritethe existing
value, and then click OK to finish.

Update-FSRMClassificationPropertyDefinition
$date = Get-Date
$AutomaticClassificationScheduledTask = New-FsrmScheduledTask -Time $date -Weekly @(3, 2, 4, 5,1,6,0) -
RunDuration 0;
Set-FsrmClassification -Continuous -schedule $AutomaticClassificationScheduledTask
New-FSRMClassificationRule -Name "High Business Impact" -Property "Impact_MS" -Description "Determines if the
document has a high business impact based on the presence of the string 'Contoso Confidential'" -PropertyValue
"3000" -Namespace @("D:\Finance Documents") -ClassificationMechanism "Content Classifier" -Parameters
@("StringEx=Min=1;Expr=Contoso Confidential") -ReevaluateProperty Overwrite
To create the high-PII classification rule

2. On the desktop, open the folder named Regular Expressions, and then open the text document named
RegEx-SSN. Highlight and copy the following regular expression string: ^(?!000)([0-7]\d{2}|7([0-
7]\d|7[012]))([ -]?)(?!00)\d\d\3(?!0000)\d{4}$. This string will be used later in this step so keep it on your
clipboard.
4. In the left pane of File Server Resource Manager, expand Classification Management, and then select
Classification Rules.
5. In the Actions pane, click Configure Classification Schedule. On the Automatic Classification tab,
select Enable fixed schedule, select a Day of the week, and then select the Allow continuous
classification for new files check box. Click OK.
6. In the Rule name box, type High PII. In the Description box, type Determines if the document has a
high PII based on the presence of a Social Security Number.
7. Click the Scope tab, select the Group Files check box.
8. Click the Classification tab. Under Choose a method to assign the property to files, select Content
Classifier from the drop-down list.
9. Under Choose a property to assign to files, select Personally Identifiable Information from the drop-
down list.
10. Under Specify a value, select High from the drop-down list.
11. Click Configure under Parameters.
In the Classification Parameterswindow, in the Expression Type list, select Regular Expression. In the
Expression box, paste the text from your clipboard: ^(?!000)([0-7]\d{2}|7([0-7]\d|7[012]))([ -]?)
(?!00)\d\d\3(?!0000)\d{4}$, and then click OK.
NOTE
This expression will allow invalid Social Security numbers. This allows us to use fictitious Social Security numbers in the
demonstration.
12. Click the Evaluation Type tab. Select Re-evaluate existing property values, Overwritethe existing
value, and then click OK to finish.

New-FSRMClassificationRule -Name "High PII" -Description "Determines if the document has a high PII based on
the presence of a Social Security Number." -Property "PII_MS" -PropertyValue "5000" -Namespace @("D:\Finance
Documents") -ClassificationMechanism "Content Classifier" -Parameters
@("RegularExpressionEx=Min=1;Expr=^(?!000)([0-7]\d{2}|7([0-7]\d|7[012]))([ -]?)(?!00)\d\d\3(?!0000)\d{4}$") -
ReevaluateProperty Overwrite
You should now have two classification rules:

High Business Impact
High PII
Step 3: Use file management tasks to automatically protect documents

with AD RMS
Now that you've created rules to automatically classify documents based on content, the next step is to create a file
management task that uses AD RMS to automatically protect certain documents based on their classification. In
this step, you will create a file management task that automatically protects any documents with a high PII. Only
members of the FinanceAdmin group will have access to documents that contain high PII.
To protect documents with AD RMS
3. In the left pane, select File Management Tasks. In the Actions pane, select Create File Management
Task.
4. In the Task name: field, type High PII. In the Description field, type Automatic RMS protection for
high PII documents.
5. Click the Scope tab, select the Group Files check box.
6. Click the Action tab. Under Type, select RMS Encryption. Click Browse to select a template, and then
select the Contoso Finance Admin Only template.
7. Click the Condition tab, and then click Add. Under Property, select Personally Identifiable Information.
Under Operator, select Equal. Under Value, select High. Click OK.
8. Click the Schedule tab. In the Schedule section, click Weekly, and then select Sunday. Running the task
once-a-week will ensure that you catch any documents that may have been missed due to a service outage
or other disruptive event.
9. In the Continuous operation section, select Run task continuously on new files, and then click OK. You
should now have a file management task named High PII.

$fmjRmsEncryption = New-FSRMFmjAction -Type 'Rms' -RmsTemplate 'Contoso Finance Admin Only'

$fmjCondition1 = New-FSRMFmjCondition -Property 'PII_MS' -Condition 'Equal' -Value '5000'
$date = get-date
$schedule = New-FsrmScheduledTask -Time $date -Weekly @('Sunday')
$fmj1=New-FSRMFileManagementJob -Name "High PII" -Description "Automatic RMS protection for high PII documents"
-Namespace @('D:\Finance Documents') -Action $fmjRmsEncryption -Schedule $schedule -Continuous -Condition
@($fmjCondition1)
Step 4: View the results

It's time to take a look at your new automatic classification and AD RMS protection rules in action. In this step you
will examine the classification of documents and observe how they change as you change the content in the
document.
To view the results
2. In Windows Explorer, navigate to D:\Finance Documents.
3. Right-click the Finance Memo document and click Properties.Click the Classification tab, and notice that
the Impact property currently has no value. Click Cancel.
4. Right-click the Request for Approval to Hire document, and then select Properties.
5. Click the Classification tab, and notice that the Personally Identifiable Information property currently
has no value. Click Cancel.
6. Switch to CLIENT1. Sign off any user who is signed in, and then sign in as Contoso\MReid with the
password pass@word1.
7. From the Desktop, open the Finance Documents shared folder.
8. Open the Finance Memo document. Near the bottom of the document, you will see the word
Confidential. Modify it to read: Contoso Confidential. Save the document and close it.
9. Open the Request for Approval to Hire document. In the Social Security#: section, type: 777-77-7777.
Save the document and close it.
NOTE
You may need to wait 30 seconds for the classification to occur.
10. Switch back to ID_AD_FILE1. In Windows Explorer, navigate to D:\Finance Documents.

11. Right-click the Finance Memo document, and click Properties. Click the Classification tab. Notice that the
Impact property is now set to High. Click Cancel.
12. Right-click the Request for Approval to Hire document and click Properties.
13. . Click the Classification tab. Notice that the Personally Identifiable Information property is now set to
High. Click Cancel.
Step 5: Verify protection with AD RMS

To verify that the document is protected
1. Switch back to ID_AD_CLIENT1.
2. Open the Request for approval to Hire document.
3. Click OK to allow the document to connect to your AD RMS server.
4. You can now see that the document has been protected by AD RMS because it contains a Social Security
number.
Scenario: Get Insight into Your Data by Using
Classification
Reliance on data and storage resources has continued to grow in importance for most organizations. IT
administrators face the growing challenge of overseeing larger and more complex storage infrastructures, while
simultaneously being tasked with the responsibility to ensure that total cost-of-ownership is maintained at
reasonable levels. Managing storage resources is not only about the volume or availability of data; it is also about
enforcing company policies and knowing how storage is consumed to enable efficient utilization and compliance to
mitigate risk. File Classification Infrastructure provides insight into your data by automating classification processes
so that you can manage your data more effectively. The following classification methods are available with File
Classification Infrastructure: manual, programmatic, and automatic. This topic focuses on the automatic file
classification method.
File Classification Infrastructure uses classification rules to automatically scan files and classify them according to
the contents of the file. Classification properties are defined centrally in Active Directory so that these definitions
can be shared across file servers in the organization. You can create classification rules that scan files for a standard
string or for a string that matches a pattern (regular expression). When a configured classification parameter is
found in a file, that file is classified as configured in the classification rule. Some examples of classification rules
include:
Classify any file that contains the string "Contoso Confidential" as having high business impact
Classify any file that contains at least 10 social security numbers as having personally identifiable
information
When a file is classified, you can use a file management task to take action on any files that are classified a specific
way. The actions in a file management task include protecting the rights associated with the file, expiring the file,
and running a custom action (such as posting information to a web service).
You can find planning information for configuring automatic file classification in Plan for Automatic File
Classification.
You can find steps for how to automatically classify files in Deploy Automatic File Classification (Demonstration
Steps).
In this scenario
Control, see:
File Classification Infrastructure in Windows Server 2012 contributes to Dynamic Access Control by enabling
business data owners to easily classify and label data. The classification information that is stored in the central
access policy allows you to define access policies for data classes that are critical to business.

File Server Resource Manager Overview File Classification Infrastructure is a feature that is included in
File Server Resource Manager.
File and Storage Services Overview File Server Resource Manager is a feature that is included with
the File Services server role.
Deploy Automatic File Classification (Demonstration
Steps)
This topic explains how to enable resource properties in Active Directory, create classification rules on the file
server, and then assign values to the resource properties for files on the file server. For this example, the following
classification rules are created:
A content classification rule that searches a set of files for the string 'Contoso Confidential.' If the string is
found in a file, the Impact resource property is set to High on the file.
A content classification rule that searches a set of files for a regular expression that matches a social security
number at least 10 times in one file. If the pattern is found, the file is classified as having personally
identifiable information and the Personally Identifiable Information resource property is set to High.
In this document
Step 1: Create resource property definitions
Step 2: Create a string content classification rule
Step 3: Create a regular expression content classification rule
Step 4: Verify that the files are classified
NOTE

The Impact and Personally Identifiable Information resource properties are enabled so that File Classification
Infrastructure can use these resource properties to tag the files that are scanned on a network shared folder.
To create resource property definitions
1. On the domain controller, sign in to the server as a member of the Domain Admins security group.
2. Open Active Directory Administrative Center. In Server Manager, click Tools, and then click Active
Directory Administrative Center.
3. Expand Dynamic Access Control, and then click Resource Properties.
4. Right-click Impact, and then click Enable.
5. Right-click Personally Identifiable Information, and then click Enable.

Set-ADResourceProperty '"Enabled:$true '"Identity:'CN=Impact_MS,CN=Resource Properties,CN=Claims

Configuration,CN=Services,CN=Configuration,DC=contoso,DC=com'
Set-ADResourceProperty '"Enabled:$true '"Identity:'CN=PII_MS,CN=Resource Properties,CN=Claims
Step 2: Create a string content classification rule

A string content classification rule scans a file for a specific string. If the string is found, the value of a resource
property can be configured. In this example, we will scan each file on a network shared folder and look for the
string 'Contoso Confidential.' If the string is found, the associated file is classified as having high business impact.
To create a string content classification rule
1. Log on to the file server as a member of the Administrators security group.
2. From the Windows PowerShell command prompt, type Update-FsrmClassificationPropertyDefinition
and then press ENTER. This will synchronize the property definitions created on the domain controller to the
file server.
Manager.
4. Expand Classification Management, right-click Classification Rules, and then click Configure
Classification Schedule.
5. Select the Enable fixed schedule check box, select the Allow continuous classification for new files
check box, choose a day of the week to run the classification, and then click OK.
6. Right-click Classification Rules, and then click Create Classification Rule.
7. On the General tab, in the Rule name box, type a rule name such as Contoso Confidential.
8. On the Scope tab, click Add, and choose the folders that should be included in this rule, such as D:\Finance
Documents.
NOTE
You can also choose a dynamic name space for the scope. For more information about dynamic name spaces for
classification rules, see What's New in File Server Resource Manager in Windows Server 2012 [redirected].
9. On the Classification tab, configure the following:

In the Choose a method to assign a property to files box, ensure that Content Classifier is
selected.
In the Choose a property to assign to files box, click Impact.
In the Specify a value box, click High.
10. Under the Parameters heading, click Configure.
11. In the Expression Type column, select String.
12. In the Expression column, type Contoso Confidential, and then click OK.
13. On the Evaluation Type tab, select the Re-evaluate existing property values check box, click Overwrite
the existing value, and then click OK.

$date = Get-Date
$AutomaticClassificationScheduledTask = New-FsrmScheduledTask -Time $date -Weekly @(3, 2, 4, 5,1,6,0) -
RunDuration 0;$AutomaticClassificationScheduledTask
Set-FsrmClassification -Continuous -schedule $AutomaticClassificationScheduledTask
New-FSRMClassificationRule -Name 'Contoso Confidential' -Property "Impact_MS" -PropertyValue "3000" -Namespace
@('D:\Finance Documents') -ClassificationMechanism "Content Classifier" -Parameters
@("StringEx=Min=1;Expr=Contoso Confidential") -ReevaluateProperty Overwrite
Step 3: Create a regular expression content classification rule

A regular expression classification rule scans a file for a pattern that matches the regular expression. If a string that
matches the regular expression is found, the value of a resource property can be configured. In this example, we
will scan each file on a network shared folder and look for a string that matches the pattern of a social security
number (XXX-XX-XXXX). If the pattern is found, the associated file is classified as having personally identifiable
information.
To create a regular expression content classification rule
1. Sign in to the file server as a member of the Administrators security group.
2. From the Windows PowerShell command prompt, type Update-FsrmClassificationPropertyDefinition,
and then press ENTER. This will synchronize the property definitions that are created on the domain
controller to the file server.
Manager.
4. Right-click Classification Rules, and then click Create Classification Rule.
5. On the General tab, in the Rule name box, type a name for the classification rule, such as PII Rule.
6. On the Scope tab, click Add, and then choose the folders that should be included in this rule, such as
D:\Finance Documents.
7. On the Classification tab, configure the following:
In the Choose a method to assign a property to files box, ensure that Content Classifier is
selected.
In the Choose a property to assign to files box, click Personally Identifiable Information.
In the Specify a value box, click High.
8. Under the Parameters heading, click Configure.
9. In the Expression Type column, select Regular expression.
10. In the Expression column, type ^(?!000)([0-7]\d{2}|7([0-7]\d|7[012]))([ -]?)(?!00)\d\d\3(?!0000)\d{4}$
11. In the Minimum Occurrences column, type 10, and then click OK.
12. On the Evaluation Type tab, select the Re-evaluate existing property values check box, click Overwrite
the existing value, and then click OK.

New-FSRMClassificationRule -Name "PII Rule" -Property "PII_MS" -PropertyValue "5000" -Namespace @('D:\Finance
Documents') -ClassificationMechanism "Content Classifier" -Parameters
@("RegularExpressionEx=Min=10;Expr=^(?!000)([0-7]\d{2}|7([0-7]\d|7[012]))([ -]?)(?!00)\d\d\3(?!0000)\d{4}$") -
ReevaluateProperty Overwrite
Step 4: Verify that the files are classified correctly

You can verify that the files are properly classified by viewing the properties of a file that was created in the folder
specified in the classification rules.
To verify that the files are classified correctly
1. On the file server, run the classification rules by using File Server Resource Manager.
a. Click Classification Management, right-click Classification Rules, and then click Run
Classification With All Rules Now.
b. Click the Wait for classification to complete option, and then click OK.
c. Close the Automatic Classification Report.
d. You can do this by using Windows PowerShell with the following command: Start-
FSRMClassification '"RunDuration 0 -Confirm:$false
2. Navigate to the folder that was specified in the classification rules, such as D:\Finance Documents.
3. Right-click a file in that folder, and then click Properties.
4. Click the Classification tab, and verify that the file is classified correctly.
See also
Scenario: Get Insight into Your Data by Using Classification
Plan for Automatic File Classification
Scenario: Implement Retention of Information on File
Servers
A retention period is the amount of time that a document should be kept before it is expired. Depending on the
organization, the retention period can be different. You can classify files in a folder as having a short, medium, or
long-term retention period, and then assign a timeframe for each period. You may want to keep a file indefinitely by
putting it on legal hold.
File Classification Infrastructure and File Server Resource Manager uses file management tasks and file
classification to apply retention periods for a set of files. You can assign a retention period on a folder and then use
a file management task to configure how long an assigned retention period is to last. When the files in the folder
are about to expire, the owner of the file receives a notification email. You can also classify a file as being on legal
hold so that the file management task will not expire the file.
You can find planning information for configuring retention in Plan for Retention of Information on File Servers.
You can find steps for classifying files for legal hold and configuring a retention period in Deploy Implementing
Retention of Information on File Servers (Demonstration Steps).
NOTE
That scenario only discusses how to manually classify a document for legal hold. However, it is possible in Windows Server
2012 to automatically classify documents for legal hold. One way to do this is to create a Windows PowerShell classifier that
compares the file owner to a list of user accounts that are under legal hold. If the file owner is a part of the user account list,
the file is classified for legal hold.
In this scenario
Control, see:

File Server Resource Manager Overview File Classification Infrastructure is a feature that is included in
File and Storage Services Overview File Server Resource Manager is a feature that is included with
the File Services server role.
Deploy Implementing Retention of Information on
File Servers (Demonstration Steps)
You can set retention periods for folders and put files on legal hold by using File Classification Infrastructure and
In this document
Prerequisites
Step 2: Configure notifications
Step 3: Create a file management task
Step 4: Classify a file manually
NOTE
Prerequisites
The steps in this topic assume you have a SMTP server configured for file expiration notifications.

In this step, we enable the Retention Period and Discoverability resource properties so that File Classification
Infrastructure can use these resource properties to tag the files that are scanned in a network shared folder.
To create resource property definitions
1. On the domain controller, sign in to the server as a member of the Domain Admins security group.
2. Open Active Directory Administrative Center. In Server Manager, click Tools, and then click Active
Directory Administrative Center.
3. Expand Dynamic Access Control, and then click Resource Properties.
4. Right-click Retention Period, and then click Enable.
5. Right-click Discoverability, and then click Enable.

Set-ADResourceProperty -Enabled:$true -Identity:'CN=RetentionPeriod_MS,CN=Resource Properties,CN=Claims

Set-ADResourceProperty -Enabled:$true -Identity:'CN=Discoverability_MS,CN=Resource Properties,CN=Claims
Step 2: Configure notifications

In this step, we use the File Server Resource Manager console to configure the SMTP server, the default
administrator email address, and the default email address that the reports are sent from.
To configure notifications
2. From the Windows PowerShell command prompt, type Update-FsrmClassificationPropertyDefinition,
and then press ENTER. This will synchronize the property definitions that are created on the domain
controller to the file server.
Manager.
4. Right-click File Server Resource Manager (local), and then click Configure Options.
5. On the Email Notifications tab, configure the following:
In the SMTP server name or IP address box, type the name of the SMTP server on your network.
In the Default administrator recipients box, type the email address of the administrator who
should get the notification.
In the Default "From" e-mail address box, type the email address that should be used to send the
notifications.
6. Click OK.

Set-FsrmSetting -SmtpServer IP address of SMTP server -FromEmailAddress "FromEmailAddress" -AdminEmailAddress

"AdministratorEmailAddress"
Step 3: Create a file management task

In this step, we use the File Server Resource Manager console to create a file management task that will run on the
last day of the month and expire any files with the following criteria:
The file is not classified as being on legal hold.
The file is classified as having a long-term retention period.
The file has not been modified in the last 10 years.
To create a file management task
Manager.
3. Right-click File Management Tasks, and then click Create File Management Task.
4. On the General tab, in the Task name box, type a name for the file management task, such as Retention
Task.
5. On the Scope tab, click Add, and choose the folders that should be included in this rule, such as D:\Finance
Documents.
6. On the Action tab, in the Type box, click File expiration. In the Expiration directory box, type a path to a
folder on the local file server where the expired files will be moved. This folder should have an access control
list that grants only file server administrators access.
7. On the Notification tab, click Add.
Select the Send e-mail to the following administrators check box.
Select the Send an email to users with affected files check box, and then click OK.
8. On the Condition tab, click Add, and add the following properties:
In the Property list, click Discoverability. In the Operator list, click Not equal. In the Value list,
click Hold.
In the Property list, click Retention Period. In the Operator list, click Equal. In the Value list, click
Long-Term.
9. On the Condition tab, select the Days since file was last modified check box, and then set the value to
3650.
10. On the Schedule tab, click the Monthly option, and then select the Last check box.
11. Click OK.

$fmjexpiration = New-FSRMFmjAction -Type 'Expiration' -ExpirationFolder folder

$fmjNotificationAction = New-FsrmFmjNotificationAction -Type Email -MailTo "[FileOwner],[AdminEmail]"
$fmjNotification = New-FsrmFMJNotification -Days 10 -Action @($fmjNotificationAction)
$fmjCondition1 = New-FSRMFmjCondition -Property 'Discoverability_MS' -Condition 'NotEqual' -Value "Hold"
$fmjCondition2 = New-FSRMFmjCondition -Property 'RetentionPeriod_MS' -Condition 'Equal' -Value "Long-term"
$fmjCondition3 = New-FSRMFmjCondition -Property 'File.DateLastAccessed' -Condition 'Equal' -Value 3650
$date = get-date
$schedule = New-FsrmScheduledTask -Time $date -Monthly @(-1)
$fmj1=New-FSRMFileManagementJob -Name "Retention Task" -Namespace @('D:\Finance Documents') -Action
$fmjexpiration -Schedule $schedule -Notification @($fmjNotification) -Condition @( $fmjCondition1,
$fmjCondition2, $fmjCondition3)
Step 4: Classify a file manually

In this step, we manually classify a file to be on legal hold. The parent folder of this file will be classified with a long-
term retention period.
To manually classify a file
2. Navigate to the folder that was configured in the scope of the file management task created in Step 3.
3. Right-click the folder, and then click Properties.
4. On the Classification tab, click Retention Period, click Long-Term, and then click OK.
5. Right-click a file within that folder, and then click Properties.
6. On the Classification tab, click Discoverability, click Hold, click Apply, and then click OK.
7. On the file server, run the file management task by using the File Server Resource Manager console. After
the file management task completes, check the folder and ensure the file was not moved to the expiration
directory.
8. Right-click the same file within that folder, and then click Properties.
9. On the Classification tab, click Discoverability, click Not Applicable, click Apply, and then click OK.
10. On the file server, run the file management task again by using the File Server Resource Manager console.
After the file management task completes, check the folder and ensure that file was moved to the expiration
directory.
See also
Scenario: Implement Retention of Information on File Servers
Plan for Retention of Information on File Servers
In Windows Server 2012 , a claim type is an assertion about the object with which it's associated. Claim types are
defined per forest in Active Directory. There are many scenarios where a security principal may need to traverse a
trust boundary to access resources in a trusted forest. Cross-forest claims transformation in Windows Server 2012
enables you to transform egress and ingress claims that traverse forests so that the claims are recognized and
accepted in the trusting and trusted forests. Some of the real-world scenarios for transformation of claims are:
Trusting forests can use claim transformation as a guard against elevation of privilege by filtering the
incoming claims with specific values.
Trusting forests can also issue claims for principals coming over a trust boundary if the trusted forest does
not support or issue any claims.
Trusted forests can use claim transformation to prevent certain claim types and claims with certain values
from going out to the trusting forest.
You can also use claim transformation to map different claim types between trusting and trusted forests. This
can be used to generalize the claim-type, the claim value, or both. Without this, you need to standardize the
data between the forests before you can use the claims. Generalizing claims between the trusting and trusted
forests reduces the IT costs.
Claim transformation rules

The transformation rule language syntax divides a single rule into two main parts: a series of condition statements
and the issue statement. Each condition statement has two subcomponents: the claim identifier and the condition.
The issue statement contains keywords, delimiters, and an issue expression. The condition statement optionally
begins with a claim identifier variable, which represents the matched input claim. The condition checks for the
expression. If the input claim does not match the condition, then the transformation engine ignores the issue
statement and evaluates the next input claim against the transformation rule. If all conditions match the input claim,
it processes the issue statement.
For detailed information on claim rules language, see Claims Transformation Rules Language.
Linking claim transformation policies to forests

There are two components involved in setting up claim transformation policies: claim transformation policy objects
and the transformation link. The policy objects live in the configuration naming context in a forest, and they contain
mapping information for the claims. The link specifies which trusting and trusted forests the mapping applies to.
It is important to understand if the forest is the trusting or trusted forest because this is basis for linking
transformation policy objects. For example, the trusted forest is the forest that contains user accounts that require
access. The trusting forest is the forest that contains resources that you want to give users access to. Claims travel
in the same direction as the security principal that requires access. For example, if there is a one-way trust from the
contoso.com forest to the adatum.com forest, the claims will flow from adatum.com to contoso.com, which allows
users from adatum.com to access resources in contoso.com.
By default, a trusted forest allows all outgoing claims to pass, and a trusting forest drops all incoming claims that it
receives.
In this scenario
The following guidance is available for this scenario:
Deploy Claims Across Forests (Demonstration Steps)

Active Directory Domain Services In this scenario, you are required to set up two Active
Directory forests with a two-way trust. You have claims in both
forests. You also set central access policies on the trusting
forest where the resources reside.
File and Storage Services role In this scenario, the data classification is applied to the
resources on the file servers. The central access policy is
applied to the folder where you want to grant user access.
After transformation, the claim grants user access to resources
based on the central access policy that is applied to the folder
on the file server.
Deploy Claims Across Forests (Demonstration Steps)
In this topic, we'll cover a basic scenario that explains how to configure claims transformations between trusting
and trusted forests. You will learn how claims transformation policy objects can be created and linked to the trust
on the trusting forest and the trusted forest. You will then validate the scenario.
Scenario overview
Adatum Corporation provides financial services to Contoso, Ltd. Each quarter, Adatum accountants copy their
account spreadsheets to a folder on a file server located at Contoso, Ltd. There is a two-way trust set up from
Contoso to Adatum. Contoso, Ltd. wants to protect the share so that only Adatum employees can access the remote
share.
In this scenario:
1. Set up the prerequisites and the test environment
2. Set up claims transformation on trusted forest (Adatum)
3. Set up claims transformation in the trusting forest (Contoso)
4. Validate the scenario
Set up the prerequisites and the test environment

The test configuration involves setting up two forests: Adatum Corporation and Contoso, Ltd, and having a two-
way trust between Contoso and Adatum. "adatum.com" is the trusted forest and "contoso.com" is the trusting
forest.
The claims transformation scenario demonstrates transformation of a claim in the trusted forest to a claim in the
trusting forest. To do this, you need to set up a new forest called adatum.com and populate the forest with a test
user with a company value of 'Adatum'. You then have to set up a two-way trust between contoso.com and
adatum.com.
IMPORTANT
When setting up the Contoso and Adatum forests, you must ensure that both the root domains are at the Windows Server
2012 Domain Functional Level for claims transformation to work.
You need to set up the following for the lab. These procedures are explained in detail in Appendix B: Setting Up the
Test Environment
You need to implement the following procedures to set up the lab for this scenario:
1. Set Adatum as trusted forest to Contoso
2. Create the 'Company' claim type on Contoso
3. Enable the 'Company' resource property on Contoso
4. Create the central access rule
5. Create the central access policy
6. Publish the new policy through Group Policy
7. Create the Earnings folder on the file server
8. Set classification and apply the central access policy on the new folder
Use the following information to complete this scenario:
OBJECTS DETAILS
Users Jeff Low, Contoso
User claims on Adatum and Contoso ID: ad://ext/Company:ContosoAdatum,
Source attribute: company
Suggested values: Contoso, Adatum Important: You must set

the ID on the 'Company' claim type on both Contoso and
Adatum to be the same for the claims transformation to work.
Central access rule on Contoso AdatumEmployeeAccessRule
Central access policy on Contoso Adatum Only Access Policy
Claims Transformation policies on Adatum and Contoso DenyAllExcept Company
File folder on Contoso D:\EARNINGS
Set up claims transformation on trusted forest (Adatum)

In this step you create a transformation policy in Adatum to deny all claims except 'Company' to pass to Contoso.
The Active Directory module for Windows PowerShell provides the DenyAllExcept argument, which drops
everything except the specified claims in the transformation policy.
To set up a claims transformation, you need to create a claims transformation policy and link it between the trusted
and trusting forests.
Create a claims transformation policy in Adatum
To c r e a t e a t r a n sfo r m a t i o n p o l i c y A d a t u m t o d e n y a l l c l a i m s e x c e p t ' C o m p a n y '
1. Sign in to the domain controller, adatum.com as Administrator with the password pass@word1.
2. Open an elevated command prompt in Windows PowerShell, and type the following:
New-ADClaimTransformPolicy `
-Description:"Claims transformation policy to deny all claims except Company"`
-Name:"DenyAllClaimsExceptCompanyPolicy" `
-DenyAllExcept:company `
-Server:"adatum.com" `
Set a claims transformation link on Adatum's trust domain object

In this step, you apply the newly created claims transformation policy on Adatum's trust domain object for
Contoso.
To a p p l y t h e c l a i m s t r a n sfo r m a t i o n p o l i c y
1. Sign in to the domain controller, adatum.com as Administrator with the password pass@word1.
2. Open an elevated command prompt in Windows PowerShell, and type the following:
Set-ADClaimTransformLink `
-Identity:"contoso.com" `
-Policy:"DenyAllClaimsExceptCompanyPolicy" `
'"TrustRole:Trusted `
Set up claims transformation in the trusting forest (Contoso)

In this step you create a claims transformation policy in Contoso (the trusting forest) to deny all claims except
'Company.' You need to create a claims transformation policy and link it to the forest trust.
Create a claims transformation policy in Contoso
To c r e a t e a t r a n sfo r m a t i o n p o l i c y A d a t u m t o d e n y a l l e x c e p t ' C o m p a n y '
1. Sign in to the domain controller, contoso.com as Administrator with the password pass@word1.
2. Open an elevated command prompt in Windows PowerShell and type the following:
New-ADClaimTransformPolicy `
-Description:"Claims transformation policy to deny all claims except company" `
-Name:"DenyAllClaimsExceptCompanyPolicy" `
-DenyAllExcept:company `
-Server:"contoso.com" `
Set a claims transformation link on Contoso's trust domain object

In this step, you apply the newly created claims transformation policy on the contoso.com trust domain object for
Adatum to allow "Company" be passed through to contoso.com. The trust domain object is named adatum.com.
To se t t h e c l a i m s t r a n sfo r m a t i o n p o l i c y
1. Sign in to the domain controller, contoso.com as Administrator with the password pass@word1.
2. Open an elevated command prompt in Windows PowerShell and type the following:
Set-ADClaimTransformLink
-Identity:"adatum.com" `
-Policy:"DenyAllClaimsExceptCompanyPolicy" `
-TrustRole:Trusting `
Validate the scenario

In this step you try to access the D:\EARNINGS folder that was set up on the file server FILE1 to validate that the
user has access to the shared folder.
To ensure that the Adatum user can access the shared folder
1. Sign in to the Client machine, CLIENT1 as Jeff Low with the password pass@word1.
2. Browse to the folder \\FILE1.contoso.com\Earnings.
3. Jeff Low should be able to access the folder.
Additional scenarios for claims transformation policies

Following is a list of additional common cases in claims transformation.
SCENARIO POLICY
Allow all claims that come from Adatum to go through to Code -

Contoso Adatum New-ADClaimTransformPolicy `
-Description:"Claims transformation policy to allow all claims" `
-Name:"AllowAllClaimsPolicy" `
-AllowAll `
-Policy:"AllowAllClaimsPolicy" `
Deny all claims that come from Adatum to go through to Code -

Contoso Adatum New-ADClaimTransformPolicy `
-Description:"Claims transformation policy to deny all claims" `
-Name:"DenyAllClaimsPolicy" `
-DenyAll `
-Policy:"DenyAllClaimsPolicy" `
-Server:"contoso.com"`
Allow all claims that come from Adatum except "Company" Code
and "Department" to go through to Contoso Adatum - New-ADClaimTransformationPolicy `
-Description:"Claims transformation policy to allow all claims
except company and department" `
-Name:"AllowAllClaimsExceptCompanyAndDepartmentPolicy" `
-AllowAllExcept:company,department `
-Policy:"AllowAllClaimsExceptCompanyAndDepartmentPolicy" `
See also
For a list of all Windows PowerShell cmdlets that are available for claims transformation, see Active
Directory PowerShell Cmdlet Reference.
For advanced tasks that involve export and import of DAC configuration information between two forests,
use the Dynamic Access Control PowerShell Reference
The across-forest claims transformation feature enables you to bridge claims for Dynamic Access Control across
forest boundaries by setting claims transformation policies on across-forest trusts. The primary component of all
policies is rules that are written in claims transformation rules language. This topic provides details about this
language and provides guidance about authoring claims transformation rules.
The Windows PowerShell cmdlets for transformation policies on across-forest trusts have options to set simple
policies that are required in common scenarios. These cmdlets translate the user input into policies and rules in the
claims transformation rules language, and then store them in Active Directory in the prescribed format. For more
information about cmdlets for claims transformation, see the AD DS Cmdlets for Dynamic Access Control.
Depending on the claims configuration and the requirements placed on the across-forest trust in your Active
Directory forests, your claims transformation policies may have to be more complex than the policies supported by
the Windows PowerShell cmdlets for Active Directory. To effectively author such policies, it is essential to
understand the claims transformation rules language syntax and semantics. This claims transformation rules
language ("the language") in Active Directory is a subset of the language that is used by Active Directory
Federation Services for similar purposes, and it has a very similar syntax and semantics. However, there are fewer
operations allowed, and additional syntax restrictions are placed in the Active Directory version of the language.
This topic briefly explains the syntax and semantics of the claims transformation rules language in Active Directory
and considerations to be made when authoring policies. It provides several sets of example rules to get you started,
and examples of incorrect syntax and the messages they generate, to help you decipher error messages when you
author the rules.
Tools for authoring claims transformation policies

Windows PowerShell cmdlets for Active Directory: This is the preferred and recommended way to author and
set claims transformation policies. These cmdlets provide switches for simple policies and verify rules that are set
for more complex policies.
LDAP: Claims transformation policies can be edited in Active Directory through Lightweight Directory Access
Protocol (LDAP ). However, this is not recommended because the policies have several complex components, and
the tools you use may not validate the policy before writing it to Active Directory. This may subsequently require a
considerable amount of time to diagnose problems.
Active Directory claims transformation rules language

Syntax overview
Here is a brief overview of the syntax and semantics of the language:
The claims transformation rule set consists of zero or more rules. Each rule has two active parts: Select
Condition List and Rule Action. If the Select Condition List evaluates to TRUE, the corresponding rule
action is executed.
Select Condition List has zero or more Select Conditions. All of the Select Conditions must evaluate to
TRUE for the Select Condition List to evaluate to TRUE.
Each Select Condition has a set of zero or more Matching Conditions. All the Matching Conditions
must evaluate to TRUE for the Select Condition to evaluate to TRUE. All of these conditions are evaluated
against a single claim. A claim that matches a Select Condition can be tagged by an Identifier and
referred to in the Rule Action.
Each Matching Condition specifies the condition to match the Type or Value or ValueType of a claim by
using different Condition Operators and String Literals.
When you specify a Matching Condition for a Value, you must also specify a Matching Condition
for a specific ValueType and vice versa. These conditions must be next to each other in the syntax.
ValueType matching conditions must use specific ValueType literals only.
A Rule Action can copy one claim that is tagged with an Identifier or issue one claim based on a claim that
is tagged with an Identifier and/or given String Literals.
Example rule
This example shows a rule that can be used to translate the claims Type between two forests, provided that they use
the same claims ValueTypes and have the same interpretations for claims Values for this type. The rule has one
matching condition and an Issue statement that uses String Literals and a matching claims reference.
C1: [TYPE=="EmployeeType"]
=> ISSUE (TYPE= "EmpType", VALUE = C1.VALUE, VALUETYPE = C1.VALUETYPE);
[TYPE=="EmployeeType"] == Select Condition List with one Matching Condition for claims Type.
ISSUE (TYPE= "EmpType", VALUE = C1.VALUE, VALUETYPE = C1.VALUETYPE) == Rule Action that issues a claims using
string literal and matching claim referred with the Identifier.
Runtime operation
It is important to understand the runtime operation of claims transformations to author the rules effectively. The
runtime operation uses three sets of claims:
1. Input claims set: The input set of claims that are given to the claims transformation operation.
2. Working claims set: Intermediate claims that are read from and written to during the claims
transformation.
3. Output claims set: Output of the claims transformation operation.
Here is a brief overview of the runtime claims transformation operation:
1. Input claims for claims transformation are used to initialize the working claims set.
a. When processing each rule, the working claims set is used for the input claims.
b. The Selection Condition List in a rule is matched against all possible sets of claims from the working
claims set.
c. Each set of matching claims is used to run the action in that rule.
d. Running a rule action results in one claim, which is appended to the output claims set and the
working claims set. Thus, the output from a rule is used as input for subsequent rules in the rule set.
2. The rules in the rule set are processed in sequential order starting with the first rule.
3. When the entire rule set is processed, the output claims set is processed to remove duplicate claims and for
other security issues.The resulting claims are the output of the claims transformation process.
It is possible to write complex claims transformations based on the previous runtime behavior.
Example: Runtime operation
This example shows the runtime operation of a claims transformation that uses two rules.
C1:[Type=="EmpType", Value=="FullTime",ValueType=="string"] =>

Issue(Type=="EmployeeType", Value=="FullTime",ValueType=="string");
[Type=="EmployeeType"] =>
Issue(Type=="AccessType", Value=="Privileged", ValueType=="string");
Input claims and Initial Evaluation Context:
{(Type= "EmpType"),(Value="FullTime"),(ValueType="String")}
{(Type= "Organization"),(Value="Marketing"),(ValueType="String")}
After Processing Rule 1:
Evaluation Context:
{(Type= "Organization"), (Value="Marketing"),(ValueType="String")}
{(Type= "EmployeeType"),(Value="FullTime"),(ValueType="String")}
Output Context:
After Processing Rule 2:

Evaluation Context:
{(Type= "Organization"),(Value="Marketing"),(ValueType="String")}
{(Type= "AccessType"),(Value="Privileged"),(ValueType="String")}
Output Context:
Final Output:
Special rules semantics

The following are special syntax for rules:
1. Empty Rule Set == No Output Claims
2. Empty Select Condition List == Every Claim matches the Select Condition List
Example: Empty Select Condition List
The following rule matches every claim in the working set.
=> Issue (Type = "UserType", Value = "External", ValueType = "string")
3. Empty Select Matching List == Every claim matches the Select Condition List
Example: Empty Matching Conditions
The following rule matches every claim in the working set. This is the basic "Allow -all" rule if it is used alone.
C1:[] => Issule (claim = C1);
Security considerations
Claims that enter a forest
The claims presented by principals that are incoming to a forest need to be inspected thoroughly to ensure that we
allow or issue only the correct claims. Improper claims can compromise the forest security, and this should be a top
consideration when authoring transformation policies for claims that enter a forest.
Active Directory has the following features to prevent misconfiguration of claims that enter a forest:
If a forest trust has no claims transformation policy set for the claims that enter a forest, for security
purposes, Active Directory drops all the principal claims that enter the forest.
If running the rule set on claims that enters a forest results in claims that are not defined in the forest, the
undefined claims are dropped from the output claims.
Claims that leave a forest
Claims that leave a forest present a lesser security concern for the forest than the claims that enter the forest.
Claims are allowed to leave the forest as-is even when there is no corresponding claims transformation policy in
place. It is also possible to issue claims that are not defined in the forest as part of transforming claims that leave
the forest. This is to easily set up across-forest trusts with claims. An administrator can determine if claims that
enter the forest need to be transformed, and set up the appropriate policy. For example, an administrator could set
a policy if there is a need to hide a claim to prevent information disclosure.
Syntax errors in claims transformation rules
If a given claims transformation policy has a rules set that is syntactically incorrect or if there are other syntax or
storage issues, the policy is considered invalid. This is treated differently than the default conditions mentioned
earlier.
Active Directory is unable to determine the intent in this case and goes into a fail-safe mode, where no output
claims are generated on that trust+direction of traversal. Administrator intervention is required to correct the issue.
This could happen if LDAP is used to edit the claims transformation policy. Windows PowerShell cmdlets for Active
Directory have validation in place to prevent writing a policy with syntax issues.
Other language considerations

1. There are several key words or characters that are special in this language (referred to as terminals). These
are presented in the Language terminals table later in this topic. The error messages use the tags for these
terminals for disambiguation.
2. Terminals can sometimes be used as string literals. However, such usage may conflict with the language
definition or have unintended consequences. This kind of usage is not recommended.
3. The rule action cannot perform any type conversions on claim Values, and a rule set that contains such a rule
action is considered invalid. This would cause a runtime error, and no output claims are produced.
4. If a rule action refers to an Identifier that was not used in the Select Condition List portion of the rule, it is an
invalid usage. This would cause a syntax error.
Example: Incorrect Identifier reference
The following rule illustrates an incorrect Identifier used in rule action.
C1:[] => Issue (claim = C2);
Sample transformation rules

Allow all claims of a certain type
Exact type
C1:[type=="XYZ"] => Issue (claim = C1);
Using Regex
C1: [type =~ "XYZ*"] => Issue (claim = C1);
Disallow a certain claim type

Exact type
C1:[type != "XYZ"] => Issue (claim=C1);
Using Regex
C1:[Type !~ "XYZ?"] => Issue (claim=C1);
Examples of rules parser errors

Claims transformation rules are parsed by a custom parser to check for syntax errors. This parser is run by related
Windows PowerShell cmdlets before storing rules in Active Directory. Any errors in parsing the rules, including
syntax errors, are printed on the console. Domain controllers also run the parser before using the rules for
transforming claims, and they log errors in the event log (add event log numbers).
This section illustrates some examples of rules that are written with incorrect syntax and the corresponding syntax
errors that are generated by the parser.
1. Example:
c1;[]=>Issue(claim=c1);
This example has an incorrectly used semicolon in place of a colon.

Error message:
POLICY0002: Could not parse policy data.
Line number: 1, Column number: 2, Error token: ;. Line: 'c1;[]=>Issue(claim=c1 );'.
Parser error: 'POLICY0030: Syntax error, unexpected ';', expecting one of the following: ':' .'
2. Example:
c1:[]=>Issue(claim=c2);
In this example, the Identifier tag in the copy issuance statement is undefined.
Error message:
POLICY0011: No conditions in the claim rule match the condition tag specified in the
CopyIssuanceStatement: 'c2'.
3. Example:
c1:[type=="x1", value=="1", valuetype=="bool"]=>Issue(claim=c1)
"bool" is not a Terminal in the language, and it is not a valid ValueType. Valid terminals are listed in the
following error message.
Error message:
Line number: 1, Column number: 39, Error token: "bool". Line: 'c1:[type=="x1",
value=="1",valuetype=="bool"]=>Issue(claim=c1);'.
Parser error: 'POLICY0030: Syntax error, unexpected 'STRING', expecting one of the following:
'INT64_TYPE' 'UINT64_TYPE' 'STRING_TYPE' 'BOOLEAN_TYPE' 'IDENTIFIER'
4. Example:
c1:[type=="x1", value==1, valuetype=="boolean"]=>Issue(claim=c1);
The numeral 1 in this example is not a valid token in the language, and such usage is not allowed in a
matching condition. It has to be enclosed in double quotes to make it a string.
Error message:
Line number: 1, Column number: 23, Error token: 1. Line: 'c1:[type=="x1", value==1,
valuetype=="bool"]=>Issue(claim=c1 );'.Parser error: 'POLICY0029: Unexpected input.
5. Example:
c1:[type == "x1", value == "1", valuetype == "boolean"] =>
Issue(type = c1.type, value="0", valuetype == "boolean");
This example used a double equal sign (==) instead of a single equal sign (=).
Error message:
Line number: 1, Column number: 91, Error token: ==. Line: 'c1:[type=="x1", value=="1",
valuetype=="boolean"]=>Issue(type=c1.type, value="0", valuetype=="boolean");'.
Parser error: 'POLICY0030: Syntax error, unexpected '==', expecting one of the following: '='
6. Example:
c1:[type=="x1", value=="boolean", valuetype=="string"] =>
Issue(type=c1.type, value=c1.value, valuetype = "string");
This example is syntactically and semantically correct. However, using "boolean" as a string value is bound to
cause confusion, and it should be avoided. As previously mentioned, using language terminals as claims
values should be avoided where possible.
Language terminals
The following table lists the complete set of terminal strings and the associated language terminals that are used in
the claims transformation rules language. These definitions use case-insensitive UTF -16 strings.
STRING TERMINAL
"=>" IMPLY
";" SEMICOLON
":" COLON
STRING TERMINAL
"," COMMA
"." DOT
"[" O_SQ_BRACKET
"]" C_SQ_BRACKET
"(" O_BRACKET
")" C_BRACKET
"==" EQ
"!=" NEQ
"=~" REGEXP_MATCH
"!~" REGEXP_NOT_MATCH
"=" ASSIGN
"&&" AND
"issue" ISSUE
"type" TYPE
"value" VALUE
"valuetype" VALUE_TYPE
"claim" CLAIM
"[_A-Za-z][_A-Za-z0-9]*" IDENTIFIER
"\"[^\"\n]*\"" STRING
"uint64" UINT64_TYPE
"int64" INT64_TYPE
"string" STRING_TYPE
"boolean" BOOLEAN_TYPE
Language syntax
The following claims transformation rules language is specified in ABNF form. This definition uses the terminals
that are specified in the previous table in addition to the ABNF productions defined here. The rules must be
encoded in UTF -16, and the string comparisons must be treated as case insensitive.
Rule_set = ;/*Empty*/
/ Rules
Rules = Rule
/ Rule Rules
Rule = Rule_body
Rule_body = (Conditions IMPLY Rule_action SEMICOLON)
Conditions = ;/*Empty*/
/ Sel_condition_list
Sel_condition_list = Sel_condition
/ (Sel_condition_list AND Sel_condition)
Sel_condition = Sel_condition_body
/ (IDENTIFIER COLON Sel_condition_body)
Sel_condition_body = O_SQ_BRACKET Opt_cond_list C_SQ_BRACKET
Opt_cond_list = /*Empty*/
/ Cond_list
Cond_list = Cond
/ (Cond_list COMMA Cond)
Cond = Value_cond
/ Type_cond
Type_cond = TYPE Cond_oper Literal_expr
Value_cond = (Val_cond COMMA Val_type_cond)
/(Val_type_cond COMMA Val_cond)
Val_cond = VALUE Cond_oper Literal_expr
Val_type_cond = VALUE_TYPE Cond_oper Value_type_literal
claim_prop = TYPE
/ VALUE
Cond_oper = EQ
/ NEQ
/ REGEXP_MATCH
/ REGEXP_NOT_MATCH
Literal_expr = Literal
/ Value_type_literal
Expr = Literal
/ Value_type_expr
/ (IDENTIFIER DOT claim_prop)
Value_type_expr = Value_type_literal
/(IDENTIFIER DOT VALUE_TYPE)
Value_type_literal = INT64_TYPE
/ UINT64_TYPE
/ STRING_TYPE
/ BOOLEAN_TYPE
Literal = STRING
Rule_action = ISSUE O_BRACKET Issue_params C_BRACKET
Issue_params = claim_copy
/ claim_new
claim_copy = CLAIM ASSIGN IDENTIFIER
claim_new = claim_prop_assign_list
claim_prop_assign_list = (claim_value_assign COMMA claim_type_assign)
/(claim_type_assign COMMA claim_value_assign)
claim_value_assign = (claim_val_assign COMMA claim_val_type_assign)
/(claim_val_type_assign COMMA claim_val_assign)
claim_val_assign = VALUE ASSIGN Expr
claim_val_type_assign = VALUE_TYPE ASSIGN Value_type_expr
Claim_type_assign = TYPE ASSIGN Expr
Appendix A: Dynamic Access Control Glossary
Following are the list of terms and definitions that are included in the Dynamic Access Control scenario.
TERM DEFINITION
Automatic classification Classification that occurs based on classification properties

that are determined by classification rules configured by an
administrator.
CAPID Central access policy ID. This ID references a specific central

access policy, and it is used to reference the policy from the
security descriptor of files and folders.
Central access rule A rule that includes a condition and an access expression.
Central access policy Policies that are authored and hosted in Active Directory.
Claims-based access control A paradigm that utilizes claims to make access control
decisions to resources.
Classification The process of determining the classification properties of

resources and assigning these properties to the metadata that
is associated with the resources. See also REF
AutomaticClassification \h \* MERGEFORMAT Automatic
classification, REF InheritedClassification \h \* MERGEFORMAT
Inherited classification, and REF ManualClassification \h \*
MERGEFORMAT Manual classification.
Device claim A claim that is associated with the system. With user claims, it
is included in the token of a user attempting to access a
resource.
Discretionary access control list (DACL) An access control list that identifies trustees who are allowed
or denied access to a securable resource. It can be modified at
the discretion of the resource owner.
Resource property Properties (such as labels) that describe a file and are assigned
to files by using automatic classification or manual
classification. Examples include: Sensitivity, Project, and
Retention period.
File Server Resource Manager A feature in the Windows Server operating system that offers
management of folder quotas, file screening, storage reports,
file classification, and file management jobs on a file server.
Folder properties and labels Properties and labels that describe a folder and are assigned
manually by administrators and folder owners. These
properties assign default property values to the files within
these folders, for example, Secrecy or Department.
TERM DEFINITION
Group Policy A set of rules and policies that controls the working
environment of users and computers in an Active Directory
environment.
Near real time classification Automatic classification that is performed shortly after a file is
created or modified.
Near real-time file management tasks File management tasks that are performed shortly after (a file
is created or modified. These tasks are triggered by the Near
real-time classification.
Organizational Unit (OU) An Active Directory container that represents hierarchical,

logical structures within an organization. It is the smallest
scope to which Group Policy settings are applied.
Secure property A classification property that the authorization runtime can

trust to be a valid assertion about the resource at a certain
point-in-time. In claims-based access control, a secure
property that is assigned to a resource is treated as a resource
claim.
Security descriptor A data structure that contains security information associated

with a securable resource, such as access control lists.
Security descriptor definition language A specification that describes the information in a security
descriptor as a text string.
Staging policy A central access policy that is not yet in effect.
System access control list (SACL) An access control list that specifies the types of access
attempts by particular trustees for which audit records need to
be generated.
User claim Attributes of a user that are provided within the user security
token. Examples include: Department, Company, Project, and
Security clearance. Information in the user token from systems
prior to Windows Server 2012 , such as the security groups
that the user is part of, can also be considered user claims.
Some user claims are provided through Active Directory and
others are calculated dynamically, such as whether the user
logged in with a smart card.
User token A data object that identifies a user and the user claims and
device claims that are associated with that user. It is used to
authorize the user's access to resources.
See Also
Appendix B: Setting Up the Test Environment
This topic outlines the steps to build a hands-on lab to test Dynamic Access Control. The instructions are meant to
be followed sequentially because there are many components that have dependencies.
Prerequisites
Hardware and software requirements
Requirements for setting up the test lab:
A host server running Windows Server 2008 R2 with SP1 and Hyper-V
A copy of the Windows Server 2012 ISO
A copy of the Windows 8 ISO
Microsoft Office 2010
A server running Microsoft Exchange Server 2003 or later
You need to build the following virtual machines to test the Dynamic Access Control scenarios:
DC1 (domain controller)
DC2 (domain controller)
FILE1 (file server and Active Directory Rights Management Services)
SRV1 (POP3 and SMTP server)
CLIENT1 (client computer with Microsoft Outlook)
The passwords for the virtual machines should be as follows:
BUILTIN\Administrator: pass@word1
Contoso\Administrator: pass@word1
All other accounts: pass@word1
Build the test lab virtual machines

Install the Hyper-V role
You need to install the Hyper-V role on a computer running Windows Server 2008 R2 with SP1.
To i n st a l l t h e H y p e r- V R o l e
1. Click Start, and then click Server Manager.

2. In the Roles Summary area of the Server Manager main window, click Add Roles.
3. On the Select Server Roles page, click Hyper-V.
4. On the Create Virtual Networks page, click one or more network adapters if you want to make their
network connection available to virtual machines.
5. On the Confirm Installation Selections page, click Install.
6. The computer must be restarted to complete the installation. Click Close to finish the wizard, and then click
Yes to restart the computer.
7. After you restart the computer, sign in with the same account you used to install the role. After the Resume
Configuration Wizard completes the installation, click Close to finish the wizard.
Create an internal virtual network
Now you will create an internal virtual network called ID_AD_Network.
To c r e a t e a v i r t u a l n e t w o r k
1. Open Hyper-V Manager.

2. From the Actions menu, click Virtual Network Manager.
3. Under Create virtual network, select the Internal.
4. Click Add. The New Virtual Network page appears.
5. Type ID_AD_Network as the name for the new network. Review the other properties and modify them if
necessary.
6. Click OK to create the virtual network and close Virtual Network Manager, or click Apply to create the
virtual network and continue using Virtual Network Manager.
Build the domain controller
Build a virtual machine to be used as the domain controller (DC1). Install the virtual machine using Windows
Server 2012 ISO, and name it DC1.
To i n st a l l A c t i v e D i r e c t o r y D o m a i n Se r v i c e s
1. Connect the virtual machine to the ID_AD_Network. Sign in to the DC1 as Administrator with the password
pass@word1.
2. In Server Manager, click Manage, and then click Add Roles and Features.
3. On the Before you begin page, click Next.
4. On the Select installation type page, click Role-based or Feature-based Install, and then click Next.
5. On the Select destination server page, click Next.
6. On the Select server roles page, click Active Directory Domain Services. In the Add Roles and
Features Wizard dialog box, click Add Features, and then click Next.
7. On the Select features page, click Next.
8. On the Active Directory Domain Services page, review the information, and then click Next.
9. On the Confirm installation selections page, click Install. The Feature installation progress bar on the
Results page indicates that the role is being installed.
10. On the Results page, verify that the installation succeeded, and click Close. In Server Manager, click the
warning icon with an exclamation mark on top right corner of the screen, next to Manage. In the Tasks list,
click the Promote this server to a domain controller link.
11. On the Deployment Configuration page, click Add a new forest, type the name of the root domain,
contoso.com, and then click Next.
12. On the Domain Controller Options page, select the domain and forest functional levels as Windows
Server 2012, specify the DSRM password pass@word1, and then click Next.
13. On the DNS Options page, click Next.
14. On the Additional Options page, click Next.
15. On the Paths page, type the locations for the Active Directory database, log files, and SYSVOL folder (or
accept default locations), and then click Next.
16. On the Review Options page, confirm your selections, and then click Next.
17. On the Prerequisites Check page, confirm that the prerequisites validation is completed, and then click
Install.
18. On the Results page, verify that the server was successfully configured as a domain controller, and then click
Close.
19. Restart the server to complete the AD DS installation. (By default, this happens automatically.)
Create the following users by using Active Directory Administrative Center.
C r e a t e u se r s a n d g r o u p s o n D C 1
1. Sign in to contoso.com as Administrator. Launch Active Directory Administrative Center.

2. Create the following security groups:
GROUP NAME EMAIL ADDRESS
FinanceAdmin financeadmin@contoso.com
FinanceException financeexception@contoso.com
3. Create the following organizational unit (OU ):
OU NAME COMPUTERS
FileServerOU FILE1
4. Create the following users with the attributes indicated:
COUNTRY/REGIO
USER USERNAME EMAIL ADDRESS DEPARTMENT GROUP N
Myriam MDelesalle MDelesalle@con Finance US

Delesalle toso.com
Miles Reid MReid MReid@contoso Finance FinanceAdmin US

.com
Esther Valle EValle EValle@contoso. Operations FinanceExceptio US

com n
Maira Wenzel MWenzel MWenzel@cont HR US

oso.com
Jeff Low JLow JLow@contoso.c HR US

om
COUNTRY/REGIO
USER USERNAME EMAIL ADDRESS DEPARTMENT GROUP N
RMS Server rms rms@contoso.c

om
For more information about creating security groups, see Create a New Group on the Windows Server
website.
To c r e a t e a G r o u p P o l i c y O b j e c t
1. Hover the cursor on the upper right corner of screen and click the search icon. In the Search box, type group
policy management, and click Group Policy Management.
2. Expand Forest: contoso.com, and then expand Domains, navigate to contoso.com, expand
(contoso.com ), and then select FileServerOU. Right-click Create a GPO in this domain and Link it
here
3. Type a descriptive name for the GPO, such as FlexibleAccessGPO, and then click OK.
To e n a b l e D y n a m i c A c c e ss C o n t r o l fo r c o n t o so .c o m
1. Open the Group Policy Management Console, click contoso.com, and then double-click Domain
Controllers.
2. Right-click Default Domain Controllers Policy, and select Edit.
4. Double-click KDC support for claims, compound authentication, and Kerberos armoring and select
the option next to Enabled. You need to enable this setting to use Central Access Policies.
5. Open an elevated command prompt, and run the following command:
gpupdate /force
Build the file server and AD RMS server (FILE1)

1. Build a virtual machine with the name FILE1 from the Windows Server 2012 ISO.
2. Connect the virtual machine to the ID_AD_Network.
3. Join the virtual machine to the contoso.com domain, and then sign in to FILE1 as contoso\administrator
using the password pass@word1.
Install File Services Resource Manager
To i n s t a l l t h e F i l e Se rv i c e s ro l e a n d t h e F i l e Se rv e r R e s o u rc e M a n a g e r
1. In Server Manager, click Add Roles and Features.

3. On the Select installation type page, click Next.
4. On the Select destination server page, click Next.
5. On the Select Server Roles page, expand File and Storage Services, select the check-box next to File and
iSCSI Services, expand, and select File Server Resource Manager.
In the Add Roles and Features Wizard, click Add Features, and then click Next.
7. On the Confirm installation selections page, click Install.
8. On the Installation progress page, click Close.
Install the Microsoft Office Filter Packs on the file server
You should install the Microsoft Office Filter Packs on Windows Server 2012 to enable IFilters for a wider array of
Office files than are provided by default. Windows Server 2012 does not have any IFilters for Microsoft Office Files
installed by default, and the file classification infrastructure uses IFilters to perform content analysis.
To download and install the IFilters, see Microsoft Office 2010 Filter Packs.
Configure email notifications on FILE1
When you create quotas and file screens, you have the option of sending email notifications to users when their
quota limit is approaching or after they have attempted to save files that have been blocked. If you want to
routinely notify certain administrators of quota and file screening events, you can configure one or more default
recipients. To send these notifications, you must specify the SMTP server to be used for forwarding the email
messages.
To c o n f i g u re e ma i l o p t i o n s i n F i l e Se rv e r R e s o u rc e M a n a g e r
2. In the File Server Resource Manager interface, right-click File Server Resource Manager, and then click
Configure options. The File Server Resource Manager Options dialog box opens.
3. On the E -mail Notifications tab, under SMTP server name or IP address, type the host name or the IP
address of the SMTP server that will forward email notifications.
4. If you want to routinely notify certain administrators of quota or file screening events, under Default
administrator recipients, type each email address such as fileadmin@contoso.com. Use the format
account@domain, and use semicolons to separate multiple accounts.
Create groups on FILE1
To c re a t e s e c u ri t y g ro u p s o n F I L E 1
1. Sign in to FILE1 as contoso\administrator, with the password: pass@word1.

2. Add NT AUTHORITY\Authenticated Users to the WinRMRemoteWMIUsers__ group.
Create files and folders on FILE1
1. Create a new NTFS volume on FILE1 and then create the following folder: D:\Finance Documents.
2. Create the following files with the details specified:
Finance Memo.docx: Add some finance related text in the document. For example, 'The business
rules about who can access finance documents have changed. Finance documents are now only
accessed by members of the FinanceExpert group. No other departments or groups have access.' You
need to evaluate the impact of this change before implementing it in the environment. Ensure that
this document has CONTOSO CONFIDENTIAL as the footer on every page.
Request for Approval to Hire.docx: Create a form in this document that collects applicant
information. You must have the following fields in the document: Applicant Name, Social Security
number, Job Title, Proposed Salary, Starting Date, Supervisor name, Department. Add an
additional section in the document that has a form for Supervisor Signature, Approved Salary,
Conformation of Offer, and Status of Offer.
Make the document rights-management enabled.
Word Document1.docx: Add some test content to this document.
Word Document2.docx: Add test content to this document.
Workbook1.xlsx
Workbook2.xlsx
Create a folder on the desktop called Regular Expressions. Create a text document under the folder
called RegEx-SSN. Type the following content in the file, and then save and close the file:
^(?!000)([0-7]\d{2}|7([0-7]\d|7[012]))([ -]?)(?!00)\d\d\3(?!0000)\d{4}$
3. Share the folder D:\Finance Documents as Finance Documents and allow everyone to have Read and Write
access to the share.
NOTE
Central access policies are not enabled by default on the system or boot volume C:.
Install Active Directory Rights Management Services

Add the Active Directory Rights Management Services (AD RMS ) and all required features through Server
Manager. Choose all the defaults.
To i n s t a l l A c t i v e Di re c t o ry R i g h t s M a n a g e me n t Se rv i c e s
1. Sign in to the FILE1 as CONTOSO\Administrator or as a member of the Domain Admins group.
IMPORTANT
In order to install the AD RMS server role the installer account (in this case, CONTOSO\Administrator) will have to be
given membership in both the local Administrators group on the server computer where AD RMS is to be installed as
well as membership in the Enterprise Admins group in Active Directory.
2. In Server Manager, click Add Roles and Features. The Add Roles and Features Wizard appears.
3. On the Before you Begin screen, click Next.
4. On the Select Installation Type screen, click Role/Feature Based Install, and then click Next.
5. On the Select Server Targets screen, click Next.
6. On the Select Server Roles screen, select the box next to Active Directory Rights Management
Services, and then click Next.
7. In the Add features that are required for Active Directory Rights Management Services? dialog box,
click Add Features.
8. On the Select Server Roles screen, click Next.
9. On the Select Features to Install screen, click Next.
10. On the Active Directory Rights Management Services screen, click Next.
11. On the Select Role Services screen, click Next.
12. On the Web Server Role (IIS ) screen, click Next.
13. On the Select Role Services screen, click Next.
14. On the Confirm Installation Selections screen, click Install.
15. After the installation has completed, on the Installation Progress screen, click Perform additional
configuration. The AD RMS Configuration Wizard appears.
16. On the AD RMS screen, click Next.
17. On the AD RMS Cluster screen, select Create a new AD RMS root cluster and then click Next.
18. On the Configuration Database screen, click Use Windows Internal Database on this server, and then
click Next.
NOTE
Using the Windows Internal Database is recommended for test environments only because it does not support more
than one server in the AD RMS cluster. Production deployments should use a separate database server.
19. On the Service Account screen, in Domain User Account, click Specify and then specify the user name
(contoso\rms), and Password (pass@word1) and click OK, and then click Next.
20. On the Cryptographic Mode screen, click Cryptographic Mode 2.
21. On the Cluster Key Storage screen, click Next.
22. On the Cluster Key Password screen, in the Password and Confirm password boxes, type pass@word1,
and then click Next.
23. On the Cluster Web Site screen, make sure that Default Web Site is selected, and then click Next.
24. On the Cluster Address screen, select the Use an unencrypted connection option, in the Fully
Qualified Domain Name box, type FILE1.contoso.com, and then click Next.
25. On the Licensor Certificate Name screen, accept the default name (FILE1) in the text box and click Next.
26. On the SCP Registration screen, select Register SCP now, and then click Next.
27. On the Confirmation screen, click Install.
28. On the Results screen, click Close, and then click Close on Installation Progress screen. When complete,
log off and log on as contoso\rms using the password provided (pass@word1).
29. Launch the AD RMS console and navigate to Rights Policy Templates.
To open the AD RMS console, in Server Manager, click Local Server in the console tree, then click Tools,
and then click Active Directory Rights Management Services.
30. Click the Create Distributed Rights Policy template located on the right panel, click Add, and select the
following information:
Language: US English
Name: Contoso Finance Admin Only
Description: Contoso Finance Admin Only
Click Add, and then click Next.
31. Under the Users and Rights section, click Users and rights, click Add, type financeadmin@contoso.com,
and click OK.
32. Select Full Control, and leave Grant owner (author) full control right with no expiration selected.
33. Click though the remaining tabs with no changes, and then click Finish. Sign in as
CONTOSO\Administrator.
34. Browse to the folder, C:\inetpub\wwwroot\_wmcs\certification, select the ServerCertification.asmx file, and
add Authenticated Users to have Read and Write permissions to the file.
35. Open Windows PowerShell and run Get-FsrmRmsTemplate . Verify that you are able to see the RMS template
you created in the previous steps in this procedure with this command.
IMPORTANT
If you want your file servers to immediately change so you can test them, you need to do the following:
1. On the file server, FILE1, open an elevated command prompt, and run the following commands:
gpupdate /force.
NLTEST /SC_RESET:contoso.com
2. On the domain controller (DC1), replicate Active Directory.
For more information about steps to force the replication of Active Directory, see Active Directory Replication
Optionally, instead of using the Add Roles and Features Wizard in Server Manager, you can use Windows
PowerShell to install and configure the AD RMS server role as show in the following procedure.
To i n s t a l l a n d c o n f i g u re a n A D R M S c l u s t e r i n W i n d o w s Se rv e r 2012 u s i n g W i n d o w s P o w e r Sh e l l
1. Logon on as CONTOSO\Administrator with the password: pass@word1.
IMPORTANT
In order to install the AD RMS server role the installer account (in this case, CONTOSO\Administrator) will have to be
given membership in both the local Administrators group on the server computer where AD RMS is to be installed as
well as membership in the Enterprise Admins group in Active Directory.
2. On the Server desktop, right-click the Windows PowerShell icon on the taskbar and select Run as
Administrator to open a Windows PowerShell prompt with administrative privileges.
3. To use Server Manager cmdlets to install the AD RMS server role, type:
Add-WindowsFeature ADRMS '"IncludeAllSubFeature '"IncludeManagementTools
4. Create the Windows PowerShell drive to represent the AD RMS server you are installing.
For example, to create a Windows PowerShell drive named RC to install and configure the first server in an
AD RMS root cluster, type:
Import-Module ADRMS
New-PSDrive -PSProvider ADRMSInstall -Name RC -Root RootCluster
5. Set properties on objects in the drive namespace that represent required configuration settings.
For example, to set the AD RMS service account, at the Windows PowerShell command prompt, type:
$svcacct = Get-Credential
When the Windows security dialog box appears, type the AD RMS service account domain user name
CONTOSO\RMS and the assigned password.
Next, to assign the AD RMS service account to the AD RMS cluster settings, type the following:
Set-ItemProperty -Path RC:\ -Name ServiceAccount -Value $svcacct
Next, to set the AD RMS server to use the Windows Internal Database, at the Windows PowerShell
command prompt, type:
Set-ItemProperty -Path RC:\ClusterDatabase -Name UseWindowsInternalDatabase -Value $true
Next, to securely store the cluster key password in a variable, at the Windows PowerShell command prompt,
type:
$password = Read-Host -AsSecureString -Prompt "Password:"
Type the cluster key password, and then press the ENTER key.
Next, to assign the password to your AD RMS installation, at the Windows PowerShell command prompt,
type:
Set-ItemProperty -Path RC:\ClusterKey -Name CentrallyManagedPassword -Value $password
Next, to set the AD RMS cluster address, at the Windows PowerShell command prompt, type:
Set-ItemProperty -Path RC:\ -Name ClusterURL -Value "http://file1.contoso.com:80"
Next, to assign the SLC name for your AD RMS installation, at the Windows PowerShell command prompt,
type:
Set-ItemProperty -Path RC:\ -Name SLCName -Value "FILE1"
Next, to set the service connection point (SCP ) for the AD RMS cluster, at the Windows PowerShell
Set-ItemProperty -Path RC:\ -Name RegisterSCP -Value $true
6. Run the Install-ADRMS cmdlet. In addition to installing the AD RMS server role and configuring the
server, this cmdlet also installs other features required by AD RMS if necessary.
For example, to change to the Windows PowerShell drive named RC and install and configure AD RMS,
type:
Set-Location RC:\
Install-ADRMS -Path.
Type "Y" when the cmdlet prompts you to confirm you want to start the installation.
7. Log out as CONTOSO\Administrator and log on as CONTOSO\RMS using the provided password
("pass@word1").
IMPORTANT
In order to manage the AD RMS server the account you are logged on to and using to manage the server (in this
case, CONTOSO\RMS) will have to be given membership in both the local Administrators group on the AD RMS
server computer as well as membership in the Enterprise Admins group in Active Directory.
8. On the Server desktop, right-click the Windows PowerShell icon on the taskbar and select Run as
Administrator to open a Windows PowerShell prompt with administrative privileges.
9. Create the Windows PowerShell drive to represent the AD RMS server you are configuring.
For example, to create a Windows PowerShell drive named RC to configure the AD RMS root cluster, type:
Import-Module ADRMSAdmin `
New-PSDrive -PSProvider ADRMSAdmin -Name RC -Root http://localhost -Force -Scope Global
10. To create new rights template for the Contoso finance administrator and assign it user rights with full control
in your AD RMS installation, at the Windows PowerShell command prompt, type:
New-Item -Path RC:\RightsPolicyTemplate '"LocaleName en-us -DisplayName "Contoso Finance Admin Only" -
Description "Contoso Finance Admin Only" -UserGroup financeadmin@contoso.com -Right ('FullControl')
11. To verify that you can see the new rights template for the Contoso finance administrator, at the Windows
PowerShell command prompt:
Get-FsrmRmsTemplate
Review the output of this cmdlet to confirm the RMS template you created in the previous step is present.
Build the mail server (SRV1)
SRV1 is the SMTP/POP3 mail server. You need to set it up so that you can send email notifications as part of the
Access-Denied assistance scenario.
Configure Microsoft Exchange Server on this computer. For more information, see How to Install Exchange Server.
Build the client virtual machine (CLIENT1)
To b u i l d t h e c l i e n t v i r t u a l m a c h i n e
1. Connect the CLIENT1 to the ID_AD_Network.

2. Install Microsoft Office 2010.
3. Sign in as Contoso\Administrator, and use the following information to configure Microsoft Outlook.
Your name: File Administrator
Email address: fileadmin@contoso.com
Account type: POP3
Incoming mail server: Static IP address of SRV1
Outgoing mail server: Static IP address of SRV1
User name: fileadmin@contoso.com
Remember password: Select
4. Create a shortcut to Outlook on the contoso\administrator desktop.
5. Open Outlook and address all the 'first time launched' messages.
6. Delete any test messages that were generated.
7. Create a new short cut on desktop for all users on the client virtual machine that points to \\FILE1\Finance
Documents.
8. Reboot as needed.
En a b l e A c c e ss- D e n i e d a ssi st a n c e o n t h e c l i e n t v i r t u a l m a c h i n e
1. Open Registry Editor, and navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Explorer.
Set EnableShellExecuteFileStreamCheck to 1.
Value: DWORD
Lab setup for deploying claims across forests scenario

Build a virtual machine for DC2
Build a virtual machine from the Windows Server 2012 ISO.
Create the virtual machine name as DC2.
Connect the virtual machine to the ID_AD_Network.
IMPORTANT
Joining virtual machines to a domain and deploying claim types across forests require that the virtual machines be able to
resolve the FQDNs of the relevant domains. You may have to manually configure the DNS settings on the virtual machines to
accomplish this. For more information, see Configuring a virtual network.
All the virtual machine images (servers and clients) must be reconfigured to use a static IP version 4 (IPv4) address and
Domain Name System (DNS) client settings. For more information, see Configure a DNS Client for Static IP Address.
Set up a new forest called adatum.com

To i n st a l l A c t i v e D i r e c t o r y D o m a i n Se r v i c e s
1. Connect the virtual machine to the ID_AD_Network. Sign in to the DC2 as Administrator with the password
Pass@word1.
2. In Server Manager, click Manage, and then click Add Roles and Features.
4. On the Select Installation Type page, click Role-based or Feature-based Install, and then click Next.
5. On the Select destination server page, click Select a server from the server pool, click the names of the
server where you want to install Active Directory Domain Services (AD DS ), and then click Next.
6. On the Select Server Roles page, click Active Directory Domain Services. In the Add Roles and
7. On the Select Features page, click Next.
8. On the AD DS page, review the information, and then click Next.
9. On the Confirmation page, click Install. The Feature installation progress bar on the Results page indicates
that the role is being installed.
10. On the Results page, verify that the installation succeeded, and then click the warning icon with an
exclamation mark on top right corner of the screen, next to Manage. In the Tasks list, click the Promote this
server to a domain controller link.
IMPORTANT
If you close the installation wizard at this point rather than click Promote this server to a domain controller, you
can continue the AD DS installation by clicking Tasks in Server Manager.
11. On the Deployment Configuration page, click Add a new forest, type the name of the root domain,
adatum.com, and then click Next.
12. On the Domain Controller Options page, select the domain and forest functional levels as Windows
Server 2012, specify the DSRM password pass@word1, and then click Next.
13. On the DNS Options page, click Next.
14. On the Additional Options page, click Next.
accept default locations), and then click Next.
16. On the Review Options page, confirm your selections, and then click Next.
17. On the Prerequisites Check page, confirm that the prerequisites validation is completed, and then click
Install.
18. On the Results page, verify that the server was successfully configured as a domain controller, and then click
Close.
19. Restart the server to complete the AD DS installation. (By default, this happens automatically.)
IMPORTANT
To ensure that the network is configured properly, after you have set up both the forests, you must do the following:
Sign in to adatum.com as adatum\administrator. Open a Command Prompt window, type nslookup contoso.com, and
then press ENTER.
Sign in to contoso.com as contoso\administrator. Open a Command Prompt window, type nslookup adatum.com, and
then press ENTER.
If these commands execute without errors, the forests can communicate with each other. For more information on nslookup
errors, see the troubleshooting section in the topic Using NSlookup.exe
Set contoso.com as a trusting forest to adatum.com

In this step, you create a trust relationship between the Adatum Corporation site and the Contoso, Ltd. site.
To se t C o n t o so a s a t r u st i n g fo r e st t o A d a t u m
1. Sign in to DC2 as administrator. On the Start screen, type domain.msc.

2. In the console tree, right-click adatum.com, and then click Properties.
3. On the Trusts tab, click New Trust, and then click Next.
4. On the Trust Name page, type contoso.com, in the Domain Name System (DNS ) name field, and then
click Next.
5. On the Trust Type page, click Forest Trust, and then click Next.
6. On the Direction of Trust page, click Two-way.
7. On the Sides of Trust page, click Both this domain and the specified domain, and then click Next.
8. Continue to follow the instructions in the wizard.
Create additional users in the Adatum forest
Create the user Jeff Low with the password pass@word1, and assign the company attribute with the value
Adatum.
To c r e a t e a u se r w i t h t h e C o m p a n y a t t r i b u t e
1. Open an elevated command prompt in Windows PowerShell, and paste the following code:
New-ADUser `
-SamAccountName jlow `
-Name "Jeff Low" `
-UserPrincipalName jlow@adatum.com `
-AccountPassword (ConvertTo-SecureString `
-AsPlainText "pass@word1" -Force) `
-Enabled $true `
-PasswordNeverExpires $true `
-Path 'CN=Users,DC=adatum,DC=com' `
-Company Adatum`
Create the Company claim type on adataum.com

To c r e a t e a c l a i m t y p e b y u si n g W i n d o w s P o w e r Sh e l l
1. Sign in to adatum.com as an administrator.

2. Open an elevated command prompt in Windows PowerShell, and type the following code:
New-ADClaimType `
-AppliesToClasses:@('user') `
-Description:"Company" `
-DisplayName:"Company" `
-ID:"ad://ext/Company:ContosoAdatum" `
-IsSingleValued:$true `
-Server:"adatum.com" `
-SourceAttribute:Company `
-SuggestedValues:@((New-Object Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry("Contoso",
"Contoso", "")), (New-Object Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry("Adatum",
"Adatum", ""))) `
Enable the Company resource property on contoso.com

To e n a b l e t h e C o m p a n y r e so u r c e p r o p e r t y o n c o n t o so .c o m
1. Sign in to contoso.com as an administrator.

2. In Server Manager, click Tools, and then click Active Directory Administrative Center.
3. In the left pane of Active Directory Administrative Center, click Tree View. In the left pane, click Dynamic
Access Control, and then double-click Resource Properties.
4. Select Company from the Resource Properties list, right-click and select Properties. In the Suggested
Values section, click Add to add the suggested values: Contoso and Adatum, and then click OK twice.
5. Select Company from the Resource Properties list, right-click and select Enable.
Enable Dynamic Access Control on adatum.com
To e n a b l e D y n a m i c A c c e ss C o n t r o l fo r a d a t u m .c o m
1. Sign in to adatum.com as an administrator.

2. Open the Group Policy Management Console, click adatum.com, and then double-click Domain
Controllers.
3. Right-click Default Domain Controllers Policy, and select Edit.
5. Double-click KDC support for claims, compound authentication, and Kerberos armoring and select
the option next to Enabled. You need to enable this setting to use Central Access Policies.
6. Open an elevated command prompt, and run the following command:
gpupdate /force
Create the Company claim type on contoso.com

To c r e a t e a c l a i m t y p e b y u si n g W i n d o w s P o w e r Sh e l l

2. Open an elevated command prompt in Windows PowerShell, then type the following code:
New-ADClaimType '"SourceTransformPolicy `
'"DisplayName 'Company' `
'"ID 'ad://ext/Company:ContosoAdatum' `
'"IsSingleValued $true `
'"ValueType 'string' `
Create the central access rule

To c r e a t e a c e n t r a l a c c e ss r u l e
1. In the left pane of Active Directory Administrative Center, click Tree View. In the left pane, click Dynamic
Access Control, and then click Central Access Rules.
2. Right-click Central Access Rules, click New, and then Central Access Rule.
3. In the Name field, type AdatumEmployeeAccessRule.
4. In the Permissions section, select the Use following permissions as current permissions option, click
Edit, and then click Add. Click the Select a principal link, type Authenticated Users, and then click OK.
5. In the Permission Entry for Permissions dialog box, click Add a condition, and enter the following
conditions: [User] [Company] [Equals] [Value] [Adatum ]. Permissions should be Modify, Read and
Execute, Read, Write.
6. Click OK.
7. Click OK three times to finish and return to Active Directory Administrative Center.
New-ADCentralAccessRule `
-CurrentAcl:"O:SYG:SYD:AR(A;;FA;;;OW)(A;;FA;;;BA)(A;;FA;;;SY)(XA;;0x1301bf;;;AU;
(@USER.ad://ext/Company:ContosoAdatum == `"Adatum`"))" `
-Name:"AdatumEmployeeAccessRule" `
-ProposedAcl:$null `
-ProtectedFromAccidentalDeletion:$true `
Create the central access policy

To c r e a t e a c e n t r a l a c c e ss p o l i c y

2. Open an elevated command prompt in Windows PowerShell, and then paste the following code:
New-ADCentralAccessPolicy "Adatum Only Access Policy"

Add-ADCentralAccessPolicyMember "Adatum Only Access Policy" `
-Member "AdatumEmployeeAccessRule" `
Publish the new policy through Group Policy
To a p p l y t h e c e n t r a l a c c e ss p o l i c y a c r o ss fi l e se r v e r s t h r o u g h G r o u p P o l i c y
1. On the Start screen, type Administrative Tools, and in the Search bar, click Settings. In the Settings
results, click Administrative Tools. Open the Group Policy Management Console from the Administrative
Tools folder.
TIP
If the Show Administrative tools setting is disabled, the Administrative Tools folder and its contents will not appear
in the Settings results.
2. Right-click the contoso.com domain, click Create a GPO in this domain and Link it here
3. Type a descriptive name for the GPO, such as AdatumAccessGPO, and then click OK.
To a p p l y t h e c e n t r a l a c c e ss p o l i c y t o t h e fi l e se r v e r t h r o u g h G r o u p P o l i c y
1. On the Start screen, type Group Policy Management, in the Search box. Open Group Policy
Management from the Administrative Tools folder.
TIP
If the Show Administrative tools setting is disabled, the Administrative Tools folder and its contents will not appear
in the Settings results.
2. Navigate to and select Contoso as follows: Group Policy Management\Forest:

contoso.com\Domains\contoso.com.
3. Right-click the AdatumAccessGPO policy, and select Edit.
4. In Group Policy Management Editor, click Computer Configuration, expand Policies, expand Windows
Settings, and then click Security Settings.
5. Expand File System, right-click Central Access Policy, and then click Manage Central access policies.
6. In the Central Access Policies Configuration dialog box, click Add, select Adatum Only Access Policy,
and then click OK.
7. Close the Group Policy Management Editor. You have now added the central access policy to Group Policy.
Create the Earnings folder on the file server
Create a new NTFS volume on FILE1, and create the following folder: D:\Earnings.
NOTE
Central access policies are not enabled by default on the system or boot volume C:.
Set classification and apply the central access policy on the Earnings folder
To a ssi g n t h e c e n t r a l a c c e ss p o l i c y o n t h e fi l e se r v e r
1. In Hyper-V Manager, connect to server FILE1. Sign in to the server by using Contoso\Administrator, with
the password pass@word1.
2. Open an elevated command prompt and type: gpupdate /force. This will ensure that your Group Policy
changes will take effect on your server.
3. You also need to refresh the Global Resource Properties from Active Directory. Open Windows PowerShell,
type Update-FSRMClassificationpropertyDefinition , and then press ENTER. Close Windows PowerShell.
4. Open Windows Explorer, and navigate to D:\EARNINGS. Right-click the Earnings folder, and click
Properties.
5. Click the Classification tab. Select Company, and then select Adatum in the Value field.
6. Click Change, select Adatum Only Access Policy from the drop-down menu, and then click Apply.
7. Click the Security tab, click Advanced, and then click the Central Policy tab. You should see the
AdatumEmployeeAccessRule listed. You can expand the item to view all of the permissions that you set
when you created the rule in Active Directory.
8. Click OK to return to Windows Explorer.
You will find links to Active Directory Domain services content on this page.
What's new in Active Directory Domain Services
AD DS Getting Started
AD DS Deployment
AD DS Operations
Whats new in Active Directory Domain Services for
Windows Server 2016
Applies To: Windows Server 2016
The following new features in Active Directory Domain Services (AD DS ) improve the ability for organizations to
secure Active Directory environments and help them migrate to cloud-only deployments and hybrid deployments,
where some applications and services are hosted in the cloud and others are hosted on premises. The
improvements include:
Privileged access management
Extending cloud capabilities to Windows 10 devices through Azure Active Directory Join
Connecting domain-joined devices to Azure AD for Windows 10 experiences
Enable Microsoft Passport for Work in your organization
Deprecation of File Replication Service (FRS ) and Windows Server 2003 functional levels
Privileged access management

Privileged access management (PAM ) helps mitigate security concerns for Active Directory environments that are
caused by credential theft techniques such pass-the-hash, spear phishing, and similar types of attacks. It provides a
new administrative access solution that is configured by using Microsoft Identity Manager (MIM ). PAM introduces:
A new bastion Active Directory forest, which is provisioned by MIM. The bastion forest has a special PAM
trust with an existing forest. It provides a new Active Directory environment that is known to be free of any
malicious activity, and isolation from an existing forest for the use of privileged accounts.
New processes in MIM to request administrative privileges, along with new workflows based on the
approval of requests.
New shadow security principals (groups) that are provisioned in the bastion forest by MIM in response to
administrative privilege requests. The shadow security principals have an attribute that references the SID
of an administrative group in an existing forest. This allows the shadow group to access resources in an
existing forest without changing any access control lists (ACLs).
An expiring links feature, which enables time-bound membership in a shadow group. A user can be added
to the group for just enough time required to perform an administrative task. The time-bound membership
is expressed by a time-to-live (TTL ) value that is propagated to a Kerberos ticket lifetime.
NOTE
Expiring links are available on all linked attributes. But the member/memberOf linked attribute relationship between a
group and a user is the only example where a complete solution such as PAM is preconfigured to use the expiring
links feature.
KDC enhancements are built in to Active Directory domain controllers to restrict Kerberos ticket lifetime to
the lowest possible time-to-live (TTL ) value in cases where a user has multiple time-bound memberships in
administrative groups. For example, if you are added to a time-bound group A, then when you log on, the
Kerberos ticket-granting ticket (TGT) lifetime is equal to the time you have remaining in group A. If you are
also a member of another time-bound group B, which has a lower TTL than group A, then the TGT lifetime
is equal to the time you have remaining in group B.
New monitoring capabilities to help you easily identify who requested access, what access was granted, and
what activities were performed.
Requirements for Privileged access management
Microsoft Identity Manager
Active Directory forest functional level of Windows Server 2012 R2 or higher.
Azure AD Join
Azure Active Directory Join enhances identity experiences for enterprise, business and EDU customers- with
improved capabilities for corporate and personal devices.
Benefits:
Availability of Modern Settings on corp-owned Windows devices. Oxygen Services no longer require a
personal Microsoft account: they now run off users' existing work accounts to ensure compliance. Oxygen
Services will work on PCs that are joined to an on-premises Windows domain, and PCs and devices that are
"joined" to your Azure AD tenant ("cloud domain"). These settings include:
Roaming or personalization, accessibility settings and credentials
Backup and Restore
Access to Microsoft Store with work account
Live tiles and notifications
Access organizational resources on mobile devices (phones, phablets) that can't be joined to a Windows
Domain, whether they are corp-owned or BYOD
Single-Sign On to Office 365 and other organizational apps, websites and resources.
On BYOD devices, add a work account (from an on-premises domain or Azure AD ) to a personally-owned
device and enjoy SSO to work resources, via apps and on the web, in a way that helps ensure compliance with
new capabilities such as Conditional Account Control and Device Health attestation.
MDM integration lets you auto-enroll devices to your MDM (Intune or third-party)
Set up "kiosk" mode and shared devices for multiple users in your organization
Developer experience lets you build apps that cater to both enterprise and personal contexts with a shared
programing stack.
Imaging option lets you choose between imaging and allowing your users to configure corp-owned devices
directly during the first-run experience.
For more information see, Introduction to device management in Azure Active Directory.
Windows Hello for Business

Windows Hello for Business is a key-based authentication approach organizations and consumers, that goes
beyond passwords. This form of authentication relies on breach, theft, and phish-resistant credentials.
The user logs on to the device with a biometric or PIN log on information that is linked to a certificate or an
asymmetrical key pair. The Identity Providers (IDPs) validate the user by mapping the public key of the user to
IDLocker and provides log on information through One Time Password (OTP ), Phone or a different notification
mechanism.
For more information see, Windows Hello for Business
Deprecation of File Replication Service (FRS) and Windows Server 2003

functional levels
Although File Replication Service (FRS ) and the Windows Server 2003 functional levels were deprecated in
previous versions of Windows Server, it bears repeating that the Windows Server 2003 operating system is no
longer supported. As a result, any domain controller that runs Windows Server 2003 should be removed from the
domain. The domain and forest functional level should be raised to at least Windows Server 2008 to prevent a
domain controller that runs an earlier version of Windows Server from being added to the environment.
At the Windows Server 2008 and higher domain functional levels, Distributed File Service (DFS ) Replication is
used to replicate SYSVOL folder contents between domain controllers. If you create a new domain at the Windows
Server 2008 domain functional level or higher, DFS Replication is automatically used to replicate SYSVOL. If you
created the domain at a lower functional level, you will need to migrate from using FRS to DFS replication for
SYSVOL. For migration steps, you can either follow these steps or you can refer to the streamlined set of steps on
the Storage Team File Cabinet blog.
The Windows Server 2003 domain and forest functional levels continue to be supported, but organizations should
raise the functional level to Windows Server 2008 (or higher if possible) to ensure SYSVOL replication
compatibility and support in the future. In addition, there are many other benefits and features available at the
higher functional levels higher. See the following resources for more information:
Understanding Active Directory Domain Services (AD DS ) Functional Levels
Raise the Domain Functional Level
Raise the Forest Functional Level
AD DS Getting Started
Active Directory stores information about objects on the network and makes this information easy for
administrators and users to find and use. Active Directory uses a structured data store as the basis for a logical,
hierarchical organization of directory information.
TOPIC DESCRIPTION
Active Directory Domain Services Overview Provides information on basic AD DS features. Includes
technical concepts, links to planning and deployment.
Active Directory Administrative Center Provides information about the Active Directory Administrative
Center that includes enhanced management experience
features. These features ease the administrative burden for
managing Active Directory Domain Services (AD DS).
Active Directory Domain Services Virtualization Provides overview and technical information on AD DS
Virtualization.
Windows Time Service Provides details on what is the Windows Time Service, the
importance of Time Protocols, and how the Windows Time
Service works.
Active Directory Domain Services Overview
A directory is a hierarchical structure that stores information about objects on the network. A directory service,
such as Active Directory Domain Services (AD DS ), provides the methods for storing directory data and making
this data available to network users and administrators. For example, AD DS stores information about user
accounts, such as names, passwords, phone numbers, and so on, and enables other authorized users on the same
network to access this information.
Active Directory stores information about objects on the network and makes this information easy for
administrators and users to find and use. Active Directory uses a structured data store as the basis for a logical,
hierarchical organization of directory information.
This data store, also known as the directory, contains information about Active Directory objects. These objects
typically include shared resources such as servers, volumes, printers, and the network user and computer accounts.
For more information about the Active Directory data store, see Directory data store.
Security is integrated with Active Directory through logon authentication and access control to objects in the
directory. With a single network logon, administrators can manage directory data and organization throughout
their network, and authorized network users can access resources anywhere on the network. Policy-based
administration eases the management of even the most complex network. For more information about Active
Directory security, see Security overview.
Active Directory also includes:
A set of rules, the schema, that defines the classes of objects and attributes contained in the directory, the
constraints and limits on instances of these objects, and the format of their names. For more information
about the schema, see Schema.
A global catalog that contains information about every object in the directory. This allows users and
administrators to find directory information regardless of which domain in the directory actually contains
the data. For more information about the global catalog, see The role of the global catalog.
A query and index mechanism, so that objects and their properties can be published and found by
network users or applications. For more information about querying the directory, see Finding directory
information.
A replication service that distributes directory data across a network. All domain controllers in a domain
participate in replication and contain a complete copy of all directory information for their domain. Any
change to directory data is replicated to all domain controllers in the domain. For more information about
Active Directory replication, see Replication overview.
Understanding Active Directory

This section provides links to core Active Directory concepts:
Active Directory Structure and Storage Technologies
Domains Controller Roles
Active Directory Schema
Understanding Trusts
Active Directory Replication Technologies
Active Directory Search and Publication Technologies
Interoperating with DNS and Group Policy
Understanding Schema
For a detailed list of Active Directory concepts, see Understanding Active Directory.
Active Directory Administrative Center
The Active Directory Administrative Center (ADAC ) in Windows Server includes enhanced management experience
features. These features ease the administrative burden for managing Active Directory Domain Services (AD DS ).
The following topics provide an introduction and additional details:
Introduction to Active Directory Administrative Center Enhancements (Level 100)
Advanced AD DS Management Using Active Directory Administrative Center (Level 200)
Introduction to Active Directory Administrative
Center Enhancements (Level 100)
The Active Directory Administrative Center in Windows Server includes management features for the following:
Active Directory Recycle Bin
Fine-Grained Password Policy
Active Directory Recycle Bin

Accidental deletion of Active Directory objects is a common occurrence for users of Active Directory Domain
Services (AD DS ) and Active Directory Lightweight Directory Services (AD LDS ). In past versions of Windows
Server, prior to Windows Server 2008 R2 , one could recover accidentally deleted objects in Active Directory, but
the solutions had their drawbacks.
In Windows Server 2008, you could use the Windows Server Backup feature and ntdsutil authoritative restore
command to mark objects as authoritative to ensure that the restored data was replicated throughout the domain.
The drawback to the authoritative restore solution was that it had to be performed in Directory Services Restore
Mode (DSRM ). During DSRM, the domain controller being restored had to remain offline. Therefore, it was not
able to service client requests.
In Windows Server 2003 Active Directory and Windows Server 2008 AD DS, you could recover deleted Active
Directory objects through tombstone reanimation. However, reanimated objects' link-valued attributes (for
example, group memberships of user accounts) that were physically removed and non-link-valued attributes that
were cleared were not recovered. Therefore, administrators could not rely on tombstone reanimation as the
ultimate solution to accidental deletion of objects. For more information about tombstone reanimation, see
Reanimating Active Directory Tombstone Objects.
Active Directory Recycle Bin, starting in Windows Server 2008 R2, builds on the existing tombstone reanimation
infrastructure and enhances your ability to preserve and recover accidentally deleted Active Directory objects.
When you enable Active Directory Recycle Bin, all link-valued and non-link-valued attributes of the deleted Active
Directory objects are preserved and the objects are restored in their entirety to the same consistent logical state
that they were in immediately before deletion. For example, restored user accounts automatically regain all group
memberships and corresponding access rights that they had immediately before deletion, within and across
domains. Active Directory Recycle Bin works for both AD DS and AD LDS environments. For a detailed description
of Active Directory Recycle Bin, see What's New in AD DS: Active Directory Recycle Bin.
What's new? In Windows Server 2012 and newer, the Active Directory Recycle Bin feature is enhanced with a new
graphical user interface for users to manage and restore deleted objects. Users can now visually locate a list of
deleted objects and restore them to their original or desired locations.
If you plan to enable Active Directory Recycle Bin in Windows Server, consider the following:
By default, Active Directory Recycle Bin is disabled. To enable it, you must first raise the forest functional level of
your AD DS or AD LDS environment to Windows Server 2008 R2 or higher. This in turn requires that all
domain controllers in the forest or all servers that host instances of AD LDS configuration sets be running
Windows Server 2008 R2 or higher.
The process of enabling Active Directory Recycle Bin is irreversible. After you enable Active Directory Recycle
Bin in your environment, you cannot disable it.
To manage the Recycle Bin feature through a user interface, you must install the version of Active Directory
Administrative Center in Windows Server 2012.
NOTE
You can use Server Manager to install Remote Server Administration Tools (RSAT) to use the correct version of
Active Directory Administrative Center to manage Recycle Bin through a user interface.
For information about installing RSAT, see the article Remote Server Administration Tools.
Active Directory Recycle Bin step-by-step

In the following steps, you will use ADAC to perform the following Active Directory Recycle Bin tasks in Windows
Server 2012 :
Step 1: Raise the forest functional level
Step 2: Enable Recycle Bin
Step 3: Create test users, group and organizational unit
Step 4: Restore deleted objects
NOTE
Membership in the Enterprise Admins group or equivalent permissions is required to perform the following steps.
Step 1: Raise the forest functional level

In this step, you will raise the forest functional level. You must first raise the functional level on the target forest to
be Windows Server 2008 R2 at a minimum before you enable Active Directory Recycle Bin.
To raise the functional level on the target forest
1. Right click the Windows PowerShell icon, click Run as Administrator and type dsac.exe to open ADAC.
2. Click Manage, click Add Navigation Nodes and select the appropriate target domain in the Add
Navigation Nodes dialog box and then click OK.
3. Click the target domain in the left navigation pane and in the Tasks pane, click Raise the forest functional
level. Select a forest functional level that is at least Windows Server 2008 R2 or higher and then click OK.

Set-ADForestMode -Identity contoso.com -ForestMode Windows2008R2Forest -Confirm:$false
For the -Identity argument, specify the fully qualified DNS domain name.
Step 2: Enable Recycle Bin
In this step, you will enable the Recycle Bin to restore deleted objects in AD DS.
To enable Active Directory Recycle Bin in ADAC on the target domain
3. In the Tasks pane, click Enable Recycle Bin ... in the Tasks pane, click OK on the warning message box, and
then click OK to the refresh ADAC message.
4. Press F5 to refresh ADAC.

Enable-ADOptionalFeature -Identity 'CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows

NT,CN=Services,CN=Configuration,DC=contoso,DC=com' -Scope ForestOrConfigurationSet -Target 'contoso.com'
Step 3: Create test users, group and organizational unit

In the following procedures, you will create two test users. You will then create a test group and add the test users
to the group. In addition, you will create an OU.
To create test users
3. In the Tasks pane, click New and then click User.
4. Enter the following information under Account and then click OK:
Full name: test1
User SamAccountName logon: test1
Password: p@ssword1
Confirm password: p@ssword1
5. Repeat the previous steps to create a second user, test2.
To create a test group and add users to the group
2. Click Manage, click Add Navigation Nodes and select the appropriate target domain in the Add Navigation
Nodes dialog box and then click OK.
3. In the Tasks pane, click New and then click Group.
4. Enter the following information under Group and then click OK:
Group name:group1
5. Click group1, and then under the Tasks pane, click Properties.
6. Click Members, click Add, type test1;test2, and then click OK.

Add-ADGroupMember -Identity group1 -Member test1
To create an organizational unit

2. Click Manage, click Add Navigation Nodes and select the appropriate target domain in the Add Navigation
Nodes dialog box and then click **OK
3. In the Tasks pane, click New and then click Organizational Unit.
4. Enter the following information under Organizational Unit and then click OK:
NameOU1

1..2 | ForEach-Object {New-ADUser -SamAccountName test$_ -Name "test$_" -Path "DC=fabrikam,DC=com" -

AccountPassword (ConvertTo-SecureString -AsPlainText "p@ssword1" -Force) -Enabled $true}
New-ADGroup -Name "group1" -SamAccountName group1 -GroupCategory Security -GroupScope Global -DisplayName
"group1"
New-ADOrganizationalUnit -Name OU1 -Path "DC=fabrikam,DC=com"
Step 4: Restore deleted objects

In the following procedures, you will restore deleted objects from the Deleted Objects container to their original
location and to a different location.
To restore deleted objects to their original location
3. Select users test1 and test2, click Delete in the Tasks pane and then click Yes to confirm the deletion.
Get-ADUser -Filter 'Name -Like "*test*"'|Remove-ADUser -Confirm:$false
4. Navigate to the Deleted Objects container, select test2 and test1 and then click Restore in the Tasks pane.
5. To confirm the objects were restored to their original location, navigate to the target domain and verify the
user accounts are listed.
NOTE
If you navigate to the Properties of the user accounts test1 and test2 and then click Member Of, you will see that
their group membership was also restored.
Get-ADObject -Filter 'Name -Like "*test*"' -IncludeDeletedObjects | Restore-ADObject
To restore deleted objects to a different location

3. Select users test1 and test2, click Delete in the Tasks pane and then click Yes to confirm the deletion.
4. Navigate to the Deleted Objects container, select test2 and test1 and then click Restore To in the Tasks
pane.
5. Select OU1 and then click OK.
6. To confirm the objects were restored to OU1, navigate to the target domain, double click OU1 and verify the
user accounts are listed.

Get-ADObject -Filter 'Name -Like "*test*"' -IncludeDeletedObjects | Restore-ADObject -TargetPath

"OU=OU1,DC=contoso,DC=com"
Fine-Grained Password Policy

The Windows Server 2008 operating system provides organizations with a way to define different password and
account lockout policies for different sets of users in a domain. In Active Directory domains prior to Windows
Server 2008, only one password policy and account lockout policy could be applied to all users in the domain.
These policies were specified in the Default Domain Policy for the domain. As a result, organizations that wanted
different password and account lockout settings for different sets of users had to either create a password filter or
deploy multiple domains. Both are costly options.
You can use fine-grained password policies to specify multiple password policies within a single domain and apply
different restrictions for password and account lockout policies to different sets of users in a domain. For example,
you can apply stricter settings to privileged accounts and less strict settings to the accounts of other users. In other
cases, you might want to apply a special password policy for accounts whose passwords are synchronized with
other data sources. For a detailed description of Fine-Grained Password Policy, see AD DS: Fine-Grained Password
Policies
What's new?
In Windows Server 2012 and newer, fine-grained password policy management is made easier and more visual by
providing a user interface for AD DS administrators to manage them in ADAC. Administrators can now view a
given user's resultant policy, view and sort all password policies within a given domain, and manage individual
password policies visually.
If you plan to use fine-grained password policies in Windows Server 2012, consider the following:
Fine-grained password policies apply only global security groups and user objects (or inetOrgPerson objects
if they are used instead of user objects). 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 functional level must be Windows Server 2008 or higher.
You must use the Windows Server 2012 or newer version of Active Directory Administrative Center to
administer fine-grained password policies through a graphical user interface.
NOTE
Fine -Grained Password Policy step-by-step

In the following steps, you will use ADAC to perform the following fine-grained password policy tasks:
Step 1: Raise the domain functional level
Step 2: Create test users, group, and organizational unit
Step 3: Create a new fine-grained password policy
Step 4: View a resultant set of policies for a user
Step 5: Edit a fine-grained password policy
Step 6: Delete a fine-grained password policy
NOTE
Membership in the Domain Admins group or equivalent permissions is required to perform the following steps.
Step 1: Raise the domain functional level

In the following procedure, you will raise the domain functional level of the target domain to Windows Server 2008
or higher. A domain functional level of Windows Server 2008 or higher is required to enable fine-grained password
policies.
To r a i se t h e d o m a i n fu n c t i o n a l l e v e l
3. Click the target domain in the left navigation pane and in the Tasks pane, click Raise the domain
functional level. Select a forest functional level that is at least Windows Server 2008 or higher and then
click OK.

Set-ADDomainMode -Identity contoso.com -DomainMode 3
Step 2: Create test users, group, and organizational unit

To create the test users and group need for this step, follow the procedures located here: Step 3: Create test users,
group and organizational unit (you do not need to create the OU to demonstrate fine-grained password policy).
Step 3: Create a new fine-grained password policy
In the following procedure you will create a new fine-grained password policy using the UI in ADAC.
To c r e a t e a n e w fi n e g r a i n e d p a ssw o r d p o l i c y
3. In the ADAC navigation pane, open the System container and then click Password Settings Container.
4. In the Tasks pane, click New, and then click Password Settings.
Fill in or edit fields inside the property page to create a new Password Settings object. The Name and
Precedence fields are required.
5. Under Directly Applies To, click Add, type group1, and then click OK.
This associates the Password Policy object with the members of the global group you created for the test
environment.
6. Click OK to submit the creation.

New-ADFineGrainedPasswordPolicy TestPswd -ComplexityEnabled:$true -LockoutDuration:"00:30:00" -

LockoutObservationWindow:"00:30:00" -LockoutThreshold:"0" -MaxPasswordAge:"42.00:00:00" -
MinPasswordAge:"1.00:00:00" -MinPasswordLength:"7" -PasswordHistoryCount:"24" -Precedence:"1" -
ReversibleEncryptionEnabled:$false -ProtectedFromAccidentalDeletion:$true
Add-ADFineGrainedPasswordPolicySubject TestPswd -Subjects group1
Step 4: View a resultant set of policies for a user

In the following procedure, you will view the resultant password settings for a user that is a member of the group
to which you assigned a fine grained password policy in Step 3: Create a new fine-grained password policy.
To v i e w a r e su l t a n t se t o f p o l i c i e s fo r a u se r
3. Select a user, test1 that belongs to the group, group1 that you associated a fine-grained password policy
with in Step 3: Create a new fine-grained password policy.
4. Click View Resultant Password Settings in the Tasks pane.
5. Examine the password setting policy and then click Cancel.

Get-ADUserResultantPasswordPolicy test1
Step 5: Edit a fine-grained password policy

In the following procedure, you will edit the fine grained password policy you created in Step 3: Create a new fine-
grained password policy
To e d i t a fi n e - g r a i n e d p a ssw o r d p o l i c y
3. In the ADAC Navigation Pane, expand System and then click Password Settings Container.
4. Select the fine grained password policy you created in Step 3: Create a new fine-grained password policy
and click Properties in the Tasks pane.
5. Under Enforce password history, change the value of Number of passwords remembered to 30.
6. Click OK.

Set-ADFineGrainedPasswordPolicy TestPswd -PasswordHistoryCount:"30"
Step 6: Delete a fine-grained password policy

To d e l e t e a fi n e - g r a i n e d p a ssw o r d p o l i c y
3. In the ADAC Navigation Pane, expand System and then click Password Settings Container.
4. Select the fine grained password policy you created in Step 3: Create a new fine-grained password policy
and in the Tasks pane click Properties.
5. Clear the Protect from accidental deletion checkbox and click OK.
6. Select the fine grained password policy, and in the Tasks pane click Delete.
7. Click OK in the confirmation dialog.

Set-ADFineGrainedPasswordPolicy -Identity TestPswd -ProtectedFromAccidentalDeletion $False

Remove-ADFineGrainedPasswordPolicy TestPswd -Confirm

ADAC is a user interface tool built on top of Windows PowerShell. In Windows Server 2012 and newer, IT
administrators can leverage ADAC to learn Windows PowerShell for Active Directory cmdlets by using the
Windows PowerShell History Viewer. As actions are executed in the user interface, the equivalent Windows
PowerShell command is shown to the user in Windows PowerShell History Viewer. This allows administrators to
create automated scripts and reduce repetitive tasks, thus increasing IT productivity. Also, this feature reduces the
time to learn Windows PowerShell for Active Directory and increases the users' confidence in the correctness of
their automation scripts.
When using the Windows PowerShell History Viewer in Windows Server 2012 or newer consider the following:
To use Windows PowerShell Script Viewer, you must use the Windows Server 2012 or newer version of
ADAC
NOTE
Have a basic understanding of Windows PowerShell. For example, you need to know how piping in
Windows PowerShell works. For more information about piping in Windows PowerShell, see Piping and the
Pipeline in Windows PowerShell.
Windows PowerShell History Viewer step-by-step
In the following procedure, you will use the Windows PowerShell History Viewer in ADAC to construct a Windows
PowerShell script. Before you begin this procedure, remove user, test1 from the group, group1.
To construct a script using PowerShell History Viewer
3. Expand the Windows PowerShell History pane at the bottom of the ADAC screen.
4. Select user, test1.
5. Click Add to group... in the Tasks pane.
6. Navigate to group1 and click OK in the dialog box.
7. Navigate to the Windows PowerShell History pane and locate the command just generated.
8. Copy the command and paste it into your desired editor to construct your script.
For example, you can modify the command to add a different user to group1, or add test1 to a different
group.
See Also
Advanced AD DS Management Using Active Directory Administrative Center (Level 200)
Advanced AD DS Management Using Active
Directory Administrative Center (Level 200)
This topic covers the updated Active Directory Administrative Center with its new Active Directory Recycle Bin,
Fine-grained Password policy, and Windows PowerShell History Viewer in more detail, including architecture,
examples for common tasks, and troubleshooting information. For an introduction, see Introduction to Active
Directory Administrative Center Enhancements (Level 100).
Active Directory Administrative Center Architecture
Enabling and Managing the Active Directory Recycle Bin Using Active Directory Administrative Center
Configuring and Managing Fine-Grained Password Policies Using Active Directory Administrative Center
Using the Active Directory Administrative Center Windows PowerShell History Viewer
Troubleshooting AD DS Management
Active Directory Administrative Center Architecture

Active Directory Administrative Center Executables, DLLs
The module and underlying architecture of Active Directory Administrative Center has not changed with the new
recycle bin, FGPP, and history viewer capabilities.
Microsoft.ActiveDirectory.Management.UI.dll
Microsoft.ActiveDirectory.Management.UI.resources.dll
Microsoft.ActiveDirectory.Management.dll
Microsoft.ActiveDirectory.Management.resources.dll
ActiveDirectoryPowerShellResources.dll
The underlying Windows PowerShell and layer of operations for the new Recycle Bin functionality are illustrated
below:
Enabling and Managing the Active Directory Recycle Bin Using Active
Directory Administrative Center
Capabilities
The Windows Server 2012 or newer Active Directory Administrative Center enables you to configure and
manage the Active Directory Recycle Bin for any domain partition in a forest. There is no longer a requirement
to use Windows PowerShell or Ldp.exe to enable the Active Directory Recycle Bin or restore objects in domain
partitions.
The Active Directory Administrative Center has advanced filtering criteria, making targeted restoration easier in
large environments with many intentionally deleted objects.
Limitations
Because the Active Directory Administrative Center can only manage domain partitions, it cannot restore
deleted objects from the Configuration, Domain DNS, or Forest DNS partitions (you cannot delete objects
from the Schema partition). To restore objects from non-domain partitions, use Restore-ADObject.
The Active Directory Administrative Center cannot restore sub-trees of objects in a single action. For
example, if you delete an OU with nested OUs, users, groups, and computers, restoring the base OU does
not restore the child objects.
NOTE
The Active Directory Administrative Center batch restore operation does a "best effort" sort of the deleted objects
within the selection only so parents are ordered before the children for the restore list. In simple test cases, sub-trees
of objects may be restored in a single action. But corner cases, such as a selection that contains partial trees - trees
with some of the deleted parent nodes missing - or error cases, such as skipping the child objects when parent restore
fails, may not work as expected. For this reason, you should always restore sub-trees of objects as a separate action
after you restore the parent objects.
The Active Directory Recycle Bin requires a Windows Server 2008 R2 Forest Functional Level and you must be a
member of the Enterprise Admins group. Once enabled, you cannot disable Active Directory Recycle Bin. Active
Directory Recycle Bin increases the size of the Active Directory database (NTDS.DIT) on every domain controller in
the forest. Disk space used by the recycle bin continues to increase over time as it preserves objects and all their
attribute data.
Enabling Active Directory Recycle Bin using Active Directory Administrative Center
To enable the Active Directory Recycle Bin, open the Active Directory Administrative Center and click the name
of your forest in the navigation pane. From the Tasks pane, click Enable Recycle Bin.
The Active Directory Administrative Center shows the Enable Recycle Bin Confirmation dialog. This dialog
warns you that enabling the recycle bin is irreversible. Click OK to enable the Active Directory Recycle Bin. The
Active Directory Administrative Center shows another dialog to remind you that the Active Directory Recycle Bin is
not fully functional until all domain controllers replicate the configuration change.
IMPORTANT
The option to enable the Active Directory Recycle Bin is unavailable if:
The forest functional level is less than Windows Server 2008 R2
It is already enabled
The equivalent Active Directory Windows PowerShell cmdlet is:
Enable-ADOptionalFeature
For more information about using Windows PowerShell to enable the Active Directory Recycle Bin, see the Active
Directory Recycle Bin Step-by-Step Guide.
Managing Active Directory Recycle Bin using Active Directory Administrative Center
This section uses the example of an existing domain named corp.contoso.com. This domain organizes users into a
parent OU named UserAccounts. The UserAccounts OU contains three child OUs named by department, which
each contain further OUs, users, and groups.
Storage and Filtering

The Active Directory Recycle Bin preserves all objects deleted in the forest. It saves these objects according to the
msDS -deletedObjectLifetime attribute, which by default is set to match the tombstoneLifetime attribute of the
forest. In any forest created using Windows Server 2003 SP1 or later, the value of tombstoneLifetime is set to
180 days by default. In any forest upgraded from Windows 2000 or installed with Windows Server 2003 (no
service pack), the default tombstoneLifetime attribute is NOT SET and Windows therefore uses the internal default
of 60 days. All of this is configurable.You can use the Active Directory Administrative Center to restore any objects
deleted from the domain partitions of the forest. You must continue to use the cmdlet Restore-ADObject to
restore deleted objects from other partitions, such as Configuration.Enabling the Active Directory Recycle Bin
makes the Deleted Objects container visible under every domain partition in the Active Directory Administrative
Center.
The Deleted Objects container shows you all the restorable objects in that domain partition. Deleted objects older
than msDS -deletedObjectLifetime are known as recycled objects. The Active Directory Administrative Center
does not show recycled objects and you cannot restore these objects using Active Directory Administrative Center.
For a deeper explanation of the recycle bin's architecture and processing rules, see The AD Recycle Bin:
Understanding, Implementing, Best Practices, and Troubleshooting.
The Active Directory Administrative Center artificially limits the default number of objects returned from a
container to 20,000 objects. You can raise this limit as high as 100,000 objects by clicking the Manage menu, then
Management List Options.
Restoration
Fi l t er i n g
Active Directory Administrative Center offers powerful criteria and filtering options that you should become
familiar with before you need to use them in a real-life restoration. Domains intentionally delete many objects over
their lifetime .With a likely deleted object lifetime of 180 days, you cannot simply restore all objects when an
accident occurs.
Rather than writing complex LDAP filters and converting UTC values into dates and times, use the basic and
advanced Filter menu to list only the relevant objects. If you know the day of deletion, the names of objects, or any
other key data, use that to your advantage when filtering. Toggle the advanced filter options by clicking the chevron
to the right of the search box.
The restore operation supports all the standard filter criteria options, the same as any other search. Of the built-in
filters, the important ones for restoring objects are typically:
ANR (ambiguous name resolution - not listed in the menu, but what is used when you type in theFilterbox)
Last modified between given dates
Object is user/inetorgperson/computer/group/organization unit
Name
When deleted
Last known parent
Type
Description
City
Country /region
Department
Employee ID
First name
Job title
Last name
SAMaccountname
State/Province
Telephone number
UPN
ZIP/Postal code
You can add multiple criteria. For example, you can find all user objects deleted on September 24, 2012 from
Chicago, Illinois with a job title of Manager.
You can also add, modify, or reorder the column headers to provide more detail when evaluating which objects to
recover.
For more information about Ambiguous Name Resolution, see ANR Attributes.
Si n g l e O b j e c t
Restoring deleted objects has always been a single operation. The Active Directory Administrative Center makes
that operation easier. To restore a deleted object, such as a single user:
1. Click the domain name in the navigation pane of the Active Directory Administrative Center.
2. Double-click Deleted Objects in the management list.
3. Right-click the object and then click Restore, or click Restore from the Tasks pane.
The object restores to its original location.
Click Restore To... to change the restore location. This is useful if the deleted object's parent container was also
deleted but you do not want to restore the parent.
Mu l t i pl e Peer O bj ec t s
You can restore multiple peer-level objects, such as all the users in an OU. Hold down the CTRL key and click one
or more deleted objects you want to restore. Click Restore from the Tasks pane. You can also select all displayed
objects by holding down the CTRL and A keys, or a range of objects using SHIFT and clicking.
Mu l t i pl e Par en t an d Ch i l d O bj ec t s
It is critical to understand the restoration process for a multi-parent-child restoration because the Active Directory
Administrative Center cannot restore a nested tree of deleted objects with a single action.
1. Restore the top-most deleted object in a tree.
2. Restore the immediate children of that parent object.
3. Restore the immediate children of those parent objects.
4. Repeat as necessary until all objects restore.
You cannot restore a child object before restoring its parent. Attempting this restoration returns the following error:
The operation could not be performed because the object's parent is either uninstantiated or deleted.
The Last Known Parent attribute shows the parent relationship of each object. The Last Known Parent attribute
changes from the deleted location to the restored location when you refresh the Active Directory Administrative
Center after restoring a parent. Therefore, you can restore that child object when a parent object's location no
longer shows the distinguished name of the deleted objects container.
Consider the scenario where an administrator accidentally deletes the Sales OU, which contains child OUs and
users.
First, observe the value of the Last Known Parent attribute for all the deleted users and how it reads
OU=Sales\0ADEL:*<guid+deleted objects container distinguished name>*:
Filter on the ambiguous name Sales to return the deleted OU, which you then restore:
Refresh the Active Directory Administrative Center to see the deleted user object's Last Known Parent attribute
change to the restored Sales OU distinguished name:
Filter on all the Sales users. Hold down the CTRL and A keys to select all the deleted Sales users. Click Restore to
move the objects from the Deleted Objects container to the Sales OU with their group memberships and
attributes intact.
If the Sales OU contained child OUs of its own, then you would restore the child OUs first before restoring their
children, and so on.
To restore all nested deleted objects by specifying a deleted parent container, see Appendix B: Restore Multiple,
Deleted Active Directory Objects (Sample Script).
The Active Directory Windows PowerShell cmdlet for restoring deleted objects is:
Restore-adobject
The Restore-ADObject cmdlet functionality did not change between Windows Server 2008 R2 and Windows
Server 2012.
Se r v e r- si d e F i l t e r i n g
It is possible that over time, the Deleted Objects container will accumulate over 20,000 (or even 100,000) objects in
medium and large enterprises and have difficulty showing all objects. Since the filter mechanism in Active Directory
Administrative Center relies on client-side filtering, it cannot show these additional objects. To work around this
limitation, use the following steps to perform a server-side search:
1. Right click the Deleted Objects container and click Search under this node.
2. Click the chevron to expose the +Add criteria menu, select and add Last modified between given dates. The
Last Modified time (the whenChanged attribute) is a close approximation of the deletion time; in most
environments, they are identical. This query performs a server-side search.
3. Locate the deleted objects to restore by using further display filtering, sorting, and so on in the results, and then
restore them normally.
Configuring and Managing Fine-Grained Password Policies Using Active

Directory Administrative Center
Configuring Fine -Grained Password Policies
The Active Directory Administrative Center enables you to create and manage Fine-Grained Password Policy
(FGPP ) objects. Windows Server 2008 introduced the FGPP feature but Windows Server 2012 has the first
graphical management interface for it. You apply Fine-Grained Password Policies at a domain level and it enables
overriding the single domain password required by Windows Server 2003. By creating different FGPP with
different settings, individual users or groups get differing password policies in a domain.
For information about the Fine-Grained Password Policy, see AD DS Fine-Grained Password and Account Lockout
Policy Step-by-Step Guide (Windows Server 2008 R2).
In the Navigation pane, click Tree View, click your domain, click System, click Password Settings Container, and
then in the Tasks pane, click New and Password Settings.
Managing Fine -Grained Password Policies

Creating a new FGPP or editing an existing one brings up the Password Settings editor. From here, you configure
all desired password policies, as you would have in Windows Server 2008 or Windows Server 2008 R2, only now
with a purpose-built editor.
Fill out all required (red asterisk) fields and any optional fields, and then click Add to set the users or groups that
receives this policy. FGPP overrides default domain policy settings for those specified security principals. In the
figure above, an extremely restrictive policy applies only to the built-in Administrator account, to prevent
compromise. The policy is far too complex for standard users to comply with, but is perfect for a high-risk account
used only by IT professionals.
You also set precedence and to which users and groups the policy applies within a given domain.
The Active Directory Windows PowerShell cmdlets for Fine-Grained Password Policy are:
Add-ADFineGrainedPasswordPolicySubject
Get-ADFineGrainedPasswordPolicy
Get-ADFineGrainedPasswordPolicySubject
New-ADFineGrainedPasswordPolicy
Remove-ADFineGrainedPasswordPolicy
Remove-ADFineGrainedPasswordPolicySubject
Set-ADFineGrainedPasswordPolicy
Fine-Grained Password Policy cmdlet functionality did not change between the Windows Server 2008 R2 and
Windows Server 2012. As a convenience, the following diagram illustrates the associated arguments for cmdlets:
The Active Directory Administrative Center also enables you to locate the resultant set of applied FGPP for a
specific user. Right click any user and click View resultant password settings... to open the Password Settings
page that applies to that user through implicit or explicit assignment:
Examining the Properties of any user or group shows the Directly Associated Password Settings, which are the
explicitly assigned FGPPs:
Implicit FGPP assignment does not display here; for that, you must use the View resultant password settings...
option.
Using the Active Directory Administrative Center Windows PowerShell

History Viewer
The future of Windows management is Windows PowerShell. By layering graphical tools on top of a task
automation framework, management of the most complex distributed systems becomes consistent and efficient.
You need to understand how Windows PowerShell works in order to reach your full potential and maximize your
computing investments.
The Active Directory Administrative Center now provides a complete history of all the Windows PowerShell
cmdlets it runs and their arguments and values. You can copy the cmdlet history elsewhere for study or
modification and re-use. You can create Task notes to assist in isolating what your Active Directory Administrative
Center commands resulted in Windows PowerShell. You can also filter the history to find points of interest.
The Active Directory Administrative Center Windows PowerShell History Viewer's purpose is for you to learn
through practical experience.
Click the chevron (arrow ) to show Windows PowerShell History Viewer.
Then, create a user or modify a group's membership. The history viewer continually updates with a collapsed view
of each cmdlet that the Active Directory Administrative Center ran with the arguments specified.
Expand any line item of interest to see all values provided to the cmdlet's arguments:
Click the Start Task menu to create a manual notation before you use Active Directory Administrative Center to
create, modify, or delete an object. Type in what you were doing. When done with your change, select End Task.
The task note groups all of those actions performed into a collapsible note you can use for better understanding.
For example, to see the Windows PowerShell commands used to change a user's password and remove him from a
group:
Selecting the Show All check box also shows the Get-* verb Windows PowerShell cmdlets that only retrieve data.
The history viewer shows the literal commands run by the Active Directory Administrative Center and you might
note that some cmdlets appear to run unnecessarily. For example, you can create a new user with:
new-aduser
and do not need to use:
set-adaccountpassword
enable-adaccount
set-aduser
The Active Directory Administrative Center's design required minimal code usage and modularity. Therefore,
instead of a set of functions that create new users and another set that modify existing users, it minimally does each
function and then chains them together with the cmdlets. Keep this in mind when you are learning Active Directory
Windows PowerShell. You can also use that as a learning technique, where you see how simply you can use
Windows PowerShell to complete a single task.
Troubleshooting AD DS Management
Introduction to Troubleshooting
Because of its relative newness and lack of usage in existing customer environments, the Active Directory
Administrative Center has limited troubleshooting options.
Troubleshooting Options
Logging Options
The Active Directory Administrative Center now contains built-in logging, as part of a tracing config file.
Create/modify the following file in the same folder as dsac.exe:
dsac.exe.config
Create the following contents:
<appSettings>
<add key="DsacLogLevel" value="Verbose" />
</appSettings>
<system.diagnostics>
<trace autoflush="false" indentsize="4">
<listeners>
<add name="myListener"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="dsac.trace.log" />
<remove name="Default" />
</listeners>
</trace>
</system.diagnostics>
The verbosity levels for DsacLogLevel are None, Error, Warning, Info, and Verbose. The output file name is
configurable and writes to the same folder as dsac.exe. The output can tell you more about how ADAC is operating,
which domain controllers it contacted, what Windows PowerShell commands executed, what the responses were,
and further details.
For example, while using the INFO level, which returns all results except the trace-level verbosity:
DSAC.exe starts
Logging starts
Domain Controller requested to return initial domain information
[12:42:49][TID 3][Info] Command Id, Action, Command, Time, Elapsed Time ms (output), Number objects
(output)
[12:42:49][TID 3][Info] 1, Invoke, Get-ADDomainController, 2012-04-16T12:42:49
[12:42:49][TID 3][Info] Get-ADDomainController-Discover:$null-DomainName:"CORP"-ForceDiscover:$null-
Service:ADWS-Writable:$null
Domain controller DC1 returned from domain Corp

PS AD virtual drive loaded
[12:42:49][TID 3][Info] 1, Output, Get-ADDomainController, 2012-04-16T12:42:49, 1

[12:42:49][TID 3][Info] Found the domain controller 'DC1' in the domain 'CORP'.
[12:42:49][TID 3][Info] 2, Invoke, New-PSDrive, 2012-04-16T12:42:49
[12:42:49][TID 3][Info] New-PSDrive-Name:"ADDrive0"-PSProvider:"ActiveDirectory"-Root:""-
Server:"dc1.corp.contoso.com"
[12:42:49][TID 3][Info] 2, Output, New-PSDrive, 2012-04-16T12:42:49, 1
[12:42:49][TID 3][Info] 3, Invoke, Get-ADRootDSE, 2012-04-16T12:42:49
Get domain Root DSE Information

[12:42:49][TID 3][Info] Get-ADRootDSE -Server:"dc1.corp.contoso.com"
[12:42:49][TID 3][Info] 3, Output, Get-ADRootDSE, 2012-04-16T12:42:49, 1
[12:42:49][TID 3][Info] 4, Invoke, Get-ADOptionalFeature, 2012-04-16T12:42:49
Get domain AD recycle bin information
[12:42:49][TID 3][Info] Get-ADOptionalFeature -LDAPFilter:"(msDS-OptionalFeatureFlags=1)" -

[12:42:49][TID 3][Info] 4, Output, Get-ADOptionalFeature, 2012-04-16T12:42:49, 1
[12:42:49][TID 3][Info] 7, Invoke, Get-ADOptionalFeature, 2012-04-16T12:42:49
[12:42:49][TID 3][Info] Get-ADOptionalFeature -LDAPFilter:"(msDS-OptionalFeatureFlags=1)" -
[12:42:50][TID 3][Info] 7, Output, Get-ADOptionalFeature, 2012-04-16T12:42:50, 1
[12:42:50][TID 3][Info] 8, Invoke, Get-ADForest, 2012-04-16T12:42:50
Get AD forest
[12:42:50][TID 3][Info] Get-ADForest -Identity:"corp.contoso.com" -Server:"dc1.corp.contoso.com"

[12:42:50][TID 3][Info] 8, Output, Get-ADForest, 2012-04-16T12:42:50, 1
[12:42:50][TID 3][Info] 9, Invoke, Get-ADObject, 2012-04-16T12:42:50
Get Schema information for supported encryption types, FGPP, certain user information
[12:42:50][TID 3][Info] Get-ADObject

-LDAPFilter:"(|(ldapdisplayname=msDS-PhoneticDisplayName)(ldapdisplayname=msDS-PhoneticCompanyName)
(ldapdisplayname=msDS-PhoneticDepartment)(ldapdisplayname=msDS-PhoneticFirstName)(ldapdisplayname=msDS-
PhoneticLastName)(ldapdisplayname=msDS-SupportedEncryptionTypes)(ldapdisplayname=msDS-
PasswordSettingsPrecedence))"
-Properties:lDAPDisplayName
-ResultPageSize:"100"
-ResultSetSize:$null
-SearchBase:"CN=Schema,CN=Configuration,DC=corp,DC=contoso,DC=com"
-SearchScope:"OneLevel"
-Server:"dc1.corp.contoso.com"
[12:42:50][TID 3][Info] 9, Output, Get-ADObject, 2012-04-16T12:42:50, 7
[12:42:50][TID 3][Info] 10, Invoke, Get-ADObject, 2012-04-16T12:42:50
Get all information about the domain object to display to administrator who clicked on the domain head.
[12:42:50][TID 3][Info] Get-ADObject
-IncludeDeletedObjects:$false
-LDAPFilter:"(objectClass=*)"
-
Properties:allowedChildClassesEffective,allowedChildClasses,lastKnownParent,sAMAccountType,systemFlags,u
serAccountControl,displayName,description,whenChanged,location,managedBy,memberOf,primaryGroupID,objectS
id,msDS-User-Account-Control-
Computed,sAMAccountName,lastLogonTimestamp,lastLogoff,mail,accountExpires,msDS-PhoneticCompanyName,msDS-
PhoneticDepartment,msDS-PhoneticDisplayName,msDS-PhoneticFirstName,msDS-
PhoneticLastName,pwdLastSet,operatingSystem,operatingSystemServicePack,operatingSystemVersion,telephoneN
umber,physicalDeliveryOfficeName,department,company,manager,dNSHostName,groupType,c,l,employeeID,givenNa
me,sn,title,st,postalCode,managedBy,userPrincipalName,isDeleted,msDS-PasswordSettingsPrecedence
-ResultPageSize:"100"
-ResultSetSize:"20201"
-SearchBase:"DC=corp,DC=contoso,DC=com"
-SearchScope:"Base"
-Server:"dc1.corp.contoso.com"
Setting the Verbose level also shows the .NET stacks for each function, but these do not include enough data to be
particularly useful except when troubleshooting the Dsac.exe suffering an access violation or crash. The two likely
causes of this issue are:
The ADWS service is not running on any accessible domain controllers.
Network communications are blocked to the ADWS service from the computer running the Active Directory
Administrative Center.
IMPORTANT
There is also an out-of-band version of the service called the Active Directory Management Gateway, which runs on Windows
Server 2008 SP2 and Windows Server 2003 SP2.
The errors shown when no Active Directory Web Services instances are available are:
ERROR OPERATION
"Cannot connect to any domain. Refresh or try again when Shown at start of the Active Directory Administrative Center
connection is available" application
"Cannot find an available server in the domain that is running Shown when trying to select a domain node in the Active
the Active Directory Web Service (ADWS)" Directory Administrative Center application
To troubleshoot this issue, use these steps:

1. Validate the Active Directory Web Services service is started on at least one domain controller in the domain
(and preferably all domain controllers in the forest). Ensure that it is set to start automatically on all domain
controllers as well.
2. From the computer running the Active Directory Administrative Center, validate that you can locate a server
running ADWS by running these NLTest.exe commands:
nltest /dsgetdc:<domain NetBIOS name> /ws /force

nltest /dsgetdc:<domain fully qualified DNS name> /ws /force
If those tests fail even though the ADWS service is running, the issue is with name resolution or LDAP and
not ADWS or Active Directory Administrative Center. This test fails with error "1355 0x54B
ERROR_NO_SUCH_DOMAIN" if ADWS is not running on any domain controllers though, so double-check
before reaching any conclusions.
3. On the domain controller returned by NLTest, dump the listening port list with command:
Netstat -anob > ports.txt
Examine the ports.txt file and validate that the ADWS service is listening on port 9389. Example:
TCP 0.0.0.0:9389 0.0.0.0:0 LISTENING 1828

[Microsoft.ActiveDirectory.WebServices.exe]
TCP [::]:9389 [::]:0 LISTENING 1828

[Microsoft.ActiveDirectory.WebServices.exe]
If listening, validate the Windows Firewall rules and ensure that they allow 9389 TCP inbound. By default,
domain controllers enable firewall rule "Active Directory Web Services (TCP -in)". If not listening, validate
again that the service is running on this server and restart it. Validate that no other process is already
listening on port 9389.
4. Install NetMon or another network capture utility on the computer running Active Directory Administrative
Center and on the domain controller returned by NLTEST. Gather simultaneous network captures from both
computers, where you start Active Directory Administrative Center and see the error before stopping the
captures. Validate that the client is able to send to and receive from the domain controller on port TCP 9389.
If packets are sent but never arrive, or arrive and the domain controller replies but they never reach the
client, it is likely there is a firewall in between the computers on the network dropping packets on that port.
This firewall may be software or hardware, and may be part of third party endpoint protection (antivirus)
software.
See Also
AD Recycle Bin, Fine-Grained Password Policy, and PowerShell History
This topic lists resources that are available for using virtualized domain controllers.
Introduction to Active Directory Domain Services (AD DS ) Virtualization (Level 100)
Virtualized Domain Controller Technical Reference (Level 300)
Virtualized Domain Controller Cloning Test Guidance for Application Vendors
Support for using Hyper-V Replica for virtualized domain controllers
Introduction to Active Directory Domain Services (AD
DS) Virtualization (Level 100)
Virtualization of Active Directory Domain Services (AD DS ) environments has been ongoing for a number of years.
Beginning with Windows Server 2012, AD DS provides greater support for virtualizing domain controllers by
introducing virtualization-safe capabilities.
Safe virtualization of domain controllers

Virtual environments present unique challenges to distributed workloads that depend upon a logical clock-based
replication scheme. AD DS replication, for example, uses a monotonically increasing value (known as a USN or
Update Sequence Number) assigned to transactions on each domain controller. Each domain controller's database
instance is also given an identity, known as an InvocationID. The InvocationID of a domain controller and its USN
together serve as a unique identifier associated with every write-transaction performed on each domain controller
and must be unique within the forest.
AD DS replication uses InvocationID and USNs on each domain controller to determine what changes need to be
replicated to other domain controllers. If a domain controller is rolled back in time outside of the domain
controller's awareness and a USN is reused for an entirely different transaction, replication will not converge
because other domain controllers will believe they have already received the updates associated with the re-used
USN under the context of that InvocationID.
For example, the following illustration shows the sequence of events that occurs in Windows Server 2008 R2 and
earlier operating systems when USN rollback is detected on VDC2, the destination domain controller that is
running on a virtual machine. In this illustration, the detection of USN rollback occurs on VDC2 when a replication
partner detects that VDC2 has sent an up-to-dateness USN value that was seen previously by the replication
partner, which indicates that VDC2's database has rolled back in time improperly.
A virtual machine (VM ) makes it easy for hypervisor administrators to roll back a domain controller's USNs (its
logical clock) by, for example, applying a snapshot outside of the domain controller's awareness. For more
information about USN and USN rollback, including another illustration to demonstrate undetected instances of
USN rollback, see USN and USN Rollback.
Beginning with Windows Server 2012 , AD DS virtual domain controllers hosted on hypervisor platforms that
expose an identifier called VM -Generation ID can detect and employ necessary safety measures to protect the AD
DS environment if the virtual machine is rolled back in time by the application of a VM snapshot. The VM -
GenerationID design uses a hypervisor-vendor independent mechanism to expose this identifier in the address
space of the guest virtual machine, so the safe virtualization experience is consistently available of any hypervisor
that supports VM -GenerationID. This identifier can be sampled by services and applications running inside the
virtual machine to detect if a virtual machine has been rolled back in time.
How do these virtualization safeguards work?
During domain controller installation, AD DS initially stores the VM GenerationID identifier as part of the msDS -
GenerationID attribute on the domain controller's computer object in its database (often referred to as the directory
information tree, or DIT). The VM GenerationID is independently tracked by a Windows driver inside the virtual
machine.
When an administrator restores the virtual machine from a previous snapshot, the current value of the VM
GenerationID from the virtual machine driver is compared against a value in the DIT.
If the two values are different, the invocationID is reset and the RID pool discarded thereby preventing USN re-use.
If the values are the same, the transaction is committed as normal.
AD DS also compares the current value of the VM GenerationID from the virtual machine against the value in the
DIT each time the domain controller is rebooted and, if different, it resets the invocationID, discards the RID pool
and updates the DIT with the new value. It also non-authoritatively synchronizes the SYSVOL folder in order to
complete safe restoration. This enables the safeguards to extend to the application of snapshots on VMs that were
shutdown. These safeguards introduced in Windows Server 2012 enable AD DS administrators to benefit from the
unique advantages of deploying and managing domain controllers in a virtualized environment.
The following illustration shows how virtualization safeguards are applied when the same USN rollback is detected
on a virtualized domain controller that runs Windows Server 2012 on a hypervisor that supports VM -
GenerationID.
In this case, when the hypervisor detects a change to VM -GenerationID value, virtualization safeguards are
triggered, including the reset of the InvocationID for the virtualized DC (from A to B in the preceding example) and
updating the VM -GenerationID value saved on the VM to match the new value (G2) stored by the hypervisor. The
safeguards ensure that replication converges for both domain controllers.
With Windows Server 2012 , AD DS employs safeguards on virtual domain controllers hosted on VM -
GenerationID aware hypervisors and ensures that the accidental application of snapshots or other such hypervisor-
enabled mechanisms that could rollback a virtual machine's state does not disrupt the AD DS environment (by
preventing replication problems such as a USN bubble or lingering objects). However, restoring a domain
controller by applying a virtual machine snapshot is not recommended as an alternative mechanism to backing up
a domain controller. It is recommended that you continue to use Windows Server Backup or other VSS -writer
based backup solutions.
Cau t i on
If a domain controller in a production environment is accidentally reverted to a snapshot, it's advised that you
consult the vendors for the applications, and services hosted on that virtual machine, for guidance on verifying the
state of these programs after snapshot restore.
For more information, see Virtualized domain controller safe restore architecture.
Virtualized domain controller cloning

Beginning with Windows Server 2012 , administrators can easily and safely deploy replica domain controllers by
copying an existing virtual domain controller. In a virtual environment, administrators no longer have to repeatedly
deploy a server image prepared by using sysprep.exe, promote the server to a domain controller and then
complete additional configuration requirements for deploying each replica domain controller.
NOTE
Administrators need to follow existing processes to deploy the first domain controller in a domain, such as using a sysprep.exe
to prepare a server virtual hard disk (VHD), promote the server to a domain controller and then complete any additional
configuration requirements. In a disaster recovery scenario, use the latest server backup to restore the first domain controller
in a domain.
Scenarios that benefit from virtual domain controller cloning

Rapid deployment of additional domain controllers in a new domain
Quickly restore business continuity during disaster recovery by restoring AD DS capacity via rapid
deployment of domain controllers using cloning
Optimize private cloud deployments by leveraging elastic provisioning of domain controllers to
accommodate increased scale requirements
Rapid provisioning of test environments enabling deployment and testing of new features and capabilities
before production rollout
Quickly meet increased capacity needs in branch offices by cloning existing domain controllers in branch
offices
When rapidly deploying a large number of domain controllers, continue to follow your existing procedures for
validating the health of each domain controller after installation finishes. Deploy domain controllers in reasonably
sized batches so you can validate their health after each batch of installations is complete. The recommended batch
size is 10. For more information, see Steps for deploying a clone virtualized domain controller.
Clear separation of responsibilities
The authorization to clone virtualized domain controllers is under the control of the AD DS administrator. In order
for hypervisor administrators to deploy additional domain controllers by copying virtual domain controllers, the
AD DS administrator has to select and authorize a domain controller and then run preparatory steps to enable it as
a source for cloning.
With the virtual machine provisioning typically under the purview of the hypervisor administrator, hypervisor
administrators can provision replica domain controller virtual machines by copying virtualized domain controllers
that are authorized and prepared for cloning by the AD DS administrator.
WARNING
Anyone allowed to administer the hypervisor that hosts a virtual domain controller must be highly trusted and audited in the
environment.
How does virtual domain controller cloning work?

The process of cloning involves making a copy of an existing virtual domain controller's VHD (or, for more complex
configurations, the domain controller VM ), authorizing it for cloning in AD DS and creating a clone configuration
file. This reduces the number of steps and time involved in deploying a replica virtual domain controller by
eliminating otherwise repetitive deployment tasks.
The clone domain controller uses the following criteria to detect that it is a copy of another domain controller:
1. The value of the VM -Generation ID supplied by the virtual machine is different than the value of the VM -
Generation ID stored in the DIT.
NOTE
The hypervisor platform must support VM-Generation ID ( Windows Server 2012 Hyper-V supports VM-Generation
ID).
2. Presence of a file called DCCloneConfig.xml in one of the following locations:

The directory where the DIT resides
%windir%\NTDS
The root of a removable media drive
Once the criteria are met, it goes through the process of cloning to provision itself as a replica domain controller.
The clone domain controller uses the security context of the source domain controller (the domain controller whose
copy it represents) to contact the Windows Server 2012 Primary Domain Controller (PDC ) emulator operations
master role holder (also known as flexible single master operations, or FSMO ). The PDC emulator must be running
Windows Server 2012 , but it does not have to be running on a hypervisor.
NOTE
If you have a schema extension with attributes that reference the source domain controller and the attribute is on one of the
objects copied (computer object, NTDS settings object) to create the clone, that attribute will not be copied or updated to
reference the clone domain controller.
After verifying that the requesting domain controller is authorized for cloning, the PDC emulator will create a new
machine identity including new account, SID, name, and password that identifies this machine as a replica domain
controller and send this information back to the clone. The clone domain controller will then prepare the AD DS
database files to serve as a replica and it will also clean up the machine state.
For more information, see Virtualized domain controller cloning architecture.
Cloning components
The cloning components include new cmdlets in the Active Directory module for Windows PowerShell and
associated XML files:
New-ADDCCloneConfigFile " This cmdlet creates and places DCCloneConfig.xml at the right location to
ensure it is available to trigger cloning. It also performs prerequisite checks to ensure successful cloning. It is
included in the Active Directory module for Windows PowerShell. You can run it locally on a virtualized
domain controller that is being prepared for cloning, or you can run it remotely using the -offline option. You
can specify settings for the clone domain controller, such as its name, site, and IP address.
The prerequisite checks that it performs are:
NOTE
The prerequisite checks are not performed when the "offline option is used. For more information, see Running New-
ADDCCloneConfigFile in offline mode.
The DC being prepared is authorized for cloning (is a member of the Cloneable Domain
Controllers group)
The PDC emulator runs Windows Server 2012 .
Any programs or services listed from running Get-ADDCCloningExcludedApplicationList are
included in CustomDCCloneAllowList.xml (explained in more detail at the end of this list of cloning
components).
DCCloneConfig.xml " To successfully clone a virtualized domain controller, this file must be present in the
directory where the DIT resides, %windir%\NTDS, or the root of a removable media drive. Besides being
used as one of the triggers to detect and initiate cloning, it also provides a means to specify configuration
settings for the clone domain controller.
The schema and a sample file for the DCCloneConfig.xml file are stored on all Windows Server 2012
computers at:
%windir%\system32\DCCloneConfigSchema.xsd
%windir%\system32\SampleDCCloneConfig.xml
It is recommended that you use the New -ADDCCloneConfigFile cmdlet to create the DCCloneConfig.xml
file. Although you could also use the schema file with an XML -aware editor to create this file, manually
editing the file increases the likelihood of errors. If you edit the file, it must be done by using XML -aware
editors, such as Visual Studio, XML Notepad, or third-party applications (do not use Notepad).
Get-ADDCCloningExcludedApplicationList " This cmdlet is run on the source domain controller before
beginning the cloning process to determine which services or installed programs are not on the default
supported list, DefaultDCCloneAllowList.xml, or a user-defined inclusion list named
CustomDCCloneAllowList.xml file, and thereby have not been evaluated for cloning impact.
This cmdlet searches the source domain controller for services in the Services Control Manager, and
installed programs listed under HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall that
are not specified in the default list (DefaultDCCloneAllowList.xml) or, if one is provided, the user-defined
inclusion list (CustomDCCloneAllowList.xml file). The list of applications and services that is returned by
running the cmdlet is the difference between what has already been provided in the
DefaultDCCloneAllowList.xml or the CustomDCCloneAllowList.xml file and the list that is constructed at run
time, based on what is installed on the source DC. The services and programs output from Get-
ADDCCloningExcludedApplicationList can be added to the CustomDCCloneAllowList.xml file if you
determine that the services and programs can be safely cloned. To determine if a service or installed
program can be safely cloned, evaluate the following conditions:
Is the service or installed program affected by the machine identity, such as name, SID, password, and
so on?
Does the service or installed program store any state locally on the computer that might affect its
functionality on the clone?
You must work with the software vendor of the application to determine if the service or program can be
safely cloned.
NOTE
Before provisioning additional services or programs in the CustomDCCloneAllowList.xml file, verify whether you have
the necessary license to copy that software contained on that virtual machine.
If the applications are not cloneable, remove them from the source domain controller before you create the
clone media. If an application appears in the cmdlet output, but is not included in the
CustomDCCloneAllowList.xml file, cloning will fail. For cloning to succeed, the cmdlet output should not list
any services or programs. In other words, an application should either be included in the
CustomDCCloneAllowList.xml file or removed from the source domain controller.
The following table explains the options for running Get-ADDCCloningExcludedApplicationList.
Argument Explanation
Displays a list of services or programs on the console that

have not been accounted for cloning. If there is already a
CustomDCCloneAllowList.XML in any of the permissible
locations, it uses that file to displays the remaining services
and programs (which may be nothing if the lists match).
-GenerateXml Creates the CustomDCCloneAllowList.XML file populated

with the services and programs listed on the console.
-Force Overwrites an existing CustomDCCloneAllowList.XML file.
-Path Folder path to create the CustomDCCloneAllowList.XML.
DefaultDCCloneAllowList.xml " This file is present by default on every Windows Server 2012 domain
controller in the %windir%\system32. It lists the services and installed programs that can be safely cloned by
default. You must not change the location or contents of this file or cloning will fail.
CustomDCCloneAllowList.xml " If you have services or installed programs that reside on your source
domain controller that are outside of those listed in the DefaultDCCloneAllowList.xml file, those services and
programs must be included in this file. To find the services or installed programs that are not listed in the in
the DefaultDCCloneAllowList.xml file, run the Get-ADDCCloningExcludedApplicationList cmdlet. You
should use the "GenerateXml argument to generate the XML file.
The cloning process checks the following locations in order for this file and uses the first XML file found,
regardless of the other folder's contents:
1. The following registry key:
HKey_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters
AllowListFolder (REG_SZ)
2. DSA Working Directory

3. %systemroot%\NTDS
4. Removable read/write media, in order of drive letter, at the root of the drive
Deployment scenarios
The following deployment scenarios are supported for virtual domain controller cloning:
Deploy a clone domain controller by making a copy of a source domain controller's virtual hard disk (vhd)
file.
Deploy a clone domain controller by copying the virtual machine of a source domain controller using the
export/import semantics exposed by the hypervisor.
NOTE
The steps in the section Steps for deploying a clone virtualized domain controller demonstrate copying a virtual machine
using the export/import feature of Windows Server 2012 Hyper-V.
Steps for deploying a clone virtualized domain controller

Prerequisites
Step 1: Grant the source virtualized domain controller the permission to be cloned
Step 2: Run Get-ADDCCloningExcludedApplicationList cmdlet
Step 3: Run New -ADDCCloneConfigFile
Step 4: Export and then import the virtual machine of the source domain controller
Prerequisites
To complete the steps in the following procedures, you must be a member of the Domain Admins group or
have the equivalent permissions assigned to it.
The Windows PowerShell commands used in this guide must be run from an elevated command prompt. To
do this, right click the Windows PowerShell icon, and then click Run as administrator.
A Windows Server 2012 server with the Hyper-V server role installed (HyperV1).
A second Windows Server 2012 server with the Hyper-V server role installed (HyperV2).
NOTE
If you are using another hypervisor, you should contact the vendor of that hypervisor to verify if the hypervisor
supports VM-Generation ID. If the hypervisor does not support VM-Generation ID and you have provided a
DCCloneConfig.xml, the new VM will boot into Directory Services Restore Mode (DSRM).
To increase the availability of the AD DS service, this guide recommends and provides instructions using two
different Hyper-V hosts, which helps prevent a potentially single point of failure. However, you do not need two
Hyper-V hosts to perform virtual domain controller cloning.
You need to be a member of the local Administrators group on each Hyper-V server ( HyperV1 and HyperV2).
In order to successfully import and export a VHD file using Hyper-V, the virtual network switches on both Hyper-
V hosts should have the same name. For example, if you have a virtual network switch on HyperV1 named VNet
then there needs to be a virtual network switch on HyperV2 named VNet.
If the two Hyper-V hosts (HyperV1 and HyperV2) have different processors, shut down the virtual machine
(VirtualDC1) that you plan to export, right-click the VM, click Settings, click Processor, and under Processor
compatibility select Migrate to a physical computer with a different processor version and click OK.
A deployed Windows Server 2012 domain controller (virtualized or physical) that hosts the PDC emulator
role (DC1). To verify whether the PDC emulator role is hosted on a Windows Server 2012 domain controller,
run the following Windows PowerShell command:
Get-ADComputer (Get-ADDomainController "Discover "Service "PrimaryDC").name "Property

operatingsystemversion | fl
The OperatingSystemVersion value should return as a version 6.2. If necessary, you can transfer the PDC
emulator role to a domain controller that runs Windows Server 2012 . For more information, see Using
Ntdsutil.exe to transfer or seize FSMO roles to a domain controller.
A deployed Windows Server 2012 guest virtualized domain controller (VirtualDC1) that is in the same
domain as the Windows Server 2012 domain controller hosting the PDC emulator role (DC1). This will be
the source domain controller used for cloning. The guest virtual domain controller will be hosted on a
Windows Server 2012 Hyper-V server (HyperV1).
NOTE
For cloning to succeed, the source domain controller that is used to create the clone cannot be from a DC that has
been demoted since the source VHD media was created.
Shut down the source domain controller prior to copying the VM or its VHD.
You should not clone a VHD or restore a snapshot that is older than the tombstone lifetime value (or the deleted
object lifetime value if Active Directory Recycle Bin is enabled). If you are copying a VHD of an existing domain
controller, be sure the VHD file is not older that the tombstone lifetime value (by default, 60 days). You should not
copy a VHD of a running domain controller to create clone media.
Eject any virtual floppy drive (VFD ) the source DC may have. This can cause a sharing problem when trying
to import the new VM.
Only Windows Server 2012 domain controllers hosted on a VM -GenerationID hypervisor can be used as a
source for cloning. The source Windows Server 2012 domain controller used for cloning should be in a
healthy state. To determine the state of the source domain controller run dcdiag. To gain a better
understanding of the output returned by dcdiag, see What does DCDIAG actually...do?.
If the source domain controller is a DNS server, the cloned domain controller will also be a DNS server. You
should choose a DNS server that hosts only Active Directory-integrated zones.
DNS client settings are not cloned but are instead specified in the DCCloneConfig.xml file. If they are not
specified, the cloned domain controller will point to itself as Preferred DNS server by default. The cloned
domain controller will not have a DNS delegation. The administrator of the parent DNS zone should update
the DNS delegation for the cloned domain controller as needed.
WARNING
The virtualization safeguards do not extend to Active Directory Lightweight Directory Services (AD LDS). Therefore you
should not attempt to clone an AD DS domain controller that hosts an AD LDS instance by adding this AD LDS
instance to the CustomDCCloneAllowList.xml. Because AD LDS is not VM-Generation ID aware, cloning a domain
controller with AD LDS can cause USN rollback-induced divergence on that AD LDS configuration set.
The following server roles are not supported for cloning:

Dynamic Host Configuration Protocol (DHCP )
Active Directory Certificate Services (AD CS )
Active Directory Lightweight Directory Services (AD LDS )
Step 1: Grant the source virtualized domain controller the permission to be cloned
In this procedure, you grant the source domain controller the permission to be cloned by using Active Directory
Administrative Center to add the source domain controller to the Cloneable Domain Controllers group.
To g r a n t t h e so u r c e v i r t u a l i z e d d o m a i n c o n t r o l l e r t h e p e r m i ssi o n t o b e c l o n e d
1. On any domain controller in the same domain as the domain controller being prepared for cloning
(VirtualDC1), open Active Directory Administrative Center (ADAC ), locate the virtualized domain
controller object (domain controllers are usually located under the Domain Controllers container in
ADAC ), right click it, choose Add to group and under Enter the object name to select type Cloneable
Domain Controllers and then click OK.
The group membership update performed in this step must replicate to PDC emulator before cloning can be
performed. If the Cloneable Domain Controllers group is not found, the PDC emulator role might not be
hosted on a domain controller that runs Windows Server 2012 .
NOTE
To open ADAC on a Windows Server 2012 domain controller, open Windows PowerShell and type dsac.exe.

The following Windows PowerShell cmdlet performs the same function as the preceding procedure:
Add-ADGroupMember "Identity "CN=Cloneable Domain Controllers,CN=Users, DC=Fabrikam,DC=Com" "Member

"CN=VirtualDC1,OU=Domain Controllers,DC=Fabrikam,DC=com"
Step 2: Run Get-ADDCCloningExcludedApplicationList cmdlet

In this procedure, run the Get-ADDCCloningExcludedApplicationList cmdlet on the source virtualized domain
controller to identify any programs or services that are not evaluated for cloning. You need to run the Get-
ADDCCloningExcludedApplicationList cmdlet before the New -ADDCCloneConfigFile cmdlet because if the New -
ADDCCloneConfigFile cmdlet detects an excluded application, it will not create a DCCloneConfig.xml file.
To i d e n t i fy a p p l i c a t i o n s o r se r v i c e s t h a t r u n o n a so u r c e d o m a i n c o n t r o l l e r w h i c h h a v e n o t b e e n e v a l u a t e d fo r c l o n i n g
1. On the source domain controller (VirtualDC1), click Server Manager, click Tools, click Active Directory
Module for Windows PowerShell and then type the following command:
Get-ADDCCloningExcludedApplicationList
1. Vet the list of the returned services and installed programs with the software vendor to determine whether
they can be safely cloned. If applications or services in the list cannot be safely cloned, you must remove
them from the source domain controller or cloning will fail.
2. For the set of services and installed programs that were determined to be safely cloned, run the command
again with the "GenerateXML switch to provision these services and programs in the
CustomDCCloneAllowList.xml file.
Get-ADDCCloningExcludedApplicationList -GenerateXml
Step 3: Run New-ADDCCloneConfigFile

Run New -ADDCCloneConfigFile on the source domain controller, and optionally specify configuration settings for
the clone domain controller, such as the name, the IP address, and DNS resolver.
For example, to create a clone domain controller named VirtualDC2 with a static IPv4 address, type:
New-ADDCCloneConfigFile "Static -IPv4Address "10.0.0.2" -IPv4DNSResolver "10.0.0.1" -IPv4SubnetMask

"255.255.255.0" -CloneComputerName "VirtualDC2" -IPv4DefaultGateway "10.0.0.3" -SiteName "REDMOND"
NOTE
The clone domain controller will be located in the same site as the source domain controller unless a different site is specified
in the DCCloneConfig.xml file. It is recommended that you specify a suitable site in the DCCloneConfig.xml file for the clone
domain controller based on its IP address.
The computer name is optional. If you do not specify one, a unique name will be generated based on the following
algorithm:
The prefix is the first 8 characters of the source domain controller computer name. For example, a source
computer name of SourceComputer is truncated to a prefix string of SourceCo.
A unique naming suffix of the format ""CLnnnn" is appended to the prefix string where nnnn is the next
available value from 0001-9999 that the PDC determines is not currently in use. For example, if 0047 is the
next available number in the allowed range, using the preceding example of the computer name prefix
SourceCo, the derived name to use for the clone computer will be set as SourceCo-CL0047.
NOTE
A global catalog server (GC) is required for the New-ADDCCloneConfigFile cmdlet to work successfully. The source domain
controller's membership in the Cloneable Domain Controllers group must be reflected on the GC. The GC does not need to
be the same domain controller as the PDC emulator, but preferably it should be in the same site. If a GC is not available, the
command fails with the error "The server is not operational." For more information, see Virtualized Domain Controller
Troubleshooting.
To create a clone domain controller named Clone1 with static IPv4 settings and specify preferred and alternate
WINS servers, type:
New-ADDCCloneConfigFile "CloneComputerName "Clone1" "Static -IPv4Address "10.0.0.5" "IPv4DNSResolver "10.0.0.1"

"IPv4SubnetMask "255.255.0.0" "PreferredWinsServer "10.0.0.1" "AlternateWinsServer "10.0.0.2"
NOTE
If you specify WINS servers, you must specify both "PreferredWINSServer and "AlternateWINSServer. If you specify only
of those arguments, cloning fails with error code 0x80041005 appearing in the dcpromo.log.
To create a clone domain controller named Clone2 with dynamic IPv4 settings, type:
New-ADDCCloneConfigFile -CloneComputerName "Clone2" -IPv4DNSResolver "10.0.0.1"
NOTE
In this case, there should be a DHCP server in the environment that the clone can reach and obtain IP address and other
relevant network settings.
To create a clone domain controller named Clone2 with dynamic IPv4 settings and specify preferred and alternate
WINS servers, type:
New-ADDCCloneConfigFile -CloneComputerName "Clone2" -IPv4DNSResolver "10.0.0.1" -SiteName "REDMOND"

"PreferredWinsServer "10.0.0.1" "AlternateWinsServer "10.0.0.2"
To create a clone domain controller with dynamic IPv6 settings, type:
New-ADDCCloneConfigFile -IPv6DNSResolver "2002:4898:e0:31fc:d61:2b0a:c9c9:2ccc"
To create a clone domain controller with static IPv6 settings, type:
New-ADDCCloneConfigFile "Static -IPv6DNSResolver "2002:4898:e0:31fc:d61:2b0a:c9c9:2ccc"

NOTE
When specifying IPv6 settings, the only difference between the static and dynamic settings is the inclusion of -Static switch.
The inclusion of the -Static switch makes it mandatory to specify at least one IPv6DNSResolver.The static IPv6 address is
expected to be configured via stateless address auto configuration (SLAAC) with router assigned prefixes. With dynamic IPv6,
the DNS resolvers are optional, but it's expected that the clone can reach an IPv6-enabled DHCP server on the subnet to
obtain IPv6 address and DNS configuration information.
Running New-ADDCCloneConfigFile in offline mode

If you have multiple copies of source domain controller media that have been prepared for cloning (meaning the
source domain controller is authorized for cloning, the Get-ADDCCloningExcludedApplicationList cmdlet has been
run, and so on) and you want to specify different settings for each copy of the media, you can run New -
ADDCCloneConfigFile in offline mode. This can be more efficient than individually preparing each VM, for
example, by importing each copy.
In this case, domain administrators can mount the offline disk and use Remote Server Administration Tools (RSAT)
to run the New -ADDCCloneConfigFile cmdlet with the -offline argument in order to add the XML files, which
allows for factory-like automation using new Windows PowerShell options included in Windows Server 2012. For
more information about how to mount the offline disk in order to run the New -ADDCCloneConfigFile cmdlet in
offline mode, see Adding XML to the Offline System Disk.
You should first run the cmdlet locally on the source media to ensure that prerequisite checks pass. The prerequisite
checks are not performed in offline mode because the cmdlet could be run from a machine that may not be from
the same domain or from a domain-joined computer. After you run the cmdlet locally, it will create a
DCCloneConfig.xml file. You may delete the DCCloneConfig.xml that is created locally if you plan to use the offline
mode subsequently.
To create a clone domain controller named CloneDC1 in offline mode, in a site called REDMOND" with static IPv4
address, type:
New-ADDCCloneConfigFile -Offline -CloneComputerName CloneDC1 -SiteName REDMOND -IPv4Address "10.0.0.2" -

IPv4DNSResolver "10.0.0.1" -IPv4SubnetMask "255.255.0.0" -IPv4DefaultGateway "10.0.0.1" -Static -Path
F:\Windows\NTDS
To create a clone domain controller named Clone2 in offline mode with static IPv4 and static IPv6 settings, type:
New-ADDCCloneConfigFile -Offline -IPv4Address "10.0.0.2" -IPv4DNSResolver "10.0.0.1" -IPv4SubnetMask

"255.255.0.0" -Static -IPv6DNSResolver "2002:4898:e0:31fc:d61:2b0a:c9c9:2ccc" -CloneComputerName "Clone2" -
PreferredWINSServer "10.0.0.1" -AlternateWINSServer "10.0.0.3" -Path F:\Windows\NTDS
To create a clone domain controller in offline mode with static IPv4 and dynamic IPv6 settings and specify multiple
DNS servers for the DNS resolver settings, type:
New-ADDCCloneConfigFile -Offline -IPv4Address "10.0.0.10" -IPv4SubnetMask "255.255.0.0" -IPv4DefaultGateway

"10.0.0.1" -IPv4DNSResolver @( "10.0.0.1","10.0.0.2" ) -Static -IPv6DNSResolver
"2002:4898:e0:31fc:d61:2b0a:c9c9:2ccc" -Path F:\Windows\NTDS
To create a clone domain controller named Clone1 in offline mode with dynamic IPv4 and static IPv6 settings, type:
New-ADDCCloneConfigFile -Offline -Static -IPv6DNSResolver "2002:4898:e0:31fc:d61:2b0a:c9c9:2ccc" -

CloneComputerName "Clone1" -PreferredWINSServer "10.0.0.1" -AlternateWINSServer "10.0.0.3" -SiteName "REDMOND"
-Path F:\Windows\NTDS
To create a clone domain controller in offline mode with dynamic IPv4 and dynamic IPv6 settings, type:
New-ADDCCloneConfigFile -Offline -IPv4DNSResolver "10.0.0.1" -IPv6DNSResolver

Step 4: Export and then import the virtual machine of the source domain controller
In this procedure, export the virtual machine of the source virtualized domain controller and then import the virtual
machine. This action creates a clone virtualized domain controller in your domain.
You need to be a member of the local Administrators group on each Hyper-V host. If you use different credentials
for each server, run the Windows PowerShell cmdlets to export and import the VM in different Windows
PowerShell sessions.
If there are snapshots on the source domain controller, they should be deleted before the source domain controller
is exported because the VM will not import if a snapshot has processor settings that are incompatible with the
target hyper-v host. If the processor settings are compatible between the source and target hyper-v hosts, you may
export and copy the source without deleting snapshots beforehand. After import, however, the snapshots must be
deleted from the clone VM before it starts.
To c o p y a v i r t u a l d o m a i n c o n t r o l l e r b y e x p o r t i n g a n d t h e n i m p o r t i n g t h e v i r t u a l i z e d so u r c e d o m a i n c o n t r o l l e r
1. On HyperV1, shutdown the source domain controller (VirtualDC1).

Stop-VM -Name VirtualDC1 -ComputerName HyperV1
2. On HyperV1, delete snapshots and then export the source domain controller (VirtualDC1) to the
c:\CloneDCs directory.
NOTE
You should delete all the associated snapshots because each time a snapshot is taken, a new AVHD file is created that acts as
differencing disk. This creates a chain affect. If you have taken snapshots and insert the DCCLoneConfig.xml file into the VHD,
you may end up creating a clone from an older DIT version or inserting the configuration file into the wrong VHD file.
Deleting the snapshot merges all these AVHDs into the base VHD.
Get-VMSnapshot VirtualDC1 | Remove-VMSnapshot -IncludeAllChildSnapshots

Export-VM -Name VirtualDC1 -ComputerName HyperV1 -Path c:\CloneDCs\VirtualDC1
1. Copy the folder virtualdc1 to the c:\Import directory of HyperV2.

2. On HyperV2, using Hyper-V Manager, import the virtual machine (using the Import Virtual Machine
wizard in Hyper-V Manager) from the folder c:\Import\virtualdc1 and delete all associated Snapshots.
Use the Copy the virtual machine (create new unique ID ) option when importing the virtual machine.
$path = Get-ChildItem "C:\CloneDCs\VirtualDC1\VirtualDC1\Virtual Machines"

$vm = Import-VM -Path $path.fullname -Copy -GenerateNewId
Rename-VM $vm VirtualDC2
To create multiple clone domain controllers from the same source domain controller:
UI: in the Import Virtual Machine wizard, specify new locations for Virtual machine configuration
folder, Snapshot store, Smart Paging folder, and a different Location for the virtual hard disks for the
virtual machine.
Windows PowerShell: specify new locations for the virtual machine by using the following parameters for
the Import-VM cmdlet:
$path = Get-ChildItem "C:\CloneDCs\VirtualDC1\VirtualDC1\Virtual Machines" Import-VM -Path
$path.fullname -Copy -GenerateNewId -ComputerName HyperV2 -VhdDestinationPath "path" -
SnapshotFilePath "path" -SmartPagingFilePath "path" -VirtualMachinePath "path"
NOTE
The recommended batch size for creating multiple clone domain controllers simultaneously is 10. The maximum number is
restricted by the maximum number of outbound replication connections, which by default is 16 for Distributed File System
Replication (DFSR) and 10 for File Replication Service (FRS). You should not deploy more than the recommended number of
clone domain controllers simultaneously unless you have thoroughly tested that number for your environment.
1. On HyperV1, restart the source domain controller ((VirtualDC1) to bring it back online.
Start-VM -Name VirtualDC1 -ComputerName HyperV1
1. On HyperV2, start the virtual machine ( VirtualDC2) to bring it online as a clone domain controller in the
domain.
Start-VM -Name VirtualDC2 -ComputerName HyperV2
NOTE
The PDC emulator must be running for cloning to succeed. If it was shutdown, make sure it has started and performed initial
synchronization so it is aware that is holds the PDC emulator role. For more information, see Microsoft KB article 305476.
After cloning completes, verify the name of the clone computer to ensure the cloning operation succeeded. Verify
that the VM did not start in Directory Services Restore Mode (DSRM ). If you try to log on and receive an error
indicating no logon servers are available, try logging on in DSRM. If the DC did not clone successfully and it is
booted in DSRM, check the logs in Event Viewer and dcpromo logs in the %systemroot%/debug folder.
The cloned domain controller will be a member of the Cloneable Domain Controllers group because it copies
the membership from the source domain controller. As a best practice, you should leave the Cloneable Domain
Controllers group empty until you are ready to perform cloning operations, and you should remove members
after cloning operations are complete.
If the source domain controller stores a backup media, the cloned domain controller will also store the backup
media. You can run wbadmin get versions to show the backup media on the cloned domain controller. A member of
the Domain Admins group should delete the backup media on the cloned domain controller to prevent it from
being accidentally restored. For more information about how to delete a system state backup using wbadmin.exe,
see Wbadmin delete systemstatebackup.
Troubleshooting
If the clone domain controller (VirtualDC2) starts in Directory Services Restore Mode (DSRM ), it does not return
to a normal mode on its own on the next reboot. To log on to a domain controller that is started in DSRM, use
.\Administrator and specify the DSRM password.
Correct the cause for cloning failure and verify that the dcpromo.log does not indicate that cloning cannot be re-
tried. If cloning cannot be re-tried, safely discard the media. If cloning can be re-tried, you must remove the DS
Restore Mode boot flag in order to try cloning again.
1. Open Windows Server 2012 with an elevated command (right click Windows Server 2012 and choose Run
as Administrator), and then type msconfig.
2. On the Boot tab, under Boot Options, clear Safe boot (it is already selected with the option Active
Directory repair enabled).
3. Click OK and restart when prompted.
For more troubleshooting information about virtualized domain controllers, see Virtualized Domain Controller
Troubleshooting.
Virtualized Domain Controller Technical Reference
(Level 300)
The virtualized domain controller (VDC ) technical reference consists of the following topics:
Virtualized Domain Controller Deployment and Configuration
Virtualized Domain Controller Technical Reference Appendix
Virtualized Domain Controller Additional Resources
This topic covers the architecture of virtualized domain controller cloning and safe restore. It shows the processes
cloning and safe restore with flowcharts and then provides a detailed explanation of each step in the process.
Virtualized domain controller cloning architecture
Virtualized domain controller safe restore architecture
Virtualized domain controller cloning architecture

Overview
Virtualized domain controller cloning relies on the hypervisor platform to expose an identifier called VM -
Generation ID to detect creation of a virtual machine. AD DS initially stores the value of this identifier in its
database (NTDS.DIT) during domain controller promotion. When the virtual machine boots up, the current value of
the VM -Generation ID from the virtual machine is compared against the value in the database. If the two values are
different, the domain controller resets the Invocation ID and discards the RID pool, thereby preventing USN re-use
or the potential creation of duplicate security-principals. The domain controller then looks for a DCCloneConfig.xml
file in the locations called out in Step 3 in Cloning Detailed Processing. If it finds a DCCloneConfig.xml file, it
concludes that it is being deployed as a clone, so it initiates cloning to provision itself as an additional domain
controller by re-promoting using the existing NTDS.DIT and SYSVOL contents copied from source media.
In a mixed environment where some hypervisors support VM -GenerationID and others do not, it is possible for a
clone media to be accidentally deployed on a hypervisor that does not support VM -GenerationID. The presence of
DCCloneConfig.xml file indicates administrative intent to clone a DC. Therefore, if a DCCloneConfig.xml file is
found during boot but a VM -GenerationID is not provided from the host, the clone DC is booted into Directory
Services Restore Mode (DSRM ) to prevent any impact to the rest of the environment. The clone media can be
subsequently moved to a hypervisor that supports VM -GenerationID and then cloning can be retried.
If the clone media is deployed on a hypervisor that supports VM -GenerationID but a DCCloneConfig.xml file is not
provided, as the DC detects a VM -GenerationID change between its DIT and the one from the new VM, it will
trigger safeguards to prevent USN re-use and avoid duplicate SIDs. However, cloning will not be initiated, so the
secondary DC will continue to run under the same identity as the source DC. This secondary DC should be
removed from the network at the earliest possible time to avoid any inconsistencies in the environment. For more
information about how to reclaim this secondary DC while ensuring that updates get replicated outbound, see
Microsoft KB article 2742970.
Cloning Detailed Processing
The following diagram shows the architecture for an initial cloning operation and for a cloning retry operation.
These processes are explained in more detail later in this topic.
Initial Cloning Operation
Cloning retry operation
The following steps explain the process in more detail:

1. An existing virtual machine domain controller boots up in a hypervisor that supports VM -Generation ID.
a. This VM has no existing VM Generation-ID value set on its AD DS computer object after promotion.
b. Even if it is null, the next computer creation will mean it still clones, as a new VM Generation-ID will
not match.
c. The VM Generation-ID is set after the next reboot of the DC, and does not replicate.
2. The virtual machine then reads the VM -Generation ID provided by the VMGenerationCounter driver. It
compares the two VM -Generation IDs.
a. If the IDs match, this is not a new virtual machine and cloning will not proceed. If a
DCCloneConfig.xml file exists, the domain controller renames the file with a time-date stamp to
prevent cloning. The server continues booting normally. This is how every reboot of any virtual
domain controller operates in Windows Server 2012.
b. If the two IDs do not match, this is a new virtual machine that contains an NTDS.DIT from a previous
domain controller (or it is a restored snapshot). If a DCCloneConfig.xml file exists, the domain
controller proceeds with cloning operations. If not, it continues with snapshot restoration operations.
See Virtualized domain controller safe restore architecture.
c. If the hypervisor does not provide a VM -Generation ID for comparison but there is a
DCCloneConfig.xml file, the guest renames the file and then boots into DSRM to protect the network
from a duplicate domain controller. If there is no dccloneconfig.xml file, the guest boots normally (with
the potential for a duplicate domain controller on the network). For more information about how to
reclaim this duplicate domain controller, see Microsoft KB article 2742970.
3. The NTDS service checks the value of the VDCisCloning DWORD registry value name (under
HKEY_Local_Machine\System\CurrentControlSet\Services\Ntds\Parameters).
a. If it does not exist, this is a first attempt at cloning for this virtual machine. The guest implements the
VDC object duplication safeguards of invalidating the local RID pool and setting a new replication
invocation ID for the domain controller
b. If it is already set to 0x1, this is a "retry" cloning attempt, where a previous cloning operation failed.
The VDC object duplication safety measures are not taken as they had to have already run once
before and would unnecessarily alter the guest multiple times.
4. The IsClone DWORD registry value name is written (under
Hkey_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters)
5. The NTDS service changes the guest boot flag to start in DS Repair Mode for any further reboots.
6. The NTDS service attempts to read the DcCloneConfig.xml in one of the three accepted locations (DSA
Working Directory, %windir%\NTDS, or removable read/write media, in order of drive letter, at the root of
the drive).
a. If the file does not exist in any valid location, the guest checks the IP address for duplication. If the IP
address is not duplicated, the server boots up normally. If there is a duplicate IP address, the
computer boots into DSRM to protect the network from a duplicate domain controller.
b. If the file does exist in a valid location, the NTDS service validates its settings. If the file is blank (or
any particular settings are blank) then NTDS configures automatic values for those settings.
c. If the DcCloneConfig.xml exists but contains any invalid entries or is unreadable, cloning fails and the
guest boots into Directory Services Restore Mode (DSRM ).
7. The guest disables all DNS auto-registration to prevent accidental hijacking of the source computer name
and IP addresses.
8. The guest stops the Netlogon service to prevent any advertising or answering of network AD DS requests
from clients.
9. NTDS validates that there are no services or programs installed that are not part of the
DefaultDCCloneAllowList.xml or CustomDCCloneAllowList.xml
a. If there are services or programs installed that are not in the default exclusion allow list or the custom
exclusion allow list, cloning fails and the guest boots into DSRM to protect the network from a
duplicate domain controller.
b. If there are no incompatibilities, cloning continues.
10. If automatic IP addressing will be used due to blank DCCloneConfig.xml network settings, the guest enables
DHCP on the network adapters to gain an IP address lease, network routing, and name resolution
information.
11. The guest locates and contacts the domain controller running the PDC emulator FSMO role. This uses DNS
and the DCLocator protocol. It makes an RPC connection and calls the method IDL_DRSAddCloneDC to
clone the domain controller computer object.
a. If the guest's source computer object holds domain head extended permission of "'Allow a DC to
create a clone of itself" then cloning proceeds.
b. If the guest's source computer object does not hold that extended permission, cloning fails and the
guest boots into DSRM to protect the network from a duplicate domain controller.
12. The AD DS computer object name is set to match the name specified in the DCCloneConfig.xml, if any, or
else automatically generated on the PDCE. NTDS creates the correct NTDS setting object for the
appropriate Active Directory logical site.
a. If this is a PDC cloning, then the guest renames the local computer and reboots. After reboot, it goes
through step 1 - 10 again, then goes to step 13.
b. If this is a replica DC cloning, there is no reboot at this stage.
13. The guest provides the promotion settings to the DS Role Server service, which commences promotion.
14. The DS Role Server service stops all of the AD DS -related services (NTDS, NTFRS/DFSR, KDC, DNS ).
15. The guest forces NT5DS (Windows NTP ) time synchronization with another domain controller (in a default
Windows Time Service hierarchy, this means using the PDCE ). The guest contacts the PDCE. All existing
Kerberos tickets flush.
16. The guest configures the DFSR or NTFRS services to run automatically. The guest deletes all existing DFSR
and NTFRS database files (default: c:\windows\ntfrs and c:\system volume
information\dfsr\<database_GUID>), in order to force non-authoritative synchronization of SYSVOL when
the service is next started. The guest does not delete the file contents of SYSVOL, to pre-seed the SYSVOL
when the synchronization starts later.
17. The guest is renamed. The DS Role Server service on the guest begins AD DS configuration (promotion),
using the existing NTDS.DIT database file as a source, rather than the template database included in
c:\windows\system32 like a promotion normally does.
18. The guest contacts the RID Master FSMO role holder to get a new RID pool allocation.
19. The promotion process creates a new invocation ID and recreates the NTDS Settings object for the cloned
domain controller (irrespective of cloning, this is part of domain promotion when using an existing
NTDS.DIT database).
20. NTDS replicates in objects that are missing, newer, or have a higher version from a partner domain
controller. The NTDS.DIT already contains objects from the time the source domain controller went offline,
and those are used as possible in order to minimize replication traffic inbound. The global catalog partitions
are populated.
21. The DFSR or FRS service starts and because there is no database, SYSVOL non-authoritatively
synchronizes inbound from a replication partner. This process re-uses pre-existing data in the SYSVOL
folder, in order to minimize network replication traffic.
22. The guest re-enables DNS client registration now that the computer is uniquely named and networked.
23. The guest runs the SYSPREP modules specified by the DefaultDCCloneAllowList.xml element in order to
scrub out references to the previous computer name and SID.
24. Cloning promotion is complete.
a. The guest removes the DSRM boot flag so the next reboot will be normal.
b. The guest renames the DCCloneConfig.xml with an appended date-time stamp, so that it is not read
again at next boot up.
c. The guest removes the VdcIsCloning DWORD registry value name under
HKEY_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters.
d. The guest sets the "VdcCloningDone" DWORD registry value name under
HKEY_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters to 0x1. Windows does
not use this value, but instead provides it as a marker for third parties.
25. The guest updates the msDS -GenerationID attribute on its own cloned domain controller object to match
the current guest VM -Generation ID.
26. The guest restarts. It is now a normal, advertising domain controller.
Virtualized domain controller safe restore architecture

Overview
AD DS relies on the hypervisor platform to expose an identifier called VM -Generation ID to detect the snapshot
restore of a virtual machine. AD DS initially stores the value of this identifier in its database (NTDS.DIT) during
domain controller promotion. When an administrator restores the virtual machine from a previous snapshot, the
current value of the VM -Generation ID from the virtual machine is compared against the value in the database. If
the two values are different, the domain controller resets the Invocation ID and discards the RID pool, thereby
preventing USN re-use or the potential creation of duplicate security-principals. There are two scenarios where safe
restore can occur:
When a virtual domain controller is started after a snapshot has been restored while it was shut down
When a snapshot is restored on a running virtual domain controller
If the virtualized domain controller in the snapshot is in a suspended state rather than shutdown, then you
need to restart the AD DS service to trigger a new RID pool request. You can restart the AD DS service by
using the Services snap-in or using Windows PowerShell (Restart-Service NTDS -force).
The following sections explain safe restore in detail for each scenario.
Safe Restore Detailed Processing
The following flowchart shows how safe restore occurs when a virtual domain controller is started after a snapshot
has been restored while it was shut down.
1. When the virtual machine boots up after a snapshot restore, it will have new VM -Generation ID provided by
the hypervisor host because of the snapshot restore.
2. The new VM -Generation ID from the virtual machine is compared to the VM -Generation ID in the database.
Because the two IDs do not match, it employs virtualization safeguards (see step 3 in the previous section).
After the restore finishes applying, the VM -GenerationID set on its AD DS computer object is updated to
match the new ID provide by the hypervisor host.
3. The guest employs virtualization safeguards by:
a. Invalidating the local RID pool.
b. Setting a new invocation ID for the domain controller database.
NOTE
This part of the safe restore overlaps with the cloning process. Although this process is about safe restore of a virtual domain
controller after it boots up following a snapshot restore, the same steps happen during the cloning process.
The following diagram shows how virtualization safeguards prevent divergence induced by USN rollback when a
snapshot is restored on a running virtual domain controller.
NOTE
The preceding illustration is simplified to explain the concepts.
1. At time T1, the hypervisor administrator takes a snapshot of virtual DC1. DC1 at this time has a USN value
(highestCommittedUsn in practice) of 100, InvocationId (represented as ID in the preceding diagram)
value of A (in practice this would be GUID ). The savedVMGID value is the VM -GenerationID in the DIT file
of the DC (stored against the computer object of the DC in an attribute named msDS -GenerationId). The
VMGID is the current value of the VM -GenerationId available from the virtual machine driver. This value is
supplied by the hypervisor.
2. At a later time T2, 100 users are added to this DC (consider users as an example of updates that could have
been performed on this DC between time T1 and T2; these updates could actually be a mix of user creations,
group creations, password updates, attribute updates, and so on). In this example, each update consumes
one unique USN (though in practice a user creation may consume more than one USN ). Before committing
these updates, DC1 checks if the value of VM -GenerationID in its database (savedVMGID ) is the same as
the current value available from the driver (VMGID ). They are same, as no rollback has happened yet, so the
updates are committed and USN moves up to 200, indicating that the next update can use USN 201. There
is no change in InvocationId, savedVMGID, or VMGID. These updates replicate out to DC2 at the next
replication cycle. DC2 updates it high watermark (and UptoDatenessVector) represented here simply as
DC1(A) @USN = 200. That is, DC2 is aware of all updates from DC1 in the context of InvocationId A
through USN 200.
3. At time T3, the snapshot taken at time T1 is applied to DC1. DC1 has been rolled back, so its USN rolls back
to 100, indicating it could use USNs from 101 to associate with subsequent updates. However, at this point,
the value of VMGID would be different on hypervisors that support VM -GenerationID.
4. Subsequently, when DC1 performs any update, it checks whether the value of VM -GenerationId that it has
in its database (savedVMGID ) is the same as the value from the virtual machine driver (VMGID ). In this
case, it is not the same, so DC1 infers this as indicative of a rollback, and it triggers virtualization safeguards;
in other words, it resets its InvocationId (ID = B ) and discards the RID pool (not shown in the preceding
diagram). It then saves the new value of VMGID in its database and commits those updates (USN 101 -
250) in the context of the new InvocationId B. At the next replication cycle, DC2 knows nothing from DC1 in
the context of InvocationId B, so it requests everything from DC1 associated with InvocationID B. As a result,
the updates performed on DC1 subsequent to the application of snapshot will safely converge. In addition,
the set of updates that were performed on DC1 at T2 (which were lost on DC1 after the restore of the
snapshot) would replicate back into DC1 at the next scheduled replication because they had replicated out to
DC2 (as indicated by the dotted line back to DC1).
After the guest employs virtualization safeguards, NTDS replicates Active Directory object differences inbound
non-authoritatively from a partner domain controller. The up-to-dateness vector of the destination directory service
is updated accordingly. Then the guest synchronizes SYSVOL:
If using FRS, the guest stops the NTFRS service and sets D2 BURFLAGS registry value. It then starts the
NTFRS service, which non-authoritatively replicates inbound, re-using existing unchanged SYSVOL data
when possible.
If using DFSR, the guest stops the DFSR service and deletes the DFSR database files (default location:
%systemroot%\system volume information\dfsr\). It then starts the DFSR service, which non-authoritatively
replicates inbound, re-using existing unchanged SYSVOL data when possible.
NOTE
If the hypervisor does not provide a VM-Generation ID for comparison, the hypervisor does not support virtualization
safeguards and the guest will operate like a virtualized domain controller that runs Windows Server 2008 R2 or earlier. The
guest implements USN rollback quarantine protection if there is an attempt to start replicating with USNs that have not
advanced past the last highest USN seen by the partner DC. For more information about USN rollback quarantine
protection, see USN and USN Rollback
Virtualized Domain Controller Deployment and
Configuration
This topic covers:

Installation Considerations
This includes platform requirements and other important constraints.
Virtualized Domain Controller Cloning
This explains in detail the entire virtualized domain controller cloning process.
Virtualized Domain Controller Safe Restore
This explains in detail the validations that are made during virtualized domain controller safe restore.
Installation Considerations
There is no special role or feature installation for virtualized domain controllers; all domain controllers
automatically contain cloning and safe restore capabilities. You cannot remove or disable these capabilities.
Use of Windows Server 2012 domain controllers requires a Windows Server 2012 AD DS Schema version 56 or
higher and forest functional level equal to Windows Server 2003 Native or higher.
Both writable and read-only domain controllers support all aspects of virtualized DC, as do Global Catalogs and
FSMO roles.
IMPORTANT
The PDC Emulator FSMO role holder must be online when cloning begins.
Platform Requirements
Virtualized Domain Controller cloning requires:
PDC emulator FSMO role hosted on a Windows Server 2012 DC
PDC emulator available during cloning operations
Both cloning and safe restore require:
Windows Server 2012 virtualized guests
Virtualization host platform supports VM -Generation ID (VMGID )
Review the table below for virtualization products and whether they support virtualized domain controllers and
VM -Generation ID.
Virtualization Product Supports virtualized domain controllers and VMGID

Microsoft Windows Server 2012 server with Hyper-V Yes
Feature
Microsoft Windows Server 2012 Hyper-V Server Yes
Microsoft Windows 8 with Hyper-V Client Feature Yes
Windows Server 2008 R2 and Windows Server 2008 No
Non-Microsoft virtualization solutions Contact vendor
Even though Microsoft supports Windows 7 Virtual PC, Virtual PC 2007, Virtual PC 2004, and Virtual Server 2005,
they cannot run 64-bit guests, nor do they support VM -GenerationID.
For help with third party virtualization products and their support stance with virtualized domain controllers,
contact that vendor directly.
For more information, review Support policy for Microsoft software running in non-Microsoft hardware
virtualization software.
Critical Caveats
Virtualized domain controllers do not support safe restore of the following:
VHD and VHDX files manually copied over existing VHD files
VHD and VHDX files restored using file backup or full disk backup software
NOTE
VHDX files are new to Windows Server 2012 Hyper-V.
Neither of these operations is covered under VM -GenerationID semantics and therefore do not change the VM -
Generation ID. Restoring domain controllers using these methods could either result in a USN rollback and either
quarantine the domain controller or introduce lingering objects and the need for forest wide cleanup operations.
WARNING
Virtualized domain controller safe restore is not a replacement for system state backups and the AD DS Recycle Bin.
After restoring a snapshot, the deltas of previously un-replicated changes originating from that domain controller after the
snapshot are permanently lost. Safe restore implements automated non-authoritative restoration to prevent accidental
domain controller quarantine only.
For more information about USN bubbles and lingering objects, see Troubleshooting Active Directory operations
that fail with error 8606: "Insufficient attributes were given to create an object".
Virtualized Domain Controller Cloning

There are a number of stages and steps to cloning a virtualized domain controller, regardless of using graphical
tools or Windows PowerShell. At a high level, the three stages are:
Prepare the environment
Step 1: Validate that the hypervisor supports VM -Generation ID and therefore, cloning
Step 2: Verify the PDC emulator role is hosted by a domain controller that runs Windows Server 2012 and
that it is online and reachable by the cloned domain controller during cloning.
Prepare the source domain controller
Step 3: Authorize the source domain controller for cloning
Step 4: Remove incompatible services or programs or add them to the CustomDCCloneAllowList.xml file.
Step 5: Create DCCloneConfig.xml
Step 6: Take the source domain controller offline
Create the cloned domain controller
Step 7: Copy or export the source VM and add the XML if not already copied
Step 8: Create a new virtual machine from the copy
Step 9: Start the new virtual machine to commence cloning
There are no procedural differences in the operation when using graphical tools such as the Hyper-V Management
Console or command-line tools such as Windows PowerShell, so the steps are presented only once with both
interfaces. This topic provides Windows PowerShell samples for you to explore end-to-end automation of the
cloning process; they are not required for any steps. There is no graphical management tool for virtualized domain
controllers included in Windows Server 2012.
There are several points in the procedure where you have choices for how to create the cloned computer and how
you add the xml files; these steps are noted in the details below. The process is otherwise unalterable.
The following diagram illustrates the virtualized domain controller cloning process, where the domain already
exists.
Step 1 - Validate the Hypervisor
Ensure the source domain controller is running on a supported hypervisor by reviewing vendor documentation.
Virtualized domain controllers are hypervisor-independent and do not require Hyper-V.
If the hypervisor is Microsoft Hyper-V, ensure it is running on Windows Server 2012 . You can validate this using
Device Management
Open Devmgmt.msc and examine System Devices for installed Microsoft Hyper-V devices and drivers. The
specific system device required for a virtualized domain controller is the Microsoft Hyper-V Generation Counter
(driver: vmgencounter.sys).
Step 2 - Verify the PDCE FSMO role
Before you attempt to clone a DC, you must validate that the domain controller hosting the Primary Domain
Controller Emulator FSMO runs Windows Server 2012. The PDC emulator (PDCE ) is required for several reasons:
1. The PDCE creates the special Cloneable Domain Controllers group and sets its permission on the root of
the domain to allow a domain controller to clone itself.
2. The cloning domain controller contacts the PDCE directly using the DRSUAPI RPC protocol, in order to
create computer objects for the clone DC.
NOTE
Windows Server 2012 extends the existing Directory Replication Service (DRS) Remote Protocol (UUID E3514235-
4B06-11D1-AB04-00C04FC2DCD2) to include a new RPC method IDL_DRSAddCloneDC (Opnum 28). The
IDL_DRSAddCloneDC method creates a new domain controller object by copying attributes from an existing domain
controller object.
The states of a domain controller are composed of computer, server, NTDS settings, FRS, DFSR, and connection objects
maintained for each domain controller. When duplicating an object, this RPC method replaces all references to the
original domain controller with corresponding objects of the new domain controller. The caller must have the control
access right DS-Clone-Domain-Controller on the domain naming context.
Use of this new method always requires direct access to the PDC emulator domain controller from the caller.
Because this RPC method is new, your network analysis software requires updated parsers to include fields for the new
Opnum 28 in the existing UUID E3514235-4B06-11D1-AB04-00C04FC2DCD2. Otherwise, you cannot parse this
traffic.
For more information, see 4.1.29 IDL_DRSAddCloneDC (Opnum 28).
This also means when using non -fully routed networks, virtualized domain controller cloning requires
network segments with access to the PDCE. It is acceptable to move a cloned domain controller to a different
network after cloning - just like a physical domain controller - as long as you are careful to update the AD DS
logical site information.
IMPORTANT
When cloning a domain that contains only a single domain controller, you must ensure the source DC is back online before
starting the clone copies. A production domain should always contain at least two domain controllers.
Active Directory Users and Computers Method

1. Using the Dsa.msc snap-in, right click the domain and click Operations Masters. Note the domain
controller named on the PDC tab and close the dialog.
2. Right-click that DC's computer object and click Properties, and then validate the Operating System info.
Windows PowerShell Method
You can combine the following Active Directory Windows PowerShell Module cmdlets to return the version of the
PDC emulator:
Get-adddomaincontroller
Get-adcomputer
If not provided the domain, these cmdlets assume the domain of the computer where run.
The following command returns PDCE and Operating System info:
get-adcomputer(Get-ADDomainController -Discover -Service "PrimaryDC").name -property * | format-list

dnshostname,operatingsystem,operatingsystemversion
This example below demonstrates specifying the domain name and filtering the returned properties before the
Windows PowerShell pipeline:
Step 3 - Authorize a Source DC

The source domain controller must have the control access right (CAR ) Allow a DC to create a clone of itself on
the domain NC head. By default, the well-known group Cloneable Domain Controllers has this permission and
contains no members. The PDCE creates this group when that FSMO role transfers to a Windows Server 2012
domain controller.
Active Directory Administrative Center Method
1. Start Dsac.exe and navigate to the source DC, then open its detail page.
2. In the Member Of section, add the Cloneable Domain Controllers group for that domain.
You can combine the following Active Directory Windows PowerShell Module cmdlets get-adcomputer and add-
adgroupmember to add a domain controller to the Cloneable Domain Controllers group:
Get-adcomputer <dc name> | %{add-adgroupmember "cloneable domain controllers" $_.samaccountname}
For instance, this adds server DC1 to the group, without the need to specify the distinguished name of the group
member:
Rebuilding Default Permissions

If you remove this permission from the domain head, cloning fails. You can recreate the permission using the Active
Directory Administrative Center or Windows PowerShell.
A c t i v e D i r e c t o r y A d m i n i st r a t i v e C e n t e r M e t h o d
1. Open Active Directory Administrative Center, right-click the domain head, click Properties, click the
Extensions tab, click Security, and then click Advanced. Click This Object Only.
2. Click Add, under Enter the object name to select, type the group name Cloneable Domain Controllers.
3. Under Permissions, click Allow a DC to create a clone of itself, and then click OK.
NOTE
You can also remove the default permission and add individual domain controllers. Doing so is likely to cause ongoing
maintenance problems however, where new administrators are unaware of this customization. Changing the default setting
does not increase security and is discouraged.
W i n d o w s P o w e r Sh e l l M e t h o d
Use the following commands in an administrator-elevated Windows PowerShell console prompt. These commands
detect the domain name and add back in the default permissions:
import-module activedirectory
cd ad:
$domainNC = get-addomain
$dcgroup = get-adgroup "Cloneable Domain Controllers"
$sid1 = (get-adgroup $dcgroup).sid
$acl = get-acl $domainNC
$objectguid = new-object Guid 3e0f7e18-2c7a-4c10-ba82-4d926db99a3e
$ace1 = new-object System.DirectoryServices.ActiveDirectoryAccessRule $sid1,"ExtendedRight","Allow",$objectguid
$acl.AddAccessRule($ace1)
set-acl -aclobject $acl $domainNC
cd c:
Alternatively, run the sample FixVDCPermissions.ps1 in a Windows PowerShell console, where the console starts
as an elevated administrator on a domain controller in the affected domain. It automatically set the permissions.
The sample is located in the appendix of this module.
Step 4 - Remove Incompatible applications or services (if not using CustomDCCloneAllowList.xml)
Any programs or services previously returned by Get-ADDCCloningExcludedApplicationList - and not added to
the CustomDCCloneAllowList.xml - must be removed prior to cloning. Uninstalling the application or service is the
recommended method.
WARNING
Any incompatible program or service not uninstalled or added to the CustomDCCloneAllowList.xml prevents cloning.
Use the Get-AdComputerServiceAccount cmdlet to locate any standalone Managed Service Accounts (MSAs) in
the domain and if this computer is using any of them. If any MSA is installed, use the Uninstall-ADServiceAccount
cmdlet to remove the locally installed service account. Once you are done with taking the source domain controller
offline in step 6, you can re-add the MSA using Install-ADServiceAccount when the server is back online. For more
information, see Uninstall-ADServiceAccount.
IMPORTANT
Standalone MSAs - first released in Windows Server 2008 R2 - were replaced in Windows Server 2012 with group MSAs.
Group MSAs support cloning.
Step 5 - Create DCCloneConfig.xml

The DcCloneConfig.xml file is required for cloning Domain controllers. Its contents allow you to specify unique
details like the new computer name and IP address.
The CustomDCCloneAllowList.xml file is optional unless you install applications or potentially incompatible
Windows services on the source domain controller. The files require precise naming, formatting, and placement;
otherwise, cloning fails.
For that reason, you should always use the Windows PowerShell cmdlets to create the XML files and place them in
the correct location.
Generating with New-ADDCCloneConfigFile
The Active Directory Windows PowerShell module contains a new cmdlet in Windows Server 2012:
New-ADDCCloneConfigFile
You run the cmdlet on the proposed source domain controller that you intend to clone. The cmdlet supports
multiple arguments and when used, always tests the computer and environment where it is run unless you specify
the -offline argument.
ActiveDirectory Arguments Explanation
Cmdlet
New-ADDCCloneConfigFile Creates a blank DcCloneConfig.xml file

in the DSA Working Directory (default:
%systemroot%\ntds)
-CloneComputerName Specifies the clone DC computer name.

String data type.
-Path Specifies the folder to create the

DcCloneConfig.xml. If not specified,
writes to the DSA Working Directory
(default: %systemroot%\ntds). String
data type.
-SiteName Specifies the AD logical site name to join
during cloned computer account
creation. String data type.
-IPv4Address Specifies the static IPv4 address of the

cloned computer. String data type.
-IPv4SubnetMask Specifies the static IPv4 subnet mask of

the cloned computer. String data type.
-IPv4DefaultGateway Specifies the static IPv4 default gateway

address of the cloned computer. String
data type.
-IPv4DNSResolver Specifies the static IPv4 DNS entries of

the cloned computer in a comma-
separated list. Array data type. Up to
four entries can be provided.
-PreferredWINSServer Specifies the static IPv4 address of the

primary WINS server. String data type.
-AlternateWINSServer Specifies the static IPv4 address of the

secondary WINS server. String data
type.
-IPv6DNSResolver Specifies the static IPv6 DNS entries of

the cloned computer in a comma-
separated list. There is no way to set
Ipv6 static information in virtualized
domain controller cloning. Array data
type.
-Offline Does not perform the validation tests

and overwrites any existing
dccloneconfig.xml. Has no parameters.
For more information, see Running
New-ADDCCloneConfigFile in offline
mode.
-Static Required if specifying static IP

arguments IPv4SubnetMask,
IPv4SubnetMask, or
IPv4DefaultGateway. Has no
parameters.
Tests performed when run in online mode:

PDC Emulator is Windows Server 2012 or later
Source domain controller is a member of Cloneable Domain Controllers group
Source domain controller does not include any excluded applications or services
Source domain controller does not already contain a DcCloneConfig.xml at the specified path
Step 6 - Take the Source Domain Controller Offline
You cannot copy a running source DC; it must be shutdown gracefully. Do not clone a domain controller stopped by
graceless power loss.
Graphical Method
Use the shutdown button within the running DC, or the Hyper-V Manager shutdown button.

You can shut down a virtual machine using either of the following cmdlets:
Stop-computer
Stop-vm
Stop-computer is a cmdlet that supports shutting down computers regardless of virtualization, and is analogous to
the legacy Shutdown.exe utility. Stop-vm is a new cmdlet in the Windows Server 2012 Hyper-V Windows
PowerShell module, and is equivalent to the power options in Hyper-V Manager. The latter is useful in lab
environments where the domain controller often operates on a private virtualized network.
Step 7 - Copy Disks

An administrative choice is required in the copying phase:
Copy the disks manually, without Hyper-V
Export the VM, using Hyper-V
Export the merged disks, using Hyper-V
All of a virtual machine's disks must be copied, not just the system drive. If the source domain controller uses
differencing disks and you plan to move your cloned domain controller to another Hyper-V host, you must export.
Copying disks manually is recommended if the source domain controller has only one drive. Export/Import is
recommended for VMs with more than one drive or other complex virtualized hardware customizations like
multiple NICs.
If copying files manually, delete any snapshots prior to copying. If exporting the VM, delete snapshots prior to
exporting or delete them from the new VM after importing.
WARNING
Snapshots are differencing disks that can return a domain controller to previous state. If you were to clone a domain
controller and then restore its pre-cloning snapshot, you would end up with duplicate domain controllers in the forest. There
is no value in prior snapshots on a newly cloned domain controller.
Manually Copying Disks

H y p e r- V M a n a g e r M e t h o d
Use the Hyper-V Manager snap-in to determine which disks are associated with the source domain controller. Use
the Inspect option to validate if the domain controller uses differencing disks (which requires that you copy the
parent disk also)
To delete snapshots, select a VM and delete the snapshot subtree.
You can then manually copy the VHD or VHDX files using Windows Explorer, Xcopy.exe, or Robocopy.exe. No
special steps are required. It is a best practice to change the file names even if moving to another folder.
NOTE
If copying between host computers on a LAN (1-Gbit or greater), the Xcopy.exe /J option copies VHD/VHDX files
considerably faster than any other tool, at the cost of much greater bandwidth usage.
To determine the disks using Windows PowerShell, use the Hyper-V Modules:
Get-vmidecontroller
Get-vmscsicontroller
Get-vmfibrechannelhba
Get-vmharddiskdrive
For example, you can return all IDE hard drives from a VM named DC2 with the following sample:
If the disk path points to an AVHD or AVHDX file, it is a snapshot. To delete the snapshots associated with a disk
and merge in the real VHD or VHDX, use cmdlets:
Get-VMSnapshot
Remove-VMSnapshot
For example, to delete all snapshots from a VM named DC2-SOURCECLONE:
To copy the files using Windows PowerShell, use the following cmdlet:
Copy-Item
Combine with VM cmdlets in pipelines to aid automation. The pipeline is a channel used between multiple cmdlets
to pass data. For example, to copy the drive of an offline source domain controller named DC2-SOURCECLONE to
a new disk called c:\temp\copy.vhd without the need to know the exact path to its system drive:
Get-VMIdeController dc2-sourceclone | Get-VMHardDiskDrive | select-Object {copy-item -path $_.path -destination

c:\temp\copy.vhd}
IMPORTANT
You cannot use passthru disks with cloning, as they do not use a virtual disk file but instead an actual hard disk.
NOTE
For more information about more Windows PowerShell operations with pipelines, see Piping and the Pipeline in Windows
PowerShell.
Exporting the VM
As an alternative to copying the disks, you can export the entire Hyper-V VM as a copy. Exporting automatically
creates a folder named for the VM and containing all disks and configuration information.
To export a VM with Hyper-V Manager:

1. Right-click the source domain controller and click Export.
2. Select an existing folder as the export container.
3. Wait for the Status column to stop showing Exporting.
To export a VM using the Hyper-V Windows PowerShell module, use cmdlet:
Export-vm
For example, to export a VM named DC2-SOURCECLONE to a folder named C:\VM:
NOTE
Windows Server 2012 Hyper-V supports new export and import capabilities that are outside the scope of this training.
Review TechNet for more information.
Exporting merged disks, using Hyper-V

The final option is to use the disk merge and conversion options within Hyper-V. These allow you to make a copy
of an existing disk structure - even when including snapshot AVHD/AVHDX files - into a single new disk. Like the
manual disk copy scenario, this is primarily intended for simpler virtual machines that only use a single drive, such
as C:\. Its lone advantage is that, unlike manually copying, it does not require you to first delete snapshots. This
operation is necessarily slower than simply deleting the snapshots and copying disks.
To create a merged disk using Hyper-V Manager:
1. Click Edit Disk.
2. Browse for the lowest child disk. For example, if you are using a differencing disk, the child disk is the lowest
child. If the virtual machine has a snapshot (or multiple ones), the currently selected snapshot is the lowest
child disk.
3. Select the Merge option to create a single disk out of the entire parent-child structure.
4. Select a new virtual hard disk and provide a path. This reconciles the existing VHD/VHDX files into a single
new portable unit that is not at risk of restoring previous snapshots.
To create a merged disk from a complex set of parents using the Hyper-V Windows PowerShell module, use
cmdlet:
Convert-vm
For example, to export the entire chain of a VM's disk snapshots (this time not including any differencing disks) and
parent disk into a new single disk named DC4-CLONED.VHDX:
Adding XML to the Offline System Disk

If you did copy the Dccloneconfig.xml to the running source DC, you must copy the updated dccloneconfig.xml file
to the offline copied/exported system disk now. Depending on installed applications detected with Get-
ADDCCloningExcludedApplicationList earlier, you may also need to copy the CustomDCCloneAllowList.xml file to
the disk.
The following locations can contain the DcCloneConfig.xml file:
2. %windir%\NTDS
These paths are not configurable. After cloning begins, the cloning checks these locations in that specific order and
uses the first DcCloneConfig.xml file found, regardless of the other folder's contents.
The following locations can contain the CustomDCCloneAllowList.xml file:
1. HKey_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters
AllowListFolder (REG_SZ )
3. %windir%\NTDS
You can run New -ADDCCloneConfigFile with the -offline argument (also known as offline mode) to create the
DcCloneConfig.xml file and place it in a correct location. The following examples show how to run New -
ADDCCloneConfigFile in offline mode.
To create a clone domain controller named CloneDC1 in offline mode, in a site called "REDMOND" with static IPv4
address, type:
New-ADDCCloneConfigFile -Offline -CloneComputerName CloneDC1 -SiteName REDMOND -IPv4Address "10.0.0.2" -

IPv4DNSResolver "10.0.0.1" -IPv4SubnetMask "255.255.0.0" -IPv4DefaultGateway "10.0.0.1" -Static -Path
F:\Windows\NTDS
To create a clone domain controller named Clone2 in offline mode with static IPv4 and static IPv6 settings, type:
New-ADDCCloneConfigFile -Offline -IPv4Address "10.0.0.2" -IPv4DNSResolver "10.0.0.1" -IPv4SubnetMask

"255.255.0.0" -Static -IPv6DNSResolver "2002:4898:e0:31fc:d61:2b0a:c9c9:2ccc" -CloneComputerName "Clone2" -
PreferredWINSServer "10.0.0.1" -AlternateWINSServer "10.0.0.3" -Path F:\Windows\NTDS
To create a clone domain controller in offline mode with static IPv4 and dynamic IPv6 settings and specify multiple
DNS servers for the DNS resolver settings, type:
New-ADDCCloneConfigFile -Offline -IPv4Address "10.0.0.10" -IPv4SubnetMask "255.255.0.0" -IPv4DefaultGateway

"10.0.0.1" -IPv4DNSResolver @( "10.0.0.1","10.0.0.2" ) -Static -IPv6DNSResolver
To create a clone domain controller named Clone1 in offline mode with dynamic IPv4 and static IPv6 settings, type:
New-ADDCCloneConfigFile -Offline -Static -IPv6DNSResolver "2002:4898:e0:31fc:d61:2b0a:c9c9:2ccc" -

CloneComputerName "Clone1" -PreferredWINSServer "10.0.0.1" -AlternateWINSServer "10.0.0.3" -SiteName "REDMOND"
-Path F:\Windows\NTDS
To create a clone domain controller in offline mode with dynamic IPv4 and dynamic IPv6 settings, type:
New-ADDCCloneConfigFile -Offline -IPv4DNSResolver "10.0.0.1" -IPv6DNSResolver

W i n d o w s Ex p l o r e r M e t h o d
Windows Server 2012 now offers a graphical option for mounting VHD and VHDX files. This requires installation
of the Desktop Experience feature on Windows Server 2012.
1. Click the newly copied VHD/VHDX file that contains the source DC's system drive or DSA Working
Directory location folder, and then click Mount from the Disc Image Tools menu.
2. In the now -mounted drive, copy the XML files to a valid location. You may be prompted for permissions to
the folder.
3. Click the mounted drive and click Eject from the Disk Tools menu.
Alternatively, you can mount the offline disk and copy the XML file using the Windows PowerShell cmdlets:
mount-vhd
get-disk
get-partition
get-volume
Add-PartitionAccessPath
Copy-Item
This allows you complete control over the process. For instance, the drive can be mounted with a specific drive
letter, the file copied, and the drive dismounted.
mount-vhd <disk path> -passthru -nodriveletter | get-disk | get -partition | get-volume | get-partition | where
{$_.partition number -eq 2} | Add-PartitionAccessPath -accesspath <drive letter>
copy-item <xml file path><destination path>\dccloneconfig.xml
dismount-vhd <disk path>
For example:
Alternatively, you can use the new Mount-DiskImage cmdlet to mount a VHD (or ISO ) file.
Step 8 - Create the New Virtual Machine
The final configuration step before starting the cloning process is creating a new VM that uses the disks from the
copied source domain controller. Depending on the selection made in the copying disks phase, you have two
options:
1. Associate a new VM with the copied disk
2. Import the exported VM
Associating a New VM with Copied Disks
If you copied the system disk manually, you must create a new virtual machine using the copied disk. The
hypervisor automatically sets the VM -Generation ID when a new VM is created; no configuration changes are
required in the VM or Hyper-V host.
1. Create a new virtual machine.

2. Specify the VM name, memory, and network.
3. On the Connect Virtual Hard Disk page, specify the copied system disk.
4. Complete the wizard to create the VM.
If there were multiple disks, network adapters, or other customizations, configure them before starting the domain
controller. The "Export-Import" method of copying disks is recommended for complex VMs.
You can use the Hyper-V Windows PowerShell module to automate VM creation in Windows Server 2012, using
the following cmdlet:
New-VM
For example, here the DC4-CLONEDFROMDC2 VM is created, using 1GB of RAM, booting from the c:\vm\dc4-
systemdrive-clonedfromdc2.vhd file, and using the 10.0 virtual network:
Import VM
If you previously exported your VM, you now need to import it back in as a copy. This uses the exported XML to
recreate the computer using all the previous settings, drives, networks, and memory settings.
If you intend to create additional copies from the same exported VM, make as many copies of the exported VM as
necessary. Then use Import for each copy.
IMPORTANT
It is important to use the Copy option, as export preserves all information from the source; importing the server with Move
or In Place causes information collision if done on the same Hyper-V host server.
To import using the Hyper-V Manager snap-in:

1. Click Import Virtual Machine
2. On the Locate Folder page, select the exported VM definition file using the Browse button
3. On the Select Virtual Machine page, click the source computer.
4. On the Choose Import Type page, click Copy the virtual machine (create a new unique ID ), then click
Finish.
5. Rename the imported VM if importing on the same Hyper-V host; it will have the same name as the
exported source domain controller.
Remember to remove any imported snapshots, using the Hyper-V Management snap-in:
WARNING
Deleting any imported snapshots is critically important; if applied, they would return the cloned domain controller to the state
of a previous - and possibly live - DC, leading to replication failure, duplicate IP information, and other disruptions.
You can use the Hyper-V Windows PowerShell module to automate VM import in Windows Server 2012, using
the following cmdlets:
Import-VM
Rename-VM
For example, here the exported VM DC2-CLONED is imported using its automatically determined XML file, then
renamed immediately to its new VM name DC5-CLONEDFROMDC2:
Remember to remove any imported snapshots, using the following cmdlets:
Get-VMSnapshot
Remove-VMSnapshot
For example:
WARNING
Ensure that, when importing the computer, static MAC addresses were not assigned to the source domain controller. If a
source computer with a static MAC is cloned, those copied computers will not correctly send or receive any network traffic.
Set a new unique static or dynamic MAC address if this is the case. You can see if a VM uses static MAC addresses with the
command:
Get-VM -VMName
test-vm | Get-VMNetworkAdapter | fl \*
Step 9 - Clone the New Virtual Machine

Optionally, before you begin cloning, restart the offline clone source domain controller. Ensure that the PDC
emulator is online, regardless.
To begin cloning, simply start the new virtual machine. The process initiates automatically and the domain
controller reboots automatically after cloning is complete.
IMPORTANT
Keeping domain controllers turned off for an extended period of time is not recommended and if the clone is joining the same
site as its source DC, the initial intra and inter-site replication topology may take longer to build if the source domain
controller is offline.
If using Windows PowerShell to start a VM, the new Hyper-V Module cmdlet is:
Start-VM
For example:
Once the computer restarts after cloning completes, it is a domain controller and you can logon on normally to
confirm normal operation. If there are any errors, the server is set to start in Directory Services Restore Mode for
investigation.
Virtualization safeguards
Unlike virtualized domain controller cloning, Windows Server 2012 virtualization safeguards have no configuration
steps. The feature works without intervention as long as you meet some simple conditions:
The hypervisor supports VM -Generation ID
There is a valid partner domain controller that a restored domain controller can replicate changes from non-
authoritatively.
Validate the Hypervisor
Ensure the source domain controller is running on a supported hypervisor by reviewing vendor documentation.
Virtualized domain controllers are hypervisor-independent and do not require Hyper-V.
Review the previous Platform Requirements section for known VM -Generation ID support.
If you are migrating VMs from a source hypervisor to a different target hypervisor, virtualization safeguards may
or may not be triggered depending on whether the hypervisors support VM -Generation ID, as explained in the
following table.
SOURCE HYPERVISOR TARGET HYPERVISOR RESULT
Supports VM-Generation ID Does not support VM-Generation ID Safeguards not triggered (if a
DCCloneConfigFile.xml is present, DC
will boot into DSRM)
Does not support VM-Generation ID Supports VM-Generation ID Safeguards triggered
Supports VM-Generation ID Supports VM-Generation ID Safeguards not triggered because VM

definition has not changed, which
means so VM-Generation ID remains
the same
Validate the Replication Topology

Virtualization safeguards initiate non-authoritative inbound replication for the delta of Active Directory replication
as well as non-authoritative resynchronization of all SYSVOL contents. This ensures the domain controller returns
from a snapshot with full functionality and is eventually consistent with the rest of the environment.
With this new capability come several requirements and limitations:
A restored domain controller must be able to contact a writable DC
All domain controllers in a domain must not be restored simultaneously
Any changes originating from a restored domain controller that have not yet replicated outbound since the
snapshot was taken are lost forever
While the troubleshooting section covers these scenarios, details below ensure you do not create a topology that
could cause problems.
Writable Domain Controller Availability
If restored, a domain controller must have connectivity to a writable domain controller; a read-only domain
controller cannot send the delta of updates. The topology is likely correct for this already, as a writable domain
controller always needed a writable partner. However, if all writable domain controllers are restoring
simultaneously, none of them can find a valid source. The same goes if the writable domain controllers are offline
for maintenance or otherwise unreachable through the network.
Simultaneous Restore
Do not restore all domain controllers in a single domain simultaneously. If all snapshots restore at once, Active
Directory replication works normally but SYSVOL replication halts. The restore architecture of FRS and DFSR
require setting their replica instance to non-authoritative sync mode. If all domain controllers restore at once, and
each domain controller marks itself non-authoritative for SYSVOL, they all will then try to synchronize group
policies and scripts from an authoritative partner; at that point, though, all partners are also non-authoritative.
IMPORTANT
If all domain controllers are restored at once, use the following articles to set one domain controller - typically the PDC
emulator - as authoritative, so that the other domain controllers can return to normal operation:
Using the BurFlags registry key to reinitialize File Replication Service replica sets
How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS)
WARNING
Do not run all domain controllers in a forest or domain on the same hypervisor host. That introduces a single point of failure
that cripples AD DS, Exchange, SQL, and other enterprise operations each time the hypervisor goes offline. This is no different
from using only one domain controller for an entire domain or forest. Multiple domain controllers on multiple platforms help
provide redundancy and fault tolerance.
Post-Snapshot Replication
Do not restore snapshots until all locally originating changes made since snapshot creation have replicated
outbound. Any originating changes are lost forever if other domain controllers did not already receive them
through replication.
Use Repadmin.exe to show any un-replicated outbound changes between a domain controller and its partners:
1. Return the DC's partner names and DSA Object GUIDs with:
Repadmin.exe /showrepl <DC Name of the partner> /repsto
2. Return the pending inbound replication of the partner domain controller to the domain controller to be
restored:
Repadmin.exe /showchanges < Name of partner DC><DSA Object GUID of the domain controller being restored>
<naming context to compare>
Alternatively, just to see the count of un-replicated changes:
Repadmin.exe /showchanges <Name of partner DC><DSA Object GUID of the domain controller being restored><naming
context to compare> /statistics
For example (with output modified for readability and important entries italicized), here you look at the replication
partnerships of DC4:
C:\>repadmin.exe /showrepl dc4.corp.contoso.com /repsto
Default-First-Site-Name\DC4
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 5d083398-4bd3-48a4-a80d-fb2ebafb984f
DSA invocationID: 730fafec-b6d4-4911-88f2-5b64e48fc2f1
==== OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS ============
DC=corp,DC=contoso,DC=com
Default-First-Site-Name\DC3 via RPC
DSA object GUID: f62978a8-fcf7-40b5-ac00-40aa9c4f5ad3
Last attempt @ 2011-11-11 15:04:12 was successful.
Default-First-Site-Name\DC2 via RPC
DSA object GUID: 3019137e-d223-4b62-baaa-e241a0c46a11
Last attempt @ 2011-11-11 15:04:15 was successful.
Now you know that it is replicating with DC2 and DC3. You then show the list of changes that DC2 states it still
does not have from DC4, and see that there is one new group:
C:\>repadmin /showchanges dc2.corp.contoso.com 5d083398-4bd3-48a4-a80d-fb2ebafb984f dc=corp,dc=contoso,dc=com
==== SOURCE DSA: (null) ====

Objects returned: 1
(0) add CN=newgroup4,CN=Users,DC=corp,DC=contoso,DC=com
1> parentGUID: 55fc995a-04f4-4774-b076-d6a48ac1af99
1> objectGUID: 96b848a2-df1d-433c-a645-956cfbf44086
2> objectClass: top; group
1> instanceType: 0x4 = ( WRITE )
1> whenCreated: 11/11/2011 3:03:57 PM Eastern Standard Time
You would also test the other partner to ensure that it had not already replicated.
Alternatively, if you did not care which objects had not replicated and only cared that any objects were outstanding,
you can use the /statistics option:
C:\>repadmin /showchanges dc2.corp.contoso.com 5d083398-4bd3-48a4-a80d-fb2ebafb984f dc=corp,dc=contoso,dc=com

/statistics
***********************************************
********* Grand total *************************
Packets: 1
Objects: 1Object Additions: 1Object Modifications: 0Object Deletions: 0Object Moves:
0Attributes: 12Values: 13
IMPORTANT
Test all writable partners if you see any failures or outstanding replication. As long as at least one is converged, it is generally
safe to restore the snapshot, as transitive replication eventually reconciles the other servers.
Be sure to note any errors in replication shown by /showchanges and do not proceed until they are fixed.
Windows PowerShell Snapshot Cmdlets

The following Windows PowerShell Hyper-V module cmdlets provide snapshot capabilities in Windows Server
2012:
Checkpoint-VM
Export-VMSnapshot
Get-VMSnapshot
Remove-VMSnapshot
Rename-VMSnapshot
Restore-VMSnapshot
Virtualizing Domain Controllers using Hyper-V
Applies to: Windows Server 2016
This topic will be updated in order to make the guidance applicable to Windows Server 2016. Windows Server
2012 introduces many improvements for virtualized domain controllers (DCs), including safeguards to prevent
USN rollback on virtual DCs and the ability to clone virtual DCs. For more information about these improvements,
see Introduction to Active Directory Domain Services (AD DS ) Virtualization (Level 100).
Hyper-V consolidates different server roles onto a single physical computer. This guide describes running domain
controllers as 32-bit or 64-bit guest operating systems.
Planning to Virtualize Domain Controllers

This section covers hardware requirements for Hyper-v server, how to avoid single points of failure, selecting the
appropriate type of configuration for your Hyper-V servers and virtual machines, and security and performance
decisions.
Hyper-V requirements
To install and use the Hyper-V role, you must have the following:
An x64 processor
Hyper-V is available in x64-based versions of Windows Server 2008 or later.
Hardware-assisted virtualization
This feature is available in processors that include a virtualization option, specifically, Intel Virtualization
Technology (Intel VT) or AMD Virtualization (AMD -V ).
Hardware Data Execution Protection (DEP )
Hardware DEP must be available and enabled. Specifically, you must enable Intel XD bit (execute disable
bit) or AMD NX bit (no execute bit).
Avoid creating single points of failure

You should attempt to avoid creating potential single points of failure when you plan your virtual domain controller
deployment. You can avoid introducing potential single points of failure by implementing system redundancy. For
example, consider the following recommendations while keeping in mind the potential for increases in the cost of
administration:
1. Run at least two virtualized domain controllers per domain on different virtualization hosts, which reduces the
risk of losing all domain controllers if a single virtualization host fails.
2. As recommended for other technologies, diversify the hardware (using different CPUs, motherboards, network
adapters, or other hardware) on which the domain controllers are running. Hardware diversification limits the
damage that might be caused by a malfunction that is specific to a vendor configuration, a driver, or a single
piece or type of hardware.
3. If possible, domain controllers should be running on hardware that is located in different regions of the world.
This helps to reduce the impact of a disaster or failure that affects a site at which the domain controllers are
hosted.
4. Maintain physical domain controllers in each of your domains. This mitigates the risk of a virtualization
platform malfunction that affects all host systems that use that platform.
Security considerations
The host computer on which virtual domain controllers are running must be managed as carefully as a writeable
domain controller, even if that computer is only a domain-joined or workgroup computer. This is an important
security consideration. A mismanaged host is vulnerable to an elevation-of-privilege attack, which occurs when a
malicious user gains access and system privileges that were not authorized or legitimately assigned. A malicious
user can use this type of attack to compromise all the virtual machines, domains, and forests that this computer
hosts.
Be sure to keep the following security considerations in mind when you are planning to virtualize domain
controllers:
The local administrator of a computer that hosts virtual, writeable domain controllers should be considered
equivalent in credentials to the default domain administrator of all the domains and forests that those domain
controllers belong to.
The recommended configuration to avoid security and performance issues is a host running a Server Core
installation of Windows Server 2008 or later, with no applications other than Hyper-V. This configuration limits
the number of applications and services that are installed on the server, which should result in increased
performance and fewer applications and services that could be maliciously exploited to attack the computer or
network. The effect of this type of configuration is known as a reduced attack surface. In a branch office or other
locations that cannot be satisfactorily secured, a read-only domain controller (RODC ) is recommended. If a
separate management network exists, we recommend that the host be connected only to the management
network.
You can use Bitlocker with your domain controllers, since Windows Server 2016 you can use the virtual TPM
feature to also give the guest key material to unlock the system volume.
Guarded fabric and shielded VMs can provide additional controls to protect your domain controllers.
For information about RODCs, see Read-Only Domain Controller Planning and Deployment Guide.
For more information about securing domain controllers, see Best Practice Guide for Securing Active Directory
Installations.
Security boundaries for different host and guest configurations

Using virtual machines makes it possible to have many different configurations of domain controllers. Careful
consideration must be given to the way that virtual machines affect boundaries and trusts in your Active Directory
topology. Possible configurations for an Active Directory domain controller and host (Hyper-V server) and its guest
computers (virtual machines running on the Hyper-V server) are described in the following table.
MACHINE CONFIGURATION 1 CONFIGURATION 2
Host Workgroup or member computer Workgroup or member computer
Guest Domain controller Workgroup or member computer

The administrator on the host computer has the same access as a domain administrator on the writable domain
controller guests and must be treated as such. In the case of an RODC guest, the administrator of the host
computer has the same access as a local administrator on the guest RODC.
A domain controller in a virtual machine has administrative rights on the host if the host is joined to the same
domain. There is an opportunity for a malicious user to compromise all virtual machines if the malicious user
first gains access to Virtual Machine 1. This is known as an attack vector. If there are domain controllers for
multiple domains or forests, these domains should have centralized administration in which the administrator of
one domain is trusted on all domains.
The opportunity for attack from Virtual Machine 1 exists even if Virtual Machine 1 is installed as an RODC.
Although an administrator of an RODC does not explicitly have domain administrator rights, the RODC can be
used to send policies to the host computer. These policies might include startup scripts. If this operation is
successful, the host computer can be compromised, and it can then be used to compromise the other virtual
machines on the host computer.
Security of VHD files

A VHD file of a virtual domain controller is equivalent to the physical hard drive of a physical domain controller. As
such, it should be protected with the same amount of care that goes into securing the hard drive of a physical
domain controller. Make sure that only reliable and trusted administrators are allowed access to the domain
controller’s VHD files.
RODCs
One benefit of RODCs is the ability to place them at locations where physical security cannot be guaranteed, such
as at branch offices. You can use Windows BitLocker Drive Encryption to protect VHD files themselves (not the file
systems therein) from being compromised on the host through theft of the physical disk.
Performance
With the new microkernel 64-bit architecture, there are significant increases in Hyper-V performance from
previous virtualization platforms. For best host performance, the host should be a Server Core installation of
Windows Server 2008 or later, and it should not have server roles other than Hyper-V installed.
Performance of virtual machines depends specifically on the workload. To guarantee satisfactory Active Directory
performance, test specific topologies. Assess the current workload over a period of time with a tool such as the
Reliability and Performance Monitor (Perfmon.msc) or the Microsoft Assessment and Planning (MAP ) toolkit. The
MAP tool can also be valuable if you want to take an inventory of all of the servers and server roles that currently
exist in your network.
To get a general idea of the performance of virtualized domain controllers, the following performance tests were
carried out with the Active Directory Performance Testing Tool (ADTest.exe).
Lightweight Directory Access Protocol (LDAP ) tests were run on a physical domain controller with ADTest.exe and
then on a virtual machine that was hosted on a server that was identical to the physical domain controller. Only one
logical processor was used for the physical computer, and only one virtual processor was used for the virtual
machine to easily reach 100-percent CPU utilization. In the following table, the letter and number in parenthesis
after each test indicate the specific test in ADTest.exe. As this data shows, virtualized domain controller
performance was 88 to 98 percent of the physical domain controller performance.
MEASUREMENT TEST PHYSICAL VIRTUAL DELTA
Searches/sec Search for 11508 10276 -10.71%

common name in
base scope (L1)
Searches/sec Search for a set of 10123 9005 -11.04%

attributes in base
scope (L2)
Searches/sec Search for all 1284 1242 -3.27%

attributes in base
scope (L3)
Searches/sec Search for 8613 7904 -8.23%

common name in
subtree scope (L6)
Successful Perform fast binds 1438 1374 -4.45%

binds/sec (B1)
Successful Perform simple 611 550 -9.98%

binds/sec binds (B2)
Successful Use NTLM to 1068 1056 -1.12%

binds/sec perform binds
(B5)
Writes/sec Write multiple 6467 5885 -9.00%

attributes (W2)
To ensure satisfactory performance, integration components (IC ) were installed to allow the guest operating
system to use “enlightenments,” or hypervisor-aware synthetic drivers. During the installation process, it may be
necessary to use emulated Integrated Drive Electronics (IDE ) or network adapter drivers. In production
environments, you should replace these emulated drivers with synthetic drivers to increase performance.
When you monitor performance of virtual machines with Reliability and Performance Manager (Perfmon.msc),
within the virtual machine the CPU information will not be entirely accurate as a result of the way the virtual CPU
is scheduled on the physical processor. When you want to obtain CPU information for a virtual machine that is
running on a Hyper-V server, use the Hyper-V Hypervisor Logical Processor counters in the host partition.
For more information about performance tuning of both AD DS and Hyper-V, see Performance Tuning Guidelines
for Windows Server 2016.
Also, do not plan to use a differencing disk VHD on a virtual machine that is configured as a domain controller
because the differencing disk VHD can reduce performance. To learn more about Hyper-V disk types, including
differencing disks, see New Virtual Hard Disk Wizard.
For additional information regarding AD DS in virtual hosting environments, see Things to consider when you
host Active Directory domain controllers in virtual hosting environments in the Microsoft Knowledge Base.
Deployment Considerations for Virtualized Domain Controllers

There are several common virtual machine practices that you should avoid when you deploy domain controllers,
and special considerations for time synchronization and storage.
Virtualization deployment practices to avoid

Virtualization platforms, such as Hyper-V, offer a number of convenience features that make managing,
maintaining, backing up, and migrating computers easier. However, the following common deployment practices
and features should not be used for virtual domain controllers:
To ensure durability of Active Directory writes, do not deploy a virtual domain controller’s database files (the
Active Directory database (NTDS.DIT), logs and SYSVOL ) on virtual IDE disks. Instead, create a second VHD
attached to a virtual SCSI controller and ensure that the database, logs, and SYSVOL are placed on the virtual
machine’s SCSI disk during domain controller installation.
Do not implement differencing disk virtual hard disks (VHDs) on a virtual machine that you are configuring as a
domain controller. This makes it too easy to revert to a previous version, and it also decreases performance. For
more information about VHD types, see New Virtual Hard Disk Wizard.
Do not deploy new Active Directory domains and forests on a copy of a Windows Server operating system
that was not first prepared using System Preparation tool (Sysprep). For more information about running
the Sysprep, see Sysprep (System Preparation) Overview
WARNING
Running Sysprep on a domain controller is not supported.
To help prevent a potential update sequence number (USN ) rollback situation, do not use copies of a VHD
file that represents an already deployed domain controller to deploy additional domain controllers. For more
information about USN rollback, see USN and USN Rollback.
Windows Server 2012 and newer allows administrators to clone domain controller images if prepared
properly when they want to deploy additional domain controllers
Do not use the Hyper-V Export feature to export a virtual machine that is running a domain controller.
With Windows Server 2012 and newer, an export and import of a Domain Controller virtual guest is
handled like a non-authoritative restore as it detects a change of the Generation ID and it is not
configured for cloning.
Ensure you are not using the guest that you exported anymore.
You may use Hyper-V Replication to keep a second inactive copy of a Domain Controller. If you
start the replicated image, you also need to perform proper cleanup, for the same reason as not
using the source after exporting a DC guest image.
Physical-to-virtual migration
System Center Virtual Machine Manager (VMM ) 2008 provides unified management of physical machines and
virtual machines. It also provides the ability to migrate a physical machine to a virtual machine. This process is
known as physical-to-virtual machine conversion (P2V conversion). During the P2V conversion process, the new
virtual machine and the physical domain controller that is being migrated must not be running at the same time, to
avoid a USN rollback situation as described in USN and USN Rollback.
You should perform P2V conversion using offline mode so that the directory data is consistent when the domain
controller is turned back on. The offline mode option is offered and recommended in the Convert Physical Server
Wizard. For a description of the difference between online mode and offline mode, see P2V: Converting Physical
Computers to Virtual Machines in VMM. During P2V conversion, the virtual machine should not be connected to
the network. The network adapter of the virtual machine should be enabled only after the P2V conversion process
is complete and verified. At this point, the physical source machine will be off. Do not bring the physical source
machine back onto the network again before you reformat the hard disk.
NOTE
There are safer options to create new virtual DCs that don’t run the risks of creating a USN Rollback. You may setup a new
virtual DC by regular promotion, promotion from Install from Media (IfM), and also using Domain Controller cloning, if you
already have at least one virtual DC. This also helps avoiding problems with hardware or platform-related problems P2V-
converted virtual guests may encounter.
WARNING
To prevent issues with Active Directory replication, ensure that only one instance (physical or virtual) of a given domain
controller exists on a given network at any point in time. You can lower the likelihood of the old clone being a problem:
When the new virtual DC is running, change the computer account password twice using: netdom resetpwd /Server: …
Export and import the new virtual guest to force it becoming a new Generation ID and hence a database invocation ID.
Using P2V Migration to Create Test Environments

You can use P2V migration through the VMM to create test environments. You can migrate production domain
controllers from physical machines to virtual machines to create a test environment without permanently bringing
down the production domain controllers. However, the test environment must be on a different network from the
production environment if two instances of the same domain controller are to exist. Great care must be taken in the
creation of test environments with P2V migration to avoid USN rollbacks that can affect your test and production
environments. The following is a method that you can use for creating test environments with P2V.
One in-production domain controller from each domain is migrated to a test virtual machine using P2V according
to the guidelines stated in the Physical-to-virtual migration section. The physical production machines and the test
virtual machines must be in different networks when they are brought back online. To avoid USN rollbacks in the
test environment, all domain controllers that are to be migrated from physical machines to virtual machines must
be taken offline. (You can do this by stopping the ntds service or by restarting the computer in Directory Services
Restore Mode (DSRM ).) After the domain controllers are offline, no new updates should be introduced to the
environment. The computers must remain offline during the P2V migration; none of the computers should be
brought back online until all the computers have been fully migrated. To learn more about USN rollback, see USN
and USN Rollback.
Subsequent test domain controllers should be promoted as replicas in the test environment.
Time service
For virtual machines that are configured as domain controllers, it is recommended that you disable time
synchronization between the host system and guest operating system acting as a domain controller. This enables
your guest domain controller to synchronize time from the domain hierarchy.
To disable the Hyper-V time synchronization provider, shut down the VM and clear the Time synchronization check
box under Integration Services.
NOTE
This guidance has been recently updated to reflect the current recommendation to synchronize time for the guest domain
controller from only the domain hierarchy, rather than the previous recommendation to partially disable time synchronization
between the host system and guest domain controller.
Storage
To optimize the performance of the domain controller virtual machine and ensure durability of Active Directory
writes, use the following recommendations for storing operating system, Active Directory, and VHD files:
Guest storage. Store the Active Directory database file (Ntds.dit), log files, and SYSVOL files on a separate
virtual disk from the operating system files. Create a second VHD attached to a virtual SCSI controller and
store the database, logs, and SYSVOL on the virtual machine’s virtual SCSI disk. Virtual SCSI disks provide
increased performance compared to virtual IDE and they support Forced Unit Access (FUA). FUA ensures
that the operating system writes and reads data directly from the media bypassing any and all caching
mechanisms.
NOTE
If you are planning to use Bitlocker for the virtual DC guest, you need to make sure the additional volumes are
configured for “auto unlock”. More information about configuring auto unlock can be found in Enable-
BitLockerAutoUnlock
Host storage of VHD files. Recommendations: Host storage recommendations address storage of VHD
files. For maximum performance, do not store VHD files on a disk that is used frequently by other services
or applications, such as the system disk on which the host Windows operating system is installed. Store each
VHD file on a separate partition from the host operating system and any other VHD files. The ideal
configuration is to store each VHD file on a separate physical drive.
The host physical disk system must also satisfy at least one of the following criteria to meet the
requirements of virtualized workload data integrity:
The system uses server-class disks (SCSI, Fibre Channel).
The system makes sure that the disks are connected to a battery-backed caching host bus adapter (HBA).
The system uses a storage controller (for example, a RAID system) as the storage device.
The system makes sure that power to the disk is protected by an uninterruptible power supply (UPS ).
The system makes sure that the disk's write-caching feature is disabled.
Fixed VHD versus pass-through disks. There are many ways to configure storage for virtual machines.
When VHD files are used, fixed-size VHDs are more efficient than dynamic VHDs because the memory for
fixed-size VHDs is allocated when they are created. Pass-through disks, which virtual machines can use to
access physical storage media, are even more optimized for performance. Pass-through disks are essentially
physical disks or logical unit numbers (LUNs) that are attached to a virtual machine. Pass-through disks do
not support the snapshot feature. Therefore, pass-through disks are the preferred hard disk configuration,
because the use of snapshots with domain controllers is not recommended.
To reduce the chance of corruption of Active Directory data, use virtual SCSI controllers:
Use SCSI physical drives (as opposed to IDE/ATA drives) on Hyper-V servers that host virtual domain
controllers. If you cannot use SCSI drives, ensure that write caching is disabled on the ATA/IDE drives that host
virtual domain controllers. For more information, see Event ID 1539 – Database Integrity.
To guarantee the durability of Active Directory writes, the Active Directory database, logs, and SYSVOL must be
placed on a virtual SCSI disk. Virtual SCSI disks support Forced Unit Access (FUA). FUA ensures that the
operating system writes and reads data directly from the media bypassing any and all caching mechanisms.
Operational Considerations for Virtualized Domain Controllers

Domain controllers that are running on virtual machines have operational restrictions that do not apply to domain
controllers that are running on physical machines. When you use a virtualized domain controller, there are some
virtualization software features and practices that you should not use:
Do not pause, stop, or store the saved state of a domain controller in a virtual machine for time periods longer
than the tombstone lifetime of the forest and then resume from the paused or saved state. Doing this can
interfere with replication. To learn how to determine the tombstone lifetime for the forest, see Determine the
Tombstone Lifetime for the Forest.
Do not copy or clone virtual hard disks (VHDs). Even with the Safeguards in place for the guest VM, individual
VHDs can still be copied and cause USN roll-back.
Do not take or use a Snapshot of a virtual domain controller. It is technically supported with Windows Server
2012 and newer, it is not a replacement for a good backup strategy. There are few reasons for taking DC
snapshots or restoring the snapshots.
Do not use a differencing disk VHD on a virtual machine that is configured as a domain controller. This makes
reverting to a previous version too easy, and it also decreases performance.
Do not use the Export feature on a virtual machine that is running a domain controller.
Do not restore a domain controller or attempt to roll back the contents of an Active Directory database by any
means other than using a supported backup. For more information, see Backup and Restore Considerations for
Virtualized Domain Controllers.
All these recommendations are made to help avoid the possibility of an update sequence number (USN ) rollback.
For more information about USN rollback, see USN and USN Rollback.
Backup and Restore Considerations for Virtualized Domain Controllers

Backing up domain controllers is a critical requirement for any environment. Backups protect against data loss in
the event of domain controller failure or administrative error. If such an event occurs, it is necessary to roll back the
system state of the domain controller to a point in time before the failure or error. The supported method of
restoring a domain controller to a healthy state is to use an Active Directory–compatible backup application, such
as Windows Server Backup, to restore a system state backup that originated from the current installation of the
domain controller. For more information about using Windows Server Backup with Active Directory Domain
Services (AD DS ), see the AD DS Backup and Recovery Step-by-Step Guide.
With virtual machine technology, certain requirements of Active Directory restore operations take on added
significance. For example, if you restore a domain controller by using a copy of the virtual hard disk (VHD ) file, you
bypass the critical step of updating the database version of a domain controller after it has been restored.
Replication will proceed with inappropriate tracking numbers, resulting in an inconsistent database among domain
controller replicas. In most cases, this problem goes undetected by the replication system and no errors are
reported, despite inconsistencies between domain controllers.
There is one supported way to perform backup and restore of a virtualized domain controller:
1. Run Windows Server Backup in the guest operating system.
With Windows Server 2012 and newer Hyper-V hosts and guests, you can take supported backups of domain
controllers using snapshots, guest VM export and import and also Hyper-V Replication. All of these however are
not a good fit for creating a proper backup history, with the slight exception of guest VM export.
With Windows Server 2016 Hyper-V there is support for “production snapshots” where the Hyper-V server
triggers a VSS -based backup of the guest and when the guest is done with the snapshot, the host fetches the VHDs
and stores them in the backup location.
While this works with Windows Server 2012 and newer, there is an incompatibility with Bitlocker:
When doing a VSS Snap-Shot, AD wants to perform a post-snapshot task to mark the database as coming
from a backup, or in the case of preparing a IFM source for RODC, remove credentials from the database.
When Hyper-V mounts the snapshotted volume for this task, there is no facility that would unlock the Volume
for unencrypted access. So the AD database engine fails accessing the database and eventually fails the
snapshot.
NOTE
The shielded VM project mentioned previously has a Hyper-V host driven backup as a non-goal for maximum data
protection of the guest VM.
Backup and restore practices to avoid

As mentioned, domain controllers that are running in virtual machines have restrictions that do not apply to
domain controllers that are running in physical machines. When you back up or restore a virtual domain controller,
there are certain virtualization software features and practices that you should not use:
Do not copy or clone VHD files of domain controllers instead of performing regular backups. If he VHD file is
copied or cloned, it becomes stale. Then, if the VHD is started in normal mode, you will encounter a USN
Rollback. You should perform proper backup operations that are supported by Active Directory Domain
Services (AD DS ), such as using the Windows Server Backup feature.
Do not use the Snapshot feature as a backup to restore a virtual machine that was configured as a domain
controller. Problems will occur with replication when you revert the virtual machine to an earlier state with
Windows Server 2008 R2 and older. For more information, see USN and USN Rollback. Although using a
snapshot to restore a read-only domain controller (RODC ) will not cause replication issues, this method of
restoration is still not recommended.
Restoring a virtual domain controller

To restore a domain controller when it fails, you must regularly backup system state. System state includes Active
Directory data and log files, the registry, the system volume (SYSVOL folder), and various elements of the
operating system. This requirement is the same for physical and virtual domain controllers. System state restore
procedures that Active Directory–compatible backup applications perform are designed to ensure the consistency
of local and replicated Active Directory databases after a restore process, including the notification to replication
partners of invocation ID resets. However, using virtual hosting environments and disk or operating system
imaging applications makes it possible for administrators to bypass the checks and validations that ordinarily occur
when domain controller system state is restore.
When a domain controller virtual machine fails and an update sequence number (USN ) rollback has not occurred,
there are two supported situations for restoring the virtual machine:
If a valid system state data backup that predates the failure exists, you can restore system state by using the
restore option of the backup utility that you used to create the backup. The system state data backup must have
been created using an Active Directory–compatible backup utility within the span of the tombstone lifetime,
which is by default, no more than 180 days. You should back up your domain controllers at least every half
tombstone lifetime. For instructions about how to determine the specific tombstone lifetime for your forest, see
Determine the Tombstone Lifetime for the Forest.
If a working copy of the VHD file is available, but no system state backup is available, you can remove the
existing virtual machine. Restore the existing virtual machine by using a previous copy of the VHD, but be sure
to start it in Directory Services Restore Mode (DSRM ) and configure the registry properly, as described in the
following section. Then, restart the domain controller in normal mode.
Use the process in the following illustration to determine the best way to restore your virtualized domain controller.
For RODCs, the restoration process and decisions are simpler.

Restoring the system state backup of a virtual domain controller
If a valid system state backup exists for the domain controller virtual machine, you can safely restore the backup by
following the restore procedure prescribed by the backup tool that you used to back up the VHD file.
IMPORTANT
To properly restore the domain controller, you must start it in DSRM. You must not allow the domain controller to start in
normal mode. If you miss the opportunity to enter DSRM during system startup, turn off the domain controller’s virtual
machine before it can fully start in normal mode. It is important to start the domain controller in DSRM because starting a
domain controller in normal mode increments its USNs, even if the domain controller is disconnected from the network. For
more information about USN rollback, see USN and USN Rollback.
To restore the system state backup of a virtual domain controller

1. Start the domain controller’s virtual machine, and press F5 to access the Windows Boot Manager screen. If
you are required to enter connection credentials, immediately click the Pause button on the virtual machine
so that it does not continue starting. Then, enter your connection credentials, and click the Play button on
the virtual machine. Click inside the virtual machine window, and then press F5.
If you do not see the Windows Boot Manager screen and the domain controller begins to start in normal
mode, turn off the virtual machine to prevent it from completing startup. Repeat this step as many times as
necessary until you are able to access the Windows Boot Manager screen. You cannot access DSRM from
the Windows Error Recovery menu. Therefore, turn off the virtual machine and try again if the Windows
Error Recovery menu appears.
2. In the Windows Boot Manager screen, press F8 to access advanced boot options.
3. In the Advanced Boot Options screen, select Directory Services Restore Mode, and then press ENTER.
This starts the domain controller in DSRM.
4. Use the appropriate restore method for the tool that you used to create the system state backup. If you used
Windows Server Backup, see Performing a Nonauthoritative Restore of AD DS.
Restoring a virtual domain controller when an appropriate system state

data backup is not available
If you do not have a system state data backup that predates the virtual machine failure, you can use a previous
VHD file to restore a domain controller that is running on a virtual machine. If you can, make a copy of the VHD, so
that if you encounter an issue during the procedure or miss a step, you can try again with the copied VHD.
IMPORTANT
You should not consider using the following procedure as a replacement for regularly planned and scheduled backups.
Restores that are performed with the following procedure are not supported by Microsoft and should be used
only when there is no other alternative.
Do not use this procedure if the copy of the VHD that you are about to restore has been started in normal mode by any
virtual machine.
To restore a previous version of a virtual domain controller VHD without

system state data backup
1. Using the previous VHD, start the virtual domain controller in DSRM, as described in the previous section. Do
not allow the domain controller to start in normal mode. If you miss the Windows Boot Manager screen and the
domain controller begins to start in normal mode, turn off the virtual machine to prevent it from completing
startup. See the previous section for detailed instructions for entering DSRM.
2. Open Registry Editor. To open Registry Editor, click Start, click Run, type regedit, and then click OK. If the User
Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes. In
Registry Editor, expand the following path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Look for a value
named DSA Previous Restore Count. If the value is there, make a note of the setting. If the value is not there,
the setting is equal to the default, which is zero. Do not add a value if you do not see one there.
3. Right-click the Parameters key, click New, and then click DWORD (32-bit) Value.
4. Type the new name Database restored from backup, and then press ENTER.
5. Double-click the value that you just created to open the Edit DWORD (32-bit) Value dialog box, and then type
1 in the Value data box. The Database restored from backup entry option is available on domain controllers
that are running Windows 2000 Server with Service Pack 4 (SP4), Windows Server 2003 with the updates that
are included in How to detect and recover from a USN rollback in Windows Server 2003, Windows Server
2008, and Windows Server 2008 R2 in the Microsoft Knowledge Base installed, and Windows Server 2008.
6. Restart the domain controller in normal mode.
7. When the domain controller restarts, open Event Viewer. To open Event Viewer, click Start, click Control Panel,
double-click Administrative Tools, and then double-click Event Viewer.
8. Expand Application and Services Logs, and then click the Directory Services log. Ensure that events appear
in the details pane.
9. Right-click the Directory Services log, and then click Find. In Find what, type 1109, and then click Find Next.
10. You should see at least an Event ID 1109 entry. If you do not see this entry, proceed to the next step.
Otherwise, double-click the entry, and then review the text confirming that the update was made to the
InvocationID:
Active Directory has been restored from backup media, or has been configured to host an application
partition.
The invocationID attribute for this directory server has been changed.
The highest update sequence number at the time the backup was created is <time>
InvocationID attribute (old value):<Previous InvocationID value>

InvocationID attribute (new value):<New InvocationID value>
Update sequence number:<USN>
The InvocationID is changed when a directory server is restored from backup media or is configured to
host a writeable application directory partition.
11. Close Event Viewer.

12. Use Registry Editor to verify that the value in DSA Previous Restore Count is equal to the previous value plus
one. If this is not the correct value and you cannot find an entry for Event ID 1109 in Event Viewer, verify that
the domain controller’s service packs are current. You cannot try this procedure again on the same VHD. You
can try again on a copy of the VHD or a different VHD that has not been started in normal mode by starting
over at step 1.
13. Close Registry Editor.
USN and USN Rollback

This section describes replication issues that can occur as a result of an incorrect restoration of the Active Directory
database with an older version of a virtual machine. For additional details about the Active Directory replication
process, see Active Directory Replication Concepts
USNs
Active Directory Domain Services (AD DS ) uses update sequence numbers (USNs) to keep track of replication of
data between domain controllers. Each time that a change is made to data in the directory, the USN is incremented
to indicate that a change has been made.
For each directory partition that a destination domain controller stores, USNs are used to track the latest
originating update that a domain controller introduced to its database, as well as the status of every other domain
controller that stores a replica of the directory partition. When domain controllers replicate changes to one another,
they query their replication partners for changes with USNs that are greater than the USN of the last change that
the domain controller received from each partner.
The following two replication metadata tables contain USNs. Source and destination domain controllers use them
to filter updates that the destination domain controller requires.
1. Up-to-dateness vector: A table that the destination domain controller maintains for tracking the originating
updates that are received from all source domain controllers. When a destination domain controller requests
changes for a directory partition, it provides its up-to-dateness vector to the source domain controller. The
source domain controller then uses this value to filter the updates that it sends to the destination domain
controller. The source domain controller sends its up-to-dateness vector to the destination at the completion of
a successful replication cycle in order to ensure that the destination domain controller knows that it has
synchronized with every domain controllers’ originating updates and the updates are at the same level as the
source.
2. High water mark: A value that the destination domain controller maintains to keep track of the most recent
changes that it has received from a specific source domain controller for a specific partition. The high water
mark prevents the source domain controller from sending out changes that by the destination domain
controller has already received from it.
Directory database identity
In addition to USNs, domain controllers keep track of the directory database of source replication partners. The
identity of the directory database running on the server is maintained separately from the identity of the server
object itself. The directory database identity on each domain controller is stored in the invocationID attribute of
the NTDS Settings object, which is located under the following Lightweight Directory Access Protocol (LDAP ) path:
cn=NTDS Settings, cn=ServerName, cn=Servers, cn=SiteName, cn=Sites, cn=Configuration,
dc=ForestRootDomain. The server object identity is stored in the objectGUID attribute of the NTDS Settings
object. The identity of the server object never changes. However, the identity of the directory database changes
when a system state restore procedure occurs on the server or when an application directory partition is added,
then removed and later re-added from the server. (other scenario: when a HyperV instance triggers its VSS writers
on a partition containing a virtual DC’s VHD, the guest in turn triggers its own VSS writers (the same mechanism
used by backup/restore above) resulting in another means by which the invocationID is reset)
Consequently, invocationID effectively relates a set of originating updates on a domain controller with a specific
version of the directory database. The up-to-dateness vector and the high water mark tables use the invocationID
and DC GUID respectively so that domain controllers know from which copy of the Active Directory database the
replication information is coming.
The invocationID is a globally unique identifier (GUID ) value that is visible near the top of the output after you
run the command repadmin /showrepl. The following text represents example output from the command:
Repadmin: running command /showrepl against full DC local host

Default-First-Site-Name\VDC1
DSA Options: IS_GC
DSA object GUID: 966651f3-a544-461f-9f2c-c30c91d17818
DSA invocationID: b0d9208b-8eb6-4205-863d-d50801b325a9
When AD DS is properly restored on a domain controller, the invocationID is reset. As a result of this change, you
will experience an increase in replication traffic – the duration of which is relative to the size of the partition being
replicated
For example, assume that VDC1 and DC2 are two domain controllers in the same domain. The following figure
shows the perception of DC2 about VDC1 when the invocationID value is reset in a proper restore situation.
USN rollback
USN rollback occurs when the normal updates of the USNs are circumvented and a domain controller tries to use
a USN that is lower than its latest update. USN rollback will be detected and replication will be stopped before
divergence in the forest is created, in most cases.
USN rollback can be caused in many ways, for example, when old virtual hard disk (VHD ) files are used or
physical-to-virtual conversion (P2V conversion) is performed without ensuring that the physical machine stays
offline permanently after the conversion. Take the following precautions to ensure that USN rollback does not
occur:
When not running Windows Server 2012 or newer, do not take or use a snapshot of a domain controller virtual
machine.
Do not copy the domain controller VHD file.
When not running Windows Server 2012 or newer, do not export the virtual machine that is running a domain
controller.
Do not restore a domain controller or attempt to roll back the contents of an Active Directory database by any
other means than a supported backup solution, such as Windows Server Backup.
In some cases, USN rollback may go undetected. In other cases, it may cause other replication errors. In these
cases, it is necessary to identify the extent of the problem and take care of it in a timely manner. For information
about how to remove lingering objects that may occur as a result of USN rollback, see Outdated Active Directory
objects generate event ID 1988 in Windows Server 2003 in the Microsoft Knowledge Base.
USN rollback detection

In most cases, USN rollbacks without a corresponding reset of the invocationID caused by improper restore
procedures are detected. Windows Server 2008 provides protections against inappropriate replication after an
improper domain controller restore operation. These protections are triggered by the fact that an improper restore
operation results in lower USNs that represent originating changes that the replication partners have already
received.
In Windows Server 2008 and Windows Server 2003 SP1, when a destination domain controller requests changes
by using a previously used USN, the response by its source replication partner is interpreted by the destination
domain controller to mean that its replication metadata is outdated. This indicates that the Active Directory
database on the source domain controller has been rolled back to a previous state. For example, the VHD file of a
virtual machine has been rolled back to a previous version. In this case, the destination domain controller initiates
the following quarantine measures on the domain controller that has been identified as having undergone an
improper restore:
AD DS pauses the Net Logon service, which prevents user accounts and computer accounts from changing
account passwords. This action prevents the loss of such changes if they occur after an improper restore.
AD DS disables inbound and outbound Active Directory replication.
AD DS generates Event ID 2095 in the Directory Service event log to indicate the condition.
The following illustration shows the sequence of events that occurs when USN rollback is detected on VDC2, the
destination domain controller that is running on a virtual machine. In this illustration, the detection of USN rollback
occurs on VDC2 when a replication partner detects that VDC2 has sent an up-to-dateness USN value that was
seen previously by the destination domain controller, which indicates that VDC2’s database has rolled back in time
improperly.
If the Directory Service event log reports Event ID 2095, complete the following procedure immediately.
To resolve Event ID 2095

1. Isolate the virtual machine that recorded the error from the network.
2. Attempt to determine whether any changes originated from this domain controller and propagated to other
domain controllers. If the event was a result of a snapshot or copy of a virtual machine being started, try to
determine the time the USN rollback occurred. You can then check the replication partners of that domain
controller to determine whether replication occurred since then.
You can use the Repadmin tool to make this determination. For information about how to use Repadmin,
see Monitoring and Troubleshooting Active Directory Replication Using Repadmin. If you are not able to
determine this yourself, contact Microsoft Support for assistance.
3. Forcefully demote the domain controller. This involves cleaning up the domain controller’s metadata and
seizing the operations master (also known as flexible single master operations or FSMO ) roles. For more
information, see the “Recovering from USN rollback” section of How to detect and recover from a USN
rollback in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 in the Microsoft
Knowledge Base.
4. Delete all former VHD files for the domain controller.
Undetected USN rollback

USN rollback might not be detected in one of two circumstances:
1. The VHD file is attached to different virtual machines that are running in multiple locations simultaneously.
2. The USN on the restored domain controller has increased past the last USN that the other domain controller
has received.
In the first circumstance, other domain controllers might replicate with either one of the virtual machines, and
changes might occur on either virtual machine without being replicated to the other. This divergence of the forest is
difficult to detect, and it will cause unpredictable directory responses. This situation might occur after a P2V
migration if both the physical and virtual machine are run on the same network. This could also happen if multiple
virtual domain controllers are created from the same physical domain controller and then run on the same
network.
In the second circumstance, a range of USNs applies to two different sets of changes. This can continue for
extended periods without being detected. Whenever an object that is created during that time is modified, a
lingering object is detected and reported as Event ID 1988 in Event Viewer. The following illustration shows how
USN rollback might not be detected in such a circumstance.
Read-only domain controllers

RODCs are domain controllers that host read-only copies of the partitions in an Active Directory database. RODCs
avoid most USN rollback issues because they do not replicate any changes to the other domain controllers.
However, if an RODC replicates from a writeable domain controller that has been affected by USN rollback, the
RODC is affected as well.
Restoring an RODC using a snapshot is not recommended. Restore an RODC using an Active Directory–
compatible backup application. Also, as with writeable domain controllers, care must be taken to not allow an
RODC to be offline for more than tombstone lifetime. This condition can result in lingering objects on the RODC.
For more information about RODCs, see the Read-Only Domain Controller Planning and Deployment Guide.
This topic provides detailed methodology on troubleshooting the virtualized domain controller feature.
Troubleshooting virtualized domain controller cloning
Troubleshooting virtualized domain controller safe restore
Introduction
The most important way to improve your troubleshooting skills is build a test lab and rigorously examine normal,
working scenarios. If you encounter errors, they are more obvious and easy to understand, since you then have a
solid foundation of how domain controller promotion works. This also allows you to build your analysis and
network analysis skills. This goes for all distributed systems technologies, not just virtualized domain controller
deployment.
The critical elements to advanced troubleshooting of domain controller configuration are:
1. Linear analysis combined with focus and attention to detail.
2. Understanding network capture analysis
3. Understanding the built-in logs
The first and second are beyond the scope of this topic, but the third can be explained in some detail. Virtualized
domain controller troubleshooting requires a logical and linear method. The key is to approach the issue using the
data provided and only resort to complex tools and analysis when you have exhausted the provided output and
logging.
Troubleshooting virtualized domain controller cloning

This sections covers:
Tools for Troubleshooting
Logging Options
General Methodology for Troubleshooting Domain Controller Cloning
Server Core and the Event Log
Troubleshooting Specific Problems
The troubleshooting strategy for virtualized domain controller cloning follows this general format:
Logging Options
The built-in logs are the most important tool for troubleshooting issues with domain controller cloning. All of these
logs are enabled and configured for maximum verbosity, by default.
Operation Log
Cloning - Event viewer\Windows logs\System

- Event viewer\Applications and services logs\Directory Service
- %systemroot%\debug\dcpromo.log
Promotion - %systemroot%\debug\dcpromo.log
- Event viewer\Windows logs\System
- Event viewer\Applications and services logs\File Replication
Service
- Event viewer\Applications and services logs\DFS Replication
Tools and Commands for Troubleshooting Domain Controller Configuration

To troubleshoot issues not explained by the logs, use the following tools as a starting point:
Dcdiag.exe
Repadmin.exe
Network Monitor 3.4
General Methodology for Troubleshooting Domain Controller Cloning
1. Is the VM booting into DS Repair Mode (DSRM )? This indicates troubleshooting is necessary. To log on in
DSRM, use .\Administrator account and specify the DSRM password.
a. Examine the Dcpromo.log.
a. Did initial cloning steps succeed but domain controller promotion fail?
b. Do errors indicate issues with the local domain controller or with the AD DS environment,
such as errors returned from the PDC emulator?
b. Examine the System and Directory Services event logs and the dccloneconfig.xml and
CustomDCCloneAllowList.xml
a. Does an incompatible application need to be in the CustomDCCloneAllowList.xml allow list?
b. Is the IP address or computer name either duplicated or invalid in the dccloneconfig.xml?
c. Is the Active Directory site invalid in the dccloneconfig.xml?
d. Is the IP address not set in the dccloningconfig.xml and there is no DHCP server available?
e. Is the PDC emulator online and available through the RPC protocol?
f. Is the domain controller a member of the Cloneable Domain Controllers group? Is the
permission Allow a DC to create a clone of itself set on the domain root for that group?
g. Does the Dccloneconfig.xml file contain syntax errors that prevent correct parsing?
h. Is the hypervisor supported?
i. Did domain controller promotion fail after cloning began successfully?
j. Was the maximum number of auto-generated domain controller names (9999) exceeded?
k. Is the MAC address duplicated?
2. Is host name of the clone the same as the source DC?
a. Is there a Dccloneconfig.xml file in one of the allowed locations?
3. Is the VM booting into normal mode and cloning completed, but the domain controller is not functioning
correctly?
a. First check if the host name is changed on the clone. If the host name is different, cloning has at least
partially completed.
b. Does the domain controller have a duplicate IP address of the source domain controller from the
dccloneconfig.xml, but the source domain controller was offline during cloning?
c. If the domain controller is advertising, treat the issue as any normal post-promotion issue you would
have without cloning.
d. If the domain controller is not advertising, examine the Directory Service, System, Application, File
Replication and DFS Replication event logs for post-promotion errors.
Disabling DSRM Boot
Once booted into DSRM due to any error, diagnose the cause for failure and if the dcpromo.log does not indicate
that cloning cannot be retried, fix the cause for failure and reset the DSRM flag. A failed clone does not return to
normal mode on its own on the next reboot; you must remove the DS Restore Mode boot flag in order to try
cloning again. All of these steps require running as an elevated administrator.
R e m o v i n g D SR M w i t h M sc o n fi g .e x e
To turn DSRM boot off using a GUI, use the System Configuration tool:
1. Run msconfig.exe
2. On the Boot tab, under Boot Options, de-select Safe boot (it is already selected with the option Active
Directory repair enabled)
3. Click OK and restart when prompted
R e m o v i n g D SR M w i t h B c d e d i t .e x e
To turn DSRM boot off from the command-line, use the Boot Configuration Data Store Editor:
1. Open a CMD prompt and run:
Bcdedit.exe /deletevalue safeboot
2. Restart the computer with:
Shutdown.exe /t /0 /r
NOTE
Bcdedit.exe also works in a Windows PowerShell console. The commands there are:
Bcdedit.exe /deletevalue safeboot
Restart-computer
Server Core and the Event Log

The event logs contain much of the useful information about virtualized domain controller cloning operations. By
default, a Windows Server 2012 computer installation is a Server Core installation, which means there is no
graphical interface and therefore, no way to run the local Event Viewer snap-in.
To review the event logs on a server running a Server Core installation:
Run the Wevtutil.exe tool locally
Run PowerShell cmdlet Get-WinEvent locally
If you have enabled the Windows Advanced Firewall rules for the "Remote Event Log Management" groups
(or equivalent ports) to allow inbound communication, you can manage the event log remotely using
Eventvwr.exe, wevtutil.exe, or Get-Winevent. This can be done on Server Core installation using NETSH.exe,
Group Policy, or the new Set-NetFirewallRule cmdlet in Windows PowerShell 3.0.
WARNING
Do not attempt to add the graphical shell back to the computer while it is in DSRM. Windows servicing stack (CBS) cannot
operate correctly while in Safe Mode or DSRM. Attempts to add features or roles while in DSRM will not complete and leave
the computer in an unstable state until it is booted normally. Since a virtualized domain controller clone in DSRM cannot boot
normally, and should not be booted normally under most circumstances, it is impossible to safely add the graphical shell.
Doing so is unsupported and may leave you with an unusable server.

Events
All virtualized domain controller cloning events write to the Directory Services event log of the clone domain
controller VM. The Application, File Replication Service, and DFS Replication event logs may also contain useful
troubleshooting information for failed cloning. Failures during the RPC call to the PDC emulator may be available
in the event log on the PDC emulator.
Below are the Windows Server 2012 cloning-specific events in the Directory Services event log, with notes and
suggested resolutions for errors.
D i r e c t o r y Se r v i c e s Ev e n t L o g
Event ID 2160
Source Microsoft-Windows-ActiveDirectory_DomainService
Severity Informational
Message The local has found a virtual domain controller cloning

configuration file.
The virtual domain controller cloning configuration file is found

at: %1
The existence of the virtual domain controller cloning

configuration file indicates that the local virtual domain
controller is a clone of another virtual domain controller. The
will start to clone itself.
Notes and resolution This is a success event and only an issue if unexpected.
Examine the DSA Working Directory, %systemroot%\ntds, and
root of any local or removable disks for the dcclconeconfig.xml
file.
Event ID 2161
Message The local did not find the virtual domain controller cloning
configuration file. The local machine is not a cloned DC.
file.
Event ID 2162
Severity Error
Message Virtual domain controller cloning failed.
Please check events logged in System event logs and

%systemroot%\debug\dcpromo.log for more information on
errors that correspond to the virtual domain controller cloning
attempt.
Error code: %1
Notes and resolution Follow message instructions, this error is a catchall.
Event ID 2163
Message DsRoleSvc service was started to clone the local virtual domain
controller.
file.
Event ID 2164
Severity Error
Message failed to start the DsRoleSvc service to clone the local virtual
domain controller.
Notes and resolution Examine the service settings for the DS Role Server service
(DsRoleSvc) and ensure its start type is set to manual. Validate
that no third party program is preventing the start of this
service.
Event ID 2165
Severity Error
Message failed to start a thread during the cloning of the local virtual
domain controller.
Error code:%1
Error message:%2
Thread name:%3
Notes and resolution Contact Microsoft Product Support
Event ID 2166
Severity Error
Message needs RPCSS service to initiate rebooting into DSRM. Waiting

for RPCSS to initialize into a running state failed.
Error code:%1
Notes and resolution Examine the System event log and service settings for the RPC
Server service (Rpcss)
Event ID 2167
Severity Error
Message could not initialize virtual domain controller knowledge. See

previous event log entry for details.
Additional Data
Failure code:%1
Notes and resolution Follow message instructions, this error is a catchall.
Event ID 2168
Message Microsoft-Windows-ActiveDirectory_DomainService
The DC is running on a supported hypervisor. VM Generation

ID is detected.
Current value of VM Generation ID: %1
Event ID 2169
Message There is no VM Generation ID detected. The DC is hosted on a

physical machine, a down-level version of Hyper-V, or a
hypervisor that does not support the VM Generation ID.
Additional Data
Failure code returned when checking VM Generation ID:%1
Notes and resolution This is a success event if not intending to clone. Otherwise,
examine the System event log and review hypervisor product
support documentation.
Event ID 2170
Severity Warning
Message A Generation ID change has been detected.
Generation ID cached in DS (old value):%1
Generation ID currently in VM (new value):%2
The Generation ID change occurs after the application of a

virtual machine snapshot, after a virtual machine import
operation or after a live migration operation. will create a new
invocation ID to recover the domain controller. Virtualized
domain controllers should not be restored using virtual
machine snapshots. The supported method to restore or
rollback the content of an Active Directory Domain Services
database is to restore a system state backup made with an
Active Directory Domain Services aware backup application.
Notes and resolution This is a success event if intending to clone. Otherwise,

examine the System event log.
Event ID 2171
Message No Generation ID change has been detected.
Notes and resolution This is a success event if not intending to clone, and should be
seen at every reboot of a virtualized DC. Otherwise, examine
the System event log.
Event ID 2172
Message Read the msDS-GenerationId attribute of the Domain

Controller's computer object.
msDS-GenerationId attribute value:%1
Notes and resolution This is a success event if intending to clone. Otherwise,

Event ID 2173
Message Failed to read the msDS-GenerationId attribute of the Domain

Controller's computer object. This may be caused by database
transaction failure, or the generation id does not exist in the
local database. The msDS-GenerationId does not exist during
the first reboot after dcpromo or the DC is not a virtual
domain controller.
Additional Data
Failure code:%1
Notes and resolution This is a success event if intending to clone and it is the first
VM reboot after cloning has completed. It can also be ignored
on non-virtual Domain controllers. Otherwise, examine the
System event log.
Event ID 2174
Message The DC is neither a virtual domain controller clone nor a

restored virtual domain controller snapshot.
Notes and resolution This is a success event if not intending to clone. Otherwise,
Event ID 2175
Severity Error
Message Virtual domain controller clone configuration file exists on an

unsupported platform.
Notes and resolution This occurs when a dccloneconfig.xml is found but a VM

Generation-ID could not be found, such as when a
dccloneconfig.xml file is found on a physical computer or on a
hypervisor that does not support VM Generation-ID.
Event ID 2176
Message Renamed virtual domain controller clone configuration file.
Additional Data
Old file name:%1
New file name:%2
Notes and resolution Rename expected when booting a source VM back up,
because the VM Generation ID has not changed. This prevents
the source domain controller from trying to clone.
Event ID 2177
Severity Error
Message Renaming virtual domain controller clone configuration file

failed.
Additional Data
File name:%1
Failure code:%2 %3
Notes and resolution Rename attempt expected when booting a source VM back
up, because the VM Generation ID has not changed. This
prevents the source domain controller from trying to clone.
Manually rename the file and investigate installed third party
products that may be preventing the file rename.
Event ID 2178
Message Detected virtual domain controller clone configuration file, but

VM Generation ID has not been changed. The local DC is the
clone source DC. Rename the clone configuration file.
Notes and resolution Expected when booting a source VM back up, because the VM
Generation ID has not changed. This prevents the source
domain controller from trying to clone.
Event ID 2179
Message The msDS-GenerationId attribute of the Domain Controller's

computer object has been set to the following parameter:
GenerationID attribute:%1
Event ID 2180
Severity Warning
Message Failed to set the msDS-GenerationId attribute of the Domain
Controller's computer object.
Additional Data
Failure code:%1
Notes and resolution Examine the System event log and Dcpromo.log. Lookup the
specific error in MS TechNet, MS Knowledgebase, and MS
blogs to determine its usual meaning, and then troubleshoot
based on those results.
Event ID 2182
Message Internal event: The Directory Service has been asked to clone a
remote DSA:
Event ID 2183
Message Internal event: completed the request to clone the remote

Directory System Agent.
Original DC name:%3
Request clone DC name:%4
Request clone DC site:%5
Additional Data
Error value:%1 %2
Event ID 2184
Severity Error
Message failed to create a domain controller account for the cloned DC.
Original DC name:%1
Allowed number of cloned DC:%2
The limit on the number of domain controller accounts that

can be generated by cloning was exceeded.
Notes and resolution A single source domain controller name can only automatically
generate 9999 times if domain controllers are not demoted,
based on the naming convention. Use the element in the XML
to generate a new unique name or clone from a differently
named DC.
Event ID 2191
Message set the following registry value to disable DNS updates.
Registry Key:%1
Registry Value: %2
Registry Value data: %3
During the cloning process, the local machine may have the
same computer name as the clone source machine for a short
time. DNS A and AAAA record registration are disabled during
this period so clients cannot send requests to the local
machine undergoing cloning. The cloning process will enable
DNS updates again after cloning is completed.
Event ID 2192
Severity Error
Message failed to set the following registry value to disable DNS
updates.
Registry Key:%1
Registry Value: %2
Error code:%4
Error message:%5
machine undergoing cloning.
Notes and resolution Examine Application and System event logs. Investigate third
party application that may be blocking registry updates.
Event ID 2193
Message set the following registry value to enable DNS updates.
Registry Key:%1
Registry Value: %2
Event ID 2194
Severity Error
Message failed to set the following registry value to enable DNS
updates.
Registry Key:%1
Registry Value: %2
Error code:%4
Error message:%5
Event ID 2195
Severity Error
Message Failed to set DSRM boot.
Error code:%1
Error message:%2
When virtual domain controller cloning failed or virtual

domain controller clone configuration file appears on a non-
supported hypervisor, the local machine will reboot into DSRM
for troubleshooting. Setting DSRM boot failed.
Event ID 2196
Severity Error
Message Failed to enable shutdown privilege.
Error code:%1
Error message:%2

for troubleshooting. Enabling shutdown privilege failed.
party application that may be blocking privilege usage.
Event ID 2197
Severity Error
Message Failed to initiate system shutdown.
Error code:%1
Error message:%2

for troubleshooting. Initiating system shutdown failed.
Event ID 2198
Severity Error
Message failed to create or modify the following cloned DC object.
Additional data:
Object:
%1
Error value: %2
%3
Notes and resolution Lookup the specific error in MS TechNet, MS Knowledgebase,
and MS blogs to determine its usual meaning, and then
troubleshoot based on those results.
Event ID 2199
Severity Error
Message failed to create the following cloned DC object because the

object already exists.
Additional data:
Source DC:
%1
Object:
%2
Notes and resolution Validate the dccloneconfig.xml did not specify an existing
domain controller or that copies of the dccloneconfig.xml have
been used on multiple clones without editing the name. If the
collision is still unexpected, determine which administrator
promoted it; contact them to discuss if the existing domain
controller should be demoted, the existing domain controller
metadata cleaned, or if the clone should use a different name.
Event ID 2203
Severity Error
Message Last virtual domain controller cloning failed. This is the first
reboot since then so this should be a re-try of the cloning.
However, neither virtual domain controller clone configuration
file exists nor virtual machine generation ID change is
detected. Boot into DSRM.
Last virtual domain controller cloning failed:%1
Virtual domain controller clone configuration file exists:%2
Virtual machine generation ID change is detected:%3
Notes and resolution Expected if cloning failed previously, due to missing or invalid
dccloneconfig.xml
Event ID 2210
Severity Error
Message failed to create objects for clone domain controller.
Additional data:
Clone Id: %6
Clone domain controller name: %1
Retry loop: %2
Exception value: %3
Error value: %4
DSID: %5
Notes and resolution Review the System and Directory Services event logs and the
dcpromo.log for further details on why cloning failed.
Event ID 2211
Message has created objects for clone domain controller.
Additional data:
Clone Id: %3
Retry loop: %2
Event ID 2212
Message started to create objects for the clone domain controller.
Additional data:
Clone Id: %1
Clone name: %2
Clone site: %3
Clone RODC: %4
Event ID 2213
Message created a new KrbTgt object for Read-Only domain controller

cloning.
Additional data:
Clone Id: %1
New KrbTgt Object Guid: %2
Event ID 2214
Message will create a computer object for the clone domain controller.
Additional data:
Clone Id: %1
Original domain controller: %2
Clone domain controller: %3
Event ID 2215
Message will add the clone domain controller in the following site.
Additional data:
Clone Id: %1
Site: %2
Event ID 2216
Message will create a servers container for the clone domain controller.
Additional data:
Clone Id: %1
Servers Container: %2
Event ID 2217
Message will create a server object for the clone domain controller.
Additional data:
Clone Id: %1
Server Object: %2
Event ID 2218
Message will create a NTDS Settings object for the clone domain
controller.
Additional data:
Clone Id: %1
Object: %2
Event ID 2219
Message will create connection objects for the clone Read-Only domain
controller.
Additional data:
Clone Id: %1
Event ID 2220
Message will create SYSVOL objects for the clone Read-Only domain
controller.
Additional data:
Clone Id: %1
Event ID 2221
Severity Error
Message failed to generate a random password for the cloned domain
controller.
Additional data:
Clone Id: %1
Error: %3 %4
Notes and resolution Examine the system event log for further details on why the
machine account password could not be created.
Event ID 2222
Severity Error
Message failed to set password for the cloned domain controller.
Additional data:
Clone Id: %1
Error: %3 %4
Notes and resolution Examine the system event log for further details on why the
machine account password could not be set.
Event ID 2223
Message successfully set machine account password for the cloned

domain controller.
Additional data:
Clone Id: %1
Total retry times: %3
Event ID 2224
Severity Error
Message Virtual domain controller cloning failed. The following %1

Managed Service Account(s) exist on the cloned machine:
%2
For cloning to succeed, all Managed Service Accounts must be

removed. This can be done using the Remove-
ADComputerServiceAccount PowerShell cmdlet.
Notes and resolution Expected when using standalone MSAs (not group MSA). Do
not follow the event advice to remove the account - it is
incorrectly written. Use Uninstall-AdServiceAccount -
https://technet.microsoft.com/library/hh852310.
Standalone MSAs - first released in Windows Server 2008 R2 -

were replaced in Windows Server 2012 with group MSAs
(gMSA). GMSAs support cloning.
Event ID 2225
Message The cached secrets of the following security principal have

been successfully removed from local domain controller:
%1
After cloning a read-only domain controller, secrets which were

previously cached on the cloning source read-only domain
controller will be removed on the cloned domain controller.
Event ID 2226
Severity Error
Message Failed to remove cached secrets of the following security
principal from local domain controller:
%1
Error: %2 (%3)

controller need to be removed on the clone in order to
decrease the risk that an attacker can obtain those credentials
from stolen or compromised clone. If the security principal is a
highly privileged account and should be protected against this,
please use rootDSE operation rODCPurgeAccount to manually
clear its secrets on local domain controller.
Notes and resolution Examine the System and Directory Services event logs for
further information.
Event ID 2227
Severity Error
Message Exception is raised while trying to remove cached secrets from

local domain controller.
Additional data:
Exception value: %1
Error value: %2
DSID: %3

controller need to be removed on the clone in order to
decrease the risk that an attacker can obtain those credentials
from stolen or compromised clone. If any of these security
principals is a highly privileged account and should be
protected against this, please use rootDSE operation
rODCPurgeAccount to manually clear its secrets on local
domain controller.
Notes and resolution Examine the System and Directory Services event logs for
further information.
Event ID 2228
Severity Error
Message The Virtual machine generation ID in the Active Directory
database of this domain controller is different from the current
value of this virtual machine. However, a virtual domain
controller clone configuration file (DCCloneConfig.xml) could
not be located so domain controller cloning was not
attempted. If a domain controller cloning operation was
intended, please ensure that a DCCloneConfig.xml is provided
in any one of the supported locations. In addition, the IP
address of this domain controller conflicts with another
domain controller's IP address. To ensure no disruptions in
service occur, the domain controller has been configured to
boot into DSRM.
Additional data:
The duplicate IP address: %1
Notes and resolution This protection mechanism stops duplicate domain controllers
when possible (it will not when using DHCP, for example). Add
a valid DcCloneConfig.xml file, remove the DSRM flag, and re-
attempt cloning
Event ID 29218
Source Microsoft-Windows-DirectoryServices-DSROLE-Server
Severity Error
Message Virtual domain controller cloning failed. The cloning operation

could not be completed and the cloned domain controller was
rebooted into Directory Services Restore Mode (DSRM).
Please check previously logged events and

%systemroot%\debug\dcpromo.log for more information on
errors that correspond to the virtual domain controller cloning
attempt and whether or not this clone image can be reused.
If one or more log entries indicate that the cloning process

cannot be retried, the image must be securely destroyed.
Otherwise you may fix the errors, clear the DSRM boot flag,
and reboot normally; upon reboot, the cloning operation will
be retried.
Notes and resolution Review the System and Directory Services event logs and the
dcpromo.log for further details on why cloning failed.
Event ID 29219
Message Virtual domain controller cloning succeeded.

Event ID 29248
Severity Error
Message Virtual domain controller cloning failed to obtain Winlogon

Notification. The returned error code is %1 (%2).
For more information on this error, please review

%systemroot%\debug\dcpromo.log for errors that correspond
to the virtual domain controller cloning attempt.
Notes and resolution Contact Microsoft Product Support
Event ID 29249
Severity Error
Message Virtual domain controller cloning failed to parse virtual domain

controller configuration file.
The returned HRESULT code is %1.
The configuration file is:%2
Please fix the errors in the configuration file and retry the
cloning operation.
For more information about this error, please see

%systemroot%\debug\dcpromo.log.
Notes and resolution Examine the dclconeconfig.xml file for syntax errors using an
XML editor and the DCCloneConfigSchema.xsd schema file.
Event ID 29250
Severity Error
Message Virtual domain controller cloning failed. There are software or
services currently enabled on the cloned virtual domain
controller that are not present in the allowed application list
for virtual domain controller cloning.
Following are the missing entries:
%2
%1 (if any) was used as the defined inclusion list.
The cloning operation cannot be completed if there are non-

cloneable applications installed.
Please run Active Directory PowerShell Cmdlet Get-

ADDCCloningExcludedApplicationList to check which
applications are installed on the cloned machine, but not
included in the allow list, and add them to the allow list if they
are compatible with virtual domain controller cloning. If any of
these applications are not compatible with virtual domain
controller cloning, please uninstall them before re-trying the
cloning operation.
The virtual domain controller cloning process searches for the

allowed application list file, CustomDCCloneAllowList.xml,
based on the following search order; the first file found is used
and all others are ignored:
1. The registry value name:

HKey_Local_Machine\System\CurrentControlSet\Services\NTD
S\Parameters\AllowListFolder
2. The same directory where the DSA Working Directory folder

resides
3. %windir%\NTDS
4. Removable read/write media in order of drive letter at the

root of the drive
Notes and resolution Follow the message instructions
Event ID 29251
Severity Error
Message Virtual domain controller cloning failed to reset the IP
addresses of the clone machine.
The returned error code is %1 (%2).
This error might be caused by misconfiguration in network

configuration sections in the virtual domain controller
configuration file.
Please see %systemroot%\debug\dcpromo.log for more

information about errors that correspond to IP addresses
resetting during virtual domain controller cloning attempts.
Details on resetting machine IP addresses on the cloned

machine can be found at https://go.microsoft.com/fwlink/?
LinkId=208030
Notes and resolution Verify the IP information set in the dccloneconfig.xml is valid
and does not duplicate the original source machine.
Event ID 29253
Severity Error
Message Virtual domain controller cloning failed. The clone domain

controller was unable to locate the primary domain controller
(PDC) operations master in the cloned computer's home
domain of the cloned machine.
Please verify that the primary domain controller in the home

domain of the cloned machine is assigned to a live domain
controller, is online, and is operational. Verify that the cloned
machine has LDAP/RPC connectivity to the primary domain
controller over the required ports and protocols.
Notes and resolution Validate the cloned domain controller IP and DNS information
is set. Use Dcdiag.exe /test:locatorcheck to validate if the PDCE
is online, use Nltest.exe /server: /dclist: to valid RPC, obtain a
network capture from the PDCE while cloning fails and analyze
the traffic.
Event ID 29254
Severity Error
Message Virtual domain controller cloning failed to bind to the primary
domain controller %1.
Please verify that the primary domain controller %1 is online

and is operational. Verify that the cloned machine has
LDAP/RPC connectivity to the primary domain controller over
the required ports and protocols.
Notes and resolution Validate the cloned domain controller IP and DNS information
is set. Use Dcdiag.exe /test:locatorcheck to validate if the PDCE
is online, use Nltest.exe /server: /dclist: to valid RPC, obtain a
network capture from the PDCE while cloning fails and analyze
the traffic.
Event ID 29255
Severity Error
Message Virtual domain controller cloning failed.
An attempt to create objects on the primary domain controller

%1 required for the image being cloned returned error %2
(%3).
Please verify that the cloned domain controller has privilege to

clone itself. Check for related events in the Directory Service
event log on primary domain controller %1.
Notes and resolution Lookup the specific error in MS TechNet, MS Knowledgebase,

and MS blogs to determine its typical meaning, and then
troubleshoot based on those results.
Event ID 29256
Severity Error
Message An attempt to set the Boot into Directory Services Restore

Mode flag failed with error code %1.

information about errors.
Notes and resolution Examine the Directory Services log and dcpromo.log for details.
Examine Application and System event logs. Investigate third
Event ID 29257
Severity Error
Message Virtual domain controller cloning has done. An attempt to

reboot the machine failed with error code %1.
Please reboot the machine to finish the cloning operation.
Event ID 29264
Severity Error
Message An attempt to clear the Boot into Directory Services Restore

Mode flag failed with error code %1.

information about errors.
Notes and resolution Examine the Directory Services log and dcpromo.log for details.
Examine Application and System event logs. Investigate third
Event ID 29265
Message Virtual domain controller cloning succeeded. The virtual

domain controller cloning configuration file %1 has been
renamed to %2.
Notes and resolution N/A, this is a success event.
Event ID 29266
Severity Error
Message Virtual domain controller cloning succeeded. The attempt to
rename virtual domain controller cloning configuration file %1
failed with error code %2 (%3).
Notes and resolution Manually rename the dccloneconfig.xml file.
Event ID 29267
Severity Error
Message Virtual domain controller cloning failed to check the virtual

domain controller cloning allowed application list.
This error might be caused by a syntax error in the clone allow

list file (The file currently being checked is: %3). For more
information about this error, please see
%systemroot%\debug\dcpromo.log.
Notes and resolution Follow the event instructions
Er r o r M e ssa g e s
There are no direct interactive errors for failed virtualized domain controller cloning; all cloning information logs in
the System and Directory Services logs and the domain controller promotion logs in dcpromo.log. However, if the
server boots into DS Restore Mode, investigate immediately, as promotion or cloning failed.
The dcpromo.log is the first place to check for cloning failure. Depending on the failure listed, it may be necessary
to subsequently review Directory Services and System logs for further diagnosis.
Known Issues and Support Scenarios
The following are common issues seen during the Windows Server 2012 development process. All of these issues
are "by design" and have either a valid workaround or more appropriate technique to avoid them in the first place.
Some may be resolved in later releases of Windows Server 2012.
Issue Cloning fails, DSRM
Symptoms Clone boots into Directory Services Restore Mode
Resolution and Notes Validate all steps followed from sections Deploying Virtualized
Domain Controller section and General Methodology for
Troubleshooting Domain Controller Cloning
Described in KB 2742844.
Issue Extra IP leases when using DHCP to clone

Symptoms After successfully cloning a DC and using DHCP, the first boot
of the clone takes a DHCP lease. Then when the server is
renamed and restarted as a DC, it takes a second DHCP lease.
The first IP address is not released and you end up with a
"phantom" lease
Resolution and Notes Manually delete the unused address lease in DHCP or allow it
to expire normally. Described in KB 2742836.
Issue Cloning fails into DSRM after very long delay
Symptoms Cloning appears to pause at "Domain controller cloning is at

X% completion" for between 8 and 15 minutes. After this, the
cloning fails and boots into DSRM.
Resolution and Notes The cloned computer cannot get a dynamic IP address from
DHCP or SLAAC, or is using a duplicate IP address, or cannot
find the PDC. Multiple retry attempts performed by cloning
lead to the delay. Resolve the networking issue to allow
cloning.
Issue Cloning does not recreate all service principal names
Symptoms If a set of three-part service principal names (SPN) includes

both a NetBIOS name with a port and an otherwise identical
NetBIOS name without a port, the non-port entry is not
recreated with the new computer name. For example:
customspn/DC1:200/app1 INVALID USE OF SYMBOLS this is

recreated with the new computer name
customspn/DC1/app1 INVALID USE OF SYMBOLS this is not

recreated with the new computer name
Fully qualified names are recreated and SPNs without three

parts are recreated, regardless of ports. For example, these are
recreated successfully on the clone:
customspn/DC1:202 INVALID USE OF SYMBOLS this is

recreated
customspn/DC1 INVALID USE OF SYMBOLS this is recreated
customspn/DC1.corp.contoso.com:202 INVALID USE OF

SYMBOLS this is recreated name
customspn/DC1.corp.contoso.com INVALID USE OF SYMBOLS

this is recreated
Resolution and Notes This is a limitation of the domain controller rename process in
Windows, not just in cloning. Three-part SPNS are not handled
by the renaming logic in any scenario. Most included Windows
services are unaffected by this, as they recreate any missing
SPNs as needed. Other applications may require manually
entering the SPN to resolve the issue.
Issue Cloning fails, boots into DSRM, general networking

errors
Symptoms Clone boots into Directory Services Repair Mode. There are
general networking errors.
Resolution and Notes Ensure that the new clone does not have a duplicate static
MAC address assigned from the source domain controller; you
can see if a VM uses static MAC addresses by running this
command on the hypervisor host for both the source and
clone virtual machines:
Get-VM -VMName test-vm | Get-VMNetworkAdapter | fl *
Change the MAC address to a unique static address or switch

to using dynamic MAC addresses.
Described in KB 2742844
Issue Cloning fails, boots into DSRM as a duplicate of the

source DC
Symptoms A new clone boots up without cloning. The dccloneconfig.xml

is not renamed and the server starts in DS Restore Mode. The
Directory Services event log shows Error 2164
failed to start the DsRoleSvc service to clone the local virtual

domain controller.
Resolution and Notes Examine the service settings for the DS Role Server service
(DsRoleSvc) and ensure its start type is set to Manual. Validate
that no third party program is preventing the start of this
service.
For more information about how to reclaim this secondary DC

while ensuring that updates get replicated outbound, see
Microsoft KB article 2742970.
Issue Cloning fails, boots into DSRM, error 8610
Symptoms Clone boots into Directory Services Restore Mode. Dcpromo

.log shows 8610 error (which is
ERROR_DS_ROLE_NOT_VERIFIED 8610 or 0x21A2)
Resolution and Notes Will happen if the PDC can be discoverable but it has not
performed sufficient replication to allow itself to assume the
role. For example, if cloning is started and another
administrator moves the PDCE FSMO role to a new DC.
Issue Cloning fails, boots into DSRM, general networking

errors
Symptoms Clone boots into Directory Services Restore Mode. There are
general networking errors.
Resolution and Notes Ensure that the new clone does not have a duplicate static
MAC address assigned from the source domain controller; you
can see if a VM uses static MAC addresses by running this
command on the Hyper-V host for both the source and clone
virtual machines:
Get-VM -VMName test-vm | Get-VMNetworkAdapter | fl *
Change the MAC address to a unique static address or switch

to using dynamic MAC addresses.
Issue Cloning fails, boots into DSRM
Symptoms Clone boots into Directory Services Repair Mode
Resolution and Notes Ensure that the dccloneconfig.xml contains the schema
definition (see sampledccloneconfig.xml, line 2):
<d3c:DCCloneConfig
xmlns:d3c="uri:microsoft.com:schemas:DCCloneConfig"
>
Issue No logon servers are available error logging into DSRM
Symptoms Clone boots into Directory Services Repair Mode. You attempt
to logon and receive error:
There are currently no logon servers are available to

service the logon request
Resolution and Notes Ensure you logon with the DSRM administrator account, and
not the domain account. Use the left arrow and type a user
name of:
.\administrator
Issue Clone Source fails into DSRM, error
Symptoms During cloning, fails 8437 "Create clone DC objects on PDC

failed" (0x20f5)
Resolution and Notes Duplicate computer name was set in DCCloneConfig.xml as

the source DC or an existing DC. The computer name also
needs to be in the NetBIOS computer name format (15
characters or fewer, not an FQDN).
Fix the dccloneconfig.xml file by setting a unique, valid name.
Issue New-addccloneconfigfile error "index was out of range"
Symptoms When running the new-addccloneconfigfile cmdlet, you receive

error:
Index was out of range. Must be non-negative and less than

the size of the collection.
Resolution and Notes You must run the cmdlet in an administrator-elevated

Windows PowerShell console. This error is caused by lack of
local administrator group membership on the computer.
Issue Cloning fails, duplicate DC
Symptoms Clone boots without cloning, duplicates existing source DC
Resolution and Notes The computer was copied and started but does not contain a
DcCloneConfig.xml file in any of the supported locations, and
did not have a duplicate IP address with the source domain
controller. The DC must be correctly removed in order to avoid
data loss.
Issue New-ADDCCloneConfigFile fails with The server is not
operational error when it checks if the source domain
controller is a member of the Cloneable Domain
controllers group if a GC is not available.
Symptoms When running New-ADDCCloneConfigFile to create a

dccloneconfig.xml file, you receive error:
Code - The server is not operational
Resolution and Notes Verify connectivity to a GC from the server where you run
New-ADDCCloneConfigFile and verify that the membership of
the source domain controller in the Cloneable Domain
Controllers group has replicated to that GC.
Run the following command as a means of flushing the DC

locator cache for cases where a GC or DC may have been
taken offline recently:
Code - nltest /dsgetdc: /GC /FORCE
Advanced Troubleshooting
This module seeks to teach advanced troubleshooting by using working logs as samples, with some explanation of
what occurred. If you understand what a successful virtualized domain controller operation looks like, failures
become obvious in your environment. These logs are presented by their source, with the ascending order of
expected events (even when they are warnings and errors) related to a cloned domain controller within each log.
Cloning a Domain Controller
In this example, the clone domain controller uses DHCP to get an IP address, replicates SYSVOL using FRS or
DFSR (see the appropriate log as necessary), is a global catalog, and uses a blank dccloneconfig.xml file.
The Directory Services log contains the majority of event-based cloning operational information. The hypervisor
changes the VM -Generation ID and the NTDS service notes it, then invalidates the RID pool and changes the
invocation ID. The new VM -Generation ID is set and the server replicates Active Directory data inbound. The DFSR
service is stopped and its database that hosts SYSVOL is deleted, forcing a non-authoritative sync inbound. The
USN high watermark is adjusted.
Event ID Source Message
2160 ActiveDirectory_DomainService The local Active Directory Domain

Services has found a virtual domain
controller cloning configuration file.
The virtual domain controller cloning

configuration file is found at:
\DCCloneConfig.xml
The existence of the virtual domain

controller cloning configuration file
indicates that the local virtual domain
controller is a clone of another virtual
domain controller. The Active Directory
Domain Services will start to clone itself.
2191 ActiveDirectory_DomainService Active Directory Domain Services set the
following registry value to disable DNS
updates.
Registry Key:
SYSTEM\CurrentControlSet\Services\Net
logon\Parameters
Registry Value:
UseDynamicDns
Registry Value data:
During the cloning process, the local

machine may have the same computer
name as the clone source machine for a
short time. DNS A and AAAA record
registration are disabled during this
period so clients cannot send requests
to the local machine undergoing
cloning. The cloning process will enable
DNS updates again after cloning is
completed.
2191 ActiveDirectory_DomainService Active Directory Domain Services set the
following registry value to disable DNS
updates.
Registry Key:
SYSTEM\CurrentControlSet\Services\Dn
scache\Parameters
Registry Value:
RegistrationEnabled

completed.
"Information 2/7/2012 3:12:49 PM

Microsoft-Windows-
ActiveDirectory_DomainService 2191
Internal Configuration" Active Directory
Domain Services set the following
registry value to disable DNS updates.
Registry Key:
SYSTEM\CurrentControlSet\Services\Tcpi
p\Parameters
Registry Value:
DisableDynamicUpdate

completed.
2172 ActiveDirectory_DomainService Read the msDS-GenerationId attribute
of the Domain Controller's computer
object.
msDS-GenerationId attribute value:
2170 ActiveDirectory_DomainService A Generation ID change has been

detected.
Generation ID cached in DS (old value):
Generation ID currently in VM (new

value):
The Generation ID change occurs after

the application of a virtual machine
snapshot, after a virtual machine import
operation or after a live migration
operation. Active Directory Domain
Services will create a new invocation ID
to recover the domain controller.
Virtualized domain controllers should
not be restored using virtual machine
snapshots. The supported method to
restore or rollback the content of an
database is to restore a system state
backup made with an Active Directory
Domain Services aware backup
application.
1109 ActiveDirectory_DomainService The invocationID attribute for this
directory server has been changed. The
highest update sequence number at the
time the backup was created is as
follows:
InvocationID attribute (old value):
InvocationID attribute (new value):
Update sequence number:
The invocationID is changed when a

directory server is restored from backup
media, is configured to host a writeable
application directory partition, has been
resumed after a virtual machine
snapshot has been applied, after a
virtual machine import operation, or
after a live migration operation.
Domain Services-aware backup
application.
1000 ActiveDirectory_DomainService Microsoft Active Directory Domain

Services startup complete.
1394 ActiveDirectory_DomainService All problems preventing updates to the

database have been cleared. New
updates to the Active Directory Domain
Services database are succeeding. The
Net Logon service has restarted
2163 ActiveDirectory_DomainService DsRoleSvc service was started to clone

the local virtual domain controller.
326 NTDS ISAM NTDS (536) NTDSA: The database

engine attached a database (1,
C:\Windows\NTDS\ntds.dit). (Time=0
seconds)
Internal Timing Sequence: [1] 0.000, [2]

0.000, [3] 0.000, [4] 0.000, [5] 0.000, [6]
0.016, [7] 0.000, [8] 0.000, [9] 0.000,
[10] 0.000, [11] 0.000, [12] 0.000.
Saved Cache: 1
engine stopped the instance (0).
Dirty Shutdown: 0

0.000, [3] 0.000, [4] 0.000, [5] 0.032, [6]
0.000, [7] 0.000, [8] 0.000, [9] 0.031,
[10] 0.000, [11] 0.000, [12] 0.000, [13]
0.000, [14] 0.000, [15] 0.000.

engine (6.02.8225.0000) is starting a
new instance (0).

engine started a new instance (0).
(Time=0 seconds)

0.000, [3] 0.015, [4] 0.078, [5] 0.000, [6]
0.000, [7] 0.000, [8] 0.000, [9] 0.046,
[10] 0.000, [11] 0.000.
1004 ActiveDirectory_DomainService Active Directory Domain Services was

shut down successfully.

engine (6.02.8225.0000) is starting a
new instance (0).

engine attached a database (1,
C:\Windows\NTDS\ntds.dit). (Time=0
seconds)

0.015, [3] 0.016, [4] 0.000, [5] 0.031, [6]
0.000, [7] 0.000, [8] 0.000, [9] 0.000,
[10] 0.000, [11] 0.000, [12] 0.000.
Saved Cache: 1

engine started a new instance (0).
(Time=1 seconds)

0.000, [3] 0.000, [4] 0.391, [5] 0.000, [6]
0.000, [7] 0.000, [8] 0.000, [9] 0.031,
[10] 0.000, [11] 0.000.
follows:

application.
1168 ActiveDirectory_DomainService Internal error: An Active Directory

Domain Services error has occurred.
Additional Data
Error value (decimal):
Error value (hexadecimal):
Internal ID:
7011658
1110 ActiveDirectory_DomainService Promotion of this domain controller to a
global catalog will be delayed for the
following interval.
Interval (minutes):
This delay is necessary so that the

required directory partitions can be
prepared before the global catalog is
advertised. In the registry, you can
specify the number of seconds that the
directory system agent will wait before
promoting the local domain controller
to a global catalog. For more
information about the Global Catalog
Delay Advertisement registry value, see
the Resource Kit Distributed Systems
Guide

engine stopped the instance (0).
Dirty Shutdown: 0

0.000, [3] 0.000, [4] 0.000, [5] 0.047, [6]
0.000, [7] 0.000, [8] 0.000, [9] 0.016,
[10] 0.000, [11] 0.000, [12] 0.000, [13]
0.000, [14] 0.000, [15] 0.000.
1004 ActiveDirectory_DomainService Active Directory Domain Services was

shut down successfully.
1539 ActiveDirectory_DomainService Active Directory Domain Services could

not disable the software-based disk
write cache on the following hard disk.
Hard disk:
c:
Data might be lost during system

failures
2179 ActiveDirectory_DomainService The msDS-GenerationId attribute of the

Domain Controller's computer object
has been set to the following
parameter:
GenerationID attribute:
2173 ActiveDirectory_DomainService Failed to read the msDS-GenerationId
attribute of the Domain Controller's
computer object. This may be caused by
database transaction failure, or the
generation id does not exist in the local
database. The msDS-GenerationId does
not exist during the first reboot after
dcpromo or the DC is not a virtual
domain controller.
Additional Data
Failure code:
1000 ActiveDirectory_DomainService Microsoft Active Directory Domain

Services startup complete, version
6.2.8225.0
1394 ActiveDirectory_DomainService All problems preventing updates to the

database have been cleared. New
updates to the Active Directory Domain
Services database are succeeding. The
Net Logon service has restarted.
1128 ActiveDirectory_DomainService 1128 Knowledge Consistency Checker

"A replication connection was created
from the following source directory
service to the local directory service.
Source directory service:
CN=NTDS Settings,
Local directory service:
CN=NTDS Settings,
Additional Data
Reason Code:
0x2
Creation Point Internal ID:
f0a025d
1999 ActiveDirectory_DomainService The source directory service has
optimized the update sequence number
(USN) presented by the destination
directory service. The source and
destination directory services have a
common replication partner. The
destination directory service is up to
date with the common replication
partner, and the source directory
service was installed using a backup of
this partner.
Destination directory service ID:
()
Common directory service ID:
Common property USN:
As a result, the up-to-dateness vector

of the destination directory service has
been configured with the following
settings.
Previous object USN:
Previous property USN:
Database GUID:
Object USN:
Property USN:
Sy st e m Ev e n t L o g
The next indications of cloning operations are in the System Event log. As the hypervisor tells the guest computer
that it was cloned or restored from a snapshot, the domain controller immediately invalidates its RID pool to avoid
duplicating security principals later. As cloning proceeds, various expected operations and messages appear, mostly
around services starting and stopping and some expected errors caused by this. When completed the System event
log notes overall cloning success.

16654 Directory-Services-SAM A pool of account-identifiers (RIDs) has
been invalidated. This may occur in the
following expected cases:
1. A domain controller is restored from

backup.
2. A domain controller running on a

virtual machine is restored from
snapshot.
3. An administrator has manually

invalidated the pool
7036 Service Control Manager The Active Directory Domain Services

service entered the running state.
7036 Service Control Manager The Kerberos Key Distribution Center

3096 Netlogon The primary Domain Controller for this

domain could not be located.
7036 Service Control Manager The Security Accounts Manager service

entered the running state.
7036 Service Control Manager The Server service entered the running
state.
7036 Service Control Manager The Netlogon service entered the

running state.
7036 Service Control Manager The Active Directory Web Services

7036 Service Control Manager The DFS Replication service entered the
running state.
7036 Service Control Manager The File Replication Service service

14533 Microsoft-Windows-DfsSvc DFS has finished building all

namespaces.
14531 Microsoft-Windows-DfsSvc DFS server has finished initializing.
7036 Service Control Manager The DFS Namespace service entered the
running state.
7023 Service Control Manager The Intersite Messaging service

terminated with the following error:
The specified server cannot perform the

requested operation.
7036 Service Control Manager The Intersite Messaging service entered
the stopped state.
5806 Netlogon Dynamic updates have been manually

disabled on this domain controller.
USER ACTION
Reconfigure this domain controller to

use dynamic updates or manually add
the DNS records from the file
'%SystemRoot%\System32\Config\Netlo
gon.dns' to the DNS database."
16651 Directory-Services-SAM The request for a new account-identifier

pool failed. The operation will be retried
until the request succeeds. The error is
The requested FSMO operation failed.

The current FSMO holder could not be
contacted.
7036 Service Control Manager The DNS Server service entered the
running state.
7036 Service Control Manager The DS Role Server service entered the
running state.

stopped state.

entered the stopped state.
7036 Service Control Manager The Kerberos Key Distribution Center

service entered the stopped state.
7036 Service Control Manager The DNS Server service entered the
stopped state.
7036 Service Control Manager The Active Directory Domain Services

service entered the stopped state.

running state.
7040 Service Control Manager The start type of the Active Directory
Domain Services service was changed
from auto start to disabled.

stopped state.

29219 DirectoryServices-DSROLE-Server Virtual domain controller cloning
succeeded.
29223 DirectoryServices-DSROLE-Server This server is now a Domain Controller.
29265 DirectoryServices-DSROLE-Server Virtual domain controller cloning

succeeded. The virtual domain controller
cloning configuration file
C:\Windows\NTDS\DCCloneConfig.xml
has been renamed to
C:\Windows\NTDS\DCCloneConfig.2012
0207-151533.xml.
1074 User32 The process

C:\Windows\system32\lsass.exe (DC2)
has initiated the restart of computer
DC2 on behalf of user NT
AUTHORITY\SYSTEM for the following
reason: Operating System:
Reconfiguration (Planned)
Reason Code: 0x80020004
Shutdown Type: restart
Comment: "
D C P R O M O .L O G
The Dcpromo.log contains the actual promotion portion of cloning that the Directory Services event log does not
describe. Since the log does not provide the level of explanation that the event log entries impart, this section of the
module contains additional annotation.
The promotion process means that the cloning starts, the DC is scrubbed of its current configuration and re-
promoted using the existing AD database (much like an IFM promotion), then the DC replicates inbound change
deltas of AD and SYSVOL, and cloning is complete.
NOTE
The log has been modified in this module for readability, by removing the date column.
NOTE
For further explanation of the dcpromo.log see the Understand and Troubleshoot AD DS Simplified Administration in
Windows Server 2012.
https://go.microsoft.com/fwlink/p/?LinkId=237244
Start clone-based promotion

Set the Directory Services Restore Mode flag so that the server does not boot back up normally as the
original clone and cause naming or Directory Service collisions
Update the Directory Services event log
15:14:01 [INFO] vDC Cloneing: Setting Boot into DSRM flag succeeded.
15:14:01 [WARNING] Cannot get user Token for Format Message: 1725l
15:14:01 [INFO] vDC Cloning: Created vDCCloningUpdate event.
15:14:01 [INFO] vDC Cloning: Created vDCCloningComplete event.
Stop the NetLogon service so that the domain controller does not advertise
15:14:01 [INFO] Stopping service NETLOGON

15:14:01 [INFO] ControlService(STOP) on NETLOGON returned 1(gle=0)
15:14:01 [INFO] DsRolepWaitForService: waiting for NETLOGON to enter one of 7 states
15:14:01 [INFO] DsRolepWaitForService: QueryServiceStatus on NETLOGON returned 1 (gle=0), SvcStatus.dwCS=3
15:14:02 [INFO] DsRolepWaitForService: exiting because NETLOGON entered STOPPED state
15:14:02 [INFO] DsRolepWaitForService(for any end state) on NETLOGON service returned 0
15:14:02 [INFO] Exiting service-stop loop after service NETLOGON entered STOPPED state
15:14:02 [INFO] StopService on NETLOGON returned 0
15:14:02 [INFO] Configuring service NETLOGON to 1 returned 0
15:14:02 [INFO] Updating service status to 4
15:14:02 [INFO] vDC Cloning: Set vDCCloningUpdate event.
Examine the dccloneconfig.xml file for administrator-specified customizations.

In this sample case it is a blank file, so all settings are automatically generated and automatic IP addressing
is required from the network
15:14:02 [INFO] vDC Cloning: Clone config file C:\Windows\NTDS\DCCloneConfig.xml is considered to be a blank
file (containing 0 bytes)
15:14:02 [INFO] vDC Cloning: Parsing clone config file C:\Windows\NTDS\DCCloneConfig.xml returned HRESULT 0x0
Validate that there are no services or programs installed that are not part of the DefaultDCCloneAllowList.xml
or CustomDCCloneAllowList.xml
15:14:02 [INFO] vDC Cloning: Checking allowed list:

15:14:03 [INFO] vDC Cloning: Completed checking allowed list:
Enable DHCP on the network adapters, since IP information was not specified by the administrator
15:14:03 [INFO] vDC Cloning: Enable DHCP:

15:14:03 [INFO] WMI Instance: Win32_NetworkAdapterConfiguration.Index=12
15:14:03 [INFO] Method: EnableDHCP
15:14:03 [INFO] HRESULT code: 0x0 (0)
15:14:03 [INFO] Return Value: 0x0 (0)
Locate the PDC emulator

Set the clone's site (automatically generated in this case)
Set the clone's name (automatically generated in this case)
15:14:03 [INFO] vDC Cloning: Found PDC. Name: DC1.root.fabrikam.com
15:14:04 [INFO] vDC Cloning: Winlogon UI Notification #1: Domain Controller cloning is at 5% completion...
15:14:05 [INFO] Site of the cloned DC: Default-First-Site-Name
Create the new clone computer object

Rename the clone to match the new name
15:14:05 [INFO] vDC Cloning: Clone DC objects are created on PDC.

15:14:05 [INFO] Name of the cloned DC: DC2-CL0001
15:14:05 [INFO] DsRolepSetRegStringValue on System\CurrentControlSet\Services\NTDS\Parameters\CloneMachineName
to DC2-CL0001 returned 0
15:14:05 [INFO] vDC Cloning: Save CloneMachineName in registry: 0x0 (0)
Provide the promotion settings, based on previous dccloneconfig.xml or automatic generation rules
15:14:05 [INFO] vDC Cloning: Promotion parameters setting:

15:14:05 [INFO] DNS Domain Name: root.fabrikam.com
15:14:05 [INFO] Replica Partner: \\DC1.root.fabrikam.com
15:14:05 [INFO] Site Name: Default-First-Site-Name
15:14:05 [INFO] DS Database Path: C:\Windows\NTDS
15:14:05 [INFO] DS Log Path: C:\Windows\NTDS
15:14:05 [INFO] SysVol Root Path: C:\Windows\SYSVOL
15:14:05 [INFO] Account: root.fabrikam.com\DC2-CL0001$
15:14:05 [INFO] Options: DSROLE_DC_CLONING (0x800400)
Start promotion
15:14:05 [INFO] Promote DC as a clone

15:14:05 [INFO] Validate supplied paths
15:14:05 [INFO] Validating path C:\Windows\NTDS.
15:14:05 [INFO] Path is a directory
15:14:05 [INFO] Path is on a fixed disk drive.
15:14:05 [INFO] Validating path C:\Windows\NTDS.
15:14:05 [INFO] Path is a directory
15:14:05 [INFO] Validating path C:\Windows\SYSVOL.
15:14:05 [INFO] Path is on an NTFS volume
15:14:05 [INFO] Start the worker task
15:14:05 [INFO] Request for promotion returning 0
Stop and configure all of the AD DS -related services (NTDS, NTFRS/DFSR, KDC, DNS )
NOTE
The DNS service taking a long time to shutdown is expected in this scenario, as it is using AD-integrated zones that were no
longer available even before the NTDS service stopped - see the DNS events described later in this section of the module.
15:14:15 [INFO] Stopping service NTDS

15:14:15 [INFO] Stopping service NtFrs
15:14:15 [INFO] ControlService(STOP) on NtFrs returned 1(gle=0)
15:14:15 [INFO] DsRolepWaitForService: waiting for NtFrs to enter one of 7 states
15:14:15 [INFO] DsRolepWaitForService: QueryServiceStatus on NtFrs returned 1 (gle=0), SvcStatus.dwCS=3
15:14:16 [INFO] DsRolepWaitForService: QueryServiceStatus on NtFrs returned 1 (gle=0), SvcStatus.dwCS=1
15:14:16 [INFO] DsRolepWaitForService: exiting because NtFrs entered STOPPED state
15:14:16 [INFO] DsRolepWaitForService(for any end state) on NtFrs service returned 0
15:14:16 [INFO] ControlService(STOP) on NtFrs returned 0(gle=1062)
15:14:16 [INFO] Exiting service-stop loop after service NtFrs entered STOPPED state
15:14:16 [INFO] StopService on NtFrs returned 0
15:14:16 [INFO] Configuring service NtFrs to 1 returned 0
15:14:16 [INFO] Stopping service Kdc
15:14:16 [INFO] ControlService(STOP) on Kdc returned 1(gle=0)
15:14:16 [INFO] DsRolepWaitForService: waiting for Kdc to enter one of 7 states
15:14:16 [INFO] DsRolepWaitForService: QueryServiceStatus on Kdc returned 1 (gle=0), SvcStatus.dwCS=3
15:14:17 [INFO] DsRolepWaitForService: QueryServiceStatus on Kdc returned 1 (gle=0), SvcStatus.dwCS=1
15:14:17 [INFO] DsRolepWaitForService: exiting because Kdc entered STOPPED state
15:14:17 [INFO] DsRolepWaitForService(for any end state) on Kdc service returned 0
15:14:17 [INFO] ControlService(STOP) on Kdc returned 0(gle=1062)
15:14:17 [INFO] Exiting service-stop loop after service Kdc entered STOPPED state
15:14:17 [INFO] StopService on Kdc returned 0
15:14:17 [INFO] Configuring service Kdc to 1 returned 0
15:14:17 [INFO] Stopping service DNS
15:14:17 [INFO] ControlService(STOP) on DNS returned 1(gle=0)
15:14:17 [INFO] DsRolepWaitForService: waiting for DNS to enter one of 7 states
15:14:17 [INFO] DsRolepWaitForService: QueryServiceStatus on DNS returned 1 (gle=0), SvcStatus.dwCS=3
15:15:00 [INFO] DsRolepWaitForService: exiting because DNS entered STOPPED state
15:15:00 [INFO] DsRolepWaitForService(for any end state) on DNS service returned 0
15:15:00 [INFO] ControlService(STOP) on DNS returned 0(gle=1062)
15:15:00 [INFO] Exiting service-stop loop after service DNS entered STOPPED state
15:15:00 [INFO] StopService on DNS returned 0
15:15:00 [INFO] Configuring service DNS to 1 returned 0
15:15:00 [INFO] ControlService(STOP) on NTDS returned 1(gle=1062)
15:15:00 [INFO] DsRolepWaitForService: waiting for NTDS to enter one of 7 states
15:15:00 [INFO] DsRolepWaitForService: QueryServiceStatus on NTDS returned 1 (gle=0), SvcStatus.dwCS=3
15:15:01 [INFO] DsRolepWaitForService: QueryServiceStatus on NTDS returned 1 (gle=0), SvcStatus.dwCS=1
15:15:01 [INFO] DsRolepWaitForService: exiting because NTDS entered STOPPED state
15:15:01 [INFO] DsRolepWaitForService(for any end state) on NTDS service returned 0
15:15:01 [INFO] ControlService(STOP) on NTDS returned 0(gle=1062)
15:15:01 [INFO] Exiting service-stop loop after service NTDS entered STOPPED state
15:15:01 [INFO] StopService on NTDS returned 0
15:15:01 [INFO] Configuring service NTDS to 1 returned 0
15:15:01 [INFO] Configuring service NTDS
Force NT5DS (NTP ) time synchronization with another domain controller (typically the PDCE )
15:15:02 [INFO] Forcing time sync
Contact a domain controller that holds the source domain controller account of the clone
Flush any existing Kerberos tickets
15:15:02 [INFO] Searching for a domain controller for the domain root.fabrikam.com that contains the account
DC2$
15:15:02 [INFO] Located domain controller DC1.root.fabrikam.com for domain root.fabrikam.com
15:15:02 [INFO] Directing kerberos authentication to DC1.root.fabrikam.com returns 0
15:15:02 [INFO] DsRolepFlushKerberosTicketCache() successfully flushed the Kerberos ticket cache
15:15:02 [INFO] Using site Default-First-Site-Name for server \\DC1.root.fabrikam.com
Stop the NetLogon service and set its start type

15:15:02 [INFO] DsRolepWaitForService: waiting for NETLOGON to enter one of 7 states
15:15:03 [INFO] DsRolepWaitForService: exiting because NETLOGON entered STOPPED state
15:15:03 [INFO] DsRolepWaitForService(for any end state) on NETLOGON service returned 0
15:15:03 [INFO] Exiting service-stop loop after service NETLOGON entered STOPPED state
15:15:03 [INFO] StopService on NETLOGON returned 0
15:15:03 [INFO] Configuring service NETLOGON to 1 returned 0
15:15:03 [INFO] Stopped NETLOGON
Configure the DFSR/NTFRS services to run automatically

Delete their existing database files to force non-authoritative sync of SYSVOL when the service next starts
15:15:03 [INFO] Configuring service DFSR

15:15:03 [INFO] Configuring service DFSR to 256 returned 0
15:15:03 [INFO] Configuring service NTFRS
15:15:03 [INFO] Configuring service NTFRS to 256 returned 0
15:15:03 [INFO] Removing DFSR Database files for SysVol
15:15:03 [INFO] Removing FRS Database files in C:\Windows\ntfrs\jet
15:15:03 [INFO] Removed C:\Windows\ntfrs\jet\log\edb.log
15:15:03 [INFO] Removed C:\Windows\ntfrs\jet\log\edbres00001.jrs
15:15:03 [INFO] Removed C:\Windows\ntfrs\jet\log\edbres00002.jrs
15:15:03 [INFO] Removed C:\Windows\ntfrs\jet\log\edbtmp.log
15:15:03 [INFO] Removed C:\Windows\ntfrs\jet\ntfrs.jdb
15:15:03 [INFO] Removed C:\Windows\ntfrs\jet\sys\edb.chk
15:15:03 [INFO] Removed C:\Windows\ntfrs\jet\temp\tmp.edb
15:15:04 [INFO] Created system volume path
15:15:04 [INFO] Configuring service DFSR
15:15:04 [INFO] Configuring service DFSR to 128 returned 0
15:15:04 [INFO] Configuring service NTFRS
15:15:04 [INFO] Configuring service NTFRS to 128 returned 0
Start the promotion process using the existing NTDS database file
Contact the RID Master
NOTE
The AD DS service is not actually installed here, this is legacy instrumentation in the log
15:15:04 [INFO] Installing the Directory Service
15:15:04 [INFO] Calling NtdsInstall for root.fabrikam.com
15:15:04 [INFO] Starting Active Directory Domain Services installation
15:15:04 [INFO] Validating user supplied options
15:15:04 [INFO] Determining a site in which to install
15:15:04 [INFO] Examining an existing forest...
15:15:04 [INFO] Starting a replication cycle between DC1.root.fabrikam.com and the RID operations master
(2008r2-01.root.fabrikam.com), so that the new replica will be able to create users, groups, and computer
objects...
15:15:04 [INFO] Configuring the local computer to host Active Directory Domain Services
15:15:04 [INFO] EVENTLOG (Warning): NTDS General / Service Control : 1539
Active Directory Domain Services could not disable the software-based disk write cache on the following hard
disk.
Hard disk:
c:
Data might be lost during system failures.
15:15:10 [INFO] EVENTLOG (Informational): NTDS General / Internal Processing : 2041
Duplicate event log entries were suppressed.
See the previous event log entry for details. An entry is considered a duplicate if
the event code and all of its insertion parameters are identical. The time period for
this run of duplicates is from the time of the previous event to the time of this event.
Event Code:
80000603
Number of duplicate entries:
2
15:15:10 [INFO] EVENTLOG (Informational): NTDS General / Internal Configuration : 2121
This Active Directory Domain Services server is disabling the Recycle Bin. Deleted objects may not be undeleted
at this time.
Change the existing invocation ID that existed in the source computers database
Create a new NTDS Settings object for this clone
Replicate in AD object delta from the partner domain controller
NOTE
Even though all objects are listed as replicated, this is just metadata needed to subsume the updates. All the unchanged
objects in the cloned NTDS database already exist and do not require replication again, just like using IFM-based promotion.
15:15:10 [INFO] EVENTLOG (Informational): NTDS Replication / Replication : 1109
The invocationID attribute for this directory server has been changed. The highest update sequence number at
the time the backup was created is as follows:
24e7b22f-4706-402d-9b4f-f2690f730b40
f74cefb2-89c2-442c-b1ba-3234b0ed62f8
20520
The invocationID is changed when a directory server is restored from backup media, is configured to host a
writeable application directory partition, has been resumed after a virtual machine snapshot has been applied,
after a virtual machine import operation, or after a live migration operation. Virtualized domain controllers
should not be restored using virtual machine snapshots. The supported method to restore or rollback the content
of an Active Directory Domain Services database is to restore a system state backup made with an Active
Directory Domain Services-aware backup application.
15:15:10 [INFO] EVENTLOG (Error): NTDS General / Internal Processing : 1168
Internal error: An Active Directory Domain Services error has occurred.
Additional Data
Error value (decimal):
2
Error value (hexadecimal):
2
Internal ID:
7011658
15:15:11 [INFO] Creating the NTDS Settings object for this Active Directory Domain Controller on the remote AD
DC DC1.root.fabrikam.com...
15:15:11 [INFO] Replicating the schema directory partition
15:15:11 [INFO] Replicated the schema container.
15:15:12 [INFO] Active Directory Domain Services updated the schema cache.
15:15:12 [INFO] Replicating the configuration directory partition
15:15:12 [INFO] Replicating data CN=Configuration,DC=root,DC=fabrikam,DC=com: Received 2612 out of
approximately 2612 objects and 94 out of approximately 94 distinguished name (DN) values...
15:15:12 [INFO] Replicated the configuration container.
15:15:13 [INFO] Replicating critical domain information...
15:15:13 [INFO] Replicating data DC=root,DC=fabrikam,DC=com: Received 109 out of approximately 109 objects and
35 out of approximately 35 distinguished name (DN) values...
15:15:13 [INFO] Replicated the critical objects in the domain container.
Populate the GC partitions as needed with any missing updates

Complete the critical AD DS portion of the promotion
15:15:13 [INFO] EVENTLOG (Informational): NTDS General / Global Catalog : 1110

Promotion of this domain controller to a global catalog will be delayed for the following interval.
Interval (minutes):
5
This delay is necessary so that the required directory partitions can be prepared before the global catalog is
advertised. In the registry, you can specify the number of seconds that the directory system agent will wait
before promoting the local domain controller to a global catalog. For more information about the Global Catalog
Delay Advertisement registry value, see the Resource Kit Distributed Systems Guide.
15:15:14 [INFO] EVENTLOG (Informational): NTDS General / Service Control : 1000
Microsoft Active Directory Domain Services startup complete, version 6.2.8225.0
15:15:15 [INFO] Creating new domain users, groups, and computer objects
15:15:16 [INFO] Completing Active Directory Domain Services installation
15:15:16 [INFO] NtdsInstall for root.fabrikam.com returned 0
15:15:16 [INFO] DsRolepInstallDs returned 0
15:15:16 [INFO] Installed Directory Service
Complete the inbound replication of SYSVOL

15:15:18 [INFO] Completed system volume replication
15:15:18 [INFO] SetProductType to 2 [LanmanNT] returned 0
15:15:18 [INFO] Set the product type
15:15:18 [INFO] Set the system volume path for NETLOGON
15:15:18 [INFO] Replicating non critical information
15:15:18 [INFO] User specified to not replicate non-critical data
15:15:18 [INFO] Stopped the DS
15:15:18 [INFO] Configuring service NTDS
Enable client DNS registration
15:15:18 [INFO] vDC Cloning: Set DisableDynamicUpdate reg value to 0 to enable dynamic update records
registration.
15:15:18 [INFO] vDC Cloning: Set UseDynamicDns reg value to 1 to enable dynamic update records registration.
15:15:18 [INFO] vDC Cloning: Set RegistrationEnabled reg value to 1 to enable dynamic update records
registration.
Run the SYSPREP modules specified by the DefaultDCCloneAllowList.xml element.
15:15:18 [INFO] vDC Cloning: Running sysprep providers.

15:15:32 [INFO] vDC Cloning: Completed running sysprep providers.
Cloning promotion is complete

Remove the DSRM boot flag so the server boots normally next time
Rename the dccloneconfig.xml so that it is not read again at next bootup
Restart the computer
15:15:32 [INFO] The attempted domain controller operation has completed

15:15:32 [INFO] Updating service status to 4
15:15:32 [INFO] DsRolepSetOperationDone returned 0
15:15:32 [INFO] vDC Cloning: Set vDCCloningComplete event.
15:15:32 [INFO] vDC Cloneing: Clearing Boot into DSRM flag succeeded.
15:15:32 [INFO] vDC Cloning: Winlogon UI Notification #22: Cloning Domain Controller succeeded. Now
rebooting...
15:15:33 [INFO] vDC Cloning: Renamed vDC clone configuration file.
15:15:33 [INFO] vDC Cloning: The old name is: C:\Windows\NTDS\DCCloneConfig.xml
15:15:33 [INFO] vDC Cloning: The new name is: C:\Windows\NTDS\DCCloneConfig.20120207-151533.xml
15:15:34 [INFO] vDC Cloning: Release Ipv4 on interface 'Wired Ethernet Connection 2', result=0.
15:15:34 [INFO] vDC Cloning: Release Ipv6 on interface 'Wired Ethernet Connection 2', result=0.
15:15:34 [INFO] Rebooting machine
A c t i v e D i r e c t o r y W e b Se r v i c e s Ev e n t L o g
While cloning is occurring, the NTDS.DIT database is often offline for extended periods. The ADWS service logs at
least one event for this. After cloning is complete, the ADWS service starts, notes that there is not yet a valid
computer certificate yet (there may or may not be, depending on your environment deploying a Microsoft PKI with
auto-enrollment or not) and then starts the instance for the new domain controller.
1202 ADWS Instance Events This computer is now hosting the

specified directory instance, but Active
Directory Web Services could not
service it. Active Directory Web Services
will retry this operation periodically.
Directory instance: NTDS
Directory instance LDAP port: 389
Directory instance SSL port: 636
1000 ADWS Instance Events Active Directory Web Services is starting
1008 ADWS Instance Events Active Directory Web Services has

successfully reduced its security
privileges
1100 ADWS Instance Events The values specified in the section of the
configuration file for Active Directory
Web Services have been loaded without
errors.
1400 ADWS Instance Events ADWS Certificate Events"Active

Directory Web Services could not find a
server certificate with the specified
certificate name. A certificate is required
to use SSL/TLS connections. To use
SSL/TLS connections, verify that a valid
server authentication certificate from a
trusted Certification Authority (CA) is
installed on the machine.
Certificate name:
1100 ADWS Instance Events The values specified in the section of the
configuration file for Active Directory
Web Services have been loaded without
errors.
1200 ADWS Instance Events Active Directory Web Services is now

servicing the specified directory
instance.
Directory instance: NTDS
Directory instance LDAP port: 389
Directory instance SSL port: 636
D N S Se r v e r Ev e n t L o g
The DNS service will experience brief expected outages while cloning occurs, as the DNS service is still running
while the AD DS database is offline. This occurs if using Active Directory Integrated DNS, but not if using Standard
Primary or Secondary DNS. These errors log multiple times. After cloning completes, DNS comes back online
normally.
4013 DNS-Server-Service The DNS server is waiting for Active

Directory Domain Services (AD DS) to
signal that the initial synchronization of
the directory has been completed. The
DNS server service cannot start until
the initial synchronization is complete
because critical DNS data might not yet
be replicated onto this domain
controller. If events in the AD DS event
log indicate that there is a problem with
DNS name resolution, consider adding
the IP address of another DNS server
for this domain to the DNS server list in
the Internet Protocol properties of this
computer. This event will be logged
every two minutes until AD DS has
signaled that the initial synchronization
has successfully completed.
4015 DNS-Server-Service The DNS server has encountered a

critical error from the Active Directory.
Check that the Active Directory is
functioning properly. The extended error
debug information (which may be
empty) is """". The event data contains
the error.
4000 DNS-Server-Service The DNS server was unable to open

Active Directory. This DNS server is
configured to obtain and use
information from the directory for this
zone and is unable to load the zone
without it. Check that the Active
Directory is functioning properly and
reload the zone. The event data is the
error code.
4013 DNS-Server-Service The DNS server is waiting for Active

Directory Domain Services (AD DS) to
signal that the initial synchronization of
the directory has been completed. The
DNS server service cannot start until
the initial synchronization is complete
because critical DNS data might not yet
be replicated onto this domain
controller. If events in the AD DS event
log indicate that there is a problem with
DNS name resolution, consider adding
the IP address of another DNS server
for this domain to the DNS server list in
the Internet Protocol properties of this
computer. This event will be logged
every two minutes until AD DS has
signaled that the initial synchronization
has successfully completed.
2 DNS-Server-Service The DNS server has started.
4 DNS-Server-Service The DNS server has finished the

background loading of zones. All zones
are now available for DNS updates and
zone transfers, as allowed by their
individual zone configuration.
F i l e R e p l i c a t i o n Se r v i c e Ev e n t L o g
The File Replication Service synchronizes non-authoritatively from a partner during cloning. Cloning accomplishes
this by deleting the NTFRS database files and leaving the contents of SYSVOL untouched, for use as pre-seeded
data. The two attempts to synchronize are expected.
13562 NtFrs Following is the summary of warnings

and errors encountered by File
Replication Service while polling the
Domain Controller
DC2.root.fabrikam.com for FRS replica
set configuration information.
Could not bind to a Domain Controller.

Will try again at next polling cycle
13502 NtFrs The File Replication Service is stopping.
13565 NtFrs File Replication Service is initializing the

system volume with data from another
domain controller. Computer DC2
cannot become a domain controller
until this process is complete. The
system volume will then be shared as
SYSVOL.
To check for the SYSVOL share, at the

net share
When File Replication Service completes

the initialization process, the SYSVOL
share will appear.
The initialization of the system volume

can take some time. The time is
dependent on the amount of data in
the system volume, the availability of
other domain controllers, and the
replication interval between domain
controllers.
13501 NtFrs The File Replication Service is starting
13502 NtFrs The File Replication Service is stopping.

13503 NtFrs The File Replication Service has stopped.
13565 NtFrs File Replication Service is initializing the

SYSVOL.

net share

share will appear.

controllers.
13501 NtFrs The File Replication Service is starting.
13553 NtFrs The File Replication Service successfully

added this computer to the following
replica set:
"DOMAIN SYSTEM VOLUME (SYSVOL

SHARE)"
Information related to this event is

shown below:
Computer DNS name is
Replica set member name is
Replica set root path is
Replica staging directory path is
Replica working directory path is

13520 NtFrs The File Replication Service moved the
preexisting files in to
\NtFrs_PreExisting___See_EventLog.
The File Replication Service may delete

the files in
\NtFrs_PreExisting___See_EventLog at
any time. Files can be saved from
deletion by copying them out of
Copying the files into
c:\windows\sysvol\domain may lead to
name conflicts if the files already exist
on some other replicating partner.
In some cases, the File Replication

Service may copy a file from
\NtFrs_PreExisting___See_EventLog into
instead of replicating the file from some
other replicating partner.
Space can be recovered at any time by

deleting the files in
\NtFrs_PreExisting___See_EventLog."
13508 NtFrs he File Replication Service is having

trouble enabling replication from \\ to
for using the
DNS name \\. FRS will keep retrying.
Following are some of the reasons you

would see this warning.
[1] FRS cannot correctly resolve the DNS

name \\ from this computer.
[2] FRS is not running on \\.
[3] The topology information in the

Active Directory Domain Services for
this replica has not yet replicated to all
the Domain Controllers.
This event log message will appear once

per connection, After the problem is
fixed you will see another event log
message indicating that the connection
has been established.
13509 NtFrs The File Replication Service has enabled

replication from \\ to for after repeated
retries.
13516 NtFrs The File Replication Service is no longer
preventing the computer from
becoming a domain controller. The
system volume has been successfully
initialized and the Netlogon service has
been notified that the system volume is
now ready to be shared as SYSVOL.
Type "net share" to check for the

SYSVOL share."
D F S R e p l i c a t i o n Ev e n t L o g
The DFSR services synchronizes non-authoritatively from a partner during cloning. Cloning accomplishes this by
deleting the DFSR database files and leaving the contents of SYSVOL untouched, for use as pre-seeded data. The
two attempts to synchronize are expected.
1004 DFSR The DFS Replication service has started.
1314 DFSR The DFS Replication service successfully

configured the debug log files.
Additional Information:
Debug Log File Path:

C:\Windows\debug
6102 DFSR The DFS Replication service has

successfully registered the WMI
provider

contacted domain controller
DC2.corp.contoso.com to access
configuration information.

set up an RPC listener for incoming
replication requests.
Port: 0"
4614 DFSR The DFS Replication service initialized
SYSVOL at local path
C:\Windows\SYSVOL\domain and is
waiting to perform initial replication. The
replicated folder will remain in the initial
synchronization state until it has
replicated with its partner. If the server
was in the process of being promoted
to a domain controller, the domain
controller will not advertise and function
as a domain controller until this issue is
resolved. This can occur if the specified
partner is also in the initial
synchronization state, or if sharing
violations are encountered on this
server or the synchronization partner. If
this event occurred during the
migration of SYSVOL from File
Replication Service (FRS) to DFS
Replication, changes will not replicate
out until this issue is resolved. This can
cause the SYSVOL folder on this server
to become out of sync with other
domain controllers.
Replicated Folder Name: SYSVOL Share
Replicated Folder ID:
Replication Group Name: Domain

System Volume
Replication Group ID:
Member ID:
Read-Only: 0
initialized the SYSVOL replicated folder
at local path
C:\Windows\SYSVOL\domain. This
member has completed initial
synchronization of SYSVOL with partner
dc1.corp.contoso.com. To check for the
presence of the SYSVOL share, open a
command prompt window and then
type ""net share"".

System Volume
Member ID:
Sync partner:
Troubleshooting virtualized domain controller safe restore

Logging Options
The built-in logs are the most important tool for troubleshooting issues with domain controller safe snapshot
restore. All of these logs are enabled and configured for maximum verbosity, by default.
Operation Log
Snapshot creation - Event viewer\Applications and services

logs\Microsoft\Windows\Hyper-V-Worker
Snapshot restore - Event viewer\Applications and services logs\Directory Service

- Event viewer\Windows logs\Application
Service
- Event viewer\Applications and services logs\DNS
- Event viewer\Applications and services
logs\Microsoft\Windows\Hyper-V-Worker

Dcdiag.exe
Repadmin.exe
Network Monitor 3.4
General Methodology for Troubleshooting Domain Controller Safe Restore
1. Is the safe snapshot restore expected, but having issues?
a. Examine the Directory Services event log
a. Are there snapshot restore errors?
b. Are there AD replication errors?
b. Examine the System event log
a. Are there communication errors?
b. Are there AD errors?
2. Is the safe snapshot restore unexpected?
a. Examine the hypervisor audit logs to determine who or what caused a rollback
b. Contact all administrators of the hypervisor and interrogate them as to who rolled back the VM
without notification
3. Is the server implementing USN rollback protection and not safely restoring?
a. Examine the Directory Services event log for an unsupported hypervisor or integration services
b. Examine the operating system and validate running Windows Server 2012?
Events
All virtualized domain controller safe snapshot restore events write to the Directory Services event log of the
restored domain controller VM. The Application, System, File Replication Service, and DFS Replication event logs
may also contain useful troubleshooting information for failed restores.
Below are the Windows Server 2012 safe restore-specific events in the Directory Services event log.
Event ID 2170
Severity Warning
Message A Generation ID change has been detected.
The Generation ID change occurs after the application of a

virtual machine snapshot, after a virtual machine import
operation or after a live migration operation. will create a new
invocation ID to recover the domain controller. Virtualized
domain controllers should not be restored using virtual
machine snapshots. The supported method to restore or
rollback the content of an Active Directory Domain Services
database is to restore a system state backup made with an
Active Directory Domain Services aware backup application.
Notes and resolution This is a success event if the snapshot was expected. If not,
examine the Hyper-V-Worker event log or contact the
hypervisor administrator.
Event ID 2174
Message The DC is neither a virtual domain controller clone nor a

restored virtual domain controller snapshot.
Notes and resolution Expected event when starting physical domain controllers or
virtualized domain controllers not restored from snapshot
Event ID 2181
Message The transaction was aborted due to the virtual machine being
reverted to a previous state. This occurs after the application
of a virtual machine snapshot, after a virtual machine import
operation, or after a live migration operation.
Notes and resolution Expected when restoring a snapshot. Transactions track the
VM Generation ID changing
Event ID 2185
Message stopped the FRS or DFSR service used to replicate the SYSVOL
folder.
Service name:%1
Active Directory detected that the virtual machine that hosts

the domain controller was reverted to a previous state. must
initialize a non-authoritative restore on the local SYSVOL
replica. This is performed by stopping the FRS or DFSR service
used to replicate the SYSVOL folder and starting it with the
appropriate registry keys and values to trigger the restore.
Event 2187 will be logged when FRS or DFSR service is
restarted.
Notes and resolution Expected when restoring a snapshot. All SYSVOL data on this
domain controller is replaced with a partner DC's copy.
Event ID 2186
Severity Error
Message failed to stop the FRS or DFSR service used to replicate the
SYSVOL folder.
Service name:%1
Error code:%2
Error message:%3

the domain controller was reverted to a previous state. must
initialize a non-authoritative restore on the local SYSVOL
replica. This is done by stopping the FRS or DFSR replication
service used to replicate the SYSVOL folder and then starting
it with the appropriate registry keys and values to trigger the
restore. failed to stop the current running service and cannot
complete the non-authoritative restore. Please perform a non-
authoritative restore manually.
Notes and resolution Examine the System, FRS and DFSR event logs for further
information.
Event ID 2187
Message started the FRS or DFSR service used to replicate the SYSVOL
folder.
Service name:%1

the domain controller was reverted to a previous state.
needed to initialize a non-authoritative restore on the local
SYSVOL replica. This was done by stopping the FRS or DFSR
service used to replicate the SYSVOL folder and starting it with
the appropriate registry keys and values to trigger the restore.
Event ID 2188
Severity Error
Message failed to start the FRS or DFSR service used to replicate the
SYSVOL folder.
Service name:%1
Error code:%2
Error message:%3

the domain controller was reverted to a previous state. needs
to initialize a non-authoritative restore on the local SYSVOL
replica. This is done by stopping the FRS or DFSR service used
to replicate the SYSVOL and starting it with appropriate
registry keys and values to trigger the restore. failed to start
the FRS or DFSR service used to replicate the SYSVOL folder
and cannot complete the non-authoritative restore. Please
perform a non-authoritative restore manually and restart the
service.
Notes and resolution Examine the System, FRS and DFSR event logs for further
information.
Event ID 2189
Message set the following registry values to initialize SYSVOL replica

during a non-authoritative restore:
Registry Key:%1
Registry Value: %2

replica. This is done by stopping the FRS or DFSR service used
to replicate the SYSVOL folder and starting it with the
appropriate registry keys and values to trigger the restore.
Event ID 2190
Severity Error
Message failed to set the following registry values to initialize the

SYSVOL replica during a non-authoritative restore:
Registry Key:%1
Registry Value: %2
Error code:%4
Error message:%5

the domain controller role was reverted to a previous state.
needs to initialize a non-authoritative restore on the local
SYSVOL replica. This is done by stopping the FRS or DFSR
service used to replicate the SYSVOL folder and starting it with
the appropriate registry keys and values to trigger the restore.
failed to set the above registry values and cannot complete
the non-authoritative restore. Please perform a non-
authoritative restore manually.
party applications that may be blocking registry updates.
Event ID 2200
Message Active Directory detected that the virtual machine that hosts
the domain controller was reverted to a previous state.
initializes replication to bring the domain controller current.
Event 2201 will be logged when the replication is finished.
Notes and resolution Expected when restoring a snapshot. Marks the beginning of
inbound AD replication.
Event ID 2201
the domain controller was reverted to a previous state. has
finished replication to bring the domain controller current.
Notes and resolution Expected when restoring a snapshot. Marks the end of
inbound AD replication.
Event ID 2202
Severity Error
the domain controller was reverted to a previous state. failed
replication to bring the domain controller up-to-date. The
domain controller will be updated after next periodic
replication.
Notes and resolution Examine the Directory Services and System event logs. Use
repadmin.exe to attempt forcing replication and note any
failures.
Event ID 2204
Message has detected a change of virtual machine generation ID. The

change means that the virtual domain controller has been
reverted to a previous state. will perform the following
operations to protect the reverted domain controller against
possible data divergence and to protect creation of security
principals with duplicate SIDs:
Create a new invocation ID
Invalidate current RID pool
Ownership of the FSMO roles will be validated at next inbound

replication. During this window if the domain controller held a
FSMO role, that role will be unavailable.
Start SYSVOL replication service restore operation.
Start replication to bring the reverted domain controller to the

most current state.
Request a new RID pool.
Notes and resolution Expected when restoring a snapshot. This explains all the
various reset operations that will occur as part of the safe
restore process.
Event ID 2205
Message invalidated current RID pool after virtual domain controller

was reverted to previous state.
Notes and resolution Expected when restoring a snapshot. The local RID pool must
be destroyed as the domain controller has time travelled and
they may have already been issued.
Event ID 2206
Severity ERROR
Message failed to invalidate current RID pool after virtual domain

controller was reverted to previous state.
Additional data:
Error code: %1
Error value: %2
Notes and resolution Examine the Directory Services and System event logs. Validate
that the RID Master is online can be reached from this server
using Dcdiag.exe /test:ridmanager
Event ID 2207
Severity ERROR
Message failed to restore after virtual domain controller was reverted to

previous state. A reboot into DSRM was requested. Please
check previous events for more information.
Notes and resolution Examine the Directory Services and System event logs.
Event ID 2208
Message deleted DFSR databases to initialize SYSVOL replica during a

non-authoritative restore.
Notes and resolution Expected when restoring a snapshot. This guarantees DFSR
non-authoritatively synchronizes SYSVOL from a partner DC.
Note that any other DFSR Replicated Folders on the same
volume as SYSVOL will also non-authoritatively sync (domain
controllers are not recommended to host custom DFSR sets
on the same volume as SYSVOL).
Event ID 2209
Severity Error
Message failed to delete DFSR databases.
Additional data:
Error code: %1
Error value: %2

replica. For DFSR, this is done by stopping the DFSR service,
deleting DFSR databases, and re-starting the service. Upon
restarting DFSR will rebuild the databases and start the initial
sync.
Notes and resolution Examine the DFSR event log.
Error Messages
There are no direct interactive errors for failed virtualized domain controller safe snapshot restore; all cloning
information logs in the Directory Services event logs. Naturally, any critical replication or server advertising errors
manifest themselves as symptoms elsewhere.
Known Issues and Support Scenarios
The General Methodology for Troubleshooting Domain Controller Safe Restore are usually adequate to
troubleshoot most issues.
Issue Cannot create new security principals on recently safe

restored domain controller
Symptoms After restoring a snapshot, attempts to create a new security
principal (user, computer, group) on that domain controller fail
with:
Error 0x2010
The directory service was unable to allocate a relative identifier.
Resolution and Notes This issue is caused by the restored computer's stale
knowledge of the RID Master FSMO role. If the role moved to
this or another domain controller after a snapshot was taken
and then later restored, the restored domain controller will not
have knowledge of the RID master until initial replication has
completed.
To resolve the issue, allow AD replication to complete inbound

to the restored domain controller. If still not working, validate
that all domain controllers have the same correct knowledge
of which DC hosts the RID Master.
Issue Restored domain controllers do not share SYSVOL,

advertise
Symptoms After restoring a snapshot, one or more DCs do not advertise,

do not share sysvol, and do not have up to date SYSVOL
contents
Resolution and Notes The DC's upstream partners do not have a working SYSVOL
replica that is correctly replicating with DFSR or FRS. This issue
is unrelated to safe restore but is likely to manifest as a safe
restore issue, because the customer was unaware of the other
replication issue affecting un-restored DCs
Advanced Troubleshooting
This module seeks to teach advanced troubleshooting by using working logs as samples, with some explanation of
what occurred. If you understand what a successful virtualized domain controller operation looks like, failures
become obvious in your environment. These logs are presented by their source, with the ascending order of
expected events related to a cloned domain controller within each log.
Restoring a Domain Controller that Replicates SYSVOL Using DFSR
The Directory Services log contains the majority of safe restore operational information. The hypervisor changes
the VM -Generation ID and the NTDS service notes it, then invalidates the RID pool and changes the invocation ID.
The new VM -Generation ID is set and the servers replicates AD data inbound. The DFSR service is stopped and its
database that hosts SYSVOL is deleted, forcing a non-authoritative sync inbound. The USN high watermark is
adjusted.

2170 ActiveDirectory_DomainService A Generation ID change has been
detected.
Generation ID cached in DS (old value):
Generation ID currently in VM (new

value):
The Generation ID change occurs after

the application of a virtual machine
operation or after a live migration
operation. Active Directory Domain
Services will create a new invocation ID
to recover the domain controller.
Domain Services aware backup
application."
2181 ActiveDirectory_DomainService The transaction was aborted due to the

virtual machine being reverted to a
previous state. This occurs after the
application of a virtual machine
operation, or after a live migration
operation.
2204 ActiveDirectory_DomainService Active Directory Domain Services has
detected a change of virtual machine
generation ID. The change means that
the virtual domain controller has been
reverted to a previous state. Active
Directory Domain Services will perform
the following operations to protect the
reverted domain controller against
possible data divergence and to protect
creation of security principals with
duplicate SIDs:
Create a new invocation ID
Invalidate current RID pool
Ownership of the FSMO roles will be

validated at next inbound replication.
During this window if the domain
controller held a FSMO role, that role
will be unavailable.
Start SYSVOL replication service restore

operation.
Start replication to bring the reverted

domain controller to the most current
state.
Request a new RID pool."
2181 ActiveDirectory_DomainService The transaction was aborted due to the

virtual machine being reverted to a
previous state. This occurs after the
application of a virtual machine
operation, or after a live migration
operation.
follows:

application."
2179 ActiveDirectory_DomainService The msDS-GenerationId attribute of the

Domain Controller's computer object
has been set to the following
parameter:
GenerationID attribute:
2200 ActiveDirectory_DomainService Active Directory detected that the

virtual machine that hosts the domain
controller was reverted to a previous
state. Active Directory Domain Services
initializes replication to bring the
domain controller current. Event 2201
will be logged when the replication is
finished.
2201 ActiveDirectory_DomainService Active Directory detected that the

has finished replication to bring the
domain controller current.
2185 ActiveDirectory_DomainService Active Directory Domain Services
stopped the FRS or DFSR service used
to replicate the SYSVOL folder.
Service name:
DFSR
Active Directory detected that the

must initialize a non-authoritative
restore on the local SYSVOL replica. This
is performed by stopping the FRS or
DFSR service used to replicate the
SYSVOL folder and starting it with the
appropriate registry keys and values to
trigger the restore. Event 2187 will be
logged when FRS or DFSR service is
restarted."

deleted DFSR databases to initialize
SYSVOL replica during a non-
authoritative restore.

needs to initialize a non-authoritative
restore on the local SYSVOL replica. For
DFSR, this is done by stopping the DFSR
service, deleting DFSR databases, and
re-starting the service. Upon restarting
DFSR will rebuild the databases and
start the initial sync. "

started the FRS or DFSR service used to
replicate the SYSVOL folder.
Service name:
DFSR

needed to initialize a non-authoritative
restore on the local SYSVOL replica. This
was done by stopping the FRS or DFSR
service used to replicate the SYSVOL
folder and starting it with the
appropriate registry keys and values to
trigger the restore. "
1587 ActiveDirectory_DomainService This directory service has been restored
or has been configured to host an
application directory partition. As a
result, its replication identity has
changed. A partner has requested
replication changes using our old
identity. The starting sequence number
has been adjusted.
The destination directory service

corresponding to the following object
GUID has requested changes starting at
a USN that precedes the USN at which
the local directory service was restored
from backup media.
Object GUID:
()
USN at the time of restore:
As a result, the up-to-dateness vector

of the destination directory service has
been configured with the following
settings.
Previous database GUID:
Previous object USN:
Previous property USN:
New database GUID:
New object USN:
New property USN:
Sy st e m Ev e n t L o g
The System event log notes that the machine time that occurs when bringing an offline virtual machine back online
and synchronizing with host time. The RID pool invalidates and the DFSR or FRS services are restarted.

1 Kernel-General The system time has changed to ? from
<snapshot time/date>.
Change Reason: An application or

system component changed the time.
16654 Directory-Services-SAM A pool of account-identifiers (RIDs) has

been invalidated. This may occur in the
following expected cases:
1. A domain controller is restored from

backup.
2. A domain controller running on a

virtual machine is restored from
snapshot.
3. An administrator has manually

invalidated the pool.
See https://go.microsoft.com/fwlink/?
LinkId=226247 for more information.
stopped state.
running state.
A p p l i c a t i o n Ev e n t L o g
The Application event log notes the DFSR database stopping and starting.
103 ESENT DFSRs (1360) \\.\C:\System Volume

Information\DFSR\database_\dfsr.db:
The database engine stopped the
instance (0).
Dirty Shutdown: 0

0.000, [3] 0.000, [4] 0.000, [5] 0.141, [6]
0.000, [7] 0.000, [8] 0.000, [9] 0.000,
[10] 0.000, [11] 0.016, [12] 0.000, [13]
0.000, [14] 0.000, [15] 0.000.

The database engine (6.02.8189.0000)
is starting a new instance (0).
The database engine started a new
instance (0). (Time=0 seconds)

0.000, [3] 0.000, [4] 0.000, [5] 0.000, [6]
0.000, [7] 0.000, [8] 0.000, [9] 0.031,
[10] 0.000, [11] 0.000.
DFSRs (532) \\.\C:\System Volume

The database engine created a new
database (1, \\.\C:\System Volume
Information\DFSR\database_\dfsr.db).
(Time=0 seconds)

0.000, [3] 0.016, [4] 0.062, [5] 0.000, [6]
0.016, [7] 0.000, [8] 0.000, [9] 0.015,
[10] 0.000, [11] 0.000.
D F S R e p l i c a t i o n Ev e n t L o g
The DFSR service is stopped and the database that contains SYSVOL is deleted, forcing a non-authoritative
synchronization inbound.
1006 DFSR The DFS Replication service is stopping.

stopped.
1002 DFSR The DFS Replication service is starting.
1004 DFSR The DFS Replication service has started.

configured the debug log files.
Debug Log File Path:

C:\Windows\debug

successfully registered the WMI
provider.

contacted domain controller to access
configuration information.
set up an RPC listener for incoming
replication requests.
Port: 0
4614 DFSR The DFS Replication service initialized

SYSVOL at local path
C:\Windows\SYSVOL\domain and is
waiting to perform initial replication. The
replicated folder will remain in the initial
synchronization state until it has
replicated with its partner. If the server
was in the process of being promoted
to a domain controller, the domain
controller will not advertise and function
as a domain controller until this issue is
resolved. This can occur if the specified
partner is also in the initial
synchronization state, or if sharing
violations are encountered on this
server or the synchronization partner. If
this event occurred during the
migration of SYSVOL from File
Replication Service (FRS) to DFS
Replication, changes will not replicate
out until this issue is resolved. This can
cause the SYSVOL folder on this server
to become out of sync with other
domain controllers.

System Volume
Member ID:
Read-Only: 0
initialized the SYSVOL replicated folder
at local path
C:\Windows\SYSVOL\domain. This
member has completed initial
synchronization of SYSVOL with partner
dc1.corp.contoso.com. To check for the
presence of the SYSVOL share, open a
command prompt window and then
type "net share".

System Volume
Member ID:
Sync partner:
Restoring a Domain Controller that Replicates SYSVOL Using FRS

The File Replication Event log is used instead of the DFSR event log in this case. The Application event log also
writes different FRS -related events. Otherwise, the Directory Services and System Event log messages are
generally the same and in the same order as previously described.
F i l e R e p l i c a t i o n Se r v i c e Ev e n t L o g
The FRS service is stopped and restarted with a D2 BURFLAGS value to non-authoritatively synchronize SYSVOL.
13502 NTFRS The File Replication Service is stopping.
13503 NTFRS The File Replication Service has stopped.
13501 NTFRS The File Replication Service is starting
13512 NTFRS The File Replication Service has detected

an enabled disk write cache on the drive
containing the directory
c:\windows\ntfrs\jet on the computer
DC4. The File Replication Service might
not recover when power to the drive is
interrupted and critical updates are lost.
13565 NTFRS File Replication Service is initializing the
SYSVOL.

net share

share will appear.

controllers."
13520 NTFRS The File Replication Service moved the

preexisting files in to
The File Replication Service may delete

the files in
\NtFrs_PreExisting___See_EventLog at
any time. Files can be saved from
deletion by copying them out of
Copying the files into may lead to name
conflicts if the files already exist on some
In some cases, the File Replication

Service may copy a file from
\NtFrs_PreExisting___See_EventLog into
instead of replicating the file from some
Space can be recovered at any time by

deleting the files in
13553 NTFRS The File Replication Service successfully
added this computer to the following
replica set:

SHARE)"
Information related to this event is

shown below:
Computer DNS name is ""
Replica set member name is ""
Replica set root path is ""
Replica staging directory path is " "
Replica working directory path is ""
13554 NTFRS The File Replication Service successfully

added the connections shown below to
the replica set:

SHARE)"
Inbound from ""
Outbound to ""
More information may appear in

subsequent event log messages.
13516 NTFRS The File Replication Service is no longer

preventing the computer DC4 from
becoming a domain controller. The
system volume has been successfully
initialized and the Netlogon service has
been notified that the system volume is
now ready to be shared as SYSVOL.
Type "net share" to check for the

SYSVOL share.
A p p l i c a t i o n Ev e n t L o g
The FRS database stops and starts, and is purged due to the D2 BURFLAGS operation.

327 ESENT ntfrs (1424) The database engine
detached a database (1,
c:\windows\ntfrs\jet\ntfrs.jdb). (Time=0
seconds)

0.015, [3] 0.000, [4] 0.000, [5] 0.000, [6]
0.516, [7] 0.000, [8] 0.000, [9] 0.000,
[10] 0.000, [11] 0.063, [12] 0.000.
Revived Cache: 0

stopped the instance (0).
Dirty Shutdown: 0

0.000, [3] 0.000, [4] 0.000, [5] 0.000, [6]
0.000, [7] 0.000, [8] 0.000, [9] 0.031,
[10] 0.000, [11] 0.016, [12] 0.000, [13]
0.000, [14] 0.047, [15] 0.000.

(6.02.8189.0000) is starting a new
instance (0).

started a new instance (0). (Time=0
seconds)

0.000, [3] 0.000, [4] 0.000, [5] 0.000, [6]
0.000, [7] 0.000, [8] 0.000, [9] 0.062,
[10] 0.000, [11] 0.141.

Dirty Shutdown: 0

0.000, [3] 0.000, [4] 0.000, [5] 0.000, [6]
0.000, [7] 0.000, [8] 0.000, [9] 0.000,
[10] 0.000, [11] 0.000, [12] 0.000, [13]
0.015, [14] 0.000, [15] 0.000.

instance (0).

seconds)

0.000, [3] 0.000, [4] 0.000, [5] 0.000, [6]
0.000, [7] 0.000, [8] 0.000, [9] 0.078,
[10] 0.000, [11] 0.109.
created a new database (1,
seconds)

0.000, [3] 0.016, [4] 0.016, [5] 0.000, [6]
0.015, [7] 0.000, [8] 0.000, [9] 0.078,
[10] 0.016, [11] 0.000.

Dirty Shutdown: 0

0.000, [3] 0.000, [4] 0.000, [5] 0.078, [6]
0.000, [7] 0.000, [8] 0.000, [9] 0.125,
[10] 0.016, [11] 0.000, [12] 0.000, [13]
0.000, [14] 0.000, [15] 0.000.

instance (0).

seconds)

0.000, [3] 0.000, [4] 0.094, [5] 0.000, [6]
0.000, [7] 0.000, [8] 0.000, [9] 0.032,
[10] 0.000, [11] 0.000.

attached a database (1,
seconds)

0.015, [3] 0.000, [4] 0.000, [5] 0.016, [6]
0.015, [7] 0.000, [8] 0.000, [9] 0.000,
[10] 0.000, [11] 0.000, [12] 0.000.
Saved Cache: 1
Virtualized Domain Controller Technical Reference
Appendix
This topic covers:

Terminology
FixVDCPermissions.ps1
Terminology
Snapshot - The state of a virtual machine at a particular point in time. It is dependent on the chain of
previous snapshots taken, on the hardware, and on the virtualization platform.
Clone - A complete and separate copy of a virtual machine. It is dependent on the virtual hardware
(hypervisor).
Full Clone - A full clone is an independent copy of a virtual machine that shares no resources with the
parent virtual machine after the cloning operation. Ongoing operation of a full clone is entirely separate
from the parent virtual machine.
Differencing disk - A copy of a virtual machine that shares virtual disks with the parent virtual machine in
an ongoing manner. This usually conserves disk space and allows multiple virtual machines to use the same
software installation.
VM Copy- A file system copy of all the related files and folders of a virtual machine.
VHD File Copy - A copy of a virtual machine's VHD
VM Generation ID - a 128-bit integer given to the virtual machine by the hypervisor. This ID is stored in
memory and reset every time a snapshot is applied. The design uses a hypervisor-agnostic mechanism for
surfacing the VM -Generation ID in the virtual machine. The Hyper-V implementation exposes the ID in the
ACPI table of the virtual machine.
Import/Export - A Hyper-V feature that allows the user to save the entire virtual machine (VM files, VHD
and the machine configuration). It then allows users to using that set of files to bring the machine back on
the same machine as the same VM (Restore), on a different machine as the same VM (Move), or a new VM
(copy)
FixVDCPermissions.ps1
# Unsigned script, requires use of set-executionpolicy remotesigned -force
# You must run the Windows PowerShell console as an elevated administrator
# Load Active Directory Windows PowerShell Module and switch to AD DS drive

cd ad:
## Get Domain NC
$domainNC = get-addomain
## Get groups and obtain their SIDs

$dcgroup = get-adgroup "Cloneable Domain Controllers"
$sid1 = (get-adgroup $dcgroup).sid
## Get the DACL of the domain

$acl = get-acl $domainNC
## The following object specific ACE grants extended right 'Allow a DC to create a clone of itself' for the CDC
group to the Domain NC
## 3e0f7e18-2c7a-4c10-ba82-4d926db99a3e is the schemaIDGuid for 'DS-Clone-Domain-Controller"
$objectguid = new-object Guid 3e0f7e18-2c7a-4c10-ba82-4d926db99a3e

$ace1 = new-object System.DirectoryServices.ActiveDirectoryAccessRule $sid1,"ExtendedRight","Allow",$objectguid
## Add the ACE in the ACL and set the ACL on the object
$acl.AddAccessRule($ace1)
set-acl -aclobject $acl $domainNC
write-host "Done writing new VDC permissions."
cd c:
Virtualized Domain Controller Additional Resources
AD DS Virtualization (Cloning and Virtualization safe improvements)

Active Directory Replication Model Technical Reference
Running Domain Controllers in Hyper-V (Windows Server 2008 R2 Behaviors)
USN and USN Rollback Protection (Windows Server 2008 R2)
Active Directory Administration with Windows PowerShell (Windows Server 2008 R2)
Hyper-V in Windows Server 2012
Ask the Directory Services Team (Official Microsoft Commercial Technical Support Blog)
Virtualized Domain Controller Cloning Test Guidance
for Application Vendors
This topic explains what application vendors should consider to help ensure their application continues to work as
expected after the virtualized domain controller (DC ) cloning process completes. It covers those aspects of the
cloning process that interest application vendors and scenarios that may warrant additional testing. Application
vendors who have validated that their application works on virtualized domain controllers that have been cloned
are encouraged to list the name of the application in the Community Content at the bottom of this topic, along with
a link to your organization's web site where users can learn more about the validation.
Overview of virtualized DC cloning

The virtualized domain controller cloning process is described in detail in Introduction to Active Directory Domain
Services (AD DS ) Virtualization (Level 100) and Virtualized Domain Controller Technical Reference (Level 300).
From an application vendor's perspective, these are some considerations to take into account when assessing the
impact of cloning to your application:
The original computer is not destroyed. It remains on the network, interacting with clients. Unlike a rename
where the DNS records of the original computer are removed, the original records for the source domain
controller remain.
During the cloning process, the new computer is initially running for a brief period of time under the identity
of the old computer until the cloning process is initiated and makes the necessary changes. Applications that
create records about the host should ensure that the cloned computer does not overwrite records about the
original host during the cloning process.
Cloning is a specific deployment capability for only virtualized domain controllers, not a general purpose
extension to clone other server roles. Some server roles are specifically not supported for cloning:
Dynamic Host Configuration Protocol (DHCP )
Active Directory Certificate Services (AD CS )
Active Directory Lightweight Directory Services (AD LDS )
As part of the cloning process, the entire VM that represents the original DC is copied, so any application
state on that VM is also copied. Validate that the application adapts to this change in state of the local host
on the cloned DC, or if any intervention is required, such as a service restart.
As part of cloning, the new DC gets a new machine identity and provisions itself as a replica DC in the
topology. Validate whether the application depends on the machine identity, such as its name, account, SID,
and so on. Does it automatically adapt to the change of machine identity on the clone? If that application
caches data, ensure that it does not rely on machine identity data that may be cached.
What is interesting for Application Vendors?

CustomDCCloneAllowList.xml
A domain controller that runs your application or service cannot be cloned until the application or service is either:
Added to the CustomDCCloneAllowList.xml file by using the Get-ADDCCloningExcludedApplicationList
Windows PowerShell cmdlet
-Or-
Removed from the domain controller
The first time the user runs the Get-ADDCCloningExcludedApplicationList cmdlet, it returns a list of services and
applications that are running on the domain controller but are not in the default list of services and applications
that are supported for cloning. By default, your service or application will not be listed. To add your service or
application to the list of applications and services that can be safely cloned, the user runs Get-
ADDCCloningExcludedApplicationList cmdlet again with the -GenerateXML option in order to add it to the
CustomDCCloneAllowList.xml file. For more information, see Step 2: Run Get-
ADDCCloningExcludedApplicationList cmdlet.
Distributed System Interactions
Usually services isolated to the local computer either pass or fail when participating in cloning. Distributed services
have to be concerned about having two instances of the host computer on the network simultaneously for a brief
period of time. This may manifest as a service instance trying to pull information from a partner system where the
clone has registered as the new vendor of the identity. Or both instances of the service may push information into
the AD DS database at the same time with different results. For example, it is not deterministic which computer will
be communicated with when two computers that have Windows Testing Technologies (WTT) service are on the
network with the domain controller.
For the distributed DNS Server service, the cloning process carefully avoids overwriting the DNS records of the
source domain controller when the clone domain controller starts with a new IP address.
You should not rely on the computer to remove all of the old identity until the end of cloning. After the new domain
controller is promoted inside the new context, select Sysprep providers are run to clean up the additional state of
the computer. For example, it is at this point the old certificates of the computer are removed and the cryptography
secrets that the computer can access are changed.
The greatest factor that varies the timing of the cloning is how many objects there are to replicate from the PDC.
Older media increases the time required to complete cloning.
Because your service or application is unknown, it is left running. The cloning process does not change the state of
non-Windows services.
Additionally, the new computer has a different IP address than the original computer. These behaviors may cause
side effects to your service or application depending on how the service or application behaves in this environment.
Additional scenarios suggested for testing

Cloning Failure
Service vendors should test this scenario because when cloning fails the computer boots into Directory Services
Repair Mode (DSRM ), a form of Safe Mode. At this point the computer has not completed cloning. Some state may
have changed and some state may remain from the original domain controller. Test this scenario to understand
what impact it can have on your application.
To induce a cloning failure, try to clone a domain controller without granting it permission to be cloned. In this case,
the computer will have only changed the IP addresses and still have the majority of its state from the original
domain controller. For more information about granting a domain controller permission to be cloned, see Step 1:
Grant the source virtualized domain controller the permission to be cloned.
PDC emulator cloning
Service and application vendors should test this scenario because there is an additional reboot when the PDC
emulator is cloned. In addition, the majority of cloning is performed under a temporary identity to allow the new
clone to interact with the PDC emulator during the cloning process.
Writable versus read-only domain controllers
Service and application vendors should test cloning by using the same type of domain controller (that is, on a
writable or read-only domain controller) that service is planned to run on.
Support for using Hyper-V Replica for virtualized
domain controllers
This topic explains the supportability of using Hyper-V Replica to replicate a virtual machine (VM ) that runs as a
domain controller (DC ). Hyper-V Replica is a new capability of Hyper-V beginning with Windows Server 2012 that
provides a built-in replication mechanism at a VM level.
Hyper-V Replica asynchronously replicates selected VMs from a primary Hyper-V host to a replica Hyper-V host
across either LAN or WAN links. After initial replication is complete, subsequent changes are replicated at an
interval defined by the administrator.
Failover can be either planned or unplanned. A planned failover is initiated by an administrator on the primary VM,
and any un-replicated changes are copied over to the replica VM to prevent any data loss. An unplanned failover is
initiated on the replica VM in response to an unexpected failure of the primary VM. Data loss is possible because
there is no opportunity to transmit changes on the primary VM that might not have been replicated yet.
For more information about Hyper-V Replica, see Hyper-V Replica Overview and Deploy Hyper-V Replica.
NOTE
Hyper-V Replica can be run only on Windows Server Hyper-V, not the version of Hyper-V that runs on Windows 8.
Windows Server 2012 or newer domain controllers required

Windows Server 2012 Hyper-V introduced VM -GenerationID (VMGenID ). VMGenID provides a way for the
hypervisor to communicate to the guest OS when significant changes have occurred. For example, the hypervisor
can communicate to a virtualized DC that a restore from snapshot has occurred (Hyper-V snapshot restore
technology, not backup restore). AD DS in Windows Server 2012 and newer is aware of VMGenID VM technology
and uses it to detect when hypervisor operations are performed, such as snapshot restore, which allows it to better
protect itself.
NOTE
Only AD DS on Windows Server 2012 DCs or newer provide these safety measures resulting from VMGenID; DCs that run all
previous releases of Windows Server are subject to problems such as USN rollback that can occur when a virtualized DC is
restored using an unsupported mechanism, such as snapshot restore. For more information about these safeguards and
when they are triggered, see Virtualized Domain Controller Architecture.
When a Hyper-V replica failover occurs (planned or unplanned), the virtualized DC detects a VMGenID reset,
triggering the aforementioned safety features. Active Directory operations then proceed as normal. The replica VM
runs in place of the primary VM.
NOTE
Given that now there are now two instances of the same DC identity, there is a potential for both the primary instance and
the replicated instance to run. While Hyper-V Replica has control mechanisms in place to ensure the primary and replica VMs
do not run simultaneously, it is possible for them to run at the same time in the event the link between them fails after
replication of the VM. In the event of this unlikely occurrence, virtualized DCs that run Windows Server 2012 have safeguards
to help protect AD DS, whereas virtualized DCs that run earlier versions of Windows Server do not.
When using Hyper-V Replica, ensure that you follow best practices for running virtual domain controllers on
Hyper-V. This discusses, for example, recommendations for storing Active Directory files on virtual SCSI disks,
which provides stronger guarantees of data durability.
Supported and unsupported scenarios

Only VMs that run Windows Server 2012 or newer are supported for unplanned failover and for testing failover.
Even for planned failover, Windows Server 2012 or newer is recommended for the virtualized DC in order to
mitigate risks in the event that an administrator inadvertently starts both the primary VM and the replicated VM at
the same time.
VMs that run earlier versions of Windows Server are supported for planned failover but unsupported for
unplanned failover because of the potential for USN rollback. For more information about USN rollback, see USN
and USN Rollback.
NOTE
There are no functional level requirements for the domain or forest; there are only operating system requirements for the DCs
that run as VMs that are replicated using Hyper-V Replica. The VMs can be deployed in a forest that contains other physical
or virtual DCs that run earlier versions of Windows Server and may or may not also be replicated using Hyper-V Replica.
This support statement is based on tests that were performed in a single domain-forest, though multi-domain
forest configurations are also supported. For these tests, virtualized domain controllers DC1 and DC2 are Active
Directory replication partners in the same site, hosted on a server that runs Hyper-V on Windows Server 2012. The
VM guest that runs DC2 has Hyper-V Replica enabled. The Replica server is hosted in another geographically
distant datacenter. To help explain the test case processes outlined below, the VM running on the replica server is
referred to as DC2-Rec (although in practice it retains the same name as the original VM ).
Windows Server 2012
The following table explains support for virtualized DCs that run Windows Server 2012 and test cases.
Planned Failover Unplanned Failover
Supported Supported
Test case: The test case is the same as for a planned failover, with these
exceptions:
- DC1 and DC2 are running Windows Server 2012.
- Any AD updates received on DC2 but not yet replicated by
- DC2 is shut down and a failover is performed on DC2-Rec. AD to a replication partner before the failover event will be
The failover can be either planned or unplanned. lost.
- After DC2-Rec starts, it checks whether the value of - AD updates received on DC2 after the time of the recovery
VMGenID that it has in its database is the same as the value point that were replicated by AD to DC1 will be replicated
from the virtual machine driver saved by the Hyper-V Replica from DC1 back to DC2-Rec.
server.
- As a result, DC2-Rec triggers virtualization safeguards; in

other words, it resets its InvocationID, discards its RID pool,
and sets an initial synchronization requirement before it will
assume an operations master role. For more information
about initial synchronization requirement, see .
- DC2-Rec then saves the new value of VMGenID in its

database and commits any subsequent updates in the context
of the new InvocationID.
- As a result of the InvocationID reset, DC1 will converge on all

AD changes introduced by DC2-Rec even if it was rolled back
in time, meaning any AD updates performed on DC2-Rec after
the failover will safely converge
Windows Server 2008 R2 and earlier versions

The following table explains support for virtualized DCs that run Windows Server 2008 R2 and earlier versions.
Planned Failover Unplanned Failover
Supported but not recommended because DCs that run these Not supported Note: Unplanned failover would be supported
versions of Windows Server do not support VMGenID or use where USN rollback is not a risk, such as a single DC in the
associated virtualization safeguards. This places them at risk forest (a configuration that is not recommended).
for USN rollback. For more information, see USN and USN
Rollback.
Test case: N/A
- DC1 and DC2 are running Windows Server 2008 R2.
- DC2 is shut down and a planned failover is performed on

DC2-Rec. All data on DC2 is replicated to DC2-Rec before the
shutdown is complete.
- After DC2-Rec starts, it resumes replication with DC1 using

the same invocationID as DC2.
Windows Time Service
Applies to: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows 10 or later
In this guide
Where to find Windows Time Service Configuration Information
What is the Windows Time Service?
Importance of Time Protocols
How the Windows Time Service Works
Windows Time Service Tools and Settings
NOTE
In Windows Server 2003 and Microsoft Windows 2000 Server, the directory service is named Active Directory directory
service. In Windows Server 2008 R2 and Windows Server 2008 , the directory service is named Active Directory Domain
Services (AD DS). The rest of this topic refers to AD DS, but the information is also applicable to Active Directory Domain
Services in Windows Server 2016.
The Windows Time service, also known as W32Time, synchronizes the date and time for all computers running in
an AD DS domain. Time synchronization is critical for the proper operation of many Windows services and line-of-
business applications. The Windows Time service uses the Network Time Protocol (NTP ) to synchronize computer
clocks on the network so that an accurate clock value, or time stamp, can be assigned to network validation and
resource access requests. The service integrates NTP and time providers, making it a reliable and scalable time
service for enterprise administrators.
IMPORTANT
Prior to Windows Server 2016, the W32Time service was not designed to meet time-sensitive application needs. However,
updates to Windows Server 2016 now allow you to implement a solution for 1ms accuracy in your domain. See Windows
2016 Accurate Time and Support boundary to configure the Windows Time service for high-accuracy environments for more
information.
Where to Find Windows Time Service Configuration Information

This guide does not discuss configuring the Windows Time service. There are several different topics on Microsoft
TechNet and in the Microsoft Knowledge Base that do explain procedures for configuring the Windows Time
service. If you require configuration information, the following topics should help you locate the appropriate
information.
To configure the Windows Time service for the forest root primary domain controller (PDC ) emulator, see:
Configure the Windows Time service on the PDC emulator in the Forest Root Domain
Configuring a time source for the forest
Microsoft Knowledge Base article 816042, How to configure an authoritative time server in Windows
Server, which describes configuration settings for computers running Windows Server 2008 R2,
Windows Server 2008, Windows Server 2003, and Windows Server 2003 R2.
To configure the Windows Time service on any domain member client or server, or even domain controllers
that are not configured as the forest root PDC emulator, see Configure a client computer for automatic
domain time synchronization.
WARNING
Some applications may require their computers to have high-accuracy time services. If that is the case, you may
choose to configure a manual time source, but be aware that the Windows Time service was not designed to function
as a highly accurate time source. Ensure that you are aware of the support limitations for high-accuracy time
environments as described in Microsoft Knowledge Base article 939322, Support boundary to configure the Windows
Time service for high-accuracy environments.
To configure the Windows Time service on any Windows-based client or server computers that are
configured as workgroup members instead of domain members see Configure a manual time source for a
selected client computer.
To configure the Windows Time service on a host computer that runs a virtual environment, see Microsoft
Knowledge Base article 816042, How to configure an authoritative time server in Windows Server. If you
are working with a non-Microsoft virtualization product, be sure to consult the documentation of the vendor
for that product.
To configure the Windows Time service on a domain controller that is running in a virtual machine, it is
recommended that you partially disable time synchronization between the host system and guest operating
system acting as a domain controller. This enables your guest domain controller to synchronize time for the
domain hierarchy, but protects it from having a time skew if it is restored from a Saved state. For more
information, see Microsoft Knowledge Base article 976924, You receive Windows Time Service event IDs 24,
29, and 38 on a virtualized domain controller that is running on a Windows Server 2008-based host server
with Hyper-V and Deployment Considerations for Virtualized Domain Controllers.
To configure the Windows Time service on a domain controller acting as the forest root PDC emulator that
is also running in a virtual computer, follow the same instructions for a physical computer as described in
Configure the Windows Time service on the PDC emulator in the Forest Root Domain.
To configure the Windows Time service on a member server running as a virtual computer, use the domain
time hierarchy as described in (Configure a client computer for automatic domain time synchronization.
What is the Windows Time Service?

The Windows Time service (W32Time) provides network clock synchronization for computers without the need for
extensive configuration.
The Windows Time service is essential to the successful operation of Kerberos version 5 authentication and,
therefore, to AD DS -based authentication. Any Kerberos-aware application, including most security services, relies
on time synchronization between the computers that are participating in the authentication request. AD DS domain
controllers must also have synchronized clocks to help to ensure accurate data replication.
The Windows Time service is implemented in a dynamic link library called W32Time.dll. W32Time.dll is installed
by default in the %Systemroot%\System32 folder during operating system setup and installation.
W32Time.dll was originally developed for Windows 2000 Server to support a specification by the Kerberos V5
authentication protocol that required clocks on a network to be synchronized. Starting with Windows Server 2003,
W32Time.dll provided increased accuracy in network clock synchronization over the Windows 2000 Server
operating system and, in addition, supported a variety of hardware devices and network time protocols by means
of time providers. Although originally designed to provide clock synchronization for Kerberos authentication, many
current applications use timestamps to ensure transactional consistency, to record the time of important events,
and other business-critical, time-sensitive information. These applications benefit from time synchronization
between computers that is provided by the Windows Time service.
Importance of Time Protocols

Time protocols communicate between two computers to exchange time information and then use that information
to synchronize their clocks. With the Windows Time service time protocol, a client requests time information from a
server and synchronizes its clock based on the information that is received.
The Windows Time service uses NTP to help synchronize time across a network. NTP is an Internet time protocol
that includes the discipline algorithms necessary for synchronizing clocks. NTP is a more accurate time protocol
than the Simple Network Time Protocol (SNTP ) that is used in some versions of Windows; however, W32Time
continues to support SNTP to enable backward compatibility with computers running SNTP -based time services
such as Windows 2000.
See Also
How the Windows Time Service Works
Windows Time Service Tools and Settings
Microsoft Knowledge Base article 902229
By deploying Windows Server Active Directory Domain Services (AD DS ) in your environment, you can take
advantage of the centralized, delegated administrative model and single sign-on (SSO ) capability that AD DS
provides. After you identify the deployment tasks and current environment for your organization, you can create
the AD DS deployment strategy that meets your organization's needs.
About this guide

This guide provides recommendations to help you develop an AD DS deployment strategy based on the
requirements of your organization and the particular design that you want to create. This guide is intended for use
by infrastructure specialists or system architects. Before you read this guide, you should have a good understanding
of how AD DS works on a functional level. You should also have a good understanding of the organizational
requirements that will be reflected in your AD DS deployment strategy.
This guide describes sets of tasks for several possible starting points of a Windows Server 2008 AD DS
deployment. The guide helps you determine the most appropriate deployment strategy for your environment.
Although the strategies that are presented in this guide are appropriate for almost all server operating system
deployments, they have been tested and validated specifically for environments that contain fewer than 100,000
users and fewer than 1,000 sites, with network connections of a minimum of 28.8 kilobits per second (Kbps). If your
environment does not meet these criteria, consider using a consulting firm that has experience deploying AD DS in
more complex environments.
For more information about testing the AD DS deployment process, see the article Testing and Verifying the
Deployment Process.
In this guide
Identifying Your AD DS Design and Deployment Requirements
Mapping Your Requirements to an AD DS Deployment Strategy
Designing the Logical Structure for Windows Server 2008 AD DS
Designing the Site Topology for Windows Server 2008 AD DS
Organizations can use Active Directory Domain Services (AD DS ) in Windows Server to simplify user and resource
management while creating scalable, secure, and manageable infrastructures. You can use AD DS to manage your
network infrastructure, including branch office, Microsoft Exchange Server, and multiple forest environments.
An AD DS deployment project involves three phases: a design phase, a deployment phase, and an operations
phase. During the design phase, the design team creates a design for the AD DS logical structure that best meets
the needs of each division in the organization that will use the directory service. After the design is approved, the
deployment team tests the design in a lab environment and then implements the design in the production
environment. Because testing is performed by the deployment team and it potentially affects the design phase, it is
an interim activity that overlaps both design and deployment. When the deployment is complete, the operations
team is responsible for maintaining the directory service.
Although the Windows Server AD DS design and deployment strategies that are presented in this guide are based
on extensive lab and pilot-program testing and successful implementation in customer environments, you might
have to customize your AD DS design and deployment to better suit specific, complex environments.
For more information about deploying AD DS in a branch office environment, see the Read-Only Domain
Controller (RODC ) Branch Office Planning Guide.
For more information about deploying AD DS in an Exchange environment, see the article Exchange 2007 -
Planning Active Directory.
For more information about deploying AD DS in a multiple forest environment, see the article Multiple Forest
Considerations in Windows 2000 and Windows Server 2003.
Identifying Your AD DS Design and Deployment
Requirements
Performing a high-level assessment of your current environment and correctly identifying your Active Directory
Domain Services (AD DS ) deployment tasks is essential for the success of your AD DS deployment strategy.
Your AD DS deployment strategy depends on your existing network configuration. For example, if your
organization currently runs Windows Server 2003, you can upgrade your operating system to Windows Server
2008. Your deployment process might involve restructuring existing domains, either within an Active Directory
forest or between Active Directory forests. You may have to restructure your existing domains after you deploy
Windows Server 2008 AD DS or after organizational changes or corporate acquisitions.
Designing the Active Directory logical structure

Before you deploy Windows Server 2008 Active Directory Domain Services (AD DS ), you must plan for and design
the AD DS logical structure for your environment. The AD DS logical structure determines how your directory
objects are organized, and it provides an effective method for managing your network accounts and shared
resources. When you design your AD DS logical structure, you define a significant part of the network
infrastructure of your organization.
To design the AD DS logical structure, determine the number of forests that your organization requires, and then
create designs for domains, Domain Name System (DNS ) infrastructure, and organizational units (OUs). The
following illustration shows the process for designing the logical structure.
For more information, see Designing the Logical Structure for Windows Server 2008 AD DS.
Designing the site topology

After you design the logical structure for your AD DS infrastructure, you must design the site topology for your
network. The site topology is a logical representation of your physical network. It contains information about the
location of AD DS sites, the AD DS domain controllers within each site, and the site links and site link bridges that
support AD DS replication between sites. The following illustration shows the site topology design process.
For more information, see Designing the Site Topology for Windows Server 2008 AD DS.
Planning domain controller capacity

To ensure efficient AD DS performance, you must determine the appropriate number of domain controllers for
each site and verify that they meet the hardware requirements for Windows Server 2008 . Careful capacity
planning for your domain controllers ensures that you do not underestimate hardware requirements, which can
cause poor domain controller performance and application response time. The following illustration shows the
process of domain controller capacity planning.
Enabling Windows Server 2008 advanced AD DS features

You can use Windows Server 2008 AD DS to introduce advanced features into your environment by raising the
domain or forest functional level. You can raise the functional level to Windows Server 2008 when all domain
controllers in the domain or forest are running Windows Server 2008 .
For more information, see Enabling Advanced Features for AD DS.
The structure of your existing environment determines your strategy for deploying Windows Server 2008 Active
Directory Domain Services (AD DS ). If you are creating an AD DS environment and you do not have an existing
domain structure, complete your AD DS design before you begin creating your AD DS environment. Then, you can
deploy a new forest root domain and deploy the rest of your domain structure according to your design.
Also, as part of your AD DS deployment, you might decide to upgrade and restructure your environment. For
example, if your organization has an existing Windows 2000 domain structure, you might perform an in-place
upgrade of some domains and restructure others. In addition, you might decide to reduce the complexity of your
environment by either restructuring domains between forests or restructuring domains within a forest after you
deploy AD DS.
Deploying a Windows Server 2008 forest root domain

The forest root domain provides the foundation for your AD DS forest infrastructure. To deploy AD DS, you must
first deploy a forest root domain. To do this, you must review your AD DS design; configure the DNS service for
the forest root domain; create the forest root domain, which consists of deploying forest root domain controllers,
configuring the site topology for the forest root domain, and configuring operations master roles (also known as
flexible single master operations or FSMO ); and raise the forest and domain functional levels. The following
illustration shows the overall process of deploying a forest root domain.
For more information, see Deploying a Windows Server 2008 Forest Root Domain.
Deploying Windows Server 2008 regional domains

After you complete the deployment of the forest root domain, you are ready to deploy any new Windows Server
2008 regional domains that are specified by your design. To do this, you must deploy domain controllers for each
regional domain. The following illustration shows the process of deploying regional domains.
For more information, see Deploying Windows Server 2008 Regional Domains.
Upgrading Active Directory domains to Windows Server 2008

Upgrading your Windows 2000 or Windows Server 2003 domains to Windows Server 2008 domains is an
efficient, straightforward way to take advantage of additional Windows Server 2008 features and functionality. You
can upgrade domains to maintain your current network and domain configuration while improving the security,
scalability, and manageability of your network infrastructure. Upgrading from Windows 2000 or Windows Server
2003 to Windows Server 2008 requires minimal network configuration. Upgrading also has little impact on user
operations. For more information, see Upgrading Active Directory Domains to Windows Server 2008 and
Windows Server 2008 R2 AD DS Domains.
Restructuring AD DS domains
When you restructure domains between Windows Server 2008 forests (interforest restructure), you can reduce the
number of domains in your environment and therefore reduce administrative complexity and overhead. When you
migrate objects between forests as part of this restructuring process, both the source domain and target domain
environments exist simultaneously. This makes it possible for you to roll back to the source environment during the
migration, if necessary.
When you restructure Windows Server 2008 domains within a Windows Server 2008 forest (intraforest
restructure), you can consolidate your domain structure and therefore reduce administrative complexity and
overhead. When you restructure domains within a forest, the migrated accounts no longer exist in the source
domain.
For more information about how to use the Active Directory Migration Tool (ADMT) version 3.1 (ADMT v3.1) to
restructure domains, see ADMT v3.1 Migration Guide.
Mapping Your Requirements to an AD DS
Deployment Strategy
After you finish reviewing and identifying the Active Directory Domain Services (AD DS ) design and deployment
requirements and you determine which of them are related to your specific deployment, you can map those
requirements to a specific AD DS deployment strategy.
Use the following table to determine which AD DS deployment strategy maps to the appropriate combination of
AD DS design and deployment requirements for your organization. ("Yes" means that a specific requirement is
necessary for your deployment strategy; "No" means that a specific requirement is not necessary for your
deployment strategy.)
This table refers only to the three primary AD DS deployment strategies as described in this guide:
Deploying AD DS in a Windows Server 2003 Organization
However, you can create a hybrid or custom AD DS deployment strategy by using any combination of the AD DS
design and deployment requirements to meet the needs of your organization.
DEPLOYING AD DS IN A DEPLOYING AD DS IN A
AD DS DESIGN AND DEPLOYING AD DS IN A NEW WINDOWS SERVER 2003 WINDOWS 2000
DEPLOYMENT REQUIREMENTS ORGANIZATION ORGANIZATION ORGANIZATION
Designing the Logical Yes Yes Yes

Structure for Windows
Server 2008 AD DS
Designing the Site Topology Yes Yes Yes

for Windows Server 2008 AD
DS
Planning Domain Controller Yes Yes Yes

Capacity
Deploying a Windows Server Yes No No

2008 Forest Root Domain
Deploying Windows Server Yes Yes Yes

2008 Regional Domains
DEPLOYING AD DS IN A DEPLOYING AD DS IN A
AD DS DESIGN AND DEPLOYING AD DS IN A NEW WINDOWS SERVER 2003 WINDOWS 2000
DEPLOYMENT REQUIREMENTS ORGANIZATION ORGANIZATION ORGANIZATION
Enabling Advanced Features Yes Yes, but all domain Yes, but all domain
for AD DS controllers in the controllers in the
environment must run environment must run
Windows Server 2008 before Windows Server 2008 before
you set the domain or forest you set the domain or forest
functional level to Windows functional level to Windows
Server 2008 . Server 2008 .
Upgrading Active Directory No Yes Yes

Domains to Windows Server
2008 and Windows Server
2008 R2 AD DS Domains
Restructuring AD DS Yes, if you want to migrate a Yes, if you want to merge Yes, if you want to merge
Domains Between Forests pilot domain into your with another organization with another organization
production environment, and consolidate the two IT and consolidate the two IT
merge with another infrastructures or consolidate infrastructures or consolidate
organization and consolidate resource and account resource and account
the two information domains that you upgraded domains that you upgraded
technology (IT) in place from Windows 2000 in place from Windows 2000
infrastructures, or or Windows Server 2003 or Windows Server 2003
consolidate resource and environments. environments.
account domains that you
upgraded in place from
Windows 2000 or Windows
Server 2003 environments.
Restructuring AD DS No Yes, if you need to reduce Yes, if you need to reduce

Domains Within Forests) the number of domains, the number of domains,
reduce replication traffic and reduce replication traffic and
the amount of required user the amount of required user
and group administration, or and group administration, or
simplify the administration of simplify the administration of
Group Policy. Group Policy.
Thoroughly preparing your Active Directory Domain Services (AD DS ) design is essential to a cost-effective
deployment. If your network environment is currently operating without a directory service, complete a
comprehensive design of your AD DS logical structure before you deploy AD DS. Then, you can deploy a new
forest root domain and deploy the rest of your domain structure according to your design.
The following illustration shows the steps for deploying Windows Server 2008 AD DS in a network environment
that is currently operating without a directory service.
For a list of detailed tasks that you can use to plan and deploy AD DS in a new organization, see Checklist:
Deploying AD DS in a New Organization.
Deploying AD DS in a Windows Server 2003
Organization
If your organization is currently running Windows Server 2003 Active Directory, you can deploy Windows Server
2008 Active Directory Domain Services (AD DS ) by either performing an in-place upgrade of some or all of your
domain controllers' operating systems to Windows Server 2008 or by introducing domain controllers running
Windows Server 2008 into your environment.
Before you can add a domain controller running Windows Server 2008 to an existing Windows Server 2003 Active
Directory domain, you must run adprep, a command-line tool. Adprep extends the AD DS schema, updates default
security descriptors of selected objects, and adds new directory objects as required by some applications. Adprep is
available on the Windows Server 2008 installation disk (\sources\adprep\adprep.exe). For more information, see
Adprep (https://go.microsoft.com/fwlink/?LinkId=99215).
The following illustration shows the steps for deploying Windows Server 2008 AD DS in a network environment
that is currently running Windows Server 2003 Active Directory.
NOTE
If you want to set the domain or forest functional level to Windows Server 2008 , all domain controllers in your environment
must run the Windows Server 2008 operating system.
Consolidating resource domains and account domains that are upgraded in place from a Windows Server 2003
environment as part of your Windows Server 2008 AD DS deployment may require interforest or intraforest
domain restructuring. Restructuring AD DS domains between forests helps you reduce the complexity of the
representation of your organization in AD DS, and it helps reduce the associated administrative costs. Restructuring
AD DS domains within a forest helps you decrease the administrative overhead for your organization by reducing
replication traffic, reducing the amount of user and group administration that is required, and simplifying the
administration of Group Policy. For more information, see ADMT v3.1 Migration Guide
(https://go.microsoft.com/fwlink/?LinkId=93678).
For a list of detailed tasks that you can use to plan and deploy AD DS in an organization that is running Windows
Server 2003 Active Directory, see Checklist: Deploying AD DS in a Windows Server 2003 Organization.
If your organization is currently running Windows 2000 Active Directory, you can deploy Windows Server 2008
Active Directory Domain Services (AD DS ) by either performing an in-place upgrade of some or all of your domain
controllers' operating systems to Windows Server 2008 or by introducing domain controllers running Windows
Server 2008 into your environment.
Before you can add a domain controller running Windows Server 2008 to an existing Windows 2000 Active
Directory domain, you must run adprep, a command-line tool. Adprep extends the AD DS schema, updates default
security descriptors of selected objects, and adds new directory objects as required by some applications. Adprep is
available on the Windows Server 2008 installation disk (\sources\adprep\adprep.exe). For more information, see
Adprep (https://go.microsoft.com/fwlink/?LinkId=99215).
NOTE
If you want to perform an in-place upgrade of an existing Windows 2000 AD DS domain controller to Windows Server 2008 ,
you must first upgrade the server to Windows Server 2003, and then upgrade it to Windows Server 2008 .
The following illustration shows the steps for deploying the Windows Server 2008 AD DS in a network
environment that is currently running Windows 2000 Active Directory.
NOTE
If you want to set the domain or forest functional level to Windows Server 2008 , all domain controllers in your environment
must run the Windows Server 2008 operating system.
Consolidating resource and account domains that are upgraded in place from a Windows 2000 environment as
part of your Windows Server 2008 AD DS deployment may require interforest or intraforest domain restructuring.
Restructuring AD DS domains between forests helps you reduce the complexity of your organization and the
associated administrative costs. Restructuring AD DS domains within a forest helps you to decrease the
administrative overhead for your organization by reducing replication traffic, reducing the amount of user and
group administration that is required, and simplifying the administration of Group Policy. For more information,
see ADMT v3.1 Migration Guide (https://go.microsoft.com/fwlink/?LinkId=93678).
For a list of detailed tasks that you can use to plan and deploy AD DS in an organization that is currently running
Windows 2000 Active Directory, see Checklist: Deploying AD DS in a Windows 2000 Organization.
Designing the Logical Structure
Active Directory Domain Services (AD DS ) enables organizations to create a scalable, secure, and manageable
infrastructure for user and resource management. It also enables them to support directory-enabled applications.
A well-designed Active Directory logical structure provides the following benefits:
Simplified management of Microsoft Windows-based networks that contain large numbers of objects
A consolidated domain structure and reduced administration costs
The ability to delegate administrative control over resources, as appropriate
Reduced impact on network bandwidth
Simplified resource sharing
Optimal search performance
Low total cost of ownership
A well-designed Active Directory logical structure facilitates the efficient integration of such features as Group
Policy; desktop lockdown; software distribution; and user, group, workstation, and server administration into your
system. In addition, a carefully designed logical structure facilitates the integration of Microsoft and non-Microsoft
applications and services, such as Microsoft Exchange Server, public key infrastructure (PKI), and a domain-based
distributed file system (DFS ).
When you design an Active Directory logical structure before you deploy AD DS, you can optimize your
deployment process to best take advantage of Active Directory features. To design the Active Directory logical
structure, your design team first identifies the requirements for your organization and, based on this information,
decides where to place the forest and domain boundaries. Then, the design team decides how to configure the
Domain Name System (DNS ) environment to meet the needs of the forest. Finally, the design team identifies the
organizational unit (OU ) structure that is required to delegate the management of resources in your organization.
In this guide
Understanding the Active Directory Logical Model
Understanding the Active Directory Logical Model
Designing your logical structure for Active Directory Domain Services (AD DS ) involves defining the relationships
between the containers in your directory. These relationships might be based on administrative requirements, such
as delegation of authority, or they might be defined by operational requirements, such as the need to control
replication.
Before you design your Active Directory logical structure, it is important to understand the Active Directory logical
model. AD DS is a distributed database that stores and manages information about network resources as well as
application-specific data from directory-enabled applications. AD DS allows administrators to organize elements of
a network (such as users, computers, and devices) into a hierarchical containment structure. The top-level container
is the forest. Within forests are domains, and within domains are organizational units (OUs). This is called the
logical model because it is independent of the physical aspects of the deployment, such as the number of domain
controllers required within each domain and network topology.
Active Directory forest

A forest is a collection of one or more Active Directory domains that share a common logical structure, directory
schema (class and attribute definitions), directory configuration (site and replication information), and global
catalog (forest-wide search capabilities). Domains in the same forest are automatically linked with two-way,
transitive trust relationships.
Active Directory domain

A domain is a partition in an Active Directory forest. Partitioning data enables organizations to replicate data only
to where it is needed. In this way, the directory can scale globally over a network that has limited available
bandwidth. In addition, the domain supports a number of other core functions related to administration, including:
Network-wide user identity. Domains allow user identities to be created once and referenced on any
computer joined to the forest in which the domain is located. Domain controllers that make up a domain are
used to store user accounts and user credentials (such as passwords or certificates) securely.
Authentication. Domain controllers provide authentication services for users and supply additional
authorization data such as user group memberships, which can be used to control access to resources on the
network.
Trust relationships. Domains can extend authentication services to users in domains outside their own forest
by means of trusts.
Replication. The domain defines a partition of the directory that contains sufficient data to provide domain
services and then replicates it between the domain controllers. In this way, all domain controllers are peers in
a domain and are managed as a unit.
Active Directory organizational units

OUs can be used to form a hierarchy of containers within a domain. OUs are used to group objects for
administrative purposes such as the application of Group Policy or delegation of authority. Control (over an OU
and the objects within it) is determined by the access control lists (ACLs) on the OU and on the objects in the OU.
To facilitate the management of large numbers of objects, AD DS supports the concept of delegation of authority.
By means of delegation, owners can transfer full or limited administrative control over objects to other users or
groups. Delegation is important because it helps to distribute the management of large numbers of objects across a
number of people who are trusted to perform management tasks.
The first step in establishing a deployment project for Active Directory Domain Service (AD DS ) is to establish the
design and deployment project teams that will be responsible for managing the design phase and deployment
phase of the Active Directory project cycle. In addition, you must identify the individuals and groups who will be
responsible for owning and maintaining the directory after the deployment is completed.
Defining project-specific roles
Establishing owners and administrators
Building project teams
Defining project-specific roles

An important step in establishing the project teams is to identify the individuals who are to hold project-specific
roles. These include the executive sponsor, the project architect, and the project manager. These individuals are
responsible for running the Active Directory deployment project.
After you appoint the project architect and project manager, these individuals establish channels of communication
throughout the organization, build project schedules, and identify the individuals who will be members of the
project teams, beginning with the various owners.
Executive sponsor
Deploying an infrastructure such as AD DS can have a wide-ranging impact on an organization. For this reason, it
is important to have an executive sponsor who understands the business value of the deployment, supports the
project at the executive level, and can help resolve conflicts across the organization.
Project architect
Each Active Directory deployment project requires a project architect to manage the Active Directory design and
deployment decision-making process. The architect provides technical expertise to assist with the process of
designing and deploying AD DS.
NOTE
If no existing personnel in your organization have directory design experience, you might want to hire an outside consultant
who is an expert in Active Directory design and deployment.
The responsibilities of the Active Directory project architect include the following:
Owning the Active Directory design
Understanding and recording the rationale for key design decisions
Ensuring that the design meets the business needs of the organization
Establishing consensus between design, deployment, and operations teams
Understanding the needs of AD DS -integrated applications
The final Active Directory design must reflect a combination of business goals and technical decisions. Therefore,
the project architect must review design decisions to ensure that they align with business goals.
Project manager
The project manager facilitates cooperation across business units and between technology management groups.
Ideally, the Active Directory deployment project manager is someone from within the organization who is familiar
with both the operational policies of the IT group and the design requirements for the groups that are preparing to
deploy AD DS. The project manager oversees the entire deployment project, beginning with design and continuing
through implementation, and makes sure that the project stays on schedule and within budget. The responsibilities
of the project manager include the following:
Providing basic project planning such as scheduling and budgeting
Driving progress on the Active Directory design and deployment project
Ensuring that the appropriate individuals are involved in each part of the design process
Serving as single point of contact for the Active Directory deployment project
Establishing communication between design, deployment, and operations teams
Establishing and maintaining communication with the executive sponsor throughout the deployment project
Establishing owners and administrators

In an Active Directory deployment project, individuals who are owners are held accountable by management to
make sure that deployment tasks are completed and that Active Directory design specifications meet the needs of
the organization. Owners do not necessarily have access to or manipulate the directory infrastructure directly.
Administrators are the individuals responsible for completing the required deployment tasks. Administrators have
the network access and permissions necessary to manipulate the directory and its infrastructure.
The role of the owner is strategic and managerial. Owners are responsible for communicating to administrators the
tasks required for the implementation of the Active Directory design such as the creation of new domain controllers
within the forest. The administrators are responsible for implementing the design on the network according to the
design specifications.
In large organizations, different individuals fill owner and administrator roles; however, in some small
organizations, the same individual might act as both the owner and the administrator.
Service and data owners
Managing AD DS on a daily basis involves two types of owners:
Service owners who are responsible for planning and long-term maintenance of the Active Directory
infrastructure and for ensuring that the directory continues to function and that the goals established in
service level agreements are maintained
Data owners who are responsible for the maintenance of the information stored in the directory. This
includes user and computer account management and management of local resources such as member
servers and workstations.
It is important to identify the Active Directory service and data owners early so that they can participate in as much
of the design process as possible. Because the service and data owners are responsible for the long-term
maintenance of the directory after the deployment project is finished, it is important for these individuals to provide
input regarding organizational needs and to be familiar with how and why certain design decisions are made.
Service owners include the forest owner, the Active Directory Domain Naming System (DNS ) owner, and the site
topology owner. Data owners include organizational unit (OU ) owners.
Service and data administrators
The operation of AD DS involves two types of administrators: service administrators and data administrators.
Service administrators implement policy decisions made by service owners and handle the day-to-day tasks
associated with maintaining the directory service and infrastructure. This includes managing the domain controllers
that are hosting the directory service, managing other network services such as DNS that are required for AD DS,
controlling the configuration of forest-wide settings, and ensuring that the directory is always available.
Service administrators are also responsible for completing ongoing Active Directory deployment tasks that are
required after the initial Windows Server 2008 Active Directory deployment process is complete. For example, as
demands on the directory increase, service administrators create additional domain controllers and establish or
remove trusts between domains, as needed. For this reason, the Active Directory deployment team needs to include
service administrators.
You must be careful to assign service administrator roles only to trusted individuals in the organization. Because
these individuals have the ability to modify the system files on domain controllers, they can change the behavior of
AD DS. You must ensure that the service administrators in your organization are individuals who are familiar with
the operational and security policies that are in place on your network and who understand the need to enforce
those policies.
Data administrators are users within a domain who are responsible both for maintaining data that is stored in AD
DS such as user and group accounts and for maintaining computers that are members of their domain. Data
administrators control subsets of objects within the directory and have no control over the installation or
configuration of the directory service.
Data administrator accounts are not provided by default. After the design team determines how resources are to be
managed for the organization, domain owners must create data administrator accounts and delegate them the
appropriate permissions based on the set of objects for which the administrators are to be responsible.
It is best to limit the number of service administrators in your organization to the minimum number required to
ensure that the infrastructure continues to function. The majority of administrative work can be completed by data
administrators. Service administrators require a much wider skill set because they are responsible for maintaining
the directory and the infrastructure that supports it. Data administrators only require the skills necessary to
manage their portion of the directory. Dividing work assignments in this way results in cost savings for the
organization because only a small number of administrators need to be trained to operate and maintain the entire
directory and its infrastructure.
For example, a service administrator needs to understand how to add a domain to a forest. This includes how to
install the software to convert a server into a domain controller and how to manipulate the DNS environment so
that the domain controller can be merged seamlessly into the Active Directory environment. A data administrator
only needs to know how to manage the specific data that they are responsible for such as the creation of new user
accounts for new employees in their department.
Deploying AD DS requires coordination and communication between many different groups involved in the
operation of the network infrastructure. These groups should appoint service and data owners who are responsible
for representing the various groups during the design and deployment process.
Once the deployment project is complete, these service and data owners continue to be responsible for the portion
of the infrastructure managed by their group. In an Active Directory environment, these owners are the forest
owner, the DNS for AD DS owner, the site topology owner, and the OU owner. The roles of these service and data
owners are explained in the following sections.
Forest owner
The forest owner is typically a senior information technology (IT) manager in the organization who is responsible
for the Active Directory deployment process and who is ultimately accountable for maintaining service delivery
within the forest after the deployment is complete. The forest owner assigns individuals to fill the other ownership
roles by identifying key personnel within the organization who are able to contribute necessary information about
network infrastructure and administrative needs. The forest owner is responsible for the following:
Deployment of the forest root domain to create the forest
Deployment of the first domain controller in each domain to create the domains required for the forest
Memberships of the service administrator groups in all domains of the forest
Creation of the design of the OU structure for each domain in the forest
Delegation of administrative authority to OU owners
Changes to the schema
Changes to forest-wide configuration settings
Implementation of certain Group Policy policy settings, including domain user account policies such as fine-
grained password and account lockout policy
Business policy settings that apply to domain controllers
Any other Group Policy settings that are applied at the domain level
The forest owner has authority over the entire forest. It is the forest owner's responsibility to set Group Policy and
business policies and to select the individuals who are service administrators. The forest owner is a service owner.
DNS for AD DS owner
The DNS for AD DS owner is an individual who has a thorough understanding of the existing DNS infrastructure
and the existing namespace of the organization.
The DNS for AD DS owner is responsible for the following:
Serving as a liaison between the design team and the IT group that currently owns the DNS infrastructure
Providing the information about the existing DNS namespace of the organization to assist in the creation of
the new Active Directory namespace
Working with the deployment team to make sure that the new DNS infrastructure is deployed according to
the specifications of the design team and that it is working properly
Managing the DNS for AD DS infrastructure, including the DNS Server service and DNS data
The DNS for AD DS owner is a service owner.
Site topology owner
The site topology owner is familiar with the physical structure of the organization network, including mapping of
individual subnets, routers, and network areas that are connected by means of slow links. The site topology owner
is responsible for the following:
Understanding the physical network topology and how it affects AD DS
Understanding how the Active Directory deployment will impact the network
Determining the Active Directory logical sites that need to be created
Updating site objects for domain controllers when a subnet is added, modified, or removed
Creating site links, site link bridges, and manual connection objects
The site topology owner is a service owner.
OU owner
The OU owner is responsible for managing data stored in the directory. This individual needs to be familiar with
the operational and security policies that are in place on the network. OU owners can perform only those tasks that
have been delegated to them by the service administrators, and they can perform only those tasks on the OUs to
which they are assigned. Tasks that might be assigned to the OU owner include the following:
Performing all account management tasks within their assigned OU
Managing workstations and member servers that are members of their assigned OU
Delegating authority to local administrators within their assigned OU
The OU owner is a data owner.
Building project teams

Active Directory project teams are temporary groups that are responsible for completing Active Directory design
and deployment tasks. When the Active Directory deployment project is complete, the owners assume
responsibility for the directory, and the project teams can disband.
The size of the project teams varies according to the size of the organization. In small organizations, a single person
can cover multiple areas of responsibility on a project team and be involved in more than one phase of the
deployment. Large organizations might require larger teams with different individuals or even different teams
covering the different areas of responsibility. The size of the teams is not important as long as all areas of
responsibility are assigned, and the design goals of the organization are met.
Identifying potential forest owners
Identify the groups within your organization that own and control the resources necessary to provide directory
services to users on the network. These groups are considered potential forest owners.
The separation of service and data administration in AD DS makes it possible for the infrastructure IT group (or
groups) of an organization to manage the directory service while local administrators in each group manage the
data that belongs to their own groups. Potential forest owners have the required authority over the network
infrastructure to deploy and support AD DS.
For organizations that have one centralized infrastructure IT group, the IT group is generally the forest owner and,
therefore, the potential forest owner for any future deployments. Organizations that include a number of
independent infrastructure IT groups have a number of potential forest owners. If your organization already has an
Active Directory infrastructure in place, any current forest owners are also potential forest owners for new
deployments.
Select one of the potential forest owners to act as the forest owner for each forest that you are considering for
deployment. These potential forest owners are responsible for working with the design team to determine whether
or not their forest will actually be deployed or if an alternate course of action (such as joining another existing
forest) is a better use of the available resources and still meets their needs. The forest owner (or owners) in your
organization are members of the Active Directory design team.
Establishing a design team
The Active Directory design team is responsible for gathering all the information needed to make decisions about
the Active Directory logical structure design.
The responsibilities of the design team include the following:
Determining how many forests and domains are required and what the relationships are between the forests
and domains
Working with data owners to ensure that the design meets their security and administrative requirements
Working with the current network administrators to ensure that the current network infrastructure supports
the design and that the design will not adversely affect existing applications deployed on the network
Working with representatives of the security group of the organization to ensure that the design meets
established security policies
Designing OU structures that permit appropriate levels of protection and the proper delegation of authority
to the data owners
Working with the deployment team to test the design in a lab environment to ensure that it functions as
planned and modifying the design as needed to address any problems that occur
Creating a site topology design that meets the replication requirements of the forest while preventing
overload of available bandwidth. For more information about designing the site topology, see Designing the
Site Topology for Windows Server 2008 AD DS.
Working with the deployment team to ensure that the design is implemented correctly
The design team includes the following members:
Potential forest owners
Project architect
Project manager
Individuals who are responsible for establishing and maintaining security policies on the network
During the logical structure design process, the design team identifies the other owners. These individuals must
start participating in the design process as soon as they are identified. After the deployment project is handed off to
the deployment team, the design team is responsible for overseeing the deployment process to ensure that the
design is implemented correctly. The design team also makes changes to the design based on feedback from
testing.
Establishing a deployment team
The Active Directory deployment team is responsible for testing and implementing the Active Directory logical
structure design. This involves the following tasks:
Establishing a test environment that sufficiently emulates the production environment
Testing the design by implementing the proposed forest and domain structure in a lab environment to verify
that it meets the goals of each role owner
Developing and testing any migration scenarios proposed by the design in a lab environment
Making sure that each owner signs off on the testing process to ensure that the correct design features are
being tested
Testing the deployment operation in a pilot environment
When the design and testing tasks are complete, the deployment team performs the following tasks:
Creates the forests and domains according to the Active Directory logical structure design
Creates the sites and site link objects as needed based on the site topology design
Ensures that the DNS infrastructure is configured to support AD DS and that any new namespaces are
integrated into the existing namespace of the organization
The Active Directory deployment team includes the following members:
Forest owner
DNS for AD DS owner
Site topology owner
OU owners
The deployment team works with the service and data administrators during the deployment phase to ensure that
members of the operations team are familiar with the new design. This helps to ensure a smooth transition of
ownership when the deployment operation is completed. At the completion of the deployment process, the
responsibility for maintaining the new Active Directory environment passes to the operations team.
Documenting the design and deployment teams
Document the names and contact information for the people who will participate in the design and deployment of
AD DS. Identify who will be responsible for each role on the design and deployment teams. Initially, this list
includes the potential forest owners, the project manager, and the project architect. When you determine the
number of forests that you will deploy, you might need to create new design teams for additional forests. Note that
you will need to update your documentation as team memberships change and as you identify the various Active
Directory owners during the design process. For a worksheet to assist you in documenting the design and
deployment teams for each forest, download
Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip from Job Aids for Windows Server 2003
Deployment Kit (https://go.microsoft.com/fwlink/?LinkID=102558) and open "Design and Deployment Team
Information" (DSSLOGI_1.doc).
Creating a forest design involves first identifying the groups within your organization that have the resources
available to host an Active Directory forest and then defining your forest design requirements. Finally, you need to
determine the number of forests that you require to meet the needs of your organization.
After you map all your design requirements to forest models and select the forest model that meets the needs of
your organization, document the proposed forest design. Include in your documentation the name of the group for
which the forest is designed, the contact information for the forest owner, the type of forest for each forest that you
include, and the requirements that each forest is designed to meet. This documentation will help the design team
both to ensure that all the appropriate people are involved in the design process and to clarify the scope of the
deployment project.
For a worksheet to assist you in documenting the proposed forest design, download
Deployment Kit and open "Forest Design" (DSSLOGI_3.doc).
In this section
To create a forest design for your organization, you must identify the business requirements that your directory
structure needs to accommodate. This involves determining how much autonomy the groups in your organization
need to manage their network resources and whether or not each group needs to isolate their resources on the
network from other groups.
Active Directory Domain Services (AD DS ) enables you to design a directory infrastructure that accommodates
multiple groups within an organization that have unique management requirements and to achieve structural and
operational independence between groups as needed.
Groups in your organization might have some of the following types of requirements:
Organizational structure requirements. Parts of an organization might participate in a shared
infrastructure to save costs but require the ability to operate independently from the rest of the organization.
For example, a research group within a large organization might need to maintain control over all of their
own research data.
Operational requirements. One part of an organization might place unique constraints on the directory
service configuration, availability, or security, or use applications that place unique constraints on the
directory. For example, individual business units within an organization might deploy directory-enabled
applications that modify the directory schema that are not deployed by other business units. Because the
directory schema is shared between all the domains in the forest, creating multiple forests is one solution for
such a scenario. Other examples are found in the following organizations and scenarios:
Military organizations
Hosting scenarios
Organizations that maintain a directory that is available both internally and externally (such as those
that are publicly accessible by users on the Internet)
Legal requirements. Some organizations have legal requirements to operate in a specific way, for example,
restricting access to certain information as specified in a business contract. Some organizations have security
requirements to operate on isolated internal networks. Failure to meet these requirements can result in loss
of the contract and possibly legal action.
Part of identifying your forest design requirements involves identifying the degree to which groups in your
organization can trust the potential forest owners and their service administrators and identifying the autonomy
and isolation requirements for each group in your organization.
The design team must document the isolation and autonomy requirements for service and data administration for
each group in the organization that intends to use AD DS. The team must also note any areas of limited
connectivity that might affect the deployment of AD DS.
The design team must document the isolation and autonomy requirements for service and data administration for
each group in the organization that intends to use AD DS. The team must also note any areas of limited
connectivity that might affect the deployment of AD DS. For a worksheet to assist you in documenting the regions
you identified, download Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip from Job Aids
for Windows Server 2003 Deployment Kit and open "Forest Design Requirements" (DSSLOGI_2.doc).
In this section
Service Administrator Scope of Authority
Autonomy vs. Isolation
Service Administrator Scope of Authority
If you choose to participate in an Active Directory forest, you must trust the forest owner and the service
administrators. The forest owners are responsible for selecting and managing the service administrators; therefore,
when you trust a forest owner, you also trust the service administrators that the forest owner manages. These
service administrators have access to all of the resources in the forest. Before making the decision to participate in
a forest, it is important to understand that the forest owner and the service administrators will have full access to
your data. You cannot prevent this access.
All service administrators in a forest have full control over all data and services on all computers in the forest.
Service administrators have the capability to do the following:
Correct errors on access control lists (ACLs) of objects. This enables the service administrator to read,
modify, or delete objects regardless of the ACLs that are set on those objects.
Modify the system software on a domain controller to bypass normal security checks. This enables the
service administrator to view or manipulate any object in the domain, regardless of the ACL on the object.
Use the Restricted Groups security policy to grant to any user or group administrative access to any
computer joined to the domain. In this way, service administrators can obtain control of any computer joined
to the domain regardless of the intentions of the computer owner.
Reset passwords or change group memberships for users.
Gain access to other domains in the forest by modifying the system software on a domain controller. Service
administrators can affect the operation of any domain in the forest, view or manipulate forest configuration
data, view or manipulate data stored in any domain, and view or manipulate data stored on any computer
joined to the forest.
For this reason, groups that store data in organizational units (OUs) in the forest and that join computers to a forest
must trust the service administrators. For a group to join a forest, it must choose to trust all service administrators
in the forest. This involves ensuring that:
The forest owner can be trusted to act in the interests of the group and does not have reason to act
maliciously against the group.
The forest owner appropriately restricts physical access to domain controllers. Domain controllers within a
forest cannot be isolated from one another. It is possible for an attacker who has physical access to a single
domain controller to make offline changes to the directory database and, by doing so, interfere with the
operation of any domain in the forest, view or manipulate data stored anywhere in the forest, and view or
manipulate data stored on any computer joined to the forest. For this reason, physical access to domain
controllers must be restricted to trusted personnel.
You understand and accept the potential risk that trusted service administrators can be coerced into
compromising the security of the system.
Some groups might determine that the collaborative and cost-saving benefits of participating in a shared
infrastructure outweigh the risks that service administrators will misuse or will be coerced into misusing their
authority. These groups can share a forest and use OUs to delegate authority. However, other groups might not
accept this risk because the consequences of a compromise in security are too severe. These groups require
separate forests.
Autonomy vs. Isolation
You can design your Active Directory logical structure to achieve either of the following:
Autonomy. Involves independent but not exclusive control of a resource. When you achieve autonomy,
administrators have the authority to manage resources independently; however, administrators with greater
authority exist who also have control over those resources and can take control away if necessary. You can
design your Active Directory logical structure to achieve the following types of autonomy:
Service autonomy. This type of autonomy involves control over all or part of service management.
Data autonomy. This type of autonomy involves control over all or part of the data stored in the
directory or on member computers joined to the directory.
Isolation. Involves independent and exclusive control of a resource. When you achieve isolation,
administrators have the authority to manage a resource independently, and no other administrator can take
away control of the resource. You can design your Active Directory logical structure to achieve the following
types of isolation:
Service isolation. Prevents administrators (other than those administrators who are specifically
designated to control service management) from controlling or interfering with service management.
Data isolation. Prevents administrators (other than those administrators who are specifically
designated to control or view data) from controlling or viewing a subset of data in the directory or on
member computers joined to the directory.
Administrators who require only autonomy accept that other administrators who have equal or greater
administrative authority have equal or greater control over service or data management. Administrators who
require isolation have exclusive control over service or data management. Creating a design to achieve autonomy is
generally less expensive than creating a design to achieve isolation.
In Active Directory Domain Services (AD DS ), administrators can delegate both service administration and data
administration to achieve either autonomy or isolation between organizations. The combination of service
management, data management, autonomy, and isolation requirements of an organization impact the Active
Directory containers that are used to delegate administration.
Isolation and autonomy requirements

The number of forests that you need to deploy is based on the autonomy and isolation requirements of each group
within your organization. To identify your forest design requirements, you must identify the autonomy and isolation
requirements for all groups in your organization. Specifically, you must identify the need for data isolation, data
autonomy, service isolation, and service autonomy. You must also identify areas of limited connectivity in your
organization.
Data isolation
Data isolation involves exclusive control over data by the group or organization that owns the data. It is important
to note that service administrators have the ability to take control of a resource away from data administrators. And
data administrators do not have the ability to prevent service administrators from accessing the resources that they
control. Therefore, you cannot achieve data isolation when another group within the organization is responsible for
service administration. If a group requires data isolation, that group must also assume responsibility for service
administration.
Because data stored in AD DS and on computers joined to AD DS cannot be isolated from service administrators,
the only way for a group within an organization to achieve complete data isolation is to create a separate forest for
that data. Organizations for which the consequences of an attack by malicious software or by a coerced service
administrator are substantial might choose to create a separate forest to achieve data isolation. Legal requirements
typically create a need for this type of data isolation. For example:
A financial institution is required by law to limit access to data that belongs to clients in a particular
jurisdiction to users, computers, and administrators located in that jurisdiction. Although the institution
trusts service administrators that work outside the protected area, if the access limitation is violated, the
institution will no longer be able to do business in that jurisdiction. Therefore, the financial institution must
isolate data from service administrators outside that jurisdiction. Note that encryption is not always an
alternative to this solution. Encryption might not protect data from service administrators.
A defense contractor is required by law to limit access to project data to a specified set of users. Although the
contractor trusts service administrators who control computer systems related to other projects, a violation
of this access limitation will cause the contractor to lose business.
NOTE
If you have a data isolation requirement, you must decide if you need to isolate your data from service administrators
or from data administrators and ordinary users. If your isolation requirement is based on isolation from data
administrators and ordinary users, you can use access control lists (ACLs) to isolate the data. For the purposes of this
design process, isolation from data administrators and ordinary users is not considered a data isolation requirement.
Data autonomy
Data autonomy involves the ability of a group or organization to manage its own data, including making
administrative decisions about the data and performing any required administrative tasks without the need for
approval from another authority.
Data autonomy does not prevent service administrators in the forest from accessing the data. For example, a
research group within a large organization might want to be able to manage their project-specific data themselves
but not need to secure the data from other administrators in the forest.
Service isolation
Service isolation involves exclusive control of the Active Directory infrastructure. Groups that require service
isolation require that no administrator outside of the group can interfere with the operation of the directory service.
Operational or legal requirements typically create a need for service isolation. For example:
A manufacturing company has a critical application that controls equipment on the factory floor.
Interruptions in the service on other parts of the network of the organization cannot be allowed to interfere
with the operation of the factory floor.
A hosting company provides service to multiple clients. Each client requires service isolation so that any
service interruption that affects one client does not affect the other clients.
Service autonomy
Service autonomy involves the ability to manage the infrastructure without a requirement for exclusive control; for
example, when a group wants to make changes to the infrastructure (such as adding or removing domains,
modifying the Domain Name System (DNS ) namespace, or modifying the schema) without the approval of the
forest owner.
Service autonomy might be required within an organization for a group that wants to be able to control the service
level of AD DS (by adding and removing domain controllers, as needed) or for a group that needs to be able to
install directory-enabled applications that require schema extensions.
Limited connectivity
If a group within your organization owns networks that are separated by devices that restrict or limit connectivity
between networks (such as firewalls and Network Address Translation (NAT) devices), this can impact your forest
design. When you identify your forest design requirements, be sure to note the locations where you have limited
network connectivity. This information is required to enable you to make decisions regarding the forest design.
To determine the number of forests that you must deploy, you need to carefully identify and evaluate the isolation
and autonomy requirements for each group in your organization and map those requirements to the appropriate
forest design models.
When determining the number of forests to deploy for your organization, consider the following:
Isolation requirements limit your design choices. Therefore, if you identify isolation requirements, make sure
that the groups actually require data isolation and that data autonomy is not sufficient for their needs.
Ensure that the various groups in your organization clearly understand the concepts of isolation and
autonomy.
Negotiating the design can be a lengthy process. It can be difficult for groups to come to an agreement
about ownership and uses for available resources. Make sure that you allow enough time for the groups in
your organization to conduct adequate research to identify their needs. Set firm deadlines for design
decisions and get consensus from all parties on the established deadlines.
Determining the number of forests to deploy involves balancing costs against benefits. A single-forest model
is the most cost-effective option and requires the least amount of administrative overhead. Although a group
in the organization might prefer autonomous service operations, it might be more cost-effective for the
organization to subscribe to service delivery from a centralized and trusted information technology (IT)
group. This allows the group to own data management without creating the added costs of service
management. Balancing costs against benefits might require input from the executive sponsor.
A single forest is the easiest configuration to manage. It allows for maximum collaboration within the
environment because:
All objects in a single forest are listed in the global catalog. Therefore, no synchronization across
forests is required.
Management of a duplicate infrastructure is not required.
We do not recommend co-ownership of a single forest by two separate and autonomous IT organizations. In
the future, the goals of the two IT groups might change, so that they can no longer accept shared control.
We do not recommend outsourcing service administration to more than one outside partner. Multinational
organizations that have groups in different countries or regions might choose to outsource service
administration to a different outside partner for each country or region. Because multiple outside partners
cannot be isolated from one another, the actions of one partner can affect the service of the other, which
makes it difficult to hold the partners accountable to their service level agreements.
Only one instance of an Active Directory domain should exist at any time. Microsoft does not support
cloning, splitting, or copying domain controllers from one domain in an attempt to establish a second
instance of the same domain. For more information about this limitation, see the following section.
Restructuring limitations
When a company acquires another company, business unit, or product line, the purchasing company might also
want to acquire corresponding IT assets from the seller. Specifically, the buyer might want to acquire some or all of
the domain controllers that host the user accounts, computer accounts, and security groups that correspond to the
business assets that are to be acquired. The only supported methods for the buyer to acquire the IT assets that are
stored in the seller's Active Directory forest are as follows:
1. Acquire the only instance of the forest, including all domain controllers and directory data in the seller's
entire forest.
2. Migrate the needed directory data from the seller's forest or domains to one or more of the buyer's domains.
The target for such a migration might be an entirely new forest or one or more existing domains that are
already deployed in the buyer's forest.
This support limitation exists because:
Each domain in an Active Directory forest is assigned a unique identity during the creation of the forest.
Copying domain controllers from an original domain to a cloned domain compromises the security of both
the domains and the forest. Threats to the original domain and the cloned domain include the following:
Sharing of passwords that can be used to gain access to resources
Insight regarding privileged user accounts and groups
Mapping of IP addresses to computer names
Additions, deletions, and modifications of directory information if domain controllers in a cloned
domain ever establish network connectivity with domain controllers from the original domain
Cloned domains share a common security identity; therefore, trust relationships cannot be established
between them, even if one or both of the domains have been renamed.
In this section
Forest Design Models
Mapping Design Requirements to Forest Design Models
Using the Organizational Domain Forest Model
Forest Design Models
You can apply one of the following three forest design models in your Active Directory environment:
Organizational forest model
Resource forest model
Restricted access forest model
It is likely that you will need to use a combination of these models to meet the needs of all the different groups in
your organization.
Organizational forest model

In the organizational forest model, user accounts and resources are contained in the forest and managed
independently. The organizational forest can be used to provide service autonomy, service isolation, or data
isolation, if the forest is configured to prevent access to anyone outside the forest.
If users in an organizational forest need to access resources in other forests (or the reverse), trust relationships can
be established between one organizational forest and the other forests. This makes it possible for administrators to
grant access to resources in the other forest. The following illustration shows the organizational forest model.
Every Active Directory design includes at least one organizational forest.
Resource forest model

In the resource forest model, a separate forest is used to manage resources. Resource forests do not contain user
accounts other than those required for service administration and those required to provide alternate access to the
resources in that forest, if the user accounts in the organizational forest become unavailable. Forest trusts are
established so that users from other forests can access the resources contained in the resource forest. The following
illustration shows the resource forest model.
Resource forests provide service isolation that is used to protect areas of the network that need to maintain a state
of high availability. For example, if your company includes a manufacturing facility that needs to continue to
operate when there are problems on the rest of the network, you can create a separate resource forest for the
manufacturing group.
Restricted access forest model

In the restricted access forest model, a separate forest is created to contain user accounts and data that must be
isolated from the rest of the organization. Restricted access forests provide data isolation in situations where the
consequences of compromising project data are severe. The following illustration shows a restricted access forest
model.
Users from other forests cannot be granted access to the restricted data because no trust exists. In this model, users
have an account in an organizational forest for access to general organizational resources and a separate user
account in the restricted access forest for access to the classified data. These users must have two separate
workstations, one connected to the organizational forest and the other connected to the restricted access forest.
This protects against the possibility that a service administrator from one forest can gain access to a workstation in
the restricted forest.
In extreme cases, the restricted access forest might be maintained on a separate physical network. Organizations
that work on classified government projects sometimes maintain restricted access forests on separate networks to
meet security requirements.
Mapping Design Requirements to Forest Design
Models
Most groups in your organization can share a single organizational forest that is managed by a single information
technology (IT) group and that contains the user accounts and resources for all of the groups that share the forest.
This shared forest, called the initial organizational forest, is the foundation of the forest design model for the
organization.
Because the initial organizational forest can host multiple groups in the organization, the forest owner must
establish service level agreements with each group so that all the parties understand what is expected of them. This
protects both the individual groups and the forest owner by establishing agreed-on service expectations.
If not all of the groups in your organization can share a single organizational forest, you must expand your forest
design to accommodate the needs of the different groups. This involves identifying the design requirements that
apply to the groups based on their needs for autonomy and isolation and whether or not they have a limited-
connectivity network, and then identifying the forest model that you can use to accommodate those requirements.
The following table lists forest design model scenarios based on the autonomy, isolation, and connectivity factors.
After you identify the forest design scenario that best matches your requirements, determine if you need to make
any additional decisions to meet your design specifications.
NOTE
If a factor is listed as N/A, it is not a consideration because other requirements also accommodate that factor.
LIMITED SERVICE SERVICE

SCENARIO CONNECTIVITY DATA ISOLATION DATA AUTONOMY ISOLATION AUTONOMY
Scenario 1: Join No No Yes No No

an existing forest
for data
autonomy
Scenario 2: Use No No N/A No Yes

an organizational
forest or domain
for service
autonomy
Scenario 3: Use No No N/A Yes N/A

an organizational
forest or resource
forest for service
isolation
LIMITED SERVICE SERVICE
SCENARIO CONNECTIVITY DATA ISOLATION DATA AUTONOMY ISOLATION AUTONOMY
Scenario 4: Use N/A Yes N/A N/A N/A

an organizational
forest or
restricted access
forest for data
isolation
Scenario 5: Use Yes No N/A No No

an organizational
forest, or
reconfigure the
firewall for limited
connectivity
Scenario 6: Use Yes No N/A No Yes

an organizational
forest or domain,
and reconfigure
the firewall for
service autonomy
with limited
connectivity
Scenario 7: Use a Yes No N/A Yes N/A

resource forest,
and reconfigure
the firewall for
service isolation
with limited
connectivity
Scenario 1: Join an existing forest for data autonomy

You can meet a requirement for data autonomy simply by hosting the group in organizational units (OUs) in an
existing organizational forest. Delegate control over the OUs to data administrators from that group to achieve data
autonomy. For more information about delegating control by using OUs, see Creating an Organizational Unit
Design.
Scenario 2: Use an organizational forest or domain for service

autonomy
If a group in your organization identifies service autonomy as a requirement, we recommend that you first
reconsider this requirement. Achieving service autonomy creates more management overhead and additional costs
for the organization. Ensure that the requirement for service autonomy is not simply for convenience and that you
can justify the costs involved in meeting this requirement.
You can meet a requirement for service autonomy by doing one of the following:
Creating an organizational forest. Place the users, groups, and computers for the group that requires service
autonomy into a separate organizational forest. Assign an individual from that group to be the forest owner.
If the group needs to access or share resources with other forests in the organization, they can establish a
trust between their organizational forest and the other forests.
Using organizational domains. Place the users, groups, and computers in a separate domain in an existing
organizational forest. This model provides for domain-level service autonomy only and not for full service
autonomy, service isolation, or data isolation.
For more information about using organizational domains, see Using the Organizational Domain Forest Model.
Scenario 3: Use an organizational forest or resource forest for service

isolation
You can meet a requirement for service isolation by doing one of the following:
Using an organizational forest. Place the users, groups, and computers for the group that requires service
isolation into a separate organizational forest. Assign an individual from that group to be the forest owner. If
the group needs to access or share resources with other forests in the organization, they can establish a trust
between their organizational forest and the other forests. However, we do not recommend this approach
because resource access through universal groups is heavily restricted in forest trust scenarios.
Using a resource forest. Place resources and service accounts into a separate resource forest, keeping user
accounts in an existing organizational forest. If necessary, alternate accounts can be created in the resource
forest to access resources in the resource forest if the organizational forest becomes unavailable. The
alternate accounts must have the authority required to log on to the resource forest and maintain control of
the resources until the organizational forest is back online.
Establish a trust between the resource and organizational forests, so that the users can access the resources
in the forest while using their regular user accounts. This configuration enables centralized management of
user accounts while allowing users to fall back to alternate accounts in the resource forest if the
organizational forest becomes unavailable.
Considerations for service isolation include the following:
Forests created for service isolation can trust domains from other forests but must not include users from
other forests in their service administrators groups. If users from other forests are included in administrative
groups in the isolated forest, the security of the isolated forest potentially can be compromised because the
service administrators in the forest do not have exclusive control.
As long as domain controllers are accessible on a network, they are subject to attacks (such as denial-of-
service attacks) from malicious software on that network. You can do the following to protect against the
possibility of an attack:
Host domain controllers only on networks that are considered secure.
Limit access to the network or networks hosting the domain controllers.
Service isolation requires the creation of an additional forest. Evaluate whether the cost of maintaining the
infrastructure to support the additional forest outweighs the costs associated with loss of access to resources
due to an organizational forest being unavailable.
Scenario 4: Use an organizational forest or restricted access forest for

data isolation
You can achieve data isolation by doing one of the following:
Using an organizational forest. Place the users, groups, and computers for the group that requires data
isolation into a separate organizational forest. Assign an individual from that group to be the forest owner. If
the group needs to access or share resources with other forests in the organization, establish a trust between
the organizational forest and the other forests. Only the users who require access to the classified
information exist in the new organizational forest. Users have one account that they use to access both
classified data in their own forest and unclassified data in other forests by means of trust relationships.
Using a restricted access forest. This is a separate forest that contains the restricted data and the user
accounts that are used to access that data. Separate user accounts are maintained in the existing
organizational forests that are used to access the unrestricted resources on the network. No trusts are
created between the restricted access forest and other forests in the enterprise. You can further restrict the
forest by deploying the forest on a separate physical network, so that it cannot connect to other forests. If
you deploy the forest on a separate network, users must have two workstations: one for accessing the
restricted forest and one for accessing the nonrestricted areas of the network.
Considerations for creating forests for data isolation include the following:
Organizational forests created for data isolation can trust domains from other forests, but users from other
forests must not be included in any of the following:
Groups responsible for service management or groups that can manage the membership of service
administrator groups
Groups that have administrative control over computers that store protected data
Groups that have access to protected data or groups that are responsible for the management of user
objects or group objects that have access to protected data
If users from another forest are included in any of these groups, a compromise of the other forest
might lead to a compromise of the isolated forest and to disclosure of protected data.
Other forests can be configured to trust the organizational forest created for data isolation so that users in
the isolated forest can access resources in other forests. However, users from the isolated forest must never
interactively log on to workstations in the trusting forest. The computer in the trusting forest can potentially
be compromised by malicious software and can be used to capture the logon credentials of the user.
NOTE
To prevent servers in a trusting forest from impersonating users from the isolated forest, and then accessing
resources in the isolated forest, the forest owner can disable delegated authentication or use the constrained
delegation feature. For more information about delegated authentication and constrained delegation, see Delegating
authentication.
You might need to establish a firewall between the organizational forest and the other forests in the
organization to limit user access to information outside of their forest.
Although creating a separate forest enables data isolation, as long as the domain controllers in the isolated
forest and computers that host protected information are accessible on a network, they are subject to attacks
launched from computers on that network. Organizations that decide that the risk of attack is too high or
that the consequence of an attack or security violation is too great need to limit access to the network or
networks that are hosting the domain controllers and the computers that are hosting protected data.
Limiting access can be done by using technologies such as firewalls and Internet Protocol security (IPsec). In
extreme cases, organizations might choose to maintain the protected data on an independent network that
has no physical connection to any other network in the organization.
NOTE
If any network connectivity exists between a restricted access forest and another network, the possibility exists for
data in the restricted area to be transmitted to the other network.
Scenario 5: Use an organizational forest, or reconfigure the firewall for

limited connectivity
To meet a limited connectivity requirement, you can do one of the following:
Place users into an existing organizational forest, and then open the firewall enough to allow Active
Directory traffic to pass through.
Use an organizational forest. Place the users, groups, and computers for the group for which connectivity is
limited into a separate organizational forest. Assign an individual from that group to be the forest owner. The
organizational forest provides a separate environment on the other side of the firewall. The forest includes
user accounts and resources that are managed within the forest, so that users do not need to go through the
firewall to accomplish their daily tasks. Specific users or applications might have special needs that require
the capability to pass through the firewall to contact other forests. You can address these needs individually
by opening the appropriate interfaces in the firewall, including those necessary for any trusts to function.
For more information about configuring firewalls for use with Active Directory Domain Services (AD DS ), see
Active Directory in Networks Segmented by Firewalls.
Scenario 6: Use an organizational forest or domain, and reconfigure the

firewall for service autonomy with limited connectivity
If a group in your organization identifies service autonomy as a requirement, we recommend that you first
reconsider this requirement. Achieving service autonomy creates more management overhead and additional costs
for the organization. Ensure that the requirement for service autonomy is not simply for convenience and that you
can justify the costs involved in meeting this requirement.
If limited connectivity is an issue, and you have a requirement for service autonomy, you can do one of the
following:
Use an organizational forest. Place the users, groups, and computers for the group that requires service
autonomy into a separate organizational forest. Assign an individual from that group to be the forest owner.
The organizational forest provides a separate environment on the other side of the firewall. The forest
includes user accounts and resources that are managed within the forest, so that users do not need to go
through the firewall to accomplish their daily tasks. Specific users or applications might have special needs
that require the capability to pass through the firewall to contact other forests. You can address these needs
individually by opening the appropriate interfaces in the firewall, including those necessary for any trusts to
function.
Place the users, groups, and computers in a separate domain in an existing organizational forest. This model
provides for domain-level service autonomy only and not for full service autonomy, service isolation, or data
isolation. Other groups in the forest must trust the service administrators of the new domain to the same
degree that they trust the forest owner. For this reason, we do not recommend this approach. For more
information about using organizational domains, see Using the Organizational Domain Forest Model.
You also need to open the firewall enough to allow Active Directory traffic to pass through. For more information
about configuring firewalls for use with AD DS, see Active Directory in Networks Segmented by Firewalls.
Scenario 7: Use a resource forest, and reconfigure the firewall for

service isolation with limited connectivity
If limited connectivity is an issue, and you have a requirement for service isolation, you can do one of the following:
Use an organizational forest. Place the users, groups, and computers for the group that requires service
isolation into a separate organizational forest. Assign an individual from that group to be the forest owner.
The organizational forest provides a separate environment on the other side of the firewall. The forest
includes user accounts and resources that are managed within the forest, so that users do not need to go
through the firewall to accomplish their daily tasks. Specific users or applications might have special needs
that require the capability to pass through the firewall to contact other forests. You can address these needs
individually by opening the appropriate interfaces in the firewall, including those necessary for any trusts to
function.
Use a resource forest. Place resources and service accounts into a separate resource forest, keeping user
accounts in an existing organizational forest. It might be necessary to create some alternate user accounts in
the resource forest to maintain access to the resource forest if the organizational forest becomes unavailable.
The alternate accounts must have the authority required to log on to the resource forest and maintain
control of the resources until the organizational forest is back online.
Establish a trust between the resource and organizational forests, so that the users can access the resources
in the forest while using their regular user accounts. This configuration enables centralized management of
user accounts while allowing users to fall back to alternate accounts in the resource forest if the
organizational forest becomes unavailable.
Considerations for service isolation include the following:
Forests created for service isolation can trust domains from other forests but must not include users from
other forests in their service administrators groups. If users from other forests are included in administrative
groups in the isolated forest, the security of the isolated forest potentially can be compromised because the
service administrators in the forest do not have exclusive control.
As long as domain controllers are accessible on a network, they are subject to attacks (such as denial-of-
service attacks) from computers on that network. You can do the following to protect against the possibility
of an attack:
Host domain controllers only on networks that are considered secure.
Limit access to the network or networks hosting the domain controllers.
Service isolation requires the creation of an additional forest. Evaluate whether the cost of maintaining the
infrastructure to support the additional forest outweighs the costs associated with loss of access to resources
due to an organizational forest being unavailable.
Specific users or applications might have special needs that require the capability to pass through the
firewall to contact other forests. You can address these needs individually by opening the appropriate
interfaces in the firewall, including those necessary for any trusts to function.
For more information about configuring firewalls for use with AD DS, see Active Directory in Networks Segmented
by Firewalls.
Using the Organizational Domain Forest Model
In the organizational domain forest model, several autonomous groups each own a domain within a forest. Each
group controls domain-level service administration, which enables them to manage certain aspects of service
management autonomously while the forest owner controls forest-level service management.
The following illustration shows an organizational domain forest model.
Domain-level service autonomy

The organizational domain forest model enables the delegation of authority for domain-level service management.
The following table lists the types of service management that can be controlled at the domain level.
TYPE OF SERVICE MANAGEMENT ASSOCIATED TASKS
Management of domain controller operations - Creating and removing domain controllers

- Monitoring the functioning of domain controllers
- Managing services that are running on domain controllers
- Backing up and restoring the directory
Configuration of domain-wide settings - Creating domain and domain user account policies, such as
password, Kerberos, and account lockout policies
- Creating and applying domain-wide Group Policy
TYPE OF SERVICE MANAGEMENT ASSOCIATED TASKS
Delegation of data-level administration - Creating organizational units (OUs) and delegating

administration
- Repairing problems in the OU structure that OU owners do
not have sufficient access rights to fix
Management of external trusts - Establishing trust relationships with domains outside the
forest
Other types of service management, such as schema or replication topology management, are the responsibility of
the forest owner.
Domain owner
In an organizational domain forest model, domain owners are responsible for domain-level service management
tasks. Domain owners have authority over the entire domain as well as access to all other domains in the forest. For
this reason, domain owners must be trusted individuals selected by the forest owner.
Delegate domain-level service management to a domain owner, if the following conditions are met:
All groups participating in the forest trust the new domain owner and the service management practices of
the new domain.
The new domain owner trusts the forest owner and all the other domain owners.
All domain owners in the forest agree that the new domain owner has service administrator management
and selection policies and practices that are equal to or more strict than their own.
All domain owners in the forest agree that domain controllers managed by the new domain owner in the
new domain are physically secure.
Note that if a forest owner delegates domain-level service management to a domain owner, other groups might
choose not to join that forest if they do not trust that domain owner.
All domain owners must be aware that if any of these conditions change in the future, it might become necessary to
move the organizational domains into a multiple forest deployment.
NOTE
Another way to minimize security risks to a Windows Server 2008 Active Directory domain is to employ administrator role
separation, which requires the deployment of a read-only domain controller (RODC) in your Active Directory infrastructure.
An RODC is a new type of domain controller in the Windows Server 2008 operating system that hosts read-only partitions of
the Active Directory database. Before the release of Windows Server 2008 , any server maintenance work on a domain
controller had to be performed by a domain administrator. In Windows Server 2008 , you can delegate local administrative
permissions for an RODC to any domain user without granting that user any administrative rights for the domain or other
domain controllers. This permits the delegated user to log on to an RODC and perform maintenance work, such as upgrading
a driver, on the server. However, this delegated user cannot log on to any other domain controller or perform any other
administrative task in the domain. In this way, any trusted user can be delegated the ability to effectively manage the RODC
without compromising the security of the rest of the domain. For more information about RODCs, see AD DS: Read-Only
Domain Controllers.
The forest owner is responsible for creating a domain design for the forest. Creating a domain design involves
examining the replication requirements and the existing capacity of your network infrastructure and then building a
domain structure that enables Active Directory Domain Services (AD DS ) to function in the most efficient way.
Domains are used to partition the directory so that the information in the directory can be distributed and
managed efficiently throughout the enterprise. The goal for your domain design is to maximize the efficiency of the
Active Directory replication topology while ensuring that replication does not use too much available network
bandwidth and does not interfere with the daily operation of your network.
In this section
Reviewing the Domain Models
Determining Whether to Upgrade Existing Domains or Deploy New Domains
Reviewing the Domain Models
The following factors impact the domain design model that you select:
Amount of available capacity on your network that you are willing to allocate to Active Directory Domain
Services (AD DS ). The goal is to select a model that provides efficient replication of information with
minimal impact on available network bandwidth.
Number of users in your organization. If your organization includes a large number of users, deploying
more than one domain enables you to partition your data and gives you more control over the amount of
replication traffic that will pass through a given network connection. This makes it possible for you to control
where data is replicated and reduce the load created by replication traffic on slow links in your network.
The simplest domain design is a single domain. In a single domain design, all information is replicated to all of the
domain controllers. If necessary, however, you can deploy additional regional domains. This might occur if portions
of the network infrastructure are connected by slow links, and the forest owner wants to be sure that replication
traffic does not exceed the capacity that has been allocated to AD DS.
It is best to minimize the number of domains that you deploy in your forest. This reduces the overall complexity of
the deployment and, as a result, reduces total cost of ownership. The following table lists the administrative costs
associated with adding regional domains.
COST IMPLICATIONS
Management of multiple service administrator groups Each domain has its own service administrator groups that
need to be managed independently. The membership of these
service administrator groups must be carefully controlled.
Maintaining consistency among Group Policy settings that are Group Policy settings that need to be applied forest-wide
common to multiple domains must be applied separately to each individual domain in the
forest.
Maintaining consistency among access control and auditing Access control and auditing settings that need to be applied
settings that are common to multiple domains across the forest must be applied separately to each individual
domain in the forest.
Increased likelihood of objects moving between domains The greater the number of domains, the greater the likelihood
that users will need to move from one domain to another. This
move can potentially impact end users.
NOTE
Windows Server fine-grained password and account lockout policies can also impact the domain design model that you select.
Before this release of Windows Server 2008, you could apply only one password and account lockout policy, which is specified
in the domain Default Domain Policy, to all users in the domain. As a result, if you wanted different password and account
lockout settings for different sets of users, you had to either create a password filter or deploy multiple domains. You can now
use fine-grained password policies to specify multiple password policies and to apply different password restrictions and
account lockout policies to different sets of users within a single domain. For more information about fine-grained password
and account lockout policies, see the article Step-by-Step Guide for Fine-Grained Password and Account Lockout Policy
Configuration.
Single domain model

A single domain model is the easiest to administer and the least expensive to maintain. It consists of a forest that
contains a single domain. This domain is the forest root domain, and it contains all of the user and group accounts
in the forest.
A single domain forest model reduces administrative complexity by providing the following advantages:
Any domain controller can authenticate any user in the forest.
All domain controllers can be global catalogs, so you do not need to plan for global catalog server
placement.
In a single domain forest, all directory data is replicated to all geographic locations that host domain controllers.
While this model is the easiest to manage, it also creates the most replication traffic of the two domain models.
Partitioning the directory into multiple domains limits the replication of objects to specific geographic regions but
results in more administrative overhead.
Regional domain model

All object data within a domain is replicated to all domain controllers in that domain. For this reason, if your forest
includes a large number of users that are distributed across different geographic locations connected by a wide
area network (WAN ), you might need to deploy regional domains to reduce replication traffic over the WAN links.
Geographically based regional domains can be organized according to network WAN connectivity.
The regional domain model enables you to maintain a stable environment over time. Base the regions used to
define domains in your model on stable elements, such as continental boundaries. Domains based on other factors,
such as groups within the organization, can change frequently and might require you to restructure your
environment.
The regional domain model consists of a forest root domain and one or more regional domains. Creating a
regional domain model design involves identifying what domain is the forest root domain and determining the
number of additional domains that are required to meet your replication requirements. If your organization
includes groups that require data isolation or service isolation from other groups in the organization, create a
separate forest for these groups. Domains do not provide data isolation or service isolation.
Every forest starts with a single domain. The maximum number of users that a single domain forest can contain is
based on the slowest link that must accommodate replication between domain controllers and the available
bandwidth that you want to allocate to Active Directory Domain Services (AD DS ). The following table lists the
maximum recommended number of users that a domain can contain based on a single domain forest, the speed of
the slowest link, and the percentage of bandwidth that you want to reserve for replication. This information applies
to forests that contain a maximum of 100,000 users and that have a connectivity of 28.8 kilobits per second (Kbps)
or higher. For recommendations that apply to forests that contain more than 100,000 users or connectivity of less
than 28.8 Kbps, consult an experienced Active Directory designer. The values in the following table are based on the
replication traffic generated in an environment that has the following characteristics:
New users join the forest at a rate of 20 percent per year.
Users leave the forest at a rate of 15 percent per year.
Each user is a member of five global groups and five universal groups.
The ratio of users to computers is 1:1.
Active Directory-integrated Domain Name System (DNS ) is used.
DNS scavenging is used.
NOTE
The figures listed in the following table are approximations. The quantity of replication traffic depends largely on the number
of changes made to the directory in a given amount of time. Confirm that your network can accommodate your replication
traffic by testing the estimated quantity and rate of changes on your design in a lab before deploying your domains.
MAXIMUM NUMBER OF USERS MAXIMUM NUMBER OF USERS MAXIMUM NUMBER OF USERS

SLOWEST LINK CONNECTING A IF 1-PERCENT BANDWIDTH IS IF 5-PERCENT BANDWIDTH IS IF 10-PERCENT BANDWIDTH IS
DOMAIN CONTROLLER (KBPS) AVAILABLE AVAILABLE AVAILABLE
28.8 10,000 25,000 40,000
32 10,000 25,000 50,000
56 10,000 50,000 100,000
64 10,000 50,000 100,000
128 25,000 100,000 100,000
256 50,000 100,000 100,000
512 80,000 100,000 100,000
1,500 100,000 100,000 100,000
To use this table:

1. In the Slowest link connecting a domain controller column, locate the value that matches the speed of
the slowest link across which AD DS will replicate in your domain.
2. In the row that corresponds to your slowest link speed, locate the column that represents the percentage
bandwidth you want to allocate to AD DS. The value at that location is the maximum number of users that
the domain in a single domain forest can contain.
If you determine that the total number of users in your forest is less than the maximum number of users that your
domain can contain, you can use a single domain. Be sure to accommodate for planned future growth when you
make this determination. If you determine that the total number of users in your forest is greater than the
maximum number of users that your domain can contain, you need to reserve a higher percentage of bandwidth
for replication, increase your link speed, or divide your organization into regional domains.
Dividing the organization into regional domains

If you cannot accommodate all of your users in a single domain, you must select the regional domain model. Divide
your organization into regions in a way that makes sense for your organization and your existing network. For
example, you might create regions based on continental boundaries.
Note that because you need to create an Active Directory domain for each region that you establish, we
recommend that you minimize the number of regions that you define for AD DS. Although it is possible to include
an unlimited number of domains in a forest, for manageability we recommend that a forest include no more than
10 domains. You must establish the appropriate balance between optimizing your replication bandwidth and
minimizing your administrative complexity when dividing your organization into regional domains.
First, determine the maximum number of users that your forest can host. Base this on the slowest link in the forest
across which domain controllers will replicate and the average amount of bandwidth you want to allocate to Active
Directory replication. The following table lists the maximum recommended number of users that a forest can
contain. This is based on the speed of the slowest link and the percentage bandwidth that you want to reserve for
replication. This information applies to forests that contain a maximum of 100,000 users and that have a
connectivity of 28.8 Kbps or higher. The values in the following table are based on the following assumptions:
All domain controllers are global catalog servers.
Users are members of five global groups and five universal groups.
Active Directory-integrated DNS is used.
NOTE

28.8 10,000 50,000 75,000
32 10,000 50,000 75,000

56 10,000 75,000 100,000
64 25,000 75,000 100,000
128 50,000 100,000 100,000
256 75,000 100,000 100,000
512 100,000 100,000 100,000
1,500 100,000 100,000 100,000
To use this table:

the slowest link across which AD DS will replicate in your forest.
bandwidth that you want to allocate to AD DS. The value at that location is the maximum number of users
that your forest can host.
If the maximum number of users that your forest can host is greater than the number of users that you need to
host, a single forest will work for your design. If you need to host more users than the maximum number that you
identified, you need to increase the minimum link speed, allocate a greater percentage of bandwidth for AD DS, or
deploy additional forests.
If you determine that a single forest will accommodate the number of users that you need to host, the next step is
to determine the maximum number of users that each region can support based on the slowest link located in that
region. Divide your forest into regions that make sense to you. Make sure that you base your decision on
something that is not likely to change. For example, use continents instead of sales regions. These regions will be
the basis of your domain structure when you have identified the maximum number of users.
Determine the number of users that need to be hosted in each region, and then verify that they do not exceed the
maximum allowed based on the slowest link speed and the bandwidth allocated to AD DS in that region. The
following table lists the maximum recommended number of users that a regional domain can contain. It is based
on the speed of the slowest link and the percentage of bandwidth you want to reserve for replication. This
information applies to forests that contain a maximum of 100,000 users and that have a connectivity of 28.8 Kbps
or higher. The values in the following table are based on the following assumptions:
All domain controllers are global catalog servers.
Users are members of five global groups and five universal groups.
Active Directory-integrated DNS is used.
NOTE

28.8 10,000 18,000 40,000
32 10,000 20,000 50,000
56 10,000 40,000 100,000
64 10,000 50,000 100,000
128 15,000 100,000 100,000
256 30,000 100,000 100,000
512 80,000 100,000 100,000
1,500 100,000 100,000 100,000
To use this table:

the slowest link across which AD DS will replicate in your region.
bandwidth that you want to allocate to AD DS. That value represents the maximum number of users that the
region can host.
Evaluate each proposed region and determine if the maximum number of users in each region is less than the
recommended maximum number of users that a domain can contain. If you determine that the region can host the
number of users that you require, you can create a domain for that region. If you determine that you cannot host
that many users, consider dividing your design into smaller regions and recalculating the maximum number of
users that can be hosted in each region. The other alternatives are to allocate more bandwidth or increase your link
speed.
Although the total number of users that you can put in a domain in a multidomain forest is smaller than the
number of users in the domain in a single domain forest, the overall number of users in the multidomain forest can
be higher. The smaller number of users per domain in a multidomain forest accommodates the additional
replication overhead created by maintaining the global catalog in that environment. For recommendations that
apply to forests that contain more than 100,000 users or connectivity of less than 28.8 Kbps, consult an experienced
Active Directory designer.
Documenting the regions identified

After you divide your organization into regional domains, document the regions that you want represented and the
number of users that will exist in each region. In addition, note the speed of the slowest links in each region that
you will use for Active Directory replication. This information is used to determine if additional domains or forests
are required.
For a worksheet to assist you in documenting the regions you identified, download
Deployment Kit and open "Identifying Regions" (DSSLOGI_4.doc).
Determining Whether to Upgrade Existing Domains
or Deploy New Domains
Each domain in your design will either be a new domain or an existing upgraded domain. Users from existing
domains that you do not upgrade must be moved into new domains.
Moving accounts between domains can impact end users. Before deciding whether to move users into a new
domain or to upgrade existing domains, evaluate the long-term administrative benefits of a new AD DS domain
against the cost of moving users into the domain.
For more information about upgrading Active Directory domains to Windows Server 2008 , see Upgrading Active
Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains.
For more information about restructuring AD DS domains within and between forests, see Active Directory
Migration Tool version 3.1 Migration Guide (https://go.microsoft.com/fwlink/?LinkId=93678).
For a worksheet to assist you in documenting your plans for new and upgraded domains, download
Deployment Kit (https://go.microsoft.com/fwlink/?LinkID=102558) and open "Domain Planning"
(DSSLOGI_5.doc).
You must assign a name to every domain in your plan. Active Directory Domain Services (AD DS ) domains have
two types of names: Domain Name System (DNS ) names and NetBIOS names. In general, both names are visible
to end users. The DNS names of Active Directory domains include two parts, a prefix and a suffix. When creating
domain names, first determine the DNS prefix. This is the first label in the DNS name of the domain. The suffix is
determined when you select the name of the forest root domain. The following table lists the prefix naming rules
for DNS names.
RULE EXPLANATION
Select a prefix that is not likely to become outdated. Avoid names such as a product line or operating system that
might change in the future. We recommend using
geographical names.
Select a prefix that includes Internet standard characters only. A-Z, a-z, 0-9, and (-), but not entirely numerical.
Include 15 characters or less in the prefix. If you choose a prefix length of 15 characters or less, the
NetBIOS name is the same as the prefix.
For more information, see Naming conventions in Active Directory for computers, domains, sites, and OUs
NOTE
Although Dcpromo.exe in Windows Server 2008 and Windows Server 2003 allows you to create a single-label DNS domain
name, you should not use a single-label DNS name for a domain for several reasons. In Windows Server 2008 R2,
Dcpromo.exe does not allow you to create a single-label DNS name for a domain. For more information, see
https://go.microsoft.com/fwlink/?LinkId=92467.
If the current NetBIOS name of the domain is inappropriate to represent the region or fails to satisfy the prefix
naming rules, select a new prefix. In this case, the NetBIOS name of the domain is different from the DNS prefix of
the domain.
For each new domain that you deploy, select a prefix that is appropriate for the region and that satisfies prefix
naming rules. We recommend that the NetBIOS name of the domain be the same as the DNS prefix.
Document the DNS prefix and NetBIOS names that you select for each domain in your forest. You can add the
DNS and NetBIOS name information to the "Domain Planning" worksheet that you created to document your plan
for new and upgraded domains. To open it, download
Deployment Kit (https://go.microsoft.com/fwlink/?LinkID=102558) and open "Domain Planning"
(DSSLOGI_5.doc).
The first domain that you deploy in an Active Directory forest is called the forest root domain. This domain remains
the forest root domain for the life cycle of the AD DS deployment.
The forest root domain contains the Enterprise Admins and Schema Admins groups. These service administrator
groups are used to manage forest-level operations such as the addition and removal of domains and the
implementation of changes to the schema.
Selecting the forest root domain involves determining if one of the Active Directory domains in your domain
design can function as the forest root domain or if you need to deploy a dedicated forest root domain.
For information about deploying a forest root domain, see Deploying a Windows Server 2008 Forest Root Domain.
Choosing a regional or dedicated forest root domain

If you are applying a single domain model, the single domain functions as the forest root domain. If you are
applying a multiple domain model, you can choose to deploy a dedicated forest root domain or select a regional
domain to function as the forest root domain.
Dedicated forest root domain
A dedicated forest root domain is a domain that is created specifically to function as the forest root. It does not
contain any user accounts other than the service administrator accounts for the forest root domain. Also, it does not
represent any geographical region in your domain structure. All other domains in the forest are children of the
dedicated forest root domain.
Using a dedicated forest root provides the following advantages:
Operational separation of forest service administrators from domain service administrators. In a single domain
environment, members of the Domain Admins and built-in Administrators groups can use standard tools and
procedures to make themselves members of the Enterprise Admins and Schema Admins groups. In a forest that
uses a dedicated forest root domain, members of the Domain Admins and built-in Administrators groups in the
regional domains cannot make themselves members of the forest-level service administrator groups by using
standard tools and procedures.
Protection from operational changes in other domains. A dedicated forest root domain does not represent a
particular geographical region in your domain structure. For this reason, it is not affected by reorganizations or
other changes that result in the renaming or restructuring of domains.
Serves as a neutral root so that no country or region appears to be subordinate to another region. Some
organizations might prefer to avoid the appearance that one country or region is subordinate to another
country or region in the namespace. When you use a dedicated forest root domain, all regional domains can be
peers in the domain hierarchy.
In a multiple-regional-domain environment in which a dedicated forest root is used, the replication of the forest
root domain has minimal impact on the network infrastructure. This is because the forest root only hosts the
service administrator accounts. The majority of the user accounts in the forest and other domain-specific data are
stored in the regional domains.
One disadvantage to using a dedicated forest root domain is that it creates additional management overhead to
support the additional domain.
Regional domain as a forest root domain
If you choose not to deploy a dedicated forest root domain, you must select a regional domain to function as the
forest root domain. This domain is the parent domain of all of the other regional domains and will be the first
domain that you deploy. The forest root domain contains user accounts and is managed in the same way that the
other regional domains are managed. The primary difference is that it also includes the Enterprise Admins and
Schema Admins groups.
The advantage of selecting a regional domain to function as the forest root domain is that it does not create the
additional management overhead that maintaining an additional domain creates. Select an appropriate regional
domain to be the forest root, such as the domain that represents your headquarters or the region that has the
fastest network connections. If it is difficult for your organization to select a regional domain to be the forest root
domain, you can choose to use a dedicated forest root model instead.
Assigning the forest root domain name

The forest root domain name is also the name of the forest. The forest root name is a Domain Name System (DNS )
name that consists of a prefix and a suffix in the form of prefix.suffix. For example, an organization might have the
forest root name corp.contoso.com. In this example, corp is the prefix and contoso.com is the suffix.
Select the suffix from a list of existing names on your network. For the prefix, select a new name that has not been
used on your network previously. By attaching a new prefix to an existing suffix, you create a unique namespace.
Creating a new namespace for Active Directory Domain Services (AD DS ) ensures that any existing DNS
infrastructure does not need to be modified to accommodate AD DS.
Selecting a suffix
To select a suffix for the forest root domain:
1. Contact the DNS owner for the organization for a list of registered DNS suffixes that are in use on the
network that will host AD DS. Note that the suffixes used on the internal network might be different than the
suffixes used externally. For example, an organization might use contosopharma.com on the Internet and
contoso.com on the internal corporate network.
2. Consult the DNS owner to select a suffix for use with AD DS. If no suitable suffixes exist, register a new
name with an Internet naming authority.
We recommend that you use DNS names that are registered with an Internet authority in the Active Directory
namespace. Only registered names are guaranteed to be globally unique. If another organization later registers the
same DNS domain name (or if your organization merges with, acquires, or is acquired by another company that
uses the same DNS name), the two infrastructures cannot interact with one another.
Cau t i on
Do not use single-label DNS names. For more information, see Information about configuring Windows for
domains with single-label DNS names (https://go.microsoft.com/fwlink/?LinkId=106631). Also, we do not
recommend using unregistered suffixes, such as .local.
Selecting a prefix
If you chose a registered suffix that is already in use on the network, select a prefix for the forest root domain name
by using the prefix rules in the table below. Add a prefix that is not currently in use to create a new subordinate
name. For example, if your DNS root name is contoso.com, you can create the Active Directory forest root domain
name concorp.contoso.com if the namespace concorp.contoso.com is not already in use on the network. This new
branch of the namespace will be dedicated to AD DS and can be integrated easily with the existing DNS
implementation.
If you selected a regional domain to function as a forest root domain, you might need to select a new prefix for the
domain. Because the forest root domain name affects all of the other domain names in the forest, a regionally
based name might not be appropriate. If you are using a new suffix that is not currently in use on the network, you
can use it as the forest root domain name without choosing an additional prefix.
The following table lists the rules for selecting a prefix for a registered DNS name.
RULE EXPLANATION
Select a prefix that is not likely to become outdated. Avoid names such as a product line or operating system that
might change in the future. We recommend using generic
names such as corp or ds.
Select a prefix that includes Internet standard characters only. A-Z, a-z, 0-9, and (-), but not entirely numerical.
Include 15 characters or less in the prefix. If you choose a prefix length of 15 characters or less, the
NetBIOS name is the same as the prefix.
It is important for the Active Directory DNS owner to work with the DNS owner for the organization to obtain
ownership of the name that will be used for the Active Directory namespace. For more information about designing
a DNS infrastructure to support AD DS, see Creating a DNS Infrastructure Design.
Documenting the forest root domain name

Document the DNS prefix and suffix that you select for the forest root domain. At this point, identify what domain
will be the forest root. You can add the forest root domain name information to the "Domain Planning" worksheet
that you created to document your plan for new and upgraded domains and your domain names. To open it,
download Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip from Job Aids for Windows
Server 2003 Deployment Kit and open "Domain Planning" (DSSLOGI_5.doc).
After you create your Active Directory forest and domain designs, you must design a Domain Name System (DNS )
infrastructure to support your Active Directory logical structure. DNS enables users to use friendly names that are
easy to remember to connect to computers and other resources on IP networks. Active Directory Domain Services
(AD DS ) in Windows Server 2008 requires DNS.
The process for designing DNS to support AD DS varies according to whether your organization already has an
existing DNS Server service or you are deploying a new DNS Server service:
If you already have an existing DNS infrastructure, you must integrate the Active Directory namespace into that
environment. For more information, see Integrating AD DS into an Existing DNS Infrastructure.
If you do not have a DNS infrastructure in place, you must design and deploy a new DNS infrastructure to
support AD DS. For more information, see Deploying Domain Name System (DNS ).
If your organization has an existing DNS infrastructure, you must make sure that you understand how your DNS
infrastructure will interact with the Active Directory namespace. For a worksheet to assist you in documenting your
existing DNS infrastructure design, download
Deployment Kit and open "DNS Inventory" (DSSLOGI_8.doc).
NOTE
In addition to IP version 4 (IPv4) addresses, Windows Server also supports IP version 6 (IPv6) addresses. For a worksheet to
assist you in listing the IPv6 addresses while documenting the recursive name resolution method of your current DNS
structure, see Appendix A: DNS Inventory.
Before you design your DNS infrastructure to support AD DS, it can be helpful to read about the DNS hierarchy,
the DNS name resolution process, and how DNS supports AD DS. For more information about the DNS hierarchy
and name resolution process, see the DNS Technical Reference (https://go.microsoft.com/fwlink/?LinkID=48145).
For more information about how DNS supports AD DS, see the DNS Support for Active Directory Technical
Reference (https://go.microsoft.com/fwlink/?LinkID=48147).
In this section
DNS and AD DS
Domain Name System (DNS ) is a distributed database that represents a namespace. The namespace contains all of
the information needed for any client to look up any name. Any DNS server can answer queries about any name
within its namespace. A DNS server answers queries in one of the following ways:
If the answer is in its cache, it answers the query from the cache.
If the answer is in a zone hosted by the DNS server, it answers the query from its zone. A zone is a portion of
the DNS tree stored on a DNS server. When a DNS server hosts a zone, it is authoritative for the names in that
zone (that is, the DNS server can answer queries for any name in the zone). For example, a server hosting the
zone contoso.com can answer queries for any name in contoso.com.
If the server cannot answer the query from its cache or zones, it queries other servers for the answer.
It is important to understand the core features of DNS, such as delegation, recursive name resolution, and Active
Directory-integrated DNS zones, because they have a direct impact on your Active Directory logical structure
design.
For more information about DNS and Active Directory Domain Services (AD DS ), see DNS and AD DS.
Delegation
For a DNS server to answer queries about any name, it must have a direct or indirect path to every zone in the
namespace. These paths are created by means of delegation. A delegation is a record in a parent zone that lists a
name server that is authoritative for the zone in the next level of the hierarchy. Delegations make it possible for
servers in one zone to refer clients to servers in other zones. The following illustration shows one example of
delegation.
The DNS root server hosts the root zone represented as a dot ( . ). The root zone contains a delegation to a zone in
the next level of the hierarchy, the com zone. The delegation in the root zone tells the DNS root server that, to find
the com zone, it must contact the Com server. Likewise, the delegation in the com zone tells the Com server that, to
find the contoso.com zone, it must contact the Contoso server.
NOTE
A delegation uses two types of records. The name server (NS) resource record provides the name of an authoritative server.
Host (A) and host (AAAA) resource records provide IP version 4 (IPv4) and IP version 6 (IPv6) addresses of an authoritative
server.
This system of zones and delegations creates a hierarchical tree that represents the DNS namespace. Each zone
represents a layer in the hierarchy, and each delegation represents a branch of the tree.
By using the hierarchy of zones and delegations, a DNS root server can find any name in the DNS namespace. The
root zone includes delegations that lead directly or indirectly to all other zones in the hierarchy. Any server that can
query the DNS root server can use the information in the delegations to find any name in the namespace.
Recursive name resolution

Recursive name resolution is the process by which a DNS server uses the hierarchy of zones and delegations to
respond to queries for which it is not authoritative.
In some configurations, DNS servers include root hints (that is, a list of names and IP addresses) that enable them
to query the DNS root servers. In other configurations, servers forward all queries that they cannot answer to
another server. Forwarding and root hints are both methods that DNS servers can use to resolve queries for which
they are not authoritative.
Resolving names by using root hints
Root hints enable any DNS server to locate the DNS root servers. After a DNS server locates the DNS root server,
it can resolve any query for that namespace. The following illustration describes how DNS resolves a name by
using root hints.
In this example, the following events occur:

1. A client sends a recursive query to a DNS server to request the IP address that corresponds to the name
ftp.contoso.com. A recursive query indicates that the client wants a definitive answer to its query. The response
to the recursive query must be a valid address or a message indicating that the address cannot be found.
2. Because the DNS server is not authoritative for the name and does not have the answer in its cache, the DNS
server uses root hints to find the IP address of the DNS root server.
3. The DNS server uses an iterative query to ask the DNS root server to resolve the name ftp.contoso.com. An
iterative query indicates that the server will accept a referral to another server in place of a definitive answer to
the query. Because the name ftp.contoso.com ends with the label com, the DNS root server returns a referral to
the Com server that hosts the com zone.
4. The DNS server uses an iterative query to ask the Com server to resolve the name ftp.contoso.com. Because the
name ftp.contoso.com ends with the name contoso.com, the Com server returns a referral to the Contoso server
that hosts the contoso.com zone.
5. The DNS server uses an iterative query to ask the Contoso server to resolve the name ftp.contoso.com. The
Contoso server finds the answer in its zone data and then returns the answer to the server.
6. The server then returns the result to the client.
Resolving names by using forwarding
Forwarding enables you to route name resolution through specific servers instead of using root hints. The
following illustration describes how DNS resolves a name by using forwarding.
In this example, the following events occur:

1. A client queries a DNS server for the name ftp.contoso.com.
2. The DNS server forwards the query to another DNS server, known as a forwarder.
3. Because the forwarder is not authoritative for the name and does not have the answer in its cache, it uses root
hints to find the IP address of the DNS root server.
4. The forwarder uses an iterative query to ask the DNS root server to resolve the name ftp.contoso.com. Because
the name ftp.contoso.com ends with the name com, the DNS root server returns a referral to the Com server
that hosts the com zone.
5. The forwarder uses an iterative query to ask the Com server to resolve the name ftp.contoso.com. Because the
name ftp.contoso.com ends with the name contoso.com, the Com server returns a referral to the Contoso server
that hosts the contoso.com zone.
6. The forwarder uses an iterative query to ask the Contoso server to resolve the name ftp.contoso.com. The
Contoso server finds the answer in its zone files, and then returns the answer to the server.
7. The forwarder then returns the result to the original DNS server.
8. The original DNS server then returns the result to the client.
DNS and AD DS
Active Directory Domain Services (AD DS ) uses Domain Name System (DNS ) name resolution services to make it
possible for clients to locate domain controllers and for the domain controllers that host the directory service to
communicate with each other.
AD DS enables easy integration of the Active Directory namespace into an existing DNS namespace. Features such
as Active Directory-integrated DNS zones make it easier for you to deploy DNS by eliminating the need to set up
secondary zones, and then configure zone transfers.
For information about how DNS supports AD DS, see the section DNS Support for Active Directory Technical
Reference.
NOTE
If you implement a disjoint namespace in which the AD DS domain name differs from the primary DNS suffix that clients use,
AD DS integration with DNS is more complex. For more information, see Disjoint Namespace.
In this section
Domain Controller Location
Active Directory-Integrated DNS Zones
Computer Naming
Disjoint Namespace
Domain Controller Location
Clients use Domain Name System (DNS ) to locate domain controllers to complete operations such as processing
logon requests or searching the directory for published resources. Domain controllers register a variety of records
in DNS to help clients and other computers locate them. These records are collectively referred to as the locator
records.
Domain controllers also use DNS to locate other domain controllers and to perform tasks such as replication. The
process by which domain controllers locate other domain controllers is the same as the process by which clients
locate domain controllers.
Active Directory-Integrated DNS Zones
Domain Name System (DNS ) servers running on domain controllers can store their zones in Active Directory
Domain Services (AD DS ). In this way, it is not necessary to configure a separate DNS replication topology that
uses ordinary DNS zone transfers because all zone data is replicated automatically by means of Active Directory
replication. This simplifies the process of deploying DNS and provides the following advantages:
Multiple masters are created for DNS replication. Therefore, any domain controller in the domain running
the DNS Server service can write updates to the Active Directory-integrated DNS zones for the domain
name for which they are authoritative. A separate DNS zone transfer topology is not needed.
Secure dynamic updates are supported. Secure dynamic updates allow an administrator to control what
computers update what names and prevent unauthorized computers from overwriting existing names in
DNS.
Active Directory-integrated DNS in Windows Server 2008 stores zone data in application directory partitions.
(There are no behavioral changes from Windows Server 2003-based DNS integration with Active Directory.) The
following DNS -specific application directory partitions are created during AD DS installation:
A forest-wide application directory partition, called ForestDnsZones
Domain-wide application directory partitions for each domain in the forest, named DomainDnsZones
For more information about how AD DS stores DNS information in application partitions, see the DNS Technical
Reference.
NOTE
We recommend that you install DNS when you run the Active Directory Domain Services Installation Wizard (Dcpromo.exe). If
you do this, the wizard creates the DNS zone delegation automatically. For more information, see Deploying a Windows
Server 2008 Forest Root Domain.
Computer Naming
When a computer running the Windows 2000, Windows XP, Windows Server 2003, Windows Server 2008 , or
Windows Vista operating system joins a domain, by default the computer assigns itself a name. The name it assigns
itself comprises the host name of the computer (that is, Computer Name in System Properties) and the Domain
Name System (DNS ) name of the Active Directory domain that the computer joined (that is, Primary DNS Suffix in
System Properties). The concatenation of the host name and the DNS name of the domain is known as the fully
qualified domain name (FQDN ). For example, if a computer with host name Server1 joins the domain
corp.contoso.com, the FQDN of the computer is server1.corp.contoso.com.
If a computer already has a different DNS domain name that was statically entered into a DNS zone or registered
by an integrated DNS/Dynamic Host Configuration Protocol (DHCP ) Server service, the FQDN of the computer is
distinct from the name that was registered previously. The computer can be referenced by either name.
For more information about naming conventions in Active Directory Domain Services (AD DS ), see Naming
conventions in Active Directory for computers, domains, sites, and organizational units
(https://go.microsoft.com/fwlink/?LinkID=106629).
Disjoint Namespace
A disjoint namespace occurs when one or more domain member computers have a primary Domain Name Service
(DNS ) suffix that does not match the DNS name of the Active Directory domain of which the computers are
members. For example, a member computer that uses a primary DNS suffix of corp.fabrikam.com in an Active
Directory domain named na.corp.fabrikam.com is using a disjoint namespace.
A disjoint namespace is more complex to administer, maintain, and troubleshoot than a contiguous namespace. In a
contiguous namespace, the primary DNS suffix matches the Active Directory domain name. Network applications
that are written to assume that the Active Directory namespace is identical to the primary DNS suffix for all domain
member computers do not function properly in a disjoint namespace.
Support for disjoint namespaces

Domain member computers, including domain controllers, can function in a disjoint namespace. Domain member
computers can register their host (A) resource record and IP version 6 (IPv6) host (AAAA) resource record in a
disjoint DNS namespace. When domain member computers register their resource records in this way, domain
controllers continue to register global and site-specific service (SRV ) resource records in the DNS zone that is
identical to the Active Directory domain name.
For example, assume that a domain controller for the Active Directory domain named na.corp.fabrikam.com that
uses a primary DNS suffix of corp.fabrikam.com registers host (A) and IPv6 host (AAAA) resource records in the
corp.fabrikam.com DNS zone. The domain controller continues to register global and site-specific service (SRV )
resource records in the _msdcs.na.corp.fabrikam.com and na.corp.fabrikam.com DNS zones, which makes service
location possible.
IMPORTANT
Although Windows operating systems may support a disjoint namespace, applications that are written to assume that the
primary DNS suffix is the same as the Active Directory domain suffix may not function in such an environment. For this
reason, you should test all applications and their respective operating systems carefully before you deploy a disjoint
namespace.
A disjoint namespace should work (and is supported) in the following situations:

When a forest with multiple Active Directory domains uses a single DNS namespace, which is also known as
a DNS zone
An example of this is a company that uses regional domains with names such as na.corp.fabrikam.com,
sa.corp.fabrikam.com, and asia.corp.fabrikam.com and uses a single DNS namespace, such as
corp.fabrikam.com.
When a single Active Directory domain is split into separate DNS namespaces
An example of this is a company with an Active Directory domain of corp.contoso.com that uses DNS zones
such as hr.corp.contoso.com, production.corp.contoso.com, and it.corp.contoso.com.
A disjoint namespace does not work properly (and is not supported) in the following situations:
A disjoint suffix used by domain members matches an Active Directory domain name in this or another
forest. This breaks Kerberos name-suffix routing.
The same disjoint suffix is used in another forest. This prevents routing these suffixes uniquely between
forests.
When a domain member certification authority (CA) server changes its fully qualified domain name (FQDN )
so that it no longer use the same primary DNS suffix that is used by the domain controllers of the domain to
which the CA server is a member. In this case, you may have problems validating certificates the CA server
issued, depending on what DNS names are used in the CRL Distribution Points. But if you place a CA server
in a stable disjoint namespace, it works properly and is supported.
Considerations for disjoint namespaces

The following considerations may help you decide if you should use a disjoint namespace.
Application compatibility
As previously mentioned, a disjoint namespace can cause problems for any applications and services that are
written to assume that a computer primary DNS suffix is identical to the name of the domain name of which it is a
member. Before you deploy a disjoint namespace, you must check applications for compatibility issues. Also, be
sure to check the compatibility of all applications that you use when you perform your analysis. This includes
applications from Microsoft and from other software developers.
Advantages of disjoint namespaces
Using a disjoint namespace can have the following advantages:
Because the primary DNS suffix of a computer can indicate different information, you can manage the DNS
namespace separately from the Active Directory domain name.
You can separate the DNS namespace based on business structure or geographical location. For example,
you can separate the namespace based on business unit names or physical location such as continent,
country/region, or building.
Disadvantages of disjoint namespaces
Using a disjoint namespace can have the following disadvantages:
You must create and manage separate DNS zones for each Active Directory domain in the forest that has
member computers that use a disjoint namespace. (That is, it requires an additional and more complex
configuration.)
You must perform manual steps to modify and manage the Active Directory attribute that allows domain
members to use specified, primary DNS suffixes.
To optimize name resolution, you must perform manual steps to modify and maintain Group Policy to
configure member computers with alternate primary DNS suffixes.
NOTE
The Windows Internet Name Service (WINS) could be used to offset this disadvantage by resolving single-label names.
For more information about WINS, see the WINS Technical Reference (https://go.microsoft.com/fwlink/?
LinkId=102303).
When your environment requires multiple primary DNS suffixes, you must configure the DNS suffix search
order for all of the Active Directory domains in the forest appropriately.
To set the DNS suffix search order, you can use Group Policy objects or Dynamic Host Configuration
Protocol (DHCP ) Server service parameters. You can also modify the registry.
You must carefully test all applications for compatibility issues.
For more information about steps that you can take to address these disadvantages, see Create a Disjoint
Namespace (https://go.microsoft.com/fwlink/?LinkId=106638).
Planning a namespace transition
Before you modify a namespace, review the following considerations, which apply to transitions from contiguous
namespaces to disjoint namespaces (or the reverse):
Manually configured Service Principal Names (SPNs) may no longer match DNS names after a namespace
change. This can cause authentication failures.
For more information, see Service Logons Fail Due to Incorrectly Set SPNs
If you use Windows Server 2003-based computers with constrained delegation, those computers
may require additional configuration to change SPNs. For more information, see article 936628 in
the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=102306).
If you want to delegate permissions to modify SPNs to subordinate administrators, see Delegating
Authority to Modify SPNs (https://go.microsoft.com/fwlink/?LinkId=106639).
If you use Lightweight Directory Access Protocol (LDAP ) over Secure Sockets Layer (SSL ) (known as
LDAPS ) with a CA in a deployment that has domain controllers that are configured in a disjoint namespace,
you must use the appropriate Active Directory domain name and primary DNS suffix when you configure
the LDAPS certificates.
For more information about domain controller certificate requirements, see article 321051 in the Microsoft
Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=102307).
NOTE
Domain controllers that use certificates for LDAPS may require you to redeploy their certificates. When you do so,
domain controllers may not select an appropriate certificate until they are restarted. For more information about
LDAPS authentication and a related update for Windows Server 2003, see article 932834 in the Microsoft Knowledge
Base (https://go.microsoft.com/fwlink/?LinkId=102308).
Planning for disjoint namespace deployments

Take the following precautions if you deploy computers in an environment that has a disjoint namespace:
1. Notify all software vendors with whom you do business that they must test and support a disjoint
namespace. Ask them to verify that they support their applications in environments that use disjoint
namespaces.
2. Test all versions of operating systems and applications in disjoint namespace lab environments. When you
do, follow these recommendations:
a. Resolve all software issues before you deploy the software into your environment.
b. When possible, participate in beta tests of operating systems and applications that you plan to deploy
in disjoint namespaces.
3. Ensure that administrators and helpdesk staff are aware of the disjoint namespace and its impact.
4. Create a plan that makes it possible for you to transition from a disjoint namespace to a contiguous
namespace, if necessary.
5. Evangelize the importance of disjoint namespace support with operating system and application providers.
The forest owner assigns a Domain Name System (DNS ) for Active Directory Domain Services (AD DS ) owner for
the forest. The DNS for AD DS owner of the forest is a person (or group of people) who is responsible for
overseeing the deployment of the DNS for AD DS infrastructure and for making sure that (if necessary) domain
names are registered with the proper Internet authorities.
The DNS for AD DS owner is responsible for the DNS for AD DS design for the forest. If your organization is
currently operating a DNS Server service, the DNS designer for the existing DNS Server service works with the
DNS for AD DS owner to delegate the forest root DNS name to DNS servers running on domain controllers.
The DNS for AD DS owner for the forest also maintains contact with the Dynamic Host Configuration Protocol
(DHCP ) group and the DNS group of the organization and coordinates the plans of the individual DNS owners of
each domain in the forest (if any) with these groups. The DNS owner for the forest ensures that the DHCP and
DNS groups are involved in the DNS for AD DS design process so that each group is aware of the DNS design
plan and can provide input early.
If your organization already has an existing Domain Name System (DNS ) Server service, the DNS for Active
Directory Domain Services (AD DS ) owner must work with the DNS owner for your organization to integrate AD
DS into the existing infrastructure. This involves creating a DNS server and DNS client configuration.
Creating a DNS server configuration

When integrating AD DS with an existing DNS namespace, we recommend that you do the following:
Install the DNS Server service on every domain controller in the forest. This provides fault tolerance if one
of the DNS servers is unavailable. In this way, domain controllers do not need to rely on other DNS servers
for name resolution. This also simplifies the management environment because all domain controllers have
a uniform configuration.
Configure the Active Directory forest root domain controller to host the DNS zone for the Active Directory
forest.
Configure the domain controllers for each regional domain to host the DNS zones that correspond to their
Active Directory domains.
Configure the zone containing the Active Directory forest-wide locator records (that is, the
_msdcs.forestname zone) to replicate to every DNS server in the forest by using the forest-wide DNS
application directory partition.
NOTE
When the DNS Server service is installed with the Active Directory Domain Services Installation Wizard (we
recommend this option), all the previous tasks are performed automatically. For more information, see Deploying a
Windows Server 2008 Forest Root Domain.
NOTE
AD DS uses forest-wide locator records to enable replication partners to find each other and to enable clients to find
global catalog servers. AD DS stores the forest-wide locator records in the _msdcs.forestname zone. Because the
information in the zone must be widely available, this zone is replicated to all DNS servers in the forest by means of
the forest-wide DNS application directory partition.
The existing DNS structure remains intact. You do not need to move any servers or zones. You simply need to
create a delegation to your Active Directory-integrated DNS zones from your existing DNS hierarchy.
Creating the DNS client configuration

To configure DNS on client computers, the DNS for AD DS owner must specify the computer naming scheme and
how the clients will locate DNS servers. The following table lists our recommended configurations for these design
elements.
DESIGN ELEMENT CONFIGURATION
Computer naming Use default naming. When a Windows 2000, Windows XP,
Windows Server 2003, Windows Server 2008 , or Windows
Vista-based computer joins a domain, the computer assigns
itself a fully qualified domain name (FQDN) that comprises the
host name of the computer and the name of the Active
Directory domain.
Client resolver configuration Configure client computers to point to any DNS server on the
network.
NOTE
Active Directory clients and domain controllers can dynamically register their DNS names even if they are not pointing to the
DNS server that is authoritative for their names.
A computer might have a different existing DNS name if the organization previously, statically registered the
computer in DNS or if the organization previously deployed an integrated Dynamic Host Configuration Protocol
(DHCP ) solution. If your client computers already have a registered DNS name, when the domain to which they are
joined is upgraded to Windows Server 2008 AD DS, they will have two different names:
The existing DNS name
The new fully qualified domain name (FQDN )
Clients can still be located by either name. Any existing DNS, DHCP, or integrated DNS/DHCP solution is left
intact. The new primary names are created automatically and updated by means of dynamic update. They are
cleaned up automatically by means of scavenging.
If you want to take advantage of Kerberos authentication when connecting to a server running Windows 2000,
Windows Server 2003, or Windows Server 2008 , you must make sure that the client connects to the server by
using the primary name.
You can use the following tables to assist you in documenting the recursive name resolution method of your
current Domain Name System (DNS ) structure as part of the logical structure design for Windows Server Active
Directory Domain Services (AD DS ).
Root hints
NAME IPV4 ADDRESS IPV6 ADDRESS
Forwarding
NAME IPV4 ADDRESS IPV6 ADDRESS PHYSICAL LOCATION
Forest owners are responsible for creating organizational unit (OU ) designs for their domains. Creating an OU
design involves designing the OU structure, assigning the OU owner role, and creating account and resource OUs.
Initially, design your OU structure to enable delegation of administration. When the OU design is complete, you
can create additional OU structures for the application of Group Policy to the users and computers and to limit the
visibility of objects. For more information, see Designing a Group Policy Infrastructure
OU owner role
The forest owner designates an OU owner for each OU that you design for the domain. OU owners are data
managers who control a subtree of objects in Active Directory Domain Services (AD DS ). OU owners can control
how administration is delegated and how policy is applied to objects within their OU. They can also create new
subtrees and delegate administration of OUs within those subtrees.
Because OU owners do not own or control the operation of the directory service, you can separate ownership and
administration of the directory service from ownership and administration of objects, reducing the number of
service administrators who have high levels of access.
OUs provide administrative autonomy and the means to control visibility of objects in the directory. OUs provide
isolation from other data administrators, but they do not provide isolation from service administrators. Although
OU owners have control over a subtree of objects, the forest owner retains full control over all subtrees. This
enables the forest owner to correct mistakes, such as an error in an access control list (ACL ), and to reclaim
delegated subtrees when data administrators are terminated.
Account OUs and resource OUs

Account OUs contain user, group, and computer objects. Forest owners must create an OU structure to manage
these objects and then delegate control of the structure to the OU owner. If you are deploying a new AD DS
domain, create an account OU for the domain so that you can delegate control of the accounts in the domain.
Resource OUs contain resources and the accounts that are responsible for managing those resources. The forest
owner is also responsible for creating an OU structure to manage these resources and for delegating control of that
structure to the OU owner. Create resource OUs as needed based on the requirements of each group within your
organization for autonomy in the management of data and equipment.
Documenting the OU design for each domain

Assemble a team to design the OU structure that you use to delegate control over resources within the forest. The
forest owner might be involved in the design process and must approve the OU design. You might also involve at
least one service administrator to ensure that the design is valid. Other design team participants might include the
data administrators who will work on the OUs and the OU owners who will be responsible for managing them.
It is important to document your OU design. List the names of the OUs that you plan to create. And, for each OU,
document the type of OU, the OU owner, the parent OU (if applicable), and the origin of that OU.
For a worksheet to assist you in documenting your OU design, download
Deployment Kit (https://go.microsoft.com/fwlink/?LinkID=102558) and open "Identifying OUs for Each Domain"
(DSSLOGI_9.doc).
In this section
The organizational unit (OU ) structure for a domain includes the following:
A diagram of the OU hierarchy
A list of OUs
For each OU:
The purpose for the OU
A list of users or groups that have control over the OU or the objects in the OU
The type of control that users and groups have over the objects in the OU
The OU hierarchy does not need to reflect the departmental hierarchy of the organization or group. OUs are
created for a specific purpose, such as the delegation of administration, the application of Group Policy, or to limit
the visibility of objects.
You can design your OU structure to delegate administration to individuals or groups within your organization that
require the autonomy to manage their own resources and data. OUs represent administrative boundaries and
enable you to control the scope of authority of data administrators.
For example, you can create an OU called ResourceOU and use it to store all the computer accounts that belong to
the file and print servers managed by a group. Then, you can configure security on the OU so that only data
administrators in the group have access to the OU. This prevents data administrators in other groups from
tampering with the file and print server accounts.
You can further refine your OU structure by creating subtrees of OUs for specific purposes, such as the application
of Group Policy or to limit the visibility of protected objects so that only certain users can see them. For example, if
you need to apply Group Policy to a select group of users or resources, you can add those users or resources to an
OU, and then apply Group Policy to that OU. You can also use the OU hierarchy to enable further delegation of
administrative control.
While there is no technical limit to the number of levels in your OU structure, for manageability we recommend
that you limit your OU structure to a depth of no more than 10 levels. There is no technical limit to the number of
OUs on each level. Note that Active Directory Domain Services (AD DS )-enabled applications might have
restrictions on the number of characters used in the distinguished name (that is, the full Lightweight Directory
Access Protocol (LDAP ) path to the object in the directory) or on the OU depth within the hierarchy.
The OU structure in AD DS is not intended to be visible to end users. The OU structure is an administrative tool for
service administrators and for data administrators, and it is easy to change. Continue to review and update your
OU structure design to reflect changes in your administrative structure and to support policy-based administration.
You can use organizational units (OUs) to delegate the administration of objects, such as users or computers, within
the OU to a designated individual or group. To delegate administration by using an OU, place the individual or
group to which you are delegating administrative rights into a group, place the set of objects to be controlled into
an OU, and then delegate administrative tasks for the OU to that group.
Active Directory Domain Services (AD DS ) enables you to control the administrative tasks that can be delegated at
a very detailed level. For example, you can assign one group to have full control of all objects in an OU; assign
another group the rights only to create, delete, and manage user accounts in the OU; and then assign a third group
the right only to reset user account passwords. You can make these permissions inheritable so that they apply to
any OUs that are placed in subtrees of the original OU.
Default OUs and containers are created during the installation of AD DS and are controlled by service
administrators. It is best if service administrators continue to control these containers. If you need to delegate
control over objects in the directory, create additional OUs and place the objects in these OUs. Delegate control
over these OUs to the appropriate data administrators. This makes it possible to delegate control over objects in
the directory without changing the default control given to the service administrators.
The forest owner determines the level of authority that is delegated to an OU owner. This can range from the ability
to create and manipulate objects within the OU to only being allowed to control a single attribute of a single type of
object in the OU. Granting a user the ability to create an object in the OU implicitly grants that user the ability to
manipulate any attribute of any object that the user creates. In addition, if the object that is created is a container,
the user implicitly has the ability to create and manipulate any objects that are placed in the container.
In this section
Delegating Administration of Default Containers and OUs
Delegating Administration of Account OUs and Resource OUs
Delegating Administration of Default Containers and
OUs
Every Active Directory domain contains a standard set of containers and organizational units (OUs) that are created
during the installation of Active Directory Domain Services (AD DS ). These include the following:
Domain container, which serves as the root container to the hierarchy
Built-in container, which holds the default service administrator accounts
Users container, which is the default location for new user accounts and groups created in the domain
Computers container, which is the default location for new computer accounts created in the domain
Domain Controllers OU, which is the default location for the computer accounts for domain controllers
computer accounts
The forest owner controls these default containers and OUs.
Domain container
The domain container is the root container of the hierarchy of a domain. Changes to the policies or the access
control list (ACL ) on this container can potentially have domain-wide impact. Do not delegate control of this
container; it must be controlled by the service administrators.
Users and computers containers

When you perform an in-place domain upgrade from Windows Server 2003 to Windows Server 2008 , existing
users and computers are automatically placed into the users and the computers containers. If you are creating a
new Active Directory domain, the users and computers containers are the default locations for all new user
accounts and non-domain-controller computer accounts in the domain.
IMPORTANT
If you need to delegate control over users or computers, do not modify the default settings on the users and computers
containers. Instead, create new OUs (as needed) and move the user and computer objects from their default containers and
into the new OUs. Delegate control over the new OUs, as needed. We recommend that you not modify who controls the
default containers.
Also, you cannot apply Group Policy settings to the default users and computers containers. To apply Group Policy
to users and computers, create new OUs and move the user and computer objects into those OUs. Apply the
Group Policy settings to the new OUs.
Optionally, you can redirect the creation of objects that are placed in the default containers to be placed in
containers of your choice.
Well-known users and groups and built-in accounts

By default, several well-known users and groups and built-in accounts are created in a new domain. We
recommend that management of these accounts remains under the control of the service administrators. Do not
delegate management of these accounts to an individual who is not a service administrator. The following table lists
the well-known users and groups and built-in accounts that need to remain under the control of the service
administrators.
WELL-KNOWN USERS AND GROUPS BUILT-IN ACCOUNTS
Cert Publishers Administrator
Domain Controllers Guest
Group Policy Creator Owners Guests
KRBTGT Account Operators
Domain Guests Administrators
Administrator Backup Operators
Domain Admins Incoming Forest Trust Builders
Schema Admins (forest root domain only) Print Operators
Enterprise Admins (forest root domain only) Pre-Windows 2000 Compatible Access
Domain Users Server Operators
Users
Domain Controller OU
When domain controllers are added to the domain, their computer objects are automatically added to the Domain
Controller OU. This OU has a default set of policies applied to it. To ensure that these policies are applied uniformly
to all domain controllers, we recommend that you not move the computer objects of the domain controllers out of
this OU. Failure to apply the default policies can cause a domain controller to fail to function properly.
By default, the service administrators control this OU. Do not delegate control of this OU to individuals other than
the service administrators.
Delegating Administration of Account OUs and
Resource OUs
Account organizational units (OUs) contain user, group, and computer objects. Resource OUs contain resources
and the accounts that are responsible for managing those resources. The forest owner is responsible for creating an
OU structure to manage these objects and resources and for delegating control of that structure to the OU owner.
Delegating administration of account OUs

Delegate an account OU structure to data administrators if they need to create and modify user, group, and
computer objects. The account OU structure is a subtree of OUs for each account type that must be independently
controlled. For example, the OU owner can delegate specific control to various data administrators over child OUs
in an account OU for users, computers, groups, and service accounts.
The following illustration shows one example of an account OU structure.
The following table lists and describes the possible child OUs that you can create in an account OU structure.
OU PURPOSE
Users Contains user accounts for nonadministrative personnel.

OU PURPOSE
Service Accounts Some services that require access to network resources run as
user accounts. This OU is created to separate service user
accounts from the user accounts contained in the users OU.
Also, placing the different types of user accounts in separate
OUs enables you to manage them according to their specific
administrative requirements.
Computers Contains accounts for computers other than domain

controllers.
Groups Contains groups of all types except for administrative groups,

which are managed separately.
Admins Contains user and group accounts for data administrators in

the account OU structure to allow them to be managed
separately from regular users. Enable auditing for this OU so
that you can track changes to administrative users and
groups.
The following illustration shows one example of an administrative group design for an account OU structure.
Groups that manage the child OUs are granted full control only over the specific class of objects that they are
responsible for managing.
The types of groups that you use to delegate control within an OU structure are based on where the accounts are
located relative to the OU structure that is to be managed. If the admin user accounts and the OU structure all exist
within a single domain, the groups that you create to use for delegation must be global groups. If your organization
has a department that manages its own user accounts and exists in more than one geographical region, you might
have a group of data administrators who are responsible for managing account OUs in more than one domain. If
the accounts of the data administrators all exist in a single domain and you have OU structures in multiple domains
to which you need to delegate control, make those administrative accounts members of global groups and delegate
control of the OU structures in each domain to those global groups. If the data administrators accounts to which
you delegate control of an OU structure come from multiple domains, you must use a universal group. Universal
groups can contain users from different domains, and therefore, they can be used to delegate control in multiple
domains.
Delegating administration of resource OUs

Resource OUs are used to manage access to resources. The resource OU owner creates computer accounts for
servers that are joined to the domain that include resources such as file shares, databases, and printers. The
resource OU owner also creates groups to control access to those resources.
The following illustration shows the two possible locations for the resource OU.
The resource OU can be located under the domain root or as a child OU of the corresponding account OU in the
OU administrative hierarchy. Resource OUs do not have any standard child OUs. Computers and groups are placed
directly in the resource OU.
The resource OU owner owns the objects within the OU but does not own the OU container itself. Resource OU
owners manage only computer and group objects; they cannot create other classes of objects within the OU, and
they cannot create child OUs.
NOTE
The creator or owner of an object has the ability to set the access control list (ACL) on the object regardless of the
permissions that are inherited from the parent container. If a resource OU owner can reset the ACL on an OU, that owner can
create any class of object in the OU, including users. For this reason, resource OU owners are not permitted to create OUs.
For each resource OU in the domain, create a global group to represent the data administrators who are
responsible for managing the content of the OU. This group has full control over the group and computer objects
in the OU but not over the OU container itself.
The following illustration shows the administrative group design for a resource OU.
Placing the computer accounts into a resource OU gives the OU owner control over the account objects but does
not make the OU owner an administrator of the computers. In an Active Directory domain, the Domain Admins
group is, by default, placed in the local Administrators group on all computers. That is, service administrators have
control over those computers. If resource OU owners require administrative control over the computers in their
OUs, the forest owner can apply a Restricted Groups Group Policy to make the resource OU owner a member of
the Administrators group on the computers in that OU.
Finding Additional Resources for Logical Structure
Design
You can find Additional Resources for Logical Structure Design in the following documentation about Active
Directory Domain Services (AD DS ):
For more information about designing the site topology, see Designing the Site Topology for Windows
Server 2008 AD DS.
For worksheets to assist you in documenting the proposed forest, domain, Domain Name System (DNS )
infrastructure, and organizational unit (OU ) design, download
Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip from Job Aids for Windows
Server 2003 Deployment Kit (https://go.microsoft.com/fwlink/?LinkID=102558).
For more information about delegated authentication and constrained delegation, see Delegating
authentication (https://go.microsoft.com/fwlink/?LinkID=106614).
For more information about configuring firewalls for use with AD DS, see Active Directory in Networks
Segmented by Firewalls (https://go.microsoft.com/fwlink/?LinkId=37928).
For more information about upgrading Active Directory domains to Windows Server 2008 , see Upgrading
Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains.
For more information about restructuring AD DS domains within and between forests, see Active Directory
Migration Tool version 3.1 Migration Guide (https://go.microsoft.com/fwlink/?LinkId=93678).
For more information about deploying a forest root domain, see Deploying a Windows Server 2008 Forest
Root Domain.
For more information about deploying DNS, see Deploying Domain Name System (DNS )
For more information about the DNS hierarchy and name resolution process, see the DNS Technical
Reference (https://go.microsoft.com/fwlink/?LinkId=106636). For more information about how DNS
supports AD DS, see the DNS Support for Active Directory Technical Reference
For more information about WINS, see the WINS Technical Reference (https://go.microsoft.com/fwlink/?
LinkId=106661).
For more information about creating a disjoint namespace, see Create a Disjoint Namespace
For more information about setting Service Principal Names (SPNs), see Service Logons Fail Due to
Incorrectly Set SPNs (https://go.microsoft.com/fwlink/?LinkId=102304).
For more information about how to delegate permissions to modify SPNs to subordinate administrators,
see Delegating Authority to Modify SPNs (https://go.microsoft.com/fwlink/?LinkID=106639).
For more information about domain controller certificate requirements, see article 321051 in the Microsoft
For more information about Lightweight Directory Access Protocol (LDAP ) over Secure Sockets Layer (SSL )
(LDAPS ) authentication and a related update for Windows Server 2003, see article 932834 in the Microsoft
For more information about Group Policy infrastructure, see Designing a Group Policy Infrastructure
For more information about read-only domain controllers (RODCs), see AD DS: Read-Only Domain
Controllers (https://go.microsoft.com/fwlink/?LinkID=106616).
For more information about fine-grained password and account lockout policies, see the Step-by-Step Guide
for Fine-Grained Password and Account Lockout Policy Configuration (https://go.microsoft.com/fwlink/?
LinkID=91477).
For more information about naming conventions in AD DS, see article 909264 in the Microsoft Knowledge
Base (https://go.microsoft.com/fwlink/?LinkID=106629).
Designing the Site Topology
A directory service site topology is a logical representation of your physical network. Designing a site topology for
Active Directory Domain Services (AD DS ) involves planning for domain controller placement and designing sites,
subnets, site links, and site link bridges to ensure efficient routing of query and replication traffic.
Designing a site topology helps you efficiently route client queries and Active Directory replication traffic. A well-
designed site topology helps your organization achieve the following benefits:
Minimize the cost of replicating Active Directory data.
Minimize administrative efforts that are required to maintain the site topology.
Schedule replication that enables locations with slow or dial-up network links to replicate Active Directory
data during off-peak hours.
Optimize the ability of client computers to locate the nearest resources, such as domain controllers and
Distributed File System (DFS ) servers. This helps to reduce network traffic over slow wide area network
(WAN ) links, improve logon and logoff processes, and speed up file download operations.
Before you begin to design your site topology, you must understand your physical network structure. In addition,
you must first design your Active Directory logical structure, including the administrative hierarchy, forest plan, and
domain plan for each forest. You must also complete your Domain Name System (DNS ) infrastructure design for
AD DS. For more information about designing your Active Directory logical structure and DNS infrastructure, see
Designing the Logical Structure for Windows Server 2008 AD DS.
After you complete your site topology design, you must verify that your domain controllers meet the hardware
requirements for Windows Server 2008 Standard , Windows Server 2008 Enterprise , and Windows Server 2008
Datacenter .
In this guide
Finding Additional Resources for Windows Server 2008 Active Directory Site Topology Design
Your site topology significantly affects the performance of your network and the ability of your users to access
network resources. Before you begin to design your site topology, become familiar with the functions for sites in
Windows Server 2008 , the different network topologies that organizations commonly use, the role of the site
topology owner, and some Active Directory replication concepts.
In this section
Site Functions
Site Functions
Windows Server 2008 uses site information for many purposes, including routing replication, client affinity, system
volume (SYSVOL ) replication, Distributed File System Namespaces (DFSN ), and service location.
Routing replication
Active Directory Domain Services (AD DS ) uses a multimaster, store-and-forward method of replication. A domain
controller communicates directory changes to a second domain controller, which then communicates to a third, and
so on, until all domain controllers have received the change. To achieve the best balance between reducing
replication latency and reducing traffic, site topology controls Active Directory replication by distinguishing
between replication that occurs within a site and replication that occurs between sites.
Within sites, replication is optimized for speed, data updates trigger replication, and the data is sent without the
overhead required by data compression. Conversely, replication between sites is compressed to minimize the cost
of transmission over wide area network (WAN ) links. When replication occurs between sites, a single domain
controller per domain at each site collects and stores the directory changes and communicates them at a scheduled
time to a domain controller in another site.
Client affinity
Domain controllers use site information to inform Active Directory clients about domain controllers present within
the closest site as the client. For example, consider a client in the Seattle site that does not know its site affiliation
and contacts a domain controller from the Atlanta site. Based on the IP address of the client, the domain controller
in Atlanta determines which site the client is actually from and sends the site information back to the client. The
domain controller also informs the client whether the chosen domain controller is the closest one to it. The client
caches the site information provided by the domain controller in Atlanta, queries for the site-specific service (SRV )
resource record (a Domain Name System (DNS ) resource record used to locate domain controllers for AD DS ) and
thereby finds a domain controller within the same site.
By finding a domain controller in the same site, the client avoids communications over WAN links. If no domain
controllers are located at the client site, a domain controller that has the lowest cost connections relative to other
connected sites advertises itself (registers a site-specific service (SRV ) resource record in DNS ) in the site that does
not have a domain controller. The domain controllers that are published in DNS are those from the closest site as
defined by the site topology. This process ensures that every site has a preferred domain controller for
authentication.
For more information about the process of locating a domain controller, see Active Directory Collection
SYSVOL replication
SYSVOL is a collection of folders in the file system that exists on each domain controller in a domain. The SYSVOL
folders provide a default Active Directory location for files that must be replicated throughout a domain, including
Group Policy objects (GPOs), startup and shutdown scripts, and logon and logoff scripts. Windows Server 2008
can use the File Replication Service (FRS ) or Distributed File System Replication (DFSR ) to replicate changes made
to the SYSVOL folders from one domain controller to other domain controllers. FRS and DFSR replicate these
changes according to the schedule that you create during your site topology design.
DFSN
DFSN uses site information to direct a client to the server that is hosting the requested data within the site. If
DFSN does not find a copy of the data within the same site as the client, DFSN uses the site information in AD DS
to determine which file server that has DFSN shared data is closest to the client.
Service location
By publishing services such as file and print services in AD DS, you allow Active Directory clients to locate the
requested service within the same or nearest site. Print services use the location attribute stored in AD DS to let
users browse for printers by location without knowing their precise location. For more information about designing
and deploying print servers, see Designing and Deploying Print Servers (https://go.microsoft.com/fwlink/?
LinkId=107041).
The administrator who manages the site topology is known as the site topology owner. The site topology owner
understands the conditions of the network between sites and has the authority to change settings in Active
Directory Domain Services (AD DS ) to implement changes to the site topology. Changes to the site topology affect
changes in the replication topology. The site topology owner's responsibilities include:
Controlling changes to the site topology if network connectivity changes.
Obtaining and maintaining information about network connections and routers from the network group.
The site topology owner must maintain a list of subnet addresses, subnet masks, and the location to which
each belongs. The site topology owner must also understand any issues about network speed and capacity
that affect site topology to effectively set costs for site links.
Moving Active Directory server objects representing domain controllers between sites if a domain
controller's IP address changes to a different subnet in a different site, or if the subnet itself is assigned to a
different site. In either case, the site topology owner must manually move the Active Directory server object
of the domain controller to the new site.
Before designing site topology, become familiar with some Active Directory replication concepts.
Connection object
KCC
Failover functionality
Subnet
Site
Site link
Site link bridge
Site link transitivity
Global catalog server
Universal group membership caching
Connection object
A connection object is an Active Directory object that represents a replication connection from a source domain
controller to a destination domain controller. A domain controller is a member of a single site and is represented in
the site by a server object in Active Directory Domain Services (AD DS ). Each server object has a child NTDS
Settings object that represents the replicating domain controller in the site.
The connection object is a child of the NTDS Settings object on the destination server. For replication to occur
between two domain controllers, the server object of one must have a connection object that represents inbound
replication from the other. All replication connections for a domain controller are stored as connection objects
under the NTDS Settings object. The connection object identifies the replication source server, contains a
replication schedule, and specifies a replication transport.
The Knowledge Consistency Checker (KCC ) creates connection objects automatically, but they can also be created
manually. Connection objects created by the KCC appear in the Active Directory Sites and Services snap-in as and
are considered adequate under normal operating conditions. Connection objects created by an administrator are
manually created connection objects. A manually created connection object is identified by the name assigned by
the administrator when it was created. When you modify an connection object, you convert it into an
administratively modified connection object and the object appears in the form of a GUID. The KCC does not make
changes to manual or modified connection objects.
KCC
The KCC is a built-in process that runs on all domain controllers and generates replication topology for the Active
Directory forest. The KCC creates separate replication topologies depending on whether replication is occurring
within a site (intrasite) or between sites (intersite). The KCC also dynamically adjusts the topology to accommodate
the addition of new domain controllers, the removal of existing domain controllers, the movement of domain
controllers to and from sites, changing costs and schedules, and domain controllers that are temporarily
unavailable or in an error state.
Within a site, the connections between writable domain controllers are always arranged in a bidirectional ring, with
additional shortcut connections to reduce latency in large sites. On the other hand, the intersite topology is a
layering of spanning trees, which means one intersite connection exists between any two sites for each directory
partition and generally does not contain shortcut connections. For more information about spanning trees and
Active Directory replication topology, see Active Directory Replication Topology Technical Reference
On each domain controller, the KCC creates replication routes by creating one-way inbound connection objects that
define connections from other domain controllers. For domain controllers in the same site, the KCC creates
connection objects automatically without administrative intervention. When you have more than one site, you
configure site links between sites, and a single KCC in each site automatically creates connections between sites as
well.
KCC improvements for Windows Server 2008 RODCs
There are a number of KCC improvements to accommodate the newly available read-only domain controller
(RODC ) in Windows Server 2008 . A typical deployment scenario for RODC is the branch office. The Active
Directory replication topology most commonly deployed in this scenario is based on a hub-and-spoke design,
where branch domain controllers in multiple sites replicate with a small number of bridgehead servers in a hub site.
One of the benefits of deploying RODC in this scenario is unidirectional replication. Bridgehead servers are not
required to replicate from the RODC, which reduces administration and network usage.
However, one administrative challenge highlighted by the hub-spoke topology on previous versions of the
Windows Server operating system is that after adding a new bridgehead domain controller in the hub, there is no
automatic mechanism to redistribute the replication connections between the branch domain controllers and the
hub domain controllers to take advantage of the new hub domain controller.
For Windows Server 2003 domain controllers, you can rebalance the workload by using a tool such as Adlb.exe
from the Windows Server 2003 Branch Office Deployment Guide (https://go.microsoft.com/fwlink/?
LinkID=28523).
For Windows Server 2008 RODCs, normal functioning of the KCC provides some rebalancing, which eliminates the
need to use an additional tool such as Adlb.exe. The new functionality is enabled by default. You can disable it by
adding the following registry key set on the RODC:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
"Random BH Loadbalancing Allowed"
1 = Enabled (default), 0 = Disabled
For more information about how these KCC improvements work, see Planning and Deploying Active Directory
Domain Services for Branch Offices (https://go.microsoft.com/fwlink/?LinkId=107114).
Failover functionality
Sites ensure that replication is routed around network failures and offline domain controllers. The KCC runs at
specified intervals to adjust the replication topology for changes that occur in AD DS, such as when new domain
controllers are added and new sites are created. The KCC reviews the replication status of existing connections to
determine if any connections are not working. If a connection is not working due to a failed domain controller, the
KCC automatically builds temporary connections to other replication partners (if available) to ensure that
replication occurs. If all the domain controllers in a site are unavailable, the KCC automatically creates replication
connections between domain controllers from another site.
Subnet
A subnet is a segment of a TCP/IP network to which a set of logical IP addresses are assigned. Subnets group
computers in a way that identifies their physical proximity on the network. Subnet objects in AD DS identify the
network addresses that are used to map computers to sites.
Site
Sites are Active Directory objects that represent one or more TCP/IP subnets with highly reliable and fast network
connections. Site information allows administrators to configure Active Directory access and replication to optimize
usage of the physical network. Site objects are associated with a set of subnets, and each domain controller in a
forest is associated with an Active Directory site according to its IP address. Sites can host domain controllers from
more than one domain, and a domain can be represented in more than one site.
Site link
Site links are Active Directory objects that represent logical paths that the KCC uses to establish a connection for
Active Directory replication. A site link object represents a set of sites that can communicate at uniform cost
through a specified intersite transport.
All sites contained within the site link are considered to be connected by means of the same network type. Sites
must be manually linked to other sites by using site links so that domain controllers in one site can replicate
directory changes from domain controllers in another site. Because site links do not correspond to the actual path
taken by network packets on the physical network during replication, you do not need to create redundant site links
to improve Active Directory replication efficiency.
When two sites are connected by a site link, the replication system automatically creates connections between
specific domain controllers in each site that are called bridgehead servers. In Windows Server 2008 , all domain
controllers in a site that host the same directory partition are candidates for being selected as bridgehead servers.
The replication connections created by the KCC are randomly distributed among all candidate bridgehead servers
in a site to share the replication workload. By default, the randomized selection process takes place only once, when
connection objects are first added to the site.
Site link bridge

A site link bridge is an Active Directory object that represents a set of site links, all of whose sites can communicate
by using a common transport. Site link bridges enable domain controllers that are not directly connected by means
of a communication link to replicate with each other. Typically, a site link bridge corresponds to a router (or a set of
routers) on an IP network.
By default, the KCC can form a transitive route through any and all site links that have some sites in common. If this
behavior is disabled, each site link represents its own distinct and isolated network. Sets of site links that can be
treated as a single route are expressed through a site link bridge. Each bridge represents an isolated
communication environment for network traffic.
Site link bridges are a mechanism to logically represent transitive physical connectivity between sites. A site link
bridge allows the KCC to use any combination of the included site links to determine the least expensive route to
interconnect directory partitions held in those sites. The site link bridge does not provide actual connectivity to the
domain controllers. If the site link bridge is removed, replication over the combined site links will continue until the
KCC removes the links.
Site link bridges are only necessary if a site contains a domain controller hosting a directory partition that is not
also hosted on a domain controller in an adjacent site, but a domain controller hosting that directory partition is
located in one or more other sites in the forest. Adjacent sites are defined as any two or more sites included in a
single site link.
A site link bridge creates a logical connection between two site links, providing a transitive path between two
disconnected sites by using an interim site. For the purposes of the intersite topology generator (ISTG ), the bridge
implies physical connectivity by using the interim site. The bridge does not imply that a domain controller in the
interim site will provide the replication path. However, this would be the case if the interim site contained a domain
controller that hosted the directory partition to be replicated, in which case a site link bridge is not required.
The cost of each site link is added, creating a summed cost for the resulting path. The site link bridge would be used
if the interim site does not contain a domain controller hosting the directory partition and a lower cost link does not
exist. If the interim site contained a domain controller that hosts the directory partition, two disconnected sites
would set up replication connections to the interim domain controller and not use the bridge.
Site link transitivity

By default all site links are transitive, or "bridged." When site links are bridged and the schedules overlap, the KCC
creates replication connections that determine domain controller replication partners between sites, where the sites
are not directly connected by site links but are connected transitively through a set of common sites. This means
that you can connect any site to any other site through a combination of site links.
In general, for a fully routed network, you do not need to create any site link bridges unless you want to control the
flow of replication changes. If your network is not fully routed, site link bridges should be created to avoid
impossible replication attempts. All site links for a specific transport implicitly belong to a single site link bridge for
that transport. The default bridging for site links occurs automatically, and no Active Directory object represents
that bridge. The Bridge all site links setting, found in the properties of both the IP and Simple Mail Transfer
Protocol (SMTP ) intersite transport containers, implements automatic site link bridging.
NOTE
SMTP replication will not be supported in future versions of AD DS; therefore, creating site links objects in the SMTP container
is not recommended.
Global catalog server

A global catalog server is a domain controller that stores information about all objects in the forest, so that
applications can search AD DS without referring to specific domain controllers that store the requested data. Like
all domain controllers, a global catalog server stores full, writable replicas of the schema and configuration
directory partitions and a full, writable replica of the domain directory partition for the domain that it is hosting. In
addition, a global catalog server stores a partial, read-only replica of every other domain in the forest. Partial, read-
only domain replicas contain every object in the domain but only a subset of the attributes (those attributes that are
most commonly used for searching the object).
Universal group membership caching

Universal group membership caching allows the domain controller to cache universal group membership
information for users. You can enable domain controllers that are running Windows Server 2008 to cache universal
group memberships by using the Active Directory Sites and Services snap-in.
Enabling universal group membership caching eliminates the need for a global catalog server at every site in a
domain, which minimizes network bandwidth usage because a domain controller does not need to replicate all of
the objects located in the forest. It also reduces logon times because the authenticating domain controllers do not
always need to access a global catalog to obtain universal group membership information. For more information
about when to use universal group membership caching, see Planning Global Catalog Server Placement.
The first step in designing an effective site topology in Active Directory Domain Services (AD DS ) is to consult your
organization's networking group to collect information and communicate with them regularly about your physical
network topology.
Creating a location map

Create a location map that represents the physical network infrastructure of your organization. On the location
map, identify the geographic locations that contain groups of computers with internal connectivity of 10 megabits
per second (Mbps) or higher (local area network (LAN ) speed or better).
Listing communication links and available bandwidth

After creating a location map, document the type of communication link, its link speed, and the available bandwidth
between each location. Obtain a wide area network (WAN ) topology from your networking group. For a list of
common WAN circuit types and their bandwidths, see "Determining the cost" section in Creating a Site Link
Design. You will need this information to create site links later in the site topology design process.
Bandwidth refers to the amount of data that you can transmit across a communication channel in a given amount
of time. Available bandwidth refers to the amount of bandwidth actually available for use by AD DS. You can obtain
available bandwidth information from your networking group, or you can analyze traffic on each link by using a
protocol analyzer such as Network Monitor. For information about installing Network Monitor, see the article
Monitoring network traffic.
Document each location and the other locations that are linked to it. In addition, record the type of communication
link and its available bandwidth. For a worksheet to assist you in listing communication links and available
bandwidth, see Job Aids for Windows Server 2003 Deployment Kit, download
Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip, and open "Geographic Locations and
Communication Links" (DSSTOPO_1.doc).
Listing IP subnets within each location

After you document the communication links and the available bandwidth between each location, record the IP
subnets within each location. If you do not already know the subnet mask and IP address within each location,
consult your networking group.
AD DS associates a workstation with a site by comparing the workstation's IP address with the subnets that are
associated with each site. As you add domain controllers to a domain, AD DS also examines their IP addresses and
places them in the most appropriate site.
For a worksheet to assist you in listing the IP subnets within each location, see Job Aids for Windows Server 2003
Deployment Kit, download Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip, and open
"Locations and Subnets" (DSSTOPO_2.doc).
NOTE
In addition to IP version 4 (IPv4) addresses, Windows Server also supports IP version 6 (IPv6) subnet prefixes. For a
worksheet to assist you in listing the IPv6 subnet prefixes, see Appendix A: Locations and subnet prefixes.
Listing domains and number of users for each location

The number of users for each regional domain that is represented in a location is one of the factors that determine
the placement of regional domain controllers and global catalog servers, which is the next step in the site topology
design process. For example, plan to place a regional domain controller in a location that contains more than 100
regional domain users so they can still log on to the domain if the WAN link fails.
Record the locations, the domains that are represented in each location, and the number of users for each domain
that is represented in each location. For a worksheet to assist you in listing the domains and the number of users
that are represented in each location, see Job Aids for Windows Server 2003 Deployment Kit, download
Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip, and open "Domains and Users in Each
Location" (DSSTOPO_3.doc).
After you have gathered all of the network information that will be used to design your site topology, plan where
you want to place domain controllers, including forest root domain controllers, regional domain controllers,
operations master role holders, and global catalog servers.
In Windows Server 2008 , you can also take advantage of read-only domain controllers (RODCs). An RODC is a
new type of domain controller that hosts read-only partitions of the Active Directory database. Except for account
passwords, an RODC holds all the Active Directory objects and attributes that a writable domain controller holds.
However, changes cannot be made to the database that is stored on the RODC. Changes must be made on a
writable domain controller and then replicated back to the RODC.
An RODC is designed primarily to be deployed in remote or branch office environments, which typically have
relatively few users, poor physical security, relatively poor network bandwidth to a hub site, and personnel with
limited knowledge of information technology (IT). Deploying RODCs results in improved security and more
efficient access to network resources. For more information about RODC features, see AD DS: Read-Only Domain
Controllers (https://go.microsoft.com/fwlink/?LinkID=106616). For information about how to deploy an RODC,
see the Step-by-Step Guide for Read-Only Domain Controllers (https://go.microsoft.com/fwlink/?LinkID=92728).
NOTE
This guide does not explain how you determine the proper number of domain controllers and the domain controller hardware
requirements for each domain that is represented in each site.
In this section
Planning Regional Domain Controller Placement
Forest root domain controllers are needed to create trust paths for clients that need to access resources in domains
other than their own. Place forest root domain controllers in hub locations and at locations that host datacenters. If
users in a given location need to access resources from other domains in the same location, and the network
availability between the datacenter and the user location is unreliable, you can either add a forest root domain
controller in the location or create a shortcut trust between the two domains. It is more cost efficient to create a
shortcut trust between the domains unless you have other reasons to place a forest root domain controller in that
location.
Shortcut trusts help to optimize authentication requests made from users located in either domain. For more
information about shortcut trusts between domains, see the article Understanding When to Create a Shortcut
Trust.
For a worksheet to assist you in documenting your forest root domain controller placement, see Job Aids for
Windows Server 2003 Deployment Kit, download
Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip, and open "Domain Controller
Placement" (DSSTOPO_4.doc).
You will need to refer to this information when you create the forest root domain. For more information about
deploying the forest root domain, see Deploying a Windows Server 2008 Forest Root Domain.
Planning Regional Domain Controller Placement
To ensure cost efficiency, plan to place as few regional domain controllers as possible. First, review the "Geographic
Locations and Communication Links" (DSSTOPO_1.doc) worksheet used in Collecting Network Information to
determine whether a location is a hub.
Plan to place regional domain controllers for each domain that is represented in each hub location. After you place
regional domain controllers in all hub locations, evaluate the need for placing regional domain controllers at
satellite locations. Eliminating unnecessary regional domain controllers from satellite locations reduces the support
costs required to maintain a remote server infrastructure.
In addition, ensure the physical security of domain controllers in hub and satellite locations so that unauthorized
personnel cannot access them. Do not place writable domain controllers in hub and satellite locations in which you
cannot guarantee the physical security of the domain controller. A person who has physical access to a writable
domain controller can attack the system by:
Accessing physical disks by starting an alternate operating system on a domain controller.
Removing (and possibly replacing) physical disks on a domain controller.
Obtaining and manipulating a copy of a domain controller system state backup.
Add writable regional domain controllers only to locations in which you can guarantee their physical security.
In locations with inadequate physical security, deploying a read-only domain controller (RODC ) is the
recommended solution. Except for account passwords, an RODC holds all the Active Directory objects and
attributes that a writable domain controller holds. However, changes cannot be made to the database that is stored
on the RODC. Changes must be made on a writable domain controller and then replicated back to the RODC.
To authenticate client logons and access to local file servers, most organizations place regional domain controllers
for all regional domains that are represented in a given location. However, you must consider many variables when
evaluating whether a business location requires its clients to have local authentication or the clients can rely on
authentication and query over a wide area network (WAN ) link. The following illustration shows how to determine
whether to place domain controllers at satellite locations.
Onsite technical expertise availability
Domain controllers need to be managed continuously for various reasons. Place a regional domain controller only
in locations that include personnel who can administer the domain controller, or be sure that the domain controller
can be managed remotely.
In branch office environments with typically poor physical security and personnel with little information technology
knowledge, deploying an RODC is often the recommended solution. Local administrative permissions for an RODC
can be delegated to any domain user without granting that user any user rights for the domain or other domain
controllers. This permits a local branch user to log on to an RODC and perform maintenance work on the server,
such as upgrading a driver. However, the branch user cannot log on to any other domain controller or perform any
other administrative task in the domain. In this way, the branch user can be delegated the ability to effectively
manage the RODC in the branch office without compromising the security of the rest of the domain or the forest.
WAN link availability

WAN links that experience frequent outages can cause significant productivity loss to users if the location does not
include a domain controller that can authenticate the users. If your WAN link availability is not 100 percent and
your remote sites cannot tolerate a service outage, place a regional domain controller in locations where the users
require the ability to log on or exchange server access when the WAN link is down.
Authentication availability
Certain organizations, such as banks, require that users be authenticated at all times. Place a regional domain
controller in a location where the WAN link availability is not 100 percent but users require authentication at all
times.
Logon performance over WAN links

If your WAN link availability is highly reliable, placing a domain controller at the location depends on the logon
performance requirements over the WAN link. Factors that influence logon performance over the WAN include link
speed and available bandwidth, number of users and usage profiles, and the amount of logon network traffic versus
replication traffic.
WAN link speed and bandwidth utilization
The activities of a single user can congest a slow WAN link. Place a domain controller at a location if logon
performance over the WAN link is unacceptable.
The average percentage of bandwidth utilization indicates how congested a network link is. If a network link has
average bandwidth utilization that is greater than an acceptable value, place a domain controller at that location.
Number of users and usage profiles
The number of users and their usage profiles at a given location can help determine whether you need to place
regional domain controllers at that location. To avoid productivity loss if a WAN link fails, place a regional domain
controller at a location that has 100 or more users.
The usage profiles indicate how the users use the network resources. You do not need to place a domain controller
in a location that contains only a few users who do not frequently access network resources.
Logon network traffic vs. replication traffic
If a domain controller is not available within the same location as the Active Directory client, the client creates logon
traffic on the network. The amount of logon network traffic that is created on the physical network is influenced by
several factors, including group memberships; number and size of Group Policy objects (GPOs); logon scripts; and
features such as offline folders, folder redirection, and roaming profiles.
On the other hand, a domain controller that is placed at a given location generates replication traffic on the
network. The frequency and amount of updates made on the partitions hosted on the domain controllers influence
the amount of replication traffic that is created on the network. The different types of updates that can be made on
the partitions hosted on the domain controllers include adding or changing users and user attributes, changing
passwords, and adding or changing global groups, printers, or volumes.
To determine if you need to place a regional domain controller at a location, compare the cost of logon traffic
created by a location without a domain controller versus the cost of replication traffic created by placing a domain
controller at the location.
For example, consider a network that has branch offices that are connected through slow links to the headquarters
and in which domain controllers can easily be added. If the daily logon and directory lookup traffic of a few remote
site users causes more network traffic than replicating all company data to the branch, consider adding a domain
controller to the branch.
If reducing the cost of maintaining domain controllers is more important than network traffic, either centralize the
domain controllers for that domain and do not place any regional domain controllers at the location or consider
placing RODCs at the location.
For a worksheet to assist you in documenting the placement of regional domain controllers and the number of
users for each domain that is represented in each location, see Job Aids for Windows Server 2003 Deployment Kit,
download Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip, and open "Domain Controller
Placement" (DSSTOPO_4.doc).
You will need to refer to the information about locations in which you need to place regional domain controllers
when you deploy regional domains. For more information about deploying regional domains, see Deploying
Windows Server 2008 Regional Domains.
Global catalog placement requires planning except if you have a single-domain forest. In a single-domain forest,
configure all domain controllers as global catalog servers. Because every domain controller stores the only domain
directory partition in the forest, configuring each domain controller as a global catalog server does not require any
additional disk space usage, CPU usage, or replication traffic. In a single-domain forest, all domain controllers act as
virtual global catalog servers; that is, they can all respond to any authentication or service request. This special
condition for single-domain forests is by design. Authentication requests do not require contacting a global catalog
server as they do when there are multiple domains, and a user can be a member of a universal group that exists in
a different domain. However, only domain controllers that are designated as global catalog servers can respond to
global catalog queries on the global catalog port 3268. To simplify administration in this scenario and to ensure
consistent responses, designating all domain controllers as global catalog servers eliminates the concern about
which domain controllers can respond to global catalog queries. Specifically, any time a user uses Start\Search\For
People or Find Printers or expands Universal Groups, these requests go only to the global catalog.
In multiple-domain forests, global catalog servers facilitate user logon requests and forest-wide searches. The
following illustration shows how to determine which locations require global catalog servers.
In most cases, it is recommended that you include the global catalog when you install new domain controllers. The
following exceptions apply:
Limited bandwidth: In remote sites, if the wide area network (WAN ) link between the remote site and the hub
site is limited, you can use universal group membership caching in the remote site to accommodate the logon
needs of users in the site.
Infrastructure operations master role incompatibility: Do not place the global catalog on a domain controller
that hosts the infrastructure operations master role in the domain unless all domain controllers in the domain
are global catalog servers or the forest has only one domain.
Adding global catalog servers based on application requirements

Certain applications, such as Microsoft Exchange, Message Queuing (also known as MSMQ ), and applications
using DCOM do not deliver adequate response over latent WAN links and therefore need a highly available global
catalog infrastructure to provide low query latency. Determine whether any applications that perform poorly over a
slow WAN link are running in locations or whether the locations require Microsoft Exchange Server. If your
locations include applications that do not deliver adequate response over a WAN link, you must place a global
catalog server at the location to reduce query latency.
NOTE
Read-only domain controllers (RODCs) can be promoted successfully to global catalog server status. However, certain
directory-enabled applications cannot support an RODC as a global catalog server. For example, no version of Microsoft
Exchange Server uses RODCs. However, Microsoft Exchange Server works in environments that include RODCs, as long as
there are writable domain controllers available. Exchange Server 2007 effectively ignores RODCs. Exchange Server 2003 also
ignores RODCs in default conditions where Exchange components automatically detect available domain controllers. No
changes were made to Exchange Server 2003 to make it aware of read-only directory servers. Therefore, trying to force
Exchange Server 2003 services and management tools to use RODCs may result in unpredictable behavior.
Adding global catalog servers for a large number of users

Place global catalog servers at all locations that contain more than 100 users to reduce congestion of network
WAN links and to prevent productivity loss in case of WAN link failure.
Using highly available bandwidth

You do not need to place a global catalog at a location that does not include applications that require a global
catalog server, includes less than 100 users, and is also connected to another location that includes a global catalog
server by a WAN link that is 100 percent available for Active Directory Domain Services (AD DS ). In this case, the
users can access the global catalog server over the WAN link.
Roaming users need to contact the global catalog servers whenever they log on for the first time at any location. If
the logon time over the WAN link is unacceptable, place a global catalog at a location that is visited by a large
number of roaming users.
Enabling universal group membership caching

For locations that include less than 100 users and that do not include a large number of roaming users or
applications that require a global catalog server, you can deploy domain controllers that are running Windows
Server 2008 and enable universal group membership caching. Ensure that the global catalog servers are not more
than one replication hop from the domain controller on which universal group membership caching is enabled so
that universal group information in the cache can be refreshed. For information about how universal group caching
works, see the article How the Global Catalog Works.
For a worksheet to assist you in documenting where you plan to place global catalog servers and domain
controllers with universal group caching enabled, see Job Aids for Windows Server 2003 Deployment Kit,
download Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip, and open Domain Controller
Placement (DSSTOPO_4.doc). See the information about locations in which you need to place global catalog
servers when you deploy the forest root domain and regional domains.
Active Directory Domain Services (AD DS ) supports multimaster replication of directory data, which means any
domain controller can accept directory changes and replicate the changes to all other domain controllers. However,
certain changes, such as schema modifications, are impractical to perform in a multimaster fashion. For this reason
certain domain controllers, known as operations masters, hold roles responsible for accepting requests for certain
specific changes.
NOTE
Operations master role holders must be able to write some information to the Active Directory database. Because of the
read-only nature of the Active Directory database on a read-only domain controller (RODC), RODCs cannot act as
operations master role holders.
Three operations master roles (also known as flexible single master operations or FSMO ) exist in each domain:
The primary domain controller (PDC ) emulator operations master processes all password updates.
The relative ID (RID ) operations master maintains the global RID pool for the domain and allocates local
RIDs pools to all domain controllers to ensure that all security principals created in the domain have a
unique identifier.
The infrastructure operations master for a given domain maintains a list of the security principals from other
domains that are members of groups within its domain.
In addition to the three domain-level operations master roles, two operations master roles exist in each forest:
The schema operations master governs changes to the schema.
The domain naming operations master adds and removes domains and other directory partitions (for example,
Domain Name System (DNS ) application partitions) to and from the forest.
Place the domain controllers hosting these operations master roles in areas where network reliability is high, and
ensure that the PDC emulator and the RID master are consistently available.
Operations master role holders are assigned automatically when the first domain controller in a given domain is
created. The two forest-level roles (schema master and domain naming master) are assigned to the first domain
controller created in a forest. In addition, the three domain-level roles (RID master, infrastructure master, and PDC
emulator) are assigned to the first domain controller created in a domain.
NOTE
Automatic operations master role holder assignments are made only when a new domain is created and when a current role
holder is demoted. All other changes to role owners have to be initiated by an administrator.
These automatic operations master role assignments can cause very high CPU usage on the first domain controller
created in the forest or the domain. To avoid this, assign (transfer) operations master roles to various domain
controllers in your forest or domain. Place the domain controllers that host operations master roles in areas where
the network is reliable and where the operations masters can be accessed by all other domain controllers in the
forest.
You should also designate standby (alternate) operations masters for all operations master roles. The standby
operations masters are domain controllers to which you could transfer the operations master roles in case the
original role holders fail. Ensure that the standby operations masters are direct replication partners of the actual
operations masters.
Planning the PDC emulator placement

The PDC emulator processes client password changes. Only one domain controller acts as the PDC emulator in
each domain in the forest.
Even if all the domain controllers are upgraded to Windows 2000, Windows Server 2003, and Windows Server
2008 , and the domain is operating at the Windows 2000 native functional level, the PDC emulator receives
preferential replication of password changes performed by other domain controllers in the domain. If a password
was recently changed, that change takes time to replicate to every domain controller in the domain. If logon
authentication fails at another domain controller due to a bad password, that domain controller forwards the
authentication request to the PDC emulator before deciding whether to accept or reject the logon attempt.
Place the PDC emulator in a location that contains a large number of users from that domain for password
forwarding operations if needed. In addition, ensure that the location is well connected to other locations to
minimize replication latency.
For a worksheet to assist you in documenting the information about where you plan to place PDC emulators and
the number of users for each domain that is represented in each location, see Job Aids for Windows Server 2003
Deployment Kit (https://go.microsoft.com/fwlink/?LinkID=102558), download
Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip, and open Domain Controller Placement
(DSSTOPO_4.doc).
You need to refer to the information about locations in which you need to place PDC emulators when you deploy
regional domains. For more information about deploying regional domains, see Deploying Windows Server 2008
Regional Domains.
Requirements for infrastructure master placement

The infrastructure master updates the names of security principals from other domains that are added to groups in
its own domain. For example, if a user from one domain is a member of a group in a second domain and the user's
name is changed in the first domain, the second domain is not notified that the user's name must be updated in the
group's membership list. Because domain controllers in one domain do not replicate security principals to domain
controllers in another domain, the second domain never becomes aware of the change in the absence of the
infrastructure master.
The infrastructure master constantly monitors group memberships, looking for security principals from other
domains. If it finds one, it checks with the security principal's domain to verify that the information is updated. If the
information is out of date, the infrastructure master performs the update and then replicates the change to the
other domain controllers in its domain.
Two exceptions apply to this rule. First, if all domain controllers are global catalog servers, the domain controller
that hosts the infrastructure master role is insignificant because global catalogs replicate the updated information
regardless of the domain to which they belong. Second, if the forest has only one domain, the domain controller
that hosts the infrastructure master role is insignificant because security principals from other domains do not exist.
Do not place the infrastructure master on a domain controller that is also a global catalog server. If the
infrastructure master and global catalog are on the same domain controller, the infrastructure master will not
function. The infrastructure master will never find data that is out of date; therefore, it will never replicate any
changes to the other domain controllers in the domain.
Operations master placement for networks with limited connectivity
Be aware that if your environment does have a central location or hub site in which you can place operations
master role holders, certain domain controller operations that depend on the availability of those operations master
role holders might be affected.
For example, suppose that an organization creates sites A, B, C, and D. Site links exist between A and B, between B
and C, and between C and D. Network connectivity exactly mirrors the network connectivity of the sites links. In this
example, all operations master roles are placed in site A and the option to Bridge all site links is not selected.
Although this configuration results in successful replication between all of the sites, the operations master role
functions have the following limitations:
Domain controllers in sites C and D cannot access the PDC emulator in site A to update a password or to check
it for a password that has been recently updated.
Domain controllers in sites C and D cannot access the RID master in site A to obtain an initial RID pool after the
Active Directory installation and to refresh RID pools as they become depleted.
Domain controllers in sites C and D cannot add or remove directory, DNS, or custom application partitions.
Domain controllers in sites C and D cannot make schema changes.
For a worksheet to assist you in planning operations master role placement, see Job Aids for Windows Server 2003
Deployment Kit, download Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip, and open
Domain Controller Placement (DSSTOPO_4.doc).
You will need to refer to this information when you create the forest root domain and regional domains. For more
information about deploying the forest root domain, see Deploying a Deploying a Windows Server 2008 Forest
Root Domain. For more information about deploying regional domains, see Deploying Windows Server 2008
Regional Domains.
Next steps
Additional information about FSMO role placement can be found in the support topic FSMO placement and
optimization on Active Directory domain controllers
Creating a site design involves deciding which locations will become sites, creating site objects, creating subnet
objects, and associating the subnets with sites.
Deciding which locations will become sites

Decide which locations to create sites for as follows:
Create sites for all locations in which you plan to place domain controllers. Refer to the information documented
in the "Domain Controller Placement" (DSSTOPO_4.doc) worksheet to identify locations that include domain
controllers.
Create sites for those locations that include servers that are running applications that require a site to be
created. Certain applications, such as Distributed File System Namespaces (DFSN ), use site objects to locate
the closest servers to clients.
NOTE
If your organization has multiple networks in close proximity with fast, reliable connections, you can include all of the
subnets for those networks in a single Active Directory site. For example, if the round-trip return network latency
between two servers in different subnets is 10 ms or less, you can include both subnets in the same Active Directory
site. If the network latency between the two locations is greater than 10 ms, you should not include the subnets in a
single Active Directory site. Even when latency is 10 ms or less, you may elect to deploy separate sites if you want to
segment the traffic between sites for Active Directory-based applications.
If a site is not required for a location, add the subnet of the location to a site for which the location has the
maximum wide area network (WAN ) speed and available bandwidth.
Document locations that will become sites and the network addresses and subnet masks within each location. For a
worksheet to assist you in documenting sites, see Job Aids for Windows Server 2003 Deployment Kit, download
Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip, and open "Associating Subnets with
Sites" (DSSTOPO_6.doc).
Creating a site object design

For every location where you have decided to create sites, plan to create site objects in Active Directory Domain
Services (AD DS ). Document locations that will become sites in the "Associating Subnets with Sites" worksheet.
For more information about how to create site objects, see the article Create a Site.
Creating a subnet object design

For every IP subnet and subnet mask associated with each location, plan to create subnet objects in AD DS
representing all the IP addresses within the site.
When creating an Active Directory subnet object, the information about network IP subnet and subnet mask is
automatically translated into the network prefix length notation format /. For example, the network IP version 4
(IPv4) address 172.16.4.0 with a subnet mask 255.255.252.0 appears as 172.16.4.0/22. In addition to IPv4
addresses, Windows Server 2008 also supports IP version 6 (IPv6) subnet prefixes, for example,
3FFE:FFFF:0:C000::/64. For more information about IP subnets in each location, see the "Locations and Subnets"
(DSSTOPO_2.doc) worksheet in Collecting Network Information and Appendix A: Locations and Subnet Prefixes.
Associate each subnet object with a site object by referring to the "Associating Subnets with Sites"
(DSSTOPO_6.doc) worksheet in "Deciding Which Locations Will Become Sites" section to determine which subnet
is to be associated with which site. Document the Active Directory subnet object associated with each location in
the "Associating Subnets with Sites" (DSSTOPO_6.doc) worksheet.
For more information about how to create subnet objects, see the article Create a Subnet.
Create a site link design to connect your sites with site links. Site links reflect the intersite connectivity and method
used to transfer replication traffic. You must connect sites with site links so that domain controllers at each site can
replicate Active Directory changes.
Connecting sites with site links

To connect sites with site links, identify the member sites that you want to connect with the site link, create a site
link object in the respective Inter-Site Transports container, and then name the site link. After you create the site
link, you can proceed to set the site link properties.
When creating site links, ensure that every site is included in a site link. In addition, ensure that all sites are
connected to each other through other site links so that the changes can be replicated from domain controllers in
any site to all other sites. If you fail to do this, an error message is generated in the Directory Service log in Event
Viewer stating that the site topology is not connected.
Whenever you add sites to a newly created site link, determine if the site being added is a member of other site
links, and change the site link membership of the site if needed. For example, if you make a site a member of the
Default-First-Site-Link when you initially create the site, be sure to remove the site from the Default-First-Site-Link
after you add the site to a new site link. If you do not remove the site from the Default-First-Site-Link, the
Knowledge Consistency Checker (KCC ) will make routing decisions based on the membership of both site links,
which may result in incorrect routing.
To identify the member sites that you want to connect with a site link, use the list of locations and linked locations
that you recorded in the "Geographic Locations and Communication Links" (DSSTOPO_1.doc) worksheet. If
multiple sites have the same connectivity and availability to each other, you can connect them with the same site
link.
The Inter-Site Transports container provides the means for mapping site links to the transport that the link uses.
When you create a site link object, you create it in either the IP container, which associates the site link with the
remote procedure call (RPC ) over IP transport, or the Simple Mail Transfer Protocol (SMTP ) container, which
associates the site link with the SMTP transport.
NOTE
SMTP replication will not be supported in future versions of Active Directory Domain Services (AD DS); therefore, creating site
links objects in the SMTP container is not recommended.
When you create a site link object in the respective Inter-Site Transports container, AD DS uses RPC over IP to
transfer both intersite and intrasite replication between domain controllers. To keep data secure while in transit,
RPC over IP replication uses both the Kerberos authentication protocol and data encryption.
When a direct IP connection is not available, you can configure replication between sites to use SMTP. However,
SMTP replication functionality is limited and requires an enterprise certification authority (CA). SMTP can only
replicate the configuration, schema, and application directory partitions and does not support the replication of
domain directory partitions.
To name site links, use a consistent naming scheme, such as name_of_site1-name_of_site2. Record the list of sites,
linked sites, and the names of the site links connecting these sites in a worksheet. For a worksheet to assist you in
recording site names and associated site link names, see Job Aids for Windows Server 2003 Deployment Kit,
download Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip, and open"Sites and
Associated Site Links" (DSSTOPO_5.doc).
In this guide
Intersite replication occurs according to the properties of the connection objects. When the Knowledge Consistency
Checker (KCC ) creates connection objects, it derives the replication schedule from properties of the site link objects.
Each site link object represents the wide area network (WAN ) connection between two or more sites.
Setting site link object properties includes the following steps:
Determining the cost that is associated with that replication path. The KCC uses cost to determine the least
expensive route for replication between two sites that replicate the same directory partition.
Determining the schedule that defines the times during which intersite replication can occur.
Determining the replication interval that defines how frequently replication should occur during the times
when replication is allowed, as defined in the schedule.
In this guide
Determining the Cost
Determining the Schedule
Determining the Interval
Determining the Cost
You assign cost values to site links to favor inexpensive connections over expensive connections. Certain
applications and services, such as Domain Controller Locator (DCLocator) and Distributed File System
Namespaces (DFSN ), also use cost information to locate the nearest resources. Site link cost can be used to
determine which domain controller is contacted by clients in one site if the domain controller for the specified
domain does not exist at that site. The client contacts the domain controller by using the site link that has the lowest
cost assigned to it.
We recommend that the cost value be defined on a site-wide basis. Cost is usually based not only on the total
bandwidth of the link but also on the availability, latency, and monetary cost of the link.
To determine the costs to place on site links, document the connection speed for each site link. Refer to the
"Geographic Locations and Communication Links" (DSSTOPO_1.doc) worksheet in Collecting Network
Information for information about the connection speed that you identified.
The following table lists the speeds for different types of networks.
NETWORK TYPE SPEED
Very slow 56 kilobits per second (Kbps)
Slow 64 Kbps
Integrated Services Digital Network (ISDN) 64 Kbps or 128 Kbps
Frame relay Variable rate, commonly between 56 Kbps and 1.5 megabits
per second (Mbps)
T1 1.5 Mbps
T3 45 Mbps
10BaseT 10 Mbps
Asynchronous transfer mode (ATM) Variable rate, commonly between 155 Mbps and 622 Mbps
100BaseT 100 Mbps
Gigabit Ethernet 1 gigabit per second (Gbps)
Use the following table to calculate the cost of each site link based on wide area network speed (WAN ) link speed.
For WAN link speed that is not listed in the table, you can calculate a relative cost factor by dividing 1,024 by the
log of the available bandwidth, as measured in Kbps.
AVAILABLE BANDWIDTH (KBPS) COST
9.6 1,042
19.2 798
38.4 644
56 586
64 567
128 486
256 425
512 378
1,024 340
2,048 309
4,096 283
These costs do not reflect differences in reliability between network links. Set higher costs on any failure-prone
network links so that you do not have to rely on those links for replication. By setting higher site link costs, you can
control replication failover when a site link fails.
Enabling Clients to Locate the Next Closest Domain
Controller
Applies To: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
If you have a domain controller that runs Windows Server 2008 or newer, you can make it possible for client
computers that run Windows Vista or newer or Windows Server 2008 or newer to locate domain controllers more
efficiently by enabling the Try Next Closest Site Group Policy setting. This setting improves the Domain
Controller Locator (DC Locator) by helping to streamline network traffic, especially in large enterprises that have
many branch offices and sites.
This new setting can affect how you configure site link costs because it affects the order in which domain
controllers are located. For enterprises that have many hub sites and branch offices, you can significantly reduce
Active Directory traffic on the network by ensuring that clients fail over to the next closest hub site when they
cannot find a domain controller in the closest hub site.
As a general best practice, you should simplify your site topology and site link costs as much as possible if you
enable the Try Next Closest Site setting. In enterprises with many hub sites, this can simplify any plans that you
make for handling situations in which clients in one site need to fail over to a domain controller in another site.
By default, the Try Next Closest Site setting is not enabled. When the setting is not enabled, DC Locator uses the
following algorithm to locate a domain controller:
Try to find a domain controller in the same site.
If no domain controller is available in the same site, try to find any domain controller in the domain.
NOTE
This is the same algorithm that DC Locator used in previous versions of Active Directory. For more information, see the article
How DNS Support for Active Directory Works.
If you enable the Try Next Closest Site setting, DC Locator uses the following algorithm to locate a domain
controller:
Try to find a domain controller in the same site.
If no domain controller is available in the same site, try to find a domain controller in the next closest site. A site
is closer if it has a lower site-link cost than another site with a higher site-link cost.
If no domain controller is available in the next closest site, try to find any domain controller in the domain.
The Try Next Closest Site setting works in coordination with automatic site coverage. For example, if the next
closest site has no domain controller, DC Locator tries to find the domain controller that performs automatic site
coverage for that site.
By default, DC Locator does not consider any site that contains a read-only domain controller (RODC ) when it
determines the next closest site. In addition, when the client gets a response from a domain controller that runs a
version earlier than Windows Server 2008, the DC Locator behavior is the same as when then setting is not
enabled.
For example, assume that a site topology has four sites with the site link values in the following illustration. In this
example, all the domain controllers are writable domain controllers that run Windows Server 2008 or newer.
When the Try Next Closest Site Group Policy setting is enabled in this example, if a client computer in Site_B tries
to locate a domain controller, it first tries to find a domain controller in its own Site_B. If none is available in Site_B,
it tries to find a domain controller in Site_A.
If the setting is not enabled, the client tries to find a domain controller in Site_A, Site_C, or Site_D if no domain
controller is available in Site_B.
NOTE
The Try Next Closest Site setting works in coordination with automatic site coverage. For example, if the next closest site has
no domain controller, DC Locator tries to find the domain controller that performs automatic site coverage for that site.
To apply the Try Next Closest Site setting, you can create a Group Policy object (GPO ) and link it to the
appropriate object for your organization, or you can modify the Default Domain Policy to have it affect all clients
that run Windows Vista or newer and Windows Server 2008 or newer in the domain. For more information about
how to set the Try Next Closest Site setting, see Enable Clients to Locate a Domain Controller in the Next Closest
Site.
Determining the Schedule
You can control site link availability by setting a schedule for site links. When replication between two sites
traverses multiple site links, the intersection of the replication schedules on all the relevant links determines the
connection schedule between the two sites.
To plan for setting the site link schedule, create two overlapping schedules between site links that contain domain
controllers that directly replicate with each other. Use the default (100-percent available) schedule on those links
unless you want to block replication traffic during peak hours. By blocking replication, you give priority to other
traffic, but you also increase replication latency.
Domain controllers store time in Coordinated Universal Time (UTC ). Time settings in site link object schedules
conform to the local time of the site and computer on which the schedule is set. When a domain controller contacts
a computer that is in a different site and time zone, the schedule on the domain controller displays the time setting
according to the local time for the site of the computer.
Determining the Interval
You must set the site link replication interval property to indicate how frequently you want replication to occur
during the times when the schedule allows replication. For example, if the schedule allows replication between
02:00 hours and 04:00 hours, and the replication interval is set for 30 minutes, replication can occur up to four
times during the scheduled time. The default replication interval is 180 minutes, or 3 hours. The minimum interval
is 15 minutes.
Consider the following criteria to determine how often replication occurs within the schedule window:
A small interval decreases latency but increases the amount of wide area network (WAN ) traffic.
To keep domain directory partitions up to date, low latency is preferred.
With a store-and-forward replication strategy, it is difficult to determine just how long a directory update might
take to be replicated to every domain controller. To provide a conservative estimate of maximum latency, perform
these tasks:
Create a table of all the sites on your network, as shown in the following example:
WASHINGTON,
SITES SEATTLE BOSTON LOS ANGELES NEW YORK D.C.
Seattle 0.25
Boston 0.25
Los Angeles 0.25
New York 0.25
Washington, 0.25
D.C.
A worst-case latency within a site is estimated to be 15 minutes.

From the replication schedule, determine the maximum replication latency that is possible on any site link
that connects two hub sites.
For example, if replication occurs between Seattle and New York every three hours, the maximum delay for
replication between these sites is three hours. If the replication delay between New York and Seattle is the
longest scheduled delay among all hub sites, the maximum latency between all hubs is three hours.
For each hub site, create a table of the maximum latencies between the hub site and any of its satellite sites.
For example, if replication occurs between New York and Washington, D.C., every four hours and this is the
longest replication delay between New York and any of its satellite sites, the maximum latency between New
York and its satellites is four hours.
Combine these maximum latencies to determine the maximum latency for the entire network.
For example, if the maximum latency between Seattle and its satellite site in Los Angeles is one day, the
maximum replication latency for this set of links (Washington, D.C.-New York-Seattle-Los Angeles) is 31
hours, that is, 4 (Washington, D.C.-New York) + 3 (New York-Seattle) + 24 (Seattle-Los Angeles), as shown
in the following table.
WASHINGTON,
SITES SEATTLE BOSTON LOS ANGELES NEW YORK D.C.
Seattle 0.25 4+3 24.00 3.00 4+3
Boston 0.25 4+3+24 4.00 4.00
Los Angeles 0.25 24 + 3 24+3+4
New York 0.25 4.00
Washington, 0.25
D.C.
A site link bridge connects two or more site links and enables transitivity between site links. Each site link in a
bridge must have a site in common with another site link in the bridge. The Knowledge Consistency Checker (KCC )
uses the information on each site link to compute the cost of replication between sites in one site link and sites in
the other site links of the bridge. Without the presence of a common site between site links, the KCC also cannot
establish direct connections between domain controllers in the sites that are connected by the same site link bridge.
By default, all site links are transitive. We recommend that you keep transitivity enabled by not changing the default
value of Bridge all site links (enabled by default). However, you will need to disable Bridge all site links and
complete a site link bridge design if:
Your IP network is not fully routed. When you disable Bridge all site links, all site links are considered
nontransitive, and you can create and configure site link bridge objects to model the actual routing behavior of
your network.
You need to control the replication flow of the changes made in Active Directory Domain Services (AD DS ). By
disabling Bridge all site links for the site link IP transport and configuring a site link bridge, the site link bridge
becomes the equivalent of a disjointed network. All site links within the site link bridge can route transitively, but
they do not route outside of the site link bridge.
For more information about how to use the Active Directory Sites and Services snap-in to disable the Bridge all
site links setting, see the article Enable or disable site link bridges.
Controlling AD DS replication flow

Two scenarios in which you need a site link bridge design to control replication flow include controlling replication
failover and controlling replication through a firewall.
Controlling replication failover
If your organization has a hub-and-spoke network topology, you generally do not want the satellite sites to create
replication connections to other satellite sites if all domain controllers in the hub site fail. In such scenarios, you
must disable Bridge all site links and create site link bridges so that replication connections are created between
the satellite site and another hub site that is just one or two hops away from the satellite site.
Controlling replication through a firewall
If two domain controllers representing the same domain in two different sites are specifically allowed to
communicate with each other only through a firewall, you can disable Bridge all site links and create site link
bridges for sites on the same side of the firewall. Therefore, if your network is separated by firewalls, we
recommend that you disable transitivity of site links and create site link bridges for the network on one side of the
firewall. For information about managing replication through firewalls, see the article Active Directory in Networks
Segmented by Firewalls.
Finding Additional Resources for Windows Server
2008 Active Directory Site Topology Design
You can find the following documentation about Active Directory Domain Services (AD DS ) on the Windows
Server 2003 and Windows Server 2008 TechCenter Web sites:
For more information about the process of locating a domain controller, see Active Directory Collection
For more information about designing and deploying print servers, see Designing and Deploying Print
Servers (https://go.microsoft.com/fwlink/?LinkId=107041).
For more information about spanning trees and Active Directory replication topology, see Active Directory
Replication Topology Technical Reference (https://go.microsoft.com/fwlink/?LinkId=44137).
For more information about using Adlb.exe and managing environments that have 100 or more branch
sites, see Planning and Deploying Active Directory Domain Services for Branch Offices
For information about installing Network Monitor, see Monitoring network traffic
For worksheets to assist you in documenting your Windows Server 2008 AD DS site topology design, see
Job Aids for Windows Server 2003 Deployment Kit (https://go.microsoft.com/fwlink/?LinkID=102558).
For more information about shortcut trusts between domains, see Understanding When to Create a
Shortcut Trust (https://go.microsoft.com/fwlink/?LinkId=107061).
For more information about deploying the forest root domain, see Deploying a Windows Server 2008
Forest Root Domain.
For more information about securing domain controllers, see Best Practice Guide for Securing Windows
Server Active Directory Installations (https://go.microsoft.com/fwlink/?LinkId=28521).
For more information about deploying regional domains, see Deploying Windows Server 2008 Regional
Domains.
For more information about how universal group caching works, see How the Global Catalog Works
For more information about how to create site objects, see Create a Site (https://go.microsoft.com/fwlink/?
LinkId=107067).
For more information about how to create subnet objects, see Create a Subnet
For more information about how to use the Active Directory Sites and Services snap-in to disable the
Bridge all site links setting, see Enable or disable site link bridges (https://go.microsoft.com/fwlink/?
LinkId=107073).
For information about managing replication through firewalls, see Active Directory in Networks Segmented
by Firewalls (https://go.microsoft.com/fwlink/?LinkId=37928).
For more information about read-only domain controller (RODC ) features, see AD DS: Read-Only Domain
For information about how to deploy an RODC, see the Step-by-Step Guide for Read-only Domain
Appendix A: Locations and Subnet Prefixes
Use the following table to assist in listing the IP version 6 (IPv6) subnet prefixes when you design the site topology
for Windows Server 2008 Active Directory Domain Services (AD DS ).
LOCATION NETWORK SUBNET PREFIX

Active Directory Domain Services (AD DS ) makes it possible for you to introduce advanced features into your
environment by raising the domain or forest functional levels. To use advanced AD DS features, you must identify
the operating systems that are running on the domain controllers in your environment.
You must also determine the best functional level for your organization based on your existing infrastructure and
then raise the domain or forest functional level as appropriate. You can raise the functional level when all domain
controllers in the domain or forest are running an appropriate version of Windows. Although raising the functional
level makes it possible for you to enable new features, it also limits the versions of Windows operating systems that
you can run on domain controllers in your environment.
Forest and Domain Functional Levels
Applies To: Windows Server
Functional levels determine the available Active Directory Domain Services (AD DS ) domain or forest capabilities.
They also determine which Windows Server operating systems you can run on domain controllers in the domain
or forest. However, functional levels do not affect which operating systems you can run on workstations and
member servers that are joined to the domain or forest.
When you deploy AD DS, set the domain and forest functional levels to the highest value that your environment
can support. This way, you can use as many AD DS features as possible. When you deploy a new forest, you are
prompted to set the forest functional level and then set the domain functional level. You can set the domain
functional level to a value that is higher than the forest functional level, but you cannot set the domain functional
level to a value that is lower than the forest functional level.
With the end of life of Windows 2003, Windows 2003 domain controllers (DCs) need to be updated to Windows
Server 2008, 2008R2, 2012, 2012R2, 2016, or 2019. As a result, any domain controller that runs Windows Server
2003 should be removed from the domain.
At the Windows Server 2008 and higher domain functional levels, Distributed File Service (DFS ) Replication is
used to replicate SYSVOL folder contents between domain controllers. If you create a new domain at the
Windows Server 2008 domain functional level or higher, DFS Replication is automatically used to replicate
SYSVOL. If you created the domain at a lower functional level, you will need to migrate from using FRS to DFS
replication for SYSVOL. For migration steps, you can either follow the procedures on TechNet or you can refer to
the streamlined set of steps on the Storage Team File Cabinet blog.
Windows Server 2019

There are no new forest or domain functional levels added in this release.
The minimum requirement to add a Windows Server 2019 Domain Controller is a Windows Server 2008R2
functional level.
Windows Server 2016

Supported Domain Controller Operating System:
Windows Server 2019
Windows Server 2016
Windows Server 2016 forest functional level features
All of the features that are available at the Windows Server 2012R2 forest functional level, and the following
features, are available:
Privileged access management (PAM ) using Microsoft Identity Manager (MIM )
Windows Server 2016 domain functional level features
All default Active Directory features, all features from the Windows Server 2012R2 domain functional
level, plus the following features:
DCs can support automatic rolling of the NTLM and other password-based secrets on a user account
configured to require PKI authentication. This configuration is also known as “Smart card required for
interactive logon”
DCs can support allowing network NTLM when a user is restricted to specific domain-joined devices.
Kerberos clients successfully authenticating with the PKInit Freshness Extension will get the fresh
public key identity SID.
For more information see What's New in Kerberos Authentication and What's new in Credential
Protection
Windows Server 2012R2

Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
Windows Server 2012R2 forest functional level features
All of the features that are available at the Windows Server 2012 forest functional level, but no additional
features.
Windows Server 2012R2 domain functional level features
All default Active Directory features, all features from the Windows Server 2012 domain functional level, plus
the following features:
DC -side protections for Protected Users. Protected Users authenticating to a Windows Server 2012 R2
domain can no longer:
Authenticate with NTLM authentication
Use DES or RC4 cipher suites in Kerberos pre-authentication
Be delegated with unconstrained or constrained delegation
Renew user tickets (TGTs) beyond the initial 4 hour lifetime
Authentication Policies
New forest-based Active Directory policies which can be applied to accounts in Windows Server
2012 R2 domains to control which hosts an account can sign-on from and apply access control
conditions for authentication to services running as an account.
Authentication Policy Silos
New forest-based Active Directory object, which can create a relationship between user,
managed service and computer, accounts to be used to classify accounts for authentication
policies or for authentication isolation.
Windows Server 2012

Windows Server 2019
Windows Server 2016
Windows Server 2012
All of the features that are available at the Windows Server 2008 R2 forest functional level, but no additional
features.
All default Active Directory features, all features from the Windows Server 2008R2 domain functional level,
plus the following features:
The KDC support for claims, compound authentication, and Kerberos armoring KDC administrative
template policy has two settings (Always provide claims and Fail unarmored authentication requests)
that require Windows Server 2012 domain functional level. For more information, see What's New in
Kerberos Authentication
Windows Server 2008R2

Windows Server 2019
Windows Server 2016
Windows Server 2012
Windows Server 2008R2 forest functional level features
All of the features that are available at the Windows Server 2003 forest functional level, plus the following
features:
Active Directory Recycle Bin, which provides the ability to restore deleted objects in their entirety while
AD DS is running.
Windows Server 2008R2 domain functional level features
All default Active Directory features, all features from the Windows Server 2008 domain functional level, plus
the following features:
Authentication mechanism assurance, which packages information about the type of logon method
(smart card or user name/password) that is used to authenticate domain users inside each user’s
Kerberos token. When this feature is enabled in a network environment that has deployed a federated
identity management infrastructure, such as Active Directory Federation Services (AD FS ), the
information in the token can then be extracted whenever a user attempts to access any claims-aware
application that has been developed to determine authorization based on a user’s logon method.
Automatic SPN management for services running on a particular computer under the context of a
Managed Service Account when the name or DNS host name of the machine account changes. For
more information about Managed Service Accounts, see Service Accounts Step-by-Step Guide.
Windows Server 2008

Windows Server 2019
Windows Server 2016
Windows Server 2012
Windows Server 2008
All of the features that are available at the Windows Server 2003 forest functional level, but no additional
features are available.
All of the default AD DS features, all of the features from the Windows Server 2003 domain functional
level, and the following features are available:
Distributed File System (DFS ) replication support for the Windows Server 2003 System Volume
(SYSVOL )
DFS replication support provides more robust and detailed replication of SYSVOL contents.
[!NOTE ]> >Beginning with Windows Server 2012 R2, File Replication Service (FRS ) is
deprecated. A new domain that is created on a domain controller that runs at least Windows
Server 2012 R2 must be set to the Windows Server 2008 domain functional level or higher.
Domain-based DFS namespaces running in Windows Server 2008 Mode, which includes support
for access-based enumeration and increased scalability. Domain-based namespaces in Windows
Server 2008 mode also require the forest to use the Windows Server 2003 forest functional level.
For more information, see Choose a Namespace Type.
Advanced Encryption Standard (AES 128 and AES 256) support for the Kerberos protocol. In order
for TGTs to be issued using AES, the domain functional level must be Windows Server 2008 or
higher and the domain password needs to be changed.
For more information, see Kerberos Enhancements. [!NOTE ]> >Authentication errors may occur
on a domain controller after the domain functional level is raised to Windows Server 2008 or
higher if the domain controller has already replicated the DFL change but has not yet refreshed
the krbtgt password. In this case, a restart of the KDC service on the domain controller will
trigger an in-memory refresh of the new krbtgt password and resolve related authentication
errors.
Last Interactive Logon Information displays the following information:
The total number of failed logon attempts at a domain-joined Windows Server 2008 server or a
Windows Vista workstation
The total number of failed logon attempts after a successful logon to a Windows Server 2008
server or a Windows Vista workstation
The time of the last failed logon attempt at a Windows Server 2008 or a Windows Vista
workstation
The time of the last successful logon attempt at a Windows Server 2008 server or a Windows
Vista workstation
Fine-grained password policies make it possible for you to specify password and account lockout
policies for users and global security groups in a domain. For more information, see Step-by-Step
Guide for Fine-Grained Password and Account Lockout Policy Configuration.
Personal Virtual Desktops
To use the added functionality provided by the Personal Virtual Desktop tab in the User Account
Properties dialog box in Active Directory Users and Computers, your AD DS schema must be
extended for Windows Server 2008 R2 (schema object version = 47). For more information, see
Deploying Personal Virtual Desktops by Using RemoteApp and Desktop Connection Step-by-
Step Guide.
Windows Server 2003

Windows Server 2012
Windows Server 2008
Windows Server 2003
All of the default AD DS features, and the following features, are available:
Forest trust
Domain rename
Linked-value replication
Linked-value replication makes it possible for you to change group membership to store and
replicate values for individual members instead of replicating the entire membership as a single
unit. Storing and replicating the values of individual members uses less network bandwidth and
fewer processor cycles during replication, and prevents you from losing updates when you add
or remove multiple members concurrently at different domain controllers.
The ability to deploy a read-only domain controller (RODC )
Improved Knowledge Consistency Checker (KCC ) algorithms and scalability
The intersite topology generator (ISTG ) uses improved algorithms that scale to support forests
with a greater number of sites than AD DS can support at the Windows 2000 forest functional
level. The improved ISTG election algorithm is a less-intrusive mechanism for choosing the ISTG
at the Windows 2000 forest functional level.
The ability to create instances of the dynamic auxiliary class named dynamicObject in a domain
directory partition
The ability to convert an inetOrgPerson object instance into a User object instance, and to complete
the conversion in the opposite direction
The ability to create instances of new group types to support role-based authorization.
These types are called application basic groups and LDAP query groups.
Deactivation and redefinition of attributes and classes in the schema. The following attributes can be
reused: ldapDisplayName, schemaIdGuid, OID, and mapiID.
Domain-based DFS namespaces running in Windows Server 2008 Mode, which includes support for
access-based enumeration and increased scalability. For more information, see Choose a Namespace
Type.
All the default AD DS features, all the features that are available at the Windows 2000 native domain
functional level, and the following features are available:
The domain management tool, Netdom.exe, which makes it possible for you to rename domain
controllers
Logon time stamp updates
The lastLogonTimestamp attribute is updated with the last logon time of the user or computer.
This attribute is replicated within the domain.
The ability to set the userPassword attribute as the effective password on inetOrgPerson and user
objects
The ability to redirect Users and Computers containers
By default, two well-known containers are provided for housing computer and user accounts,
namely, cn=Computers, and cn=Users,. This feature allows the definition of a new, well-known
location for these accounts.
The ability for Authorization Manager to store its authorization policies in AD DS
Constrained delegation
Constrained delegation makes it possible for applications to take advantage of the secure
delegation of user credentials by means of Kerberos-based authentication.
You can restrict delegation to specific destination services only.
Selective authentication
Selective authentication makes it is possible for you to specify the users and groups from a
trusted forest who are allowed to authenticate to resource servers in a trusting forest.
Windows 2000
Windows Server 2008
Windows Server 2003
Windows 2000
Windows 2000 native forest functional level features
All of the default AD DS features are available.
Windows 2000 native domain functional level features
All of the default AD DS features and the following directory features are available including:
Universal groups for both distribution and security groups.
Group nesting
Group conversion, which allows conversion between security and distribution groups
Security identifier (SID ) history
Next Steps
Raise the Domain Functional Level
Raise the Forest Functional Level
Identifying Your Functional Level Upgrade
Before you can raise domain and forest functional levels, you have to evaluate your current environment and
identify the functional level requirement that best meets the needs of your organization. Assess your current
environment by identifying the domains in your forest, the domain controllers that are located in each domain, the
operating system and service packs that each domain controller is running, and the date that you plan to upgrade
the domain controllers. If you plan to retire a domain controller, make sure that you understand the full impact that
doing so will have on your environment.
The following circumstances might prevent you from upgrading an earlier version of the Windows Server
operating system to the Windows Server 2008 or Windows Server 2008 R2 functional level:
Insufficient hardware
A domain controller running an antivirus program that is incompatible with Windows Server 2008 or
Use of a version-specific program that does not run on Windows Server 2008 or Windows Server 2008 R2
The need to upgrade a program with the latest service pack
Documenting this information can help you identify the steps to take to ensure that you have a fully functional
Windows Server 2008 or Windows Server 2008 R2 environment.
After you assess your current environment, you have to identify the functional level upgrade that applies to your
organization. These options are available:
Windows 2000 native-mode environment to Windows Server 2008 or Windows Server 2008 R2
Windows Server 2003 forest to Windows Server 2008 or Windows Server 2008 R2
New Windows Server 2008 forest
New Windows Server 2008 R2 forest
Upgrading functional levels in a native Windows 2000 Active Directory

forest
In a Windows 2000 native environment that consists only of Windows 2000-based domain controllers, the
functional levels are set by default to the following levels, and they remain at these levels until you raise them
manually:
Windows 2000 native domain functional level
Windows 2000 forest functional level
To use all the forest-level and domain-level features in Windows Server 2008 or Windows Server 2008 R2 , you
have to upgrade this Windows 2000 environment to Windows Server 2008 or Windows Server 2008 R2 . You can
perform this upgrade in either of the following ways:
Introduce newly installed Windows Server 2008 -based or Windows Server 2008 R2 -based domain
controllers into the forest, and then retire all domain controllers running Windows 2000.
Perform an in-place upgrade of all existing domain controllers running Windows 2000 in the forest to
domain controllers running Windows Server 2003. Then, perform an in-place upgrade of those domain
controllers to Windows Server 2008 or Windows Server 2008 R2 . For more information, see Upgrading
Active Directory Domains to Windows Server 2008 AD DS Domains [LH].
IMPORTANT
Windows Server 2008 R2 is an x64-based operating system. If your server is running an x64-based version of
Windows Server 2003, you can successfully perform an in-place upgrade of this computer's operating system to
Windows Server 2008 R2 . If your server is running an x86-based version of Windows Server 2003, you cannot
upgrade this computer to Windows Server 2008 R2 .
To use the Windows Server 2008 or Windows Server 2008 R2 domain-level features without upgrading your
entire Windows 2000 forest to Windows Server 2008 or Windows Server 2008 R2 , raise only the domain
functional level to Windows Server 2008 or Windows Server 2008 R2 .
NOTE
Before you raise the domain functional level, you must upgrade all Windows 2000-based domain controllers in that domain
to Windows Server 2008 or Windows Server 2008 R2 .
After you replace all the Windows 2000-based domain controllers in the forest with domain controllers that run
Windows Server 2008 or Windows Server 2008 R2 , you can raise the forest functional level to Windows Server
2008 or Windows Server 2008 R2 . Doing so automatically raises the functional level of all domains in the forest
that are set to Windows 2000 native or higher to Windows Server 2008 or Windows Server 2008 R2 .
For more information about raising forest and domain functional levels, and for procedures to perform those tasks,
see Deploying a Windows Server 2008 Forest Root Domain [LH].
Upgrading functional levels in a Windows Server 2003 Active Directory

forest
In a Windows Server 2003 environment that consists of only Windows Server 2003-based domain controllers, the
functional levels are set by default to the following levels, and they remain at these levels until you raise them
manually:
To use all the forest-level and domain-level features in Windows Server 2008 or Windows Server 2008 R2 , you
have to upgrade this Windows Server 2003 environment to Windows Server 2008 or Windows Server 2008 R2 .
You can perform this upgrade in either of the following ways:
Introduce a newly installed Windows Server 2008 -based or Windows Server 2008 R2 -based domain
controller into the forest, and then retire all domain controllers running Windows Server 2003 or upgrade
them to Windows Server 2008 or Windows Server 2008 R2 .
Perform an in-place upgrade of all existing domain controllers running Windows Server 2003 to domain
controllers running Windows Server 2008 or Windows Server 2008 R2 . For more information, see
Upgrading Active Directory Domains to Windows Server 2008 AD DS Domains [LH].
IMPORTANT
Windows Server 2008 R2 is an x64-based operating system. If your server is running an x64-based version of Windows
Server 2003, you can successfully perform an in-place upgrade of this computer's operating system to Windows Server 2008
R2 . If your server is running an x86-based version of Windows Server 2003, you cannot upgrade this computer to run
Windows Server 2008 R2 .
To use all the Windows Server 2008 or Windows Server 2008 R2 domain-level features without upgrading your
entire Windows Server 2003 forest to Windows Server 2008 or Windows Server 2008 R2 , raise only the domain
functional level to Windows Server 2008 or Windows Server 2008 R2 .
NOTE
Before you raise the domain functional level, you must upgrade all Windows Server 2003-based domain controllers in that
domain to Windows Server 2008 or Windows Server 2008 R2 .
After you upgrade all the Windows Server 2003-based domain controllers in the forest to Windows Server 2008 or
Windows Server 2008 R2 , you can raise the forest functional level to Windows Server 2008 or Windows Server
2008 R2 . Doing so automatically raises the functional level of all domains in the forest that are set to Windows
Server 2003 to Windows Server 2008 or Windows Server 2008 R2 .
Upgrading functional levels in a new Windows Server 2008 forest

When you install the first domain controller in a new Windows Server 2008 forest, functional levels are set by
default to the following levels, and they remain at these levels until you raise them manually:
Functional levels are set at these default levels to give you the option of adding Windows 2000 or Windows Server
2003-based domain controllers to your new Windows Server 2008 forest. After you create a forest root domain,
the domain functional level for each domain that you add to the Windows Server 2008 forest is set to Windows
2000 native. However, if you want all domain controllers in your new Windows Server 2008 environment to run
Windows Server 2008 , set the forest functional level, and then the domain functional level, to Windows Server
2008 when you install the first domain controller in your forest. Doing this saves time and enables all the forest-
level and domain-level features in Windows Server 2008 .
IMPORTANT
If the forest operates at the Windows Server 2008 functional level and you attempt to install Active Directory on a Windows
Server 2003-based member server or a Windows 2000-based member server, the installation fails.
Upgrading functional levels in a new Windows Server 2008 R2 forest

When you install the first domain controller in a new Windows Server 2008 R2 forest, functional levels are set by
default to the following levels, and they remain at these levels until you raise them manually:
Windows Server 2003 domain functional level
Windows Server 2003 forest functional level
Functional levels are set at these default levels to give you the option of adding Windows Server 2003-based
domain controllers to your new Windows Server 2008 R2 forest. After you create a forest root domain, the domain
functional level for each domain that you add to the Windows Server 2008 R2 forest is set to Windows Server
2003. However, if you want all domain controllers in your new Windows Server 2008 R2 environment to run
Windows Server 2008 R2 , set the forest functional level, and then the domain functional level, to Windows Server
2008 R2 when you install the first domain controller in your forest. Doing this saves time and enables all forest-
level and domain-level features in Windows Server 2008 R2 .
IMPORTANT
If the forest operates at the Windows Server 2008 R2 functional level and you attempt to install Active Directory on a
Windows Server 2008 -based or Windows Server 2003-based member server, or on a Windows 2000-based member server,
the installation fails.
NOTE
Although ADMT v3.1 must be installed on Windows Server 2008, you can use ADMT v3.1 to migrate objects to a domain
that is hosted by one or more Windows Server 2008 R2 domain controllers. For more information, see article 976659 in the
Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=180398).
Finding Additional Resources for Enabling Advanced
Features
You can find the following documentation about Active Directory Domain Services (AD DS ) in the Windows Server
2008 Technical Library:
For more information about deploying a Windows Server 2008 forest root domain, see Deploying a
Windows Server 2008 Forest Root Domain [LH].
For more information about upgrading an Active Directory domain to Windows Server 2008 , see
Upgrading Active Directory Domains to Windows Server 2008 AD DS Domains [LH].
For more information about deploying AD DS, see the Step-by-Step Guide for Windows Server 2008 Active
Directory Domain Services Installation and Removal (https://go.microsoft.com/fwlink/?LinkId=100492).
Consider the following example of a fictitious company, Contoso Pharmaceuticals, which is deploying Active
Directory Domain Services (AD DS ) in its environment. The Contoso environment consists of four domains. The
forest functional level is Windows Server 2003. The following illustration shows the current domain structure for
the Contoso organization.
After reviewing its existing environment and identifying its deployment goals, Contoso established the following
AD DS deployment strategy:
Upgrade Windows Server 2003 domains to Windows Server 2008 domains.
Enable advanced AD DS features by raising the domain and forest functional levels to Windows Server
2008 .
Restructure the africa.concorp.contoso.com domain within the forest to consolidate that domain with the
emea.concorp.contoso.con domain.
Raising the forest functional level to Windows Server 2008 will enable Contoso to take full advantage of the new
AD DS features. Restructuring the domains within the forest, as shown in the following illustration, will reduce the
amount of administration that is necessary for managing the domains.
The following terms are relevant to the deployment process for Windows Server 2008 Active Directory Domain
Services (AD DS ).
Active Directory domain

An administrative unit in a computer network that, for management convenience, groups several capabilities,
including the following:
Network-wide user identity. In domains, user identities can be created once and then referenced on any
computer that is joined to the forest in which the domain is located. Domain controllers that make up a
domain store user accounts and user credentials, such as passwords or certificates, securely.
Authentication. Domain controllers provide authentication services for users. They also supply additional
authorization data, such as user group memberships. Administrators can use these services to control access
to resources on the network.
Trust relationships. Domains extend authentication services to users in other domains in their own forest
by means of automatic bidirectional trusts. Domains also extend authentication services to users in domains
in other forests by means of either forest trusts or manually created external trusts.
Policy administration. A domain is a scope of administrative policies, such as password complexity and
password reuse rules.
Replication. A domain defines a partition of the directory tree that provides data that is adequate to provide
required services and that is replicated between domain controllers. In this way, all domain controllers are
peers in a domain, and they are managed as a unit.
Active Directory forest

A collection of one or more Active Directory domains that share a common logical structure, directory schema, and
network configuration, as well as automatic, two-way, transitive trust relationships. Each forest is a single instance
of the directory, and it defines a security boundary.
Active Directory functional level

An AD DS setting that enables advanced domain-wide or forest-wide AD DS features.
Migration
The process of moving an object from a source domain to a target domain, while preserving or modifying
characteristics of the object to make it accessible in the new domain.
Domain restructure
A migration process that involves changing the domain structure of a forest. A domain restructure can involve
either the consolidation or the addition of domains, and it can take place between forests or within a forest.
Domain consolidation
A restructuring process that involves eliminating AD DS domains by merging their contents with the contents of
other domains.
Domain upgrade
The process of upgrading the directory service of a domain to a later version of the directory service. This includes
upgrading the operating system on all domain controllers and raising the AD DS functional level where applicable.
In-place domain upgrade

The process of upgrading the operating systems of all domain controllers in a given domain, for example,
upgrading Windows Server 2003 to Windows Server 2008 , and raising the functional level of the domain, if
applicable, while leaving domain objects, such as users and groups, in place.
Forest root domain

The first domain that is created in the Active Directory forest. This domain is automatically designated as the forest
root domain. It provides the foundation for the Active Directory forest infrastructure.
Regional domain
A child domain that is created in a geographic region to optimize replication traffic.
AD DS Deployment
This guide covers how to install and remove Active Directory Domain Services (AD DS ) in Windows Server 2012 ,
and important issues to be aware of when you add new domain controllers to an existing Active Directory
environment.
Upgrade Domain Controllers to Windows Server 2012 R2 and Windows Server 2012
Install Active Directory Domain Services (Level 100)
Steps for removing Active Directory Domain Services
AD DS Installation and Removal Wizard Page Descriptions
Changes Made by Adprep
Windows Server Functional Levels
What's New in Active Directory Domain Services
Installation and Removal
Active Directory Domain Services (AD DS ) deployment in Windows Server 2012 is simpler and faster than
previous versions of Windows Server. The AD DS installation process is now built on Windows PowerShell and is
integrated with Server Manager. The number of steps required to introduce domain controllers into an existing
Active Directory environment is reduced. This makes the process for creating a new Active Directory environment
simpler and more efficient. The new AD DS deployment process minimizes the chances of errors that would have
otherwise blocked installation.
In addition, you can install the AD DS server role binaries (that is the AD DS server role) on multiple servers at the
same time. You can also run the AD DS installation wizard remotely on an individual server. These improvements
provide more flexibility for deploying domain controllers that run Windows Server 2012, especially for large-scale,
global deployments where many domain controllers need to be deployed to offices in different regions.
AD DS installation includes the following features:
Adprep.exe integration into the AD DS installation process. The cumbersome steps required to
prepare an existing Active Directory, such as the need to use a variety of different credentials, copy the
Adprep.exe files, or log on to specific domain controllers, are all simplified or occur automatically. This
reduces the time required to install AD DS and reduces the chances for errors that might otherwise block
domain controller promotion.
For environments where it is preferable to run adprep.exe commands in advance of a new domain controller
installation, you can still execute adprep.exe commands separately from the AD DS installation. The
Windows Server 2012 version of adprep.exe runs remotely, so you can execute all necessary commands
from a server that runs a 64-bit version of Windows Server 2008 or later.
The new AD DS installation is built on Windows PowerShell and can be invoked remotely. The new
AD DS installation is integrated with Server Manager, so you can use the same interface to install AD DS
that you use when installing other server roles. For Windows PowerShell users, the AD DS deployment
cmdlets provide greater functionality and flexibility. There is functional parity between command-line and
GUI installation options.
The new AD DS installation includes prerequisite validation. Any potential errors are identified before the
installation begins. You can correct error conditions before they occur without the concerns resulting from a
partially complete upgrade. For example, if adprep /domainprep needs to be run, the installation wizard verifies
that the user has sufficient rights to execute the operation.
Configuration pages are grouped in a sequence that mirrors the requirements of the most common
promotion options with related options grouped in fewer wizard pages. This provides better context for
making installation choices.
You can export a Windows PowerShell script that contains all the options that were specified during
the graphical installation. At the end of an installation or removal, you can export the settings to a Windows
PowerShell script for use with automating the same operation.
Only critical replication occurs before reboot. New switch to allow replication of non-critical data before
reboot. For more information, see ADDSDeployment cmdlet arguments.
The Active Directory Domain Services Configuration Wizard
Beginning with Windows Server 2012 , the Active Directory Domain Services Configuration Wizard replaces the
legacy Active Directory Domain Services Installation Wizard as the user interface (UI) option to specify settings
when you install a domain controller. The Active Directory Domain Services Configuration Wizard begins after Add
Roles Wizard is finished.
WARNING
The legacy Active Directory Domain Services Installation Wizard (dcpromo.exe) is deprecated beginning with Windows Server
2012.
In Install Active Directory Domain Services (Level 100), the UI procedures show how to start the Add Roles Wizard
to install the AD DS server role binaries and then run the Active Directory Domain Services Configuration Wizard
to complete the domain controller installation. The Windows PowerShell examples show how to complete both
steps using an AD DS deployment cmdlet.
Adprep.exe integration
Beginning with Windows Server 2012, there is only one version of Adprep.exe (there is no 32-bit version,
adprep32.exe). Adprep commands are run automatically as needed when you install a domain controller that runs
Windows Server 2012 to an existing Active Directory domain or forest.
Although adprep operations are run automatically, you can run Adprep.exe separately. For example, if the user who
installs AD DS is not a member of the Enterprise Admins group, which is required in order to run Adprep
/forestprep, then you might need to run the command separately. But, you only have to run adprep.exe if you are
planning to in-place upgrade your first Windows Server 2012 domain controller (in other words, you plan to in-
place upgrade the operating system of a domain controller that runs Windows Server 2012).
Adprep.exe is located in the \support\adprep folder of the Windows Server 2012 installation disc. The Windows
Server 2012 version of adprep is capable of executing remotely.
The Windows Server 2012 version of adprep.exe can run on any server that runs a 64-bit version of Windows
Server 2008 or later. The server needs network connectivity to the schema master for the forest and the
infrastructure master of the domain where you want to add a domain controller. If either of those roles is hosted on
a server that runs Windows Server 2003, then adprep must be run remotely. The server where you run adprep
does not need to be a domain controller. It can be domain joined or in a workgroup.
NOTE
If you try to run the Windows Server 2012 version of adprep.exe on a server that runs Windows Server 2003, the following
error appears:
Adprep.exe is not a valid Win32 application.
For information about resolving other errors returned by Adprep.exe, see Known issues.
Group membership check against Windows Server 2003 operations master roles
For each command (/forestprep, /domainprep, or /rodcprep), Adprep performs a group membership check to
determine whether the specified credential represents an account in certain groups. To perform this check, Adprep
contacts the operations master role owner. If the operations master is running Windows Server 2003, you need to
specify the /user and /userdomain command line parameters if you run Adprep.exe to ensure the group
membership check is performed in all cases.
The /user and /userdomain are new parameters for Adprep.exe in Windows Server 2012 . These parameters
specify the user account name and user domain, respectively, of the user who runs the adprep command. The
Adprep.exe command-line utility blocks specifying one of /userdomain and /user but omitting the other.
However, Adprep operations can also be run as part of an AD DS installation using Windows PowerShell or Server
Manager. Those experiences share the same underlying implementation (adprep.dll) as adprep.exe. The Windows
PowerShell and Server Manager experiences have their separate credentials input, which does not impose the
same requirements as by adprep.exe. Using Windows PowerShell or Server Manager, it is possible to pass a value
for /user but not /userdomain to adprep.dll. If /user is specified but /userdomain is not specified, the local machine's
domain is used to perform the check. If the machine is not domain joined, group membership cannot be checked.
When group membership cannot be checked, Adprep shows a warning message in the adprep log files and
continues:
Adprep was unable to check the specified user's group membership. This could happen if the FSMO role owner <DNS
host name of operations master> is running Windows Server 2003 or lower version of Windows.
If you run Adprep.exe without specifying the /user and /userdomain parameters and the operations master is
running Windows Server 2003, Adprep.exe contacts a domain controller in the domain of the current logon user. If
the current logon user is not a domain account, Adprep.exe cannot perform the group membership check.
Adprep.exe also cannot perform the group membership check if smartcard credentials are used, even if you do
specify both /user and /userdomain.
If Adprep finishes successfully, there is no action required. If Adprep fails during execution with access errors,
provide an account with the correct membership. For more information, see Credential requirements to run
Adprep.exe and install Active Directory Domain Services.
Syntax for Adprep in Windows Server 2012
Use the following syntax to run adprep separately from an AD DS installation:
Adprep.exe /forestprep /forest <forest name> /userdomain <user domain name> /user <user name> /password *
Use /logdsid in the command in order to generate more detailed logging. The adprep.log is located in
%windir%\System32\Debug\Adprep\Logs.
Running adprep using smartcard
The Windows Server 2012 version of adprep.exe works using smartcard as credentials, but there is no easy way to
specify the smart card credential through the command line. One way to do it is to obtain the smart card credential
through PowerShell cmdlet Get-Credential. Then use the user name of the returned PSCredential object, which
appears as @@... . The password is the PIN of the smart card.
Adprep.exe requires /userdomain if /user is specified. For smartcard credentials, the /userdomain should be the
domain of the underlying user account represented by the smartcard.
Adprep /domainprep /gpprep command is not run automatically
The adprep /domainprep /gpprep command is not run as part of AD DS installation. This command sets
permissions that are required for Resultant Set of Policy (RSOP ) planning mode functionality. For more
information about this command, see Microsoft Knowledge Base article 324392. If the command needs to be run
in your Active Directory domain, you can run it separately from the AD DS installation. If the command has already
been run in preparation of deploying domain controllers that run Windows Server 2003 SP1 or later, the command
does not need to be run again.
You can safely add domain controllers that run Windows Server 2012 to an existing domain without running
adprep /domainprep /gpprep, but RSOP planning mode will not function properly.
AD DS installation prerequisite validation

The AD DS installation wizard checks that the following prerequisites are met before the installation begins. This
provides you with a chance to correct issues that can potentially block installation.
For example, Adprep-related prerequisites include:
Adprep credential verification: If adprep needs to be run, the installation wizard verifies that the user has
sufficient rights to execute the required Adprep operations.
Schema master availability check: If the installation wizard determines that adprep /forestprep needs to be run,
it verifies that the schema master is online and fails otherwise.
Infrastructure master availability check: If the installation wizard determines that adprep /domainprep needs to
be run, it verifies that the infrastructure master is online and fails otherwise.
Other prerequisite checks that are carried forward from the legacy Active Directory Installation Wizard
(dcpromo.exe) include:
Forest name verification: Ensures that the forest name is valid and does not currently exist.
NetBIOS name verification: Checks that provided NetBIOS name is valid and does not conflict with existing
names.
Component path verification: Verifies that paths for the Active Directory database, logs, and SYSVOL are valid
and that there is enough disk space available for them.
Child domain name verification: Ensures that the parent and new child domain names are valid and that they do
not conflict with existing domains.
Tree domain name verification: Ensures that the specified tree name is valid and that it does not currently exist.
System requirements
System requirements for Windows Server 2012 are unchanged from Windows Server 2008 R2. For more
information, see Windows Server 2008 R2 with SP1 System Requirements
(https://www.microsoft.com/windowsserver2008/en/us/system-requirements.aspx).
Some features can have additional requirements. For example, the virtual domain controller cloning feature
requires that the PDC emulator run Windows Server 2012 and a computer running Windows Server 2012 with the
Hyper-V role installed.
Known issues
This section lists some of the known issues that affect AD DS installation in Windows Server 2012 . For additional
known issues, see Troubleshooting Domain Controller Deployment.
If WMI access to the schema master is blocked by Windows Firewall when you remotely run adprep
/forestprep, the following error is logged in the adprep log at %systemroot%\system32\debug\adprep:
Adprep encountered a Win32 error.

Error code: 0x6ba Error message: The RPC server is unavailable.
In this case, you can work around the error by either running adprep /forestprep directly on the schema
master, or you can run one of the following commands to allow WMI traffic through Windows Firewall.
For Windows Server 2008 or later:
netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes
For Windows Server 2003:
netsh firewall set service RemoteAdmin enable
After adprep finishes you can run either of the following commands to block WMI traffic again:
netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=no
netsh firewall set service remoteadmin disable
You can type Ctrl + C to cancel the Install-ADDSForest cmdlet. The cancellation stops the installation and
any changes that were made to the state of the server are reverted. But after the cancellation command is
issued, control is not returned to Windows PowerShell, and the cmdlet can hang indefinitely.
Installation of an additional domain controller using smart card credentials fails if the target
server is not joined to the domain before installation.
The error message returned in this case is:
Unable to connect to the replication source domain controller source domain controller name. (Exception:
Logonfailure: unknown user name or bad password)
If you join the target server to the domain and then perform the installation using a smart card, the
installation succeeds.
The ADDSDeployment module does not run under 32-bit processes. If you are automating
deployment and configuration of Windows Server 2012 using a script that includes an ADDSDeployment
cmdlet and any other cmdlet that does not support native 64-bit processes, the script can fail with an error
that indicates the ADDSDeployment cmdlet cannot be found.
In this case, you need to run the ADDSDeployment cmdlet separately from the cmdlet that does not support
native 64-bit processes.
There is a new file system in Windows Server 2012 named Resilient File System. Do not store the Active
Directory database, log files, or SYSVOL on a data volume formatted with Resilient File System (ReFS ). For
more information about ReFS, see Building the next generation file system for Windows: ReFS.
In Server Manager, servers that run AD DS or other server roles on a Server Core installation and have been
upgraded to Windows Server 2012 , the server role can appear with red status, even though events and status
are collected as expected. Servers that run a Server Core installation of a preliminary release Windows Server
2012 can also be impacted.
Active Directory Domain Services installation hangs if an error prevents critical replication
If the AD DS installation encounters an error during the critical replication phase, the installation can hang
indefinitely. For example, if networking errors prevent critical replication from completing, the installation will not
proceed.
If you are installing using Server Manager, you may see the installation progress page remain open, but there is no
error reported on screen, and the progress may not change for about 15 minutes. If you are using Windows
PowerShell, the progress shown in the Windows PowerShell window will not change for more than 15 minutes.
If you experience this problem, check the dcpromo.log file in the %systemroot%\debug folder on the target server.
The log file will typically indicate repeated failures to replicate. Some known causes for this problem are:
Networking problems prevent critical replication between the target server being promoted and the
replication source domain controller.
For example, the dcpromo.log shows:
05/02/2012 14:16:46 [INFO] EVENTLOG (Error): NTDS Replication / DS RPC Client : 1963
Internal event: The following local directory service received an exception from a remote procedure call
(RPC) connection. Extensive RPC information was requested. This is intermediate information and might
not contain a possible cause.
Process ID:
500
Reported error information:
Error value:
Could not find the domain controller for this domain. (1908)
directory service:
<domain>.com
Extensive error information:
Error value:
A security package specific error occurred. 1825
directory service:
<DC Name>
Because the installation process retries critical replication indefinitely, the domain controller installation
proceeds if the underlying network problems are resolved. Investigate the networking problem using tools
such as ipconfig, nslookup, and netmon as needed. Ensure connectivity exists between the domain controller
you are promoting and the replication partner selected during the AD DS installation. Also make sure name
resolution is working.
AD DS installation requirements for network connectivity and name resolution are validated during the
prerequisite check before the installation begins. But some error conditions can arise in the time after
prerequisite validation occurs and before the installation completes, such as if the replication partner
becomes unavailable during installation.
During replica domain controller installation, the local Administrator account of the target server is specified
for the installation credentials and the password of the local Administrator account matches the password of
a Domain Admin account. In this case, you can complete the installation wizard and begin the installation
before you encounter the "Access is denied" failure.
For example, the dcpromo.log shows:
03/30/2012 11:36:51 [INFO] Creating the NTDS Settings object for this Active Directory Domain Controller
on the remote AD DC DC2.contoso.com...
03/30/2012 11:36:51 [INFO] EVENTLOG (Error): NTDS Replication / DS RPC Client : 1963Internal event: The
following local directory service received an exception from a remote procedure call (RPC) connection.
Extensive RPC information was requested. This is intermediate information and might not contain a
possible cause.
Process ID:
508
Reported error information:
Error value:
Access is denied. (5)
directory service:
DC2.contoso.com
If the error is caused by specifying a local Administrator account and password, in order to recover you need
to reinstall the operating system, perform metadata cleanup of the account for the domain controller that
failed to complete installation, and then retry the AD DS installation using Domain Admin credentials.
Restarting the server will not correct this error condition because the server will indicate that AD DS is
installed even though the installation did not finish successfully.
Active Directory Domain Services Configuration Wizard warns when a non-normalized DNS name is specified
If you create a new domain or forest and you specify a DNS domain name that includes internationalized
characters that are not normalized, then the Active Directory Domain Services Configuration Wizard displays a
warning that DNS queries for the name can fail. Although the DNS domain name is specified in the Deployment
Configuration page, the warning appears on the Prerequisites Check page later in the wizard.
If a DNS domain name is specified using an un-normalized name like füßball.com or 'ΣΤ'.com (the normalized
versions are: füssball.com and βστα.com), client applications that try to access it with WinHTTP will normalize the
name before calling name resolution APIs. If the user types "'ΣΤ'.com" on some dialog, the DNS query will be sent
as "βστα.com" and no DNS server will match it with a resource record for "'ΣΤ'.com". The user will be unable to
resolve name.
The following example explains one of the issues that can happen when using an IDN name that is not normalized:
1. The domain using a non-normalized name is created and registered on dns server: füßball.com
2. Machine "nps" is joined to the domain and gets its name registered: nps.füßball.com
3. A client application tries to connect to the server nps.füßball.com
4. The client application tries to resolve the name nps.füßball.com calling name resolution APIs.
5. Due to normalization, the name gets converted to nps.füssball.com and is queried over the wire as
nps.füßball.com
6. The client application is unable to resolve the name since the registered name is nps.füßball.com
If the warning appears in the Prerequisites Check page in the Active Directory Domain Services Configuration
Wizard, return to the Deployment Configuration page and specify a normalized DNS domain name. If you are
installing a new domain using Windows PowerShell, specify a normalized DNS name for the -DomainName
option.
For more information about IDNs, see Handling Internationalized Domain Names (IDNs).

This topic provides background information about Active Directory Domain Services in Windows Server 2016 and
explains the process for upgrading domain controllers from Windows Server 2012 or Windows Server 2012 R2.
Pre-requisites
The recommended way to upgrade a domain is to promote domain controllers that run newer versions of
Windows Server and demote the older domain controllers as needed. That method is preferable to upgrading the
operating system of an existing domain controller. This list covers general steps to follow before you promote a
domain controller that runs a newer version of Windows Server:
1. Verify the target server meets system requirements.
2. Verify Application compatibility.
3. Review Recommendations for moving to Windows Server 2016
4. Verify security settings. For more information, see Deprecated features and behavior changes related to AD DS
in Windows Server 2016.
5. Check connectivity to the target server from the computer where you plan to run the installation.
6. Check for availability of necessary operation master roles:
To install the first DC that runs Windows Server 2016 in an existing domain and forest, the machine
where you run the installation needs connectivity to the schema master in order to run adprep
/forestprep and the infrastructure master in order to run adprep /domainprep.
To install the first DC in a domain where the forest schema is already extended, you only need
connectivity to infrastructure master.
To install or remove a domain in an existing forest, you need connectivity to the domain naming
master.
Any domain controller installation also requires connectivity to the RID master.
If you are installing the first read-only domain controller in an existing forest, you need connectivity to
the infrastructure master for each application directory partition, also known as a non-domain naming
context or NDNC.
Installation steps and required administrative levels
The following table provides a summary of the upgrade steps and the permission requirements to accomplish
these steps
INSTALLATION ACTION CREDENTIAL REQUIREMENTS
Install a new forest Local Administrator on the target server
Install a new domain in an existing forest Enterprise Admins
Install an additional DC in an existing domain Domain Admins
Run adprep /forestprep Schema Admins, Enterprise Admins, and Domain Admins
Run adprep /domainprep Domain Admins
Run adprep /domainprep /gpprep Domain Admins
Run adprep /rodcprep Enterprise Admins
For additional information on new features in Windows Server 2016, see What's new in Windows Server 2016.
Supported in-place upgrade paths

Domain controllers that run 64-bit versions of Windows Server 2012 or Windows Server 2012 R2 can be
upgraded to Windows Server 2016. Only 64-bit version upgrades are supported because Windows Server 2016
only comes in a 64-bit version.
IF YOU ARE RUNNING THIS EDITION: YOU CAN UPGRADE TO THESE EDITIONS:
Windows Server 2012 Standard Windows Server 2016 Standard or Datacenter
Windows Server 2012 Datacenter Windows Server 2016 Datacenter
Windows Server 2012 R2 Standard Windows Server 2016 Standard or Datacenter
Windows Server 2012 R2 Datacenter Windows Server 2016 Datacenter
Windows Server 2012 R2 Essentials Windows Server 2016 Essentials
Windows Storage Server 2012 Standard Windows Storage Server 2016 Standard
Windows Storage Server 2012 Workgroup Windows Storage Server 2016 Workgroup
Windows Storage Server 2012 R2 Standard Windows Storage Server 2016 Standard
Windows Storage Server 2012 R2 Workgroup Windows Storage Server 2016 Workgroup
For more information about supported upgrade paths, see Supported Upgrade Paths
Adprep and Domainprep

If you are doing an in-place upgrade of an existing domain controller to the Windows Server 2016 operating
system, you will need to run adprep /forestprep and adprep /domainprep manually. Adprep /forestprep needs to
be run only once in the forest. Adprep /domainprep needs to be run once in each domain in which you have
domain controllers that you are upgrading to Windows Server 2016.
If you are promoting a new Windows Server 2016 server you do not need to run these manually. These are
integrated into the PowerShell and Server Manager experiences.
For more information on running adprep see Running Adprep
Functional level features and requirements

Windows Server 2016 requires a Windows Server 2003 forest functional level. That is, before you can add a
domain controller that runs Windows Server 2016 to an existing Active Directory forest, the forest functional level
must be Windows Server 2003 or higher. If the forest contains domain controllers running Windows Server 2003
or later but the forest functional level is still Windows 2000, the installation is also blocked.
Windows 2000 domain controllers must be removed prior to adding Windows Server 2016 domain controllers to
your forest. In this case, consider the following workflow:
1. Install domain controllers that run Windows Server 2003 or later. These domain controllers can be deployed on
an evaluation version of Windows Server. This step also requires running adprep.exe for that operating system
release as a prerequisite.
2. Remove the Windows 2000 domain controllers. Specifically, gracefully demote or forcibly remove Windows
Server 2000 domain controllers from the domain and used Active Directory Users and Computers to remove
the domain controller accounts for all removed domain controllers.
3. Raise the forest functional level to Windows Server 2003 or higher.
4. Install domain controllers that run Windows Server 2016.
5. Remove domain controllers that run earlier versions of Windows Server.
Rolling back functional levels
After you set the forest functional level (FFL ) to a certain value, you cannot roll back or lower the forest functional
level, with the following exceptions:
If you are upgrading from Windows Server 2012 R2 FFL, you can lower it back to Windows Server 2012 R2.
If you are upgrading from Windows Server 2008 R2 FFL, you can lower it back to Windows Server 2008 R2.
After you set the domain functional level to a certain value, you cannot roll back or lower the domain functional
level, with the following exceptions:
when you raise the domain functional level to Windows Server 2016 and if the forest functional level is
Windows Server 2012 or lower, you have the option of rolling the domain functional level back to Windows
Server 2012 or Windows Server 2012 R2
For more information about features that are available at lower functional levels, see Understanding Active
Directory Domain Services (AD DS ) Functional Levels.
AD DS interoperability with other server roles and Windows operating

systems
AD DS is not supported on the following Windows operating systems:
Windows MultiPoint Server
Windows Server 2016 Essentials
AD DS cannot be installed on a server that also runs the following server roles or role services:
Microsoft Hyper-V Server 2016
Remote Desktop Connection Broker
Administration of Windows Server 2016 servers

Use the Remote Server Administration Tools for Windows 10 to manage domain controllers and other servers that
run Windows Server 2016. You can run the Windows Server 2016 Remote Server Administration Tools on a
computer that runs Windows 10.
Step-by-Step for Upgrading to Windows Server 2016

The following is a simple example of upgrading the Contoso forest from Windows Server 2012 R2 to Windows
Server 2016.
1. Join the new Windows Server 2016 to your forest. Restart when prompted.
2. Sign in to the new Windows Server 2016 with a domain admin account.
3. In Server Manager, under Add Roles and Features, install Active Directory Domain Services on the new
Windows Server 2016. This will automatically run adprep on the 2012 R2 forest and domain.
4. In Server Manager, click the yellow triangle, and from the drop-down click Promote the server to a domain
controller.
5. On the Deployment Configuration screen, select Add a domain controller to an existing forest and click
next.
6. On the Domain Controller options screen, enter the Directory Services Restore Mode (DSRM ) password
and click next.
7. For the remainder of the screens click Next.
8. On the Prerequisite Check screen, click install. Once the restart has completed you can sign back in.
9. On the Windows Server 2012 R2 server, in Server Manager, under tools, select Active Directory Module
for Windows PowerShell.
10. In the PowerShell windows use the Move-ADDirectoryServerOperationMasterRole to move the FSMO
roles. You can type the name of each -OperationMasterRole or use numbers to specify the roles. For more
information see Move-ADDirectoryServerOperationMasterRole
Move-ADDirectoryServerOperationMasterRole -Identity "DC-W2K16" -OperationMasterRole 0,1,2,3,4

11. Verify the roles have been moved by going to the Windows Server 2016 server, in Server Manager, under
tools, select Active Directory Module for Windows PowerShell. Use the Get-ADDomain and Get-ADForest
cmdlets to view the FSMO role holders.
12. Demote and remove the Windows Server 2012 R2 domain controller. For information on demoting a dc, see
Demoting Domain Controllers and Domains
13. Once the server is demoted and removed you can raise the forest functional and domain functional levels to
Next Steps
Windows Server 2016 Functional Levels
R2 and Windows Server 2012
This topic provides background information about Active Directory Domain Services in Windows Server 2012 R2
and Windows Server 2012 and explains the process for upgrading domain controllers from Windows Server 2008
or Windows Server 2008 R2.
Domain controller upgrade steps

The recommended way to upgrade a domain is to promote domain controllers that run newer versions of
Windows Server and demote older domain controllers as needed. That method is preferable to upgrading the
operating system of an existing domain controller. This list covers general steps to follow before you promote a
domain controller that runs a newer version of Windows Server:
1. Verify the target server meets system requirements.
2. Verify Application compatibility.
3. Verify security settings. For more information, see Deprecated features and behavior changes related to AD DS
in Windows Server 2012 and Secure default settings in Windows Server 2008 and Windows Server 2008 R2.
4. Check connectivity to the target server from the computer where you plan to run the installation.
5. Check for availability of necessary operation master roles:
To install the first DC that runs Windows Server 2012 in an existing domain and forest, the machine
where you run the installation needs connectivity to the schema master in order to run adprep
/forestprep and the infrastructure master in order to run adprep /domainprep.
To install the first DC in a domain where the forest schema is already extended, you only need
connectivity to infrastructure master.
To install or remove a domain in an existing forest, you need connectivity to the domain naming master.
Any domain controller installation also requires connectivity to the RID master.
If you are installing the first read-only domain controller in an existing forest, you need connectivity to the
infrastructure master for each application directory partition, also known as a non-domain naming
context or NDNC.
6. Be sure to supply the necessary credentials to run the AD DS installation.
Install a new forest Local Administrator on the target server
Install a new domain in an existing forest Enterprise Admins
Install an additional DC in an existing domain Domain Admins
Run adprep /forestprep Schema Admins, Enterprise Admins, and Domain Admins
Run adprep /domainprep Domain Admins

Run adprep /domainprep /gpprep Domain Admins
Run adprep /rodcprep Enterprise Admins
You can delegate permissions to install AD DS. For more information, see Installation Management Tasks.
Steps-by-step instructions to promote new and replica Windows Server 2012 domain controllers using Windows
PowerShell cmdlets and Server Manager can be found in the following links:
Install a New Windows Server 2012 Active Directory Forest (Level 200)
Install a Replica Windows Server 2012 Domain Controller in an Existing Domain (Level 200)
Install a New Windows Server 2012 Active Directory Child or Tree Domain (Level 200)
Install a Windows Server 2012 Active Directory Read-Only Domain Controller (RODC ) (Level 200)
Step-by-Step Guide for Setting Up Windows Server 2012 Domain Controller (en-US )
Windows Update considerations

Prior to the release of Windows 8, Windows Update managed its own internal schedule to check for updates, and
to download and install them. It required that the Windows Update Agent was always running in the background,
consuming memory and other system resources.
Windows 8 and Windows Server 2012 introduce a new feature called Automatic Maintenance. Automatic
Maintenance consolidates many different features that each used to manage its own scheduling and execution
logic. This consolidation allows for all these components to use far less system resources, work consistently, respect
the new Connected Standby state for new device types, and consume less battery on portable devices.
Because Windows Update is a part of Automatic Maintenance in Windows 8 and Windows Server 2012, its own
internal schedule for setting a day and time to install updates is no longer effective. To help ensure consistent and
predictable restart behavior for all devices and computers in your enterprise, including those that run Windows 8
and Windows Server 2012, see Microsoft KB article 2885694 (or see October 2013 cumulative rollup 2883201),
then configure policy settings described in the WSUS blog post Enabling a more predictable Windows Update
experience for Windows 8 and Windows Server 2012 (KB 2885694).
What's new in AD DS in Windows Server 2012 R2?

The following table summarizes new features for AD DS in Windows Server 2012 R2, with a link to more detailed
information where it is available. For a more detailed explanation of some features, including their requirements,
see What's New in Active Directory in Windows Server 2012 R2.
FEATURE DESCRIPTION
Workplace Join Allows information workers to join their personal devices with
their company to access company resources and services.
Web Application Proxy Provides access to web application using a new Remote Access
role service.
Active Directory Federation Services AD FS has simplified deployment and improvements to enable
users to access resources from personal devices and help IT
departments manage access control.
FEATURE DESCRIPTION
SPN and UPN uniqueness Domain Controllers running Windows Server 2012 R2 block
the creation of duplicate service principal names (SPNs) and
user principal names (UPNs).
Winlogon Automatic Restart Sign-On (ARSO) Enables lock screen applications to be restarted and available
on Windows 8.1 devices.
TPM Key Attestation Enables CAs to cryptographically attest in an issued certificate

that the certificate requester private key is actually protected
by a Trusted Platform Module (TPM).
Credentials Protection and Management New credential protection and domain authentication controls
to reduce credential theft.
Deprecation of File Replication Service (FRS) The Windows Server 2003 domain functional level is also
deprecated because at the functional level, FRS is used to
replicate SYSVOL. That means when you create a new domain
on a server that runs Windows Server 2012 R2, the domain
functional level must be Windows Server 2008 or newer. You
can still add a domain controller that runs Windows Server
2012 R2 to an existing domain that has a Windows Server
2003 domain functional level; you just can't create a new
domain at that level.
New domain and forest functional levels There are new functional levels for Windows Server 2012 R2.
New features are available at Windows Server 2012 R2 DFL.
LDAP query optimizer changes Performance improvement in LDAP search efficiency and LDAP
search time of complex queries.
1644 Event improvements LDAP search result statistics were added to event ID 1644 to
aid in troubleshooting.
Active Directory replication throughput improvement Adjusts the maximum AD Replication throughput from
40Mbps to around 600 Mbps
What's new in AD DS in Windows Server 2012?

The following table summarizes the new features for AD DS in Windows Server 2012, with a link to more detailed
information where it is available. For a more detailed explanation of some features, including their requirements,
see What's New in Active Directory Domain Services (AD DS ).
FEATURE DESCRIPTION
Active Directory-Based Activation (AD BA) see Volume Simplifies the task of configuring the distribution and
Activation Overview management of volume software licenses.
Active Directory Federation Services (AD FS) Adds role install via Server Manager, simplified trust-setup,
automatic trust management, SAML-protocol support, and
more.
Active Directory lost page flush events NTDS ISAM event 530 with jet error -1119 is logged to detect
lost page flush events to Active Directory databases.
FEATURE DESCRIPTION
Active Directory Recycle Bin User Interface Active Directory Administrative Center (ADAC) adds GUI
management of recycle bin feature originally introduced in
Windows Server 2008 R2.
Active Directory Replication and Topology Windows PowerShell Supports the creation and management of Active Directory
cmdlets sites, site-links, connection objects, and more using Windows
PowerShell.
Dynamic Access Control New claims-based authorization platform that enhances the
legacy access control model.
Fine-Grained Password Policy User Interface ADAC adds GUI support for the creating, editing and
assignment of PSOs originally added in Windows Server 2008.
Group Managed Service Accounts (gMSA) A new security principal type known as a gMSA. Services
running on multiple hosts can run under the same gMSA
account.
DirectAccess Offline Domain Join Extends offline domain-join by including DirectAccess

prerequisites.
Rapid deployment via virtual domain controller (DC) cloning Virtualized DCs can be rapidly deployed by cloning existing
virtual domain controllers using Windows PowerShell cmdlets.
RID pool changes Adds new monitoring events and quotas to safeguard against
excessive consumption of the global RID pool. Optionally
doubles the size of the global RID pool if the original pool
becomes exhausted.
Secure Time service Enhances security for W32tm by removing secrets from the
wire, removing the MD5 hash functions and requiring the
server to authenticate with Windows 8 time clients
USN rollback protection for virtualized DCs Accidentally restoring snapshot backups of virtualized DCs no
longer causes USN rollback.
Windows PowerShell History Viewer Allow administrators to view the Windows PowerShell
commands executed when using ADAC.
Automatic Maintenance and changes to restart behavior after updates are applied by Windows Update
Prior to the release of Windows 8, Windows Update managed its own internal schedule to check for updates, and
to download and install them. It required that the Windows Update Agent was always running in the background,
consuming memory and other system resources.
Windows 8 and Windows Server 2012 introduce a new feature called Automatic Maintenance. Automatic
Maintenance consolidates many different features that each used to manage its own scheduling and execution
logic. This consolidation allows for all these components to use far less system resources, work consistently, respect
the new Connected Standby state for new device types, and consume less battery on portable devices.
Because Windows Update is a part of Automatic Maintenance in Windows 8 and Windows Server 2012, its own
internal schedule for setting a day and time to install updates is no longer effective. To help ensure consistent and
predictable restart behavior for all devices and computers in your enterprise, including those that run Windows 8
and Windows Server 2012, you can configure the following Group Policy settings:
Computer Configuration|Policies|Administrative Templates|Windows Components|Windows
Update|Configure Automatic Updates
Computer Configuration|Policies|Administrative Templates|Windows Components|Windows
Update|No auto-restart with logged on users
Computer Configuration|Policies|Administrative Templates|Windows Components|Maintenance
Scheduler|Maintenance Random Delay
The following table lists some examples of how to configure these settings to provide desired restart behavior.
Scenario Recommended configuration(s)
WSUS managed Set machines to auto-install, prevent auto-reboot until desired

time
- Install updates once per week
- Reboot Fridays at 11PM Policy: Configure Automatic Updates (Enabled)
Configure automatic updating: 4 - Auto download and

schedule the install
Policy: No auto-restart with logged-on users (Disabled)
WSUS deadlines: set to Fridays at 11PM
WSUS managed Set target groups for different groups of machines that should
be updated together
- Stagger installs across different hours/days
Use above steps for previous scenario
Set different deadlines for different target groups
Not WSUS-managed - no support for deadlines Policy: Configure Automatic Updates (Enabled)
- Stagger installs at different times Configure automatic updating: 4 - Auto download and
schedule the install
Registry key: Enable the registry key discussed in Microsoft

KB article 2835627
Policy: Automatic Maintenance Random Delay (Enabled)
Set Regular maintenance random delay to PT6H for 6-hour

random delay to provide the following behavior:
- Updates will install at the configured maintenance time plus

a random delay
- Restart for each machine will take place exactly 3 days later
Alternatively, set a different maintenance time for each group

of machines
For more information about why the Windows engineering team implemented these changes, see Minimizing
restarts after automatic updating in Windows Update.
AD DS server role installation changes

In Windows Server 2003 through Windows Server 2008 R2, you ran the x86 or X64 version of the Adprep.exe
command-line tool before running the Active Directory Installation Wizard, Dcpromo.exe, and Dcpromo.exe had
optional variants to install from media or for unattended installation.
Beginning in Windows Server 2012, command-line installations are performed by using the ADDSDeployment
Module in Windows PowerShell. GUI-based promotions are performed in Server Manager using a completely new
AD DS Configuration Wizard. To simplify the installation process, ADPREP has been integrated into the AD DS
installation and runs automatically as needed. The Windows PowerShell-based AD DS Configuration Wizard
automatically targets the schema and infrastructure master roles in the domains where DCs are being added, then
remotely runs the required ADPREP commands on the relevant domain controllers.
Prerequisite checks in the AD DS Installation Wizard identify potential errors before the installation begins. Error
conditions can be corrected to eliminate concerns from a partially complete upgrade. The wizard also exports a
Windows PowerShell script that contains all the options that were specified during the graphical installation.
Taken together, the AD DS installation changes simplify the DC role installation process and reduce the likelihood
of administrative errors, especially when you are deploying multiple domain controllers across global regions and
domains.
More detailed information on GUI and Windows PowerShell-based installations, including command line syntax
and step-by-step wizard instructions, see Install Active Directory Domain Services. For administrators that want to
control the introduction of schema changes in an Active Directory forest independent of the installation of
Windows Server 2012 DCs in an existing forest, Adprep.exe commands can still be run at an elevated command
prompt.
Deprecated features and behavior changes related to AD DS in

Windows Server 2012
There are some changes related to AD DS:
Deprecation of Adprep32.exe
There is only one version of Adprep.exe and it can be run as needed on 64-bit servers that run Windows
Server 2008 or later. It can be run remotely, and must be run remotely if that targeted operations master
role is hosted on a 32-bit operating system or Windows Server 2003.
Deprecation of Dcpromo.exe
Dcpromo is deprecated although in Windows Server 2012 only it can still be run with an answer file or
command line parameters to give organizations time to transition existing automation to the new
Windows PowerShell installation options.
LMHash is disabled on user accounts
Secure defaults in Security templates on Windows Server 2008, Windows Server 2008 R2 and Windows
Server 2012 enable the NoLMHash policy which is disabled in the security templates of Windows 2000
and Windows Server 2003 domain controllers. Disable the NoLMHash policy for LMHash-dependent
clients as required, using the steps in KB article 946405.
Beginning with Windows Server 2008 , domain controllers also have the following secure default settings,
compared to domain controllers that run Windows Server 2003 or Windows 2000.
Encryption type or policy Windows Server 2008 Windows Server 2012 and Comment
default Windows Server 2008 R2
default
AllowNT4Crypto Disabled Disabled Third-party Server Message
Block (SMB) clients may be
incompatible with the secure
default settings on domain
controllers. In all cases, these
settings can be relaxed to
allow interoperability, but
only at the expense of
security. For more
information, see article
942564 in the Microsoft
Knowledge Base
(https://go.microsoft.com/fwl
ink/?LinkId=164558).
DES Enabled Disabled Article 977321 in the

Microsoft Knowledge Base
ink/?LinkId=177717)
CBT/Extended Protection for N/A Enabled See Microsoft Security

Integrated Authentication Advisory (937811)
ink/?LinkId=164559) and
article 976918 in the
ink/?LinkId=178251).
Review and install the hotfix

in article 977073
ink/?LinkId=186394) in the
Microsoft Knowledge Base as
required.
LMv2 Enabled Disabled Article 976918 in the

ink/?LinkId=178251)
Operating system requirements

The minimum system requirements for Windows Server 2012 are listed in the following table. For more
information about system requirements and pre-installation information, see Installing Windows Server 2012.
There are no additional system requirements to install a new Active Directory forest, but you should add sufficient
memory to cache the contents of Active Directory database in order to improve performance for domain
controllers, LDAP client requests, and Active Directory-enabled applications. If you are upgrading an existing
domain controller or adding a new domain controller to an existing forest, review the next section to ensure the
server meets disk space requirements.
Processor 1.4 Ghz 64-bit processor
RAM 512 MB
Free disk space requirements 32 GB
Screen resolution 800 x 600 or higher
Miscellaneous DVD drive, keyboard, Internet access
Disk space requirements for upgrading domain controllers

This section covers disk space requirements only for upgrading domain controllers from Windows Server 2008 or
Windows Server 2008 R2 . For more information about disk space requirements for upgrading domain controllers
to earlier versions of Windows Server, see Disk space requirements for upgrading to Windows Server 2008 or Disk
space requirements for upgrading to Windows Server 2008 R2.
Size the disk that hosts the Active Directory database and log files in order to accommodate the custom and
application-driven schema extensions, application and administrator-initiated indexes, plus space for the objects
and attributes that you will be added to the directory over deployment life of the domain controller (typically 5 to 8
years). Right sizing at deployment time is typically a good investment compared to greater touch costs required to
expand disk storage after deployment. For more information, see Capacity Planning for Active Directory Domain
Services.
On domain controllers that you plan to upgrade, make sure that the drive that hosts the Active Directory database
(NTDS.DIT) has free disk space that represents at least 20% of the NTDS.DIT file before you begin the operating
system upgrade. If there is insufficient free disk space on the volume, the upgrade can fail and the upgrade
compatibility report returns an error indicating insufficient free disk space:
In this case, you can try an offline defragmentation of the Active Directory database to recapture additional space,
and then retry the upgrade. For more information, see Compact the Directory Database File (Offline
Defragmentation).
Available SKUs
There are 4 editions of Windows Server: Foundation, Essentials, Standard and Datacenter. The two editions that
support the AD DS role are Standard and Datacenter.
In previous releases, Windows Server editions differed in their support of server roles, processor counts and large
memory support. The Standard and Datacenter editions of Windows Server support all features and underlying
hardware but vary in their virtualization rights - two virtual instances are allowed for Standard edition and
unlimited virtual instances are allowed for Datacenter edition.
Windows client and Windows Server operating systems that are supported to join Windows Server domains
The following Windows client and Windows Server operating systems are supported for domain member
computers with domain controllers that run Windows Server 2012 or later:
Client operating systems: Windows 8.1, Windows 8, Windows 7, Windows Vista
Computers that run Windows 8.1 or Windows 8 are also able to join domains that have domain
controllers that run earlier version of Windows Server, including Windows Server 2003 or later. In this
case however, some Windows 8 features may require additional configuration or may not be available.
For more information about those features and other recommendations for managing Windows 8 clients
in downlevel domains, see Running Windows 8 member computers in Windows Server 2003 domains.
Server operating systems: Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2,
Windows Server 2008, Windows Server 2003 R2, Windows Server 2003
Supported in-place upgrade paths

Domain controllers that run 64-bit versions of Windows Server 2008 or Windows Server 2008 R2 can be
upgraded to Windows Server 2012 . You cannot upgrade domain controllers that run Windows Server 2003 or 32-
bit versions of Windows Server 2008. To replace them, install domain controllers that run a later version of
Windows Server in the domain, and then remove the domain controllers that Windows Server 2003.
IF YOU ARE RUNNING THESE EDITIONS YOU CAN UPGRADE TO THESE EDITIONS
Windows Server 2008 Standard with SP2 Windows Server 2012 Standard
OR OR
Windows Server 2008 Enterprise with SP2 Windows Server 2012 Datacenter
Windows Server 2008 Datacenter with SP2 Windows Server 2012 Datacenter
Windows Web Server 2008 Windows Server 2012 Standard
Windows Server 2008 R2 Standard with SP1 Windows Server 2012 Standard
OR OR
Windows Server 2008 R2 Enterprise with SP1 Windows Server 2012 Datacenter
Windows Server 2008 R2 Datacenter with SP1 Windows Server 2012 Datacenter
Windows Web Server 2008 R2 Windows Server 2012 Standard
For more information about supported upgrade paths, see Evaluation Versions and Upgrade Options for Windows
Server 2012. Note that you cannot convert a domain controller that runs an evaluation version of Windows Server
2012 directly to a retail version. Instead, install an additional domain controller on a server that runs a retail version
and remove AD DS from the domain controller that runs on the evaluation version.
Due to a known issue, you cannot upgrade a domain controller that runs a Server Core installation of Windows
Server 2008 R2 to a Server Core installation of Windows Server 2012 . The upgrade will hang on a solid black
screen late in the upgrade process. Rebooting such DCs exposes an option in boot.ini file to roll back to the
previous operating system version. An additional reboot triggers the automatic rollback to the previous operating
system version. Until a solution is available, it is recommended that you install a new domain controller running a
Server Core installation of Windows Server 2012 instead of in-place upgrading an existing domain controller that
runs a Server Core installation of Windows Server 2008 R2. For more information, see KB article 2734222.
Functional level features and requirements

Windows Server 2012 requires a Windows Server 2003 forest functional level. That is, before you can add a
domain controller that runs Windows Server 2012 to an existing Active Directory forest, the forest functional level
must be Windows Server 2003 or higher. This means that domain controllers that run Windows Server 2008 R2,
Windows Server 2008, or Windows Server 2003 can operate in the same forest, but domain controllers that run
Windows 2000 Server are not supported and will block installation of a domain controller that runs Windows
Server 2012. If the forest contains domain controllers running Windows Server 2003 or later but the forest
functional level is still Windows 2000, the installation is also blocked.
Windows 2000 domain controllers must be removed prior to adding Windows Server 2012 domain controllers to
your forest. In this case, consider the following workflow:
1. Install domain controllers that run Windows Server 2003 or later. These domain controllers can be deployed on
an evaluation version of Windows Server. This step also requires running adprep.exe for that operating system
release as a prerequisite.
2. Remove the Windows 2000 domain controllers. Specifically, gracefully demote or forcibly remove Windows
Server 2000 domain controllers from the domain and used Active Directory Users and Computers to remove
the domain controller accounts for all removed domain controllers.
3. Raise the forest functional level to Windows Server 2003 or higher.
4. Install domain controllers that run Windows Server 2012.
5. Remove domain controllers that run earlier versions of Windows Server.
The new Windows Server 2012 domain functional level enables one new feature: the KDC support for claims,
compound authentication, and Kerberos armoring KDC administrative template policy has two settings
(Always provide claims and Fail unarmored authentication requests) that require Windows Server 2012
domain functional level.
The Windows Server 2012 forest functional level does not provide any new features, but it ensures that any new
domain created in the forest will automatically operate at the Windows Server 2012 domain functional level. The
Windows Server 2012 domain functional level does not provide other new features beyond KDC support for
claims, compound authentication, and Kerberos armoring. But it ensures that any domain controller in the domain
runs Windows Server 2012 . For more information about other features that are available at different functional
levels, see Understanding Active Directory Domain Services (AD DS ) Functional Levels.
After you set the forest functional level to a certain value, you cannot roll back or lower the forest functional level,
with the following exceptions: after you raise the forest functional level to Windows Server 2012 , you can lower it
to Windows Server 2008 R2 . If Active Directory Recycle Bin has not been enabled, you can also lower the forest
functional level from Windows Server 2012 to Windows Server 2008 R2 or Windows Server 2008 or from
Windows Server 2008 R2 back to Windows Server 2008 . If the forest functional level is set to Windows Server
2008 R2 , it cannot be rolled back, for example, to Windows Server 2003.
After you set the domain functional level to a certain value, you cannot roll back or lower the domain functional
level, with the following exceptions: when you raise the domain functional level to Windows Server 2008 R2 or
Windows Server 2012 , and if the forest functional level is Windows Server 2008 or lower, you have the option of
rolling the domain functional level back to Windows Server 2008 or Windows Server 2008 R2 . You can lower the
domain functional level only from Windows Server 2012 to Windows Server 2008 R2 or Windows Server 2008 or
from Windows Server 2008 R2 to Windows Server 2008 . If the domain functional level is set to Windows Server
2008 R2 , it cannot be rolled back, for example, to Windows Server 2003.
For more information about features that are available at lower functional levels, see Understanding Active
Directory Domain Services (AD DS ) Functional Levels.
Beyond functional levels, a domain controller that runs Windows Server 2012 provides additional features that are
not available on a domain controller that runs an earlier version of Windows Server. For example, a domain
controller that runs Windows Server 2012 can be used for virtual domain controller cloning, whereas a domain
controller that runs an earlier version of Windows Server cannot. But virtual domain controller cloning and virtual
domain controller safeguards in Windows Server 2012 do not have any functional level requirements.
NOTE
Microsoft Exchange Server 2013 requires a forest functional level of Windows server 2003 or higher.
AD DS interoperability with other server roles and Windows operating

systems
AD DS is not supported on the following Windows operating systems:
Windows MultiPoint Server
Windows Server 2012 Essentials
AD DS cannot be installed on a server that also runs the following server roles or role services:
Hyper-V Server
Remote Desktop Connection Broker
Operations master roles

Some new features in Windows Server 2012 affect operations master roles:
The PDC emulator must be running Windows Server 2012 to support cloning virtual domain controllers. There
are additional prerequisites for cloning DCs. For more information, see Active Directory Domain Services (AD
DS ) Virtualization.
New security principals are created when the PDC emulator runs Windows Server 2012 .
The RID Master has new RID issuance and monitoring functionality. The improvements include better event
logging, more appropriate limits, and the ability to - in an emergency - increase the overall RID pool allocation
by one bit. For more information, see Managing RID Issuance.
NOTE
Though they are not operations master roles, another change in AD DS installation is that DNS server role and the global
catalog are installed by default on all domain controllers that run Windows Server 2012 .
Virtualizing domain controllers

Improvements in AD DS beginning in Windows Server 2012 enable safer virtualization of domain controllers and
the ability to clone domain controllers. Cloning domain controllers in turn enables rapid deployment of additional
domain controllers in a new domain and other benefits. For more information, see Introduction to Active Directory
Domain Services (AD DS ) Virtualization (Level 100).
Administration of Windows Server 2012 servers

Use the Remote Server Administration Tools for Windows 8 to manage domain controllers and other servers that
run Windows Server 2012 . You can run the Windows Server 2012 Remote Server Administration Tools on a
computer that runs Windows 8.
Application compatibility
The following table covers common Active Directory-integrated Microsoft applications. The table covers what
versions of Windows Server that the applications can be installed on and whether the introduction of Windows
Server 2012 DCs affects application compatibility.
PRODUCT NOTES
Microsoft Configuration Manager 2007 Configuration Manager 2007 with SP2 (includes Configuration
Manager 2007 R2 and Configuration Manager 2007 R3):
- Windows 8 Pro
- Windows 8 Enterprise
- Windows Server 2012 Standard
- Windows Server 2012 Datacenter Note: Though these will
be fully supported as clients, there is no plan to add support
for deploying these as operating systems by using the
Configuration Manager 2007 operating system deployment
feature. Also, no site servers or site systems will be supported
on any SKU of Windows Server 2012.
PRODUCT NOTES
Microsoft SharePoint 2007 Microsoft Office SharePoint Server 2007 is not supported for
installation on Windows Server 2012.
Microsoft SharePoint 2010 SharePoint 2010 Service Pack 2 is required to install and
operate
SharePoint 2010 on Windows Server 2012 Servers
SharePoint 2010 Foundation Service Pack 2 is required to

install and operate SharePoint 2010 Foundation on Windows
Server 2012 Servers
The SharePoint Server 2010 (without service packs) installation

process fails on Windows Server 2012
The SharePoint Server 2010 prerequisite installer

(PrerequisiteInstaller.exe) fails with error "This program has
compatibility issues." Clicking "Run the program without
getting help" displays the error "Verifying if SharePoint can be
installed | SharePoint Server 2010 (without service packs)
cannot be installed on Windows Server 2012."
Microsoft SharePoint 2013 Minimum requirements for a database server in a farm
The 64-bit edition of Windows Server 2008 R2 Service Pack 1

(SP1) Standard, Enterprise, or Datacenter or the 64-bit edition
of Windows Server 2012 Standard or Datacenter
Minimum requirements for a single server with built-in

database:

of Windows Server 2012 Standard or Datacenter
Minimum requirements for front-end web servers and

application servers in a farm:

of Windows Server 2012 Standard or Datacenter.
Microsoft System Center Configuration Manager 2012 System Center 2012 Configuration Manager Service Pack 1:
Microsoft will add the following operating systems to our

client support matrix with the release of Service Pack 1:
- Windows 8 Pro
- Windows Server 2012 Datacenter
All site server roles - including site servers, SMS providers, and
management points - can be deployed to servers with the
following operating system editions:

PRODUCT NOTES
Microsoft Lync Server 2013 Lync Server 2013 requires with Windows Server 2008 R2 or
Windows Server 2012. It cannot be run on a Server Core
installation. It can be run on virtual servers.
Lync Server 2010 Lync Server 2010 can be installed on a new (not upgraded)
installation Windows Server 2012 if October 2012 cumulative
updates for Lync Server are installed. Upgrading the operating
system to Windows Server 2012 for an existing installation of
Lync Server 2010 is not supported. Microsoft Lync Server
2010 Group Chat Server is also not supported on Windows
Server 2012.
System Center 2012 Endpoint Protection System Center 2012 Endpoint Protection Service Pack 1 will
update the client support matrix to include the following
operating systems
- Windows 8 Pro
System Center 2012 Forefront Endpoint Protection FEP 2010 with Update Rollup 1 will update the client support
matrix to include the following operating systems:
- Windows 8 Pro
Forefront Threat Management Gateway (TMG) TMG is supported to run only on Windows Server 2008 and
Windows Server 2008 R2. For more information, see System
requirements for Forefront TMG.
Windows Server Update Services This release of WSUS already supports Windows 8-based
computers or Windows Server 2012-based computers as
clients.
Windows Server Update Services 3.0 Update KB article 2734608 lets servers that are running
Windows Server Update Services (WSUS) 3.0 SP2 provide
updates to computers that are running Windows 8 or
Windows Server 2012: Note: Customers with standalone
WSUS 3.0 SP2 environments or System Center Configuration
Manager 2007 Service Pack 2 environments with WSUS 3.0
SP2 require 2734608 to properly manage Windows 8-based
computers or Windows Server 2012-based computers as
clients.
Exchange 2013 Windows Server 2012 Standard and Datacenter are supported
for the following roles: schema master, global catalog server,
domain controller, mailbox and client access server role
Forest Functional Level: Windows Server 2003 or higher
Source: Exchange 2013 System Requirements

PRODUCT NOTES
Exchange 2010 Source: Exchange 2010 Service Pack 3
Exchange 2010 with Service Pack 3 can be installed on

Windows Server 2012 member servers.
Exchange 2010 System Requirements lists the latest

supported schema master, global catalog and domain
controller as Windows Server 2008 R2.
Forest Functional Level: Windows Server 2003 or higher
SQL Server 2012 Source: KB 2681562
SQL Server 2012 RTM is supported on Windows Server 2012.
SQL Server 2008 R2 Source: KB 2681562
Requires SQL Server 2008 R2 with Service Pack 1 or later to

install on Windows Server 2012.
Requires SQL Server 2008 with Service Pack 3 or later to install

on Windows Server 2012.
Not supported to install on Windows Server 2012.
Known issues
The following table lists known issues related to AD DS installation.
KB article number and title Technology area impacted Issue/description
2830145: SID S-1-18-1 and SID S-1- AD DS Management/App compat Applications that map SID S-1-18-1 and
18-2 can't be mapped on Windows 7 or SID S-1-18-2, which are new in
Windows Server 2008 R2-based Windows Server 2012, may fail because
computers in a domain environment the SIDs cannot be resolved on
Windows 7-based or Windows Server
2008 R2-based computers. To resolve
this issue, install the hotfix on the
Windows 7-based and Windows Server
2008 R2-based computers in the
domain.
2737129: Group Policy preparation is AD DS Installation Adprep /domainprep /gpprep is not

not performed when you automatically automatically run as part of installing
prepare an existing domain for the first DC that runs Windows Server
Windows Server 2012 2012 in a domain. If it has never been
run previously in the domain, it must be
run manually.
2737416: Windows PowerShell-based AD DS Installation Warnings can appear during
domain controller deployment repeats prerequisite validation and then
warnings reappear during the installation.
2737424: "Format of the specified AD DS Installation This error appears if you are removing
domain name is invalid" error when you the last DC in a domain where pre-
try to remove Active Directory Domain created RODC accounts still exist. This
Services from a domain controller affects Windows Server 2012, Windows
Server 2008 R2, and Windows Server
2008.
2737463: Domain controller does not AD DS Installation A DC does not start because an
start, c00002e2 error occurs, or administrator used Dism.exe,
"Choose an option" is displayed Pkgmgr.exe, or Ocsetup.exe to remove
the DirectoryServices-DomainController
role.
2737516: IFM verification limitations in AD DS Installation IFM verification can have limitations as
Windows Server 2012 Server Manager explained in the KB article.
2737535: Install-AddsDomainController AD DS Installation You can receive an error when you try
cmdlet returns parameter set error for to attach a server to an RODC account
RODC if you specify arguments that are
already populated on the pre-created
RODC account.
2737560: "Unable to perform Exchange AD DS Installation Prerequisite check fails when you
schema conflict check" error, and configure the first Windows Server 2012
prerequisites check fails DC in an existing domain because DCs
are missing the SeServiceLogonRight for
Network Service or because WMI or
DCOM protocols are blocked.
2737797: AddsDeployment module AD DS Installation The -WhatIf parameter shows DNS

with the -Whatif argument shows server will not be installed but it will be.
incorrect DNS results
2737807: The Next button is not AD DS Installation The Next button is disabled on the
available on the Domain Controller Domain Controller Options page
Options page because the IP address of the target DC
does not map to an existing subnet or
site, or because the DSRM password is
not typed and confirmed correctly.
2737935: Active Directory installation AD DS Installation The installation hangs because the local
stalls at the "Creating the NTDS settings Administrator password matches the
object" stage domain Administrator password, or
because networking problems prevent
critical replication from completing.
2738060: "Access is denied" error AD DS Installation You receive the error when you run
message when you create a child Install-ADDSDomain with the Invoke-
domain remotely by using Install- Command cmdlet if the
AddsDomain DNSDelegationCredential has a bad
password.
2738697: "The server is not AD DS Installation You receive this error when you try to
operational" domain controller install AD DS on a workgroup computer
configuration error when you configure because NTLM authentication is
a server by using Server Manager disabled.
2738746: You receive access denied AD DS Installation When you log on using a local
errors after you log on to a local Administrator account rather than the
administrator domain account built-in Administrator account and then
create a new domain, the account is not
added to the Domain Admins group.
2743345: "The system cannot find the AD DS Installation You receive this error when you run
file specified" Adprep /gpprep error, or adprep /gpprep because the
tool crashes infrastructure master is implements a
disjoint namespace
2743367: Adprep "not a valid Win32 AD DS Installation You receive this error because Windows
application" error on Windows Server Server 2012 Adprep cannot be run on
2003, 64-bit version Windows Server 2003.
2753560: ADMT 3.2 and PES 3.1 ADMT ADMT 3.2 cannot be installed on
installation errors on Windows Server Windows Server 2012 by design.
2012
2750857: DFS Replication diagnostic DFS Replication DFS Replication diagnostic report does
reports do not display correctly in not display correctly because of changes
Internet Explorer 10 in Internet Explorer 10.
2741537: Remote Group Policy updates Group Policy This is due to scheduled tasks run in the
are visible to users context of each user who is logged on.
The Windows Task Scheduler design
requires an interactive prompt in this
scenario.
2741591: ADM files are not present in Group Policy GP replication can report "replication in
SYSVOL in the GPMC Infrastructure progress" because GPMC Infrastructure
Status option Status does not follow customized
filtering rules.
2737880: "The service cannot be Virtual DC cloning You receive this error while installing or
started" error during AD DS removing AD DS, or cloning, because
configuration the DS Role Server service is disabled.
2742836: Two DHCP leases are created Virtual DC cloning This happens because the cloned
for each domain controller when you domain controller received a lease
use the VDC cloning feature before cloning and again when cloning
was complete.
2742844: Domain controller cloning Virtual DC cloning The cloned DC starts in DSRM because
fails and the server restarts in DSRM in cloning failed for any of a variety of
Windows Server 2012 reasons listed in the KB article.
2742874: Domain controller cloning Virtual DC cloning Some three-part SPNs are not recreated
does not re-create all service principal on the cloned DC because of a
names limitation of the domain rename
process.
2742908: "No logon servers are Virtual DC cloning You receive this error when you try to
available" error after cloning domain log on after cloning a virtualized DC
controller because cloning failed and the DC is
started in DSRM. Log on as
.\administrator to troubleshoot the
cloning failure.
2742916: Domain controller cloning Virtual DC cloning Cloning fails because the PDC emulator
fails with error 8610 in dcpromo.log has not performed inbound replication
of the domain partition, likely because
the role was transferred.
2742927: "Index was out of range" Virtual DC cloning You receive the error after you run
New-AdDcCloneConfig error New-ADDCCloneConfigFile cmdlet while
cloning virtual DCs, either because the
cmdlet was not run from an elevated
command prompt or because your
access token does not contain the
Administrators group.
2742959: Domain controller cloning Virtual DC cloning Cloning failed because an invalid clone
fails with error 8437: "invalid parameter name or a duplicate NetBIOS name was
was specified for this replication specified.
operation"
2742970: DC Cloning fails with no Virtual DC cloning The cloned virtual DC boots in Directory
DSRM, duplicate source and clone Services Repair Mode (DSRM), using a
computer duplicate name as the source DC
because the DCCloneConfig.xml file was
not created in the correct location or
because the source DC was rebooted
before cloning.
2743278: Domain controller cloning Virtual DC cloning The cloned DC boots into DSRM
error 0x80041005 because only one WINS server was
specified. If any WINS server is specified,
both Preferred and Alternate WINS
servers must be specified.
2745013: "Server is not operational" Virtual DC cloning You receive this error after you run the
error message if you run New- New-ADDCCloneConfigFile cmdlet
AdDcCloneConfigFile in Windows Server because the server cannot contact a
2012 global catalog server.
2747974: Domain controller cloning Virtual DC cloning Event ID 2224 incorrectly states that
event 2224 provides incorrect guidance managed service accounts must be
removed before cloning. Standalone
MSAs must be removed but Group
MSAs do not block cloning.
2748266: You cannot unlock a BitLocker You receive an "Application not found"
BitLocker-encrypted drive after you error when you try to unlock a drive on
upgrade to Windows 8 a computer that was upgraded from
Windows 7.
See Also
Windows Server 2012 Evaluation Resources
Windows Server 2012 Evaluation Guide
Install and Deploy Windows Server 2012
AD DS Simplified Administration
This topic explains the capabilities and benefits of Windows Server 2012 domain controller deployment and
administration, and the differences between previous operating system DC deployment and the new Windows
Server 2012 implementation.
Windows Server 2012 introduced the next generation of Active Directory Domain Services Simplified
Administration, and was the most radical domain re-envisioning since Windows 2000 Server. AD DS Simplified
Administration takes lessons learned from twelve years of Active Directory and makes a more supportable, more
flexible, more intuitive administrative experience for architects and administrators. This meant creating new
versions of existing technologies as well as extending the capabilities of components released in Windows Server
2008 R2.
AD DS Simplified Administration is a reimagining of domain deployment.
AD DS role deployment is now part of the new Server Manager architecture and allows remote installation
The AD DS deployment and configuration engine is now Windows PowerShell, even when using the new AD
DS Configuration Wizard
Schema extension, forest preparation, and domain preparation are automatically part of domain controller
promotion and no longer require separate tasks on special servers such as the Schema Master
Promotion now includes prerequisite checking that validates forest and domain readiness for the new domain
controller, lowering the chance of failed promotions
Active Directory module for Windows PowerShell now includes cmdlets for replication topology management,
Dynamic Access Control, and other operations
The Windows Server 2012 forest functional level does not implement new features and domain functional level
is required only for a subset of new Kerberos features, relieving administrators of the frequent need for a
homogenous domain controller environment
Full support added for Virtualized Domain Controllers, to include automated deployment and rollback
protection
For more information about virtualized domain controllers, see Introduction to Active Directory Domain
Services (AD DS ) Virtualization (Level 100).
In addition, there are many administrative and maintenance improvements:
The Active Directory Administrative Center includes a graphical Active Directory Recycle Bin, Fine-Grained
Password Policy management, and Windows PowerShell history viewer
The new Server Manager has AD DS -specific interfaces into performance monitoring, best practice analysis,
critical services, and the event logs
Group Managed Service Accounts support multiple computers using the same security principals
Improvements in Relative Identifier (RID ) issuance and monitoring for better manageability in mature Active
Directory domains
AD DS profits from other new features included in Windows Server 2012, such as:
NIC teaming and Datacenter Bridging
DNS Security and faster AD -integrated zone availability after boot
Hyper-V reliability and scalability improvements
BitLocker Network Unlock
Additional Windows PowerShell component administration modules
ADPREP Integration
Active Directory forest schema extension and domain preparation now integrate into the domain controller
configuration process. If you promote a new domain controller into an existing forest, the process detects upgrade
status and the schema extension and domain preparation phases occur automatically. The user installing the first
Windows Server 2012 domain controller must still be an Enterprise Admin and Schema Admin or provide valid
alternate credentials.
Adprep.exe remains on the DVD for separate forest and domain preparation. The version of the tool included with
Windows Server 2012 is backwards compatible to Windows Server 2008 x64 and Windows Server 2008 R2.
Adprep.exe also supports remote forestprep and domainprep, just like the ADDSDeployment-based domain
controller configuration tools.
For information about Adprep and previous operating system forest preparation, see Running Adprep (Windows
Server 2008 R2).
Server Manager AD DS Integration
Server Manager acts as a hub for server management tasks. Its dashboard-style appearance periodically refreshes
views of installed roles and remote server groups. Server Manager provides centralized management of local and
remote servers, without the need for console access.
Active Directory Domain Services is one of those hub roles; by running Server Manager on a domain controller or
the Remote Server Administration Tools on a Windows 8, you see important recent issues on domain controllers in
your forest.
These views include:
Server availability
Performance monitor alerts for high CPU and memory usage
The status of Windows services specific to AD DS
Recent Directory Services-related warning and error entries in the event log
Best Practice analysis of a domain controller against a set of Microsoft-recommended rules
Active Directory Administrative Center Recycle Bin
Windows Server 2008 R2 introduced the Active Directory Recycle Bin, which recovers deleted Active Directory
objects without restoring from backup, restarting the AD DS service, or rebooting domain controllers.
Windows Server 2012 enhances the existing Windows PowerShell-based restore capabilities with a new graphical
interface in the Active Directory Administrative Center. This allows administrators to enable the Recycle Bin and
locate or restore deleted objects in the domain contexts of the forest, all without directly running Windows
PowerShell cmdlets. The Active Directory Administrative Center and Active Directory Recycle Bin still use Windows
PowerShell under the covers, so previous scripts and procedures are still valuable.
For information about the Active Directory Recycle Bin, see Active Directory Recycle Bin Step-by-Step Guide
(Windows Server 2008 R2).
Active Directory Administrative Center Fine-Grained Password Policy
Windows Server 2008 introduced the Fine-Grained Password policy, which allows administrators to configure
multiple password and account lockout policies per domain. This allows domains a flexible solution to enforce more
or less restrictive password rules, based on users and groups. It had no managerial interface and required
administrators to configure it using Ldp.exe or Adsiedit.msc. Windows Server 2008 R2 introduced the Active
Directory module for Windows PowerShell, which granted administrators a command-line interface to FGPP.
Windows Server 2012 brings a graphical interface to Fine-Grained Password Policy. The Active Directory
Administrative Center is the home of this new dialog, which brings simplified FGPP management to all
administrators.
For information about the Fine-Grained Password Policy, see AD DS Fine-Grained Password and Account Lockout
Policy Step-by-Step Guide (Windows Server 2008 R2).
Active Directory Administrative Center Windows PowerShell History

Viewer
Windows Server 2008 R2 introduced the Active Directory Administrative Center, which superseded the older
Active Directory Users and Computers snap-in created in Windows 2000. The Active Directory Administrative
Center creates a graphical administrative interface to the then-new Active Directory module for Windows
PowerShell.
While the Active Directory module contains over a hundred cmdlets, the learning curve for an administrator can be
steep. Since Windows PowerShell integrates heavily into the strategy of Windows administration, the Active
Directory Administrative Center now includes a viewer that enables you to see the cmdlet execution in the
graphical interface. You can search, copy, clear history, and add notes with a simple interface. The intent is for an
administrator to use the graphical interface to create and modify objects, and then review them in the history
viewer to learn more about Windows PowerShell scripting and modify the examples.
AD Replication Windows PowerShell

Windows Server 2012 adds additional Active Directory replication cmdlets to the Active Directory Windows
PowerShell module. These allow configuration of new or existing sites, subnets, connections, site links, and bridges.
They also return Active Directory replication metadata, replication status, queuing, and up-to-dateness version
vector information. The introduction of the replication cmdlets - combined with the deployment and other existing
AD DS cmdlets - makes it possible to administer a forest using Windows PowerShell alone. This creates new
opportunities for administrators wishing to provision and manage Windows Server 2012 without a graphical
interface, which then reduces the operating system's attack surface and servicing requirements. This is especially
important when deploying servers into high security networks such as Secret Internet Protocol Router (SIPR ) and
corporate DMZs.
For more information about AD DS site topology and replication, see the Windows Server Technical Reference.
RID Management and Issuance Improvements

Windows 2000 Active Directory introduced the RID Master, which issues pools of relative identifiers to domain
controllers, in order to create security identifiers (SIDs) of security trustees like users, groups, and computers. By
default, this global RID space is limited to 230 (or 1,073,741,823) total SIDs created in a domain. SIDs cannot return
to the pool or reissue. Over time, a large domain may begin to run low on RIDs, or accidents may lead to
unnecessary RID depletion and eventual exhaustion.
Windows Server 2012 addresses a number of RID issuance and management issues uncovered by customers and
Microsoft Customer Support as AD DS matured since the creation of the first Active Directory domains in 1999.
These include:
Periodic RID consumption warnings are written to the event log
Events log when an administrator invalidates a RID pool
A maximum cap on the RID policy RID Block Size is now enforced
Artificial RID ceilings are now enforced and logged when the global RID space is low, allowing an administrator
to take action before the global space is exhausted
The global RID space can now be increased by one bit, doubling the size to 231 (2,147,483,648 SIDs)
For more information about RIDs and the RID Master, review How Security Identifiers Work.
AD DS Role Deployment and Management Architecture

Server Manager and ADDSDeployment Windows PowerShell rely on the following core assemblies for
functionality when deploying or managing the AD DS role:
Microsoft.ADroles.Aspects.dll
Microsoft.ADroles.Instrumentation.dll
Microsoft.ADRoles.ServerManager.Common.dll
Microsoft.ADRoles.UI.Common.dll
Microsoft.DirectoryServices.Deployment.Types.dll
Microsoft.DirectoryServices.ServerManager.dll
Addsdeployment.psm1
Addsdeployment.psd1
Both rely on Windows PowerShell and its remote invoke-command for remote role installation and configuration.
Windows Server 2012 also refactors a number of previous promotion operations out of LSASS.EXE, as part of:
DS Role Server Service (DsRoleSvc)
DSRoleSvc.dll (loaded by DsRoleSvc service)
This service must be present and running in order to promote, demote, or clone virtual domain controllers. AD DS
role installation adds this service and sets a start type of Manual, by default. Do not disable this service.
ADPrep and Prerequisite Checking Architecture

Adprep no longer requires running on the schema master. It can be run remotely from a computer that runs
Windows Server 2008 x64 or later.
NOTE
Adprep uses LDAP to import Schxx.ldf files and does not automatically reconnect if the connection to the schema master is
lost during import. As part of the import process, the schema master is set in a specific mode and automatic reconnection is
disabled because if LDAP reconnects after the connection is lost, the re-established connection would not be in the specific
mode. In that case, the schema would not be updated correctly.
Prerequisite checking ensures that certain conditions are true. These conditions are required for successful AD DS
installation. If some required conditions are not true, they can be resolved before continuing the installation. It also
detects that a forest or domain are not yet prepared, so that the Adprep deployment code runs automatically.
ADPrep Executables, DLLs, LDFs, files
ADprep.dll
Ldifde.dll
Csvde.dll
Sch14.ldf - Sch56.ldf
Schupgrade.cat
*dcpromo.csv
The AD Preparation code formerly housed in ADprep.exe is refactored into adprep.dll. This allows both ADPrep.exe
and the ADDSDeployment Windows PowerShell module to use the library for the same tasks and have the same
capabilities. Adprep.exe is included with the installation media but automated processes do not call it directly - only
an Administrator runs it manually. It can only run on Windows Server 2008 x64 and later operating systems.
Ldifde.exe and csvde.exe also have refactored versions as DLLs that are loaded by the preparation process. Schema
extension still uses the signature-verified LDF files, like in previous operating system versions.
IMPORTANT
There is no 32-bit Adprep32.exe tool for Windows Server 2012. You must have at least one Windows Server 2008 x64,
Windows Server 2008 R2, or Windows Server 2012 computer, running as a domain controller, member server, or in a
workgroup, to prepare the forest and domain. Adprep.exe does not run on Windows Server 2003 x64.
Prerequisite Checking
The prerequisite checking system built into ADDSDeployment Windows PowerShell managed code works in
different modes, based on the operation. The tables below describe each test, when it is used, and an explanation of
how and what it validates. These tables may be useful if there are issues where the validation fails and the error is
not sufficient to troubleshoot the problem.
These tests log in the DirectoryServices-Deployment operational event log channel under the Task Category
Core, always as Event ID 103.
Prerequisite Windows PowerShell
There are ADDSDeployment Windows PowerShell cmdlets for all of the domain controller deployment cmdlets.
They have approximately the same arguments as their associated cmdlets.
Test-ADDSDomainControllerInstallation
Test-ADDSDomainControllerUninstallation
Test-ADDSDomainInstallation
Test-ADDSForestInstallation
Test-ADDSReadOnlyDomainControllerAccountCreation
There is no need to run these cmdlets, ordinarily; they already automatically execute with the deployment cmdlets
by default.
Prerequisite Tests
Test Name Protocols Explanation and notes
used
VerifyAdminTrusted LDAP Validates that you have the "Enable
computer and user accounts to be
ForDelegationProvider trusted for delegation"
(SeEnableDelegationPrivilege) privilege
on the existing partner domain
controller. This requires access to your
constructed tokenGroups attribute.
Not used when contacting Windows

Server 2003 domain controllers. You
must manually confirm this privilege
prior to promotion
VerifyADPrep LDAP Discovers and contacts the Schema

Master using the rootDSE
Prerequisites (forest) namingContexts attribute and Schema
naming context fsmoRoleOwner
attribute. Determines which preparatory
operations (forestprep, domainprep, or
rodcprep) are required for AD DS
installation. Validates the schema
objectVersion is expected and if it
requires further extension.
VerifyADPrep LDAP Discovers and contacts the

Infrastructure Master using the rootDSE
Prerequisites (domain and RODC) namingContexts attribute and the
Infrastructure container fsmoRoleOwner
attribute. In the case of an RODC
installation, this test discovers the
domain naming master and make sure
it is online.
CheckGroup LDAP, Validate the user is a member of

Domain Admins or Enterprise Admins
Membership RPC over SMB (LSARPC) group, depending on the operation (DA
for adding or demoting a domain
controller, EA for adding or removing a
domain)
CheckForestPrep LDAP, Validate the user is a member of

Schema Admins and Enterprise Admins
GroupMembership RPC over SMB (LSARPC) groups and has the Manage Audit and
Security Event Logs (SesScurityPrivilege)
privilege on the existing domain
controllers
CheckDomainPrep LDAP, Validate the user is a member of

Domain Admins group and has the
GroupMembership RPC over SMB (LSARPC) Manage Audit and Security Event Logs
(SesScurityPrivilege) privilege on the
existing domain controllers
CheckRODCPrep LDAP, Validate the user is a member of

Enterprise Admins group and has the
GroupMembership RPC over SMB (LSARPC) Manage Audit and Security Event Logs
(SesScurityPrivilege) privilege on the
existing domain controllers
VerifyInitSync LDAP Validate that the Schema Master has
replicated at least once since it restarted
AfterReboot by setting a dummy value on rootDSE
attribute becomeSchemaMaster
VerifySFUHotFix LDAP Validate the existing forest schema does

not contain known problem SFU2
Applied extension for the UID attribute with OID
1.2.840.113556.1.4.7000.187.102
(https://support.microsoft.com/kb/8217
32)
VerifyExchange LDAP, WMI, DCOM, RPC Validate the existing forest schema does
not still contain problem Exchange 2000
SchemaFixed extensions ms-Exch-Assistant-Name,
ms-Exch-LabeledURI, and ms-Exch-
House-Identifier
(https://support.microsoft.com/kb/3146
49)
VerifyWin2KSchema LDAP Validate the existing forest schema has

consistent (not incorrectly modified by a
Consistency third party) core attributes and classes.
DCPromo DRSR over RPC, Validate the command-line syntax

passed to the promotion code and test
LDAP, promotion. Validate the forest or
domain does not already exist if creating
DNS new.
RPC over SMB (SAMR)
VerifyOutbound LDAP, DRSR over SMB, RPC over SMB Validate the existing domain controller
(LSARPC) specified as the replication partner has
ReplicationEnabled outbound replication enabled by
checking the NTDS Settings object's
options attribute for
NTDSDSA_OPT_DISABLE_OUTBOUND_R
EPL (0x00000004)
VerifyMachineAdmin DRSR over RPC, Validate the safe mode password set for
DSRM meets domain complexity
Password LDAP, requirements.
DNS
RPC over SMB (SAMR)
VerifySafeModePassword N/A Validate the local Administrator

password set meets computer security
policy complexity requirements.
Simplified Administration Appendix
Server Manager Add Servers Dialog (Active Directory)

Server Manager Remote Server Status
Windows PowerShell Module Loading
RID Issuance Hotfixes for Previous Operating Systems
Ntdsutil.exe Install from Media Changes
Server Manager Add Servers Dialog (Active Directory)

The Add Servers dialog allows searching Active Directory for servers, by operating system, using wildcards, and
by location. The dialog also allows using DNS queries by fully qualified domain name or prefix name. These
searches use native DNS and LDAP protocols implemented through .NET, not AD Windows PowerShell against
the AD Management Gateway through SOAP - meaning that the domain controllers contacted by Server Manager
can even run Windows Server 2003. You can also import a file with server names for provisioning purposes.
The Active Directory search uses the following LDAP filters:
(&(ObjectCategory=computer)
(&(ObjectCategory=computer)(cn=dc*)(OperatingSystemVersion=6.2*))
(&(ObjectCategory=computer)(OperatingSystemVersion=6.1*))
(&(ObjectCategory=computer)(OperatingSystemVersion=6.0*))
(&(ObjectCategory=computer)(|(OperatingSystemVersion=5.2*)(OperatingSystemVersion=5.1*)))
The Active Directory search returns the following attributes:
( dnsHostName )( operatingSystem )( cn )
Server Manager Remote Server Status

Server Manager tests remote server accessibility using Address Routing Protocol. Any servers not responding to
ARP requests are not listed, even if they are in the pool.
If ARP responds, then DCOM and WMI connections are made to the server to return status information. If RPC,
DCOM, and WMI are unreachable, server manager cannot fully manage the server.
Windows PowerShell Module Loading

Windows PowerShell 3.0 implements dynamic module loading. Using the Import-Module cmdlet is typically no
longer required; instead, simply invoking the cmdlet, alias, or function automatically loads the module.
To see loaded modules, use the Get-Module cmdlet.
Get-Module
To see all installed modules with their exported functions and cmdlets, use:
Get-Module -ListAvailable
The main case for using the import-module command is when you need access to the "AD:" Windows PowerShell
virtual drive and nothing else has already loaded the module. For example, using the following commands:
cd ad:
dir
RID Issuance Hotfixes for Previous Operating Systems

See An update is available to detect and prevent too much consumption of the global RID pool on a domain
controller that is running Windows Server 2008 R2.
Ntdsutil.exe Install from Media Changes

Windows Server 2012 adds two additional options to the Ntdsutil.exe command-line tool for the IFM (IFM Media
Creation) menu. These allow you to create IFM stores without first performing an offline defrag of the exported
NTDS.DIT database file. When disk space is not a premium, this saves time creating the IFM.
The following table describes the two new menu items:
Menu Item Explanation
Create Full NoDefrag %s Create IFM media without defragmenting for a full AD DC or
an AD/LDS instance into folder %s
Create Sysvol Full NoDefrag %s Create IFM media with SYSVOL and without defragmenting
for a full AD DC into folder %s
This topic explains how to install AD DS in Windows Server 2012 by using any of the following methods:
Credential requirements to run Adprep.exe and install Active Directory Domain Services
Installing AD DS by Using Windows PowerShell
Installing AD DS by using Server Manager
Performing a Staged RODC Installation using the Graphical User Interface
Credential requirements to run Adprep.exe and install Active Directory

Domain Services
The following credentials are required to run Adprep.exe and install AD DS.
To install a new forest, you must be logged on as the local Administrator for the computer.
To install a new child domain or new domain tree, you must be logged on as a member of the Enterprise
Admins group.
To install an additional domain controller in an existing domain, you must be a member of the Domain
Admins group.
NOTE
If you do not run adprep.exe command separately and you are installing the first domain controller that runs
Windows Server 2012 in an existing domain or forest, you will be prompted to supply credentials to run Adprep
commands. The credential requirements are as follows:
To introduce the first Windows Server 2012 domain controller in the forest, you need to supply credentials for a
member of Enterprise Admins group, the Schema Admins group, and the Domain Admins group in the domain
that hosts the schema master.
To introduce the first Windows Server 2012 domain controller in a domain, you need to supply credentials for a
member of the Domain Admins group.
To introduce the first read-only domain controller (RODC) in the forest, you need to supply credentials for a
member of the Enterprise Admins group.
NOTE
If you have already run adprep /rodcprep in Windows Server 2008 or Windows Server 2008 R2, you do not
need to run it again for Windows Server 2012 .
Installing AD DS by Using Windows PowerShell

Beginning with Windows Server 2012 , you can install AD DS using Windows PowerShell. Dcpromo.exe is
deprecated beginning with Windows Server 2012 , but you can still run dcpromo.exe by using an answer file
(dcpromo /unattend: or dcpromo /answer:). The ability to continue running dcpromo.exe with an answer file
provides organizations that have resources invested in existing automation time to convert the automation from
dcpromo.exe to Windows PowerShell. For more information about running dcpromo.exe with an answer file, see
https://support.microsoft.com/kb/947034.
For more information about removing AD DS using Windows PowerShell, see Remove AD DS using Windows
PowerShell.
Start with adding the role using Windows PowerShell. This command installs the AD DS server role and installs the
AD DS and AD LDS server administration tools, including GUI-based tools such as Active Directory Users and
Computers and command-line tools such as dcdia.exe. Server administration tools are not installed by default when
you use Windows PowerShell. You need to specify "IncludeManagementTools to manage the local server or
install Remote Server Administration Tools to manage a remote server.
Install-windowsfeature -name AD-Domain-Services -IncludeManagementTools

<<Windows PowerShell cmdlet and arguments>>
There is no reboot required until after the AD DS installation is complete.

You can then run this command to see the available cmdlets in the ADDSDeployment module.
Get-Command -Module ADDSDeployment
To see the list of arguments that can be specified for a cmdlets and syntax:
Get-Help <cmdlet name>
For example, to see the arguments for creating an unoccupied read-only domain controller (RODC ) account, type
Get-Help Add-ADDSReadOnlyDomainControllerAccount
Optional arguments appear in square brackets.

You can also download the latest Help examples and concepts for Windows PowerShell cmdlets. For more
information, see about_Updatable_Help.
You can run Windows PowerShell cmdlets against remote servers:
In Windows PowerShell, use Invoke-Command with the ADDSDeployment cmdlet. For example, to install
AD DS on a remote server named ConDC3 in the contoso.com domain, type:
Invoke-Command { Install-ADDSDomainController -DomainName contoso.com -Credential (Get-Credential) } -

ComputerName ConDC3
-or-
In Server Manager, create a server group that includes the remote server. Right-click the name of the remote
server and click Windows PowerShell.
The next sections explain how to run ADDSDeployment module cmdlets to install AD DS.
ADDSDeployment cmdlet arguments
Specifying Windows PowerShell Credentials
Using test cmdlets
Installing a new forest root domain using Windows PowerShell
Installing a new child or tree domain using Windows PowerShell
Installing an additional (replica) domain controller using Windows PowerShell
ADDSDeployment cmdlet arguments
The following table lists arguments for the ADDSDeployment cmdlets in Windows PowerShell. Arguments in bold
are required. Equivalent arguments for dcpromo.exe are listed in parentheses if they are named different in
Windows PowerShell.
Windows PowerShell switches accept $TRUE or $FALSE arguments. Arguments that are $TRUE by default do not
need to be specified.
To override default values, you can specify the argument with a $False value. For example, because -installdns is
automatically run for a new forest installation if it is not specified, the only way to prevent DNS installation when
you install a new forest is to use:
-InstallDNS:$false
Similarly, because "installdns has a default value of $False if you install a domain controller in an environment
that does not host Windows Server DNS server, you need to specify the following argument in order to install DNS
server:
-InstallDNS:$true
ARGUMENT DESCRIPTION
ADPrepCredential Note: Required if you are installing the Specifies the account with Enterprise Admins and Schema
first Windows Server 2012 domain controller in a domain or Admins group membership that can prepare the forest,
forest and the credentials of the current user are insufficient to according to the rules of Get-Credential and a PSCredential
perform the operation. object.
If no value is specified, the value of the "credential argument

is used.
AllowDomainControllerReinstall Specifies whether to continue installing this writable domain

controller, despite the fact that another writable domain
controller account with the same name is detected.
Use $True only if you are sure that the account is not
currently used by another writable domain controller.
The default is $False.
This argument is not valid for an RODC.
AllowDomainReinstall Specifies whether an existing domain is recreated.
The default is $False.

AllowPasswordReplicationAccountName <string []> Specifies the names of user accounts, group accounts, and
computer accounts whose passwords can be replicated to this
RODC. Use an empty string "" if you want to keep the value
empty. By default, only the Allowed RODC Password
Replication Group is allowed, and it is originally created empty.
Supply values as a string array. For example:
Code -AllowPasswordReplicationAccountName
"JSmith","JSmithPC","Branch Users"
ApplicationPartitionsToReplicate <string []> Note: There is no Specifies the application directory partitions to replicate. This
equivalent option in the UI. If you install using the UI, or using argument is applied only when you specify the -
IFM, then all application partitions will be replicated. InstallationMediaPath argument to install from media (IFM).
By default, all application partitions will replicate based on their
own scopes.
Code -
-ApplicationPartitionsToReplicate
"partition1","partition2","partition3"
Confirm Prompts you for confirmation before running the cmdlet.
CreateDnsDelegation Note: You cannot specify this argument Indicates whether to create a DNS delegation that references
when you run the Add-ADDSReadOnlyDomainController the new DNS server that you are installing along with the
cmdlet. domain controller. Valid for Active Directory"integrated DNS
only. Delegation records can be created only on Microsoft DNS
servers that are online and accessible. Delegation records
cannot be created for domains that are immediately
subordinate to top-level domains such as .com, .gov, .biz, .edu
or two-letter country code domains such as .nz and .au.
The default is computed automatically based on the

environment.
Credential Note: Required only if the credentials of the Specifies the domain account that can logon to the domain,
current user are insufficient to perform the operation. according to the rules of Get-Credential and a PSCredential
object.
If no value is specified, the credentials of the current user are

used.
CriticalReplicationOnly Specifies whether the AD DS installation operation performs

only critical replication before reboot and then continues. The
noncritical replication happens after the installation finishes
and the computer reboots.
Using this argument is not recommended.
There is no equivalent for this option in the user interface (UI).

DatabasePath Specifies the fully qualified, non"Universal Naming Convention

(UNC) path to a directory on a fixed disk of the local computer
that contains the domain database, for example,
C:\Windows\NTDS.
The default is %SYSTEMROOT%\NTDS. Important: While

you can store the AD DS database and log files on volume
formatted with Resilient File System (ReFS), there are no
specific benefits for hosting AD DS on ReFS, other than the
normal benefits of resiliency you get for hosting any data on
ReFS.
DelegatedAdministratorAccountName Specifies the name of the user or group that can install and
administer the RODC.
By default, only members of the Domain Admins group can

administer an RODC.
DenyPasswordReplicationAccountName <string []> Specifies the names of user accounts, group accounts, and
computer accounts whose passwords are not to be replicated
to this RODC. Use an empty string "" if you do not want to
deny the replication of credentials of any users or computers.
By default, Administrators, Server Operators, Backup
Operators, Account Operators, and the Denied RODC
Password Replication Group are denied. By default, the Denied
RODC Password Replication Group includes Cert Publishers,
Domain Admins, Enterprise Admins, Enterprise Domain
Controllers, Enterprise Read-Only Domain Controllers, Group
Policy Creator Owners, the krbtgt account, and Schema
Admins.
Code -
-DenyPasswordReplicationAccountName
"RegionalAdmins","AdminPCs"
DnsDelegationCredential Note: You cannot specify this Specifies the user name and password for creating DNS
argument when you run the Add- delegation, according to the rules of Get-Credential and a
ADDSReadOnlyDomainController cmdlet. PSCredential object.
DomainMode {Win2003 | Win2008 | Win2008R2 | Win2012 | Specifies the domain functional level during the creation of a
Win2012R2} new domain.
Or The domain functional level cannot be lower than the forest

functional level, but it can be higher.
DomainMode {2 | 3 | 4 | 5 | 6}
The default value is automatically computed and set to the
existing forest functional level or the value that is set for -
ForestMode.
DomainName Specifies the FQDN of the domain in which you want to install
an additional domain controller.
Required for Install-ADDSForest and Install-
ADDSDomainController cmdlets.
DomainNetbiosName Use with Install-ADDSForest. Assigns a NetBIOS name to the

new forest root domain.
Required for Install-ADDSForest if FQDN prefix name is longer
than 15 characters.
DomainType {ChildDomain | TreeDomain} or {child | tree} Indicates the type of domain that you want to create: a new
domain tree in an existing forest, a child of an existing domain,
or a new forest.
The default for DomainType is ChildDomain.
Force When this parameter is specified any warnings that might

normally appear during the installation and addition of the
domain controller will be suppressed to allow the cmdlet to
complete its execution. This parameter can be useful to include
when scripting installation.
ForestMode {Win2003 | Win2008 | Win2008R2 | Win2012 | Specifies the forest functional level when you create a new
Win2012R2} forest.
Or The default value is Win2012.
ForestMode {2 | 3 | 4 | 5 | 6}
InstallationMediaPath Indicates the location of the installation media that will be

used to install a new domain controller.
InstallDns Specifies whether the DNS Server service should be installed

and configured on the domain controller.
For a new forest, the default is $True and DNS Server is

installed.
For a new child domain or domain tree, if the parent domain

(or forest root domain for a domain tree) already hosts and
stores the DNS names for the domain, then the default for this
parameter is $True.
For a domain controller installation in an existing domain, if

this parameter is left unspecified and the current domain
already hosts and stores the DNS names for the domain, then
the default for this parameter is $True. Otherwise, if DNS
domain names are hosted outside of Active Directory, the
default is $False and no DNS Server is installed.
LogPath Specifies the fully qualified, non-UNC path to a directory on a

fixed disk of the local computer that contains the domain log
files, for example, C:\Windows\Logs.
The default is %SYSTEMROOT%\NTDS. Important: Do not

store the Active Directory log files on a data volume formatted
with Resilient File System (ReFS).
MoveInfrastructureOperationMasterRoleIfNecessary Specifies whether to transfer the infrastructure master

operations master role (also known as flexible single master
operations or FSMO) to the domain controller that you are
creating"in case it is currently hosted on a global catalog
server"and you do not plan to make the domain controller
that you are creating a global catalog server. Specify this
parameter to transfer the infrastructure master role to the
domain controller that you are creating in case the transfer is
needed; in this case, specify the NoGlobalCatalog option if
you want the infrastructure master role to remain where it
currently is.
NewDomainName Note: Required only for Install- Specifies the single domain name for the new domain.
ADDSDomain.
For example, if you want to create a new child domain named
emea.corp.fabrikam.com, you should specify emea as the
value of this argument.
NewDomainNetbiosName Use with Install-ADDSDomain. Assigns a NetBIOS name to the

new domain. The default value is derived from the value of
Required for Install-ADDSDomain if FQDN prefix name is "NewDomainName.
longer than 15 characters.
NoDnsOnNetwork Specifies that DNS service is not available on the network. This
parameter is used only when the IP setting of the network
adapter for this computer is not configured with the name of a
DNS server for name resolution. It indicates that a DNS server
will be installed on this computer for name resolution.
Otherwise, the IP settings of the network adapter must first be
configured with the address of a DNS server.
Omitting this parameter (the default) indicates that the TCP/IP

client settings of the network adapter on this server computer
will be used to contact a DNS server. Therefore, if you are not
specifying this parameter, ensure that TCP/IP client settings
are first configured with a preferred DNS server address.
NoGlobalCatalog Specifies that you do not want the domain controller to be a

global catalog server.
Domain controllers that run Windows Server 2012 are

installed with the global catalog by default. In other words, this
runs automatically without computation, unless you specify:
Code -
-NoGlobalCatalog
NoRebootOnCompletion Specifies whether to restart the computer upon completion of

the command, regardless of success. By default, the computer
will restart. To prevent the server from restarting, specify:
Code -
-NoRebootOnCompletion:$True
There is no equivalent for this option in the user interface (UI).

ParentDomainName Note: Required for Install- Specifies the FQDN of an existing parent domain. You use this
ADDSDomain cmdlet argument when you install a child domain or new domain tree.
For example, if you want to create a new child domain named

emea.corp.fabrikam.com, you should specify
corp.fabrikam.com as the value of this argument.
ReadOnlyReplica Specifies whether to install a read-only domain controller

(RODC).
ReplicationSourceDC Indicates the FQDN of the partner domain controller from

which you replicate the domain information. The default is
automatically computed.
SafeModeAdministratorPassword Supplies the password for the administrator account when the
computer is started in Safe Mode or a variant of Safe Mode,
such as Directory Services Restore Mode.
The default is an empty password. You must supply a

password. The password must be supplied in a
System.Security.SecureString format, such as that provided by
read-host -assecurestring or ConvertTo-SecureString.
The SafeModeAdministratorPassword argument's operation is

special:If not specified as an argument, the cmdlet prompts
you to enter and confirm a masked password. This is the
preferred usage when running the cmdlet interactively.If
specified without a value, and there are no other arguments
specified to the cmdlet, the cmdlet prompts you to enter a
masked password without confirmation. This is not the
preferred usage when running the cmdlet interactively.If
specified with a value, the value must be a secure string. This is
not the preferred usage when running the cmdlet
interactively.For example, you can manually prompt for a
password by using the Read-Host cmdlet to prompt the user
for a secure string:-safemodeadministratorpassword (read-
host -prompt "Password:" -assecurestring)You can also
provide a secure string as a converted clear-text variable,
although this is highly discouraged. -
safemodeadministratorpassword (convertto-securestring
"Password1" -asplaintext -force)
SiteName Specifies the site where the domain controller will be installed.
There is no "sitename argument when you run Install-
Required for the Add-addsreadonlydomaincontrolleraccount ADDSForest because the first site created is Default-First-Site-
cmdlet Name.
The site name must already exist when provided as an

argument to -sitename. The cmdlet will not create the site.
SkipAutoConfigureDNS Skips automatic configuration of DNS client settings,

forwarders, and root hints. This argument is in effect only if
the DNS Server service is already installed or automatically
installed with -InstallDNS.
SystemKey Specifies the system key for the media from which you
replicate the data.
The default is none.
Data must be in format provided by read-host -assecurestring

or ConvertTo-SecureString.
SysvolPath Specifies the fully qualified, non-UNC path to a directory on a

fixed disk of the local computer, for example,
C:\Windows\SYSVOL.
The default is %SYSTEMROOT%\SYSVOL. Important:

SYSVOL cannot be stored on a data volume formatted with
Resilient File System (ReFS).
SkipPreChecks Does not run the prerequisite checks before starting

installation. It is not advisable to use this setting.
WhatIf Shows what would happen if the cmdlet runs. The cmdlet is
not run.
Specifying Windows PowerShell Credentials

You can specify credentials without revealing them in plain text on screen by using Get-credential.
The operation for the -SafeModeAdministratorPassword and LocalAdministratorPassword arguments is special:
If not specified as an argument, the cmdlet prompts you to enter and confirm a masked password. This is the
preferred usage when running the cmdlet interactively.
If specified with a value, the value must be a secure string. This is not the preferred usage when running the
cmdlet interactively.
For example, you can manually prompt for a password by using the Read-Host cmdlet to prompt the user for a
secure string
-SafeModeAdministratorPassword (Read-Host -Prompt "DSRM Password:" -AsSecureString)
WARNING
As the previous option does not confirm the password, use extreme caution: the password is not visible.
You can also provide a secure string as a converted clear-text variable, although this is highly discouraged:
-SafeModeAdministratorPassword (ConvertTo-SecureString "Password1" -AsPlainText -Force)
WARNING
Providing or storing a clear text password is not recommended. Anyone running this command in a script or looking over
your shoulder knows the DSRM password of that domain controller. With that knowledge, they can impersonate the domain
controller itself and elevate their privilege to the highest level in an Active Directory forest.
Using test cmdlets
Each ADDSDeployment cmdlet has a corresponding test cmdlet. The test cmdlets runs only the prerequisite checks
for the installation operation; no installation settings are configured. The arguments for each test cmdlet are the
same as for the corresponding installation cmdlet, but "SkipPreChecks is not available for test cmdlets.
TEST CMDLET DESCRIPTION
Test-ADDSForestInstallation Runs the prerequisites for installing a new Active Directory

forest.
Test-ADDSDomainInstallation Runs the prerequisites for installing a new domain in Active

Directory.
Test-ADDSDomainControllerInstallation Runs the prerequisites for installing a domain controller in

Active Directory.
Test-ADDSReadOnlyDomainControllerAccountCreation Runs the prerequisites for adding a read-only domain

controller (RODC) account.
Installing a new forest root domain using Windows PowerShell

The command syntax for installing a new forest is as follows. Optional arguments appear within square brackets.
Install-ADDSForest [-SkipPreChecks] -DomainName <string> -SafeModeAdministratorPassword <SecureString> [-

CreateDNSDelegation] [-DatabasePath <string>] [-DNSDelegationCredential <PS Credential>] [-NoDNSOnNetwork] [-
DomainMode <DomainMode> {Win2003 | Win2008 | Win2008R2 | Win2012}] [-DomainNetBIOSName <string>] [-ForestMode
<ForestMode> {Win2003 | Win2008 | Win2008R2 | Win2012}] [-InstallDNS] [-LogPath <string>] [-
NoRebootOnCompletion] [-SkipAutoConfigureDNS] [-SYSVOLPath] [-Force] [-WhatIf] [-Confirm] [<CommonParameters>]
NOTE
The -DomainNetBIOSName argument is required if you want to change the 15-character name that is automatically
generated based on the DNS domain name prefix or if the name exceeds 15 characters.
For example, to install a new forest named corp.contoso.com and be securely prompted to provide the DSRM
password, type:
Install-ADDSForest -DomainName "corp.contoso.com"
NOTE
DNS server is installed by default when you run Install-ADDSForest.
To install a new forest named corp.contoso.com, create a DNS delegation in the contoso.com domain, set domain
functional level to Windows Server 2008 R2 and set forest functional level to Windows Server 2008, install the
Active Directory database and SYSVOL on the D:\ drive, install the log files on the E:\ drive, and be prompted to
provide the Directory Services Restore Mode password and type:
Install-ADDSForest -DomainName corp.contoso.com -CreateDNSDelegation -DomainMode Win2008 -ForestMode Win2008R2

-DatabasePath "d:\NTDS" -SYSVOLPath "d:\SYSVOL" -LogPath "e:\Logs"
Installing a new child or tree domain using Windows PowerShell

The command syntax for installing a new domain is as follows. Optional arguments appear within square brackets.
Install-ADDSDomain [-SkipPreChecks] -NewDomainName <string> -ParentDomainName <string> -

SafeModeAdministratorPassword <SecureString> [-ADPrepCredential <PS Credential>] [-AllowDomainReinstall] [-
CreateDNSDelegation] [-Credential <PS Credential>] [-DatabasePath <string>] [-DNSDelegationCredential <PS
Credential>] [-NoDNSOnNetwork] [-DomainMode <DomainMode> {Win2003 | Win2008 | Win2008R2 | Win2012}] [DomainType
<DomainType> {Child Domain | TreeDomain} [-InstallDNS] [-LogPath <string>] [-NoGlobalCatalog] [-
NewDomainNetBIOSName <string>] [-NoRebootOnCompletion] [-ReplicationSourceDC <string>] [-SiteName <string>] [-
SkipAutoConfigureDNS] [-Systemkey <SecureString>] [-SYSVOLPath] [-Force] [-WhatIf] [-Confirm]
[<CommonParameters>]
NOTE
The -credential argument is only required when you are not currently logged on as a member of the Enterprise Admins
group.
The -NewDomainNetBIOSName argument is required if you want to change the automatically generated 15-character
name based on the DNS domain name prefix or if the name exceeds 15 characters.
For example, to use credentials of corp\EnterpriseAdmin1 to create a new child domain named
child.corp.contoso.com, install DNS server, create a DNS delegation in the corp.contoso.com domain, set domain
functional level to Windows Server 2003, make the domain controller a global catalog server in a site named
Houston, use DC1.corp.contoso.com as the replication source domain controller, install the Active Directory
database and SYSVOL on the D:\ drive, install the log files on the E:\ drive, and be prompted to provide the
Directory Services Restore Mode password but not prompted to confirm the command, type:
Install-ADDSDomain -SafeModeAdministratorPassword -Credential (get-credential corp\EnterpriseAdmin1) -

NewDomainName child -ParentDomainName corp.contoso.com -InstallDNS -CreateDNSDelegation -DomainMode Win2003 -
ReplicationSourceDC DC1.corp.contoso.com -SiteName Houston -DatabasePath "d:\NTDS" "SYSVOLPath "d:\SYSVOL" -
LogPath "e:\Logs" -Confirm:$False
Installing an additional (replica) domain controller using Windows PowerShell

The command syntax for installing an additional domain controller is as follows. Optional arguments appear within
square brackets.
Install-ADDSDomainController -DomainName <string> [-SkipPreChecks] -SafeModeAdministratorPassword

<SecureString> [-ADPrepCredential <PS Credential>] [-AllowDomainControllerReinstall] [-
ApplicationPartitionsToReplicate <string[]>] [-CreateDNSDelegation] [-Credential <PS Credential>] [-
CriticalReplicationOnly] [-DatabasePath <string>] [-DNSDelegationCredential <PS Credential>] [-NoDNSOnNetwork]
[-NoGlobalCatalog] [-InstallationMediaPath <string>] [-InstallDNS] [-LogPath <string>] [-
MoveInfrastructureOperationMasterRoleIfNecessary] [-NoRebootOnCompletion] [-ReplicationSourceDC <string>] [-
SiteName <string>] [-SkipAutoConfigureDNS] [-SystemKey <SecureString>] [-SYSVOLPath <string>] [-Force] [-
WhatIf] [-Confirm] [<CommonParameters>]
To install a domain controller and DNS server in the corp.contoso.com domain and be prompted to supply the
domain Administrator credentials and the DSRM password, type:
Install-ADDSDomainController -Credential (Get-Credential CORP\Administrator) -DomainName "corp.contoso.com"
If the computer is already domain joined and you are a member of the Domain Admins group, you can use:
Install-ADDSDomainController -DomainName "corp.contoso.com"
To be prompted for the domain name, type:

Install-ADDSDomainController -Credential (Get-Credential) -DomainName (Read-Host "Domain to promote into")
The following command will use credentials of Contoso\EnterpriseAdmin1 to install a writable domain controller
and a global catalog server in a site named Boston, install DNS server, create a DNS delegation in the contoso.com
domain, install from media that is stored in the c:\ADDS IFM folder, install the Active Directory database and
SYSVOL on the D:\ drive, install the log files on the E:\ drive, have the server automatically restart after AD DS
installation is complete, and be prompted to provide the Directory Services Restore Mode password:
Install-ADDSDomainController -Credential (Get-Credential CONTOSO\EnterpriseAdmin1) -CreateDNSDelegation -

DomainName corp.contoso.com -SiteName Boston -InstallationMediaPath "c:\ADDS IFM" -DatabasePath "d:\NTDS" -
SYSVOLPath "d:\SYSVOL" -LogPath "e:\Logs"
Performing a staged RODC installation using Windows PowerShell

The command syntax to create an RODC account is as follows. Optional arguments appear within square brackets.
Add-ADDSReadOnlyDomainControllerAccount [-SkipPreChecks] -DomainControllerAccuntName <string> -DomainName

<string> -SiteName <string> [-AllowPasswordReplicationAccountName <string []>] [-NoGlobalCatalog] [-Credential
<PS Credential>] [-DelegatedAdministratorAccountName <string>] [-DenyPasswordReplicationAccountName <string
[]>] [-InstallDNS] [-ReplicationSourceDC <string>] [-Force] [-WhatIf] [-Confirm] [<Common Parameters>]
The command syntax to attach a server to an RODC account is as follows. Optional arguments appear within
square brackets.
Install-ADDSDomainController -DomainName <string> [-SkipPreChecks] -SafeModeAdministratorPassword

<SecureString> [-ADPrepCredential <PS Credential>] [-ApplicationPartitionsToReplicate <string[]>] [-Credential
<PS Credential>] [-CriticalReplicationOnly] [-DatabasePath <string>] [-NoDNSOnNetwork] [-InstallationMediaPath
<string>] [-InstallDNS] [-LogPath <string>] [-MoveInfrastructureOperationMasterRoleIfNecessary] [-
NoRebootOnCompletion] [-ReplicationSourceDC <string>] [-SkipAutoConfigureDNS] [-SystemKey <SecureString>] [-
SYSVOLPath <string>] [-UseExistingAccount] [-Force] [-WhatIf] [-Confirm] [<CommonParameters>]
For example, to create an RODC account named RODC1:
Add-ADDSReadOnlyDomainControllerAccount -DomainControllerAccountName RODC1 -DomainName corp.contoso.com -

SiteName Boston DelegatedAdministratoraccountName PilarA
Then run the following commands on the server that you want to attach to the RODC1 account. The server cannot
be joined to the domain. First, install the AD DS server role and management tools:
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
The run the following command to create the RODC:
Install-ADDSDomainController -DomainName corp.contoso.com -SafeModeAdministratorPassword (Read-Host -Prompt

"DSRM Password:" -AsSecureString) -Credential (Get-Credential Corp\PilarA) -UseExistingAccount
Press Y to confirm or include the "confirm argument to prevent the confirmation prompt.
Installing AD DS by using Server Manager

AD DS can be installed in Windows Server 2012 by using the Add Roles Wizard in Server Manager, followed by
the Active Directory Domain Services Configuration Wizard, which is new beginning in Windows Server 2012 . The
Active Directory Domain Services Installation Wizard (dcpromo.exe) is deprecated beginning in Windows Server
2012 .
The following sections explain how to create server pools in order to install and manage AD DS on multiple
servers, and how to use the wizards to install AD DS.
Creating server pools
Server Manager can pool other servers on the network as long as they are accessible from the computer running
Server Manager. Once pooled, you choose those servers for remote installation of AD DS or any other
configuration options possible within Server Manager. The computer running Server Manager automatically pools
itself. For more information about server pools, see Add Servers to Server Manager.
NOTE
In order to manage a domain-joined computer using Server Manager on a workgroup server, or vice-versa, additional
configuration steps are needed. For more information, see "Add and manage servers in workgroups" in Add Servers to Server
Manager.
Installing AD DS
Administrative credentials
The credential requirements to install AD DS vary depending on which deployment configuration you choose. For
more information, see Credential requirements to run Adprep.exe and install Active Directory Domain Services.
Use the following procedures to install AD DS using the GUI method. The steps can be performed locally or
remotely. For more detailed explanation of these steps, see the following topics:
Deploying a Forest with Server Manager
Install a Windows Server 2012 Active Directory Read-Only Domain Controller (RODC ) (Level 200)
To i n st a l l A D D S b y u si n g Se r v e r M a n a g e r
1. In Server Manager, click Manage and click Add Roles and Features to start the Add Roles Wizard.
3. On the Select installation type page, click Role-based or feature-based installation and then click
Next.
4. On the Select destination server page, click Select a server from the server pool, click the name of the
server where you want to install AD DS and then click Next.
To select remote servers, first create a server pool and add the remote servers to it. For more information
about creating server pools, see Add Servers to Server Manager.
5. On the Select server roles page, click Active Directory Domain Services, then on the Add Roles and
6. On the Select features page, select any additional features you want to install and click Next.
7. On the Active Directory Domain Services page, review the information and then click Next.
9. On the Results page, verify that the installation succeeded, and click Promote this server to a domain
controller to start the Active Directory Domain Services Configuration Wizard.
IMPORTANT
If you close Add Roles Wizard at this point without starting the Active Directory Domain Services Configuration
Wizard, you can restart it by clicking Tasks in Server Manager.
10. On the Deployment Configuration page, choose one of the following options:
If you are installing an additional domain controller in an existing domain, click Add a domain
controller to an existing domain, and type the name of the domain (for example,
emea.corp.contoso.com) or click Select... to choose a domain, and credentials (for example, specify an
account that is a member of the Domain Admins group) and then click Next.
NOTE
The name of the domain and current user credentials are supplied by default only if the machine is domain-
joined and you are performing a local installation. If you are installing AD DS on a remote server, you need to
specify the credentials, by design. If current user credentials are not sufficient to perform the installation, click
Change... in order to specify different credentials.
For more information, see Install a Replica Windows Server 2012 Domain Controller in an Existing
Domain (Level 200).
If you are installing a new child domain, click Add a new domain to an existing forest, for Select
domain type, select Child Domain, type or browse to the name of the parent domain DNS name
(for example, corp.contoso.com), type the relative name of the new child domain (for example emea),
type credentials to use to create the new domain, and then click Next.
For more information, see Install a New Windows Server 2012 Active Directory Child or Tree Domain
(Level 200).
If you are installing a new domain tree, click Add new domain to an existing forest, for Select
domain type, choose Tree Domain, type the name of the root domain (for example,
corp.contoso.com), type the DNS name of the new domain (for example, fabrikam.com), type
credentials to use to create the new domain, and then click Next.
For more information, see Install a New Windows Server 2012 Active Directory Child or Tree Domain
(Level 200).
If you are installing a new forest, click Add a new forest and then type the name of the root domain
(for example, corp.contoso.com).
For more information, see Install a New Windows Server 2012 Active Directory Forest (Level 200).
11. On the Domain Controller Options page, choose one of the following options:
If you are creating a new forest or domain, select the domain and forest functional levels, click
Domain Name System (DNS ) server, specify the DSRM password, and then click Next.
If you are adding a domain controller to an existing domain, click Domain Name System (DNS )
server, Global Catalog (GC ), or Read Only Domain Controller (RODC ) as needed, choose the
site name, and type the DSRM password and then click Next.
For more information about which options on this page are available or not available under different
conditions, see Domain Controller Options.
12. On the DNS Options page (which appears only if you install a DNS server), click Update DNS delegation
as needed. If you do, provide credentials that have permission to create DNS delegation records in the
parent DNS zone.
If a DNS server that hosts the parent zone cannot be contacted, the Update DNS Delegation option is not
available.
For more information about whether you need to update the DNS delegation, see Understanding Zone
Delegation. If you attempt to update the DNS delegation and encounter an error, see DNS Options.
13. On the RODC Options page (which appears only if you install an RODC ), specify the name of a group or
user who will manage the RODC, add accounts to or remove accounts from the Allowed or Denied
password replication groups, and then click Next.
For more information, see Password Replication Policy.
14. On the Additional Options page, choose one of the following options:
If you are creating a new domain, type a new NetBIOS name or verify the default NetBIOS name of
the domain, and then click Next.
If you are adding a domain controller to an existing domain, select the domain controller that you
want to replicate the AD DS installation data from (or allow the wizard to select any domain
controller). If you are installing from media, click Install from media path type and verify the path to
the installation source files, and then click Next.
You cannot use install from media (IFM ) to install the first domain controller in a domain. IFM does
not work across different operating system versions. In other words, in order to install an additional
domain controller that runs Windows Server 2012 by using IFM, you must create the backup media
on a Windows Server 2012 domain controller. For more information about IFM, see Installing an
Additional Domain Controller by Using IFM.
accept default locations), and click Next.
IMPORTANT
Do not store the Active Directory database, log files, or SYSVOL folder on a data volume formatted with Resilient File
System (ReFS).
16. On the Preparation Options page, type credentials that are sufficient to run adprep. For more information,
see Credential requirements to run Adprep.exe and install Active Directory Domain Services.
17. On the Review Options page, confirm your selections, click View script if you want to export the settings
to a Windows PowerShell script, and then click Next.
18. On the Prerequisites Check page, confirm that prerequisite validation completed and then click Install.
19. On the Results page, verify that the server was successfully configured as a domain controller. The server
will be restarted automatically to complete the AD DS installation.
Performing a Staged RODC Installation using the Graphical User

Interface
A staged RODC installation allows you to create an RODC in two stages. In the first stage, a member of the
Domain Admins group creates an RODC account. In the second stage, a server is attached to the RODC account.
The second stage can be completed by a member of the Domain Admins group or a delegated domain user or
group.
To create an RODC account by using the Active Directory management tools
1. You can create the RODC account using Active Directory Administrative Center or Active Directory Users
and Computers.
a. Click Start, click Administrative Tools, and then click Active Directory Administrative Center.
b. In the navigation pane (left pane), click the name of the domain.
c. In the Management list (center pane), click the Domain Controllers OU.
d. In the Tasks Pane (right pane), click Pre-create a read-only domain controller account.
-Or-
a. Click Start, click Administrative Tools, and then click Active Directory Users and Computers.
b. Either right-click the Domain Controllers organizational unit (OU ) or click the Domain Controllers
OU, and then click Action.
c. Click Pre-create Read-only Domain Controller account.
2. On the Welcome to the Active Directory Domain Services Installation Wizard page, if you want to
modify the default the Password Replication Policy (PRP ), select Use advanced mode installation, and
then click Next.
3. On the Network Credentials page, under Specify the account credentials to use to perform the
installation, click My current logged on credentials or click Alternate credentials, and then click Set. In
the Windows Security dialog box, provide the user name and password for an account that can install the
additional domain controller. To install an additional domain controller, you must be a member of the
Enterprise Admins group or the Domain Admins group. When you are finished providing credentials, click
Next.
4. On the Specify the Computer Name page, type the computer name of the server that will be the RODC.
5. On the Select a Site page, select a site from the list or select the option to install the domain controller in
the site that corresponds to the IP address of the computer on which you are running the wizard, and then
click Next.
6. On the Additional Domain Controller Options page, make the following selections, and then click Next:
DNS server: This option is selected by default so that your domain controller can function as a
Domain Name System (DNS ) server. If you do not want the domain controller to be a DNS server,
clear this option. However, if you do not install the DNS server role on the RODC and the RODC is
the only domain controller in the branch office, users in the branch office will not be able to perform
name resolution when the wide area network (WAN ) to the hub site is offline.
Global catalog: This option is selected by default. It adds the global catalog, read-only directory
partitions to the domain controller, and it enables global catalog search functionality. If you do not
want the domain controller to be a global catalog server, clear this option. However, if you do not
install a global catalog server in the branch office or enable universal group membership caching for
the site that includes the RODC, users in the branch office will not be able to log on to the domain
when the WAN to the hub site is offline.
Read-only domain controller. When you create an RODC account, this option is selected by default
and you cannot clear it.
7. If you selected the Use advanced mode installation check box on the Welcome page, the Specify the
Password Replication Policy page appears. By default, no account passwords are replicated to the RODC,
and security-sensitive accounts (such as members of the Domain Admins group) are explicitly denied from
ever having their passwords replicated to the RODC.
To add other accounts to policy, click Add, then click Allow passwords for the account to replicate to
this RODC or click Deny passwords for the account from replicating to this RODC and then select the
accounts.
When complete (or to accept the default setting), click Next.
8. On the Delegation of RODC Installation and Administration page, type the name of the user or the
group who will attach the server to the RODC account that you are creating. You can type the name of only
one security principal.
To search the directory for a specific user or group, click Set. In Select User or Group, type the name of the
user or group. We recommend that you delegate RODC installation and administration to a group.
This user or group will also have local administrative rights on the RODC after the installation. If you do not
specify a user or group, only members of the Domain Admins group or the Enterprise Admins group will be
able to attach the server to the account.
When you are finished, click Next.
9. On the Summary page, review your selections. Click Back to change any selections, if necessary.
To save the settings that you selected to an answer file that you can use to automate subsequent AD DS
operations, click Export settings. Type a name for your answer file, and then click Save.
When you are sure that your selections are accurate, click Next to create the RODC account.
10. On the Completing the Active Directory Domain Services Installation Wizard page, click Finish.
After an RODC account is created, you can attach a server to account to complete the RODC installation. This
second stage can be completed in the branch office where the RODC will be located. The server where you perform
this procedure must not be joined to the domain. Beginning in Windows Server 2012 , you use the Add Roles
Wizard in Server Manager to attach a server to an RODC account.
To attach a server to an RODC account using Server Manager
1. Log on as local Administrator.
2. In Server Manager, click Add roles and features.
4. On the Select installation type page, click Role-based or feature-based installation and then click
Next.
5. On the Select destination server page, click Select a server from the server pool, click the name of the
server where you want to install AD DS and then click Next.
6. On the Select server roles page, click Active Directory Domain Services, click Add Features and then
click Next.
7. On the Select features page, select any additional features that you want to install and click Next.
8. On the Active Directory Domain Services page, review the information and then click Next.
10. On the Results page, verify Installation succeeded, and click Promote this server to a domain
controller to start the Active Directory Domain Services Configuration Wizard.
IMPORTANT
If you close Add Roles Wizard at this point without starting the Active Directory Domain Services Configuration
Wizard, you can restart it by clicking Tasks in Server Manager.
(media/Install-Active-Directory-Domain-Services--Level-100-/ADDS_SMI_Tasks.gif)
11. On the Deployment Configuration page, click Add a domain controller to an existing domain, type
the name of the domain (for example, emea.contoso.com) and credentials (for example, specify an account
that is delegated to manage and install the RODC ), and then click Next.
12. On the Domain Controller Options page, click Use existing RODC account, type and confirm the
Directory Services Restore Mode password, and then click Next.
13. On the Additional Options page, if you are installing from media, click Install from media path type and
verify the path to the installation source files, select the domain controller that you want to replicate the AD
DS installation data from (or allow the wizard to select any domain controller) and then click Next.
14. On the Paths page, type the locations for the Active Directory database, log files, and SYSVOL folder, or
accept default locations, and then click Next.
15. On the Review Options page, confirm your selections, click View Script to export the settings to a
Windows PowerShell script, and then click Next.
16. On the Prerequisites Check page, confirm that prerequisite validation completed and then click Install.
To complete the AD DS installation, the server will restart automatically.
See Also
Install a New Windows Server 2012 Active Directory Forest (Level 200)
Install a New Windows Server 2012 Active Directory
Forest (Level 200)
This topic explains the new Windows Server 2012 Active Directory Domain Services domain controller promotion
feature at an introductory level. In Windows Server 2012, AD DS replaces the Dcpromo tool with a Server
Manager and Windows PowerShell-based deployment system.
Active Directory Domain Services Simplified Administration
Technical Overview
Deploying a Forest with Windows PowerShell
Active Directory Domain Services Simplified Administration

Windows Server 2012 introduces the next generation of Active Directory Domain Services Simplified
Administration, and is the most radical domain re-envisioning since Windows 2000 Server. AD DS Simplified
Administration takes lessons learned from twelve years of Active Directory and makes a more supportable, more
flexible, more intuitive administrative experience for architects and administrators. This meant creating new
versions of existing technologies as well as extending the capabilities of components released in Windows Server
2008 R2.
What Is AD DS Simplified Administration?
AD DS Simplified Administration is a reimagining of domain deployment. Some of those features include:
AD DS role deployment is now part of the new Server Manager architecture and allows remote installation.
The AD DS deployment and configuration engine is now Windows PowerShell, even when using a graphical
setup.
Promotion now includes prerequisite checking that validates forest and domain readiness for the new
domain controller, lowering the chance of failed promotions.
The Windows Server 2012 forest functional level does not implement new features and domain functional
level is required only for a subset of new Kerberos features, relieving administrators of the frequent need for
a homogenous domain controller environment.
Purpose and Benefits
These changes may appear more complex, not simpler. In redesigning the AD DS deployment process though,
there was opportunity to coalesce many steps and best practices into fewer, easier actions. This means, for example,
that the graphical configuration of a new replica domain controller is now eight dialogs rather than the previous
twelve. Creating a new Active Directory forest requires a single Windows PowerShell command with only one
argument: the name of the domain.
Why is there such an emphasis on Windows PowerShell in Windows Server 2012? As distributed computing
evolves, Windows PowerShell allows a single engine for configuration and maintenance from both graphical and
command-line interfaces. It permits fully featured scripting of any component with the same first class citizenship
for an IT Professional that an API grants to developers. As cloud-based computing becomes ubiquitous, Windows
PowerShell also finally brings the ability to remotely administer a server, where a computer with no graphical
interface has the same management capabilities as one with a monitor and mouse.
A veteran AD DS administrator should find their previous knowledge highly relevant. A beginning administrator
will find a far shallower learning curve.
Technical Overview
What You Should Know Before You Begin
This topic assumes familiarity with previous releases of Active Directory Domain Services, and does not provide
foundational detail around their purpose and functionality. For more information about AD DS, see the TechNet
Portal pages linked below:
Active Directory Domain Services for Windows Server 2008 R2
Active Directory Domain Services for Windows Server 2008
Windows Server Technical Reference
Functional Descriptions
AD DS Role Installation
Active Directory Domain Services installation uses Server Manager and Windows PowerShell, like all other server
roles and features in Windows Server 2012. The Dcpromo.exe program no longer provides GUI configuration
options.
You use a graphical wizard in Server Manager or the ServerManager module for Windows PowerShell in both local
and remote installations. By running multiple instances of those wizards or cmdlets and targeting different servers,
you can deploy AD DS to multiple domain controllers simultaneously, all from one single console. Although these
new features are not backwards compatible with Windows Server 2008 R2 or earlier operating systems, you can
also still use the Dism.exe application introduced in Windows Server 2008 R2 for local role installation from the
classic command-line.
AD DS Role Configuration
Active Directory Domain Services configuration " previously known as DCPROMO " is a now a discrete operation
from role installation. After installing the AD DS role, an administrator configures the server as a domain controller
using a separate wizard within Server Manager or using the ADDSDeployment Windows PowerShell module.
AD DS role configuration builds on twelve years of field experience and now configures domain controllers based
on the most recent Microsoft best practices. For example, Domain Name System and Global Catalogs install by
default on every domain controller.
The Server Manager AD DS configuration wizard merges many individual dialogs into fewer prompts and no
longer hides settings in an "advanced" mode. The entire promotion process is in one expanding dialog box during
installation. The wizard and the ADDSDeployment Windows PowerShell module show you notable changes and
security concerns, with links to further information.
The Dcpromo.exe remains in Windows Server 2012 for command-line unattended installations only, and no longer
runs the graphical installation wizard. It is highly recommended that you discontinue use of Dcpromo.exe for
unattended installs and replace it with the ADDSDeployment module, as the now -deprecated executable will not be
included in the next version of Windows.
These new features are not backwards compatible to Windows Server 2008 R2 or older operating systems.
IMPORTANT
Dcpromo.exe no longer contains a graphical wizard and no longer installs role or feature binaries. Attempting to run
Dcpromo.exe from the Explorer shell returns:
"The Active Directory Domain Services Installation Wizard is relocated in Server Manager. For more information, see
https://go.microsoft.com/fwlink/?LinkId=220921."
Attempting to run Dcpromo.exe /unattend still installs the binaries, as in previous operating systems, but warns:
"The dcpromo unattended operation is replaced by the ADDSDeployment module for Windows PowerShell. For more
information, see https://go.microsoft.com/fwlink/?LinkId=220924."
Windows Server 2012 deprecates dcpromo.exe and it will not be included with future versions of Windows, nor will it receive
further enhancements in this operating system. Administrators should discontinue its use and switch to the supported
Windows PowerShell modules if they wish to create domain controllers from the command-line.
Prerequisite Checking
Domain controller configuration also implements a prerequisite checking phase that evaluates the forest and
domain prior to continuing with domain controller promotion. This includes FSMO role availability, user privileges,
extended schema compatibility and other requirements. This new design alleviates issues where domain controller
promotion starts and then halts midway with a fatal configuration error. This lessens the chance of orphaned
domain controller metadata in the forest or a server that incorrectly believes it is a domain controller.

This section explains how to install the first domain controller in a forest root domain using Server Manager on a
graphical Windows Server 2012 computer.
Server Manager AD DS Role Installation Process
The diagram below illustrates the Active Directory Domain Services role installation process, beginning with you
running ServerManager.exe and ending right before the promotion of the domain controller.
Server Pool and Add Roles

Any Windows Server 2012 computers accessible from the computer running Server Manager are eligible for
pooling. Once pooled, you select those servers for remote installation of AD DS or any other configuration options
possible within Server Manager.
To add servers, choose one of the following:
Click Add Other Servers to Manage on the dashboard welcome tile
Click the Manage menu and select Add Servers
Right-click All Servers and choose Add Servers
This brings up the Add Servers dialog:
This gives you three ways to add servers to the pool for use or grouping:
Active Directory search (uses LDAP, requires that the computers belong to a domain, allows operating
system filtering and supports wildcards)
DNS search (uses DNS alias or IP address via ARP or NetBIOS broadcast or WINS lookup, does not allow
operating system filtering or support wildcards)
Import (uses a text file list of servers separated by CR/LF )
Click Find Now to return a list of servers from that same Active Directory domain that the computer is joined to,
Click one or more server names from the list of servers. Click the right arrow to add the servers to the Selected
list. Use the Add Servers dialog to add selected servers to dashboard role groups. Or Click Manage, and then
click Create Server Group, or click Create Server Group on the dashboard Welcome to Server Manager tile to
create custom server groups.
NOTE
The Add Servers procedure does not validate that a server is online or accessible. However, any unreachable servers flag in
the Manageability view in Server Manager at the next refresh
You can install roles remotely on any Windows Server 2012 computers added the pool, as shown:
You cannot fully manage servers running operating systems older than Windows Server 2012. The Add Roles and
Features selection is running ServerManager Windows PowerShell Module Install-WindowsFeature.
You can also use the Server Manager Dashboard on an existing domain controller to select remote server AD DS
installation with the role already preselected by right clicking the AD DS dashboard tile and selecting Add AD DS
to Another Server. This is invoking Install-WindowsFeature AD -Domain-Services.
The computer you are running Server Manager on pools itself automatically. To install the AD DS role here, simply
click the Manage menu and click Add Roles and Features.
Installation Type
The Installation Type dialog provides an option that does not support Active Directory Domain Services: the
Remote Desktop Services scenario based-installation. That option only allows Remote Desktop Service in a
multi-server distributed workload. If you select it, AD DS cannot install.
Always leave the default selection in place when installing AD DS: Role-based or Feature-based Installation.
Server Selection
The Server Selection dialog enables you to choose from one of the servers previously added to the pool, as long
as it is accessible. The local server running Server Manager is automatically available.
In addition, you can select offline Hyper-V VHD files with the Windows Server 2012 operating system and Server
Manager adds the role to them directly through component servicing. This allows you to provision virtual servers
with the necessary components before further configuring them.
Server Roles and Features
Select the Active Directory Domain Services role if you intend to promote a domain controller. All Active
Directory administration features and required services install automatically, even if they are ostensibly part of
another role or do not appear selected in the Server Manager interface.
Server Manager also presents an informational dialog that shows which management features this role implicitly
installs; this is equivalent to the -IncludeManagementTools argument.
Additional Features can be added here as desired.
The Active Directory Domain Services dialog provides limited information on requirements and best practices.
It mainly acts as a confirmation that you chose the AD DS role " if this screen does not appear, you did not select
AD DS.
Confirmation
The Confirmation dialog is the final checkpoint before role installation starts. It offers an option to restart the
computer as needed after role installation, but AD DS installation does not require a reboot.
By clicking Install, you confirm you are ready to begin role installation. You cannot cancel a role installation once it
begins.
Results
The Results dialog shows the current installation progress and current installation status. Role installation
continues regardless of whether Server Manager is closed.
Verifying the installation results is still a best practice. If you close the Results dialog before installation completes,
you can check the results using the Server Manager notification flag. Server Manager also shows a warning
message for any servers that have installed the AD DS role but not been further configured as domain controllers.
Task Notifications
AD DS Details
Task Details
Promote to Domain Controller
At the end of the AD DS role installation, you can continue with configuration by using the Promote this server to
a domain controller link. This is required to make the server a domain controller, but is not necessary to run the
configuration wizard immediately. For example, you may only want to provision servers with the AD DS binaries
before sending them to another branch office for later configuration. By adding the AD DS role before shipping,
you save time when it reaches its destination. You also follow the best practice of not keeping a domain controller
offline for days or weeks. Finally, this enables you to update components before domain controller promotion,
saving you at least one subsequent reboot.
Selecting this link later invokes the ADDSDeployment cmdlets: install-addsforest, install-addsdomain, or
install-addsdomaincontroller.
Uninstalling/Disabling
You remove the AD DS role like any other role, regardless of whether you promoted the server to a domain
controller. However, removing the AD DS role requires a restart on completion.
Active Directory Domain Services role removal is different from installation, in that it requires domain controller
demotion before it can complete. This is necessary to prevent a domain controller from having its role binaries
uninstalled without proper metadata cleanup in the forest. For more information, see Demoting Domain
Controllers and Domains (Level 200).
WARNING
Removing the AD DS roles with Dism.exe or the Windows PowerShell DISM module after promotion to a Domain Controller is
not supported and will prevent the server from booting normally.
Unlike Server Manager or the AD DS Deployment module for Windows PowerShell, DISM is a native servicing system that has
no inherent knowledge of AD DS or its configuration. Do not use Dism.exe or the Windows PowerShell DISM module to
uninstall the AD DS role unless the server is no longer a domain controller.
Create an AD DS Forest Root Domain with Server Manager

The following diagram illustrates the Active Directory Domain Services configuration process, in the case where
you have previously installed the AD DS role and started the Active Directory Domain Services Configuration
Wizard using Server Manager.
Deployment Configuration
Server Manager begins every domain controller promotion with the Deployment Configuration page. The
remaining options and required fields change on this page and subsequent pages, depending on which deployment
operation you select.
To create a new Active Directory forest, click Add a new forest. You must provide a valid root domain name; the
name cannot be single-labeled (for example, the name must be contoso.com or similar and not just contoso) and
must use allowed DNS domain naming requirements.
For more information on valid domain names, see KB article Naming conventions in Active Directory for
computers, domains, sites, and OUs.
WARNING
Do not create new Active Directory forests with the same name as an external DNS name. For example, if your Internet DNS
URL is http://contoso.com, you must choose a different name for your internal forest to avoid future compatibility issues. That
name should be unique and unlikely for web traffic. For example: corp.contoso.com.
A new forest does not need new credentials for the domain's Administrator account. The domain controller
promotion process uses the credentials of the built-in Administrator account from the first domain controller used
to create the forest root. There is no way (by default) to disable or lock out the built-in Administrator account and it
may be the only entry point into a forest if the other administrative domain accounts are unusable. It is critical to
know the password before deploying a new forest.
DomainName requires a valid fully qualified domain DNS name and is required.
Domain Controller Options
The Domain Controller Options enables you to configure the forest functional level and domain functional
level for the new forest root domain. By default, these settings are Windows Server 2012 in a new forest root
domain. The Windows Server 2012 forest functional level does not provide any new functionality over the
Windows Server 2008 R2 forest functional level. The Windows Server 2012 domain functional level is required
only in order to implement the new Kerberos settings "always provide claims" and "Fail unarmored authentication
requests." A primary use for functional levels in Windows Server 2012 is to restrict participation in the domain to
domain controllers that meet minimum-allowed operating system requirements. In other words, you can specify
Windows Server 2012 domain functional level only domain controllers that run Windows Server 2012 can host the
domain. Windows Server 2012 implements a new domain controller flag called DS_WIN8_REQUIRED in the
DSGetDcName function of NetLogon that exclusively locates Windows Server 2012 domain controllers. This
allows you the flexibility of a more homogeneous or heterogeneous forest in terms of which operating systems are
permitted to be run on domain controllers.
For more information about domain controller Location, review Directory Service Functions.
The only configurable domain controller capability is the DNS server option. Microsoft recommends that all
domain controllers provide DNS services for high availability in distributed environments, which is why this option
is selected by default when installing a domain controller in any mode or domain. The Global Catalog and read only
domain controller options are unavailable when creating a new forest root domain; the first domain controller must
be a GC, and cannot be a read only domain controller (RODC ).
The specified Directory Services Restore Mode Password must adhere to the password policy applied to the
server, which by default does not require a strong password; only a non-blank one. Always choose a strong,
complex password or preferably, a passphrase.
DNS Options and DNS Delegation Credentials
The DNS Options page enables you to configure DNS delegation and provide alternate DNS administrative
credentials.
You cannot configure DNS options or delegation in the Active Directory Domain Services Configuration Wizard
when installing a new Active Directory Forest Root Domain where you selected the DNS server on the Domain
Controller Options page. The Create DNS delegation option is available when creating a new forest root DNS
zone in an existing DNS server infrastructure. This option enables you to provide alternate DNS administrative
credentials that have the rights to update DNS zone.
For more information about whether you need to create a DNS delegation, see Understanding Zone Delegation.
Additional Options
The Additional Options page shows the NetBIOS name of the domain and enables you to override it. By default,
the NetBIOS domain name matches the left-most label of the fully qualified domain name provided on the
Deployment Configuration page. For example, if you provided the fully qualified domain name of
corp.contoso.com, the default NetBIOS domain name is CORP.
If the name is 15 characters or less and does not conflict with another NetBIOS name, it is unaltered. If it does
conflict with another NetBIOS name, a number is appended to the name. If the name is more than 15 characters,
the wizard provides a unique, truncated suggestion. In either case, the wizard first validates the name is not already
in use via a WINS lookup and NetBIOS broadcast.
For more information on valid domain names, see KB article Naming conventions in Active Directory for
computers, domains, sites, and OUs.
Paths
The Paths page enables you to override the default folder locations of the AD DS database, the database
transaction logs, and the SYSVOL share. The default locations are always in subdirectories of %systemroot% (i.e.
C:\Windows).
Review Options and View Script
The Review Options page enables you to validate your settings and ensure they meet your requirements before
you start the installation. This is not the last opportunity to stop the installation when using Server Manager. This is
simply an option to confirm your settings before continuing the configuration
The Review Options page in Server Manager also offers an optional View Script button to create a Unicode text
file that contains the current ADDSDeployment configuration as a single Windows PowerShell script. This enables
you to use the Server Manager graphical interface as a Windows PowerShell deployment studio. Use the Active
Directory Domain Services Configuration Wizard to configure options, export the configuration, and then cancel
the wizard. This process creates a valid and syntactically correct sample for further modification or direct use. For
example:
#
# Windows PowerShell Script for AD DS Deployment
#
Import-Module ADDSDeployment
Install-ADDSForest `
-CreateDNSDelegation `
-DatabasePath "C:\Windows\NTDS" `
-DomainMode "Win2012" `
-DomainName "corp.contoso.com" `
-DomainNetBIOSName "CORP" `
-ForestMode "Win2012" `
-InstallDNS:$true `
-LogPath "C:\Windows\NTDS" `
-NoRebootOnCompletion:$false `
-SYSVOLPath "C:\Windows\SYSVOL"
-Force:$true
NOTE
Server Manager generally fills in all arguments with values when promoting and does not rely on defaults (as they may
change between future versions of Windows or service packs). The one exception to this is the -
safemodeadministratorpassword argument (which is deliberately omitted from the script). To force a confirmation prompt,
omit the value when running cmdlet interactively.
Prerequisites Check
The Prerequisites Check is a new feature in AD DS domain configuration. This new phase validates that the
server configuration is capable of supporting a new AD DS forest.
When installing a new forest root domain, the Server Manager Active Directory Domain Services Configuration
Wizard invokes a series of modular tests. These tests alert you with suggested repair options. You can run the tests
as many times as required. The domain controller process cannot continue until all prerequisite tests pass.
The Prerequisites Check also surfaces relevant information such as security changes that affect older operating
systems.
For more information on the specific prerequisite checks, see Prerequisite Checking.
Installation
When the Installation page displays, the domain controller configuration begins and cannot be halted or canceled.
Detailed operations display on this page and are written to logs:
%systemroot%\debug\dcpromo.log
%systemroot%\debug\dcpromoui.log
NOTE
You can run multiple role installation and AD DS configuration wizards from the same Server Manager console simultaneously.
Results
The Results page shows the success or failure of the promotion and any important administrative information. The
domain controller will automatically reboot after 10 seconds.
Deploying a Forest with Windows PowerShell

This section explains how to install the first domain controller in a forest root domain using Windows PowerShell
on a Core Windows Server 2012 computer.
Windows PowerShell AD DS Role Installation Process
By implementing a few straightforward ServerManager deployment cmdlets into your deployment processes, you
further realize the vision of AD DS simplified administration.
The next figure illustrates the Active Directory Domain Services role installation process, beginning with you
running PowerShell.exe and ending right before the promotion of the domain controller.
ServerManager Cmdlet Arguments (Bold arguments are required. Italicized

arguments can be specified by using Windows PowerShell or
the AD DS Configuration Wizard.)
Install-WindowsFeature/Add-WindowsFeature -Name
-Restart
-IncludeAllSubFeature
-IncludeManagementTools
-Source
-ComputerName
-Credential
-LogPath
-Vhd
-ConfigurationFilePath
NOTE
While not required, the argument -IncludeManagementTools is highly recommended when installing the AD DS role
binaries
The ServerManager module exposes role installation, status, and removal portions of the new DISM module for
Windows PowerShell. This layering simplifies the most tasks and reduces need for direct usage of the powerful (but
dangerous when misused) DISM module.
Use Get-Command to export the aliases and cmdlets in ServerManager.
Get-Command -module ServerManager
For example:
To add the Active Directory Domain Services role, simply run the Install-WindowsFeature with the AD DS role
name as an argument. Like Server Manager, all required services implicit to the AD DS role install automatically.
Install-WindowsFeature -name AD-Domain-Services
If you also want the AD DS management tools installed - and this is highly recommended - then provide the -
IncludeManagementTools argument:
Install-WindowsFeature -name AD-Domain-Services -IncludeManagementTools
For example:
To list all features and roles with their installation status, use Get-WindowsFeature without arguments. Specify -
ComputerName argument for the installation status from a remote server.
Get-WindowsFeature
Because Get-WindowsFeature does not have a filtering mechanism, you must use Where-Object with a pipeline
to find specific features. The pipeline is a channel used between multiple cmdlets to pass data and the Where-
Object cmdlet acts as a filter. The built-in $_ variable acts as the current object passing through the pipeline with
any properties it may contain.
Get-WindowsFeature | where-object <options>
For example, to find all features containing "Active Dir" in their Display Name property, use:
Get-WindowsFeature | where displayname -like "*active dir*"
Further examples illustrated below:

For more information about more Windows PowerShell operations with pipelines and Where-Object, see Piping
and the Pipeline in Windows PowerShell.
Note also that Windows PowerShell 3.0 significantly simplified the command-line arguments needed in this
pipeline operation. Windows PowerShell 2.0 would have required:
Get-WindowsFeature | where {$_.displayname - like "*active dir*"}
By using the Windows PowerShell pipeline, you can create readable results. For example:
Install-WindowsFeature | Format-List
Install-WindowsFeature | select-object | Format-List
Note how using the Select-Object cmdlet with the -expandproperty argument returns interesting data:
NOTE
The Select-Object -expandproperty argument slows down overall installation performance slightly.
Create an AD DS Forest Root Domain with Windows PowerShell

To install a new Active Directory forest using the ADDSDeployment module, use the following cmdlet:
Install-addsforest
The Install-AddsForest cmdlet only has two phases (prerequisite checking and installation). The two figures below
show the installation phase with the minimum required argument of -domainname.
ADDSDeployment Cmdlet Arguments (Bold arguments are required. Italicized

Install-Addsforest -Confirm
-CreateDNSDelegation
-DatabasePath
-DomainMode
-DomainName
-DomainNetBIOSName
-DNSDelegationCredential
-ForestMode
-Force
-InstallDNS
-LogPath
-NoDnsOnNetwork
-NoRebootOnCompletion
-SafeModeAdministratorPassword
-SkipAutoConfigureDNS
-SkipPreChecks
-SYSVOLPath
-Whatif
NOTE
The -DomainNetBIOSName argument is required if you want to change the automatically generated 15-character name
based on the DNS domain name prefix or if the name exceeds 15 characters.
The equivalent Server Manager Deployment Configuration ADDSDeployment cmdlet and arguments are:
Install-ADDSForest
-DomainName <string>
The equivalent Server Manager Domain Controller Options ADDSDeployment cmdlet arguments are:
-ForestMode <{Win2003 | Win2008 | Win2008R2 | Win2012 | Default}>

-DomainMode <{Win2003 | Win2008 | Win2008R2 | Win2012 | Default}>
-InstallDNS <{$false | $true}>
-SafeModeAdministratorPassword <secure string>
The Install-ADDSForest arguments follow the same defaults as Server Manager if not specified.
The SafeModeAdministratorPassword argument's operation is special:
For example, to create a new forest named corp.contoso.com and be prompted to enter and confirm a
masked password:
Install-ADDSForest "DomainName corp.contoso.com
secure string:
-safemodeadministratorpassword (read-host -prompt "Password:" -assecurestring)
WARNING
You can also provide a secure string as a converted clear-text variable, although this is highly discouraged.
-safemodeadministratorpassword (convertto-securestring "Password1" -asplaintext -force)
Finally, you could store the obfuscated password in a file, and then reuse it later, without the clear text password
ever appearing. For example:
$file = "c:\pw.txt"
$pw = read-host -prompt "Password:" -assecurestring
$pw | ConvertFrom-SecureString | Set-Content $file
-safemodeadministratorpassword (Get-Content $File | ConvertTo-SecureString)

WARNING
Providing or storing a clear or obfuscated text password is not recommended. Anyone running this command in a script or
looking over your shoulder knows the DSRM password of that domain controller. Anyone with access to the file could reverse
that obfuscated password. With that knowledge, they can logon to a DC started in DSRM and eventually impersonate the
domain controller itself, elevating their privileges to the highest level in an Active Directory forest. An additional set of steps
using System.Security.Cryptography to encrypt the text file data is advisable but out of scope. The best practice is to
totally avoid password storage.
The ADDSDeployment cmdlet offers an additional option to skip automatic configuration of DNS client settings,
forwarders, and root hints. You cannot skip this configuration option when using Server Manager. This argument
matters only if you installed the DNS Server role prior to configuring the domain controller:
The DomainNetBIOSName operation is also special:

If the DomainNetBIOSName argument is not specified with a NetBIOS domain name and the single-label
prefix domain name in the DomainName argument is 15 characters or fewer, then promotion continues
with an automatically generated name.
If the DomainNetBIOSName argument is not specified with a NetBIOS domain name and the single-label
prefix domain name in the DomainName argument is 16 characters or more, then promotion fails.
If the DomainNetBIOSName argument is specified with a NetBIOS domain name of 15 characters or
fewer, then promotion continues with that specified name.
If the DomainNetBIOSName argument is specified with a NetBIOS domain name of 16 characters or
more, then promotion fails.
The equivalent Server Manager Additional Options ADDSDeployment cmdlet argument is:
-domainnetbiosname <string>
The equivalent Server Manager Paths ADDSDeployment cmdlet arguments are:
-databasepath <string>
-logpath <string>
-sysvolpath <string>
Use the optional Whatif argument with the Install-ADDSForest cmdlet to review configuration information. This
enables you to see the explicit and implicit values of a cmdlet's arguments.
For example:
You cannot bypass the Prerequisite Check when using Server Manager, but you can skip the process when using
the AD DS Deployment cmdlet using the following argument:
-skipprechecks
WARNING
Microsoft discourages skipping the prerequisite check as it can lead to a partial domain controller promotion or damaged AD
DS forest.
Note how, just like Server Manager, Install-ADDSForest reminds you that promotion will reboot the server
automatically.
To accept the reboot prompt automatically, use the -force or -confirm:$false arguments with any
ADDSDeployment Windows PowerShell cmdlet. To prevent the server from automatically rebooting at the end of
promotion, use the -norebootoncompletion argument.
WARNING
Overriding the reboot is discouraged. The domain controller must reboot to function correctly.
See Also
Active Directory Domain Services (TechNet Portal)
Active Directory Domain Services for Windows Server 2008 R2
Active Directory Domain Services for Windows Server 2008
Windows Server Technical Reference (Windows Server 2003)
Active Directory Administrative Center: Getting Started (Windows Server 2008 R2)
Active Directory Administration with Windows PowerShell (Windows Server 2008 R2)
Ask the Directory Services Team (Official Microsoft Commercial Technical Support Blog)
Install a Replica Windows Server 2012 Domain
Controller in an Existing Domain (Level 200)
This topic covers the steps necessary to upgrade an existing forest or domain to Windows Server 2012, using
either Server Manager or Windows PowerShell. It covers how to add domain controllers that run Windows Server
2012 to an existing domain.
Upgrade and Replica Workflow
Upgrade and Replica Windows PowerShell
Deployment
Upgrade and Replica Workflow

The following diagram illustrates the Active Directory Domain Services configuration process when you previously
installed the AD DS role and you have started the Active Directory Domain Services Configuration Wizard using
Server Manager to create a new domain controller in an existing domain.
Upgrade and Replica Windows PowerShell

Install-AddsDomainController -SkipPreChecks
-DomainName
-SiteName
-ADPrepCredential
-AllowDomainControllerReinstall
-Confirm
-Credential
-CriticalReplicationOnly
-DatabasePath
-Force
-InstallationMediaPath
-InstallDNS
-LogPath
-MoveInfrastructureOperationMasterRoleIfNecessary
-NoDnsOnNetwork
-NoGlobalCatalog
-Norebootoncompletion
-ReplicationSourceDC
-SiteName
-SystemKey
-SYSVOLPath
-UseExistingAccount
-Whatif
NOTE
The -credential argument is only required if you are not already logged on as a member of the Enterprise Admins and
Schema Admins groups (if you are upgrading the forest) or the Domain Admins group (if you are adding a new DC to an
existing domain).
Deployment
To upgrade an existing forest or add a writable domain controller to an existing domain, click Add a domain
controller to an existing domain and click Select to Specify the domain information for this domain.
Server Manager prompts you for valid credentials if needed.
Upgrading the forest requires credentials that include group memberships in both the Enterprise Admins and
Schema Admins groups in Windows Server 2012. The Active Directory Domain Services Configuration Wizard
prompts you later if your current credentials do not have adequate permissions or group memberships.
The automatic Adprep process is the only operational difference between adding a domain controller to an existing
Windows Server 2012 domain and a domain where domain controllers run an earlier version of Windows Server.
The Deployment Configuration ADDSDeployment cmdlet and arguments are:
Install-AddsDomainController
-domainname <string>
-credential <pscredential>
Certain tests perform at each page, some of which repeat later as discrete prerequisite checks. For instance, if the
selected domain does not meet the minimal functional levels, you do not have to go all the way through promotion
to the prerequisite check to find out:

The Domain Controller Options page specifies the domain controller capabilities for the new domain controller.
The configurable domain controller capabilities are DNS server, Global Catalog, and Read-only domain
controller. Microsoft recommends that all domain controllers provide DNS and GC services for high availability in
distributed environments. GC is always selected by default and DNS server is selected by default if the current
domain hosts DNS already on its DCs based on Start of Authority query. The Domain Controller Options page
also enables you to choose the appropriate Active Directory logical site name from the forest configuration. By
default, it selects the site with the most correct subnet. If there is only one site, it selects automatically.
NOTE
If the server does not belong to an Active Directory subnet and there is more than one Active Directory site, nothing is
selected and the Next button is unavailable until you choose a site from the list.
server. Always choose a strong, complex password or preferably, a passphrase.
The Domain Controller Options ADDSDeployment arguments are:

-NoGlobalCatalog <{$false | $true}>
-sitename <string>
IMPORTANT
The site name must already exist when provided as an argument to -sitename. The install-AddsDomainController cmdlet
does not create sites. You can use cmdlet new-adreplicationsite to create new sites.

For example, to create an additional domain controller in treyresearch.net domain and be prompted to enter
and confirm a masked password:
Install-ADDSDomainController "DomainName treyresearch.net "credential (get-credential)
secure string:
WARNING
$file = "c:\pw.txt"
WARNING
domain controller itself, elevating their privileges to the highest level in an Active Directory forest. An additional set of steps
using System.Security.Cryptography to encrypt the text file data is advisable but out of scope. The best practice is to
totally avoid password storage.
The ADDSDeployment cmdlet offers an additional option to skip automatic configuration of DNS client settings,
forwarders, and root hints. You cannot skip this configuration option when using Server Manager. This argument
matters only if you installed the DNS Server role prior to configuring the domain controller:
The Domain Controller Options page warns that you cannot create read only domain controllers if your existing
domain controllers run Windows Server 2003. This is expected, and you can dismiss the warning.
The DNS Options page enables you to configure DNS delegation if you selected the DNS server option on the
Domain Controller Options page and if pointing to a zone where DNS delegations are allowed. You may need to
provide alternate credentials of a user that is a member of the DNS Admins group.
The DNS Options ADDSDeployment cmdlet arguments are:
-creatednsdelegation
-dnsdelegationcredential <pscredential>
For more information about whether you need to create a DNS delegation, see Understanding Zone Delegation.
Additional Options
The Additional Options page provides the configuration option to name a domain controller as the replication
source, or you can use any domain controller as the replication source.
You can also choose to install the domain controller using backed up media using the Install from media (IFM )
option. The Install from media checkbox provides a browse option once selected and you must click Verify to
ensure the provided path is valid media. Media used by the IFM option is created with Windows Server Backup or
Ntdsutil.exe from another existing Windows Server 2012 computer only; you cannot use a Windows Server 2008
R2 or previous operating system to create media for a Windows Server 2012 domain controller. For more
information about changes in IFM, see Simplified Administration Appendix. If using media protected with a
SYSKEY, Server Manager prompts for the image's password during verification.
The Additional Options ADDSDeployment cmdlet arguments are:
-replicationsourcedc <string>
-installationmediapath <string>
-syskey <secure string>
Paths
transaction logs, and the SYSVOL share. The default locations are always in subdirectories of %systemroot%.
The Active Directory Paths ADDSDeployment cmdlet arguments are:
-logpath <string>
Preparation Options
The Preparation Options page alerts you that the AD DS configuration includes extending the Schema
(forestprep) and updating the domain (domainprep). You only see this page when the forest and domain have not
been prepared by previous Windows Server 2012 domain controller installation or from manually running
Adprep.exe. For example, the Active Directory Domain Services Configuration Wizard suppresses this page if you
add a new domain controller to an existing Windows Server 2012 forest root domain.
Extending the Schema and updating the domain do not occur when you click Next. These events occur only during
the installation phase. This page simply brings awareness about the events that will occur later in the installation.
This page also validates that the current user credentials are members of the Schema Admin and Enterprise
Admins groups, as you need membership in these groups to extend the schema or prepare a domain. Click
Change to provide the adequate user credentials if the page informs you that the current credentials do not
provide sufficient permissions.
The Additional Options ADDSDeployment cmdlet argument is:
-adprepcredential <pscredential>
IMPORTANT
As with previous versions of Windows Server, automated domain preparation for domain controllers that run Windows Server
2012 does not run GPPREP. Run adprep.exe /gpprep manually for all domains that were not previously prepared for
Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2. You should run GPPrep only once in the history of
a domain, not with every upgrade. Adprep.exe does not run /gpprep automatically because its operation can cause all files
and folders in the SYSVOL folder to re-replicate on all domain controllers.
Automatic RODCPrep runs when you promote the first un-staged RODC in a domain. It does not occur when you promote
the first writeable Windows Server 2012 domain controller. You can also still manually adprep.exe /rodcprep if you plan to
deploy read-only domain controllers.
The Review Options page enables you to validate your settings and ensure that they meet your requirements
before you start the installation. This is not the last opportunity to stop the installation using Server Manager. This
page simply enables you to review and confirm your settings before continuing the configuration.
the wizard. This process creates a valid and syntactically correct sample for further modification or direct use.
For example:
#
#
Install-ADDSDomainController `
-Credential (Get-Credential) `
-CriticalReplicationOnly:$false `
-DomainName "root.fabrikam.com" `
-InstallDNS:$true `
-SiteName "Default-First-Site-Name" `
-Force:$true
NOTE
safemodeadministratorpassword argument. To force a confirmation prompt omit the value when running cmdlet
interactively
Use the optional Whatif argument with the Install-ADDSDomainController cmdlet to review configuration information.
This enables you to see the explicit and implicit values of the arguments for a cmdlet.
Prerequisites Check
domain and forest are capable of supporting a new Windows Server 2012 domain controller.
When installing a new domain controller, the Server Manager Active Directory Domain Services Configuration
Wizard invokes a series of serialized modular tests. These tests alert you with suggested repair options. You can run
the tests as many times as required. The domain controller process cannot continue until all prerequisite tests pass.
systems.
For more information about the specific prerequisite checks, see Prerequisite Checking.
-skipprechecks
WARNING
DS forest.
Click Install to begin the domain controller promotion process. This is last opportunity to cancel the installation.
You cannot cancel the promotion process once it begins. The computer will reboot automatically at the end of
promotion, regardless of the promotion results.The Prerequisites Check page displays any issues it encountered
during the process and guidance for resolving the issue.
Installation
%systemroot%\debug\adprep\logs
%systemroot%\debug\netsetup.log (if server is in a workgroup)
Install-addsdomaincontroller
See Upgrade and Replica Windows PowerShell for required and optional arguments.
The Install-AddsDomainController cmdlet only has two phases (prerequisite checking and installation). The two
figures below show the installation phase with the minimum required arguments of -domainname and -
credential. Note how the Adprep operation happens automatically as part of adding the first Windows Server
2012 domain controller to an existing Windows Server 2003 forest:
Note how, just like Server Manager, Install-ADDSDomainController reminds you that promotion will reboot the
server automatically. To accept the reboot prompt automatically, use the -force or -confirm:$false arguments with
any ADDSDeployment Windows PowerShell cmdlet. To prevent the server from automatically rebooting at the end
of promotion, use the -norebootoncompletion argument.
WARNING
To configure a domain controller remotely using Windows PowerShell, wrap the install-adddomaincontroller
cmdlet inside of the invoke-command cmdlet. This requires using the curly braces.
invoke-command {install-addsdomaincontroller "domainname <domain> -credential (get-credential)} -computername

<dc name>
For example:
NOTE
For more information on how the installation and Adprep process works, see the Troubleshooting Domain Controller
Deployment.
Results
The Results page shows the success or failure of the promotion and any important administrative information. If
successful, the domain controller will automatically reboot after 10 seconds.
As with previous versions of Windows Server, automated domain preparation for domain controllers that run
Windows server 2012 does not run GPPREP. Run adprep.exe /gpprep manually for all domains that were not
previously prepared for Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2. You should
run GPPrep only once in the history of a domain, not with every upgrade. Adprep.exe does not run /gpprep
automatically because its operation can cause all files and folders in the SYSVOL folder to re-replicate on all
domain controllers.
Install a New Windows Server 2012 Active Directory
Child or Tree Domain (Level 200)
This topic explains how to add child and tree domains to an existing Windows Server 2012 forest, using Server
Manager or Windows PowerShell.
Child and Tree Domain Workflow
Child and Tree Domain Windows PowerShell
Deployment
Child and Tree Domain Workflow

The following diagram illustrates the Active Directory Domain Services configuration process when you previously
Server Manager to create a new domain in an existing forest.
Child and Tree Domain Windows PowerShell

Install-AddsDomain -SkipPreChecks
-NewDomainName
-ParentDomainName
-ADPrepCredential
-AllowDomainReinstall
-Confirm
-Credential
-DatabasePath
-NoDNSOnNetwork
-DomainMode
-DomainType
-Force
-InstallDNS
-LogPath
-NewDomainNetBIOSName
-NoGlobalCatalog
-NoNorebootoncompletion
-SiteName
-SYSVOLPath
-Whatif
NOTE
The -credential argument is only required when you are not currently logged on as a member of the Enterprise Admins
group.The -NewDomainNetBIOSName argument is required if you want to change the automatically generated 15-
character name based on the DNS domain name prefix or if the name exceeds 15 characters.
Deployment
The following screenshot shows the options for adding a child domain:
The following screenshot shows the options for adding a tree domain:
This topic combines two discrete operations: child domain promotion and tree domain promotion. The only
difference between the two operations is the domain type that you choose to create. All of the other steps are
identical between the two operations.
To create a new child domain, click Add a domain to an existing Forest and choose Child Domain. For
Parent domain name, type or select the name of the parent domain. Then type the name of the new
domain in the New domain name box. Provide a valid, single-label child domain name; the name must use
DNS domain name requirements.
To create a tree domain within an existing forest, click Add a domain to an existing Forest and choose
Tree Domain. Type the name of the forest root domain, and then type the name of the new domain. Provide
a valid, fully qualified root domain name; the name cannot be single-labeled and must use DNS domain
name requirements.
For more information about DNS names, see Naming conventions in Active Directory for computers, domains,
sites, and OUs.
The Server Manager Active Directory Domain Services Configuration Wizard prompts you for domain credentials
if your current credentials are not from the domain. Click Change to provide domain credentials for the promotion
operation.
The Deployment Configuration ADDSDeployment cmdlet and arguments are:
Install-AddsDomain
-domaintype <{childdomain | treedomain}>
-parentdomainname <string>
-newdomainname <string>
The Domain Controller Options page specifies the domain controller options for the new domain controller. The
configurable domain controller options include DNS server and Global Catalog; you cannot configure read-only
domain controller as the first domain controller in a new domain.
Microsoft recommends that all domain controllers provide DNS and GC services for high availability in distributed
environments. GC is always selected by default and DNS is selected by default if the current domain hosts DNS
already on its DCs, based on a Start-of-Authority query. You must also specify a Domain functional level. The
default functional level is Windows Server 2012, and you can choose any other value that is equal to or greater
than the current forest functional level.
The Domain Controller Options page also enables you to choose the appropriate Active Directory logical site
name from the forest configuration. By default, the site with the most correct subnet is selected. If there is only one
site, it is selected automatically.
IMPORTANT
The Domain Controller Options ADDSDeployment cmdlet arguments are:

-NoGlobalCatalog <{$false | $true}>
-DomainMode <{Win2003 | Win2008 | Win2008R2 | Win2012 | Default}>
-Sitename <string>
-Credential <pscredential>
IMPORTANT
The site name must already exist when provided as a value to the sitename argument. The install-AddsDomainController
cmdlet does not create site names. You can use the new-adreplicationsite cmdlet to create new sites.
The Install-ADDSDomainController cmdlet arguments follow the same defaults as Server Manager if not
specified.
For example, to create a new child domain named NorthAmerica in the Contoso.com forest and be
prompted to enter and confirm a masked password:
Install-ADDSDomain "NewDomainName NorthAmerica "ParentDomainName Contoso.com "DomainType Child
secure string:

WARNING
$file = "c:\pw.txt"
WARNING
domain controller itself, elevating their privileges to the highest level in an AD forest. An additional set of steps using
System.Security.Cryptography to encrypt the text file data is advisable but out of scope. The best practice is to totally
avoid password storage.
The ADDSDeployment module offers an additional option to skip automatic configuration of DNS client settings,
forwarders, and root hints. This is not configurable when using Server Manager. This argument matters only if you
already installed the DNS Server service prior to configuring the domain controller:
The DNS Options page enables you to provide alternate DNS Admin credentials for delegation.
When installing a new domain in an existing forest - where you selected DNS installation on the Domain
Controller Options page - you cannot configure any options; the delegation happens automatically and
irrevocably. You have the option to provide alternate DNS administrative credentials with rights to update that
structure.
The DNS Options ADDSDeployment Windows PowerShell arguments are:
-creatednsdelegation
-dnsdelegationcredential <pscredential>
For more information about DNS delegation, see Understanding Zone Delegation.
Additional Options
The Additional Options page shows the NetBIOS name of the domain and enables you to override it. By default,
the NetBIOS domain name matches the left-most label of the fully qualified domain name provided on the
Deployment Configuration page. For example, if you provided the fully qualified domain name of
corp.contoso.com, the default NetBIOS domain name is CORP.
If the name is 15 characters or less and does not conflict with another NetBIOS name, it is unaltered. If it does
conflict with another NetBIOS name, a number is appended to the name. If the name is more than 15 characters,
the wizard provides a unique, truncated suggestion. In either case, the wizard first validates the name is not already
in use via a WINS lookup and NetBIOS broadcast.
For more information about DNS names, see Naming conventions in Active Directory for computers, domains,
sites, and OUs.
The Install-AddsDomain arguments follow the same defaults as Server Manager if not specified. The
DomainNetBIOSName operation is special:
1. If the NewDomainNetBIOSName argument is not specified with a NetBIOS domain name and the
single-label prefix domain name in the DomainName argument is 15 characters or fewer, then promotion
continues with an automatically generated name.
2. If the NewDomainNetBIOSName argument is not specified with a NetBIOS domain name and the
single-label prefix domain name in the DomainName argument is 16 characters or more, then promotion
fails.
3. If the NewDomainNetBIOSName argument is specified with a NetBIOS domain name of 15 characters
or fewer, then promotion continues with that specified name.
4. If the NewDomainNetBIOSName argument is specified with a NetBIOS domain name of 16 characters
or more, then promotion fails.
-newdomainnetbiosname <string>
Paths
The Paths page enables you to override the default folder locations of the AD DS database, the data base
transaction logs, and the SYSVOL share. The default locations are always in subdirectories of %systemroot%.
The Paths ADDSDeployment cmdlet arguments are:
-logpath <string>
The Review Options page enables you to validate your settings and ensure they meet your requirements before
you start the installation. This is not the last opportunity to stop the installation when using Server Manager. This is
simply an option to confirm your settings before continuing the configuration
example:
#
#
Install-ADDSDomain `
-NoGlobalCatalog:$false `
-DomainMode "Win2012" `
-DomainType "ChildDomain" `
-InstallDNS:$true `
-NewDomainName "research" `
-NewDomainNetBIOSName "RESEARCH" `
-ParentDomainName "corp.contoso.com" `
-Norebootoncompletion:$false `
-Force:$true
NOTE
safemodeadministratorpassword argument (which is deliberately omitted from the script). To force a confirmation prompt,
omit the value when running cmdlet interactively.
Use the optional Whatif argument with the Install-ADDSForest cmdlet to review configuration information. This
enables you to see the explicit and implicit values of the arguments for a cmdlet.
Prerequisites Check
server configuration is capable of supporting a new AD DS domain.
systems.
For more information on the specific prerequisite checks, see Prerequisite Checking.
-skipprechecks
WARNING
DS forest.
promotion, regardless of the promotion results.
Installation
To install a new Active Directory domain using the ADDSDeployment module, use the following cmdlet:
Install-addsdomain
See Child and Tree Domain Windows PowerShell for required and optional arguments.The Install-addsdomain
cmdlet only has two phases (prerequisite checking and installation). The two figures below show the installation
phase with the minimum required arguments of -domaintype, -newdomainname, -parentdomainname, and -
credential. Note how, just like Server Manager, Install-ADDSDomain reminds you that promotion will reboot
the server automatically.
WARNING
Overriding the reboot is not recommended. The domain controller must reboot to function correctly
Results
Install a Windows Server 2012 Active Directory Read-
Only Domain Controller (RODC) (Level 200)
This topic explains how to create a staged RODC account and then attach a server to that account during RODC
installation. This topic also explains how to install an RODC without performing a staged installation.
Stage RODC Workflow

A staged read only domain controller (RODC ) installation works in two discrete phases:
1. Staging an unoccupied computer account
2. Attaching an RODC to that account during promotion
The following diagram illustrates the Active Directory Domain Services Read-Only Domain Controller staging
process, where you create an empty RODC computer account in the domain using the Active Directory
Administrative Center (Dsac.exe).
Stage RODC Windows PowerShell

Add-addsreadonlydomaincontrolleraccount -SkipPreChecks
-DomainControllerAccountName
-DomainName
-SiteName
-AllowPasswordReplicationAccountName
-Credential
-DelegatedAdministratorAccountName
-NoGlobalCatalog
-InstallDNS
NOTE
The -credential argument is only required if you are not already logged on as a member of the Domain Admins group.
Attach RODC Workflow

The diagram below illustrates the Active Directory Domain Services configuration process, where you already
installed the AD DS role, you staged the RODC account, and started Promote this Server to a Domain
Controller using Server Manager to create a new RODC in an existing domain, attaching it to the staged computer
account.
Attach RODC Windows PowerShell

Install-AddsDomaincontroller -SkipPreChecks
-DomainName
-Credential
-DatabasePath
-LogPath
-SystemKey
-SYSVOLPath
-UseExistingAccount
NOTE
Staging
You perform the staging operation of a read-only domain controller computer account by opening the Active
Directory Administrative Center (Dsac.exe). Click the name of the domain in the navigation pane. Double-click
Domain Controllers in the management list. Click Pre-create a Read-only domain controller account in the
tasks pane.
For more information about the Active Directory Administrative Center, see Advanced AD DS Management Using
Active Directory Administrative Center (Level 200) and review Active Directory Administrative Center: Getting
Started.
If you have experience creating read-only domain controllers, you will discover that the installation wizard has the
same graphical interface as seen when using the older Active Directory Users and Computers snap-in from
Windows Server 2008 and uses the same code, which includes exporting the configuration in the unattend file
format used by the obsolete dcpromo.
Windows Server 2012 introduces a new ADDSDeployment cmdlet to stage RODC computer accounts, but the
wizard does not use the cmdlet for its operation. The following sections display the equivalent cmdlet and
arguments in order to make the information associated with each easier to understand.
The Pre-create a Read-only domain controller account link in the Active Directory Administrative Center's task
pane is equivalent to the ADDSDeployment Windows PowerShell cmdlet:
Add-addsreadonlydomaincontrolleraccount
Welcome
The Welcome to the Active Directory Domain Services Installation Wizard dialog has one option named
Use advanced mode installation. Select this option and click Next to show password replication policy options.
Clear this option to use the default values for password replication policy options (this is discussed in further detail
later in this section).
Network Credentials
The domain name option in the Network Credentials dialog displays the domain targeted by the Active Directory
Administrative Center by default. Your current credentials are used by default. If they do not include membership in
the Domain Admins group, click Alternate Credentials, and click Set to provide the wizard with a user name and
password that is a member of Domain Admins.
The equivalent ADDSDeployment Windows PowerShell argument is:
Keep in mind that the staging system is a direct port from Windows Server 2008 R2 and does not provide the new
Adprep functionality. If you plan to deploy staged RODC accounts, you must either first deploy an un-staged RODC
in that domain so that the automatic rodcprep operation runs, or manually run adprep.exe /rodcprep first.
Otherwise, you will receive error "You will not be able to install a read-only domain controller in this domain
because "adprep /rodcprep" was not yet run".
Specify the Computer Name

The Specify the Computer Name dialog requires you to enter the single-label Computer name of a domain
controller that does not exist. The domain controller you configure and attach to this account later must have the
same name, or the promotion operation will not detect the staged account.
-domaincontrolleraccountname <string>
Select a Site
The Select a Site dialog shows a list of Active Directory sites for the current forest. The staged read-only domain
controller operation requires you to select a single site from the list. The RODC uses this information to create its
NTDS Settings object in the Configuration partition and join itself to the correct site when it starts for the first time
after being deployed.
-sitename <string>
Additional Domain Controller Options

The Additional Domain Controller Options dialog enables you to specify that a domain controller include
running as a DNS Server and a Global Catalog. Microsoft recommends that read-only domain controllers
provide DNS and GC services, so both are installed by default; one intention of the RODC role is branch office
scenarios where the wide area network may not be available and without those DNS and global catalog services,
computers in the branch will not be able to use AD DS resources and functionality.
The Read-only domain controller (RODC ) option is pre-selected and cannot be disabled. The equivalent
ADDSDeployment Windows PowerShell arguments are:
-installdns <string>
-NoGlobalCatalog <{$true | $false}>
NOTE
By default, the -NoGlobalCatalog value is $false, which means the domain controller will be a global catalog server if the
argument is not specified.
Specify the Password Replication Policy

The Specify the Password Replication Policy dialog enables you to modify the default list of accounts that are
allowed to cache their passwords on this read-only domain controller. Accounts in the list configured with Deny or
that are not in the list (implicit) do not cache their password. Accounts that are not allowed to cache passwords on
the RODC and cannot connect and authenticate to a writable domain controller cannot access resources or
functionality provided by Active Directory.
IMPORTANT
The wizard shows this dialog only if you select the Use Advanced Mode Installation check box on the welcome screen. If
you clear this check box, then the wizard uses following default groups and values:
Administrators - Deny
Server Operators - Deny
Backup Operators - Deny
Account Operators - Deny
Denied RODC Password Replication Group - Deny
Allowed RODC Password Replication Group - Allow
The equivalent ADDSDeployment Windows PowerShell arguments are:
-allowpasswordreplicationaccountname <string []>

-denypasswordreplicationaccountname <string []>
Delegation of RODC Installation and Administration
The Delegation of RODC Installation and Administration dialog enables you to configure a user or group
containing users who are allowed to attach the server to the RODC computer account. Click Set to browse the
domain for a user or group. The user or group specified in this dialog gains local administrative permissions to the
RODC. The specified user or members of the specified group can perform operations on the RODC with privileges
equivalent to the computer's Administrators group. They are not members of the Domain Admins or domain built-
in Administrators groups.
Use this option to delegate branch office administration without granting the branch administrator membership to
the Domain Admins group. Delegating RODC administration is not required.
-delegatedadministratoraccountname <string>
Summary
The Summary dialog enables you to confirm your settings. This is the last opportunity to stop the installation
before the wizard creates the staged account. Click Next when you are ready to create the staged RODC computer
account. Click Export Settings to save an answer file in the obsolete dcpromo unattend file format.
Creation
The Active Directory Domain Services Installation Wizard creates the staged read-only domain controller in
Active Directory. You cannot cancel this operation after it starts.
Use the following cmdlet to stage a read-only domain controller computer account using the ADDSDeployment
Windows PowerShell module:
Add-addsreadonlydomaincontrolleraccount
See Stage RODC Windows PowerShell for required and optional arguments.
Because Add-addsreadonlydomaincontrolleraccount only has one action with two phases (prerequisite
checking and installation), the following screen shots show the installation phase with the minimum required
arguments.
The stage RODC operation creates the RODC computer account in Active Directory. The Active Directory
Administrative Center shows the Domain Controller Type as an Unoccupied Domain Controller Account.
This domain controller types indicates that staged RODC account is ready for a server to attach to it as a read only
domain controller.
IMPORTANT
The Active Directory Administrative Center is no longer required to attach a server to a read-only domain controller computer
account. Use Server Manager and the Active Directory Domain Services Configuration Wizard or the ADDSDeployment
Windows PowerShell module cmdlet Install-AddsDomainController to attach a new RODC to its staged account. The steps
are similar to adding a new writable domain controller to an existing domain, with the exception that the staged RODC
computer account contains configuration options decided at the time you staged the RODC computer account.
Attaching
To add a read-only domain controller to an existing domain, select Add a domain controller to an existing
domain and click the Select button to Specify the domain information for this domain. Server Manager
automatically prompts you for valid credentials, or you can click Change.
Attaching an RODC requires membership in the Domain Admins groups in Windows Server 2012. The Active
Directory Domain Services Configuration Wizard prompts you later if your current credentials do not have
adequate permissions or group memberships.
The Deployment Configuration ADDSDeployment Windows PowerShell cmdlet and arguments are:
The Domain Controller Options page shows the domain controller options for the new domain controller. When
this page loads, the Active Directory Domain Services Configuration Wizard sends an LDAP query to an existing
domain controller to check for unoccupied accounts. If the query finds an unoccupied domain controller computer
account that shares the same name as the current computer, then the wizard displays an informational message at
the top of the page that reads "A Pre-created RODC account that matches the name of the target server
exists in the directory. Choose whether to use this existing RODC account or reinstall this domain
controller." The wizard uses the Use existing RODC account as the default configuration.
IMPORTANT
You can use the Reinstall this domain controller option when a domain controller has suffered a physical problem and
cannot return to functionality. This saves time when configuring the replacement domain controller, by leaving the domain
controller computer account and object metadata in Active Directory. Install the new computer with the same name, and
promote it as a domain controller in the domain. The Reinstall this domain controller option is unavailable if you removed
the domain controller object's metadata from Active Directory (metadata cleanup).
You cannot configure domain controller options when you are attaching a server to an RODC computer account.
You configure domain controller options when you create the staged RODC computer account.
The Domain Controller Options ADDSDeployment Windows PowerShell arguments are:
-UseExistingAccount <{$true | $false}>

IMPORTANT
does not create site names. You can use cmdlet new-adreplicationsite to create new sites.
The Install-ADDSDomainController arguments follow the same defaults as Server Manager if not specified.
For example, to create a new RODC in the corp.contoso.com and be prompted to enter and confirm a
masked password:
Install-ADDSDomainController -DomainName corp.contoso.com -credential (get-credential)
secure string:
WARNING
$file = "c:\pw.txt"

WARNING
Additional Options
The Additional Options page provides configuration options to name a domain controller as the replication
R2 or previous operating system to create media for a Windows Server 2012 domain controller. For more
information about changes in IFM, see Ntdsutil.exe Install from Media Changes. If using media protected with a
SYSKEY, Server Manager prompts for the image's password during verification.
-systemkey <secure string>
Paths
transaction logs, and the SYSVOL share. The default locations are always in subdirectories of %systemroot%. The
Paths ADDSDeployment cmdlet arguments are:
-logpath <string>

page simply enables you to review and confirm your settings before continuing the configuration. The Review
Options page in Server Manager also offers an optional View Script button to create a Unicode text file that
contains the current ADDSDeployment configuration as a single Windows PowerShell script. This enables you to
use the Server Manager graphical interface as a Windows PowerShell deployment studio. Use the Active Directory
Domain Services Configuration Wizard to configure options, export the configuration, and then cancel the wizard.
This process creates a valid and syntactically correct sample for further modification or direct use. For example:
#
#
-SYSVOLPath "C:\Windows\SYSVOL" `
-UseExistingAccount:$true `
-Norebootoncompletion:$false
-Force:$true
NOTE
safemodeadministratorpassword argument. To force a confirmation prompt omit the value when running cmdlet
interactively
Use the optional Whatif argument with the Install-ADDSDomainController cmdlet to review configuration
information. This enables you to see the explicit and implicit values of the arguments for a cmdlet.
Prerequisites Check
the tests as many times as required. The domain controller installation process cannot continue until all prerequisite
tests pass.
systems. For more information about the prerequisite checks, see Prerequisite Checking.
-skipprechecks
WARNING
DS forest.
Installation
See Attach RODC Windows PowerShell for required and optional arguments.
The Install-addsdomaincontroller cmdlet only has two phases (prerequisite checking and installation). The two
figures below show the installation phase with the minimum required arguments of -domainname, -
useexistingaccount, and -credential. Note how, just like Server Manager, Install-ADDSDomainController
reminds you that promotion will reboot the server automatically:
WARNING
Results
RODC without Staging Workflow

The following diagram illustrates the Active Directory Domain Services configuration process, when you previously
Server Manager to create a new non-staged read-only domain controller in an existing Windows Server 2012
domain.
RODC without Staging Windows PowerShell

Install-AddsDomainController -SkipPreChecks
-DomainName
-SiteName
-Credential
-DatabasePath
-DNSOnNetwork
-InstallDNS
-LogPath
-MoveInfrastructureOperationMasterRoleIfNecessary
-NoGlobalCatalog
-SystemKey
-SYSVOLPath
-AllowPasswordReplicationAccountName
-DelegatedAdministratorAccountName
-ReadOnlyReplica
NOTE
RODC without Staging Deployment

To add an un-staged read-only domain controller to an existing Windows Server 2012 domain, select Add a
domain controller to an existing domain and click the Select button to Specify the domain information for
this domain. Server Manager automatically prompts you for valid credentials, or you can click Change.
Attaching an RODC requires membership in the Domain Admins groups in Windows Server 2012. The Active
Directory Domain Services Configuration Wizard prompts you later if your current credentials do not have
adequate permissions or group memberships.
The Deployment Configuration ADDSDeployment Windows PowerShell cmdlet and arguments are:

The Domain Controller Options page specifies the domain controller capabilities for the new domain controller.
The configurable domain controller capabilities are DNS server, Global Catalog, and Read-only domain
controller. Microsoft recommends that all domain controllers provide DNS and GC services for high availability in
distributed environments. GC is always selected by default and DNS server is selected by default if the current
domain hosts DNS already on its DCs based on Start of Authority query.
The Domain Controller Options page also enables you to choose the appropriate Active Directory logical site
name from the forest configuration. By default, it selects the site with the most correct subnet. If there is only one
site, it selects that site automatically.
IMPORTANT
server. Always choose a strong, complex password or preferably, a passphrase.The Domain Controller Options
ADDSDeployment Windows PowerShell arguments are:
-UseExistingAccount <{$true | $false}>

IMPORTANT
does not create site names. You can use cmdlet new-adreplicationsite to create new sites.
The Install-ADDSDomainController arguments follow the same defaults as Server Manager if not specified.
For example, to create a new RODC in the corp.contoso.com and be prompted to enter and confirm a
masked password:
Install-ADDSDomainController -DomainName corp.contoso.com -credential (get-credential)
secure string:
WARNING
$file = "c:\pw.txt"
WARNING
RODC Options
The RODC Options page enables you to modify the settings:
Delegated Administrator Account
Accounts that are allowed to replicate passwords to the RODC
Accounts that are denied from replicating passwords to the RODC
Delegated administrator accounts gain local administrative permissions to the RODC. These users can operate with
privileges equivalent to the local computer's Administrators group. They are not members of the Domain Admins
or the domain built-in Administrators groups. This option is useful for delegating branch office administration
without giving out domain administrative permissions. Configuring delegation of administration is not required.
-delegatedadministratoraccountname <string>
Accounts that are not allowed to cache passwords on the RODC and cannot connect and authenticate to a writable
domain controller cannot access resources or functionality provided by Active Directory.
IMPORTANT
If not modified, the default groups and settings are used:
Administrators - Deny
Server Operators - Deny
Backup Operators - Deny
Account Operators - Deny
Denied RODC Password Replication Group - Deny
Allowed RODC Password Replication Group - Allow

-allowpasswordreplicationaccountname <string []>
-denypasswordreplicationaccountname <string []>
Additional Options
The Additional Options page provides configuration options to name a domain controller as the replication
R2 or previous operating system to create media for a Windows Server 2012 domain controller. The Appendices
provides more information on changes in IFM. If using media protected with a SYSKEY, Server Manager prompts
for the image's password during verification.
-systemkey <secure string>
Paths
transaction logs, and the SYSVOL share. The default locations are always in subdirectories of %systemroot%. The
Paths ADDSDeployment cmdlet arguments are:
-logpath <string>
Preparation Options
The Preparation Options page alerts you that the AD DS configuration includes extending the Schema
(forestprep) and updating the domain (domainprep). You only see this page when the forest or domain has not
been prepared by previous Windows Server 2012 domain controller installation or from manually running
Adprep.exe. For example, the Active Directory Domain Services Configuration Wizard suppresses this page if you
add a new replica domain controller to an existing Windows Server 2012 forest root domain.
Extending the Schema and updating the domain do not occur when you click Next. These events occur only during
the installation phase. This page simply brings awareness about the events that will occur later in the installation.
This page also validates that the current user credentials are members of the Schema Admin and Enterprise
Admins groups, as you need membership in these groups to extend the schema or prepare a domain. Click
Change to provide the adequate user credentials if the page informs you that the current credentials do not
provide sufficient permissions.
-adprepcredential <pscredential>
IMPORTANT
As with previous versions of Windows Server, Windows Server 2012's automated domain preparation does not run GPPREP.
Run adprep.exe /gpprep manually for all domains that were not previously prepared for Windows Server 2003, Windows
Server 2008, or Windows Server 2008 R2. You should run GPPrep only once in the history of a domain, not with every
upgrade. Adprep.exe does not run /gpprep automatically because its operation can cause all files and folders in the SYSVOL
folder to re-replicate on all domain controllers.
Automatic RODCPrep runs when you promote the first un-staged RODC in a domain. It does not occur when you promote
the first writeable Windows Server 2012 domain controller. You can also still manually run adprep.exe /rodcprep if you plan
to deploy read-only domain controllers.

page simply enables you to review and confirm your settings before continuing the configuration.
example:
#
#
-AllowPasswordReplicationAccountName @("CORP\Allowed RODC Password Replication Group", "CORP\Chicago RODC
Admins", "CORP\Chicago RODC Users and Computers") `
-DelegatedAdministratorAccountName "CORP\Chicago RODC Admins" `
-DenyPasswordReplicationAccountName @("BUILTIN\Administrators", "BUILTIN\Server Operators", "BUILTIN\Backup
Operators", "BUILTIN\Account Operators", "CORP\Denied RODC Password Replication Group") `
-InstallDNS:$true `
-ReadOnlyReplica:$true `
-Force:$true
NOTE
safemodeadministratorpassword argument. To force a confirmation prompt, omit the value when running cmdlet
interactively.
Use the optional Whatif argument with the Install-ADDSDomainController cmdlet to review configuration
information. This enables you to see the explicit and implicit values of the arguments for a cmdlet.
Prerequisites Check
systems.
-skipprechecks
Installation
See the ADDSDeployment Cmdlet table at the begininng of this section for required and optional arguments.
The Install-addsdomaincontroller cmdlet only has two phases (prerequisite checking and installation). The two
figures below show the installation phase with the minimum required arguments of -domainname, -
readonlyreplica, -sitename, and -credential. Note how, just like Server Manager, Install-
ADDSDomainController reminds you that promotion will reboot the server automatically:
WARNING
Overriding the reboot is not recommended. The domain controller must reboot to function correctly. If you log off the
domain controller, you cannot log back on interactively until you restart it.
Results
Demoting Domain Controllers and Domains
This topic explains how to remove AD DS, using Server Manager or Windows PowerShell.
AD DS removal workflow
Cau t i on
Removing the AD DS roles with Dism.exe or the Windows PowerShell DISM module after promotion to a Domain
Controller is not supported and will prevent the server from booting normally.
Unlike Server Manager or the ADDSDeployment module for Windows PowerShell, DISM is a native servicing
system that has no inherent knowledge of AD DS or its configuration. Do not use Dism.exe or the Windows
PowerShell DISM module to uninstall the AD DS role unless the server is no longer a domain controller.
Demotion and role removal with PowerShell
ADDSDeployment and ServerManager Cmdlets Arguments (Bold arguments are required. Italicized
Uninstall-AddsDomainController -SkipPreChecks
-LocalAdministratorPassword
-Confirm
-Credential
-DemoteOperationMasterRole
-DNSDelegationRemovalCredential
-Force
-ForceRemoval
-IgnoreLastDCInDomainMismatch
-IgnoreLastDNSServerForZone
-LastDomainControllerInDomain
-RemoveApplicationPartitions
-RemoveDNSDelegation
-RetainDCMetadata
Uninstall-WindowsFeature/Remove-WindowsFeature -Name
-IncludeManagementTools
-Restart
-Remove
-Force
-ComputerName
-Credential
-LogPath
-Vhd
NOTE
The -credential argument is only required if you are not already logged on as a member of the Enterprise Admins group
(demoting last DC in a domain) or the Domain Admins group (demoting a replica DC).The -includemanagementtools
argument is only required if you want to remove all of the AD DS management utilities.
Demote
Remove Roles and Features
Server Manager offers two interfaces to removing the Active Directory Domain Services role:
The Manage menu on the main dashboard, using Remove Roles and Features
Click AD DS or All Servers on the navigation pane. Scroll down to the Roles and Features section. Right-
click Active Directory Domain Services in the Roles and Features list and click Remove Role or
Feature. This interface skips the Server Selection page.
The ServerManager cmdlets Uninstall-WindowsFeature and Remove-WindowsFeature will prevent you from
removing the AD DS role until you demote the domain controller.
Server Selection
The Server Selection dialog enables you to choose from one of the servers previously added to the pool, as long
as it is accessible. The local server running Server Manager is always automatically available.
Server Roles and Features
Clear the Active Directory Domain Services check box to demote a domain controller; if the server is currently a
domain controller, this does not remove the AD DS role and instead switches to a Validation Results dialog with
the offer to demote. Otherwise, it simply removes the binaries like any other role feature.
Do not remove any other AD DS -related roles or features - such as DNS, GPMC, or the RSAT tools - if you
intend to promote the domain controller again immediately. Removing additional roles and feature increases the
time to re-promote, as Server Manager reinstalls these features when you reinstall the role.
Remove unneeded AD DS roles and features at your own discretion if you intend to demote the domain
controller permanently. This requires clearing the check boxes for those roles and features.
The full list of AD DS -related roles and features include:
Active Directory Module for Windows PowerShell feature
AD DS and AD LDS Tools feature
Active Directory Administrative Center feature
AD DS Snap-ins and Command-line Tools feature
DNS Server
Group Policy Management Console
The equivalent ADDSDeployment and ServerManager Windows PowerShell cmdlets are:
Uninstall-addsdomaincontroller
Uninstall-windowsfeature
Credentials
You configure demotion options on the Credentials page. Provide the credentials necessary to perform the
demotion from the following list:
Demoting an additional domain controller requires Domain Admin credentials. Selecting Force the
removal of this domain controller demotes the domain controller without removing the domain
controller object's metadata from Active Directory.
WARNING
Do not select this option unless the domain controller cannot contact other domain controllers and there is no
reasonable way to resolve that network issue. Forced demotion leaves orphaned metadata in Active Directory on the
remaining domain controllers in the forest. In addition, all un-replicated changes on that domain controller, such as
passwords or new user accounts, are lost forever. Orphaned metadata is the root cause in a significant percentage of
Microsoft Customer Support cases for AD DS, Exchange, SQL, and other software.
If you forcibly demote a domain controller, you must manually perform metadata cleanup immediately. For steps,
review Clean Up Server Metadata.
Demoting the last domain controller in a domain requires Enterprise Admins group membership, as this
removes the domain itself (if the last domain in the forest, this removes the forest). Server Manager informs
you if the current domain controller is the last domain controller in the domain. Select the Last domain
controller in the domain check box to confirm the domain controller is the last domain controller in the
domain.
-forceremoval <{ $true | false }>
-lastdomaincontrollerindomain <{ $true | false }>
Warnings
The Warnings page alerts you to the possible consequences of removing this domain controller. To continue, you
must select Proceed with removal.
WARNING
If you previously selected Force the removal of this domain controller on the Credentials page, then the Warnings page
shows all Flexible Single Master Operations roles hosted by this domain controller. You must seize the roles from another
domain controller immediately after demoting this server. For more information on seizing FSMO roles, see Seize the
Operations Master Role.
This page does not have an equivalent ADDSDeployment Windows PowerShell argument.
Removal Options
The Removal Options page appears depending on previously selecting Last domain controller in the domain
on the Credentials page. This page enables you to configure additional removal options. Select Ignore last DNS
server for zone, Remove application partitions, and Remove DNS Delegation to expose the Next button.
The options only appear if applicable to this domain controller. For instance, if there is no DNS delegation for this
server then that checkbox will not display.
Click Change to specify alternate DNS administrative credentials. Click View Partitions to view additional
partitions the wizard removes during the demotion. By default, the only additional partitions are Domain DNS and
Forest DNS Zones. All other partitions are non-Windows partitions.
The equivalent ADDSDeployment cmdlet arguments are:
-ignorelastdnsserverforzone <{ $true | false }>

-removeapplicationpartitions <{ $true | false }>
-removednsdelegation <{ $true | false }>
-dnsdelegationremovalcredential <pscredential>
New Administrator Password
The New Administrator Password page requires you to provide a password for the built-in local computer's
Administrator account, once the demotion completes and the computer becomes a domain member server or
workgroup computer.
The Uninstall-ADDSDomainController cmdlet and arguments follow the same defaults as Server Manager if
not specified.
The LocalAdministratorPassword argument is special:
If not specified as an argument, then the cmdlet prompts you to enter and confirm a masked password. This is
the preferred usage when running the cmdlet interactively.
If specified with a value, then the value must be a secure string. This is not the preferred usage when running
the cmdlet interactively.
secure string.
-localadministratorpassword (read-host -prompt "Password:" -assecurestring)
WARNING
As the previous two options do not confirm the password, use extreme caution: the password is not visible.
You can also provide a secure string as a converted clear-text variable, although this is highly discouraged. For
example:
-localadministratorpassword (convertto-securestring "Password1" -asplaintext -force)
WARNING
Providing or storing a clear text password is not recommended. Anyone running this command in a script or looking over
your shoulder knows the local administrator password of that computer. With that knowledge, they have access to all of its
data and can impersonate the server itself.
Confirmation
The Confirmation page shows the planned demotion; the page does not list demotion configuration options. This
is the last page the wizard shows before the demotion begins. The View Script button creates a Windows
PowerShell demotion script.
Click Demote to run the following AD DS Deployment cmdlet:
Uninstall-DomainController
Use the optional Whatif argument with the Uninstall-ADDSDomainController and cmdlet to review
configuration information. This enables you to see the explicit and implicit values of a cmdlet's arguments.
For example:
The prompt to restart is your last opportunity to cancel this operation when using ADDSDeployment Windows
PowerShell. To override that prompt, use the -force or confirm:$false arguments.
Demotion
When the Demotion page displays, the domain controller configuration begins and cannot be halted or canceled.
Detailed operations display on this page and write to logs:
Since Uninstall-AddsDomainController and Uninstall-WindowsFeature only have one action apiece, they are
shown here in the Confirmation phase with the minimum required arguments. Pressing ENTER starts the
irrevocable demotion process and restarts the computer.
promotion, use the -norebootoncompletion:$false argument.
WARNING
Overriding the reboot is discouraged. The member server must reboot to function correctly.
Here is an example of forcibly demoting with its minimal required arguments of -forceremoval and -
demoteoperationmasterrole. The -credential argument is not required because the user logged on as a
member of the Enterprise Admins group:
Here is an example of removing the last domain controller in the domain with its minimal required arguments of -
lastdomaincontrollerindomain and -removeapplicationpartitions:
If you attempt to remove the AD DS role before demoting the server, Windows PowerShell blocks you with an
error:
IMPORTANT
You must restart the computer after demoting the server before you can remove the AD-Domain-Services role binaries.
Results
Clean up Active Directory Domain Controller server
metadata

Metadata cleanup is a required procedure after a forced removal of Active Directory Domain Services (AD DS ).
You perform metadata cleanup on a domain controller in the domain of the domain controller that you forcibly
removed. Metadata cleanup removes data from AD DS that identifies a domain controller to the replication system.
Metadata cleanup also removes File Replication Service (FRS ) and Distributed File System (DFS ) Replication
connections and attempts to transfer or seize any operations master (also known as flexible single master
operations or FSMO ) roles that the retired domain controller holds.
There are three options to clean up server metadata:
Clean up server metadata by using GUI tools
Clean up server metadata using the command line
Clean up server metadata by using a script
NOTE
If you receive an “Access is denied” error when you use any of these methods to perform metadata cleanup, make sure that
the computer object and the NTDS Settings object for the domain controller are not protected against accidental deletion. To
verify this right-click the computer object or the NTDS Settings object, click Properties, click Object, and clear the Protect
object from accidental deletion check box. In Active Directory Users and Computers, the Object tab of an object appears
if you click View and then click Advanced Features.
Clean up server metadata using GUI tools

When you use Remote Server Administration Tools (RSAT) or the Active Directory Users and Computers console
(Dsa.msc) that is included with Windows Server to delete a domain controller computer account from the Domain
Controllers organizational unit (OU ), the cleanup of server metadata is performed automatically. Previos to
Windows Server 2008 you had to perform a separate metadata cleanup procedure.
You can also use the Active Directory Sites and Services console (Dssite.msc) to delete a domain controller’s
computer account, which also completes metadata cleanup automatically. However, Active Directory Sites and
Services removes the metadata automatically only when you first delete the NTDS Settings object below the
computer account in Dssite.msc.
As long as you are using the Windows Server 2008 or newer RSAT versions of Dsa.msc or Dssite.msc, you can
clean up metadata automatically for domain controllers running earlier versions of Windows operating systems.
Membership in Domain Admins, or equivalent, is the minimum required to complete these procedures.
Clean up server metadata using Active Directory Users and Computers

1. Open Active Directory Users and Computers.
2. If you have identified replication partners in preparation for this procedure and if you are not connected to a
replication partner of the removed domain controller whose metadata you are cleaning up, right-click Active
Directory Users and Computers node, and then click Change Domain Controller. Click the name of the
domain controller from which you want to remove the metadata, and then click OK.
3. Expand the domain of the domain controller that was forcibly removed, and then click Domain Controllers.
4. In the details pane, right-click the computer object of the domain controller whose metadata you want to clean
up, and then click Delete.
5. In the Active Directory Domain Services dialog box, confirm the name of the domain controller you wish to
delete is shown, and click Yes to confirm the computer object deletion.
6. In the Deleting Domain Controller dialog box, select This Domain Controller is permanently offline and
can no longer be demoted using the Active Directory Domain Services Installation Wizard
(DCPROMO ), and then click Delete.
7. If the domain controller is a global catalog server, in the Delete Domain Controller dialog box, click Yes to
continue with the deletion.
8. If the domain controller currently holds one or more operations master roles, click OK to move the role or roles
to the domain controller that is shown. You cannot change this domain controller. If you want to move the role
to a different domain controller, you must move the role after you complete the server metadata cleanup
procedure.
Clean up server metadata using Active Directory Sites and Services

1. Open Active Directory Sites and Services.
2. If you have identified replication partners in preparation for this procedure and if you are not connected to a
replication partner of the removed domain controller whose metadata you are cleaning up, right-click Active
Directory Sites and Services, and then click Change Domain Controller. Click the name of the domain
controller from which you want to remove the metadata, and then click OK.
3. Expand the site of the domain controller that was forcibly removed, expand Servers, expand the name of the
domain controller, right-click the NTDS Settings object, and then click Delete.
4. In the Active Directory Sites and Services dialog box, click Yes to confirm the NTDS Settings deletion.
5. In the Deleting Domain Controller dialog box, select This Domain Controller is permanently offline and
can no longer be demoted using the Active Directory Domain Services Installation Wizard
(DCPROMO ), and then click Delete.
6. If the domain controller is a global catalog server, in the Delete Domain Controller dialog box, click Yes to
continue with the deletion.
7. If the domain controller currently holds one or more operations master roles, click OK to move the role or roles
to the domain controller that is shown.
8. Right-click the domain controller that was forcibly removed, and then click Delete.
9. In the Active Directory Domain Services dialog box, click Yes to confirm the domain controller deletion.
Clean up server metadata using the command line

As an alternative, you can clean up metadata by using Ntdsutil.exe, a command-line tool that is installed
automatically on all domain controllers and servers that have Active Directory Lightweight Directory Services (AD
LDS ) installed. Ntdsutil.exe is also available on computers that have RSAT installed.
To clean up server metadata by using Ntdsutil

1. Open a command prompt as an administrator: On the Start menu, right-click Command Prompt, and then
click Run as administrator. If the User Account Control dialog box appears, provide credentials of an
Enterprise Administrator if required, and then click Continue.
2. At the command prompt, type the following command, and then press ENTER:
ntdsutil
3. At the ntdsutil: prompt, type the following command, and then press ENTER:
metadata cleanup
4. At the metadata cleanup: prompt, type the following command, and then press ENTER:
remove selected server <ServerName>
5. In Server Remove Configuration Dialog, review the information and warning, and then click Yes to
remove the server object and metadata.
At this point, Ntdsutil confirms that the domain controller was removed successfully. If you receive an error
message that indicates that the object cannot be found, the domain controller might have been removed
earlier.
6. At the metadata cleanup: and ntdsutil: prompts, type quit , and then press ENTER.
7. To confirm removal of the domain controller:
Open Active Directory Users and Computers. In the domain of the removed domain controller, click
Domain Controllers. In the details pane, an object for the domain controller that you removed should not
appear.
Open Active Directory Sites and Services. Navigate to the Servers container and confirm that the server
object for the domain controller that you removed does not contain an NTDS Settings object. If no child
objects appear below the server object, you can delete the server object. If a child object appears, do not
delete the server object because another application is using the object.
See Also
Demoting Domain Controllers
Ntdsutil command reference
AD DS Installation and Removal Wizard Page
Descriptions
This topic provides descriptions for the controls on the following wizard pages that comprise the AD DS server role
installation and removal in Server Manager.
DNS Options
RODC Options
Additional Options
Paths
Preparation Options
Review Options
Prerequisites Check
Results
Role Removal credentials
AD DS Removal Options and Warnings
Confirm Role Removal Selections
Server Manager begins every domain controller installation with the Deployment Configuration page. The
operation you select. For example, if you create a new forest, the Preparation Options page does not appear, but it
does if you install the first domain controller that runs Windows Server 2012 in an existing forest or domain.
Some validations tests are performed on this page, and again later as part of prerequisite checks. For example, if
you try to install the first Windows Server 2012 domain controller in a forest that has Windows 2000 functional
level, an error appears on this page.
The following options appear when you create a new forest.
When you create a new forest, you must specify a name for the forest root domain. The forest root domain
name cannot be single-labeled (for example, it must be "contoso.com" instead of "contoso"). It must use
allowed DNS domain naming conventions. You can specify an Internationalized Domain Name (IDN ). For
more information about DNS domain naming conventions, see KB 909264.
Do not create new Active Directory forests with the same name as your external DNS name. For example, if
your Internet DNS URL is http://contoso.com, you must choose a different name for your internal forest to
avoid future compatibility issues. That name should be unique and unlikely for web traffic, such as
corp.contoso.com.
You must be a member of Administrators group on the server where you want to create a new forest.
For more information about how to create a forest, see Install a New Windows Server 2012 Active Directory Forest
(Level 200).
The following options appear when you create a new domain.
NOTE
If you create a new tree domain, you need to specify the name of the forest root domain instead of the parent domain, but
the remaining wizard pages and options are the same.
Click Select to browse to the parent domain or Active Directory tree, or type a valid parent domain or tree
name. Then type the name of the new domain in New domain name.
Tree domain: provide a valid, fully qualified root domain name; the name cannot be single-labeled and must
use DNS domain name requirements.
Child domain: provide a valid, single-label child domain name; the name must use DNS domain name
requirements.
The Active Directory Domain Services Configuration Wizard prompts you for domain credentials if your
current credentials are not from the domain. Click Change to provide domain credentials.
For more information about how to create a domain, see Install a New Windows Server 2012 Active Directory
Child or Tree Domain (Level 200).
The following options appear when you add a new domain controller to an existing domain.
Click Select to browse to the domain, or type a valid domain name.
Server Manager prompts you for valid credentials if needed. Installing an additional domain controller
requires membership in the Domain Admins group.
In addition, installing the first domain controller that runs Windows Server 2012 in a forest requires
credentials that include group memberships in both the Enterprise Admins and Schema Admins groups. The
Active Directory Domain Services Configuration Wizard prompts you later if your current credentials do not
have adequate permissions or group memberships.
For more information about how to add a domain controller to an existing domain, see Install a Replica Windows
Server 2012 Domain Controller in an Existing Domain (Level 200).

If you are creating a new forest, the Domain Controller Options page has these options:
The forest and domain functional levels are set to Windows Server 2012 by default.
There is one new feature available at the Windows Server 2012 domain functional level: the Support for
Dynamic Access Control and Kerberos armoring KDC administrative template policy has two settings
(Always provide claims and Fail unarmored authentication requests) that require Windows Server 2012
domain functional level. For more information, see "Support for claims, compound authentication and
Kerberos armoring" in What's new in Kerberos Authentication.
The Windows Server 2012 forest functional level does not provide any new features, but it ensures that any
new domain created in the forest will automatically operate at the Windows Server 2012 domain functional
level. The Windows Server 2012 domain functional level does not provide any new other features beside
support for Dynamic Access Control and Kerberos armoring, but it ensures that any domain controller in the
domain runs Windows Server 2012 . For more information about other features that are available at
different functional levels, see Understanding Active Directory Domain Services (AD DS ) Functional Levels.
Beyond functional levels, a domain controller that runs Windows Server 2012 provides additional features
that are not available on a domain controller that runs an earlier version of Windows Server. For example, a
domain controller that runs Windows Server 2012 can be used for virtual domain controller cloning,
whereas a domain controller that runs an earlier version of Windows Server cannot.
DNS server is selected by default when you create a new forest. The first domain controller in the forest
must be a global catalog (GC ) server, and it cannot be a read only domain controller (RODC ).
The Directory Services Restore Mode (DSRM ) password is needed in order to log on to a domain controller
where AD DS is not running. The password you specify must adhere to the password policy applied to the
server, which by default does not require a strong password; only a non-blank password. Always choose a
strong, complex password or preferably, a passphrase. For information about how to synchronize the DSRM
password with the password of a domain user account, see KB 961320.
For more information about how to create a forest, see Install a New Windows Server 2012 Active Directory Forest
(Level 200).
If you are creating a child domain, the Domain Controller Options page has these options:
The domain functional level is set to Windows Server 2012 by default. You can specify any other value that is
at least the value of the forest functional level or higher.
The configurable domain controller options include DNS server and Global Catalog; you cannot configure
read-only domain controller as the first domain controller in a new domain.
Microsoft recommends that all domain controllers provide DNS and global catalog services for high
availability in distributed environments, which is why the wizard enables these options by default when
creating a new domain.
The Domain Controller Options page also enables you to choose the appropriate Active Directory logical
site name from the forest configuration. By default, it selects the site with the most correct subnet. If there is
only one site, it selects that site automatically.
IMPORTANT
If the server does not belong to an Active Directory subnet and there is more than one site, nothing is selected and
the Next button is unavailable until you choose a site from the list.
Child or Tree Domain (Level 200).
If you are adding a domain controller to a domain, the Domain Controller Options page has these options:
The configurable domain controller options include DNS server and Global Catalog, and Read-only
domain controller.
Microsoft recommends that all domain controllers provide DNS and global catalog services for high
availability in distributed environments, which is why the wizard enables these options by default. For more
information about deploying RODCs, see Read-Only Domain Controller Planning and Deployment Guide.
For more information about how to add a domain controller to an existing domain, see Install a Replica Windows
Server 2012 Domain Controller in an Existing Domain (Level 200).
DNS Options
If you install DNS server, the following DNS Options page appears:
When you install DNS server, delegation records that point to the DNS server as authoritative for the zone should
be created in the parent Domain Name System (DNS ) zone. Delegation records transfer name resolution authority
and provide correct referral to other DNS servers and clients of the new servers that are being made authoritative
for the new zone. These resource records include the following:
A name server (NS ) resource record to effect the delegation. This resource record advertises that the server
named ns1.na.example.microsoft.com is an authoritative server for the delegated subdomain.
A host (A or AAAA) resource record also known as a glue record must be present to resolve the name of the
server that is specified in the name server (NS ) resource record to its IP address. The process of resolving
the host name in this resource record to the delegated DNS server in the name server (NS ) resource record
is sometimes referred to as "glue chasing."
You can have the Active Directory Domain Services Configuration Wizard create them automatically. The wizard
verifies that the appropriate records exist in the parent DNS zone after you click Next on the Domain Controller
Options page. If the wizard cannot verify that the records exist in the parent domain, the wizard provides you with
the option to create a new DNS delegation for a new domain (or update the existing delegation) automatically and
continue with the new domain controller installation.
Alternatively, you can create these DNS delegation records before you install DNS server. To create a zone
delegation, open DNS Manager, right-click the parent domain, and then click New Delegation. Follow the steps
in the New Delegation Wizard to create the delegation.
The installation process tries to create the delegation to ensure that computers in other domains can resolve DNS
queries for hosts, including domain controllers and member computers, in the DNS subdomain. Note that the
delegation records can be automatically created only on Microsoft DNS servers. If the parent DNS domain zone
resides on third party DNS servers such as BIND, a warning about the failure to create DNS delegation records
appears on the Prerequisites check page. For more information about the warning, see Known issues for installing
AD DS.
Delegations between the parent domain and the subdomain being promoted can be created and validated before
or after the installation. There is no reason to delay the installation of a new domain controller because you cannot
create or update the DNS delegation.
For more information about delegation, see Understanding Zone Delegation (https://go.microsoft.com/fwlink/?
LinkId=164773). If zone delegation is not possible in your situation, you might consider other methods for
providing name resolution from other domains to the hosts in your domain. For example, the DNS administrator of
another domain could configure conditional forwarding, stub-zones, or secondary zones in order to resolve names
in your domain. For more information, see the following topics:
Understanding zone types (https://go.microsoft.com/fwlink/?LinkID=157399)
Understanding stub zones (https://go.microsoft.com/fwlink/?LinkId=164776)
Understanding forwarders (https://go.microsoft.com/fwlink/?LinkId=164778)
RODC Options
The following options appear when you install a read-only domain controller (RODC ).
Delegated administrator accounts gain local administrative permissions to the RODC. These users can
operate with privileges equivalent to the local computer's Administrators group. They are not members of
the Domain Admins or the domain built-in Administrators groups. This option is useful for delegating
branch office administration without giving out domain administrative permissions. Configuring delegation
of administration is not required. For more information, see Administrator Role Separation.
The Password Replication Policy acts as an access control list (ACL ). It determines if an RODC should be
permitted to cache a password. After the RODC receives an authenticated user or computer logon request, it
refers to the Password Replication Policy to determine if the password for the account should be cached. The
same account can then perform subsequent logons more efficiently.
The Password Replication Policy (PRP ) lists the accounts whose passwords are allowed to be cached, and
accounts whose passwords are explicitly denied from being cached. The list of user and computer accounts
that are permitted to be cached does not imply that the RODC has necessarily cached the passwords for
those accounts. An administrator can, for example, specify in advance any accounts that an RODC will cache.
This way, the RODC can authenticate those accounts, even if the WAN link to the hub site is offline.
Any users or computers who are not allowed (including implicit) or denied do not cache their password. If
those users or computers do not have access to a writable domain controller, they cannot access AD DS -
provided resources or functionality. For more information about the PRP, see Password Replication Policy.
For more information about managing the PRP, see Administering the Password Replication Policy.
For more information about installing RODCs, see Install a Windows Server 2012 Active Directory Read-Only
Domain Controller (RODC ) (Level 200).
Additional Options
The following option appears on the Additional Options page if you are creating a new domain:
The following options appear on the Additional Options page if you install an additional domain controller in an
existing domain:
You can either specify a domain controller as the replication source, or allow the wizard to choose any
domain controller as the replication source.
You can also choose to install the domain controller using backed up media using the Install from media
(IFM ) option. If the installation media is stored locally, the Install from media Path option allows you to
browse to the file location. The browse option is not available for a remote installation. You can click Verify
to ensure the provided path is valid media. Media used by the IFM option must be created with Windows
Server Backup or Ntdsutil.exe from another existing Windows Server 2012 computer only; you cannot use a
Windows Server 2008 R2 or previous operating system to create media for a Windows Server 2012 domain
controller. If the media is protected with a SYSKEY, Server Manager prompts for the image's password
during verification.
Child or Tree Domain (Level 200). For more information about how to add a domain controller to an existing
domain, see Install a Replica Windows Server 2012 Domain Controller in an Existing Domain (Level 200).
Paths
The following options appear on the Paths page.
transaction logs, and the SYSVOL share. The default locations are always in %systemroot%.
Specify the location for the AD DS database (NTDS.DIT), log files, and SYSVOL. For a local installation, you can
browse to the location where you want to store the files.
Preparation Options
If you are not currently logged on with sufficient credentials to run adprep.exe commands and adprep is required to
run in order to complete the AD DS installation, you are prompted to supply credentials to run adprep.exe. Adprep
is required to run in order to add the first domain controller that runs Windows Server 2012 to an existing domain
or forest. More specifically:
Adprep /forestprep must be run to add the first domain controller that runs Windows Server 2012 to an
existing forest. This command must be run by a member of the Enterprise Admins group, the Schema
Admins group, and the Domain Admins group of the domain that hosts the schema master. For this
command to complete successfully, there must be connectivity between the computer where you run the
command and the schema master for the forest.
Adprep /domainprep must be run to add the first domain controller that runs Windows Server 2012 to an
existing domain. This command must be run by a member of the Domain Admins group of the domain
where you are installing the domain controller that runs Windows Server 2012 . For this command to
complete successfully, there must be connectivity between the computer where you run the command and
the infrastructure master for the domain.
Adprep /rodcprep must be run to add the first RODC to an existing forest. This command must be run by a
member of the Enterprise Admins group. For this command to complete successfully, there must be
connectivity between the computer where you run the command and the infrastructure master for each
application directory partition in the forest.
For more information about Adprep.exe, see Adprep.exe integration and see Running Adprep.exe.
Review Options
The Review Options page enables you to validate your settings and ensure that they meet your
requirements before you start the installation. This is not the last opportunity to stop the installation using
Server Manager. This page simply enables you to review and confirm your settings before continuing the
configuration.
The Review Options page in Server Manager also offers an optional View Script button to create a
Unicode text file that contains the current ADDSDeployment configuration as a single Windows PowerShell
script. This enables you to use the Server Manager graphical interface as a Windows PowerShell
deployment studio. Use the Active Directory Domain Services Configuration Wizard to configure options,
export the configuration, and then cancel the wizard. This process creates a valid and syntactically correct
sample for further modification or direct use.
Prerequisites Check
Some of the warnings that appear on this page include:
Domain controllers that run Windows Server 2008 or later have a default setting for "Allow cryptography
algorithms compatible with Windows NT 4" that prevents weaker cryptography algorithms when
establishing secure channel sessions. For more information about the potential impact and a workaround,
see KB article 942564.
DNS delegation could not be created or updated. For more information, see DNS Options.
The prerequisite check requires WMI calls. They can fail if they are blocked firewall rules block, and return an
RPC server unavailable error.
For more information about the specific prerequisite checks that are performed for AD DS installation, see
Prerequisite Tests.
Results
On this page, you can review the results of the installation.
You can also select to restart the target server after the wizard completes, but if the installation succeeds, the server
will always restart regardless of whether you select that option. In some cases after the wizard completes on a
target server that was not joined to the domain before the installation, the system state of the target server can
make the server unreachable on the network, or the system state can prevent you from having permissions to
manage the remote server.
If the target server fails to restart in this case, you must manually restart it. Tools such as shutdown.exe or Windows
PowerShell cannot restart it. You can use Remote Desktop Services to log on and remotely shut down the target
server.
Role Removal credentials

You configure demotion options on the Credentials page. Provide the credentials necessary to perform the
demotion from the following list:
Demoting an additional domain controller requires Domain Admin credentials. Selecting Force removal of
the domain controller demotes the domain controller without removing the domain controller object's
metadata from Active Directory.
IMPORTANT
Do not select this option unless the domain controller cannot contact other domain controllers and there is no
reasonable way to resolve that network issue. Forced demotion leaves orphaned metadata in Active Directory on the
remaining domain controllers in the forest. In addition, all un-replicated changes on that domain controller, such as
passwords or new user accounts, are lost forever. Orphaned metadata is the root cause in a significant percentage of
Microsoft Customer Support cases for AD DS, Exchange, SQL, and other software. If you forcibly demote a domain
controller, you must manually perform metadata cleanup immediately. For steps, review Clean Up Server Metadata.
Demoting the last domain controller in a domain requires Enterprise Admins group membership, as this
removes the domain itself (if this is the last domain in the forest, this removes the forest). Server Manager
informs you if the current domain controller is the last domain controller in the domain. Select Last domain
controller in the domain to confirm the domain controller is the last domain controller in the domain.
For more information about removing AD DS, see Remove Active Directory Domain Services (Level 100) and
Demoting Domain Controllers and Domains (Level 200).
AD DS Removal Options and Warnings

If you need help with the Review Options page, see Review Options
If the domain controller hosts additional roles, such as DNS server role or global catalog server, the following
Warning page appears:
You must click Proceed with removal in order to acknowledge that the additional roles will no longer be available
before you can click Next to continue.
If you force the removal of a domain controller, any Active Directory object changes that have not replicated to
other domain controllers in the domain will be lost. Additionally, if the domain controller hosts operation master
roles, the global catalog, or DNS server role, critical operations in the domain and forest may be impacted as
follows. Before you remove a domain controller that hosts any operations master role, try to transfer the role to
another domain controller. If it is not possible to transfer the role, first remove Active Directory Domain Services
from this computer, and then use Ntdsutil.exe to seize the role. Use Ntdsutil on the domain controller that you plan
to seize the role to; if possible, use a recent replication partner in the same site as this domain controller. For more
information about transferring and seizing operations master roles, see article 255504 in the Microsoft Knowledge
Base. If the wizard cannot determine if the domain controller host an operations master role, run netdom.exe
command to determine whether this domain controller performs any operations master roles.
Global catalog: Users might have trouble logging on to domains in the forest. Before you remove a global
catalog server, ensure that enough global catalog servers are in this forest and site to service user logons. If
necessary, designate another global catalog server and update clients and applications with the new
information.
DNS server: All of the DNS data that is stored in Active Directory-integrated zones will be lost. After you
remove AD DS, this DNS server will not be able to perform name resolution for the DNS zones that were
Active Directory-integrated. Therefore, we recommend that you update the DNS configuration of all
computers that currently refer to the IP address of this DNS server for name resolution with the IP address
of a new DNS server.
Infrastructure master: clients in the domain might have difficulty locating objects in other domains. Before
you continue, transfer the infrastructure master role to a domain controller that is not a global catalog server.
RID master: you might have problems creating new user accounts, computer accounts, and security groups.
Before you continue, transfer the RID master role to a domain controller in the same domain as this domain
controller.
Primary domain controller (PDC ) emulator: operations that are performed by the PDC emulator, such as
Group Policy updates and password resets for non-AD DS accounts, will not function properly. Before you
continue, transfer the PDC emulator master role to a domain controller that is in the same domain as this
domain controller.
Schema master: you will no longer be able to modify the schema for this forest. Before you continue,
transfer the schema master role to a domain controller in the root domain in the forest.
Domain naming master: you will no longer be able to add domains to or remove domains from this forest.
Before you continue, transfer the domain naming master role to a domain controller in the root domain in
the forest.
All application directory partitions on this Active Directory domain controller will be removed. If a domain
controller holds the last replica of one or more application directory partitions, when the removal operation
is complete, those partitions will no longer exist.
Be aware that the domain will no longer exist after you uninstall Active Directory Domain Services from the last
domain controller in the domain.
If the domain controller is a DNS server that is delegated to host the DNS zone, the following page will provide the
option to remove the DNS server from the DNS zone delegation.

The New Administrator Password page requires you to provide a password for the built-in local computer's
Administrator account, once the demotion completes and the computer becomes a domain member server or
workgroup computer.
Review Options
The Review Options page provides you the chance to export the configuration settings for demotion to a
Windows PowerShell script so you can automate additional demotions. Click Demote to remove AD DS.
Changes Made by Adprep.exe
This topic describes the changes that Adprep.exe makes in Windows Server 2012 R2 and Windows Server 2012 .
Forest-Wide Updates
Domain-Wide Updates
Schema Updates
See Also
Windows Server 2008 R2: Appendix of Changes to Adprep.exe to Support AD DS
Windows Server 2008: Appendix of Changes to Adprep.exe to Support AD DS
Windows Server Active Directory schema updates
This topic lists the LDF files that include the changes that Adprep.exe makes.
This is the LDF file included in Windows Server 2019:
Sch88.ldf
These are the LDF files included in Windows Server 2016:
Sch58.ldf
Sch59.ldf
Sch60.ldf
Sch61.ldf
Sch62.ldf
Sch63.ldf
Sch64.ldf
Sch65.ldf
Sch66.ldf
Sch67.ldf
Sch68.ldf
Sch69.ldf
Sch70.ldf
Sch71.ldf
Sch72.ldf
Sch73.ldf
Sch74.ldf
Sch75.ldf
Sch76.ldf
Sch77.ldf
Sch78.ldf
Sch79.ldf
Sch80.ldf
Sch81.ldf
Sch82.ldf
Sch83.ldf
Sch84.ldf
Sch85.ldf
Sch86.ldf
Sch87.ldf
These are the LDF files included in Windows Server 2012 R2:
Sch57.ldf
Sch58.ldf
Sch59.ldf
Sch60.ldf
Sch61.ldf
Sch62.ldf
Sch63.ldf
Sch64.ldf
Sch65.ldf
Sch66.ldf
Sch67.ldf
Sch68.ldf
Sch69.ldf
These are the LDF files included in Windows Server 2012:
Sch48.ldf
Sch49.ldf
Sch50.ldf
Sch51.ldf
Sch52.ldf
Sch53.ldf
Sch54.ldf
Sch55.ldf
Sch56.ldf
Schema Update in Windows Server 2019

Sch88.ldf
dn: CN=ms-DS-Preferred-Data-Location,CN=schema,CN=configuration,DC=X
changetype: ntdsSchemaAdd
objectClass: attributeSchema
attributeID: 1.2.840.113556.1.4.2366
attributeSyntax: 2.5.5.12
adminDisplayName: ms-DS-Preferred-Data-Location
adminDescription: ms-DS-Preferred-Data-Location
oMSyntax: 64
lDAPDisplayName: msDS-preferredDataLocation
isSingleValued: TRUE
schemaIDGUID:: 3ooM+pRMEEa6zhgO/e4hQA==
searchFlags: 0
showInAdvancedViewOnly: FALSE
systemFlags: 16
systemOnly: FALSE
rangeLower: 1
rangeUpper: 10
isMemberOfPartialAttributeSet: TRUE
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: ntdsSchemaModify
add: systemMayContain
systemMayContain: 1.2.840.113556.1.4.2366
-
dn: CN=Contact,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Group,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Schema,CN=Configuration,DC=X
changeType: ntdsSchemaModify
replace: objectVersion
objectVersion: 88
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Schema Updates in Windows Server 2016

Sch58.ldf
dn: CN=ms-DS-Resource-Property-List,CN=Schema,CN=Configuration,DC=X
replace: defaultHidingValue
defaultHidingValue: FALSE
-
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 58
-
Sch59.ldf
dn: CN=ms-DS-User-Device-Registration,CN=Schema,CN=Configuration,DC=X
replace: isDefunct
isDefunct: TRUE
-
dn: CN=ms-DS-User-Device-Registration-Container,CN=Schema,CN=Configuration,DC=X
replace: isDefunct
isDefunct: TRUE
-
dn: CN=ms-DS-Device,CN=Schema,CN=Configuration,DC=X
delete: systemMayContain
-
-
dn: CN=ms-DS-User-Device-Registration-Link,CN=Schema,CN=Configuration,DC=X
replace: isDefunct
isDefunct: TRUE
-
dn: CN=ms-DS-User-Device-Registration-Link-BL,CN=Schema,CN=Configuration,DC=X
replace: isDefunct
isDefunct: TRUE
-
dn: CN=ms-DS-Authentication-Level,CN=Schema,CN=Configuration,DC=X
replace: isDefunct
isDefunct: TRUE
-
dn: CN=ms-DS-Approximate-Last-Use-Time-Stamp,CN=Schema,CN=Configuration,DC=X
replace: isDefunct
isDefunct: TRUE
-
-
dn: CN=ms-DS-Device-Reference,CN=Schema,CN=Configuration,DC=X
replace: isDefunct
isDefunct: TRUE
-
dn: CN=ms-DS-Device-Location,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Device-Location
adminDisplayName: ms-DS-Device-Location
adminDescription: The DN under which the device objects will be created.
ldapDisplayName: msDS-DeviceLocation
attributeId: 1.2.840.113556.1.4.2261
omSyntax: 127
omObjectClass:: KwwCh3McAIVK
instanceType: 4
searchFlags: 0
systemOnly: TRUE
schemaIdGuid:: yFb74+hd9UWxsdK2zTHnYg==
showInAdvancedViewOnly: TRUE
systemFlags: 16
dn: CN=ms-DS-Registered-Owner,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Registered-Owner
adminDisplayName: ms-DS-Registered-Owner
adminDescription: Single valued binary attribute containing the primary SID referencing the first user to
register the device. The value is not removed during de-registration, but could be managed by an administrator.
ldapDisplayName: msDS-RegisteredOwner
attributeId: 1.2.840.113556.1.4.2258
omSyntax: 4
instanceType: 4
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: 6SZ2YesBz0KZH85heYIjfg==
systemFlags: 18
dn: CN=ms-DS-Registered-Users,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Registered-Users
adminDisplayName: ms-DS-Registered-Users
adminDescription: Contains the list of users that have registered the device. Users in this list have all of
the features provided by the “Company Portal” app. And they have SSO to company resources.
ldapDisplayName: msDS-RegisteredUsers
attributeId: 1.2.840.113556.1.4.2263
omSyntax: 4
isSingleValued: FALSE
instanceType: 4
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: DBZJBI5ayE+wUgHA9uSPAg==
systemFlags: 18
dn: CN=ms-DS-Approximate-Last-Logon-Time-Stamp,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Approximate-Last-Logon-Time-Stamp
adminDisplayName: ms-DS-Approximate-Last-Logon-Time-Stamp
adminDescription: The approximate time a user last logged on with from the device.
ldapDisplayName: msDS-ApproximateLastLogonTimeStamp
attributeId: 1.2.840.113556.1.4.2262
omSyntax: 65
instanceType: 4
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: O5hPo8aEDE+QUKOhSh01pA==
systemFlags: 16
dn: CN=ms-DS-Device-Object-Version,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Device-Object-Version
adminDisplayName: ms-DS-Device-Object-Version
adminDescription: This attribute is used to identify the schema version of the device.
ldapDisplayName: msDS-DeviceObjectVersion
attributeId: 1.2.840.113556.1.4.2257
omSyntax: 2
instanceType: 4
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: Wmll73nxak6T3rAeBmgc+w==
systemFlags: 18
dn: CN=ms-DS-Device-OS-Type,CN=Schema,CN=Configuration,DC=X
replace: isSingleValued
-
replace: searchFlags
searchFlags: 1
-
dn: CN=ms-DS-Device-OS-Version,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ms-DS-Device-Physical-IDs,CN=Schema,CN=Configuration,DC=X
replace: omSyntax
omSyntax: 64
-
replace: attributeSyntax
-
replace: rangeUpper
rangeUpper: 1024
-
dn:
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-DS-Device-Registration-Service,CN=Schema,CN=Configuration,DC=X
add: systemMustContain
systemMustContain: 1.2.840.113556.1.4.2261
-
-
-
-
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 59
-
Sch60.ldf
dn: CN=ms-DS-Is-Member-Of-DL-Transitive,CN=Schema,CN=Configuration,DC=X
# This constructed attribute transitively expands the
# linked attribute "isMemberOfDL"
changetype: ntdsschemaadd
lDAPDisplayName: msds-memberOfTransitive
adminDisplayName: msds-memberOfTransitive
adminDescription: msds-memberOfTransitive
attributeID: 1.2.840.113556.1.4.2236
oMSyntax: 127
oMObjectClass:: KwwCh3McAIVK
systemOnly: TRUE
# 0x800(only return on base search)
searchFlags: 2048
schemaIdGuid:: tmYhhkHJJ0eVZUi//ylB3g==
# 0x10 (base schema) +
# 0x08 (operational) +
# 0x04 (constructed) +
# 0x01 (not replicated)
systemFlags: 29
dn: CN=ms-DS-Member-Transitive,CN=Schema,CN=Configuration,DC=X
# linked attribute "member"
lDAPDisplayName: msds-memberTransitive
adminDisplayName: msds-memberTransitive
adminDescription: msds-memberTransitive
attributeID: 1.2.840.113556.1.4.2238
oMSyntax: 127
systemOnly: TRUE
searchFlags: 2048
schemaIdGuid:: WzkV4gSR2US4lDmeyeId/A==
systemFlags: 29
dn: CN=ms-DS-Parent-Dist-Name,CN=Schema,CN=Configuration,DC=X
lDAPDisplayName: msDS-parentdistname
adminDisplayName: ms-DS-Parent-Dist-Name
adminDescription: ms-DS-Parent-Dist-Name
attributeID: 1.2.840.113556.1.4.2203
oMSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIDGUID:: ff4YuRqXBPSeIZJhq+yXCw==
systemFlags: 29
dn: CN=ms-DS-Repl-Value-Meta-Data-Ext,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ReplValueMetaDataExt
adminDisplayName: ms-DS-Repl-Value-Meta-Data-Ext
adminDescription: ms-DS-Repl-Value-Meta-Data-Ext
attributeId: 1.2.840.113556.1.4.2235
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 79ICHq1EskamfZ/RjXgLyg==
# 0x04 (constructed)
systemFlags: 20
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: cn=Top,cn=Schema,cn=Configuration,dc=X
changetype: ntdsschemamodify
-
dn: CN=DS-Set-Owner,CN=Extended-Rights,CN=Configuration,DC=X
objectClass: controlAccessRight
displayName: Set Owner of an object during creation.
rightsGuid: 4125c71f-7fac-4ff0-bcb7-f09a41325286
appliesTo: 26f11b08-a29d-4869-99bb-ef0b99fd883e
validAccesses: 256
dn: CN=DS-Bypass-Quota,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Bypass the quota restrictions during creation.
rightsGuid: 88a9933e-e5c8-4f2a-9dd7-2527416b8092
validAccesses: 256
dn: CN=DS-Read-Partition-Secrets,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Read secret attributes of objects in a Partition
rightsGuid: 084c93a2-620d-4879-a836-f0ae47de0e89
validAccesses: 256
dn: CN=DS-Write-Partition-Secrets,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Write secret attributes of objects in a Partition
rightsGuid: 94825A8D-B171-4116-8146-1E34D8F54401
validAccesses: 256
objectVersion: 60
-
Sch61.ldf
dn: CN=ms-DS-Drs-Farm-ID,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Drs-Farm-ID
adminDisplayName: ms-DS-Drs-Farm-ID
adminDescription: This attribute stores the name of the federation service this DRS object is associated with.
ldapDisplayName: msDS-DrsFarmID
attributeId: 1.2.840.113556.1.4.2265
omSyntax: 64
instanceType: 4
searchFlags: 0
systemOnly: TRUE
schemaIdGuid:: ZvdVYC4gzUmovuUrsVnt+w==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
-
objectVersion: 61
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch62.ldf
dn: CN=ms-DS-Issuer-Public-Certificates,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Issuer-Public-Certificates
adminDisplayName: ms-DS-Issuer-Public-Certificates
adminDescription: The public keys of the keys used to sign certificates issued by the Registration Service.
ldapDisplayName: msDS-IssuerPublicCertificates
attributeId: 1.2.840.113556.1.4.2269
omSyntax: 4
instanceType: 4
rangeLower: 1
rangeUpper: 65536
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: /u3xtdK0dkCrD2FINCsL9g==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
-
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 62
-
Sch63.ldf
dn: CN=ms-DS-Issuer-Certificates,CN=Schema,CN=Configuration,DC=X
searchFlags: 128
-
replace: defaultSecurityDescriptor
defaultSecurityDescriptor: D:(A;;RPLCLORC;;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
-
dn: CN=ms-DS-Device-Registration-Service-Container,CN=Schema,CN=Configuration,DC=X
-
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 63
-
Sch64.ldf
defaultSecurityDescriptor: D:(A;;RPLCLORC;;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;EA)
-
-
-
-
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 64
-
Sch65.ldf
dn: CN=ms-DS-Registration-Quota,CN=Schema,CN=Configuration,DC=X
add: showInAdvancedViewOnly
-
dn: CN=ms-DS-Maximum-Registration-Inactivity-Period,CN=Schema,CN=Configuration,DC=X
-
-
-
-
dn: CN=ms-DS-Is-Enabled,CN=Schema,CN=Configuration,DC=X
-
-
-
-
dn: CN=ms-DS-Device-ID,CN=Schema,CN=Configuration,DC=X
-
-
-
dn: CN=ms-DS-IsManaged,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-IsManaged
adminDisplayName: ms-DS-IsManaged
adminDescription: This attribute is used to indicate the device is managed by a on-premises MDM.
ldapDisplayName: msDS-IsManaged
attributeId: 1.2.840.113556.1.4.2270
omSyntax: 1
instanceType: 4
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: zmpoYCds3kOk5fAML40zCQ==
systemFlags: 16
dn: CN=ms-DS-Cloud-IsManaged,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Cloud-IsManaged
adminDisplayName: ms-DS-Cloud-IsManaged
adminDescription: This attribute is used to indicate the device is managed by a cloud MDM.
ldapDisplayName: msDS-CloudIsManaged
attributeId: 1.2.840.113556.1.4.2271
omSyntax: 1
instanceType: 4
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: jroVU4+VUku9OBNJowTdYw==
systemFlags: 16
dn: CN=ms-DS-Cloud-Anchor,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Cloud-Anchor
adminDisplayName: ms-DS-Cloud-Anchor
adminDescription: This attribute is used by the DirSync engine to indicate the object SOA and to maintain the
relationship between the on-premises and cloud object.
ldapDisplayName: msDS-CloudAnchor
attributeId: 1.2.840.113556.1.4.2273
omSyntax: 4
instanceType: 4
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: gF5WeNQD40+vrIw7yi82Uw==
systemFlags: 16
dn: CN=ms-DS-Cloud-Issuer-Public-Certificates,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Cloud-Issuer-Public-Certificates
adminDisplayName: ms-DS-Cloud-Issuer-Public-Certificates
adminDescription: The public keys used by the cloud DRS to sign certificates issued by the Registration
Service.
ldapDisplayName: msDS-CloudIssuerPublicCertificates
attributeId: 1.2.840.113556.1.4.2274
omSyntax: 4
instanceType: 4
rangeLower: 1
rangeUpper: 65536
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: T7XoodZL0k+Y4rzukqVUlw==
systemFlags: 16
dn: CN=ms-DS-Cloud-IsEnabled,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Cloud-IsEnabled
adminDisplayName: ms-DS-Cloud-IsEnabled
adminDescription: This attribute is used to indicate whether cloud DRS is enabled.
ldapDisplayName: msDS-CloudIsEnabled
attributeId: 1.2.840.113556.1.4.2275
omSyntax: 1
instanceType: 4
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: KIOEiU58b0+gEyjOOtKC3A==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
-
-
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 65
-
Sch66.ldf
dn: CN=ms-DS-SyncServerUrl,CN=Schema,CN=Configuration,DC=X
changeType: ntdsSchemaAdd
cn: ms-DS-SyncServerUrl
ldapDisplayName: msDS-SyncServerUrl
adminDisplayName: ms-DS-SyncServerUrl
adminDescription: Use this attribute to store the sync server (Url format) which hosts the user sync folder
AttributeID: 1.2.840.113556.1.4.2276
omSyntax: 64
SystemOnly: FALSE
searchFlags: 1
rangeLower: 1
rangeUpper: 512
schemaIdGuid:: 0sOst3QqpE+sJeY/6LYSGA==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
-
objectVersion: 66
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch67.ldf
delete: systemMustContain
-
dn:
changetype: modify
schemaUpdateNow: 1
-
add: isDefunct
isDefunct: TRUE
-
objectVersion: 67
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch68.ldf
dn: CN=ms-DS-User-Allowed-To-Authenticate-To,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-UserAllowedToAuthenticateTo
adminDisplayName: ms-DS-User-Allowed-To-Authenticate-To
adminDescription: This attribute is used to determine if a user has permission to authenticate to a service.
attributeId: 1.2.840.113556.1.4.2277
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: f6oM3k5yhkKxeRkmce/GZA==
systemFlags: 16
RangeLower: 0
RangeUpper: 132096
instanceType: 4
dn: CN=ms-DS-User-Allowed-To-Authenticate-From,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-UserAllowedToAuthenticateFrom
adminDisplayName: ms-DS-User-Allowed-To-Authenticate-From
adminDescription: This attribute is used to determine if a user has permission to authenticate from a computer.
attributeId: 1.2.840.113556.1.4.2278
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: AJZMLOGwfUSN2nSQIle9tQ==
systemFlags: 16
RangeLower: 0
RangeUpper: 132096
instanceType: 4
instanceType: 4
dn: CN=ms-DS-User-TGT-Lifetime,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-UserTGTLifetime
adminDisplayName: User TGT Lifetime
adminDescription: This attribute specifies the maximum age of a Kerberos TGT issued to a user in units of 10^(-
7) seconds.
attributeId: 1.2.840.113556.1.4.2279
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: g8khhZn1D0K5q7EiK9+VwQ==
systemFlags: 16
instanceType: 4
dn: CN=ms-DS-Computer-Allowed-To-Authenticate-To,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ComputerAllowedToAuthenticateTo
adminDisplayName: ms-DS-Computer-Allowed-To-Authenticate-To
adminDescription: This attribute is used to determine if a computer has permission to authenticate to a
service.
attributeId: 1.2.840.113556.1.4.2280
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 6atbEH4Hk0e5dO8EELYlcw==
systemFlags: 16
RangeLower: 0
RangeUpper: 132096
instanceType: 4
dn: CN=ms-DS-Computer-TGT-Lifetime,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ComputerTGTLifetime
adminDisplayName: Computer TGT Lifetime
adminDescription: This attribute specifies the maximum age of a Kerberos TGT issued to a computer in units of
10^(-7) seconds.
attributeId: 1.2.840.113556.1.4.2281
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: JHWTLrnfrEykNqW32mT9Zg==
systemFlags: 16
instanceType: 4
dn: CN=ms-DS-Service-Allowed-To-Authenticate-To,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ServiceAllowedToAuthenticateTo
adminDisplayName: ms-DS-Service-Allowed-To-Authenticate-To
adminDescription: This attribute is used to determine if a service has permission to authenticate to a service.
attributeId: 1.2.840.113556.1.4.2282
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: MTGX8k2bIEi03gR07zuEnw==
systemFlags: 16
RangeLower: 0
RangeUpper: 132096
instanceType: 4
dn: CN=ms-DS-Service-Allowed-To-Authenticate-From,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ServiceAllowedToAuthenticateFrom
adminDisplayName: ms-DS-Service-Allowed-To-Authenticate-From
adminDescription: This attribute is used to determine if a service has permission to authenticate from a
computer.
attributeId: 1.2.840.113556.1.4.2283
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: mnDalxY3Zkmx0YOLpTw9iQ==
systemFlags: 16
RangeLower: 0
RangeUpper: 132096
instanceType: 4
dn: CN=ms-DS-Service-TGT-Lifetime,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ServiceTGTLifetime
adminDisplayName: Service TGT Lifetime
adminDescription: This attribute specifies the maximum age of a Kerberos TGT issued to a service in units of
10^(-7) seconds.
attributeId: 1.2.840.113556.1.4.2284
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: IDz+XSnKfUCbq4Qh5V63XA==
systemFlags: 16
instanceType: 4
dn: CN=ms-DS-Assigned-AuthN-Policy-Silo,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AssignedAuthNPolicySilo
adminDisplayName: Assigned Authentication Policy Silo
adminDescription: This attribute specifies which AuthNPolicySilo a principal is assigned to.
attributeId: 1.2.840.113556.1.4.2285
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: QcE/svUN6kqzPWz0kwd7Pw==
systemFlags: 16
instanceType: 4
linkID: 2202
dn: CN=ms-DS-Assigned-AuthN-Policy-Silo-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AssignedAuthNPolicySiloBL
adminDisplayName: Assigned Authentication Policy Silo Backlink
adminDescription: This attribute is the backlink for msDS-AssignedAuthNPolicySilo.
attributeId: 1.2.840.113556.1.4.2286
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: FAUUM3r10keOxATEZmYAxw==
systemFlags: 16
instanceType: 4
linkID: 2203
dn: CN=ms-DS-AuthN-Policy-Silo-Members,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicySiloMembers
adminDisplayName: Authentication Policy Silo Members
adminDescription: This attribute specifies which principals are assigned to the AuthNPolicySilo.
attributeId: 1.2.840.113556.1.4.2287
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: BR5NFqZIhkio6XeiAG48dw==
systemFlags: 16
instanceType: 4
linkID: 2204
dn: CN=ms-DS-AuthN-Policy-Silo-Members-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicySiloMembersBL
adminDisplayName: Authentication Policy Silo Members Backlink
adminDescription: This attribute is the backlink for msDS-AuthNPolicySiloMembers.
attributeId: 1.2.840.113556.1.4.2288
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: x8v8EeT7UUm0t63fb579RA==
systemFlags: 16
instanceType: 4
linkID: 2205
dn: CN=ms-DS-User-AuthN-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-UserAuthNPolicy
adminDisplayName: User Authentication Policy
adminDescription: This attribute specifies which AuthNPolicy should be applied to users assigned to this silo
object.
attributeId: 1.2.840.113556.1.4.2289
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 87kmzRXUKkSPeHxhUj7pWw==
systemFlags: 16
instanceType: 4
linkID: 2206
dn: CN=ms-DS-User-AuthN-Policy-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-UserAuthNPolicyBL
adminDisplayName: User Authentication Policy Backlink
adminDescription: This attribute is the backlink for msDS-UserAuthNPolicy.
attributeId: 1.2.840.113556.1.4.2290
attributeId: 1.2.840.113556.1.4.2290
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: qfoXL0ddH0uXfqpS+r5lyA==
systemFlags: 16
instanceType: 4
linkID: 2207
dn: CN=ms-DS-Computer-AuthN-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ComputerAuthNPolicy
adminDisplayName: Computer Authentication Policy
adminDescription: This attribute specifies which AuthNPolicy should be applied to computers assigned to this
silo object.
attributeId: 1.2.840.113556.1.4.2291
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: yWO4r6O+D0Sp82FTzGaJKQ==
systemFlags: 16
instanceType: 4
linkID: 2208
dn: CN=ms-DS-Computer-AuthN-Policy-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ComputerAuthNPolicyBL
adminDisplayName: Computer Authentication Policy Backlink
adminDescription: This attribute is the backlink for msDS-ComputerAuthNPolicy.
attributeId: 1.2.840.113556.1.4.2292
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: MmLvK6EwfkWGBHr22/ExuA==
systemFlags: 16
instanceType: 4
linkID: 2209
dn: CN=ms-DS-Service-AuthN-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ServiceAuthNPolicy
adminDisplayName: Service Authentication Policy
adminDescription: This attribute specifies which AuthNPolicy should be applied to services assigned to this
silo object.
attributeId: 1.2.840.113556.1.4.2293
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: lW1qKs4o7km7JG0fwB4xEQ==
systemFlags: 16
instanceType: 4
linkID: 2210
dn: CN=ms-DS-Service-AuthN-Policy-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ServiceAuthNPolicyBL
adminDisplayName: Service Authentication Policy Backlink
adminDescription: This attribute is the backlink for msDS-ServiceAuthNPolicy.
attributeId: 1.2.840.113556.1.4.2294
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: 7CgRLKJao0KzLfCXnKn80g==
systemFlags: 16
instanceType: 4
linkID: 2211
dn: CN=ms-DS-Assigned-AuthN-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AssignedAuthNPolicy
adminDisplayName: Assigned Authentication Policy
adminDescription: This attribute specifies which AuthNPolicy should be applied to this principal.
attributeId: 1.2.840.113556.1.4.2295
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 2Ap6uPdUwUmEoOZNEoU1iA==
systemFlags: 16
instanceType: 4
linkID: 2212
dn: CN=ms-DS-Assigned-AuthN-Policy-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AssignedAuthNPolicyBL
adminDisplayName: Assigned Authentication Policy Backlink
adminDescription: This attribute is the backlink for msDS-AssignedAuthNPolicy.
attributeId: 1.2.840.113556.1.4.2296
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: PBsTLZ/T7kqBXo20vBznrA==
systemFlags: 16
instanceType: 4
linkID: 2213
dn: CN=ms-DS-AuthN-Policy-Enforced,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicyEnforced
adminDisplayName: Authentication Policy Enforced
adminDescription: This attribute specifies whether the authentication policy is enforced.
attributeId: 1.2.840.113556.1.4.2297
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: wgxWekXsukSy1yEjatWf1Q==
instanceType: 4
systemFlags: 16
dn: CN=ms-DS-AuthN-Policy-Silo-Enforced,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicySiloEnforced
adminDisplayName: Authentication Policy Silo Enforced
adminDescription: This attribute specifies whether the authentication policy silo is enforced.
attributeId: 1.2.840.113556.1.4.2298
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: AhH18uBrPUmHJhVGzbyHcQ==
instanceType: 4
systemFlags: 16
dn: CN=ms-DS-AuthN-Policy-Silos,CN=Schema,CN=Configuration,DC=X
objectClass: classSchema
ldapDisplayName: msDS-AuthNPolicySilos
adminDisplayName: Authentication Policy Silos
adminDescription: A container of this class can contain authentication policy silo objects.
governsId: 1.2.840.113556.1.5.291
objectClassCategory: 1
rdnAttId: cn
schemaIdGuid:: Ckex0oSPHkmnUrQB7gD+XA==
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLOLORCWOWDSDDTDTSW;;;EA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPLCLORC;;;AU)
defaultHidingValue: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-AuthN-Policy-Silos,CN=Schema,CN=Configuration,DC=X
instanceType: 4
systemFlags: 16
subClassOf: top
systemPossSuperiors: 1.2.840.113556.1.3.23
dn: CN=ms-DS-AuthN-Policies,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicies
adminDisplayName: Authentication Policies
adminDescription: A container of this class can contain authentication policy objects.
governsId: 1.2.840.113556.1.5.293
rdnAttId: cn
schemaIdGuid:: Xd+aOpd7fk+rtOW1XBwGtA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-AuthN-Policies,CN=Schema,CN=Configuration,DC=X
instanceType: 4
systemFlags: 16
subClassOf: top
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-DS-AuthN-Policy-Silo,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicySilo
adminDisplayName: Authentication Policy Silo
adminDescription: An instance of this class defines authentication policies and related behaviors for assigned
users, computers, and services.
governsId: 1.2.840.113556.1.5.292
rdnAttId: cn
schemaIdGuid:: Hkbw+X1piUaSmTfmHWF7DQ==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-AuthN-Policy-Silo,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
instanceType: 4
systemmaycontain: msDS-AuthNPolicySiloMembers
systemmaycontain: msDS-UserAuthNPolicy
systemmaycontain: msDS-ComputerAuthNPolicy
systemmaycontain: msDS-ServiceAuthNPolicy
systemmaycontain: msDS-AssignedAuthNPolicySiloBL
systemmaycontain: msDS-AuthNPolicySiloEnforced
subClassOf: top
systemPossSuperiors: msDS-AuthNPolicySilos
dn: CN=ms-DS-AuthN-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicy
adminDisplayName: Authentication Policy
adminDescription: An instance of this class defines authentication policy behaviors for assigned principals.
governsId: 1.2.840.113556.1.5.294
rdnAttId: cn
schemaIdGuid:: VhFqq8dN9UCRgI5M5C/lzQ==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-AuthN-Policy,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
instanceType: 4
systemmaycontain: msDS-UserAllowedToAuthenticateTo
systemmaycontain: msDS-UserAllowedToAuthenticateFrom
systemmaycontain: msDS-UserTGTLifetime
systemmaycontain: msDS-ComputerAllowedToAuthenticateTo
systemmaycontain: msDS-ComputerTGTLifetime
systemmaycontain: msDS-ServiceAllowedToAuthenticateTo
systemmaycontain: msDS-ServiceAllowedToAuthenticateFrom
systemmaycontain: msDS-ServiceTGTLifetime
systemmaycontain: msDS-UserAuthNPolicyBL
systemmaycontain: msDS-ComputerAuthNPolicyBL
systemmaycontain: msDS-ServiceAuthNPolicyBL
systemmaycontain: msDS-AssignedAuthNPolicyBL
systemmaycontain: msDS-AuthNPolicyEnforced
subClassOf: top
systemPossSuperiors: msDS-AuthNPolicies
dn: CN=user,CN=Schema,CN=Configuration,DC=X
add: systemmaycontain
systemmaycontain: msDS-AssignedAuthNPolicy
systemmaycontain: msDS-AssignedAuthNPolicySilo
systemmaycontain: msDS-AuthNPolicySiloMembersBL
-
objectVersion: 68
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch69.ldf
add: defaultHidingValue
-
-
objectVersion: 69
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch70.ldf
dn: CN=ms-DS-Device-MDMStatus,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Device-MDMStatus
adminDisplayName: ms-DS-Device-MDMStatus
adminDescription: This attribute is used to manage the mobile device management status of the device.
ldapDisplayName: msDS-DeviceMDMStatus
attributeId: 1.2.840.113556.1.4.2308
omSyntax: 64
instanceType: 4
rangeUpper: 256
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: lo8K9sRXLEKjrZ4voJzm9w==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
-
objectVersion: 70
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch71.ldf
dn: CN=ms-DS-GeoCoordinates-Altitude,CN=Schema,CN=Configuration,DC=X
replace: systemFlags
systemFlags: 16
-
dn: CN=ms-DS-GeoCoordinates-Latitude,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
dn: CN=ms-DS-GeoCoordinates-Longitude,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
searchFlags: 1
-
searchFlags: 1
-
# Increase schema version

objectVersion: 71
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch72.ldf
dn: CN=ms-DS-External-Directory-Object-Id,CN=Schema,CN=Configuration,DC=X
adminDisplayName: ms-DS-External-Directory-Object-Id
adminDescription: ms-DS-External-Directory-Object-Id
ldapDisplayName: msDS-ExternalDirectoryObjectId
attributeSecurityGuid:: hri1d0qU0RGuvQAA+ANnwQ==
attributeId: 1.2.840.113556.1.4.2310
omSyntax: 64
instanceType: 4
rangeUpper: 256
schemaIdGuid:: kL8pva1m4UCIexDfBwQZpg==
searchFlags: 9
systemOnly: FALSE
systemFlags: 16
dn:
schemaUpdateNow: 1
-
dn: CN=Mail-Recipient,CN=Schema,CN=Configuration,DC=X
add: mayContain
mayContain: 1.2.840.113556.1.4.2310
-
dn: CN=Top,CN=Schema,CN=Configuration,DC=X
-
objectVersion: 72
-
Sch73.ldf
dn: CN=ms-DS-Is-Compliant,CN=Schema,CN=Configuration,DC=x
CN: ms-DS-Is-Compliant
adminDescription: This attribute is used to determine if the object is compliant with company policies.
adminDisplayName: msDS-IsCompliant
lDAPDisplayName: msDS-IsCompliant
attributeId: 1.2.840.113556.1.4.2314
oMSyntax: 1
instanceType: 4
searchFlags: 0
systemOnly: FALSE
schemaIDGUID:: D31SWcC34kyh3XHO9pYykg==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
-
objectVersion: 73
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch74.ldf
dn: CN=ms-DS-Key-Id,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-KeyId
adminDisplayName: msDS-KeyId
adminDescription: This attribute contains a key identifier.
attributeId: 1.2.840.113556.1.4.2315
omSyntax: 4
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: S/iUwq0vcUu+TJ/FcB9gug==
systemFlags: 16
RangeLower: 0
RangeUpper: 132096
instanceType: 4
dn: CN=ms-DS-Key-Material,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-KeyMaterial
adminDisplayName: msDS-KeyMaterial
adminDescription: This attribute contains key material.
attributeId: 1.2.840.113556.1.4.2316
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: nw4uodveMU+PIRMRuVgYLw==
systemFlags: 16
RangeLower: 0
RangeUpper: 132096
instanceType: 4
dn: CN=ms-DS-Key-Usage,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-KeyUsage
adminDisplayName: msDS-KeyUsage
adminDescription: This attribute identifies the usage scenario for the key.
attributeId: 1.2.840.113556.1.4.2317
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: TLRx3ropl0WeysM0is4ZFw==
systemFlags: 16
RangeLower: 0
RangeUpper: 132096
instanceType: 4
dn: CN=ms-DS-Key-Principal,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-KeyPrincipal
adminDisplayName: msDS-KeyPrincipal
adminDescription: This attribute specifies the principal that a key object applies to.
attributeId: 1.2.840.113556.1.4.2318
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: OyVhvQGUOUGmkzVvxADz6g==
systemFlags: 16
instanceType: 4
linkID: 2218
dn: CN=ms-DS-Key-Principal-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-KeyPrincipalBL
adminDisplayName: msDS-KeyPrincipalBL
adminDescription: This attribute is the backlink for msDS-KeyPrincipal.
attributeId: 1.2.840.113556.1.4.2319
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: vI8y0XSFUEGIHQsQiIJ4eA==
systemFlags: 16
instanceType: 4
linkID: 2219
dn: CN=ms-DS-Device-DN,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-DeviceDN
adminDisplayName: msDS-DeviceDN
adminDescription: This attribute identifies the registered device from which this key object was provisioned.
attributeId: 1.2.840.113556.1.4.2320
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: KREsZJk4IUeOIUg545iM5Q==
systemFlags: 16
instanceType: 4
dn: CN=ms-DS-Computer-SID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ComputerSID
adminDisplayName: msDS-ComputerSID
adminDescription: This attribute identifies a domain-joined computer.
attributeId: 1.2.840.113556.1.4.2321
omSyntax: 4
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: INf733IILkCZQPzXjbBJug==
systemFlags: 16
dn: CN=ms-DS-Custom-Key-Information,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-CustomKeyInformation
adminDisplayName: msDS-CustomKeyInformation
adminDescription: This attribute contains additional information about the key.
attributeId: 1.2.840.113556.1.4.2322
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: iOnltuTlhkyirg2suXCg4Q==
systemFlags: 16
RangeLower: 0
RangeUpper: 132096
instanceType: 4
dn: CN=ms-DS-Key-Approximate-Last-Logon-Time-Stamp,CN=Schema,CN=Configuration,DC=X
adminDisplayName: msDS-KeyApproximateLastLogonTimeStamp
adminDescription: The approximate time this key was last used in a logon operation.
adminDescription: The approximate time this key was last used in a logon operation.
ldapDisplayName: msDS-KeyApproximateLastLogonTimeStamp
attributeId: 1.2.840.113556.1.4.2323
omSyntax: 65
instanceType: 4
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: jcmaZJqbQU2va/YW8qYuSg==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-DS-Key-Credential,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-KeyCredential
adminDisplayName: msDS-KeyCredential
adminDescription: An instance of this class contains key material.
governsId: 1.2.840.113556.1.5.297
rdnAttId: cn
schemaIdGuid:: Q1Uf7i58akeLP+EfSvbEmA==
systemOnly: FALSE
systemFlags: 16
instanceType: 4
subClassOf: top
-
objectVersion: 74
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch75.ldf
dn: CN=ms-DS-Device-Trust-Type,CN=Schema,CN=Configuration,DC=X
CN: ms-DS-Device-Trust-Type
adminDescription: Represents join type for devices.
adminDisplayName: msDS-DeviceTrustType
lDAPDisplayName: msDS-DeviceTrustType
attributeId: 1.2.840.113556.1.4.2325
oMSyntax: 2
instanceType: 4
searchFlags: 0
systemOnly: FALSE
schemaIDGUID:: B2ikxNxqu0uX3mvtGBob/g==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
-
#
# Optional Feature Object
#
dn: CN=Expiring Group Membership Feature,CN=Optional Features,CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,DC=X
objectClass: msDS-OptionalFeature
msDS-OptionalFeatureFlags: 1
msDS-OptionalFeatureGUID:: c+hD7OjMQEa0qwf/5KtbzQ==
msDS-RequiredForestBehaviorVersion: 7
# 0x800000000
# 0x080000000
# 0x040000000
systemFlags: 2348810240
objectVersion: 75
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch76.ldf
dn: CN=ms-DS-Shadow-Principal-Sid,CN=Schema,CN=Configuration,DC=X
lDAPDisplayName: msDS-ShadowPrincipalSid
adminDisplayName: ms-DS-Shadow-Principal-Sid
adminDescription: Contains the SID of a principal from an external forest.
attributeID: 1.2.840.113556.1.4.2324
attributeID: 1.2.840.113556.1.4.2324
oMSyntax: 4
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: IgfMHbCq70+Vbydv4Z3hBw==
systemFlags: 16
instanceType: 4
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-DS-Shadow-Principal-Container,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ShadowPrincipalContainer
adminDisplayName: ms-DS-Shadow-Principal-Container
adminDescription: Dedicated container for msDS-ShadowPrincipal objects.
governsId: 1.2.840.113556.1.5.298
rdnAttId: cn
schemaIdGuid:: RVX5ERLXUEy4R9J4FTfGMw==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
systemFlags: 16
instanceType: 4
subClassOf: container
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-DS-Shadow-Principal,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ShadowPrincipal
adminDisplayName: ms-DS-Shadow-Principal
adminDescription: Represents a principal from an external forest.
governsId: 1.2.840.113556.1.5.299
rdnAttId: cn
schemaIdGuid:: s0wPd0MWnEa3Zu3XeqdeFA==
systemOnly: FALSE
systemFlags: 16
instanceType: 4
subClassOf: top
systemPossSuperiors: msDS-ShadowPrincipalContainer
systemMayContain: member
systemMustContain: msDS-ShadowPrincipalSid
dn: CN=Shadow Principal Feature,CN=Optional Features,CN=Directory Service,CN=Windows

objectClass: msDS-OptionalFeature
msDS-OptionalFeatureFlags: 1
msDS-OptionalFeatureGUID:: KbW388juRVatNjmTdiXpNg==
msDS-RequiredForestBehaviorVersion: 7
dn: CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=X

objectClass: msDS-ShadowPrincipalContainer
objectVersion: 76
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch77.ldf
dn: CN=ms-DS-Key-Id,CN=Schema,CN=Configuration,DC=X
replace: isMemberOfPartialAttributeSet
isMemberOfPartialAttributeSet: FALSE
-
dn: CN=ms-DS-Key-Material,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ms-DS-Key-Usage,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ms-DS-Key-Principal,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ms-DS-Device-DN,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ms-DS-Computer-SID,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ms-DS-Custom-Key-Information,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ms-DS-Key-Approximate-Last-Logon-Time-Stamp,CN=Schema,CN=Configuration,DC=X
-
-
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-DS-Key-Credential,CN=Schema,CN=Configuration,DC=X
-
objectVersion: 77
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch78.ldf
#
# Optional Feature Object
#
# FLAG_ALLOW_RENAME 0x400000
-

changetype: ntdsSchemaModRdn
newrdn: Privileged Access Management Feature
deleteoldrdn: 1
dn: CN=Privileged Access Management Feature,CN=Optional Features,CN=Directory Service,CN=Windows

# FLAG_DISALLOW_DELETE 0x80000000
# FLAG_DOMAIN_DISALLOW_RENAME 0x08000000
# FLAG_DOMAIN_DISALLOW_MOVE 0x04000000
-

# FLAG_DOMAIN_DISALLOW_RENAME 0x08000000
# FLAG_DOMAIN_DISALLOW_MOVE 0x04000000
-

changetype: ntdsSchemaDelete
objectVersion: 78
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch79.ldf
-
objectVersion: 79
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch80.ldf
dn: CN=ms-DS-Key-Credential-Link,CN=schema,CN=configuration,DC=X
attributeID: 1.2.840.113556.1.4.2328
adminDisplayName: ms-DS-Key-Credential-Link
adminDescription: Contains key material and usage.
oMSyntax: 127
oMObjectClass:: KoZIhvcUAQEBCw==
lDAPDisplayName: msDS-KeyCredentialLink
systemOnly: FALSE
schemaIDGUID:: D9ZHW5BgskCfNypN6I8wYw==
searchFlags: 0
systemFlags: 16
linkId: 2220
dn: CN=ms-DS-Key-Credential-Link-BL,CN=schema,CN=configuration,DC=X
attributeID: 1.2.840.113556.1.4.2329
oMSyntax: 127
lDAPDisplayName: msDS-KeyCredentialLink-BL
systemOnly: FALSE
schemaIDGUID:: iNeKk18i7k6Tua0koVnh2w==
searchFlags: 0
systemFlags: 16
linkId: 2221
dn:
changetype: modify
schemaUpdateNow: 1
-
-
-
objectVersion: 80
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch81.ldf
dn: CN=DS-Validated-Write-Computer,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Validated write to computer attributes.
rightsGuid: 9b026da6-0d3c-465c-8bee-5199d7165cba
appliesTo: bf967a86-0de6-11d0-a285-00aa003049e2
ShowInAdvancedViewOnly: TRUE
validAccesses: 8
dn: CN=ms-DS-Key-Credential-Link,CN=schema,CN=configuration,DC=X
add: attributeSecurityGUID
attributeSecurityGUID:: pm0CmzwNXEaL7lGZ1xZcug==
-
objectVersion: 81
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch82.ldf
dn: CN=Dns-Zone-Scope-Container,CN=Schema,CN=Configuration,DC=X
cn: Dns-Zone-Scope-Container
adminDisplayName: Dns-Zone-Scope-Container
adminDescription: Container for Dns Zone Scope objects.
ldapDisplayName: dnsZoneScopeContainer
rDNAttID: cn
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;ED)
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;CC;;;AU)(A;;RPLCLORC;;;WD)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;CO)
governsId: 1.2.840.113556.1.5.300
instanceType: 4
schemaIdGuid:: k5Bp8lryIEKd6wPfTMSpxQ==
systemOnly: FALSE
systemFlags: 16
subClassOf: top
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=Dns-Zone-Scope,CN=Schema,CN=Configuration,DC=X
cn: Dns-Zone-Scope
adminDisplayName: Dns-Zone-Scope
adminDescription: A zonescope of a zone is another copy of the zone contained in the zone with different set of
resource records.
ldapDisplayName: dnsZoneScope
rDNAttID: cn
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;ED)
governsId: 1.2.840.113556.1.5.301
instanceType: 4
schemaIdGuid:: YYpvaT8tzkCks+J138xJxQ==
systemOnly: FALSE
systemFlags: 16
subClassOf: top
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=Dns-Node,CN=Schema,CN=Configuration,DC=X
add: systemPossSuperiors
-
objectVersion: 82
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch83.ldf
dn: CN=ms-DS-Expire-Passwords-On-Smart-Card-Only-Accounts,CN=Schema,CN=Configuration,DC=X
CN: ms-DS-Expire-Passwords-On-Smart-Card-Only-Accounts
attributeID: 1.2.840.113556.1.4.2344
adminDisplayName: ms-DS-Expire-Passwords-On-Smart-Card-Only-Accounts
adminDescription: This attribute controls whether the passwords on smart-card-only accounts expire in
accordance with the password policy.
oMSyntax: 1
lDAPDisplayName: msDS-ExpirePasswordsOnSmartCardOnlyAccounts
systemOnly: FALSE
schemaIDGUID:: SKsXNCTfsU+AsA/LNn4l4w==
systemFlags: 16
searchFlags: 0
instanceType: 4
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=Domain-DNS,CN=Schema,CN=Configuration,DC=X
-
objectVersion: 83
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch84.ldf
dn: CN=ms-DS-Token-Group-Names,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msds-tokenGroupNames
adminDisplayName: ms-DS-Token-Group-Names
adminDescription: The distinguished names of security groups the principal is directly or indirectly a member
of.
attributeId: 1.2.840.113556.1.4.2345
omSyntax: 127
systemOnly: TRUE
# 0x00000800 (Attribute is returned only on base searches.)
# searchFlags hex value 0x00000800
searchFlags: 2048
schemaIdGuid:: dgVlZZlGyU+NGCbgzQE3pg==
attributeSecurityGuid:: +IhwA+EK0hG0IgCgyWj5OQ==
# 0x00000001 (Attribute is not replicated)
# 0x00000004 (Attribute is constructed)
# 0x00000008 (Attribute is operational)
# 0x00000010 (Attribute is in the base schema)
# systemFlags hex value 0x0000001D
systemFlags: 29
dn: CN=ms-DS-Token-Group-Names-Global-And-Universal,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msds-tokenGroupNamesGlobalAndUniversal
adminDisplayName: ms-DS-Token-Group-Names-Global-And-Universal
adminDescription: The distinguished names of global and universal security groups the principal is directly or
indirectly a member of.
attributeId: 1.2.840.113556.1.4.2346
omSyntax: 127
systemOnly: TRUE
searchFlags: 2048
schemaIdGuid:: 9NEG+iJ5rUq3nLIgH1RBfA==
systemFlags: 29
dn: CN=ms-DS-Token-Group-Names-No-GC-Acceptable,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msds-tokenGroupNamesNoGCAcceptable
adminDisplayName: ms-DS-Token-Group-Names-No-GC-Acceptable
adminDescription: The distinguished names of security groups the principal is directly or indirectly a member
of as reported by the local DC.
attributeId: 1.2.840.113556.1.4.2347
omSyntax: 127
systemOnly: TRUE
searchFlags: 2048
schemaIdGuid:: yMY/UvSaAkqc1z3qEp7rJw==
systemFlags: 29
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=Security-Principal,CN=Schema,CN=Configuration,DC=X
-
objectVersion: 84
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch85.ldf
dn: CN=ms-DS-User-Allowed-NTLM-Network-Authentication,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-UserAllowedNTLMNetworkAuthentication
adminDisplayName: ms-DS-User-Allowed-NTLM-Network-Authentication
adminDescription: This attribute is used to determine if a user is allowed to authenticate using NTLM
authentication.
attributeId: 1.2.840.113556.1.4.2348
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
# schemaIdGuid {7ece040f-9327-4cdc-aad3-037adfe62639}
schemaIdGuid:: DwTOfieT3Eyq0wN63+YmOQ==
# attributeSecurityGuid {00000000-0000-0000-0000-000000000000}
# systemFlags hex value 0x00000010
systemFlags: 16
dn: CN=ms-DS-Service-Allowed-NTLM-Network-Authentication,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ServiceAllowedNTLMNetworkAuthentication
adminDisplayName: ms-DS-Service-Allowed-NTLM-Network-Authentication
adminDescription: This attribute is used to determine if a service is allowed to authenticate using NTLM
authentication.
attributeId: 1.2.840.113556.1.4.2349
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
# schemaIdGuid {278947b9-5222-435e-96b7-1503858c2b48}
schemaIdGuid:: uUeJJyJSXkOWtxUDhYwrSA==
systemFlags: 16
dn: CN=ms-DS-Strong-NTLM-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-StrongNTLMPolicy
adminDisplayName: ms-DS-Strong-NTLM-Policy
adminDescription: This attribute specifies policy options for NTLM secrets with strong entropy.
attributeId: 1.2.840.113556.1.4.2350
omSyntax: 2
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
# schemaIdGuid {aacd2170-482a-44c6-b66e-42c2f66a285c}
schemaIdGuid:: cCHNqipIxkS2bkLC9mooXA==
systemFlags: 16
-
objectVersion: 85
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch86.ldf
dn: CN=ms-DS-Source-Anchor,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-SourceAnchor
adminDisplayName: ms-DS-Source-Anchor
adminDescription: Unique, immutable identifier for the object in the authoritative directory.
attributeId: 1.2.840.113556.1.4.2352
# Syntax: String
oMSyntax: 64
# Note that we do not supply rangeUpper here. DS API enforces a maximum length of 256 Unicode characters,
# which may translate to more than 256 multi-byte characters in AD given that the AD syntax for this
# attribute is not String(Unicode).
rangeLower: 1
systemOnly: FALSE
# searchFlags: +fPDNTATTINDEX for SearchForAddressListObjects
# searchFlags: fPDNTATTINDEX | fPRESERVEONDELETE
searchFlags: 10
schemaIDGUID:: B/QCsEAT60G8oL19k44lqQ==
systemFlags: 16
dn: CN=ms-DS-Object-SOA,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ObjectSoa
adminDisplayName: ms-DS-Object-SOA
adminDescription: This attribute is used to identify the source of authority of the object.
attributeId: 1.2.840.113556.1.4.2353
attributeId: 1.2.840.113556.1.4.2353
# Syntax: String
oMSyntax: 64
# Note that we do not supply rangeUpper here. DS API enforces a maximum length of 256 Unicode characters,
# which may translate to more than 256 multi-byte characters in AD given that the AD syntax for this
# attribute is not String(Unicode).
rangeLower: 1
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: 9b32NHkuO0yOFD2Tt1qriQ==
systemFlags: 16
-
objectVersion: 86
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch87.ldf
dn: CN=Send-As,CN=Extended-Rights,CN=Configuration,DC=X
changetype: modify
add: appliesTo
appliesTo: 7b8b558a-93a5-4af7-adca-c017e67f1057
-
dn: CN=Receive-As,CN=Extended-Rights,CN=Configuration,DC=X
changetype: modify
add: appliesTo
-
dn: CN=Personal-Information,CN=Extended-Rights,CN=Configuration,DC=X
changetype: modify
add: appliesTo
-
dn: CN=Public-Information,CN=Extended-Rights,CN=Configuration,DC=X
changetype: modify
add: appliesTo
-
dn: CN=Validated-SPN,CN=Extended-Rights,CN=Configuration,DC=X
changetype: modify
add: appliesTo
-
dn: CN=Allowed-To-Authenticate,CN=Extended-Rights,CN=Configuration,DC=X
changetype: modify
add: appliesTo
-
dn: CN=MS-TS-GatewayAccess,CN=Extended-Rights,CN=Configuration,DC=X
changetype: modify
add: appliesTo
-
objectVersion: 87
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Schema Updates in Windows Server 2012 R2

Sch57.ldf
cn: ms-DS-Issuer-Certificates
adminDisplayName: ms-DS-Issuer-Certificates
adminDescription: The keys used to sign certificates issued by the Registration Service.
ldapDisplayName: msDS-IssuerCertificates
attributeId: 1.2.840.113556.1.4.2240
omSyntax: 4
instanceType: 4
rangeLower: 1
rangeUpper: 65536
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: 2m89a5MIxEOJ+x+1KmYWqQ==
systemFlags: 16
cn: ms-DS-Registration-Quota
adminDisplayName: ms-DS-Registration-Quota
adminDescription: Policy used to limit the number of registrations allowed for a single user.
ldapDisplayName: msDS-RegistrationQuota
attributeId: 1.2.840.113556.1.4.2241
omSyntax: 2
instanceType: 4
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: woYyymQfeUCWvOYrYQ5zDw==
systemFlags: 16
cn: ms-DS-Maximum-Registration-Inactivity-Period
adminDisplayName: ms-DS-Maximum-Registration-Inactivity-Period
adminDescription: The maximum ammount of days used to detect inactivty of registration objects.
ldapDisplayName: msDS-MaximumRegistrationInactivityPeriod
attributeId: 1.2.840.113556.1.4.2242
omSyntax: 2
instanceType: 4
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: OapcCuYFykm4CAJbk2YQ5w==
systemFlags: 16
cn: ms-DS-Is-Enabled
adminDisplayName: ms-DS-Is-Enabled
adminDescription: This attribute is used to enable or disable the user-device relationship.
ldapDisplayName: msDS-IsEnabled
attributeId: 1.2.840.113556.1.4.2248
omSyntax: 1
instanceType: 4
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: DlypIoMfgkyUzr6miM/IcQ==
systemFlags: 16
cn: ms-DS-Device-OS-Type
adminDisplayName: ms-DS-Device-OS-Type
adminDescription: This attribute is used to track the type of device based on the OS.
ldapDisplayName: msDS-DeviceOSType
attributeId: 1.2.840.113556.1.4.2249
omSyntax: 64
instanceType: 4
rangeLower: 0
rangeUpper: 1024
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: TUUOELvzy02EX41e3EccWQ==
systemFlags: 16
cn: ms-DS-Device-OS-Version
adminDisplayName: ms-DS-Device-OS-Version
adminDescription: This attribute is used to track the OS version of the device.
ldapDisplayName: msDS-DeviceOSVersion
attributeId: 1.2.840.113556.1.4.2250
omSyntax: 64
instanceType: 4
rangeLower: 0
rangeUpper: 512
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: Y4z7cKtfBEWrnRSzKain+A==
systemFlags: 16
cn: ms-DS-Device-Physical-IDs
adminDisplayName: ms-DS-Device-Physical-IDs
adminDescription: This attribute is used to store identifiers of the physical device.
ldapDisplayName: msDS-DevicePhysicalIDs
attributeId: 1.2.840.113556.1.4.2251
omSyntax: 4
instanceType: 4
rangeLower: 1
rangeUpper: 10485760
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: FFRhkKCiR0Spk1NAlZm3Tg==
systemFlags: 16
cn: ms-DS-Device-ID
adminDisplayName: ms-DS-Device-ID
adminDescription: This attribute stores the ID of the device.
ldapDisplayName: msDS-DeviceID
attributeId: 1.2.840.113556.1.4.2252
omSyntax: 4
instanceType: 4
rangeLower: 16
rangeUpper: 16
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: x4EBw0Jj+0GyeffFZsvgpw==
schemaIdGuid:: x4EBw0Jj+0GyeffFZsvgpw==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
cn: ms-DS-Device-Registration-Service-Container
adminDisplayName: ms-DS-Device-Registration-Service-Container
adminDescription: A class for the container used to house all enrollment services used for device
registrations.
ldapDisplayName: msDS-DeviceRegistrationServiceContainer
rDNAttID: cn
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLOLORCWOWDSDDTDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
governsId: 1.2.840.113556.1.5.287
instanceType: 4
schemaIdGuid:: zlULMc09kkOpbcnjU5fCTw==
systemOnly: FALSE
systemFlags: 16
subClassOf: top
dn: CN=ms-DS-Device-Container,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Device-Container
adminDisplayName: ms-DS-Device-Container
adminDescription: A class for the container used to hold device objects.
ldapDisplayName: msDS-DeviceContainer
rDNAttID: cn
defaultSecurityDescriptor: D:(A;;RPLCLORC;;;AU)(A;;RPWPCRCCDCLCLOLORCWOWDSDDTDTSW;;;DA)
governsId: 1.2.840.113556.1.5.289
instanceType: 4
schemaIdGuid:: WIyefBuQqE627E656fwOEQ==
systemOnly: FALSE
systemFlags: 16
subClassOf: top
dn:
changetype: modify
schemaUpdateNow: 1
-
cn: ms-DS-Device-Registration-Service
adminDisplayName: ms-DS-Device-Registration-Service
adminDescription: An object of this class holds the registration service configuration used for devices.
ldapDisplayName: msDS-DeviceRegistrationService
rDNAttID: cn
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLOLORCWOWDSDDTDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
governsId: 1.2.840.113556.1.5.284
instanceType: 4
schemaIdGuid:: Gjq8ltLj00mvEXsN951n9Q==
schemaIdGuid:: Gjq8ltLj00mvEXsN951n9Q==
systemOnly: FALSE
systemFlags: 16
subClassOf: top
cn: ms-DS-Device
adminDisplayName: ms-DS-Device
adminDescription: An object of this type represents a registered device.
ldapDisplayName: msDS-Device
rDNAttID: cn
defaultSecurityDescriptor: D:(A;;RPLCLORC;;;AU)(A;;RPWPCRCCDCLCLOLORCWOWDSDDTDTSW;;;DA)
governsId: 1.2.840.113556.1.5.286
instanceType: 4
schemaIdGuid:: c7byXUFtdEez6NUujun/mQ==
systemOnly: FALSE
systemFlags: 16
subClassOf: top
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 57
-
Sch58.ldf
-
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 58
-
Sch59.ldf
dn: CN=ms-DS-User-Device-Registration,CN=Schema,CN=Configuration,DC=X
replace: isDefunct
isDefunct: TRUE
-
dn: CN=ms-DS-User-Device-Registration-Container,CN=Schema,CN=Configuration,DC=X
replace: isDefunct
isDefunct: TRUE
-
-
-
dn: CN=ms-DS-User-Device-Registration-Link,CN=Schema,CN=Configuration,DC=X
replace: isDefunct
isDefunct: TRUE
-
dn: CN=ms-DS-User-Device-Registration-Link-BL,CN=Schema,CN=Configuration,DC=X
replace: isDefunct
isDefunct: TRUE
-
dn: CN=ms-DS-Authentication-Level,CN=Schema,CN=Configuration,DC=X
replace: isDefunct
isDefunct: TRUE
-
dn: CN=ms-DS-Approximate-Last-Use-Time-Stamp,CN=Schema,CN=Configuration,DC=X
replace: isDefunct
isDefunct: TRUE
-
-
dn: CN=ms-DS-Device-Reference,CN=Schema,CN=Configuration,DC=X
replace: isDefunct
isDefunct: TRUE
-
dn: CN=ms-DS-Device-Location,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Device-Location
adminDisplayName: ms-DS-Device-Location
adminDescription: The DN under which the device objects will be created.
ldapDisplayName: msDS-DeviceLocation
attributeId: 1.2.840.113556.1.4.2261
omSyntax: 127
instanceType: 4
searchFlags: 0
systemOnly: TRUE
schemaIdGuid:: yFb74+hd9UWxsdK2zTHnYg==
systemFlags: 16
cn: ms-DS-Registered-Owner
adminDisplayName: ms-DS-Registered-Owner
adminDescription: Single valued binary attribute containing the primary SID referencing the first user to
register the device. The value is not removed during de-registration, but could be managed by an administrator.
ldapDisplayName: msDS-RegisteredOwner
attributeId: 1.2.840.113556.1.4.2258
omSyntax: 4
instanceType: 4
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: 6SZ2YesBz0KZH85heYIjfg==
systemFlags: 18
cn: ms-DS-Registered-Users
adminDisplayName: ms-DS-Registered-Users
adminDescription: Contains the list of users that have registered the device. Users in this list have all of
the features provided by the "Company Portal" app. And they have SSO to company resources.
ldapDisplayName: msDS-RegisteredUsers
attributeId: 1.2.840.113556.1.4.2263
omSyntax: 4
instanceType: 4
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: DBZJBI5ayE+wUgHA9uSPAg==
systemFlags: 18
cn: ms-DS-Approximate-Last-Logon-Time-Stamp
adminDisplayName: ms-DS-Approximate-Last-Logon-Time-Stamp
adminDescription: The approximate time a user last logged on with from the device.
ldapDisplayName: msDS-ApproximateLastLogonTimeStamp
attributeId: 1.2.840.113556.1.4.2262
omSyntax: 65
instanceType: 4
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: O5hPo8aEDE+QUKOhSh01pA==
systemFlags: 16
cn: ms-DS-Device-Object-Version
adminDisplayName: ms-DS-Device-Object-Version
adminDescription: This attribute is used to identify the schema version of the device.
ldapDisplayName: msDS-DeviceObjectVersion
attributeId: 1.2.840.113556.1.4.2257
omSyntax: 2
instanceType: 4
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: Wmll73nxak6T3rAeBmgc+w==
systemFlags: 18
-
searchFlags: 1
-
-
replace: omSyntax
omSyntax: 64
-
replace: attributeSyntax
-
replace: rangeUpper
rangeUpper: 1024
-
dn:
dn:
changetype: modify
schemaUpdateNow: 1
-
-
-
-
-
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 59
-
Sch60.ldf
dn: CN=ms-DS-Is-Member-Of-DL-Transitive,CN=Schema,CN=Configuration,DC=X
# linked attribute "isMemberOfDL"
lDAPDisplayName: msds-memberOfTransitive
adminDisplayName: msds-memberOfTransitive
adminDescription: msds-memberOfTransitive
attributeID: 1.2.840.113556.1.4.2236
oMSyntax: 127
systemOnly: TRUE
searchFlags: 2048
schemaIdGuid:: tmYhhkHJJ0eVZUi//ylB3g==
systemFlags: 29
dn: CN=ms-DS-Member-Transitive,CN=Schema,CN=Configuration,DC=X
# linked attribute "member"
lDAPDisplayName: msds-memberTransitive
adminDisplayName: msds-memberTransitive
adminDescription: msds-memberTransitive
attributeID: 1.2.840.113556.1.4.2238
oMSyntax: 127
systemOnly: TRUE
searchFlags: 2048
schemaIdGuid:: WzkV4gSR2US4lDmeyeId/A==
systemFlags: 29
dn: CN=ms-DS-Parent-Dist-Name,CN=Schema,CN=Configuration,DC=X
lDAPDisplayName: msDS-parentdistname
adminDisplayName: ms-DS-Parent-Dist-Name
adminDescription: ms-DS-Parent-Dist-Name
attributeID: 1.2.840.113556.1.4.2203
oMSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIDGUID:: ff4YuRqXBPSeIZJhq+yXCw==
systemFlags: 29
dn: CN=ms-DS-Repl-Value-Meta-Data-Ext,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ReplValueMetaDataExt
adminDisplayName: ms-DS-Repl-Value-Meta-Data-Ext
adminDescription: ms-DS-Repl-Value-Meta-Data-Ext
attributeId: 1.2.840.113556.1.4.2235
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 79ICHq1EskamfZ/RjXgLyg==
# 0x04 (constructed)
systemFlags: 20
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: cn=Top,cn=Schema,cn=Configuration,dc=X
changetype: ntdsschemamodify
-
dn: CN=DS-Set-Owner,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Set Owner of an object during creation.
rightsGuid: 4125c71f-7fac-4ff0-bcb7-f09a41325286
validAccesses: 256
dn: CN=DS-Bypass-Quota,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Bypass the quota restrictions during creation.
rightsGuid: 88a9933e-e5c8-4f2a-9dd7-2527416b8092
validAccesses: 256
dn: CN=DS-Read-Partition-Secrets,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Read secret attributes of objects in a Partition
rightsGuid: 084c93a2-620d-4879-a836-f0ae47de0e89
validAccesses: 256
dn: CN=DS-Write-Partition-Secrets,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Write secret attributes of objects in a Partition
rightsGuid: 94825A8D-B171-4116-8146-1E34D8F54401
validAccesses: 256
objectVersion: 60
-
Sch61.ldf
cn: ms-DS-Drs-Farm-ID
adminDisplayName: ms-DS-Drs-Farm-ID
adminDescription: This attribute stores the name of the federation service this DRS object is associated with.
ldapDisplayName: msDS-DrsFarmID
attributeId: 1.2.840.113556.1.4.2265
omSyntax: 64
instanceType: 4
searchFlags: 0
systemOnly: TRUE
schemaIdGuid:: ZvdVYC4gzUmovuUrsVnt+w==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
-
objectVersion: 61
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch62.ldf
dn: CN=ms-DS-Issuer-Public-Certificates,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Issuer-Public-Certificates
adminDisplayName: ms-DS-Issuer-Public-Certificates
adminDescription: The public keys of the keys used to sign certificates issued by the Registration Service.
ldapDisplayName: msDS-IssuerPublicCertificates
attributeId: 1.2.840.113556.1.4.2269
omSyntax: 4
instanceType: 4
rangeLower: 1
rangeUpper: 65536
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: /u3xtdK0dkCrD2FINCsL9g==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
-
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 62
-
Sch63.ldf
searchFlags: 128
-
-
-
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 63
-
Sch64.ldf
-
-
-
-
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 64
-
Sch65.ldf
-
-
-
-
-
-
-
-
-
-
-
-
dn: CN=ms-DS-IsManaged,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-IsManaged
adminDisplayName: ms-DS-IsManaged
adminDescription: This attribute is used to indicate the device is managed by a on-premises MDM.
ldapDisplayName: msDS-IsManaged
attributeId: 1.2.840.113556.1.4.2270
omSyntax: 1
instanceType: 4
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: zmpoYCds3kOk5fAML40zCQ==
systemFlags: 16
dn: CN=ms-DS-Cloud-IsManaged,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Cloud-IsManaged
adminDisplayName: ms-DS-Cloud-IsManaged
adminDescription: This attribute is used to indicate the device is managed by a cloud MDM.
ldapDisplayName: msDS-CloudIsManaged
attributeId: 1.2.840.113556.1.4.2271
omSyntax: 1
instanceType: 4
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: jroVU4+VUku9OBNJowTdYw==
systemFlags: 16
dn: CN=ms-DS-Cloud-Anchor,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Cloud-Anchor
adminDisplayName: ms-DS-Cloud-Anchor
adminDescription: This attribute is used by the DirSync engine to indicate the object SOA and to maintain the
relationship between the on-premises and cloud object.
ldapDisplayName: msDS-CloudAnchor
attributeId: 1.2.840.113556.1.4.2273
omSyntax: 4
instanceType: 4
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: gF5WeNQD40+vrIw7yi82Uw==
systemFlags: 16
dn: CN=ms-DS-Cloud-Issuer-Public-Certificates,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Cloud-Issuer-Public-Certificates
adminDisplayName: ms-DS-Cloud-Issuer-Public-Certificates
adminDescription: The public keys used by the cloud DRS to sign certificates issued by the Registration
Service.
ldapDisplayName: msDS-CloudIssuerPublicCertificates
attributeId: 1.2.840.113556.1.4.2274
omSyntax: 4
instanceType: 4
rangeLower: 1
rangeUpper: 65536
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: T7XoodZL0k+Y4rzukqVUlw==
systemFlags: 16
dn: CN=ms-DS-Cloud-IsEnabled,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Cloud-IsEnabled
adminDisplayName: ms-DS-Cloud-IsEnabled
adminDescription: This attribute is used to indicate whether cloud DRS is enabled.
ldapDisplayName: msDS-CloudIsEnabled
attributeId: 1.2.840.113556.1.4.2275
omSyntax: 1
instanceType: 4
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: KIOEiU58b0+gEyjOOtKC3A==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
-
-
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 65
-
Sch66.ldf
dn: CN=ms-DS-SyncServerUrl,CN=Schema,CN=Configuration,DC=X
changeType: ntdsSchemaAdd
cn: ms-DS-SyncServerUrl
ldapDisplayName: msDS-SyncServerUrl
adminDisplayName: ms-DS-SyncServerUrl
adminDescription: Use this attribute to store the sync server (Url format) which hosts the user sync folder
AttributeID: 1.2.840.113556.1.4.2276
omSyntax: 64
SystemOnly: FALSE
searchFlags: 1
rangeLower: 1
rangeUpper: 512
schemaIdGuid:: 0sOst3QqpE+sJeY/6LYSGA==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
-
objectVersion: 66
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch67.ldf
delete: systemMustContain
-
dn:
changetype: modify
schemaUpdateNow: 1
-
add: isDefunct
isDefunct: TRUE
-
objectVersion: 67
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch68.ldf
dn: CN=ms-DS-User-Allowed-To-Authenticate-To,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-UserAllowedToAuthenticateTo
adminDisplayName: ms-DS-User-Allowed-To-Authenticate-To
adminDescription: This attribute is used to determine if a user has permission to authenticate to a service.
attributeId: 1.2.840.113556.1.4.2277
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: f6oM3k5yhkKxeRkmce/GZA==
systemFlags: 16
RangeLower: 0
RangeUpper: 132096
instanceType: 4
dn: CN=ms-DS-User-Allowed-To-Authenticate-From,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-UserAllowedToAuthenticateFrom
adminDisplayName: ms-DS-User-Allowed-To-Authenticate-From
adminDescription: This attribute is used to determine if a user has permission to authenticate from a computer.
attributeId: 1.2.840.113556.1.4.2278
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: AJZMLOGwfUSN2nSQIle9tQ==
systemFlags: 16
RangeLower: 0
RangeUpper: 132096
instanceType: 4
instanceType: 4
dn: CN=ms-DS-User-TGT-Lifetime,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-UserTGTLifetime
adminDisplayName: User TGT Lifetime
adminDescription: This attribute specifies the maximum age of a Kerberos TGT issued to a user in units of 10^(-
7) seconds.
attributeId: 1.2.840.113556.1.4.2279
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: g8khhZn1D0K5q7EiK9+VwQ==
systemFlags: 16
instanceType: 4
dn: CN=ms-DS-Computer-Allowed-To-Authenticate-To,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ComputerAllowedToAuthenticateTo
adminDisplayName: ms-DS-Computer-Allowed-To-Authenticate-To
adminDescription: This attribute is used to determine if a computer has permission to authenticate to a
service.
attributeId: 1.2.840.113556.1.4.2280
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 6atbEH4Hk0e5dO8EELYlcw==
systemFlags: 16
RangeLower: 0
RangeUpper: 132096
instanceType: 4
dn: CN=ms-DS-Computer-TGT-Lifetime,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ComputerTGTLifetime
adminDisplayName: Computer TGT Lifetime
adminDescription: This attribute specifies the maximum age of a Kerberos TGT issued to a computer in units of
10^(-7) seconds.
attributeId: 1.2.840.113556.1.4.2281
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: JHWTLrnfrEykNqW32mT9Zg==
systemFlags: 16
instanceType: 4
dn: CN=ms-DS-Service-Allowed-To-Authenticate-To,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ServiceAllowedToAuthenticateTo
adminDisplayName: ms-DS-Service-Allowed-To-Authenticate-To
adminDescription: This attribute is used to determine if a service has permission to authenticate to a service.
attributeId: 1.2.840.113556.1.4.2282
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: MTGX8k2bIEi03gR07zuEnw==
systemFlags: 16
RangeLower: 0
RangeUpper: 132096
instanceType: 4
dn: CN=ms-DS-Service-Allowed-To-Authenticate-From,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ServiceAllowedToAuthenticateFrom
adminDisplayName: ms-DS-Service-Allowed-To-Authenticate-From
adminDescription: This attribute is used to determine if a service has permission to authenticate from a
computer.
attributeId: 1.2.840.113556.1.4.2283
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: mnDalxY3Zkmx0YOLpTw9iQ==
systemFlags: 16
RangeLower: 0
RangeUpper: 132096
instanceType: 4
dn: CN=ms-DS-Service-TGT-Lifetime,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ServiceTGTLifetime
adminDisplayName: Service TGT Lifetime
adminDescription: This attribute specifies the maximum age of a Kerberos TGT issued to a service in units of
10^(-7) seconds.
attributeId: 1.2.840.113556.1.4.2284
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: IDz+XSnKfUCbq4Qh5V63XA==
systemFlags: 16
instanceType: 4
dn: CN=ms-DS-Assigned-AuthN-Policy-Silo,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AssignedAuthNPolicySilo
adminDisplayName: Assigned Authentication Policy Silo
adminDescription: This attribute specifies which AuthNPolicySilo a principal is assigned to.
attributeId: 1.2.840.113556.1.4.2285
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: QcE/svUN6kqzPWz0kwd7Pw==
systemFlags: 16
instanceType: 4
linkID: 2202
dn: CN=ms-DS-Assigned-AuthN-Policy-Silo-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AssignedAuthNPolicySiloBL
adminDisplayName: Assigned Authentication Policy Silo Backlink
adminDescription: This attribute is the backlink for msDS-AssignedAuthNPolicySilo.
attributeId: 1.2.840.113556.1.4.2286
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: FAUUM3r10keOxATEZmYAxw==
systemFlags: 16
instanceType: 4
linkID: 2203
dn: CN=ms-DS-AuthN-Policy-Silo-Members,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicySiloMembers
adminDisplayName: Authentication Policy Silo Members
adminDescription: This attribute specifies which principals are assigned to the AuthNPolicySilo.
attributeId: 1.2.840.113556.1.4.2287
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: BR5NFqZIhkio6XeiAG48dw==
systemFlags: 16
instanceType: 4
linkID: 2204
dn: CN=ms-DS-AuthN-Policy-Silo-Members-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicySiloMembersBL
adminDisplayName: Authentication Policy Silo Members Backlink
adminDescription: This attribute is the backlink for msDS-AuthNPolicySiloMembers.
attributeId: 1.2.840.113556.1.4.2288
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: x8v8EeT7UUm0t63fb579RA==
systemFlags: 16
instanceType: 4
linkID: 2205
dn: CN=ms-DS-User-AuthN-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-UserAuthNPolicy
adminDisplayName: User Authentication Policy
adminDescription: This attribute specifies which AuthNPolicy should be applied to users assigned to this silo
object.
attributeId: 1.2.840.113556.1.4.2289
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 87kmzRXUKkSPeHxhUj7pWw==
systemFlags: 16
instanceType: 4
linkID: 2206
dn: CN=ms-DS-User-AuthN-Policy-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-UserAuthNPolicyBL
adminDisplayName: User Authentication Policy Backlink
adminDescription: This attribute is the backlink for msDS-UserAuthNPolicy.
attributeId: 1.2.840.113556.1.4.2290
attributeId: 1.2.840.113556.1.4.2290
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: qfoXL0ddH0uXfqpS+r5lyA==
systemFlags: 16
instanceType: 4
linkID: 2207
dn: CN=ms-DS-Computer-AuthN-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ComputerAuthNPolicy
adminDisplayName: Computer Authentication Policy
adminDescription: This attribute specifies which AuthNPolicy should be applied to computers assigned to this
silo object.
attributeId: 1.2.840.113556.1.4.2291
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: yWO4r6O+D0Sp82FTzGaJKQ==
systemFlags: 16
instanceType: 4
linkID: 2208
dn: CN=ms-DS-Computer-AuthN-Policy-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ComputerAuthNPolicyBL
adminDisplayName: Computer Authentication Policy Backlink
adminDescription: This attribute is the backlink for msDS-ComputerAuthNPolicy.
attributeId: 1.2.840.113556.1.4.2292
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: MmLvK6EwfkWGBHr22/ExuA==
systemFlags: 16
instanceType: 4
linkID: 2209
dn: CN=ms-DS-Service-AuthN-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ServiceAuthNPolicy
adminDisplayName: Service Authentication Policy
adminDescription: This attribute specifies which AuthNPolicy should be applied to services assigned to this
silo object.
attributeId: 1.2.840.113556.1.4.2293
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: lW1qKs4o7km7JG0fwB4xEQ==
systemFlags: 16
instanceType: 4
linkID: 2210
dn: CN=ms-DS-Service-AuthN-Policy-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ServiceAuthNPolicyBL
adminDisplayName: Service Authentication Policy Backlink
adminDescription: This attribute is the backlink for msDS-ServiceAuthNPolicy.
attributeId: 1.2.840.113556.1.4.2294
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: 7CgRLKJao0KzLfCXnKn80g==
systemFlags: 16
instanceType: 4
linkID: 2211
dn: CN=ms-DS-Assigned-AuthN-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AssignedAuthNPolicy
adminDisplayName: Assigned Authentication Policy
adminDescription: This attribute specifies which AuthNPolicy should be applied to this principal.
attributeId: 1.2.840.113556.1.4.2295
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 2Ap6uPdUwUmEoOZNEoU1iA==
systemFlags: 16
instanceType: 4
linkID: 2212
dn: CN=ms-DS-Assigned-AuthN-Policy-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AssignedAuthNPolicyBL
adminDisplayName: Assigned Authentication Policy Backlink
adminDescription: This attribute is the backlink for msDS-AssignedAuthNPolicy.
attributeId: 1.2.840.113556.1.4.2296
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: PBsTLZ/T7kqBXo20vBznrA==
systemFlags: 16
instanceType: 4
linkID: 2213
dn: CN=ms-DS-AuthN-Policy-Enforced,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicyEnforced
adminDisplayName: Authentication Policy Enforced
adminDescription: This attribute specifies whether the authentication policy is enforced.
attributeId: 1.2.840.113556.1.4.2297
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: wgxWekXsukSy1yEjatWf1Q==
instanceType: 4
systemFlags: 16
ldapDisplayName: msDS-AuthNPolicySiloEnforced
adminDisplayName: Authentication Policy Silo Enforced
adminDescription: This attribute specifies whether the authentication policy silo is enforced.
attributeId: 1.2.840.113556.1.4.2298
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: AhH18uBrPUmHJhVGzbyHcQ==
instanceType: 4
systemFlags: 16
dn: CN=ms-DS-AuthN-Policy-Silos,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicySilos
adminDisplayName: Authentication Policy Silos
adminDescription: A container of this class can contain authentication policy silo objects.
governsId: 1.2.840.113556.1.5.291
rdnAttId: cn
schemaIdGuid:: Ckex0oSPHkmnUrQB7gD+XA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-AuthN-Policy-Silos,CN=Schema,CN=Configuration,DC=X
instanceType: 4
systemFlags: 16
subClassOf: top
dn: CN=ms-DS-AuthN-Policies,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicies
adminDisplayName: Authentication Policies
adminDescription: A container of this class can contain authentication policy objects.
governsId: 1.2.840.113556.1.5.293
rdnAttId: cn
schemaIdGuid:: Xd+aOpd7fk+rtOW1XBwGtA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-AuthN-Policies,CN=Schema,CN=Configuration,DC=X
instanceType: 4
systemFlags: 16
subClassOf: top
dn:
changetype: modify
schemaUpdateNow: 1
-
ldapDisplayName: msDS-AuthNPolicySilo
adminDisplayName: Authentication Policy Silo
users, computers, and services.
governsId: 1.2.840.113556.1.5.292
rdnAttId: cn
schemaIdGuid:: Hkbw+X1piUaSmTfmHWF7DQ==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-AuthN-Policy-Silo,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
instanceType: 4
systemmaycontain: msDS-AuthNPolicySiloMembers
systemmaycontain: msDS-UserAuthNPolicy
systemmaycontain: msDS-ComputerAuthNPolicy
systemmaycontain: msDS-ServiceAuthNPolicy
systemmaycontain: msDS-AssignedAuthNPolicySiloBL
systemmaycontain: msDS-AuthNPolicySiloEnforced
subClassOf: top
systemPossSuperiors: msDS-AuthNPolicySilos
ldapDisplayName: msDS-AuthNPolicy
adminDisplayName: Authentication Policy
adminDescription: An instance of this class defines authentication policy behaviors for assigned principals.
governsId: 1.2.840.113556.1.5.294
rdnAttId: cn
schemaIdGuid:: VhFqq8dN9UCRgI5M5C/lzQ==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-AuthN-Policy,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
instanceType: 4
systemmaycontain: msDS-UserAllowedToAuthenticateTo
systemmaycontain: msDS-UserAllowedToAuthenticateFrom
systemmaycontain: msDS-UserTGTLifetime
systemmaycontain: msDS-ComputerAllowedToAuthenticateTo
systemmaycontain: msDS-ComputerTGTLifetime
systemmaycontain: msDS-ServiceAllowedToAuthenticateTo
systemmaycontain: msDS-ServiceAllowedToAuthenticateFrom
systemmaycontain: msDS-ServiceTGTLifetime
systemmaycontain: msDS-UserAuthNPolicyBL
systemmaycontain: msDS-ComputerAuthNPolicyBL
systemmaycontain: msDS-ServiceAuthNPolicyBL
systemmaycontain: msDS-AssignedAuthNPolicyBL
systemmaycontain: msDS-AuthNPolicyEnforced
subClassOf: top
systemPossSuperiors: msDS-AuthNPolicies
dn: CN=user,CN=Schema,CN=Configuration,DC=X
add: systemmaycontain
systemmaycontain: msDS-AssignedAuthNPolicy
systemmaycontain: msDS-AssignedAuthNPolicySilo
systemmaycontain: msDS-AuthNPolicySiloMembersBL
-
objectVersion: 68
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Sch69.ldf
-
-
objectVersion: 69
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Schema Updates in Windows Server 2012

Sch48.ldf
dn: CN=ms-DS-Members-Of-Resource-Property-List,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-MembersOfResourcePropertyList
adminDisplayName: ms-DS-Members-Of-Resource-Property-List
adminDescription: For a resource property list object, this multi-valued link attribute points to one or more
resource property objects.
attributeId: 1.2.840.113556.1.4.2103
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ERw3Ta1MQUyK0rGAqyvRPA==
linkID: 2180
systemFlags: 16
dn: CN=ms-DS-Members-Of-Resource-Property-List-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-MembersOfResourcePropertyListBL
adminDisplayName: ms-DS-Members-Of-Resource-Property-List-BL
adminDescription: Backlink for ms-DS-Members-Of-Resource-Property-List. For a resource property object, this
attribute references the resource property list object that it is a member of.
attributeId: 1.2.840.113556.1.4.2104
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: BLdpdLDtaEWlpVn0hix1pw==
linkID: 2181
systemFlags: 17
dn: CN=ms-DS-Claim-Value-Type,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimValueType
adminDisplayName: ms-DS-Claim-Value-Type
adminDescription: For a claim type object, specifies the value type of the claims issued.
attributeId: 1.2.840.113556.1.4.2098
omSyntax: 65
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: uRdixo7k90e31WVSuK/WGQ==
systemFlags: 16
dn: CN=ms-DS-Claim-Possible-Values,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimPossibleValues
adminDisplayName: ms-DS-Claim-Possible-Values
adminDescription: For a claim type or resource property object, this attribute describes the values suggested
to a user when the he/she use the claim type or resource property in applications.
attributeId: 1.2.840.113556.1.4.2097
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 1048576
schemaIdGuid:: 7u0oLnztP0Wv5JO9hvIXTw==
systemFlags: 16
dn: CN=ms-DS-Claim-Attribute-Source,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimAttributeSource
adminDisplayName: ms-DS-Claim-Attribute-Source
adminDescription: For a claim type object, this attribute points to the attribute that will be used as the
source for the claim type.
attributeId: 1.2.840.113556.1.4.2099
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: PhK87ua6ZkGeWymISot2sA==
systemFlags: 16
dn: CN=ms-DS-Claim-Type-Applies-To-Class,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimTypeAppliesToClass
adminDisplayName: ms-DS-Claim-Type-Applies-To-Class
adminDescription: For a claim type object, this linked attribute points to the AD security principal classes
that for which claims should be issued. (For example, a link to the user class).
attributeId: 1.2.840.113556.1.4.2100
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: TA77anbYfEOutsPkFFTCcg==
linkID: 2176
systemFlags: 16
dn: CN=ms-DS-Claim-Shares-Possible-Values-With,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimSharesPossibleValuesWith
adminDisplayName: ms-DS-Claim-Shares-Possible-Values-With
adminDescription: For a resource property object, this attribute indicates that the suggested values of the
claims issued are defined on the object that this linked attribute points to. Overrides ms-DS-Claim-Possible-
Values on itself, if populated.
attributeId: 1.2.840.113556.1.4.2101
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: OtHIUgvOV0+JKxj1pDokAA==
linkID: 2178
systemFlags: 16
dn: CN=ms-DS-Claim-Shares-Possible-Values-With-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimSharesPossibleValuesWithBL
adminDisplayName: ms-DS-Claim-Shares-Possible-Values-With-BL
adminDescription: For a claim type object, this attribute indicates that the possible values described in ms-
DS-Claim-Possible-Values are being referenced by other claim type objects.
attributeId: 1.2.840.113556.1.4.2102
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 2yLVVJXs9UibvRiA67shgA==
linkID: 2179
systemFlags: 17
dn: CN=ms-DS-Is-Used-As-Resource-Security-Attribute,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-IsUsedAsResourceSecurityAttribute
adminDisplayName: ms-DS-Is-Used-As-Resource-Security-Attribute
adminDescription: For a resource property, this attribute indicates whether it is being used as a secure
attribute.
attributeId: 1.2.840.113556.1.4.2095
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: nfjJUTBHjUaitR1JMhLRfg==
systemFlags: 16
dn: CN=ms-SPP-KMS-Ids,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-KMSIds
adminDisplayName: ms-SPP-KMS-Ids
adminDescription: KMS IDs enabled by the Activation Object
attributeId: 1.2.840.113556.1.4.2082
omSyntax: 4
systemOnly: FALSE
searchFlags: 1
rangeLower: 16
rangeUpper: 16
schemaIdGuid:: 2j5mm0I11kad8DFAJa8rrA==
systemFlags: 16
dn: CN=ms-SPP-CSVLK-Pid,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-CSVLKPid
adminDisplayName: ms-SPP-CSVLK-Pid
adminDescription: ID of CSVLK product-key used to create the Activation Object
attributeId: 1.2.840.113556.1.4.2105
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 512
schemaIdGuid:: DVF/tFBr4Ue1VncseeT/xA==
systemFlags: 16
dn: CN=ms-SPP-CSVLK-Sku-Id,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-CSVLKSkuId
adminDisplayName: ms-SPP-CSVLK-Sku-Id
adminDescription: SKU ID of CSVLK product-key used to create the Activation Object
attributeId: 1.2.840.113556.1.4.2081
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 16
rangeUpper: 16
schemaIdGuid:: OfeElnh7bUeNdDGtdpLu9A==
systemFlags: 16
dn: CN=ms-SPP-Phone-License,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-PhoneLicense
adminDisplayName: ms-SPP-Phone-License
adminDescription: License used during phone activation of the Active Directory forest
attributeId: 1.2.840.113556.1.4.2086
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeUpper: 5242880
schemaIdGuid:: EtnkZ2LzUkCMeUL0W6eyIQ==
systemFlags: 16
dn: CN=ms-SPP-Config-License,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-ConfigLicense
adminDisplayName: ms-SPP-Config-License
adminDescription: Product-key configuration license used during online/phone activation of the Active Directory
forest
attributeId: 1.2.840.113556.1.4.2087
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeUpper: 5242880
schemaIdGuid:: tcRTA5nRsECzxd6zL9nsBg==
systemFlags: 16
dn: CN=ms-SPP-Online-License,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-OnlineLicense
adminDisplayName: ms-SPP-Online-License
adminDescription: License used during online activation of the Active Directory forest
attributeId: 1.2.840.113556.1.4.2085
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeUpper: 5242880
schemaIdGuid:: jjaPCRJIzUivt6E2uWgH7Q==
systemFlags: 16
dn: CN=ms-SPP-Confirmation-Id,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-ConfirmationId
adminDisplayName: ms-SPP-Confirmation-Id
adminDescription: Confirmation ID (CID) used for phone activation of the Active Directory forest
attributeId: 1.2.840.113556.1.4.2084
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 512
schemaIdGuid:: xJeHbtqsSUqHQLC9Bam4MQ==
systemFlags: 16
dn: CN=ms-SPP-Installation-Id,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-InstallationId
adminDisplayName: ms-SPP-Installation-Id
adminDescription: Installation ID (IID) used for phone activation of the Active Directory forest
attributeId: 1.2.840.113556.1.4.2083
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 512
schemaIdGuid:: FLG/aXtAOUeiE8ZjgCs+Nw==
systemFlags: 16
dn: CN=ms-SPP-Issuance-License,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-IssuanceLicense
adminDisplayName: ms-SPP-Issuance-License
adminDescription: Issuance license used during online/phone activation of the Active Directory forest
attributeId: 1.2.840.113556.1.4.2088
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeUpper: 5242880
schemaIdGuid:: obN1EK+70kmujcTyXIIzAw==
systemFlags: 16
dn: CN=ms-SPP-CSVLK-Partial-Product-Key,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-CSVLKPartialProductKey
adminDisplayName: ms-SPP-CSVLK-Partial-Product-Key
adminDescription: Last 5 characters of CSVLK product-key used to create the Activation Object
attributeId: 1.2.840.113556.1.4.2106
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 5
rangeUpper: 5
schemaIdGuid:: kbABplKGOkWzhoetI5t8CA==
systemFlags: 16
dn: CN=ms-TPM-Srk-Pub-Thumbprint,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTPM-SrkPubThumbprint
adminDisplayName: TPM-SrkPubThumbprint
adminDescription: This attribute contains the thumbprint of the SrkPub corresponding to a particular TPM. This
helps to index the TPM devices in the directory.
attributeId: 1.2.840.113556.1.4.2107
omSyntax: 4
systemOnly: FALSE
searchFlags: 11
rangeUpper: 20
schemaIdGuid:: 6wbXGXZNokSF1hw0K+O+Nw==
systemFlags: 16
dn: CN=ms-TPM-Owner-Information-Temp,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTPM-OwnerInformationTemp
adminDisplayName: TPM-OwnerInformationTemp
adminDescription: This attribute contains temporary owner information for a particular TPM.
attributeId: 1.2.840.113556.1.4.2108
omSyntax: 64
systemOnly: FALSE
searchFlags: 640
rangeUpper: 128
schemaIdGuid:: nYCUyBO1+E+IEfT0P1rHvA==
systemFlags: 16
dn: CN=ms-TPM-Tpm-Information-For-Computer,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTPM-TpmInformationForComputer
adminDisplayName: TPM-TpmInformationForComputer
adminDescription: This attribute links a Computer object to a TPM object.
attributeId: 1.2.840.113556.1.4.2109
omSyntax: 127
systemOnly: FALSE
searchFlags: 16
schemaIdGuid:: k3sb6khe1Ua8bE30/aeKNQ==
linkID: 2182
systemFlags: 16
dn: CN=ms-TPM-Tpm-Information-For-Computer-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTPM-TpmInformationForComputerBL
adminDisplayName: TPM-TpmInformationForComputerBL
adminDescription: This attribute links a TPM object to the Computer objects associated with it.
attributeId: 1.2.840.113556.1.4.2110
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: yYT6FM2OSEO8kW087Ucqtw==
linkID: 2183
systemFlags: 17
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-DS-Claim-Types,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimTypes
adminDisplayName: ms-DS-Claim-Types
adminDescription: A container of this class can contain claim type objects.
governsId: 1.2.840.113556.1.5.270
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: NTIJNhXHIUirarVvsoBaWA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Claim-Types,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
ldapDisplayName: msDS-ResourcePropertyList
adminDisplayName: ms-DS-Resource-Property-List
adminDescription: An object of this class contains a list of resource properties.
governsId: 1.2.840.113556.1.5.274
governsId: 1.2.840.113556.1.5.274
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: etTjckKzRU2PVrr/gDyr+Q==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Resource-Property-List,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Resource-Properties,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ResourceProperties
adminDisplayName: ms-DS-Resource-Properties
adminDescription: A container of this class can contain resource properties.
governsId: 1.2.840.113556.1.5.271
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: hEVKelCzj0es1rS4UtgswA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Resource-Properties,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Claim-Type-Property-Base,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimTypePropertyBase
adminDisplayName: ms-DS-Claim-Type-Property-Base
adminDescription: An abstract class that defines the base class for claim type or resource property classes.
governsId: 1.2.840.113556.1.5.269
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: WC9EuJDEh0SKndgLiDJxrQ==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Claim-Type-Property-Base,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Resource-Property,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ResourceProperty
adminDisplayName: ms-DS-Resource-Property
adminDescription: An instance of this class holds the definition of a property on resources.
governsId: 1.2.840.113556.1.5.273
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.269
schemaIdGuid:: Xj0oWwSElUGTOYRQGIxQGg==
schemaIdGuid:: Xj0oWwSElUGTOYRQGIxQGg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Resource-Property,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Claim-Type,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimType
adminDisplayName: ms-DS-Claim-Type
adminDescription: An instance of this class holds the definition of a claim type that can be defined on
security principals.
governsId: 1.2.840.113556.1.5.272
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.269
schemaIdGuid:: fIWjgWlUj02q5sJ2mXYmBA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Claim-Type,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-SPP-Activation-Objects-Container,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-ActivationObjectsContainer
adminDisplayName: ms-SPP-Activation-Objects-Container
adminDescription: Container for Activation Objects used by Active Directory based activation
governsId: 1.2.840.113556.1.5.266
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: K4YvtyW7XU2qUWLFm9+Qrg==
defaultSecurityDescriptor: O:BAG:BAD: (A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-SPP-Activation-Objects-Container,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-SPP-Activation-Object,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-ActivationObject
adminDisplayName: ms-SPP-Activation-Object
adminDescription: Activation Object used in Active Directory based activation
governsId: 1.2.840.113556.1.5.267
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: jOagUcUNykOTXcHJEb8u5Q==
defaultSecurityDescriptor: O:BAG:BAD: (A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-SPP-Activation-Object,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-TPM-Information-Objects-Container,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTPM-InformationObjectsContainer
adminDisplayName: TPM-InformationObjectsContainer
adminDescription: Container for TPM objects.
governsId: 1.2.840.113556.1.5.276
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
systemMustContain: 2.5.4.3
schemaIdGuid:: vagn4FZk3kWQozhZOHfudA==
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;LOLCCCRP;;;DC)
systemOnly: FALSE
defaultObjectCategory: CN=ms-TPM-Information-Objects-Container,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-TPM-Information-Object,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTPM-InformationObject
adminDisplayName: TPM-InformationObject
adminDescription: This class contains recovery information for a Trusted Platform Module (TPM) device.
governsId: 1.2.840.113556.1.5.275
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: alsEhaZHQ0KnzGiQcB9mLA==
(A;;RPLO;;;DC)(A;;WP;;;CO)
systemOnly: FALSE
defaultObjectCategory: CN=ms-TPM-Information-Object,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
dn: CN=Computer,CN=Schema,CN=Configuration,DC=X
-
dn:
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 48
-
Sch49.ldf
dn: CN=ms-DNS-Is-Signed,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-IsSigned
adminDisplayName: ms-DNS-Is-Signed
adminDescription: An attribute used to define whether or not the DNS zone is signed.
attributeId: 1.2.840.113556.1.4.2130
omSyntax: 1
systemOnly: FALSE
searchFlags: 8
schemaIdGuid:: TIUSqvzYXk2RyjaLjYKb7g==
systemFlags: 16
dn: CN=ms-DNS-NSEC3-OptOut,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-NSEC3OptOut
adminDisplayName: ms-DNS-NSEC3-OptOut
adminDescription: An attribute used to define whether or not the DNS zone should be signed using NSEC opt-out.
attributeId: 1.2.840.113556.1.4.2132
omSyntax: 1
systemOnly: FALSE
searchFlags: 8
schemaIdGuid:: iCDqe+KMPEKxkWbsUGsVlQ==
systemFlags: 16
dn: CN=ms-DNS-Signing-Keys,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-SigningKeys
adminDisplayName: ms-DNS-Signing-Keys
adminDescription: An attribute that contains the set of encrypted DNSSEC signing keys used by the DNS server to
sign the DNS zone.
attributeId: 1.2.840.113556.1.4.2144
omSyntax: 4
systemOnly: FALSE
searchFlags: 8
rangeUpper: 10000
schemaIdGuid:: bT5nt9nKnk6zGmPoCY/dYw==
systemFlags: 16
dn: CN=ms-DNS-Sign-With-NSEC3,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-SignWithNSEC3
ldapDisplayName: msDNS-SignWithNSEC3
adminDisplayName: ms-DNS-Sign-With-NSEC3
adminDescription: An attribute used to define whether or not the DNS zone is signed with NSEC3.
attributeId: 1.2.840.113556.1.4.2131
omSyntax: 1
systemOnly: FALSE
searchFlags: 8
schemaIdGuid:: mSGfx6Ft/0aSPB8/gAxyHg==
systemFlags: 16
dn: CN=ms-DNS-NSEC3-User-Salt,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-NSEC3UserSalt
adminDisplayName: ms-DNS-NSEC3-User-Salt
adminDescription: An attribute that defines a user-specified NSEC3 salt string to use when signing the DNS
zone. If empty, random salt will be used.
attributeId: 1.2.840.113556.1.4.2148
omSyntax: 64
systemOnly: FALSE
searchFlags: 8
rangeLower: 0
rangeUpper: 510
schemaIdGuid:: cGfxryKWvE+hKDCId3YFuQ==
systemFlags: 16
dn: CN=ms-DNS-DNSKEY-Records,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-DNSKEYRecords
adminDisplayName: ms-DNS-DNSKEY-Records
adminDescription: An attribute that contains the DNSKEY record set for the root of the DNS zone and the root
key signing key signature records.
attributeId: 1.2.840.113556.1.4.2145
omSyntax: 4
systemOnly: FALSE
searchFlags: 8
rangeUpper: 10000
schemaIdGuid:: 9VjEKC1gyUqnfLPxvlA6fg==
systemFlags: 16
dn: CN=ms-DNS-DS-Record-Set-TTL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-DSRecordSetTTL
adminDisplayName: ms-DNS-DS-Record-Set-TTL
adminDescription: An attribute that defines the time-to-live (TTL) value assigned to DS records when signing
the DNS zone.
attributeId: 1.2.840.113556.1.4.2140
omSyntax: 2
systemOnly: FALSE
searchFlags: 8
rangeLower: 0
rangeUpper: 2592000
schemaIdGuid:: fJuGKcRk/kKX1fvC+hJBYA==
systemFlags: 16
dn: CN=ms-DNS-Keymaster-Zones,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DNS-Keymaster-Zones,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-KeymasterZones
adminDisplayName: ms-DNS-Keymaster-Zones
adminDescription: A list of Active Directory-integrated zones for which the DNS server is the keymaster.
attributeId: 1.2.840.113556.1.4.2128
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: O93gCxoEjEGs6S8X0j6dQg==
systemFlags: 16
dn: CN=ms-DNS-NSEC3-Iterations,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-NSEC3Iterations
adminDisplayName: ms-DNS-NSEC3-Iterations
adminDescription: An attribute that defines how many NSEC3 hash iterations to perform when signing the DNS
zone.
attributeId: 1.2.840.113556.1.4.2138
omSyntax: 2
systemOnly: FALSE
searchFlags: 8
rangeLower: 0
rangeUpper: 10000
schemaIdGuid:: qwq3gFmJwE6OkxJudt86yg==
systemFlags: 16
dn: CN=ms-DNS-Propagation-Time,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-PropagationTime
adminDisplayName: ms-DNS-Propagation-Time
adminDescription: An attribute used to define in seconds the expected time required to propagate zone changes
through Active Directory.
attributeId: 1.2.840.113556.1.4.2147
omSyntax: 2
systemOnly: FALSE
searchFlags: 8
schemaIdGuid:: Rw00uoEhoEyi9vrkR52rKg==
systemFlags: 16
dn: CN=ms-DNS-NSEC3-Current-Salt,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-NSEC3CurrentSalt
adminDisplayName: ms-DNS-NSEC3-Current-Salt
adminDescription: An attribute that defines the current NSEC3 salt string being used to sign the DNS zone.
attributeId: 1.2.840.113556.1.4.2149
omSyntax: 64
systemOnly: FALSE
searchFlags: 8
rangeLower: 0
rangeUpper: 510
schemaIdGuid:: MpR9ONGmdESCzQqJquCErg==
systemFlags: 16
dn: CN=ms-DNS-RFC5011-Key-Rollovers,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-RFC5011KeyRollovers
adminDisplayName: ms-DNS-RFC5011-Key-Rollovers
adminDescription: An attribute that defines whether or not the DNS zone should be maintained using key rollover
procedures defined in RFC 5011.
attributeId: 1.2.840.113556.1.4.2135
omSyntax: 1
systemOnly: FALSE
searchFlags: 8
schemaIdGuid:: QDzZJ1oGwEO92M3yx9Egqg==
systemFlags: 16
dn: CN=ms-DNS-NSEC3-Hash-Algorithm,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-NSEC3HashAlgorithm
adminDisplayName: ms-DNS-NSEC3-Hash-Algorithm
adminDescription: An attribute that defines the NSEC3 hash algorithm to use when signing the DNS zone.
attributeId: 1.2.840.113556.1.4.2136
omSyntax: 2
systemOnly: FALSE
searchFlags: 8
schemaIdGuid:: UlWe/7d9OEGIiAXOMgoDIw==
systemFlags: 16
dn: CN=ms-DNS-DS-Record-Algorithms,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-DSRecordAlgorithms
adminDisplayName: ms-DNS-DS-Record-Algorithms
adminDescription: An attribute used to define the algorithms used when writing the dsset file during zone
signing.
attributeId: 1.2.840.113556.1.4.2134
omSyntax: 2
systemOnly: FALSE
searchFlags: 8
schemaIdGuid:: 0npbXPogu0S+szS5wPZVeQ==
systemFlags: 16
dn: CN=ms-DNS-DNSKEY-Record-Set-TTL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-DNSKEYRecordSetTTL
adminDisplayName: ms-DNS-DNSKEY-Record-Set-TTL
adminDescription: An attribute that defines the time-to-live (TTL) value assigned to DNSKEY records when
signing the DNS zone.
attributeId: 1.2.840.113556.1.4.2139
omSyntax: 2
systemOnly: FALSE
searchFlags: 8
rangeLower: 0
rangeUpper: 2592000
schemaIdGuid:: fzFOj9coLESm3x9JH5ezJg==
systemFlags: 16
dn: CN=ms-DNS-Maintain-Trust-Anchor,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-MaintainTrustAnchor
adminDisplayName: ms-DNS-Maintain-Trust-Anchor
adminDescription: An attribute used to define the type of trust anchor to automatically publish in the forest-
wide trust anchor store when the DNS zone is signed.
attributeId: 1.2.840.113556.1.4.2133
omSyntax: 2
systemOnly: FALSE
searchFlags: 8
schemaIdGuid:: wWPADdlSVkSeFZwkNKr9lA==
systemFlags: 16
dn: CN=ms-DNS-NSEC3-Random-Salt-Length,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-NSEC3RandomSaltLength
adminDisplayName: ms-DNS-NSEC3-Random-Salt-Length
adminDescription: An attribute that defines the length in bytes of the random salt used when signing the DNS
zone.
attributeId: 1.2.840.113556.1.4.2137
omSyntax: 2
systemOnly: FALSE
searchFlags: 8
rangeLower: 0
rangeUpper: 255
schemaIdGuid:: ZRY2E2yR502lnbHrvQ3hKQ==
systemFlags: 16
dn: CN=ms-DNS-Signing-Key-Descriptors,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-SigningKeyDescriptors
adminDisplayName: ms-DNS-Signing-Key-Descriptors
adminDescription: An attribute that contains the set of DNSSEC Signing Key Descriptors (SKDs) used by the DNS
server to generate keys and sign the DNS zone.
attributeId: 1.2.840.113556.1.4.2143
omSyntax: 4
systemOnly: FALSE
searchFlags: 8
rangeUpper: 10000
schemaIdGuid:: zdhDNLblO0+wmGWaAhSgeQ==
systemFlags: 16
dn: CN=ms-DNS-Signature-Inception-Offset,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-SignatureInceptionOffset
adminDisplayName: ms-DNS-Signature-Inception-Offset
adminDescription: An attribute that defines in seconds how far in the past DNSSEC signature validity periods
should begin when signing the DNS zone.
attributeId: 1.2.840.113556.1.4.2141
omSyntax: 2
systemOnly: FALSE
searchFlags: 8
rangeLower: 0
rangeLower: 0
rangeUpper: 2592000
schemaIdGuid:: LsPUAxfiYUqWmXu8RymgJg==
systemFlags: 16
dn: CN=ms-DNS-Parent-Has-Secure-Delegation,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-ParentHasSecureDelegation
adminDisplayName: ms-DNS-Parent-Has-Secure-Delegation
adminDescription: An attribute used to define whether the parental delegation to the DNS zone is secure.
attributeId: 1.2.840.113556.1.4.2146
omSyntax: 1
systemOnly: FALSE
searchFlags: 8
schemaIdGuid:: ZGlcKBrBnkmW2L98daIjxg==
systemFlags: 16
dn: CN=ms-DNS-Secure-Delegation-Polling-Period,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-SecureDelegationPollingPeriod
adminDisplayName: ms-DNS-Secure-Delegation-Polling-Period
adminDescription: An attribute that defines in seconds the time between polling attempts for child zone key
rollovers.
attributeId: 1.2.840.113556.1.4.2142
omSyntax: 2
systemOnly: FALSE
searchFlags: 8
rangeLower: 0
rangeUpper: 2592000
schemaIdGuid:: vvCw9uSoaESP2cPEe4ci+Q==
systemFlags: 16
dn: CN=ms-Authz-Member-Rules-In-Central-Access-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msAuthz-MemberRulesInCentralAccessPolicy
adminDisplayName: ms-Authz-Member-Rules-In-Central-Access-Policy
adminDescription: For a central access policy, this attribute identifies the central access rules that comprise
the policy.
attributeId: 1.2.840.113556.1.4.2155
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ei/yV343w0KYcs7G8h0uPg==
linkID: 2184
systemFlags: 16
dn: CN=ms-Authz-Member-Rules-In-Central-Access-Policy-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msAuthz-MemberRulesInCentralAccessPolicyBL
adminDisplayName: ms-Authz-Member-Rules-In-Central-Access-Policy-BL
adminDescription: Backlink for ms-Authz-Member-Rules-In-Central-Access-Policy. For a central access rule
object, this attribute references one or more central access policies that point to it.
attributeId: 1.2.840.113556.1.4.2156
omSyntax: 127
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: z2duUd3+lES7OrxQapSIkQ==
linkID: 2185
systemFlags: 17
dn: CN=ms-DS-Claim-Source,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimSource
adminDisplayName: ms-DS-Claim-Source
adminDescription: For a claim type, this attribute indicates the source of the claim type. For example, the
source can be certificate.
attributeId: 1.2.840.113556.1.4.2157
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: pvIy+ovy0Ee/kWY+j5EKcg==
systemFlags: 16
dn: CN=ms-Authz-Proposed-Security-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msAuthz-ProposedSecurityPolicy
adminDisplayName: ms-Authz-Proposed-Security-Policy
adminDescription: For a Central Access Policy Entry, defines the proposed security policy of the objects the
CAPE is applied to.
attributeId: 1.2.840.113556.1.4.2151
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: zr5GubUJakuyWktjozDoDg==
systemFlags: 16
dn: CN=ms-DS-Claim-Source-Type,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimSourceType
adminDisplayName: ms-DS-Claim-Source-Type
adminDescription: For a security principal claim type, lists the type of store the issued claim is sourced from
attributeId: 1.2.840.113556.1.4.2158
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: BZzxkvqNIkK70SxPAUh3VA==
systemFlags: 16
dn: CN=ms-Authz-Effective-Security-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msAuthz-EffectiveSecurityPolicy
adminDisplayName: ms-Authz-Security-Policy
adminDescription: For a central access rule, this attribute defines the permission that is applying to the
target resources on the central access rule.
attributeId: 1.2.840.113556.1.4.2150
omSyntax: 64
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: GRmDB5SPtk+KQpFUXcza0w==
systemFlags: 16
dn: CN=ms-DS-Claim-Is-Single-Valued,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimIsSingleValued
adminDisplayName: ms-DS-Claim-Is-Single-Valued
adminDescription: For a claim type object, this attribute identifies if the claim type or resource property can
only contain single value.
attributeId: 1.2.840.113556.1.4.2160
omSyntax: 1
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: uZ94zbSWSEaCGco3gWGvOA==
systemFlags: 16
dn: CN=ms-Authz-Last-Effective-Security-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msAuthz-LastEffectiveSecurityPolicy
adminDisplayName: ms-Authz-Last-Effective-Security-Policy
adminDescription: For a Central Access Policy Entry, defines the security policy that was last applied to the
objects the CAPE is applied to.
attributeId: 1.2.840.113556.1.4.2152
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: xoUWji8+okiljVrw6nifoA==
systemFlags: 16
dn: CN=ms-Authz-Resource-Condition,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msAuthz-ResourceCondition
adminDisplayName: ms-Authz-Resource-Condition
adminDescription: For a central access rule, this attribute is an expression that identifies the scope of the
target resource to which the policy applies.
attributeId: 1.2.840.113556.1.4.2153
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: d3iZgHT4aEyGTW5QioO9vQ==
systemFlags: 16
dn: CN=ms-DS-Claim-Is-Value-Space-Restricted,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimIsValueSpaceRestricted
adminDisplayName: ms-DS-Claim-Is-Value-Space-Restricted
adminDescription: For a claim type, this attribute identifies whether a user can input values other than those
described in the msDS-ClaimPossibleValues in applications.
attributeId: 1.2.840.113556.1.4.2159
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: x+QsDMPxgkSFeMYNS7dEIg==
systemFlags: 16
dn: CN=ms-Authz-Central-Access-Policy-ID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msAuthz-CentralAccessPolicyID
adminDisplayName: ms-Authz-Central-Access-Policy-ID
adminDescription: For a Central Access Policy, this attribute defines a GUID that can be used to identify the
set of policies when applied to a resource.
attributeId: 1.2.840.113556.1.4.2154
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: YJvyYnS+MEaUVi9mkZk6hg==
systemFlags: 16
dn: CN=ms-DS-Generation-Id,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-GenerationId
adminDisplayName: ms-DS-Generation-Id
adminDescription: For virtual machine snapshot resuming detection. This attribute represents the VM Generation
ID.
attributeId: 1.2.840.113556.1.4.2166
omSyntax: 4
rangeLower: 16
rangeUpper: 16
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: PTldHreMT0uECpc7NswJww==
systemFlags: 17
dn: CN=ms-DS-Claim-Shares-Possible-Values-With,CN=Schema,CN=Configuration,DC=X
replace: adminDescription
adminDescription: For a claim type object, indicates that the possible values of the claims issued are defined
on the object this linked attribute points to; overrides msDS-ClaimPossibleValues, msDS-ClaimValueType, and
msDS-ClaimIsValueSpaceRestricted, if populated.
-
-
dn: CN=ms-DNS-Server-Settings,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-ServerSettings
adminDisplayName: ms-DNS-Server-Settings
adminDescription: A container for storing DNS server settings.
governsId: 1.2.840.113556.1.4.2129
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: 7cMv7xhuW0GZ5DEUqMsSSw==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DNS-Server-Settings,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-Authz-Central-Access-Policies,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msAuthz-CentralAccessPolicies
adminDisplayName: ms-Authz-Central-Access-Policies
adminDescription: A container of this class can contain Central Access Policy objects.
governsId: 1.2.840.113556.1.4.2161
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: wyFcVTahWkWTl3lrvTWOJQ==
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;EA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-Authz-Central-Access-Policies,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-Authz-Central-Access-Rules,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msAuthz-CentralAccessRules
adminDisplayName: ms-Authz-Central-Access-Rules
adminDescription: A container of this class can contain Central Access Policy Entry objects.
governsId: 1.2.840.113556.1.4.2162
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: ehu7mW1gi0+ADuFb5VTKjQ==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-Authz-Central-Access-Rules,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-Authz-Central-Access-Rule,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msAuthz-CentralAccessRule
adminDisplayName: ms-Authz-Central-Access-Rule
adminDescription: A class that defines Central Access Rules used to construct a central access policy.
governsId: 1.2.840.113556.1.4.2163
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: 3AZKWxwl206IEwvdcTJyJg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-Authz-Central-Access-Rule,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-Authz-Central-Access-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msAuthz-CentralAccessPolicy
adminDisplayName: ms-Authz-Central-Access-Policy
adminDescription: A class that defines Central Access Policy objects.
governsId: 1.2.840.113556.1.4.2164
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: sJxnpZ1vLEOLdR4+g08Cqg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-Authz-Central-Access-Policy,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Claim-Types,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ms-DS-Resource-Properties,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ms-DS-List-Of-Claim-Types,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ms-DS-Claim-Type,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Dns-Zone,CN=Schema,CN=Configuration,DC=X
-
-
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=DS-Clone-Domain-Controller,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Allow a DC to create a clone of itself
rightsGuid: 3e0f7e18-2c7a-4c10-ba82-4d926db99a3e
appliesTo: 19195a5b-6da0-11d0-afd3-00c04fd930c9
validAccesses: 256
localizationDisplayId: 80
objectVersion: 49
-
Sch50.ldf
dn: CN=ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AllowedToActOnBehalfOfOtherIdentity
adminDisplayName: ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity
adminDescription: This attribute is used for access checks to determine if a requester has permission to act on
the behalf of other identities to services running as this account.
attributeId: 1.2.840.113556.1.4.2182
omSyntax: 66
systemOnly: TRUE
searchFlags: 0
rangeLower: 0
rangeUpper: 132096
schemaIdGuid:: 5cN4P5r3vUaguJ0YEW3ceQ==
systemFlags: 16
dn: CN=ms-Kds-Version,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-Version
adminDisplayName: ms-Kds-Version
adminDescription: Version number of this root key.
attributeId: 1.2.840.113556.1.4.2176
omSyntax: 2
systemOnly: FALSE
searchFlags: 640
schemaIdGuid:: QHPw1bDmSh6Xvg0zGL2dsQ==
systemFlags: 16
dn: CN=ms-Kds-DomainID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-DomainID
adminDisplayName: ms-Kds-DomainID
adminDescription: Distinguished name of the Domain Controller which generated this root key.
attributeId: 1.2.840.113556.1.4.2177
omSyntax: 127
systemOnly: FALSE
searchFlags: 640
schemaIdGuid:: ggRAlgfPTOmQ6PLvxPBJXg==
systemFlags: 16
dn: CN=ms-Kds-KDF-Param,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-KDFParam
adminDisplayName: ms-Kds-KDF-Param
adminDescription: Parameters for the key derivation algorithm.
attributeId: 1.2.840.113556.1.4.2170
omSyntax: 4
systemOnly: FALSE
searchFlags: 640
rangeUpper: 2000
schemaIdGuid:: cgeAirj0TxW0HC5Cce/3pw==
systemFlags: 16
dn: CN=ms-Kds-CreateTime,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-CreateTime
adminDisplayName: ms-Kds-CreateTime
adminDescription: The time when this root key was created.
attributeId: 1.2.840.113556.1.4.2179
omSyntax: 65
systemOnly: FALSE
searchFlags: 640
schemaIdGuid:: nxEYrpBjRQCzLZfbxwGu9w==
systemFlags: 16
dn: CN=ms-Kds-RootKeyData,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-RootKeyData
adminDisplayName: ms-Kds-RootKeyData
adminDescription: Root key.
attributeId: 1.2.840.113556.1.4.2175
omSyntax: 4
systemOnly: FALSE
searchFlags: 640
rangeUpper: 128
schemaIdGuid:: J3xiJqIIQAqhsY3OhbQpkw==
systemFlags: 16
dn: CN=ms-DS-Primary-Computer,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PrimaryComputer
adminDisplayName: ms-DS-Primary-Computer
adminDescription: For a user or group object, identifies the primary computers.
attributeId: 1.2.840.113556.1.4.2167
omSyntax: 127
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: 4vQ9obDb60yCi4suFD6egQ==
linkID: 2186
systemFlags: 16
dn: CN=ms-Kds-UseStartTime,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-UseStartTime
adminDisplayName: ms-Kds-UseStartTime
adminDescription: The time after which this root key may be used.
attributeId: 1.2.840.113556.1.4.2178
omSyntax: 65
systemOnly: FALSE
searchFlags: 640
schemaIdGuid:: fwTcbCL1SreanNlayM39og==
systemFlags: 16
dn: CN=ms-Imaging-Hash-Algorithm,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msImaging-HashAlgorithm
adminDisplayName: ms-Imaging-Hash-Algorithm
adminDescription: Contains the name of the hash algorithm used to create the Thumbprint Hash for the Scan
Repository/Secure Print Device.
attributeId: 1.2.840.113556.1.4.2181
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 64
schemaIdGuid:: tQ3nigZklkGS/vO7VXUgpw==
systemFlags: 16
dn: CN=ms-Kds-KDF-AlgorithmID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-KDFAlgorithmID
adminDisplayName: ms-Kds-KDF-AlgorithmID
adminDescription: The algorithm name of the key derivation function used to compute keys.
attributeId: 1.2.840.113556.1.4.2169
omSyntax: 64
systemOnly: FALSE
searchFlags: 640
rangeUpper: 200
schemaIdGuid:: skgs203RTuyfWK1XnYtEDg==
systemFlags: 16
dn: CN=ms-Imaging-Thumbprint-Hash,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msImaging-ThumbprintHash
adminDisplayName: ms-Imaging-Thumbprint-Hash
adminDescription: Contains a hash of the security certificate for the Scan Repository/Secure Print Device.
attributeId: 1.2.840.113556.1.4.2180
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeUpper: 1024
schemaIdGuid:: xdvfnAQDaUWV9sT2Y/5a5g==
systemFlags: 16
dn: CN=ms-Kds-PublicKey-Length,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-PublicKeyLength
adminDisplayName: ms-Kds-PublicKey-Length
adminDescription: The length of the secret agreement public key.
attributeId: 1.2.840.113556.1.4.2173
omSyntax: 2
systemOnly: FALSE
searchFlags: 640
schemaIdGuid:: cPQ44805SUWrW/afnlg/4A==
systemFlags: 16
dn: CN=ms-Kds-PrivateKey-Length,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-PrivateKeyLength
adminDisplayName: ms-Kds-PrivateKey-Length
adminDescription: The length of the secret agreement private key.
attributeId: 1.2.840.113556.1.4.2174
omSyntax: 2
systemOnly: FALSE
searchFlags: 640
schemaIdGuid:: oUJfYec3SBGg3TAH4Jz8gQ==
systemFlags: 16
dn: CN=ms-DS-Is-Primary-Computer-For,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-IsPrimaryComputerFor
adminDisplayName: ms-DS-Is-Primary-Computer-For
adminDescription: Backlink atribute for msDS-IsPrimaryComputer.
attributeId: 1.2.840.113556.1.4.2168
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: rAaMmYc/TkSl3xGwPcilDA==
schemaIdGuid:: rAaMmYc/TkSl3xGwPcilDA==
linkID: 2187
systemFlags: 17
dn: CN=ms-Kds-SecretAgreement-Param,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-SecretAgreementParam
adminDisplayName: ms-Kds-SecretAgreement-Param
adminDescription: The parameters for the secret agreement algorithm.
attributeId: 1.2.840.113556.1.4.2172
omSyntax: 4
systemOnly: FALSE
searchFlags: 640
rangeUpper: 2000
schemaIdGuid:: MLCZ2e3+dUm4B+ukRNp56Q==
systemFlags: 16
dn: CN=ms-Kds-SecretAgreement-AlgorithmID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-SecretAgreementAlgorithmID
adminDisplayName: ms-Kds-SecretAgreement-AlgorithmID
adminDescription: The name of the secret agreement algorithm to be used with public keys.
attributeId: 1.2.840.113556.1.4.2171
omSyntax: 64
systemOnly: FALSE
searchFlags: 640
rangeUpper: 200
schemaIdGuid:: XZcCF14iSsuxXQ2uqLXpkA==
systemFlags: 16
dn: CN=ms-DS-Value-Type-Reference,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ValueTypeReference
adminDisplayName: ms-DS-Value-Type-Reference
adminDescription: This attribute is used to link a resource property object to its value type.
attributeId: 1.2.840.113556.1.4.2187
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: hF38eNzBSDGJhFj3ktQdPg==
linkID: 2188
systemFlags: 16
dn: CN=ms-DS-Value-Type-Reference-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ValueTypeReferenceBL
adminDisplayName: ms-DS-Value-Type-Reference-BL
adminDescription: This is the back link for ms-DS-Value-Type-Reference. It links a value type object back to
attributeId: 1.2.840.113556.1.4.2188
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
searchFlags: 0
schemaIdGuid:: rUNVq6EjRTu5N5sxPVR0qA==
linkID: 2189
systemFlags: 17
dn: CN=ms-DS-Is-Possible-Values-Present,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-IsPossibleValuesPresent
adminDisplayName: ms-DS-Is-Possible-Values-Present
adminDescription: This attribute identifies if ms-DS-Claim-Possible-Values on linked resource property must
have value or must not have value.
attributeId: 1.2.840.113556.1.4.2186
omSyntax: 1
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: 2tyrb1OMTyCxpJ3wxnwetA==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-Kds-Prov-RootKey,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-ProvRootKey
adminDisplayName: ms-Kds-Prov-RootKey
adminDescription: Root keys for the Group Key Distribution Service.
governsId: 1.2.840.113556.1.5.278
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
systemMustContain: 2.5.4.3
schemaIdGuid:: Qf0CquAXGE+Gh7Ijlklzaw==
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)
systemOnly: FALSE
defaultObjectCategory: CN=ms-Kds-Prov-RootKey,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-Kds-Prov-ServerConfiguration,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-ProvServerConfiguration
adminDisplayName: ms-Kds-Prov-ServerConfiguration
adminDescription: Configuration for the Group Key Distribution Service.
governsId: 1.2.840.113556.1.5.277
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: qEPyXiUqpkWLcwinGuZ3zg==
systemOnly: FALSE
defaultObjectCategory: CN=ms-Kds-Prov-ServerConfiguration,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
dn: CN=Group,CN=Schema,CN=Configuration,DC=X
-
-
-
dn: CN=Organizational-Person,CN=Schema,CN=Configuration,DC=X
-
-
dn: CN=ms-DS-Value-Type,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ValueType
adminDisplayName: ms-DS-Value-Type
adminDescription: An value type object holds value type information for a resource property.
governsId: 1.2.840.113556.1.5.279
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: 33/C4x2wTk+H5wVu7w65Ig==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Value-Type,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=Validated-MS-DS-Behavior-Version,CN=Extended-Rights,CN=Configuration,DC=X
rightsGuid: d31a8757-2447-4545-8081-3bb610cacbf2
appliesTo: f0f8ffab-1191-11d0-a060-00aa006c33ed
displayName: Validated write to MS DS behavior version
validAccesses: 8
dn: CN=Validated-MS-DS-Additional-DNS-Host-Name,CN=Extended-Rights,CN=Configuration,DC=X
rightsGuid: 80863791-dbe9-4eb8-837e-7f0ab55d9ac7
appliesTo: bf967a86-0de6-11d0-a285-00aa003049e2
displayName: Validated write to MS DS Additional DNS Host Name
validAccesses: 8
objectVersion: 50
-
Sch51.ldf
dn: CN=ms-DS-Transformation-Rules,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-TransformationRules
adminDisplayName: ms-DS-Transformation-Rules
adminDescription: Specifies the Transformation Rules for Across-Forest Claims Transformation.
attributeId: 1.2.840.113556.1.4.2189
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: cSuHVbLESDuuUUCV+R7GAA==
systemFlags: 16
dn: CN=ms-DS-Applies-To-Resource-Types,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AppliesToResourceTypes
adminDisplayName: ms-DS-Applies-To-Resource-Types
adminDisplayName: ms-DS-Applies-To-Resource-Types
adminDescription: For a resource property, this attribute indicates what resource types this resource property
applies to.
attributeId: 1.2.840.113556.1.4.2195
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: BiA/aWRXSj2EOVjwSqtLWQ==
systemFlags: 16
dn: CN=ms-DS-Transformation-Rules-Compiled,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-TransformationRulesCompiled
adminDisplayName: ms-DS-Transformation-Rules-Compiled
adminDescription: Blob containing compiled transformation rules.
attributeId: 1.2.840.113556.1.4.2190
omSyntax: 4
systemOnly: TRUE
searchFlags: 128
schemaIdGuid:: EJq0C2tTTbyicwurDdS9EA==
systemFlags: 17
dn: CN=ms-DS-Egress-Claims-Transformation-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-EgressClaimsTransformationPolicy
adminDisplayName: ms-DS-Egress-Claims-Transformation-Policy
adminDescription: This is a link to a Claims Transformation Policy Object for the egress claims (claims leaving
this forest) to the Trusted Domain. This is applicable only for an incoming or bidirectional Across-Forest
Trust. When this link is not present, all claims are allowed to egress as-is.
attributeId: 1.2.840.113556.1.4.2192
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fkI3wXOaQLCRkBsJW7QyiA==
linkID: 2192
systemFlags: 16
dn: CN=ms-DS-Ingress-Claims-Transformation-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-IngressClaimsTransformationPolicy
adminDisplayName: ms-DS-Ingress-Claims-Transformation-Policy
adminDescription: This is a link to a Claims Transformation Policy Object for the ingress claims (claims
entering this forest) from the Trusted Domain. This is applicable only for an outgoing or bidirectional Across-
Forest Trust. If this link is absent, all the ingress claims are dropped.
attributeId: 1.2.840.113556.1.4.2191
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: CEwohm4MQBWLFXUUfSPSDQ==
linkID: 2190
systemFlags: 16
dn: CN=ms-DS-TDO-Egress-BL,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DS-TDO-Egress-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-TDOEgressBL
adminDisplayName: ms-DS-TDO-Egress-BL
adminDescription: Backlink to TDO Egress rules link on object.
attributeId: 1.2.840.113556.1.4.2194
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: KWIA1ROZQiKLF4N2HR4OWw==
linkID: 2193
systemFlags: 17
dn: CN=ms-DS-TDO-Ingress-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-TDOIngressBL
adminDisplayName: ms-DS-TDO-Ingress-BL
adminDescription: Backlink to TDO Ingress rules link on object.
attributeId: 1.2.840.113556.1.4.2193
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: oWFWWsaXS1SAVuQw/nvFVA==
linkID: 2191
systemFlags: 17
dn: CN=ms-DS-ManagedPassword,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ManagedPassword
adminDisplayName: msDS-ManagedPassword
adminDescription: This attribute is the managed password data for a group MSA.
attributeId: 1.2.840.113556.1.4.2196
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: hu1i4yi3QgiyfS3qep3yGA==
systemFlags: 20
dn: CN=ms-DS-ManagedPasswordId,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ManagedPasswordId
adminDisplayName: msDS-ManagedPasswordId
adminDescription: This attribute is the identifier for the current managed password data for a group MSA.
attributeId: 1.2.840.113556.1.4.2197
omSyntax: 4
systemOnly: TRUE
searchFlags: 0
rangeUpper: 1024
schemaIdGuid:: Wil4DtPGQAq0kdYiUf+gpg==
systemFlags: 16
dn: CN=ms-DS-GroupMSAMembership,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DS-GroupMSAMembership,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-GroupMSAMembership
adminDisplayName: msDS-GroupMSAMembership
adminDescription: This attribute is used for access checks to determine if a requester has permission to
retrieve the password for a group MSA.
attributeId: 1.2.840.113556.1.4.2200
omSyntax: 66
systemOnly: FALSE
searchFlags: 0
rangeUpper: 132096
schemaIdGuid:: 1u2OiATOQN+0YrilDkG6OA==
systemFlags: 16
dn: CN=ms-DS-GeoCoordinates-Altitude,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-GeoCoordinatesAltitude
adminDisplayName: ms-DS-GeoCoordinates-Altitude
adminDescription: ms-DS-GeoCoordinates-Altitude
attributeId: 1.2.840.113556.1.4.2183
omSyntax: 65
searchFlags: 1
schemaIdGuid:: twMXoUFWnE2GPl+zMl504A==
systemFlags: 16
dn: CN=ms-DS-GeoCoordinates-Latitude,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-GeoCoordinatesLatitude
adminDisplayName: ms-DS-GeoCoordinates-Latitude
adminDescription: ms-DS-GeoCoordinates-Latitude
attributeId: 1.2.840.113556.1.4.2184
omSyntax: 65
searchFlags: 1
schemaIdGuid:: TtRm3EM99UCFxTwS4WmSfg==
systemFlags: 16
dn: CN=ms-DS-GeoCoordinates-Longitude,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-GeoCoordinatesLongitude
adminDisplayName: ms-DS-GeoCoordinates-Longitude
adminDescription: ms-DS-GeoCoordinates-Longitude
attributeId: 1.2.840.113556.1.4.2185
omSyntax: 65
searchFlags: 1
schemaIdGuid:: ECHElOS66kyFd6+BOvXaJQ==
systemFlags: 16
dn: CN=ms-DS-ManagedPasswordInterval,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ManagedPasswordInterval
adminDisplayName: msDS-ManagedPasswordInterval
adminDescription: This attribute is used to retrieve the number of days before a managed password is
automatically changed for a group MSA.
attributeId: 1.2.840.113556.1.4.2199
omSyntax: 2
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: 9451+HasQ4ii7qJrTcr0CQ==
systemFlags: 16
dn: CN=ms-DS-ManagedPasswordPreviousId,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ManagedPasswordPreviousId
adminDisplayName: msDS-ManagedPasswordPreviousId
adminDescription: This attribute is the identifier for the previous managed password data for a group MSA.
attributeId: 1.2.840.113556.1.4.2198
omSyntax: 4
systemOnly: TRUE
searchFlags: 0
rangeUpper: 1024
schemaIdGuid:: MSHW0EotT9CZ2RxjZGIppA==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-DS-Claims-Transformation-Policies,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimsTransformationPolicies
adminDisplayName: ms-DS-Claims-Transformation-Policies
adminDescription: An object of this class holds the one set of Claims Transformation Policy for Across-Forest
Claims Transformation.
governsId: 1.2.840.113556.1.5.281
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: san8yIh9T7uCekSJJ3EHYg==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Claims-Transformation-Policies,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Claims-Transformation-Policy-Type,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimsTransformationPolicyType
adminDisplayName: ms-DS-Claims-Transformation-Policy-Type
adminDescription: An object of this class holds the one set of Claims Transformation Policy for Across-Forest
Claims Transformation.
governsId: 1.2.840.113556.1.5.280
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: s2LrLnMTRf6BATh/Fnbtxw==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Claims-Transformation-Policy-Type,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
dn: CN=Trusted-Domain,CN=Schema,CN=Configuration,DC=X
-
-
dn: CN=Mail-Recipient,CN=Schema,CN=Configuration,DC=X
add: mayContain
mayContain: 1.2.840.113556.1.4.2183
mayContain: 1.2.840.113556.1.4.2184
mayContain: 1.2.840.113556.1.4.2185
-
dn: CN=ms-DS-Group-Managed-Service-Account,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-GroupManagedServiceAccount
adminDisplayName: msDS-Group-Managed-Service-Account
adminDescription: The group managed service account class is used to create an account which can be shared by
different computers to run Windows services.
governsId: 1.2.840.113556.1.5.282
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.30
systemPossSuperiors: 2.5.6.5
schemaIdGuid:: ilWLe6WT90qtysAX5n8QVw==
defaultSecurityDescriptor: D:(OD;;CR;00299570-246d-11d0-a768-00aa006e0529;;WD)
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPCRLCLORCSDDT;;;CO)(OA;;WP;4c164200-20c0-11d0-a768-00aa006e0529;;CO)(OA;;SW;72e39547-7b18-11d1-adef-
00c04fd8d5cd;;CO)(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;CO)(OA;;WP;3e0abfd0-126a-11d0-a060-
00aa006c33ed;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967a86-
0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;bf967950-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-
00aa003049e2;CO)(OA;;WP;bf967953-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;CO)
(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;PS)(OA;;RPWP;77B5B886-944A-11d1-AEBD-0000F80367C1;;PS)
(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;PS)(A;;RPLCLORC;;;AU)(OA;;RPWP;bf967a7f-0de6-11d0-a285-
00aa003049e2;;CA)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)(OA;;RP;e362ed86-b728-0842-b27d-
00aa003049e2;;CA)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)(OA;;RP;e362ed86-b728-0842-b27d-
2dea7a9df218;;WD)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Group-Managed-Service-Account,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 51
-
Sch52.ldf
dn: CN=ms-DS-RID-Pool-Allocation-Enabled,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-RIDPoolAllocationEnabled
adminDisplayName: ms-DS-RID-Pool-Allocation-Enabled
adminDescription: This attribute indicates whether RID pool allocation is enabled or not.
attributeId: 1.2.840.113556.1.4.2213
omSyntax: 1
instanceType: 4
systemOnly: TRUE
searchFlags: 0
schemaFlagsEx: 1
schemaIdGuid:: jHyXJLfBQDO09is3XrcR1w==
systemFlags: 16
dn: CN=RID-Set-References,CN=Schema,CN=Configuration,DC=X
searchFlags: 8
-
dn: CN=Netboot-DUID,CN=Schema,CN=Configuration,DC=X
cn: Netboot-DUID
ldapDisplayName: netbootDUID
adminDisplayName: Netboot-DUID
adminDescription: This attribute is used to store DHCPv6 DUID device ID.
attributeId: 1.2.840.113556.1.4.2234
omSyntax: 4
instanceType: 4
searchFlags: 1
systemFlags: 16
systemOnly: FALSE
rangeLower: 2
rangeUpper: 128
schemaIdGuid:: vXAlU3c9T0KCLw1jbcbarQ==
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=RID-Manager,CN=Schema,CN=Configuration,DC=X
-
dn: CN=domainDNS-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
add: adminContextMenu
adminContextMenu: 3,{2fb1b669-59ea-4f64-b728-05309f2c11c8}
-
dn: CN=computer-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
add: adminPropertyPages
adminPropertyPages: 13,{2fb1b669-59ea-4f64-b728-05309f2c11c8}
-
dn: CN=Certificate-AutoEnrollment,CN=Extended-Rights,CN=Configuration,DC=X
appliesTo: e5209ca2-3bba-11d2-90cc-00c04fd91ab1
displayname: AutoEnrollment
rightsGuid: a05b8cc2-17bc-4802-a710-e7c15ab866a2
validAccesses: 256
# Update element: computer

add: mayContain
mayContain: 1.2.840.113556.1.4.2234
-
dn: CN=ms-DS-cloudExtensionAttribute1,CN=Schema,CN=Configuration,dc=X
cn: ms-DS-cloudExtensionAttribute1
lDAPDisplayName: msDS-cloudExtensionAttribute1
adminDisplayName: ms-DS-cloudExtensionAttribute1
adminDescription: An attribute used to house an arbitrary cloud-relevant string
attributeID: 1.2.840.113556.1.4.2214
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: r+oJl9pJsk2QigRG5eq4RA==
attributeSecurityGUID:: hri1d0qU0RGuvQAA+ANnwQ==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2215
oMSyntax: 64
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: rOBO88HAqUuCyRqQdS8WpQ==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2216
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: Gsj2gtr6DUqw93BtRoOOtQ==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2217
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: NzS/nG5OW0iykSKwJVQnPw==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2218
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: W+gVKUfjUkiquyLlplHIZA==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2219
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: eSZFYOEo7Eus43EoMzYUVg==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2220
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: GRN8Sk7jwkCdAGD/eJDyBw==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2221
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: FMXRPEmEykSBwAIXgYANKg==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2222
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: LOFjCkAwQUSuJs2Vrw0kfg==
schemaIDGUID:: LOFjCkAwQUSuJs2Vrw0kfg==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2223
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: s/wKZ70T/EeQswpSftgatw==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2224
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: yLuenqV9pkKJJSROEqVuJA==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2225
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: PcQBPAvhyk+Sskz2FdWwmg==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2226
attributeID: 1.2.840.113556.1.4.2226
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: S0a+KJCreUumsN9DdDHQNg==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2227
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: ura8zoBuJ0mFYJj+yghqnw==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2228
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: N9XkqvCKqk2cxmLq24T/Aw==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2229
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: WyGBlZZRU0ChHm/8r8YsTQ==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2230
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: 2m08PehrKUKWfi/1u5O0zg==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2231
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: NDvniKYKaUSYQm6wGzKltQ==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2232
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: mf51CQeWikaOGMgA0zhzlQ==
systemFlags: 16
attributeID: 1.2.840.113556.1.4.2233
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: KGNE9W6LjUmVqCEXSNWs3A==
systemFlags: 16
dn: CN=ms-DS-Cloud-Extensions,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-CloudExtensions
adminDisplayName: ms-DS-Cloud-Extensions
adminDescription: A collection of attributes used to house arbitrary cloud-relevant strings.
governsId: 1.2.840.113556.1.5.283
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
MayContain: 1.2.840.113556.1.4.2214
MayContain: 1.2.840.113556.1.4.2215
MayContain: 1.2.840.113556.1.4.2216
MayContain: 1.2.840.113556.1.4.2217
MayContain: 1.2.840.113556.1.4.2218
MayContain: 1.2.840.113556.1.4.2219
MayContain: 1.2.840.113556.1.4.2220
MayContain: 1.2.840.113556.1.4.2221
MayContain: 1.2.840.113556.1.4.2222
MayContain: 1.2.840.113556.1.4.2223
MayContain: 1.2.840.113556.1.4.2224
MayContain: 1.2.840.113556.1.4.2225
MayContain: 1.2.840.113556.1.4.2226
MayContain: 1.2.840.113556.1.4.2227
MayContain: 1.2.840.113556.1.4.2228
MayContain: 1.2.840.113556.1.4.2229
MayContain: 1.2.840.113556.1.4.2230
MayContain: 1.2.840.113556.1.4.2231
MayContain: 1.2.840.113556.1.4.2232
MayContain: 1.2.840.113556.1.4.2233
schemaIdGuid:: pIceZCaDcUe6LccG3zXjWg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Cloud-Extensions,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
add: systemAuxiliaryClass
systemAuxiliaryClass: 1.2.840.113556.1.5.283
-
dn: CN=Personal-Information,CN=Extended-Rights,CN=Configuration,DC=X
add: appliesTo
appliesTo: 641E87A4-8326-4771-BA2D-C706DF35E35A
-
objectVersion: 52
-
Sch53.ldf
dn: CN=ms-Authz-Central-Access-Rule,CN=Schema,CN=Configuration,DC=X
-
objectVersion: 53
-
Sch54.ldf
dn: CN=User-Account-Restrictions,CN=Extended-Rights,CN=Configuration,DC=X
add: appliesTo
-
dn: CN=ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity,CN=Schema,CN=Configuration,DC=X
replace: attributeSecurityGuid
attributeSecurityGuid:: AEIWTMAg0BGnaACqAG4FKQ==
-
objectVersion: 54
-
Sch55.ldf
dn: CN=DNS-Host-Name-Attributes,CN=Extended-Rights,CN=Configuration,DC=X
add: appliesTo
-
dn: CN=Validated-DNS-Host-Name,CN=Extended-Rights,CN=Configuration,DC=X
add: appliesTo
-
objectVersion: 55
-
Sch56.ldf
# Update element: computer. Remove netboot-DUID from mayContain
delete: mayContain
mayContain: 1.2.840.113556.1.4.2234
-
# Update element: computer. Add netboot-DUID to SystemMayContain

-
objectVersion: 56
-
There are no changes to adprep /rodcprep in Windows Server 2012 R2 or in Windows Server 2012.
Domain-wide schema updates
You can review the following set of changes to help understand and prepare for the schema updates that are
performed by adprep /domainprep in Windows Server.
Beginning in Windows Server 2012, Adprep commands run automatically as needed during AD DS installation.
They can also be run separately in advance of AD DS installation. For more information, see Running Adprep.exe.
For more information about how to interpret the access control entry (ACE ) strings, see ACE strings. For more
information about how to interpret the security ID (SID ) strings, see SID strings.
Windows Server (Semi-Annual Channel): Domain-wide updates

After the operations that are performed by domainprep in Windows Server 2016 (operation 89) complete, the
revision attribute for the CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,DC=ForestRootDomain
object is set to 16.
OPERATIONS NUMBER AND GUID DESCRIPTION PERMISSIONS
Operation 89: {A0C238BA-9E30-4EE6- Delete the ACE granting Full Control to Delete
80A6-43F731E9A5CD} Enterprise Key Admins and add an ACE (A;CI;RPWPCRLCLOCCDCRCWDWOSD
granting Enterprise Key Admins Full DTSW;;;Enterprise Key Admins)
Control over just the
msdsKeyCredentialLink attribute. Add (OA;CI;RPWP;5b47d60f-6090-
40b2-9f37-2a4de88f3063;;Enterprise
Key Admins)
Windows Server 2016: Domain-wide updates

After the operations that are performed by domainprep in Windows Server 2016 (operations 82-88) complete,
the revision attribute for the
CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,DC=ForestRootDomain object is set to 15.
OPERATIONS NUMBER AND

GUID DESCRIPTION ATTRIBUTES PERMISSIONS
Operation 82: {83C53DA7- Create CN=Keys container at - objectClass: container (A;CI;RPWPCRLCLOCCDCRC

427E-47A4-A07A- root of domain - description: Default WDWOSDDTSW;;;EA)
A324598B88F7} container for key credential (A;CI;RPWPCRLCLOCCDCRC
objects WDWOSDDTSW;;;DA)
- ShowInAdvancedViewOnly: (A;CI;RPWPCRLCLOCCDCRC
TRUE WDWOSDDTSW;;;SY)
(A;CI;RPWPCRLCLOCCDCRC
WDWOSDDTSW;;;DD)
(A;CI;RPWPCRLCLOCCDCRC
WDWOSDDTSW;;;ED)
Operation 83: {C81FC9CC- Add Full Control allow aces N/A (A;CI;RPWPCRLCLOCCDCRC
0130-4FD1-B272- to CN=Keys container for WDWOSDDTSW;;;Key
634D74818133} "domain\Key Admins" and Admins)
"rootdomain\Enterprise Key (A;CI;RPWPCRLCLOCCDCRC
Admins". WDWOSDDTSW;;;Enterprise
Key Admins)
Operation 84: {E5F9E791- Modify - otherWellKnownObjects: N/A

D96D-4FC9-93C9- otherWellKnownObjects B:32:683A24E2E8164BD3AF
D53E1DC439BA} attribute to point to the 86AC3C2CF3F981:CN=Keys,
CN=Keys container. %ws
Operation 85: {e6d5fd00- Modify the domain NC to N/A (OA;CI;RPWP;5b47d60f-

385d-4e65-b02d- permit "domain\Key Admins" 6090-40b2-9f37-
9da3493ed850} and "rootdomain\Enterprise 2a4de88f3063;;Key Admins)
Key Admins" to modify the (OA;CI;RPWP;5b47d60f-
msds-KeyCredentialLink 6090-40b2-9f37-
attribute. 2a4de88f3063;;Enterprise
Key Admins in root domain,
but in non-root domains
resulted in a bogus domain-
relative ACE with a non-
resolvable -527 SID)
Operation 86: {3a6b3fbf- Grant the DS-Validated- N/A (OA;CIIO;SW;9b026da6-

3168-4312-a10d- Write-Computer CAR to 0d3c-465c-8bee-
dd5b3393952d} creator owner and self 5199d7165cba;bf967a86-
0de6-11d0-a285-
00aa003049e2;PS)
(OA;CIIO;SW;9b026da6-
0d3c-465c-8bee-
5199d7165cba;bf967a86-
0de6-11d0-a285-
00aa003049e2;CO)
Operation 87: {7F950403- Delete the ACE granting Full N/A Delete
0AB3-47F9-9730- Control to the incorrect (A;CI;RPWPCRLCLOCCDCRC
5D7B0269F9BD} domain-relative Enterprise WDWOSDDTSW;;;Enterprise
Key Admins group, and add Key Admins)
an ACE granting Full Control
to Enterprise Key Admins Add
group. (A;CI;RPWPCRLCLOCCDCRC
WDWOSDDTSW;;;Enterprise
Key Admins)
Operation 88: {434bb40d- Add "msDS- N/A N/A

dbc9-4fe7-81d4- ExpirePasswordsOnSmartCar
d57229f7b080} dOnlyAccounts" on the
domain NC object and set
default value to FALSE
The Enterprise Key Admins and Key Admins groups are only created after a Windows Server 2016 Domain
Controller is promoted and takes over the PDC Emulator FSMO role.
Windows Server 2012 R2: Domain-wide updates

Although no operations are performed by domainprep in Windows Server 2012 R2, after the command
completes, the revision attribute for the
Windows Server 2012: Domain-wide updates

After the operations that are performed by domainprep in Windows Server 2012 (operations 78, 79, 80, and 81)
complete, the revision attribute for the

Operation 78: {c3c927a6- Create a new object Object class: msTPM- N/A
cc1d-47c0-966b- CN=TPM Devices in the InformationObjectsContainer
be8f9b63d991} Domain partition.
Operation 79: {54afcfb9- Created an access control N/A (OA;CIIO;WP;ea1b7b93-

637a-4251-9f47- entry for the TPM service. 5e48-46d5-bc6c-
4d50e7021211} 4df4fda78a35;bf967a86-
0de6-11d0-a285-
00aa003049e2;PS)
Operation 80: {f4728883- Grant "Clone DC" extended N/A (OA;;CR;3e0f7e18-2c7a-

84dd-483c-9897- right to Cloneable Domain 4c10-ba82-
274f2ebcf11e} Controllers group 4d926db99a3e;;domain
SID-522)
Operation 81: {ff4f9d27- Grant ms-DS-Allowed-To- N/A (OA;CIOI;RPWP;3f78c3e5-

7157-4cb0-80a9- Act-On-Behalf-Of-Other- f79a-46bd-a0b8-
5d6f2b14c8ff} Identity to Principal Self on 9d18116ddc79;;PS)
all objects.
Forest-Wide Updates
You can review the following set of changes to help understand and prepare for the schema updates that are
performed by adprep /forestprep in Windows Server 2019.
Beginning in Windows Server 2012, Adprep commands run automatically as needed during AD DS installation.
They can also be run separately in advance of AD DS installation. For more information, see Running Adprep.exe.
For more information about how to interpret the access control entry (ACE ) strings, see ACE strings. For more
information about how to interpret the security ID (SID ) strings, see SID strings.
Windows Server 2016: Forest-wide updates

After the operations that are performed by the forestprep command in Windows Server 2016 (operations 136-
142) are complete, the revision attribute for the
CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=ForestRootDomain object is set to 16.
OPERATION NUMBER AND

Operation 136: {328092FB- Granting the "CN=Send- N/A N/A

16E7-4453-9AB8- As,CN=Extended-Rights" to
7592DB56E9C4} gMSA accounts.
Operation 137: {3A1C887F- Granting the "CN=Receive- N/A N/A

DF0A-489F-B3F2- As,CN=Extended-Rights" to
2D0409095F6E} gMSA accounts.
Operation 138: {232E831F- Granting the "CN=Personal- N/A N/A

F988-4444-8E3E- Information,CN=Extended-
8A352E2FD411} Rights" to gMSA accounts.
Operation 139: Granting the "CN=Public- N/A N/A

{DDDDCF0C-BEC9-4A5A- Information,CN=Extended-
AE86-3CFE6CC6E110} Rights" to gMSA accounts.
Operation 140: Granting the "CN=Validated- N/A N/A

{A0A45AAC-5550-42DF- SPN,CN=Extended-Rights"
BB6A-3CC5C46B52F2} to gMSA accounts.
Operation 141: {3E7645F3- Granting the "CN=Allowed- N/A N/A

3EA5-4567-B35A- To-
87630449C70C} Authenticate,CN=Extended-
Rights" to gMSA accounts.
Operation 142: {E634067B- Granting the "CN=MS-TS- N/A N/A

E2C4-4D79-B6E8- GatewayAccess,CN=Extende
73C619324D5E} d-Rights" to gMSA accounts.
Windows Server 2012 R2: Forest-wide updates
After the operations that are performed by the forestprep command in Windows Server 2012 R2 (operations 131-
135) are complete, the revision attribute for the

Operation 131: {b83818c1- Created a new - objectClass: container (A;;RPLCLORC;;;AU)

01a6-4f39-91b7- authentication policy - displayName: (A;;RPWPCRLCLOCCRCWDW
a3bb581c3ae3} configuration container Authentication Policy OSW;;;EA)
object CN=AuthN Policy Configuration (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services - description: Contains DWOSDDTSW;;;SY)
in the Configuration configuration for
partition. authentication policy.
- showInAdvancedViewOnly:
True
Operation 132: {bbbb9db0- Created a new - objectClass: msDS- (A;;RPWPCRCCDCLCLOLOR

4009-4368-8c40- authentication policies object AuthNPolicies CWOWDSDDTDTSW;;;EA)
6674e980d3c3} CN=AuthN - displayName: (A;;RPWPCRCCDCLCLORCW
Policies,CN=AuthN Policy Authentication Policies OWDSDDTSW;;;SY)
Configuration,CN=Services - description: Contains (A;;RPLCLORC;;;AU)
in the Configuration authentication policy objects.
partition. - showInAdvancedViewOnly:
True
Operation 133: {f754861c- Created a new - objectClass: msDS- (A;;RPWPCRCCDCLCLOLOR

3692-4a7b-b2c2- authentication policy silos AuthNPolicySilos CWOWDSDDTDTSW;;;EA)
d0fa28ed0b0b} object CN=AuthN - displayName: (A;;RPWPCRCCDCLCLORCW
Silos,CN=AuthN Policy Authentication Policy Silos OWDSDDTSW;;;SY)
Configuration,CN=Services - description: Contains (A;;RPLCLORC;;;AU)
in the Configuration authentication policy silo
partition. objects.
True
Operation 134: {d32f499f- Created a new - objectClass: msDS- (A;;RPWPCRCCDCLCLORCW

3026-4af0-a5bd- authentication silo claim type ClaimType OWDSDDTSW;;;EA)
13fe5a331bd2} object - displayname: (A;;RPWPCRCCDCLCLORCW
CN=ad://ext/AuthenticationS AuthenticationSilo OWDSDDTSW;;;SY)
ilo,CN=Claim - name: (A;;RPLCLORC;;;AU)
Types,CN=Claims ad://ext/AuthenticationSilo
Configuration,CN=Services - Enabled: True
in the Configuration - msDS-
partition. ClaimIsValueSpaceRestricted:
True
- msDS-ClaimIsSingleValued:
True
- msDS-ClaimSourceType:
Constructed
- msDS-ClaimValueType: 3
- msDS-
ClaimTypeAppliesToClass:
CN=User,CN=Schema,%ws
- msDS-
CN=Computer,CN=Schema,
%ws
- msDS-
CN=ms-DS-Managed-
Service-
Account,CN=Schema,%ws
- msDS-
CN=ms-DS-Group-
Managed-Service-
Account,CN=Schema,%ws
Operation 135: {38618886- Set the msDS- - msDS- N/A

98ee-4e42-8cf1- ClaimIsValueSpaceRestricted ClaimIsValueSpaceRestricted:
d9a2cd9edf8b} attribute on new False
authentication silo claim type
to false
Windows Server 2012: Forest-wide updates

After the operations that are performed by the forestprep command in Windows Server 2012 (operations 84-130)
are complete, the revision attribute for the

Operation 84: {4664e973- Created a new container - objectClass: container (A;;RPLCLORC;;;AU)

cb20-4def-b3d5- CN=Claims (A;;RPWPCRLCLOCCRCWDW
559d6fe123e0} Configuration,CN=Services OSW;;;EA)
in the Configuration (A;;RPWPCRLCLOCCDCRCW
partition. DWOSDDTSW;;;SY)
Operation 85: {2972d92d- Created a new object - objectClass: msDS- (A;;RPLCLORC;;;AU)

a07a-44ac-9cb0- CN=Claim Types,CN=Claims ClaimTypes (A;;RPWPCRLCLOCCDCRCW
bf243356f345} Configuration,CN=Services - showInAdvancedViewOnly: DWOSW;;;EA)
in the Configuration True (A;;RPWPCRLCLOCCDCRCW
partition. DWOSDDTSW;;;SY)
Operation 86: {09a49cb3- Created a new object - objectClass: msDS- (A;;RPLCLORC;;;AU)

6c54-4b83-ab20- CN=Resource ResourceProperties (A;;RPWPCRLCLOCCDCRCW
8370838ba149} Properties,CN=Claims - showInAdvancedViewOnly: DWOSW;;;EA)
Configuration,CN=Services True (A;;RPWPCRLCLOCCDCRCW
in the Configuration DWOSDDTSW;;;SY)
partition.
Operation 87: {77283e65- Created a new container - objectClass: container (A;;RPLCLORC;;;AU)

ce02-4dc3-8c1e- CN=Resource Property - showInAdvancedViewOnly: (A;;RPWPCRLCLOCCDCRCW
bf99b22527c2} Lists,CN=Claims True DWOSW;;;EA)
Configuration,CN=Services (A;;RPWPCRLCLOCCDCRCW
partition.
Operation 88: {0afb7f53- Created a new object N/A Created the following access
96bd-404b-a659- CN=Sam-Domain in the control entry (ACE) to grant
89e65c269420} Schema partition. Write Property to Principal
Self on the object:
(OA;CIIO;WP;ea1b7b93-
5e48-46d5-bc6c-
4df4fda78a35;bf967a86-
0de6-11d0-a285-
00aa003049e2;PS)
Operation 89: {c7f717ef- Created a new object N/A Created the following access
fdbe-4b4b-8dfc- CN=Domain-DNS in the control entry (ACE) to grant
fa8b839fbcfa} Schema partition. Write Property to Principal
Self on the object:
(OA;CIIO;WP;ea1b7b93-
5e48-46d5-bc6c-
4df4fda78a35;bf967a86-
0de6-11d0-a285-
00aa003049e2;PS)
Operation 90: {00232167- Call back function to N/A N/A

f3a4-43c6-b503- upgrade display specifiers.
9acb7a81b01c}
Operation 91: {73a9515b- Created a new container - objectClass: container (A;;RPLCLORC;;;AU)

511c-44d2-822b- CN=Microsoft - showInAdvancedViewOnly: (A;;RPWPCRLCLOCCRCWDW
444a33d3bd33} SPP,CN=Services in the True OSW;;;EA)
Configuration partition. (A;;RPWPCRLCLOCCDCRCW
DWOSDDTSW;;;SY)
Operation 92: {e0c60003- Created a new Activation - objectClass: msSPP- (A;;RPLCLORC;;;AU)

2ed7-4fd3-8659- Objects container ActivationObjectsContainer (A;;RPWPCRLCLOCCRCWDW
7655a7e79397} CN=Activation - showInAdvancedViewOnly: OSW;;;EA)
Objects,CN=Microsoft True (A;;RPWPCRLCLOCCDCRCW
SPP,CN=Services in the DWOSDDTSW;;;SY)
Configuration partition.
Operation 93: {ed0c8cca- Created a new Central - objectClass: msAuthz- (A;;RPLCLORC;;;AU)

80ab-4b6b-ac5a- Access Policies container CentralAccessPolicies (A;;RPWPCRLCLOCCDCRCW
59b1d317e11f} CN=Central Access - showInAdvancedViewOnly: DWOSW;;;EA)
Policies,CN=Claims True (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services DWOSDDTSW;;;SY)
in the Configuration
partition.
Operation 94: {b6a6c19a- Created a new Central - objectClass: msAuthz- (A;;RPLCLORC;;;AU)

afc9-476b-8994- Access Policy Entries CentralAccessRules (A;;RPWPCRLCLOCCDCRCW
61f5b14b3f05} container CN=Central Access - showInAdvancedViewOnly: DWOSW;;;EA)
Rules,CN=Claims True (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services DWOSDDTSW;;;SY)
partition.
Operation 95: {defc28cd- Created a new Group Key - objectClass: container (A;;RPLCLORC;;;AU)
6cb6-4479-8bcb- Distribution service - description: The container (A;;RPWPCRLCLOCCRCWDW
aabfb41e9713} container CN=Group Key contains configuration and OSW;;;EA)
Distribution data for Group Key (A;;RPWPCRLCLOCCDCRCW
Service,CN=Services in the Distribution Service. DWOSDDTSW;;;SY)
Configuration partition. - showInAdvancedViewOnly:
True
Operation 96: {d6bd96d4- Created a new Master Root - objectClass: container (A;;RPLCLORC;;;AU)
e66b-4a38-9c6b- Keys container CN=Master - description: The container (A;;RPWPCRLCLOCCRCWDW
e976ff58c56d} Root Keys,CN=Group Key contains master root keys OSW;;;EA)
Distribution for Group Key Distribution (A;;RPWPCRLCLOCCDCRCW
Service,CN=Services in the Service. DWOSDDTSW;;;SY)
True
Operation 97: {bb8efc40- Created a new Server - objectClass: container (A;;RPLCLORC;;;AU)

3090-4fa2-8a3f- Configuration container - description: The container (A;;RPWPCRLCLOCCRCWDW
7cd1d380e695} CN=Server contains Group Key OSW;;;EA)
Configuration,CN=Group Distribution Service (A;;RPWPCRLCLOCCDCRCW
Key Distribution configurations. DWOSDDTSW;;;SY)
Service,CN=Services in the - showInAdvancedViewOnly:
Configuration partition. True
Operation 98: {2d6abe1b- Created a new Empty server - objectClass: msKds- (A;;RPLCLORC;;;AU)
4326-489e-920c- configuration objects ProvServerConfiguration (A;;RPWPCRLCLOCCRCWDW
76d5337d2dc5} container CN=Group Key - description: The OSW;;;EA)
Distribution Service Server configuration of (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Server cryptography algorithms DWOSDDTSW;;;SY)
Configuration,CN=Group used by Group Key
Key Distribution Distribution Service.
Service,CN=Services in the - msKds-Version: 1
True
Operation 99: {6b13dfb5- Created a new Claims - objectClass: msDS- (A;;RPLCLORC;;;AU)

cecc-4fb8-b28d- Transformation Policies ClaimsTransformationPolicies (A;;RPWPCRLCLOCCDCRCW
0505cea24175} configuration container - showInAdvancedViewOnly: DWOSW;;;EA)
CN=Claims Transformation True (A;;RPWPCRLCLOCCDCRCW
Policies,CN=Claims DWOSDDTSW;;;SY)
Configuration,CN=Services
partition.
Operation 100: {92e73422- Created a new Value Types - objectClass: container (A;;RPLCLORC;;;AU)
c68b-46c9-b0d5- configuration container - showInAdvancedViewOnly: (A;;RPWPCRLCLOCCRCWDW
b55f9c741410} CN=Value Types,CN=Claims True OSW;;;EA)
Configuration,CN=Services (A;;RPWPCRLCLOCCDCRCW
partition.
Operation 101: {c0ad80b4- Created a new - objectClass: msDS- (D;;SDDT;;;WD)

8e84-4cc4-9163- SinglevaluedChoice value ValueType (A;;RPLCLORC;;;AU)
2f84649bcc42} type configuration object - description: You can use (A;;RPWPCRLCLOCCRCWDW
CN=MS-DS- this type to author a OSW;;;EA)
SinglevaluedChoice,CN=Valu resource property. When (A;;RPWPCRLCLOCCDCRCW
e Types,CN=Claims assigning value to a resource DWOSDDTSW;;;SY)
Configuration,CN=Services property of this value type, a
in the Configuration user can choose only one
partition. entry from a list of
suggested values.
- displayname: Single-valued
Choice
- msDS-
ClaimIsValueSpaceRestricted:
True
True
- msDS-
IsPossibleValuesPresent: True
True
Operation 102: {992fe1d0- Created a new YesNo value - objectClass: msDS- (D;;SDDT;;;WD)
6591-4f24-a163- type configuration object ValueType (A;;RPLCLORC;;;AU)
c820fcb7f308} CN=MS-DS- - description: The valid (A;;RPWPCRLCLOCCRCWDW
YesNo,CN=Value values for this type are Yes OSW;;;EA)
Types,CN=Claims or No. (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services - displayname: Yes/No DWOSDDTSW;;;SY)
in the Configuration - msDS-ClaimValueType: 6
partition. - msDS-
False
True
- msDS-
IsPossibleValuesPresent:
False
True
Operation 103: {ede85f96- Created a new Number value - objectClass: msDS- (D;;SDDT;;;WD)
7061-47bf-b11b- type configuration object ValueType (A;;RPLCLORC;;;AU)
0c0d999595b5} CN=MS-DS- - description: You can use (A;;RPWPCRLCLOCCRCWDW
Number,CN=Value this type to author resource OSW;;;EA)
Types,CN=Claims properties that contain a (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services single number. DWOSDDTSW;;;SY)
in the Configuration - displayname: Number
partition. - msDS-ClaimValueType: 1
- msDS-
False
True
- msDS-
False
True
Operation 104: {ee0f3271- Created a new DateTime - objectClass: msDS- (D;;SDDT;;;WD)

eb51-414a-bdac- value type configuration ValueType (A;;RPLCLORC;;;AU)
8f9ba6397a39} object CN=MS-DS- - description: You can use (A;;RPWPCRLCLOCCRCWDW
DateTime,CN=Value this type to author resource OSW;;;EA)
Types,CN=Claims properties that are of the (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services date and time format. DWOSDDTSW;;;SY)
in the Configuration - displayname: Date Time
- msDS-
False
True
- msDS-
False
True
Operation 105: {587d52e0- Created a new OrderedList - objectClass: msDS- (D;;SDDT;;;WD)

507e-440e-9d67- value type configuration ValueType (A;;RPLCLORC;;;AU)
e6129f33bb68} object CN=MS-DS- - description: You can use (A;;RPWPCRLCLOCCRCWDW
OrderedList,CN=Value this type to author resource OSW;;;EA)
Types,CN=Claims properties that contain a (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services single choice entry that can DWOSDDTSW;;;SY)
in the Configuration be compared to other
partition. resource properties of the
same type. A user typically
chooses the entry from a list
of ordered suggested values
that are provided by ms-DS-
Claim-Possible-Values on the
- displayname: Ordered List
- msDS-
True
True
- msDS-
True
Operation 106: {ce24f0f6- Created a new Text value - objectClass: msDS- (D;;SDDT;;;WD)
237e-43d6-ac04- type configuration object ValueType (A;;RPLCLORC;;;AU)
1e918ab04aac} CN=MS-DS-Text,CN=Value - description: You can use (A;;RPWPCRLCLOCCRCWDW
Types,CN=Claims this type to author resource OSW;;;EA)
Configuration,CN=Services properties that contain a (A;;RPWPCRLCLOCCDCRCW
in the Configuration single text entry. DWOSDDTSW;;;SY)
partition. - displayname: Text
- msDS-
False
True
- msDS-
False
True
Operation 107: {7f77d431- Created a new - objectClass: msDS- (D;;SDDT;;;WD)

dd6a-434f-ae4d- MultivaluedText value type ValueType (A;;RPLCLORC;;;AU)
ce82928e498f} configuration object - description: You can use (A;;RPWPCRLCLOCCRCWDW
CN=MS-DS- this type to author resource OSW;;;EA)
MultivaluedText,CN=Value properties that can have (A;;RPWPCRLCLOCCDCRCW
Types,CN=Claims multiple text entries. DWOSDDTSW;;;SY)
Configuration,CN=Services - displayname: Multi-valued
in the Configuration Text
- msDS-
False
False
- msDS-
False
True
Operation 108: {ba14e1f6- Created a new - objectClass: msDS- (D;;SDDT;;;WD)

7cd1-4739-804f- MultivaluedChoice value ValueType (A;;RPLCLORC;;;AU)
57d0ea74edf4} type configuration object - description: You can use (A;;RPWPCRLCLOCCRCWDW
CN=MS-DS- this type to author resource OSW;;;EA)
MultivaluedChoice,CN=Value properties that can have (A;;RPWPCRLCLOCCDCRCW
Types,CN=Claims multiple entries that cannot DWOSDDTSW;;;SY)
Configuration,CN=Services be compared. A user
in the Configuration typically chooses each entry
partition. from a list of suggested
values that are provided by
ms-DS-Claim-Possible-
Values on the resource
properties.
- displayname: Multi-valued
Choice
- msDS-
True
False
- msDS-
True
Operation 109: {156ffa2a- Created a new Personally - objectClass: msDS- (D;;SDDT;;;WD)

e07c-46fb-a5c4- Identifiable Information ResourceProperty (A;;RPLCLORC;;;AU)
fbd84a4e5cce} resource property object - description: The Personally (A;;RPWPCRLCLOCCRCWDW
CN=PII_MS,CN=Resource Identifiable Information (PII) OSW;;;EA)
Properties,CN=Claims property specifies whether (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services the resource contains PII and DWOSDDTSW;;;SY)
in the Configuration if it does, what the sensitivity
partition. level of that information is.
- displayname: Personally
Identifiable Information
- Enabled: False
- msDS-
IsUsedAsResourceSecurityAtt
ribute: True
- msDS-ValueTypeReference:
CN=MS-DS-
OrderedList,CN=Value
Types,CN=Claims
Configuration,CN=Services,C
N=Configuration,CN=
Operation 110: {7771d7dd- Created a new Protected - objectClass: msDS- (D;;SDDT;;;WD)

2231-4470-aa74- Health Information resource ResourceProperty (A;;RPLCLORC;;;AU)
84a6f56fc3b6} property object - description: The Protected (A;;RPWPCRLCLOCCRCWDW
CN=ProtectedHealthInforma Health Information (PHI) OSW;;;EA)
tion_MS,CN=Resource property specifies whether (A;;RPWPCRLCLOCCDCRCW
Properties,CN=Claims the resource contains any DWOSDDTSW;;;SY)
Configuration,CN=Services data related to an
in the Configuration individual's medical record or
partition. medical payment history.
- displayname: Protected
Health Information
- Enabled: False
- msDS-
ribute: True
CN=MS-DS-
YesNo,CN=Value
Types,CN=Claims
N=Configuration,CN=
Operation 111: {49b2ae86- Created a new Required - objectClass: msDS- (D;;SDDT;;;WD)

839a-4ea0-81fe- Clearance resource property ResourceProperty (A;;RPLCLORC;;;AU)
9171c1b98e83} object - description: The Required (A;;RPWPCRLCLOCCRCWDW
CN=RequiredClearance_MS, Clearance property specifies OSW;;;EA)
CN=Resource the level of clearance a user (A;;RPWPCRLCLOCCDCRCW
Properties,CN=Claims should possess before DWOSDDTSW;;;SY)
Configuration,CN=Services attempting to access the
in the Configuration resource.
partition. - displayname: Required
Clearance
- Enabled: False
- msDS-
ribute: True
CN=MS-DS-
Types,CN=Claims
N=Configuration,CN=
Operation 112: {1b1de989- Created a new - objectClass: msDS- (D;;SDDT;;;WD)

57ec-4e96-b933- Confidentiality resource ResourceProperty (A;;RPLCLORC;;;AU)
8279a8119da4} property object - description: The (A;;RPWPCRLCLOCCRCWDW
CN=Confidentiality_MS,CN= Confidentiality property OSW;;;EA)
Resource specifies the level of (A;;RPWPCRLCLOCCDCRCW
Properties,CN=Claims confidentiality of the DWOSDDTSW;;;SY)
Configuration,CN=Services resource, and the potential
in the Configuration impact of inadvertent access
partition. or disclosure.
- displayname:
Confidentiality
- Enabled: False
- msDS-
ribute: True
CN=MS-DS-
Types,CN=Claims
N=Configuration,CN=
Operation 113: {281c63f0- Created a new Compliancy - objectClass: msDS- (D;;SDDT;;;WD)

2c9a-4cce-9256- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
a238c23c0db9} CN=Compliancy_MS,CN=Re - description: The (A;;RPWPCRLCLOCCRCWDW
source Properties,CN=Claims Compliancy property OSW;;;EA)
Configuration,CN=Services specifies the compliance (A;;RPWPCRLCLOCCDCRCW
in the Configuration frameworks that apply to the DWOSDDTSW;;;SY)
partition. resource.
- displayname: Compliancy
- Enabled: False
- msDS-
ribute: True
CN=MS-DS-
MultivaluedChoice,CN=Value
Types,CN=Claims
N=Configuration,CN=
Operation 114: {4c47881a- Created a new - objectClass: msDS- (D;;SDDT;;;WD)

f15a-4f6c-9f49- Discoverability resource ResourceProperty (A;;RPLCLORC;;;AU)
2742f7a11f4b} property object - description: The (A;;RPWPCRLCLOCCRCWDW
CN=Discoverability_MS,CN= Discoverability property OSW;;;EA)
Resource specifies whether the (A;;RPWPCRLCLOCCDCRCW
Properties,CN=Claims resource contains potential DWOSDDTSW;;;SY)
Configuration,CN=Services evidence that might require
in the Configuration disclosure to opposing legal
partition. counsel during the course of
current or future litigation.
- displayname:
Discoverability
- Enabled: False
- msDS-
ribute: True
CN=MS-DS-
SinglevaluedChoice,CN=Valu
e Types,CN=Claims
N=Configuration,CN=
Operation 115: {2aea2dc6- Created a new Immutable - objectClass: msDS- (D;;SDDT;;;WD)

d1d3-4f0c-9994- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
66c1da21de0f} CN=Immutable_MS,CN=Res - description: The Immutable (A;;RPWPCRLCLOCCRCWDW
ource Properties,CN=Claims property specifies whether a OSW;;;EA)
Configuration,CN=Services user should be allowed to (A;;RPWPCRLCLOCCDCRCW
in the Configuration delete a resource or change DWOSDDTSW;;;SY)
partition. its contents.
- displayname: Immutable
- Enabled: False
- msDS-
ribute: True
CN=MS-DS-
YesNo,CN=Value
Types,CN=Claims
N=Configuration,CN=
Operation 116: {ae78240c- Created a new Intellectual - objectClass: msDS- (D;;SDDT;;;WD)

43b9-499e-ae65- Property resource property ResourceProperty (A;;RPLCLORC;;;AU)
2b6e0f0e202a} object - description: The Intellectual (A;;RPWPCRLCLOCCRCWDW
CN=IntellectualProperty_MS, Property (IP) property OSW;;;EA)
CN=Resource specifies whether the (A;;RPWPCRLCLOCCDCRCW
Properties,CN=Claims resource contains IP, and if DWOSDDTSW;;;SY)
Configuration,CN=Services so, what kind.
in the Configuration - displayname: Intellectual
partition. Property
- Enabled: False
- msDS-
ribute: True
CN=MS-DS-
e Types,CN=Claims
N=Configuration,CN=
Operation 117: {261b5bba- Created a new Department - objectClass: msDS- (D;;SDDT;;;WD)

3438-4d5c-a3e9- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
7b871e5f57f0} CN=Department_MS,CN=Re - description: The (A;;RPWPCRLCLOCCRCWDW
source Properties,CN=Claims Department property OSW;;;EA)
Configuration,CN=Services specifies the name of the (A;;RPWPCRLCLOCCDCRCW
in the Configuration department to which the DWOSDDTSW;;;SY)
partition. resource belongs.
- displayname: Department
- Enabled: False
- msDS-
ribute: True
CN=MS-DS-
e Types,CN=Claims
N=Configuration,CN=
Operation 118: {3fb79c05- Created a new Impact - objectClass: msDS- (D;;SDDT;;;WD)

8ea1-438c-8c7a- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
81f213aa61c2} CN=Impact_MS,CN=Resourc - description: The Impact (A;;RPWPCRLCLOCCRCWDW
e Properties,CN=Claims property specifies the degree OSW;;;EA)
Configuration,CN=Services of organizational impact (A;;RPWPCRLCLOCCDCRCW
in the Configuration from inappropriate access or DWOSDDTSW;;;SY)
partition. loss of the resource.
- displayname: Impact
- Enabled: False
- msDS-
ribute: True
CN=MS-DS-
Types,CN=Claims
N=Configuration,CN=
<forest root domain
- msDS-ClaimPossibleValues:
High - High business impact
(HBI) - 3000, Moderate -
Medium business impact
(MBI) - 2000, Low - Low
business impact (LBI) -
1000>
Operation 119: {0b2be39a- Created a new Personal Use - objectClass: msDS- (D;;SDDT;;;WD)
d463-4c23-8290- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
32186759d3b1} CN=PersonalUse_MS,CN=Re - description: The Personal (A;;RPWPCRLCLOCCRCWDW
source Properties,CN=Claims Use property specifies OSW;;;EA)
Configuration,CN=Services whether the file is for (A;;RPWPCRLCLOCCDCRCW
in the Configuration personal use (not business DWOSDDTSW;;;SY)
partition. related).
- displayname: Personal Use
- Enabled: False
- msDS-
ribute: True
CN=MS-DS-
YesNo,CN=Value
Types,CN=Claims
N=Configuration,CN=
Operation 120: {f0842b44- Created a new Project - objectClass: msDS- (D;;SDDT;;;WD)

bc03-46a1-a860- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
006e8527fccd} CN=Project_MS,CN=Resourc - description: The Project (A;;RPWPCRLCLOCCRCWDW
e Properties,CN=Claims property specifies the names OSW;;;EA)
Configuration,CN=Services of one or more projects that (A;;RPWPCRLCLOCCDCRCW
in the Configuration are relevant to the resource. DWOSDDTSW;;;SY)
partition. - displayname: Project
- Enabled: False
- msDS-
ribute: True
CN=MS-DS-
Types,CN=Claims
N=Configuration,CN=
Operation 121: {93efec15- Created a new Retention - objectClass: msDS- (D;;SDDT;;;WD)

4dd9-4850-bc86- Period resource property ResourceProperty (A;;RPLCLORC;;;AU)
a1f2c8e2ebb9} object - description: The Retention (A;;RPWPCRLCLOCCRCWDW
CN=RetentionPeriod_MS,CN Period property specifies the OSW;;;EA)
=Resource maximum period for which (A;;RPWPCRLCLOCCDCRCW
Properties,CN=Claims the file should be retained. DWOSDDTSW;;;SY)
Configuration,CN=Services - displayname: Retention
in the Configuration Period
partition. - Enabled: False
- msDS-
ribute: True
CN=MS-DS-
e Types,CN=Claims
N=Configuration,CN=
Operation 122: {9e108d96- Created a new Retention - objectClass: msDS- (D;;SDDT;;;WD)

672f-40f0-b6bd- Start Date resource property ResourceProperty (A;;RPLCLORC;;;AU)
69ee1f0b7ac4} object - description: The Retention (A;;RPWPCRLCLOCCRCWDW
CN=RetentionStartDate_MS, Start Date property defines OSW;;;EA)
CN=Resource the starting date for a (A;;RPWPCRLCLOCCDCRCW
Properties,CN=Claims Retention Period. The DWOSDDTSW;;;SY)
Configuration,CN=Services retention period would begin
in the Configuration on the Retention Start Date.
partition. - displayname: Retention
Start Date
- Enabled: False
- msDS-
ribute: False
CN=MS-DS-
DateTime,CN=Value
Types,CN=Claims
N=Configuration,CN=
Operation 123: {1e269508- Created a new Company - objectClass: msDS- (D;;SDDT;;;WD)

f862-4c4a-b01f- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
420d26c4ff8c} CN=Company_MS,CN=Reso - description: The Company (A;;RPWPCRLCLOCCRCWDW
urce Properties,CN=Claims property specifies which OSW;;;EA)
Configuration,CN=Services company the resource (A;;RPWPCRLCLOCCDCRCW
in the Configuration belongs to. DWOSDDTSW;;;SY)
partition. - displayname: Company
- Enabled: False
- msDS-
ribute: True
CN=MS-DS-
e Types,CN=Claims
N=Configuration,CN=
Operation 125: {e1ab17ed- Created a new Folder Usage - objectClass: msDS- (D;;SDDT;;;WD)
5efb-4691-ad2d- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
0424592c5755} Note: CN=FolderUsage_MS,CN=Re - description: The Folder (A;;RPWPCRLCLOCCRCWDW
Operation 124 was deleted. source Properties,CN=Claims Usage property specifies the OSW;;;EA)
Configuration,CN=Services purpose of the folder and (A;;RPWPCRLCLOCCDCRCW
in the Configuration the kind of files stored in it. DWOSDDTSW;;;SY)
partition. - displayname: Folder Usage
- Enabled: False
- msDS-
ribute: False
- msDS-
AppliestoResourceTypes:
MS-DS-Container
CN=MS-DS-
Types,CN=Claims
N=Configuration,CN=
Operation 126: {0e848bd4- Created a new Global - objectClass: msDS- (D;;SDDT;;;WD)

7c70-48f2-b8fc- Resource Property List ResourcePropertyList (A;;RPLCLORC;;;AU)
00fbaa82e360} configuration object - description: This is a global (A;;RPWPCRLCLOCCRCWDW
CN=Global Resource out of box resource property OSW;;;EA)
Property List,CN=Resource list that contains all resource (A;;RPWPCRLCLOCCDCRCW
Property Lists,CN=Claims properties that can be DWOSDDTSW;;;SY)
Configuration,CN=Services consumed by applications.
in the Configuration - showInAdvancedViewOnly:
partition. True
- msDS-
MembersOfResourcePropert
yList:
CN=PII_MS,CN=Resource
Properties,CN=Claims
N=Configuration,CN=
- msDS-
yList:
CN=ProtectedHealthInforma
tion_MS,CN=Resource
GUID DESCRIPTION Configuration,CN=Services,C
ATTRIBUTES PERMISSIONS
N=Configuration,CN=
- msDS-
yList:
CN=RequiredClearance_MS,
CN=Resource
N=Configuration,CN=
- msDS-
yList:
CN=Confidentiality_MS,CN=
Resource
N=Configuration,CN=
- msDS-
yList:
CN=Compliancy_MS,CN=Re
source Properties,CN=Claims
N=Configuration,CN=
- msDS-
yList:
CN=Discoverability_MS,CN=
Resource
N=Configuration,CN=
- msDS-
yList:
CN=Immutable_MS,CN=Res
ource Properties,CN=Claims
N=Configuration,CN=
- msDS-
yList:
CN=IntellectualProperty_MS,
CN=Resource
N=Configuration,CN=
- msDS-
yList:
CN=Department_MS,CN=Re
N=Configuration,CN=
- msDS-
yList:
CN=Impact_MS,CN=Resourc
e Properties,CN=Claims
N=Configuration,CN=
- msDS-
yList:
GUID DESCRIPTION CN=PersonalUse_MS,CN=Re
ATTRIBUTES PERMISSIONS
N=Configuration,CN=
- msDS-
yList:
CN=Project_MS,CN=Resourc
e Properties,CN=Claims
N=Configuration,CN=
- msDS-
yList:
CN=RetentionPeriod_MS,CN
=Resource
N=Configuration,CN=
- msDS-
yList:
CN=RetentionStartDate_MS,
CN=Resource
N=Configuration,CN=
- msDS-
yList:
CN=Company_MS,CN=Reso
urce Properties,CN=Claims
N=Configuration,CN=
- msDS-
yList:
CN=FolderUsage_MS,CN=Re
N=Configuration,CN=
Operation 127: {016f23f7- Call back function to N/A N/A
077d-41fa-a356- upgrade display specifiers.
de7cfdb01797}
Operation 128: {49c140db- Updated strings for Folder - description: The Folder N/A
2de3-44c2-a99a- Usage resource property Usage property specifies the
bab2e6d2ba81} object purpose of the folder and
CN=FolderUsage_MS,CN=Re the kind of files stored in it.
Configuration,CN=Services
partition.
Operation 129: {e0b11c80- Added ACE to grant Principal N/A (OA;CIOI;RPWP;3f78c3e5-

62c5-47f7-ad0d- Self Write Property and Read f79a-46bd-a0b8-
3734a71b8312} Property on CN=Sam- 9d18116ddc79;;PS)
Domain object.
Operation 130: {2ada1a2d- Added ACE to grant Principal N/A (OA;CIOI;RPWP;3f78c3e5-

b02f-4731-b4fe- Self Write Property and Read f79a-46bd-a0b8-
59f955e24f71} Property on CN=Domain- 9d18116ddc79;;PS)
DNS object.
This topic covers detailed methodology on troubleshooting domain controller configuration and deployment.
Logging Options
The built-in logs are the most important instrument for troubleshooting issues with domain controller promotion
and demotion. All of these logs are enabled and configured for maximum verbosity by default.
PHASE LOG
Server Manager or ADDSDeployment Windows PowerShell - %systemroot%\debug\dcpromoui.log

operations
- %systemroot%\debug\dcpromoui*.log
PHASE LOG
Installation/Promotion of the domain controller - %systemroot%\debug\dcpromo.log
- %systemroot%\debug\dcpromo*.log
- Event viewer\Windows logs\Application

Service
Forest or domain upgrade - %systemroot%\debug\adprep\\adprep.log
- %systemroot%\debug\adprep\\csv.log
- %systemroot%\debug\adprep\\dspecup.log
- %systemroot%\debug\adprep\\ldif.log*
Server Manager ADDSDeployment Windows PowerShell - Event viewer\Applications and services

deployment engine logs\Microsoft\Windows\DirectoryServices-
Deployment\Operational
Windows Servicing - %systemroot%\Logs\CBS\*
- %systemroot%\servicing\sessions\sessions.xml
- %systemroot%\winsxs\poqexec.log
- %systemroot%\winsxs\pending.xml

Dcdiag.exe
Repadmin.exe
AutoRuns.exe, Task Manager, and MSInfo32.exe
Network Monitor 3.4 (or a third party network capture and analysis tool)
General Methodology for Troubleshooting Domain Controller Configuration
1. Did a simple syntax issue cause the error?
a. Did you mistype or forget to provide an argument to ADDSDeployment Windows PowerShell? For
example, if using ADDSDeployment Windows PowerShell, did you forget to add required argument -
domainname with a valid name?
b. Examine the Windows PowerShell console output carefully to see exactly why it is failing to parse the
command-line provided.
2. Is the error a prerequisite failure?
a. Many errors that used to appear as fatal promotion results are now prevented by the prerequisite
checker.
b. Examine the text of the prerequisite errors carefully, they provide the necessary guidance to resolve
most issues, as they are controlled scenarios.
3. Is the error in promotion and therefore fatal?
a. Examine the results carefully: many errors have simple explanations such as bad passwords, network
name resolution, or critical offline domain controllers.
b. Examine the Dcpromoui.log and dcpromo.log for the errors shown in the output, then work
backwards from them to see indications of why the failure occurred.
a. Always compare to a working sample log
b. Examine the ADPrep logs for errors only if the results indicate a problem extending the
schema or preparing the forest or domain.
c. Examine the DirectoryServices-Deployment event log for errors only if the Dcpromoui.log
lacks detail or ends arbitrarily due to an unhandled exception in the configuration process.
c. Examine the Directory Services, System, and Application event logs for other indicators of a
configuration issue. Often times, the domain controller promotion is just a symptom of other network
misconfiguration that would affect all distributed systems.
d. Use dcdiag.exe and repadmin.exe to validate the overall forest health and indicate subtle
misconfigurations that may prevent further domain controller promotion.
e. Use AutoRuns.exe, Task Manager, or MSinfo32.exe to examine the computer for third party software
that may be interfering.
a. Remove third party software (do not simply disable the software; that does not prevent drivers
loading).
f. Install NetMon 3.4 on the computer that fails to promote as well the replication partner domain
controller and analyze the promotion process with double-sided network captures.
a. Compare this to your working lab environment to understand what a healthy promotion looks
like and where it is failing.
b. At this point, the errors are likely with the forest objects, non-default security changes, or the
network, and this new domain controller is a victim of misconfigurations in DNS, firewalls,
host intrusion protection software, or other outside factors.
Events and Error Messages
Domain controller promotion and demotion always returns a code at the end of operation and unlike most
programs, do not return zero for success. To see the code at the end of a domain controller configuration, you have
several options:
1. When using Server Manager, examine the promotion results in the ten seconds prior to automatic reboot.
2. When using ADDSDeployment Windows PowerShell, examine the promotion results in the ten seconds
prior to automatic reboot. Alternatively, choose not to restart automatically on completion. You should add
the Format-List pipeline to make the output easier to read. For example:
Install-addsdomaincontroller <options> -norebootoncompletion:$true | format-list
Errors in prerequisite validation and verification do not continue on to a reboot, so they are visible in all
cases. For example:
3. In any scenario, examine the dcpromo.log and dcpromoui.log.
NOTE
Some of the errors listed below are no longer possible due to operating system and domain controller configuration
changes in later operating systems. The new ADDSDeployment Windows PowerShell codes also prevents certain
errors, but the dcpromo.exe /unattend does not; this is another compelling reason to switch all of your current
automation from the deprecated DCPromo to ADDSDeployment Windows PowerShell.
Promotion and demotion return the following success message codes.
ERROR CODE EXPLANATION NOTE
1 Exit, success You still must reboot, this just notes

that the automatic restart flag was
removed
2 Exit, success, need to reboot
3 Exit, success, with a non-critical failure Typically seen when returning the DNS
Delegation warning. If not configuring
DNS delegation, use:
-creatednsdelegation:$false
4 Exit, success, with a non-critical failure, Typically seen when returning the DNS
need to reboot Delegation warning. If not configuring
DNS delegation, use:
-creatednsdelegation:$false
Promotion and demotion return the following failure message codes. There is also likely to be an extended error
message; always read the entire error carefully, not just the numeric portion.
ERROR CODE EXPLANATION SUGGESTED RESOLUTION
11 Domain controller promotion is already Do not run than one instance of domain
running controller promotion at the same time
for the same target computer
12 User must be administrator Logon as a member of the built-in

Administrators group and ensure you
are elevating with UAC
13 Certification Authority is installed You cannot demote this domain

controller, as it is also a Certification
Authority. Do not remove the CA before
you carefully inventory its usage - if it is
issuing certificates, removing the role
will cause an outage. Running CAs on
domain controllers is discouraged
14 Running in safe-boot mode Boot the server into normal mode
15 Role change is in progress or needs You must restart the server (due to
reboot prior configuration changes) before
promotion
16 Running on wrong platform Not likely to get this error
17 No NTFS 5 drives exist This error is not possible in Windows

Server 2012, which requires at least the
%systemdrive% be formatted with NTFS
18 Not enough space in windir Free up space on the %systemdrive%

volume using cleanmgr.exe
19 Name change pending, needs reboot Reboot the server
20 Computer name is invalid syntax Rename the computer with a valid name
21 This domain controller holds FSMO Add -demoteoperationmasterrole

roles, is a GC, and/or is a DNS server when using -forceremoval.
22 TCP/IP needs to be installed or isn't Verify computer has TCP/IP configured,

functioning bound, and working correctly
23 DNS client needs to be configured first Set a primary DNS server when adding
a new domain controller to a domain
24 Supplied credentials are invalid or Verify your user name and password is
missing required elements correct
25 Domain controller for the specified Validate DNS client settings, firewall
domain could not be located rules
26 List of domains could not be read from Validate DNS client settings, LDAP
the forest functionality, firewall rules
27 Missing domain name Specify a domain when promoting or

demoting
28 Bad domain name Choose a different, valid DNS domain

name when promoting
29 Parent domain does not exist Verify the parent domain specified when
creating a new child domain or tree
domain
30 Domain not in forest Verify the domain name provided
31 Child Domain already exists Specify a different domain name
32 Bad NetBIOS domain name Specify a valid NetBIOS domain name
33 Path to the IFM files is invalid Validate your path to the Install From
Media folder
34 The IFM database is bad Use the correct Install From Media for
this operating system and role (same
operating system version, same type of
domain controller - RODC versus
RWDC)
35 Missing SYSKEY The Install from Media is encrypted and

you must provide a valid SYSKEY to use
it
37 Path for NTDS Database or its logs is Change path of Database and Logs to a
invalid fixed NTFS volume, not a mapped drive
or UNC path
38 Volume does not have enough space Free up space using cleanmgr.exe, add
for NTDS database or logs more disk space, manually clear space
by moving unnecessary data elsewhere
39 Path for SYSVOL is invalid Change path of SYSVOL folder to a fixed

NTFS volume, not a mapped drive or
UNC path
40 Invalid site name Provide a site name that exists
41 Need to specify a password for safe- Provide a password for the DSRM
mode account, it cannot be blank no matter
how the password policy is configured
42 Safe-mode password does not meet Provide a password for the DSRM
criteria (promotion only) account that meets the password
policy's configured rules
43 Admin password does not meet criteria Provide a password for the local
(demotion only) administrator account that meets the
password policy's configured rules
44 The specified name for the forest is Specify a valid forest root DNS domain
invalid name
45 A forest with the specified name already Choose a different forest root DNS
exists domain name
46 The specified name for the tree is invalid Specify a valid tree DNS domain name
47 A tree with the specified name already Choose a different tree DNS domain
exists name
48 The tree name does not fit into the Choose a different tree DNS domain
forest structure name
49 The specified domain does not exist Verify your typed domain name
50 During demote, last domain controller Do not specify Last Domain Controller
was detected even though it is not, or in the Domain (-
last domain controller was specified, but lastdomaincontrollerindomain)
it is not unless it is true. Use -
ignorelastdcindomainmismatch to
override if this is truly the last domain
controller and there is phantom domain
controller metadata
51 App partitions exist on this domain Specify to Remove Application

controller Partitions (-
removeapplicationpartitions)
52 Required command-line argument is Only seen with dcpromo /unattend,

missing (that is, an answer file must be which is deprecated. See older
specified on the command-line) documentation
53 The promotion/demotion failed, Examine the extended error and logs

machine must be rebooted to clean up
54 The promotion/demotion failed Examine the extended error and logs
55 The promotion/demotion was canceled Examine the extended error and logs
by the user
56 The promotion/demotion was canceled Examine the extended error and logs
by the user, machine must be rebooted
to clean up
58 A site name must be specified during You must specify a site for an RODC, it
RODC promotion will not automatically detect one like an
RWDC
59 During demote, this domain controller is Specify that this is the Last DNS Server
the last DNS server for one of its zones in the Domain or use -
ignorelastdnsserverfordomain
60 A domain controller running Windows Promote at least one Windows Server

Server 2008 or later must be present in 2008 or later model writable domain
the domain in order to promote RODC controller
61 You cannot install Active Directory Not possible to get this error
Domain Services with DNS in an existing
domain that does not already host DNS
62 Answer file does not have a [DCInstall] Only seen with dcpromo /unattend,
section which is deprecated. See older
documentation.
63 Forest functional level is below windows Raise the forest functional level to at
server 2003 least Windows Server 2003 Native.
Windows 2000 and Windows NT 4.0 are
no longer supported operating systems
64 Promo failed because component binary Install the AD DS role

detection failed
65 Promo failed because component binary Install the AD DS role

installation failed
66 Promo failed because operating system Examine the extended error and logs;
detection failed the server is failing to return its
operating system version. It is likely that
the computer will need to be re-
installed, as its overall health is highly
suspect
68 Replication partner is invalid Use repadmin.exe or the Get-

ADReplication\* Windows PowerShell
to validate partner domain controller
health
69 Required Port is already in use by some Use netstat.exe -anob to locate

other application processes that are incorrectly assigned
to reserved AD DS ports
70 The forest root domain controller must Only seen with dcpromo /unattend,
be a GC which is deprecated. See older
documentation
71 DNS server is already installed Do not specify to install DNS (-

installDNS) if the DNS service is already
installed
72 Computer is running Remote Desktop You cannot promote this domain

Services in non-admin mode controller, as it is also a RDS server
configured for more than two admin
users. Do not remove RDS before you
carefully inventory its usage - if it is
being used by applications or end-users,
removal will cause an outage
73 The specified forest functional level is Specify a valid forest functional level
invalid.
74 The specified domain functional level is Specify a valid domain functional level
invalid.
75 Unable to determine the default Validate that the RODC password

password replication policy. replication policy exists and is accessible
76 Specified replicated/non-replicated Validate that you have typed in valid

security groups are invalid domain and user accounts when
specifying a password replication policy
77 The specified argument is invalid Examine the extended error and logs
78 Failed to examine Active Directory Examine the extended error and logs
Forest
79 RODC cannot be promoted because Use Windows Server 2012 to prepare

rodcprep has not been performed the forest or use adprep.exe
/rodcprep
80 Domainprep has not been performed Use Windows Server 2012 to prepare
the domain or use adprep.exe
/domainprep
81 Forestprep has not been performed Use Windows Server 2012 to prepare
the forest or use adprep.exe
/forestprep
82 Forest schema mismatch Use Windows Server 2012 to prepare

the forest or use adprep.exe
/forestprep
83 Unsupported SKU Not likely to get this error
84 Unable to detect a domain controller Validate that existing domain controllers

account have correct user account control
attribute set.
85 Unable to select a domain controller Returned if you specify "Use Existing

account for stage 2 Account" but either no account found
or there is an error during account
lookup. Ensure you provided the correct
RODC staged account
86 Need to run stage 2 promotion Returned if you promote an additional

domain controller but an existing
account exists and "Allow Reinstall" was
not specified
87 A domain controller account of Rename the computer before

conflicting type exists promoting, if not trying to attach to an
unoccupied domain controller. You must
attach to the unoccupied domain
controller account using -
useexistingaccount and the correct
read-only or writable argument,
depending on account type
88 The specified server admin is not valid You specified an invalid account for
RODC admin delegation. Verify that the
account specified is a valid user or
group
89 RID master for the specified domain is Use netdom.exe query fsmo to detect
offline. the RID master. Bring it online and make
it accessible to the domain controller
you are promoting
90 Domain naming master is offline. Use netdom.exe query fsmo to detect

the domain naming master. Bring it
online and make it accessible to the
domain controller you are promoting
91 Failed to detect if the process is wow64 Not possible to get this error anymore,
the operating system is 64-bit
92 Wow64 process is not supported Not possible to get this error anymore,
the operating system is 64-bit
93 Domain controller service is not running Start the AD DS service

for non-forceful demotion
94 Local admin password does not meet Provide a non-blank password and
requirement: either blank or not ensure that the local password policy
required requires a password
95 Cannot demote last Windows Server You must first demote all RODCs before
2008 or later domain controller in the you can demote all Windows Server
domain where live RODCs exist 2008 or later writable domain
controllers
96 Unable to uninstall DS binaries Only seen with dcpromo /unattend,

which is deprecated. See older
documentation
97 Forest functional level version higher Provide a child domain functional the
than that of the child domain operating same or higher than the forest
system functional level
98 Component binary install/uninstall is in Only seen with dcpromo /unattend,

progress. which is deprecated. See older
documentation
99 Forest functional level is too low (error is Raise the forest functional level to at
Windows Server 2012 only) least Windows Server 2003 native.
100 Domain functional level is too low (error Raise the domain functional level to at
is Windows Server 2012 only) least Windows Server 2003 native.
Known/Likely Issues and Support Scenarios

The following are common issues seen during the Windows Server 2012 development process. All of these issues
are "by design" and have either a valid workaround or more appropriate technique to avoid them in the first place.
Many of these behaviors are identical in Windows Server 2008 R2 and older operating systems, but the rewrite of
AD DS deployment brings heightened sensitivity to issues.
DEMOTING A DOMAIN CONTROLLER LEAVES DNS RUNNING WITH

ISSUE NO ZONES
Symptoms Server still responds to DNS requests but has no zone

information
Resolution and Notes When removing the AD DS role, also remove the DNS Server
role or set the DNS Server service to disabled. Remember to
point the DNS client to another server than itself. If using
Windows PowerShell, run the following after you demote the
server:
Code - uninstall-windowsfeature dns
or
Code - set-service dns -starttype disabled

stop-service dns
PROMOTING A WINDOWS SERVER 2012 INTO AN EXISTING

SINGLE-LABEL DOMAIN DOES NOT CONFIGURE
UPDATETOPLEVELDOMAIN=1 OR
ISSUE ALLOWSINGLELABELDNSDOMAIN=1
Symptoms DNS dynamic record registration does not occur
Resolution and Notes Set these values using the Netlogon and DNS group policies.
Microsoft began blocking single-label domain creation in
Windows Server 2008; you can use ADMT or the Domain
Rename Tool to change to an approved DNS domain structure.
DEMOTION OF LAST DOMAIN CONTROLLER IN A DOMAIN FAILS IF

ISSUE THERE ARE PRE-CREATED, UNOCCUPIED RODC ACCOUNTS
DEMOTION OF LAST DOMAIN CONTROLLER IN A DOMAIN FAILS IF
ISSUE THERE ARE PRE-CREATED, UNOCCUPIED RODC ACCOUNTS
Symptoms Demotion fails with message:
Dcpromo.General.54
Active Directory Domain Services could not find another Active

Directory Domain Controller to transfer the remaining data in
directory partition
CN=Schema,CN=Configuration,DC=corp,DC=contoso,DC=co
m.
"The format of the specified domain name is invalid."
Resolution and Notes Remove any remaining pre-created RODC accounts before
demoting a domain, using Dsa.msc or Ntdsutil.exe
metadata cleanup.
AUTOMATED FOREST AND DOMAIN PREPARATION DOES NOT RUN

ISSUE GPPREP
Symptoms Cross-domain planning functionality for Group Policy,

Resultant Set of Policy (RSOP) Planning Mode, requires
updated file system and Active Directory permissions for
existing GP. Without Gpprep, you cannot use RSOP Planning
across domains.
Resolution and Notes Run adprep.exe /gpprep manually for all domains that were
not previously prepared for Windows Server 2003, Windows
Server 2008, or Windows Server 2008 R2. Administrators
should run GPPrep only once in the history of a domain, not
with every upgrade. It is not run by automatic adprep because
if you have already set adequate custom permissions, it would
cause all SYSVOL contents to re-replicate on all domain
controllers.
INSTALL FROM MEDIA FAILS TO VERIFY WHEN POINTING TO A UNC

ISSUE PATH
Symptoms Error returned:
Code - Could not validate media path. Exception calling

"GetDatabaseInfo" with "2" arguments. The folder is not valid.
Resolution and Notes You must store IFM files on a local disk, not a remote UNC
path. This intentional block prevents partial server promotion
due to a network interruption.
DNS DELEGATION WARNING SHOWN TWICE DURING DOMAIN

ISSUE CONTROLLER PROMOTION
DNS DELEGATION WARNING SHOWN TWICE DURING DOMAIN
ISSUE CONTROLLER PROMOTION
Symptoms Warning returned twice when promoting using

ADDSDeployment Windows PowerShell:
Code - "A delegation for this DNS server cannot be created

because the authoritative parent zone cannot be found or it
does not run Windows DNS server. If you are integrating with
an existing DNS infrastructure, you should manually create a
delegation to this DNS server in the parent zone to ensure
reliable name resolution from outside the domain. Otherwise,
no action is required."
Resolution and Notes Ignore. ADDSDeployment Windows PowerShell shows the

warning first during prerequisite checking, then again during
configuration of the domain controller. If you do not wish to
configure DNS delegation, use argument:
Code - -creatednsdelegation:$false
Do not skip the prerequisite checks in order to suppress this

message
SPECIFYING UPN OR NON-DOMAIN CREDENTIALS DURING

ISSUE CONFIGURATION RETURNS MISLEADING ERRORS
Symptoms Server Manager returns error:
Code - Exception calling "DNSOption" with "6" Arguments
ADDSDeployment Windows PowerShell returns error:
Code - Verification of user permissions failed. You must supply

the name of the domain to which this user account belongs.
Resolution and Notes Ensure you are providing valid domain credentials in the form
of domain\user.
REMOVING THE DIRECTORYSERVICES-DOMAINCONTROLLER ROLE

ISSUE USING DISM.EXE LEADS TO UNBOOTABLE SERVER
Symptoms If using Dism.exe to remove the AD DS role before demoting a

domain controller gracefully, the server no longer boots
normally and shows error:
Code - Status: 0x000000000

Info: An unexpected error has occurred.
Resolution and Notes Boot into Directory Services Repair Mode using Shift+F8. Add
the AD DS role back, and then forcibly demote the domain
controller. Alternatively, restore the System State from backup.
Do not use Dism.exe for AD DS role removal; the utility has no
knowledge of domain controllers.
INSTALLING A NEW FOREST FAILS WHEN SETTING FORESTMODE TO

ISSUE WIN2012
INSTALLING A NEW FOREST FAILS WHEN SETTING FORESTMODE TO
ISSUE WIN2012
Symptoms Promotion using ADDSDeployment Windows PowerShell

returns error:
Code - Test.VerifyDcPromoCore.DCPromo.General.74
Verification of prerequisites for Domain Controller promotion

failed. The specified domain functional level is invalid
Resolution and Notes Do not specify a forest functional mode of Win2012 without
also specifying a domain functional mode of Win2012. Here is
an example that will work without errors:
Code - -forestmode Win2012 -domainmode Win2012]
Issue Clicking Verify in the Install from Media selection area appears
to do nothing
Symptoms When you specify a path to an IFM folder, clicking the Verify
button never returns a message or appears to do anything.
Resolution and Notes The Verify button only returns errors if there are issues.
Otherwise, it makes the Next button selectable if you have
provided an IFM path. You must click Verify to proceed if you
have selected IFM.
Issue Demoting with Server Manager does not provide feedback

until completed.
Symptoms When using Server Manager to remove the AD DS role and

demote a domain controller, there is no ongoing feedback
given until the demotion completes or fails.
Resolution and Notes This is a limitation of Server Manager. For feedback, use
ADDSDeployment Windows PowerShell cmdlet:
Code - Uninstall-addsdomaincontroller
Issue Install from Media Verify does not detect that RODC media
provided for writable domain controller, or vice versa.
Symptoms When promoting a new domain controller using IFM and
providing incorrect media to IFM - such as RODC media for a
writable domain controller, or RWDC media for an RODC - the
Verify button does not return an error. Later, promotion fails
with error:
Code - An error occurred while trying to configure this

machine as a domain controller.
The Install-From-Media promotion of a Read-Only DC cannot
start because the specified source database is not allowed.
Only databases from other RODCs can be used for IFM
promotion of a RODC.
Resolution and Notes Verify only validates the overall integrity of IFM. Do not
provide the wrong IFM type to a server. Restart the server
before you attempt promotion again with the correct media.
Issue Promoting an RODC into a pre-created computer account fails
Symptoms When using ADDSDeployment Windows PowerShell to

promote a new RODC with a staged computer account,
receive error:
Code - Parameter set cannot be resolved using the specified

named parameters.
InvalidArgument: ParameterBindingException
+ FullyQualifiedErrorId :
AmbiguousParameterSet,Microsoft.DirectoryServices.Deploym
ent.PowerShell.Commands.Install
Resolution and Notes Do not provide parameters already defined already on a pre-
created RODC account. These include:
Code - -readonlyreplica
-installdns
-donotconfigureglobalcatalog
-sitename
-installdns
Issue Deselecting/selecting "Restart each destination server

automatically if required" does nothing
Symptoms If selecting (or not selecting) the Server Manager option

Restart each destination server automatically if required
whendemoting a domain controller through role removal, the
server always restarts, regardless of choice.
Resolution and Notes This is intentional. The demotion process restarts the server
regardless of this setting.
Issue Dcpromo.log shows "[error] setting security on server files

failed with 2"
Symptoms Demotion of a domain controller completes without issues,
but examination of the dcpromo log shows error:
Code - [error] setting security on server files failed with 2
Resolution and Notes Ignore, error is expected and cosmetic.
Issue Prerequisite adprep check fails with error "Unable to perform

Exchange schema conflict check"
Symptoms When attempting to promote a Windows Server 2012 domain

controller into an existing Windows Server 2003, Windows
Server 2008, or Windows Server 2008 R2 forest, prerequisite
check fails with error:
Code - Verification of prerequisites for AD prep failed. Unable

to perform Exchange schema conflict check for domain
(Exception: the RPC server is unavailable)
The adprep.log shows error:
Code - Adprep could not retrieve data from the server
through Windows Management Instrumentation (WMI).
Resolution and Notes The new domain controller cannot access WMI through
DCOM/RPC protocols against the existing domain controllers.
To date, there have been three causes for this:
- A firewall rule blocks access to the existing domain

controllers
- The NETWORK SERVICE account is missing from the "Logon

as a service" (SeServiceLogonRight) privilege on the existing
domain controllers
- NTLM is disabled on domain controllers, using security

policies described in Introducing the Restriction of NTLM
Authentication
Issue Creating a new AD DS forest always shows DNS warning
Symptoms When creating a new AD DS forest and creating the DNS zone
on the new domain controller for itself, you always receive
warning message:
Code - An error was detected in the DNS configuration.

None of the DNS servers used by this computer responded
within the timeout interval.
(error code 0x000005B4 "ERROR_TIMEOUT")
Resolution and Notes Ignore. This warning is intentional on the first domain
controller in the root domain of a new forest, in case you
intended to point to an existing DNS server and zone.
Issue Windows PowerShell -whatif argument returns incorrect DNS
server information
Symptoms If you use the -whatif argument when configuring a domain

controller with implicit or explicit -installdns:$true, the
resulting output shows:
Code - "DNS Server: No"
Resolution and Notes Ignore. DNS is installed and configured correctly.
Issue After promotion, logon fails with " Not enough storage is
available to process this command"
Symptoms After you promote a new domain controller and then log off
and attempt to log on interactively, you receive error:
Code - Not enough storage is available to process this

command
Resolution and Notes The domain controller was not rebooted after promotion,
either due to an error or because you specified the
ADDSDeployment Windows PowerShell argument -
norebootoncompletion. Restart the domain controller.
Issue The Next button is not available on the Domain Controller

Options page
Symptoms Even though you have set a password, the Next button on
the Domain Controller Options page in Server Manager is
not available. There is no site listed in the Site name menu.
Resolution and Notes You have multiple AD DS sites and at least one is missing
subnets; this future domain controller belongs to one of those
subnets. You must manually select the subnet from the Site
name dropdown menu. You should also review all AD sites
using DSSITE.MSC or use the following Windows PowerShell
command to find all sites missing subnets:
Code - get-adreplicationsite -filter * -property subnets |

where-object {!$_.subnets -eq "*"} | format-table name
Issue Promotion or demotion fails with message "the service cannot

be started"
Symptoms If you attempt promotion, demotion, or cloning of a domain
controller you receive error:
Code - The service cannot be started, either because it is

disabled or it has no enabled devices associated with it"
(0x80070422)
The error may be interactive, an event, or written to a log like

dcpromoui.log or dcpromo.log
Resolution and Notes The DS Role Server service (DsRoleSvc) is disabled. By default,
this service is installed during AD DS role installation and set
to a Manual start type. Do not disable this service. Set it back
to Manual and allow the DS role operations to start and stop
it on demand. This behavior is by design.
Issue Server Manager still warns that you need to promote DC
Symptoms If you promote a domain controller using the deprecated

dcpromo.exe /unattend or upgrade an existing Windows
Server 2008 R2 domain controller in place to Windows Server
2012, Server Manager still shows the post-deployment
configuration task Promote this server to a domain
controller.
Resolution and Notes Click the post-deployment warning link and the message will
disappear for good. This behavior is cosmetic and expected.
Issue Server Manager deployment script missing role installation
Symptoms If you promote a domain controller using Server Manager and

save the Windows PowerShell deployment script, it does not
include the role installation cmdlet and arguments (install-
windowsfeature -name ad-domain-services -
includemanagementtools). Without the role, the DC cannot be
configured.
Resolution and Notes Manually add that cmdlet and arguments to any scripts. This
behavior is expected and by design.
Issue Server Manager deployment script is not named PS1
Symptoms If you promote a domain controller using Server Manager and

save the Windows PowerShell deployment script, the file is
named with a random temporary name and not as a PS1 file.
Resolution and Notes Manually rename the file. This behavior is expected and by
design.
DCPROMO /UNATTEND ALLOWS UNSUPPORTED FUNCTIONAL
ISSUE LEVELS
Symptoms If you promote a domain controller using dcpromo /unattend

with the following sample answer file:
Code -
[DCInstall]
NewDomain=Forest
ReplicaOrNewDomain=Domain
NewDomainDNSName=corp.contoso.com
SafeModeAdminPassword=Safepassword@6
DomainNetbiosName=corp
DNSOnNetwork=Yes
AutoConfigDNS=Yes
RebootOnSuccess=NoAndNoPromptEither
RebootOnCompletion=No
DomainLevel=0
ForestLevel=0
Promotion fails with the following errors in the dcpromoui.log:
Code - dcpromoui EA4.5B8 0089 13:31:50.783 Enter

CArgumentsSpec::ValidateArgument DomainLevel
dcpromoui EA4.5B8 008A 13:31:50.783 Value for DomainLevel

is 0
dcpromoui EA4.5B8 008B 13:31:50.783 Exit code is 77
dcpromoui EA4.5B8 008C 13:31:50.783 The specified

argument is invalid.
dcpromoui EA4.5B8 008D 13:31:50.783 closing log
dcpromoui EA4.5B8 0032 13:31:50.830 Exit code is 77
Level 0 is Windows 2000, which is not supported in Windows

Server 2012.
Resolution and Notes Do not use the deprecated dcpromo /unattend and
understand that it allows you to specify invalid settings that
later fail. This behavior is expected and by design.
PROMOTION "HANGS" AT CREATING NTDS SETTINGS OBJECT,

ISSUE NEVER COMPLETES
Symptoms If you promote a replica DC or RODC, the promotion reaches

"creating NTDS settings object" and never proceeds or
completes. The logs stop updating as well.
PROMOTION "HANGS" AT CREATING NTDS SETTINGS OBJECT,
ISSUE NEVER COMPLETES
Resolution and Notes This is a known issue caused by providing credentials of the
built-in local Administrator account with a matching password
to the built-in domain Administrator account. This causes a
failure down in the core setup engine that does not error, but
instead waits indefinitely (quasi-loop). This is expected - albeit
undesirable - behavior.
To fix the server:
1. Reboot it.
1. In AD, delete that server's member computer account (it will

not yet be a DC account)
1. On that server, forcibly disjoin it from the domain
1. On that server, remove the AD DS role.
1. Reboot
1. Re-add the AD DS role and reattempt promotion, ensuring

that you always provide the domain\admin formatted
credentials to DC promotion and not just the built-in local
administrator account
AD DS Operations
This section provides links to How To's and functions related to day-to-day administration, management and
automation tasks for Active Directory Domain Services.
Active Directory Replication and Topology Management Using Windows PowerShell
Active Directory Domain Services Component Updates
Active Directory Forest Recovery Guide
Applies To: Windows Server 2016, Windows Server 2012 and 2012 R2, Windows Server 2008 and 2008 R2,
Windows Server 2003
This guide contains best-practice recommendations for recovering an Active Directory® forest if forest-wide failure
renders all domain controllers (DCs) in the forest incapable of functioning normally. The steps it contains serve as a
template for your forest recovery plan, which you can customize for your particular environment. These steps apply
to DCs that run Microsoft® Windows Server 2016, 2012 R2, 2012, 2008 R2, 2008, and 2003 operating systems.
NOTE
Procedures that are unique for DCs that run Windows Server 2003 are consolidated in AD Forest Recovery Windows Server
2003.
Steps outlined in this guide

AD Forest Recovery - Devising a custom forest recovery plan
AD Forest Recovery - Steps for Recovery
AD Forest Recovery - Identify the problem
AD Forest Recovery - Determine how to recover
AD Forest Recovery - Perform initial recovery
AD Forest Recovery - Frequently Asked Questions
AD Forest Recovery - Recovering a Single Domain within a Multidomain Forest
AD Forest Recovery - Virtualization
AD Forest Recovery - Forest Recovery with Windows Server 2003 Domain Controllers
Active Directory Forest Recovery Prerequisites
Applies To: Windows Server 2016, Windows Server 2012 and 2012 R2, Windows Server 2008 and 2008 R2
The following document discuss prerequisites that you should be familiar with before devising a forest recovery
plan or attempting a recovery.
Assumptions for Using This Guide

1. You have worked with a Microsoft Support professional and:
Determine the cause of the forest-wide failure. This guide does not suggest a cause of the failure or
recommend any procedures to prevent the failure.
Evaluated any possible remedies.
Concluded, in consultation with Microsoft Support, that restoring the whole forest to its state before the
failure occurred is the best way to recover from the failure. In many cases, forest recovery should be the
last option.
2. That you have followed the Microsoft best-practice recommendations for using Active Directory–integrated
Domain Name System (DNS ). Specifically, there should be an Active Directory–integrated DNS zone for
each Active Directory domain.
If this is not the case, you can still use the basic principles of this guide to perform forest recovery.
However, you will need to take specific measures for DNS recovery based on your own environment. For
more information about using Active Directory–integrated DNS, see Creating a DNS Infrastructure
Design.
3. Although this guide is intended as a generic guide for forest recovery, not all possible scenarios are covered.
For instance, beginning with Windows Server 2008, there is a Server Core version, which is a full version of
Windows Server but without a full GUI. Although it is certainly possible to recover a forest consisting of just
DCs that run Server Core, this guide has no detailed instructions. However, based on the guidance discussed
here you will be able to design the required command-line actions yourself.
![!NOTE ] Although the objectives of this guide are to recover the forest and maintain or restore full DNS
functionality, recovery can result in a DNS configuration that is changed from the configuration before the
failure. After the forest is recovered, you can revert to the original DNS configuration. The recommendations in
this guide do not describe how to configure DNS servers to perform name resolution of other portions of the
corporate namespace where there are DNS zones that are not stored in AD DS.
Concepts for Using This Guide

Before you begin planning for recovery of an Active Directory forest, you should be familiar with the following:
Fundamental Active Directory concepts
The importance of operations master roles (also known as flexible single master operations or FSMO ). These
roles include the following:
Schema master
Domain naming master
Relative ID (RID ) master
Primary domain controller (PDC ) emulator master
Infrastructure master
In addition, you should have backed up and restored AD DS and SYSVOL in a lab environment on a regular basis.
For more information, see Backing up the System State data and Performing a nonauthoritative restore of Active
Directory Domain Services.
Next Steps
AD Forest Recovery - Steps for Restoring the forest
This section provides an overview of the recommended path for recovering a forest. The forest recovery steps are
described in detail later.
The following list summarizes the recovery steps at a high level:
1. Identify the problem
Work with IT and Microsoft Support to determine the scope of the problem and potential causes, and
evaluate possible remedies with all business stakeholders. In many cases total forest recovery should be the
last option.
2. Decide how to recover the forest
After you determine that forest recovery is necessary, complete preliminary steps to prepare for it:
determine the current forest structure, identify the functions that each DC performs, decide which DC to
restore for each domain, and ensure that all writeable DCs are taken offline.
3. Perform initial recovery
In isolation, recover one DC for each domain, clean them, and reconnect the domains. Reset privileged
accounts, and rectify problems caused by security breaches in this phase.
4. Redeploy remaining DCs
Redeploy the forest to return it to its state before the failure. This step will need to be adapted to your
specific design and requirements. Virtualized domain controller cloning can help expedite this process.
5. Cleanup
After functionality has been restored, reconfigure name resolution as needed, and get LOB applications
working.
The steps in this guide are designed to minimize the possibility of reintroducing dangerous data into the recovered
forest. You might have to modify these steps to account for such factors as:
Scalability
Remote manageability
Speed of recovery
Identify the problem
When symptoms of a forest-wide failure appear, such as in event logs or other monitoring solutions, work with
Microsoft Support to determine the cause of the failure, and evaluate any possible remedies.
Examples of forest-wide failures

All DCs have been logically corrupted or physically damaged to a point that business continuity is impossible;
for example, all business applications that depend on AD DS are nonfunctional.
A rogue administrator has compromised the Active Directory environment.
An attacker intentionally—or an administrator accidentally—runs a script that spreads data corruption across
the forest.
An attacker intentionally—or an administrator accidentally—extends the Active Directory schema with malicious
or conflicting changes.
An attacker has managed to install malicious software on DCs, and you have been advised by Microsoft
Support to recover the forest from backup.
IMPORTANT
This paper does not cover security recommendations about how to recover a forest that has been hacked or
compromised. In general, it is recommended to follow Pass-the-Hash mitigation techniques to harden the
environment. For more information, see Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft
Techniques.
None of the DCs can replicate with their replication partners.

Changes cannot be made to AD DS at any domain controller.
New DCs cannot be installed in any domain.
Next Steps
Perform initial recovery
This section includes the following steps:

Restore the first writeable domain controller in each domain
Reconnect each restored writeable domain controller to the network
Add the global catalog to a domain controller in the forest root domain
Restore the first writeable domain controller in each domain

Beginning with a writeable DC in the forest root domain, complete the steps in this section in order to restore the
first DC. The forest root domain is important because it stores the Schema Admins and Enterprise Admins groups.
It also helps maintain the trust hierarchy in the forest. In addition, the forest root domain usually holds the DNS
root server for the forest’s DNS namespace. Consequently, the Active Directory–integrated DNS zone for that
domain contains the alias (CNAME ) resource records for all other DCs in the forest (which are required for
replication) and the global catalog DNS resource records.
After you recover the forest root domain, repeat the same steps to recover the remaining domains in the forest. You
can recover more than one domain simultaneously; however, always recover a parent domain before recovering a
child to prevent any break in the trust hierarchy or DNS name resolution.
For each domain that you recover, restore only one writeable DC from backup. This is the most important part of
the recovery because the DC must have a database that has not been influenced by whatever caused the forest to
fail. It is important to have a trusted backup that is thoroughly tested before it is introduced into the production
environment.
Then perform the following steps. Procedures for performing certain steps are in AD Forest Recovery - Procedures.
1. If you plan to restore a physical server, ensure that the network cable of the target DC is not attached and
therefore is not connected to the production network. For a virtual machine, you can remove the network
adapter or use a network adapter that is attached to another network where you can test the recovery
process while isolated from the production network.
2. Because this is the first writeable DC in the domain, you must perform a nonauthoritative restore of AD DS
and an authoritative restore of SYSVOL. The restore operation must be completed by using an Active
Directory-aware backup and restore application, such as Windows Server Backup (that is, you should not
restore the DC by using unsupported methods such as restoring a VM snapshot).
An authoritative restore of SYSVOL is required because replication of the SYSVOL replicated folder must
be started after you recover from a disaster. All subsequent DCs that are added in the domain must
resynchronize their SYSVOL folder with a copy of the folder that has been selected to be authoritative
before the folder can be advertised.
Cau t i on
Perform an authoritative (or primary) restore operation of SYSVOL only for the first DC to be restored in the
forest root domain. Incorrectly performing primary restore operations of the SYSVOL on other DCs leads to
replication conflicts of SYSVOL data.
There are two options perform a nonauthoritative restore of AD DS and an authoritative restore of
SYSVOL:
Perform a full server recovery and then force an authoritative synchronization of SYSVOL. For detailed
procedures, see Performing a full server recovery and Perform an authoritative synchronization of DFSR -
replicated SYSVOL.
Perform a full server recovery followed by a system state restore. This option requires that you create
both types of backups in advance: a full server backup and a system state backup. For detailed
procedures, see Performing a full server recovery and Performing a nonauthoritative restore of Active
3. After you restore and restart the writeable DC, verify that the failure did not affect the data on the DC. If the
DC data is damaged, then repeat step 2 with a different backup.
If the restored domain controller hosts an operations master role, you may need to add the following
registry entry to avoid AD DS being unavailable until it has completed replication of a writeable
directory partition:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial
Synchronizations
Create the entry with the data type REG_DWORD and a value of 0. After the forest is recovered
completely, you can reset the value of this entry to 1, which requires a domain controller that restarts
and holds operations master roles to have successful AD DS inbound and outbound replication with
its known replica partners before it advertises itself as domain controller and starts providing services
to clients. For more information about initial synchronization requirements, see KB article 305476.
Continue to the next steps only after you restore and verify the data and before you join this
computer to the production network.
4. If you suspect that the forest-wide failure was related to network intrusion or malicious attack, reset the
account passwords for all administrative accounts, including members of the Enterprise Admins, Domain
Admins, Schema Admins, Server Operators, Account Operators groups, and so on. The reset of
administrative account passwords should be completed before additional domain controllers are installed
during the next phase of the forest recovery.
5. On the first restored DC in the forest root domain, seize all domain-wide and forest-wide operations master
roles. Enterprise Admins and Schema Admins credentials are needed to seize forest-wide operations master
roles.
In each child domain, seize domain-wide operations master roles. Although you might retain the operations
master roles on the restored DC only temporarily, seizing these roles assures you regarding which DC hosts
them at this point in the forest recovery process. As part of your post-recovery process, you can redistribute
the operations master roles as needed. For more information about seizing operations master roles, see
Seizing an operations master role. For recommendations about where to place operations master roles, see
What Are Operations Masters?.
6. Clean up metadata of all other writeable DCs in the forest root domain that you are not restoring from
backup (all writeable DCs in the domain except for this first DC ). If you use the version of Active Directory
Users and Computers or Active Directory Sites and Services that is included with Windows Server 2008 or
later or RSAT for Windows Vista or later, metadata cleanup is performed automatically when you delete a
DC object. In addition, the server object and computer object for the deleted DC are also deleted
automatically. For more information, see Cleaning metadata of removed writable DCs.
Cleaning up metadata prevents possible duplication of NTDS -settings objects if AD DS is installed on a DC
in a different site. Potentially, this could also save the Knowledge Consistency Checker (KCC ) the process of
creating replication links when the DCs themselves might not be present. Moreover, as part of metadata
cleanup, DC Locator DNS resource records for all other DCs in the domain will be deleted from DNS.
Until the metadata of all other DCs in the domain is removed, this DC, if it were a RID master before
recovery, will not assume the RID master role and therefore will not be able to issue new RIDs. You might
see event ID 16650 in the System log in Event Viewer indicating this failure, but you should see event ID
16648 indicating success a little while after you have cleaned the metadata.
7. If you have DNS zones that are stored in AD DS, ensure that the local DNS Server service is installed and
running on the DC that you have restored. If this DC was not a DNS server before the forest failure, you
must install and configure the DNS server.
NOTE
If the restored DC runs Windows Server 2008, you need to install the hotfix in KB article 975654 or connect the
server to an isolated network temporarily in order to install DNS server. The hotfix is not required for any other
versions of Windows Server.
In the forest root domain, configure the restored DC with its own IP address (or a loopback address, such as
127.0.0.1) as its preferred DNS server. You can configure this setting in the TCP/IP properties of the local
area network (LAN ) adapter. This is the first DNS server in the forest. For more information, see Configure
TCP/IP to use DNS.
In each child domain, configure the restored DC with the IP address of the first DNS server in the forest root
domain as its preferred DNS server. You can configure this setting in the TCP/IP properties of the LAN
adapter. For more information, see Configure TCP/IP to use DNS.
In the _msdcs and domain DNS zones, delete NS records of DCs that no longer exist after metadata cleanup.
Check if the SRV records of the cleaned up DCs have been removed. To help speed up DNS SRV record
removal, run:
nltest.exe /dsderegdns:server.domain.tld
8. Raise the value of the available RID pool by 100,000. For more information, see Raising the value of
available RID pools. If you have reason to believe that raising the RID Pool by 100,000 is insufficient for
your particular situation, you should determine the lowest increase that is still safe to use. RIDs are a finite
resource that should not be used up needlessly.
If new security principals were created in the domain after the time of the backup that you use for the
restore, these security principals might have access rights on certain objects. These security principals no
longer exist after recovery because the recovery has reverted to the backup; however, their access rights
might still exist. If the available RID pool is not raised after a restore, new user objects that are created after
the forest recovery might obtain identical security IDs (SIDs) and could have access to those objects, which
was not originally intended.
To illustrate, consider the example of the new employee named Amy that was mentioned in the introduction.
The user object for Amy no longer exists after the restore operation because it was created after the backup
that was used to restore the domain. However, any access rights that were assigned to that user object might
persist after the restore operation. If the SID for that user object is reassigned to a new object after the
restore operation, the new object would obtain those access rights.
9. Invalidate the current RID pool. The current RID pool is invalidated after a system state restore. But if a
system state restore was not performed, the current RID pool needs to be invalidated to prevent the restored
DC from re-issuing RIDs from the RID pool that was assigned at the time the backup was created. For more
information, see Invalidating the current RID pool.
NOTE
The first time that you attempt to create an object with a SID after you invalidate the RID pool you will receive an
error. The attempt to create an object triggers a request for a new RID pool. Retry of the operation succeeds because
the new RID pool will be allocated.
10. Reset the computer account password of this DC twice. For more information, see Resetting the computer
account password of the domain controller.
11. Reset the krbtgt password twice. For more information, see Resetting the krbtgt password.
Because the krbtgt password history is two passwords, reset passwords twice to remove the original
(prefailure) password from password history.
NOTE
If the forest recovery is in response to a security breach, you may also reset the trust passwords. For more
information, see Resetting a trust password on one side of the trust.
12. If the forest has multiple domains and the restored DC was a global catalog server before the failure, clear
the Global catalog check box in the NTDS Settings properties to remove the global catalog from the DC.
The exception to this rule is the common case of a forest with just one domain. In this case, it is not required
to remove the global catalog. For more information, see Removing the global catalog.
By restoring a global catalog from a backup that is more recent than other backups that are used to restore
DCs in other domains, you might introduce lingering objects. Consider the following example. In domain A,
DC1 is restored from a backup that was taken at time T1. In domain B, DC2 is restored from a global catalog
backup that was taken at time T2. Suppose T2 is more recent than T1, and some objects were created
between T1 and T2. After these DCs are restored, DC2, which is a global catalog, holds newer data for
domain A's partial replica than domain A holds itself. DC2, in this case, holds lingering objects because these
objects are not present on DC1.
The presence of lingering objects can lead to problems. For instance, e-mail messages might not be
delivered to a user whose user object was moved between domains. After you bring the outdated DC or
global catalog server back online, both instances of the user object appear in the global catalog. Both objects
have the same e-mail address; therefore, e-mail messages cannot be delivered.
A second problem is that a user account that no longer exists might still appear in the global address list. A
third problem is that a universal group that no longer exists might still appear in a user's access token.
If you did restore a DC that was a global catalog—either inadvertently or because that was the solitary
backup that you trusted—we recommend that you prevent the occurrence of lingering objects by disabling
the global catalog soon after the restore operation is complete. Disabling the global catalog flag will result in
the computer losing all its partial replicas (partitions) and relegating itself to regular DC status.
13. Configure Windows Time Service. In the forest root domain, configure the PDC emulator to synchronize
time from an external time source. For more information, see Configure the Windows Time service on the
PDC emulator in the Forest Root Domain.
Reconnect each restored writeable domain controller to a common

network
At this stage you should have one DC restored (and recovery steps performed) in the forest root domain and in
each of the remaining domains. Join these DCs to a common network that is isolated from the rest of the
environment and complete the following steps in order to validate forest health and replication.
NOTE
When you join the physical DCs to an isolated network, you may need to change their IP addresses. As a result, the IP
addresses of DNS records will be wrong. Because a global catalog server is not available, secure dynamic updates for DNS will
fail. Virtual DCs are more advantageous in this case because they can be joined to a new virtual network without changing
their IP addresses. This is one reason why virtual DCs are recommended as the first domain controllers to be restored during
forest recovery.
After validation, Join the DCs to the production network and complete the steps to verify forest replication health.
To fix name resolution, create DNS delegation records and configure DNS forwarding and root hints as needed.
Run repadmin /replsum to check replication between DCs.
If the restored DC’s are not direct replication partners, replication recovery will be much faster by creating
temporary connection objects between them.
To validate metadata cleanup, run Repadmin /viewlist \* for a list of all DCs in the forest. Run Nltest /DCList:
<domain> for a list of all DCs in the domain.
To check DC and DNS health, run DCDiag /v to report errors on all DCs in the forest.
Add the global catalog to a domain controller in the forest root domain
A global catalog is required for these and other reasons:
To enable logons for users.
To enable the Net Logon service running on the DCs in each child domain to register and remove records on
the DNS server in the root domain.
Although it is preferred that the forest root DC become a global catalog, it is possible to elect any of the restored
DCs to become a global catalog.
NOTE
A DC will not be advertised as a global catalog server until it has completed a full synchronization of all directory partitions in
the forest. Therefore, the DC should be forced to replicate with each of the restored DCs in the forest.
Monitor the Directory Service event log in Event Viewer for event ID 1119, which indicates that this DC is a global catalog
server, or verify the following registry key has a value of 1:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Global Catalog Promotion Complete
For more information, see Adding the global catalog.

At this stage you should have a stable forest, with one DC for each domain and one global catalog in the forest. You
should make a new backup of each of the DCs that you have just restored. You can now begin to redeploy other
DCs in the forest by installing AD DS.
Next Steps
This section contains procedures related to the forest recovery process. The procedures are applicable for Windows
Server 2016, 2012 R2, 2012 and are also applicable to Windows Server 2008 R2 and 2008 with some minor
exceptions.
Procedures that include steps that vary for Windows Server 2003 are found in Forest Recovery with Windows
Server 2003 Domain Controllers.
The following is a list of procedures that are used in backing up and restoring domain controllers and Active
Directory.
Backing up a full server
Backing up the System State data
Performing a full server recovery
Performing an authoritative synch of DFSR -replicated SYSVOL
Performing a nonauthoritative restore of Active Directory Domain Services
These steps explain how to perform an authoritative restore of SYSVOL at the same time.
Configuring the DNS Server service
Removing the global catalog
Raising the value of available RID pools
Invalidating the current RID pool
Seizing an operations master role
Cleaning up after a restore
Cleaning metadata of removed writable domain controllers
Resetting the computer account password of the domain controller
Resetting the krbtgt password
Resetting a trust password on one side of the trust
Adding the global catalog
Resources to verify replication is working
Next Steps
AD Forest Recovery - FAQ
Applies To: Windows Server 2016, Windows Server 2012 and 2012 R2, Windows Server 2008 and 2008 R2,
Windows Server 2003
This document contains frequently asked questions (FAQs) regarding forest recovery:
General Recovery
Q: What can I do to speed up recovery?
Although speed of recovery is not the primary goal of this guide, you can achieve shorter recovery times by:
Creating a detailed forest recovery plan, updating it on a regular basis, and practicing it in a simulated test
environment of reasonable size at least once a year
Using virtualized domain controller (DC ) cloning
Virtualized DC cloning expedites the process to get additional DCs running after one DC is restored from
backup in each domain. The additional virtualized DCs can be cloned rather than waiting for potentially
lengthy AD DS installations to be completed and for the completion of non-critical replication after
installation.
Forests where virtual DCs are hosted in a relatively small number of well-connected data centers
potentially benefit most from cloning during recovery. However, any environment where multiple
virtualized DCs for the same domain are co-located on the same hypervisor host should benefit.
Deploying read-only domain controllers (RODCs)
RODCs can provide business continuity during the recovery process because they do not have to be
disconnected from the network as writable DCs do. RODCs do not perform outbound replication.
Therefore, they do not present the same risk that writable DCs pose for replicating damaging data back
into the recovered environment.
Other factors that affect the duration of the forest recovery process include the following:
When you restore DCs from backups, it takes time to:
Locate the physical backup media, such as tapes.
Reinstall the operating system.
Restore data from backup media.
You can reduce the time required to reinstall the operating system and restore data from backup
by performing full server recovery instead of system state restore. Because full server recovery is
binary-based, it completes much faster than system state restore.
However, if the server contains data that is excluded from system state data that you do not want
to restore, full server recovery might not be a viable alternative to system state restore. Consider
the advantages of performing a full server recovery instead of a system state restore for your
servers specifically, and prepare accordingly by performing the appropriate type of backup that
you plan to restore later.
When you rebuild DCs, it takes time to replicate data for network-based promotions.
You can decrease the time required for restoring DCs by performing the following steps:
Reduce the time for retrieving backup media by:
Using the Active Directory Database Mounting Tool (Dsamain.exe) to identify the best backup to use for
restore operations. For more information about using the Active Directory Database Mounting Tool, see
the Active Directory Database Mounting Tool Step-by-Step Guide (https://go.microsoft.com/fwlink/?
LinkId=132577).
Labeling the backup media clearly and storing the media in an organized fashion at a convenient, yet
secure, location that allows fast retrieval.
Using the Volume Shadow Copy Service with a storage area network (SAN ) to maintain backups from
different points in time. For more information, see Windows Server 2003 Active Directory Fast Recovery
with Volume Shadow Copy Service and Virtual Disk Service (https://go.microsoft.com/fwlink/?
LinkId=70781).
Force the removal of AD DS from the DCs instead of reinstalling the operating system. If the cause of the
forest-wide failure has been identified to be purely within the scope of AD DS, you do not have to reinstall the
operating system on the DCs.
For more information about forcing the removal of AD DS from a DC that runs Windows Server 2008 or
later, see Forcing the Removal of a Windows Server 2008 Domain Controller
(https://go.microsoft.com/fwlink/?LinkId=132627). For more information about forcing the removal of
AD DS from a DC that runs Windows Server 2003, see article 332199 in the Microsoft Knowledge Base
Use faster tape devices or disk backups to reduce the time that is required for restore operations.
You can also help accelerate AD DS installations by using the Install from Media (IFM ) feature to rebuild DCs in
each domain. IFM reduces the replication latency that is incurred when you rebuild DCs in each domain.
Businesses that have a more aggressive service-level agreement (SLA) might consider altering the forest recovery
procedures to speed recovery.
Q: Can I automate the forest recovery process?
Because of the complex and critical nature of the forest recovery process, there is currently no end-to-end
automation of it. The forest recovery process is more a logistical and organizational challenge of restoring business
continuity than a technical problem of process automation. Therefore, the individual who administers the
environment should create a forest recovery plan that is specific to that environment and then automate sections of
it that can be automated successfully.
You can perform most of the forest recovery steps by using command-line tools. Therefore, most of the steps are
scriptable. For example, Ntdsutil.exe is one of the most frequently used tools in the forest recovery process.
Although scripts can speed recovery, you must thoroughly test these scripts before you apply them in a real
environment. Also, you must update them according to changes in the Active Directory environment, such as the
addition of a new domain or DC, or a new version of Active Directory.
Next Steps
AD Forest Recovery - Recovering a single domain in
a multidomain forest
There can be times when it is necessary to recover only a single domain within a forest that has multiple domains,
rather than a full forest recovery. This topic covers considerations for recovering a single domain and possible
strategies for recovery.
A single domain recovery presents a unique challenge for rebuilding global catalog (GC ) servers. For example, if
the first domain controller (DC ) for the domain is restored from a backup that was created one week earlier, then all
other GCs in the forest will have more up-to-date data for that domain than the restored DC. To re-establish GC
data consistency, there are a couple options:
Unhost and then rehost the recovered domains partition from all GCs in the forest, except those in the
recovered domain, at the same time.
Follow the forest recovery process to recover the domain, and then remove lingering objects from GCs in other
domains.
The following sections provide general considerations for each option. The complete set of steps that need to be
done for the recovery will vary for different Active Directory environments.
Rehost all GCs

WARNING
The password of the Domain Administrator account for all domains must be ready for use in case a problem prevents access
to a GC for logon.
Rehosting all GCs can be done using repadmin /unhost and repadmin /rehost commands (part of repadmin
/experthelp). You would run the repadmin commands on every GC in each domain that is not recovered. It needs to
be ensured, that all GCs do not hold a copy of the recovered domain anymore. To achieve this, unhost the domain
partition first from all domain controllers across all none-recovered domains of the forest first. After all GCs do not
contain the partition anymore, you can rehost it. When rehosting, consider the site- and replication-structure of
your forest, for example, finish the rehost of one DC per site prior to rehosting the other DCs of that site.
This option can be advantageous for a small organization that has only a few domain controllers for each domain.
All of the GCs could be rebuilt on a Friday night and, if necessary, complete replication for all read-only domain
partitions before Monday morning. But if you need to recover a large domain that covers sites across the globe,
rehosting the read-only domain partition on all GCs for other domains can significantly impact operations and
potentially require down time.
Remove lingering objects

Similar to the forest recovery process, you restore one DC from backup in the domain that you need to recover,
perform metadata cleanup of remaining DCs, and then re-install AD DS to build out the domain. On the GCs of all
other domains in the forest, you remove the lingering objects for the read-only partition of the recovered domain.
The source for the lingering object cleanup must be a DC in the recovered domain. To be certain that the source DC
does not have any lingering objects for any domain partitions, you can remove the global catalog if it was a GC.
Removing lingering objects is advantageous for larger organizations that cannot risk the down time associated with
the other options.
For more information, see Use Repadmin to remove lingering objects.
Next Steps
Active Directory Forest Recovery Virtualization
This topic describes the virtualized domain controller cloning feature in Windows Server 2016, 2012 R2, and 2012.
Using virtualized domain controller cloning to expedite forest recovery

Virtualized domain controller (DC ) cloning simplifies and expedites the process for installing additional virtualized
DCs in a domain, especially in centralized locations such as datacenters where several DCs run on hypervisors.
After you restore one virtual DC in each domain from backup, additional DCs in each domain can be rapidly
brought online by using the virtualized DC cloning process. You can prepare the first virtualized DC that you
recover, shut it down, and then copy that virtual hard disk as many times as is necessary in order to create cloned
virtualized DCs to build out the domain.
The requirements for virtualized DC cloning are:
The hypervisor must support VM -GenerationID. Hyper-V in Windows Server 2016, 2012 and Windows 8 is an
example of a hypervisor that supports VM -GenerationID. Check with your hypervisor vendor if VM -
GenerationID is supported.
The virtualized DC that is used as a source for cloning must run Windows Server 2016 or 2012 and be a
member of the Cloneable Domain Controllers group.
The PDC emulator must run Windows Server 2016 or 2012. You can clone PDC emulator if it is virtualized.
For step-by-step instructions about how to perform virtualized DC cloning, see Introduction to Active Directory
Domain Services (AD DS ) Virtualization (Level 100). For details about how virtualized DC cloning works, see
Virtualized Domain Controller Technical Reference (Level 300).
Next steps
AD Forest Recovery - Windows Server 2003
Recovery
This topic includes forest recovery procedures for domain controllers (DCs) that run Windows Server 2003. The
general process for forest recovery is no different with Windows Server 2003 DCs, but specific procedures can
differ because of different tools. For example, Ntdsutil.exe can be used to backup and restore DCs that run
Windows Server 2003 DCs, whereas Windows Server Backup or Wbadmin.exe is used for DCs that run Windows
Server 2008 or later.
[Performing a nonauthoritative restore](#Performing-a-nonauthoritative restore)
Install and configure the DNS Server service

Use the following procedure to back up the System State data, along with any other data you have selected for the
current backup operation, of a DC that runs Windows Server 2003. Windows Server 2003 includes the Ntbackup
tool, which you can use to back up System State data.
Membership in Administrators or Backup Operators, or equivalent, is the minimum required to back up files and
folders.
If you are backing up the System State data to a tape, and the Backup program indicates that there is no unused
media available, you might have to use Removable Storage. This adds your tape to the free media pool so that
Backup can use it.
You can only back up the System State data on a local computer. You cannot back it up on a remote computer.
To back up the System State data on a domain controller that runs Windows Server 2003
1. Click Start, point to All Programs, point to Accessories, point to System Tools, and then click Backup.
2. On the Welcome page, click Advanced Mode.
3. On the Backup tab, select the check box for any drive, folder, or file that you want to back up.
4. Select the System State check box.
5. Click Start Backup.
Performing a nonauthoritative restore

Use the following procedure to perform a nonauthoritative restore of a DC that runs Windows Server 2003. By
performing a nonauthoritative restore on Active Directory in Windows Server 2003, you automatically perform a
nonauthoritative restore of SYSVOL. No additional steps are required.
NOTE
If you are also reinstalling the Windows Server 2003 operating system, you might or might not join the computer to the
domain and you can give any name to the computer during setup of the operating system. Do not install Active Directory.
After reinstalling the operating system, go directly to step 4.
On Windows Server 2003 domain controllers where you have restored only system state data, you need to also
reinstall any software applications that were running on DCs before recovery. Restoring AD DS on the first DC in
the domain also restores the registry because they both are part of System State data. Keep this in mind if you had
any applications running on these DCs and if they had any information stored in the registry.
To save time required to re-install software, determine if applications that need to be installed on the DCs are
compatible with virtual DC cloning. Such applications can be installed on the source DC prior to cloning in order to
save the time and effort required to install them on the cloned virtual DCs.
To perform a nonauthoritative restore
1. After you start the DC, press F8 to restart the computer in Directory Services Restore Mode (DSRM ).
2. Select Directory Services Restore Mode (Windows domain controllers only).
3. Select the operating system that you want to start in restore mode.
4. Log on as an administrator (you can only use a local computer account, no domain logon option is available).
5. At a command prompt, type ntbackup, and then press ENTER.
6. On the Welcome page, click Advanced Mode, and then select the Restore and Manage Media tab. (Do not
select Restore Wizard.)
7. Select the appropriate backup file to restore from and ensure that the System disk and System State check
boxes are selected.
8. Click Start Restore.
9. When the restore operation is complete, restart the computer.
Use the following procedure to perform an authoritative (also known as primary) restore of SYSVOL on a DC that
runs Windows Server 2003. Perform this procedure only on the first Windows Server 2003 DC that is restored in
the domain.
To perform an authoritative restore of SYSVOL
1. Perform steps 1 through 8 in the previous procedure.
2. In the Confirm Restore dialog box, click Advanced.
3. To perform an authoritative restore of SYSVOL, select the check box When restoring replicated data sets,
mark the restored data as the primary data for all replicas.
NOTE
Marking the restored data as the primary data in the Backup is equivalent to setting the BurFlags entry to D4 under
the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\
GUID
4. When the restore operation is complete, restart the computer.
Install and configure the DNS Server service

If the DC that you restored from backup is running Windows Server 2003, you can install DNS server without
connecting the DC to any network.
To install and configure the DNS Server service
1. Open Windows Components Wizard. To open the wizard:
Click Start, click Control Panel, and then click Add or Remove Programs.
Click Add/Remove Windows Components.
2. In Components, select the Networking Services check box, and then click Details.
3. In Subcomponents of Networking Services, select the Domain Name System (DNS ) check box, click OK,
4. If you are prompted, in Copy files from, type the full path of the distribution files, and then click OK.
After the installation, complete the following steps to configure the DNS server.
5. Click Start, point to All Programs, point to Administrative Tools, and then click DNS.
6. Create DNS zones for the same DNS domain names that were hosted on the DNS servers before the critical
malfunction. For more information, see Add a Forward Lookup Zone (https://go.microsoft.com/fwlink/?
LinkId=74574).
7. Configure the DNS data as it existed before the critical malfunction. For example:
Configure DNS zones to be stored in AD DS. For more information, see Change the Zone Type
Configure the DNS zone that is authoritative for domain controller locator (DC Locator) resource records
to allow secure dynamic update. For more information, see Allow Only Secure Dynamic Updates
8. Ensure that the parent DNS zone contains delegation resource records (name server (NS ) and glue host (A)
resource records) for the child zone that is hosted on this DNS server. For more information, see Create a
Zone Delegation (https://go.microsoft.com/fwlink/?LinkId=74562).
9. After you configure DNS, at the command prompt, type the following command, and then press ENTER:
net stop netlogon
10. Type the following command, and then press ENTER:
net start netlogon
NOTE
Net Logon will register the DC Locator resource records in DNS for this DC. If you are installing the DNS Server service
on a server in the child domain, this DC will not be able to register its records immediately. This is because it is
currently isolated as part of the recovery process, and its primary DNS server is the forest root DNS server. Configure
this computer with the same IP address as it had before the disaster to avoid DC service lookup failures.
Next Steps
This document provides a practitioner's perspective and contains a set of practical techniques to help IT executives
protect an enterprise Active Directory environment. Active Directory plays a critical role in the IT infrastructure, and
ensures the harmony and security of different network resources in a global, interconnected environment. The
methods discussed are based largely on the Microsoft Information Security and Risk Management (ISRM )
organization's experience, which is accountable for protecting the assets of Microsoft IT and other Microsoft
Business Divisions, in addition to advising a selected number of Microsoft Global 500 customers.
Executive Summary
Introduction
Avenues to Compromise
Reducing the Active Directory Attack Surface
Implementing Least-Privilege Administrative Models
Securing Domain Controllers Against Attack
Monitoring Active Directory for Signs of Compromise
Planning for Compromise
Maintaining a More Secure Environment
Appendices
Appendix D: Securing Built-In Administrator Accounts in Active Directory
Appendix I: Creating Management Accounts for Protected Accounts and Groups in Active Directory
Executive Summary
IMPORTANT
The following documentation was written in 2013 and is provided for historical purposes only. Currently we are reviewing this
documentation and it is subject to change. It may not reflect current best practices.
No organization with an information technology (IT) infrastructure is immune from attack, but if appropriate
policies, processes, and controls are implemented to protect key segments of an organization's computing
infrastructure, it might be possible to prevent a breach event from growing to a wholesale compromise of the
computing environment.
This executive summary is intended to be useful as a standalone document summarizing the content of the
document, which contains recommendations that will assist organizations in enhancing the security of their Active
Directory installations. By implementing these recommendations, organizations will be able to identify and
prioritize security activities, protect key segments of their organization's computing infrastructure, and create
controls that significantly decrease the likelihood of successful attacks against critical components of the IT
environment.
Although this document discusses the most common attacks against Active Directory and countermeasures to
reduce the attack surface, it also contains recommendations for recovery in the event of complete compromise. The
only sure way to recover in the event of a complete compromise of Active Directory is to be prepared for the
compromise before it happens.
The major sections of this document are:
This section provides information about some of the most commonly leveraged vulnerabilities used by attackers to
compromise customers' infrastructures. It contains general categories of vulnerabilities and how they're used to
initially penetrate customers' infrastructures, propagate compromise across additional systems, and eventually
target Active Directory and domain controllers to obtain complete control of the organizations' forests. It does not
provide detailed recommendations about addressing each type of vulnerability, particularly in the areas in which
the vulnerabilities are not used to directly target Active Directory. However, for each type of vulnerability, we have
provided links to additional information to use to develop countermeasures and reduce the organization's attack
surface.
Included are the following subjects:
Initial breach targets - Most information security breaches start with the compromise of small pieces of an
organization's infrastructure-often one or two systems at a time. These initial events, or entry points into the
network, often exploit vulnerabilities that could have been fixed, but weren't. Commonly seen vulnerabilities
are:
Gaps in antivirus and antimalware deployments
Incomplete patching
Outdated applications and operating systems
Misconfiguration
Lack of secure application development practices
Attractive Accounts for Credential Theft - Credential theft attacks are those in which an attacker initially
gains privileged access to a computer on a network and then uses freely available tooling to extract
credentials from the sessions of other logged-on accounts.
Included in this section are the following:
Activities that Increase the Likelihood of Compromise - Because the target of credential theft is
usually highly privileged domain accounts and "very important person" (VIP ) accounts, it is important
for administrators to be conscious of activities that increase the likelihood of a success of a credential-
theft attack. These activities are:
Logging on to unsecured computers with privileged accounts
Browsing the Internet with a highly privileged account
Configuring local privileged accounts with the same credentials across systems
Overpopulation and overuse of privileged domain groups
Insufficient management of the security of domain controllers.
Privilege Elevation and Propagation - Specific accounts, servers, and infrastructure components
are usually the primary targets of attacks against Active Directory. These accounts are:
Permanently privileged accounts
VIP accounts
"Privilege-Attached" Active Directory accounts
Domain controllers
Other infrastructure services that affect identity, access, and configuration management, such
as public key infrastructure (PKI) servers and systems management servers

This section focuses on technical controls to reduce the attack surface of an Active Directory installation. Included in
this section are the following subjects:
The Privileged Accounts and Groups in Active Directory section discusses the highest privileged
accounts and groups in Active Directory and the mechanisms by which privileged accounts are protected.
Within Active Directory, three built-in groups are the highest privilege groups in the directory (Enterprise
Admins, Domain Admins, and Administrators), although a number of additional groups and accounts should
also be protected.
The Implementing Least-Privilege Administrative Models section focuses on identifying the risk that
the use of highly privileged accounts for day-to-day administration presents, in addition to providing
recommendations to reduce that risk.
Excessive privilege isn't only found in Active Directory in compromised environments. When an organization has
developed the habit of granting more privilege than is required, it is typically found throughout the infrastructure:
In Active Directory
On member servers
On workstations
In applications
In data repositories
The Implementing Secure Administrative Hosts section describes secure administrative hosts, which are
computers that are configured to support administration of Active Directory and connected systems. These
hosts are dedicated to administrative functionality and do not run software such as email applications, web
browsers, or productivity software (such as Microsoft Office).
Included in this section are the following:
Principles for Creating Secure Administrative Hosts - The general principles to keep in mind are:
Never administer a trusted system from a less-trusted host.
Do not rely on a single authentication factor when performing privileged activities.
Do not forget physical security when designing and implementing secure administrative hosts.
Securing Domain Controllers Against Attack - If a malicious user obtains privileged access to a domain
controller, that user can modify, corrupt, and destroy the Active Directory database, and by extension, all of
the systems and accounts that are managed by Active Directory.
Included in this section are the following subjects:
Physical Security for Domain Controllers - Contains recommendations for providing physical security
for domain controllers in datacenters, branch offices, and remote locations.
Domain Controller Operating Systems - Contains recommendations for securing the domain controller
operating systems.
Secure Configuration of Domain Controllers - Native and freely available configuration tools and
settings can be used to create security configuration baselines for domain controllers that can subsequently
be enforced by Group Policy Objects (GPOs).

This section provides information about legacy audit categories and audit policy subcategories (which were
introduced in Windows Vista and Windows Server 2008), and Advanced Audit Policy (which was introduced in
Windows Server 2008 R2). Also provided is information about events and objects to monitor that can indicate
attempts to compromise the environment and some additional references that can be used to construct a
comprehensive audit policy for Active Directory.
Windows Audit Policy - Windows security event logs have categories and subcategories that determine
which security events are tracked and recorded.
Audit Policy Recommendations - This section describes the Windows default audit policy settings, audit
policy settings that are recommended by Microsoft, and more aggressive recommendations for
organizations to use to audit critical servers and workstations.
This section contains recommendations that will help organizations prepare for a compromise before it happens,
implement controls that can detect a compromise event before a full breach has occurred, and provide response
and recovery guidelines for cases in which a complete compromise of the directory is achieved by attackers.
Rethinking the Approach - Contains principles and guidelines to create secure environments into which
an organization can place their most critical assets. These guidelines are as follows:
Identifying principles for segregating and securing critical assets
Defining a limited, risk-based migration plan
Leveraging "nonmigratory" migrations where necessary
Implementing "creative destruction"
Isolating legacy systems and applications
Simplifying security for end users
Maintaining a More Secure Environment - Contains high-level recommendations meant to be used as
guidelines to use in developing not only effective security, but effective lifecycle management. Included in
this section are the following subjects:
Creating Business-Centric Security Practices for Active Directory - To effectively manage the
lifecycle of the users, data, applications and systems managed by Active Directory, follow these
principles.
Assign a Business Ownership to Active Directory Data - Assign ownership of
infrastructure components to IT; for data that is added to Active Directory Domain Services
(AD DS ) to support the business, for example, new employees, new applications, and new
information repositories, a designated business unit or user should be associated with the data.
Implement Business-Driven Lifecycle Management - Lifecycle management should be
implemented for data in Active Directory.
Classify all Active Directory Data - Business owners should provide classification for data in
Active Directory. Within the data classification model, classification for the following Active
Directory data should be included:
Systems - Classify server populations, their operating system their role, the applications
running on them, and the IT and business owners of record.
Applications - Classify applications by functionality, user base, and their operating
system.
Users - The accounts in the Active Directory installations that are most likely to be
targeted by attackers should be tagged and monitored.
Summary of Best Practices for Securing Active Directory Domain

Services
The following table provides a summary of the recommendations provided in this document for securing an AD
DS installation. Some best practices are strategic in nature and require comprehensive planning and
implementation projects; others are tactical and focused on specific components of Active Directory and related
infrastructure.
Practices are listed in approximate order of priority, that is., lower numbers indicate higher priority. Where
applicable, best practices are identified as preventative or detective in nature. All of these recommendations should
be thoroughly tested and modified as needed for your organization's characteristics and requirements.
BEST PRACTICE TACTICAL OR STRATEGIC PREVENTATIVE OR DETECTIVE
1 Patch applications. Tactical Preventative
2 Patch operating systems. Tactical Preventative
3 Deploy and promptly update Tactical Both

antivirus and antimalware
software across all systems
and monitor for attempts to
remove or disable it.
4 Monitor sensitive Active Tactical Detective

Directory objects for
modification attempts and
Windows for events that
may indicate attempted
compromise.
5 Protect and monitor Tactical Both

accounts for users who have
access to sensitive data
6 Prevent powerful accounts Tactical Preventative

from being used on
unauthorized systems.
7 Eliminate permanent Tactical Preventative

membership in highly
privileged groups.
8 Implement controls to grant Tactical Preventative

temporary membership in
privileged groups when
needed.
9 Implement secure Tactical Preventative

administrative hosts.
10 Use application whitelisting Tactical Preventative

on domain controllers,
administrative hosts, and
other sensitive systems.
11 Identify critical assets, and Tactical Both

prioritize their security and
monitoring.
12 Implement least-privilege, Strategic Preventative

role-based access controls
for administration of the
directory, its supporting
infrastructure, and domain-
joined systems.
BEST PRACTICE TACTICAL OR STRATEGIC PREVENTATIVE OR DETECTIVE
13 Isolate legacy systems and Tactical Preventative

applications.
14 Decommission legacy Strategic Preventative

systems and applications.
15 Implement secure Strategic Preventative

development lifecycle
programs for custom
applications.
16 Implement configuration Strategic Preventative

management, review
compliance regularly, and
evaluate settings with each
new hardware or software
version.
17 Migrate critical assets to Strategic Both

pristine forests with
stringent security and
monitoring requirements.
18 Simplify security for end Strategic Preventative

users.
19 Use host-based firewalls to Tactical Preventative

control and secure
communications.
20 Patch devices. Tactical Preventative
21 Implement business-centric Strategic N/A

lifecycle management for IT
assets.
22 Create or update incident Strategic N/A

recovery plans.
Introduction
Attacks against computing infrastructures, whether simple or complex, have existed as long as computers have.
However, within the past decade, increasing numbers of organizations of all sizes, in all parts of the world have
been attacked and compromised in ways that have significantly changed the threat landscape. Cyber-warfare and
cybercrime have increased at record rates. "Hacktivism," in which attacks are motivated by activist positions, has
been claimed as the motivation for a number of breaches intended to expose organizations' secret information, to
create denials-of-service, or even to destroy infrastructure. Attacks against public and private institutions with the
goal of exfiltrating the organizations' intellectual property (IP ) have become ubiquitous.
No organization with an information technology (IT) infrastructure is immune from attack, but if appropriate
policies, processes, and controls are implemented to protect key segments of an organization's computing
infrastructure, escalation of attacks from penetration to complete compromise might be preventable. Because the
number and scale of attacks originating from outside an organization has eclipsed insider threat in recent years, this
document often discusses external attackers rather than misuse of the environment by authorized users.
Nonetheless, the principles and recommendations provided in this document are intended to help secure your
environment against external attackers and misguided or malicious insiders.
The information and recommendations provided in this document are drawn from a number of sources and
derived from practices designed to protect Active Directory installations against compromise. Although it is not
possible to prevent attacks, it is possible to reduce the Active Directory attack surface and to implement controls
that make compromise of the directory much more difficult for attackers. This document presents the most
common types of vulnerabilities we have observed in compromised environments and the most common
recommendations we have made to customers to improve the security of their Active Directory installations.
Account and Group Naming Conventions

The following table provides a guide to the naming conventions used in this document for the groups and accounts
referenced throughout the document. Included in the table is the location of each account/group, its name, and how
these accounts/groups are referenced in this document.
HOW IT IS REFERENCED IN THIS

ACCOUNT/GROUP LOCATION NAME OF ACCOUNT/GROUP DOCUMENT
Active Directory - each domain Administrator Built-in Administrator account
Active Directory - each domain Administrators Built-in Administrators (BA) group
Active Directory - each domain Domain Admins Domain Admins (DA) group
Active Directory - forest root domain Enterprise Admins Enterprise Admins (EA) group
Local computer security accounts Administrator Local Administrator account

manager (SAM) database on computers
running Windows Server and
workstations that are not domain
controllers
HOW IT IS REFERENCED IN THIS
ACCOUNT/GROUP LOCATION NAME OF ACCOUNT/GROUP DOCUMENT
Local computer security accounts Administrators Local Administrators group

manager (SAM) database on computers
running Windows Server and
workstations that are not domain
controllers
About This Document

The Microsoft Information Security and Risk Management (ISRM ) organization, which is part of Microsoft
Information Technology (MSIT), works with internal business units, external customers, and industry peers to
gather, disseminate, and define policies, practices, and controls. This information can be used by Microsoft and our
customers to increase the security and reduce the attack surface of their IT infrastructures. The recommendations
provided in this document are based on a number of information sources and practices used within MSIT and
ISRM. The following sections present more information about the origins of this document.
Microsoft IT and ISRM
A number of practices and controls have been developed within MSIT and ISRM to secure the Microsoft AD DS
forests and domains. Where these controls are broadly applicable, they have been integrated into this document.
SAFE -T (Solution Accelerators for Emerging Technologies) is a team within ISRM whose charter is to identify
emerging technologies, and to define security requirements and controls to accelerate their adoption.
Active Directory Security Assessments
Within Microsoft ISRM, the Assessment, Consulting, and Engineering (ACE ) Team works with internal Microsoft
business units and external customers to assess application and infrastructure security and to provide tactical and
strategic guidance to increase the organization's security posture. One ACE service offering is the Active Directory
Security Assessment (ADSA), which is a holistic assessment of an organization's AD DS environment that assesses
people, process, and technology and produces customer-specific recommendations. Customers are provided with
recommendations that are based on the organization's unique characteristics, practices, and risk appetite. ADSAs
have been performed for Active Directory installations at Microsoft in addition to those of our customers. Over
time, a number of recommendations have been found to be applicable across customers of varying sizes and
industries.
Content Origin and Organization
Much of the content of this document is derived from the ADSA and other ACE Team assessments performed for
compromised customers and customers who have not experienced significant compromise. Although individual
customer data was not used to create this document, we have collected the most commonly exploited
vulnerabilities we have identified in our assessments and the recommendations we have made to customers to
improve the security of their AD DS installations. Not all vulnerabilities are applicable to all environments, nor are
all recommendations feasible to implement in every organization.
This document is organized as follows:
Executive Summary
The Executive Summary, which can be read as a standalone document or in combination with the full document,
provides a high-level summary of this document. Included in the Executive Summary are the most common attack
vectors we have observed used to compromise customer environments, summary recommendations for securing
Active Directory installations, and basic objectives for customers who plan to deploy new AD DS forests now or in
the future.
Introduction
This is the section you are reading now.
This section provides information about some of the most commonly leveraged vulnerabilities we have found to be
used by attackers to compromise customers' infrastructures. This section begins with general categories of
vulnerabilities and how they are leveraged to initially penetrate customers' infrastructures, propagate compromise
across additional systems, and eventually target AD DS and domain controllers to obtain complete control of
organizations' forests.
This section does not provide detailed recommendations about addressing each type of vulnerability, particularly in
the areas in which the vulnerabilities are not used to directly target Active Directory. However, for each type of
vulnerability, we have provided links to additional information that you can use to develop countermeasures and
reduce your organization's attack surface.
This section begins by providing background information about privileged accounts and groups in Active Directory
to provide the information that helps clarify the reasons for the subsequent recommendations for securing and
managing privileged groups and accounts. We then discuss approaches to reduce the need to use highly privileged
accounts for day-to-day administration, which does not require the level of privilege that is granted to groups such
as the Enterprise Admins (EA), Domain Admins (DA), and Built-in Administrators (BA) groups in Active Directory.
Next, we provide guidance for securing the privileged groups and accounts and for implementing secure
administrative practices and systems.
Although this section provides detailed information about these configuration settings, we have also included
appendices for each recommendation that provide step-by-step configuration instructions that can be used "as is"
or can be modified for the organization's needs. This section finishes by providing information to securely deploy
and manage domain controllers, which should be among the most stringently secured systems in the infrastructure.
Whether you have implemented robust security information and event monitoring (SIEM ) in your environment or
are using other mechanisms to monitor the security of the infrastructure, this section provides information that can
be used to identify events on Windows systems that may indicate that an organization is being attacked. We discuss
traditional and advanced audit policies, including effective configuration of audit subcategories in the Windows 7
and Windows Vista operating systems. This section includes comprehensive lists of objects and systems to audit,
and an associated appendix lists events for which you should monitor if the goal is to detect compromise attempts.
This section begins by "stepping back" from technical detail to focus on principles and processes that can be
implemented to identify the users, applications, and systems that are most critical not only to the IT infrastructure,
but to the business. After identifying what is most critical to the stability and operations of your organization, you
can focus on segregating and securing these assets, whether they are intellectual property, people, or systems. In
some cases, segregating and securing assets may be performed in your existing AD DS environment, while in other
cases, you should consider implementing small, separate "cells" that allow you to establish a secure boundary
around critical assets and monitor those assets more stringently than less-critical components. A concept called
"creative destruction," which is a mechanism by which legacy applications and systems can be eliminated by
creating new solutions is discussed, and the section ends with recommendations that can help to maintain a more
secure environment by combining business and IT information to construct a detailed picture of what is a normal
operational state. By knowing what is normal for an organization, abnormalities that may indicate attacks and
compromises can be more easily identified.
Summary of Best Practice Recommendations
This section provides a table that summarizes the recommendations made in this document and orders them by
relative priority, in addition to providing links to where more information about each recommendation can be
found in the document and its appendices.
Appendices
Appendices are included in this document to augment the information contained in the body of the document. The
list of appendices and a brief description of each is included the following table.
APPENDIX DESCRIPTION
Appendix B: Privileged Accounts and Groups in Active Provides background information that helps you to identify
Directory the users and groups you should focus on securing because
they can be leveraged by attackers to compromise and even
destroy your Active Directory installation.
Appendix C: Protected Accounts and Groups in Active Contains information about protected groups in Active
Directory Directory. It also contains information for limited
customization (removal) of groups that are considered
protected groups and are affected by AdminSDHolder and
SDProp.
Appendix D: Securing Built-In Administrator Accounts in Active Contains guidelines to help secure the Administrator account
Directory in each domain in the forest.
Appendix E: Securing Enterprise Admins Groups in Active Contains guidelines to help secure the Enterprise Admins
Directory group in the forest.
Appendix F: Securing Domain Admins Groups in Active Contains guidelines to help secure the Domain Admins group
Appendix G: Securing Administrators Groups in Active Contains guidelines to help secure the Built-in Administrators
Directory group in each domain in the forest.
Appendix H: Securing Local Administrator Accounts and Contains guidelines to help secure local Administrator
Groups accounts and Administrators groups on domain-joined servers
and workstations.
Appendix I: Creating Management Accounts for Protected Provides information to create accounts that have limited
Accounts and Groups in Active Directory privileges and can be stringently controlled, but can be used to
populate privileged groups in Active Directory when
temporary elevation is required.
Appendix L: Events to Monitor Lists events for which you should monitor in your
environment.
Appendix M: Document Links and Recommended Reading Contains a list of recommended reading. Also contains a list of
links to external documents and their URLs so that readers of
hard copies of this document can access this information.
Law Number Seven: The most secure network is a well-administered one. - 10 Immutable Laws of Security
Administration
In organizations that have experienced catastrophic compromise events, assessments usually reveal that the
organizations have limited visibility into the actual state of their IT infrastructures, which may differ significantly
from their "as documented" states. These variances introduce vulnerabilities that expose the environment to
compromise, often with little risk of discovery until the compromise has progressed to the point at which the
attackers effectively "own" the environment.
Detailed assessments of these organizations' AD DS configuration, public key infrastructures (PKIs), servers,
workstations, applications, access control lists (ACLs), and other technologies reveal misconfigurations and
vulnerabilities that, if remediated, could have prevented the initial compromise.
Analysis of IT documentation, processes, and procedures identifies vulnerabilities introduced by gaps in
administrative practices that were leveraged by attackers to eventually obtain privileges that were used to fully
compromise the Active Directory forest. A fully compromised forest is one in which attackers compromise not only
individual systems, applications, or user accounts, but escalate their access to obtain a level of privilege in which
they can modify or destroy all aspects of the forest. When an Active Directory installation has been compromised to
that degree, attackers can make changes that allow them to maintain a presence throughout the environment, or
worse, to destroy the directory and the systems and accounts it manages.
Although a number of the commonly exploited vulnerabilities in the descriptions that follow are not attacks against
Active Directory, they allow attackers to establish a foothold in an environment that can be used to run privilege
escalation (also called privilege elevation) attacks and to eventually target and compromise AD DS.
This section of this document focuses on describing the mechanisms that attackers typically use to gain access to
the infrastructure and eventually to launch privilege elevation attacks. Also see the following sections:
Reducing the Active Directory Attack Surface Detailed recommendations for the secure configuration of
Active Directory.
Monitoring Active Directory for Signs of Compromise Recommendations to help detect compromise
Planning for Compromise High-level approaches to help prepare for attacks against the infrastructure from
IT and business perspectives
NOTE
Although this document focuses on Active Directory and Windows systems that are part of an AD DS domain, attackers
rarely focus solely on Active Directory and Windows. In environments with a mixture of operating systems, directories,
applications, and data repositories, it is common to find that non-Windows systems have also been compromised. This is
particularly true if the systems provide a "bridge" between Windows and non-Windows environments, such as file servers
accessed by Windows and UNIX or Linux clients, directories that provide authentication services to multiple operating
systems, or metadirectories that synchronize data across disparate directories.
AD DS is targeted because of the centralized access and configuration management capabilities it provides not only to
Windows systems, but to other clients. Any other directory or application that provides authentication and configuration
management services can, and will be targeted by determined attackers. Although this document is focused on protections
that can reduce the likelihood of a compromise of Active Directory installations, every organization that includes non-
Windows computers, directories, applications, or data repositories should also prepare for attacks against those systems.
Initial Breach Targets

Nobody intentionally builds an IT infrastructure that exposes the organization to compromise. When an Active
Directory forest is first constructed, it is usually pristine and current. As years pass and new operating systems and
applications are acquired, they're added to the forest. As the manageability benefits that Active Directory provides
are recognized, more and more content is added to the directory, more people integrate their computers or
applications with AD DS, and domains are upgraded to support new functionality offered by the most current
versions of the Windows operating system. What also happens over time, however, is that even as a new
infrastructure is being added, other parts of the infrastructure might not be maintained as well as they initially were,
systems and applications are functioning properly and therefore are not receiving attention, and organizations
begin to forget that they have not eliminated their legacy infrastructure. Based on what we see in assessing
compromised infrastructures, the older, larger, and more complex the environment, the more likely it is that there
are numerous instances of commonly exploited vulnerabilities.
Regardless of the motivation of the attacker, most information security breaches start with the compromise of one
or two systems at a time. These initial events, or entry points into the network, often leverage vulnerabilities that
could have been fixed, but were not. The 2012 Data Breach Investigations Report (DBIR ), which is an annual study
produced by the Verizon RISK Team in cooperation with a number of national security agencies and other
companies, states that 96 percent of attacks were "not highly difficult," and that "97 percent of breaches were
avoidable through simple or intermediate controls." These findings may be a direct consequence of the commonly
exploited vulnerabilities that follow.
Gaps in Antivirus and Antimalware Deployments
Law Number Eight: An out-of-date malware scanner is only marginally better than no scanner at all. - Ten
Immutable Laws of Security (Version 2.0)
Analysis of organizations' antivirus and antimalware deployments often reveals an environment in which most
workstations are configured with antivirus and antimalware software that is enabled and current. Exceptions are
usually workstations that connect infrequently to the corporate environment or employee devices for which
antivirus and antimalware software can be difficult to deploy, configure, and update.
Server populations, however, tend to be less consistently protected in many compromised environments. As
reported in the 2012 Data Breach Investigations, 94 percent of all data compromises involved servers, which
represents an 18 percent increase over the previous year, and 69 percent of attacks incorporated malware. In server
populations, it is not uncommon to find that antivirus and antimalware installations are inconsistently configured,
outdated, misconfigured, or even disabled. In some cases, the antivirus and antimalware software is disabled by
administrative staff, but in other cases, attackers disable the software after compromising a server via other
vulnerabilities. When the antivirus and antimalware software is disabled, the attackers then plant malware on the
server and focus on propagating compromise across the server population.
It is important not only to ensure that your systems are protected with current, comprehensive malware protection,
but also to monitor systems for disabling or removal of antivirus and antimalware software and to automatically
restart protection when it is manually disabled. Although no antivirus and antimalware software can guarantee
prevention and detection of all infections, a properly configured and deployed antivirus and antimalware
implementation can reduce the likelihood of infection.
Incomplete Patching
Law Number Three: If you don't keep up with security fixes, your network won't be yours for long. - 10 Immutable
Laws of Security Administration
Microsoft releases security bulletins on the second Tuesday of each month, although on rare occasions security
updates are released between the monthly security updates (these are also known as "out-of-band" updates) when
the vulnerability is determined to pose an urgent risk to customer systems. Whether a small business configures its
Windows computers to use Windows Update to manage system and application patching or a large organization
uses management software such as System Center Configuration Manager (SCCM ) to deploy patches according to
detailed, hierarchical plans, many customers patch their Windows infrastructures in a relatively timely manner.
However, few infrastructures include only Windows computers and Microsoft applications, and in compromised
environments, it is common to find that the organization's patch management strategy contains gaps. Windows
systems in these environments are inconsistently patched. Non-Windows operating systems are patched
sporadically, if at all. Commercial off-the-shelf (COTS ) applications contain vulnerabilities for which patches exist,
but have not been applied. Networking devices are often configured with factory-default credentials and no
firmware updates years after their installation. Applications and operating systems that are no longer supported by
their vendors are often kept running, despite the fact that they can no longer be patched against vulnerabilities.
Each of these unpatched systems represents another potential entry point for attackers.
The consumerization of IT has introduced additional challenges in that employee owned devices are being used to
access corporate owned data, and the organization may have little to no control over the patching and
configuration of employees' personal devices. Enterprise-class hardware typically ships with enterprise-ready
configuration options and management capabilities, at the cost of less choice in individual customization and device
selection. Employee-focused hardware offers a broader range of manufacturers, vendors, hardware security
features, software security features, management capabilities and configuration options, and many enterprise
features may be absent altogether.
Patch and Vulnerability Management Software
If an effective patch management system is in place for the Windows systems and Microsoft applications, part of
the attack surface that unpatched vulnerabilities create has been addressed. However, unless the non-Windows
systems, non-Microsoft applications, network infrastructure, and employee devices are also kept up-to-date on
patches and other fixes, the infrastructure remains vulnerable. In some cases, an application's vendor may offer
automatic update capabilities; in others, there may be a need to devise an approach to regularly retrieve and apply
patches and other fixes.
Outdated Applications and Operating Systems
"You can't expect a six-year-old operating system to protect you against a six-month-old attack." - Information
Security Professional with 10 years of experience securing enterprise installations
Although "get current, stay current" may sound like a marketing phrase, outdated operating systems and
applications create risk in many organizations' IT infrastructures. An operating system that was released in 2003
might still be supported by the vendor and provided with updates to address vulnerabilities, but that operating
system might not contain security features added in newer versions of the operating system. Outdated systems can
even require weakening of certain AD DS security configuration to support the lesser capabilities of those
computers.
Applications that were written to use legacy authentication protocols by vendors who are no longer supporting the
application usually cannot be retooled to support stronger authentication mechanisms. However, an organization's
Active Directory domain may still be configured to store LAN Manager hashes or reversibly encrypted passwords
to support such applications. Applications written prior to the introduction of newer operating systems may not
function well or at all on current operating systems, requiring organizations to maintain older and older systems,
and in some cases, completely unsupported hardware and software.
Even in cases in which organizations have updated their domain controllers to Windows Server 2012, Windows
Server 2008 R2, or Windows Server 2008, it is typical to find significant portions of the member server population
to be running Windows Server 2003, Windows 2000 Server or Windows NT Server 4.0 (which are completely
unsupported). The longer an organization maintains aging systems, the more the disparity between feature sets
grows, and the more likely it becomes that production systems will be unsupported. Additionally, the longer an
Active Directory forest is maintained, the more we observe that legacy systems and applications are missed in
upgrade plans. This can mean that a single computer running a single application can introduce domain- or forest-
wide vulnerabilities because Active Directory is configured to support its legacy protocols and authentication
mechanisms.
To eliminate legacy systems and applications, you should first focus on identifying and cataloging them, then on
determining whether to upgrade or replace the application or host. Although it can be difficult to find replacements
for highly specialized applications for which there is neither support nor an upgrade path, you may be able to
leverage a concept called "creative destruction" to replace the legacy application with a new application that
provides the necessary functionality. Planning for Compromise is described in more depth in "Planning for
Compromise" later in this document.
Misconfiguration
Law Number Four: It doesn't do much good to install security fixes on a computer that was never secured to begin
with. - 10 Immutable Laws of Security Administration
Even in environments where systems are generally kept current and patched, we commonly identify gaps or
misconfigurations in the operating system, applications running on computers, and Active Directory. Some
misconfigurations expose only the local computer to compromise, but after a computer is "owned," attackers
usually focus on further propagating the compromise across other systems and eventually to Active Directory.
Following are some of the common areas in which we identify configurations that introduce risk.
In Active Directory
The accounts in Active Directory that are most commonly targeted by attackers are those that are members of the
most-highly privileged groups, such as members of the Domain Admins (DA), Enterprise Admins (EA), or built-in
Administrators (BA) groups in Active Directory. The membership of these groups should be reduced to the smallest
number of accounts possible so that the attack surface of these groups is limited. It is even possible to eliminate
"permanent" membership in these privileged groups; that is, you can implement settings that allow you to
temporarily populate these groups only when their domain- and forest-wide privileges are needed. When highly
privileged accounts are used, they should be used only on designated, secure systems such as domain controllers
or secure administrative hosts. Detailed information to help implement all of these configurations is provided in
Reducing the Active Directory Attack Surface.
When we evaluate the membership of the highest privileged groups in Active Directory, we commonly find
excessive membership in all three of the most- privileged groups. In some cases, organizations have dozens, even
hundreds of accounts in DA groups. In other cases, organizations place accounts directly into built-in
Administrators groups, thinking that the group is "less privileged" than the DAs group. It is not. We often find a
handful of permanent members of the EA group in the forest root domain, despite the fact that EA privileges are
rarely and temporarily required. Finding an IT user's day-to-day administrative account in all three groups is also
common, even though this is an effectively redundant configuration. As described in Reducing the Active Directory
Attack Surface, whether an account is a permanent member of one of these groups or all of them, the account can
be used to compromise, and even destroy the AD DS environment and the systems and accounts managed by it.
Recommendations for the secure configuration and use of privileged accounts in Active Directory are provided in
Reducing the Active Directory Attack Surface.
On Domain Controllers
When we assess domain controllers, we find often find them configured and managed no differently than member
servers. Domain controllers sometimes run the same applications and utilities installed on member servers, not
because they're needed on the domain controllers, but because the applications are part of a standard build. These
applications may provide minimal functionality on the domain controllers but add significantly to its attack surface
by requiring configuration setting that open ports, create highly privileged service accounts, or grant access to the
system by users who should not connect to a domain controller for any purpose other than authentication and
Group Policy application. In some breaches, attackers have used tools that were already installed on domain
controllers not only to gain access to the domain controllers, but to modify or damage the AD DS database.
When we extract the Internet Explorer configuration settings on domain controllers, we find that users have logged
on with accounts that have high levels of privilege in Active Directory and have used the accounts to access the
Internet and intranet from the domain controllers. In some cases, the accounts have configured Internet Explorer
settings on the domain controllers to allow download of Internet content, and freeware utilities have been
downloaded from Internet sites and installed on the domain controllers. Internet Explorer Enhanced Security
Configuration is enabled for Users and Administrators by default, yet we often observe that is has been disabled
for Administrators. When a highly privileged account accesses the Internet and downloads content to any
computer, that computer is put at severe risk. When the computer is a domain controller, the entire AD DS
installation is put at risk.
Pr o t ec t i n g Do m ai n Co n t r o l l er s
Domain controllers should be treated as critical infrastructure components, secured more stringently and
configured more rigidly than file, print, and application servers. Domain controllers should not run any software
that is not required for the domain controller to function or doesn't protect the domain controller against attacks.
Domain controllers should not be permitted to access the Internet, and security settings should be configured and
enforced by Group Policy Objects (GPOs). Detailed recommendations for the secure installation, configuration, and
management of domain controllers are provided in Securing Domain Controllers Against Attack.
Within the Operating System
Law Number Two: If a bad guy can alter the operating system on your computer, it's not your computer anymore. -
Ten Immutable Laws of Security (Version 2.0)
Although some organizations create baseline configurations for servers of different types and allow limited
customization of the operating system after it's installed, analysis of compromised environments often uncovers
large numbers of servers deployed in an ad hoc fashion, and configured manually and independently.
Configurations between two servers performing the same function may be completely different, where neither
server is configured securely. Conversely, server configuration baselines may be consistently enforced, but also
consistently misconfigured; that is, servers are configured in a manner that creates the same vulnerability on all
servers of a given type. Misconfiguration includes practices such as disabling of security features, granting
excessive rights and permissions to accounts (particularly service accounts), use of identical local credentials across
systems, and permitting installation of unauthorized applications and utilities that create vulnerabilities of their
own.
D i sa b l i n g Se c u r i t y F e a t u r e s
Organizations sometimes disable Windows Firewall with Advanced Security (WFAS ) out of a belief that WFAS is
difficult to configure or requires work-intensive configuration. However, beginning with Windows Server 2008,
when any role or feature is installed on a server, it is configured by default with the least privileges required for the
role or feature to function, and the Windows Firewall is automatically configured to support the role or feature. By
disabling WFAS (and not using another host-based firewall in its place), organizations increase the attack surface of
the entire Windows environment. Perimeter firewalls provide some protection against attacks that directly target an
environment from the Internet, but they provide no protection against attacks that exploit other attack vectors such
as drive-by download attacks, or attacks that originate from other compromised systems on the intranet.
User Account Control (UAC ) settings are sometimes disabled on servers because administrative staff find the
prompts intrusive. Although Microsoft Support article 2526083 describes scenarios in which UAC may be disabled
on Windows Server, unless you are running a server core installation (where UAC is disabled by design), you
should not disable UAC on servers without careful consideration and research.
In other cases, server settings are configured to less-secure values because organizations apply outdated server
configuration settings to new operating systems, such as applying Windows Server 2003 baselines to computers
running Windows Server 2012, Windows Server 2008 R2, or Windows Server 2008, without changing the
baselines to reflect the changes in the operating system. Rather than carrying old server baselines to new operating
systems, when deploying a new operating system, review security changes and configuration settings to ensure
that the settings implemented are applicable and appropriate for the new operating system.
G r a n t i n g Ex c e ssi v e P r i v i l e g e
In nearly every environment we have assessed, excessive privilege is granted to local and domain-based accounts
on Windows systems. Users are granted local Administrator rights on their workstations, member servers run
services that are configured with rights beyond what they need to function, and local Administrators groups across
the server population contain dozens or even hundreds of local and domain accounts. Compromise of only one
privileged account on a computer allows attackers to compromise the accounts of every user and service that logs
on to the computer, and to harvest and leverage credentials to propagate the compromise to other systems.
Although pass-the-hash (PTH) and other credential theft attacks are ubiquitous today, it is because there is freely
available tooling that makes it simple and easy to extract the credentials of other privileged accounts when an
attacker has gained Administrator- or SYSTEM -level access to a computer. Even without tooling that allows
harvesting of credentials from logon sessions, an attacker with privileged access to a computer can just as easily
install keystroke loggers that capture keystrokes, screenshots, and clipboard contents. An attacker with privileged
access to a computer can disable antimalware software, install rootkits, modify protected files, or install malware on
the computer that automates attacks or turns a server into a drive-by download host.
The tactics used to extend a breach beyond a single computer vary, but the key to propagating compromise is the
acquisition of highly privileged access to additional systems. By reducing the number of accounts with privileged
access to any system, you reduce the attack surface not only of that computer, but the likelihood of an attacker
harvesting valuable credentials from the computer.
St a n d a r d i z i n g L o c a l A d m i n i st r a t o r C r e d e n t i a l s
There has long been debate among security specialists as to whether there is value in renaming local Administrator
accounts on Windows computers. What is actually important about local Administrator accounts is whether they
are configured with the same user name and password across multiple computers.
If the local Administrator account is named to the same value across servers and the password assigned to the
account is also configured to the same value, attackers can extract the account's credentials on one computer on
which Administrator or SYSTEM -level access has been obtained. The attacker does not have to initially
compromise the Administrator account; they need only compromise the account of a user who is a member of the
local Administrators group, or of a service account that is configured to run as LocalSystem or with Administrator
privileges. The attacker can then extract the credentials for the Administrator account and replay those credentials
in network logons to other computers on the network.
As long as another computer has a local account with the same user name and password (or password hash) as the
account credentials that are being presented, the logon attempt succeeds and the attacker obtains privileged access
to the targeted computer. In current versions of Windows, the built-in Administrator account is disabled by default,
but in legacy operating systems, the account is enabled by default.
NOTE
Some organizations have intentionally configured local Administrator accounts to be enabled in the belief that this provides a
"failsafe" in case all other privileged accounts are locked out of a system. However, even if the local Administrator account is
disabled and there are no other accounts available that can enable the account or log on to the system with Administrator
privileges, the system can be booted into safe mode and the built-in local Administrator account can be re-enabled, as
described in Microsoft Support article 814777. Additionally, if the system still successfully applies GPOs, a GPO can be
modified to (temporarily) re-enable the Administrator account, or Restricted Groups can be configured to add a domain-
based account to the local Administrators group. Repairs can be performed and the Administrator account can again be
disabled. To effectively prevent a lateral compromise that uses built-in local Administrator account credentials, unique user
names and passwords must be configured for local Administrator accounts. To deploy unique passwords for local
Administrator accounts via a GPO, see Solution for management of built-in Administrator account's password via GPO on
technet.
P e r m i t t i n g I n st a l l a t i o n o f U n a u t h o r i z e d A p p l i c a t i o n s
Law Number One: If a bad guy can persuade you to run his program on your computer, it's not solely your
computer anymore. - Ten Immutable Laws of Security (Version 2.0)
Whether an organization deploys consistent baseline settings across servers, the installation of applications that are
not part of a server's defined role should not be permitted. By allowing software to be installed that is not part of a
server's designated functionality, servers are exposed to inadvertent or malicious installation of software that
increases the server's attack surface, introduces application vulnerabilities, or causes system instability.
Applications
As described earlier, applications are often installed and configured to use accounts that are granted more privilege
than the application actually requires. In some cases, the application's documentation specifies that service accounts
must be members of a server's local Administrators group or must be configured to run in the context of the
LocalSystem. This is often not because the application requires those rights, but because determining what rights
and permissions an application's service accounts need requires investment in additional time and effort. If an
application does not install with the minimum privileges required for the application and its configured features to
function, the system is exposed to attacks that leverage application privileges without any attack against the
operating system itself.
Lack of Secure Application Development Practices
Infrastructure exists to support business workloads. Where these workloads are implemented in custom
applications, it is critical to ensure that the applications are developed using secure best practices. Root-cause
analysis of enterprise-wide incidents often reveals that an initial compromise is effected through custom
applications-particularly those that are Internet facing. Most of these compromises are accomplished via
compromise of well-known attacks such as SQL injection (SQLi) and cross-site scripting (XSS ) attacks.
SQL Injection is an application vulnerability that allows user-defined input to modify a SQL statement that is
passed to the database for execution. This input can be provided via a field in the application, a parameter (such as
the query string or a cookie), or other methods. The result of this injection is that the SQL statement provided to
the database is fundamentally different than what the developer intended. Take, for example, a common query used
in the evaluation of a user name/password combination:
SELECT userID FROM users WHERE username = 'sUserName' AND password = 'sPassword'
When this is received by the database server, it instructs the server to look through the users table and return any
userID record where the user name and password match those provided by the user (presumably via a login form
of some kind). Naturally the intent of the developer in this case is to only return a valid record if a correct user
name and password can be provided by the user. If either is incorrect, the database server will be unable to find a
matching record and return an empty result.
The issue occurs when an attacker does something unexpected such as providing their own SQL in place of valid
data. Because SQL is interpreted on-the-fly by the database server, the injected code would be processed as if the
developer had put it in himself. For example, if the attacker entered administrator for the user ID and xyz OR 1=1
as the password, the resulting statement processed by the database would be:
SELECT userID FROM users WHERE username = 'administrator' AND password = 'xyz' OR 1=1
When this query is processed by the database server, all rows in the table will be returned in the query because
1=1 will always evaluate to True, thus it doesn't matter if the correct username and password is known or provided.
The net result in most cases is that the user will be logged on as the first user in the user's database; in most cases,
this will be the administrative user.
In addition to simply logging on, malformed SQL statements such as this can be used to add, delete, or change
data, or even drop (delete) entire tables from a database. In the most extreme cases where SQLi is combined with
excessive privilege, operating system commands can be run to enable the creation of new users, to download attack
tools, or to take any other actions of the attackers choosing.
In cross-site scripting, the vulnerability is introduced in the application's output. An attack begins with an attacker
providing malformed data to the application, but in this case the malformed data is in the form of scripting code
(such as JavaScript) that will be run by the victim's browser. Exploit of an XSS vulnerability can allow an attacker to
run any functions of the target application in the context of the user who launched the browser. XSS attacks are
typically initiated by a phishing email encouraging the user to click a link that connects to the application and runs
the attack code.
XSS is often exploited in online banking and e-commerce scenarios where an attacker can make purchases or
transfer money in the context of the exploited user. In the case of a targeted attack on a custom web-based identity
management application, it can allow an attacker to create their own identities, modify permissions and rights, and
lead to a systemic compromise.
Although a full discussion of cross-site scripting and SQL injection is outside the scope of this document, the Open
Web Application Security Project (OWASP ) publishes a top 10 list with in-depth discussion of the vulnerabilities
and countermeasures.
Regardless of the investment in infrastructure security, if poorly designed and written applications are deployed
within that infrastructure, the environment is made vulnerable to attacks. Even well-secured infrastructures often
cannot provide effective countermeasures to these application attacks. Compounding the problem, poorly designed
applications may require that service accounts be granted excessive permissions for the application to function.
The Microsoft Security Development Lifecycle (SDL ) is a set of structural process controls that work to improve
security beginning early in requirements gathering and extending through the lifecycle of the application until it is
decommissioned. This integration of effective security controls is not only critical from a security perspective, it is
critical to ensure that application security is cost and schedule effective. Assessing an application for security issues
when it is effectively code complete requires organizations to make decisions about application security only before
or even after the application has been deployed. An organization can choose to address the application flaws before
deploying the application in production, incurring costs and delays, or the application can be deployed in
production with known security flaws, exposing the organization to compromise.
Some organizations place the full cost of fixing a security issue in production code above $10,000 per issue, and
applications developed without an effective SDL can average more than ten high-severity issues per 100,000 lines
of code. In large applications, the costs escalate quickly. By contrast, many companies set a benchmark of less than
one issue per 100,000 lines of code at the final code review stage of the SDL, and aim for zero issues in high-risk
applications in production.
Implementing the SDL improves security by including security requirements early in requirements gathering and
design of an application provides threat modeling for high-risk applications; requires effective training and
monitoring of developers; and requires clear, consistent code standards and practices. The net effect of an SDL is
significant improvements in application security while reducing the cost to develop, deploy, maintain, and
decommission an application. Although a detailed discussion of the design and implementation of SDL is beyond
the scope of this document, refer to the Microsoft Security Development Lifecycle for detailed guidance and
information.
Credential theft attacks are those in which an attacker initially gains highest-privilege (root, Administrator, or
SYSTEM, depending on the operating system in use) access to a computer on a network and then uses freely
available tooling to extract credentials from the sessions of other logged-on accounts. Depending on the system
configuration, these credentials can be extracted in the form of hashes, tickets, or even plaintext passwords. If any of
the harvested credentials are for local accounts that are likely to exist on other computers on the network (for
example, Administrator accounts in Windows, or root accounts in OSX, UNIX, or Linux), the attacker presents the
credentials to other computers on the network to propagate compromise to additional computers and to try to
obtain the credentials of two specific types of accounts:
1. Privileged domain accounts with both broad and deep privileges (that is, accounts that have administrator-
level privileges on many computers and in Active Directory). These accounts may not be members of any of
the highest-privilege groups in Active Directory, but they may have been granted Administrator-level
privilege across many servers and workstations in the domain or forest, which makes them effectively as
powerful as members of privileged groups in Active Directory. In most cases, accounts that have been
granted high levels of privilege across broad swaths of the Windows infrastructure are service accounts, so
service accounts should always be assessed for breadth and depth of privilege.
2. "Very Important Person" (VIP ) domain accounts. In the context of this document, a VIP account is any
account that has access to information an attacker wants (intellectual property and other sensitive
information), or any account that can be used to grant the attacker access to that information. Examples of
these user accounts include:
a. Executives whose accounts have access to sensitive corporate information
b. Accounts for Help Desk staff who are responsible for maintaining the computers and applications
used by executives
c. Accounts for legal staff who have access to an organization's bid and contract documents, whether the
documents are for their own organization or client organizations
d. Product planners who have access to plans and specifications for products in an company's
development pipeline, regardless of the types of products the company makes
e. Researchers whose accounts are used to access study data, product formulations, or any other
research of interest to an attacker
Because highly privileged accounts in Active Directory can be used to propagate compromise and to manipulate
VIP accounts or the data that they can access, the most useful accounts for credential theft attacks are accounts that
are members of Enterprise Admins, Domain Admins, and Administrators groups in Active Directory.
Because domain controllers are the repositories for the AD DS database and domain controllers have full access to
all of the data in Active Directory, domain controllers are also targeted for compromise, whether in parallel with
credential theft attacks, or after one or more highly privileged Active Directory accounts have been compromised.
Although numerous publications (and many attackers) focus on the Domain Admins group memberships when
describing pass-the-hash and other credential theft attacks (as is described in Reducing the Active Directory Attack
Surface), an account that is a member of any of the groups listed here can be used to compromise the entire AD DS
installation.
NOTE
For comprehensive information about pass-the-hash and other credential theft attacks, please see the Mitigating Pass-the-
Hash (PTH) Attacks and Other Credential Theft Techniques whitepaper listed in Appendix M: Document Links and
Recommended Reading. For more information about attacks by determined adversaries, which are sometimes referred to as
"advanced persistent threats" (APTs), please see Determined Adversaries and Targeted Attacks.
Activities that Increase the Likelihood of Compromise

Because the target of credential theft is usually highly privileged domain accounts and VIP accounts, it is important
for administrators to be conscious of activities that increase the likelihood of success of a credential-theft attack.
Although attackers also target VIP accounts, if VIPs are not given high levels of privilege on systems or in the
domain, theft of their credentials requires other types of attacks, such as socially engineering the VIP to provide
secret information. Or the attacker must first obtain privileged access to a system on which VIP credentials are
cached. Because of this, activities that increase the likelihood of credential theft described here are focused primarily
on preventing the acquisition of highly privileged administrative credentials. These activities are common
mechanisms by which attackers are able to compromise systems to obtain privileged credentials.
Logging on to Unsecured Computers with Privileged Accounts
The core vulnerability that allows credential theft attacks to succeed is the act of logging on to computers that are
not secure with accounts that are broadly and deeply privileged throughout the environment. These logons can be
the result of various misconfigurations described here.
Not Maintaining Separate Administrative Credentials
Although this is relatively uncommon, in assessing various AD DS installations, we have found IT employees using
a single account for all of their work. The account is a member of at least one of the most highly privileged groups
in Active Directory and is the same account that the employees use to log on to their workstations in the morning,
check their email, browse Internet sites, and download content to their computers. When users run with accounts
that are granted local Administrator rights and permissions, they expose the local computer to complete
compromise. When those accounts are also members of the most privileged groups in Active Directory, they
expose the entire forest to compromise, making it trivially easy for an attacker to gain complete control of the
Active Directory and Windows environment.
Similarly, in some environments, we've found that the same user names and passwords are used for root accounts
on non-Windows computers as are used in the Windows environment, which allows attackers to extend
compromise from UNIX or Linux systems to Windows systems and vice versa.
Logons to Compromised Workstations or Member Servers with Privileged Accounts
When a highly privileged domain account is used to log on interactively to a compromised workstation or member
server, that compromised computer may harvest credentials from any account that logs on to the system.
Unsecured Administrative Workstations
In many organizations, IT staff use multiple accounts. One account is used for logon to the employee's workstation,
and because these are IT staff, they often have local Administrator rights on their workstations. In some cases, UAC
is left enabled so that the user at least receives a split access token at logon and must elevate when privileges are
required. When these users are performing maintenance activities, they typically use locally installed management
tools and provide the credentials for their domain-privileged accounts, by selecting the Run as Administrator
option or by providing the credentials when prompted. Although this configuration may seem appropriate, it
exposes the environment to compromise because:
The "regular" user account that the employee uses to log on to their workstation has local Administrator
rights, the computer is vulnerable to drive-by download attacks in which the user is convinced to install
malware.
The malware is installed in the context of an administrative account, the computer can now be used to
capture keystrokes, clipboard contents, screenshots, and memory-resident credentials, any of which can
result in exposure of the credentials of a powerful domain account.
The problems in this scenario are twofold. First, although separate accounts are used for local and domain
administration, the computer is unsecured and does not protect the accounts against theft. Second, the regular user
account and the administrative account have been granted excessive rights and permissions.
Browsing the Internet with a Highly Privileged Account
Users who log on to computers with accounts that are members of the local Administrators group on the computer,
or members of privileged groups in Active Directory, and who then browse the Internet (or a compromised
intranet) expose the local computer and the directory to compromise.
Accessing a maliciously crafted website with a browser running with administrative privileges can allow an attacker
to deposit malicious code on the local computer in the context of the privileged user. If the user has local
Administrator rights on the computer, attackers may deceive the user into downloading malicious code or opening
email attachments that leverage application vulnerabilities and leverage the user's privileges to extract locally
cached credentials for all active users on the computer. If the user has administrative rights in the directory by
membership in the Enterprise Admins, Domain Admins, or Administrators groups in Active Directory, the attacker
can extract the domain credentials and use them to compromise the entire AD DS domain or forest, without
needing to compromise any other computer in the forest.
Configuring Local Privileged Accounts with the Same Credentials across Systems
Configuring the same local Administrator account name and password on many or all computers enables
credentials stolen from the SAM database on one computer to be used to compromise all other computers that use
the same credentials. At a minimum, you should use different passwords for local Administrator accounts across
each domain-joined system. Local Administrator accounts may also be uniquely named, but using different
passwords for each system's privileged local accounts is sufficient to ensure that credentials cannot be used on
other systems.
Overpopulation and Overuse of Privileged Domain Groups
Granting membership in the EA, DA, or BA groups in a domain creates a target for attackers. The greater the
number of members of these groups, the greater the likelihood that a privileged user may inadvertently misuse the
credentials and expose them to credential theft attacks. Every workstation or server to which a privileged domain
user logs on presents a possible mechanism by which the privileged user's credentials may be harvested and used
to compromise the AD DS domain and forest.
Poorly Secured Domain Controllers
Domain controllers house a replica of a domain's AD DS database. In the case of read-only domain controllers, the
local replica of the database contains the credentials for only a subset of the accounts in the directory, none of
which are privileged domain accounts by default. On read-write domain controllers, each domain controller
maintains a full replica of the AD DS database, including credentials not only for privileged users like Domain
Admins, but privileged accounts such as domain controller accounts or the domain's Krbtgt account, which is the
account that is associated with the KDC service on domain controllers. If additional applications that are not
necessary for domain controller functionality are installed on domain controllers, or if domain controllers are not
stringently patched and secured, attackers may compromise them via unpatched vulnerabilities, or they may
leverage other attack vectors to install malicious software directly on them.
Privilege Elevation and Propagation

Regardless of the attack methods used, Active Directory is always targeted when a Windows environment is
attacked, because it ultimately controls access to whatever the attackers want. This does not mean that the entire
directory is targeted, however. Specific accounts, servers, and infrastructure components are usually the primary
targets of attacks against Active Directory. These accounts are described as follows.
Permanent Privileged Accounts
Because the introduction of Active Directory, it has been possible to use highly privileged accounts to build the
Active Directory forest and then to delegate rights and permissions required to perform day-to-day administration
to less-privileged accounts. Membership in the Enterprise Admins, Domain Admins, or Administrators groups in
Active Directory is required only temporarily and infrequently in an environment that implements least-privilege
approaches to daily administration.
Permanent privileged accounts are accounts that have been placed in privileged groups and left there from day to
day. If your organization places five accounts into the Domain Admins group for a domain, those five accounts can
be targeted 24-hours a day, seven days a week. However, the actual need to use accounts with Domain Admins
privileges is typically only for specific domain-wide configuration, and for short periods of time.
VIP Accounts
An often overlooked target in Active Directory breaches is the accounts of "very important persons" (or VIPs) in an
organization. Privileged accounts are targeted because those accounts can grant access to attackers, which allows
them to compromise or even destroy targeted systems, as described earlier in this section.
"Privilege -Attached" Active Directory Accounts
"Privilege-attached" Active Directory accounts are domain accounts that have not been made members of any of
the groups that have the highest levels of privilege in Active Directory, but have instead been granted high levels of
privilege on many servers and workstations in the environment. These accounts are most often domain-based
accounts that are configured to run services on domain-joined systems, typically for applications running on large
sections of the infrastructure. Although these accounts have no privileges in Active Directory, if they are granted
high privilege on large numbers of systems, they can be used to compromise or even destroy large segments of the
infrastructure, achieving the same effect as compromise of a privileged Active Directory account.
This section focuses on technical controls to implement to reduce the attack surface of the Active Directory
installation. The section contains the following information:
Implementing Least-Privilege Administrative Models focuses on identifying the risk that the use of highly
privileged accounts for day-to-day administration presents, in addition to providing recommendations to
implement to reduce the risk that privileged accounts present.
Implementing Secure Administrative Hosts describes principles for deployment of dedicated, secure
administrative systems, in addition to some sample approaches to a secure administrative host deployment.
Securing Domain Controllers Against Attack discusses policies and settings that, although similar to the
recommendations for the implementation of secure administrative hosts, contain some domain controller-
specific recommendations to help ensure that the domain controllers and the systems used to manage them
are well-secured.
Privileged Accounts and Groups in Active Directory

This section provides background information about privileged accounts and groups in Active Directory intended
to explain the commonalities and differences between privileged accounts and groups in Active Directory. By
understanding these distinctions, whether you implement the recommendations in Implementing Least-Privilege
Administrative Models verbatim or choose to customize them for your organization, you have the tools you need to
secure each group and account appropriately.
Built-in Privileged Accounts and Groups
Active Directory facilitates delegation of administration and supports the principle of least privilege in assigning
rights and permissions. "Regular" users who have accounts in a domain are, by default, able to read much of what is
stored in the directory, but are able to change only a very limited set of data in the directory. Users who require
additional privilege can be granted membership in various "privileged" groups that are built into the directory so
that they may perform specific tasks related to their roles, but cannot perform tasks that are not relevant to their
duties. Organizations can also create groups that are tailored to specific job responsibilities and are granted
granular rights and permissions that allow IT staff to perform day-to-day administrative functions without granting
rights and permissions that exceed what is required for those functions.
Within Active Directory, three built-in groups are the highest privilege groups in the directory: Enterprise Admins,
Domain Admins, and Administrators. The default configuration and capabilities of each of these groups are
described in the following sections:
Highest Privilege Groups in Active Directory
En t e r p r i se A d m i n s
Enterprise Admins (EA) is a group that exists only in the forest root domain, and by default, it is a member of the
Administrators group in all domains in the forest. The built-in Administrator account in the forest root domain is
the only default member of the EA group. EAs are granted rights and permissions that allow them to implement
forest-wide changes (that is, changes that affect all domains in the forest), such as adding or removing domains,
establishing forest trusts, or raising forest functional levels. In a properly designed and implemented delegation
model, EA membership is required only when first constructing the forest or when making certain forest-wide
changes such as establishing an outbound forest trust. Most of the rights and permissions granted to the EA group
can be delegated to lesser-privileged users and groups.
Dom ain A dm in s
Each domain in a forest has its own Domain Admins (DA) group, which is a member of that domain's
Administrators group and a member of the local Administrators group on every computer that is joined to the
domain. The only default member of the DA group for a domain is the built-in Administrator account for that
domain. DAs are "all-powerful" within their domains, while EAs have forest-wide privilege. In a properly designed
and implemented delegation model, Domain Admins membership should be required only in "break glass"
scenarios (such as situations in which an account with high levels of privilege on every computer in the domain is
needed). Although native Active Directory delegation mechanisms allow delegation to the extent that it is possible
to use DA accounts only in emergency scenarios, constructing an effective delegation model can be time
consuming, and many organizations leverage third-party tools to expedite the process.
A d m i n i st r a t o r s
The third group is the built-in domain local Administrators (BA) group into which DAs and EAs are nested. This
group is granted many of the direct rights and permissions in the directory and on domain controllers. However,
the Administrators group for a domain has no privileges on member servers or on workstations. It is via
membership in the computers' local Administrators group that local privilege is granted.
NOTE
Although these are the default configurations of these privileged groups, a member of any of the three groups can
manipulate the directory to gain membership in any of the other groups. In some cases, it is trivial to obtain membership in
the other groups, while in others it is more difficult, but from the perspective of potential privilege, all three groups should be
considered effectively equivalent.
Sc h e m a A d m i n s
A fourth privileged group, Schema Admins (SA), exists only in the forest root domain and has only that domain's
built-in Administrator account as a default member, similar to the Enterprise Admins group. The Schema Admins
group is intended to be populated only temporarily and occasionally (when modification of the AD DS schema is
required).
Although the SA group is the only group that can modify the Active Directory schema (that is., the directory's
underlying data structures such as objects and attributes), the scope of the SA group's rights and permissions is
more limited than the previously described groups. It is also common to find that organizations have developed
appropriate practices for the management of the membership of the SA group because membership in the group is
typically infrequently needed, and only for short periods of time. This is technically true of the EA, DA, and BA
groups in Active Directory, as well, but it is far less common to find that organizations have implemented similar
practices for these groups as for the SA group.
Protected Accounts and Groups in Active Directory
Within Active Directory, a default set of privileged accounts and groups called "protected" accounts and groups are
secured differently than other objects in the directory. Any account that has direct or transitive membership in any
protected group (regardless of whether the membership is derived from security or distribution groups) inherits
this restricted security.
For example, if a user is a member of a distribution group that is, in turn, a member of a protected group in Active
Directory, that user object is flagged as a protected account. When an account is flagged as a protected account, the
value of the adminCount attribute on the object is set to 1.
NOTE
Although transitive membership in a protected group includes nested distribution and nested security groups, accounts that
are members of nested distribution groups will not receive the protected group's SID in their access tokens. However,
distribution groups can be converted to security groups in Active Directory, which is why distribution groups are included in
protected group member enumeration. Should a protected nested distribution group ever be converted to a security group,
the accounts that are members of the former distribution group will subsequently receive the parent protected group's SID in
their access tokens at the next logon.
The following table lists the default protected accounts and groups in Active Directory by operating system version
and service pack level.
Default Protected Accounts and Groups in Active Directory by Operating System and Service Pack (SP )
Version
Windows 2000 <SP4 Windows 2000 SP4 - Windows Server 2003 Windows Server 2008 -
Windows Server 2003 SP1+ Windows Server 2012
Administrators Account Operators Account Operators Account Operators
Administrator Administrator Administrator
Administrators Administrators Administrators
Domain Admins Backup Operators Backup Operators Backup Operators
Cert Publishers
Domain Admins Domain Admins Domain Admins
Enterprise Admins Domain Controllers Domain Controllers Domain Controllers
Enterprise Admins Enterprise Admins Enterprise Admins
Krbtgt Krbtgt Krbtgt
Print Operators Print Operators Print Operators
Read-only Domain
Controllers
Replicator Replicator Replicator
Schema Admins Schema Admins Schema Admins
A d m i n SD H o l d e r a n d SD P r o p
In the System container of every Active Directory domain, an object called AdminSDHolder is automatically
created. The purpose of the AdminSDHolder object is to ensure that the permissions on protected accounts and
groups are consistently enforced, regardless of where the protected groups and accounts are located in the domain.
Every 60 minutes (by default), a process known as Security Descriptor Propagator (SDProp) runs on the domain
controller that holds the domain's PDC Emulator role. SDProp compares the permissions on the domain's
AdminSDHolder object with the permissions on the protected accounts and groups in the domain. If the
permissions on any of the protected accounts and groups do not match the permissions on the AdminSDHolder
object, the permissions on the protected accounts and groups are reset to match those of the domain's
AdminSDHolder object.
Permissions inheritance is disabled on protected groups and accounts, which means that even if the accounts or
groups are moved to different locations in the directory, they do not inherit permissions from their new parent
objects. Inheritance is also disabled on the AdminSDHolder object so that permissions changes to the parent
objects do not change the permissions of AdminSDHolder.
NOTE
When an account is removed from a protected group, it is no longer considered a protected account, but its adminCount
attribute remains set to 1 if it is not manually changed. The result of this configuration is that the object's ACLs are no longer
updated by SDProp, but the object still does not inherit permissions from its parent object. Therefore, the object may reside in
an organizational unit (OU) to which permissions have been delegated, but the formerly protected object will not inherit these
delegated permissions. A script to locate and reset formerly protected objects in the domain can be found in the Microsoft
Support article 817433.
A d mi n SDHo l d e r O w n e rs h i p
Most objects in Active Directory are owned by the domain's BA group. However, the AdminSDHolder object is, by
default, owned by the domain's DA group. (This is a circumstance in which DAs do not derive their rights and
permissions via membership in the Administrators group for the domain.)
In versions of Windows earlier than Windows Server 2008, owners of an object can change permissions of the
object, including granting themselves permissions that they did not originally have. Therefore, the default
permissions on a domain's AdminSDHolder object prevent users who are members of BA or EA groups from
changing the permissions for a domain's AdminSDHolder object. However, members of the Administrators group
for the domain can take ownership of the object and grant themselves additional permissions, which means that
this protection is rudimentary and only protects the object against accidental modification by users who are not
members of the DA group in the domain. Additionally, the BA and EA (where applicable) groups have permission
to change the attributes of the AdminSDHolder object in the local domain (root domain for EA).
NOTE
An attribute on the AdminSDHolder object, dSHeuristics, allows limited customization (removal) of groups that are considered
protected groups and are affected by AdminSDHolder and SDProp. This customization should be carefully considered if it is
implemented, although there are valid circumstances in which modification of dSHeuristics on AdminSDHolder is useful. More
information about modification of the dSHeuristics attribute on an AdminSDHolder object can be found in the Microsoft
Support articles 817433 and 973840, and in Appendix C: Protected Accounts and Groups in Active Directory.
Although the most privileged groups in Active Directory are described here, there are a number of other groups
that have been granted elevated levels of privilege. For more information about all of the default and built-in
groups in Active Directory and the user rights assigned to each, see Appendix B: Privileged Accounts and Groups in
Active Directory.
Implementing Least-Privilege Administrative Models
The following excerpt is from The Administrator Accounts Security Planning Guide, first published on April 1, 1999:
"Most security-related training courses and documentation discuss the implementation of a principle of least
privilege, yet organizations rarely follow it. The principle is simple, and the impact of applying it correctly
greatly increases your security and reduces your risk. The principle states that all users should log on with a
user account that has the absolute minimum permissions necessary to complete the current task and nothing
more. Doing so provides protection against malicious code, among other attacks. This principle applies to
computers and the users of those computers.
"One reason this principle works so well is that it forces you to do some internal research. For example, you
must determine the access privileges that a computer or user really needs, and then implement them. For many
organizations, this task might initially seem like a great deal of work; however, it is an essential step to
successfully secure your network environment. "You should grant all domain administrator users their domain
privileges under the concept of least privilege. For example, if an administrator logs on with a privileged
account and inadvertently runs a virus program, the virus has administrative access to the local computer and
to the entire domain. If the administrator had instead logged on with a nonprivileged (nonadministrative)
account, the virus's scope of damage would only be the local computer because it runs as a local computer user.
"In another example, accounts to which you grant domain-level administrator rights must not have elevated
rights in another forest, even if there is a trust relationship between the forests. This tactic helps prevent
widespread damage if an attacker manages to compromise one managed forest. Organizations should
regularly audit their network to protect against unauthorized escalation of privilege."
The following excerpt is from the Microsoft Windows Security Resource Kit, first published in 2005:
"Always think of security in terms of granting the least amount of privileges required to carry out the task. If an
application that has too many privileges should be compromised, the attacker might be able to expand the
attack beyond what it would if the application had been under the least amount of privileges possible. For
example, examine the consequences of a network administrator unwittingly opening an email attachment that
launches a virus. If the administrator is logged on using the domain Administrator account, the virus will have
Administrator privileges on all computers in the domain and thus unrestricted access to nearly all data on the
network. If the administrator is logged on using a local Administrator account, the virus will have Administrator
privileges on the local computer and thus would be able to access any data on the computer and install
malicious software such as key-stroke logging software on the computer. If the administrator is logged on using
a normal user account, the virus will have access only to the administrator's data and will not be able to install
malicious software. By using the least privileges necessary to read email, in this example, the potential scope of
the compromise is greatly reduced."
The Privilege Problem

The principles described in the preceding excerpts have not changed, but in assessing Active Directory installations,
we invariably find excessive numbers of accounts that have been granted rights and permissions far beyond those
required to perform day-to-day work. The size of the environment affects the raw numbers of overly privileged
accounts, but not the proportionmidsized directories may have dozens of accounts in the most highly privileged
groups, while large installations may have hundreds or even thousands. With few exceptions, regardless of the
sophistication of an attacker's skills and arsenal, attackers typically follow the path of least resistance. They increase
the complexity of their tooling and approach only if and when simpler mechanisms fail or are thwarted by
defenders.
Unfortunately, the path of least resistance in many environments has proven to be the overuse of accounts with
broad and deep privilege. Broad privileges are rights and permissions that allow an account to perform specific
activities across a large cross-section of the environment- for example, Help Desk staff may be granted permissions
that allow them to reset the passwords on many user accounts.
Deep privileges are powerful privileges that are applied to a narrow segment of the population, such giving an
engineer Administrator rights on a server so that they can perform repairs. Neither broad privilege nor deep
privilege is necessarily dangerous, but when many accounts in the domain are permanently granted broad and
deep privilege, if only one of the accounts is compromised, it can quickly be used to reconfigure the environment to
the attacker's purposes or even to destroy large segments of the infrastructure.
Pass-the-hash attacks, which are a type of credential theft attack, are ubiquitous because the tooling to perform
them is freely available and easy-to-use, and because many environments are vulnerable to the attacks. Pass-the-
hash attacks, however, are not the real problem. The crux of the problem is twofold:
1. It is usually easy for an attacker to obtain deep privilege on a single computer and then propagate that privilege
broadly to other computers.
2. There are usually too many permanent accounts with high levels of privilege across the computing landscape.
Even if pass-the-hash attacks are eliminated, attackers would simply use different tactics, not a different strategy.
Rather than planting malware that contains credential theft tooling, they might plant malware that logs keystrokes,
or leverage any number of other approaches to capture credentials that are powerful across the environment.
Regardless of the tactics, the targets remain the same: accounts with broad and deep privilege.
Granting of excessive privilege isn't only found in Active Directory in compromised environments. When an
organization has developed the habit of granting more privilege than is required, it is typically found throughout
the infrastructure as discussed in the following sections.
In Active Directory
In Active Directory, it is common to find that the EA, DA and BA groups contain excessive numbers of accounts.
Most commonly, an organization's EA group contains the fewest members, DA groups usually contain a multiplier
of the number of users in the EA group, and Administrators groups usually contain more members than the
populations of the other groups combined. This is often due to a belief that Administrators are somehow "less
privileged" than DAs or EAs. While the rights and permissions granted to each of these groups differ, they should
be effectively considered equally powerful groups because a member of one can make himself or herself a member
of the other two.
On Member Servers
When we retrieve the membership of local Administrators groups on member servers in many environments, we
find membership ranging from a handful of local and domain accounts, to dozens of nested groups that, when
expanded, reveal hundreds, even thousands, of accounts with local Administrator privilege on the servers. In many
cases, domain groups with large memberships are nested in member servers' local Administrators groups, without
consideration to the fact that any user who can modify the memberships of those groups in the domain can gain
administrative control of all systems on which the group has been nested in a local Administrators group.
On Workstations
Although workstations typically have significantly fewer members in their local Administrators groups than
member servers do, in many environments, users are granted membership in the local Administrators group on
their personal computers. When this occurs, even if UAC is enabled, those users present an elevated risk to the
integrity of their workstations.
IMPORTANT
You should consider carefully whether users require administrative rights on their workstations, and if they do, a better
approach may be to create a separate local account on the computer that is a member of the Administrators group. When
users require elevation, they can present the credentials of that local account for elevation, but because the account is local, it
cannot be used to compromise other computers or access domain resources. As with any local accounts, however, the
credentials for the local privileged account should be unique; if you create a local account with the same credentials on
multiple workstations, you expose the computers to pass-the-hash attacks.
In Applications
In attacks in which the target is an organization's intellectual property, accounts that have been granted powerful
privileges within applications can be targeted to allow exfiltration of data. Although the accounts that have access to
sensitive data may have been granted no elevated privileges in the domain or the operating system, accounts that
can manipulate the configuration of an application or access to the information the application provides present
risk.
In Data Repositories
As is the case with other targets, attackers seeking access to intellectual property in the form of documents and
other files can target the accounts that control access to the file stores, accounts that have direct access to the files,
or even groups or roles that have access to the files. For example, if a file server is used to store contract documents
and access is granted to the documents by the use of an Active Directory group, an attacker who can modify the
membership of the group can add compromised accounts to the group and access the contract documents. In cases
in which access to documents is provided by applications such as SharePoint, attackers can target the applications
as described earlier.
Reducing Privilege
The larger and more complex an environment, the more difficult it is to manage and secure. In small organizations,
reviewing and reducing privilege may be a relatively simple proposition, but each additional server, workstation,
user account, and application in use in an organization adds another object that must be secured. Because it can be
difficult or even impossible to properly secure every aspect of an organization's IT infrastructure, you should focus
efforts first on the accounts whose privilege create the greatest risk, which are typically the built-in privileged
accounts and groups in Active Directory, and privileged local accounts on workstations and member servers.
Securing Local Administrator Accounts on Workstations and Member Servers
Although this document focuses on securing Active Directory, as has been previously discussed, most attacks
against the directory begin as attacks against individual hosts. Full guidelines for securing local groups on member
systems cannot be provided, but the following recommendations can be used to help you secure the local
Administrator accounts on workstations and member servers.
Securing Local Administrator Accounts
On all versions of Windows currently in mainstream support, the local Administrator account is disabled by default,
which makes the account unusable for pass-the-hash and other credential theft attacks. However, in domains
containing legacy operating systems or in which local Administrator accounts have been enabled, these accounts
can be used as previously described to propagate compromise across member servers and workstations. For this
reason, the following controls are recommended for all local Administrator accounts on domain-joined systems.
Detailed instructions for implementing these controls are provided in Appendix H: Securing Local Administrator
Accounts and Groups. Before implementing these settings, however, ensure that local Administrator accounts are
not currently used in the environment to run services on computers or perform other activities for which these
accounts should not be used. Test these settings thoroughly before implementing them in a production
environment.
Controls for Local Administrator Accounts
Built-in Administrator accounts should never be used as service accounts on member servers, nor should they be
used to log on to local computers (except in Safe Mode, which is permitted even if the account is disabled). The goal
of implementing the settings described here is to prevent each computer's local Administrator account from being
usable unless protective controls are first reversed. By implementing these controls and monitoring Administrator
accounts for changes, you can significantly reduce the likelihood of success of an attack that targets local
Administrator accounts.
C o n fi g u r i n g G P O s t o R e st r i c t A d m i n i st r a t o r A c c o u n t s o n D o m a i n - J o i n e d Sy st e m s
In one or more GPOs that you create and link to workstation and member server OUs in each domain, add the
Administrator account to the following user rights in Computer Configuration\Policies\Windows
Settings\Security Settings\Local Policies\User Rights Assignments:
Deny access to this computer from the network
Deny log on as a batch job
Deny log on as a service
Deny log on through Remote Desktop Services
When you add Administrator accounts to these user rights, specify whether you are adding the local Administrator
account or the domain's Administrator account by the way that you label the account. For example, to add the
NWTRADERS domain's Administrator account to these deny rights, you would type the account as
NWTRADERS\Administrator, or browse to the Administrator account for the NWTRADERS domain. To ensure
that you restrict the local Administrator account, type Administrator in these user rights settings in the Group
Policy Object Editor.
NOTE
Even if local Administrator accounts are renamed, the policies will still apply.
These settings will ensure that a computer's Administrator account cannot be used to connect to the other
computers, even if it is inadvertently or maliciously enabled. Local logons using the local Administrator account
cannot be completely disabled, nor should you attempt to do so, because a computer's local Administrator account
is designed to be used in disaster recovery scenarios.
Should a member server or workstation become disjoined from the domain with no other local accounts granted
administrative privileges, the computer can be booted into safe mode, the Administrator account can be enabled,
and the account can then be used to effect repairs on the computer. When repairs are completed, the Administrator
account should again be disabled.
Securing Local Privileged Accounts and Groups in Active Directory
Law Number Six: A computer is only as secure as the administrator is trustworthy. - Ten Immutable Laws of
Security (Version 2.0)
The information provided here is intended to give general guidelines for securing the highest privilege built-in
accounts and groups in Active Directory. Detailed step-by-step instructions are also provided in Appendix D:
Securing Built-In Administrator Accounts in Active Directory, Appendix E: Securing Enterprise Admins Groups in
Active Directory, Appendix F: Securing Domain Admins Groups in Active Directory, and in Appendix G: Securing
Administrators Groups in Active Directory.
Before you implement any of these settings, you should also test all settings thoroughly to determine if they are
appropriate for your environment. Not all organizations will be able to implement these settings.
Securing Built-in Administrator Accounts in Active Directory
In each domain in Active Directory, an Administrator account is created as part of the creation of the domain. This
account is by default a member of the Domain Admins and Administrator groups in the domain, and if the domain
is the forest root domain, the account is also a member of the Enterprise Admins group. Use of a domain's local
Administrator account should be reserved only for initial build activities and, possibly, disaster-recovery scenarios.
To ensure that a built-in Administrator account can be used to effect repairs in the event that no other accounts can
be used, you should not change the default membership of the Administrator account in any domain in the forest.
Instead, you should following guidelines to help secure the Administrator account in each domain in the forest.
Detailed instructions for implementing these controls are provided in Appendix D: Securing Built-In Administrator
Accounts in Active Directory.
Controls for Built-in Administrator Accounts
The goal of implementing the settings described here is to prevent each domain's Administrator account (not a
group) from being usable unless a number of controls are reversed. By implementing these controls and
monitoring the Administrator accounts for changes, you can significantly reduce the likelihood of a successful
attack by leveraging a domain's Administrator account. For the Administrator account in each domain in your
forest, you should configure the following settings.
En a b l e t h e " A c c o u n t i s se n si t i v e a n d c a n n o t b e d e l e g a t e d " fl a g o n t h e a c c o u n t
By default, all accounts in Active Directory can be delegated. Delegation allows a computer or service to present the
credentials for an account that has authenticated to the computer or service to other computers to obtain services
on behalf of the account. When you enable the Account is sensitive and cannot be delegated attribute on a
domain-based account, the account's credentials cannot be presented to other computers or services on the
network, which limits attacks that leverage delegation to use the account's credentials on other systems.
En a b l e t h e " Sm a r t c a r d i s r e q u i r e d fo r i n t e r a c t i v e l o g o n " fl a g o n t h e a c c o u n t
When you enable the Smart card is required for interactive logon attribute on an account, Windows resets the
account's password to a 120-character random value. By setting this flag on built-in Administrator accounts, you
ensure that the password for the account is not only long and complex, but is not known to any user. It is not
technically necessary to create smart cards for the accounts before enabling this attribute, but if possible, smart
cards should be created for each Administrator account prior to configuring the account restrictions and the smart
cards should be stored in secure locations.
Although setting the Smart card is required for interactive logon flag resets the account's password, it does not
prevent a user with rights to reset the account's password from setting the account to a known value and using the
account's name and new password to access resources on the network. Because of this, you should implement the
following additional controls on the account.
C o n fi g u r i n g G P O s t o R e st r i c t D o m a i n s' A d m i n i st r a t o r A c c o u n t s o n D o m a i n - J o i n e d Sy st e m s
Although disabling the Administrator account in a domain makes the account effectively unusable, you should
implement additional restrictions on the account in case the account is inadvertently or maliciously enabled.
Although these controls can ultimately be reversed by the Administrator account, the goal is to create controls that
slow an attacker's progress and limit the damage the account can inflict.
In one or more GPOs that you create and link to workstation and member server OUs in each domain, add each
domain's Administrator account to the following user rights in Computer Configuration\Policies\Windows
NOTE
When you add local Administrator accounts to this setting, you must specify whether you are configuring local Administrator
accounts or domain Administrator accounts. For example, to add the NWTRADERS domain's local Administrator account to
these deny rights, you must either type the account as NWTRADERS\Administrator, or browse to the local Administrator
account for the NWTRADERS domain. If you type Administrator in these user rights settings in the Group Policy Object
Editor, you will restrict the local Administrator account on each computer to which the GPO is applied.
We recommend restricting local Administrator accounts on member servers and workstations in the same manner as
domain-based Administrator accounts. Therefore, you should generally add the Administrator account for each domain in the
forest and the Administrator account for the local computers to these user rights settings.
C o n fi g u r i n g G P O s t o R e st r i c t A d m i n i st r a t o r A c c o u n t s o n D o m a i n C o n t r o l l e r s
In each domain in the forest, the Default Domain Controllers policy or a policy linked to the Domain Controllers
OU should be modified to add each domain's Administrator account to the following user rights in Computer
Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignments:
NOTE
These settings will ensure that the local Administrator account cannot be used to connect to a domain controller, although
the account, if enabled, can log on locally to domain controllers. Because this account should only be enabled and used in
disaster-recovery scenarios, it is anticipated that physical access to at least one domain controller will be available, or that
other accounts with permissions to access domain controllers remotely can be used.
C o n fi g u r e A u d i t i n g o f B u i l t - i n A d m i n i st r a t o r A c c o u n t s
When you have secured each domain's Administrator account and disabled it, you should configure auditing to
monitor for changes to the account. If the account is enabled, its password is reset, or any other modifications are
made to the account, alerts should be sent to the users or teams responsible for administration of AD DS, in
addition to incident response teams in your organization.
Securing Administrators, Domain Admins and Enterprise Admins Groups
Securing Enterprise Admin Groups
The Enterprise Admins group, which is housed in the forest root domain, should contain no users on a day-to-day
basis, with the possible exception of the domain's local Administrator account, provided it is secured as described
earlier and in Appendix D: Securing Built-In Administrator Accounts in Active Directory.
When EA access is required, the users whose accounts require EA rights and permissions should be temporarily
placed into the Enterprise Admins group. Although users are using the highly privileged accounts, their activities
should be audited and preferably performed with one user performing the changes and another user observing the
changes to minimize the likelihood of inadvertent misuse or misconfiguration. When the activities have been
completed, the accounts should be removed from the EA group. This can be achieved via manual procedures and
documented processes, third-party privileged identity/access management (PIM/PAM ) software, or a combination
of both. Guidelines for creating accounts that can be used to control the membership of privileged groups in Active
Directory are provided in Attractive Accounts for Credential Theft and detailed instructions are provided in
Appendix I: Creating Management Accounts for Protected Accounts and Groups in Active Directory.
Enterprise Admins are, by default, members of the built-in Administrators group in each domain in the forest.
Removing the Enterprise Admins group from the Administrators groups in each domain is an inappropriate
modification because in the event of a forest disaster-recovery scenario, EA rights will likely be required. If the
Enterprise Admins group has been removed from Administrators groups in a forest, it should be added to the
Administrators group in each domain and the following additional controls should be implemented:
As described earlier, the Enterprise Admins group should contain no users on a day-to-day basis, with the
possible exception of the forest root domain's Administrator account, which should be secured as described in
Appendix D: Securing Built-In Administrator Accounts in Active Directory.
In GPOs linked to OUs containing member servers and workstations in each domain, the EA group should be
added to the following user rights:
Deny log on locally
Deny log on through Remote Desktop Services.
This will prevent members of the EA group from logging on to member servers and workstations. If jump servers
are used to administer domain controllers and Active Directory, ensure that jump servers are located in an OU to
which the restrictive GPOs are not linked.
Auditing should be configured to send alerts if any modifications are made to the properties or membership of
the EA group. These alerts should be sent, at a minimum, to users or teams responsible for Active Directory
administration and incident response. You should also define processes and procedures for temporarily
populating the EA group, including notification procedures when legitimate population of the group is
performed.
Securing Domain Admins Groups
As is the case with the Enterprise Admins group, membership in Domain Admins groups should be required only
in build or disaster-recovery scenarios. There should be no day-to-day user accounts in the DA group with the
exception of the local Administrator account for the domain, if it has been secured as described in Appendix D:
Securing Built-In Administrator Accounts in Active Directory.
When DA access is required, the accounts needing this level of access should be temporarily placed in the DA
group for the domain in question. Although the users are using the highly privileged accounts, activities should be
audited and preferably performed with one user performing the changes and another user observing the changes
to minimize the likelihood of inadvertent misuse or misconfiguration. When the activities have been completed, the
accounts should be removed from the Domain Admins group. This can be achieved via manual procedures and
documented processes, via third-party privileged identity/access management (PIM/PAM ) software, or a
combination of both. Guidelines for creating accounts that can be used to control the membership of privileged
groups in Active Directory are provided in Appendix I: Creating Management Accounts for Protected Accounts and
Groups in Active Directory.
Domain Admins are, by default, members of the local Administrators groups on all member servers and
workstations in their respective domains. This default nesting should not be modified because it affects
supportability and disaster recovery options. If Domain Admins groups have been removed from the local
Administrators groups on the member servers, they should be added to the Administrators group on each member
server and workstation in the domain via restricted group settings in linked GPOs. The following general controls,
which are described in depth in Appendix F: Securing Domain Admins Groups in Active Directory should also be
implemented.
For the Domain Admins group in each domain in the forest:
1. Remove all members from the DA group, with the possible exception of the built-in Administrator account for
the domain, provided it has been secured as described in Appendix D: Securing Built-In Administrator Accounts
in Active Directory.
2. In GPOs linked to OUs containing member servers and workstations in each domain, the DA group should
be added to the following user rights:
Deny log on locally
This will prevent members of the DA group from logging on to member servers and workstations. If jump
servers are used to administer domain controllers and Active Directory, ensure that jump servers are located
in an OU to which the restrictive GPOs are not linked.
3. Auditing should be configured to send alerts if any modifications are made to the properties or membership
of the DA group. These alerts should be sent, at a minimum, to users or teams responsible for AD DS
administration and incident response. You should also define processes and procedures for temporarily
populating the DA group, including notification procedures when legitimate population of the group is
performed.
Securing Administrators Groups in Active Directory
As is the case with the EA and DA groups, membership in the Administrators (BA) group should be required only in
build or disaster-recovery scenarios. There should be no day-to-day user accounts in the Administrators group with
the exception of the local Administrator account for the domain, if it has been secured as described in Appendix D:
Securing Built-In Administrator Accounts in Active Directory.
When Administrators access is required, the accounts needing this level of access should be temporarily placed in
the Administrators group for the domain in question. Although the users are using the highly privileged accounts,
activities should be audited and, preferably, performed with a user performing the changes and another user
observing the changes to minimize the likelihood of inadvertent misuse or misconfiguration. When the activities
have been completed, the accounts should immediately be removed from the Administrators group. This can be
achieved via manual procedures and documented processes, via third-party privileged identity/access management
(PIM/PAM ) software, or a combination of both.
Administrators are, by default, the owners of most of the AD DS objects in their respective domains. Membership
in this group may be required in build and disaster recovery scenarios in which ownership or the ability to take
ownership of objects is required. Additionally, DAs and EAs inherit a number of their rights and permissions by
virtue of their default membership in the Administrators group. Default group nesting for privileged groups in
Active Directory should not be modified, and each domain's Administrators group should be secured as described
in Appendix G: Securing Administrators Groups in Active Directory, and in the general instructions below.
1. Remove all members from the Administrators group, with the possible exception of the local Administrator
account for the domain, provided it has been secured as described in Appendix D: Securing Built-In
Administrator Accounts in Active Directory.
2. Members of the domain's Administrators group should never need to log on to member servers or
workstations. In one or more GPOs linked to workstation and member server OUs in each domain, the
Administrators group should be added to the following user rights:
Deny log on as a batch job,
This will prevent members of the Administrators group from being used to log on or connect to member
servers or workstations (unless multiple controls are first breached), where their credentials could be
cached and thereby compromised. A privileged account should never be used to log on to a less-
privileged system, and enforcing these controls affords protection against a number of attacks.
3. At the domain controllers OU in each domain in the forest, the Administrators group should be granted the
following user rights (if they do not already have these rights), which will allow the members of the
Administrators group to perform functions necessary for a forest-wide disaster recovery scenario:
Access this computer from the network
Allow log on locally
Allow log on through Remote Desktop Services
of the Administrators group. These alerts should be sent, at a minimum, to members of the team responsible
for AD DS administration. Alerts should also be sent to members of the security team, and procedures
should be defined for modifying the membership of the Administrators group. Specifically, these processes
should include a procedure by which the security team is notified when the Administrators group is going to
be modified so that when alerts are sent, they are expected and an alarm is not raised. Additionally,
processes to notify the security team when the use of the Administrators group has been completed and the
accounts used have been removed from the group should be implemented.
NOTE
When you implement restrictions on the Administrators group in GPOs, Windows applies the settings to members of a
computer's local Administrators group in addition to the domain's Administrators group. Therefore, you should use caution
when implementing restrictions on the Administrators group. Although prohibiting network, batch and service logons for
members of the Administrators group is advised wherever it is feasible to implement, do not restrict local logons or logons
through Remote Desktop Services. Blocking these logon types can block legitimate administration of a computer by members
of the local Administrators group. The following screenshot shows configuration settings that block misuse of built-in local
and domain Administrator accounts, in addition to misuse of built-in local or domain Administrators groups. Note that the
Deny log on through Remote Desktop Services user right does not include the Administrators group, because including it
in this setting would also block these logons for accounts that are members of the local computer's Administrators group. If
services on computers are configured to run in the context of any of the privileged groups described in this section,
implementing these settings can cause services and applications to fail. Therefore, as with all of the recommendations in this
section, you should thoroughly test settings for applicability in your environment.
Role -Based Access Controls (RBAC ) for Active Directory

Generally speaking, role-based access controls (RBAC ) are a mechanism for grouping users and providing access
to resources based on business rules. In the case of Active Directory, implementing RBAC for AD DS is the process
of creating roles to which rights and permissions are delegated to allow members of the role to perform day-to-day
administrative tasks without granting them excessive privilege. RBAC for Active Directory can be designed and
implemented via native tooling and interfaces, by leveraging software you may already own, by purchasing third-
party products, or any combination of these approaches. This section does not provide step-by-step instructions to
implement RBAC for Active Directory, but instead discusses factors you should consider in choosing an approach
to implementing RBAC in your AD DS installations.
Native Approaches to RBAC for Active Directory
In the simplest RBAC implementation, you can implement roles as AD DS groups and delegate rights and
permissions to the groups that allow them to perform daily administration within the designated scope of the role.
In some cases, existing security groups in Active Directory can be used to grant rights and permissions appropriate
to a job function. For example, if specific employees in your IT organization are responsible for the management
and maintenance of DNS zones and records, delegating those responsibilities can be as simple as creating an
account for each DNS administrator and adding it to the DNS Admins group in Active Directory. The DNS Admins
group, unlike more highly privileged groups, has few powerful rights across Active Directory, although members of
this group have been delegated permissions that allow them to administer DNS and is still subject to compromise
and abuse could result in elevation of privilege.
In other cases, you may need to create security groups and delegate rights and permissions to Active Directory
objects, file system objects, and registry objects to allow members of the groups to perform designated
administrative tasks. For example, if your Help Desk operators are responsible for resetting forgotten passwords,
assisting users with connectivity problems, and troubleshooting application settings, you may need to combine
delegation settings on user objects in Active Directory with privileges that allow Help Desk users to connect
remotely to users' computers to view or modify the users' configuration settings. For each role you define, you
should identify:
1. Which tasks members of the role perform on a day-to-day basis and which tasks are less frequently performed.
2. On which systems and in which applications members of a role should be granted rights and permissions.
3. Which users should be granted membership in a role.
4. How management of role memberships will be performed.
In many environments, manually creating role-based access controls for administration of an Active Directory
environment can be challenging to implement and maintain. If you have clearly defined roles and responsibilities
for administration of your IT infrastructure, you may want to leverage additional tooling to assist you in creating a
manageable native RBAC deployment. For example, if Forefront Identity Manager (FIM ) is in use in your
environment, you can use FIM to automate the creation and population of administrative roles, which can ease
ongoing administration. If you use System Center Configuration Manager (SCCM ) and System Center Operations
Manager (SCOM ), you can use application-specific roles to delegate management and monitoring functions, and
also enforce consistent configuration and auditing across systems in the domain. If you have implemented a public
key infrastructure (PKI), you can issue and require smart cards for IT staff responsible for administering the
environment. With FIM Credential Management (FIM CM ), you can even combine management of roles and
credentials for your administrative staff.
In other cases, it may be preferable for an organization to consider deploying third-party RBAC software that
provides "out-of-box" functionality. Commercial, off-the-shelf (COTS ) solutions for RBAC for Active Directory,
Windows, and non-Windows directories and operating systems are offered by a number of vendors. When
choosing between native solutions and third-party products, you should consider the following factors:
1. Budget: By investing in development of RBAC using software and tools you may already own, you can reduce
the software costs involved in deploying a solution. However, unless you have staff who are experienced in
creating and deploying native RBAC solutions, you may need to engage consulting resources to develop your
solution. You should carefully weigh the anticipated costs for a custom-developed solution with the costs to
deploy an "out-of-box" solution, particularly if your budget is limited.
2. Composition of the IT environment: If your environment is comprised primarily of Windows systems, or if you
are already leveraging Active Directory for management of non-Windows systems and accounts, custom native
solutions may provide the optimal solution for your needs. If your infrastructure contains many systems that are
not running Windows and are not managed by Active Directory, you may need to consider options for
management of non-Windows systems separately from the Active Directory environment.
3. Privilege model in the solution: If a product relies on placement of its service accounts into highly privileged
groups in Active Directory and does not offer options that do not require excessive privilege be granted to the
RBAC software, you have not really reduced your Active Directory attack surface you've only changed the
composition of the most privileged groups in the directory. Unless an application vendor can provide controls
for service accounts that minimize the probability of the accounts being compromised and maliciously used, you
may want to consider other options.
Privileged Identity Management
Privileged identity management (PIM ), sometimes referred to as privileged account management (PAM ) or
privileged credential management (PCM ) is the design, construction, and implementation of approaches to
managing privileged accounts in your infrastructure. Generally speaking, PIM provides mechanisms by which
accounts are granted temporary rights and permissions required to perform build-or-break fix functions, rather
than leaving privileges permanently attached to accounts. Whether PIM functionality is manually created or is
implemented via the deployment of third-party software one or more of the following features may be available:
Credential "vaults," where passwords for privileged accounts are "checked out" and assigned an initial password,
then "checked in" when activities have been completed, at which time passwords are again reset on the accounts.
Time-bound restrictions on the use of privileged credentials
One-time-use credentials
Workflow -generated granting of privilege with monitoring and reporting of activities performed and automatic
removal of privilege when activities are completed or allotted time has expired
Replacement of hard-coded credentials such as user names and passwords in scripts with application
programming interfaces (APIs) that allow credentials to be retrieved from vaults as needed
Automatic management of service account credentials
Creating Unprivileged Accounts to Manage Privileged Accounts
One of the challenges in managing privileged accounts is that, by default, the accounts that can manage privileged
and protected accounts and groups are privileged and protected accounts. If you implement appropriate RBAC and
PIM solutions for your Active Directory installation, the solutions may include approaches that allow you to
effectively depopulate the membership of the most privileged groups in the directory, populating the groups only
temporarily and when needed.
If you implement native RBAC and PIM, however, you should consider creating accounts that have no privilege and
with the only function of populating and depopulating privileged groups in Active Directory when needed.
Appendix I: Creating Management Accounts for Protected Accounts and Groups in Active Directory provides step-
by-step instructions that you can use to create accounts for this purpose.
Implementing Robust Authentication Controls
Law Number Six: There really is someone out there trying to guess your passwords. - 10 Immutable Laws of
Security Administration
Pass-the-hash and other credential theft attacks are not specific to Windows operating systems, nor are they new.
The first pass-the-hash attack was created in 1997. Historically, however, these attacks required customized tools,
were hit-or-miss in their success, and required attackers to have a relatively high degree of skill. The introduction of
freely available, easy-to-use tooling that natively extracts credentials has resulted in an exponential increase in the
number and success of credential theft attacks in recent years. However, credential theft attacks are by no means
the only mechanisms by which credentials are targeted and compromised.
Although you should implement controls to help protect you against credential theft attacks, you should also
identify the accounts in your environment that are most likely to be targeted by attackers, and implement robust
authentication controls for those accounts. If your most privileged accounts are using single factor authentication
such as user names and passwords (both are "something you know," which is one authentication factor), those
accounts are weakly protected. All that an attacker needs is knowledge of the user name and knowledge of the
password associated with the account, and pass-the-hash attacks are not required the attacker can authenticate as
the user to any systems that accept single factor credentials.
Although implementing multi-factor authentication does not protect you against pass-the-hash attacks,
implementing multi-factor authentication in combination with protected systems can. More information about
implementing protected systems is provided in Implementing Secure Administrative Hosts, and authentication
options are discussed in the following sections.
General Authentication Controls
If you have not already implemented multi-factor authentication such as smart cards, consider doing so. Smart
cards implement hardware-enforced protection of private keys in a public-private key pair, preventing a user's
private key from being accessed or used unless the user presents the proper PIN, passcode, or biometric identifier
to the smart card. Even if a user's PIN or passcode is intercepted by a keystroke logger on a compromised
computer, for an attacker to reuse the PIN or passcode, the card must also be physically present.
In cases in which long, complex passwords have proven difficult to implement because of user resistance, smart
cards provide a mechanism by which users may implement relatively simple PINs or passcodes without the
credentials being susceptible to brute force or rainbow table attacks. Smart card PINs are not stored in Active
Directory or in local SAM databases, although credential hashes may still be stored in LSASS protected memory
on computers on which smart cards have been used for authentication.
Additional Controls for VIP Accounts
Another benefit of implementing smart cards or other certificate-based authentication mechanisms is the ability to
leverage Authentication Mechanism Assurance to protect sensitive data that is accessible to VIP users.
Authentication Mechanism Assurance is available in domains in which the functional level is set to Windows Server
2012 or Windows Server 2008 R2. When it is enabled, Authentication Mechanism Assurance adds an
administrator-designated global group membership to a user's Kerberos token when the user's credentials are
authenticated during logon using a certificate-based logon method.
This makes it possible for resource administrators to control access to resources, such as files, folders, and printers,
based on whether the user logs on using a certificate-based logon method, in addition to the type of certificate
used. For example, when a user logs on by using a smart card, the user's access to resources on the network can be
specified as different from what the access is when the user does not use a smart card (that is, when the user logs
on by entering a user name and password). For more information about Authentication Mechanism Assurance, see
the Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide.
Configuring Privileged Account Authentication
In Active Directory for all administrative accounts, enable the Require smart card for interactive logon attribute,
and audit for changes to (at a minimum), any of the attributes on the Account tab for the account (for example, cn,
name, sAMAccountName, userPrincipalName, and userAccountControl) administrative user objects.
Although setting the Require smart card for interactive logon on accounts resets the account's password to a
120-character random value and requires smart cards for interactive logons, the attribute can still be overwritten
by users with permissions that allow them to change passwords on the accounts, and the accounts can then be
used to establish non-interactive logons with only user name and password.
In other cases, depending on the configuration of accounts in Active Directory and certificate settings in Active
Directory Certificate Services (AD CS ) or a third-party PKI, User Principal Name (UPN ) attributes for
administrative or VIP accounts can be targeted for a specific kind of attack, as described here.
U P N H i j a c k i n g fo r C e r t i fi c a t e Sp o o fi n g
Although a thorough discussion of attacks against public key infrastructures (PKIs) is outside the scope of this
document, attacks against public and private PKIs have increased exponentially since 2008. Breaches of public PKIs
have been broadly publicized, but attacks against an organization's internal PKI are perhaps even more prolific. One
such attack leverages Active Directory and certificates to allow an attacker to spoof the credentials of other
accounts in a manner that can be difficult to detect.
When a certificate is presented for authentication to a domain-joined system, the contents of the Subject or the
Subject Alternative Name (SAN ) attribute in the certificate are used to map the certificate to a user object in Active
Directory. Depending on the type of certificate and how it is constructed, the Subject attribute in a certificate
typically contains a user's common name (CN ), as shown in the following screenshot.
By default, Active Directory constructs a user's CN by concatenating the account's first name + " "+ last name.
However, CN components of user objects in Active Directory are not required or guaranteed to be unique, and
moving a user account to a different location in the directory changes the account's distinguished name (DN ),
which is the full path to the object in the directory, as shown in the bottom pane of the previous screenshot.
Because certificate subject names are not guaranteed to be static or unique, the contents of the Subject Alternative
Name are often used to locate the user object in Active Directory. The SAN attribute for certificates issued to users
from enterprise certification authorities (Active Directory integrated CAs) typically contains the user's UPN or email
address. Because UPNs are guaranteed to be unique in an AD DS forest, locating a user object by UPN is
commonly performed as part of authentication, with or without certificates involved in the authentication process.
The use of UPNs in SAN attributes in authentication certificates can be leveraged by attackers to obtain fraudulent
certificates. If an attacker has compromised an account that has the ability to read and write UPNs on user objects,
the attack is implemented as follows:
The UPN attribute on a user object (such as a VIP user) is temporarily changed to a different value. The SAM
account name attribute and CN can also be changed at this time, although this is usually not necessary for the
reasons described earlier.
When the UPN attribute on the target account has been changed, a stale, enabled user account or a freshly created
user account's UPN attribute is changed to the value that was originally assigned to the target account. Stale,
enabled user accounts are accounts that have not logged on for long periods of time, but have not been disabled.
They are targeted by attackers who intend to "hide in plain sight" for the following reasons:
1. Because the account is enabled, but hasn't been used recently, using the account is unlikely to trigger alerts the
way that enabling a disabled user account might.
2. Use of an existing account doesn't require the creation of a new user account that might be noticed by
administrative staff.
3. Stale user accounts that are still enabled are usually members of various security groups and are granted access
to resources on the network, simplifying access and "blending in" to an existing user population.
The user account on which the target UPN has now been configured is used to request one or more certificates
from Active Directory Certificate Services.
When certificates have been obtained for the attacker's account, the UPNs on the "new" account and the target
account are returned to their original values.
The attacker now has one or more certificates that can be presented for authentication to resources and
applications as if the user is the VIP user whose account was temporarily modified. Although a full discussion of all
of the ways in which certificates and PKI can be targeted by attackers is outside the scope of this document, this
attack mechanism is provided to illustrate why you should monitor privileged and VIP accounts in AD DS for
changes, particularly for changes to any of the attributes on the Account tab for the account (for example, cn,
name, sAMAccountName, userPrincipalName, and userAccountControl). In addition to monitoring the accounts,
you should restrict who can modify the accounts to as small a set of administrative users as possible. Likewise, the
accounts of administrative users should be protected and monitored for unauthorized changes.
Secure administrative hosts are workstations or servers that have been configured specifically for the purposes of
creating secure platforms from which privileged accounts can perform administrative tasks in Active Directory or
on domain controllers, domain-joined systems, and applications running on domain-joined systems. In this case,
"privileged accounts" refers not only to accounts that are members of the most privileged groups in Active
Directory, but to any accounts that have been delegated rights and permissions that allow administrative tasks to
be performed.
These accounts may be Help Desk accounts that have the ability to reset passwords for most of the users in a
domain, accounts that are used to administer DNS records and zones, or accounts that are used for configuration
management. Secure administrative hosts are dedicated to administrative functionality, and they do not run
software such as email applications, web browsers, or productivity software such as Microsoft Office.
Although the "most privileged" accounts and groups should accordingly be the most stringently protected, this
does not eliminate the need to protect any accounts and groups to which privileges above those of standard user
accounts have been granted.
A secure administrative host can be a dedicated workstation that is used only for administrative tasks, a member
server that runs the Remote Desktop Gateway server role and to which IT users connect to perform administration
of destination hosts, or a server that runs the Hyper-V role and provides a unique virtual machine for each IT user
to use for their administrative tasks. In many environments, combinations of all three approaches may be
implemented.
Implementing secure administrative hosts requires planning and configuration that is consistent with your
organization's size, administrative practices, risk appetite, and budget. Considerations and options for implementing
secure administrative hosts are provided here for you to use in developing an administrative strategy suitable for
your organization.
Principles for Creating Secure Administrative Hosts

To effectively secure systems against attacks, a few general principles should be kept in mind:
1. You should never administer a trusted system (that is, a secure server such as a domain controller) from a
less-trusted host (that is, a workstation that is not secured to the same degree as the systems it manages).
2. You should not rely on a single authentication factor when performing privileged activities; that is, user name
and password combinations should not be considered acceptable authentication because only a single factor
(something you know ) is represented. You should consider where credentials are generated and cached or
stored in administrative scenarios.
3. Although most attacks in the current threat landscape leverage malware and malicious hacking, do not omit
physical security when designing and implementing secure administrative hosts.
Account Configuration
Even if your organization does not currently use smart cards, you should consider implementing them for
privileged accounts and secure administrative hosts. Administrative hosts should be configured to require smart
card logon for all accounts by modifying the following setting in a GPO that is linked to the OUs containing
administrative hosts:
Computer Configuration\Policies\Windows Settings\Local Policies\Security Options\Interactive logon:
Require smart card
This setting will require all interactive logons to use a smart card, regardless of the configuration on an individual
account in Active Directory.
You should also configure secure administrative hosts to permit logons only by authorized accounts, which can be
configured in:
Computer Configuration\Policies\Windows Settings\Local Policies\Security Settings\Local
Policies\User Rights Assignment
This grants interactive (and, where appropriate, Remote Desktop Services) logon rights only to authorized users of
the secure administrative host.
Physical Security
For administrative hosts to be considered trustworthy, they must be configured and protected to the same degree
as the systems they manage. Most of the recommendations provided in Securing Domain Controllers Against
Attack are also applicable to the hosts that are used to administer domain controllers and the AD DS database. One
of the challenges of implementing secure administrative systems in most environments is that physical security can
be more difficult to implement because these computers often reside in areas that are not as secure as servers
hosted in datacenters, such as administrative users' desktops.
Physical security includes controlling physical access to administrative hosts. In a small organization, this may mean
that you maintain a dedicated administrative workstation that is kept locked in an office or a desk drawer when not
in use. Or it may mean that when you need to perform administration of Active Directory or your domain
controllers, you log on to the domain controller directly.
In medium-sized organizations, you may consider implementing secure administrative "jump servers" that are
located in a secured location in an office and are used when management of Active Directory or domain controllers
is required. You may also implement administrative workstations that are locked in secure locations when not in
use, with or without jump servers.
In large organizations, you can deploy datacenter-housed jump servers that provide strictly controlled access to
Active Directory; domain controllers; and file, print, or application servers. Implementation of a jump server
architecture is most likely to include a combination of secure workstations and servers in large environments.
Regardless of the size of your organization and the design of your administrative hosts, you should secure physical
computers against unauthorized access or theft, and should use BitLocker Drive Encryption to encrypt and protect
the drives on administrative hosts. By implementing BitLocker on administrative hosts, even if a host is stolen or its
disks are removed, you can ensure that the data on the drive is inaccessible to unauthorized users.
Operating System Versions and Configuration
All administrative hosts, whether servers or workstations, should run the newest operating system in use in your
organization for the reasons described earlier in this document. By running current operating systems, your
administrative staff benefits from new security features, full vendor support, and additional functionality introduced
in the operating system. Moreover, when you are evaluating a new operating system, by deploying it first to
administrative hosts, you will need to familiarize yourself with the new features, settings and management
mechanisms it offers, which can subsequently be leveraged in planning broader deployment of the operating
system. By then, the most sophisticated users in your organization will also be the users who are familiar with the
new operating system and best positioned to support it.
Microsoft Security Configuration Wizard
If you implement jump servers as part of your administrative host strategy, you should use the built-in Security
Configuration Wizard to configure service, registry, audit, and firewall settings to reduce the server's attack surface.
When the Security Configuration Wizard configuration settings have been collected and configured, the settings
can be converted to a GPO that is used to enforce a consistent baseline configuration on all jump servers. You can
further edit the GPO to implement security settings specific to jump servers, and can combine all of the settings
with additional baseline settings extracted from the Microsoft Security Compliance Manager.
Microsoft Security Compliance Manager
The Microsoft Security Compliance Manager is a freely available tool that integrates security configurations that
are recommended by Microsoft, based on operating system version and role configuration, and collects them in a
single tool and UI that can be used to create and configure baseline security settings for domain controllers.
Microsoft Security Compliance Manager templates can be combined with Security Configuration Wizard settings
to produce comprehensive configuration baselines for jump servers that are deployed and enforced by GPOs
deployed at the OUs in which jump servers are located in Active Directory.
NOTE
As of this writing, the Microsoft Security Compliance Manager does not include settings specific to jump servers or other
secure administrative hosts, but Security Compliance Manager (SCM) can still be used to create initial baselines for your
administrative hosts. To properly secure the hosts, however, you should apply additional security settings appropriate to
highly secured workstations and servers.
AppLocker
Administrative hosts and virtual machinesshould be configured with script, tool, and application whitelists via
AppLocker or a third-party application restriction software. Any administrative applications or utilities that do not
adhere to secure settings should be upgraded or replaced with tooling that adheres to secure development and
administrative practices. When new or additional tooling is needed on an administrative host, applications and
utilities should be thoroughly tested, and if the tooling is suitable for deployment on administrative hosts, it can be
added to the systems' whitelists.
RDP Restrictions
Although the specific configuration will vary depending on the architecture of your administrative systems, you
should include restrictions on which accounts and computers can be used to establish Remote Desktop Protocol
(RDP ) connections to managed systems, such as using Remote Desktop Gateway (RD Gateway) jump servers to
control access to domain controllers and other managed systems from authorized users and systems.
You should allow interactive logons by authorized users and should remove or even block other logon types that
are not needed for server access.
Patch and Configuration Management
Smaller organizations may rely on offerings such as Windows Update or Windows Server Update Services
(WSUS ) to manage deployment of updates to Windows systems, while larger organizations may implement
enterprise patch and configuration management software such as System Center Configuration Manager.
Regardless of the mechanisms you use to deploy updates to your general server and workstation population, you
should consider separate deployments for highly secure systems such as domain controllers, certification
authorities, and administrative hosts. By segregating these systems from the general management infrastructure, if
your management software or service accounts are compromised, the compromise cannot be easily extended to
the most secure systems in your infrastructure.
Although you should not implement manual update processes for secure systems, you should configure a separate
infrastructure for updating secure systems. Even in very large organizations, this infrastructure can usually be
implemented via dedicated WSUS servers and GPOs for secured systems.
Blocking Internet Access
Administrative hosts should not be permitted to access the Internet, nor should they be able to browse an
organization's intranet. Web browsers and similar applications should not be permitted on administrative hosts. You
can block Internet access for secure hosts via a combination of perimeter firewall settings, WFAS configuration, and
"black hole" proxy configuration on secure hosts. You can also use application whitelisting to prevent web browsers
from being used on administrative hosts.
Virtualization
Where possible, consider implementing virtual machines as administrative hosts. Using virtualization, you can
create per-user administrative systems that are centrally stored and managed, and which can be easily shut down
when not in use, ensuring that credentials are not left active on the administrative systems. You can also require
that virtual administrative hosts are reset to an initial snapshot after each use, ensuring that the virtual machines
remain pristine. More information about options for virtualization of administrative hosts is provided in the
following section.
Sample Approaches to Implementing Secure Administrative Hosts

Regardless of how you design and deploy your administrative host infrastructure, you should keep in mind the
guidelines provided in "Principles for Creating Secure Administrative Hosts" earlier in this topic. Each of the
approaches described here provides general information about how you can separate "administrative" and
"productivity" systems used by your IT staff. Productivity systems are computers that IT administrators employ to
check email, browse the Internet, and to use general productivity software such as Microsoft Office. Administrative
systems are computers that are hardened and dedicated to use for day-to-day administration of an IT environment.
The simplest way to implement secure administrative hosts is to provide your IT staff with secured workstations
from which they can perform administrative tasks. In a workstation-only implementation, each administrative
workstation is used to launch management tools and RDP connections to manage servers and other infrastructure.
Workstation-only implementations can be effective in smaller organizations, although larger, more complex
infrastructures may benefit from a distributed design for administrative hosts in which dedicated administrative
servers and workstations are used, as described in "Implementing Secure Administrative Workstations and Jump
Servers" later in this topic.
Implementing Separate Physical Workstations
One way that you can implement administrative hosts is to issue each IT user two workstations. One workstation is
used with a "regular" user account to perform activities such as checking email and using productivity applications,
while the second workstation is dedicated strictly to administrative functions.
For the productivity workstation, the IT staff can be given regular user accounts rather than using privileged
accounts to log on to unsecured computers. The administrative workstation should be configured with a stringently
controlled configuration and the IT staff should use a different account to log on to the administrative workstation.
If you have implemented smart cards, administrative workstations should be configured to require smart card
logons, and IT staff should be given separate accounts for administrative use, also configured to require smart
cards for interactive logon. The administrative host should be hardened as previously described, and only
designated IT users should be allowed to log on locally to the administrative workstation.
Pros
By implementing separate physical systems, you can ensure that each computer is configured appropriately for its
role and that IT users cannot inadvertently expose administrative systems to risk.
Cons
Implementing separate physical computers increases hardware costs.
Logging on to a physical computer with credentials that are used to administer remote systems caches the
credentials in memory.
If administrative workstations are not stored securely, they may be vulnerable to compromise via
mechanisms such as physical hardware key loggers or other physical attacks.
Implementing a Secure Physical Workstation with a Virtualized Productivity Workstation
In this approach, IT users are given a secured administrative workstation from which they can perform day-to-day
administrative functions, using Remote Server Administration Tools (RSAT) or RDP connections to servers within
their scope of responsibility. When IT users need to perform productivity tasks, they can connect via RDP to a
remote productivity workstation running as a virtual machine. Separate credentials should be used for each
workstation, and controls such as smart cards should be implemented.
Pros
Administrative workstations and productivity workstations are separated.
IT staff using secure workstations to connect to productivity workstations can use separate credentials and
smart cards, and privileged credentials are not deposited on the less-secure computer.
Cons
Implementing the solution requires design and implementation work and robust virtualization options.
If the physical workstations are not stored securely, they may be vulnerable to physical attacks that
compromise the hardware or the operating system and make them susceptible to communications
interception.
Implementing a Single Secure Workstation with Connections to Separate "Productivity" and "Administrative"
Virtual Machines
In this approach, you can issue IT users a single physical workstation that is locked down as previously described,
and on which IT users do not have privileged access. You can provide Remote Desktop Services connections to
virtual machines hosted on dedicated servers, providing IT staff with one virtual machine that runs email and other
productivity applications, and a second virtual machine that is configured as the user's dedicated administrative
host.
You should require smart card or other multifactor logon for the virtual machines, using separate accounts other
than the account that is used to log on to the physical computer. After an IT user logs on to a physical computer,
they can use their productivity smart card to connect to their remote productivity computer and a separate account
and smart card to connect to their remote administrative computer.
Pros
IT users can use a single physical workstation.
By requiring separate accounts for the virtual hosts and using Remote Desktop Services connections to the
virtual machines, IT users' credentials are not cached in memory on the local computer.
The physical host can be secured to the same degree as administrative hosts, reducing the likelihood of
compromise of the local computer.
In cases in which an IT user's productivity virtual machine or their administrative virtual machine may have
been compromised, the virtual machine can easily be reset to a "known good" state.
If the physical computer is compromised, no privileged credentials will be cached in memory, and the use of
smart cards can prevent compromise of credentials by keystroke loggers.
Cons
Implementing the solution requires design and implementation work and robust virtualization options.
If the physical workstations are not stored securely, they may be vulnerable to physical attacks that
compromise the hardware or the operating system and make them susceptible to communications
interception.
Implementing Secure Administrative Workstations and Jump Servers
As an alternative to secure administrative workstations, or in combination with them, you can implement secure
jump servers, and administrative users can connect to the jump servers using RDP and smart cards to perform
administrative tasks.
Jump servers should be configured to run the Remote Desktop Gateway role to allow you to implement
restrictions on connections to the jump server and to destination servers that will be managed from it. If possible,
you should also install the Hyper-V role and create Personal Virtual Desktops or other per-user virtual machines
for administrative users to use for their tasks on the jump servers.
By giving the administrative users per-user virtual machines on the jump server, you provide physical security for
the administrative workstations, and administrative users can reset or shut down their virtual machines when not in
use. If you prefer not to install the Hyper-V role and the Remote Desktop Gateway role on the same administrative
host, you can install them on separate computers.
Wherever possible, remote administration tools should be used to manage servers. The Remote Server
Administration Tools (RSAT) feature should be installed on the users' virtual machines (or the jump server if you
are not implementing per-user virtual machines for administration), and administrative staff should connect via
RDP to their virtual machines to perform administrative tasks.
In cases when an administrative user must connect via RDP to a destination server to manage it directly, RD
Gateway should be configured to allow the connection to be made only if the appropriate user and computer are
used to establish the connection to the destination server. Execution of RSAT (or similar) tools should be prohibited
on systems that are not designated management systems, such as general-use workstations and member servers
that are not jump servers.
Pros
Creating jump servers allows you to map specific servers to "zones" (collections of systems with similar
configuration, connection, and security requirements) in your network and to require that the administration
of each zone is achieved by administrative staff connecting from secure administrative hosts to a designated
"zone" server.
By mapping jump servers to zones, you can implement granular controls for connection properties and
configuration requirements, and can easily identify attempts to connect from unauthorized systems.
By implementing per-administrator virtual machines on jump servers, you enforce shutdown and resetting
of the virtual machines to a known clean state when administrative tasks are completed. By enforcing
shutdown (or restart) of the virtual machines when administrative tasks are completed, the virtual machines
cannot be targeted by attackers, nor are credential theft attacks feasible because memory-cached credentials
do not persist beyond a reboot.
Cons
Dedicated servers are required for jump servers, whether physical or virtual.
Implementing designated jump servers and administrative workstations requires careful planning and
configuration that maps to any security zones configured in the environment.
Securing Domain Controllers Against Attack
Law Number Three: If a bad guy has unrestricted physical access to your computer, it's not your computer
anymore. - Ten Immutable Laws of Security (Version 2.0)
Domain controllers provide the physical storage for the AD DS database, in addition to providing the services and
data that allow enterprises to effectively manage their servers, workstations, users, and applications. If privileged
access to a domain controller is obtained by a malicious user, that user can modify, corrupt, or destroy the AD DS
database and, by extension, all of the systems and accounts that are managed by Active Directory.
Because domain controllers can read from and write to anything in the AD DS database, compromise of a domain
controller means that your Active Directory forest can never be considered trustworthy again unless you are able to
recover using a known good backup and to close the gaps that allowed the compromise in the process.
Depending on an attacker's preparation, tooling, and skill, modification or even irreparable damage to the AD DS
database can be completed in minutes to hours, not days or weeks. What matters isn't how long an attacker has
privileged access to Active Directory, but how much the attacker has planned for the moment when privileged
access is obtained. Compromising a domain controller can provide the most expedient path to wide scale
propagation of access, or the most direct path to destruction of member servers, workstations, and Active
Directory. Because of this, domain controllers should be secured separately and more stringently than the general
Windows infrastructure.
Physical Security for Domain Controllers

This section provides information about physically securing domain controllers, whether the domain controllers are
physical or virtual machines, in datacenter locations, branch offices, and even remote locations with only basic
infrastructure controls.
Datacenter Domain Controllers
Physical Domain Controllers
In datacenters, physical domain controllers should be installed in dedicated secure racks or cages that are separate
from the general server population. When possible, domain controllers should be configured with Trusted Platform
Module (TPM ) chips and all volumes in the domain controller servers should be protected via BitLocker Drive
Encryption. BitLocker generally adds performance overhead in single-digit percentages, but protects the directory
against compromise even if disks are removed from the server. BitLocker can also help protect systems against
attacks such as rootkits because the modification of boot files will cause the server to boot into recovery mode so
that the original binaries can be loaded. If a domain controller is configured to use software RAID, serial-attached
SCSI, SAN/NAS storage, or dynamic volumes, BitLocker cannot be implemented, so locally attached storage (with
or without hardware RAID ) should be used in domain controllers whenever possible.
Virtual Domain Controllers
If you implement virtual domain controllers, you should ensure that domain controllers run on separate physical
hosts than other virtual machines in the environment. Even if you use a third-party virtualization platform, consider
deploying virtual domain controllers on Hyper-V Server in Windows Server 2012 or Windows Server 2008 R2,
which provides a minimal attack surface and can be managed with the domain controllers it hosts rather than being
managed with the rest of the virtualization hosts. If you implement System Center Virtual Machine Manager
(SCVMM ) for management of your virtualization infrastructure, you can delegate administration for the physical
hosts on which domain controller virtual machines reside and the domain controllers themselves to authorized
administrators. You should also consider separating the storage of virtual domain controllers to prevent storage
administrators from accessing the virtual machine files.
Branch Locations
Physical Domain Controllers in branches
In locations in which multiple servers reside but are not physically secured to the degree that datacenter servers are
secured, physical domain controllers should be configured with TPM chips and BitLocker Drive Encryption for all
server volumes. If a domain controller cannot be stored in a locked room in branch locations, you should consider
deploying RODCs in those locations.
Virtual Domain Controllers in branches
Whenever possible, you should run virtual domain controllers in branch offices on separate physical hosts than the
other virtual machines in the site. In branch offices in which virtual domain controllers cannot run on separate
physical hosts from the rest of the virtual server population, you should implement TPM chips and BitLocker Drive
Encryption on hosts on which virtual domain controllers run at minimum, and all hosts if possible. Depending on
the size of the branch office and the security of the physical hosts, you should consider deploying RODCs in branch
locations.
Remote Locations with Limited Space and Security
If your infrastructure includes locations in which only a single physical server can be installed, a server capable of
running virtualization workloads should be installed in the remote location, and BitLocker Drive Encryption should
be configured to protect all volumes in the server. One virtual machine on the server should run an RODC, with
other servers running as separate virtual machines on the host. Information about planning for deployment of
RODC is provided in the Read-Only Domain Controller Planning and Deployment Guide. For more information
about deploying and securing virtualized domain controllers, see Running Domain Controllers in Hyper-V on the
TechNet website. For more detailed guidance for hardening Hyper-V, delegating virtual machine management, and
protecting virtual machines, see the Hyper-V Security Guide Solution Accelerator on the Microsoft website.
Domain Controller Operating Systems

You should run all domain controllers on the newest version of Windows Server that is supported within your
organization and prioritize decommissioning of legacy operating systems in the domain controller population. By
keeping your domain controllers current and eliminating legacy domain controllers, you can often take advantage
of new functionality and security that may not be available in domains or forests with domain controllers running
legacy operating system. Domain controllers should be freshly installed and promoted rather than upgraded from
previous operating systems or server roles; that is, do not perform in-place upgrades of domain controllers or run
the AD DS Installation Wizard on servers on which the operating system is not freshly installed. By implementing
freshly installed domain controllers, you ensure that legacy files and settings are not inadvertently left on domain
controllers, and you simplify the enforcement of consistent, secure domain controller configuration.
Secure Configuration of Domain Controllers

A number of freely available tools, some of which are installed by default in Windows, can be used to create an
initial security configuration baseline for domain controllers that can subsequently be enforced by GPOs. These
tools are described here.
Security Configuration Wizard
All domain controllers should be locked down upon initial build. This can be achieved using the Security
Configuration Wizard that ships natively in Windows Server to configure service, registry, system, and WFAS
settings on a "base build" domain controller. Settings can be saved and exported to a GPO that can be linked to the
Domain Controllers OU in each domain in the forest to enforce consistent configuration of domain controllers. If
your domain contains multiple versions of Windows operating systems, you can configure Windows Management
Instrumentation (WMI) filters to apply GPOs only to the domain controllers running the corresponding version of
the operating system.
Microsoft Security Compliance Toolkit
Microsoft Security Compliance Toolkit domain controller settings can be combined with Security Configuration
Wizard settings to produce comprehensive configuration baselines for domain controllers that are deployed and
enforced by GPOs deployed at the Domain Controllers OU in Active Directory.
RDP Restrictions
Group Policy Objects that link to all domain controllers OUs in a forest should be configured to allow RDP
connections only from authorized users and systems (for example, jump servers). This can be achieved through a
combination of user rights settings and WFAS configuration and should be implemented in GPOs so that the
policy is consistently applied. If it is bypassed, the next Group Policy refresh returns the system to its proper
configuration.
Patch and Configuration Management for Domain Controllers
Although it may seem counterintuitive, you should consider patching domain controllers and other critical
infrastructure components separately from your general Windows infrastructure. If you leverage enterprise
configuration management software for all computers in your infrastructure, compromise of the systems
management software can be used to compromise or destroy all infrastructure components managed by that
software. By separating patch and systems management for domain controllers from the general population, you
can reduce the amount of software installed on domain controllers, in addition to tightly controlling their
management.
Blocking Internet Access for Domain Controllers
One of the checks that is performed as part of an Active Directory Security Assessment is the use and configuration
of Internet Explorer on domain controllers. Internet Explorer (or any other web browser) should not be used on
domain controllers, but analysis of thousands of domain controllers has revealed numerous cases in which
privileged users used Internet Explorer to browse the organization's intranet or the Internet.
As previously described in the "Misconfiguration" section of Avenues to Compromise, browsing the Internet (or an
infected intranet) from one of the most powerful computers in a Windows infrastructure using a highly privileged
account (which are the only accounts permitted to log on locally to domain controllers by default) presents an
extraordinary risk to an organization's security. Whether via a drive by download or by download of malware-
infected "utilities," attackers can gain access to everything they need to completely compromise or destroy the
Active Directory environment.
Although Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, and current versions of
Internet Explorer offer a number of protections against malicious downloads, in most cases in which domain
controllers and privileged accounts had been used to browse the Internet, the domain controllers were running
Windows Server 2003, or protections offered by newer operating systems and browsers had been intentionally
disabled.
Launching web browsers on domain controllers should be prohibited not only by policy, but by technical controls,
and domain controllers should not be permitted to access the Internet. If your domain controllers need to replicate
across sites, you should implement secure connections between the sites. Although detailed configuration
instructions are outside the scope of this document, you can implement a number of controls to restrict the ability
of domain controllers to be misused or misconfigured and subsequently compromised.
Perimeter Firewall Restrictions
Perimeter firewalls should be configured to block outbound connections from domain controllers to the Internet.
Although domain controllers may need to communicate across site boundaries, perimeter firewalls can be
configured to allow intersite communication by following the guidelines provided in How to configure a firewall for
domains and trusts on the Microsoft Support website.
DC Firewall Configurations
As described earlier, you should use the Security Configuration Wizard to capture configuration settings for the
Windows Firewall with Advanced Security on domain controllers. You should review the output of Security
Configuration Wizard to ensure that the firewall configuration settings meet your organization's requirements, and
then use GPOs to enforce configuration settings.
Preventing Web Browsing from Domain Controllers
You can use a combination of AppLocker configuration, "black hole" proxy configuration, and WFAS configuration
to prevent domain controllers from accessing the Internet and to prevent the use of web browsers on domain
controllers.
Law Number Five: Eternal vigilance is the price of security. - 10 Immutable Laws of Security Administration
A solid event log monitoring system is a crucial part of any secure Active Directory design. Many computer security
compromises could be discovered early in the event if the victims enacted appropriate event log monitoring and
alerting. Independent reports have long supported this conclusion. For example, the 2009 Verizon Data Breach
Report states:
"The apparent ineffectiveness of event monitoring and log analysis continues to be somewhat of an enigma. The
opportunity for detection is there; investigators noted that 66 percent of victims had sufficient evidence available
within their logs to discover the breach had they been more diligent in analyzing such resources."
This lack of monitoring active event logs remains a consistent weakness in many companies' security defense plans.
The 2012 Verizon Data Breach report found that even though 85 percent of breaches took several weeks to be
noticed, 84 percent of victims had evidence of the breach in their event logs.
Windows Audit Policy

The following are links to the Microsoft official enterprise support blog. The content of these blogs provides advice,
guidance, and recommendations about auditing that will assist you in enhancing the security of your Active
Directory infrastructure and are a valuable resource when designing an audit policy.
Global Object Access Auditing is Magic - describes a control mechanism called Advanced Audit Policy
Configuration that was added to Windows 7 and Windows Server 2008 R2 that lets you set what types of
data you wanted to audit easily and not juggle scripts and auditpol.exe.
Introducing Auditing Changes in Windows 2008 - introduces the auditing changes made in Windows Server
2008.
Cool Auditing Tricks in Vista and 2008 - explains interesting auditing features of Windows Vista and
Windows Server 2008 that can be used for troubleshooting problems or seeing what is happening in your
environment.
One-Stop Shop for Auditing in Windows Server 2008 and Windows Vista - contains a compilation of
auditing features and information contained in Windows Server 2008 and Windows Vista.
The following links provide information about improvements to Windows auditing in Windows 8 and Windows
Server 2012, and information about AD DS auditing in Windows Server 2008.
What's New in Security Auditing - provides an overview of new security auditing features in Windows 8 and
AD DS Auditing Step-by-Step Guide - describes the new Active Directory Domain Services (AD DS )
auditing feature in Windows Server 2008. It also provides procedures to implement this new feature.
Windows Audit Categories
Prior to Windows Vista and Windows Server 2008, Windows had only nine event log audit policy categories:
Account Logon Events
Account Management
Directory Service Access
Logon Events
Object Access
Policy Change
Privilege Use
Process Tracking
System Events
These nine traditional audit categories comprise an audit policy. Each audit policy category can be enabled for
Success, Failure, or Success and Failure events. Their descriptions are included in the next section.
Audit Policy Category Descriptions
The audit policy categories enable the following event log message types.
A u d i t A c c o u n t L o g o n Ev e n t s
Reports each instance of a security principal (for example, user, computer, or service account) that is logging on to
or logging off from one computer in which another computer is used to validate the account. Account logon events
are generated when a domain security principal account is authenticated on a domain controller. Authentication of a
local user on a local computer generates a logon event that is logged in the local security log. No account logoff
events are logged.
This category generates a lot of "noise" because Windows is constantly having accounts logging on to and off of
the local and remote computers during the normal course of business. Still, any security plan should include the
success and failure of this audit category.
A u di t A c c o u n t Man agem en t
This audit setting determines whether to track management of users and groups. For example, users and groups
should be tracked when a user or computer account, a security group, or a distribution group is created, changed,
or deleted; when a user or computer account is renamed, disabled, or enabled; or when a user or computer
password is changed. An event can be generated for users or groups that are added to or removed from other
groups.
A u d i t D i r e c t o r y Se r v i c e A c c e ss
This policy setting determines whether to audit security principal access to an Active Directory object that has its
own specified system access control list (SACL ). In general, this category should only be enabled on domain
controllers. When enabled, this setting generates a lot of "noise."
A u d i t L o g o n Ev e n t s
Logon events are generated when a local security principal is authenticated on a local computer. Logon Events
records domain logons that occur on the local computer. Account logoff events are not generated. When enabled,
Logon Events generates a lot of "noise," but they should be enabled by default in any security auditing plan.
A u d i t O b j e c t A c c e ss
Object Access can generate events when subsequently defined objects with auditing enabled are accessed (for
example, Opened, Read, Renamed, Deleted, or Closed). After the main auditing category is enabled, the
administrator must individually define which objects will have auditing enabled. Many Windows system objects
come with auditing enabled, so enabling this category will usually begin to generate events before the
administrator has defined any.
This category is very "noisy" and will generate five to ten events for each object access. It can be difficult for
administrators new to object auditing to gain useful information. It should only be enabled when needed.
A u di t i n g Pol i c y Ch an ge
This policy setting determines whether to audit every incidence of a change to user rights assignment policies,
Windows Firewall policies, Trust policies, or changes to the audit policy. This category should be enabled on all
computers. It generates very little noise.
A u d i t P r i v i l e g e U se
There are dozens of user rights and permissions in Windows (for example, Logon as a Batch Job and Act as Part of
the Operating System). This policy setting determines whether to audit each instance of a security principal by
exercising a user right or privilege. Enabling this category results in a lot of "noise," but it can be helpful in tracking
security principal accounts using elevated privileges.
A u d i t P r o c e ss T r a c k i n g
This policy setting determines whether to audit detailed process tracking information for events such as program
activation, process exit, handle duplication, and indirect object access. It is useful for tracking malicious users and
the programs they use.
Enabling Audit Process Tracking generates a large number of events, so typically it is set to No Auditing. However,
this setting can provide a great benefit during an incident response from the detailed log of the processes started
and the time they were launched. For domain controllers and other single-role infrastructure servers, this category
can be safely turned on all the time. Single role servers do not generate much process tracking traffic during the
normal course of their duties. As such, they can be enabled to capture unauthorized events if they occur.
Sy st e m Ev e n t s A u d i t
System Events is almost a generic catch-all category, registering various events that impact the computer, its system
security, or the security log. It includes events for computer shutdowns and restarts, power failures, system time
changes, authentication package initializations, audit log clearings, impersonation issues, and a host of other
general events. In general, enabling this audit category generates a lot of "noise," but it generates enough very
useful events that it is difficult to ever recommend not enabling it.
Advanced Audit Policies
Starting with Windows Vista and Windows Server 2008, Microsoft improved the way event log category selections
can be made by creating subcategories under each main audit category. Subcategories allow auditing to be far
more granular than it could otherwise by using the main categories. By using subcategories, you can enable only
portions of a particular main category, and skip generating events for which you have no use. Each audit policy
subcategory can be enabled for Success, Failure, or Success and Failure events.
To list all the available auditing subcategories, review the Advanced Audit Policy container in a Group Policy Object,
or type the following at a command prompt on any computer running Windows Server 2012, Windows Server
2008 R2, or Windows Server 2008, Windows 8, Windows 7, or Windows Vista:
auditpol /list /subcategory:\*
To get a list of currently configured auditing subcategories on a computer running Windows Server 2012, Windows
Server 2008 R2, or Windows 2008, type the following:
auditpol /get /category:\*
The following screenshot shows an example of auditpol.exe listing the current audit policy.
NOTE
Group Policy does not always accurately report the status of all enabled auditing policies, whereas auditpol.exe does. See
Getting the Effective Audit Policy in Windows 7 and 2008 R2 for more details.
Each main category has multiple subcategories. Below is a list of categories, their subcategories, and a description
of their functions.
Auditing Subcategories Descriptions
Audit policy subcategories enable the following event log message types:
Account Logon
C r e d e n t i a l Va l i d a t i o n
This subcategory reports the results of validation tests on credentials submitted for a user account logon request.
These events occur on the computer that is authoritative for the credentials. For domain accounts, the domain
controller is authoritative, whereas for local accounts, the local computer is authoritative.
In domain environments, most of the account logon events are logged in the security log of the domain controllers
that are authoritative for the domain accounts. However, these events can occur on other computers in the
organization when local accounts are used to log on.
K e r b e r o s Se r v i c e T i c k e t O p e r a t i o n s
This subcategory reports events generated by Kerberos ticket request processes on the domain controller that is
authoritative for the domain account.
K e r b e r o s A u t h e n t i c a t i o n Se r v i c e
This subcategory reports events generated by the Kerberos authentication service. These events occur on the
computer that is authoritative for the credentials.
O t h e r A c c o u n t L o g o n Ev e n t s
This subcategory reports the events that occur in response to credentials submitted for a user account logon
request that do not relate to credential validation or Kerberos tickets. These events occur on the computer that is
authoritative for the credentials. For domain accounts, the domain controller is authoritative, whereas for local
accounts, the local computer is authoritative.
In domain environments, most account logon events are logged in the security log of the domain controllers that
are authoritative for the domain accounts. However, these events can occur on other computers in the organization
when local accounts are used to log on. Examples can include the following:
Remote Desktop Services session disconnections
New Remote Desktop Services sessions
Locking and unlocking a workstation
Invoking a screen saver
Dismissing a screen saver
Detection of a Kerberos replay attack, in which a Kerberos request with identical information is received
twice
Access to a wireless network granted to a user or computer account
Access to a wired 802.1x network granted to a user or computer account
Account Management
U se r A c c o u n t M a n a g e m e n t
This subcategory reports each event of user account management, such as when a user account is created,
changed, or deleted; a user account is renamed, disabled, or enabled; or a password is set or changed. If this audit
policy setting is enabled, administrators can track events to detect malicious, accidental, and authorized creation of
user accounts.
Co m pu t er A c c o u n t Man agem en t
This subcategory reports each event of computer account management, such as when a computer account is
created, changed, deleted, renamed, disabled, or enabled.
Se c u r i t y G r o u p M a n a g e m e n t
This subcategory reports each event of security group management, such as when a security group is created,
changed, or deleted or when a member is added to or removed from a security group. If this audit policy setting is
enabled, administrators can track events to detect malicious, accidental, and authorized creation of security group
accounts.
D i st r i b u t i o n G r o u p M a n a g e m e n t
This subcategory reports each event of distribution group management, such as when a distribution group is
created, changed, or deleted or when a member is added to or removed from a distribution group. If this audit
policy setting is enabled, administrators can track events to detect malicious, accidental, and authorized creation of
group accounts.
A ppl i c at i o n Gr o u p Man agem en t
This subcategory reports each event of application group management on a computer, such as when an application
group is created, changed, or deleted or when a member is added to or removed from an application group. If this
audit policy setting is enabled, administrators can track events to detect malicious, accidental, and authorized
creation of application group accounts.
O t h e r A c c o u n t M a n a g e m e n t Ev e n t s
This subcategory reports other account management events.

Detailed Process Tracking
P r o c e ss C r e a t i o n
This subcategory reports the creation of a process and the name of the user or program that created it.
P r o c e ss Te r m i n a t i o n
This subcategory reports when a process terminates.

DPA PI Activity
This subcategory reports encrypt or decrypt calls into the data protection application programming interface
(DPAPI). DPAPI is used to protect secret information such as stored password and key information.
R P C Ev e n t s
This subcategory reports remote procedure call (RPC ) connection events.

Directory Service Access
D i r e c t o r y Se r v i c e A c c e ss
This subcategory reports when an AD DS object is accessed. Only objects with configured SACLs cause audit
events to be generated, and only when they are accessed in a manner that matches the SACL entries. These events
are similar to the directory service access events in earlier versions of Windows Server. This subcategory applies
only to domain controllers.
D i r e c t o r y Se r v i c e C h a n g e s
This subcategory reports changes to objects in AD DS. The types of changes that are reported are create, modify,
move, and undelete operations that are performed on an object. Directory service change auditing, where
appropriate, indicates the old and new values of the changed properties of the objects that were changed. Only
objects with SACLs cause audit events to be generated, and only when they are accessed in a manner that matches
their SACL entries. Some objects and properties do not cause audit events to be generated due to settings on the
object class in the schema. This subcategory applies only to domain controllers.
D i r e c t o r y Se r v i c e R e p l i c a t i o n
This subcategory reports when replication between two domain controllers begins and ends.
D e t a i l e d D i r e c t o r y Se r v i c e R e p l i c a t i o n
This subcategory reports detailed information about the information replicated between domain controllers. These
events can be very high in volume.
Logon/Logoff
Logon
This subcategory reports when a user attempts to log on to the system. These events occur on the accessed
computer. For interactive logons, the generation of these events occurs on the computer that is logged on to. If a
network logon takes place to access a share, these events generate on the computer that hosts the accessed
resource. If this setting is configured to No auditing, it is difficult or impossible to determine which user has
accessed or attempted to access organization computers.
N e t w o r k P o l i c y Se r v e r
This subcategory reports events generated by RADIUS (IAS ) and Network Access Protection (NAP ) user access
requests. These requests can be Grant, Deny, Discard, Quarantine, Lock, and Unlock. Auditing this setting will
result in a medium or high volume of records on NPS and IAS servers.
I P se c M a i n M o d e
This subcategory reports the results of Internet Key Exchange (IKE ) protocol and Authenticated Internet Protocol
(AuthIP ) during Main Mode negotiations.
I P se c Ex t e n d e d M o d e
This subcategory reports the results of AuthIP during Extended Mode negotiations.
O t h e r L o g o n / L o g o ff Ev e n t s
This subcategory reports other logon and logoff-related events, such as Remote Desktop Services session
disconnects and reconnects, using RunAs to run processes under a different account, and locking and unlocking a
workstation.
L o g o ff
This subcategory reports when a user logs off the system. These events occur on the accessed computer. For
interactive logons, the generation of these events occurs on the computer that is logged on to. If a network logon
takes place to access a share, these events generate on the computer that hosts the accessed resource. If this setting
is configured to No auditing, it is difficult or impossible to determine which user has accessed or attempted to
access organization computers.
A c c ou n t Loc kou t
This subcategory reports when a user's account is locked out as a result of too many failed logon attempts.
I P se c Q u i c k M o d e
This subcategory reports the results of IKE protocol and AuthIP during Quick Mode negotiations.
Sp e c i a l L o g o n
This subcategory reports when a special logon is used. A special logon is a logon that has administrator equivalent
privileges and can be used to elevate a process to a higher level.
Policy Change
A u di t Pol i c y Ch an ge
This subcategory reports changes in audit policy including SACL changes.
A u t h en t i c at i o n Po l i c y Ch an ge
This subcategory reports changes in authentication policy.

A u t h or i z at i on Pol i c y Ch an ge
This subcategory reports changes in authorization policy including permissions (DACL ) changes.
M P SSV C R u l e - L e v e l P o l i c y C h a n g e
This subcategory reports changes in policy rules used by the Microsoft Protection Service (MPSSVC.exe). This
service is used by Windows Firewall.
F i l t e r i n g P l a t fo r m P o l i c y C h a n g e
This subcategory reports the addition and removal of objects from WFP, including startup filters. These events can
be very high in volume.
O t h e r P o l i c y C h a n g e Ev e n t s
This subcategory reports other types of security policy changes such as configuration of the Trusted Platform
Module (TPM ) or cryptographic providers.
Privilege Use
Se n si t i v e P r i v i l e g e U se
This subcategory reports when a user account or service uses a sensitive privilege. A sensitive privilege includes
the following user rights: act as part of the operating system, back up files and directories, create a token object,
debug programs, enable computer and user accounts to be trusted for delegation, generate security audits,
impersonate a client after authentication, load and unload device drivers, manage auditing and security log, modify
firmware environment values, replace a process-level token, restore files and directories, and take ownership of files
or other objects. Auditing this subcategory will create a high volume of events.
N o n se n si t i v e P r i v i l e g e U se
This subcategory reports when a user account or service uses a nonsensitive privilege. A nonsensitive privilege
includes the following user rights: access Credential Manager as a trusted caller, access this computer from the
network, add workstations to domain, adjust memory quotas for a process, allow log on locally, allow log on
through Remote Desktop Services, bypass traverse checking, change the system time, create a pagefile, create
global objects, create permanent shared objects, create symbolic links, deny access this computer from the network,
deny log on as a batch job, deny log on as a service, deny log on locally, deny log on through Remote Desktop
Services, force shutdown from a remote system, increase a process working set, increase scheduling priority, lock
pages in memory, log on as a batch job, log on as a service, modify an object label, perform volume maintenance
tasks, profile single process, profile system performance, remove computer from docking station, shut down the
system, and synchronize directory service data. Auditing this subcategory will create a very high volume of events.
O t h e r P r i v i l e g e U se Ev e n t s
This security policy setting is not currently used.

Object Access
F i l e Sy st e m
This subcategory reports when file system objects are accessed. Only file system objects with SACLs cause audit
events to be generated, and only when they are accessed in a manner matching their SACL entries. By itself, this
policy setting will not cause auditing of any events. It determines whether to audit the event of a user who accesses
a file system object that has a specified system access control list (SACL ), effectively enabling auditing to take place.
If the audit object access setting is configured to Success, an audit entry is generated each time that a user
successfully accesses an object with a specified SACL. If this policy setting is configured to Failure, an audit entry is
generated each time that a user fails in an attempt to access an object with a specified SACL.
R e g i st r y
This subcategory reports when registry objects are accessed. Only registry objects with SACLs cause audit events
to be generated, and only when they are accessed in a manner matching their SACL entries. By itself, this policy
setting will not cause auditing of any events.
Ker n el O bj ec t
This subcategory reports when kernel objects such as processes and mutexes are accessed. Only kernel objects
with SACLs cause audit events to be generated, and only when they are accessed in a manner matching their SACL
entries. Typically kernel objects are only given SACLs if the AuditBaseObjects or AuditBaseDirectories auditing
options are enabled.
SA M
This subcategory reports when local Security Accounts Manager (SAM ) authentication database objects are
accessed.
C e r t i fi c a t i o n Se r v i c e s
This subcategory reports when Certification Services operations are performed.

A ppl i c at i o n Gen er at ed
This subcategory reports when applications attempt to generate audit events by using the Windows auditing
application programming interfaces (APIs).
Han dl e Man i pu l at i o n
This subcategory reports when a handle to an object is opened or closed. Only objects with SACLs cause these
events to be generated, and only if the attempted handle operation matches the SACL entries. Handle Manipulation
events are only generated for object types where the corresponding object access subcategory is enabled (for
example, file system or registry).
F i l e Sh a r e
This subcategory reports when a file share is accessed. By itself, this policy setting will not cause auditing of any
events. It determines whether to audit the event of a user who accesses a file share object that has a specified
system access control list (SACL ), effectively enabling auditing to take place.
F i l t e r i n g P l a t fo r m P a c k e t D r o p
This subcategory reports when packets are dropped by Windows Filtering Platform (WFP ). These events can be
very high in volume.
F i l t e r i n g P l a t fo r m C o n n e c t i o n
This subcategory reports when connections are allowed or blocked by WFP. These events can be high in volume.
O t h e r O b j e c t A c c e ss Ev e n t s
This subcategory reports other object access-related events such as Task Scheduler jobs and COM+ objects.
System
Se c u r i t y St a t e C h a n g e
This subcategory reports changes in security state of the system, such as when the security subsystem starts and
stops.
Se c u r i t y Sy st e m Ex t e n si o n
This subcategory reports the loading of extension code such as authentication packages by the security subsystem.
Sy st e m I n t e g r i t y
This subcategory reports on violations of integrity of the security subsystem.

IPsec Driver
This subcategory reports on the activities of the Internet Protocol security (IPsec) driver.
O t h e r Sy st e m Ev e n t s
This subcategory reports on other system events.

For more information about the subcategory descriptions, refer to the Microsoft Security Compliance Manager
tool.
Each organization should review the previous covered categories and subcategories and enable the ones which
best fit their environment. Changes to audit policy should always be tested prior to deployment in a production
environment.
Configuring Windows Audit Policy
Windows audit policy can be set using group policies, auditpol.exe, APIs, or registry edits. The recommended
methods for configuring audit policy for most companies are Group Policy or auditpol.exe. Setting a system's audit
policy requires administrator-level account permissions or the appropriate delegated permissions.
NOTE
The Manage auditing and security log privilege must be given to security principals (Administrators have it by default) to
allow the modification of object access auditing options of individual resources, such as files, Active Directory objects, and
registry keys.
Setting Windows Audit Policy by Using Group Policy

To set audit policy using group policies, configure the appropriate audit categories located under Computer
Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy (see the following
screenshot for an example from the Local Group Policy Editor (gpedit.msc)). Each audit policy category can be
enabled for Success, Failure, or Success and Failure events.
Advanced Audit Policy can be set by using Active Directory or local group policies. To set Advanced Audit Policy,
configure the appropriate subcategories located under Computer Configuration\Windows Settings\Security
Settings\Advanced Audit Policy (see the following screenshot for an example from the Local Group Policy
Editor (gpedit.msc)). Each audit policy subcategory can be enabled for Success, Failure, or Success and Failure
events.
Setting Windows Audit Policy Using Auditpol.exe

Auditpol.exe (for setting Windows audit policy) was introduced in Windows Server 2008 and Windows Vista.
Initially, only auditpol.exe could be used to set Advanced Audit Policy, but Group Policy can be used in Windows
Server 2012, Windows Server 2008 R2, or Windows Server 2008, Windows 8, and Windows 7.
Auditpol.exe is a command-line utility. The syntax is as follows:
auditpol /set /<Category|Subcategory>: /<success|failure:> /<enable|disable>
Auditpol.exe syntax examples:
auditpol /set /subcategory:"user account management" /success:enable /failure:enable
auditpol /set /subcategory:"logon" /success:enable /failure:enable
auditpol /set /subcategory:"IPSEC Main Mode" /failure:enable
NOTE
Auditpol.exe sets Advanced Audit Policy locally. If local policy conflicts with Active Directory or local Group Policy, Group Policy
settings usually prevail over auditpol.exe settings. When multiple group or local policy conflicts exist, only one policy will
prevail (that is, replace). Audit policies will not merge.
Scripting Auditpol
Microsoft provides a sample script for administrators who want to set Advanced Audit Policy by using a script
instead of manually typing in each auditpol.exe command.
Note Group Policy does not always accurately report the status of all enabled auditing policies, whereas
auditpol.exe does. See Getting the Effective Audit Policy in Windows 7 and Windows 2008 R2 for more details.
Other Auditpol Commands
Auditpol.exe can be used to save and restore a local audit policy, and to view other auditing related commands.
Here are the other auditpol commands.
auditpol /clear - Used to clear and reset local audit policies
auditpol /backup /file: - Used to back up a current local audit policy to a binary file
auditpol /restore /file: - Used to import a previously saved audit policy file to a local audit policy
auditpol /<get/set> /option: /<enable/disable> - If this audit policy setting is enabled, it causes the system to
immediately stop (with STOP: C0000244 {Audit Failed} message) 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 retention method specified
for the security log is Do Not Overwrite Events or Overwrite Events by Days. Typically it is only enabled by
environments that need higher assurance that the security log is logging. If enabled, administrators must closely
watch security log size and rotate logs as required. It can also be set with Group Policy by modifying the security
option Audit: Shut down system immediately if unable to log security audits (default=disabled).
Auditpol /<get/set> /option: /<enable/disable> - This audit policy setting determines whether to audit the
access of global system objects. If this policy is enabled, it causes system objects, such as mutexes, events,
semaphores, and DOS devices to be created with a default system access control list (SACL ). Most administrators
consider auditing global system objects to be too "noisy," and they will only enable it if malicious hacking is
suspected. Only named objects are given a SACL. If the audit object access audit policy (or Kernel Object audit
subcategory) is also enabled, access to these system objects is audited. When configuring this security setting,
changes will not take effect until you restart Windows. This policy can also be set with Group Policy by modifying
the security option Audit the access of global system objects (default=disabled).
auditpol /<get/set> /option: /<enable/disable> - This audit policy setting specifies that named kernel objects
(such as mutexes and semaphores) are to be given SACLs when they are created. AuditBaseDirectories affects
container objects while AuditBaseObjects affects objects that cannot contain other objects.
Auditpol /<get/set> /option: /<enable/disable> -
This audit policy setting specifies whether the client generates an event when one or more of these privileges are
assigned to a user security token: AssignPrimaryTokenPrivilege, AuditPrivilege, BackupPrivilege,
CreateTokenPrivilege, DebugPrivilege, EnableDelegationPrivilege, ImpersonatePrivilege, LoadDriverPrivilege,
RestorePrivilege, SecurityPrivilege, SystemEnvironmentPrivilege, TakeOwnershipPrivilege, and TcbPrivilege. If this
option is not enabled (default=Disabled), the BackupPrivilege and RestorePrivilege privileges are not recorded.
Enabling this option can make the security log extremely noisy (sometimes hundreds of events a second) during a
backup operation. This policy can also be set with Group Policy by modifying the security option Audit: Audit the
use of Backup and Restore privilege.
NOTE
Some information provided here was taken from the Microsoft Audit Option Type and the Microsoft SCM tool.
Enforcing Traditional Auditing or Advanced Auditing

In Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, Windows 7, and Windows
Vista, administrators can choose to enable the nine traditional categories or to use the subcategories. It's a binary
choice that must be made in each Windows system. Either the main categories can be enabled or the
subcategoriesit cannot be both.
To prevent the legacy traditional category policy from overwriting audit policy subcategories, you must enable the
Force audit policy subcategory settings(Windows Vista or later) to override audit policy category
settings policy setting located under Computer Configuration\Windows Settings\Security Settings\Local
Policies\Security Options.
We recommend that the subcategories be enabled and configured instead of the nine main categories. This
requires that a Group Policy setting be enabled (to allow subcategories to override the auditing categories) along
with configuring the different subcategories that support auditing policies.
Auditing subcategories can be configured by using several methods, including Group Policy and the command-line
program, auditpol.exe.
For more information about Windows auditing, see the following articles:
Advanced Security Auditing in Windows 7 and Windows Server 2008 R2
Auditing and Compliance in Windows Server 2008
How to use Group Policy to configure detailed security auditing settings for Windows Vista-based and
Windows Server 2008-based computers in a Windows Server 2008 domain, in a Windows Server 2003
domain, or in a Windows 2000 domain
Advanced Security Audit Policy Step-by-Step Guide
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows 10, Windows
8.1, Windows 7
This section addresses the Windows default audit policy settings, baseline recommended audit policy settings, and
the more aggressive recommendations from Microsoft, for workstation and server products.
The SCM baseline recommendations shown here, along with the settings we recommend to help detect
compromise, are intended only to be a starting baseline guide to administrators. Each organization must make its
own decisions regarding the threats they face, their acceptable risk tolerances, and what audit policy categories or
subcategories they should enable. For further information about threats, refer to the Threats and Countermeasures
Guide. Administrators without a thoughtful audit policy in place are encouraged to start with the settings
recommended here, and then to modify and test, prior to implementing in their production environment.
The recommendations are for enterprise-class computers, which Microsoft defines as computers that have average
security requirements and require a high level of operational functionality. Entities needing higher security
requirements should consider more aggressive audit policies.
NOTE
Microsoft Windows defaults and baseline recommendations were taken from the Microsoft Security Compliance Manager
tool.
The following baseline audit policy settings are recommended for normal security computers that are not known to
be under active, successful attack by determined adversaries or malware.
Recommended Audit Policies by Operating System

This section contains tables that list the audit setting recommendations that apply to the following operating
systems:
Windows Server 2016
Windows Server 2012
Windows Server 2008
Windows 10
Windows 8.1
Windows 7
These tables contain the Windows default setting, the baseline recommendations, and the stronger
recommendations for these operating systems.
Audit Policy Tables Legend
Notation Recommendation
YES Enable in general scenarios
NO Do not enable in general scenarios
IF Enable if needed for a specific scenario, or if a role or feature

for which auditing is desired is installed on the machine
DC Enable on domain controllers
[Blank] No recommendation
Windows 10, Windows 8, and Windows 7 Audit Settings Recommendations

Audit Policy
STRONGER
WINDOWS DEFAULT BASELINE RECOMMENDATION RECOMMENDATION
AUDIT POLICY CATEGORY OR
SUBCATEGORY SUCCESS FAILURE SUCCESS FAILURE SUCCESS FAILURE
Account Logon
Audit Credential Validation No No Yes No Yes Yes
Audit Kerberos Yes Yes

Authentication Service
Audit Kerberos Service Ticket Yes Yes

Operations
Audit Other Account Logon Yes Yes

Events
Account Management
Audit Application Group

Management
Audit Computer Account Yes No Yes Yes

Management
Audit Distribution Group

Management
Audit Other Account Yes No Yes Yes

Management Events
Audit Security Group Yes No Yes Yes

Management
Audit User Account Yes No Yes No Yes Yes

Management
STRONGER
Detailed Tracking
Audit DPAPI Activity Yes Yes
Audit Process Creation Yes No Yes Yes
Audit Process Termination
Audit RPC Events
DS Access
Audit Detailed Directory

Service Replication
Audit Directory Service

Access

Changes

Replication
Logon and Logoff
Audit Account Lockout Yes No Yes No
Audit User/Device Claims
Audit IPsec Extended Mode
Audit IPsec Main Mode IF IF
Audit IPsec Quick Mode
Audit Logoff Yes No Yes No Yes No
Audit Logon 1 Yes Yes Yes Yes Yes Yes
Audit Network Policy Server Yes Yes
Audit Other Logon/Logoff

Events
Audit Special Logon Yes No Yes No Yes Yes
Object Access
STRONGER
Audit Application Generated
Audit Certification Services
Audit Detailed File Share
Audit File Share
Audit File System
Audit Filtering Platform

Connection

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
Audit Audit Policy Change Yes No Yes Yes Yes Yes
Audit Authentication Policy Yes No Yes No Yes Yes

Change
Audit Authorization Policy

Change

Policy Change
Audit MPSSVC Rule-Level Yes

Policy Change
Audit Other Policy Change

Events
STRONGER
Privilege Use
Audit Non Sensitive Privilege

Use
Audit Other Privilege Use

Events
Audit Sensitive Privilege Use
System
Audit IPsec Driver Yes Yes Yes Yes
Audit Other System Events Yes Yes
Audit Security State Change Yes No Yes Yes Yes Yes
Audit Security System Yes Yes Yes Yes

Extension
Audit System Integrity Yes Yes Yes Yes Yes Yes
Global Object Access

Auditing
Audit IPsec Driver
Audit Other System Events
Audit Security State Change
Audit Security System

Extension
Audit System Integrity
1 Beginning with Windows 10 version 1809, Audit Logon is enabled by default for both Success and Failure. In
previous versions of Windows, only Success is enabled by default.
Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, and
Windows Server 2008 Audit Settings Recommendations
STRONGER
Account Logon
Audit Credential Validation No No Yes Yes Yes Yes

STRONGER
Audit Kerberos Yes Yes

Authentication Service
Audit Kerberos Service Ticket Yes Yes

Operations
Audit Other Account Logon Yes Yes

Events
Account Management
Audit Application Group

Management
Audit Computer Account Yes DC Yes Yes

Management
Audit Distribution Group

Management
Audit Other Account Yes Yes Yes Yes

Management Events
Audit Security Group Yes Yes Yes Yes

Management
Audit User Account Yes No Yes Yes Yes Yes

Management
Detailed Tracking
Audit DPAPI Activity Yes Yes
Audit Process Creation Yes No Yes Yes
Audit Process Termination
Audit RPC Events
DS Access
Audit Detailed Directory

Service Replication
Audit Directory Service DC DC DC DC

Access
Audit Directory Service DC DC DC DC

Changes
STRONGER

Replication
Logon and Logoff
Audit Account Lockout Yes No Yes No
Audit User/Device Claims
Audit IPsec Extended Mode
Audit IPsec Main Mode IF IF
Audit IPsec Quick Mode
Audit Logoff Yes No Yes No Yes No
Audit Logon Yes Yes Yes Yes Yes Yes
Audit Network Policy Server Yes Yes
Audit Other Logon/Logoff Yes Yes

Events
Audit Special Logon Yes No Yes No Yes Yes
Object Access
Audit Application Generated
Audit Certification Services
Audit Detailed File Share
Audit File Share
Audit File System

Connection

Packet Drop
Audit Handle Manipulation
Audit Kernel Object

STRONGER
Audit Other Object Access

Events
Audit Registry
Audit Removable Storage
Audit SAM
Audit Central Access Policy

Staging
Policy Change
Audit Audit Policy Change Yes No Yes Yes Yes Yes
Audit Authentication Policy Yes No Yes No Yes Yes

Change
Audit Authorization Policy

Change

Policy Change
Audit MPSSVC Rule-Level Yes

Policy Change
Audit Other Policy Change

Events
Privilege Use
Audit Non Sensitive Privilege

Use
Audit Other Privilege Use

Events
Audit Sensitive Privilege Use
System
Audit IPsec Driver Yes Yes Yes Yes
Audit Other System Events Yes Yes
Audit Security State Change Yes No Yes Yes Yes Yes

STRONGER
Audit Security System Yes Yes Yes Yes

Extension
Audit System Integrity Yes Yes Yes Yes Yes Yes
Global Object Access

Auditing
Audit IPsec Driver
Audit Other System Events
Audit Security State Change
Audit Security System

Extension
Audit System Integrity
Set Audit Policy on Workstations and Servers

All event log management plans should monitor workstations and servers. A common mistake is to only monitor
servers or domain controllers. Because malicious hacking often initially occurs on workstations, not monitoring
workstations is ignoring the best and earliest source of information.
Administrators should thoughtfully review and test any audit policy prior to implementation in their production
environment.
Events to Monitor
A perfect event ID to generate a security alert should contain the following attributes:
High likelihood that occurrence indicates unauthorized activity
Low number of false positives
Occurrence should result in an investigative/forensics response
Two types of events should be monitored and alerted:
1. Those events in which even a single occurrence indicates unauthorized activity
2. An accumulation of events above an expected and accepted baseline
An example of the first event is:
If Domain Admins (DAs) are forbidden from logging on to computers that are not domain controllers, a single
occurrence of a DA member logging on to an end-user workstation should generate an alert and be investigated.
This type of alert is easy to generate by using the Audit Special Logon event 4964 (Special groups have been
assigned to a new logon). Other examples of single instance alerts include:
If Server A should never connect to Server B, alert when they connect to each other.
Alert if a normal end-user account is unexpectedly added to a sensitive security group.
If employees in factory location A never work at night, alert when a user logs on at midnight.
Alert if an unauthorized service is installed on a domain controller.
Investigate if a regular end-user attempts to directly log on to a SQL Server for which they have no clear
reason for doing so.
If you have no members in your DA group, and someone adds themselves there, check it immediately.
An example of the second event is:
An aberrant number of failed logons could indicate a password guessing attack. For an enterprise to provide an
alert for an unusually high number of failed logons, they must first understand the normal levels of failed logons
within their environment prior to a malicious security event.
For a comprehensive list of events that you should include when you monitor for signs of compromise, please see
Appendix L: Events to Monitor.
Active Directory Objects and Attributes to Monitor

The following are the accounts, groups, and attributes that you should monitor to help you detect attempts to
compromise your Active Directory Domain Services installation.
Systems for disabling or removal of antivirus and antimalware software (automatically restart protection
when it is manually disabled)
Administrator accounts for unauthorized changes
Activities that are performed by using privileged accounts (automatically remove account when suspicious
activities are completed or allotted time has expired)
Privileged and VIP accounts in AD DS. Monitor for changes, particularly changes to attributes on the
Account tab (for example, cn, name, sAMAccountName, userPrincipalName, or userAccountControl). In
addition to monitoring the accounts, restrict who can modify the accounts to as small a set of administrative
users as possible.
Refer to Appendix L: Events to Monitor for a list of recommended events to monitor, their criticality ratings, and an
event message summary.
Group servers by the classification of their workloads, which allows you to quickly identify the servers that
should be the most closely monitored and most stringently configured
Changes to the properties and membership of following AD DS groups: Enterprise Admins (EA), Domain
Admins (DA), Administrators (BA), and Schema Admins (SA)
Disabled privileged accounts (such as built-in Administrator accounts in Active Directory and on member
systems) for enabling the accounts
Management accounts to log all writes to the account
Built-in Security Configuration Wizard to configure service, registry, audit, and firewall settings to reduce the
server's attack surface. Use this wizard if you implement jump servers as part of your administrative host
strategy.
Additional Information for Monitoring Active Directory Domain Services

Review the following links for additional information about monitoring AD DS:
Global Object Access Auditing is Magic - Provides information about configuring and using Advanced Audit
Policy Configuration that was added to Windows 7 and Windows Server 2008 R2.
Introducing Auditing Changes in Windows 2008 - Introduces the auditing changes made in Windows 2008.
Cool Auditing Tricks in Vista and 2008 - Explains interesting new features of auditing in Windows Vista and
Windows Server 2008 that can be used for troubleshooting problems or seeing what's happening in your
environment.
One-Stop Shop for Auditing in Windows Server 2008 and Windows Vista - Contains a compilation of
auditing features and information contained in Windows Server 2008 and Windows Vista.
AD DS Auditing Step-by-Step Guide - Describes the new Active Directory Domain Services (AD DS )
auditing feature in Windows Server 2008. It also provides procedures to implement this new feature.
General List of Security Event ID Recommendation Criticalities

All Event ID recommendations are accompanied by a criticality rating as follows:
High: Event IDs with a high criticality rating should always and immediately be alerted and investigated.
Medium: An Event ID with a medium criticality rating could indicate malicious activity, but it must be accompanied
by some other abnormality (for example, an unusual number occurring in a particular time period, unexpected
occurrences, or occurrences on a computer that normally would not be expected to log the event.). A medium-
criticality event may also r be collected as a metric and compared over time.
Low: And Event ID with a low criticality events should not garner attention or cause alerts, unless correlated with
medium or high criticality events.
These recommendations are meant to provide a baseline guide for the administrator. All recommendations should
be thoroughly reviewed prior to implementation in a production environment.
Refer to Appendix L: Events to Monitor for a list of the recommended events to monitor, their criticality ratings, and
an event message summary.
Law Number One: Nobody believes anything bad can happen to them, until it does. - 10 Immutable Laws of
Security Administration
Disaster recovery plans in many organizations focus on recovering from regional disasters or failures that result in
loss of computing services. However, when working with compromised customers, we often find that recovering
from intentional compromise is absent in their disaster recovery plans. This is particularly true when the
compromise results in theft of intellectual property or intentional destruction that leverages logical boundaries
(such as destruction of all Active Directory domains or all servers) rather than physical boundaries (such as
destruction of a datacenter). Although an organization may have incident response plans that define initial activities
to take when a compromise is discovered, these plans often omit steps to recover from a compromise that affects
the entire computing infrastructure.
Because Active Directory provides rich identity and access management capabilities for users, servers,
workstations, and applications, it is invariably targeted by attackers. If an attacker gains highly privileged access to
an Active Directory domain or domain controller, that access can be leveraged to access, control, or even destroy
the entire Active Directory forest.
This document has discussed some of the most common attacks against Windows and Active Directory and
countermeasures you can implement to reduce your attack surface, but the only sure way to recover in the event of
a complete compromise of Active Directory is to be prepared for the compromise before it happens. This section
focuses less on technical implementation details than previous sections of this document, and more on high-level
recommendations that you can use to create a holistic, comprehensive approach to secure and manage your
organization's critical business and IT assets.
Whether your infrastructure has never been attacked, has resisted attempted breaches, or has succumbed to attacks
and been fully compromised, you should plan for the inevitable reality that you will be attacked again and again. It
is not possible to prevent attacks, but it may indeed be possible to prevent significant breaches or wholesale
compromise. Every organization should closely evaluate their existing risk management programs, and make
necessary adjustments to help reduce their overall level of vulnerability by making balanced investments in
prevention, detection, containment, and recovery.
To create effective defenses while still providing services to the users and businesses that depend on your
infrastructure and applications, you may need to consider novel ways to prevent, detect, and contain compromise in
your environment, and then recover from the compromise. The approaches and recommendations in this
document may not help you repair a compromised Active Directory installation, but can help you secure your next
one.
Recommendations for recovering an Active Directory forest are presented in Windows Server 2012: Planning for
Active Directory Forest Recovery. You may be able to prevent your new environment from being completely
compromised, but even if you can't, you will have tools to recover and regain control of your environment.
Rethinking the Approach

Law Number Eight: The difficulty of defending a network is directly proportional to its complexity. - 10 Immutable
Laws of Security Administration
It is generally well-accepted that if an attacker has obtained SYSTEM, Administrator, root, or equivalent access to a
computer, regardless of operating system, that computer can no longer be considered trustworthy, no matter how
many efforts are made to "clean" the system. Active Directory is no different. If an attacker has obtained privileged
access to a domain controller or a highly privileged account in Active Directory, unless you have a record of every
modification the attacker makes or a known good backup, you can never restore the directory to a completely
trustworthy state.
When a member server or a workstation is compromised and altered by an attacker, the computer is no longer
trustworthy, but neighboring uncompromised servers and workstations can still be trusted. Compromise of one
computer does not imply that all computers are compromised.
However, in an Active Directory domain, all domain controllers host replicas of the same AD DS database. If a
single domain controller is compromised and an attacker modifies the AD DS database, those modifications
replicate to every other domain controller in the domain, and depending on the partition in which the modifications
are made, the forest. Even if you reinstall every domain controller in the forest, you are simply reinstalling the hosts
on which the AD DS database resides. Malicious modifications to Active Directory will replicate to freshly installed
domain controllers as easily as they will replicate to domain controllers that have been running for years.
In assessing compromised environments, we commonly find that what was believed to be the first breach "event"
was actually triggered after weeks, months, or even years after attackers had initially compromised the
environment. Attackers usually obtained the credentials for highly privileged accounts long before a breach was
detected, and they leveraged those accounts to compromise the directory, domain controllers, member servers,
workstations, and even connected non-Windows systems.
These findings are consistent with several findings in Verizon's 2012 Data Breach Investigations Report, which
states that:
98 percent of data breaches stemmed from external agents
85 percent of data breaches took weeks or more to discover
92 percent of incidents were discovered by a third party, and
97 percent of breaches were avoidable though simple or intermediate controls.
A compromise to the degree described earlier is effectively irreparable, and the standard advice to "flatten and
rebuild" every compromised system is simply not feasible or even possible if Active Directory has been
compromised or destroyed. Even restoring to a known good state does not eliminate the flaws that allowed the
environment to be compromised in the first place.
Although you must defend every facet of your infrastructure, an attacker only needs to find enough flaws in your
defenses to get to their desired goal. If your environment is relatively simple and pristine, and historically well-
managed, then implementing the recommendations provided earlier in this document may be a straightforward
proposition.
However, we have found that the older, larger, and more complex the environment, the more likely it is that the
recommendations in this document will be infeasible or even impossible to implement. It is much harder to secure
an infrastructure after the fact than it is to start fresh and to construct an environment that is resistant to attack and
compromise. But as previously noted, it is no small undertaking to rebuild an entire Active Directory forest. For
these reasons, we recommend a more focused, targeted approach to secure your Active Directory forests.
Rather than focusing on and trying to fix all of the things that are "broken," consider an approach in which you
prioritize based on what is most important to your business and in your infrastructure. Instead of trying to
remediate an environment filled with outdated, misconfigured systems and applications, consider creating a new
small, secure environment into which you can safely port the users, systems, and information that are most critical
to your business.
In this section, we describe an approach by which you can create a pristine AD DS forest that serves as a "life boat"
or "secure cell" for your core business infrastructure. A pristine forest is simply a newly installed Active Directory
forest that is typically limited in size and scope, and which is built by using current operating systems, applications,
and with the principles described in Reducing the Active Directory Attack Surface.
By implementing the recommended configuration settings in a newly built forest, you can create an AD DS
installation that is built from the ground up with secure settings and practices, and you can reduce the challenges
that accompany supporting legacy systems and applications. While detailed instructions for the design and
implementation of a pristine AD DS installation are outside the scope of this document, you should follow some
general principles and guidelines to create a "secure cell" into which you can house your most critical assets. These
guidelines are as follows:
1. Identify principles for segregating and securing critical assets.
2. Define a limited, risk-based migration plan.
3. Leverage "nonmigratory" migrations where necessary.
4. Implement "creative destruction."
5. Isolate legacy systems and applications.
6. Simplify security for end users.
Identifying Principles for Segregating and Securing Critical Assets
The characteristics of the pristine environment that you create to house critical assets can vary widely. For example,
you may choose to create a pristine forest into which you migrate only VIP users and sensitive data that only those
users can access. You may create a pristine forest in which you migrate not only VIP users, but which you
implement as an administrative forest, implementing the principles described in Reducing the Active Directory
Attack Surface to create secure administrative accounts and hosts that can be used to manage your legacy forests
from the pristine forest. You might implement a "purpose-built" forest that houses VIP accounts, privileged
accounts, and systems requiring additional security such as servers running Active Directory Certificate Services
(AD CS ) with the sole goal of segregating them from less-secure forests. Finally, you might implement a pristine
forest that becomes the de facto location for all new users, systems, applications and data, allowing you to
eventually decommission your legacy forest via attrition.
Regardless of whether your pristine forest contains a handful of users and systems or it forms the basis for a more
aggressive migration, you should follow these principles in your planning:
1. Assume that your legacy forests have been compromised.
2. Do not configure a pristine environment to trust a legacy forest, although you can configure a legacy
environment to trust a pristine forest.
3. Do not migrate user accounts or groups from a legacy forest to a pristine environment if there is a possibility
that the accounts' group memberships, SID history, or other attributes may have been maliciously modified.
Instead, use "nonmigratory" approaches to populate a pristine forest. (Nonmigratory approaches are
described later in this section.)
4. Do not migrate computers from legacy forests to pristine forests. Implement freshly installed servers in the
pristine forest, install applications on the freshly installed servers, and migrate application data to the newly
installed systems. For file servers, copy data to freshly installed servers, set ACLs by using users and groups
in the new forest, and then create print servers in a similar fashion.
5. Do not permit the installation of legacy operating systems or applications in the pristine forest. If an
application cannot be updated and freshly installed, leave it in the legacy forest and consider creative
destruction to replace the application's functionality.
Defining a Limited, Risk-Based Migration Plan
Creating a limited, risk-based migration plan simply means that when deciding which users, applications, and data
to migrate into your pristine forest, you should identify migration targets based on the degree of risk to which your
organization is exposed if one of the users or systems is compromised. VIP users whose accounts are most likely to
be targeted by attackers should be housed in the pristine forest. Applications that provide vital business functions
should be installed on freshly built servers in the pristine forest, and highly sensitive data should be moved to
secured servers in the pristine forest.
If you do not already have a clear picture of the most business-critical users, systems, applications, and data in your
Active Directory environment, work with business units to identify them. Any application required for the business
to operate should be identified, as should any servers on which critical applications run or critical data is stored. By
identifying the users and resources that are required for your organization to continue to function, you create a
naturally prioritized collection of assets on which to focus your efforts.
Leveraging "Nonmigratory" Migrations
Whether you know that your environment has been compromised, suspect that it has been compromised, or
simply prefer not to migrate legacy data and objects from a legacy Active Directory installation to a new one,
consider migration approaches that do not technically "migrate" objects.
User Accounts
In a traditional Active Directory migration from one forest to another, the SIDHistory (SID history) attribute on user
objects is used to store users' SID and the SIDs of groups that users were members of in the legacy forest. If users
accounts are migrated to a new forest, and they access resources in the legacy forest, the SIDs in the SID history
are used to create an access token that allows the users to access resources to which they had access before the
accounts were migrated.
Maintaining SID history, however, has proven problematic in some environments because populating users' access
tokens with current and historical SIDs can result in token bloat. Token bloat is an issue in which the number of
SIDs that must be stored in a user's access token uses or exceeds the amount of space available in the token.
Although token sizes can be increased to a limited extent, the ultimate solution to token bloat is to reduce the
number of SIDs associated with user accounts, whether by rationalizing group memberships, eliminating SID
history, or a combination of both. For more information about token bloat, see MaxTokenSize and Kerberos Token
Bloat.
Rather than migrating users from a legacy environment (particularly one in which group memberships and SID
histories may be compromised) by using SID history, consider leveraging metadirectory applications to "migrate"
users, without carrying SID histories into the new forest. When user accounts are created in the new forest, you can
use a metadirectory application to map the accounts to their corresponding accounts in the legacy forest.
To provide the new user accounts access to resources in the legacy forest, you can use the metadirectory tooling to
identify resource groups into which the users' legacy accounts were granted access, and then add the users' new
accounts to those groups. Depending on your group strategy in the legacy forest, you may need to create domain
local groups for resource access or convert existing groups to domain local groups to allow the new accounts to be
added to resource groups. By focusing first on the most critical applications and data and migrating them to the
new environment (with or without SID history), you can limit the amount of effort expended in the legacy
environment.
Servers and Workstations
In a traditional migration from one Active Directory forest to another, migrating computers is often relatively
simple compared to migrating users, groups, and applications. Depending on the computer role, migrating to a new
forest can be as simple as disjoining an old domain and joining a new one. However, migrating computer accounts
intact into a pristine forest defeats the purpose of creating a fresh environment. Rather than migrating (potentially
compromised, misconfigured, or outdated) computer accounts to a new forest, you should freshly install servers
and workstations in the new environment. You can migrate data from systems in the legacy forest to systems in the
pristine forest, but not the systems that house the data.
Applications
Applications can present the most significant challenge in any migration from one forest to another, but in the case
of a "nonmigratory" migration, one of the most basic principles you should apply is that applications in the pristine
forest should be current, supported, and freshly installed. Data can be migrated from application instances in the
old forest where possible. In situations in which an application cannot be "recreated" in the pristine forest, you
should consider approaches such as creative destruction or isolation of legacy applications as described in the
following section.
Implementing Creative Destruction
Creative destruction is an economics term that describes economic development created by the destruction of a
prior order. In recent years, the term has been applied to information technology. It typically refers to mechanisms
by which old infrastructure is eliminated, not by upgrading it, but by replacing it with something altogether new.
The 2011 Gartner Symposium ITXPO for CIOs and senior IT executives presented creative destruction as one of its
key themes for cost reduction and increases in efficiency. Improvements in security are possible as a natural
outgrowth of the process.
For example, an organization may be composed of multiple business units that use a different application that
performs similar functionality, with varying degrees of modernity and vendor support. Historically, IT might be
responsible for maintaining each business unit's application separately, and consolidation efforts would consist of
attempting to figure out which application offered the best functionality and then migrating data into that
application from the others.
In creative destruction, rather than maintaining outdated or redundant applications, you implement entirely new
applications to replace the old, migrate data into the new applications, and decommission the old applications and
the systems on which they run. In some cases, you can implement creative destruction of legacy applications by
deploying a new application in your own infrastructure, but wherever possible, you should consider porting the
application to a cloud-based solution instead.
By deploying cloud-based applications to replace legacy in-house applications, you not only reduce maintenance
efforts and costs, but you reduce your organization's attack surface by eliminating legacy systems and applications
that present vulnerabilities for attackers to leverage. This approach provides a faster way for an organization to
obtain desired functionality while simultaneously eliminating legacy targets in the infrastructure. Although the
principle of creative destruction does not apply to all IT assets, it provides an often viable option to eliminating
legacy systems and applications while simultaneously deploying robust, secure, cloud-based applications.
Isolating Legacy Systems and Applications
A natural outgrowth of migrating your business-critical users and systems to a pristine, secure environment is that
your legacy forest will be contain less valuable information and systems. Although the legacy systems and
applications that remain in the less secure environment may present elevated risk of compromise, they also
represent a reduced severity of compromise. By rehoming and modernizing your critical business assets, you can
focus on deploying effective management and monitoring while not needing to accommodate legacy settings and
protocols.
When you have rehomed your critical data to a pristine forest, you can evaluate options to further isolating legacy
systems and applications in your "main" AD DS forest. Although you might implement creative destruction to
replace one application and the servers on which it runs, in other cases you might consider additional isolation of
the least secure systems and applications. For example, an application that is used by a handful of users, but which
requires legacy credentials like LAN Manager hashes can be migrated to a small domain you create to support
systems for which you have no replacement options.
By removing these systems from domains where they forced implementation of legacy settings, you can
subsequently increase the security of the domains by configuring them to support only current operating systems
and applications. Although, it is preferable to decommission legacy systems and applications whenever possible. If
decommissioning is simply not feasible for a small segment of your legacy population, segregating it into a
separate domain (or forest) allows you to perform incremental improvements in the rest of the legacy installation.
Simplifying Security for End Users
In most organizations, users who have access to the most sensitive information due to the nature of their roles in
the organization often have the least amount of time to devote to learning complex access restrictions and controls.
Although you should have a comprehensive security education program for all users in your organization, you
should also focus on making security as simple to use as possible by implementing controls that are transparent
and simplifying principles to which users adhere.
For example, you may define a policy in which executives and other VIPs are required to use secure workstations to
access sensitive data and systems, allowing them to use their other devices to access less sensitive data. This is a
simple principle for users to remember, but you can implement a number of backend controls to help to enforce the
approach.
You can use Authentication Mechanism Assurance to permit the users to access sensitive data only if they've
logged on to their secure systems using their smart cards, and can use IPsec and user rights restrictions to control
the systems from which they can connect to sensitive data repositories. You can use the Microsoft Data
Classification Toolkit to build a robust file classification infrastructure, and you can implement Dynamic Access
Control to restrict access to data based on characteristics of an access attempt, translating business rules into
technical controls.
From the perspective of the user, accessing sensitive data from a secured system "just works," and attempting to do
so from an unsecured system "just doesn't." However, from the perspective of monitoring and managing your
environment, you're helping to create identifiable patterns in how users access sensitive data and systems, making
it easier for you to detect anomalous access attempts.
In environments in which user resistance to long, complex passwords has resulted in insufficient password policies,
particularly for VIP users, consider alternate approaches to authentication, whether via smart cards (which come in
a number of form factors and with additional features to strengthen authentication), biometric controls such as
finger-swipe readers, or even authentication data that is secured by trusted platform module (TPM ) chips in users'
computers. Although multifactor authentication does not prevent credential theft attacks if a computer is already
compromised, by giving your users easy-to-use authentication controls, you can assign more robust passwords to
the accounts of users for whom traditional user name and password controls are unwieldy.
Maintaining a More Secure Environment
Law Number Ten: Technology is not a panacea. - 10 Immutable Laws of Security Administration
When you have created a manageable, secure environment for your critical business assets, your focus should shift
to ensuring that it is maintained securely. Although you've been given specific technical controls to increase the
security of your AD DS installations, technology alone will not protect an environment in which IT does not work in
partnership with the business to maintain a secure, usable infrastructure. The high level recommendations in this
section are meant to be used as guidelines that you can use to develop not only effective security, but effective
lifecycle management.
In some cases, your IT organization might already have a close working relationship with business units, which will
ease implementing these recommendations. In organizations in which IT and business units are not closely tied,
you might need to first obtain executive sponsorship for efforts to forge a closer relationship between IT and
business units. The Executive Summary is intended to be useful as a standalone document for executive review, and
it can be disseminated to decision makers in your organization.
Creating Business-Centric Security Practices for Active Directory

In the past, information technology within many organizations was viewed as a support structure and a cost center.
IT departments were often largely segregated from business users, and interactions limited to a request-response
model in which the business requested resources and IT responded.
As technology has evolved and proliferated, the vision of "a computer on every desktop" has effectively come to
pass for much of the world, and even been eclipsed by the broad range of easily accessible technologies available
today. Information technology is no longer a support function, it is a core business function. If your organization
could not continue to function if all IT services were unavailable, your organization's business is, at least in part,
information technology.
To create effective compromise recovery plans, IT services must work closely with business units in your
organization to identify not only the most critical components of the IT landscape, but the critical functions required
by the business. By identifying what is important to your organization as a whole, you can focus on securing the
components that have the most value. This is not a recommendation to shirk the security of low value systems and
data. Rather, like you define levels of service for system uptime, you should consider defining levels of security
control and monitoring based on criticality of asset.
When you have invested in creating a current, secure, manageable environment, you can shift focus to managing it
effectively and ensuring that you have effective lifecycle management processes that aren't determined only by IT,
but by the business. To achieve this, you need not only to partner with the business, but to invest the business in
"ownership" of data and systems in Active Directory.
When data and systems are introduced into Active Directory without designated owners, business owners and IT
owners, there is no clear chain of responsibility for the provisioning, management, monitoring, updating, and
eventually decommissioning the system. This results in infrastructures in which systems expose the organization to
risk but cannot be decommissioned because ownership is unclear. To effectively manage the lifecycle of the users,
data, applications, and systems managed by your Active Directory installation, you should follow the principles
described in this section.
Assign a Business Owner to Active Directory Data
Data in Active Directory should have an identified business owner, that is, a specified department or user who is the
point of contact for decisions about the lifecycle of the asset. In some cases, the business owner of a component of
Active Directory will be an IT department or user. Infrastructure components such as domain controllers, DHCP
and DNS servers, and Active Directory will most likely be "owned" by IT. For data that is added to AD DS to
support the business (for example, new employees, new applications, and new information repositories), a
designated business unit or user should be associated with the data.
Whether you use Active Directory to record ownership of data in the directory, or whether you implement a
separate database for tracking IT assets, no user account should be created, no server or workstation should be
installed, and no application should be deployed without a designated owner of record. Trying to establish
ownership of systems after they've been deployed in production can be challenging at best, and impossible in some
cases. Therefore, ownership should be established at the time the data is introduced into Active Directory.
Implement Business-Driven Lifecycle Management
Lifecycle management should be implemented for all data in Active Directory. For example, when a new application
is introduced into an Active Directory domain, the application's business owner should, at regular intervals, be
expected to attest to the continued use of the application. When a new version of an application is released, the
application's business owner should be informed and should decide if and when the new version will be
implemented.
If a business owner chooses not to approve deployment of a new version of an application, that business owner
should also be notified of the date when the current version will no longer be supported and should be responsible
for determining whether the application will be decommissioned or replaced. Keeping legacy applications running
and unsupported should not be an option.
When user accounts are created in Active Directory, their managers of record should be notified at object creation
and required to attest to the validity of the account at regular intervals. By implementing a business driven lifecycle
and regular attestation of the validity of the data, the people who are best equipped to identify anomalies in the
data are the people who review the data.
For example, attackers might create user accounts that appear to be valid accounts, following your organization's
naming conventions and object placement. To detect these account creations, you might implement a daily task that
returns all user objects without a designated business owner so that you can investigate the accounts. If attackers
create accounts and assign a business owner, by implementing a task that reports new object creation to the
designated business owner, the business owner can quickly identify whether the account is legitimate.
You should implement similar approaches to security and distribution groups. Although some groups may be
functional groups created by IT, by creating every group with a designated owner, you can retrieve all groups
owned by a designated user and require the user to attest to the validity of their memberships. Similar to the
approach taken with user account creation, you can trigger reporting group modifications to the designated
business owner. The more routine it becomes for a business owner to attest to the validity or invalidity of data in
Active Directory, the more equipped you are to identify anomalies that can indicate process failures or actual
compromise.
Classify all Active Directory Data
In addition to recording a business owner for all Active Directory data at the time it is added to the directory, you
should also require business owners to provide classification for the data. For example, if an application stores
business-critical data, the business owner should label the application as such, in accordance with your
organization's classification infrastructure.
Some organizations implement data classification policies that label data according to the damage that exposure of
the data would incur if it were stolen or exposed. Other organizations implement data classification that labels data
by criticality, by access requirements, and by retention. Regardless of the data classification model in use in your
organization, you should ensure that you are able to apply classification to Active Directory data, not only to "file"
data. If a user's account is a VIP account, it should be identified in your asset classification database (whether you
implement this via the use of attributes on the objects in AD DS, or whether you deploy separate asset classification
databases).
Within your data classification model, you should include classification for AD DS data such as the following.
Systems
You should not only classify data, but also their server populations. For each server, you should know what
operating system is installed, what general roles the server provides, what applications are running on the server,
the IT owner of record, and the business owner of record, where applicable. For all data or applications running on
the server, you should require classification, and the server should be secured according to the requirements for the
workloads it supports and the classifications applied to the system and data. You can also group servers by the
classification of their workloads, which allows you to quickly identify the servers that should be the most closely
monitored and most stringently configured.
Applications
You should classify applications by functionality (what they do), user base (who uses the applications), and the
operating system on which they run. You should maintain records that contain version information, patch status,
and any other pertinent information. You should also classify applications by the types of data they handle, as
previously described.
Users
Whether you call them "VIP" users, critical accounts, or use a different label, the accounts in your Active Directory
installations that are most likely to be targeted by attackers should be tagged and monitored. In most organizations,
it is simply not feasible to monitor all of the activities of all users. However, if you are able to identify the critical
accounts in your Active Directory installation, you can monitor those accounts for changes as described earlier in
this document.
You can also begin to build a database of "expected behaviors" for these accounts as you audit the accounts. For
example, if you find that a given executive uses his secured workstation to access business-critical data from his
office and from his home, but rarely from other locations, if you see attempts to access data by using his account
from an unauthorized computer or a location halfway around the planet where you know the executive is not
currently located, you can more quickly identify and investigate this anomalous behavior.
By integrating business information with your infrastructure, you can use that business information to help you
identify false positives. For example, if executive travel is recorded in a calendar that is accessible to IT staff
responsible for monitoring the environment, you can correlate connection attempts with the executives' known
locations.
Let's say Executive A is normally located in Chicago and uses a secured workstation to access business-critical data
from his desk, and an event is triggered by a failed attempt to access the data from an unsecured workstation
located in Atlanta. If you are able to verify that the executive is currently in Atlanta, you can resolve the event by
contacting the executive or the executive's assistant to determine if the access failure was the result of the executive
forgetting to use the secured workstation to access the data. By constructing a program that uses the approaches
described in Planning for Compromise, you can begin to build a database of expected behaviors for the most
"important" accounts in your Active Directory installation that can potentially help you more quickly discover and
respond to attacks.
Appendices
Appendices are included in this document to augment the information contained in the body of the document. The
list of appendices and a brief description of each in included the following table.
APPENDIX DESCRIPTION
Appendix B: Privileged Accounts and Groups in Active Provides background information that helps you to identify
Directory the users and groups you should focus on securing because
they can be leveraged by attackers to compromise and even
destroy your Active Directory installation.
Appendix C: Protected Accounts and Groups in Active Contains information about protected groups in Active
Directory Directory. It also contains information for limited
customization (removal) of groups that are considered
protected groups and are affected by AdminSDHolder and
SDProp.
Appendix D: Securing Built-In Administrator Accounts in Active Contains guidelines to help secure the Administrator account
Appendix E: Securing Enterprise Admins Groups in Active Contains guidelines to help secure the Enterprise Admins
Directory group in the forest.
Appendix F: Securing Domain Admins Groups in Active Contains guidelines to help secure the Domain Admins group
Appendix G: Securing Administrators Groups in Active Contains guidelines to help secure the Built-in Administrators
Directory group in each domain in the forest.
Appendix H: Securing Local Administrator Accounts and Contains guidelines to help secure local Administrator
Groups accounts and Administrators groups on domain-joined servers
and workstations.
Appendix I: Creating Management Accounts for Protected Provides information to create accounts that have limited
Accounts and Groups in Active Directory privileges and can be stringently controlled, but can be used to
populate privileged groups in Active Directory when
temporary elevation is required.
Appendix L: Events to Monitor Lists events for which you should monitor in your
environment.
Appendix M: Document Links and Recommended Reading Contains a list of recommended reading. Also contains a list of
links to external documents and their URLs so that readers of
hard copies of this document can access this information.
Appendix B: Privileged Accounts and Groups in Active
Directory

"Privileged" accounts and groups in Active Directory are those to which powerful rights, privileges, and permissions
are granted that allow them to perform nearly any action in Active Directory and on domain-joined systems. This
appendix begins by discussing rights, privileges, and permissions, followed by information about the "highest
privilege" accounts and groups in Active Directory,that is, the most powerful accounts and groups.
Information is also provided about built-in and default accounts and groups in Active Directory, in addition to their
rights. Although specific configuration recommendations for securing the highest privilege accounts and groups
are provided as separate appendices, this appendix provides background information that helps you identify the
users and groups you should focus on securing. You should do so because they can be leveraged by attackers to
compromise and even destroy your Active Directory installation.
Rights, Privileges, and Permissions in Active Directory
The differences between rights, permissions, and privileges can be confusing and contradictory, even within
documentation from Microsoft. This section describes some of the characteristics of each as they are used in this
document. These descriptions should not be considered authoritative for other Microsoft documentation, because it
may use these terms differently.
Rights and Privileges
Rights and privileges are effectively the same system-wide capabilities that are granted to security principals such
as users, services, computers, or groups. In interfaces typically used by IT professionals, these are usually referred
to as "rights" or "user rights," and they are often assigned by Group Policy Objects. The following screenshot shows
some of the most common user rights that can be assigned to security principals (it represents the Default Domain
Controllers GPO in a Windows Server 2012 domain). Some of these rights apply to Active Directory, such as the
Enable computer and user accounts to be trusted for delegation user right, while other rights apply to the
Windows operating system, such as Change the system time.
In interfaces such as the Group Policy Object Editor, all of these assignable capabilities are referred to broadly as
user rights. In reality however, some user rights are programmatically referred to as rights, while others are
programmatically referred to as privileges. Table B -1: User Rights and Privileges provides some of the most
common assignable user rights and their programmatic constants. Although Group Policy and other interfaces
refer to all of these as user rights, some are programmatically identified as rights, while others are defined as
privileges.
For more information about each of the user rights listed in the following table, use the links in the table or see
Threats and Countermeasures Guide: User Rights in the Threats and Vulnerabilities Mitigation guide for Windows
Server 2008 R2 on the Microsoft TechNet site. For information applicable to Windows Server 2008, please see
User Rights in the Threats and Vulnerabilities Mitigation documentation on the Microsoft TechNet site. As of the
writing of this document, corresponding documentation for Windows Server 2012 is not yet published.
NOTE
For the purposes of this document, the terms "rights" and "user rights" are used to identify rights and privileges unless
otherwise specified.
Ta b l e B - 1 : U se r R i g h t s a n d P r i v i l e g e s
User Right in Group Policy Name of Constant
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 Terminal 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 Terminal 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
Permissions
Permissions are access controls that are applied to securable objects such as the file system, registry, service, and
Active Directory objects. Each securable object has an associated access control list (ACL ), which contains access
control entries (ACEs) that grant or deny security principals (users, services, computers, or groups) the ability to
perform various operations on the object. For example, the ACLs for many objects in Active Directory contain ACEs
that allow Authenticated Users to read general information about the objects, but do not grant them the ability to
read sensitive information or to change the objects. With the exception of each domain's built-in Guest account,
every security principal that logs on and is authenticated by a domain controller in an Active Directory forest or a
trusted forest has the Authenticated Users Security Identifier (SID ) added to its access token by default. Therefore,
whether a user, service, or computer account attempts to read general properties on user objects in a domain, the
read operation is successful.
If a security principal attempts to access an object for which no ACEs are defined and that contain a SID that is
present in the principal's access token, the principal cannot access the object. Moreover, if an ACE in an object's ACL
contains a deny entry for a SID that matches the user's access token, the "deny" ACE will generally override a
conflicting "allow" ACE. For more information about access control in Windows, see Access Control on the MSDN
website.
Within this document, permissions refers to capabilities that are granted or denied to security principals on
securable objects. Whenever there is a conflict between a user right and a permission, the user right generally takes
precedence. For example, if an object in Active Directory has been configured with an ACL that denies
Administrators all read and write access to an object, a user who is a member of the domain's Administrators group
will be unable to view much information about the object. However, because the Administrators group is granted
the user right "Take ownership of files or other objects," the user can simply take ownership of the object in
question, then rewrite the object's ACL to grant Administrators full control of the object.
It is for this reason that this document encourages you to avoid using powerful accounts and groups for day-to-day
administration, rather than trying to restrict the capabilities of the accounts and groups. It is not effectively possible
to stop a determined user who has access to powerful credentials from using those credentials to gain access to any
securable resource.
Built-in Privileged Accounts and Groups
Active Directory is intended to facilitate delegation of administration and the principle of least privilege in assigning
rights and permissions. "Regular" users who have accounts in an Active Directory domain are, by default, able to
read much of what is stored in the directory, but are able to change only a very limited set of data in the directory.
Users who require additional privilege can be granted membership in various privileged groups that are built into
the directory so that they may perform specific tasks related to their roles, but cannot perform tasks that are not
relevant to their duties.
Within Active Directory, there are three built-in groups that comprise the highest privilege groups in the directory:
the Enterprise Admins (EA) group, the Domain Admins (DA) group, and the built-in Administrators (BA) group.
A fourth group, the Schema Admins (SA) group, has privileges that, if abused, can damage or destroy an entire
Active Directory forest, but this group is more restricted in its capabilities than the EA, DA, and BA groups.
In addition to these four groups, there are a number of additional built-in and default accounts and groups in Active
Directory, each of which is granted rights and permissions that allow specific administrative tasks to be performed.
Although this appendix does not provide a thorough discussion of every built-in or default group in Active
Directory, it does provide a table of the groups and accounts that you're most likely to see in your installations.
For example, if you install Microsoft Exchange Server into an Active Directory forest, additional accounts and
groups may be created in the Built-in and Users containers in your domains. This appendix describes only the
groups and accounts that are created in the Built-in and Users containers in Active Directory, based on native roles
and features. Accounts and groups that are created by the installation of enterprise software are not included.
Enterprise Admins
The Enterprise Admins (EA) group is located in the forest root domain, and by default, it is a member of the built-in
Administrators group in every domain in the forest. The Built-in Administrator account in the forest root domain is
the only default member of the EA group. EAs are granted rights and permissions that allow them to affect forest-
wide changes. These are changes that affect all domains in the forest, such as adding or removing domains,
establishing forest trusts, or raising forest functional levels. In a properly designed and implemented delegation
model, EA membership is required only when first constructing the forest or when making certain forest-wide
changes such as establishing an outbound forest trust.
The EA group is located by default in the Users container in the forest root domain, and it is a universal security
group, unless the forest root domain is running in Windows 2000 Server mixed mode, in which case the group is a
global security group. Although some rights are granted directly to the EA group, many of this group's rights are
actually inherited by the EA group because it is a member of the Administrators group in each domain in the forest.
Enterprise Admins have no default rights on workstations or member servers.
Domain Admins
Each domain in a forest has its own Domain Admins (DA) group, which is a member of that domain's built-in
Administrators (BA) group in addition to a member of the local Administrators group on every computer that is
joined to the domain. The only default member of the DA group for a domain is the Built-in Administrator account
for that domain.
DAs are all-powerful within their domains, while EAs have forest-wide privilege. In a properly designed and
implemented delegation model, DA membership should be required only in "break glass" scenarios, which are
situations in which an account with high levels of privilege on every computer in the domain is needed, or when
certain domain wide changes must be made. Although native Active Directory delegation mechanisms do allow
delegation to the extent that it is possible to use DA accounts only in emergency scenarios, constructing an effective
delegation model can be time consuming, and many organizations use third-party applications to expedite the
process.
The DA group is a global security group located in the Users container for the domain. There is one DA group for
each domain in the forest, and the only default member of a DA group is the domain's Built-in Administrator
account. Because a domain's DA group is nested in the domain's BA group and every domain-joined system's local
Administrators group, DAs not only have permissions that are specifically granted to Domain Admins, but they also
inherit all rights and permissions granted to the domain's Administrators group and the local Administrators group
on all systems joined to the domain.
Administrators
The built-in Administrators (BA) group is a domain local group in a domain's Built-in container into which DAs and
EAs are nested, and it is this group that is granted many of the direct rights and permissions in the directory and on
domain controllers. However, the Administrators group for a domain does not have any privileges on member
servers or on workstations. Membership in domain-joined computers' local Administrators group is where local
privilege is granted; and of the groups discussed, only DAs are members of all domain-joined computers' local
Administrators groups by default.
The Administrators group is a domain-local group in the domain's Built-in container. By default, every domain's BA
group contains the local domain's Built-in Administrator account, the local domain's DA group, and the forest root
domain's EA group. Many user rights in Active Directory and on domain controllers are granted specifically to the
Administrators group, not to EAs or DAs. A domain's BA group is granted full control permissions on most
directory objects, and can take ownership of directory objects. Although EA and DA groups are granted certain
object-specific permissions in the forest and domains, much of the power of groups is actually "inherited" from
their membership in BA groups.
NOTE
Although these are the default configurations of these privileged groups, a member of any one of the three groups can
manipulate the directory to gain membership in any of the other groups. In some cases, it is trivial to achieve, while in others
it is more difficult, but from the perspective of potential privilege, all three groups should be considered effectively equivalent.
Schema Admins
The Schema Admins (SA) group is a universal group in the forest root domain and has only that domain's Built-in
Administrator account as a default member, similar to the EA group. Although membership in the SA group can
allow an attacker to compromise the Active Directory schema, which is the framework for the entire Active
Directory forest, SAs have few default rights and permissions beyond the schema.
You should carefully manage and monitor membership in the SA group, but in some respects, this group is "less
privileged" than the three highest privileged groups described earlier because the scope of its privilege is very
narrow; that is, SAs have no administrative rights anywhere other than the schema.
Additional Built-in and Default Groups in Active Directory
To facilitate delegating administration in the directory, Active Directory ships with various built-in and default
groups that have been granted specific rights and permissions. These groups are described briefly in the following
table.
The following table lists the built-in and default groups in Active Directory. Both sets of groups exist by default;
however, built-in groups are located (by default) in the Built-in container in Active Directory, while default groups
are located (by default) in the Users container in Active Directory. Groups in the Built-in container are all Domain
Local groups, while groups in the Users container are a mixture of Domain Local, Global, and Universal groups, in
addition to three individual user accounts (Administrator, Guest, and Krbtgt).
In addition to the highest privileged groups described earlier in this appendix, some built-in and default accounts
and groups are granted elevated privileges and should also be protected and used only on secure administrative
hosts. These groups and accounts can be found in the shaded rows in Table B -1: Built-in and Default Groups and
Accounts in Active Directory. Because some of these groups and accounts are granted rights and permissions that
can be misused to compromise Active Directory or domain controllers, they are afforded additional protections as
described in Appendix C: Protected Accounts and Groups in Active Directory.
Ta b l e B - 1 : B u i l t - i n a n d D e fa u l t A c c o u n t s a n d G r o u p s i n A c t i v e D i r e c t o r y
Account or Group Default Container, Group Scope and Description and Default User Rights
Type
Access Control Assistance Operators Built-in container Members of this group can remotely
(Active Directory in Windows Server query authorization attributes and
2012) Domain-local security group permissions for resources on this
computer.
Direct user rights: None
Inherited user rights:
Add workstations to domain
Bypass traverse checking
Increase a process working set

Account Operators Built-in container Members can administer domain user
and group accounts.
Domain-local security group
Administrator account Users container Built-in account for administering the

domain.
Not a group
Adjust memory quotas for a process
Allow log on through Remote Desktop

Services
Back up files and directories
Change the system time
Change the time zone
Create a pagefile
Create global objects
Create symbolic links
Debug programs
Enable computer and user accounts to

be trusted for delegation
Force shutdown from a remote system
Impersonate a client after

authentication
Increase scheduling priority
Load and unload device drivers

Log on as a batch job
Manage auditing and security log
Modify firmware environment values
Perform volume maintenance tasks
Profile single process
Profile system performance
Remove computer from docking station
Restore files and directories
Shut down the system
Take ownership of files or other objects

Administrators group Built-in container Administrators have complete and
unrestricted access to the domain.
Direct user rights:

Services
Create a pagefile
Debug programs


authentication


Allowed RODC Password Replication Users container Members in this group can have their
Group passwords replicated to all read-only
Domain-local security group domain controllers in the domain.

Backup Operators Built-in container Backup Operators can override security
restrictions for the sole purpose of
Domain-local security group backing up or restoring files.
Direct user rights:
Cert Publishers Users container Members of this group are permitted to

publish certificates to the directory.
Certificate Service DCOM Access Built-in container If Certificate Services is installed on a

domain controller (not recommended),
Domain-local security group this group grants DCOM enrollment
access to Domain Users and Domain
Computers.

Cloneable Domain Controllers (AD DS in Users container Members of this group that are domain
Windows Server 2012AD DS) controllers may be cloned.
Global security group
Cryptographic Operators Built-in container Members are authorized to perform

cryptographic operations.
Debugger Users This is neither a default nor a built-in The presence of a Debugger Users
group, but when present in AD DS, is group indicates that debugging tools
cause for further investigation. have been installed on the system at
some point, whether via Visual Studio,
SQL, Office, or other applications that
require and support a debugging
environment. This group allows remote
debugging access to computers. When
this group exists at the domain level, it
indicates that a debugger or an
application that contains a debugger
has been installed on a domain
controller.
Denied RODC Password Replication Users container Members in this group cannot have
Group their passwords replicated to any read-
Domain-local security group only domain controllers in the domain.

DHCP Administrators Users container Members of this group have
administrative access to the DHCP
Domain-local security group Server service.
DHCP Users Users container Members of this group have view-only

access to the DHCP Server service.
Distributed COM Users Built-in container Members of this group are allowed to
launch, activate, and use distributed
Domain-local security group COM objects on this computer.

DnsAdmins Users container Members of this group have
administrative access to the DNS Server
Domain-local security group service.
DnsUpdateProxy Users container Members of this group are DNS clients

who are permitted to perform dynamic
Global security group updates on behalf of clients that cannot
themselves perform dynamic updates.
Members of this group are typically
DHCP servers.
Domain Admins Users container Designated administrators of the

domain; Domain Admins is a member of
Global security group every domain-joined computer's local
Administrators group and receives
rights and permissions granted to the
local Administrators group, in addition
to the domain's Administrators group.

Services

Create a pagefile
Debug programs


authentication
Domain Computers Users container All workstations and servers that are
joined to the domain are by default
Global security group members of this group.
Default direct user rights: None

Domain Controllers Users container All domain controllers in the domain.
Note: Domain controllers are not a
Global security group member of the Domain Computers
group.
Domain Guests Users container All guests in the domain
Global security group Direct user rights: None
Domain Users Users container All users in the domain
Global security group Direct user rights: None
Enterprise Admins (exists only in forest Users container Enterprise Admins have permissions to
root domain) change forest-wide configuration
Universal security group settings; Enterprise Admins is a member
of every domain's Administrators group
and receives rights and permissions
granted to that group.


Services
Create a pagefile
Debug programs


authentication

Enterprise Read-only Domain Users container This group contains the accounts for all
Controllers read-only domain controllers in the
Universal security group forest.
Event Log Readers Built-in container Members of this group in can read the
event logs on domain controllers.
Group Policy Creator Owners Users container Members of this group can create and
modify Group Policy Objects in the
Global security group domain.

Guest Users container This is the only account in an AD DS
domain that does not have the
Not a group Authenticated Users SID added to its
access token. Therefore, any resources
that are configured to grant access to
the Authenticated Users group will not
be accessible to this account. This
behavior is not true of members of the
Domain Guests and Guests groups,
however- members of those groups do
have the Authenticated Users SID
added to their access tokens.
Guests Built-in container Guests have the same access as

members of the Users group by default,
Domain-local security group except for the Guest account, which is
further restricted as described earlier.
Hyper-V Administrators (Windows Built-in container Members of this group have complete
Server 2012) and unrestricted access to all features of
Domain-local security group Hyper-V.

IIS_IUSRS Built-in container Built-in group used by Internet
Information Services.
Incoming Forest Trust Builders (exists Built-in container Members of this group can create
only in forest root domain) incoming, one-way trusts to this forest.
Domain-local security group (Creation of outbound forest trusts is
reserved for Enterprise Admins.)
Krbtgt Users container The Krbtgt account is the service

account for the Kerberos Key
Not a group Distribution Center in the domain. This
account has access to all accounts'
credentials stored in Active Directory.
This account is disabled by default and
should never be enabled
User rights: N/A
Network Configuration Operators Built-in container Members of this group are granted
privileges that allow them to manage
Domain-local security group configuration of networking features.

Performance Log Users Built-in container Members of this group can schedule
logging of performance counters, enable
Domain-local security group trace providers, and collect event traces
locally and via remote access to the
computer.
Direct user rights:
Performance Monitor Users Built-in container Members of this group can access
performance counter data locally and
Domain-local security group remotely.
Pre-Windows 2000 Compatible Access Built-in container This group exists for backward
compatibility with operating systems
Domain-local security group prior to Windows 2000 Server, and it
provides the ability for members to read
user and group information in the
domain.
Direct user rights:

Print Operators Built-in container Members of this group can administer
domain printers.
Direct user rights:
RAS and IAS Servers Users container Servers in this group can read remote
access properties on user accounts in
Domain-local security group the domain.
RDS Endpoint Servers (Windows Server Built-in container Servers in this group run virtual
2012) machines and host sessions where users
Domain-local security group RemoteApp programs and personal
virtual desktops run. This group needs
to be populated on servers running RD
Connection Broker. RD Session Host
servers and RD Virtualization Host
servers used in the deployment need to
be in this group.

RDS Management Servers (Windows Built-in container Servers in this group can perform
Server 2012) routine administrative actions on
Domain-local security group servers running Remote Desktop
Services. This group needs to be
populated on all servers in a Remote
Desktop Services deployment. The
servers running the RDS Central
Management service must be included
in this group.
RDS Remote Access Servers (Windows Built-in container Servers in this group enable users of
Server 2012) RemoteApp programs and personal
Domain-local security group virtual desktops access to these
resources. In Internet-facing
deployments, these servers are typically
deployed in an edge network. This
group needs to be populated on servers
running RD Connection Broker. RD
Gateway servers and RD Web Access
servers used in the deployment need to
be in this group.
Read-only Domain Controllers Users container This group contains all read-only
domain controllers in the domain.
Global security group

Remote Desktop Services Users Built-in container Members of this group are granted the
right to log on remotely using RDP.
Remote Management Servers (Windows Built-in container Members of this group can access WMI
Server 2012) resources over management protocols
Domain-local security group (such as WS-Management via the
Windows Remote Management service).
This applies only to WMI namespaces
that grant access to the user.
Replicator Built-in container Supports legacy file replication in a

domain.

Schema Admins (exists only in forest Users container Schema admins are the only users who
root domain) can make modifications to the Active
Universal security group Directory schema, and only if the
schema is write-enabled.
Server Operators Built-in container Members of this group can administer

domain servers.
Direct user rights:

Terminal Server License Servers Built-in container Members of this group can update user
accounts in Active Directory with
Domain-local security group information about license issuance, for
the purpose of tracking and reporting
TS Per User CAL usage
Default direct user rights: None
Users Built-in container Users have permissions that allow them

to read many objects and attributes in
Domain-local security group Active Directory, although they cannot
change most. Users are prevented from
making accidental or intentional
system-wide changes and can run most
applications.
Direct user rights:
Windows Authorization Access Group Built-in container Members of this group have access to
the computed
Domain-local security group tokenGroupsGlobalAndUniversal
attribute on User objects

WinRMRemoteWMIUsers_ (Windows Users container Members of this group can access WMI
Server 2012) resources over management protocols
Domain-local security group (such as WS-Management via the
Windows Remote Management service).
This applies only to WMI namespaces
that grant access to the user.

Appendix C: Protected Accounts and Groups in Active
Directory

Within Active Directory, a default set of highly privileged accounts and groups are considered protected accounts
and groups. With most objects in Active Directory, delegated administrators (users who have been delegated
permissions to manage Active Directory objects) can change permissions on the objects, including changing
permissions to allow themselves to change memberships of the groups, for example.
However, with protected accounts and groups, the objects' permissions are set and enforced via an automatic
process that ensures the permissions on the objects remains consistent even if the objects are moved the directory.
Even if somebody manually changes a protected object's permissions, this process ensures that permissions are
returned to their defaults quickly.
Protected Groups
The following table contains the protected groups in Active Directory listed by domain controller operating system.
Protected Accounts and Groups in Active Directory by Operating System
WINDOWS SERVER 2012,

WINDOWS SERVER 2008 R2,
WINDOWS SERVER 2003 RTM WINDOWS SERVER 2003 SP1+ WINDOWS SERVER 2008 WINDOWS SERVER 2016
Account Operators Account Operators Account Operators Account Operators
Administrator Administrator Administrator Administrator
Administrators Administrators Administrators Administrators
Backup Operators Backup Operators Backup Operators Backup Operators
Cert Publishers
Domain Admins Domain Admins Domain Admins Domain Admins
Domain Controllers Domain Controllers Domain Controllers Domain Controllers
Enterprise Admins Enterprise Admins Enterprise Admins Enterprise Admins
Enterprise Key Admins
Key Admins
Krbtgt Krbtgt Krbtgt Krbtgt
Print Operators Print Operators Print Operators Print Operators

WINDOWS SERVER 2012,
WINDOWS SERVER 2008 R2,
WINDOWS SERVER 2003 RTM WINDOWS SERVER 2003 SP1+ WINDOWS SERVER 2008 WINDOWS SERVER 2016
Read-only Domain Read-only Domain

Controllers Controllers
Replicator Replicator Replicator Replicator
Schema Admins Schema Admins Schema Admins Schema Admins
Server Operators Server Operators Server Operators Server Operators
AdminSDHolder
The purpose of the AdminSDHolder object is to provide "template" permissions for the protected accounts and
groups in the domain. AdminSDHolder is automatically created as an object in the System container of every
Active Directory domain. Its path is: CN=AdminSDHolder,CN=System,DC=<domain_component>,DC=
<domain_component>?.
Unlike most objects in the Active Directory domain, which are owned by the Administrators group,
AdminSDHolder is owned by the Domain Admins group. By default, EAs can make changes to any domain's
AdminSDHolder object, as can the domain's Domain Admins and Administrators groups. Additionally, although
the default owner of AdminSDHolder is the domain's Domain Admins group, members of Administrators or
Enterprise Admins can take ownership of the object.
SDProp
SDProp is a process that runs every 60 minutes (by default) on the domain controller that holds the domain's PDC
Emulator (PDCE ). SDProp compares the permissions on the domain's AdminSDHolder object with the permissions
on the protected accounts and groups in the domain. If the permissions on any of the protected accounts and
groups do not match the permissions on the AdminSDHolder object, the permissions on the protected accounts
and groups are reset to match those of the domain's AdminSDHolder object.
Additionally, permissions inheritance is disabled on protected groups and accounts, which means that even if the
accounts and groups are moved to different locations in the directory, they do not inherit permissions from their
new parent objects. Inheritance is disabled on the AdminSDHolder object so that permission changes to the parent
objects do not change the permissions of AdminSDHolder.
C h a n g i n g SD P r o p I n t e r v a l
Normally, you should not need to change the interval at which SDProp runs, except for testing purposes. If you
need to change the SDProp interval, on the PDCE for the domain, use regedit to add or modify the
AdminSDProtectFrequency DWORD value in HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
The range of values is in seconds from 60 to 7200 (one minute to two hours). To reverse the changes, delete
AdminSDProtectFrequency key, which will cause SDProp to revert back to the 60 minute interval. You generally
should not reduce this interval in production domains as it can increase LSASS processing overhead on the
domain controller. The impact of this increase is dependent on the number of protected objects in the domain.
R u n n i n g SD P r o p M a n u a l l y
A better approach to testing AdminSDHolder changes is to run SDProp manually, which causes the task to run
immediately but does not affect scheduled execution. Running SDProp manually is performed slightly differently
on domain controllers running Windows Server 2008 and earlier than it is on domain controllers running Windows
Server 2012 or Windows Server 2008 R2.
Procedures for running SDProp manually on older operating systems are provided in Microsoft Support article
251343, and following are step-by-step instructions for older and newer operating systems. In either case, you
must connect to the rootDSE object in Active Directory and perform a modify operation with a null DN for the
rootDSE object, specifying the name of the operation as the attribute to modify. For more information about
modifiable operations on the rootDSE object, see rootDSE Modify Operations on the MSDN website.
R u n n i n g SDP ro p M a n u a l l y i n W i n d o w s Se rv e r 2008 o r E a rl i e r
You can force SDProp to run by using Ldp.exe or by running an LDAP modification script. To run SDProp using
Ldp.exe, perform the following steps after you have made changes to the AdminSDHolder object in a domain:
1. Launch Ldp.exe.
2. Click Connection on the Ldp dialog box, and click Connect.
3. In the Connect dialog box, type the name of the domain controller for the domain that holds the PDC
Emulator (PDCE ) role and click OK.
4. Verify that you have connected successfully, as indicated by Dn: (RootDSE ) in the following screenshot,
click Connection and click Bind.
5. In the Bind dialog box, type the credentials of a user account that has permission to modify the rootDSE
object. (If you are logged on as that user, you can select Bind as currently logged on user.) Click OK.
6. After you have completed the bind operation, click Browse, and click Modify.
7. In the Modify dialog box, leave the DN field blank. In the Edit Entry Attribute field, type
FixUpInheritance, and in the Values field, type Yes. Click Enter to populate the Entry List as shown in the
following screen shot.
8. In the populated Modify dialog box, click Run, and verify that the changes you made to the AdminSDHolder
object have appeared on that object.
NOTE
For information about modifying AdminSDHolder to allow designated unprivileged accounts to modify the membership of
protected groups, see Appendix I: Creating Management Accounts for Protected Accounts and Groups in Active Directory.
If you prefer to run SDProp manually via LDIFDE or a script, you can create a modify entry as shown here:
R u n n i n g SDP ro p M a n u a l l y i n W i n d o w s Se rv e r 2012 o r W i n d o w s Se rv e r 2008 R 2
You can also force SDProp to run by using Ldp.exe or by running an LDAP modification script. To run SDProp
using Ldp.exe, perform the following steps after you have made changes to the AdminSDHolder object in a
domain:
1. Launch Ldp.exe.
2. In the Ldp dialog box, click Connection, and click Connect.
3. In the Connect dialog box, type the name of the domain controller for the domain that holds the PDC
Emulator (PDCE ) role and click OK.
4. Verify that you have connected successfully, as indicated by Dn: (RootDSE ) in the following screenshot,
click Connection and click Bind.
5. In the Bind dialog box, type the credentials of a user account that has permission to modify the rootDSE
object. (If you are logged on as that user, you can select Bind as currently logged on user.) Click OK.
6. After you have completed the bind operation, click Browse, and click Modify.
7. In the Modify dialog box, leave the DN field blank. In the Edit Entry Attribute field, type
RunProtectAdminGroupsTask, and in the Values field, type 1. Click Enter to populate the entry list as
shown here.
8. In the populated Modify dialog box, click Run, and verify that the changes you made to the
AdminSDHolder object have appeared on that object.
If you prefer to run SDProp manually via LDIFDE or a script, you can create a modify entry as shown here:
Appendix D: Securing Built-In Administrator Accounts
in Active Directory
Appendix D: Securing Built-In Administrator Accounts in Active

Directory
In each domain in Active Directory, an Administrator account is created as part of the creation of the domain. This
account is by default a member of the Domain Admins and Administrators groups in the domain, and if the domain
is the forest root domain, the account is also a member of the Enterprise Admins group.
Use of a domain's Administrator account should be reserved only for initial build activities, and possibly, disaster-
recovery scenarios. To ensure that an Administrator account can be used to effect repairs in the event that no other
accounts can be used, you should not change the default membership of the Administrator account in any domain
in the forest. Instead, you should secure the Administrator account in each domain in the forest as described in the
following section and detailed in the step-by-step instructions that follow.
NOTE
This guide used to recommend disabling the account. This was removed as the forest recovery white paper makes use of the
default administrator account. The reason is, this is the only account that allows logon without a Global Catalog Server.
Controls for Built-in Administrator Accounts

For the built-in Administrator account in each domain in your forest, you should configure the following settings:
Enable the Account is sensitive and cannot be delegated flag on the account.
Enable the Smart card is required for interactive logon flag on the account.
Configure GPOs to restrict the Administrator account's use on domain-joined systems:
In one or more GPOs that you create and link to workstation and member server OUs in each
domain, add each domain's Administrator account to the following user rights in Computer
Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights
Assignments:
NOTE
When you add accounts to this setting, you must specify whether you are configuring local Administrator accounts or domain
Administrator accounts. For example, to add the NWTRADERS domain's Administrator account to these deny rights, you must
type the account as NWTRADERS\Administrator, or browse to the Administrator account for the NWTRADERS domain. If you
type "Administrator" in these user rights settings in the Group Policy Object Editor, you will restrict the local Administrator
account on each computer to which the GPO is applied.
We recommend restricting local Administrator accounts on member servers and workstations in the same manner as
domain-based Administrator accounts. Therefore, you should generally add the Administrator account for each domain in the
forest and the Administrator account for the local computers to these user rights settings. The following screenshot shows an
example of configuring these user rights to block local Administrator accounts and a domain's Administrator account from
performing logons that should not be needed for these accounts.
Configure GPOs to restrict Administrator accounts on domain controllers

In each domain in the forest, the Default Domain Controllers GPO or a policy linked to the domain
controllers OU should be modified to add each domain's Administrator account to the following user
rights in Computer Configuration\Policies\Windows Settings\Security Settings\Local
Policies\User Rights Assignments:
NOTE
These settings will ensure that the domain's built-in Administrator account cannot be used to connect to a domain controller,
although the account, if enabled, can log on locally to domain controllers. Because this account should only be enabled and
used in disaster-recovery scenarios, it is anticipated that physical access to at least one domain controller will be available, or
that other accounts with permissions to access domain controllers remotely can be used.
Configure Auditing of Administrator Accounts

When you have secured each domain's Administrator account and disabled it, you should configure auditing
to monitor for changes to the account. If the account is enabled, its password is reset, or any other
modifications are made to the account, alerts should be sent to the users or teams responsible for
administration of Active Directory, in addition to incident response teams in your organization.
Step-by-Step Instructions to Secure Built-in Administrator Accounts in Active Directory
1. In Server Manager, click Tools, and click Active Directory Users and Computers.
2. To prevent attacks that leverage delegation to use the account's credentials on other systems, perform the
following steps:
a. Right-click the Administrator account and click Properties.
b. Click the Account tab.
c. Under Account options, select Account is sensitive and cannot be delegated flag as indicated in
the following screenshot, and click OK.
3. To enable the Smart card is required for interactive logon flag on the account, perform the following
steps:
a. Right-click the Administrator account and select Properties.
b. Click the Account tab.
c. Under Account options, select the Smart card is required for interactive logon flag as indicated
in the following screenshot, and click OK.
C o n fi g u r i n g G P O s t o R e st r i c t A d m i n i st r a t o r A c c o u n t s a t t h e D o m a i n - L e v e l
WARNING
This GPO should never be linked at the domain-level because it can make the built-in Administrator account unusable, even
in disaster recovery scenarios.
1. In Server Manager, click Tools, and click Group Policy Management.

2. In the console tree, expand \Domains\, and then Group Policy Objects (where is the name of the forest and
is the name of the domain where you want to create the Group Policy).
3. In the console tree, right-click Group Policy Objects, and click New.
4. In the New GPO dialog box, type , and click OK (where is the name of this GPO ) as indicated in the
following screenshot.
5. In the details pane, right-click , and click Edit.

6. Navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies,
and click User Rights Assignment.
7. Configure the user rights to prevent the Administrator account from accessing members servers and
workstations over the network by doing the following:
a. Double-click Deny access to this computer from the network and select Define these policy
settings.
b. Click Add User or Group and click Browse.
c. Type Administrator, click Check Names, and click OK. Verify that the account is displayed in
\Username format as indicated in the following screenshot.
d. Click OK, and OK again.

8. Configure the user rights to prevent the Administrator account from logging on as a batch job by doing the
following:
a. Double-click Deny log on as a batch job and select Define these policy settings.

9. Configure the user rights to prevent the Administrator account from logging on as a service by doing the
following:
a. Double-click Deny log on as a service and select Define these policy settings.

10. Configure the user rights to prevent the BA account from accessing member servers and workstations via
Remote Desktop Services by doing the following:
a. Double-click Deny log on through Remote Desktop Services and select Define these policy
settings.

11. To exit Group Policy Management Editor, click File, and click Exit.
12. In Group Policy Management, link the GPO to the member server and workstation OUs by doing the
following:
a. Navigate to the \Domains\ (where is the name of the forest and is the name of the domain where you
want to set the Group Policy).
b. Right-click the OU that the GPO will be applied to and click Link an existing GPO.
c. Select the GPO that you created and click OK.
d. Create links to all other OUs that contain workstations.

e. Create links to all other OUs that contain member servers.
IMPORTANT
When you add the Administrator account to these settings, you specify whether you are configuring a local Administrator
account or a domain Administrator account by how you label the accounts. For example, to add the TAILSPINTOYS domain's
Administrator account to these deny rights, you would browse to the Administrator account for the TAILSPINTOYS domain,
which would appear as TAILSPINTOYS\Administrator. If you type "Administrator" in these user rights settings in the Group
Policy Object Editor, you will restrict the local Administrator account on each computer to which the GPO is applied, as
described earlier.
Verification Steps
The verification steps outlined here are specific to Windows 8 and Windows Server 2012.
Ve r i fy " Sm a r t c a r d i s r e q u i r e d fo r i n t e r a c t i v e l o g o n " A c c o u n t O p t i o n
1. From any member server or workstation affected by the GPO changes, attempt to log on interactively to the
domain by using the domain's built-in Administrator account. After attempting to log on, a dialog box similar to
the following should appear.
Ve r i fy " A c c o u n t i s d i sa b l e d " A c c o u n t O p t i o n
1. From any member server or workstation affected by the GPO changes, attempt to log on interactively to the
domain by using the domain's built-in Administrator account. After attempting to log on, a dialog box similar to
the following should appear.
Ve r i fy " D e n y a c c e ss t o t h i s c o m p u t e r fr o m t h e n e t w o r k " G P O Se t t i n g s
From any member server or workstation that is not affected by the GPO changes (such as a jump server), attempt
to access a member server or workstation over the network that is affected by the GPO changes. To verify the GPO
settings, attempt to map the system drive by using the NET USE command by performing the following steps:
1. Log on to the domain using the domain's built-in Administrator account.
2. With the mouse, move the pointer into the upper-right or lower-right corner of the screen. When the
Charms bar appears, click Search.
3. In the Search box, type command prompt, right-click Command Prompt, and then click Run as
administrator to open an elevated command prompt.
4. When prompted to approve the elevation, click Yes.
5. In the Command Prompt window, type net use \\<Server Name>\c$, where <Server Name> is the
name of the member server or workstation you are attempting to access over the network.
6. The following screenshot shows the error message that should appear.
Ve r i fy " D e n y l o g o n a s a b a t c h j o b " G P O Se t t i n g s
From any member server or workstation affected by the GPO changes, log on locally.
C re a t e a B a t c h F i l e
2. In the Search box, type notepad, and click Notepad.
3. In Notepad, type dir c:.
4. Click File and click Save As.
5. In the Filename field, type .bat (where is the name of the new batch file).
Sc h e d u l e a Ta s k
2. In the Search box, type task scheduler, and click Task Scheduler.
NOTE
On computers running Windows 8, in the Search box, type schedule tasks, and click Schedule tasks.
3. On Task Scheduler, click Action, and click Create Task.

4. In the Create Task dialog box, type (where is the name of the new task).
5. Click the Actions tab, and click New.
6. Under Action:, select Start a program.
7. Under Program/script:, click Browse, locate and select the batch file created in the "Create a Batch File"
section, and click Open.
8. Click OK.
9. Click the General tab.
10. Under Security options, click Change User or Group.
11. Type the name of the BA account at the domain-level, click Check Names, and click OK.
12. Select Run whether the user is logged on or not and Do not store password. The task will only have
access to local computer resources.
13. Click OK.
14. A dialog box should appear, requesting user account credentials to run the task.
15. After entering the credentials, click OK.
16. A dialog box similar to the following should appear.
Ve r i fy " D e n y l o g o n a s a se r v i c e " G P O Se t t i n g s
1. From any member server or workstation affected by the GPO changes, log on locally.
3. In the Search box, type services, and click Services.
4. Locate and double-click Print Spooler.
5. Click the Log On tab.
6. Under Log on as:, select This account.
7. Click Browse, type the name of the BA account at the domain-level, click Check Names, and click OK.
8. Under Password: and Confirm password:, type the Administrator account's password, and click OK.
9. Click OK three more times.
10. Right-click the Print Spooler service and select Restart.
11. When the service is restarted, a dialog box similar to the following should appear.
R e v e r t C h a n g e s t o t h e P r i n t e r Sp o o l e r Se r v i c e
6. Under Log on as:, select the Local System account, and click OK.
Ve r i fy " D e n y l o g o n t h r o u g h R e m o t e D e sk t o p Se r v i c e s" G P O Se t t i n g s
2. In the Search box, type remote desktop connection, and click Remote Desktop Connection.
3. In the Computer field, type the name of the computer that you want to connect to, and click Connect. (You
can also type the IP address instead of the computer name.)
4. When prompted, provide credentials for the name of the BA account at the domain-level.
Appendix E: Securing Enterprise Admins Groups in
Active Directory

The Enterprise Admins (EA) group, which is housed in the forest root domain, should contain no users on a day-to-
day basis, with the possible exception of the root domain's Administrator account, provided it is secured as
described in Appendix D: Securing Built-In Administrator Accounts in Active Directory.
Enterprise Admins are, by default, members of the Administrators group in each domain in the forest. You should
not remove the EA group from the Administrators groups in each domain because in the event of a forest disaster
recovery scenario, EA rights will likely be required. The forest's Enterprise Admins group should be secured as
detailed in the step-by-step instructions that follow.
For the Enterprise Admins group in the forest:
1. In GPOs linked to OUs containing member servers and workstations in each domain, the Enterprise Admins
group should be added to the following user rights in Computer Configuration\Policies\Windows
Deny log on locally
2. Configure auditing to send alerts if any modifications are made to the properties or membership of the
Enterprise Admins group.
Step-by-Step Instructions for Removing All Members from the Enterprise Admins Group
2. If you are not managing the root domain for the forest, in the console tree, right-click , and then click
Change Domain (where is the name of the domain you're currently administering).
3. In the Change domain dialog box, click Browse, select the root domain for the forest, and click OK.
4. To remove all members from the EA group:

a. Double-click the Enterprise Admins group and then click the Members tab.
b. Select a member of the group, click Remove, click Yes, and click OK.
5. Repeat step 2 until all members of the EA group have been removed.
Step-by-Step Instructions to Secure Enterprise Admins in Active Directory
is the name of the domain where you want to set the Group Policy).
NOTE
In a forest that contains multiple domains, a similar GPO should be created in each domain that requires that the
Enterprise Admins group be secured.
4. In the New GPO dialog box, type , and click OK (where is the name of this GPO ).

7. Configure the user rights to prevent members of the Enterprise Admins group from accessing member
servers and workstations over the network by doing the following:
settings.
c. Type Enterprise Admins, click Check Names, and click OK.
8. Configure the user rights to prevent members of the Enterprise Admins group from logging on as a batch
job by doing the following:
NOTE
In a forest that contains multiple domains, click Locations and select the root domain of the forest.

9. Configure the user rights to prevent members of the EA group from logging on as a service by doing the
following:
a. Double-click Deny log as a service and select Define these policy settings.
b. Click Add User or Group and then click Browse.
NOTE

10. Configure user rights to prevent members of the Enterprise Admins group from logging on locally to
member servers and workstations by doing the following:
a. Double-click Deny log on locally and select Define these policy settings.
NOTE

11. Configure the user rights to prevent members of the Enterprise Admins group from accessing member
servers and workstations via Remote Desktop Services by doing the following:
settings.
NOTE

following:
c. Select the GPO that you just created and click OK.

f. In a forest that contains multiple domains, a similar GPO should be created in each domain that
requires that the Enterprise Admins group be secured.
IMPORTANT
If jump servers are used to administer domain controllers and Active Directory, ensure that jump servers are located in an OU
to which this GPOs is not linked.
Verification Steps
Verify "Deny access to this computer from the network" GPO Settings
From any member server or workstation that is not affected by the GPO changes (such as a "jump server"), attempt
settings, attempt to map the system drive by using the NET USE command by performing the following steps:
1. Log on locally using an account that is a member of the EA group.
name of the member server or workstation you're attempting to access over the network.
6. The following screen shot shows the error message that should appear.
Verify "Deny log on as a batch job" GPO Settings

Cr eat e a Bat c h Fi l e
4. Click File, and click Save As.
5. In the File name box, type .bat (where is the name of the new batch file).
Sc h e d u l e a Ta sk
NOTE
3. Click Action, and click Create Task.

6. In the Action field, select Start a program.
7. Under Program/script, click Browse, locate and select the batch file created in the Create a Batch File
8. Click OK.
10. In the Security options field, click Change User or Group.
11. Type the name of an account that is a member of the EAs group, click Check Names, and click OK.
12. Select Run whether the user is logged on or not and select Do not store password. The task will only
have access to local computer resources.
13. Click OK.
Verify "Deny log on as a service" GPO Settings

6. Under Log on as, select This account.
7. Click Browse, type the name of an account that is a member of the EAs group, click Check Names, and click
OK.
8. Under Password: and Confirm password, type the selected account's password, and click OK.
10. Right-click the Print Spooler service and select Restart.
Revert Changes to the Printer Spooler Service

6. Under Log on as, select the Local System account, and click OK.
Verify "Deny log on locally" GPO Settings
1. From any member server or workstation affected by the GPO changes, attempt to log on locally using an
account that is a member of the EA group. A dialog box similar to the following should appear.
Verify "Deny log on through Remote Desktop Services" GPO Settings

2. In the Search box, type remote desktop connection, and then click Remote Desktop Connection.
3. In the Computer field, type the name of the computer that you want to connect to, and then click Connect.
(You can also type the IP address instead of the computer name.)
4. When prompted, provide credentials for an account that is a member of the EA group.
Appendix F: Securing Domain Admins Groups in
Active Directory

As is the case with the Enterprise Admins (EA) group, membership in the Domain Admins (DA) group should be
required only in build or disaster recovery scenarios. There should be no day-to-day user accounts in the DA group
with the exception of the built-in Administrator account for the domain, if it has been secured as described in
Appendix D: Securing Built-In Administrator Accounts in Active Directory.
Domain Admins are, by default, members of the local Administrators groups on all member servers and
workstations in their respective domains. This default nesting should not be modified for supportability and
disaster recovery purposes. If Domain Admins have been removed from the local Administrators groups on the
member servers, the group should be added to the Administrators group on each member server and workstation
in the domain. Each domain's Domain Admins group should be secured as described in the step-by-step
instructions that follow.
For the Domain Admins group in each domain in the forest:
1. Remove all members from the group, with the possible exception of the built-in Administrator account for
the domain, provided it has been secured as described in Appendix D: Securing Built-In Administrator
Accounts in Active Directory.
be added to the following user rights in Computer Configuration\Policies\Windows Settings\Security
Settings\Local Policies\User Rights Assignments:
Deny log on locally
Deny log on through Remote Desktop Services user rights
of the Domain Admins group.
Step-by-Step Instructions for Removing all Members from the Domain Admins Group
2. To remove all members from the DA group, perform the following steps:
a. Double-click the Domain Admins group and click the Members tab.
3. Repeat step 2 until all members of the DA group have been removed.
Step-by-Step Instructions to Secure Domain Admins in Active Directory
2. In the console tree, expand <Forest>\Domains\<Domain>, and then Group Policy Objects (where
<Forest> is the name of the forest and <Domain> is the name of the domain where you want to set the
Group Policy).
4. In the New GPO dialog box, type <GPO Name>, and click OK (where <GPO Name> is the name of this
GPO ).
5. In the details pane, right-click <GPO Name>, and click Edit.

7. Configure the user rights to prevent members of the Domain Admins group from accessing members
servers and workstations over the network by doing the following:
settings.
c. Type Domain Admins, click Check Names, and click OK.

8. Configure the user rights to prevent members of the DA group from logging on as a batch job by doing the
following:

9. Configure the user rights to prevent members of the DA group from logging on as a service by doing the
following:

10. Configure the user rights to prevent members of the Domain Admins group from logging on locally to
member servers and workstations by doing the following:
a. Double-click Deny log on locally and select Define these policy settings.

11. Configure the user rights to prevent members of the Domain Admins group from accessing member
servers and workstations via Remote Desktop Services by doing the following:
settings.

following:
a. Navigate to the <Forest>\Domains\<Domain> (where <Forest> is the name of the forest and
<Domain> is the name of the domain where you want to set the Group Policy).

IMPORTANT
If jump servers are used to administer domain controllers and Active Directory, ensure that jump servers are
located in an OU to which this GPOs is not linked.
Verification Steps
settings, attempt to map the system drive by using the NET USE command.
1. Log on locally using an account that is a member of the Domain Admins group.
5. In the File name field, type <Filename>.bat (where <Filename> is the name of the new batch file).
NOTE
3. In the Task Scheduler menu bar, click Action, and click Create Task.
4. In the Create Task dialog box, type <Task Name> (where <Task Name> is the name of the new task).
7. Under Program/script, click Browse, locate and select the batch file created in the Create a Batch File
8. Click OK.
10. Under Security options, click Change User or Group.
11. Type the name of an account that is a member of the Domain Admins group, click Check Names, and click
OK.
12. Select Run whether the user is logged on or not and select Do not store password. The task will only
have access to local computer resources.
13. Click OK.
6. Under Log on as, select the This account option.
7. Click Browse, type the name of an account that is a member of the Domain Admins group, click Check
Names, and click OK.
8. Under Password and Confirm password, type the selected account's password, and click OK.
10. Right-click Print Spooler and click Restart.
6. Under Log on as, select the Local System account, and click OK.
Ve r i fy " D e n y l o g o n l o c a l l y " G P O Se t t i n g s
1. From any member server or workstation affected by the GPO changes, attempt to log on locally using an
account that is a member of the Domain Admins group. A dialog box similar to the following should appear.
Ve r i fy " D e n y l o g o n t h r o u g h R e m o t e D e sk t o p Se r v i c e s" G P O Se t t i n g s
4. When prompted, provide credentials for an account that is a member of the Domain Admins group.
Appendix G: Securing Administrators Groups in Active
Directory

As is the case with the Enterprise Admins (EA) and Domain Admins (DA) groups, membership in the built-in
Administrators (BA) group should be required only in build or disaster recovery scenarios. There should be no day-
to-day user accounts in the Administrators group with the exception of the Built-in Administrator account for the
domain, if it has been secured as described in Appendix D: Securing Built-In Administrator Accounts in Active
Directory.
Administrators are, by default, the owners of most of the AD DS objects in their respective domains. Membership
in this group may be required in build or disaster recovery scenarios in which ownership or the ability to take
ownership of objects is required. Additionally, DAs and EAs inherit a number of their rights and permissions by
virtue of their default membership in the Administrators group. Default group nesting for privileged groups in
Active Directory should not be modified, and each domain's Administrators group should be secured as described
in the step-by-step instructions that follow.
For the Administrators group in each domain in the forest:
1. Remove all members from the Administrators group, with the possible exception of the built-in
Administrator account for the domain, provided it has been secured as described in Appendix D: Securing
Built-In Administrator Accounts in Active Directory.
be added to the following user rights in Computer Configuration\Policies\Windows Settings\Security
Settings\Local Policies\ User Rights Assignment:
3. At the domain controllers OU in each domain in the forest, the Administrators group should be granted the
following user rights:
Allow log on through Remote Desktop Services
of the Administrators group.
Step-by-Step Instructions for Removing All Members from the Administrators Group
2. To remove all members from the Administrators group, perform the following steps:
a. Double-click the Administrators group and click the Members tab.
3. Repeat step 2 until all members of the Administrators group have been removed.
Step-by-Step Instructions to Secure Administrators Groups in Active Directory
2. In the console tree, expand <Forest>\Domains\<Domain>, and then Group Policy Objects (where
<Forest> is the name of the forest and <Domain> is the name of the domain where you want to set the
Group Policy).
4. In the New GPO dialog box, type , and click OK (where GPO Name is the name of this GPO ).

7. Configure the user rights to prevent members of the Administrators group from accessing member servers
and workstations over the network by doing the following:
settings.
c. Type Administrators, click Check Names, and click OK.

8. Configure the user rights to prevent members of the Administrators group from logging on as a batch job
by doing the following:

9. Configure the user rights to prevent members of the Administrators group from logging on as a service by
doing the following:

following:
a. Navigate to the <Forest>>\Domains\<Domain> (where <Forest> is the name of the forest and
<Domain> is the name of the domain where you want to set the Group Policy).

IMPORTANT
If jump servers are used to administer domain controllers and Active Directory, ensure that jump servers are
located in an OU to which this GPOs is not linked.
NOTE
When you implement restrictions on the Administrators group in GPOs, Windows applies the settings to
members of a computer's local Administrators group in addition to the domain's Administrators group.
Therefore, you should use caution when implementing restrictions in the Administrators group. Although
prohibiting network, batch, and service logons for members of the Administrators group is advised wherever
it is feasible to implement, do not restrict local logons or logons through Remote Desktop Services. Blocking
these logon types can block legitimate administration of a computer by members of the local Administrators
group.
The following screen shot shows configuration settings that block misuse of built-in local and domain
Administrator accounts, in addition to misuse of built-in local or domain Administrators groups. Note that the
Deny log on through Remote Desktop Services user right does not include the Administrators group,
because including it in this setting would also block these logons for accounts that are members of the local
computer's Administrators group. If services on computers are configured to run in the context of any of the
privileged groups described in this section, implementing these settings can cause services and applications to
fail. Therefore, as with all of the recommendations in this section, you should thoroughly test settings for
applicability in your environment.
Step-by-Step Instructions to Grant User Rights to the Administrators Group

7. Configure the user rights to allow members of the Administrators group to access domain controllers over
the network by doing the following:
a. Double-click Access to this computer from the network and select Define these policy settings.
c. Click Add User or Group and click Browse.

8. Configure the user rights to allow members of the Administrators group to log on locally by doing the
following:
a. Double-click Allow log on locally and select Define these policy settings.

9. Configure the user rights to allow members of the Administrators group to log on through Remote Desktop
Services by doing the following:
a. Double-click Allow log on through Remote Desktop Services and select Define these policy
settings.

11. In Group Policy Management, link the GPO to the domain controllers OU by doing the following:
b. Right-click the domain controllers OU and click Link an existing GPO.
Verification Steps
1. Log on locally using an account that is a member of the Administrators group.
5. In the File name field, type .bat (where is the name of the new batch file).
NOTE

7. In the Program/script field, click Browse, locate and select the batch file created in the Create a Batch File
8. Click OK.
11. Type the name of an account that is a member of the Administrators group, click Check Names, and click
OK.
12. Select Run whether the user is logged onor not and Do not store password. The task will only have
13. Click OK.
15. After entering the password, click OK.
6. In the Log on as field, select This account.
7. Click Browse, type the name of an account that is a member of the Administrators group, click Check
Names, and click OK.
8. In the Password and Confirm password fields, type the selected account's password, and click OK.
6. In the Log on as field, click Local System account, and click OK.
Appendix H: Securing Local Administrator Accounts
and Groups

On all versions of Windows currently in mainstream support, the local Administrator account is disabled by default,
which makes the account unusable for pass-the-hash and other credential theft attacks. However, in environments
that contain legacy operating systems or in which local Administrator accounts have been enabled, these accounts
can be used as previously described to propagate compromise across member servers and workstations. Each local
Administrator account and group should be secured as described in the step-by-step instructions that follow.
For detailed information about considerations in securing Built-in Administrator (BA) groups, see Implementing
Least-Privilege Administrative Models.
Controls for Local Administrator Accounts
For the local Administrator account in each domain in your forest, you should configure the following settings:
Configure GPOs to restrict the domain's Administrator account's use on domain-joined systems
In one or more GPOs that you create and link to workstation and member server OUs in each
domain, add the Administrator account to the following user rights in Computer
Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights
Assignments:
Step-by-Step Instructions to Secure Local Administrators Groups
C o n f i g u ri n g G P O s t o R e s t ri c t A d mi n i s t ra t o r A c c o u n t o n Do ma i n -Jo i n e d Sy s t e ms


7. Configure the user rights to prevent the local Administrator account from accessing members servers and
workstations over the network by doing the following:
settings.
b. Click Add User or Group, type the user name of the local Administrator account, and click OK. This
user name will be Administrator, the default when Windows is installed.
c. Click OK.
IMPORTANT
When you add the Administrator account to these settings, you specify whether you are configuring a local
Administrator account or a domain Administrator account by how you label the accounts. For example, to add
the TAILSPINTOYS domain's Administrator account to these deny rights, you would browse to the
Administrator account for the TAILSPINTOYS domain, which would appear as TAILSPINTOYS\Administrator. If
you type Administrator in these user rights settings in the Group Policy Object Editor, you will restrict the
local Administrator account on each computer to which the GPO is applied, as described earlier.
8. Configure the user rights to prevent the local Administrator account from logging on as a batch job by doing
the following:
c. Click OK.
IMPORTANT
When you add the Administrator account to these settings, you specify whether you are configuring local
Administrator account or domain Administrator account by how you label the accounts. For example, to add
9. Configure the user rights to prevent the local Administrator account from logging on as a service by doing
the following:
c. Click OK.
IMPORTANT
10. Configure the user rights to prevent the local Administrator account from accessing member servers and
workstations via Remote Desktop Services by doing the following:
settings.
c. Click OK.
IMPORTANT
following:
c. Select the GPO that you created and click OK.

Verification Steps
From any member server or workstation that is not affected by the GPO changes (such as a jump server), attempt
1. Log on locally to any member server or workstation that is not affected by the GPO changes.
5. In the Command Prompt window, type net use \\\c$ /user:\Administrator, where is the name of the
member server or workstation you're attempting to access over the network.
NOTE
The local Administrator credentials must be from the same system you're attempting to access over the network.
6. The following screenshot shows the error message that should appear.
5. In the File name box, type .bat (where is the name of the new batch file).
NOTE

6. In the Action field, click Start a program.
7. In the Program/script field, click Browse, locate and select the batch file created in the Create a Batch File
8. Click OK.
11. Type the name of the system's local Administrator account, click Check Names, and click OK.
12. Select Run whether the user is logged on or not and Do not store password. The task will only have
13. Click OK.
V e ri f y " De n y l o g o n a s a s e rv i c e " G P O Se t t i n g s
6. In Log on as field, click This account.
7. Click Browse, type the system's local Administrator account, click Check Names, and click OK.
8. In the Password and Confirm password fields, type the selected account's password, and click OK.
R e v e rt C h a n g e s t o t h e P ri n t e r Sp o o l e r Se rv i c e
6. In the Log on as: field, select Local Systemaccount, and click OK.
V e ri f y " De n y l o g o n t h ro u g h R e mo t e De s k t o p Se rv i c e s " G P O Se t t i n g s
4. When prompted, provide credentials for the system's local Administrator account.
Appendix I: Creating Management Accounts for
Protected Accounts and Groups in Active Directory
One of the challenges in implementing an Active Directory model that does not rely on permanent membership in
highly privileged groups is that there must be a mechanism to populate these groups when temporary
membership in the groups is required. Some privileged identity management solutions require that the software's
service accounts are granted permanent membership in groups such as DA or Administrators in each domain in
the forest. However, it is technically not necessary for Privileged Identity Management (PIM ) solutions to run their
services in such highly privileged contexts.
This appendix provides information that you can use for natively implemented or third-party PIM solutions to
create accounts that have limited privileges and can be stringently controlled, but can be used to populate
privileged groups in Active Directory when temporary elevation is required. If you are implementing PIM as a
native solution, these accounts may be used by administrative staff to perform the temporary group population,
and if you're implementing PIM via third-party software, you might be able to adapt these accounts to function as
service accounts.
NOTE
The procedures described in this appendix provide one approach to the management of highly privileged groups in Active
Directory. You can adapt these procedures to suit your needs, add additional restrictions, or omit some of the restrictions that
are described here.
Creating Management Accounts for Protected Accounts and Groups in

Active Directory
Creating accounts that can be used to manage the membership of privileged groups without requiring the
management accounts to be granted excessive rights and permissions consists of four general activities that are
described in the step-by-step instructions that follow:
1. First, you should create a group that will manage the accounts, because these accounts should be managed
by a limited set of trusted users. If you do not already have an OU structure that accommodates segregating
privileged and protected accounts and systems from the general population in the domain, you should
create one. Although specific instructions are not provided in this appendix, screenshots show an example of
such an OU hierarchy.
2. Create the management accounts. These accounts should be created as "regular" user accounts and granted
no user rights beyond those that are already granted to users by default.
3. Implement restrictions on the management accounts that make them usable only for the specialized purpose
for which they were created, in addition to controlling who can enable and use the accounts (the group you
created in the first step).
4. Configure permissions on the AdminSDHolder object in each domain to allow the management accounts to
change the membership of the privileged groups in the domain.
You should thoroughly test all of these procedures and modify them as needed for your environment before
implementing them in a production environment. You should also verify that all settings work as expected (some
testing procedures are provided in this appendix), and you should test a disaster recovery scenario in which the
management accounts are not available to be used to populate protected groups for recovery purposes. For more
information about backing up and restoring Active Directory, see the AD DS Backup and Recovery Step-by-Step
Guide.
NOTE
By implementing the steps described in this appendix, you will create accounts that will be able to manage the membership of
all protected groups in each domain, not only the highest-privilege Active Directory groups like EAs, DAs and BAs. For more
information about protected groups in Active Directory, see Appendix C: Protected Accounts and Groups in Active Directory.
Step-by-Step Instructions for Creating Management Accounts for Protected Groups

Creating a Group to Enable and Disable Management Accounts
Management accounts should have their passwords reset at each use and should be disabled when activities
requiring them are complete. Although you might also consider implementing smart card logon requirements for
these accounts, it is an optional configuration and these instructions assume that the management accounts will be
configured with a user name and long, complex password as minimum controls. In this step, you will create a group
that has permissions to reset password on the management accounts and to enable and disable the accounts.
To create a group to enable and disable management accounts, perform the following steps:
1. In the OU structure where you will be housing the management accounts, right-click the OU where you
want to create the group, click New and click Group.
2. In the New Object - Group dialog box, enter a name for the group. If you plan to use this group to
"activate" all management accounts in your forest, make it a universal security group. If you have a single-
domain forest or if you plan to create a group in each domain, you can create a global security group. Click
OK to create the group.
3. Right-click the group you just created, click Properties, and click the Object tab. In the group's Object
property dialog box, select Protect object from accidental deletion, which will not only prevent
otherwise-authorized users from deleting the group, but also from moving it to another OU unless the
attribute is first deselected.
NOTE
If you have already configured permissions on the group's parent OUs to restrict administration to a limited set of
users, you may not need to perform the following steps. They are provided here so that even if you have not yet
implemented limited administrative control over the OU structure in which you've created this group, you can secure
the group against modification by unauthorized users.
4. Click the Members tab, and add the accounts for members of your team who will be responsible for
enabling management accounts or populating protected groups when necessary.
5. If you have not already done so, in the Active Directory Users and Computers console, click View and
select Advanced Features. Right-click the group you just created, click Properties, and click the Security
tab. On the Security tab, click Advanced.
6. In the Advanced Security Settings for [Group] dialog box, click Disable Inheritance. When prompted,
click Convert inherited permissions into explicit permissions on this object, and click OK to return to
the group's Security dialog box.
7. On the Security tab, remove groups that should not be permitted to access this group. For example, if you
do not want Authenticated Users to be able to read the group's name and general properties, you can
remove that ACE. You can also remove ACEs, such as those for account operators and pre-Windows 2000
Server compatible access. You should, however, leave a minimum set of object permissions in place. Leave
the following ACEs intact:
SELF
SYSTEM
Domain Admins
Enterprise Admins
Administrators
Windows Authorization Access Group (if applicable)
ENTERPRISE DOMAIN CONTROLLERS
Although it may seem counterintuitive to allow the highest privileged groups in Active Directory to manage
this group, your goal in implementing these settings is not to prevent members of those groups from
making authorized changes. Rather, the goal is to ensure that when you have occasion to require very high
levels of privilege, authorized changes will succeed. It is for this reason that changing default privileged
group nesting, rights, and permissions are discouraged throughout this document. By leaving default
structures intact and emptying the membership of the highest privilege groups in the directory, you can
create a more secure environment that still functions as expected.
NOTE
If you have not already configured audit policies for the objects in the OU structure where you created this group, you
should configure auditing to log changes this group.
8. You have completed configuration of the group that will be used to "check out" management accounts when
they are needed and "check in" the accounts when their activities have been completed.
Creating the Management Accounts
You should create at least one account that will be used to manage the membership of privileged groups in your
Active Directory installation, and preferably a second account to serve as a backup. Whether you choose to create
the management accounts in a single domain in the forest and grant them management capabilities for all
domains' protected groups, or whether you choose to implement management accounts in each domain in the
forest, the procedures are effectively the same.
NOTE
The steps in this document assume that you have not yet implemented role-based access controls and privileged identity
management for Active Directory. Therefore, some procedures must be performed by a user whose account is a member of
the Domain Admins group for the domain in question.
When you are using an account with DA privileges, you can log on to a domain controller to perform the configuration
activities. Steps that do not require DA privileges can be performed by less-privileged accounts that are logged on to
administrative workstations. Screen shots that show dialog boxes bordered in the lighter blue color represent activities that
can be performed on a domain controller. Screen shots that show dialog boxes in the darker blue color represent activities
that can be performed on administrative workstations with accounts that have limited privileges.
To create the management accounts, perform the following steps:

1. Log on to a domain controller with an account that is a member of the domain's DA group.
2. Launch Active Directory Users and Computers and navigate to the OU where you will be creating the
management account.
3. Right-click the OU and click New and click User.
4. In the New Object - User dialog box, enter your desired naming information for the account and click
Next.
5. Provide an initial password for the user account, clear User must change password at next logon, select
User cannot change password and Account is disabled, and click Next.
6. Verify that the account details are correct and click Finish.
7. Right-click the user object you just created and click Properties.
8. Click the Account tab.
9. In the Account Options field, select the Account is sensitive and cannot be delegated flag, select the
This account supports Kerberos AES 128 bit encryption and/or the This account supports Kerberos
AES 256 encryption flag, and click OK.
NOTE
Because this account, like other accounts, will have a limited, but powerful function, the account should only be used
on secure administrative hosts. For all secure administrative hosts in your environment, you should consider
implementing the Group Policy setting Network Security: Configure Encryption types allowed for Kerberos to
allow only the most secure encryption types you can implement for secure hosts.
Although implementing more secure encryption types for the hosts does not mitigate credential theft attacks, the
appropriate use and configuration of the secure hosts does. Setting stronger encryption types for hosts that are only
used by privileged accounts simply reduces the overall attack surface of the computers.
For more information about configuring encryption types on systems and accounts, see Windows Configurations for
Kerberos Supported Encryption Type.
These settings are supported only on computers running Windows Server 2012, Windows Server 2008 R2, Windows
8, or Windows 7.
10. On the Object tab, select Protect object from accidental deletion. This will not only prevent the object
from being deleted (even by authorized users), but will prevent it from being moved to a different OU in
your AD DS hierarchy, unless the check box is first cleared by a user with permission to change the attribute.
11. Click the Remote control tab.
12. Clear the Enable remote control flag. It should never be necessary for support staff to connect to this
account's sessions to implement fixes.
NOTE
Every object in Active Directory should have a designated IT owner and a designated business owner, as described in
Planning for Compromise. If you are tracking ownership of AD DS objects in Active Directory (as opposed to an
external database), you should enter appropriate ownership information in this object's properties.
In this case, the business owner is most likely an IT division, andthere is no prohibition on business owners also being
IT owners. The point of establishing ownership of objects is to allow you to identify contacts when changes need to be
made to the objects, perhaps years from their initial creation.
13. Click on the Organization tab.

14. Enter any information that is required in your AD DS object standards.
15. Click on the Dial-in tab.
16. In the Network Access Permission field, select Deny access.This account should never need to connect
over a remote connection.
NOTE
It is unlikely that this account will be used to log on to read-only domain controllers (RODCs) in your environment.
However, should circumstance ever require the account to log on to an RODC, you should add this account to the
Denied RODC Password Replication Group so that its password is not cached on the RODC.
Although the account's password should be reset after each use and the account should be disabled, implementing
this setting does not have a deleterious effect on the account, and it might help in situations in which an
administrator forgets to reset the account's password and disable it.
17. Click the Member Of tab.

18. Click Add.
19. Type Denied RODC Password Replication Group in the Select Users, Contacts, Computers dialog box
and click Check Names. When the name of the group is underlined in the object picker, click OK and verify
that the account is now a member of the two groups displayed in the following screenshot. Do not add the
account to any protected groups.
20. Click OK.
21. Click the Security tab and click Advanced.

22. In the Advanced Security Settings dialog box, click Disable inheritance and copy the inherited
permissions as explicit permissions, and click Add.
23. In the Permission Entry for [Account] dialog box, click Select a principal and add the group you created
in the previous procedure. Scroll to the bottom of the dialog box and click Clear all to remove all default
permissions.
24. Scroll to the top of the Permission Entry dialog box. Ensure that the Type drop-down list is set to Allow,
and in the Applies to drop-down list, select This object only.
25. In the Permissions field, select Read all properties, Read permissions, and Reset password.
26. In the Properties field, select Read userAccountControl and Write userAccountControl.
27. Click OK, OK again in the Advanced Security Settings dialog box.
NOTE
The userAccountControl attribute controls multiple account configuration options. You cannot grant permission to
change only some of the configuration options when you grant write permission to the attribute.
28. In the Group or user names field of the Security tab, remove any groups that should not be permitted to
access or manage the account. Do not remove any groups that have been configured with Deny ACEs, such
as the Everyone group and the SELF computed account (that ACE was set when the user cannot change
password flag was enabled during creation of the account. Also do not remove the group you just added,
the SYSTEM account, or groups such as EA, DA, BA, or the Windows Authorization Access Group.
29. Click Advanced and verify that the Advanced Security Settings dialog box looks similar to the following
screenshot.
30. Click OK, and OK again to close the account's property dialog box.
31. Setup of the first management account is now complete. You will test the account in a later procedure.
Cr eat i n g A ddi t i o n al Man agem en t A c c o u n t s
You can create additional management accounts by repeating the previous steps, by copying the account you just
created, or by creating a script to create accounts with your desired configuration settings. Note, however, that if
you copy the account you just created, many of the customized settings and ACLs will not be copied to the new
account and you will have to repeat most of the configuration steps.
You can instead create a group to which you delegate rights to populate and unpopulate protected groups, but you
will need to secure the group and the accounts you place in it. Because there should be very few accounts in your
directory that are granted the ability to manage the membership of protected groups, creating individual accounts
might be the simplest approach.
Regardless of how you choose to create a group into which you place the management accounts, you should
ensure that each account is secured as described earlier. You should also consider implementing GPO restrictions
similar to those described in Appendix D: Securing Built-In Administrator Accounts in Active Directory.
A u di t i n g Man agem en t A c c o u n t s
You should configure auditing on the account to log, at minimum, all writes to the account. This will allow you to
not only identify successful enabling of the account and resetting of its password during authorized uses, but to
also identify attempts by unauthorized users to manipulate the account. Failed writes on the account should be
captured in your Security Information and Event Monitoring (SIEM ) system (if applicable), and should trigger alerts
that provide notification to the staff responsible for investigating potential compromises.
SIEM solutions take event information from involved security sources (for example, event logs, application data,
network streams, antimalware products, and intrusion detection sources), collate the data, and try to make
intelligent views and proactive actions. There are many commercial SIEM solutions, and many enterprises create
private implementations. A well designed and appropriately implemented SIEM can significantly enhance security
monitoring and incident response capabilities. However, capabilities and accuracy vary tremendously between
solutions. SIEMs are beyond the scope of this paper, but the specific event recommendations contained should be
considered by any SIEM implementer.
For more information about recommended audit configuration settings for domain controllers, see Monitoring
Active Directory for Signs of Compromise. Domain controller-specific configuration settings are provided in
Monitoring Active Directory for Signs of Compromise.
Enabling Management Accounts to Modify the Membership of Protected Groups
In this procedure, you will configure permissions on the domain's AdminSDHolder object to allow the newly
created management accounts to modify the membership of protected groups in the domain. This procedure
cannot be performed via a graphical user interface (GUI).
As discussed in Appendix C: Protected Accounts and Groups in Active Directory, the ACL on a domain's
AdminSDHolder object is effectively "copied" to protected objects when the SDProp task runs. Protected groups
and accounts do not inherit their permissions from the AdminSDHolder object; their permissions are explicitly set
to match those on the AdminSDHolder object. Therefore, when you modify permissions on the AdminSDHolder
object, you must modify them for attributes that are appropriate to the type of the protected object you are
targeting.
In this case, you will be granting the newly created management accounts to allow them to read and write the
members attribute on group objects. However, the AdminSDHolder object is not a group object and group
attributes are not exposed in the graphical ACL editor. It is for this reason that you will implement the permissions
changes via the Dsacls command-line utility. To grant the (disabled) management accounts permissions to modify
the membership of protected groups, perform the following steps:
1. Log on to a domain controller, preferably the domain controller holding the PDC Emulator (PDCE ) role, with
the credentials of a user account that has been made a member of the DA group in the domain.
2. Open an elevated command prompt by right-clicking Command Prompt and click Run as administrator.
NOTE
For more information about elevation and user account control (UAC) in Windows, see UAC Processes and
Interactions on the TechNet website.
4. At the Command Prompt, type (substituting your domain-specific information) Dsacls [distinguished
name of the AdminSDHolder object in your domain] /G [management account
UPN ]:RPWP;member.
The previous command (which is not case-sensitive) works as follows:
Dsacls sets or displays ACEs on directory objects
CN=AdminSDHolder,CN=System,DC=TailSpinToys,DC=msft identifies the object to be modified
/G indicates that a grant ACE is being configured
PIM001@tailspintoys.msft is the User Principal Name (UPN ) of the security principal to which the
ACEs will be granted
RPWP grants read property and write property permissions
Member is the name of the property (attribute) on which the permissions will be set
For more information about use of Dsacls, type Dsacls without any parameters at a command prompt.
If you have created multiple management accounts for the domain, you should run the Dsacls command for
each account. When you have completed the ACL configuration on the AdminSDHolder object, you should
force SDProp to run, or wait until its scheduled run completes. For information about forcing SDProp to run,
see "Running SDProp Manually" in Appendix C: Protected Accounts and Groups in Active Directory.
When SDProp has run, you can verify that the changes you made to the AdminSDHolder object have been
applied to protected groups in the domain. You cannot verify this by viewing the ACL on the
AdminSDHolder object for the reasons previously described, but you can verify that the permissions have
been applied by viewing the ACLs on protected groups.
5. In Active Directory Users and Computers, verify that you have enabled Advanced Features. To do so,
click View, locate the Domain Admins group, right-click the group and click Properties.
6. Click the Security tab and click Advanced to open the Advanced Security Settings for Domain Admins
dialog box.
7. Select Allow ACE for the management account and click Edit. Verify that the account has been granted
only Read Members and Write Members permissions on the DA group, and click OK.
8. Click OK in the Advanced Security Settings dialog box, and click OK again to close the property dialog
box for the DA group.
9. You can repeat the previous steps for other protected groups in the domain; the permissions should be the
same for all protected groups. You have now completed creation and configuration of the management
accounts for the protected groups in this domain.
NOTE
Any account that has permission to write membership of a group in Active Directory can also add itself to the group.
This behavior is by design and cannot be disabled. For this reason, you should always keep management accounts
disabled when not in use, and should closely monitor the accounts when they're disabled and when they're in use.
Verifying Group and Account Configuration Settings

Now that you have created and configured management accounts that can modify the membership of protected
groups in the domain (which includes the most highly privileged EA, DA, and BA groups), you should verify that the
accounts and their management group have been created properly. Verification consists of these general tasks:
1. Test the group that can enable and disable management accounts to verify that members of the group can
enable and disable the accounts and reset their passwords, but cannot perform other administrative activities
on the management accounts.
2. Test the management accounts to verify that they can add and remove members to protected groups in the
domain, but cannot change any other properties of protected accounts and groups.
Te st t h e G r o u p t h a t W i l l En a b l e a n d D i sa b l e M a n a g e m e n t A c c o u n t s
1. To test enabling a management account and resetting its password, log on to a secure administrative
workstation with an account that is a member of the group you created in Appendix I: Creating Management
Accounts for Protected Accounts and Groups in Active Directory.
2. Open Active Directory Users and Computers, right-click the management account, and click Enable
Account.
3. A dialog box should display, confirming that the account has been enabled.
4. Next, reset the password on the management account. To do so, right-click the account again and click Reset
Password.
5. Type a new password for the account in the New password and Confirm password fields, and click OK.
6. A dialog box should appear, confirming that the password for the account has been reset.
7. Now attempt to modify additional properties of the management account. Right-click the account and click
Properties, and click the Remote control tab.
8. Select Enable remote control and click Apply. The operation should fail and an Access Denied error
message should display.
9. Click the Account tab for the account and attempt to change the account's name, logon hours, or logon
workstations. All should fail, and account options that are not controlled by the userAccountControl
attribute should be grayed out and unavailable for modification.
10. Attempt to add the management group to a protected group such as the DA group. When you click OK, a
message should appear, informing you that you do not have permissions to modify the group.
11. Perform additional tests as required to verify that you cannot configure anything on the management
account except userAccountControl settings and password resets.
NOTE
The userAccountControl attribute controls multiple account configuration options. You cannot grant permission to
change only some of the configuration options when you grant write permission to the attribute.
Te st t h e M a n a g e m e n t A c c o u n t s
Now that you have enabled one or more accounts that can change the membership of protected groups, you can
test the accounts to ensure that they can modify protected group membership, but cannot perform other
modifications on protected accounts and groups.
1. Log on to a secure administrative host as the first management account.
2. Launch Active Directory Users and Computers and locate the Domain Admins group.
3. Right-click the Domain Admins group and click Properties.
4. In the Domain Admins Properties, click the Members tab and click Add. Enter the name of an account
that will be given temporary Domain Admins privileges and click Check Names. When the name of the
account is underlined, click OK to return to the Members tab.
5. On the Members tab for the Domain Admins Properties dialog box, click Apply. After clicking Apply, the
account should stay a member of the DA group and you should receive no error messages.
6. Click the Managed By tab in the Domain Admins Properties dialog box and verify that you cannot enter
text in any fields and all buttons are grayed out.
7. Click the General tab in the Domain Admins Properties dialog box and verify that you cannot modify any
of the information about that tab.
8. Repeat these steps for additional protected groups as needed. When you have finished, log on to a secure
administrative host with an account that is a member of the group you created to enable and disable the
management accounts. Then reset the password on the management account you just tested and disable the
account. You have completed setup of the management accounts and the group that will be responsible for
enabling and disabling the accounts.
Appendix L: Events

The following table lists events that you should monitor in your environment, according to the recommendations
provided in Monitoring Active Directory for Signs of Compromise. In the following table, the "Current Windows
Event ID" column lists the event ID as it is implemented in versions of Windows and Windows Server that are
currently in mainstream support.
The "Legacy Windows Event ID" column lists the corresponding event ID in legacy versions of Windows such as
client computers running Windows XP or earlier and servers running Windows Server 2003 or earlier. The
"Potential Criticality" column identifies whether the event should be considered of low, medium, or high criticality in
detecting attacks, and the "Event Summary" column provides a brief description of the event.
A potential criticality of High means that one occurrence of the event should be investigated. Potential criticality of
Medium or Low means that these events should only be investigated if they occur unexpectedly or in numbers that
significantly exceed the expected baseline in a measured period of time. All organizations should test these
recommendations in their environments before creating alerts that require mandatory investigative responses.
Every environment is different, and some of the events ranked with a potential criticality of High may occur due to
other harmless events.
Current Windows Event ID Legacy Windows Event ID Potential Criticality Event Summary
4618 N/A High A monitored security event

pattern has occurred.
4649 N/A High A replay attack was detected.

May be a harmless false
positive due to
misconfiguration error.
4719 612 High System audit policy was

changed.
4765 N/A High SID History was added to an

account.
4766 N/A High An attempt to add SID

History to an account failed.
4794 N/A High An attempt was made to set

the Directory Services
Restore Mode.
4897 801 High Role separation enabled:

4964 N/A High Special groups have been
assigned to a new logon.
5124 N/A High A security setting was

updated on the OCSP
Responder Service
N/A 550 Medium to High Possible denial-of-service

(DoS) attack
1102 517 Medium to High The audit log was cleared
4621 N/A Medium 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.
4675 N/A Medium SIDs were filtered.
4692 N/A Medium Backup of data protection

master key was attempted.
4693 N/A Medium Recovery of data protection

master key was attempted.
4706 610 Medium A new trust was created to a

domain.
4713 617 Medium Kerberos policy was

changed.
4714 618 Medium Encrypted data recovery

policy was changed.
4715 N/A Medium The audit policy (SACL) on

an object was changed.
4716 620 Medium Trusted domain information

was modified.
4724 628 Medium An attempt was made to

reset an account's password.
4727 631 Medium A security-enabled global

group was created.
4735 639 Medium A security-enabled local

group was changed.
4737 641 Medium A security-enabled global

group was changed.
4739 643 Medium Domain Policy was changed.
4754 658 Medium A security-enabled universal

group was created.
4755 659 Medium A security-enabled universal

group was changed.
4764 667 Medium A security-disabled group

was deleted
4764 668 Medium A group's type was changed.
4780 684 Medium The ACL was set on accounts

which are members of
administrators groups.
4816 N/A Medium RPC detected an integrity

violation while decrypting an
incoming message.
4865 N/A Medium A trusted forest information

entry was added.

entry was removed.

entry was modified.
4868 772 Medium The certificate manager

denied a pending certificate
request.
4870 774 Medium Certificate Services revoked a

certificate.
4882 786 Medium The security permissions for

Certificate Services changed.
4885 789 Medium The audit filter for Certificate

Services changed.
4890 794 Medium The certificate manager

settings for Certificate
Services changed.
4892 796 Medium A property of Certificate

Services changed.
4896 800 Medium One or more rows have

been deleted from the
certificate database.
4906 N/A Medium The CrashOnAuditFail value
has changed.
4907 N/A Medium Auditing settings on object

were changed.
4908 N/A Medium Special Groups Logon table

modified.
4912 807 Medium Per User Audit Policy was

changed.
4960 N/A Medium 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.

packet that failed a replay
check. If this problem
persists, it could indicate a
replay attack against this
computer.

packet that failed a replay
check. The inbound packet
had too low a sequence
number to ensure it was not
a replay.

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 N/A Medium 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.
4976 N/A Medium During Main Mode

negotiation, IPsec received
an invalid negotiation
packet. If this problem
network issue or an attempt
to modify or replay this
negotiation.
4977 N/A Medium During Quick Mode

negotiation.
4978 N/A Medium During Extended Mode

negotiation.
4983 N/A Medium An IPsec Extended Mode

negotiation failed. The
corresponding Main Mode
security association has been
deleted.
4984 N/A Medium An IPsec Extended Mode

negotiation failed. The
corresponding Main Mode
security association has been
deleted.
5027 N/A Medium The Windows Firewall Service
was unable to retrieve the
security policy from the local
storage. The service will
continue enforcing the
current policy.

was unable to parse the new
security policy. The service
will continue with currently
enforced policy.

failed to initialize the driver.
The service will continue to
enforce the current policy.

failed to start.
5035 N/A Medium The Windows Firewall Driver

failed to start.
5037 N/A Medium The Windows Firewall Driver

detected critical runtime
error. Terminating.
5038 N/A Medium 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.
5120 N/A Medium OCSP Responder Service

Started
5121 N/A Medium OCSP Responder Service

Stopped
5122 N/A Medium A configuration entry

changed in OCSP Responder
Service
5123 N/A Medium A configuration entry

changed in OCSP Responder
Service
5376 N/A Medium Credential Manager

credentials were backed up.
5377 N/A Medium Credential Manager

credentials were restored
from a backup.
5453 N/A Medium An IPsec negotiation with a
remote computer failed
because the IKE and AuthIP
IPsec Keying Modules
(IKEEXT) service is not
started.
5480 N/A Medium 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 N/A Medium IPsec Services failed to

initialize RPC server. IPsec
Services could not be
started.
5484 N/A Medium 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 N/A Medium 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.
6145 N/A Medium One or more errors occurred

while processing security
policy in the Group Policy
objects.
6273 N/A Medium Network Policy Server denied

access to a user.
6274 N/A Medium Network Policy Server

discarded the request for a
user.
discarded the accounting
request for a user.

quarantined a user.

granted access to a user but
put it on probation because
the host did not meet the
defined health policy.

granted full access to a user
because the host met the
defined health policy.
6279 N/A Medium Network Policy Server locked

the user account due to
repeated failed
authentication attempts.

unlocked the user account.
- 640 Medium General account database

changed
- 619 Medium Quality of Service Policy

changed
24586 N/A Medium An error was encountered

converting volume
24592 N/A Medium An attempt to automatically

restart conversion on
volume %2 failed.
24593 N/A Medium Metadata write: Volume %2

returning errors while trying
to modify metadata. If
failures continue, decrypt
volume
24594 N/A Medium Metadata rebuild: An

attempt to write a copy of
metadata on volume %2
failed and may appear as
disk corruption. If failures
continue, decrypt volume.
4608 512 Low Windows is starting up.
4609 513 Low Windows is shutting down.

4610 514 Low An authentication package
has been loaded by the Local
Security Authority.
4611 515 Low A trusted logon process has

been registered with the
Local Security Authority.
4612 516 Low Internal resources allocated

for the queuing of audit
messages have been
exhausted, leading to the
loss of some audits.
4614 518 Low A notification package has

been loaded by the Security
Account Manager.
4615 519 Low Invalid use of LPC port.
4616 520 Low The system time was

changed.
4622 N/A Low A security package has been

loaded by the Local Security
Authority.
4624 528,540 Low An account was successfully

logged on.
4625 529-537,539 Low An account failed to log on.
4634 538 Low An account was logged off.
4646 N/A Low IKE DoS-prevention mode

started.
4647 551 Low User initiated logoff.
4648 552 Low A logon was attempted

using explicit credentials.
4650 N/A Low An IPsec Main Mode security

association was established.
Extended Mode was not
enabled. Certificate
authentication was not used.

association was established.
Extended Mode was not
enabled. A certificate was
used for authentication.
4652 N/A Low An IPsec Main Mode
negotiation failed.
4653 N/A Low An IPsec Main Mode

negotiation failed.
4654 N/A Low An IPsec Quick Mode

negotiation failed.

association ended.
4656 560 Low A handle to an object was

requested.
4657 567 Low A registry value was

modified.
4658 562 Low The handle to an object was

closed.
4659 N/A Low A handle to an object was

requested with intent to
delete.
4660 564 Low An object was deleted.
4661 565 Low A handle to an object was

requested.
4662 566 Low An operation was performed

on an object.
4663 567 Low An attempt was made to

access an object.
4664 N/A Low An attempt was made to

create a hard link.

create an application client
context.
4666 N/A Low An application attempted an

operation:
4667 N/A Low An application client context

was deleted.
4668 N/A Low An application was initialized.
4670 N/A Low Permissions on an object

were changed.
4671 N/A Low An application attempted to
access a blocked ordinal
through the TBS.
4672 576 Low Special privileges assigned to

new logon.
4673 577 Low A privileged service was

called.
4674 578 Low An operation was attempted

on a privileged object.
4688 592 Low A new process has been

created.
4689 593 Low A process has exited.

duplicate a handle to an
object.
4691 595 Low Indirect access to an object

was requested.
4694 N/A Low Protection of auditable

protected data was
attempted.
4695 N/A Low Unprotection of auditable

protected data was
attempted.
4696 600 Low A primary token was

assigned to process.
4697 601 Low Attempt to install a service
4698 602 Low A scheduled task was

created.

deleted.

enabled.

disabled.

updated.
4704 608 Low A user right was assigned.

4705 609 Low A user right was removed.
4707 611 Low A trust to a domain was

removed.
4709 N/A Low IPsec Services was started.
4710 N/A Low IPsec Services was disabled.
4711 N/A Low May contain any one of the

following: PAStore Engine
applied locally cached copy
of Active Directory storage
IPsec policy on the
computer.PAStore Engine
applied Active Directory
storage IPsec policy on the
applied local registry storage
IPsec policy on the
failed to apply locally cached
copy of Active Directory
failed to apply Active
Directory storage IPsec
policy on the
failed to apply local registry
failed to apply some rules of
the active IPsec policy on the
failed to load directory
loaded directory storage
IPsec policy on the
failed to load local storage
IPsec policy on the
loaded local storage IPsec
policy on the
polled for changes to the
active IPsec policy and
detected no changes.
4712 N/A Low IPsec Services encountered a

potentially serious failure.
4717 621 Low System security access was

granted to an account.
4718 622 Low System security access was

removed from an account.
4720 624 Low A user account was created.
4722 626 Low A user account was enabled.

change an account's
password.
4725 629 Low A user account was disabled.
4726 630 Low A user account was deleted.
4728 632 Low A member was added to a

security-enabled global
group.
4729 633 Low A member was removed

from a security-enabled
global group.
4730 634 Low A security-enabled global

group was deleted.
4731 635 Low A security-enabled local

group was created.

security-enabled local group.

from a security-enabled local
group.
4734 638 Low A security-enabled local

group was deleted.
4738 642 Low A user account was changed.
4740 644 Low A user account was locked

out.
4741 645 Low A computer account was

changed.

changed.

deleted.
4744 648 Low A security-disabled local

group was created.
group was changed.

security-disabled local group.

from a security-disabled local
group.

group was deleted.
4749 653 Low A security-disabled global

group was created.

group was changed.

security-disabled global
group.

from a security-disabled
global group.

group was deleted.

security-enabled universal
group.

from a security-enabled
universal group.
4758 662 Low A security-enabled universal

group was deleted.
4759 663 Low A security-disabled universal

group was created.
4760 664 Low A security-disabled universal

group was changed.

security-disabled universal
group.

from a security-disabled
universal group.
4767 671 Low A user account was
unlocked.
4768 672,676 Low A Kerberos authentication

ticket (TGT) was requested.
4769 673 Low A Kerberos service ticket was

requested.
4770 674 Low A Kerberos service ticket was

renewed.
4771 675 Low Kerberos pre-authentication

failed.
4772 672 Low A Kerberos authentication

ticket request failed.
4774 678 Low An account was mapped for

logon.
4775 679 Low An account could not be

mapped for logon.
4776 680,681 Low The domain controller

attempted to validate the
credentials for an account.
4777 N/A Low The domain controller failed

to validate the credentials for
an account.
4778 682 Low A session was reconnected

to a Window Station.
4779 683 Low A session was disconnected

from a Window Station.
4781 685 Low The name of an account was

changed:
4782 N/A Low The password hash an

account was accessed.
4783 667 Low A basic application group

was created.
4784 N/A Low A basic application group

was changed.

basic application group.
from a basic application
group.
4787 691 Low A nonmember was added to

a basic application group.
4788 692 Low A nonmember was removed

from a basic application
group.
4789 693 Low A basic application group

was deleted.
4790 694 Low An LDAP query group was

created.
4793 N/A Low The Password Policy

Checking API was called.
4800 N/A Low The workstation was locked.
4801 N/A Low The workstation was

unlocked.
4802 N/A Low The screen saver was

invoked.
4803 N/A Low The screen saver was

dismissed.
4864 N/A Low A namespace collision was

detected.
4869 773 Low Certificate Services received a

resubmitted certificate
request.

request to publish the
certificate revocation list
(CRL).
4872 776 Low Certificate Services published

the certificate revocation list
(CRL).
4873 777 Low A certificate request

extension changed.
4874 778 Low One or more certificate

request attributes changed.

request to shut down.
4876 780 Low Certificate Services backup
started.
4877 781 Low Certificate Services backup

completed.
4878 782 Low Certificate Services restore

started.
4879 783 Low Certificate Services restore

completed.
4880 784 Low Certificate Services started.
4881 785 Low Certificate Services stopped.
4883 787 Low Certificate Services retrieved

an archived key.
4884 788 Low Certificate Services imported

a certificate into its database.

certificate request.
4887 791 Low Certificate Services approved

a certificate request and
issued a certificate.
4888 792 Low Certificate Services denied a

certificate request.
4889 793 Low Certificate Services set the

status of a certificate request
to pending.
4891 795 Low A configuration entry

changed in Certificate
Services.
4893 797 Low Certificate Services archived

a key.
4894 798 Low Certificate Services imported

and archived a key.
4895 799 Low Certificate Services published

the CA certificate to Active
4898 802 Low Certificate Services loaded a

template.
4902 N/A Low The Per-user audit policy
table was created.

register a security event
source.

unregister a security event
source.
4909 N/A Low The local policy settings for

the TBS were changed.
4910 N/A Low The Group Policy settings for

the TBS were changed.
4928 N/A Low An Active Directory replica

source naming context was
established.

removed.

modified.

destination naming context
was modified.
4932 N/A Low Synchronization of a replica

of an Active Directory
naming context has begun.
4933 N/A Low Synchronization of a replica

of an Active Directory
naming context has ended.
4934 N/A Low Attributes of an Active

Directory object were
replicated.
4935 N/A Low Replication failure begins.
4936 N/A Low Replication failure ends.
4937 N/A Low A lingering object was

removed from a replica.
4944 N/A Low The following policy was

active when the Windows
Firewall started.
4945 N/A Low A rule was listed when the
Windows Firewall started.
4946 N/A Low A change has been made to

Windows Firewall exception
list. A rule was added.

list. A rule was modified.

list. A rule was deleted.
4949 N/A Low Windows Firewall settings

were restored to the default
values.
4950 N/A Low A Windows Firewall setting

has changed.
4951 N/A Low A rule has been ignored

because its major version
number was not recognized
by Windows Firewall.
4952 N/A Low 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 N/A Low A rule has been ignored by

Windows Firewall because it
could not parse the rule.
4954 N/A Low Windows Firewall Group

Policy settings have
changed. The new settings
have been applied.
4956 N/A Low Windows Firewall has

changed the active profile.
4957 N/A Low Windows Firewall did not

apply the following rule:
4958 N/A Low Windows Firewall did not

apply the following rule
because the rule referred to
items not configured on this
computer:
4979 N/A Low IPsec Main Mode and
Extended Mode security
associations were
established.

associations were
established.

associations were
established.

associations were
established.
4985 N/A Low The state of a transaction

has changed.
5024 N/A Low The Windows Firewall Service

has started successfully.

has been stopped.

blocked an application from
accepting incoming
connections on the network.
5032 N/A Low Windows Firewall was unable

to notify the user that it
blocked an application from
accepting incoming
connections on the network.
5033 N/A Low The Windows Firewall Driver

has started successfully.
5034 N/A Low The Windows Firewall Driver

has been stopped.
5039 N/A Low A registry key was

virtualized.

IPsec settings. An
Authentication Set was
added.
IPsec settings. An
modified.

IPsec settings. An
deleted.

IPsec settings. A Connection
Security Rule was added.

Security Rule was modified.

Security Rule was deleted.

IPsec settings. A Crypto Set
was added.

was modified.

was deleted.
5050 N/A Low An attempt to

programmatically disable the
Windows Firewall using a call
to
InetFwProfile.FirewallEnabled
(False)
5051 N/A Low A file was virtualized.
5056 N/A Low A cryptographic self test was

performed.
5057 N/A Low A cryptographic primitive

operation failed.
5058 N/A Low Key file operation.
5059 N/A Low Key migration operation.
5060 N/A Low Verification operation failed.

5061 N/A Low Cryptographic operation.
5062 N/A Low A kernel-mode

cryptographic self test was
performed.
5063 N/A Low A cryptographic provider

operation was attempted.
5064 N/A Low A cryptographic context

5065 N/A Low A cryptographic context

modification was attempted.
5066 N/A Low A cryptographic function


modification was attempted.

provider operation was
attempted.

property operation was
attempted.

property modification was
attempted.
5125 N/A Low A request was submitted to

the OCSP Responder Service
5126 N/A Low Signing Certificate was

automatically updated by
the OCSP Responder Service
5127 N/A Low The OCSP Revocation

Provider successfully
updated the revocation
information
5136 566 Low A directory service object

was modified.
5137 566 Low A directory service object

was created.
5138 N/A Low A directory service object

was undeleted.
was moved.
5140 N/A Low A network share object was

accessed.

was deleted.
5152 N/A Low The Windows Filtering

Platform blocked a packet.
5153 N/A Low A more restrictive Windows

Filtering Platform filter has
blocked a packet.

Platform has permitted an
application or service to
listen on a port for incoming
connections.

Platform has blocked an
application or service from
listening on a port for
incoming connections.

Platform has allowed a
connection.

Platform has blocked a
connection.

Platform has permitted a
bind to a local port.

Platform has blocked a bind
to a local port.
5378 N/A Low The requested credentials

delegation was disallowed by
policy.
5440 N/A Low The following callout was

present when the Windows
Filtering Platform Base
Filtering Engine started.
5441 N/A Low The following filter was
5442 N/A Low The following provider was

5443 N/A Low The following provider

context was present when
the Windows Filtering
Platform Base Filtering
Engine started.
5444 N/A Low The following sublayer was

5446 N/A Low A Windows Filtering Platform

callout has been changed.

filter has been changed.

provider has been changed.

provider context has been
changed.

sublayer has been changed.

security association was
established.

security association ended.
5456 N/A Low PAStore Engine applied

Active Directory storage
IPsec policy on the computer.
5457 N/A Low PAStore Engine failed to

apply Active Directory
computer.
5458 N/A Low PAStore Engine applied
locally cached copy of Active
Directory storage IPsec
policy on the computer.

apply locally cached copy of
Active Directory storage
5460 N/A Low PAStore Engine applied local

registry storage IPsec policy
on the computer.

apply local registry storage

apply some rules of the
active IPsec policy on the
computer. Use the IP
Security Monitor snap-in to
diagnose the problem.
5463 N/A Low PAStore Engine polled for

changes to the active IPsec
policy and detected no
changes.

changes to the active IPsec
policy, detected changes, and
applied them to IPsec
Services.
5465 N/A Low PAStore Engine received a

control for forced reloading
of IPsec policy and processed
the control successfully.

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.
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.

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 N/A Low PAStore Engine loaded local

computer.
5472 N/A Low PAStore Engine failed to load

local storage IPsec policy on
the computer.
5473 N/A Low PAStore Engine loaded

directory storage IPsec
5474 N/A Low PAStore Engine failed to load

directory storage IPsec
5477 N/A Low PAStore Engine failed to add

quick mode filter.
5479 N/A Low 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.
5632 N/A Low A request was made to

authenticate to a wireless
network.
5633 N/A Low A request was made to

authenticate to a wired
network.
5712 N/A Low A Remote Procedure Call
(RPC) was attempted.
5888 N/A Low An object in the COM+

Catalog was modified.
5889 N/A Low An object was deleted from

the COM+ Catalog.
5890 N/A Low An object was added to the

COM+ Catalog.
6008 N/A Low The previous system

shutdown was unexpected
6144 N/A Low Security policy in the Group

Policy objects has been
applied successfully.
6272 N/A Low Network Policy Server

granted access to a user.
N/A 561 Low A handle to an object was

requested.
N/A 563 Low Object open for delete
N/A 625 Low User Account Type Changed
N/A 613 Low IPsec policy agent started
N/A 614 Low IPsec policy agent disabled
N/A 615 Low IPsec policy agent
N/A 616 Low IPsec policy agent

encountered a potential
serious failure
24577 N/A Low Encryption of volume started
24578 N/A Low Encryption of volume

stopped
24579 N/A Low Encryption of volume

completed
24580 N/A Low Decryption of volume

started

stopped
completed
24583 N/A Low Conversion worker thread

for volume started
24584 N/A Low Conversion worker thread

for volume temporarily
stopped
24588 N/A Low The conversion operation on

volume %2 encountered a
bad sector error. Please
validate the data on this
volume
24595 N/A Low Volume %2 contains bad

clusters. These clusters will
be skipped during
conversion.
24621 N/A Low Initial state check: Rolling

volume conversion
transaction on %2.
5049 N/A Low An IPsec Security Association

was deleted.
5478 N/A Low IPsec Services has started

successfully.
NOTE
Refer to Windows security audit events for a list of many security event IDs and their meanings.
Run wevtutil gp Microsoft-Windows-Security-Auditing /ge /gm:true to get a very detailed listing of all security event
IDs
For more information about Windows security event IDs and their meanings, see the Microsoft Support article
Description of security events in Windows 7 and in Windows Server 2008 R2. You can also download Security
Audit Events for Windows 7 and Windows Server 2008 R2 and Windows 8 and Windows Server 2012 Security
Event Details, which provide detailed event information for the referenced operating systems in spreadsheet
format.
Appendix M: Document Links and Recommended
Reading

Document Links
The following table contains a list of links to external documents and their URLs so that readers of hard copies of
this document can access this information. The links are listed in the order they appear in the document.
Links URLs
10 Immutable Laws of Security Administration https://technet.microsoft.com/library/cc722488.aspx
Microsoft Security Compliance Manager https://technet.microsoft.com/library/cc677002.aspx
Gartner Symposium ITXPO http://www.gartner.com/technology/symposium/orlando/
2012 Data Breach Investigations Report (DBIR) http://www.verizonbusiness.com/resources/reports/rp_data-

breach-investigations-report-2012_en_xg.pdf
Ten Immutable Laws of Security (Version 2.0) https://technet.microsoft.com/security/hh278941.aspx
Using Heuristic Scanning https://technet.microsoft.com/library/bb418939.aspx
Drive-by download https://www.microsoft.com/security/sir/glossary/drive-by-

download-sites.aspx
Microsoft Support article 2526083 https://support.microsoft.com/kb/2526083
Open Web Application Security Project (OWASP) https://www.owasp.org/index.php/Main_Page
Microsoft Security Development Lifecycle https://www.microsoft.com/security/sdl/default.aspx
Mitigating Pass-the-Hash (PtH) Attacks and Other Credential https://download.microsoft.com/download/7/7/A/77ABC5BD-

Theft Techniques 8320-41AF-863C-6ECFB10CB4B9/Mitigating Pass-the-Hash
(PtH) Attacks and Other Credential Theft
Techniques_English.pdf
Determined Adversaries and Targeted Attacks https://www.microsoft.com/download/details.aspx?id=34793
Solution for management of built-in Administrator account's https://code.msdn.microsoft.com/windowsdesktop/Solution-

password via GPO for-management-of-ae44e789
Microsoft Support article 817433 https://support.microsoft.com/?id=817433
Administrator account is disabled by default https://technet.microsoft.com/library/cc753450.aspx
The Administrator Accounts Security Planning Guide https://technet.microsoft.com/library/cc162797.aspx
Microsoft Windows Security Resource Kit https://www.microsoft.com/learning/en/us/book.aspx?

ID=6815&locale=en-us
Authentication Mechanism Assurance for AD DS in Windows https://technet.microsoft.com/library/dd378897(WS.10).aspx

Server 2008 R2 Step-by-Step Guide
Windows Server Update Services https://technet.microsoft.com/windowsserver/bb332157
Personal Virtual Desktops https://technet.microsoft.com/library/dd759174.aspx
Read-Only Domain Controller Planning and Deployment https://technet.microsoft.com/library/cc771744(WS.10).aspx

Guide
Running Domain Controllers in Hyper-V https://technet.microsoft.com/library/dd363553(v=ws.10).aspx
Hyper-V Security Guide https://www.microsoft.com/download/details.aspx?id=16650
Ask the Directory Services Team http://blogs.technet.com/b/askds/archive/2011/09/12/managi

ng-rid-pool-depletion.aspx
How to configure a firewall for domains and trusts https://support.microsoft.com/kb/179442
2009 Verizon Data Breach Report http://www.verizonbusiness.com/resources/security/reports/20

09_databreach_rp.pdf
2012 Verizon Data Breach report http://www.verizonbusiness.com/resources/reports/rp_data-

Introducing Auditing Changes in Windows 2008 http://blogs.technet.com/b/askds/archive/2007/10/19/introdu

cing-auditing-changes-in-windows-2008.aspx
Cool Auditing Tricks in Vista and 2008 http://blogs.technet.com/b/askds/archive/2007/11/16/cool-

auditing-tricks-in-vista-and-2008.aspx
Global Object Access Auditing is Magic http://blogs.technet.com/b/askds/archive/2011/03/10/global-

object-access-auditing-is-magic.aspx
One-Stop Shop for Auditing in Windows Server 2008 and http://blogs.technet.com/b/askds/archive/2008/03/27/one-

Windows Vista stop-shop-for-auditing-in-windows-server-2008-and-
windows-vista.aspx
AD DS Auditing Step-by-Step Guide https://technet.microsoft.com/library/a9c25483-89e2-4202-

881c-ea8e02b4b2a5.aspx
Getting the Effective Audit Policy in Windows 7 and 2008 R2 http://www.verizonbusiness.com/resources/reports/rp_data-
Sample script http://www.verizonbusiness.com/resources/reports/rp_data-

Audit Option Type http://www.verizonbusiness.com/resources/reports/rp_data-

Advanced Security Auditing in Windows 7 and Windows Server https://social.technet.microsoft.com/wiki/contents/articles/adva

2008 R2 nced-security-auditing-in-windows-7-and-windows-server-
2008-r2.aspx
Auditing and Compliance in Windows Server 2008 https://technet.microsoft.com/magazine/2008.03.auditing.aspx
How to use Group Policy to configure detailed security https://support.microsoft.com/kb/921469

auditing settings for Windows Vista-based and Windows
Server 2008-based computers in a Windows Server 2008
domain, in a Windows Server 2003 domain, or in a Windows
2000 Server domain
Advanced Security Audit Policy Step-by-Step Guide https://technet.microsoft.com/library/dd408940(WS.10).aspx
Threats and Countermeasures Guide https://technet.microsoft.com/library/hh125921(v=ws.10).aspx
MaxTokenSize and Kerberos Token Bloat http://blogs.technet.com/b/shanecothran/archive/2010/07/16/

maxtokensize-and-kerberos-token-bloat.aspx
Authentication Mechanism Assurance https://technet.microsoft.com/library/dd391847(v=WS.10).asp

x
Microsoft Data Classification Toolkit https://technet.microsoft.com/library/hh204743.aspx
Dynamic Access Control http://blogs.technet.com/b/windowsserver/archive/2012/05/2

2/introduction-to-windows-server-2012-dynamic-access-
control.aspx
Absolute Software http://www.absolute.com/en/landing/Google/absolute-

software-google/computrace-and-absolute-manage?
gclid=CPPh5P6v3rMCFQtxQgodFEQAnA
Absolute Manage http://www.absolute.com/landing/Google/absolute-manage-

google/it-asset-management-software
Absolute Manage MDM http://www.absolute.com/landing/Google/MDM-

google/mobile-device-management
SolarWinds http://www.solarwinds.com/eminentware-products.aspx
EminentWare WSUS Extension Pack http://solarwinds-

marketing.s3.amazonaws.com/solarwinds/Datasheets/Eminent
Ware-WSUS-Extension-Pack-005-Datasheet2.pdf
EminentWare System Center Configuration Manager Extension http://solarwinds-
Pack marketing.s3.amazonaws.com/solarwinds/Datasheets/Eminent
Ware-Extension-Pack-for-CM-Datasheet-006-Revised.pdf
GFI Software http://www.gfi.com/?

adv=952&loc=58&gclid=CLq9y5603rMCFal7QgodMFkAyA
GFI LanGuard http://www.gfi.com/network-security-vulnerability-scanner/?

adv=952&loc=60&gclid=CP2t-7i03rMCFQuCQgodNkAA7g
Secunia http://secunia.com/
Secunia Corporate Software Inspector (CSI) http://secunia.com/products/corporate/csi/
Vulnerability Intelligence Manager http://secunia.com/vulnerability_intelligence/
eEye Digital Security http://www.wideeyesecurity.com/?

gclid=CK6b0sm13rMCFad_QgodhScAiw
Retina CS Management http://www.wideeyesecurity.com/products.asp
Lumension http://www.lumension.com/?
rpLeadSourceId=5009&gclid=CKuai_e13rMCFal7QgodMFkAy
A
Lumension Vulnerability Management http://www.lumension.com/Solutions/Vulnerability-

Management.aspx
Threats and Countermeasures Guide: User Rights https://technet.microsoft.com/library/hh125917(v=ws.10).aspx
Threats and Vulnerabilities Mitigation https://technet.microsoft.com/library/cc755181(v=ws.10).aspx
User Rights https://technet.microsoft.com/library/dd349804(v=WS.10).asp

x
Access Credential Manager as a trusted caller https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_2
Access this computer from the network https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_1
Act as part of the operating system https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_3
Add workstations to domain https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_4
Adjust memory quotas for a process https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_5
Allow log on locally https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_6
Allow log on through Terminal Services https://technet.microsoft.com/library/db585464-a2be-41b1-
b781-e9845182f4b6(v=ws.10)#BKMK_7
Back up files and directories https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_8
Bypass traverse checking https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_9
Change the system time https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_10
Change the time zone https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_11
Create a pagefile https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_12
Create a token object https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_13
Create global objects https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_14
Create permanent shared objects https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_15
Create symbolic links https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_16
Debug programs https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_17
Deny access to this computer from the network https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_18
Deny log on as a batch job https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_18a
Deny log on as a service https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_19
Deny log on locally https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_20
Deny log on through Terminal Services https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_21
Enable computer and user accounts to be trusted for https://technet.microsoft.com/library/db585464-a2be-41b1-

delegation b781-e9845182f4b6(v=ws.10)#BKMK_22
Force shutdown from a remote system https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_23
Generate security audits https://technet.microsoft.com/library/db585464-a2be-41b1-
b781-e9845182f4b6(v=ws.10)#BKMK_24
Impersonate a client after authentication https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_25
Increase a process working set https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_26
Increase scheduling priority https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_27
Load and unload device drivers https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_28
Lock pages in memory https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_29
Log on as a batch job https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_30
Log on as a service https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_31
Manage auditing and security log https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_32
Modify an object label https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_33
Modify firmware environment values https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_34
Perform volume maintenance tasks https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_35
Profile single process https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_36
Profile system performance https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_37
Remove computer from docking station https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_38
Replace a process level token https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_39
Restore files and directories https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_40
Shut down the system https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_41
Synchronize directory service data https://technet.microsoft.com/library/db585464-a2be-41b1-
b781-e9845182f4b6(v=ws.10)#BKMK_42
Take ownership of files or other objects https://technet.microsoft.com/library/db585464-a2be-41b1-

b781-e9845182f4b6(v=ws.10)#BKMK_43
Access Control https://msdn.microsoft.com/library/aa374860(v=VS.85).aspx
rootDSE Modify Operations https://msdn.microsoft.com/library/cc223297.aspx
AD DS Backup and Recovery Step-by-Step Guide https://technet.microsoft.com/library/cc771290(v=ws.10).aspx
Windows Configurations for Kerberos Supported Encryption http://blogs.msdn.com/b/openspecification/archive/2011/05/3

Type 1/windows-configurations-for-kerberos-supported-
encryption-type.aspx
UAC Processes and Interactions https://technet.microsoft.com/library/dd835561(v=WS.10).asp

x#1
EmpowerID http://www.empowerid.com/products/authorizationservices
Role-based access control (RBAC) http://pic.dhe.ibm.com/infocenter/aix/v7r1/index.jsp?

topic=%2Fcom.ibm.aix.security%2Fdoc%2Fsecurity%2Fdomain
_rbac.htm
The RBAC model http://docs.oracle.com/cd/E19082-01/819-

3321/6n5i4b7ap/index.html
Active Directory-centric access control http://www.centrify.com/solutions/it-security-access-

control.asp
Cyber-Ark's Privileged Identity Management (PIM) Suite http://www.cyber-ark.com/digital-vault-products/pim-

suite/index.asp
Quest One http://www.quest.com/landing/?

id=7370&gclid=CJnNgNyr3rMCFYp_QgodXFwA3w
Enterprise Random Password Manager (ERPM) http://www.liebsoft.com/Random_Password_Manager/
NetIQ Privileged User Manager https://www.netiq.com/products/privileged-user-manager/
CA IdentityMinder? http://awards.scmagazine.com/ca-technologies-ca-identity-
manager
Description of security events in Windows Vista and in https://support.microsoft.com/kb/947226

Windows Server 2008
Description of security events in Windows 7 and in Windows https://support.microsoft.com/kb/977519

Server 2008 R2
Security Audit Events for Windows 7 https://www.microsoft.com/download/details.aspx?id=21561

Windows Server 2008 R2 and Windows 8 and Windows Server https://www.microsoft.com/download/details.aspx?id=35753
2012 Security Event Details
Georgia Tech's Emerging Cyber Threats for 2013 report http://www.gtsecuritysummit.com/report.html
Microsoft Security Intelligence Report https://www.microsoft.com/security/sir/default.aspx
Australian Government Defense Signals Directory Top 35 http://www.dsd.gov.au/infosec/top35mitigationstrategies.htm

Mitigation Strategies
Cloud Computing Security Benefits https://www.microsoft.com/news/Press/2012/May12/05-

14SMBSecuritySurveyPR.aspx
Applying the Principle of Least Privilege to User Accounts on https://www.microsoft.com/download/details.aspx?id=4868

Windows
The Administrator Accounts Security Planning Guide https://www.microsoft.com/download/details.aspx?id=19406
Best Practice Guide for Securing Active Directory Installations https://www.microsoft.com/download/details.aspx?id=16755

for Windows Server 2003
Best Practices for Delegating Active Directory Administration https://www.microsoft.com/en-us/download/details.aspx?

for Windows Server 2003 id=21678
Microsoft Support Lifecycle https://support.microsoft.com/common/international.aspx?

RDPATH=%2flifecycle%2fdefault.aspx
Active Directory Technical Specification https://msdn.microsoft.com/library/cc223122(v=prot.20).aspx
Error message when nonadministrator users who have been https://support.microsoft.com/kb/932455

delegated control try to join computers to a Windows Server
2003-based or a Windows Server 2008-based domain
controller: "Access is denied"
Authentication Mechanism Assurance for AD DS in Windows https://technet.microsoft.com/library/dd378897(WS.10).aspx

Server 2008 R2 Step-by-Step Guide
Strict KDC Validation https://www.microsoft.com/download/details.aspx?id=6382
Recommended Reading
The following table contains a list of recommended reading that will assist you in enhancing the security of your
Active Directory systems.
||
|---|
|Recommended Reading|
|Georgia Tech's Emerging Cyber Threats for 2014 Report|
|Microsoft Security Intelligence Report|
|Mitigating Pass-the-Hash (PTH) Attacks and Other Credential Theft Techniques|
|Australian Government Defense Signals Directory Top 35 Mitigation Strategies|
|2012 Data Breach Investigations Report - (Verizon, US Secret Service)|
|2009 Data Breach Investigations Report|
|Cloud Computing Security Benefits|
|Applying the Principle of Least Privilege to User Accounts on Windows|
|The Administrator Accounts Security Planning Guide|
|Best Practice Guide for Securing Active Directory Installations for Windows Server 2003|
|Best Practices for Delegating Active Directory Administration for Windows Server 2003|
|Microsoft Support Lifecycle|
|Active Directory Technical Specification - dSHeuristics information|
|Error message when nonadministrator users who have been delegated control try to join computers to a Windows
Server 2003-based or a Windows Server 2008-based domain controller: "Access is denied"|
|Best Practice Guide for Securing Active Directory Installations.doc|
|Hyper-V Security Guide|
|Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide.|
|Strict KDC Validation|
Copyright Information
The information contained in this document represents the current view of Microsoft Corporation on the issues
discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should
not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of
any information presented after the date of publication.
This white paper is for informational purposes only. Microsoft makes no warranties, express or implied, in this
document.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under
copyright, no part of this document may be reproduced, stored in, or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any
purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights
covering subject matter in this document. Except as expressly provided in any written license agreement from
Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights,
or other intellectual property.
Microsoft, Active Directory, BitLocker, Hyper-V, Internet Explorer, Windows Vista, Windows, and Windows Server
are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other
countries. All other trademarks are property of their respective owners.
The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and
events depicted herein are fictitious. No association with any real company, organization, product, domain name, e-
mail address, logo, person, place, or event is intended or should be inferred.
? 2013 Microsoft Corporation. All rights reserved.
Active Directory Replication and Topology
Management Using Windows PowerShell
Windows PowerShell for Active Directory now includes support for replication and topology management. The
following topics provide an introduction and additional details:
Introduction to Active Directory Replication and Topology Management Using Windows PowerShell (Level
100)
Advanced Active Directory Replication and Topology Management Using Windows PowerShell (Level 200)
Introduction to Active Directory Replication and
Topology Management Using Windows PowerShell
(Level 100)
Windows PowerShell for Active Directory includes the ability to manage replication, sites, domains and forests,
domain controllers, and partitions. Users of prior management tools such as the Active Directory Sites and Services
snap-in and repadmin.exe will notice that similar functionality is now available from within the Windows
PowerShell for Active Directory context. In addition, the cmdlets are compatible with the existing Windows
PowerShell for Active Directory cmdlets, thus creating a streamlined experience and allowing customers to easily
create automation scripts.
NOTE
The Windows PowerShell for Active Directory replication and topology cmdlets are available in the following environments:
Windows Server 2012 domain controller
Windows Server 2012 with the Remote Server Administration Tools for AD DS and AD LDS installed.
Windows® 8 with the Remote Server Administration Tools for AD DS and AD LDS installed.
Installing the Active Directory Module for Windows PowerShell

The Active Directory Module for Windows PowerShell is installed by default when the AD DS server role is
installed on a server that runs Windows Server 2012 . No additional steps are required other than adding the
server role. You can also install the Active Directory Module on a server that runs Windows Server 2012 by
installing the Remote Server Administration Tools, and you can install the Active Directory Module on a computer
running Windows 8 by downloading and installing the Remote Server Administrative Tools (RSAT). See
Instructionsfor installation steps.
Scenarios for testing Windows PowerShell for Active Directory

replication and topology management cmdlets
The following scenarios are designed for administrators to familiarize themselves with the new management
cmdlets:
Get a list of all domain controllers and their corresponding sites
Manage replication topology
View replication status and information
Lab Requirements
Two Windows Server 2012 domain controllers: DC1 and DC2 that are part of the contoso.com domain and
reside in the CORPORATE site within that domain.
View domain controllers and their sites
In this step, you will use the Active Directory Module for Windows PowerShell to view the existing domain
controllers and the replication topology for the domain.
To complete the steps in the following procedures, you must be a member of the Domain Admins group or have
equivalent permissions.
To view all Active Directory sites
1. On DC1, click Windows PowerShell on the taskbar.
2. Type the following command:
Get-ADReplicationSite -Filter *
This returns detailed information about each site. The Filter parameter is used throughout Active
Directory PowerShell cmdlets to limit the list of objects returned. In this case, the asterisk (*) indicates all site
objects.
TIP
You can use the Tab key to auto-complete commands in Windows PowerShell.
Example: Type Get-ADRep and press Tab multiple times to skip through the matching commands until you reach
Get-ADReplicationSite . Auto-complete also works for parameter names such as Filter .
To format the output from the Get-ADReplicationSite command as a table and limit the display to specific
fields, you can pipe the output to the Format-Table command (or " ft " for short):
Get-ADReplicationSite -Filter * | ft Name
This returns a shorter version of the site list, including only the Name field.
To produce a table of all domain controllers
Type the following command at the Active Directory module for Windows PowerShell prompt:
Get-ADDomainController -Filter * | ft Hostname,Site
This command returns the domain controllers host name as well as their site associations.
Manage replication topology

In the previous step, after running the command, Get-ADDomainController -Filter * | ft Hostname,Site , DC2 was
listed as part of the CORPORATE site. In the procedures below, you will create a new branch office site,
BRANCH1, create a new site link, set the site link cost and replication frequency and then move DC2 to
BRANCH1.
To create a new site
New-ADReplicationSite BRANCH1
This command creates the new branch office site, branch1.

To create a new site link
New-ADReplicationSiteLink 'CORPORATE-BRANCH1' -SitesIncluded CORPORATE,BRANCH1 -OtherAttributes
@{'options'=1}
This command created the site link to BRANCH1 and turned on the change notification process.
TIP
Use Tab to auto-complete parameter names such as -SitesIncluded and -OtherAttributes rather than typing
them out manually.
To set the site link cost and replication frequency

Set-ADReplicationSiteLink CORPORATE-BRANCH1 -Cost 100 -ReplicationFrequencyInMinutes 15
This command sets the site link cost to BRANCH1 at 100 and set the replication frequency with the site to
15 minutes.
To move a domain controller to a different site
Get-ADDomainController DC2 | Move-ADDirectoryServer -Site BRANCH1
This command moves the domain controller, DC2 to the BRANCH1 site.
Verification
To v e r i fy si t e c r e a t i o n , n e w si t e l i n k , a n d c o st a n d r e p l i c a t i o n fr e q u e n c y
Click Server Manager, click Tools and then click Active Directory Sites and Services and verify the
following:
Verify that the BRANCH1 site contains all of the correct values from the Windows PowerShell commands.
Verify the CORPORATE -BRANCH1 site link is created and connects the BRANCH1 and CORPORATE
sites.
Verify DC2 is now in the BRANCH1 site. Alternatively, you can open the Active Directory Module for
Windows PowerShell and type the following command to verify DC2 is now in the BRANCH1 site:
Get-ADDomainController -Filter * | ft Hostname,Site .
View replication status information

In the following procedures, you will use one of the Windows PowerShell for Active Directory replication and
management cmdlets, Get-ADReplicationUpToDatenessVectorTable DC1 , to produce a simple replication report using
the up-to-dateness vector table maintained by each domain controller. This up-to-dateness vector table keeps track
of the highest originating write USN seen from each domain controller in the forest.
To view the up-to-dateness vector table for a single domain controller
1. Type the following command at the Active Directory module for Windows PowerShell prompt:
Get-ADReplicationUpToDatenessVectorTable DC1
This shows a list of the highest USNs seen by DC1 for every domain controller in the forest. The Server
value refers to the server maintaining the table, in this case DC1. The Partner value refers to the replication
partner (direct or indirect) on which changes were made. The UsnFilter value is the highest USN seen by
DC1 from Partner. If a new domain controller is added to the forest, it will not appear in DC1's table until
DC1 receives a change that originated from the new domain.
To view the up-to-dateness vector table for all domain controllers in a domain
1. Type the following command at the Active Directory module for Windows PowerShell prompt:
Get-ADReplicationUpToDatenessVectorTable * | sort Partner,Server | ft Partner,Server,UsnFilter
This command replaces DC1 with * , thus collecting the up-to-dateness vector table data from all domain
controllers. The data is sorted by Partner and Server and then displayed in a table.
The sorting allows you to easily compare the last USN seen by each domain controller for a given
replication partner. This is a quick way to check that replication is occurring across your environment. If
replication is working correctly, the UsnFilter values reported for a given replication partner should be fairly
similar across all domain controllers.
See Also
Advanced Active Directory Replication and Topology Management Using Windows PowerShell (Level 200)
Advanced Active Directory Replication and Topology
Management Using Windows PowerShell (Level 200)
This topic explains the new AD DS replication and topology management cmdlets in more detail, and provides
additional examples. For an introduction, see Introduction to Active Directory Replication and Topology
Management Using Windows PowerShell (Level 100).
1. Introduction
2. Replication and Metadata
3. Get-ADReplicationAttributeMetadata
4. Get-ADReplicationPartnerMetadata
5. Get-ADReplicationFailure
6. Get-ADReplicationQueueOperation and Get-ADReplicationUpToDatenessVectorTable
7. Sync-ADObject
8. Topology
Introduction
Windows Server 2012 extends the Active Directory module for Windows PowerShell with twenty-five new cmdlets
to manage replication and forest topology. Prior to this, you were forced to use the generic *-AdObject nouns or
call .NET functions.
Like all Active Directory Windows PowerShell cmdlets, this new functionality requires installing the Active
Directory Management Gateway Service on at least one domain controller (and preferably, all domain controllers).
The following table lists new replication and topology cmdlets added to the Active Directory Windows PowerShell
module.
Cmdlet Explanation
Get-ADReplicationAttributeMetadata Returns attribute replication metadata for an object
Get-ADReplicationConnection Returns domain controller connection object details
Get-ADReplicationFailure Returns the most replication recent failure for a domain

controller
Get-ADReplicationPartnerMetadata Returns replication configuration of a domain controller
Get-ADReplicationQueueOperation Returns the current replication queue backlog

Get-ADReplicationSite Returns site information
Get-ADReplicationSiteLink Returns site link information
Get-ADReplicationSiteLinkBridge Returns site link bridge information
Get-ADReplicationSubnet Returns AD subnet information
Get-ADReplicationUpToDatenessVectorTable Returns the UTD vector for a domain controller
Get-ADTrust Returns information about an inter-domain or inter-forest

trust
New-ADReplicationSite Creates a new site
New-ADReplicationSiteLink Creates a new site link
New-ADReplicationSiteLinkBridge Creates a new site link bridge
New-ADReplicationSubnet Creates a new AD subnet
Remove-ADReplicationSite Deletes a site
Remove-ADReplicationSiteLink Deletes a site link
Remove-ADReplicationSiteLinkBridge Deletes a site link bridge
Remove-ADReplicationSubnet Deletes an AD subnet
Set-ADReplicationConnection Modifies a connection
Set-ADReplicationSite Modifies a site
Set-ADReplicationSiteLink Modifies a site link
Set-ADReplicationSiteLinkBridge Modifies a site link bridge
Set-ADReplicationSubnet Modifies an AD subnet
Sync-ADObject Forces replication of a single object
Most of these cmdlets have their basis in Repadmin.exe. Other cmdlets (not listed) handle features like Dynamic
Access Control and Group Managed Service Accounts.
For a complete list of all Active Directory Windows PowerShell cmdlets, run:
Get-command -module ActiveDirectory
For a complete list of all Active Directory Windows PowerShell cmdlet arguments, reference the help. For example:
Get-help New-ADReplicationSite
Use the Update-Help cmdlet to download and install help files

Replication and Metadata
Repadmin.exe validates the health and consistency of Active Directory replication. Repadmin.exe offers simple data
manipulation options - some arguments support CSV outputs, for example - but automation generally required
parsing through text file outputs. The Active Directory module for Windows PowerShell is the first attempt at
offering an option that allows real control over the returned data; prior to this, you had to create scripts or use third
party tools.
Additionally, the following cmdlets implement a new parameter set of Target, Scope, and EnumerationServer:
Get-ADReplicationFailure
Get-ADReplicationPartnerMetadata
Get-ADReplicationUpToDatenessVectorTable
The Target argument accepts a comma-separated list of strings that identify the target servers, sites, domains, or
forests specified by the Scope argument. An asterisk (*) is also permissible and means all servers within the
specified scope. If no scope is specified, it implies all servers in the current user's forest. The Scope argument
specifies the latitude of the search. Acceptable values are Server, Site, Domain, and Forest. The
EnumerationServer specifies the server that enumerates the list of domain controllers specified in Target and
Scope. It operates the same as the Server argument and requires the specified server run the Active Directory
Web Service.
To introduce the new cmdlets, here are some sample scenarios showing capabilities impossible to repadmin.exe;
armed with these illustrations, the administrative possibilities become obvious. Review the cmdlet help for specific
usage requirements.
Get-ADReplicationAttributeMetadata
This cmdlet is similar to repadmin.exe /showobjmeta. It enables you to return replication metadata, such as
when an attribute changed, the originating domain controller, the version and USN information, and attribute data.
This cmdlet is useful for auditing where and when a change occurred.
Unlike Repadmin, Windows PowerShell gives flexible search and output control. For example, you can output the
metadata of the Domain Admins object, ordered as a readable list:
Get-ADReplicationAttributeMetadata -object "cn=domain admins,cn=users,dc=corp,dc=contoso,dc=com" -server

dc1.corp.contoso.com -showalllinkedvalues | format-list
Alternatively, you can arrange the data to look like repadmin, in a table:
Get-ADReplicationAttributeMetadata -object "cn=domain admins,cn=users,dc=corp,dc=contoso,dc=com" -server

dc1.corp.contoso.com -showalllinkedvalues | format-table -wrap
Alternatively, you can get metadata for an entire class of objects, by pipelining the Get-Adobject cmdlet with a
filter, such as all groups - then combine that with a specific date. The pipeline is a channel used between multiple
cmdlets to pass data. To see all groups modified in some fashion on January 13th, 2012:
get-adobject -filter 'objectclass -eq "group"' | Get-ADReplicationAttributeMetadata -server

dc1.corp.contoso.com | where-object {$_.lastoriginatingchangetime -like "*1/13/2012*" -and $_.attributename -eq
"name"} | format-table object
For more information about more Windows PowerShell operations with pipelines, see Piping and the Pipeline in
Windows PowerShell.
Alternatively, to find out every group that has Tony Wang as a member and when the group was last modified:
get-adobject -filter 'objectclass -eq "group"' | Get-ADReplicationAttributeMetadata -server

dc1.corp.contoso.com -showalllinkedvalues | where-object {$_.attributevalue -like "*tony wang*"} | format-table
object,LastOriginatingChangeTime,version -auto
Alternatively, to find all objects authoritatively restored using a system state backup in the domain, based on their
artificially high version:
get-adobject -filter 'objectclass -like "*"' | Get-ADReplicationAttributeMetadata -server dc1.corp.contoso.com

| where-object {$_.version -gt "100000" -and $_.attributename -eq "name"} | format-table
object,LastOriginatingChangeTime
Alternatively, send all user metadata to a CSV file for later examination in Microsoft Excel:
get-adobject -filter 'objectclass -eq "user"' | Get-ADReplicationAttributeMetadata -server dc1.corp.contoso.com
-showalllinkedvalues | export-csv allgroupmetadata.csv
Get-ADReplicationPartnerMetadata
This cmdlet returns information about the configuration and state of replication for a domain controller, allowing
you to monitor, inventory, or troubleshoot. Unlike Repadmin.exe, using Windows PowerShell means you see only
the data that is important to you, in the format you want.
For example, the readable replication state of a single domain controller:
Get-ADReplicationPartnerMetadata -target dc1.corp.contoso.com
Alternatively, the last time a domain controller replicated inbound and its partners, in a table format:
Get-ADReplicationPartnerMetadata -target dc1.corp.contoso.com | format-table

lastreplicationattempt,lastreplicationresult,partner -auto
Alternatively, contact all domain controllers in the forest and display any whose last attempted replication failed for
any reason:
Get-ADReplicationPartnerMetadata -target * -scope server | where {$_.lastreplicationresult -ne "0"} | ft

server,lastreplicationattempt,lastreplicationresult,partner -auto
Get-ADReplicationFailure
This cmdlet can be used to returns information about recent errors in replication. It is analogous to Repadmin.exe
/showreplsum, but again, with much more control thanks to Windows PowerShell.
For example, you can return a domain controller's most recent failures and the partners he failed contacting:
Get-ADReplicationFailure dc1.corp.contoso.com
Alternatively, return a table view for all servers in a specific AD logical site, ordered for easier viewing and
containing only the most critical data:
Get-ADReplicationFailure -scope site -target default-first-site-name | format-table

server,firstfailuretime,failurecount,lasterror,partner -auto
Get-ADReplicationQueueOperation and Get-ADReplicationUpToDatenessVectorTable

Both of these cmdlets returns further aspects of domain controller "up to dateness", which includes pending
replication and version vector information.
Sync-ADObject
This cmdlet is analogous to running Repadmin.exe /replsingleobject. It is very useful when you make changes
that require out of band replication, especially to fix an issue.
For example, if someone deleted the CEO's user account and then restored it with the Active Directory Recycle Bin,
you probably want it replicated to all domain controllers immediately. You also probably want to do this without
forcing replication of all the other object changes made ; after all, that is why you have a replication schedule - to
avoid overloading WAN links.
Get-ADDomainController -filter * | foreach {Sync-ADObject -object "cn=tony

wang,cn=users,dc=corp,dc=contoso,dc=com" -source dc1 -destination $_.hostname}
Topology
While Repadmin.exe is good at returning information about replication topology like sites, site links, site link
bridges, and connections, it does not have a comprehensive set of arguments to make changes. In fact, there has
never been scriptable, in-box Windows utility designed specifically for administrators to create and modify AD DS
topology. As Active Directory has matured in millions of customer environments, the need to bulk modify Active
Directory logical information becomes apparent.
For example, after a rapid expansion of new branch offices, combined with the consolidation of others, you might
have a hundred site changes to make based on physical locations, network changes, and new capacity
requirements. Rather than using Dssites.msc and Adsiedit.msc to make changes, you can automate. This is
especially compelling when you start with a spreadsheet of data provided by your network and facilities teams.
The Get-Adreplication\* cmdlets return information about replication topology and are useful for pipelining into
the Set-Adreplication\* cmdlets in bulk. Get cmdlets do not change data, they only show data or to create
Windows PowerShell session objects that can be pipelined to Set-Adreplication\* cmdlets. The New and
Remove cmdlets are useful for creating or removing Active Directory topology objects.
For example, you can create new sites using a CSV file:
import-csv -path C:\newsites.csv | new-adreplicationsite
Alternatively, create a new site link between two existing sites with a custom replication interval and site cost:
new-adreplicationsitelink -name "chicago<-->waukegan" -sitesincluded chicago,waukegan -cost 50 -

replicationfrequencyinminutes 15
Alternatively, find every site in the forest and replace their Options attributes with the flag to enable inter-site
change notification, in order to replicate at maximum speed with compression:
get-adreplicationsitelink -filter * | set-adobject -replace @{options=$($_.options -bor 1)}
IMPORTANT
Set -bor 5 to disable compression on those site links as well.
Alternatively, find all sites missing subnet assignments, in order to reconcile the list with the actual subnets of those
locations:
get-adreplicationsite -filter * -property subnets | where-object {!$_.subnets -eq "*"} | format-table name
See Also
Introduction to Active Directory Replication and Topology Management Using Windows PowerShell (Level 100)
This topic explains the change to the RID master FSMO role, including the new issuance and monitoring
functionality in the RID master and how to analyze and troubleshoot RID issuance.
Troubleshooting RID Issuance
More information is available at the AskDS Blog.

By default, a domain has capacity for roughly one billion security principals, such as users, groups, and computers.
Naturally, there are no domains with that many actively used objects. However, Microsoft Customer Support has
found cases where:
Provisioning software or administrative scripts accidentally bulk created users, groups, and computers.
Many unused security and distribution groups were created by delegated users
Many domain controllers were demoted, restored, or metadata cleaned
Forest recoveries were performed
The InvalidateRidPool operation was performed frequently
The RID Block Size registry value was increased incorrectly
All of these situations use up RIDs unnecessarily, often by mistake. Over many years, a few environments ran out of
RIDs and this forced them to migrate to a new domain or perform forest recoveries.
Windows Server 2012 addresses issues with RID allocation that have only become problematic with the age and
ubiquity of Active Directory. These include better event logging, more appropriate limits, and the ability to - in an
emergency - to double the overall size of the global RID space for a domain.
Periodic Consumption Warnings
Windows Server 2012 adds global RID space event tracking that provides early warning when major milestones
are crossed. The model computes the ten (10) percent used mark in the global pool and logs an event when
reached. Then it computes the next ten percent used of the remaining and the event cycle continues. As the global
RID space is exhausted, events will accelerate as ten percent hits faster in a decreasing pool (but event log
dampening will prevent more than one entry per hour). The System event log on every domain controller writes
Directory-Services-SAM warning event 16658.
Assuming a default 30-bit global RID space, the first event logs when allocating the pool containing the
107,374,182nd RID. The event rate accelerates naturally until the last checkpoint of 100,000, with 110 events
generated in total. The behavior is similar for an unlocked 31-bit global RID space: starting at 214,748,365 and
completing in 117 events.
IMPORTANT
This event is not expected; investigate the user, computer, and group creation processes immediately in the domain. Creating
more than 100 million AD DS objects is quite out of the ordinary.
RID Pool Invalidation Events

There are new event alerts that a local DC RID pool was discarded. These are Informational and could be expected,
especially due to the new VDC functionality. See the event list below for details on the event.
RID Block Size Limit
Ordinarily, a domain controller requests RID allocations in blocks of 500 RIDs at one time. You can override this
default using the following registry REG_DWORD value on a domain controller:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\RID Values
RID Block Size
Prior to Windows Server 2012, there was no maximum value enforced in that registry key, except the implicit
DWORD maximum (which has a value of 0xffffffff or 4294967295). This value is considerably larger than the total
global RID space. Administrators sometimes inappropriately or accidentally configured RID Block Size with values
that exhausted the global RID at a massive rate.
In Windows Server 2012, you cannot set this registry value higher than 15,000 decimal (0x3A98 hexadecimal). This
prevents massive unintended RID allocation.
If you set the value higher than 15,000, the value is treated as 15,000 and the domain controller logs event 16653
in the Directory Services event log at every reboot until the value is corrected.
Global RID Space Size Unlock
Prior to Windows Server 2012, the global RID space was limited to 230 (or 1,073,741,823) total RIDs. Once
reached, only a domain migration or forest recovery to an older timeframe allowed new SIDs creation - disaster
recovery, by any measure. Starting in Windows Server 2012, the 231 bit can be unlocked in order to increase the
global pool to 2,147,483,648 RIDs.
AD DS stores this setting in a special hidden attribute named SidCompatibilityVersion on the RootDSE context
of all domain controllers. This attribute is not readable using ADSIEdit, LDP, or other tools. To see an increase in the
global RID space, examine the System event log for warning event 16655 from Directory-Services-SAM or use the
following Dcdiag command:
Dcdiag.exe /TEST:RidManager /v | find /i "Available RID Pool for the Domain"

If you increase the global RID pool, the available pool will change to 2,147,483,647 instead of the default
1,073,741,823. For example:
WARNING
This unlock is intended only to prevent running out of RIDS and is to be used only in conjunction with RID Ceiling
Enforcement (see next section). Do not "preemptively" set this in environments that have millions of remaining RIDs and low
growth, as application compatibility issues potentially exist with SIDs generated from the unlocked RID pool.
This unlock operation cannot be reverted or removed, except by a complete forest recovery to earlier backups.
Important Caveats
Windows Server 2003 and Windows Server 2008 Domain Controllers cannot issue RIDs when the global RID pool
31st bit is unlocked. Windows Server 2008 R2 domain controllers can use 31st bit RIDs but only if they have hotfix
KB 2642658 installed. Unsupported and unpatched domain controllers treat the global RID pool as exhausted
when unlocked.
This feature is not enforced by any domain functional level; take great care that only Windows Server 2012 or
updated Windows Server 2008 R2 domain controllers exist in the domain.
Implementing Unlocked Global RID space
To unlock the RID pool to the 31st bit after receiving the RID ceiling alert (see below ) perform the following steps:
1. Ensure that the RID Master role is running on a Windows Server 2012 domain controller. If not, transfer it to
a Windows Server 2012 domain controller.
2. Run LDP.exe
3. Click the Connection menu and click Connect for the Windows Server 2012 RID Master on port 389, and
then click Bind as a domain administrator.
4. Click the Browse menu and click Modify.
5. Ensure that DN is blank.
6. In Edit Entry Attribute, type:
SidCompatibilityVersion
7. In Values, type:
8. Ensure that Add is selected in Operation and click Enter. This updates the Entry List.
9. Select the Synchronous and Extended options, then click Run.
10. If successful, the LDP output window shows:
***Call Modify...
ldap_modify_ext_s(Id, '(null)',[1] attrs, SvrCtrls, ClntCtrls);
modified "".
11. Confirm the global RID pool increased by examining the System Event Log on that domain controller for
Directory-Services-SAM Informational event 16655.
RID Ceiling Enforcement
To afford a measure of protection and elevate administrative awareness, Windows Server 2012 introduces an
artificial ceiling on the global RID range at ten (10) percent remaining RIDs in the global space. When within one
(1) percent of the artificial ceiling, domain controllers requesting RID pools write Directory-Services-SAM warning
event 16656 to their System event log. When reaching the ten percent ceiling on the RID Master FSMO, it writes
Directory-Services-SAM event 16657 to its System event log and will not allocate any further RID pools until
overriding the ceiling. This forces you to assess the state of the RID master in the domain and address potential
runaway RID allocation; this also protects domains from exhausting the entire RID space.
This ceiling is hard-coded at ten percent remaining of the available RID space. That is, the ceiling activates when the
RID master allocates a pool that includes the RID corresponding to ninety (90) percent of the global RID space.
For default domains, the first trigger point is 230-1 * 0.90 = 966,367,640 (or 107,374,183 RIDs remaining).
For domains with an unlocked 31-bit RID space, the trigger point is 231-1 * 0.90 = 1,932,735,282 RIDs (or
214,748,365 RIDs remaining).
When triggered, the RID master sets Active Directory attribute msDS -RIDPoolAllocationEnabled (common
name ms-DS -RID -Pool-Allocation-Enabled) to FALSE on the object:
CN=RID Manager$,CN=System,DC=
This writes the 16657 event and prevents further RID block issuance to all domain controllers. Domain controllers
continue to consume any outstanding RID pools already issued to them.
To remove the block and allow RID pool allocation to continue, set that value to TRUE. On the next RID allocation
performed by the RID master, the attribute will return to its default NOT SET value. After that, there are no further
ceilings and eventually, the global RID space runs out, requiring forest recovery or domain migration.
Removing the Ceiling Block
To remove the block once reaching the artificial ceiling, perform the following steps:
1. Ensure that the RID Master role is running on a Windows Server 2012 domain controller. If not, transfer it to
a Windows Server 2012 domain controller.
2. Run LDP.exe.
3. Click the Connection menu and click Connect for the Windows Server 2012 RID Master on port 389, and
then click Bind as a domain administrator.
4. Click the View menu and click Tree, then for the Base DN select the RID Master's own domain naming
context. Click Ok.
5. In the navigation pane, drill down into the CN=System container and click the CN=RID Manager$ object.
Right click it and click Modify.
6. In Edit Entry Attribute, type:
MsDS-RidPoolAllocationEnabled
7. In Values, type (in upper case):
TRUE
8. Select Replace in Operation and click Enter. This updates the Entry List.
9. Enable the Synchronous and Extended options, then click Run:
10. If successful, the LDP output window shows:

***Call Modify...
ldap_modify_ext_s(ld, 'CN=RID Manager$,CN=System,DC=<domain>',[1] attrs, SvrCtrls, ClntCtrls);
Modified "CN=RID Manager$,CN=System,DC=<domain>".
Other RID Fixes

Previous Windows Server operating systems had a RID pool leak when missing rIDSetReferences attribute. To
resolve this problem on domain controllers that run Windows Server 2008 R2, install the hotfix from KB 2618669.
Unfixed RID Issues
There has historically been a RID leak on account creation failure; when creating an account, failure still uses up a
RID. The common example is to create a user with a password that does not meet complexity.
RID Fixes for earlier versions of Windows Server
All of the fixes and changes above have Windows Server 2008 R2 hotfixes released. There are currently no
Windows Server 2008 hotfixes planned or in progress.
Troubleshooting RID Issuance

RID issuance troubleshooting requires a logical and linear method. Unless you are monitoring your event logs
carefully for RID -triggered warnings and errors, your first indications of a problem are likely to be failed account
creations. The key to troubleshooting RID issuance is to understand when the symptom is expected or not; many
RID issuance issues may affect only one domain controller and have nothing to do with component improvements.
This simple diagram below helps make those decisions more clear:
Logging Options
All logging in RID issuance occurs in the System Event log, under source Directory-Services-SAM. Logging is
enabled and configured for maximum verbosity, by default. If no entries are logged for the new component
changes in Windows Server 2012, treat the issue as a classic (aka legacy, pre-Windows Server 2012) RID issuance
problem seen in Windows 2008 R2 or older operating systems.
Utilities and Commands for Troubleshooting
To troubleshoot issues not explained by the aforementioned logs - especially older RID issuance issues - use the
following list of tools as a starting point:
Dcdiag.exe
Repadmin.exe
Network Monitor 3.4
General Methodology for Troubleshooting Domain Controller Configuration
1. Is the error caused by a simple permissions or domain controller availability issue?
a. Are you trying to create a security principal without the necessary permissions? Examine the output
for access denied errors.
b. Is a domain controller available? Examine the returned error or LDAP or domain controller availability
messages.
2. Does the error returned specifically mention RIDs, and is specific enough to use as guidance? If so, follow
the guidance.
3. Does the error returned specifically mention RIDs but is otherwise non-specific? For example, "Windows
cannot create the object because the Directory Service was unable to allocate a relative identifier."
a. Examine the System Event log on the domain controller for "legacy" (pre-Windows Server 2012) RID
events detailed in RID Pool Request (16642, 16643, 16644, 16645, 16656).
b. Examine the System Event on the domain controller and the RID Master for new block-indicating
events detailed below in this topic (16655, 16656, 16657).
c. Validate Active Directory replication health with Repadmin.exe and RID Master availability with
Dcdiag.exe /test:ridmanager /v. Enable double-sided network captures between the domain
controller and the RID Master if these tests are inconclusive.
The following new messages log in the System event log on Windows Server 2012 domain controllers. Automated
AD health tracking systems, such as System Center Operations Manager, should monitor for these events; all are
notable, and some are indicators of critical domain issues.
Event ID 16653
Source Directory-Services-SAM
Severity Warning
Message A pool size for account-identifiers (RIDs) that was configured

by an Administrator is greater than the supported maximum.
The maximum value of %1 will be used when the domain
controller is the RID master.
For more information, see RID Block Size Limit.

Notes and resolution The maximum value for the RID Block Size is now 15000
decimal (3A98 hexadecimal). A domain controller cannot
request more than 15,000 RIDs. This event logs at every boot
until the value is set to a value at or below this maximum.
Event ID 16654
Message A pool of account-identifiers (RIDs) has been invalidated. This

may occur in the following expected cases:
1. A domain controller is restored from backup.
2. A domain controller running on a virtual machine is

restored from snapshot.
3. An administrator has manually invalidated the pool.
See https://go.microsoft.com/fwlink/?LinkId=226247 for more

information.
Notes and resolution If this event is unexpected, contact all domain administrators
and determine which of them performed the action. The
Directory Services event log also contains further information
on when one of these steps was performed.
Event ID 16655
Message The global maximum for account-identifiers (RIDs) has been

increased to %1.
Notes and resolution If this event is unexpected, contact all domain administrators
and determine which of them performed the action. This event
notes the increase of the overall RID pool size beyond the
default of 230 and will not happen automatically; only by
administrative action.
Event ID 16656
Severity Warning
Message The global maximum for account-identifiers (RIDs) has been
increased to %1.
Notes and resolution Action required! An account-identifier (RID) pool was allocated
to this domain controller. The pool value indicates this domain
has consumed a considerable portion of the total available
account-identifiers.
A protection mechanism will be activated when the domain

reaches the following threshold of total available account-
identifiers remaining: %1. The protection mechanism will
prevent account creation until you manually re-enable
account-identifier allocation on the RID master domain
controller.

information.
Event ID 16657
Severity Error
Message Action required! This domain has consumed a considerable

portion of the total available account-identifiers (RIDs). A
protection mechanism has been activated because the total
available account-identifiers remaining is less than: X%
[artificial ceiling argument].
The protection mechanism prevents account creation until you

manually re-enable account-identifier allocation on the RID
master domain controller.
It is extremely important that certain diagnostics are

performed prior to re-enabling account creation to ensure this
domain is not consuming account-identifiers at an abnormally
high rate. Any issues identified should be resolved prior to re-
enabling account creation.
Failure to diagnose and fix any underlying issue causing an

abnormally high rate of account-identifier consumption can
lead to account-identifier exhaustion in the domain after which
account creation will be permanently disabled in this domain.

information.
Notes and resolution Contact all domain administrators and inform them that no
further security principals can be created in this domain until
this protection is overridden. For more information about how
to override the protection and possibly increase the overall
RID pool, see Global RID Space Size Unlock.
Event ID 16658
Severity Warning
Message This event is a periodic update on the remaining total quantity

of available account-identifiers (RIDs). The number of
remaining account-identifiers is approximately: %1.
Account-identifiers are used as accounts are created, when

they are exhausted no new accounts may be created in the
domain.

information.
Notes and resolution Contact all domain administrators and inform them that RID
consumption has crossed a major milestone; determine if this
is expected behavior or not by reviewing security trustee
creation patterns. To ever see this event would be highly
unusual, as it means that at least ~100 million RIDS have been
allocated.
See Also
Managing RID Issuance in Windows Server 2012
Active Directory Domain Services Component
Updates
Applies To: Windows Server 2016, Windows Server 2012 R2
This module introduces the components that received minor updates in the Directory Services and Identity spaces.
ABOUT THE AUTHOR
Author:
Bio:
Contributors
Reviewers
NOTE
This content is written by a Microsoft customer support engineer, and is intended for experienced administrators and systems
architects who are looking for deeper technical explanations of features and solutions in Windows Server 2012 R2 than topics
on TechNet usually provide. However, it has not undergone the same editing passes, so some of the language may seem less
polished than what is typically found on TechNet.
What You Will Learn

After completing this module, you will be able to:
Explain the component updates made within the Directory Services and Identity technology areas in
Winlogon Automatic Restart Sign-On (ARSO )
TPM Key Attestation
CA Backup and Restore Windows PowerShell cmdlets
Credentials Protection and Management
Domain and Forest Functional Levels
Deprecation of NTFRS
LDAP Query Optimizer changes
1644 Event improvements
Active Directory Replication throughput improvement
Identity component updates
Lesson 1: Identity component updates

This lesson explains the Identity component updates in Windows Server 2012 R2.
What You Will Learn
After completing this lesson, you will be able to:
Describe the following changes:
Winlogon Automatic Restart Sign-On (ARSO )
TPM Key Attestation
Credentials Protection and Management
Author: Justin Turner, Senior Support Escalation Engineer with the Windows group
NOTE
NOTE
Overview
Domain Controllers running Windows Server 2012 R2 block the creation of duplicate service principal names
(SPN ) and user principal names (UPN ). This includes if the restoration or reanimation of a deleted object or the
renaming of an object would result in a duplicate.
Background
Duplicate Service Principal Names (SPN ) commonly occur and result in authentication failures and may lead to
excessive LSASS CPU utilization. There is no in-box method to block the addition of a duplicate SPN or UPN. *
Duplicate UPN values break synchronization between on-premises AD and Office 365.
*Setspn.exe is commonly used to create new SPNs, and functionally was built into the version released with
Windows Server 2008 that adds a check for duplicates.
Table SEQ Table \* ARABIC 1: UPN and SPN uniqueness
FEATURE COMMENT
UPN uniqueness Duplicate UPNs break synchronization of on-premises AD

accounts with Windows Azure AD-based services such as
Office 365.
SPN uniqueness Kerberos requires SPNs for mutual authentication. Duplicate

SPNs result in authentication failures.
For more information about uniqueness requirements for UPNs and SPNs, see Uniqueness Constraints.
Symptoms
Error codes 8467 or 8468 or their hex, symbolic or string equivalents are logged in various on-screen dialogues
and in event ID 2974 in the Directory Services event log. The attempt to create a duplicate UPN or SPN is blocked
only under the following circumstances:
The write is processed by a Windows Server 2012 R2 DC
Table SEQ Table \* ARABIC 2: UPN and SPN uniqueness error codes
DECIMAL HEX SYMBOLIC STRING
8467 21C7 ERROR_DS_SPN_VALUE_NOT The operation failed because

_UNIQUE_IN_FOREST SPN value provided for
addition/modification is not
unique forest-wide.
8648 21C8 ERROR_DS_UPN_VALUE_NO The operation failed because

T_UNIQUE_IN_FOREST UPN value provided for
addition/modification is not
unique forest-wide.
New user creation fails if UPN is not unique

DSA.msc
The user logon name you have chosen is already in use in this enterprise. Choose another logon name, and then try
again.
Modify an existing account:

The specified user logon name already exists in the enterprise. Specify a new one, either by changing the prefix or
selecting a different suffix from the list.
Active Directory Administrative Center (DSAC.exe )

An attempt to create a new user in Active Directory Administrative Center with a UPN that already exists will yield
the following error.
Figure SEQ Figure \* ARABIC 1 error displayed in AD Administrative Center when new user creation fails
due to duplicate UPN
Event 2974 Source: ActiveDirectory_DomainService
Figure SEQ Figure \* ARABIC 2 Event ID 2974 with error 8648
The event 2974 lists the value that was blocked and a list of one or more objects (up to 10) that already contain that
value. In the following figure, you can see that UPN attribute value dhunt@blue.contoso.com already exists on
four other objects. Since this is a new feature in Windows Server 2012 R2, accidental creation of duplicate UPN
and SPNs in a mixed environment will still occur when down-level DCs process the write attempt.
Figure SEQ Figure \* ARABIC 3 Event 2974 showing all objects containing the duplicate UPN
TIP
Review event ID 2974s regularly to:
identify attempts to create duplicate UPN or SPNs
identify objects that already contain duplicates
8648 = "The operation failed because UPN value provided for addition/modification is not unique forest-wide."
SetSPN:
Setspn.exe has had duplicate SPN detection built-in to it since the Windows Server 2008 release when using the "-
S" option. You can bypass the duplicate SPN detection by using the "-A" option however. Creation of a duplicate
SPN is blocked when targeting a Windows Server 2012 R2 DC using SetSPN with the -A option. The error
message displayed is the same as the one displayed when using the -S option: "Duplicate SPN found, aborting
operation!"
ADSIEDIT:
Operation failed. Error code: 0x21c8

The operation failed because UPN value provided for addition/modification is not unique forest-wide.
000021C8: AtrErr: DSID-03200BBA, #1: 0: 000021C8: DSID-03200BBA, problem 1005 (CONSTRAINT_ATT_TYPE), data 0,
Att 90290 (userPrincipalName)
Figure SEQ Figure \* ARABIC 4 Error message displayed in ADSIEdit when addition of duplicate UPN is
blocked
Windows PowerShell
Windows Server 2012 R2:
PS running from Server 2012 targeting a Windows Server 2012 R2 DC:
DSAC.exe running on Windows Server 2012 targeting a Windows Server 2012 R2 DC:
Figure SEQ Figure \* ARABIC 5 DSAC user creation error on non-Windows Server 2012 R2 while
targeting Windows Server 2012 R2 DC
Figure SEQ Figure \* ARABIC 6 DSAC user modification error on non-Windows Server 2012 R2 while
targeting Windows Server 2012 R2 DC
Restore of an object that would result in a duplicate UPN fails:
No event is logged when an object fails to restore because of a duplicate UPN / SPN.
The UPN of the object must be unique in order for it to be restored.
1. Identify the UPN that exists on the object in the Recycle Bin
2. Identify all objects that have the same value
3. Remove the duplicate UPN (s)
Identify the conflicting UPN on the deleted objectUsing repadmin.exe
Repadmin /showattr DCName "DN of deleted objects container" /subtree /filter:"(msDS-LastKnownRDN=<NAME>)"

/deleted /atts:userprincipalname
repadmin /showattr DCName "CN=Deleted Objects,DC=blue,DC=contoso,DC=com" /subtree /filter:"(msDS-

LastKnownRDN=Dianne Hunt2)" /deleted /atts:userprincipalname
C:\>repadmin /showattr winbluedc1 "cn=deleted objects,dc=blue,dc=contoso,dc=com" /subtree /filter:"(msds-

lastknownrdn=Dianne Hunt2)" /deleted /atts:userprincipalname
DN: CN=Dianne Hunt2\0ADEL:dd3ab8a4-3005-4f2f-814f-d6fc54a1a1c0,CN=Deleted Object
s,DC=blue,DC=contoso,DC=com
1> userPrincipalName: dhunt@blue.contoso.com
To identify all objects with the same UPN:Using Repadmin.exe
repadmin /showattr WinBlueDC1 "DC=blue,DC=contoso,DC=com" /subtree /filter:"

(userPrincipalName=dhunt@blue.contoso.com)" /deleted /atts:DN
C:\>repadmin /showattr winbluedc1 "dc=blue,dc=contoso,dc=com" /subtree /filter:"

(userPrincipalName=dhunt@blue.contoso.com)" /deleted /atts:DN
DN: CN=Administrator,CN=Users,DC=blue,DC=contoso,DC=com
DN: CN=xouser1,CN=Users,DC=blue,DC=contoso,DC=com
DN: CN=Dianne Hunt,OU=Marketing,DC=blue,DC=contoso,DC=com
DN: CN=Dianne Hunt2\0ADEL:dd3ab8a4-3005-4f2f-814f-d6fc54a1a1c0,CN=Deleted Objects,DC=blue,DC=contoso,DC=com
TIP
The previously undocumented /deleted parameter in repadmin.exe is used to include deleted objects in the result set
Using Global Search

Open Active Directory Administrative Center and navigate to Global Search
Select the Convert to LDAP radio button
Type (userPrincipalName=ConflictingUPN )
Replace ConflictingUPN with the actual UPN that is in conflict
Select Apply
Using Windows PowerShell
Get-ADObject -LdapFilter "(userPrincipalName=dhunt@blue.contoso.com)" -IncludeDeletedObjects -SearchBase

"DC=blue,DC=Contoso,DC=com" -SearchScope Subtree -Server winbluedc1.blue.contoso.com
If the object needs to be restored, you will need remove the duplicate UPNs from the other objects. For only one
object, it is simple enough to use ADSIEdit to remove the duplicate. If there are multiple objects with duplicates,
then Windows PowerShell might be the better tool to use.
To null out the UserPrincipalName attribute using Windows PowerShell:
NOTE
The userPrincipalName attribute is single-valued attribute, so this procedure will only remove the duplicate UPN.
Duplicate SPN
Figure SEQ Figure \* ARABIC 8 Error message displayed in ADSIEdit when addition of duplicate SPN is
blocked
Logged in the Directory Services event log is an ActiveDirectory_DomainService event ID 2974.
Operation failed. Error code: 0x21c7

The operation failed
The attribute value provided is not unique in the forest or partition. Attribute:
servicePrincipalName Value=<SPN>
<Object DN> Winerror: 8467
Figure SEQ Figure \* ARABIC 9 Error logged when creation of duplicate SPN is blocked
Workflow
If DC == GC
No offbox call required, query can be satisfied locally
UPN case
Query local forest-wide UPN index for supplied UPN (userPrincipalName; a global index)
If entries returned == 0 -> write proceeds
If entries returned !=0 -> write fails
Event logged
Also returns extended error:
8648:
ERROR_DS_UPN_VALUE_NOT_UNIQUE_IN_FOREST
SPN case
Query local forest-wide SPN index for supplied SPN (servicePrincipalName; a global index)
Event logged
8647:
ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST
If DC != GC
Offbox call desirable but not critical, i.e. this is a best-effort uniqueness check
Check proceeds against local DIT only if GC cannot be located
Event logged to indicate such
UPN case
Submit LDAP query against closest GC ? query GC's forest-wide UPN index for supplied UPN
(userPrincipalName; a global index)
Event logged
8648:
ERROR_DS_UPN_VALUE_NOT_UNIQUE_IN_FOREST
SPN case
Submit LDAP query against closest GC ? query GC's forest-wide SPN index for supplied SPN
(servicePrincipalName; a global index)
Event logged
8647:
ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST
When deleted objects are re-animated, SPN or UPN values present are checked for uniqueness. If a duplicate is
found, the request fails.
For certain attribute changes like DNS Host Name, SAM Account Name etc, when the modification is made,
SPNs are updated accordingly. In the process, the obsolete SPNs are deleted and new SPNs are constructed
and added to the database. The requisite attribute modifications against which this path is triggered are:
ATT_DNS_HOST_NAME
ATT_MS_DS_ADDITIONAL_DNS_HOST_NAME
ATT_SAM_ACCOUNT_NAME
ATT_MS_DS_ADDITIONAL_SAM_ACCOUNT_NAME
ATT_SERVER_REFERENCE_BL
ATT_USER_ACCOUNT_CONTROL
If any of the new SPN value is a duplicate, we fail the modification. Of the above list, the important attributes are
ATT_DNS_HOST_NAME (Machine name) and ATT_SAM_ACCOUNT_NAME (SAM Account Name).
Try This: Exploring SPN and UPN uniqueness
This is the first of several "Try This" activities in the module. There is not a separate lab guide for this module. The
Try This activities are essentially free-form activities that allow you explore the lesson material in the lab
environment. You have the option of following the prompt or going off script and come up with your own activity.
NOTE
This is the first of several "Try This" activities.
There is not a separate lab guide for this module.
The Try This activities are essentially free-form activities that allow you explore the lesson material in the lab environment.
You have the option of following the prompt or going off script and come up with your own activity.
While not all sections have a Try This prompt, you are still encouraged to explore the lesson content in the lab where
appropriate.
Experiment with SPN and UPN uniqueness. Follow these prompts, or complete your own.
1. Create new users with UPN
2. Create accounts with SPNs
3. Either create a new user with a UPN already previously defined or change an existing account's UPN. Do the
same for a SPN on another account
a. Populate an existing user account with a UPN already in use
a. Using PowerShell, ADSIEDIT, or Active Directory Administrative Center (DSAC.exe)
b. Populate an existing account with an SPN already in use
a. Using Windows PowerShell, ADSIEDIT, or SetSPN
4. Observe the errors
Optionally
1. Verify with the classroom instructor that it is ok to enable the AD Recycle Bin in Active Directory
Administrative Center. If so, move on to the next step.
2. Populate the UPN on a user account
3. Delete the account
4. Populate a different account with the same UPN as the deleted account
5. Attempt to use the Recycle Bin GUI to restore the account
6. Imagine you have just been presented with the error you see in the previous step. (and don't have a history
of the steps you just performed)Your goal is to complete the restore of the account. See the workbook for
example steps.
Winlogon Automatic Restart Sign-On (ARSO)
NOTE
Overview
Windows 8 introduced lock screen apps. These are the applications that run and display notifications while the
user's session is locked (calendar appointments, email and messages, etc.). Devices that are restarted due to the
Windows Update process fail to display these lock screen notifications upon restart. Some users depend on these
lock screen applications.
What's changed?
When a user signs in on a Windows 8.1 device, LSA will save the user credentials in encrypted memory accessible
only by lsass.exe. When Windows Update initiates an automatic reboot without user presence, these credentials will
be used to configure Autologon for the user. Windows Update running as system with TCB privilege will initiate the
RPC call to do this.
On rebooting, the user will automatically be signed in via the Autologon mechanism and then additionally locked to
protect the user's session. The locking will be initiated via Winlogon whereas the credential management is done by
LSA. By automatically signing on and locking the user on the console, the user's lock screen applications will be
restarted and available.
NOTE
After a Windows Update induced reboot, the last interactive user is automatically signed on and the session is locked so the
user's lock screen apps can run.
Quick Overview
Windows Update requires restart
Is computer able to restart ( no apps running that would lose data)?
Restart for you
Log back in
Lock machine
Enabled or disabled by Group Policy
Disabled by default in server SKUs
Why?
Some updates cannot finish until the user logs back in.
Better user experience: don't have to wait 15 minutes for updates to finish installing
How? AutoLogon
stores password, uses that credential to log you in
saves credential as an LSA secret in paged memory
Can only be enabled if BitLocker is enabled
Group Policy: Sign-in last interactive user automatically after a system-

initiated restart
In Windows 8.1 / Windows Server 2012 R2, autologon of the lock screen user after a Windows Update restart is
opt in for Server SKUs and opt out for Client SKUs.
Policy location: Computer Configuration > Policies > Administrative Templates > Windows Components >
Windows Logon Option
Policy Name: Sign-in last interactive user automatically after a system-initiated restart
Supported on: At least Windows Server 2012 R2, Windows 8.1 or Windows RT 8.1
Description/Help:
This policy setting controls whether a device will automatically sign-in the last interactive user after Windows
Update restarts the system.
If you enable or do not configure this policy setting, the device securely saves the user's credentials (including the
user name, domain, and encrypted password) to configure automatic sign-in after a Windows Update restart. After
the Windows Update restart, the user is automatically signed-in and the session is automatically locked with all the
lock screen apps configured for that user.
If you disable this policy setting, the device does not store the user's credentials for automatic sign-in after a
Windows Update restart. The users' lock screen apps are not restarted after the system restarts.
Registry Editor
VALUE NAME TYPE DATA
DisableAutomaticRestartSignOn DWORD 0
Example:
0 (Enabled)
1 (Disabled)
Policy Registry Location: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Type: DWORD
Registry Name: DisableAutomaticRestartSignOn
Value: 0 or 1
0 = Enabled
1 = Disabled
Troubleshooting
When WinLogon automatically locks, WinLogon's state trace will be stored in the WinLogon event log.
The status of an Autologon configuration attempt is logged
If it is successful
records it as such
If it is a failure:
records what the failure was
When BitLocker's state changes:
the removal of credentials will be logged
These will be stored in the LSA Operational log.
Reasons why autologon might fail
There are several cases in which a user automatic login cannot be achieved. This section is intended to capture the
known scenarios in which this can occur.
User Must Change Password at Next Login
User login can enter a blocked state when password change at next login is required. This can be detected prior to
restart in most cases, but not all (for example, password expiry can be reached between shutdown and next login.
User Account Disabled
An existing user session can be maintained even if disabled. Restart for an account that is disabled can be detected
locally in most cases in advance, depending on gp it may not be for domain accounts (some domain cached login
scenarios work even if account is disabled on DC ).
Logon Hours and Parental Controls
The Logon Hours and parental controls can prohibit a new user session from being created. If a restart were to
occur during this window, the user would not be permitted to login. There is additional policy that causes lock or
logout as a compliance action. This could be problematic for many child cases where account lockdown may occur
between bed time and wake-up, particularly if the maintenance window is commonly during this time.
Table SEQ Table \* ARABIC 3: ARSO Glossary
TERM DEFINITION
Autologon Autologon is a feature that has been present in Windows for

several releases. It is a documented feature of Windows that
even has tools such as Autologon for Windows v3.01
http:/technet.microsoft.com/sysinternals/bb963905.aspx
It allows a single user of the device to sign in automatically

without entering credentials. The credentials are configured
and stored in registry as an encrypted LSA secret.
TPM Key Attestation
NOTE
Overview
While support for TPM -protected keys has existed since Windows 8, there were no mechanisms for CAs to
cryptographically attest that the certificate requester private key is actually protected by a Trusted Platform Module
(TPM ). This update enables a CA to perform that attestation and to reflect that attestation in the issued certificate.
NOTE
This article assumes that the reader is familiar with certificate template concept (for reference, see Certificate Templates). It
also assumes that the reader is familiar with how to configure enterprise CAs to issue certificates based on certificate
templates (for reference, see Checklist: Configure CAs to Issue and Manage Certificates).
Terminology
TERM DEFINITION
EK Endorsement Key. This is an asymmetric key contained inside

the TPM (injected at manufacturing time). The EK is unique for
every TPM and can identify it. The EK cannot be changed or
removed.
EKpub Refers to public key of the EK.
EKPriv Refers to private key of the EK.
EKCert EK Certificate. A TPM manufacturer-issued certificate for

EKPub. Not all TPMs have EKCert.
TPM Trusted Platform Module. A TPM 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.
Background
Beginning with Windows 8, a Trusted Platform Module (TPM ) can be used to secure a certificate's private key. The
Microsoft Platform Crypto Provider Key Storage Provider (KSP ) enables this feature. There were two concerns with
the implementation:
There was no guarantee that a key is actually protected by a TPM (someone can easily spoof a software KSP
as a TPM KSP with local administrator credentials).
It was not possible to limit the list of TPMs that are allowed to protect enterprise issued certificates (in the
event that the PKI Administrator wants to control the types of devices that can be used to obtain certificates
in the environment).
TPM key attestation
TPM key attestation is the ability of the entity requesting a certificate to cryptographically prove to a CA that the
RSA key in the certificate request is protected by either "a" or "the" TPM that the CA trusts. The TPM trust model is
discussed more in the Deployment overview section later in this topic.
Why is TPM key attestation important?
A user certificate with a TPM -attested key provides higher security assurance, backed up by non-exportability, anti-
hammering, and isolation of keys provided by the TPM.
With TPM key attestation, a new management paradigm is now possible: An administrator can define the set of
devices that users can use to access corporate resources (for example, VPN or wireless access point) and have
strong guarantees that no other devices can be used to access them. This new access control paradigm is strong
because it is tied to a hardware-bound user identity, which is stronger than a software-based credential.
How does TPM key attestation work?
In general, TPM key attestation is based on the following pillars:
1. Every TPM ships with a unique asymmetric key, called the Endorsement Key (EK), burned by the
manufacturer. We refer to the public portion of this key as EKPub and the associated private key as EKPriv.
Some TPM chips also have an EK certificate that is issued by the manufacturer for the EKPub. We refer to
this cert as EKCert.
2. A CA establishes trust in the TPM either via EKPub or EKCert.
3. A user proves to the CA that the RSA key for which the certificate is being requested is cryptographically
related to the EKPub and that the user owns the EKpriv.
4. The CA issues a certificate with a special issuance policy OID to denote that the key is now attested to be
protected by a TPM.
Deployment overview
In this deployment, it is assumed that a Windows Server 2012 R2 enterprise CA is set up. Also, clients (Windows
8.1) are configured to enroll against that enterprise CA using certificate templates.
There are three steps to deploying TPM key attestation:
1. Plan the TPM trust model: The first step is to decide which TPM trust model to use. There are 3 supported
ways for doing this:
Trust based on user credential: The enterprise CA trusts the user-provided EKPub as part of the
certificate request and no validation is performed other than the user's domain credentials.
Trust based on EKCert: The enterprise CA validates the EKCert chain that is provided as part of the
certificate request against an administrator-managed list of acceptable EK cert chains. The acceptable
chains are defined per-manufacturer and are expressed via two custom certificate stores on the
issuing CA (one store for the intermediate and one for root CA certificates). This trust mode means
that all TPMs from a given manufacturer are trusted. Note that in this mode, TPMs in use in the
environment must contain EKCerts.
Trust based on EKPub: The enterprise CA validates that the EKPub provided as part of the
certificate request appears in an administrator-managed list of allowed EKPubs. This list is expressed
as a directory of files where the name of each file in this directory is the SHA-2 hash of the allowed
EKPub. This option offers the highest assurance level but requires more administrative effort, because
each device is individually identified. In this trust model, only the devices that have had their TPM's
EKPub added to the allowed list of EKPubs are permitted to enroll for a TPM -attested certificate.
Depending on which method is used, the CA will apply a different issuance policy OID to the issued
certificate. For more details about issuance policy OIDs, see the Issuance Policy OIDs table in the Configure
a certificate template section in this topic.
Note that it is possible to choose a combination of TPM trust models. In this case, the CA will accept any of
the attestation methods, and the issuance policy OIDs will reflect all attestation methods that succeed.
2. Configure the certificate template: Configuring the certificate template is described in the Deployment
details section in this topic. This article does not cover how this certificate template is assigned to the
enterprise CA or how enroll access is given to a group of users. For more information, see Checklist:
Configure CAs to Issue and Manage Certificates.
3. Configure the CA for the TPM trust model
a. Trust based on user credential: No specific configuration is required.
b. Trust based on EKCert: The administrator must obtain the EKCert chain certificates from TPM
manufacturers, and import them to two new certificate stores, created by the administrator, on the CA
that perform TPM key attestation. For more information, see the CA configuration section in this
topic.
c. Trust based on EKPub: The administrator must obtain the EKPub for each device that will need
TPM -attested certificates and add them to the list of allowed EKPubs. For more information, see the
CA configuration section in this topic.
NOTE
This feature requires Windows 8.1/Windows Server 2012 R2.
TPM key attestation for third-party smart card KSPs is not supported. Microsoft Platform Crypto Provider KSP
must be used.
TPM key attestation only works for RSA keys.
TPM key attestation is not supported for a standalone CA.
TPM key attestation does not support non-persistent certificate processing.
Deployment details
Configure a certificate template
To configure the certificate template for TPM key attestation, do the following configuration steps:
1. Compatibility tab
In the Compatibility Settings section:
Ensure Windows Server 2012 R2 is selected for the Certification Authority.
Ensure Windows 8.1 / Windows Server 2012 R2 is selected for the Certificate recipient.
2. Cryptography tab
Ensure Key Storage Provider is selected for the Provider Category and RSA is selected for the
Algorithm name. Ensure Requests must use one of the following providers is selected and the
Microsoft Platform Crypto Provider option is selected under Providers.
3. Key Attestation tab
This is a new tab for Windows Server 2012 R2:
Choose an attestation mode from the three possible options.
None: Implies that key attestation must not be used

Required, if client is capable: Allows users on a device that does not support TPM key attestation
to continue enrolling for that certificate. Users who can perform attestation will be distinguished with
a special issuance policy OID. Some devices might not be able to perform attestation because of an
old TPM that does not support key attestation, or the device not having a TPM at all.
Required: Client must perform TPM key attestation, otherwise the certificate request will fail.
Then choose the TPM trust model. There are again three options:
User credentials: Allow an authenticating user to vouch for a valid TPM by specifying their domain
credentials.
Endorsement certificate: The EKCert of the device must validate through administrator-managed
TPM intermediate CA certificates to an administrator-managed root CA certificate. If you choose this
option, you must set up EKCA and EKRoot certificate stores on the issuing CA as described in the CA
configuration section in this topic.
Endorsement Key: The EKPub of the device must appear in the PKI administrator-managed list. This
option offers the highest assurance level but requires more administrative effort. If you choose this
option, you must set up an EKPub list on the issuing CA as described in the CA configuration section
in this topic.
Finally, decide which issuance policy to show in the issued certificate. By default, each enforcement type has
an associated object identifier (OID ) that will be inserted into the certificate if it passes that enforcement
type, as described in the following table. Note that it is possible to choose a combination of enforcement
methods. In this case, the CA will accept any of the attestation methods, and the issuance policy OID will
reflect all attestation methods that succeeded.
Issuance Policy OIDs
OID KEY ATTESTATION TYPE DESCRIPTION ASSURANCE LEVEL
1.3.6.1.4.1.311.21.30 EK "EK Verified": For High

administrator-managed list
of EK
1.3.6.1.4.1.311.21.31 Endorsement certificate "EK Certificate Verified": Medium

When EK certificate chain
is validated
1.3.6.1.4.1.311.21.32 User credentials "EK Trusted on Use": For Low

user-attested EK
The OIDs will be inserted into the issued certificate if Include Issuance Policies is selected (the default
configuration).
TIP
One potential use of having the OID present in the certificate is to limit access to VPN or wireless networking to
certain devices. For example, your access policy might allow connection (or access to a different VLAN) if OID
1.3.6.1.4.1.311.21.30 is present in the certificate. This allows you to limit access to devices whose TPM EK is present in
the EKPUB list.
CA configuration
1. Setup EKCA and EKROOT certificate stores on an issuing CA
If you chose Endorsement Certificate for the template settings, do the following configuration steps:
a. Use Windows PowerShell to create two new certificate stores on the certification authority (CA)
server that will perform TPM key attestation.
b. Obtain the intermediate and root CA certificate(s) from manufacturer(s) that you want to allow in
your enterprise environment. Those certificates must be imported into the previously-created
certificate stores (EKCA and EKROOT) as appropriate.
The following Windows PowerShell script performs both of these steps. In the following example, the TPM
manufacturer Fabrikam has provided a root certificate FabrikamRoot.cer and an issuing CA certificate
Fabrikamca.cer.
PS C:>\cd cert:
PS Cert:\>cd .\\LocalMachine
PS Cert:\LocalMachine> new-item EKROOT
PS Cert:\ LocalMachine> new-item EKCA
PS Cert:\EKCA\copy FabrikamCa.cer .\EKCA
PS Cert:\EKROOT\copy FabrikamRoot.cer .\EKROOT
2. Setup EKPUB List if using EK attestation type

If you chose Endorsement Key in the template settings, the next configuration steps are to create and
configure a folder on the issuing CA, containing 0-byte files, each named for the SHA-2 hash of an allowed
EK. This folder serves as an "allow list" of devices that are permitted to obtain TPM key-attested certificates.
Because you must manually add the EKPUB for each and every device that requires an attested certificate, it
provides the enterprise with a guarantee of the devices that are authorized to obtain TPM key attested
certificates. Configuring a CA for this mode requires two steps:
a. Create the EndorsementKeyListDirectories registry entry: Use the Certutil command-line tool to
configure the folder locations where trusted EKpubs are defined as described in the following table.
OPERATION COMMAND SYNTAX
Add folder locations certutil.exe -setreg CA\EndorsementKeyListDirectories

+""
Remove folder locations certutil.exe -setreg CA\EndorsementKeyListDirectories

-""
The EndorsementKeyListDirectories in certutil command is a registry setting as described in the

following table.
VALUE NAME TYPE DATA
EndorsementKeyListDirectories REG_MULTI_SZ <LOCAL or UNC path to EKPUB

allow list(s)>
Example:
\\blueCA.contoso.com\ekpub
\\bluecluster1.contoso.com\ekpub
D:\ekpub
HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\
EndorsementKeyListDirectories will contain a list of UNC or local file system paths, each pointing to a
folder that the CA has Read access to. Each folder may contain zero or more allow list entries, where
each entry is a file with a name that is the SHA-2 hash of a trusted EKpub, with no file extension.
Creating or editing this registry key configuration requires a restart of the CA, just like existing CA
registry configuration settings. However, edits to the configuration setting will take effect immediately
and will not require the CA to be restarted.
IMPORTANT
Secure the folders in the list from tampering and unauthorized access by configuring permissions so that only
authorized administrators have Read and Write access. The computer account of the CA requires Read access
only.
b. Populate the EKPUB list: Use the following Windows PowerShell cmdlet to obtain the public key
hash of the TPM EK by using Windows PowerShell on each device and then send this public key hash
to the CA and store it on the EKPubList folder.
PS C:>\$a=Get-TpmEndorsementKeyInfo -hashalgorithm sha256

PS C:>$b=new-item $a.PublicKeyHash -ItemType file
Troubleshooting
Key attestation fields are unavailable on a certificate template
The Key Attestation fields are not available if the template settings do not meet the requirements for attestation.
Common reasons are:
1. The compatibility settings are not configured correctly. Make sure that they are configured as follows:
a. Certification Authority: Windows Server 2012 R2
b. Certificate Recipient: Windows 8.1/Windows Server 2012 R2
2. The cryptography settings are not configured correctly. Make sure that they are configured as follows:
a. Provider Category: Key Storage Provider
b. Algorithm Name: RSA
c. Providers: Microsoft Platform Crypto Provider
3. The request handling settings are not configured correctly. Make sure that they are configured as follows:
a. The Allow private key to be exported option must not be selected.
b. The Archive subject's encryption private key option must not be selected.
Verification of TPM device for attestation
Use the Windows PowerShell cmdlet, Confirm -CAEndorsementKeyInfo, to verify that a specific TPM device is
trusted for attestation by CAs. There are two options: one for verifying the EKCert, and the other for verifying an
EKPub. The cmdlet is either run locally on a CA, or on remote CAs by using Windows PowerShell remoting.
1. For verifying trust on an EKPub, do the following two steps:
a. Extract the EKPub from the client computer: The EKPub can be extracted from a client computer
via Get-TpmEndorsementKeyInfo. From an elevated command prompt, run the following:
PS C:>\$a=Get-TpmEndorsementKeyInfo -hashalgorithm sha256
b. Verify trust on an EKCert on a CA computer: Copy the extracted string (the SHA-2 hash of the
EKPub) to the server (for example, via email) and pass it to the Confirm-CAEndorsementKeyInfo
cmdlet. Note that this parameter must be 64 characters.
Confirm-CAEndorsementKeyInfo [-PublicKeyHash] <string>
2. For verifying trust on an EKCert, do the following two steps:

a. Extract the EKCert from the client computer: The EKCert can be extracted from a client computer
via Get-TpmEndorsementKeyInfo. From an elevated command prompt, run the following:
PS C:>\$a=Get-TpmEndorsementKeyInfo
PS C:>\$a.manufacturerCertificates|Export-Certificate -filepath c:\myEkcert.cer
b. Verify trust on an EKCert on a CA computer: Copy the extracted EKCert (EkCert.cer) to the CA (for
example, via email or xcopy). As an example, if you copy the certificate file the "c:\diagnose" folder on
the CA server, run the following to finish verification:
PS C:>new-object System.Security.Cryptography.X509Certificates.X509Certificate2
"c:\diagnose\myEKcert.cer" | Confirm-CAEndorsementKeyInfo
See Also
Trusted Platform Module Technology Overview
External Resource: Trusted Platform Module
NOTE
Overview
The ADCSAdministration Windows PowerShell module was introduced in Window Server 2012. Two new cmdlets
were added to this module in Window Server 2012 R2 to support the Backup and Restore of a CA.
Backup-CARoleService
Restore-CARoleService
Backup-CARoleService
Table SEQ Table \* ARABIC 17: Backup and Restore Windows PowerShell Cmdlets
ADCSAdministration Cmdlet: Backup-CARoleService
ARGUMENTS - BOLD ARGUMENTS ARE REQUIRED DESCRIPTION
-Path - String - location to save the backup

- This is the only unnamed parameter
- positional parameter
Example:
Backup-CARoleService.-Path c:\adcsbackup1
Backup-CARoleService c:\adcsbackup2
-KeyOnly - Backup the CA certificate without the database
Example:
Backup-CARoleService c:\adcsbackup3 -KeyOnly

-Password - Specifies the password to protect CA certificates and private

keys
- Must be a secure string
- Not valid with the -DatabaseOnly parameter
Example:
Backup-CARoleService c:\adcsbackup4 -Password (Read-Host -

prompt "Password:" -AsSecureString)
Backup-CARoleService c:\adcsbackup5 -Password (ConvertTo-

SecureString "Pa55w0rd!" -AsPlainText -Force)
-DatabaseOnly - Backup the database without the CA certificate
Backup-CARoleService c:\adcsbackup6 -DatabaseOnly
-Force 1. Allows you to overwrite the backup that preexists in the

location specified in the -Path parameter
Backup-CARoleService c:\adcsbackup1 -Force
-Incremental - Perform an incremental backup
Backup-CARoleService c:\adcsbackup7 -Incremental
-KeepLog 1. Instructs the command to keep log files. If the switch is not
specified, log files are truncated by default except in the
Incremental scenario
Backup-CARoleService c:\adcsbackup7 -KeepLog
-Password
If the -Password parameter is used, the supplied password must be a secure string. Use the Read-Host cmdlet to
launch an interactive prompt for secure password entry, or use the ConvertTo-SecureString cmdlet to specify the
password in-line.
Review the following examples
Specifying a secure string for the Password parameter using Read-Host
Backup-CARoleService c:\adcsbackup4 -Password (Read-Host -prompt "Password:" -AsSecureString)
Specifying a secure string for the Password parameter using ConvertTo-SecureString
Backup-CARoleService c:\adcsbackup5 -Password (ConvertTo-SecureString "Pa55w0rd!" -AsPlainText -Force)
Restore-CARoleService
ADCSAdministration Cmdlet: Restore-CARoleService
-Path - String - location to restore backup from

- This is the only unnamed parameter
- positional parameter
Example:
Restore-CARoleService.-Path c:\adcsbackup1 -Force
Restore-CARoleService c:\adcsbackup2 -Force
-KeyOnly - Restore the CA certificate without the database

- Must be specified if the backup was taken with the -KeyOnly
option
Example:
Restore-CARoleService c:\adcsbackup3 -KeyOnly -Force
-Password - Specifies the password of the CA certificates and private keys

- Must be a secure string
Example:
Restore-CARoleService c:\adcsbackup4 -Password (read-host -

prompt "Password:" -AsSecureString) -Force
Restore-CARoleService c:\adcsbackup5 -Password (ConvertTo-

SecureString "Pa55w0rd!" -AsPlainText -Force) -Force
-DatabaseOnly - Restore the database without the CA certificate
Restore-CARoleService c:\adcsbackup6 -DatabaseOnly
-Force - Allows you to overwrite the preexisting keys

- Is an optional parameter but when restoring in-place, it is
likely required
Restore-CARoleService c:\adcsbackup1 -Force
Issues
A non-password protected backup is taken if the ConvertTo-SecureString function fails while using the Backup-
CARoleService with the -Password parameter.
Table SEQ Table \* ARABIC 18: Common Errors
ACTION ERROR COMMENT
Restore-CARoleService Restore-CARoleService : The process Stop the Active Directory Certificate

C:\ADCSBackup cannot access the file because it is being Services service prior to running the
used by another process. (Exception Restore-CARoleService cmdlet
from HRESULT:
0x80070020)
Restore-CARoleService Restore-CARoleService : The directory is Use the -Force parameter to overwrite

C:\ADCSBackup not empty. (Exception from HRESULT: preexisting keys
0x80070091)
Backup-CARoleService Backup-CARoleService : Parameter set The -Password parameter is only used

C:\ADCSBackup -Password (Read- cannot be resolved using the specified to password protect private keys and is
Host -Prompt "Password:" - named parameters. therefore invalid when you are not
AsSecureString) -DatabaseOnly backing them up
Restore-CARoleService Restore-CARoleService : Parameter set The -Password parameter is only used

C:\ADCSBack15 -Password (Read- cannot be resolved using the specified to password protect private keys and is
Host -Prompt "Password:" - named parameters. therefore invalid when you are not
AsSecureString) -DatabaseOnly restoring them
Restore-CARoleService Restore-CARoleService : The system The path specified does not contain a
C:\ADCSBack14 -Password (Read- cannot find the file specified. (Exception valid database backup. Perhaps the path
Host -Prompt "Password:" - from HRESULT: 0x80070002) is invalid or the backup was taken with
AsSecureString) the -KeysOnly option?
Active Directory Certificate Services Migration Guide
Backing up a CA database and private key
Restoring the CA database and configuration on the destination server
Try This: Backup the CA in your lab using Windows PowerShell

1. Use the commands in this lesson to backup the CA database and private key secured with a password.
2. Hold off on the restore of the CA at this time.
NOTE
Overview
The pre-existing process creation audit event ID 4688 will now include audit information for command line
processes.
It will also log SHA1/2 hash of the executable in the Applocker event log
Application and Services Logs\Microsoft\Windows\AppLocker
You enable via GPO, but it is disabled by default
"Include command line in process creation events"
Figure SEQ Figure \* ARABIC 16 Event 4688
Review the updated event ID 4688 in REF _Ref366427278 \h Figure 16. Prior to this update none of the
information for Process Command Line gets logged. Because of this additional logging we can now see that not
only was the wscript.exe process started, but that it was also used to execute a VB script.
Configuration
To see the effects of this update, you will need to enable two policy settings.
You must have Audit Process Creation auditing enabled to see event ID 4688.
To enable the Audit Process Creation policy, edit the following group policy:
Policy location: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit
Configuration > Detailed Tracking
Policy Name: Audit Process Creation
Supported on: Windows 7 and above
Description/Help:
This security policy setting determines whether the operating system generates audit events when a process is
created (starts) and the name of the program or user that created it.
These audit events can help you understand how a computer is being used and to track user activity.
Event volume: Low to medium, depending on system usage
Default: Not configured
In order to see the additions to event ID 4688, you must enable the new policy setting: Include command line in
process creation events
Table SEQ Table \* ARABIC 19 Command line process policy setting
POLICY CONFIGURATION DETAILS
Path Administrative Templates\System\Audit Process Creation
Setting Include command line in process creation events
Default setting Not Configured (not enabled)
Supported on: ?
Description This policy setting determines what information is logged in

security audit events when a new process has been created.
This setting only applies when the Audit Process Creation

policy is enabled. If you enable this policy setting the
command line information for every process will be logged in
plain text in the security event log as part of the Audit Process
Creation event 4688, "a new process has been created," on the
workstations and servers on which this policy setting is
applied.
If you disable or do not configure this policy setting, the

process's command line information will not be included in
Audit Process Creation events.
Default: Not configured
Note: When this policy setting is enabled, any user with access
to read the security events will be able to read the command
line arguments for any successfully created process. Command
line arguments can contain sensitive or private information
such as passwords or user data.
When you use Advanced Audit Policy Configuration settings, you need to confirm that these settings are not
overwritten by basic audit policy settings. Event 4719 is logged when the settings are overwritten.
The following procedure shows how to prevent conflicts by blocking the application of any basic audit policy
settings.
To ensure that Advanced Audit Policy Configuration settings are not overwritten
1. Open the Group Policy Management console

2. Right-click Default Domain Policy, and then click Edit.
3. Double-click Computer Configuration, double-click Policies, and then double-click Windows Settings.
4. Double-click Security Settings, double-click Local Policies, and then click Security Options.
5. Double-click Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy
category settings, and then click Define this policy setting.
6. Click Enabled, and then click OK.
Audit Process Creation
Advanced Security Audit Policy Step-by-Step Guide
AppLocker: Frequently Asked Questions
Try This: Explore command line process auditing
1. Enable Audit Process Creation events and ensure the Advance Audit Policy configuration is not
overwritten
2. Create a script that will generate some events of interest and execute the script. Observe the events. The
script used to generate the event in the lesson looked like this:
mkdir c:\systemfiles\temp\commandandcontrol\zone\fifthward
copy \\192.168.1.254\c$\hidden c:\systemfiles\temp\hidden\commandandcontrol\zone\fifthward
start C:\systemfiles\temp\hidden\commandandcontrol\zone\fifthward\ntuserrights.vbs
del c:\systemfiles\temp\*.* /Q
3. Enable the command line process auditing

4. Execute the same script as before and observe the events
NOTE
This lesson explains the Directory Services component updates in Windows Server 2012 R2.
What You Will Learn

Explain the following new Directory Services component updates:
Explain the following new Directory Services component updates:

Overview
The section provides a brief introduction to the domain and forest functional level changes.
New DFL and FFL
With the release, there are new domain and forest functional levels:
Forest Functional Level: Windows Server 2012 R2
Domain Functional Level: Windows Server 2012 R2
The Windows Server 2012 R2 Domain Functional Level enables support for the following:
1. DC -side protections for Protected Users
Protected Users authenticating to a Windows Server 2012 R2 domain can no longer:
Authenticate with NTLM authentication
Use DES or RC4 cipher suites in Kerberos pre-authentication
Be delegated with unconstrained or constrained delegation
Renew user tickets (TGTs) beyond the initial 4 hour lifetime
2. Authentication Policies
New forest-based Active Directory policies which can be applied to accounts in Windows Server 2012 R2
domains to control which hosts an account can sign-on from and apply access control conditions for
authentication to services running as an account
3. Authentication Policy Silos
New forest-based Active Directory object which can create a relationship between user, managed service
and computer accounts to be used to classify accounts for authentication policies or for authentication
isolation.
See How to Configure Protected Accounts for more information.
In addition to the above features, the Windows Server 2012 R2 domain functional level ensures that any domain
controller in the domain runs Windows Server 2012 R2.
The Windows Server 2012 R2 forest functional level does not provide any new features, but it ensures that any
new domain created in the forest will automatically operate at the Windows Server 2012 R2 domain functional
level.
Minimum DFL enforced on new domain creation
Windows Server 2008 DFL is the minimum functional level supported on new domain creation.
NOTE
The deprecation of FRS is accomplished by removing the ability to install a new domain with a domain functional level lower
than Windows Server 2008 with Server Manager or via Windows PowerShell.
Lowering the forest and domain functional levels

The forest and domain functional levels are set to Windows Server 2012 R2 by default on new domain and new
forest creation but can be lowered using Windows PowerShell.
To raise or lower the forest functional level using Windows PowerShell, use the Set-ADForestMode cmdlet.
To set the contoso.com FFL to Windows Server 2008 mode:
Set-ADForestMode -ForestMode Windows2008Forest -Identity contoso.com
To raise or lower the domain functional level using Windows PowerShell, use the Set-ADDomainMode cmdlet.
To set the contoso.com DFL to Windows Server 2008 mode:
Set-ADDomainMode -DomainMode Windows2008Domain -Identity contoso.com
Promotion of a DC running Windows Server 2012 R2 as an additional replica into an existing domain running
2003 DFL works.
New domain creation in an existing forest
ADPREP
There are no new forest or domain operations in this release.
These .ldf files contain schema changes for the Device Registration Service.
1. Sch59
2. Sch61
3. Sch62
4. Sch63
5. Sch64
6. Sch65
7. Sch67
Work Folders:
1. Sch66
MSODS:
1. Sch60
Authentication Policies and Silos
1. Sch68
2. Sch69
Overview
FRS is deprecated in Windows Server 2012 R2. The deprecation of FRS is accomplished by enforcing a minimum
domain functional level (DFL ) of Windows Server 2008. This enforcement is present only if the new domain is
created using Server Manager or Windows PowerShell.
You use the -DomainMode parameter with the Install-ADDSForest or Install-ADDSDomain cmdlets to specify the
domain functional level. Supported values for this parameter can be either a valid integer or a corresponding
enumerated string value. For example, to set the domain mode level to Windows Server 2008 R2, you can specify
either a value of 4 or "Win2008R2". When executing these cmdlets from Server 2012 R2 valid values include those
for Windows Server 2008 (3, Win2008) Windows Server 2008 R2 (4, Win2008R2) Windows Server 2012 (5,
Win2012) and Windows Server 2012 R2 (6, Win2012R2). The domain functional level cannot be lower than the
forest functional level, but it can be higher. Since FRS is deprecated in this release, Windows Server 2003 (2,
Win2003) is not a recognized parameter with these cmdlets when executed from Windows Server 2012 R2.

Overview
The LDAP query optimizer algorithm was reevaluated and further optimized. The result is the performance
improvement in LDAP search efficiency and LDAP search time of complex queries.
NOTE
From the Developer:improvements in the performance of searches through improvements in the mapping from LDAP
query to ESE query. LDAP filters beyond a certain level of complexity prevent optimized index selection, resulting in drastically
decreased performance (1000x or more). This change alters the way in which we select indices for LDAP queries to avoid this
problem.
NOTE
A complete overhaul of the LDAP query optimizer algorithm, resulting in:
Faster search times
Efficiency gains allow DCs to do more
Less support calls regarding AD Performance issues
Back ported to Windows Server 2008 R2 (KB 2862304)
Background
The ability to search Active Directory is a core service provided by domain controllers. Other services and line of
business applications rely on Active Directory searches. Business operations can cease to a halt if this feature is not
available. As a core and heavily used service, it is imperative that domain controllers handle LDAP search traffic
efficiently. The LDAP query optimizer algorithm attempts to make LDAP searches efficient as possible by mapping
LDAP search filters to a result set that can be satisfied via records already indexed in the database. This algorithm
was reevaluated and further optimized. The result is the performance improvement in LDAP search efficiency and
LDAP search time of complex queries.
Details of change
An LDAP search contains:
A location (NC head, OU, Object) within the hierarchy to begin the search
A search filter
A list of attributes to return
The search process can be summarized as follows:
1. Simplify the search filter if possible.
2. Select a set of Index Keys that will return the smallest covered set.
3. Perform one or more intersections of Index Keys, to reduce the covered set.
4. For each record in the covered set, evaluate the filter expression as well as the security. If the filter evaluates
to TRUE and access is granted, then return this record to the client.
The LDAP query optimization work modifies steps 2 and 3, to reduce the size of the covered set. More specifically,
the current implementation selects duplicate Index Keys and performs redundant intersections.
Comparison between old and new algorithm
The target of the inefficient LDAP search in this example is a Windows Server 2012 domain controller. The search
completes in approximately 44 seconds as a result of failing to find a more efficient index.
adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304)

(userprincipalname=justintu@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)
(objectclass=person)))" -stats >>adfind.txt
Using server: WINSRV-DC1.blue.contoso.com:389
<removed search results>
Statistics
=====
Elapsed Time: 44640 (ms)
Returned 324 entries of 553896 visited - (0.06%)
Used Filter:
( | ( & ( | (cn=justintu) (postalCode=80304) (userPrincipalName=justintu@blue.contoso.com) ) ( |
(objectClass=person) (cn=justintu) ) ) ( & (cn=justintu) (objectClass=person) ) )
Used Indices:
DNT_index:516615:N
Pages Referenced : 4619650

Pages Read From Disk : 973
Pages Pre-read From Disk : 180898
Pages Dirtied : 0
Pages Re-Dirtied : 0
Log Records Generated : 0
Log Record Bytes Generated: 0
Sample results using the new algorithm

This example repeats the exact same search as above but targets a Windows Server 2012 R2 domain controller.
The same search completes in less than a second due to the improvements in the LDAP query optimizer algorithm.
adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304)

(userprincipalname=dhunt@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)
(objectclass=person)))" -stats >>adfindBLUE.txt
Using server: winblueDC1.blue.contoso.com:389
.<removed search results>
Statistics
=====
Elapsed Time: 672 (ms)
Returned 324 entries of 648 visited - (50.00%)
Used Filter:
( | ( & ( | (cn=justintu) (postalCode=80304) (userPrincipalName=justintu@blue.contoso.com) ) ( |
(objectClass=person) (cn=justintu) ) ) ( & (cn=justintu) (objectClass=person) ) )
Used Indices:
idx_userPrincipalName:648:N
idx_postalCode:323:N
idx_cn:1:N
Pages Referenced : 15350

Pages Read From Disk : 176
Pages Pre-read From Disk : 2
Pages Dirtied : 0
Pages Re-Dirtied : 0
Log Records Generated : 0
Log Record Bytes Generated: 0
If unable to optimize the tree:

For example: an expression in the tree was over a column not indexed
Record a list of indices that prevent optimization
Exposed via ETW tracing and event ID 1644
To enable the Stats control in LDP
1. Open LDP.exe, and connect and bind to a domain controller.
2. On the Options menu, click Controls.
3. On the Controls dialog box, expand the Load Predefined pull-down menu, click Search Stats and then
click OK.
4. On the Browse menu, click Search

5. In the Search dialog box, select the Options button.
6. Ensure the Extended check box is selected on the Search Options dialog box and select OK.
Try This: Use LDP to return query statistics
Perform the following on a domain controller, or from a domain-joined client or server that has the AD DS tools
installed. Repeat the following targeting your Windows Server 2012 DC and your Windows Server 2012 R2 DC.
1. Review the "Creating More Efficient Microsoft AD Enabled Applications" article and refer back to it as
needed.
2. Using LDP, enable search statistics (see To enable the Stats control in LDP )
3. Conduct several LDAP searches and observe the statistical information at the top of the results. You will
repeat the same search in other activities so document them in a notepad text file.
4. Perform an LDAP search that the query optimizer should be able to optimize because of attributes indices
5. Attempt to construct a search that takes a long time to complete (you may want to increase the Time limit
option so the search does not timeout).
What Are Active Directory Searches?
How Active Directory Searches Work
Creating More Efficient Microsoft Active Directory-Enabled Applications
951581 LDAP queries are executed more slowly than expected in the AD or LDS/ADAM directory service and
Event ID 1644 may be logged

Overview
This update adds additional LDAP search result statistics to event ID 1644 to aid in troubleshooting purposes.
Additionally, there is a new registry value that can be used to enable logging on a time-based threshold. These
improvements were made available in Windows Server 2012 and Windows Server 2008 R2 SP1 via KB 2800945
and will be made available to Windows Server 2008 SP2.
NOTE
Additional LDAP search statistics are added to event ID 1644 to aid in troubleshooting inefficient or expensive LDAP
searches
You can now specify a Search Time Threshold (eg. Log event 1644 for searches taking longer than 100ms) instead of
specifying the Expensive and Inefficient search result threshold values
Background
While troubleshooting Active Directory performance problems, it becomes apparent that LDAP search activity may
be contributing to the problem. You decide to enable logging so that you can see expensive or inefficient LDAP
queries processed by domain controller. In order to enable the logging, you must set the Field Engineering
diagnostics value and can optionally specify the expensive / inefficient search results threshold values. Upon
enabling the Field Engineering logging level to a value of 5, any search that meets these criteria is logged in the
Directory Services event log with an event ID 1644.
The event contains:
Client IP and port
Starting Node
Filter
Search scope
Attribute selection
Server controls
Visited entries
Returned entries
However, key data is missing from the event such as the amount of time spent on the search operation and what (if
any) index was used.
Additional search statistics added to event 1644
Used indexes
Pages referenced
Pages read from disk
Pages preread from disk
Clean pages modified
Dirty pages modified
Search time
Attributes Preventing Optimization
New time-based threshold registry value for event 1644 logging
Instead of specifying the Expensive and Inefficient search result threshold values, you can specify Search Time
Threshold. If you wanted to log all search results that took 50 ms or greater, you would specify 50 decimal / 32 hex
(in addition to setting the Field Engineering value).
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Search Time Threshold (msecs)"=dword:00000032
Comparison of the old and new event ID 1644

OLD
NEW
Try This: Use the event log to return query statistics
1. Repeat the following targeting your Windows Server 2012 DC and your Windows Server 2012 R2 DC.
Observe the event ID 1644s on both DCs after each search.
2. Using regedit, enable event ID 1644 logging using a time-based threshold on the Windows Server 2012 R2
DC and the old method on the Windows Server 2012 DC.
3. Conduct several LDAP searches that exceed the threshold and observe the statistical information at the top
of the results. Use the LDAP queries you documented earlier and repeat the same searches.
4. Perform an LDAP search that the query optimizer is not able to optimize because one or more attributes are
not indexed.

Overview
AD replication uses RPC for its replication transport. By default, RPC uses an 8K transmit buffer and a 5K packet
size. This has the net effect where the sending instance will transmit three packets (approximately 15K worth of
data) and then have to wait for a network round trip before sending more. Assuming a 3ms roundtrip time, the
highest throughput would be around 40Mbps, even on 1Gbps or 10 Gbps networks.
NOTE
This update adjusts the maximum AD Replication throughput from 40Mbps to around 600 Mbps.
It increases the RPC send buffer size which reduces the number of network round trips
The effect will be most noticeable on high speed, high latency network.
This updates increase the maximum throughput to around 600 Mbps by changing the RPC send buffer size from
8K to 256KB. This change allows the TCP window size to grow beyond 8K, reducing the number of network round
trips.
NOTE
There are no configurable settings to modify this behavior.
How the Active Directory Replication Model Works
How to Configure Protected Accounts
Through Pass-the-hash (PtH) attacks, an attacker can authenticate to a remote server or service by using the
underlying NTLM hash of a user's password (or other credential derivatives). Microsoft has previously published
guidance to mitigate pass-the-hash attacks. Windows Server 2012 R2 includes new features to help mitigate such
attacks further. For more information about other security features that help protect against credential theft, see
Credentials Protection and Management. This topic explains how to configure the following new features:
Protected Users
Authentication policies
Authentication policy silos
There are additional mitigations built in to Windows 8.1 and Windows Server 2012 R2 to help protect against
credential theft, which are covered in the following topics:
Restricted Admin mode for Remote Desktop
LSA Protection
Protected Users
Protected Users is a new global security group to which you can add new or existing users. Windows 8.1 devices
and Windows Server 2012 R2 hosts have special behavior with members of this group to provide better protection
against credential theft. For a member of the group, a Windows 8.1 device or a Windows Server 2012 R2 host does
not cache credentials that are not supported for Protected Users. Members of this group have no additional
protection if they are logged on to a device that runs a version of Windows earlier than Windows 8.1.
Members of the Protected Users group who are signed-on to Windows 8.1 devices and Windows Server 2012 R2
hosts can no longer use:
Default credential delegation (CredSSP ) - plaintext credentials are not cached even when the Allow
delegating default credentials policy is enabled
Windows Digest - plaintext credentials are not cached even when they are enabled
NTLM - NTOWF is not cached
Kerberos long term keys - Kerberos ticket-granting ticket (TGT) is acquired at logon and cannot be re-
acquired automatically
Sign-on offline - the cached logon verifier is not created
If the domain functional level is Windows Server 2012 R2 , members of the group can no longer:
Authenticate by using NTLM authentication
Use Data Encryption Standard (DES ) or RC4 cipher suites in Kerberos pre-authentication
Be delegated by using unconstrained or constrained delegation
Renew user tickets (TGTs) beyond the initial 4-hour lifetime
To add users to the group, you can use UI tools such as Active Directory Administrative Center (ADAC ) or Active
Directory Users and Computers, or a command-line tool such as Dsmod group, or the Windows PowerShellAdd-
ADGroupMember cmdlet. Accounts for services and computers should not be members of the Protected Users
group. Membership for those accounts provides no local protections because the password or certificate is always
available on the host.
WARNING
The authentication restrictions have no workaround, which means that members of highly privileged groups such as the
Enterprise Admins group or the Domain Admins group are subject to the same restrictions as other members of the
Protected Users group. If all members of such groups are added to the Protected Users group, it is possible for all of those
accounts to be locked out. You should never add all highly privileged accounts to the Protected Users group until you have
thoroughly tested the potential impact.
Members of the Protected Users group must be able to authenticate by using Kerberos with Advanced Encryption
Standards (AES ). This method requires AES keys for the account in Active Directory. The built-in Administrator
does not have an AES key unless the password was changed on a domain controller that runs Windows Server
2008 or later. Additionally, any account, which has a password that was changed at a domain controller that runs an
earlier version of Windows Server, is locked out. Therefore, follow these best practices:
Do not test in domains unless all domain controllers run Windows Server 2008 or later.
Change password for all domain accounts that were created before the domain was created. Otherwise,
these accounts cannot be authenticated.
Change password for each user before adding the account to the Protected Users group or ensure that the
password was changed recently on a domain controller that runs Windows Server 2008 or later.
Requirements for using protected accounts
Protected accounts have the following deployment requirements:
To provide client-side restrictions for Protected Users, hosts must run Windows 8.1 or Windows Server
2012 R2 . A user only has to sign-on with an account that is a member of a Protected Users group. In this
case, the Protected Users group can be created by transferring the primary domain controller (PDC )
emulator role to a domain controller that runs Windows Server 2012 R2 . After that group object is
replicated to other domain controllers, the PDC emulator role can be hosted on a domain controller that
runs an earlier version of Windows Server.
To provide domain controller-side restrictions for Protected Users, that is to restrict usage of NTLM
authentication, and other restrictions, the domain functional level must be Windows Server 2012 R2 . For
more information about functional levels, see Understanding Active Directory Domain Services (AD DS )
Functional Levels.
Troubleshoot events related to Protected Users
This section covers new logs to help troubleshoot events that are related to Protected Users and how Protected
Users can impact changes to troubleshoot either ticket-granting tickets (TGT) expiration or delegation issues.
New logs for Protected Users
Two new operational administrative logs are available to help troubleshoot events that are related to Protected
Users: Protected User - Client Log and Protected User Failures - Domain Controller Log. These new logs are
located in Event Viewer and are disabled by default. To enable a log, click Applications and Services Logs, click
Microsoft, click Windows, click Authentication, and then click the name of the log and click Action (or right-
click the log) and click Enable Log.
For more information about events in these logs, see Authentication Policies and Authentication Policy Silos.
Troubleshoot TGT expiration
Normally, the domain controller sets the TGT lifetime and renewal based on the domain policy as shown in the
following Group Policy Management Editor window.
For Protected Users, the following settings are hard-coded:

Maximum lifetime for user ticket: 240 minutes
Maximum lifetime for user ticket renewal: 240 minutes
Troubleshoot delegation issues
Previously, if a technology that uses Kerberos delegation was failing, the client account was checked to see if
Account is sensitive and cannot be delegated was set. However, if the account is a member of Protected
Users, it might not have this setting configured in Active Directory Administrative Center (ADAC ). As a result, check
the setting and group membership when you troubleshoot delegation issues.
Audit authentication attempts

To audit authentication attempts explicitly for the members of the Protected Users group, you can continue to
collect security log audit events or collect the data in the new operational administrative logs. For more information
about these events, see Authentication Policies and Authentication Policy Silos
Provide DC -side protections for services and computers
Accounts for services and computers cannot be members of Protected Users. This section explains which domain
controller-based protections can be offered for these accounts:
Reject NTLM authentication: Only configurable via NTLM block policies
Reject Data Encryption Standard (DES ) in Kerberos pre-authentication: Windows Server 2012 R2 domain
controllers do not accept DES for computer accounts unless they are configured for DES only because every
version of Windows released with Kerberos also supports RC4.
Reject RC4 in Kerberos pre-authentication: not configurable.
NOTE
Although it is possible to change the configuration of supported encryption types, it is not recommended to change
those settings for computer accounts without testing in the target environment.
Restrict user tickets (TGTs) to an initial 4-hour lifetime: Use Authentication Policies.
Deny delegation with unconstrained or constrained delegation: To restrict an account, open Active Directory
Administrative Center (ADAC ) and select the Account is sensitive and cannot be delegated check box.
Authentication policies
Authentication Policies is a new container in AD DS that contains authentication policy objects. Authentication
policies can specify settings that help mitigate exposure to credential theft, such as restricting TGT lifetime for
accounts or adding other claims-related conditions.
In Windows Server 2012 , Dynamic Access Control introduced an Active Directory forest-scope object class called
Central Access Policy to provide an easy way to configure file servers across an organization. In Windows Server
2012 R2 , a new object class called Authentication Policy (objectClass msDS -AuthNPolicies) can be used to apply
authentication configuration to account classes in Windows Server 2012 R2 domains. Active Directory account
classes are:
User
Computer
Managed Service Account and group Managed Service Account (GMSA)
Quick Kerberos refresher
The Kerberos authentication protocol consists of three types of exchanges, also known as subprotocols:
The Authentication Service (AS ) Exchange (KRB_AS_*)

The Ticket-Granting Service (TGS ) Exchange (KRB_TGS_*)
The Client/Server (AP ) Exchange (KRB_AP_*)
The AS exchange is where the client uses the account's password or private key to create a pre-authenticator to
request a ticket-granting ticket (TGT). This happens at user sign-on or the first time a service ticket is needed.
The TGS exchange is where the account's TGT is used to create an authenticator to request a service ticket. This
happens when an authenticated connection is needed.
The AP exchange occurs as typically as data inside the application protocol and is not impacted by authentication
policies.
For more detailed information, see How the Kerberos Version 5 Authentication Protocol Works.
Overview
Authentication policies complement Protected Users by providing a way to apply configurable restrictions to
accounts and by providing restrictions for accounts for services and computers. Authentication policies are
enforced during either the AS exchange or the TGS exchange.
You can restrict initial authentication or the AS exchange by configuring:
A TGT lifetime
Access control conditions to restrict user sign-on, which must be met by devices from which the AS
exchange is coming
You can restrict service ticket requests through a ticket-granting service (TGS ) exchange by configuring:
Access control conditions which must be met by the client (user, service, computer) or device from which the
TGS exchange is coming
Requirements for using authentication policies
POLICY REQUIREMENTS
Provide custom TGT lifetimes Windows Server 2012 R2 domain functional level account
domains
Restrict user sign-on - Windows Server 2012 R2 domain functional level account
domains with Dynamic Access Control support
- Windows 8, Windows 8.1, Windows Server 2012 or Windows
Server 2012 R2 devices with Dynamic Access Control support
Restrict service ticket issuance that is based on user account Windows Server 2012 R2 domain functional level resource
and security groups domains
POLICY REQUIREMENTS
Restrict service ticket issuance based on user claims or device Windows Server 2012 R2 domain functional level resource
account, security groups, or claims domains with Dynamic Access Control support
Restrict a user account to specific devices and hosts

A high-value account with administrative privilege should be a member of the Protected Users group. By default,
no accounts are members of the Protected Users group. Before you add accounts to the group, configure domain
controller support and create an audit policy to ensure that there are no blocking issues.
Configure domain controller support
The user's account domain must be at Windows Server 2012 R2 domain functional level (DFL ). Ensure all the
domain controllers are Windows Server 2012 R2 , and then use Active Directory Domains and Trusts to raise the
DFL to Windows Server 2012 R2 .
To configure support for Dynamic Access Control
1. In the Default Domain Controllers Policy, click Enabled to enable Key Distribution Center (KDC ) client
support for claims, compound authentication and Kerberos armoring in Computer Configuration |
Administrative Templates | System | KDC.
2. Under Options, in the drop-down list box, select Always provide claims.
NOTE
Supported can also be configured, but because the domain is at Windows Server 2012 R2 DFL, having the DCs
always provide claims will allow user claims-based access checks to occur when using non-claims aware devices and
hosts to connect to claims-aware services.
WARNING
Configuring Fail unarmored authentication requests will result in authentication failures from any operating system
which does not support Kerberos armoring, such as Windows 7 and previous operating systems, or operating
systems beginning with Windows 8, which have not been explicitly configured to support it.
Create a user account audit for authentication policy with ADAC

1. Open Active Directory Administrative Center (ADAC ).
NOTE
The selected Authentication node is visible for domains which are at Windows Server 2012 R2 DFL. If the node does
not appear, then try again by using a domain administrator account from a domain that is at Windows Server 2012
R2 DFL.
2. Click Authentication Policies, and then click New to create a new policy.
Authentications Policies must have a display name and are enforced by default.
3. To create an audit-only policy, click Only audit policy restrictions.
Authentication policies are applied based on the Active Directory account type. A single policy can apply to
all three account types by configuring settings for each type. Account types are:
User
Computer
Managed Service Account and Group Managed Service Account
If you have extended the schema with new principals that can be used by the Key Distribution Center (KDC ),
then the new account type is classified from the closest derived account type.
4. To configure a TGT lifetime for user accounts, select the Specify a Ticket-Granting Ticket lifetime for
user accounts check box and enter the time in minutes.
For example, if you want a 10-hour maximum TGT lifetime, enter 600 as shown. If no TGT lifetime is
configured, then if the account is a member of the Protected Users group, the TGT lifetime and renewal is 4
hours. Otherwise, TGT lifetime and renewal are based on the domain policy as seen in the following Group
Policy Management Editor window for a domain with default settings.
5. To restrict the user account to select devices, click Edit to define the conditions that are required for the
device.
6. In the Edit Access Control Conditions window, click Add a condition.
A dd c o m pu t er ac c o u n t o r gr o u p c o n di t i o n s
1. To configure computer accounts or groups, in the drop-down list, select the drop-down list box Member of
each and change to Member of any.
NOTE
This access control defines the conditions of the device or host from which the user signs on. In access control
terminology, the computer account for the device or host is the user, which is why User is the only option.
2. Click Add items.

3. To change object types, click Object Types.
4. To select computer objects in Active Directory, click Computers, and then click OK.
5. Type the name of the computers to restrict the user, and then click Check Names.
6. Click OK and create any other conditions for the computer account.
7. When done, then click OK and the defined conditions will appear for the computer account.
A dd c o m pu t er c l ai m c o n di t i o n s
1. To configure computer claims, drop-down Group to select the claim.
Claims are only available if they are already provisioned in the forest.
2. Type the name of OU, the user account should be restricted to sign on.
3. When done, then click OK and the box will show the conditions defined.
T r o u b l e sh o o t m i ssi n g c o m p u t e r c l a i m s
If the claim has been provisioned, but is not available, it might only be configured for Computer classes.
Let's say you wanted to restrict authentication based on the organizational unit (OU ) of the computer, which was
already configured, but only for Computer classes.
For the claim to be available to restrict User sign-on to the device, select the User check box.
Provision a user account with an authentication policy with ADAC

1. From the User account, click Policy.
2. Select the Assign an authentication policy to this account check box.
3. Then select the authentication policy to apply to the user.
Configure Dynamic Access Control support on devices and hosts

You can configure TGT lifetimes without configuring Dynamic Access Control (DAC ). DAC is only needed for
checking AllowedToAuthenticateFrom and AllowedToAuthenticateTo.
Using either Group Policy or Local Group Policy Editor, enable Kerberos client support for claims, compound
authentication and Kerberos armoring in Computer Configuration | Administrative Templates | System |
Kerberos:
Troubleshoot Authentication Policies
Determine the accounts that are directly assigned an Authentication Policy
The accounts section in the Authentication Policy shows the accounts that have directly applied the policy.
Use the Authentication Policy Failures - Domain Controller administrative log

A new Authentication Policy Failures - Domain Controller administrative log under Applications and
Services Logs > Microsoft > Windows > Authentication has been created to make it easier to discover failures
due to Authentication Policies. The log is disabled by default. To enable it, right-click the log name and click Enable
Log. The new events are very similar in content to the existing Kerberos TGT and service ticket auditing events. For
more information about these events, see Authentication Policies and Authentication Policy Silos.
Manage authentication policies by using Windows PowerShell
This command creates an authentication policy named TestAuthenticationPolicy. The
UserAllowedToAuthenticateFrom parameter specifies the devices from which users can authenticate by an
SDDL string in the file named someFile.txt.
PS C:\> New-ADAuthenticationPolicy testAuthenticationPolicy -UserAllowedToAuthenticateFrom (Get-Acl

.\someFile.txt).sddl
This command gets all authentication policies that match the filter that the Filter parameter specifies.
PS C:\> Get-ADAuthenticationPolicy -Filter "Name -like 'testADAuthenticationPolicy*'" -Server
Server02.Contoso.com
This command modifies the description and the UserTGTLifetimeMins properties of the specified authentication
policy.
PS C:\> Set-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1 -Description "Description" -

UserTGTLifetimeMins 45
This command removes the authentication policy that the Identity parameter specifies.
PS C:\> Remove-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1
This command uses the Get-ADAuthenticationPolicy cmdlet with the Filter parameter to get all authentication
policies that are not enforced. The result set is piped to the Remove-ADAuthenticationPolicy cmdlet.
PS C:\> Get-ADAuthenticationPolicy -Filter 'Enforce -eq $false' | Remove-ADAuthenticationPolicy
Authentication policy silos

Authentication Policy Silos is a new container (objectClass msDS -AuthNPolicySilos) in AD DS for user, computer,
and service accounts. They help protect high-value accounts. While all organizations need to protect members of
Enterprise Admins, Domain Admins and Schema Admins groups because those accounts could be used by an
attacker to access anything in the forest, other accounts may also need protection.
Some organizations isolate workloads by creating accounts that are unique to them and by applying Group Policy
settings to limit local and remote interactive logon and administrative privileges. Authentication policy silos
complement this work by creating a way to define a relationship between User, Computer and managed Service
accounts. Accounts can only belong to one silo. You can configure authentication policy for each type of account in
order to control:
1. Non-renewable TGT lifetime
2. Access control conditions for returning TGT (Note: cannot apply to systems because Kerberos armoring is
required)
3. Access control conditions for returning service ticket
Additionally, accounts in an authentication policy silo have a silo claim, which can be used by claims-aware
resources such as file servers to control access.
A new security descriptor can be configured to control issuing service ticket based on:
User, user's security groups, and/or user's claims
Device, device's security group, and/or device's claims
Getting this information to the resource's DCs requires Dynamic Access Control:
User claims:
Windows 8 and later clients supporting Dynamic Access Control
Account domain supports Dynamic Access Control and claims
Device and/or device security group:
Resource configured for compound authentication
Device claims:
Device domain supports Dynamic Access Control and claims
Resource configured for compound authentication
Authentication policies can be applied to all members of an authentication policy silo instead of to individual
accounts, or separate authentication policies can be applied to different types of accounts within a silo. For example,
one authentication policy can be applied to highly privileged user accounts, and a different policy can be applied to
services accounts. At least one authentication policy must be created before an authentication policy silo can be
created.
NOTE
An authentication policy can be applied to members of an authentication policy silo, or it can be applied independently of silos
to restrict specific account scope. For example, to protect a single account or a small set of accounts, a policy can be set on
those accounts without adding the accounts to a silo.
You can create an authentication policy silo by using Active Directory Administrative Center or Windows
PowerShell. By default, an authentication policy silo only audits silo policies, which is equivalent to specifying the
WhatIf parameter in Windows PowerShell cmdlets. In this case, policy silo restrictions do not apply, but audits are
generated to indicate whether failures occur if the restrictions are applied.
To create an authentication policy silo by using Active Directory Administrative Center
1. Open Active Directory Administrative Center, click Authentication, right-click Authentication Policy
Silos, click New, and then click Authentication Policy Silo.
2. In Display name, type a name for the silo. In Permitted Accounts, click Add, type the names of the
accounts, and then click OK. You can specify users, computers, or service accounts. Then specify whether to
use a single policy for all principals or a separate policy for each type of principal, and the name of the policy
or policies.
Manage authentication policy silos by using Windows PowerShell

This command creates an authentication policy silo object and enforces it.
PS C:\>New-ADAuthenticationPolicySilo -Name newSilo -Enforce
This command gets all the authentication policy silos that match the filter that is specified by the Filter parameter.
The output is then passed to the Format-Table cmdlet to display the name of the policy and the value for Enforce
on each policy.
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Name -like "*silo*"' | Format-Table Name, Enforce -AutoSize
Name Enforce
---- -------
silo True
silos False
This command uses the Get-ADAuthenticationPolicySilo cmdlet with the Filter parameter to get all
authentication policy silos that are not enforced and pipe the result of the filter to the Remove-
ADAuthenticationPolicySilo cmdlet.
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Enforce -eq $False' | Remove-ADAuthenticationPolicySilo
This command grants access to the authentication policy silo named Silo to the user account named User01.
PS C:\>Grant-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01

This command revokes access to the authentication policy silo named Silo for the user account named User01.
Because the Confirm parameter is set to $False, no confirmation message appears.
PS C:\>Revoke-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01 -Confirm:$False
This example first uses the Get-ADComputer cmdlet to get all computer accounts that match the filter that the
Filter parameter specifies. The output of this command is passed to Set-ADAccountAuthenticatinPolicySilo to
assign the authentication policy silo named Silo and the authentication policy named AuthenticationPolicy02 to
them.
PS C:\>Get-ADComputer -Filter 'Name -like "newComputer*"' | Set-ADAccountAuthenticationPolicySilo -

AuthenticationPolicySilo Silo -AuthenticationPolicy AuthenticationPolicy02
How LDAP Server Cookies Are Handled
In LDAP, some queries result in a large result set. Such queries pose some challenges to the Windows Server.
Collecting and building these big result sets is significant work. Many of the attributes need to be converted from
an internal representation to the LDAP wire representation. For many attributes, a conversion from an internal,
often binary, format needs to happen to a text-based UTF -8 format in the LDAP response frame.
Another challenge is that result sets with tens of thousands of objects become huge, easily several hundred Mega-
Bytes. These then require lots of virtual address space and also the transfer over network has issues as the whole
effort is lost when the TCP session breaks down in transit.
These capacity and logistic issues have led the Microsoft LDAP developers to creating a LDAP extension known as
"Paged Query". It is implementing a LDAP control to separate one huge query into chunks of smaller result sets. It
has become a RFC standard as RFC 2696.
Cookie Handling on Client

The Paged Query method uses the page size either set by the client or through a LDAP Policy ("MaxPageSize"). The
client always needs to enable paging by sending a LDAP control.
When working on a query with many results, at some point the maximum number of objects allowed is reached.
The LDAP server packages up the response message and adds a cookie that contains information it needs to later
continue the search.
The client application must treat the cookie as an opaque blob. It can retrieve the object count in the response and
can continue the search based on the presence of the cookie.The client continues the search by sending the query
to the LDAP server again with the same parameters such as base object and filter, and includes the cookie value
that was returned on the previous response.
If the number of objects doesn't fill a page, the LDAP query is complete and the response contains no page cookie.
If no cookie is returned by the server, the client must consider the paged search to be successfully complete.
If an error is returned by the server, the client must consider the paged search to be unsuccessful. Retrying the
search will result in restarting the search from the first page.
Server-side Cookie handling

The Windows Server returns the cookie to the client and sometimes stores information related to the cookie on the
server. This information is stored on the server in a cache and is subject to certain limits.
In this case, the cookie sent to the client by the Server is also used by the server to lookup the information from the
cache on the Server. When the client continues the paged search, the Windows Server will use the client cookie as
well as any related information from the server cookie cache to continue the search. If the server cannot find
related cookie information from the server cache due to any reason, the search is discontinued and error is
returned to the client.
How the cookie pool is managed

Obviously, the LDAP server is serving more than one client at a time, and also more than one client at a time can
launch queries that require the use of server cookie cache.Thus the Windows Server implementation there is a
tracking of cookie pool usage and limits are put into place so the cookie pool is not taking too much resources. The
limits can be set by the Administrator using the following settings in LDAP Policy. The defaults and explanations
are:
MinResultSets: 4
The LDAP server will not look at the maximum pool size discussed below, if there are less than MinResultSets
entries in the server cookie cache.
MaxResultSetSize: 262,144 bytes
The total cookie cache size on the server must not exceed the maximum of MaxResultSetSize in bytes. If it does,
cookies starting from the oldest are deleted until the pool is smaller than MaxResultSetSize bytes or less than
MinResultSets cookies are in the pool. This means that using default settings, the LDAP server considers a pool of
450KB to be OK if there are only 3 cookies stored.
MaxResultSetsPerConn: 10
The LDAP server allows no more than MaxResultSetsPerConn cookies per LDAP connection in the pool.
Handling Deleted Cookies

The removal of cookie information from LDAP Server cache does not result in an immediate error for applications
in all cases. Applications may restart the paged search from the start and complete it on another attempt. Some
applications have this kind of a retry mechanism to add robustness.
Some applications may go through a page search and never complete it. This may leave entries in the LDAP server
cookie cache, which is handled through the mechanism in section 4. This is essential to free up memory on the
server for active LDAP searches.
What happens when such a cookie is deleted on the server and the client continues the search with this cookie
handle?The LDAP Server will not find the cookie in the server cookie cache and return an error for the query, the
error response will be similar to:
00000057: LdapErr: DSID-xxxxxxxx, comment: Error processing control, data 0, v1db1
NOTE
The hexadecimal value behind "DSID" will vary depending on the build version of the LDAP server binaries.
Reporting on the cookie pool

The LDAP Server has the ability to log events through category "16 Ldap Interface" in the NTDS diagnostics key. If
you set this category to "2", you can get the following events:
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 2898
Task Category: LDAP Interface
Level: Information
Description:
Internal event: The LDAP server has reached the limit of the number of Result Sets it will maintain for a
single connection. A stored Result Set will be discarded. This will result in a client being unable to
continue a paged LDAP search.
Maximum number of Result Sets allowed per LDAP connection:
10
Current number of Result Sets for this LDAP connection:
11
User Action
The client should consider a more efficient search filter. The limit for Maximum Result Sets per Connection
may also be increased.
Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 2899
Task Category: LDAP Interface
Level: Information
Description:
Internal event: The LDAP server has exceeded the limit of the LDAP Maximum Result Set Size. A stored Result Set
will be discarded. This will result in a client being unable to continue a paged LDAP search.
Number of result sets currently stored:

4
Current Result Set Size:
263504
Maximum Result Set Size:
262144
Size of single Result Set being discarded:
40876
User Action
The client should consider a more efficient search filter. The limit for Maximum Result Set Size may also be
increased.
The events signal that a stored cookie was removed. It does NOT mean a client has seen the LDAP error, but only
that the LDAP Server has reached the administration limits for the cache. In some cases, an LDAP client may have
abandoned the paged search and may never see the error.
Monitoring the cookie pool

If you never experience LDAP search errors in your domain, you may never need to monitor the LDAP server page
search cookie pool. In case you see LDAP page search related errors in your environment, you may have an issue
with the cookie pool administrator limits.
Events 2898 and 2899 are the only ways to know that the LDAP server has reached the administrator limits. When
you experience that LDAP queries error out because of the control processing error above, you should look at
Increasing limits on one or more of the LDAP Policy settings mentioned in section 4, depending on which event
you are getting.
If you are seeing event 2898 on your DC/LDAP Server, we recommend you set MaxResultSetsPerConn to 25.
More than 25 parallel paged searches on a single LDAP connection is not usual. If you continue to see event 2898,
consider investigating your LDAP client application which encounters the error. The suspicion would be that it
somehow gets stuck retrieving additional paged results, leaves the cookie pending and restarts a new query. So see
whether the application would at some point have sufficient cookies for its purposes, you can also increase the
value of MaxResultSetsPerConn beyond 25.When you see events 2899 logged on your domain controllers, the
plan would be different. If your DC/LDAP server runs on a machine with sufficient memory (several GBs of free
memory), we recommend you set the MaxResultsetSize on the LDAP server to >=250MB. This limit is large
enough to accommodate large volumes of LDAP page searches even on very large directories.
If you are still seeing events 2899 with a pool of 250MB or more, you are likely having many clients with very high
number of objects returned, queried in a very frequent manner. The data you can gather with the Active Directory
Data Collector Set can help you find repetitive paged queries that keep your LDAP Servers busy. These queries will
all show with a number of "Entries returned" that matches the size of the page used.
If possible, you should review the application design, and implement a different approach with a lower frequency,
data volume and/or fewer client instances querying this data.In case of the applications for which you have source
code access, this guide to creating efficient AD -Enabled Applications can help you understand the optimal way for
applications to access AD.
If the query behavior can't be changed, one approach is also adding more replicated instances of the naming
contexts needed and to redistribute the clients and eventually reduce the load on the individual LDAP Servers.
This section includes troubleshooting recommendations and procedures for diagnosing and fixing problems that
may occur with Active Directory replication.
This content focuses primarily on responses to Directory Service event log messages and tool-based error
messages that might be reported by the Repadmin.exe and Dcdiag.exe tools. These tools are available on all
domain controllers that are running Windows Server 2016 or 2012 R2. You can also install Remote Server
Administration Tools (RSAT) on a member server that is running Windows 10.
Configuring a Computer for Troubleshooting Active Directory
Troubleshooting Active Directory Replication Problems
Configuring a Computer for Troubleshooting
Before you use advanced troubleshooting techniques to identify and fix Active Directory problems, configure your
computers for troubleshooting. You should also have a basic understanding of troubleshooting concepts,
procedures, and tools.
For information about monitoring tools for Windows Server, see the Step-by-Step Guide for Performance and
Reliability Monitoring in Windows Server
Configuration tasks for troubleshooting

To configure your computer for troubleshooting Active Directory Domain Services (AD DS ), perform the following
tasks:
Install Remote Server Administration Tools for AD DS
When you install AD DS to create a domain controller, the administrative tools that you use to manage AD DS are
installed automatically. If you want to manage domain controllers remotely from a computer that is not a domain
controller, you can install the Remote Server Administration Tools (RSAT) on a member server or workstation that
is running a supported version of Windows. RSAT replaces Windows Support Tools from Windows Server 2003.
Configure Reliability and Performance Monitor
Windows Server includes the Windows Reliability and Performance Monitor, which is a Microsoft Management
Console (MMC ) snap-in that combines the functionality of previous stand-alone tools, including Performance Logs
and Alerts, Server Performance Advisor, and System Monitor. This snap-in provides a graphical user interface
(GUI) for customizing Data Collector Sets and Event Trace Sessions.
Reliability and Performance Monitor also includes Reliability Monitor, an MMC snap-in that tracks changes to the
system and compares them to changes in system stability, providing a graphical view of their relationship.
Set logging levels
If the information that you receive in the Directory Service log in Event Viewer is not sufficient for troubleshooting,
raise the logging levels by using the appropriate registry entry in
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSDiagnostics.
By default, the logging levels for all entries are set to 0, which provides the minimum amount of information. The
highest logging level is 5. Increasing the level for an entry causes additional events to be logged in the Directory
Service event log.
Use the following procedure to change the logging level for a diagnostic entry. Membership in Domain Admins,
or equivalent, is the minimum required to complete this procedure.
WARNING
We recommend that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are
not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored.
This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as MMC
snap-ins, to accomplish tasks, rather than editing the registry directly. If you must edit the registry, use extreme caution.
To change the logging level for a diagnostic entry

1. Click Start > Run > type regedit > click OK.
2. Navigate to the entry for which you want to set logging in.
EXAMPLE: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSDiagnostics
3. Double-click the entry, and in Base, click Decimal.
4. In Value, type an integer from 0 through 5, and then click OK.
Troubleshooting Active Directory Replication
Problems
Active Directory replication problems can have several different sources. For example, Domain Name System
(DNS ) problems, networking issues, or security problems can all cause Active Directory replication to fail.
The rest of this topic explains tools and a general methodology to fix Active Directory replication errors. The
following subtopics cover symptoms, causes, and how to resolve specific replication errors:
Introduction and resources for troubleshooting Active Directory

replication
Inbound or outbound replication failure causes Active Directory objects that represent the replication topology,
replication schedule, domain controllers, users, computers, passwords, security groups, group memberships, and
Group Policy to be inconsistent between domain controllers. Directory inconsistency and replication failure cause
either operational failures or inconsistent results, depending on the domain controller that is contacted for the
operation, and can prevent the application of Group Policy and access control permissions. Active Directory
Domain Services (AD DS ) depends on network connectivity, name resolution, authentication and authorization, the
directory database, the replication topology, and the replication engine. When the root cause of a replication
problem is not immediately obvious, determining the cause among the many possible causes requires systematic
elimination of probable causes.
For a UI-based tool to help monitor replication and diagnose errors, see Active Directory Replication Status Tool.
There is also a hands-on lab that demonstrates how to use Active Directory Replication Status and other tools to
troubleshoot errors.
For a comprehensive document that describes how you can use the Repadmin tool to troubleshoot Active Directory
replication is available; see Monitoring and Troubleshooting Active Directory Replication Using Repadmin.
For information about how Active Directory replication works, see the following technical references:
Active Directory Replication Model Technical Reference
Active Director Replication Topology Technical Reference
Event and tool solution recommendations

Ideally, the red (Error) and yellow (Warning) events in the Directory Service event log suggest the specific
constraint that is causing replication failure on the source or destination domain controller. If the event message
suggests steps for a solution, try the steps that are described in the event. The Repadmin tool and other diagnostic
tools also provide information that can help you resolve replication failures.
For detailed information about using Repadmin for troubleshooting replication problems, see Monitoring and
Troubleshooting Active Directory Replication Using Repadmin.
Ruling out intentional disruptions or hardware failures

Sometimes replication errors occur because of intentional disruptions. For example, when you troubleshoot Active
Directory replication problems, rule out intentional disconnections and hardware failures or upgrades first.
Intentional disconnections
If replication errors are reported by a domain controller that is attempting replication with a domain controller that
has been built in a staging site and is currently offline awaiting its deployment in the final production site (a remote
site, such as a branch office), you can account for those replication errors. To avoid separating a domain controller
from the replication topology for extended periods, which causes continuous errors until the domain controller is
reconnected, consider adding such computers initially as member servers and using the install from media (IFM )
method to install Active Directory Domain Services (AD DS ). You can use the Ntdsutil command-line tool to create
installation media that you can store on removable media (CD, DVD, or other media) and ship to the destination
site. Then, you can use the installation media to install AD DS on the domain controllers at the site, without the use
of replication.
Hardware failures or upgrades
If replication problems occur as a result of hardware failure (for example, failure of a motherboard, disk subsystem,
or hard drive), notify the server owner so that the hardware problem can be resolved.
Periodic hardware upgrades can also cause domain controllers to be out of service. Ensure that your server owners
have a good system of communicating such outages in advance.
Firewall configuration
By default, Active Directory replication remote procedure calls (RPCs) occur dynamically over an available port
through the RPC Endpoint Mapper (RPCSS ) on port 135. Make sure that Windows Firewall with Advanced
Security and other firewalls are configured properly to allow for replication. For information about specifying the
port for Active Directory replication and port settings, see article 224196 in the Microsoft Knowledge Base.
For information about the ports that Active Directory replication uses, see Active Directory Replication Tools and
Settings.
For information about managing Active Directory replication over firewalls, see Active Directory Replication over
Firewalls.
Responding to failure of an outdated server running Windows 2000

Server
If a domain controller running Windows 2000 Server has failed for longer than the number of days in the
tombstone lifetime, the solution is always the same:
1. Move the server from the corporate network to a private network.
2. Either forcefully remove Active Directory or reinstall the operating system.
3. Remove the server metadata from Active Directory so that the server object cannot be revived.
You can use a script to clean up server metadata on most Windows operating systems. For information about using
this script, see Remove Active Directory Domain Controller Metadata.
By default, NTDS Settings objects that are deleted are revived automatically for a period of 14 days. Therefore, if
you do not remove server metadata (use Ntdsutil or the script mentioned previously to perform metadata cleanup),
the server metadata is reinstated in the directory, which prompts replication attempts to occur. In this case, errors
will be logged persistently as a result of the inability to replicate with the missing domain controller.
Root causes
If you rule out intentional disconnections, hardware failures, and outdated Windows 2000 domain controllers, the
remainder of replication problems almost always have one of the following root causes:
Network connectivity: The network connection might be unavailable, or network settings are not configured
properly.
Name resolution: DNS misconfigurations are a common cause of replication failures.
Authentication and authorization: Authentication and authorization problems cause "Access denied" errors
when a domain controller tries to connect to its replication partner.
Directory database (store): The directory database might not be able to process transactions fast enough to keep
up with replication time-outs.
Replication engine: If intersite replication schedules are too short, replication queues might be too large to
process in the time that is required by the outbound replication schedule. In this case, replication of some
changes can be stalled indefinitely potentially, long enough to exceed the tombstone lifetime.
Replication topology: Domain controllers must have intersite links in AD DS that map to real wide area network
(WAN ) or virtual private network (VPN ) connections. If you create objects in AD DS for the replication topology
that are not supported by the actual site topology of your network, replication that requires the misconfigured
topology fails.
General approach to fixing problems

Use the following general approach to fixing replication problems:
1. Monitor replication health daily, or use Repadmin.exe to retrieve replication status daily.
2. Attempt to resolve any reported failure in a timely manner by using the methods that are described in event
messages and this guide. If software might be causing the problem, uninstall the software before you continue
with other solutions.
3. If the problem that is causing replication to fail cannot be resolved by any known methods, remove AD DS from
the server and then reinstall AD DS. For more information about reinstalling AD DS, see Decommissioning a
Domain Controller.
4. If AD DS cannot be removed normally while the server is connected to the network, use one of the following
methods to resolve the problem:
Force AD DS removal in Directory Services Restore Mode (DSRM ), clean up server metadata, and then
reinstall AD DS.
Reinstall the operating system, and rebuild the domain controller.
For more information about forcing removal of AD DS, see Forcing the Removal of a Domain Controller.
Using Repadmin to retrieve replication status

Replication status is an important way for you to evaluate the status of the directory service. If replication is
working without errors, you know the domain controllers that are online. You also know that the following systems
and services are working:
DNS infrastructure
Kerberos authentication protocol
Windows Time service (W32time)
Remote procedure call (RPC )
Network connectivity
Use Repadmin to monitor replication status daily by running a command that assesses the replication status of all
the domain controllers in your forest. The procedure generates a .csv file that you can open in Microsoft Excel and
filter for replication failures.
You can use the following procedure to retrieve the replication status of all domain controllers in the forest.
Requirements
Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure.
Tools:
Repadmin.exe
Excel (Microsoft Office)
To generate a repadmin /showrepl spreadsheet for domain controllers
1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click
Run as administrator. If the User Account Control dialog box appears, provide Enterprise Admins credentials, if
required, and then click Continue.
2. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl * /csv > showrepl.csv
3. Open Excel.
4. Click the Office button, click Open, navigate to showrepl.csv, and then click Open.
5. Hide or delete column A as well as the Transport Type column, as follows:
6. Select a column that you want to hide or delete.
To hide the column, right-click the column, and then click Hide.
To delete the column, right-click the selected column, and then click Delete.
7. Select row 1 beneath the column heading row. On the View tab, click Freeze Panes, and then click Freeze Top
Row.
8. Select the entire spreadsheet. On the Data tab, click Filter.
9. In the Last Success Time column, click the down arrow, and then click Sort Ascending.
10. In the Source DC column, click the filter down arrow, point to Text Filters, and then click Custom Filter.
11. In the Custom AutoFilter dialog box, under Show rows where, click does not contain. In the adjacent text box,
type del to eliminate from view the results for deleted domain controllers.
12. Repeat step 11 for the Last Failure Time column, but use the value does not equal, and then type the value 0.
13. Resolve replication failures.
For every domain controller in the forest, the spreadsheet shows the source replication partner, the time that
replication last occurred, and the time that the last replication failure occurred for each naming context (directory
partition). By using Autofilter in Excel, you can view the replication health for working domain controllers only,
failing domain controllers only, or domain controllers that are the least or most current, and you can see the
replication partners that are replicating successfully.
Replication problems and resolutions

Replication problems are reported in event messages and in various error messages that occur when an application
or service attempts an operation. Ideally, these messages are collected by your monitoring application or when you
retrieve replication status.
Most replication problems are identified in the event messages that are logged in the Directory Service event log.
Replication problems might also be identified in the form of error messages in the output of the repadmin
/showrepl command.
repadmin /showrepl error messages that indicate replication problems
To identify Active Directory replication problems, use the repadmin /showrepl command, as described in the
previous section. The following table shows error messages that this command generates, along with the root
causes of the errors and links to topics that provide solutions for the errors.
REPADMIN ERROR ROOT CAUSE SOLUTION
The time since last replication with this A domain controller has failed inbound Event ID 2042: It has been too long
server has exceeded the tombstone replication with the named source since this machine replicated
lifetime. domain controller long enough for a
deletion to have been tombstoned,
replicated, and garbage-collected from
AD DS.
No inbound neighbors. If no items appear in the "Inbound Fixing Replication Connectivity Problems
Neighbors" section of the output that is (Event ID 1925)
generated by repadmin /showrepl, the
domain controller was not able to
establish replication links with another
domain controller.
Access is denied. A replication link exists between two Fixing Replication Security Problems
domain controllers, but replication
cannot be performed properly as a
result of an authentication failure.
Last attempt at <date - time> failed This problem can be related to Fixing Replication DNS Lookup Problems
with the "Target account name is connectivity, DNS, or authentication (Event IDs 1925, 2087, 2088) Fixing
incorrect." issues. If this is a DNS error, the local Replication Security Problems Fixing
domain controller could not resolve the Replication Connectivity Problems
globally unique identifier (GUID)-based (Event ID 1925)
DNS name of its replication partner.
LDAP Error 49. The domain controller computer Fixing Replication Security Problems
account might not be synchronized with
the Key Distribution Center (KDC).
Cannot open LDAP connection to local The administration tool could not Fixing Replication DNS Lookup Problems
host contact AD DS. (Event IDs 1925, 2087, 2088)
Active Directory replication has been The progress of inbound replication was Wait for replication to complete. This
preempted. interrupted by a higher-priority informational message indicates normal
replication request, such as a request operation.
that was generated manually with the
repadmin /sync command.
Replication posted, waiting. The domain controller posted a Wait for replication to complete. This
replication request and is waiting for an informational message indicates normal
answer. Replication is in progress from operation.
this source.
The following table lists common events that might indicate problems with Active Directory replication, along with
root causes of the problems and links to topics that provide solutions for the problems.
EVENT ID AND SOURCE ROOT CAUSE SOLUTION
1311 NTDS KCC The replication configuration Fixing Replication Topology Problems
information in AD DS does not (Event ID 1311)
accurately reflect the physical topology
of the network.
EVENT ID AND SOURCE ROOT CAUSE SOLUTION
1388 NTDS Replication Strict replication consistency is not in Fixing Replication Lingering Object
effect, and a lingering object has been Problems (Event IDs 1388, 1988, 2042)
replicated to the domain controller.
1925 NTDS KCC The attempt to establish a replication Fixing Replication Connectivity Problems
link for a writable directory partition (Event ID 1925) Fixing Replication DNS
failed. This event can have different Lookup Problems (Event IDs 1925,
causes, depending on the error. 2087, 2088)
1988 NTDS Replication The local domain controller has Fixing Replication Lingering Object
attempted to replicate an object from a Problems (Event IDs 1388, 1988, 2042)
source domain controller that is not
present on the local domain controller
because it may have been deleted and
already garbage-collected. Replication
does not proceed for this directory
partition with this partner until the
situation is resolved.
2042 NTDS Replication Replication has not occurred with this Fixing Replication Lingering Object
partner for a tombstone lifetime, and Problems (Event IDs 1388, 1988, 2042)
replication cannot proceed.
2087 NTDS Replication AD DS could not resolve the DNS host Fixing Replication DNS Lookup Problems
name of the source domain controller to (Event IDs 1925, 2087, 2088)
an IP address, and replication failed.
2088 NTDS Replication AD DS could not resolve the DNS host Fixing Replication DNS Lookup Problems
name of the source domain controller to (Event IDs 1925, 2087, 2088)
an IP address, but replication succeeded.
5805 Net Logon A machine account failed to Fixing Replication Security Problems
authenticate, which is usually caused by
either multiple instances of the same
computer name or the computer name
not replicating to every domain
controller.
For more information about replication concepts, see Active Directory Replication Technologies.
Next steps
For more information, including support articles specific to error codes see the support article: How to
troubleshoot common Active Directory replication errors
For detailed information about using Repadmin.exe to manage Active Directory replication, see the following
resource:
Monitoring and Troubleshooting Active Directory Replication Using Repadmin
For information about specific events that are logged for Active Directory problems, see the following resource:
Active Directory
For information about Active Directory known issues and best practices, see the following resources:
Known Issues for Creating Domain and Forest Trusts
Best Practices for Administering Domain and Forest Trusts
Known Issues for Backing Up Active Directory Domain Services
Known Issues for Authoritative Restore
Best Practices for Authoritative Restore
Known Issues for Adding Domain Controllers in Remote Sites
Best Practices for Adding Domain Controllers in Remote Sites
For general information about how to manage and configure Active Directory Domain Services (AD DS ) and how
it works, see the following resources:
Administering Active Directory Operations
Active Directory Collection
This document contains a list of all of the documentation areas for AD FS for Windows Server 2016, 2012 R2, and
2012. This includes the following:
AD FS Overview
AD FS Design
AD FS Deployment
AD FS Development
AD FS Operations
AD FS 2016 Overview
This document contains a list of all of the documentation overviews for AD FS for Windows Server 2016. This
includes the following:
What's New in AD FS for Windows Server 2019
AD FS 2016 Requirements
AD FS FAQ
What's new in Active Directory Federation Services
Applies To: Windows Server 2019, Windows Server 2016
What's new in Active Directory Federation Services for Windows Server

2019
Protected Logins
The following is a brief summary of updates to protected logins available in AD FS 2019:
External Auth Providers as Primary - Customers can now use 3rd party authentication products as the first
factor and not expose passwords as the first factor. In the cases where an externa auth provider can prove 2
factors it can claim MFA.
Password Authentication as additional Authentication - Customers have a fully supported inbox option to
use password only for the additional factor after a password less option is used as the first factor. This improves
the customer experience from ADFS 2016 where customers had to download a github adapter which is
supported as is.
Pluggable Threat Module Framework - Customers can now build their own plug in modules to block
certain types of requests during pre-authentication stage. This makes it easier for customers to use cloud
intelligence such as Identity protection to block logins for risky users or risky transactions.
ESL improvements - Improves on the ESL QFE in 2016 by adding the following capabilities
Enables customers to be in audit mode while being protected by 'classic' extranet lockout functionality
available since ADFS 2012R2. Currently 2016 customers would have no protection while in audit mode.
Enables independent lockout threshold for familiar locations. This makes it possible for multiple
instances of apps running with a common service account to roll over passwords with the least amount
of impact.
Additional security improvements
The following additional security improvements are available in AD FS 2019:
Remote PSH using SmartCard Login - Customers can now use smartcards to remote connect to ADFS via
PSH and use that to manage all PSH functions include multi-node PSH cmdlets.
HTTP Header customization - Customers can now customize HTTP headers emitted during ADFS
responses. This includes the following headers
HSTS: This conveys that ADFS endpoints can only be used on HTTPS endpoints for a compliant browser
to enforce
x-frame-options: Allows ADFS admins to allow specific relying parties to embed iFrames for ADFS
interactive login pages. This should be used with care and only on HTTPS hosts.
Future header: Additional future headers can be configured as well.
Authentication/Policy capabilities
The following authentication/policy capabilities are in AD FS 2019:
Specify auth method for additional auth per RP - Customers can now use claims rules to decide which
additional authentication provider to invoke for additional authentication provider. This is useful for 2 use cases
Customers are transitioning from one additional authentication provider to another. This way as they
onboard users to a newer authentication provider they can use groups to control which additional
authentication provider is called.
Customers have needs for a specific additional authentication provider (e.g. certificate) for certain
applications.
Restrict TLS based device auth only to applications that require it - Customers can now restrict client
TLS based device authentications to only applications performing device based conditional access. This
prevents any unwanted prompts for device authentication (or failures if the client application cannot handle) for
applications that do not require TLS based device authentication.
MFA freshness support - AD FS now supports the ability to re-do 2nd factor credential based on the
freshness of the 2nd factor credential. This allows customers to do an initial transaction with 2 factors and only
prompt for the 2nd factor on a periodic basis. This is only available to applications that can provide an
additional parameter in the request and is not a configurable setting in ADFS. This parameter is supported by
Azure AD when "Remember my MFA for X days" is configured and the 'supportsMFA' flag is set to true on the
federated domain trust settings in Azure AD.
Sign-in SSO improvements
The following sign-in SSO improvements have been made in AD FS 2019:
Paginated UX with Centered Theme - ADFS now has moved to a paginated UX flow that allows ADFS to
validate and provide a more smoother sign-in experience. ADFS now uses a centered UI (instead of the right
side of the screen). You may require newer logo and background images to align with this experience. This also
mirrors functionality offered in Azure AD.
Bug fix: Persistent SSO state for Win10 devices when doing PRT auth This addresses an issue where
MFA state was not persisted when using PRT authentication for Windows 10 devices. The result of the issue
was that end users would get prompted for 2nd factor credential (MFA) frequently. The fix also makes the
experience consistent when device auth is successfully performed via client TLS and via PRT mechanism.
Suppport for building modern line -of-business apps
The following support for building modern LOB apps has been added to AD FS 2019:
Oauth Device flow/profile - AD FS now supports the OAuth device flow profile to perform logins on devices
that do not have a UI surface area to support rich login experiences. This allows the user to complete the login
experience on a different device. This functionality is required for Azure CLI experience in Azure Stack and can
be used in other cases.
Removal of 'Resource' parameter - AD FS has now removed the requirement to specify a resource
parameter which is in line with current Oauth specifications. Clients can now provide the Relying Party trust
identifier as the scope parameter in addition to permissions requested.
CORS headers in AD FS responses - Customers can now build Single Page Applications that allow client side
JS libraries to validate the signature of the id_token by querying for the signing keys from the OIDC discovery
document on AD FS.
PKCE support - AD FS adds PKCE support to provide a secure auth code flow within OAuth. This adds an
additional layer of security to this flow to prevent hijacking the code and replaying it from a different client.
Bug fix: Send x5t and kid claim - This is a minor bug fix. AD FS now additionally sends the 'kid' claim to
denote the key id hint for verifying the signature. Previously AD FS only sent this as 'x5t' claim.
Supportability improvements
The following supportability improvements are not part of AD FS 2019:
Send error details to AD FS admins - Allows admins to configure end users to send debug logs relating to a
failure in end user authentication to be stored as a zipped filed for easy consumption. Admins can also
configure an SMTP connection to automail the zipped file to a triage email account or to auto create a ticket
based on the email.
Deployment updates
The following deployment updates are now included in AD FS 2019:
Farm Behavior Level 2019 - As with AD FS 2016, there is a new Farm Behavior Level version that is required
to enable new functionality discussed above. This allows going from:
2012 R2-> 2019
2016 -> 2019
SAML updates
The following SAML update is in AD FS 2019:
Bug fix: Fix bugs in aggregated federation - There have been numerous bug fixes around aggregated
federation support (e.g. InCommon). The fixes have been around the following:
Improved scaling for large # of entities in the aggregated federation metadata doc. Previously, this would
fail with "ADMIN0017" error.
Query using 'ScopeGroupID' parameter via Get-AdfsRelyingPartyTrustsGroup PSH cmdlet.
Handling error conditions around duplicate entityID
Azure AD style resource specification in scope parameter
Previously, AD FS required the desired resource and scope to be in a separate parameter in any authentication
request. For example, a typical oauth request would look like below: 7
https://fs.contoso.com/adfs/oauth2/authorize?
response_type=code&client_id=claimsxrayclient&resource=urn:microsoft:
adfs:claimsxray&scope=oauth&redirect_uri=https://adfshelp.microsoft.com/
ClaimsXray/TokenResponse&prompt=login
With AD FS on Server 2019, you can now pass the resource value embedded in the scope parameter. This is
consistent with how one can do authentication against Azure AD also.
The scope parameter can now be organized as a space separated list where each entry is structure as
resource/scope. For example
< create a valid sample request>
NOTE
Only one resource can be specified in the authentication request. If more than one resource is included in the request, AD FS
will return an error and authentication will not succeed.
Proof Key for Code Exchange (PKCE) support for oAuth

OAuth public clients using the Authorization Code Grant are susceptible to the authorization code interception
attack. The attack is well described in RFC 7636. To mitigate this attack, AD FS in Server 2019 supports Proof Key
for Code Exchange (PKCE ) for OAuth Authorization Code Grant flow.
To leverage the PKCE support, This specification adds additional parameters to the OAuth 2.0 Authorization and
Access Token Requests.
A. The client creates and records a secret named the "code_verifier" and derives a transformed version
"t(code_verifier)" (referred to as the "code_challenge"), which is sent in the OAuth 2.0 Authorization Request along
with the transformation method "t_m".
B. The Authorization Endpoint responds as usual but records "t(code_verifier)" and the transformation method.
C. The client then sends the authorization code in the Access Token Request as usual but includes the
"code_verifier" secret generated at (A).
D. The AD FS transforms "code_verifier" and compares it to "t(code_verifier)" from (B ). Access is denied if they are
not equal.
FAQ
Q. Can I pass resource value as part of the scope value like how requests are done against Azure AD?
A. With AD FS on Server 2019, you can now pass the resource value embedded in the scope parameter. The scope
parameter can now be organized as a space separated list where each entry is structure as resource/scope. For
example
Q. Does AD FS support PKCE extension?
A. AD FS in Server 2019 supports Proof Key for Code Exchange (PKCE ) for OAuth Authorization Code Grant flow
What's new in Active Directory Federation Services for Windows Server

2016
If you are looking for information on earlier versions of AD FS, see the following articles:
ADFS in Windows Server 2012 or 2012 R2 and AD FS 2.0
Active Directory Federation Services provides access control and single sign on across a wide variety of
applications including Office 365, cloud based SaaS applications, and applications on the corporate network.
For the IT organization, it enables you to provide sign on and access control to both modern and legacy
applications, on premises and in the cloud, based on the same set of credentials and policies.
For the user, it provides seamless sign on using the same, familiar account credentials.
For the developer, it provides an easy way to authenticate users whose identities live in the organizational
directory so that you can focus your efforts on your application, not authentication or identity.
This article describes what is new in AD FS in Windows Server 2016 (AD FS 2016).
Eliminate Passwords from the Extranet

AD FS 2016 enables three new options for sign on without passwords, enabling organizations to avoid risk of
network compromise from phished, leaked or stolen passwords.
Sign in with Azure Multi-factor Authentication
AD FS 2016 builds upon the multi-factor authentication (MFA) capabilities of AD FS in Windows Server 2012 R2
by allowing sign on using only an Azure MFA code, without first entering a username and password.
With Azure MFA as the primary authentication method, the user is prompted for their username and the OTP
code from the Azure Authenticator app.
With Azure MFA as the secondary or additional authentication method, the user provides primary
authentication credentials (using Windows Integrated Authentication, username and password, smart card, or
user or device certificate), then sees a prompt for text, voice, or OTP based Azure MFA login.
With the new built-in Azure MFA adapter, setup and configuration for Azure MFA with AD FS has never been
simpler.
Organizations can take advantage of Azure MFA without the need for an on premises Azure MFA server.
Azure MFA can be configured for intranet or extranet, or as part of any access control policy.
For more information about Azure MFA with AD FS
Password-less Access from Compliant Devices
AD FS 2016 builds on previous device registration capabilities to enable sign on and access control based the
device compliance status. Users can sign on using the device credential, and compliance is re-evaluated when
device attributes change, so that you can always ensure policies are being enforced. This enables policies such as
Enable Access only from devices that are managed and/or compliant
Enable Extranet Access only from devices that are managed and/or compliant
Require multi-factor authentication for computers that are not managed or not compliant
AD FS provides the on premises component of conditional access policies in a hybrid scenario. When you register
devices with Azure AD for conditional access to cloud resources, the device identity can be used for AD FS policies
as well.
For more information about using device based conditional access in the cloud
Azure Active Directory Conditional Access
For more information about using device based conditional access with AD FS
Planning for Device Based Conditional Access with AD FS
Access Control Policies in AD FS
Sign in with Windows Hello for Business
Windows 10 devices introduce Windows Hello and Windows Hello for Business, replacing user passwords with
strong device-bound user credentials protected by a user's gesture (a PIN, a biometric gesture like fingerprint, or
facial recognition). AD FS 2016 supports these new Windows 10 capabilities so that users can sign in to AD FS
applications from the intranet or the extranet without the need to provide a password.
For more information about using Microsoft Windows Hello for Business in your organization
Enable Windows Hello for Business in your organization
Secure Access to Applications

Modern Authentication
AD FS 2016 supports the latest modern protocols that provide a better user experience for Windows 10 as well as
the latest iOS and Android devices and apps.
For more information see AD FS Scenarios for Developers
Configure access control policies without having to know claim rules language
Previously, AD FS administrators had to configure policies using the AD FS claim rule language, making it difficult
to configure and maintain policies. With access control policies, administrators can use built in templates to apply
common policies such as
Permit intranet access only
Permit everyone and require MFA from Extranet
Permit everyone and require MFA from a specific group
The templates are easy to customize using a wizard driven process to add exceptions or additional policy rules and
can be applied to one or many applications for consistent policy enforcement.
For more information see Access control policies in AD FS.
Enable sign on with non-AD LDAP directories
Many organizations have a combination of Active Directory and third-party directories. With the addition of AD FS
support for authenticating users stored in LDAP v3-compliant directories, AD FS can now be used for:
Users in third party, LDAP v3 compliant directories
Users in Active Directory forests to which an Active Directory two-way trust is not configured
Users in Active Directory Lightweight Directory Services (AD LDS )
For more information see Configure AD FS to authenticate users stored in LDAP directories.
Better Sign-in experience

Customize sign in experience for AD FS applications
We heard from you that the ability to customize the logon experience for each application would be a great
usability improvement, especially for organizations who provide sign on for applications that represent multiple
different companies or brands.
Previously, AD FS in Windows Server 2012 R2 provided a common sign on experience for all relying party
applications, with the ability to customize a subset of text based content per application. With Windows Server
2016, you can customize not only the messages, but images, logo and web theme per application. Additionally, you
can create new, custom web themes and apply these per relying party.
For more information see AD FS user sign-in customization.
Manageability and Operational Enhancements

The following section describes the improved operational scenarios that are introduced with Active Directory
Federation Services in Windows Server 2016.
Streamlined auditing for easier administrative management
In AD FS for Windows Server 2012 R2 there were numerous audit events generated for a single request and the
relevant information about a log-in or token issuance activity is either absent (in some versions of AD FS ) or
spread across multiple audit events. By default the AD FS audit events are turned off due to their verbose nature.
With the release of AD FS 2016, auditing has become more streamlined and less verbose.
For more information see Auditing enhancements to AD FS in Windows Server 2016.
Improved interoperability with SAML 2.0 for participation in confederations
AD FS 2016 contains additional SAML protocol support, including support for importing trusts based on
metadata that contains multiple entities. This enables you to configure AD FS to participate in confederations such
as InCommon Federation and other implementations conforming to the eGov 2.0 standard.
For more information see Improved interoperability with SAML 2.0.
Simplified password management for federated O365 users
You can configure Active Directory Federation Services (AD FS ) to send password expiry claims to the relying
party trusts (applications) that are protected by AD FS. How these claims are used depends on the application. For
example, with Office 365 as your relying party, updates have been implemented to Exchange and Outlook to notify
federated users of their soon-to-be-expired passwords.
For more information see Configure AD FS to send password expiry claims.
Moving from AD FS in Windows Server 2012 R2 to AD FS in Windows Server 2016 is easier
Previously, migrating to a new version of AD FS required exporting configuration from the old farm and
importing to a brand new, parallel farm.
Now, moving from AD FS on Windows Server 2012 R2 to AD FS on Windows Server 2016 has become much
easier. Simply add a new Windows Server 2016 server to a Windows Server 2012 R2 farm, and the farm will act at
the Windows Server 2012 R2 farm behavior level, so it looks and behaves just like a Windows Server 2012 R2
farm.
Then, add new Windows Server 2016 servers to the farm, verify the functionality and remove the older servers
from the load balancer. Once all farm nodes are running Windows Server 2016, you are ready to upgrade the farm
behavior level to 2016 and begin using the new features.
For more information see Upgrading to AD FS in Windows Server 2016.
AD FS in Windows Server 2016 [AD FS 2016] enables you to add industry standard OpenID Connect and OAuth
2.0 based authentication and authorization to applications you are developing, and have those applications
authenticate users directly against AD FS.
AD FS 2016 also supports the WS -Federation, WS -Trust, and SAML protocols and profiles we have supported in
previous versions. If you are interested in developer guidance for these protocols, see the article here. This article
will focus on how to use and benefit from the newer protocol support.
Why Modern Authentication

While you can continue using AD FS for sign on with WS -Federation, WS -Trust, and SAML protocols just as you
have before, with the newer protocols, you get the following benefits:
Simplicity and consistency
Use the same set of APIs and patterns to enable sign on for:
multiple types of applications (server, desktop, mobile, browser)
multiple platforms (android, iOS, Windows)
applications inside the corporate network or hosted in the cloud
Use the same set of libraries you can already use to authenticate users against Azure AD
Flexibility
In addition to standard user authorization, enable more complex scenarios such as:
? 3-legged sign on flows in which a user authorizes one web application or service to access
resources that reside with another web app or service.
? Server-to-server flows in which a mid-tier service accesses a back end API
? JavaScript based single-page applications (SPA)
Industry support
OAuth 2.0 and OpenID Connect enjoy wide utilization across the industry, so knowledge of these
patterns will help you enable authentication and authorization outside of an Active Directory
environment as well
How it works: The Basics

You can add AD FS modern authentication to your application using the same set of tools and libraries you can
already use to authenticate users against Azure AD.
In AD FS scenarios of course, it is AD FS and not Azure AD that serves as the identity provider and authorization
server. Otherwise the concepts are exactly the same: users provide their credentials and obtain tokens, either
directly or via an intermediary, for access to resources.
The most basic scenario consists of a user or "resource owner", interacting with a browser to access a web
application:
The web application is called a "client" because it initiates the request to the authorization server (AD FS ) for an
access token to the resource. The resource may be hosted by the web app itself or may be accessible as a web API
somewhere on the network or internet. The user or "resource owner" authorizes the client web app to receive that
access token by providing credentials to the authorization server.
How it works: components

OAuth 2.0 and OpenID Connect scenarios in AD FS make use of the same set of tools and libraries you use when
Azure AD is the identity provider. These components are:
Active Directory Authentication Library (ADAL ): client libraries that facilitate collecting user credentials, creating
and submitting token requests and retrieving the resulting tokens.
OWIN (Open Web Interface for .NET) middleware: While OWIN is a community based project, Microsoft has
created a set of server side libraries that for protecting web applications and web APIs with OpenID Connect
and OAuth 2.0
The roles of these components are shown in the diagram below:
Modeling these scenarios in AD FS 2016
Application Groups
To represent these scenarios in AD FS policy, we have introduced a new concept called Application Groups. An
application group can contain any number and combination of the following fundamental types of application:
APPLICATION GROUP / APPLICATION TYPE DESCRIPTION ROLE
Native application Sometimes called a public client, this is Requests tokens from the authorization
intended to be a client app that runs on server (AD FS) for user access to
a pc or device and with which the user resources. Sends HTTP requests to
interacts. protected resources, using the tokens as
HTTP headers.
Server application A web application that runs on a server Requests tokens from the authorization
and is generally accessible to users via a server (AD FS) for user access to
browser. Because it is capable of resources. Sends HTTP requests to
maintaining its own client 'secret' or protected resources, using the tokens as
credential, it is sometimes called a HTTP headers.
confidential client.
Web API The end resource the user is accessing. Consumes tokens obtained by clients
Think of these as the new
representation of "relying parties".
Differences from AD FS 2012 R2

Application groups combine trust and authorization elements that AD FS 2012 R2 exposed separately, as relying
parties, clients, and application permissions.
The following tables compares the methods by which corresponding application trust objects are created in AD FS
2012 R2 vs AD FS 2016:
AD FS IN WINDOWS SERVER 2012 R2 IN POWERSHELL AD FS MANAGEMENT
Add native client Add-AdfsClient NA
Add server application as client Add-AdfsClient NA
Add Web API / resource Add-AdfsRelyingPartyTrust Create Relying Party Trust
AD FS 2016 IN POWERSHELL AD FS MANAGEMENT
Add native client Add-AdfsNativeClientApplication Add Native Application to Application

Group
Add server application as client Add-AdfsServerApplication Add Server Application to Application

Group
Add Web API / resource Add-AdfsWebApiApplication Add Web API Application to Application
Group
Application Permissions and Consent

By default, the clients in an application group are allowed to access the resources in the same group. The
administrator does not have to configure specific application permissions. Application groups also allow
administrators to specify the scopes allowed, such as openid or user_impersonation. The scenario descriptions
below specify exactly which scopes are required for which scenario.
Because AD FS uses a model of administrator consent, users are not prompted for consent when accessing
resources. By configuring the application group, the administrator in effect provides consent on behalf of all
application users.
Supported Scenarios
The following section describes the scenarios we support in more detail.
Tokens used
These scenarios make use of three token types:
id_token: A JWT token used to represent the identity of the user. The 'aud' or audience claim of the id_token
matches the client ID of the native or server application.
access_token: A JWT token used in Oauth and OpenID connect scenarios and intended to be consumed by the
resource. The 'aud' or audience claim of this token must match the identifier of the resource or Web API.
refresh_token: This token is submitted in place of collecting user credentials to provide a single sign on
experience. This token is both issued and consumed by AD FS, and is not readable by clients or resources.
Native client to Web API
This scenario enables the user of a native client application to call an AD FS 2016 protected Web API.
The native client application uses ADAL to send authorization and token requests to AD FS, prompting for
credentials from the user as necessary, then sends the resulting token as an HTTP header on the request to the
Web API
[This part is for demonstration purposes only] The web API reads the claims from the ClaimsPrincipal object
that results from the access token sent by the client, and sends them back to the client.
1. The native client application initiates the flow with a call to the ADAL library. This triggers a browser based
HTTP GET to the AD FS authorize endpoint:
Authorization request:
GET https://fs.contoso.com/adfs/oauth2/authorize?
PARAMETER VALUE
response_type "code"
resource RP ID (Identifier) of Web API in application group
client_id client Id of the native application in the application group
redirect_uri Redirect URI of native application in application group
Authorization request response:

If the user has not signed in before, the user is prompted for credentials.
AD FS responds by returning an authorization code as the "code" parameter in the query component of the
redirect_uri. For example: HTTP/1.1 302 Found Location: http://redirect_uri:80/?code=<code>;.
1. The native client then sends the code, along with the following parameters, to the AD FS token endpoint:
Token Request:
POST https://fs.contoso.com/adfs/oauth2/token
PARAMETER VALUE
grant_type "authorization_code"
code authorization code from 1

PARAMETER VALUE
redirect_uri Redirect URI of native application in application group
Token request response:

AD FS responds with an HTTP 200 with the access_token, refresh_token, and id_token in the body.
1. The native application then sends the access_token part of the above response as the Authorization header in
the HTTP request to the web API.
Single sign on behavior
Subsequent client requests within 1 hour (by default) the access_token will still be valid in the cache, and a new
request will not trigger any traffic to AD FS. The access_token will automatically be fetched from the cache by
ADAL.
After the access token expires, ADAL will automatically send a refresh token based request to the AD FS token
endpoint (skipping the authorization request automatically).
Refresh token request:
PARAMETER VALUE
grant_type "refresh_token"
refresh_token the refresh token issued by AD FS in response to the initial

token request
Refresh token request response:

If the refresh token is within <SSO_period>, the request will result in a new access token. The user is not prompted
for credentials. For more information on SSO settings see AD FS Single Sign On Settings
If the refresh token has expired, the request results in an HTTP 401 with error "invalid_grant" and
"error_description" "MSIS9615: The refresh token received in refresh_token parameter has expired". In this case,
ADAL automatically submits a new authorization request that looks just like #1 above.
Web Browser to Web App
In this scenario, a user with a browser needs to access resources hosted by a web application.
There are two scenarios that accomplish this.
Oauth confidential client
This scenario is similar to the above in that there is an authorization request, followed by a code for token exchange.
The web app (modeled as a Server Application in AD FS ) initiates the authorization request via the browser and
exchanges the code for the token (by connecting directly to AD FS )
1. The Web App initiates an authorization request via the browser, which sends an HTTP GET to the AD FS
authorize endpoint
PARAMETER VALUE
response_type "code"
client_id Client Id of the native application in the application group
redirect_uri Redirect URI of web app (server application) in application

group

AD FS responds by returning an authorization code as the "code" parameter in the query component of the
redirect_uri, for example: HTTP/1.1 302 Found Location: https://webapp.contoso.com/?code=<code>;.
1. As a result of the above 302, the browser initiates an HTTP GET to the web app, for example: GET
http://redirect_uri:80/?code=<code>;.
2. At this point the web app, having received the code, initiates a request to the AD FS token endpoint, sending
the following
Token request:
PARAMETER VALUE
code authorization code from 2 above

PARAMETER VALUE
client_id Client Id of the web app (server application) in the application

group

group
client_secret Secret of the web app (server application) in the application

group. Note: The client's credential does not need to be a
client_secret. AD FS supports the ability to use certificates
or Windows Integrated Authentication as well.

claims
1. The web application then either consumes the access_token part of the above response (in the case in which the
web app itself hosts the resource), or otherwise sends it as the Authorization header in the HTTP request to the
web API.
Single sign on behavior
While the access token will still be valid for 1 hour (by default) in the client's cache, you may think that the second
request will work as in the native client scenario above - that a new request will not trigger any traffic to AD FS as
the access token will automatically be fetched from the cache by ADAL. However, it is possible that the web app can
send distinct authorization and token requests, the former via distinct URL link, as in our sample.
In this case, it is the AD FS browser SSO cookie that enables AD FS to issue a new authorization code without
prompting the user for credentials. The web app then calls to AD FS to exchange the new authorization code for a
new access token. The user is not prompted for credentials.
Otherwise, if the web app is smart enough to know if the user is already authenticated, the authorize request can be
skipped and either:
the cached access token, if not expired, is retrieved and used, or
a request token based request can be sent to the AD FS token endpoint, as described below
Refresh token request:
PARAMETER VALUE
grant_type "refresh_token"

group
refresh_token Refresh token issued by AD FS in response to the initial token

request

group
Refresh token request response:
If the refresh token is within <SSO_period>, the request will result in a new access token. The user is not prompted
for credentials. For more information on SSO settings see AD FS Single Sign On Settings
If the refresh token has expired, the request results in an HTTP 401 with error "invalid_grant" and
"error_description" "MSIS9615: The refresh token received in refresh_token parameter has expired". In this case,
ADAL automatically submits a new authorization request that looks just like #1 above.
OpenID Connect: Hybrid flow
This scenario is similar to the above in that there is an authorization request initiated by the web app via browser
redirect, and a code for token exchange from the web app to AD FS. The difference in this scenario is that AD FS
issues an id_token as part of the initial authorization request response.
1. The Web App initiates an authorization request via the browser, which sends an HTTP GET to the AD FS
authorize endpoint
PARAMETER VALUE
response_type "code+id_token"
response_mode "form_post"

group
redirect_uri Redirect URI of web app (server application) in the application

group

AD FS responds with an HTTP 200 and form containing the below as hidden elements:
code: the authorization code
id_token: a JWT token containing claims describing the user authentication
The form automatically posts to the redirect_uri of the web app, sending the code and the id_token to the web
app.
1. At this point the web app, having received the code, initiates a request to the AD FS token endpoint, sending the
following
Token request:
PARAMETER VALUE
code authorization code from above

group

group

group

1. The web application then either consumes the access_token part of the above response (in the case in which the
web app itself hosts the resource), or otherwise sends it as the Authorization header in the HTTP request to the
web API.
Single Sign on behavior
The single sign on behavior is the same as for the Oauth 2.0 confidential client flow above.
On Behalf Of
In this scenario, a web app uses the original access token from a user to request and obtain another access token
for another Web API, which the web app will then access as the end user. This is called an "on behalf of" flow.
Steps 1 and 2 work just like steps 3 and 4 in the previous flow.
In Step 3, the key requirement is that the client_id parameter, the client ID of the Web app 2, must match the RP ID
of Web API A. In other words, the audience of the access token being exchanged for the new token must match the
client ID of the entity requesting the new token.
Related content
See AD FS Development for the complete list of walk-through articles, which provide step-by-step instructions on
using the related flows.
AD FS Requirements
The following are the requirements for deploying AD FS:

Certificate requirements
Hardware requirements
Proxy requirements
AD DS requirements
Configuration database requirements
Browser requirements
Network requirements
Permissions requirements
SSL Certificates
Each AD FS and Web Application Proxy server has an SSL certificate to service HTTPS requests to the federation
service. The Web Application Proxy can have additional SSL certificates to service requests to published
applications.
Recommendation: Use the same SSL certificate for all AD FS federation servers and Web Application proxies.
Requirements:
SSL certificates on federation servers must meet the following requirements
Certificate is publicly trusted (for production deployments)
Certificate contains the Server Authentication Enhanced Key Usage (EKU ) value
Certificate contains the federation service name, such as "fs.contoso.com" in the Subject or Subject Alternative
Name (SAN )
For user certificate authentication on port 443, certificate contains "certauth.<federation service name>", such
as "certauth.fs.contoso.com" in the SAN
For device registration or for modern authentication to on premises resources using pre-Windows 10 clients,
the SAN must contain "enterpriseregistration.<upn suffix>" for each UPN suffix in use in your organization.
SSL certificates on the Web Application Proxy must meet the following requirements
If the proxy is used to proxy AD FS requests that use Windows Integrated Authentication, the proxy SSL
certificate must be the same (use the same key) as the federation server SSL certificate
If the AD FS property "ExtendedProtectionTokenCheck" is enabled (the default setting in AD FS ), the proxy SSL
Otherwise, the requirements for the proxy SSL certificate are the same as those for the federation server SSL
certificate
Service Communication Certificate
This certificate is not required for most AD FS scenarios including Azure AD and Office 365. By default, AD FS
configures the SSL certificate provided upon initial configuration as the service communication certificate.
Recommendation:
Use the same certificate as you use for SSL.
Token Signing Certificate
This certificate is used to sign issued tokens to relying parties, so relying party applications must recognize the
certificate and it's associated key as known and trusted. When the token signing certificate changes, such as when it
expires and you configure a new certificate, all relying parties must be updated.
Recommendation: Use the AD FS default, internally generated, self-signed token signing certificates.
Requirements:
If your organization requires that certificates from the enterprise PKI be used for token signing, this can be done
using the SigningCertificateThumbprint parameter of the Install-AdfsFarm cmdlet.
Whether you use the default internally generated certificates or externally enrolled certificates, when the token
signing certificate is changed you must ensure all relying parties are updated with the new certificate
information. Otherwise, logons to any relying parties not updated will fail.
Token Encrypting/Decrypting Certificate
This certificate is used by claims providers who encrypt tokens issued to AD FS.
Recommendation: Use the AD FS default, internally generated, self-signed token decrypting certificates.
Requirements:
If your organization requires that certificates from the enterprise PKI be used for token signing, this can be done
using the DecryptingCertificateThumbprint parameter of the Install-AdfsFarm cmdlet.
Whether you use the default internally generated certificates or externally enrolled certificates, when the token
decrypting certificate is changed you must ensure all claims providers are updated with the new certificate
information. Otherwise, logons using any claims providers not updated will fail.
Cau t i on
Certificates that are used for token-signing and token-decrypting/encrypting are critical to the stability of the
Federation Service. Customers managing their own token-signing & token-decrypting/encrypting certificates
should ensure that these certificates are backed up and are available independently during a recovery event.
User Certificates
When using x509 user certificate authentication with AD FS, all user certificates must chain up to a root
certification authority that is trusted by the AD FS and Web Application Proxy servers.
AD FS and Web Application Proxy hardware requirements (physical or virtual) are gated on CPU, so you should
size your farm for processing capacity.
Use the AD FS 2016 Capacity Planning spreadsheet to determine the number of AD FS and Web Application
Proxy servers you will need.
The memory and disk requirements for AD FS are fairly static, see the table below:
HARDWARE REQUIREMENT MINIMUM REQUIREMENT RECOMMENDED REQUIREMENT
RAM 2 GB 4 GB
Disk space 32 GB 100 GB
SQL Server Hardware Requirements

If you are using SQL Server for your AD FS configuration database, size the SQL Server according to the most
basic SQL Server recommendations. The AD FS database size is very small, and AD FS does not put a significant
processing load on the database instance. AD FS does, however, connect to the database multiple times during an
authentication, so the network connection should be robust. Unfortunately, SQL Azure is not supported for the AD
FS configuration database.
Proxy requirements
For extranet access, you must deploy the Web Application Proxy role service - part of the Remote Access
server role.
Third party proxies must support the MS -ADFSPIP protocol to be supported as an AD FS proxy. For a list
of 3rd party vendors see the FAQ.
AD FS 2016 requires Web Application Proxy servers on Windows Server 2016. A downlevel proxy cannot
be configured for an AD FS 2016 farm running at the 2016 farm behavior level.
A federation server and the Web Application Proxy role service cannot be installed on the same computer.
AD DS requirements
Domain controller requirements
AD FS requires Domain controllers running Windows Server 2008 or later.
At least one Windows Server 2016 domain controller is required for Microsoft Passport for Work.
NOTE
All support for environments with Windows Server 2003 domain controllers has ended. Visit this page for additional
information on the Microsoft Support Lifecycle.
Domain functional-level requirements

All user account domains and the domain to which the AD FS servers are joined must be operating at the
domain functional level of Windows Server 2003 or higher.
A Windows Server 2008 domain functional level or higher is required for client certificate authentication if
the certificate is explicitly mapped to a user's account in AD DS.
Schema requirements
New installations of AD FS 2016 require the Active Directory 2016 schema (minimum version 85).
Raising the AD FS farm behavior level (FBL ) to the 2016 level requires the Active Directory 2016 schema
(minimum version 85).
Service account requirements

Any standard domain account can be used as a service account for AD FS. Group Managed Service
accounts are also supported. The permissions required at runtime will be added automatically when you
configure AD FS.
Group Managed service accounts require at least one domain controller running Windows Server 2012 or
higher. The GMSA must live under the default 'CN=Managed Service Accounts' container.
For Kerberos authentication, the service principal name ‘ HOST/<adfs\_service\_name> ’ must be registered on
the AD FS service account. By default, AD FS will configure this when creating a new AD FS farm. If this
fails, such as in the case of a collision or insufficient permissions, you'll see a warning and you should add it
manually.
Domain Requirements
All AD FS servers must be a joined to an AD DS domain.
All AD FS servers within a farm must be deployed in the same domain.
Multi Forest Requirements
The domain to which the AD FS servers are joined must trust every domain or forest that contains users
authenticating to the AD FS service.
The forest, that the AD FS service account is a member of, must trust all user login forests.
The AD FS service account must have permissions to read user attributes in every domain that contains
users authenticating to the AD FS service.

This section describes the requirements and restrictions for AD FS farms that use respectively the Windows
Internal Database (WID ) or SQL Server as the database:
WID
The artifact resolution profile of SAML 2.0 is not supported in a WID farm.
Token replay detection is not supported a WID farm. (This functionality is only used only in scenarios where
AD FS is acting as the federation provider and consuming security tokens from external claims providers.)
The following table provides a summary of how many AD FS servers are supported in a WID vs a SQL Server
farm.
1 - 100 RELYING PARTY (RP) TRUSTS

CONFIGURED IN AD FS MORE THAN 100 RP TRUSTS CONFIGURED
1 - 30 AD FS servers WID Supported Not supported using WID - SQL Server

required
More than 30 AD FS servers Not supported using WID - SQL Server Not supported using WID - SQL Server
required required
SQL Server
For AD FS in Windows Server 2016, SQL Server 2008 and higher versions are supported.
Both SAML artifact resolution and token replay detection are supported in a SQL Server farm.
When AD FS authentication is performed via a browser or browser control, your browser must comply to the
following requirements:
JavaScript must be enabled
For single sign on, the client browser must be configured to allow cookies
Server Name Indication (SNI) must be supported
For user certificate & device certificate authentication, the browser must support SSL client certificate
authentication
For seamless sign on using Windows Integrated Authentication, the federation service name (such as
https://fs.contoso.com) must be configured in local intranet zone or trusted sites zone.
Firewall Requirements
Both the firewall located between the Web Application Proxy and the federation server farm and the firewall
between the clients and the Web Application Proxy must have TCP port 443 enabled inbound.
In addition, if client user certificate authentication (clientTLS authentication using X509 user certificates) is required
and the certauth endpoint on port 443 is not enabled, AD FS 2016 requires that TCP port 49443 be enabled
inbound on the firewall between the clients and the Web Application Proxy. This is not required on the firewall
between the Web Application Proxy and the federation servers).
For additional information on hybrid port requirements see Hybrid Identity Ports and Protocols.
For additional information see Best practices for securing Active Directory Federation Services
DNS Requirements
For intranet access, all clients accessing AD FS service within the internal corporate network (intranet) must
be able to resolve the AD FS service name to the load balancer for the AD FS servers or the AD FS server.
For extranet access, all clients accessing AD FS service from outside the corporate network
(extranet/internet) must be able to resolve the AD FS service name to the load balancer for the Web
Application Proxy servers or the Web Application Proxy server.
Each Web Application Proxy server in the DMZ must be able to resolve AD FS service name to the load
balancer for the AD FS servers or the AD FS server. This can be achieved using an alternate DNS server in
the DMZ network or by changing local server resolution using the HOSTS file.
For Windows Integrated authentication, you must use a DNS A record (not CNAME ) for the federation
service name.
For user certificate authentication on port 443, "certauth.<federation service name>" must be configured in
DNS to resolve to the federation server or web application proxy.
For device registration or for modern authentication to on premises resources using pre-Windows 10
clients, "enterpriseregistration.<upn suffix>", for each UPN suffix in use in your organization, must be
configured to resolve to the federation server or web application proxy.
Load Balancer requirements
The load balancer MUST NOT terminate SSL. AD FS supports multiple use cases with certificate authentication
which will break when terminating SSL. Terminating SSL at the load balancer is not supported for any use case.
It is recommended to use a load balancer that supports SNI. In the event it does not, using the 0.0.0.0 fallback
binding on your AD FS / Web Application Proxy server should provide a workaround.
It is recommended to use the HTTP (not HTTPS ) health probe endpoints to perform load balancer health checks
for routing traffic. This avoids any issues relating to SNI. The response to these probe endpoints is an HTTP 200
OK and is served locally with no dependence on back-end services. The HTTP probe can be accessed over
HTTP using the path ‘/adfs/probe’
http://<Web Application Proxy name>/adfs/probe
http://<ADFS server name>/adfs/probe
http://<Web Application Proxy IP address>/adfs/probe
http://<ADFS IP address>/adfs/probe
It is NOT recommended to use DNS round robin as a way to load balance. Using this type of load balancing
does not provide an automated way to remove a node from the load balancer using health probes.
It is NOT recommended to use IP based session affinity or sticky sessions for authentication traffic to AD FS
within the load balancer. This can cause an overload of certain nodes when using legacy authentication protocol
for mail clients to connect to Office 365 mail services (Exchange Online).
The administrator that performs the installation and the initial configuration of AD FS must have local
administrator permissions on the AD FS server. If the local administrator does not have permissions to create
objects in Active Directory, they must first have a domain admin create the required AD objects, then configure the
AD FS farm using the AdminConfiguration parameter.
AD FS Design
AD FS Design Guide
See Also
For capacity planning for AD FS in Windows Server 2016 see the AD FS capacity planning worksheet.
Active Directory Federation Services Overview
AD FS 2016 Design Guide
The AD FS design guide is a comprehensive guide for designing AD FS deployments. This guide is made up of the
following:
See Also
For capacity planning for AD FS in Windows Server 2016 see the AD FS capcity planning worksheet.
Active Directory Federation Services (AD FS ) provides simplified, secured identity federation and Web single sign-
on (SSO ) capabilities for end users who want to access applications within an AD FS -secured enterprise, in
federation partner organizations, or in the cloud.
In Windows Server® 2012 R2, AD FS includes a federation service role service that acts as an identity provider
(authenticates users to provide security tokens to applications that trust AD FS ) or as a federation provider
(consumes tokens from other identity providers and then provides security tokens to applications that trust AD FS ).
The function of providing extranet access to applications and services that are secured by AD FS in Windows
Server 2012 R2 is now performed by a new Remote Access role service called Web Application Proxy. This is a
departure from the prior versions of Windows Server in which this function was handled by an AD FS federation
server proxy. Web Application Proxy is a server role designed to provide access for the AD FS -related extranet
scenario and other extranet scenarios. For more information on Web Application Proxy, see Web Application Proxy
Walkthrough Guide.
About this guide

This guide provides recommendations to help you plan a new deployment of AD FS, based on the requirements of
your organization. This guide is intended for use by an infrastructure specialist or system architect. It highlights
your main decision points as you plan your AD FS deployment. Before you read this guide, you should have a good
understanding of how AD FS works on a functional level. For more information, see Understanding Key AD FS
Concepts.
In this guide
AD FS Requirements
See Also
AD FS Design
Correctly identifying your Active Directory Federation Services (AD FS ) deployment goals is essential for the
success of your AD FS design project. Prioritize and, possibly, combine your deployment goals so that you can
design and deploy AD FS by using an iterative approach. You can take advantage of existing, documented, and
predefined AD FS deployment goals that are relevant to the AD FS designs and develop a working solution for
your situation.
Prior versions of AD FS were most commonly deployed to achieve the following:
Providing your employees or customers with a web-based, SSO experience when accessing claims-based
applications within your enterprise.
Providing your employees or customers with a web-based, SSO experience to access resources in any
federation partner organization.
Providing your employees or customers with a Web-based, SSO experience when remote accessing
internally hosted Web sites or services.
Providing your employees or customers with a web-based, SSO experience when accessing resources or
services in the cloud.
In addition to these, AD FS in Windows Server® 2012 R2 adds functionality that can help you achieve the
following:
Device workplace join for SSO and seamless second factor authentication. This enables organizations to
allow access from user’s personal devices and manage the risk when providing this access.
Managing risk with multi-factor access control. AD FS provides a rich level of authorization that controls
who has access to what applications. This can be based on user attributes (UPN, email, security group
membership, authentication strength, etc.), device attributes (whether the device is workplace joined) or
request attributes (network location, IP address, or user agent).
Managing risk with additional multi-factor authentication for sensitive applications. AD FS allows you to
control policies to potentially require multi-factor authentication globally or on a per application basis. In
addition, AD FS provides extensibility points for any multi-factor vendor to integrate deeply for a secure and
seamless multi-factor experience for end users.
Providing authentication and authorization capabilities for accessing web resources from the extranet that
are protected by the Web Application Proxy.
To summarize, AD FS in Windows Server 2012 R2 can be deployed to achieve the following goals in your
organization:
Enable your users to access resources on their personal devices from anywhere
Workplace join that enables users to join their personal devices to corporate Active Directory and as a result
gain access and seamless experiences when accessing corporate resources from these devices.
Pre-authentication of resources inside the corporate network that are protected by the Web Application
proxy and accessed from the internet.
Password change to enable users to change their password from any workplace joined device when their
password has expired so that they can continue to access resources.
Enhance your access control risk management tools
Managing risk is an important aspect of governance and compliance in every IT organization. There are numerous
access control risk management enhancements in AD FS in Windows Server® 2012 R2, including the following:
Flexible controls based on network location to govern how a user authenticates to access an AD FS -secured
application.
Flexible policy to determine if a user needs to perform multi-factor authentication based on the user’s data,
device data, and network location.
Per-application control to ignore SSO and force the user to provide credentials every time they access a
sensitive application.
Flexible per-application access policy based on user data, device data, or network location.
AD FS Extranet Lockout, which enables administrators to protect Active Directory accounts from brute force
attacks from the internet.
Access revocation for any workplace joined device that is disabled or deleted in Active Directory.
Use AD FS to enhance the sign-in experience
The following are new AD FS capabilities in Windows Server® 2012 R2 that enable administrator to customize
and enhance the sign-in experience:
Unified customization of the AD FS service, where the changes are made once and then automatically
propagated to the rest of the AD FS federation servers in a given farm.
Updated sign-in pages that look modern and cater to different form factors automatically.
Support for automatic fallback to forms-based authentication for devices that are not joined to the corporate
domain but are still used generate access requests from within the corporate network (intranet).
Simple controls to customize the company logo, illustration image, standard links for IT support, home page,
privacy, etc.
Customization of description messages in the sign-in pages.
Customization of web themes.
Home Realm Discovery (HRD ) based on organizational suffix of the user for enhanced privacy of a
company’s partners.
HRD filtering on a per-application basis to automatically pick a realm based on the application.
One-click error reporting for easier IT troubleshooting.
Customizable error messages.
User authentication choice when more than one authentication provider is available.
See Also
The first step in planning a deployment of Active Directory Federation Services (AD FS ) is to determine the right
deployment topology to meet the needs of your organization.
Before you read this topic, review how AD FS data is stored and replicated to other federation servers in a
federation server farm and make sure you understand the purpose of and the replication methods that can be used
for the underlying data that is stored in the AD FS configuration database.
There are two database types that you can use to store AD FS configuration data: Windows Internal Database
(WID ) and Microsoft SQL Server. For more information, see The Role of the AD FS Configuration Database.
Review the various benefits and limitations that are associated with using either WID or SQL Server as the AD FS
configuration database, along with the various application scenarios that they support and then make your
selection.
IMPORTANT
To implement basic redundancy, load balancing, and the option to scale the Federation Service (if required), we recommend
that you deploy at least two federation servers per federation server farm for all production environments, regardless of the
type of database that you will use.
Determining which type of AD FS configuration database to use

AD FS uses a database to store configuration and—in some cases—transactional data related to the Federation
Service. You can use the AD FS software to select either the built-in Windows Internal Database (WID ) or Microsoft
SQL Server 2008 or newer to store the data in the Federation Service.
For most purposes, the two database types are relatively equivalent. However, there are some differences to be
aware of before you begin reading more about the various deployment topologies that you can use with AD FS.
The following table describes the differences in supported features between a WID database and a SQL Server
database.
FEATURE SUPPORTED BY WID? SUPPORTED BY SQL SERVER?
AD FS features Federation server farm Yes. A WID farm has a limit Yes. There is no enforced
deployment of 30 federation servers if limit for the number of
you have 100 or fewer federation servers that you
relying party trusts. can deploy in a single farm
A WID farm does not
support token replay
detection or artifact
resolution (part of the
Security Assertion Markup
Language (SAML) protocol).
FEATURE SUPPORTED BY WID? SUPPORTED BY SQL SERVER?
AD FS features SAML artifact resolution No Yes

Note: This feature is not
required for Microsoft Online
Services, Microsoft Office
365, Microsoft Exchange, or
Microsoft Office SharePoint
scenarios.
AD FS features SAML/WS-Federation token No Yes

replay detection
Database features Basic database redundancy Yes No

using pull replication, where
one or more servers hosting
a read-only copy of the
database request changes
that are made on a source
server that hosts a
read/write copy of the
database
Database features Database redundancy using No Yes

high-availability solutions,
such as failover clustering or
mirroring (at the database
layer only) Note: All AD FS
deployment topologies
support clustering at the AD
FS service layer.
SQL Server considerations

You should consider the following deployment facts if you select SQL Server as the configuration database for your
AD FS deployment.
SAML features and their effect on database size and growth. When either the SAML artifact resolution
or SAML token replay detection features are enabled, AD FS stores information in the SQL Server
configuration database for each AD FS token that is issued. The growth of the SQL Server database as a
result of this activity is not considered to be significant, and it depends on the configured token replay
retention period. Each artifact record has a size of approximately 30 kilobytes (KB ).
Number of servers required for your deployment. You will need to add at least one additional server (to
the total number of servers required to deploy your AD FS infrastructure) that will act as a dedicated host of
the SQL Server instance. If you plan to use failover clustering or mirroring to provide fault tolerance and
scalability for the SQL Server configuration database, a minimum of two SQL servers is required.
How the configuration database type you select may impact hardware
resources
The impact to hardware resources on a federation server that is deployed in a farm using WID as opposed to a
federation server that is deployed in a farm using the SQL Server database is not significant. However, it is
important to consider that when you use WID for the farm, each federation server in that farm must store, manage,
and maintain replication changes for its local copy of the AD FS configuration database while also continuing to
provide the normal operations that the Federation Service requires.
In comparison, federation servers that are deployed in a farm that uses the SQL Server database do not necessarily
contain a local instance of the AD FS configuration database. Therefore, they may make slightly fewer demands on
hardware resources.
Where to place a federation server

As a security best practice, place AD FS federation servers in front of a firewall and connect them to your corporate
network to prevent exposure from the Internet. This is important because federation servers have full authorization
to grant security tokens. Therefore, they should have the same protection as a domain controller. If a federation
server is compromised, a malicious user has the ability to issue full access tokens to all Web applications and to
federation servers that are protected by AD FS.
NOTE
As a security best practice, avoid having your federation servers directly accessible on the Internet. Consider giving your
federation servers direct Internet access only when you are setting up a test lab environment or when your organization does
not have a perimeter network.
For typical corporate networks, an intranet-facing firewall is established between the corporate network and the
perimeter network, and an Internet-facing firewall is often established between the perimeter network and the
Internet. In this situation, the federation server sits inside the corporate network, and it is not directly accessible by
Internet clients.
NOTE
Client computers that are connected to the corporate network can communicate directly with the federation server through
Windows Integrated Authentication.
A federation server proxy should be placed in the perimeter network before you configure your firewall servers for
use with AD FS.
Supported deployment topologies

The following topics describe the various deployment topologies that you can use with AD FS. They also describe
the benefits and limitations associated with each deployment topology so that you can select the most appropriate
topology for your specific business needs.
Federation Server Farm Using WID
Federation Server Farm Using WID and Proxies
Federation Server Farm Using SQL Server
See Also
The default topology for Active Directory Federation Services (AD FS ) is a federation server farm, using the
Windows Internal Database (WID ). In this topology, AD FS uses WID as the store for the AD FS configuration
database for all federation servers that are joined to that farm. The farm replicates and maintains the Federation
Service data in the configuration database across each server in the farm. AD FS in Windows Server 2012 R2
enables organizations with 100 or fewer relying party trusts to configure federation server farms using WID with
up to 30 servers.
The act of creating the first federation server in a farm also creates a new Federation Service. When you use WID
for the AD FS configuration database, the first federation server that you create in the farm is referred to as the
primary federation server. This means that this computer is configured with a read/write copy of the AD FS
configuration database.
All other federation servers that you configure for this farm are referred to as secondary federation servers because
they must replicate any changes that are made on the primary federation server to the read-only copies of the AD
FS configuration database that they store locally.
IMPORTANT
We recommend the use of at least two federation servers in a load-balanced configuration.
Deployment considerations
This section describes various considerations about the intended audience, benefits, and limitations that are
associated with this deployment topology.
Who should use this topology?
Organizations with 100 or fewer configured trust relationships that need to provide their internal users
(logged on to computers that are physically connected to the corporate network) with single sign-on (SSO )
access to federated applications or services
Organizations that want to provide their internal users with SSO access to Microsoft Online Services or
Smaller organizations that require redundant, scalable services
NOTE
Organizations with larger databases should consider using the Federation Server Farm Using SQL Server deployment
topology. Organizations with users who log in from outside the network should consider using either the Federation Server
Farm Using WID and Proxies topology or the Federation Server Farm Using SQL Server topology.
What are the benefits of using this topology?

Provides SSO access to internal users
Data and Federation Service redundancy (each federation server replicates changes to other federation
servers in the same farm)
WID is included with Windows; therefore, no need to purchase SQL Server
What are the limitations of using this topology?
A WID farm has a limit of 30 federation servers if you have 100 or fewer relying party trusts.
A WID farm does not support token replay detection or artifact resolution (part of the Security Assertion
Markup Language (SAML ) protocol).
The following table provides a summary for using a WID farm. Use it to plan your implementation.
1 - 100 RP TRUSTS MORE THAN 100 RP TRUSTS
1 - 30 AD FS Nodes WID Supported Not supported using WID - SQL

Required
More than 30 AD FS Nodes Not supported using WID - SQL Not supported using WID - SQL
Required Required
Server placement and network layout recommendations

When you are ready to start deploying this topology in your network, you should plan on placing all of the
federation servers in your corporate network behind a Network Load Balancing (NLB ) host that can be configured
for an NLB cluster with a dedicated cluster Domain Name System (DNS ) name and cluster IP address.
NOTE
This cluster DNS name must match the Federation Service name, for example, fs.fabrikam.com.
The NLB host can use the settings that are defined in this NLB cluster to allocate client requests to the individual
federation servers. The following illustration shows how the fictional Fabrikam, Inc., company sets up the first phase
of its deployment using a two-computer federation server farm (fs1 and fs2) with WID and the positioning of a
DNS server and a single NLB host that is wired to the corporate network.
NOTE
If there is a failure on this single NLB host, users will not be able to access federated applications or services. Add additional
NLB hosts if your business requirements do not allow having a single point of failure.
For more information about how to configure your networking environment for use with federation servers, see
the Name Resolution Requirements section in AD FS Requirements.
See Also
This deployment topology for Active Directory Federation Services (AD FS ) is identical to the federation server
farm with Windows Internal Database (WID ) topology, but it adds proxy computers to the perimeter network to
support external users. These proxies redirect client authentication requests that come from outside your corporate
network to the federation server farm. In previous versions of AD FS, these proxies were called federation server
proxies.
IMPORTANT
In Active Directory Federation Services (AD FS) in Windows Server 2012 R2 , the role of a federation server proxy is handled
by a new Remote Access role service called Web Application Proxy. To enable your AD FS for accessibility from outside the
corporate network, which was the purpose of deploying a federation server proxy in legacy versions of AD FS, such as AD FS
2.0 and AD FS in Windows Server 2012 , you can deploy one or more web application proxies for AD FS in Windows Server
2012 R2 .
In the context of AD FS, Web Application Proxy functions as an AD FS federation server proxy. In addition to this, Web
Application Proxy provides reverse proxy functionality for web applications inside your corporate network to enable users on
any device to access them from outside the corporate network. For more information, about the Web Application Proxy role
service, see Web Application Proxy Overview.
To plan the deployment of Web Application proxy, you can review the information in the following topics:
Plan the Web Application Proxy Infrastructure (WAP)
Plan the Web Application Proxy Server
Organizations with 100 or fewer configured trust relationships that need to provide both their internal users
and external users (who are logged on to computers that are physically located outside the corporate
network) with single sign-on (SSO ) access to federated applications or services
Organizations that need to provide both their internal users and external users with SSO access to Microsoft
Office 365
Smaller organizations that have external users and require redundant, scalable services
The same benefits as listed for the Federation Server Farm Using WID topology, plus the benefit of providing
additional access for external users
The same limitations as listed for the Federation Server Farm Using WID topology
1 - 100 RP TRUSTS MORE THAN 100 RP TRUSTS

Required
Required Required

To deploy this topology, in addition to adding two web application proxies, you must make sure that your perimeter
network can also provide access to a Domain Name System (DNS ) server and to a second Network Load
Balancing (NLB ) host. The second NLB host must be configured with an NLB cluster that uses an Internet-
accessible cluster IP address, and it must use the same cluster DNS name setting as the previous NLB cluster that
you configured on the corporate network (fs.fabrikam.com). The web application proxies should also be configured
with Internet-accessible IP addresses.
The following illustration shows the existing federation server farm with WID topology that was described
previously and how the fictional Fabrikam, Inc., company provides access to a perimeter DNS server, adds a second
NLB host with the same cluster DNS name (fs.fabrikam.com), and adds two web application proxies (wap1 and
wap2) to the perimeter network.
For more information about how to configure your networking environment for use with federation servers or web
application proxies, see “Name Resolution Requirements” section in AD FS Requirements and Plan the Web
Application Proxy Infrastructure (WAP ).
See Also
This topology for Active Directory Federation Services (AD FS ) differs from the federation server farm using
Windows Internal Database (WID ) deployment topology in that it does not replicate the data to each federation
server in the farm. Instead, all federation servers in the farm can read and write data into a common database that
is stored on a server running Microsoft SQL Server that is located in the corporate network.
IMPORTANT
If you want to create an AD FS farm and use SQL Server to store your configuration data, you can use SQL Server 2008 and
newer versions, including SQL Server 2012, and SQL Server 2014.
Large organizations with more than 100 trust relationships that need to provide both their internal users and
external users with single sign-on (SSO ) access to federated application or services
Organizations that already use SQL Server and want to take advantage of their existing tools and expertise
Support for larger numbers of trust relationships (more than 100)
Support for token replay detection (a security feature) and artifact resolution (part of the Security Assertion
Markup Language (SAML ) 2.0 protocol)
Support for the full benefits of SQL Server, such as database mirroring, failover clustering, reporting, and
management tools
This topology does not provide database redundancy by default. Although a federation server farm with WID
topology automatically replicates the WID database on each federation server in the farm, the federation server
farm with SQL Server topology contains only one copy of the database
NOTE
SQL Server supports many different data and application redundancy options including failover clustering, database mirroring,
and several different types of SQL Server replication.
The Microsoft Information Technology (IT) department uses SQL Server database mirroring in high-safety
(synchronous) mode and failover clustering to provide high-availability support for the SQL Server instance. SQL
Server transactional (peer-to-peer) and merge replication have not been tested by the AD FS product team at
Microsoft. For more information about SQL Server, see High Availability Solutions Overview or Selecting the
Appropriate Type of Replication.
Supported SQL Server Versions
The following SQL server versions are supported with AD FS in Windows Server 2012 R2:
SQL Server 2008 / R2
SQL Server 2012
SQL Server 2014

Similar to the federation server farm with WID topology, all of the federation servers in the farm are configured to
use one cluster Domain Name System (DNS ) name (which represents the Federation Service name) and one
cluster IP address as part of the Network Load Balancing (NLB ) cluster configuration. This helps the NLB host
allocate client requests to the individual federation servers. Federation server proxies can be used to proxy client
requests to the federation server farm.
The following illustration shows how the fictional Contoso Pharmaceuticals company deployed its federation
server farm with SQL Server topology in the corporate network. It also shows how that company configured the
perimeter network with access to a DNS server, an additional NLB host that uses the same cluster DNS name
(fs.contoso.com) that is used on the corporate network NLB cluster, and with two web application proxies (wap1
and wap2).
For more information about how to configure your networking environment for use with federation servers or web
application proxies, see “Name Resolution Requirements” section in AD FS Requirements and Plan the Web
Application Proxy Infrastructure (WAP ).
High Availability Options for SQL Server Farms

In Windows Server 2012 R2, AD FS there are two new options to support high availability in AD FS farms using
SQL Server.
Support for SQL Server AlwaysOn Availability Groups
Support for geographically distributed high availability using SQL Server merge replication
This section describes each of these options, what problems they respectively solve, and some key considerations
for deciding which options to deploy.
NOTE
AD FS farms that use Windows Internal Database (WID) provide basic data redundancy with read/write access on the primary
federation server node and read-only access on secondary nodes. This can be used in a geographically local or a
geographically distributed topology.
When using WID be aware of the following limitations:
A WID farm does not support token replay detection or artifact resolution (part of the Security Assertion Markup
Language (SAML) protocol).
The following table provides a summary for using a WID farm.
1 - 100 RP Trusts More than 100 RP Trusts

Required
Required Required
AlwaysOn Availability Groups

Overview
AlwaysOn Availability groups were introduced in SQL Server 2012 and provide a new way to create a high
availability SQL Server instance. AlwaysOn Availability groups combine elements of clustering and database
mirroring for redundancy and failover at both the SQL instance layer and the database layer. Unlike previous high
availability options, AlwaysOn Availability groups do not require a common storage (or storage area network) at
the database layer.
An availability group is comprised of a primary replica (a set of read-write primary databases) and one to four
availability replicas (sets of corresponding secondary databases). The availability group supports a single read-
write copy (the primary replica), and one to four read-only availability replicas. Each availability replica must reside
on a different node of a single Windows Server Failover Clustering (WSFC ) cluster. For more information on
AlwaysOn Availability groups see Overview of AlwaysOn Availability Groups (SQL Server).
From the perspective of the nodes of an AD FS SQL Server farm, the AlwaysOn Availability group replaces the
single SQL Server instance as the policy / artifact database. The availability group listener is what the client (the AD
FS security token service) uses to connect to SQL.
The following diagram shows an AD FS SQL Server Farm with AlwaysOn Availability group.
NOTE
AlwaysOn Availability groups require that the SQL Server instances reside on Windows Server Failover Clustering (WSFC)
nodes.
NOTE
Only one availability replica can act as an automatic failover target, the other three will rely on manual failovers.
Key Deployment Considerations

If you plan to use AlwaysOn Availability groups in combination with SQL Server merge replication, please take
note of the issues described under “Key Deployment Considerations for using AD FS with SQL Server Merge
Replication” below. In particular, when an AlwaysOn availability group containing a database that is a replication
subscriber fails over, the replication subscription fails. To resume replication, a replication administrator must
manually reconfigure the subscriber. See the SQL Server description of specific issue at Replication Subscribers
and AlwaysOn Availability Groups (SQL Server) and overall support statements for AlwaysOn Availability groups
with replication options at Replication, Change Tracking, Change Data Capture, and AlwaysOn Availability Groups
(SQL Server).
Configuring AD FS to use an AlwaysOn Availability group
Configuring an AD FS farm with AlwaysOn Availability groups requires a slight modification to the AD FS
deployment procedure:
1. The databases you wish to back up must be created before the AlwaysOn Availability groups can be
configured. AD FS creates its databases as part of the setup and initial configuration of the first federation
service node of a new AD FS SQL Server farm. As part of the AD FS configuration, you must specify an
SQL connection string, so you will have to configure the first AD FS farm node to connect to a SQL instance
directly (this is only temporary). For specific guidance on configuring an AD FS farm, including configuring
an AD FS farm node with a SQL server connection string, see Configure a Federation Server.
2. Once the AD FS databases have been created, assign them to AlwaysOn Availability groups and create the
common TCPIP listener using SQL Server tools and process at Creation and Configuration of Availability
Groups (SQL Server).
3. Finally, use PowerShell to edit the AD FS properties to update the SQL connection string to use the DNS
address of the AlwaysOn Availability group’s listener.
Example PSH commands to update the SQL connection string for the AD FS configuration database:
PS:\>$temp= Get-WmiObject -namespace root/ADFS -class SecurityTokenService

PS:\>$temp.ConfigurationdatabaseConnectionstring=”data source=<SQLCluster\SQLInstance>; initial
catalog=adfsconfiguration;integrated security=true”
PS:\>$temp.put()
4. Example PSH commands to update the SQL connection string for the AD FS artifact resolution service
database:
PS:\> Set-AdfsProperties –artifactdbconnection ”Data source=<SQLCluster\SQLInstance >;Initial

Catalog=AdfsArtifactStore;Integrated Security=True”
SQL Server Merge Replication

Also introduced in SQL Server 2012, merge replication allows for AD FS policy data redundancy with the following
characteristics:
Read and write capability on all nodes (not just the primary)
Smaller amounts of data replicated asynchronously to avoid introducing latency to the system
The following diagram shows a geographically redundant AD FS SQL Server farms with merge replication (1
publisher, 2 subscribers):
Key Deployment Considerations for using AD FS with SQL Server Merge Replication (note numbers in
the diagram above)
The distributor database is not supported for use with AlwaysOn Availability Groups or database mirroring.
See SQL Server support statements for AlwaysOn Availability groups with replication options at Replication,
Change Tracking, Change Data Capture, and AlwaysOn Availability Groups (SQL Server).
When an AlwaysOn availability group containing a database that is a replication subscriber fails over, the
replication subscription fails. To resume replication, a replication administrator must manually reconfigure
the subscriber. See the SQL Server description of specific issue at Replication Subscribers and AlwaysOn
Availability Groups (SQL Server) and overall support statements for AlwaysOn Availability groups with
replication options Replication, Change Tracking, Change Data Capture, and AlwaysOn Availability Groups
(SQL Server).
For more detailed instructions on how to configure AD FS to use a SQL Server merge replication, see Setup
Geographic Redundancy with SQL Server Replication.
See Also
AD FS Requirements
Applies To: Windows Server 2012 R2
The following are the various requirements that you must conform to when deploying AD FS:
Software requirements
AD DS requirements
Extranet requirements
Attribute store requirements
Application requirements
Authentication requirements
Workplace join requirements
Cryptography requirements
Certificates play the most critical role in securing communications between federation servers, Web Application
Proxies, claims-aware applications, and Web clients. The requirements for certificates vary, depending on whether
you are setting up a federation server or a proxy computer, as described in this section.
Federation server certificates
Certificate type Requirements, Support & Things to Know

Secure Sockets Layer (SSL) certificate: This is a standard - This certificate must be a publicly trusted* X509 v3
SSL certificate that is used for securing communications certificate.
between federation servers and clients. - All clients that access any AD FS endpoint must trust this
certificate. It is strongly recommended to use certificates that
are issued by a public (third-party) certification authority (CA).
You can use a self-signed SSL certificate successfully on
federation servers in a test lab environment. However, for a
production environment, we recommend that you obtain the
certificate from a public CA.
- Supports any key size supported by Windows Server 2012
R2 for SSL certificates.
- Does not support certificates that use CNG keys.
- When used together with Workplace Join/Device Registration
Service, the subject alternative name of the SSL certificate for
the AD FS service must contain the value
enterpriseregistration that is followed by the User Principal
Name (UPN) suffix of your organization, for example,
enterpriseregistration.contoso.com.
- Wild card certificates are supported. When you create your
AD FS farm, you will be prompted to provide the service name
for the AD FS service (for example, adfs.contoso.com.
- It is strongly recommended to use the same SSL certificate
for the Web Application Proxy. This is however required to be
the same when supporting Windows Integrated
Authentication endpoints through the Web Application Proxy
and when Extended Protection Authentication is turned on
(default setting).
- The Subject name of this certificate is used to represent the
Federation Service name for each instance of AD FS that you
deploy. For this reason, you may want to consider choosing a
Subject name on any new CA-issued certificates that best
represents the name of your company or organization to
partners.
The identity of the certificate must match the federation
service name (for example, fs.contoso.com).The identity is
either a subject alternative name extension of type dNSName
or, if there are no subject alternative name entries, the subject
name specified as a common name. Multiple subject
alternative name entries can be present in the certificate,
provided one of them matches the federation service name.
- Important: it’s strongly recommended to use the same SSL
certificate across all nodes of your AD FS farm as well as all
Web Application proxies in your AD FS farm.
Service communication certificate: This certificate enables - By default, the SSL certificate is used as the service
WCF message security for securing communications between communications certificate. But you also have the option to
federation servers. configure another certificate as the service communication
certificate.
- Important: if you are using the SSL certificate as the service
communication certificate, when the SSL certificate expires,
make sure to configure the renewed SSL certificate as your
service communication certificate. This does not happen
automatically.
- This certificate must be trusted by clients of AD FS that use
WCF Message Security.
- We recommend that you use a server authentication
certificate that is issued by a public (third-party) certification
authority (CA).
- The service communication certificate cannot be a certificate
that uses CNG keys.
- This certificate can be managed using the AD FS
Management console.
Token-signing certificate: This is a standard X509 certificate - By default, AD FS creates a self-signed certificate with 2048
that is used for securely signing all tokens that the federation bit keys.
server issues. - CA issued certificates are also supported and can be
changed using the AD FS Management snap-in
- CA issued certificates must be stored & accessed through a
CSP Crypto Provider.
- The token signing certificate cannot be a certificate that uses
CNG keys.
- AD FS does not require externally enrolled certificates for
token signing.
AD FS automatically renews these self-signed certificates
before they expire, first configuring the new certificates as
secondary certificates to allow for partners to consume them,
then flipping to primary in a process called automatic
certificate rollover.We recommend that you use the default,
automatically generated certificates for token signing.
If your organization has policies that require different
certificates to be configured for token signing, you can specify
the certificates at installation time using Powershell (use the –
SigningCertificateThumbprint parameter of the Install-
AdfsFarm cmdlet). After installation, you can view and manage
token signing certificates using the AD FS Management
console or Powershell cmdlets Set-AdfsCertificate and Get-
AdfsCertificate.
When externally enrolled certificates are used for token
signing, AD FS does not perform automatic certificate renewal
or rollover. This process must be performed by an
administrator.
To allow for certificate rollover when one certificate is close to
expiring, a secondary token signing certificate can be
configured in AD FS. By default, all token signing certificates
are published in federation metadata, but only the primary
token-signing certificate is used by AD FS to actually sign
tokens.
Token-decryption/encryption certificate: This is a standard - By default, AD FS creates a self-signed certificate with 2048
X509 certificate that is used to decrypt/encrypt any incoming bit keys.
tokens. It is also published in federation metadata. - CA issued certificates are also supported and can be
changed using the AD FS Management snap-in
- CA issued certificates must be stored & accessed through a
CSP Crypto Provider.
- The token-decryption/encryption certificate cannot be a
certificate that uses CNG keys.
- By default, AD FS generates and uses its own, internally
generated and self-signed certificates for token decryption. AD
FS does not require externally enrolled certificates for this
purpose.
In addition, AD FS automatically renews these self-signed
certificates before they expire.
We recommend that you use the default, automatically
generated certificates for token decryption.
If your organization has policies that require different
certificates to be configured for token decryption, you can
specify the certificates at installation time using Powershell
(use the –DecryptionCertificateThumbprint parameter of the
Install-AdfsFarm cmdlet). After installation, you can view and
manage token decryption certificates using the AD FS
Management console or Powershell cmdlets Set-
AdfsCertificate and Get-AdfsCertificate.
When externally enrolled certificates are used for token
decryption, AD FS does not perform automatic
certificate renewal. This process must be performed by
an administrator.
- The AD FS service account must have access to the token-
signing certificate’s private key in the personal store of the
local computer. This is taken care of by Setup. You can also use
the AD FS Management snap-in to ensure this access if you
subsequently change the token-signing certificate.
Cau t i on
Certificates that are used for token-signing and token-decrypting/encrypting are critical to the stability of the
Federation Service. Customers managing their own token-signing & token-decrypting/encrypting certificates
should ensure that these certificates are backed up and are available independently during a recovery event.
NOTE
In AD FS you can change the Secure Hash Algorithm (SHA) level that is used for digital signatures to either SHA-1 or SHA-
256 (more secure). AD FS does not support the use of certificates with other hash methods, such as MD5 (the default hash
algorithm that is used with the Makecert.exe command-line tool). As a security best practice, we recommend that you use
SHA-256 (which is set by default) for all signatures. SHA-1 is recommended for use only in scenarios in which you must
interoperate with a product that does not support communications using SHA-256, such as a non-Microsoft product or
legacy versions of AD FS.
NOTE
After you receive a certificate from a CA, make sure that all certificates are imported into the personal certificate store of the
local computer. You can import certificates to the personal store with the Certificates MMC snap-in.
The following minimum and recommended hardware requirements apply to the AD FS federation servers in
Windows Server 2012 R2:
Hardware requirement Minimum requirement Recommended requirement
CPU speed 1.4 GHz 64-bit processor Quad-core, 2 GHz
RAM 512 MB 4 GB
Disk space 32 GB 100 GB
The following AD FS requirements are for the server functionality that is built into the Windows Server® 2012 R2
operating system:
For extranet access, you must deploy the Web Application Proxy role service - part of the Windows Server®
2012 R2 Remote Access server role. Prior versions of a federation server proxy are not supported with AD
FS in Windows Server® 2012 R2.
A federation server and the Web Application Proxy role service cannot be installed on the same computer.
AD DS requirements
Domain controller requirements
Domain controllers in all user domains and the domain to which the AD FS servers are joined must be running
Windows Server 2008 or later.
NOTE
All support for environments with Windows Server 2003 domain controllers will end after the Extended Support End Date for
Windows Server 2003. Customers are strongly recommended to upgrade their domain controllers as soon as possible. Visit
this page for additional information on Microsoft Support Lifecycle. For issues discovered that are specific to Windows Server
2003 domain controller environments, fixes will be issued only for security issues and if a fix can be issued prior to the expiry
of Extended Support for Windows Server 2003.
Domain functional-level requirements

All user account domains and the domain to which the AD FS servers are joined must be operating at the domain
functional level of Windows Server 2003 or higher.
Most AD FS features do not require AD DS functional-level modifications to operate successfully. However,
Windows Server 2008 domain functional level or higher is required for client certificate authentication to operate
successfully if the certificate is explicitly mapped to a user's account in AD DS.
Schema requirements
AD FS does not require schema changes or functional-level modifications to AD DS.
To use Workplace Join functionality, the schema of the forest that AD FS servers are joined to must be set to
Any standard service account can be used as a service account for AD FS. Group Managed Service accounts
are also supported. This requires at least one domain controller (it is recommended that you deploy two or
more) that is running Windows Server 2012 or higher.
For Kerberos authentication to function between domain-joined clients and AD FS, the
‘HOST/<adfs_service_name>’ must be registered as a SPN on the service account. By default, AD FS will
configure this when creating a new AD FS farm if it has sufficient permissions to perform this operation.
The AD FS service account must be trusted in every user domain that contains users authenticating to the
AD FS service.
Domain Requirements
All AD FS servers must be a joined to an AD DS domain.
All AD FS servers within a farm must be deployed in a single domain.
The domain that the AD FS servers are joined to must trust every user account domain that contains users
authenticating to the AD FS service.
Multi Forest Requirements
The domain that the AD FS servers are joined to must trust every user account domain or forest that
contains users authenticating to the AD FS service.
The AD FS service account must be trusted in every user domain that contains users authenticating to the
AD FS service.

The following are the requirements and restrictions that apply based on the type of configuration store:
WID
Artifact resolution profile in SAML 2.0 is not supported in the WID configuration database. Token Replay
Detection is not supported in the WID configuration database. This functionality is only used only in
scenarios where AD FS is acting as the federation provider and consuming security tokens from external
claims providers.
Deploying AD FS servers in distinct data centers for failover or geographic load balancing is supported as
long as the number of servers does not exceed 30.
The following table provides a summary for using a WID farm. Use it to plan your implementation.
1 - 100 RP Trusts More than 100 RP Trusts

Required
Required Required
SQL Server
For AD FS in Windows Server 2012 R2, you can use SQL Server 2008 and higher
When AD FS authentication is performed via a browser or browser control, your browser must comply to the
following requirements:
JavaScript must be enabled
Cookies must be turned on
Server Name Indication (SNI) must be supported
For user certificate & device certificate authentication (workplace join functionality), the browser must
support SSL client certificate authentication
Several key browsers and platforms have undergone validation for rendering and functionality the details of which
are listed below. Browsers and devices that not covered in this table are still supported if they meet the
requirements listed above:
Browsers Platforms
IE 10.0 Windows 7, Windows 8.1, Windows Server 2008 R2, Windows

Server 2012, Windows Server 2012 R2
IE 11.0 Windows7, Windows 8.1, Windows Server 2008 R2, Windows

Server 2012, Windows Server 2012 R2
Windows Web Authentication Broker Windows 8.1
Firefox [v21] Windows 7, Windows 8.1
Safari [v7] iOS 6, Mac OS-X 10.7
Chrome [v27] Windows 7, Windows 8.1, Windows Server 2012, Windows

Server 2012 R2, Mac OS-X 10.7
IMPORTANT
Known issue - Firefox: Workplace Join functionality that identifies the device using device certificate is not functional on
Windows platforms. Firefox does not currently support performing SSL client certificate authentication using certificates
provisioned to the user certificate store on Windows clients.
Cookies
AD FS creates session-based and persistent cookies that must be stored on client computers to provide sign-in,
sign-out, single sign-on (SSO ), and other functionality. Therefore, the client browser must be configured to accept
cookies. Cookies that are used for authentication are always Secure Hypertext Transfer Protocol (HTTPS ) session
cookies that are written for the originating server. If the client browser is not configured to allow these cookies, AD
FS cannot function correctly. Persistent cookies are used to preserve user selection of the claims provider. You can
disable them by using a configuration setting in the configuration file for the AD FS sign-in pages. Support for
TLS/SSL is required for security reasons.
Extranet requirements
To provide extranet access to the AD FS service, you must deploy the Web Application Proxy role service as the
extranet facing role that proxies authentication requests in a secure manner to the AD FS service. This provides
isolation of the AD FS service endpoints as well as isolation of all security keys (such as token signing certificates)
from requests that originate from the internet. In addition, features such as Soft Extranet Account Lockout require
the use of the Web Application Proxy. For more information about Web Application Proxy, see Web Application
Proxy.
If you want to use a third-party proxy for extranet access, this third-party proxy must support the protocol defined
in http://download.microsoft.com/download/9/5/E/95EF66AF -9026-4BB0-A41D -A4F81802D92C/%5bMS -
ADFSPIP%5d.pdf.
Configuring the following network services appropriately is critical for successful deployment of AD FS in your
organization:
Configuring Corporate Firewall
Both the firewall located between the Web Application Proxy and the federation server farm and the firewall
between the clients and the Web Application Proxy must have TCP port 443 enabled inbound.
In addition, if client user certificate authentication (clientTLS authentication using X509 user certificates) is required,
AD FS in Windows Server 2012 R2 requires that TCP port 49443 be enabled inbound on the firewall between the
clients and the Web Application Proxy. This is not required on the firewall between the Web Application Proxy and
the federation servers).
Configuring DNS
For intranet access, all clients accessing AD FS service within the internal corporate network (intranet) must
be able to resolve the AD FS service name (name provided by the SSL certificate) to the load balancer for
the AD FS servers or the AD FS server.
For extranet access, all clients accessing AD FS service from outside the corporate network
(extranet/internet) must be able to resolve the AD FS service name (name provided by the SSL certificate) to
the load balancer for the Web Application Proxy servers or the Web Application Proxy server.
For extranet access to function properly, each Web Application Proxy server in the DMZ must be able to
resolve AD FS service name (name provided by the SSL certificate) to the load balancer for the AD FS
servers or the AD FS server. This can be achieved using an alternate DNS server in the DMZ network or by
changing local server resolution using HOSTS file.
For Windows Integrated authentication to work inside the network and outside the network for a subset of
endpoints exposed through the Web Application Proxy, you must use an A record (not CNAME ) to point to
the load balancers.
For information on configuring corporate DNS for the federation service and Device Registration Service, see
Configure Corporate DNS for the Federation Service and DRS.
For information on configuring corporate DNS for Web Application proxies, see the “Configure DNS” section in
Step 1: Configure the Web Application Proxy Infrastructure.
For information about how to configure a cluster IP address or cluster FQDN using NLB, see Specifying the
Cluster Parameters at http://go.microsoft.com/fwlink/?LinkId=75282.

AD FS requires at least one attribute store to be used for authenticating users and extracting security claims for
those users. For a list of attribute stores that AD FS supports, see The Role of Attribute Stores.
NOTE
AD FS automatically creates an “Active Directory” attribute store, by default. Attribute store requirements depend on whether
your organization is acting as the account partner (hosting the federated users) or the resource partner (hosting the
federated application).
LDAP Attribute Stores

When you work with other Lightweight Directory Access Protocol (LDAP )-based attribute stores, you must connect
to an LDAP server that supports Windows Integrated authentication. The LDAP connection string must also be
written in the format of an LDAP URL, as described in RFC 2255.
It is also required that the service account for the AD FS service has the right to retrieve user information in the
LDAP attribute store.
SQL Server Attribute Stores
For AD FS in Windows Server 2012 R2 to operate successfully, computers that host the SQL Server attribute store
must be running either Microsoft SQL Server 2008 or higher. When you work with SQL -based attribute stores, you
also must configure a connection string.
Custom Attribute Stores
You can develop custom attribute stores to enable advanced scenarios.
The policy language that is built into AD FS can reference custom attribute stores so that any of the
following scenarios can be enhanced:
Creating claims for a locally authenticated user
Supplementing claims for an externally authenticated user
Authorizing a user to obtain a token
Authorizing a service to obtain a token on behavior of a user
Issuing additional data in security tokens issued by AD FS to relying parties.
All custom attribute stores must be built on top of .NET 4.0 or higher.
When you work with a custom attribute store, you might also have to configure a connection string. In that case,
you can enter a custom code of your choice that enables a connection to your custom attribute store. The
connection string in this situation is a set of name/value pairs that are interpreted as implemented by the developer
of the custom attribute store.For more information about developing and using custom attribute stores, see
Attribute Store Overview.
AD FS supports claims-aware applications that use the following protocols:
WS -Federation
WS -Trust
SAML 2.0 protocol using IDPLite, SPLite & eGov1.5 profiles.
OAuth 2.0 Authorization Grant Profile
AD FS also supports authentication and authorization for any non-claims-aware applications that are supported by
the Web Application Proxy.
AD DS Authentication (Primary Authentication)
For intranet access, the following standard authentication mechanisms for AD DS are supported:
Windows Integrated Authentication using Negotiate for Kerberos & NTLM
Forms Authentication using username/passwords
Certificate Authentication using certificates mapped to user accounts in AD DS
For extranet access, the following authentication mechanisms are supported:
Forms Authentication using username/passwords
Certificate Authentication using certificates that are mapped to user accounts in AD DS
Windows Integrated Authentication using Negotiate (NTLM only) for WS -Trust endpoints that accept
For Certificate Authentication:
Extends to smartcards that can be pin protected.
The GUI for the user to enter their pin is not provided by AD FS and is required to be part of the client
operating system that is displayed when using client TLS.
The reader and cryptographic service provider (CSP ) for the smart card must work on the computer where
the browser is located.
The smart card certificate must chain up to a trusted root on all the AD FS servers and Web Application
Proxy servers.
The certificate must map to the user account in AD DS by either of the following methods:
The certificate subject name corresponds to the LDAP distinguished name of a user account in AD
DS.
The certificate subject altname extension has the user principal name (UPN ) of a user account in AD
DS.
For seamless Windows Integrated Authentication using Kerberos in the intranet,
It is required for the service name to be part of the Trusted Sites or the Local Intranet sites.
In addition, the HOST/<adfs_service_name> SPN must be set on the service account that the AD FS farm
runs on.
Multi-Factor Authentication
AD FS supports additional authentication (beyond primary authentication supported by AD DS ) using a provider
model whereby vendors/customers can build their own multi-factor authentication adapter that an administrator
can register and use during login.
Every MFA adapter must be built on top of .NET 4.5.
For more information on MFA, see Manage Risk with Additional Multi-Factor Authentication for Sensitive
Applications.
Device Authentication
AD FS supports device authentication using certificates provisioned by the Device Registration Service during the
act of an end user workplace joining their device.
Workplace join requirements

End users can workplace join their devices to an organization using AD FS. This is supported by the Device
Registration Service in AD FS. As a result, end users get the additional benefit of SSO across the applications
supported by AD FS. In addition, administrators can manage risk by restricting access to applications only to
devices that have been workplace joined to the organization. Below are the following requirements to enable this
scenario.
AD FS supports workplace join for Windows 8.1 and iOS 5+ devices
To use Workplace Join functionality, the schema of the forest that AD FS servers are joined to must be
The subject alternative name of the SSL certificate for AD FS service must contain the value
enterpriseregistration that is followed by the User Principal Name (UPN ) suffix of your organization, for
example, enterpriseregistration.corp.contoso.com.
Cryptography requirements
The following table provides additional cryptography support information on the AD FS token signing, token
encryption/decryption functionality:
Algorithm Key lengths Protocols/Applications/Comments
TripleDES – Default 192 (Supported 192 >= 192 Supported algorithm for Decrypting the
– 256) - security token. Encrypting the security
http://www.w3.org/2001/04/xmlenc#tri token with this algorithm is not
pledes-cbc supported.
AES128 - 128 Supported algorithm for Decrypting the

http://www.w3.org/2001/04/xmlenc#aes security token. Encrypting the security
128-cbc token with this algorithm is not
supported.
AES192 - 192 Supported algorithm for Decrypting the

http://www.w3.org/2001/04/xmlenc#aes security token. Encrypting the security
192-cbc token with this algorithm is not
supported.
AES256 - 256 Default. Supported algorithm for

http://www.w3.org/2001/04/xmlenc#aes Encrypting the security token.
256-cbc
TripleDESKeyWrap - All Key sizes supported by .NET 4.0+ Supported algorithm for Encrypting the
http://www.w3.org/2001/04/xmlenc#kw symmetric key that encrypts a security
-tripledes token.
AES128KeyWrap - 128 Supported algorithm for Encrypting the

http://www.w3.org/2001/04/xmlenc#kw symmetric key that encrypts the
-aes128 security token.

RsaV15KeyWrap - 1024 Supported algorithm for Encrypting the

http://www.w3.org/2001/04/xmlenc#rsa symmetric key that encrypts the
-1_5 security token.
RsaOaepKeyWrap - 1024 Default. Supported algorithm for

http://www.w3.org/2001/04/xmlenc#rsa Encrypting the symmetric key that
-oaep-mgf1p encrypts the security token.
SHA1- N/A Used by AD FS Server in artifact

http://www.w3.org/PICS/DSig/SHA1_1_ SourceId generation: In this scenario,
0.html the STS uses SHA1 (per the
recommendation in the SAML 2.0
standard) to create a short 160 bit
value for the artifact sourceiD.
Also used by the ADFS web agent

(legacy component from WS2003
timeframe) to identify changes in a “last
updated” time value so that it knows
when to update information from the
STS.
SHA1withRSA- N/A Used in cases when AD FS Server

validates the signature of SAML
http://www.w3.org/PICS/DSig/RSA- AuthenticationRequest, sign the artifact
SHA1_1_0.html resolution request or response, create
token-signing certificate.
In these cases, SHA256 is the default,

and SHA1 is only used if the partner
(relying party) cannot support SHA256
and must use SHA1.
The administrator that performs the installation and the initial configuration of AD FS must have domain
administrator permissions in the local domain (in other words, the domain to which the federation server is joined
to.)
See Also
NOTE
For information about how to deploy AD FS in Windows Server 2012 R2 , see Windows Server 2012 R2 AD FS Deployment
Guide.
You can use Active Directory® Federation Services (AD FS ) with the Windows Server® 2012 operating system in
a federation services provider role to seamlessly authenticate your users to any Web-based services or applications
that reside in a resource partner organization, without the need for administrators to create or maintain external
trusts or forest trusts between the networks of both organizations and without the need for the users to log on a
second time. The process of authenticating to one network while accessing resources in another network—without
the burden of repeated logon actions by users—is known as single sign-on (SSO ).
About this guide

This guide provides recommendations to help you plan a new deployment of AD FS, based on the requirements of
your organization (also referred to in this guide as deployment goals) and the particular design that you want to
create. This guide is intended for use by an infrastructure specialist or system architect. It highlights your main
decision points as you plan your AD FS deployment. Before you read this guide, you should have a good
understanding of how AD FS works on a functional level. You should also have a good understanding of the
organizational requirements that will be reflected in your AD FS design.
This guide describes a set of deployment goals that are based on three primary AD FS designs, and it helps you
decide the most appropriate design for your environment. You can use these deployment goals to form one of the
following comprehensive AD FS designs or a custom design that meets the needs of your environment:
Federated Web SSO to support business-to-business (B2B ) scenarios and to support collaboration between
business units with independent forests
Web SSO to support customer access to applications in business-to-consumer (B2C ) scenarios
For each design, you will find guidelines for gathering the required data about your environment. You can then use
these guidelines to plan and design your AD FS deployment. After you read this guide and finish gathering,
documenting, and mapping your organization's requirements, you will have the information necessary to begin
deploying AD FS using the guidance in the Windows Server 2012 AD FS Deployment Guide.
In this guide
Correctly identifying your Active Directory Federation Services (AD FS ) deployment goals is essential for the
success of your AD FS design project. Depending on the size of your organization and the level of involvement that
you want to provide for the information technology (IT) staff in any partner organizations, form a project team that
can clearly articulate real-world deployment issues in a vision statement. Make sure that the members of this team
understand the direction in which your deployment project must move in order to reach your AD FS deployment
goals.
When you write your vision statement, identify, clarify, and refine your deployment goals. Prioritize and, possibly,
combine your deployment goals so that you can design and deploy AD FS by using an iterative approach. You can
take advantage of existing, documented, and predefined AD FS deployment goals that are relevant to the AD FS
designs and develop a working solution for your situation.
The following table lists the tasks for articulating, refining, and documenting your AD FS deployment goals.
TASK REFERENCE LINKS
Evaluate predefined AD FS deployment goals that are provided - Provide Your Active Directory Users Access to Your Claims-
in this section of the guide, and combine one or more goals to Aware Applications and Services
reach your organizational objectives - Provide Your Active Directory Users Access to the
Applications and Services of Other Organizations
- Provide Users in Another Organization Access to Your
Claims-Aware Applications and Services
Map one goal or a combination of any of the predefined AD - Mapping Your Deployment Goals to an AD FS Design
FS deployment goals to an existing AD FS design
See Also
Provide Your Active Directory Users Access to Your
When you are an administrator in the account partner organization in an Active Directory Federation Services (AD
FS ) deployment and you have a deployment goal to provide single-sign-on (SSO ) access for employees on the
corporate network to your hosted resources:
Employees who are logged on to an Active Directory forest in the corporate network can use SSO to access
multiple applications or services in the perimeter network in your own organization. These applications and
services are secured by AD FS.
For example, Fabrikam may want corporate network employees to have federated access to Web-based
applications that are hosted in the perimeter network for Fabrikam.
Remote employees who are logged on to an Active Directory domain can obtain AD FS tokens from the
federation server in your organization to gain federated access to AD FS -secured Web-based applications or
services that also reside in your organization.
Information in the Active Directory attribute store can be populated into the employees' AD FS tokens.
The following components are required for this deployment goal:
Active Directory Domain Services (AD DS ): AD DS contains the employees' user accounts that are used
to generate AD FS tokens. Information, such as group memberships and attributes, is populated into AD FS
tokens as group claims and custom claims.
NOTE
You can also use Lightweight Directory Access Protocol (LDAP) or Structured Query Language (SQL) to contain the
identities for AD FS token generation.
Corporate DNS: This implementation of Domain Name System (DNS ) contains a simple host (A) resource
record so that intranet clients can locate the account federation server. This implementation of DNS may
also host other DNS records that are required in the corporate network. For more information, see Name
Resolution Requirements for Federation Servers.
Account partner federation server: This federation server is joined to a domain in the account partner
forest. It authenticates employee user accounts and generates AD FS tokens. The client computer for the
employee performs Windows Integrated Authentication against this federation server to generate an AD FS
token. For more information, see Review the Role of the Federation Server in the Account Partner.
The account partner federation server can authenticate the following users:
Employees with user accounts in this domain
Employees with user accounts anywhere in this forest
Employees with user accounts anywhere in forests that are trusted by this forest (through a two-way
Windows trust)
Employee: An employee accesses a Web-based service (through an application) or a Web-based
application (through a supported Web browser) while he or she is logged on to the corporate network. The
employee's client computer on the corporate network communicates directly with the federation server for
authentication.
After reviewing the information in the linked topics, you can begin deploying this goal by following the steps in
Checklist: Implementing a Federated Web SSO Design.
The following illustration shows each of the required components for this AD FS deployment goal.
See Also
Provide Your Active Directory Users Access to the
Applications and Services of Other Organizations
This Active Directory Federation Services (AD FS ) deployment goal builds on the goal in Provide Your Active
Directory Users Access to Your Claims-Aware Applications and Services.
When you are an administrator in the account partner organization and you have a deployment goal to provide
federated access for employees to hosted resources in another organization:
Employees who are logged on to an Active Directory domain in the corporate network can use single-sign-
on (SSO ) functionality to access multiple Web-based applications or services, which are secured by AD FS,
when the applications or services are in a different organization. For more information, see Federated Web
SSO Design.
For example, Fabrikam may want corporate network employees to have federated access to Web services
that are hosted in Contoso.
Remote employees who are logged on to an Active Directory domain can obtain AD FS tokens from the
federation server in your organization to gain federated access to AD FS –secured Web-based applications or
services that are hosted in another organization.
For example, Fabrikam may want its remote employees to have federated access to AD FS –secured services
that are hosted in Contoso, without requiring the Fabrikam employees to be on the Fabrikam corporate
network.
In addition to the foundational components that are described in Provide Your Active Directory Users Access to
Your Claims-Aware Applications and Services and that are shaded in the following illustration, the following
components are required for this deployment goal:
Account partner federation server proxy: Employees that access the federated service or application
from the Internet can use this AD FS component to perform authentication. By default, this component
performs forms authentication, but it can also perform basic authentication. You can also configure this
component to perform Secure Sockets Layer (SSL ) client authentication if employees at your organization
have certificates to present. For more information, see Where to Place a Federation Server Proxy.
Perimeter DNS: This implementation of Domain Name System (DNS ) provides the host names for the
perimeter network. For more information about how to configure perimeter DNS for a federation server
proxy, see Name Resolution Requirements for Federation Server Proxies.
Remote employee: The remote employee accesses a Web-based application (through a supported Web
browser) or a Web-based service (through an application), using valid credentials from the corporate
network, while the employee is offsite using the Internet. The employee's client computer in the remote
location communicates directly with the federation server proxy to generate a token and authenticate to the
application or service.
Checklist: Implementing a Federated Web SSO Design.
See Also
Provide Users in Another Organization Access to Your
When you are an administrator in the resource partner organization in Active Directory Federation Services (AD
FS ) and you have a deployment goal to provide federated access for users in another organization (the account
partner organization) to a claims-aware application or a Web-based service that is located in your organization (the
resource partner organization):
Federated users both in your organization and in organizations who have configured a federation trust to
your organization (account partner organizations) can access the AD FS secured application or service that
is hosted by your organization. For more information, see Federated Web SSO Design.
For example, Fabrikam may want its corporate network employees to have federated access to Web services
that are hosted in Contoso.
Federated users who have no direct association with a trusted organization (such as individual customers),
who are logged on to an attribute store that is hosted in your perimeter network, can access multiple AD FS -
secured applications, which are also hosted in your perimeter network, by logging on one time from client
computers that are located on the Internet. In other words, when you host customer accounts to enable
access to applications or services in your perimeter network, customers that you host in an attribute store
can access one or more applications or services in the perimeter network simply by logging on once. For
more information, see Web SSO Design.
For example, Fabrikam may want its customers to have single-sign-on (SSO ) access to multiple applications
or services that are hosted in its perimeter network.
The following components are required for this deployment goal:
Active Directory Domain Services (AD DS ): The resource partner federation server must be joined to an
Active Directory domain.
Perimeter DNS: Domain Name System (DNS ) should contain a simple host (A) resource record so that
client computers can locate the resource partner federation server and the Web server. The DNS server may
host other DNS records that are also required in the perimeter network. For more information, see Name
Resource partner federation server: The resource partner federation server validates AD FS tokens that
the account partners send. Account partner discovery is performed through this federation server. For more
information, see Review the Role of the Federation Server in the Resource Partner.
Web server: The Web server can host either a Web application or a Web service. The Web server confirms
that it receives valid AD FS tokens from federated users before it allows access to the protected Web
application or Web service.
By using Windows Identity Foundation (WIF ), you can develop your Web application or service so that it
accepts federated user logon requests that are made with any standard logon method, such as user name
and password.
Checklist: Implementing a Federated Web SSO Design and Checklist: Implementing a Web SSO Design.
See Also
After you finish reviewing the existing Active Directory Federation Services (AD FS ) deployment goals and you
determine which goals are related to your deployment, you can map those goals to a specific AD FS design. For
more information about AD FS predefined deployment goals, see Identifying Your AD FS Deployment Goals.
Use the following table to determine which AD FS design maps to the appropriate combination of AD FS
deployment goals for your organization. This table refers only to the two primary AD FS designs, as described in
this guide. However, you can create a hybrid or custom AD FS design by using any combination of the AD FS
deployment goals to meet the needs of your organization.
AD FS DEPLOYMENT GOAL WEB SSO DESIGN FEDERATED WEB SSO DESIGN
Provide Your Active Directory Users No Yes, in the account partner

Access to Your Claims-Aware
Applications and Services
Provide Your Active Directory Users No Yes, optional in the account partner
Access to the Applications and Services
of Other Organizations
Provide Users in Another Organization Yes Yes

Access to Your Claims-Aware
Applications and Services
See Also
Web SSO Design
In the Web Single-Sign-On (SSO ) design in Active Directory Federation Services (AD FS ), users must authenticate
only once to access multiple AD FS -secured applications or services. In this design all users are external, and no
federation trust exists because there are no partner organizations. Typically, you deploy this design when you want
to provide individual consumer or customer access to one or more AD FS –secured services or applications over the
Internet, as shown in the following illustration.
With the Web SSO design, an organization that typically hosts an AD FS -secured application or service in a
perimeter network can maintain a separate store of customer accounts in the perimeter network, which makes it
easier to isolate customer accounts from employee accounts.
You can manage the local accounts for customers in the perimeter network by using either Active Directory
Domain Services (AD DS ), SQL Server, or a custom attribute store.
This design coincides with the deployment goal in Provide Your Active Directory Users Access to Your Claims-
Aware Applications and Services.
For a list of detailed tasks that you can use to plan and deploy your Web SSO design, see Checklist: Implementing a
Web SSO Design.
See Also
Federated Web SSO Design
The Federated Web Single-Sign-On (SSO ) design in Active Directory Federation Services (AD FS ) involves secure
communication that spans multiple firewalls, perimeter networks, and name-resolution servers—in addition to the
entire Internet routing infrastructure.
Typically, this design is used when two organizations agree to create a federation trust relationship to allow users in
one organization (the account partner organization) to access Web-based applications or services, which are
secured by AD FS, in the other organization (the resource partner organization).
In other words, a federation trust relationship is the embodiment of a business-level agreement or partnership
between two organizations. As shown in the following illustration, you can establish a federation trust relationship
between two businesses, which results in an end-to-end federation scenario.
The one-way arrow in the illustration signifies the direction of the federation trust, which—like the direction of
Windows trusts—always points to the account side of the forest. This means that authentication flows from the
account partner organization to the resource partner organization.
In this Federated Web SSO design, two federation servers (one in Fabrikam and the other in Contoso) route
authentication requests from user accounts in Fabrikam to Web-based applications or services in Contoso.
NOTE
For additional security, you can use federation server proxies to relay requests to federation servers that are not directly
accessible from the Internet.
In this example, Fabrikam is the identity, or account, provider. The Fabrikam portion of the Federated Web SSO
design uses the following AD FS deployment goal:
Provide Your Active Directory Users Access to the Applications and Services of Other Organizations
Contoso is the resource provider. The Contoso portion of the Federated Web SSO design achieves the following
AD FS deployment goals:
Provide Users in Another Organization Access to Your Claims-Aware Applications and Services
Provide Your Active Directory Users Access to Your Claims-Aware Applications and Services
For a list of detailed tasks that you can use to plan and deploy the Federated Web SSO design, see Checklist:
Implementing a Federated Web SSO Design.
See Also
The first step in planning a deployment of Active Directory Federation Services (AD FS ) is to determine the right
deployment topology to meet the single sign-on (SSO ) needs of your organization. The topics in this section
describe the various deployment topologies that you can use with AD FS. They also describe the benefits and
limitations associated with each deployment topology so that you can select the most appropriate topology for
your specific business needs.
Before you read this deployment topology topic, we recommend that you first complete the tasks in the order
shown in the following table.
RECOMMENDED TASK DESCRIPTION REFERENCE
Review how AD FS data is stored and Understand the purpose of and the The Role of the AD FS Configuration
replicated to other federation servers in replication methods that can be used Database
a federation server farm. for the underlying data that is stored in
the AD FS configuration database. This
topic introduces the concepts of the
configuration database and describes
the two database types: Windows
Internal Database (WID) and Microsoft
SQL Server.
Select the type of AD FS configuration Review the various benefits and AD FS Deployment Topology
database that you will deploy in your limitations that are associated with Considerations
organization. using either WID or SQL Server as the
AD FS configuration database, along
with the various application scenarios
that they support.
NOTE
To implement basic redundancy, load balancing, and the option to scale the Federation Service (if required), we recommend
that you deploy at least two federation servers per federation server farm for all production environments, regardless of the
type of database that you will use.
When you have reviewed the content in the previous table, proceed to the following topics in this section:
Stand-Alone Federation Server Using WID
After you finish selecting your AD FS deployment topology, we recommend that you review the topic Planning for
AD FS Server Capacity to determine the recommended number of servers that you will need to deploy to support
this topology.
See Also
AD FS Deployment Topology Considerations
This topic describes important considerations to help you plan and design which Active Directory Federation
Services (AD FS ) deployment topology to use in your production environment. This topic is a starting point for
reviewing and assessing considerations that affect what features or capabilities will be available to you after you
deploy AD FS. For example, depending on which database type you choose to store the AD FS configuration
database will ultimately determine whether you can implement certain Security Assertion Markup Language
(SAML ) features that require SQL Server.
Determining which type of AD FS configuration database to use

AD FS uses a database to store configuration and—in some cases—transactional data related to the Federation
Service. You can use the AD FS software to select either the built-in Windows Internal Database (WID ) or Microsoft
SQL Server 2005 or newer to store the data in the Federation Service.
For most purposes, the two database types are relatively equivalent. However, there are some differences to be
aware of before you begin reading more about the various deployment topologies that you can use with AD FS.
The following table describes the differences in supported features between a WID database and a SQL Server
database.
AD FS features
MORE INFORMATION ABOUT

FEATURE SUPPORTED BY WID? SUPPORTED BY SQL SERVER? THIS FEATURE
Federation server farm Yes, with a limit of 30 Yes. There is no enforced Determine Your AD FS
deployment federation servers for each limit for the number of Deployment Topology
farm federation servers that you
can deploy in a single farm
SAML artifact resolution No Yes The Role of the AD FS

Note: This feature is not Configuration Database
required for Microsoft Online
Services, Microsoft Office Best Practices for Secure
365, Microsoft Exchange, or Planning and Deployment of
Microsoft Office SharePoint AD FS
scenarios.
SAML/WS-Federation token No Yes The Role of the AD FS

replay detection Configuration Database
Best Practices for Secure

Planning and Deployment of
AD FS
Database features
MORE INFORMATION ABOUT
FEATURE SUPPORTED BY WID? SUPPORTED BY SQL SERVER? THIS FEATURE
Basic database redundancy Yes No The Role of the AD FS

using pull replication, where Configuration Database
one or more servers hosting
a read-only copy of the
database request changes
that are made on a source
server that hosts a
read/write copy of the
database
Database redundancy using No Yes The Role of the AD FS

high-availability solutions, Configuration Database
such as failover clustering or
mirroring (at the database High Availability Solutions
layer only) Note: All AD FS Overview
deployment topologies
support clustering at the AD
FS service layer.
SQL Server considerations

You should consider the following deployment facts if you select SQL Server as the configuration database for your
AD FS deployment.
SAML features and their effect on database size and growth. When either the SAML artifact resolution
or SAML token replay detection features are enabled, AD FS stores information in the SQL Server
configuration database for each AD FS token that is issued. The growth of the SQL Server database as a
result of this activity is not considered to be significant, and it depends on the configured token replay
retention period. Each artifact record has a size of approximately 30 kilobytes (KB ).
Number of servers required for your deployment. You will need to add at least one additional server (to
the total number of servers required to deploy your AD FS infrastructure) that will act as a dedicated host of
the SQL Server instance. If you plan to use failover clustering or mirroring to provide fault tolerance and
scalability for the SQL Server configuration database, a minimum of two SQL servers is required.
How the configuration database type you select may impact hardware resources
The impact to hardware resources on a federation server that is deployed in a farm using WID as opposed to a
federation server that is deployed in a farm using the SQL Server database is not significant. However, it is
important to consider that when you use WID for the farm, each federation server in that farm must store, manage,
and maintain replication changes for its local copy of the AD FS configuration database while also continuing to
provide the normal operations that the Federation Service requires.
In comparison, federation servers that are deployed in a farm that uses the SQL Server database do not necessarily
contain a local instance of the AD FS configuration database. Therefore, they may make slightly fewer demands on
hardware resources.
Verifying that your production environment can support an AD FS

deployment
In addition to the federation servers that you will deploy, and depending on how your existing production
environment is set up, the following additional servers may be required to provide the necessary infrastructure to
support your new AD FS deployment:
Active Directory domain controller
Certification authority (CA)
Web server to host federation metadata
Network load balancing (NLB )
See Also
Stand-Alone Federation Server Using WID
A stand-alone federation server in Active Directory Federation Services (AD FS ) consists of a single server that
hosts a Federation Service configured to use the Windows Internal Database (WID ). This AD FS topology is for test
labs. We do not recommend it for production environments because it has a limit of only one federation server, and
it cannot be used to scale up to more servers.
If you want to add additional federation servers to your test lab, you must rebuild the Federation Service from
scratch by deploying any of the other topologies mentioned later in this section. Therefore, we recommend that you
use this topology for a test lab or a proof-of-concept environment in your private testing network in which a single
federation server is adequate, as shown in the following illustration.
Test lab considerations

associated with this topology for test lab environments.
Information technology (IT) professionals or IT architects who want to evaluate or develop a proof of concept
for this technology
Easy to set up in a test lab environment
Only one federation server per Federation Service (no capability to scale up to a farm)
Not redundant (only a single instance of the AD FS configuration database exists)
See Also
The default topology for Active Directory Federation Services (AD FS ) is a federation server farm, using the
Windows Internal Database (WID ), that consists of up to five federation servers hosting your organization’s
Federation Service. In this topology, AD FS uses WID as the store for the AD FS configuration database for all
federation servers that are joined to that farm. The farm replicates and maintains the Federation Service data in the
configuration database across each server in the farm.
The act of creating the first federation server in a farm also creates a new Federation Service. When you use WID
for the AD FS configuration database, the first federation server that you create in the farm is referred to as the
primary federation server. This means that this computer is configured with a read/write copy of the AD FS
All other federation servers that you configure for this farm are referred to as secondary federation servers because
they must replicate any changes that are made on the primary federation server to the read-only copies of the AD
FS configuration database that they store locally.
NOTE
We recommend the use of at least two federation servers in a load-balanced configuration.
Organizations with 100 or fewer configured trust relationships that need to provide their internal users
(logged on to computers that are physically connected to the corporate network) with single sign-on (SSO )
access to federated applications or services
Organizations that want to provide their internal users with SSO access to Microsoft Online Services or
Smaller organizations that require redundant, scalable services
NOTE
Organizations with larger databases should consider using the Federation Server Farm Using SQL Server deployment
topology, which is described later in this section. Organizations with users who log in from outside the network should
consider using either the Federation Server Farm Using WID and Proxies topology or the Federation Server Farm Using SQL
Server topology.

Provides SSO access to internal users
Data and Federation Service redundancy (each federation server replicates changes to other federation
servers in the same farm)
The farm can be scaled out by adding up to five federation servers
WID is included with Windows; therefore, no need to purchase SQL Server
A WID farm has a limit of five federation servers. For more information, see AD FS Deployment Topology
Considerations.
A WID farm does not support token replay detection or artifact resolution (part of the Security Assertion
Markup Language (SAML ) protocol).

When you are ready to start deploying this topology in your network, you should plan on placing all of the
federation servers in your corporate network behind a Network Load Balancing (NLB ) host that can be configured
for an NLB cluster with a dedicated cluster Domain Name System (DNS ) name and cluster IP address.
NOTE
This cluster DNS name must match the Federation Service name, for example, fs.fabrikam.com.
The NLB host can use the settings that are defined in this NLB cluster to allocate client requests to the individual
federation servers. The following illustration shows how the fictional Fabrikam, Inc., company sets up the first phase
of its deployment using a two-computer federation server farm (fs1 and fs2) with WID and the positioning of a
DNS server and a single NLB host that is wired to the corporate network.
NOTE
If there is a failure on this single NLB host, users will not be able to access federated applications or services. Add additional
NLB hosts if your business requirements do not allow having a single point of failure.
For more information about how to configure your networking environment for use with federation servers, see
Name Resolution Requirements for Federation Servers in the AD FS Design Guide.
See Also
This deployment topology for Active Directory Federation Services (AD FS ) is identical to the federation server
farm with Windows Internal Database (WID ) topology, but it adds federation server proxies to the perimeter
network to support external users. The federation server proxies redirect client authentication requests that come
from outside your corporate network to the federation server farm.
Organizations with 100 or fewer configured trust relationships that need to provide both their internal users
and external users (who are logged on to computers that are physically located outside the corporate
network) with single sign-on (SSO ) access to federated applications or services
Organizations that need to provide both their internal users and external users with SSO access to Microsoft
Office 365
Smaller organizations that have external users and require redundant, scalable services
The same benefits as listed for the Federation Server Farm Using WID topology, plus the benefit of providing
additional access for external users
The same limitations as listed for the Federation Server Farm Using WID topology

To deploy this topology, in addition to adding two federation server proxies, you must make sure that your
perimeter network can also provide access to a Domain Name System (DNS ) server and to a second Network
Load Balancing (NLB ) host. The second NLB host must be configured with an NLB cluster that uses an Internet-
accessible cluster IP address, and it must use the same cluster DNS name setting as the previous NLB cluster that
you configured on the corporate network (fs.fabrikam.com). The federation server proxies should also be
configured with Internet-accessible IP addresses.
The following illustration shows the existing federation server farm with WID topology that was described
previously and how the fictional Fabrikam, Inc., company provides access to a perimeter DNS server, adds a second
NLB host with the same cluster DNS name (fs.fabrikam.com), and adds two federation server proxies (fsp1 and
fsp2) to the perimeter network.
For more information about how to configure your networking environment for use with federation servers or
federation server proxies, see either Name Resolution Requirements for Federation Servers or Name Resolution
Requirements for Federation Server Proxies.
See Also
This topology for Active Directory Federation Services (AD FS ) differs from the federation server farm using
Windows Internal Database (WID ) deployment topology in that it does not replicate the data to each federation
server in the farm. Instead, all federation servers in the farm can read and write data into a common database that
is stored on a server running Microsoft SQL Server that is located in the corporate network.
Large organizations with more than 100 trust relationships that need to provide both their internal users and
external users with single sign-on (SSO ) access to federated application or services
Organizations that already use SQL Server and want to take advantage of their existing tools and expertise
Support for larger numbers of trust relationships (more than 100)
Support for token replay detection (a security feature) and artifact resolution (part of the Security Assertion
Markup Language (SAML ) 2.0 protocol)
Support for the full benefits of SQL Server, such as database mirroring, failover clustering, reporting, and
management tools
This topology does not provide database redundancy by default. Although a federation server farm with WID
topology automatically replicates the WID database on each federation server in the farm, the federation server
farm with SQL Server topology contains only one copy of the database
NOTE
SQL Server supports many different data and application redundancy options including failover clustering, database mirroring,
and several different types of SQL Server replication.
The Microsoft Information Technology (IT) department uses SQL Server database mirroring in high-safety
(synchronous) mode and failover clustering to provide high-availability support for the SQL Server instance. SQL
Server transactional (peer-to-peer) and merge replication have not been tested by the AD FS product team at
Microsoft. For more information about SQL Server, see High Availability Solutions Overview or Selecting the
Appropriate Type of Replication.
Supported SQL Server Versions
The following SQL server versions are supported with AD FS installed with Windows Server 2012:
SQL Server 2008 / R2
SQL Server 2012

Similar to the federation server farm with WID topology, all of the federation servers in the farm are configured to
use one cluster Domain Name System (DNS ) name (which represents the Federation Service name) and one
cluster IP address as part of the Network Load Balancing (NLB ) cluster configuration. This helps the NLB host
allocate client requests to the individual federation servers. Federation server proxies can be used to proxy client
requests to the federation server farm.
The following illustration shows how the fictional Contoso Pharmaceuticals company deployed its federation
server farm with SQL Server topology in the corporate network. It also shows how that company configured the
perimeter network with access to a DNS server, an additional NLB host that uses the same cluster DNS name
(fs.contoso.com) that is used on the corporate network NLB cluster, and with two federation server proxies (fsp1
and fsp2).
For more information about how to configure your networking environment for use with federation servers or
federation server proxies, see either Name Resolution Requirements for Federation Servers or Name Resolution
See Also
When you plan for cross-organizational (federation-based) collaboration using Active Directory Federation
Services (AD FS ), first determine if your organization will host a Web resource to be accessed by other
organizations across the Internet or if you will provide access to the Web resource for employees in your
organization. This determination affects how you deploy AD FS, and it is fundamental in the planning of your AD
FS infrastructure.
NOTE
Make sure that the role that organization plays in the federation agreement is clearly understood by all parties.
For the Federated Web SSO Design, AD FS uses terms such as account partner (also referred to as identity
provider in the AD FS Management snap-in) and resource partner (also referred to as relying party in the AD FS
Management snap-in) to help differentiate the organization that hosts the accounts (the account partner) from the
organization that hosts the Web-based resources (the resource partner).
In the Web SSO Design, the organization acts in both the account partner and resource partner roles because it is
providing its users with access to its applications.
The following topics explain some of the AD FS partner organization concepts. They also contain links to topics in
the AD FS Deployment Guide that contain information about setting up and configuring account partner
organizations and resource partner organizations based on your AD FS deployment goals.
In this section
Best Practices for Secure Planning and Deployment of AD FS
Planning for Interoperability with AD FS 1.x
When to Use Identity Delegation
Deploying AD FS in the Account Partner Organization
Deploying AD FS in the Resource Partner Organization
See Also
Using AD DS Claims with AD FS
You can enable richer access control for federated applications by using Active Directory Domain Services (AD
DS )-issued user and device claims together with Active Directory Federation Services (AD FS ).
About Dynamic Access Control

In Windows Server® 2012, the Dynamic Access Control feature enables organizations to grant access to files
based on user claims (which are sourced by user account attributes) and device claims (which are sourced by
computer account attributes) that are issued by Active Directory Domain Services (AD DS ). AD DS issued claims
are integrated into Windows integrated authentication through the Kerberos authentication protocol.
For more information about Dynamic Access Control, see Dynamic Access Control Content Roadmap.
What’s New in AD FS?
As an extension to the Dynamic Access Control scenario, AD FS in Windows Server 2012 can now:
Access computer account attributes in addition to user account attributes from within AD DS. In previous
versions of AD FS, the Federation Service could not access computer account attributes at all from AD DS.
Consume AD DS issued user or device claims that reside in a Kerberos authentication ticket. In previous
versions of AD FS, the claims engine was able to read user and group security IDs (SIDs) from Kerberos but
was not able to read any claims information contained within a Kerberos ticket.
Transform AD DS issued user or device claims into SAML tokens that relying applications can use to
perform richer access control.
Benefits of Using AD DS Claims with AD FS

These AD DS issued claims can be inserted into Kerberos authentication tickets and used with AD FS to provide
the following benefits:
Organizations that require richer access control policies can enable claims-based access to applications and
resources by using AD DS issued claims that are based on the attribute values stored in AD DS for a given
user or computer account. This can help administrators to reduce additional overhead associated with
creating and managing:
AD DS security groups that would otherwise be used for controlling access to applications and
resources that are accessible via Windows Integrated authentication.
Forest trusts that would otherwise be used for controlling access to Business-to-Business (B2B ) /
Internet accessible applications and resources.
Organizations can now prevent unauthorized access to network resources from client computers based on
whether a specific computer account attribute value stored in AD DS (for example, a computer’s DNS name)
matches the access control policy of the resource (for example, a file server that has been ACLd with claims)
or the relying party policy (for example, a claims-aware Web application). This can help administrators to set
finer access control policies for resources or applications that are:
Only accessible via Windows Integrated authentication.
Internet accessible via AD FS authentication mechanisms. AD FS can be used to transform AD DS
issued device claims into AD FS claims that can be encapsulated into SAML tokens which can be
consumed by an Internet accessible resource or relying party application.
Differences Between AD DS and AD FS Issued Claims

There are two differentiating factors that are important to understand about claims that are issued from AD DS vs.
AD FS. These differences include:
AD DS can only issue claims that are encapsulated in Kerberos tickets, not SAML tokens. For more
information about how AD DS issues claims, see Dynamic Access Control Content Roadmap.
AD FS can only issue claims that are encapsulated in SAML tokens, not Kerberos tickets. For more
information about how AD FS issues claims, see The Role of the Claims Engine.
How AD DS Issued Claims Work with AD FS

AD DS issued claims can be used with AD FS to access both user and device claims directly from the user’s
authentication context, rather than making a separate LDAP call to Active Directory. The following illustration and
corresponding steps discusses how this process works in more detail to enable claims-based access control for the
Dynamic Access Control scenario.
1. An AD DS administrator uses the Active Directory Administrative Center console or PowerShell cmdlets to
enables specific claim type objects in the AD DS schema.
2. An AD FS administrator uses the AD FS Management console to create and configure the claims provider
and relying party trusts with either pass-through or transform claim rules.
3. A Windows client attempts to access the network. As part of the Kerberos authentication process, the client
presents its user and computer ticket-granting ticket (TGT) which does not yet contain any claims, to the
domain controller. The domain controller then looks in AD DS for enabled claim types, and includes any
resulting claims in the returned Kerberos ticket.
4. When the user/client attempts to access a file resource that is ACLd to require the claims, they can access the
resource because the compound ID that was surfaced from Kerberos has these claims.
5. When the same client attempts to access a Web site or Web application that is configured for AD FS
authentication, the user is redirected to an AD FS federation server that is configured for Windows
integrated authentication. The client sends a request to the domain controller using Kerberos. The domain
controller issues a Kerberos ticket containing the requested claims which the client can then present to the
federation server.
6. Based on the way the claims rules have been configured on the claims provider and relying party trusts that
the administrator configured previously, AD FS reads the claims from the Kerberos ticket and includes them
in a SAML token that it issues for the client.
7. The client receives the SAML token containing the correct claims and is then redirected to the website.
For more information about how to create the claim rules required for AD DS issued claims to work with AD FS,
see Create a Rule to Transform an Incoming Claim.
See Also
Best Practices for Secure Planning and Deployment of
AD FS
This topic provides best-practice information to help you plan and evaluate security when you design your Active
Directory Federation Services (AD FS ) deployment. This topic is a starting point for reviewing and assessing
considerations that affect the overall security of your use of AD FS. The information in this topic is meant to
compliment and extend your existing security planning and other design best practices.
Core security best practices for AD FS

The following core best practices are common to all AD FS installations where you want to improve or extend the
security of your design or deployment:
Use the Security Configuration Wizard to apply AD FS -specific security best practices to
federation servers and federation server proxy computers
The Security Configuration Wizard (SCW ) is a tool that comes preinstalled on all Windows Server 2008,
Windows Server 2008 R2 and Windows Server 2012 computers. You can use it to apply security best
practices that can help reduce the attack surface for a server, based on the server roles that you are installing.
When you install AD FS, the setup program creates role extension files that you can use with the SCW to
create a security policy that will apply to the specific AD FS server role (either federation server or federation
server proxy) that you choose during setup.
Each role extension file that is installed represents the type of role and subrole for which each computer is
configured. The following role extension files are installed in the C:WindowsADFSScw directory:
Farm.xml
SQLFarm.xml
StandAlone.xml
Proxy.xml (This file is present only if you configured the computer in the federation server proxy role.)
To apply the AD FS role extensions in the SCW, complete the following steps in order:
1. Install AD FS and choose the appropriate server role for that computer. For more information, see
Install the Federation Service Proxy Role Service in the AD FS Deployment Guide.
2. Register the appropriate role extension file using the Scwcmd command-line tool. See the following
table for details about using this tool in the role for which your computer is configured.
3. Verify that the command has completed successfully by examining the SCWRegister_log.xml file,
which is located in the WindowssecurityMsscwLogs directory.
You must perform all these steps on each federation server or federation server proxy computer to which
you want to apply AD FS –based SCW security policies.
The following table explains how to register the appropriate SCW role extension, based on the AD FS server
role that you chose on the computer where you installed AD FS.
AD FS CONFIGURATION DATABASE TYPE THE FOLLOWING COMMAND AT A
AD FS SERVER ROLE USED COMMAND PROMPT:
Stand-alone federation server Windows Internal Database scwcmd register

/kbname:ADFS2Standalone
/kbfile:"WindowsADFSscwStandAlone.xml"
Farm-joined federation server Windows Internal Database scwcmd register

/kbfile:"WindowsADFSscwFarm.xml"
Farm-joined federation server SQL Server scwcmd register

/kbfile:"WindowsADFSscwSQLFarm.xml"
Federation server proxy N/A scwcmd register

/kbfile:"WindowsADFSscwProxy.xml"
For more information about the databases that you can use with AD FS, see The Role of the AD FS
Configuration Database.
Use token replay detection in situations in which security is a very important concern, for
example, when kiosks are used.
Token replay detection is a feature of AD FS that ensures that any attempt to replay a token request that is
made to the Federation Service is detected and the request is discarded. Token replay detection is enabled by
default. It works for both the WS -Federation passive profile and the Security Assertion Markup Language
(SAML ) WebSSO profile by ensuring that the same token is never used more than once.
When the Federation Service starts, it begins to build a cache of any token requests that it fulfills. Over time,
as subsequent token requests are added to the cache, the ability to detect any attempts to replay a token
request multiple times increases for the Federation Service. If you disable token replay detection and later
choose to enable it again, remember that the Federation Service will still accept tokens for a period of time
that may have been used previously, until the replay cache has been allowed enough time to rebuild its
contents. For more information, see The Role of the AD FS Configuration Database.
Use token encryption, especially if you are using supporting SAML artifact resolution.
Encryption of tokens is strongly advised to increase security and protection against potential man-in-the-
middle (MITM ) attacks that might be tried against your AD FS deployment. Using use encryption might
have a slight impact on throughout but in general, it should not be usually noticed and in many deployments
the benefits for greater security exceed any cost in terms of server performance.
To enable token encryption, first set add an encryption certificate for your relying party trusts. You can
configure an encryption certificate either when creating a relying party trust or later. To add an encryption
certificate later to an existing relying party trust, you can set a certificate for use on the Encryption tab
within trust properties while using the AD FS snap-in. To specify a certificate for an existing trust using the
AD FS cmdlets, use the EncryptionCertificate parameter of either the Set-ClaimsProviderTrust or Set-
RelyingPartyTrust cmdlets. To set a certificate for the Federation Service to use when decrypting tokens,
use the Set-ADFSCertificate cmdlet and specify " Token-Encryption " for the CertificateType parameter.
Enabling and disabling encryption for specific relying party trust can be done by using the EncryptClaims
parameter of the Set-RelyingPartyTrust cmdlet.
Utilize extended protection for authentication
To help secure your deployments, you can set and use the extended protection for authentication feature
with AD FS. This setting specifies the level of extended protection for authentication supported by a
federation server.
Extended protection for authentication helps protect against man-in-the-middle (MITM ) attacks, in which an
attacker intercepts client credentials and forwards them to a server. Protection against such attacks is made
possible through a Channel Binding Token (CBT) which can be either required, allowed, or not required by
the server when it establishes communications with clients.
To enable the extended protection feature, use the ExtendedProtectionTokenCheck parameter on the
Set-ADFSProperties cmdlet. Possible values for this setting and the level of security that the values provide
are described in the following table.
PARAMETER VALUE SECURITY LEVEL PROTECTION SETTING
Require Server is fully hardened. Extended protection is enforced and

always required.
Allow Server is partially hardened. Extended protection is enforced

where systems involved have been
patched to support it.
None Server is vulnerable. Extended protection is not enforced.
If you are using logging and tracing, ensure the privacy of any sensitive information.
AD FS does not, by default, expose or track personally identifiable information (PII) directly as part of the
Federation Service or normal operations. When event logging and debug trace logging are enabled in AD
FS, however, depending on the claims policy that you configure some claims types and their associated
values might contain PII that might be logged in the AD FS event or tracing logs.
Therefore, enforcing access control on the AD FS configuration and its log files is strongly advised. If you do
not want this kind of information to be visible, you should disable loggin, or filter out any PII or sensitive
data in your logs before you share them with others.
The following tips can help you prevent the content of a log file from being exposed unintentionally:
Ensure that the AD FS event log and trace log files are protected by access control lists (ACL ) that
limit access to only those trusted administrators who require access to them.
Do not copy or archive log files using file extensions or paths that can be easily served using a Web
request. For example, the .xml file name extension is not a safe choice. You can check the Internet
Information Services (IIS ) administration guide to see a list of extensions that can be served.
If you revise the path to the log file, be sure to specify an absolute path for the log file location, which
should be outside of the Web host virtual root (vroot) public directory to prevent it from being
accessed by an external party using a Web browser.
AD FS Extranet Soft Lockout and AD FS Extranet Smart Lockout Protection
In case of an attack in the form of authentication requests with invalid(bad) passwords that come through
the Web Application Proxy, AD FS extranet lockout enables you to protect your users from an AD FS
account lockout. In addition to protecting your users from an AD FS account lockout, AD FS extranet lockout
also protects against brute force password guessing attacks.
For Extranet Soft Lockout for AD FS on Windows Server 2012 R2 see AD FS Extranet Soft Lockout
Protection.
For Extranet Smart Lockout for AD FS on Windows Server 2016 see AD FS Extranet Smart Lockout
Protection.
SQL Server–specific security best practices for AD FS
The following security best practices are specific to the use of Microsoft SQL Server® or Windows Internal
Database (WID ) when these database technologies are used to manage data in AD FS design and deployment.
NOTE
These recommendations are meant to extend, but not replace, SQL Server product security guidance. For more information
about planning a secure SQL Server installation, see Security Considerations for a Secure SQL Installation
Always deploy SQL Server behind a firewall in a physically secure network environment.
A SQL Server installation should never be exposed directly to the Internet. Only computers that are inside
your datacenter should be able to reach your SQL server installation that supports AD FS. For more
information, see Security Best Practices Checklist (https://go.microsoft.com/fwlink/?LinkID=189229).
Run SQL Server under a service account instead of using the built-in default system service
accounts.
By default, SQL Server is often installed and configured to use one of the supported built-in system
accounts, such as the LocalSystem or NetworkService accounts. To enhance the security of your SQL Server
installation for AD FS, wherever possible use a separate service account for accessing your SQL Server
service and enable Kerberos authentication by registering the security principal name (SPN ) of this account
in your Active Directory deployment. This enables mutual authentication between client and server. Without
SPN registration of a separate service account, SQL Server will use NTLM for Windows-based
authentication, where only the client is authenticated.
Minimize the surface area of SQL Server.
Enable only those SQL Server endpoints that are necessary. By default, SQL Server provides a single built-in
TCP endpoint that cannot be removed. For AD FS, you should enable this TCP endpoint for Kerberos
authentication. To review the current TCP endpoints to see if additional user-defined TCP ports are added to
a SQL installation, you can use the "SELECT * FROM sys.tcp_endpoints" query statement in a Transact-SQL
(T-SQL ) session. For more information about SQL Server endpoint configuration, see How To: Configure
the Database Engine to Listen on Multiple TCP Ports (https://go.microsoft.com/fwlink/?LinkID=189231).
Avoid using SQL -based authentication.
To avoid having to transfer passwords as clear text over your network or storing passwords in configuration
settings, use Windows authentication only with your SQL Server installation. SQL Server authentication is a
legacy authentication mode. Storing Structured Query Language (SQL ) login credentials (SQL user names
and passwords) when you are using SQL Server authentication is not recommended. For more information,
see Authentication Modes (https://go.microsoft.com/fwlink/?LinkID=189232).
Evaluate the need for additional channel security in your SQL installation carefully.
Even with Kerberos authentication in effect, the SQL Server Security Support Provider Interface (SSPI) does
not provide channel-level security. However, for installations in which servers are securely located on a
firewall-protected network, encrypting SQL communications may not be necessary.
Although encryption is a valuable tool to help ensure security, it should not be considered for all data or
connections. When you are deciding whether to implement encryption, consider how users will access data.
If users access data over a public network, data encryption might be required to increase security. However,
if all access of SQL data by AD FS involves a secure intranet configuration, encryption might not be
required. Any use of encryption should also include a maintenance strategy for passwords, keys, and
certificates.
If there is a concern that any SQL data might be seen or tampered with over your network, use Internet
Protocol security (IPsec) or Secure Sockets Layer (SSL ) to help secure your SQL connections. However, this
might have a negative effect on SQL Server performance, which might affect or limit AD FS performance in
some situations. For example, AD FS performance in token issuance might degrade when attribute lookups
from a SQL -based attribute store are critical for token issuance. You can better eliminate a SQL tampering
threat by having a strong perimeter security configuration. For example, a better solution for securing your
SQL Server installation is to ensure that it remains inaccessible for Internet users and computers and that it
remains accessible only by users or computers within your datacenter environment.
For more information, see Encrypting Connections to SQL Server or SQL Server Encryption.
Configure securely designed access by using stored procedures to perform all SQL -based lookups
by AD FS of SQL -stored data.
To provide better service and data isolation, you can create stored procedures for all attribute store lookup
commands. You can create a database role to which you then grant permission to run the stored procedures.
Assign the service identity of the AD FS Windows service to this database role. The AD FS Windows service
should not be able to run any other SQL statement, other than the appropriate stored procedures that are
used for attribute lookup. Locking down access to the SQL Server database in this way reduces the risk of an
elevation-of-privilege attack.
See Also
Planning for Interoperability with AD FS 1.x
Active Directory Federation Services (AD FS ) federation servers running Windows Server® 2012 can interoperate
with both an AD FS 1.0 (installed with Windows Server 2003 R2) Federation Service and an AD FS 1.1 (installed
with Windows Server 2008 or Windows Server 2008 R2) Federation Service. Any of the following interoperability
combinations are supported:
Any AD FS 1.x Federation Service can send a claim that can be consumed by an AD FS Federation Service in
Windows Server 2012 . For more information, see Checklist: Configuring AD FS to Consume Claims from
AD FS 1.x.
Any AD FS Federation Service in Windows Server 2012 can send an AD FS 1.x-compatible claim that can be
consumed by an AD FS 1.x Federation Service. For more information, see Checklist: Configuring AD FS to
Send Claims to an AD FS 1.x Federation Service.
Any AD FS Federation Service in Windows Server 2012 can send an AD FS 1.x-compatible claim that can be
consumed by one or more Web servers running the AD FS 1.x claims-aware Web agent. For more
information, see Checklist: Configuring AD FS to Send Claims to an AD FS 1.x Claims-Aware Web Agent.
NOTE
AD FS does not support or interoperate with the AD FS 1.x Windows NT token–based Web agent.
An AD FS 1.x-compatible claim is a claim that can be sent by an AD FS Federation Service in Windows Server
2012 and understood by an AD FS 1.x Federation Service. So that an AD FS 1.x Federation Service can consume
the claims that an AD FS Federation Service sends, a Name Identifier (ID ) claim type must be sent.
Understanding the Name ID claim type

The Name ID claim type is the equivalent of the identity claim type that AD FS 1.x uses. It must be used whenever
you want to interoperate with AD FS 1.x. The Name ID claim type enables either an AD FS 1.x Federation Service
or the AD FS 1.x claims-aware Web agent to consume claims that AD FS in Windows Server 2012 sends, as long
as these claims are sent in one of the Name ID formats in the following table.
NAME ID FORMAT CORRESPONDING URI
AD FS 1.x Email Address http://schemas.xmlsoap.org/claims/EmailAddress
AD FS 1.x Email UPN http://schemas.xmlsoap.org/claims/UPN
Common Name http://schemas.xmlsoap.org/claims/CommonName
Group http://schemas.xmlsoap.org/claims/Group
Only one Name ID claim in the appropriate format must be sent. When that criterion is satisfied, many other claims
may be sent as well, assuming that they conform to the restrictions described in the table.
NOTE
An AD FS 1.x Federation Service can interpret only incoming claim types that begin with the Uniform Resource Identifier (URI)
of http://schemas.xmlsoap.org/claims/.
See Also
When to Use Identity Delegation
What is identity delegation?

Identity delegation is a feature of Active Directory Federation Services (AD FS ) that allows administrator-specified
accounts to impersonate users. The account that impersonates the user is called the delegate. This delegation
capability is critical for many distributed applications for which there is a series of access control checks that must
be made sequentially for each application, database, or service that is in the authorization chain for the originating
request. Many real-world scenarios exist in which a Web application “front end” must retrieve data from a more
secure “back end”, such as a Web service that is connected to a Microsoft SQL Server database.
For example, an existing parts-ordering Web site can be enhanced programmatically so that it allows partner
organizations to view their own purchase history and account status. For security reasons, all partner financial data
is stored in a secure database on a dedicated Structured Query Language (SQL ) server. In this situation, the code in
the front-end application knows nothing about the partner organization’s financial data. Therefore, it must retrieve
that data from another computer elsewhere on the network that hosts (in this case) the Web service for the parts
database (the back end).
For this data-retrieval process to succeed, some succession of authorization “hand-shaking” must take place
between the Web application and the Web service for the parts database, as shown in the following illustration.
Because the original request was made to the Web server itself, which is likely to be located in a completely
different organization from the organization of the user who is attempting to access the Web server, the security
token that is sent along with the request does not meet the authorization criteria required to access any other
computer besides the Web server. Therefore, the only way that the originating user request can be fulfilled is by
placing an intermediate federation server in the resource partner organization to help with reissuing a security
token that does have the appropriate access privileges.
How does identity delegation work?

Web applications in multitier application architectures often call Web services to access common data or
functionality. It is important for these Web services to know the identity of the original user so that the service can
make authorization decisions and facilitate auditing. In this case, the front-end Web application represents the user
to the Web service as a delegate. AD FS facilitates this scenario by allowing Active Directory accounts to act as a
user to another relying party. An identity delegation scenario is shown in the following illustration.
1. Frank attempts to access part-ordering history from a Web application in another organization. His client
computer requests and receives a token from AD FS for the front-end part-ordering Web application.
2. The client computer sends a request to the Web application, including the token obtained in step 1, to prove
the client’s identity.
3. The Web application needs to communicate with the Web service to complete its transaction for the client.
The Web application contacts AD FS to obtain a delegation token to interact with the Web service.
Delegation tokens are security tokens that are issued to a delegate to act as a user. AD FS returns a
delegation token with claims about the client, targeted for the Web service.
4. The Web application uses the token that was obtained from AD FS in step 3 to access the Web service that is
acting as the client. Examining the delegation token, the Web service can determine that the Web application
is acting as the client. The Web service executes its authorization policy, logs the request, and provides the
needed parts history data that was originally requested by Frank to the Web application and therefore to
Frank.
For a particular delegate, AD FS can limit the Web services for which the Web application may request a delegation
token. The client computer does not have to have an Active Directory account for this operation to succeed. Finally,
as noted previously, the Web service can easily determine the identity of the delegate that is acting as the user. This
allows Web services to exhibit different behavior based on whether they are talking directly to the client computer
or through a delegate.
Configuring AD FS for identity delegation

You can use the AD FS Management snap-in to configure AD FS for identity delegation whenever you need to
facilitate the data retrieval process. After you configure it, AD FS can generate new security tokens that will include
the authorization context that the back-end service may require before it can provide access to the protected data.
AD FS does not restrict which users can be impersonated. After you configure AD FS for identity delegation, it does
the following:
It determines which servers can be delegated the authority to request tokens to impersonate a user.
It establishes and keeps separate both the identity context for the client account that is delegated and the
server that acts as a delegate.
You can configure identity delegation by adding delegation authorization rules to a relying party trust in the AD FS
Management snap-in. For more information about how to do this, see Checklist: Creating Claim Rules for a Relying
Party Trust.
Configuring the front-end Web application for identity delegation
Developers have several options that they can use to appropriately program the Web front-end application or
service to redirect delegation requests to an AD FS computer. For more information about how to customize a Web
application to work with identity delegation, see the Windows Identity Foundation SDK.
See Also
Deploying AD FS in the Account Partner
Organization
An account partner in Active Directory Federation Services (AD FS ) represents the organization in the federation
trust relationship that physically stores user accounts in a supported attribute store. For more information about
which attribute stores are supported, see The Role of Attribute Stores.
The federation server in the account partner organization authenticates local users and creates security tokens that
are used by the resource partner in making authorization decisions. Relying parties such as Web sites and Web
services are then able to easily register themselves with the federation server and consume issued tokens for
authentication and access control.
In scenarios in which you need to provide your users with access to multiple federated applications or services—
when each application or service is hosted by a different organization—you can configure the account partner
federation server so that you can deploy multiple relying parties.
For more information about how to set up and configure an account partner organization, see Checklist:
Configuring the Account Partner Organization.
In this section
Review the Role of the Federation Server in the Account Partner
Review the Role of the Federation Server Proxy in the Account Partner
Prepare Client Computers in the Account Partner
See Also
Review the Role of the Federation Server in the
Account Partner
A federation server in Active Directory Federation Services (AD FS ) functions as a security token issuer. A
federation server generates claims based on account values that reside in a local attribute store and packages them
into security tokens so that users can seamlessly access Web-browser-based applications (using single sign-on
(SSO )) that are hosted in a resource partner organization.
NOTE
When your users access federated applications by using a Web browser, a federation server automatically issues cookies to
the users to maintain their logon status for that Web-browser-based application. These cookies include claims for the users.
The cookies enable SSO capabilities so that the users do not have to enter credentials each time that they visit different Web-
browser-based applications in the resource partner.
In the Web SSO design, organizations with a perimeter network that want Internet users to have access to
applications must install a federation server proxy in the perimeter network. In the Federated Web SSO design,
there must be at least one federation server installed in the corporate network of the account partner organization
and at least one federation server installed in the corporate network of the resource partner organization.
NOTE
Before you can set up a federation server computer in the account partner organization, you must first join the computer to
any domain in the Active Directory forest where the federation server will be used to authenticate users from that forest. For
more information, see Checklist: Setting Up a Federation Server.
See Also
Review the Role of the Federation Server Proxy in the
Account Partner
The primary role of the federation server proxy in the perimeter network of the account partner organization in
Active Directory Federation Services (AD FS ) is to collect authentication credentials from a client computer that
logs on over the Internet and to pass those credentials to the federation server, which is located inside the corporate
network of the account partner organization. The account for the client computer is stored in the account partner’s
attribute store.
A federation server proxy can also function in one or more of the following roles, depending on how you configure
it to meet the needs of the account partner organization:
Relay Security Tokens—The federation server issues a security token to the federation server proxy, which
then relays the token to the client computer. The security token is used to provide access for that client
computer to a specific relying party.
Collect Credentials—The federation server proxy uses a default client logon Web form (clientlogon.aspx) to
collect password-based credentials through forms-based authentication. However, you can customize this
form to accept other supported types of authentication, such as Secure Sockets Layer (SSL ) client
authentication. For more information about how to customize this page, see Customizing Client Logon and
Home Realm Discovery Pages (http://go.microsoft.com/fwlink/?LinkId=104275). A federation server proxy
does not accept credentials through Windows Integrated Authentication.
To summarize, a federation server proxy in the account partner acts as a proxy for client logons to a federation
server that is located in the corporate network. The federation server proxy also facilitates the distribution of
security tokens to Internet clients that are destined for relying parties.
Cau t i on
Exposing a federation server proxy on the account partner extranet will the client logon Web form accessible by
anyone with Internet access. This can potentially leave your organization vulnerable to some password-based
attacks, such as dictionary attacks or brute force attacks that can trigger account lockouts for user accounts that are
stored in the corporate Active Directory Domain Services (AD DS ).
See Also
Prepare Client Computers in the Account Partner
The easiest way for an administrator in an account partner organization to prepare client computers for access to
Active Directory Federation Services (AD FS ) federated applications is to use Group Policy. Group Policy provides a
convenient way for you to push specific certificates and settings that are required for federation to all the client
computers that will be used to access federated applications.
So that your client computers can seamlessly access federated applications without certificate prompts or trusted
site–related prompts, we recommend that you first prepare each client computer before you deploy AD FS broadly
in your organization. Consider using Group Policy to automatically:
Configure Internet Explorer on each client computer to trust the account federation server.
For more information, see Configure Client Computers to Trust the Account Federation Server.
Install the appropriate account federation server, resource federation server, and Web server Secure Sockets
Layer (SSL ) certificates (or equivalent certificates that chain to a trusted root) on each client computer.
For more information, see Distribute Certificates to Client Computers by Using Group Policy.
See Also
Deploying AD FS in the Resource Partner
Organization
The resource partner organization in Active Directory Federation Services (AD FS ) represents the organization
whose Web servers may be protected by a resource-side federation server. The federation server at the resource
partner uses the security tokens that are produced by the account partner to provide claims to the Web servers that
are located in the resource partner.
In scenarios in which you need to provide access to federated services or applications to many different users—
when some users reside in different organizations—you can configure the resource federation server so that you
can deploy multiple account partners.
For more information about how to set up and configure a resource partner organization, see Checklist:
Configuring the Resource Partner Organization.
In this section
Review the Role of the Federation Server in the Resource Partner
Review the Role of the Federation Server Proxy in the Resource Partner
Determine Your Federated Application Strategy in the Resource Partner
See Also
Review the Role of the Federation Server in the
Resource Partner
The federation server in the resource partner organization intercepts incoming security tokens that are sent by an
account federation server, validates and signs them, and then issues its own security tokens that are destined for the
Web-based application.
NOTE
When federated users use their Web browsers to access Web-based applications, the federation server in the resource
partner organization builds a new authentication cookie and writes it to the browser. This cookie enables single-sign-on (SSO)
capabilities so that users do not have to log on again at the federation server in the account partner when the users attempt
to access different Web-based applications in the resource partner.
In the Web SSO design, at least one federation server must be installed in the perimeter network. In the Federated
Web SSO design, there must be at least one federation server installed in the corporate network of the account
partner organization and at least one federation server installed in the corporate network of the resource partner
organization.
NOTE
Before you can set up a federation server computer in the resource partner organization, you must first join the computer to
any Active Directory domain in the resource partner organization. For more information, see Checklist: Setting Up a
Federation Server.
See Also
Review the Role of the Federation Server Proxy in the
Resource Partner
A federation server proxy in Active Directory Federation Services (AD FS ) can function in one or more of the
following roles, depending on how you configure the server to meet the needs of the resource partner
organization:
Account partner discovery: An Internet client computer must identify which account partner will
authenticate it. The client finds the account partner by using an account partner discovery Web form
(discoverclientrealm.aspx), which is stored on the federation server proxy in the resource partner. If more
than one account partner is configured in the AD FS Management snap-in, a drop-down menu appears to
the client with all the available account partners that are visible to Internet client computers that access the
account partner discovery Web form. You can change how the account partner discovery Web form is
presented to client computers by customizing the discoverclientrealm.aspx file.
Security token redirection: The federation server proxy in the account partner sends the security tokens to
the resource partner. The resource federation server proxy accepts these tokens and passes them on to the
federation server in the resource partner. The resource federation server then issues a security token that is
bound for a specific resource Web server. The resource federation server proxy then redirects the token to
the client.
To summarize, a resource federation server proxy facilitates the federated logon process by redirecting client
computers to a federation server that can authenticate the clients. A resource federation server proxy also acts as a
proxy for client security tokens to resource federation servers.
NOTE
When it is necessary to help reduce the amount of hardware and the number of required certificates, the federation server
proxy can be located on the same computer as the Web server.
See Also
Determine Your Federated Application Strategy in the
Resource Partner
An important part of designing a new Active Directory Federation Services (AD FS ) infrastructure in the resource
partner organization is determining your full set of applications and services that will be used to participate in the
federation and which account partners will be the recipients of those resources. Before you design a federated
application and services strategy, consider the following questions:
Will you be enabling and deploying an ASP.NET application or a Windows Communication Foundation
(WCF ) service for federation?
Will users on your corporate network require access to the federated application or service through
Windows Integrated Authentication?
Will the federated application or service be used by users in your perimeter network? If so, will Windows
Integrated Authentication be required?
Are all of the Web servers that host federated applications running a Windows Server operating system and
Internet Information Services (IIS )?
Who will the federated application or service provide resources for?
Answering these questions will help you plan a solid AD FS design. It will also assist you in creating a federated
application and services strategy that is cost effective and resource efficient. For more information about designing
the most appropriate federated application and services strategy for your organization, see the following topics in
this guide:
Provide Your Active Directory Users Access to Your Claims-Aware Applications and Services
Provide Your Active Directory Users Access to the Applications and Services of Other Organizations
Provide Users in Another Organization Access to Your Claims-Aware Applications and Services
For more information about how to create a claims-aware ASP.NET application or WCF service, see Windows
Identity Foundation SDK.
See Also
The most critical component of an Active Directory Federation Services (AD FS ) deployment is the federation
server. Therefore, it is important that you plan your federation server placement strategy carefully, including when
and where to deploy federation servers. The information in the following topics can help you determine when and
where to create a federation server or federation server farm and whether to use that federation server in the
account partner role, the resource partner role, or both:
Review the Role of the Federation Server in the Resource Partner
When to Create a Federation Server
Where to Place a Federation Server
When to Create a Federation Server Farm
Certificate Requirements for Federation Servers
Name Resolution Requirements for Federation Servers
NOTE
Although this information might help with your placement planning for federation servers, it does not explain how to
determine the proper number of federation servers and the hardware requirements for each AD FS design.
For examples of how a federation server can be placed in any of the two primary AD FS design scenarios, see
Mapping Your Deployment Goals to an AD FS Design.
See Also
When to Create a Federation Server
When you create a federation serverin Active Directory Federation Services (AD FS ), you provide a means by
which your organization can:
Engage in Web single-sign-on (SSO )–based communication with another organization (that also has at least
one federation server) and, when necessary, with the employees in your own organization (who need access
over the Internet).
Enable front end services to impersonate users to infrastructure services using identity delegation. For more
information, see When to Use Identity Delegation.
The following sections describe some of the key decisions for determining when and where to create one or more
federation servers.
Determine the organizational role for the federation server

To make an informed decision regarding when to create a new federation server, you must first determine in which
organization the server will reside. The role that a federation server plays in an organization depends on whether
you place the federation server in the account partner organization or in the resource partner organization.
When a federation server is placed in the corporate network of the account partner, its role is to authenticate the
user credentials of browser, Web service, or identity selector clients and send security tokens to the clients. For
more information, see Review the Role of the Federation Server in the Account Partner.
When a federation server is placed in the corporate network of the resource partner, its role is to authenticate users,
based on a security token that is issued by a federation server in the resource partner organization, or its role is to
redirect token requests from configured Web applications or Web services to the account partner organization that
the client belongs to. For more information, see Review the Role of the Federation Server in the Resource Partner.
Determine which AD FS design to deploy

You create federation servers in your organization whenever you want to deploy any of the following AD FS
designs:
Web SSO Design
Federated Web SSO Design
If necessary, an organization that deploys a Federated Web SSO design can configure a single federation server so
that it acts in both the account partner role and in the resource partner role. In this case, the federation server may
produce Security Assertion Markup Language (SAML ) tokens, based on user accounts in its own organization, or
reroute token requests to the organization, based on where the users' accounts reside.
NOTE
For the Federated Web SSO design, there must be at least one federation server in the account partner and at least one
federation server in the resource partner.
Differences between a federation server and a federation server proxy
A federation server can serve out Web pages for sign-in, policy, authentication, and discovery in the same way that
a federation server proxy does. The primary differences between a federation server and a federation server proxy
have to do with what operations a federation server can perform that a federation server proxy cannot perform.
The following are the operations that only a federation server can perform:
The federation server performs the cryptographic operations that produce the token. Although federation
server proxies cannot produce tokens, they can be used to route or redirect the tokens to clients and, when
necessary, back to the federation server. For more information about using federation servers, see When to
Create a Federation Server Proxy.
Federation servers support the use of Windows Integrated Authentication for clients on the corporate
network; federation server proxies do not. For more information about using Windows Integrated
Authentication with federation server, see When to Create a Federation Server Farm.
Cau t i on
Communication between federation servers and SQL Server configuration databases, SQL Server attribute stores,
domain controllers, and AD LDS instances is not integrity or confidentiality protected by default. To mitigate this,
consider protecting the communication channel between these servers using IPSEC or using a physically secure
connection between all of these servers. For communication between federation servers and SQL servers, consider
using SSL protection in the connection string. For connections between federation servers and domain controllers,
consider turning on Kerberos signing and encryption. For LDAP, LDAP/S is not supported for AD LDS/AD DS.
How to create a federation server

You can create a federation server using the AD FS Federation Server Configuration Wizard or the Fsconfig.exe
command-line tool. When you use either of these tools, you can select any of the following options to create a
federation server.
Create a stand-alone federation server
For more information about how to set up a stand-alone federation server, see Create a Stand-Alone
Federation Server.
Create the first federation server in a federation server farm
For more information about how to set up the first federation server or add a federation server to a farm,
see Create the First Federation Server in a Federation Server Farm.
Add a federation server to a federation server farm
For more information about how to add a federation server to a farm, see Add a Federation Server to a
Federation Server Farm.
For more detailed information about how each of these options work, see The Role of the AD FS Configuration
Database.
For more information about how to set up all the prerequisites necessary to deploy a federation server, see
Checklist: Setting Up a Federation Server.
See Also
As a security best practice, place Active Directory Federation Services (AD FS )federation servers in front of a
firewall and connect them to your corporate network to prevent exposure from the Internet. This is important
because federation servers have full authorization to grant security tokens. Therefore, they should have the same
protection as a domain controller. If a federation server is compromised, a malicious user has the ability to issue full
access tokens to all Web applications and to federation servers that are protected by Active Directory Federation
Services (AD FS ) in all resource partner organizations.
NOTE
As a security best practice, avoid having your federation servers directly accessible on the Internet. Consider giving your
federation servers direct Internet access only when you are setting up a test lab environment or when your organization does
not have a perimeter network.
For typical corporate networks, an intranet-facing firewall is established between the corporate network and the
perimeter network, and an Internet-facing firewall is often established between the perimeter network and the
Internet. In this situation, the federation server sits inside the corporate network, and it is not directly accessible by
Internet clients.
NOTE
Client computers that are connected to the corporate network can communicate directly with the federation server through
A federation server proxy should be placed in the perimeter network before you configure your firewall servers for
use with AD FS. For more information, see Where to Place a Federation Server Proxy.
Configuring your firewall servers for a federation server

So that the federation servers can communicate directly with federation server proxies, the intranet firewall server
must be configured to allow Secure Hypertext Transfer Protocol (HTTPS ) traffic from the federation server proxy to
the federation server. This is a requirement because the intranet firewall server must publish the federation server
using port 443 so that the federation server proxy in the perimeter network can access the federation server.
In addition, the intranet-facing firewall server, such as a server running Internet Security and Acceleration (ISA)
Server, uses a process known as server publishing to distribute Internet client requests to the appropriate corporate
federation servers. This means that you must manually create a server publishing rule on the intranet server
running ISA Server that publishes the clustered federation server URL, for example, http://fs.fabrikam.com.
For more information about how to configure server publishing in a perimeter network, see Where to Place a
Federation Server Proxy. For information about how to configure ISA Server to publish a server, see Create a
secure Web publishing rule.
See Also
When to Create a Federation Server Farm
Consider creating a federation server farm in Active Directory Federation Services (AD FS ) when you have a larger
AD FS deployment and you want to provide fault tolerance, load-balancing, or scalability to your organization's
Federation Service. The act of creating two or more federation servers in the same network, configuring each of
them to use the same Federation Service, and adding the public key of each server's token-signing certificates to
the AD FS Management snap-in creates a federation server farm.
You can create a federation server farm or install additional federation servers to an existing farm by using the AD
FS Federation Server Configuration Wizard. For more information, see When to Create a Federation Server.
NOTE
When you choose the option to create a New federation server farm using the AD FS Federation Server Configuration
Wizard, the wizard will attempt to create a container object (for sharing certificates) in Active Directory. Therefore, it is
important that you first log on to the computer, where you are setting up the federation server role, with an account that has
sufficient permissions in Active Directory to create this container object.
Before federation servers can be grouped as a farm, they must first be clustered so that requests that arrive at a
single fully qualified domain name (FQDN ) are routed to the various federation servers in the server farm. You can
create the server cluster by deploying Network Load Balancing (NLB ) inside the corporate network. This guide
assumes that NLB has been configured appropriately to cluster each of the federation servers in the farm.
For more information about how to configure a cluster FQDN using Microsoft NLB technology, see Specifying the
Cluster Parameters.
Best practices for deploying a federation server farm

We recommend the following best practices for deploying a federation server in a production environment:
If you will be deploying multiple federation servers at the same time or you know that you will be adding
more servers to the farm over time, consider creating a server image of an existing federation server in the
farm and then installing from that image when you need to create additional federation servers quickly.
NOTE
If you do decide to use the server image method for deploying additional federation servers, you do not have to
complete the tasks in Checklist: Setting Up a Federation Server every time that you want to add a new server to the
farm.
Use NLB or some other form of clustering to allocate a single IP address for many federation server
computers.
Reserve a static IP address for each federation server in the farm and, depending on your Domain Name
System (DNS ) configuration, insert an exclusion for each IP address in Dynamic Host Configuration
Protocol (DHCP ). Microsoft NLB technology requires that each server that participates in the NLB cluster be
assigned a static IP address.
If the AD FS configuration database will be stored in a SQL database, avoid editing the SQL database from
multiple federation servers at the same time.
Configuring federation servers for a farm

The following table describes the tasks that must be completed so that each federation server can participate in a
farmed environment.
TASK DESCRIPTION
If you are using SQL Server to store the AD FS configuration A federation server farm consists of two or more federation
database servers that share the same AD FS configuration database and
token-signing certificates. The configuration database can be
stored in either Windows Internal Database or in a SQL Server
database. If you plan to store the configuration database in a
SQL database, make sure that the configuration database is
accessible so that it can be accessed by all new federation
servers that participate in the farm. Note: For farm scenarios,
it is important that the configuration database be located on a
computer that does not also participate as a federation server
in that farm. Microsoft NLB does not allow any of the
computers that participate in a farm to communicate with one
another. Note: Ensure that the identity of the AD FS AppPool
in Internet Information Services (IIS)) on every federation
server that participates in the farm has Read access to the
Obtain and share certificates You can obtain a single server authentication certificate from a
public certification authority (CA)—for example, VeriSign. You
can then configure the certificate so that all federation servers
share the same private key portion of the certificate. For more
information about how to share the same certificate, see
Checklist: Setting Up a Federation Server. Note: The AD FS
Management snap-in refers to server authentication
certificates for federation servers as service communication
certificates.
For more information, see Certificate Requirements for

Federation Servers.
Point to the same SQL Server instance If the AD FS configuration database will be stored in a SQL
database, the new federation server must point to the same
SQL Server instance that is used by other federation servers in
the farm so that the new server can participate in the farm.
See Also
In any Active Directory Federation Services (AD FS ) design, various certificates must be used to secure
communication and facilitate user authentications between Internet clients and federation servers. Each federation
server must have a service communication certificate and a token-signing certificate before it can participate in AD
FS communications. The following table describes the certificate types that are associated with federation server.
CERTIFICATE TYPE DESCRIPTION
Token-signing certificate A token-signing certificate is an X509 certificate. Federation

servers use associated public/private key pairs to digitally sign
all security tokens that they produce. This includes the signing
of published federation metadata and artifact resolution
requests.
You can have multiple token-signing certificates configured in

the AD FS Management snap-in to allow for certificate rollover
when one certificate is close to expiring. By default, all the
certificates in the list are published, but only the primary
token-signing certificate is used by AD FS to actually sign
tokens. All certificates that you select must have a
corresponding private key.
For more information, see Token-Signing Certificates and Add

a Token-Signing Certificate.
Service communication certificate Federation servers use a server authentication certificate, also
known as a service communication for Windows
Communication Foundation (WCF) Message Security. By
default, this is the same certificate that a federation server
uses as the Secure Sockets Layer (SSL) certificate in Internet
Information Services (IIS). Note: The AD FS Management
snap-in refers to server authentication certificates for
federation servers as service communication certificates.
For more information, see Service Communications Certificates

and Set a Service Communications Certificate.
Because the service communication certificate must be trusted

by client computers, we recommend that you use a certificate
that is signed by a trusted certification authority (CA). All
certificates that you select must have a corresponding private
key.
Secure Sockets Layer (SSL) certificate Federation servers use an SSL certificate to secure Web
services traffic for SSL communication with Web clients and
with federation server proxies.
Because the SSL certificate must be trusted by client

computers, we recommend that you use a certificate that is
signed by a trusted CA. All certificates that you select must
have a corresponding private key.
CERTIFICATE TYPE DESCRIPTION
Token-decryption certificate This certificate is used to decrypt tokens that are received by
this federation server.
You can have multiple decryption certificates. This makes it

possible for a resource federation server to be able to decrypt
tokens that are issued with an older certificate after a new
certificate is set as the primary decryption certificate. All
certificates can be used for decryption, but only the primary
token-decrypting certificate is actually published in federation
metadata. All certificates that you select must have a
corresponding private key.
For more information, see Add a Token-Decrypting Certificate.
You can request and install an SSL certificate or service communication certificate by requesting a service
communication certificate through the Microsoft Management Console (MMC ) snap-in for IIS. For more general
information about using SSL certificates, see IIS 7.0: Configuring Secure Sockets Layer in IIS 7.0 and IIS 7.0:
Configuring Server Certificates in IIS 7.0 .
NOTE
In AD FS you can change the Secure Hash Algorithm (SHA) level that is used for digital signatures to either SHA-1 or SHA-
256 (more secure). AD FSdoes not support the use of certificates with other hash methods, such as MD5 (the default hash
algorithm that is used with the Makecert.exe command-line tool). As a security best practice, we recommend that you use
SHA-256 (which is set by default) for all signatures. SHA-1 is recommended for use only in scenarios in which you must
interoperate with a product that does not support communications using SHA-256, such as a non-Microsoft product or AD
FS 1. x.
Determining your CA strategy

AD FS does not require that certificates be issued by a CA. However, the SSL certificate (the certificate that is also
used by default as the service communications certificate) must be trusted by the AD FS clients. We recommend
that you not use self-signed certificates for these certificate types.
IMPORTANT
Use of self-signed, SSL certificates in a production environment can allow a malicious user in an account partner organization
to take control of federation servers in a resource partner organization. This security risk exists because self-signed certificates
are root certificates. They must be added to the trusted root store of another federation server (for example, the resource
federation server), which can leave that server vulnerable to attack.
After you receive a certificate from a CA, make sure that all certificates are imported into the personal certificate
store of the local computer. You can import certificates to the personal store with the Certificates MMC snap-in.
As an alternative to using the Certificates snap-in, you can also import the SSL certificate with the IIS Manager
snap-in at the time that you assign the SSL certificate to the default Web site. For more information, see Import a
Server Authentication Certificate to the Default Web Site.
NOTE
Before you install the AD FS software on the computer that will become the federation server, make sure that both certificates
are in the Local Computer personal certificate store and that the SSL certificate is assigned to the Default Web Site. For more
information about the order of the tasks that are required to set up a federation server, see Checklist: Setting Up a Federation
Server.
Depending on your security and budget requirements, carefully consider which of your certificates will be obtained
by a public CA or a corporate CA. The following figure shows the recommended CA issuers for a given certificate
type. This recommendation reflects a best-practice approach regarding security and cost.
Certificate revocation lists

If any certificate that you use has CRLs, the server with the configured certificate must be able to contact the server
that distributes the CRLs.
See Also
Token-Signing Certificates
Federation servers require token-signing certificates to prevent attackers from altering or counterfeiting security
tokens in an attempt to gain unauthorized access to federated resources. The private/public key pairing that is used
with token-signing certificates is the most important validation mechanism of any federated partnership because
these keys verify that a security token was issued by a valid partner federation server and that the token was not
modified during transit.
Token-signing certificate requirements

A token-signing certificate must meet the following requirements to work with AD FS:
For a token-signing certificate to successfully sign a security token, the token-signing certificate must
contain a private key.
The AD FS service account must have access to the token-signing certificate’s private key in the personal
store of the local computer. This is taken care of by Setup. You can also use the AD FS Management snap-in
to ensure this access if you subsequently change the token-signing certificate.
NOTE
It is a public key infrastructure (PKI) best practice to not share the private key for multiple purposes. Therefore, do not use the
service communication certificate that you installed on the federation server as the token-signing certificate.
How token-signing certificates are used across partners

Every token-signing certificate contains cryptographic private keys and public keys that are used to digitally sign
(by means of the private key) a security token. Later, after they are received by a partner federation server, these
keys validate the authenticity (by means of the public key) of the encrypted security token.
Because each security token is digitally signed by the account partner, the resource partner can verify that the
security token was in fact issued by the account partner and that it was not modified. Digital signatures are verified
by the public key portion of a partner’s token-singing certificate. After the signature is verified, the resource
federation server generates its own security token for its organization and it signs the security token with its own
token-signing certificate.
For federation partner environments, when the token-signing certificate has been issued by a CA, ensure that:
1. The certificate revocation lists (CRLs) of the certificate are accessible to relying parties and Web servers that
trust the federation server.
2. The root CA certificate is trusted by the relying parties and Web servers that trust the federation server.
The Web server in the resource partner uses the public key of the token-signing certificate to verify that the
security token is signed by the resource federation server. The Web server then allows the appropriate access to the
client.
Deployment considerations for token-signing certificates

When you deploy the first federation server in a new AD FS installation, you must obtain a token-signing certificate
and install it in the local computer personal certificate store on that federation server. You can obtain a token-
signing certificate by requesting one from an enterprise CA or a public CA or by creating a self-signed certificate.
When you deploy an AD FS farm, token-signing certificates are installed differently, depending on how you create
the server farm.
There are two server farm options that you can consider when you obtain token-signing certificates for your
deployment:
A private key from one token-signing certificate is shared among all the federation servers in a farm.
In a federation server farm environment, we recommend that all federation servers share (or reuse) the
same token-signing certificate. You can install a single token-signing certificate from a CA on a federation
server and then export the private key, as long as the issued certificate is marked as exportable.
As shown in the following illustration, the private key from a single token-signing certificate can be shared to
all the federation servers in a farm. This option—compared to the following "unique token-signing
certificate" option—reduces costs if you plan to obtain a token-signing certificate from a public CA.
There is a unique token-signing certificate for each federation server in a farm.

When you use multiple, unique certificates throughout your farm, each server in that farm signs tokens with
its own unique private key.
As shown in the following illustration, you can obtain a separate token-signing certificate for every single
federation server in the farm. This option is more expensive if you plan to obtain your token-signing
certificates from a public CA.
For information about installing a certificate when you use Microsoft Certificate Services as your enterprise CA, see
IIS 7.0: Create a Domain Server Certificate in IIS 7.0.
For information about installing a certificate from a public CA, see IIS 7.0: Request an Internet Server Certificate.
For information about installing a self-signed certificate, see IIS 7.0: Create a Self-Signed Server Certificate in IIS
7.0.
See Also
Service Communications Certificates
A federation server requires the use of service communication certificates for scenarios in which WCF message
security is used.
Service communication certificate requirements

Service communication certificates must meet the following requirements to work with AD FS:
The service communication certificate must include the server authentication enhanced key usage (EKU )
extension.
The certificate revocation lists (CRLs) must be accessible for all the certificates in the chain from the service
communication certificate to the root CA certificate. The root CA must also be trusted by any federation
server proxies and Web servers that trust this federation server.
The subject name that is used in the service communication certificate must match the Federation Service
name in the properties of the Federation Service.
Deployment considerations for service communication certificates

Configure service communication certificates so that all federation servers use the same certificate. If you are
deploying the Federated Web Single-Sign-On (SSO ) design, we recommend that your service communication
certificate be issued by a public CA. You can request and install these certificates through the IIS Manager snap-in.
You can use self-signed, service communication certificates successfully on federation servers in a test lab
environment. However, for a production environment, we recommend that you obtain service communication
certificates from a public CA. The following are reasons why you should not use self-signed, service
communication certificates for a live deployment:
A self-signed, SSL certificate must be added to the trusted root store on each of the federation servers in the
resource partner organization. While this alone does not enable an attacker to compromise a resource
federation server, trusting self-signed certificates does increase the attack surface of a computer, and it can
lead to security vulnerabilities if the certificate signer is not trustworthy.
It creates a bad user experience. Clients will receive Security Alert prompts when they try to access federated
resources that display the following message: "The security certificate was issued by a company you have
not chosen to trust." This is expected behavior, because the self-signed certificate is not trusted.
NOTE
If necessary, you can work around this condition by using Group Policy to manually push down the self-signed
certificate to the trusted root store on each client computer that will attempt to access an AD FS site.
CAs provide additional certificate-based features, such as private key archive, renewal, and revocation, that
are not provided by self-signed certificates.
Name Resolution Requirements for Federation
Servers
When client computers on the corporate network attempt to access an application or Web service that is protected
by Active Directory Federation Services (AD FS ), they must first authenticate to a federation server. One way to
authenticate is to have the corporate network clients access a local federation server through Windows Integrated
Authentication.
Configure corporate DNS

So that successful name resolution through Windows Integrated Authentication on local federation servers can
occur, Domain Name System (DNS ) in the corporate network of the account partner must be configured for a new
host (A) resource record that will resolve the fully qualified domain name (FQDN ) host name of the federation
server to the IP address of the federation server cluster.
In the following illustration, you can see how this task is accomplished for a given scenario. In this scenario,
Microsoft Network Load Balancing (NLB ) provides a single cluster FQDN name and a single cluster IP address for
an existing federation server farm.
For information about how to configure a cluster IP address or cluster FQDN using NLB, see Specifying the
Cluster Parameters.
For information about how to configure corporate DNS for a federation server, see Add a Host (A) Resource
Record to Corporate DNS for a Federation Server.
For information about how to configure federation server proxies in the perimeter network, see Name Resolution
See Also
After you gather all the information that you will use to design your Active Directory Federation Services (AD FS )
infrastructure and after you plan your federation server and Web server strategy, you can plan when and where to
place federation server proxies in your new design. The information in the following topics can help you determine
when and where to place a federation server proxy and whether to configure it for the account partner role or the
resource partner role:
Review the Role of the Federation Server Proxy in the Resource Partner
When to Create a Federation Server Proxy
Where to Place a Federation Server Proxy
When to Create a Federation Server Proxy Farm
Certificate Requirements for Federation Server Proxies
Name Resolution Requirements for Federation Server Proxies
NOTE
Although this information might help with your placement planning for federation server proxies, it does not explain how to
determine the proper number of proxies and the proxy hardware requirements for each AD FS design.
For examples of how you can place a federation server proxy in either of the two primary AD FS design scenarios,
see Mapping Your Deployment Goals to an AD FS Design.
See Also
When to Create a Federation Server Proxy
Creating a federation server proxy in your organization adds additional security layers to your Active Directory
Federation Services (AD FS ) deployment. Consider deploying a federation server proxy in your organization's
perimeter network when you want to:
Prevent external client computers from directly accessing your federation servers. By deploying a federation
server proxy in your perimeter network, you effectively isolate your federation servers so that they can be
accessed only by client computers that are logged in to the corporate network through federation server
proxies, which act on behalf of the external client computers. Federation server proxies do not have access to
the private keys that are used to produce tokens. For more information, see Where to Place a Federation
Server Proxy.
Provide a convenient way to differentiate the sign-in experience for users who are coming from the Internet
as opposed to users who are coming from your corporate network using Windows Integrated
Authentication. A federation server proxy collects credentials or home realm details from Internet client
computers by using the logon, logout, and identity provider discovery (homerealmdiscovery.aspx) pages that
are stored on the federation server proxy.
In contrast, client computers that come from the corporate network encounter a different experience, based
on the configuration of the federation server. The corporate network federation server is often configured for
Windows Integrated Authentication, which provides a seamless sign-in experience for users on the
corporate network.
The role that a federation server proxy plays in your organization depends on whether you place the federation
server proxy in the account partner organization or in the resource partner organization. For example, when a
federation server proxy is placed in the perimeter network of the account partner, its role is to collect the user
credential information from browser clients. When a federation server proxy is placed in the perimeter network of
the resource partner, it relays security token requests to a resource federation server and produces organizational
security tokens in response to the security tokens that are provided by its account partners.
For more information, see Review the Role of the Federation Server Proxy in the Account Partner and Review the
Role of the Federation Server Proxy in the Resource Partner
How to create a federation server proxy

You can create a federation server proxy using either the AD FS Federation Server Proxy Configuration Wizard or
the Fsconfig.exe command-line tool. For instructions about how to do this, see Configure a Computer for the
Federation Server Proxy Role.
For general information about how to set up all the prerequisites necessary to deploy a federation server proxy, see
Checklist: Setting Up a Federation Server Proxy.
See Also
Where to Place a Federation Server Proxy
You can place Active Directory Federation Services (AD FS )federation server proxies in a perimeter network to
provide a protection layer against malicious users that may be coming from the Internet. Federation server proxies
are ideal for the perimeter network environment because they do not have access to the private keys that are used
to create tokens. However, federation server proxies can efficiently route incoming requests to federation servers
that are authorized to produce those tokens.
It is not necessary to place a federation server proxy inside the corporate network for either the account partner or
the resource partner because client computers that are connected to the corporate network can communicate
directly with the federation server. In this scenario, the federation server also provides federation server proxy
functionality for client computers that are coming from the corporate network.
As is typical with perimeter networks, an intranet-facing firewall is established between the perimeter network and
the corporate network, and an Internet-facing firewall is often established between the perimeter network and the
Internet. In this scenario, the federation server proxy sits between both of these firewalls on the perimeter network.
Configuring your firewall servers for a federation server proxy

For the federation server proxy redirection process to be successful, all firewall servers must be configured to allow
Secure Hypertext Transfer Protocol (HTTPS ) traffic. The use of HTTPS is required because the firewall servers must
publish the federation server proxy, using port 443, so that the federation server proxy in the perimeter network
can access the federation server in the corporate network.
NOTE
All communications to and from client computers also occur over HTTPS.
In addition, the Internet-facing firewall server, such as a computer running Microsoft Internet Security and
Acceleration (ISA) Server, uses a process known as server publishing to distribute Internet client requests to the
appropriate perimeter and corporate network servers, such as federation server proxies or federation servers.
Server publishing rules determine how server publishing works—essentially, filtering all incoming and outgoing
requests through the ISA Server computer. Server publishing rules map incoming client requests to the appropriate
servers behind the ISA Server computer. For information about how to configure ISA Server to publish a server,
see Create a Secure Web Publishing Rule.
In the federated world of AD FS, these client requests are typically made to a specific URL, for example, a
federation server identifier URL such as http://fs.fabrikam.com. Because these client requests come in from the
Internet, the Internet-facing firewall server must be configured to publish the federation server identifier URL for
each federation server proxy that is deployed in the perimeter network.
Configuring ISA Server to allow SSL
To facilitate secure AD FS communications, you must configure ISA Server to allow Secure Sockets Layer (SSL )
communications between the following:
Federation servers and federation server proxies. An SSL channel is required for all communications
between federation servers and federation server proxies. Therefore, you must configure ISA Server to allow
an SSL connection between the corporate network and the perimeter network.
Client computers, federation servers, and federation server proxies. So that communications can
occur between client computers and federation servers or between client computers and federation server
proxies, you can place a computer running ISA Server in front of the federation server or federation server
proxy.
If your organization performs SSL client authentication on the federation server or federation server proxy,
when you place a computer running ISA Server in front of the federation server or federation server proxy,
the server must be configured for pass-through of the SSL connection because the SSL connection must
terminate at the federation server or federation server proxy.
If your organization does not perform SSL client authentication on the federation server or federation server
proxy, an additional option is to terminate the SSL connection at the computer running ISA Server and then
re-establish an SSL connection to the federation server or federation server proxy.
NOTE
The federation server or federation server proxy requires that the connection be secured by SSL to protect the contents of
the security token.
See Also
When to Create a Federation Server Proxy Farm
Consider installing additional federation server proxies when you have a large Active Directory Federation Services
(AD FS ) deployment and you want to provide fault tolerance, load-balancing, and scalability for your proxy
deployment. The act of creating two or more federation server proxies in the same perimeter network and
configuring each of them to protect the same AD FS Federation Service creates a federation server proxy farm.
You can create a federation server proxy farm or install additional federation server proxies to an existing farm by
using the AD FS Federation Server Proxy Configuration Wizard. For more information, see When to Create a
Federation Server Proxy.
Before all the federation server proxies can function together as a farm, you must first cluster them under one IP
address and one Domain Name System (DNS ) fully qualified domain name (FQDN ). You can cluster the servers by
deploying Microsoft Network Load Balancing (NLB ) inside the perimeter network. The tasks in the following table
require NLB to be configured appropriately to cluster the federation server proxies in the farm.
For more information about how to configure an FQDN for a cluster using Microsoft NLB technology, see
Specifying the Cluster Parameters.
Configuring federation server proxies for a farm

The following table describes the tasks that must be completed so that each federation server proxy can participate
in a farm.
TASK DESCRIPTION
Point all proxies in the farm to the same AD FS Federation When you create the federation server proxies, you must type
Service name the same Federation Service name in the AD FS Federation
Server Proxy Configuration Wizard for all the federation server
proxies that will participate in the farm. The federation server
proxy uses the URL that makes up this DNS host name to
determine which AD FS Federation Service instance it contacts.
For more information, see Configure a Computer for the

Federation Server Proxy Role.
Obtain and share certificates You can obtain a server authentication certificate from a public
certification authority (CA)—for example, VeriSign—and then
configure the certificate so that all federation server proxies
share the same private key portion of the same certificate on
the default Web site for each federation server proxy. To share
the certificate, you must install the same server authentication
certificate on the default Web site for each federation server
proxy. For more information, see Import a Server
Authentication Certificate to the Default Web Site.
For more information, see Certificate Requirements for

Federation Server Proxies.
For more information about adding new federation server proxies to create a federation server proxy farm, see
See Also
Certificate Requirements for Federation Server
Proxies
Servers that are running in the federation server proxy role in Active Directory Federation Services (AD FS ) are
required to use Secure Sockets Layer (SSL ) server authentication certificates. Federation server proxies use SSL
server authentication certificates to secure Web server traffic communication with Web clients.
Federation server proxies are usually exposed to computers on the Internet that are not included in your enterprise
public key infrastructure (PKI). Therefore, use a server authentication certificate that is issued by a public (third-
party) certification authority (CA), for example, VeriSign.
When you have a federation server proxy farm, all federation server proxy computers must use the same server
authentication certificate. For more information, see When to Create a Federation Server Proxy Farm.
It is important to verify that the subject name in the server authentication certificate matches the Federation
Service name value that is specified in the AD FS Management snap-in. To locate this value, open the snap-in,
right-click Service, click Edit Federation Service Properties, and then find the value in Federation Service
name text box.
For general information about using SSL certificates, see Configuring Secure Sockets Layer in IIS 7.0
(http://go.microsoft.com/fwlink/?LinkID=108544) and Configuring Server Certificates in IIS 7.0
(http://go.microsoft.com/fwlink/?LinkID=108545).
NOTE
Client authentication certificates are not required for AD FS federation server proxies.
If any certificate that you use has certificate revocation lists (CRLs), the server with the configured certificate must
be able to contact the server that distributes the CRLs. The type of CRL determines what ports are used.
See Also
Name Resolution Requirements for Federation Server
Proxies
When client computers on the Internet attempt to access an application that is secured by Active Directory
Federation Services (AD FS ), they must first authenticate to the federation server. In most cases, the federation
server is usually not directly accessible from the Internet. Therefore, Internet client computers must be redirected to
the federation server proxy instead. You can accomplish successful redirection by adding the appropriate Domain
Name System (DNS ) records to your DNS zone or zones that face the Internet.
The method that you use to redirect Internet clients to the federation server proxy depends on how you configure
the DNS zone in your perimeter network or how you configure a DNS zone that you control on the Internet.
Federation server proxies are intended for use in a perimeter network. They redirect Internet client requests to
federation servers successfully only when DNS has been configured properly in all the Internet-facing zones that
you control. Therefore, the configuration of your Internet-facing zones—whether you have a DNS zone serving
only the perimeter network or a DNS zone serving both the perimeter network and Internet clients—is important.
This topic describes the steps that you can take to configure name resolution when you place a federation server
proxy in your perimeter network. To determine which steps to follow, first determine which of the following DNS
scenarios most closely matches the DNS infrastructure in the perimeter network of your organization. Then, follow
the steps for that scenario.
DNS zone serving only the perimeter network

In this scenario, your organization has one or two DNS zones in the perimeter network, and your organization does
not control any DNS zones on the Internet. Successful name resolution for a federation server proxy in the DNS
zone that serves only the perimeter network scenario depends on the following conditions:
The federation server proxy must have a setting in the hosts file to resolve the fully qualified domain name
(FQDN ) of the federation server endpoint URL to an IP address of a federation server or a federation server
cluster.
DNS in the perimeter network of the account partner must be configured so that the FQDN of the
federation server endpoint URL resolves to the IP address of the federation server proxy.
The following illustration and corresponding steps show how each of these conditions is achieved for a given
example. In this illustration, Microsoft Network Load Balancing (NLB ) technology provides a single, cluster FQDN
and a single, cluster IP address for an existing federation server farm.
For more information about configuring a cluster IP address or a cluster FQDN using NLB, see Specifying the
Cluster Parameters.
1. Configure the hosts file on the federation server proxy
Because DNS in the perimeter network is configured to resolve all requests for fs.fabrikam.com to the account
federation server proxy, the account partner federation server proxy has an entry in its local hosts file to resolve
fs.fabrikam.com to the IP address of the actual account federation server (or cluster DNS name for the federation
server farm) that is connected to the corporate network. This makes it possible for the account federation server
proxy to resolve the host name fs.fabrikam.com to the account federation server rather than to itself—as would
occur if it attempted to look up fs.fabrikam.com using perimeter DNS —so that the federation server proxy can
communicate with the federation server.
2. Configure perimeter DNS
Because there is only a single AD FS host name that client computers are directed to—whether they are on an
intranet or on the Internet—client computers on the Internet that use the perimeter DNS server must resolve the
FQDN for the account federation server (fs.fabrikam.com) to the IP address of the account federation server proxy
on the perimeter network. So that it can forward clients on to the account federation server proxy when they
attempt to resolve fs.fabrikam.com, perimeter DNS contains a limited corp.fabrikam.com DNS zone with a single
host (A) resource record for fs (fs.fabrikam.com) and the IP address of the account federation server proxy on the
perimeter network.
For more information about how to modify the hosts file of the federation server proxy and configure DNS in the
perimeter network, see Configure Name Resolution for a Federation Server Proxy in a DNS Zone That Serves
Only the Perimeter Network.
DNS zone serving both the perimeter network and Internet clients
In this scenario, your organization controls the DNS zone in the perimeter network and at least one DNS zone on
the Internet. Successful name resolution for a federation server proxy in this scenario depends on the following
conditions:
DNS in the Internet zone of the account partner must be configured so that the FQDN of the federation
server host name resolves to the IP address of the federation server proxy in the perimeter network.
DNS in the perimeter network of the account partner must be configured so that the FQDN of the
federation server host name resolves to the IP address of the federation server in the corporate network.
The following illustration and corresponding steps show how each of these conditions is achieved for a given
example.
1. Configure perimeter DNS

For this scenario, because it is assumed that you will configure the Internet DNS zone that you control to resolve
requests that are made for a specific endpoint URL (that is, fs.fabrikam.com) to the federation server proxy in the
perimeter network, you must also configure the zone in the perimeter DNS to forward these requests to the
federation server in the corporate network.
So that clients can be forwarded to the account federation server when they attempt to resolve fs.fabrikam.com,
perimeter DNS is configured with a single host (A) resource record for fs (fs.fabrikam.com) and the IP address of
the account federation server on the corporate network. This makes it possible for the account federation server
proxy to resolve the host name fs.fabrikam.com to the account federation server rather than to itself—as would
occur if it attempted to look up fs.fabrikam.com using Internet DNS —so that the federation server proxy can
communicate with the federation server.
2. Configure Internet DNS
For name resolution to be successful in this scenario, all requests from client computers on the Internet to
fs.fabrikam.com must be resolved by the Internet DNS zone that you control. Consequently, you must configure
your Internet DNS zone to forward client requests for fs.fabrikam.com to the IP address of the account federation
server proxy in the perimeter network.
For more information about how to modify the perimeter network and Internet DNS zones, see Configure Name
Resolution for a Federation Server Proxy in a DNS Zone That Serves Both the Perimeter Network and Internet
Clients.
See Also
NOTE
The content provided in this topic does not reflect actual testing that was performed on servers running Windows Server
2012 . This topic will be updated once the required testing has been performed.
Capacity planning for Active Directory Federation Services (AD FS ) is the process of forecasting peak usage
periods for your Federation Service and planning or scaling-up your AD FS server deployment to meet those load
requirements.
This section describes deployment guidelines for both the federation server and federation server proxy roles and
is based on lab testing that was performed by the AD FS product team at Microsoft. The purpose of this content is
to help you:
Closely estimate the hardware needs for your organization’s specific AD FS deployment, such as the number
of AD FS servers.
Accurately project the expected peak usage for sign-in requests, plan for growth, and ensure that your AD
FS deployment is capable of handling that expected peak usage.
Before you proceed with reading this capacity planning content, we recommend that you first complete the tasks in
the order shown in the following two tables. In the first table, we provide links to recommended tasks that will help
provide relevant context for this capacity planning discussion.
Understand the requirements for Review important hardware and Appendix A: Reviewing AD FS
deploying AD FS federation servers and software requirements necessary for Requirements
federation server proxies deploying federation server and
federation server proxies.
Select the type of AD FS configuration Before you can begin using capacity The Role of the AD FS Configuration
database that you will deploy in your planning data in this section, you first Database;
organization have to determine which AD FS
configuration database type you will AD FS Deployment Topology
deploy, either Windows Internal Considerations
Database (WID) or a Structured Query
Language (SQL) database.
Determine the type of topology layout Once you have decided on the type of Determine Your AD FS Deployment
to use with your new AD FS AD FS configuration database to use in Topology
configuration database selection your deployment, you will need to
consider which deployment topology
most closely matches where you will
need to place federation servers and
federation server proxies within your
production environment.
Understand key AD FS–related capacity Review the definitions of common See the section titled AD FS capacity
planning terms capacity planning terms that are used planning terms in this topic
throughout the AD FS capacity planning
discussion.
Once you have reviewed the content in the previous table, you can now complete the prerequisite tasks in the next
table.
PREREQUISITE TASK DESCRIPTION REFERENCE
Download the AD FS Capacity Planning The AD FS Capacity Planning Sizing AD FS Capacity Planning Spreadsheet
Sizing Spreadsheet spreadsheet can help you to determine
the number of federation servers
required for an AD FS federation server
farm deployment. Instructions for how
to use this spreadsheet are available in
the link provided below for the next
task.
Gather data about the number of users This user data you collect will be used Estimate the number of federation
who will require single sign-on (SSO) for the input values required within the servers for your organization
access to the target claims-aware context of the AD FS Capacity Planning
application and the expected peak Sizing Spreadsheet.
usage periods associated with this
access
AD FS Capacity Planning Spreadsheet Updated Planning worksheet for AD FS Windows Server 2016 Capacity
for Windows Server 2016 Windows Server 2016 Planning
AD FS capacity planning terms

The following table describes important terms that are used often in this capacity planning section of the AD FS
Design Guide. For a more complete list of AD FS terms, see Understanding Key AD FS Concepts.
TERM DEFINITION
Concurrent users The estimated number of users that are expected to submit
requests to the service within a given period of time, usually a
peak activity period.
Active users The approximate average number of users that are active on a
system, but not necessarily submitting requests, during a
given period of time.
Defined users A theoretical maximum user count, usually based on the

number of users who have defined accounts in the system.
Requests per second The number of requests either submitted by clients (when
talking about the load on a system) or processed by servers
(when talking about server throughput) in a second. This
metric is used in planning server processor and memory
capacity.
TERM DEFINITION
Target server responsiveness and utilization Success metrics that bound the acceptable server performance
range. Generally, if responsiveness goes below or utilization
goes above the target, the system is considered to be
overloaded and more capacity is required.
Windows Internal Database (WID) The default AD FS configuration database that can be used as
an alternative to SQL Server in certain AD FS deployments.
Configuration environment used during AD FS testing

This section describes the configuration environment that the AD FS product team used to perform its tests. The
team used the following computer hardware, software, and network configuration to gather performance and
scalability data in tests of the federation server:
Dual Quad Core 2.27 gigahertz (GHz) (8 cores)
16-GB RAM
Windows Server 2008 R2, Enterprise Edition
Gigabit Network
NOTE
Although 16 GB’s of RAM was used on the federation server during testing, a more moderate memory size, such as 4 GB’s of
RAM per federation server can be used for most AD FS deployments. The recommendations that are provided in this AD FS
Capacity Planning content along with the results provided by the AD FS Capacity Planning Spreadsheet are based on
assumptions that each federation server will use approximately 4GB’s of RAM for most AD FS production environments.
The product team used the following configuration to gather performance and scalability data for the federation
server proxy testing:
Dual Quad Core 2.24 GHz (4 cores)
4-GB RAM
Windows Server 2008 R2, Enterprise Edition
Gigabit Network
NOTE
Capacity recommendations for AD FS servers can vary considerably, depending on the specifications you choose for the
hardware and network configuration to be used in a given environment. As a point of reference, the sizing guidance provided
in this content is based on a utilization target of 80 percent on the computers mentioned earlier.
Measure AD FS server capacity

Typically, the hardware components that affect server performance and scalability are the CPU, memory, the disk,
and network adapters. Fortunately, each of the AD FS components requires very little demand on memory and
disk space. Network connectivity is an obvious requirement. Therefore, load tests that are performed on federation
servers and federation server proxies concentrate on two primary areas for measuring server capacity:
Peak AD FS requests per second: The number of sign-in requests that are processed per second on
federation servers. This measurement can help you determine how many simultaneous users can sign in to a
given server. You can use this measurement in conjunction with the CPU consumption measurement to
understand this measurement's effect on performance.
CPU consumption: The percentage by which CPU capacity is measured. This measurement can help you
determine the overall CPU load that occurred based on the number of incoming sign-in requests per second.
Continue reading more about AD FS capacity planning

After you have completed the prerequisite tasks and have become familiar with related terms and hardware
requirements, you can use the following additional capacity planning content to help you determine the
recommended number of AD FS servers required for your deployment:
Planning for Federation Server Capacity
Planning for Federation Server Proxy Capacity
See Also
Planning for Federation Server Capacity
Capacity planning for federation servers helps you estimate:

Which factors grow the size of the AD FS configuration database.
The appropriate hardware requirements for each federation server.
The number of federation servers to place in each organization.
Federation servers issue security tokens to users. These tokens are presented to a relying party for consumption.
Federation servers issue security tokens after authenticating a user or after receiving a security token that was
previously issued by a partner Federation Service. A security token is requested from a Federation Service when
users initially sign in to federated applications or when their security tokens expire while they are accessing
federated applications.
Federation servers are designed to accommodate high-availability server farm configurations that use Microsoft
Network Load Balancing (NLB ) technology. Federation servers in a farm configuration can service requests
independently, without accessing any common farm components for each request. Therefore, there is little
overhead involved in scaling out a federation server deployment.
Recommendations:
For mission-critical or high-availability deployments, we recommend that you create a small federation
server farm in each partner organization, with at least two federation servers per farm, to provide fault
tolerance.
With the need for high availability and the ease of scaling out federation servers, scaling out is the
recommended method for handling high numbers of requests per second for a particular Federation
Service. Scaling up beyond the base configuration in this guide is unlikely to produce significant capacity
handling gains.
AD FS configuration database size and growth

The size of the AD FS configuration database is generally considered to be small, and database size does not tend
to be a major consideration in AD FS deployments. The precise size of the AD FS configuration database can
depend largely on the number of trust relationships and the associated trust-related metadata—such as claims,
claim rules, and monitoring settings configured for each trust. As the number of trust entries in the configuration
database grows, so does the need for more disk space.
For additional deployment information about the AD FS configuration database, see AD FS Deployment Topology
Considerations.
Memory, CPU and disk space requirements

Fortunately, memory, CPU and disk space requirements for federation servers are modest, and they are not likely
to be a driving factor in hardware decisions. For more information about hardware requirements, see Appendix A:
Reviewing AD FS Requirements.
NOTE
In tests that were performed by the AD FS product team using a federation server farm configured with a dedicated SQL
Server to store the AD FS configuration database, the overall load on the SQL Server tended to be low. In one test using a
four-federation-server farm that was configured to use a single SQL Server, CPU utilization did not exceed 10% despite
testing that brought the federation servers to target utilization.
Estimate the number of federation servers for your organization

In an effort to streamline the hardware planning process for federation servers, the AD FS product team developed
the AD FS Capacity Planning Sizing Spreadsheet. This Excel spreadsheet includes calculator-like functionality that
will take expected usage data that you provide about users in your organization and return a recommended optimal
number of federation servers for your AD FS production environment.
NOTE
The number of federation servers that this spreadsheet will recommend is based on the hardware and network specifications
that the AD FS product team used during testing. Therefore, the number of federation servers that the spreadsheet will
recommend must be understood within this context. For more information about the specifications used during testing, see
the topic titled Planning for AD FS Server Capacity.
Using the AD FS Capacity Planning Sizing Spreadsheet

When you use this spreadsheet, you will need to select a value (either 40%, 60%, or 80%) that best represents the
percentage of total users you expect will send authentication requests to your federation servers during peak usage
periods.
Then, you will need to select a value (either 1 minute, 15 minutes, or 1 hour) that best represents the length of
time you expect the peak usage period to last. For example, you might estimate 40% as the value for the total
number of users who will login within a period of 15 minutes, or that 60% of users will login within a period of 1
hour. Together, these values define the peak load profile by which your sizing recommendation will be calculated.
Next, you will need to specify the total number of users that will require single sign-on access to the target claims-
aware application, based on whether the users are:
Logging into Active Directory from a local computer that is physically connected to your corporate network
(through Windows integrated authentication)
Logging into Active Directory remotely from a computer that is not physically connected to your corporate
network (through Windows integrated authentication or Username and password)
From another organization and are attempting to access the target claims-aware application from a trusted
partner
From a SAML 2.0 identity provider and are attempting to access the target claims-aware application
How to use this spreadsheet
You can use the following steps for each federation server farm instance you plan to deploy to determine the
recommended number of federation servers.
1. Download and then open the AD FS Capacity Planning Sizing Spreadsheet For Windows Server 2012 R2 or
the AD FS Capacity Planning Sizing Spreadsheet For Windows Server 2016.
2. In the cell to the right of the During the peak system usage period, I expect this percentage of my
users to authenticate cell, click the cell and then use the drop-down arrows to select your estimated system
utilization level, either 40%, 60% or 80% for the deployment.
3. In the cell to the right of the within the following period of time cell, click the cell and then use the drop-
down arrows to select either 1 minute, 15 minutes, or 1 hour to select the duration of peak load.
4. In the cell to the right of the Enter estimated number of internal applications (such as SharePoint
(2007 or 2010) or claims aware web applications) cell, type the number of internal applications you will
use in your organization.
5. In the cell to the right of the Enter estimated number of online applications (such as Office 365
Exchange Online, SharePoint Online or Lync Online) cell, type the number of online applications or
services you will used in your organization.
6. Under the cell titled Number of Users, type a number on each row that applies to an example application
scenario your users will need single sign-on access to. This column should contain the number of defined
users, not the peak users per second. If access attempts made to the application must first go through the
home realm discovery page, type Y. If you are unsure of this selection, type Y.
7. Review the following recommended values that are provided:
a. For the total number of recommended federation servers, see the lower right cell that is highlighted
in gray.
b. For the number of servers recommended for each example application scenario, see the cell on the
row that is highlighted in gray.
NOTE
The value that will be automatically calculated in the cell to the right of the cell titled Total number of federation servers
recommended at the bottom of the spreadsheet contains a formula which will add an additional 20% buffer to the sum total
of all the values in each of the individual rows preceding it. The formula added to the Total number of federation servers
recommended cell builds in this buffer to your total recommended number of deployed federation servers to make it very
unlikely that the overall load on the farm will ever hit its saturation point.
See Also
Planning for Federation Server Proxy Capacity
Capacity planning for federation server proxies helps you estimate:

The appropriate hardware requirements for each federation server proxy.
The number of federation servers and federation server proxies to place in each organization.
Federation server proxies redirect security tokens from a protected federation server in the corporate network to
federated users. The purpose of deploying a federation server proxy is to allow external users to connect to a
federation server. It does not actually sign tokens or write to data in the AD FS configuration database. Therefore,
the hardware requirements for the federation server proxy are usually lower than the hardware requirements for a
federation server.
Because every request to a federation server proxy results in a request to a federation server or federation server
farm, capacity planning for federation servers and federation server proxies must be performed in parallel.
Estimating the peak sign-ins per second for the federation server proxy requires an understanding of the usage
patterns of the federated users that will be signing in through the federation server proxy. In many deployments,
the federated users who sign in using the federation server proxy are located on the Internet. You can estimate the
peak sign-ins per second by looking at the usage patterns of these federated users on the existing Web applications
that will be protected by AD FS.
NOTE
For production deployments, we recommend a minimum of two federation server proxies for each federation server farm
instance you deploy.
Estimate the number of federation server proxies required for your

organization
Before you can estimate the number of AD FS federation server proxy machines required, you will first need to
determine the total number of federation servers that you will deploy in your organization. For more information
about how to do this, see Planning for Federation Server Capacity.
Once you have decided on the number of federation servers, multiply this number of servers by the percentage of
incoming federated authentication requests that you expect will be made from external users (located outside of the
corporate network). The value of this calculation will provide you with the estimated number of federation server
proxies that will handle the incoming authentication requests for your external users.
For example, if the number of recommended federation servers is 3, and you expect that the total number of
authentication requests that will be made from external users will be approximately 60% of the total number of
federated authentication requests, your calculation would equal 1.8 (3 X .60) which you can round up to 2.
Therefore, in this case, you would need to deploy two federation server proxy machines to accommodate the load
of external user authentication requests for the three federation servers.
In tests performed by the AD FS product team, the overall CPU utilization on each federation server proxy was
found to be significantly lower than the CPU utilization that was observed on the federation servers for the same
farm. In one test, while one federation server CPU was indicating that it was completely saturated, the CPU for a
federation server proxy providing proxy services for that same farm was observed at only 20% utilization.
Therefore, our tests revealed that the load on the CPU of a federation server proxy, which uses similar hardware
specifications as discussed earlier in this section, could reasonably handle the processing load for approximately
three federation servers.
However, for fault tolerance purposes, we recommend a minimum of two federation server proxies for each
federation server farm you deploy.
See Also
So that the organizational partners in your Active Directory Federation Services (AD FS ) deployment can
collaborate successfully, you must first make sure that your corporate network infrastructure is configured to
support AD FS requirements for accounts, name resolution, and certificates. AD FS has the following types of
requirements:
TIP
You can find additional AD FS resource links at the AD FS Content Map page on the Microsoft TechNet Wiki. This page is
managed by members of the AD FS Community and is monitored on a regular basis by the AD FS Product Team.
The following minimum and recommended hardware requirements apply to the federation server and federation
server proxy computers.
HARDWARE REQUIREMENT MINIMUM REQUIREMENT RECOMMENDED REQUIREMENT
CPU speed Single-core, 1 gigahertz (GHz) Quad-core, 2 GHz
RAM 1 GB 4 GB
Disk space 50 MB 100 MB
AD FS relies on server functionality that is built into the Windows Server® 2012 operating system.
NOTE
The Federation Service and Federation Service Proxy role services cannot coexist on the same computer.
Certificates play the most critical role in securing communications between federation servers, federation server
proxies, claims-aware applications, and Web clients. The requirements for certificates vary, depending on whether
you are setting up a federation server or federation server proxy computer, as described in this section.
Federation server certificates
Federation servers require the certificates in the following table.
WHAT YOU NEED TO KNOW BEFORE
CERTIFICATE TYPE DESCRIPTION DEPLOYING
Secure Sockets Layer (SSL) certificate This is a standard Secure Sockets Layer This certificate must be bound to the
(SSL) certificate that is used for securing Default Web Site in Internet Information
communications between federation Services (IIS) for a Federation Server or a
servers and clients. Federation Server Proxy. For a
Federation Server Proxy, the binding
must be configured in IIS prior to
running the Federation Server Proxy
Configuration Wizard successfully.
Recommendation: Because this

certificate must be trusted by clients of
AD FS, use a server authentication
certificate that is issued by a public
(third-party) certification authority (CA),
for example, VeriSign. Tip: The Subject
name of this certificate is used to
represent the Federation Service name
for each instance of AD FS that you
deploy. For this reason, you may want
to consider choosing a Subject name on
any new CA-issued certificates that best
represents the name of your company
or organization to partners.
Service communication certificate This certificate enables WCF message By default, the SSL certificate is used as
security for securing communications the service communications certificate.
between federation servers. This can be changed using the AD FS
Management console.
Token-signing certificate This is a standard X509 certificate that is The token-signing certificate must
used for securely signing all tokens that contain a private key, and it should
the federation server issues. chain to a trusted root in the Federation
Service. By default, AD FS creates a self-
signed certificate. However, you can
change this later to a CA-issued
certificate by using the AD FS
Management snap-in, depending on
the needs of your organization.
Token-decryption certificate This is a standard SSL certificate that is By default, AD FS creates a self-signed
used to decrypt any incoming tokens certificate. However, you can change
that are encrypted by a partner this later to a CA-issued certificate by
federation server. It is also published in using the AD FS Management snap-in,
federation metadata. depending on the needs of your
organization.
Cau t i on
Certificates that are used for token-signing and token-decrypting are critical to the stability of the Federation
Service. Because a loss or unplanned removal of any certificates that are configured for this purpose can disrupt
service, you should back up any certificates that are configured for this purpose.
For more information about the certificates that federation servers use, see Certificate Requirements for Federation
Servers.
Federation server proxy certificates
Federation server proxies require the certificates in the following table.
WHAT YOU NEED TO KNOW BEFORE
CERTIFICATE TYPE DESCRIPTION DEPLOYING
Server authentication certificate This is a standard Secure Sockets Layer This certificate must be bound to the
(SSL) certificate that is used for securing Default Web Site in Internet Information
communications between a federation Services (IIS) before you can run the AD
server proxy and Internet client FS Federation Server Proxy
computers. Configuration Wizard successfully.
Recommendation: Because this

certificate must be trusted by clients of
AD FS, use a server authentication
certificate that is issued by a public
(third-party) certification authority (CA),
for example, VeriSign.
Tip: The Subject name of this certificate

is used to represent the Federation
Service name for each instance of AD FS
that you deploy. For this reason, you
may want to consider choosing a
Subject name that best represents the
name of your company or organization
to partners.
For more information about the certificates that federation server proxies use, see Certificate Requirements for
Federation Server Proxies.
Although any current Web browser with JavaScript capability can be made to work as an AD FS client, the Web
pages that are provided by default have been tested only against Internet Explorer versions 7.0, 8.0 and 9.0, Mozilla
Firefox 3.0, and Safari 3.1 on Windows. JavaScript must be enabled, and cookies must be enabled for browser-
based sign-in and sign-out to work correctly.
The AD FS product team at Microsoft successfully tested the browser and operating system configurations in the
following table.
BROWSER WINDOWS 7 WINDOWS VISTA
Internet Explorer 7.0 X X
Internet Explorer 8.0 X X
Internet Explorer 9.0 X Not Tested
FireFox 3.0 X X
Safari 3.1 X X
NOTE
AD FS supports both the 32bit and 64bit versions of all the browsers showing in the above table.
Cookies
AD FS creates session-based and persistent cookies that must be stored on client computers to provide sign-in,
sign-out, single sign-on (SSO ), and other functionality. Therefore, the client browser must be configured to accept
cookies. Cookies that are used for authentication are always Secure Hypertext Transfer Protocol (HTTPS ) session
cookies that are written for the originating server. If the client browser is not configured to allow these cookies, AD
FS cannot function correctly. Persistent cookies are used to preserve user selection of the claims provider. You can
disable them by using a configuration setting in the configuration file for the AD FS sign-in pages.
Support for TLS/SSL is required for security reasons.
Configuring the following network services appropriately is critical for successful deployment of AD FS in your
organization.
TCP/IP network connectivity
For AD FS to function, TCP/IP network connectivity must exist between the client; a domain controller; and the
computers that host the Federation Service, the Federation Service Proxy (when it is used), and the AD FS Web
Agent.
DNS
The primary network service that is critical to the operation of AD FS, other than Active Directory Domain Services
(AD DS ), is Domain Name System (DNS ). When DNS is deployed, users can use friendly computer names that are
easy to remember to connect to computers and other resources on IP networks.
Windows Server 2008 uses DNS for name resolution instead of the Windows Internet Name Service (WINS )
NetBIOS name resolution that was used in Windows NT 4.0–based networks. It is still possible to use WINS for
applications that require it. However, AD DS and AD FS require DNS name resolution.
The process of configuring DNS to support AD FS varies, depending on whether:
Your organization already has an existing DNS infrastructure. In most scenarios, DNS is already configured
throughout your network so that Web browser clients in your corporate network have access to the Internet.
Because Internet access and name resolution are requirements of AD FS, this infrastructure is assumed to be
in place for your AD FS deployment.
You intend to add a federated server to your corporate network. For the purpose of authenticating users in
the corporate network, internal DNS servers in the corporate network forest must be configured to return
the CNAME of the internal server that is running the Federation Service. For more information, see Name
You intend to add a federated server proxy to your perimeter network. When you want to authenticate user
accounts that are located in the corporate network of your identity partner organization, the internal DNS
servers in the corporate network forest must be configured to return the CNAME of the internal federation
server proxy. For information about how to configure DNS to accommodate the addition of federation
server proxies, see Name Resolution Requirements for Federation Server Proxies.
You are setting up DNS for a test lab environment. If you plan to use AD FS in a test lab environment where
no single root DNS server is authoritative, it is probable that you will have to set up DNS forwarders so that
queries to names between two or more forests will be forwarded appropriately. For general information
about how to set up an AD FS test lab environment, see AD FS Step-by-Step and How To Guides.

AD FS requires at least one attribute store to be used for authenticating users and extracting security claims for
those users. For a list of attribute stores that AD FS supports, see The Role of Attribute Stores in the AD FS Design
Guide.
NOTE
AD FS automatically creates an Active Directory attribute store, by default.
Attribute store requirements depend on whether your organization is acting as the account partner (hosting the
federated users) or the resource partner (hosting the federated application).
AD DS
For AD FS to operate successfully, domain controllers in either the account partner organization or the resource
partner organization must be running Windows Server 2003 SP1, Windows Server 2003 R2, Windows Server
2008 , or Windows Server 2012 .
When AD FS is installed and configured on a domain-joined computer, the Active Directory user account store for
that domain is made available as a selectable attribute store.
IMPORTANT
Because AD FS requires the installation of Internet Information Services (IIS), we recommend that you not install the AD FS
software on a domain controller in a production environment for security purposes. However, this configuration is supported
by Microsoft Customer Service Support.
Schema requirements
AD FS does not require schema changes or functional-level modifications to AD DS.
Functional-level requirements
Most AD FS features do not require AD DS functional-level modifications to operate successfully. However,
Windows Server 2008 domain functional level or higher is required for client certificate authentication to operate
successfully if the certificate is explicitly mapped to a user's account in AD DS.
If you are creating a federation server farm, you must first create a dedicated domain-based service account in AD
DS that the Federation Service can use. Later, you configure each federation server in the farm to use this account.
For more information about how to do this, see Manually Configure a Service Account for a Federation Server
Farm in the AD FS Deployment Guide.
LDAP
When you work with other Lightweight Directory Access Protocol (LDAP )-based attribute stores, you must connect
to an LDAP server that supports Windows Integrated authentication. The LDAP connection string must also be
written in the format of an LDAP URL, as described in RFC 2255.
SQL Server
For AD FS to operate successfully, computers that host the Structured Query Language (SQL ) Server attribute
store must be running either Microsoft SQL Server 2005 or SQL Server 2008. When you work with SQL -based
attribute stores, you also must configure a connection string.
Custom attribute stores
You can develop custom attribute stores to enable advanced scenarios. The policy language that is built into AD FS
can reference custom attribute stores so that any of the following scenarios can be enhanced:
Creating claims for a locally authenticated user
Supplementing claims for an externally authenticated user
Authorizing a user to obtain a token
Authorizing a service to obtain a token on behavior of a user
When you work with a custom attribute store, you may also have to configure a connection string. In this situation,
you can enter any custom code you like that enables a connection to your custom attribute store. The connection
string in this situation is a set of name/value pairs that are interpreted as implemented by the developer of the
custom attribute store.
For more information about developing and using custom attribute stores, see Attribute Store Overview.
Federation servers can communicate with and protect federation applications, such as claims-aware applications.
AD FS integrates naturally with existing Windows authentication, for example, Kerberos authentication, NTLM,
smart cards, and X.509 v3 client-side certificates. Federation servers use standard Kerberos authentication to
authenticate a user against a domain. Clients can authenticate by using forms-based authentication, smart card
authentication, and Windows Integrated authentication, depending on how you configure authentication.
The AD FS federation server proxy role makes possible a scenario in which the user authenticates externally using
SSL client authentication. You can also configure the federation server role to require SSL client authentication,
although typically the most seamless user experience is achieved by configuring the account federation server for
Windows Integrated authentication. In this situation, AD FS has no control over what credentials the user employs
for Windows desktop logon.
Smart card logon
Although AD FS can enforce the type of credentials that it uses for authentication (passwords, SSL client
authentication, or Windows Integrated authentication), it does not directly enforce authentication with smart cards.
Therefore, AD FS does not provide a client-side user interface (UI) to obtain smart-card personal identification
number (PIN ) credentials. This is because Windows-based clients intentionally do not provide user credential
details to federation servers or Web servers.
Smart card authentication
Smart card authentication uses the Kerberos protocol to authenticate to an account federation server. AD FS cannot
be extended to add new authentication methods. The certificate in the smart card is not required to chain up to a
trusted root on the client computer. Use of a smart-card-based certificate with AD FS requires the following
conditions:
The reader and cryptographic service provider (CSP ) for the smart card must work on the computer where
the browser is located.
The smart card certificate must chain up to a trusted root on the account federation server and the account
federation server proxy.
The certificate must map to the user account in AD DS by either of the following methods:
The certificate subject name corresponds to the LDAP distinguished name of a user account in AD
DS.
The certificate subject altname extension has the user principal name (UPN ) of a user account in AD
DS.
To support certain authentication strength requirements in some scenarios, it is also possible to configure AD FS to
create a claim that indicates how the user was authenticated. A relying party can then use this claim to make an
authorization decision.
See Also
AD FS 2016 Deployment
This document contains a list of all of the documentation for deploying AD FS for Windows Server 2016. This
Best Practices for Securing AD FS
Deploy Azure AD Connect Health to Monitor your on-premises identity infrastructure in the cloud
Required Updates for AD FS and WAP
Set up Geographic Redundancy with SQL Server Replication
Deploy AD FS in Azure
AD FS in Azure with Azure Traffic Manager
Windows Server 2016 and 2012 R2 Deployment Guide
Windows Server 2012 Deployment Guide
AD FS 2016 Deployment Guide
The AD FS deployment guide is a comprehensive guide for deploying AD FS. This guide is made up of the
following:
Upgrading to AD FS in Windows Server 2016
Windows Server 2016 and 2012 R2 Deployment Guide
Windows Server 2012 Deployment Guide
Monitor your on-premises identity infrastructure and synchronization services in the cloud
Best practices for securing Active Directory Federation Services
This document provides best practices for the secure planning and deployment of Active Directory Federation
Services (AD FS ) and Web Application Proxy. It contains information about the default behaviors of these
components and recommendations for additional security configurations for an organization with specific use cases
and security requirements.
This document applies to AD FS and WAP in Windows Server 2012 R2 and Windows Server 2016 (preview ).
These recommendations can be used whether the infrastructure is deployed in an on premises network or in a
cloud hosted environment such as Microsoft Azure.
Standard deployment topology

For deployment in on-premises environments, we recommend a standard deployment topology consisting of one
or more AD FS servers on the internal corporate network, with one or more Web Application Proxy (WAP ) servers
in a DMZ or extranet network. At each layer, AD FS and WAP, a hardware or software load balancer is placed in
front of the server farm and handles traffic routing. Firewalls are placed as required in front of the external IP
address of the load balancer in front of each (FS and proxy) farm.
Ports required
The below diagram depicts the firewall ports that must be enabled between and amongst the components of the
AD FS and WAP deployment. If the deployment does not include Azure AD / Office 365, the sync requirements can
be disregarded.
Note that port 49443 is only required if user certificate authentication is used, which is optional for Azure AD
and Office 365.
Azure AD Connect and Federation Servers/WAP
This table describes the ports and protocols that are required for communication between the Azure AD Connect
server and Federation/WAP servers.
PROTOCOL PORTS DESCRIPTION
HTTP 80 (TCP/UDP) Used to download CRLs (Certificate

Revocation Lists) to verify SSL
certificates.
HTTPS 443(TCP/UDP) Used to synchronize with Azure AD.
WinRM 5985 WinRM Listener
WAP and Federation Servers

This table describes the ports and protocols that are required for communication between the Federation servers
and WAP servers.
HTTPS 443(TCP/UDP) Used for authentication.
WAP and Users

This table describes the ports and protocols that are required for communication between users and the WAP
servers.
HTTPS 443(TCP/UDP) Used for device authentication.
TCP 49443 (TCP) Used for certificate authentication.
For additional information on required ports and protocols required for hybrid deployments see the document
here.
For detailed information about ports and protocols required for an Azure AD and Office 365 deployment, see the
document here.
Endpoints enabled
When AD FS and WAP are installed, a default set of AD FS endpoints are enabled on the federation service and on
the proxy. These defaults were chosen based on the most commonly required and used scenarios and it is not
necessary to change them.
[Optional] Min set of endpoints proxy enabled for Azure AD / Office 365
Organizations deploying AD FS and WAP only for Azure AD and Office 365 scenarios can limit even further the
number of AD FS endpoints enabled on the proxy to achieve a more minimal attack surface. Below is the list of
endpoints that must be enabled on the proxy in these scenarios:
ENDPOINT PURPOSE
/adfs/ls Browser based authentication flows and current versions of

Microsoft Office use this endpoint for Azure AD and Office 365
authentication
/adfs/services/trust/2005/usernamemixed Used for Exchange Online with Office clients older than Office
2013 May 2015 update. Later clients use the passive \adfs\ls
endpoint.
/adfs/services/trust/13/usernamemixed Used for Exchange Online with Office clients older than Office
endpoint.
/adfs/oauth2 This one is used for any modern apps (on prem or in cloud)
you have configured to authenticate directly to AD FS (i.e. not
through AAD)
/adfs/services/trust/mex Used for Exchange Online with Office clients older than Office
endpoint.
/adfs/ls/federationmetadata/2007-06/federationmetadata.xml Requirement for any passive flows; and used by Office 365 /
Azure AD to check AD FS certificates
AD FS endpoints can be disabled on the proxy using the following PowerShell cmdlet:
PS:\>Set-AdfsEndpoint -TargetAddressPath <address path> -Proxy $false
For example:
PS:\>Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/certificatemixed -Proxy $false
Extended protection for authentication

Extended protection for authentication is a feature that mitigates against man in the middle (MITM ) attacks and is
enabled by default with AD FS.
To verify the settings, you can do the following:
The setting can be verified using the below PowerShell commandlet.
PS:\>Get-ADFSProperties
The property is ExtendedProtectionTokenCheck . The default setting is Allow, so that the security benefits can be
achieved without the compatibility concerns with browsers that do not support the capability.
Congestion control to protect the federation service
The federation service proxy (part of the WAP ) provides congestion control to protect the AD FS service from a
flood of requests. The Web Application Proxy will reject external client authentication requests if the federation
server is overloaded as detected by the latency between the Web Application Proxy and the federation server. This
feature is configured by default with a recommended latency threshold level.
To verify the settings, you can do the following:
1. On your Web Application Proxy computer, start an elevated command window.
2. Navigate to the ADFS directory, at %WINDIR%\adfs\config.
3. Change the congestion control settings from its default values to ‘’.
4. Save and close the file.
5. Restart the AD FS service by running ‘net stop adfssrv’ and then ‘net start adfssrv’. For your reference, guidance
on this capability can be found here.
Standard HTTP request checks at the proxy
The proxy also performs the following standard checks against all traffic:
The FS -P itself authenticates to AD FS via a short lived certificate. In a scenario of suspected compromise of
dmz servers, AD FS can “revoke proxy trust” so that it no longer trusts any incoming requests from potentially
compromised proxies. Revoking the proxy trust revokes each proxy’s own certificate so that it cannot
successfully authenticate for any purpose to the AD FS server
The FS -P terminates all connections and creates a new HTTP connection to the AD FS service on the internal
network. This provides a session-level buffer between external devices and the AD FS service. The external
device never connects directly to the AD FS service.
The FS -P performs HTTP request validation that specifically filters out HTTP headers that are not required by
AD FS service.
Recommended security configurations

Ensure all AD FS and WAP servers receive the most current updates The most important security recommendation
for your AD FS infrastructure is to ensure you have a means in place to keep your AD FS and WAP servers current
with all security updates, as well as those optional updates specified as important for AD FS on this page.
The recommended way for Azure AD customers to monitor and keep current their infrastructure is via Azure AD
Connect Health for AD FS, a feature of Azure AD Premium. Azure AD Connect Health includes monitors and alerts
that trigger if an AD FS or WAP machine is missing one of the important updates specifically for AD FS and WAP.
Information on installing Azure AD Connect Health for AD FS can be found here.
Additional security configurations

The following additional capabilities can be configured optionally to provide additional protections to those offered
in the default deployment.
Extranet “soft” lockout protection for accounts
With the extranet lockout feature in Windows Server 2012 R2, an AD FS administrator can set a maximum allowed
number of failed authentication requests (ExtranetLockoutThreshold) and an ‘observation window's time period
(ExtranetObservationWindow ). When this maximum number (ExtranetLockoutThreshold) of authentication
requests is reached, AD FS stops trying to authenticate the supplied account credentials against AD FS for the set
time period (ExtranetObservationWindow ). This action protects this account from an AD account lockout, in other
words, it protects this account from losing access to corporate resources that rely on AD FS for authentication of
the user. These settings apply to all domains that the AD FS service can authenticate.
You can use the following Windows PowerShell command to set the AD FS extranet lockout (example):
PS:\>Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow (
new-timespan -Minutes 30 )
For reference, the public documentation of this feature is here.

Differentiate access policies for intranet and extranet access
AD FS has the ability to differentiate access policies for requests that originate in the local, corporate network vs
requests that come in from the internet via the proxy. This can be done per application or globally. For high
business value applications or applications with sensitive or personally identifiable information, consider requiring
multi factor authentication. This can be done via the AD FS management snap-in.
Require Multi factor authentication (MFA )
AD FS can be configured to require strong authentication (such as multi factor authentication) specifically for
requests coming in via the proxy, for individual applications, and for conditional access to both Azure AD / Office
365 and on premises resources. Supported methods of MFA include both Microsoft Azure MFA and third party
providers. The user is prompted to provide the additional information (such as an SMS text containing a one time
code), and AD FS works with the provider specific plug-in to allow access.
Supported external MFA providers include those listed in this page, as well as HDI Global.
Hardware Security Module (HSM )
In its default configuration, the keys AD FS uses to sign tokens never leave the federation servers on the intranet.
They are never present in the DMZ or on the proxy machines. Optionally to provide additional protection, these
keys can be protected in a hardware security module attached to AD FS. Microsoft does not produce an HSM
product, however there are several on the market that support AD FS. In order to implement this recommendation,
follow the vendor guidance to create the X509 certs for signing and encryption, then use the AD FS installation
powershell commandlets, specifying your custom certificates as follows:
PS:\>Install-AdfsFarm -CertificateThumbprint <String> -DecryptionCertificateThumbprint <String> -

FederationServiceName <String> -ServiceAccountCredential <PSCredential> -SigningCertificateThumbprint <String>
where:
CertificateThumbprint is your SSL certificate
SigningCertificateThumbprint is your signing certificate (with HSM protected key)
DecryptionCertificateThumbprint is your encryption certificate (with HSM protected key)
This document describes conditional access policies based on devices in a hybrid scenario where the on-premises
directories are connected to Azure AD using Azure AD Connect.
AD FS and Hybrid conditional access

devices with Azure AD for conditional access to cloud resources, the Azure AD Connect device write back capability
makes device registration information available on premises for AD FS policies to consume and enforce. This way,
you have a consistent approach to access control policies for both on premises and cloud resources.
Types of registered devices

There are three kinds of registered devices, all of which are represented as Device objects in Azure AD and can be
used for conditional access with AD FS on premises as well.
ADD WORK OR SCHOOL

ACCOUNT AZURE AD JOIN WINDOWS 10 DOMIAN JOIN
Description Users add their work or Users join their Windows 10 Windows 10 domain joined
school account to their work device to Azure AD. devices automatically
BYOD device interactively. register with Azure AD.
Note: Add Work or School
Account is the replacement
for Workplace Join in
Windows 8/8.1
ADD WORK OR SCHOOL
How users log in to the No login to Windows as the Login to Windows as the Login using AD account.
device work or school account. (work or school) account
Login using a Microsoft that registered the device.
account.
How devices are managed MDM Policies (with MDM Policies (with Group Policy, System Center
additional Intune enrollment) additional Intune enrollment) Configuration Manager
(SCCM)
Azure AD Trust type Workplace joined Azure AD joined Domain joined
W10 Settings location Settings > Accounts > Your Settings > System > About Settings > System > About
account > Add a work or > Join Azure AD > Join a domain
school account
Also available for iOS and Yes No No

Android Devices?
For more information on the different ways to register devices, see also:
Using Windows 10 devices in your workplace
Setting up Windows 10 devices for work
Join Windows 10 Mobile to Azure Active Directory
How Windows 10 User and Device Sign on is different from previous versions
For Windows 10 and AD FS 2016 there are some new aspects of device registration and authentication you should
know about (especially if you are very familiar with device registration and "workplace join" in previous releases).
First, in Windows 10 and AD FS in Windows Server 2016, device registration and authentication is no longer based
solely on an X509 user certificate. There is a new and more robust protocol that provides better security and a
more seamless user experience. The key differences are that, for Windows 10 Domain Join and Azure AD Join,
there is an X509 computer certificate and a new credential called a PRT. You can read all about it here and here.
Second, Windows 10 and AD FS 2016 support user authentication using Microsoft Passport for Work, which you
can read about here and here.
AD FS 2016 provides seamless device and user SSO based on both PRT and Passport credentials. Using the steps
in this document, you can enable these capabilities and see them work.
Device Access Control Policies
Devices can be used in simple AD FS access control rules such as:
allow access only from a registered device
require multi factor authentication when a device is not registered
These rules can then be combined with other factors such as network access location and multi factor
authentication, creating rich conditional access policies such as:
require multi factor authentication for unregistered devices accessing from outside the corporate network,
except for members of a particular group or groups
With AD FS 2016, these policies can be configured specifically to require a particular device trust level as well:
either authenticated, managed, or compliant.
For more information on configuring AD FS access control policies, see Access control policies in AD FS.
Authenticated devices
Authenticated devices are registered devices that are not enrolled in MDM (Intune and 3rd party MDMs for
Windows 10, Intune only for iOS and Android).
Authenticated devices will have the isManaged AD FS claim with value FALSE. (Whereas devices that are not
registered at all will lack this claim.) Authenticated devices (and all registered devices) will have the isKnown AD FS
claim with value TRUE.
Managed Devices:
Managed devices are registered devices that are enrolled with MDM.
Managed devices will have the isManaged AD FS claim with value TRUE.
Devices compliant (with MDM or Group Policies )
Compliant devices are registered devices that are not only enrolled with MDM but compliant with the MDM
policies. (Compliance information originates with the MDM and is written to Azure AD.)
Compliant devices will have the isCompliant AD FS claim with value TRUE.
For complete list of AD FS 2016 device and conditional access claims, see Reference.
Reference
Complete list of new AD FS 2016 and device claims
https://schemas.microsoft.com/ws/2014/01/identity/claims/anchorclaimtype
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/implicitupn
https://schemas.microsoft.com/2014/03/psso
https://schemas.microsoft.com/2015/09/prt
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
https://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid
https://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
https://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid
https://schemas.microsoft.com/2012/01/devicecontext/claims/displayname
https://schemas.microsoft.com/2012/01/devicecontext/claims/identifier
https://schemas.microsoft.com/2012/01/devicecontext/claims/ostype
https://schemas.microsoft.com/2012/01/devicecontext/claims/osversion
https://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged
https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser
https://schemas.microsoft.com/2014/02/devicecontext/claims/isknown
https://schemas.microsoft.com/2014/02/deviceusagetime
https://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant
https://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype
https://schemas.microsoft.com/claims/authnmethodsreferences
https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent
https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path
https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork
https://schemas.microsoft.com/2012/01/requestcontext/claims/client-request-id
https://schemas.microsoft.com/2012/01/requestcontext/claims/relyingpartytrustid
https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-ip
https://schemas.microsoft.com/2014/09/requestcontext/claims/userip
https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod
Required Updates for Active Directory Federation
Services (AD FS) and Web Application Proxy (WAP)
Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2
SP1
As of October 2016, all updates to all components of Windows Server are released only via Windows Update
(WU ). There are no more hotfixes or individual downloads. This applies to Windows Server 2016, Windows Server
2012 R2, Windows Server 2012 and Windows Server 2008 R2 SP1.
This page lists rollup packages of particular interest for AD FS and WAP, as well as the historic list of hotfix updates
recommended for AD FS and WAP.
Updates for AD FS and WAP in Windows Server 2016

Updates for Windows Server 2016 are delivered monthly via Windows Update and are cumulative. The update
package listed below is recommended for all AD FS and WAP 2016 servers and includes all previously required
updates as well as the latest fixes.
KB # DESCRIPTION DATE RELEASED
4041688 (OS Build 14393.1794) This fix addresses an issue that October 2017
intermittently misdirects AD Authority
requests to the wrong Identity Provider
because of incorrect caching behavior.
This can effect authentication features
like Multi Factor Authentication.
Added the ability for AAD Connect
Health to report ADFS server health
with correct fidelity (using verbose
auditing) on mixed WS2012R2 and
WS2016 ADFS farms.
Fixed a problem where during upgrade

of 2012 R2 ADFS farm to ADFS 2016,
the powershell cmdlet to raise the farm
behavior level fails with a timeout when
there are many relying party trusts.
Addressed an issue where AD FS causes

authentication failures by modifying the
wct parameter value while federating
the requests to other Security Token
Server (STS).
4038801 (OS Build 14393.1737) Support added for OIDC logout using September 2017
federated LDPs. This will allow "Kiosk
Scenarios" where multiple users might
be serially logged into a single device
where there is federation with an LDP.
Fixed a WinHello issue where CEP/CES
based certificates don't work with gMSA
accounts.
Fixes a problem where the Windows

Internal Database (WID) on Windows
Server 2016 ADFS servers fails to sync
some settings, such as the
ApplicationGroupId columns from
IdentityServerPolicy.Scopes and
IdentityServerPolicy.Clients tables) due
to a foreign key constraint. Such sync
failures can cause different claim, claim
provider and application experiences
between primary to secondary ADFS
servers. Also, if the WID primary role is
moved to a secondary node, application
groups will no longer be manageable in
the ADFS management UX.
This update fixes an issues where Multi

Factor Authentication does not work
correctly with Mobile devices that use
custom culture definitions
4034661 (OS Build 14393.1613) Fixes a problem where the caller IP August 2017
address is nog logged by 411 events in
the Security Event log of ADFS 4.0 \
Windows Server 2016 RS1 ADFS servers
even after enabling “success audits” and
“failure audits”.
This fix addresses an issue with Azure
Multi Factor Authentication (MFA) when
an ADFX server is configured to use an
HTTP Proxy.
"Addressed an issue where presenting

an expired or revoked certificate to the
ADFS Proxy server does not return an
error to the user."
4034658 (OS Build 14393.1593) Fix for 2016 AD FS server in order to August 2017
support MFA certificate enrollment for
Windows Hello For Business for on
prem deployments
4025334 (OS Build 14393.1532) Addressed an issue where the PkeyAuth July 2017
token handler could fail an
authentication if the pkeyauth request
contains incorrect data. The
authentication should still continue
without performing device
authentication
4022723 (OS Build 14393.1378) [Web Application Proxy] Value of June 2017
DisableHttpOnlyCookieProtection
configuration property is not picked up
by WAP 2016 in 2012R2/2016 mixed
deployment
[Web Application Proxy] Unable to
obtain user access token from AD FS in
EAS Pre-auth scenarios.
AD FS 2016 : WSFED sign-out leads to

an exception
3213986 Cumulative Update for Windows Server January 2017

2016 for x64-based Systems
(KB3213986)
Updates for AD FS and WAP in Windows Server 2012 R2

Below is the list of hotfixes and update rollups that have been released for Active Directory Federation Services (AD
FS ) in Windows Server 2012 R2.
4041685 Addressed an AD FS issue where October 2017 Preview of Update Rollup

MSISConext cookies in request headers
can eventually overflow the headers size
limit and cause failure to authenticate
with HTTP status code 400 “Bad
Request - Header Too Long".
Fixed a problem where ADFS can no
longer ignore "prompt=login" during
authentication. A "Disabled" option was
added to restore scenarios where non-
password authentication is used.
4019217 Work Folders clients using token broker May 2017 Preview Update Rollup
do not work when using a Server 2012
R2 AD FS Server
4015550 Fixed an issue with AD FS not April 2017 Update Rollup

authenticating External users and AD FS
WAP randomly failing to forward
request
4015547 Fixed an issue with AD FS not April 2017 Security Update

authenticating External users and AD FS
WAP randomly failing to forward
request
4012216 MS17-019 This security update resolves March 2017 Update Rollup
a vulnerability in Active Directory
Federation Services (ADFS). The
vulnerability could allow information
disclosure if an attacker sends a specially
crafted request to an AD FS server,
allowing the attacker to read sensitive
information about the target system.
3179574 Fixed issue with AD FS extranet August 2016 Update Rollup

password update.
3172614 Introduced prompt=login support, fixed July 2016 Update Rollup

issue with the AD FS management
console and
AlwaysRequireAuthentication setting.
3163306 Active Directory Federation Services (AD June 2016 Update Rollup
FS) 3.0 can't connect to Lightweight
Directory Access Protocol (LDAP)
attribute stores that are configured to
use Secure Sockets Layer (SSL) port 636
or 3269 in connection string.
3148533 MFA fallback authentication fails May 2016

through ADFS Proxy in Windows Server
2012 R2
3134787 AD FS logs don't contain client IP February 2016

address for account lockout scenarios in
3134222 MS16-020: Security update for Active February 2016

Directory Federation Services to address
denial of service: February 9, 2016
3105881 Can't access applications when device October 2015

authentication is enabled in Windows
Server 2012 R2-based AD FS server
3092003 Page loads repeatedly and August 2015

authentication fails when users use MFA
in Windows Server 2012 R2 AD FS
3080778 AD FS does not call OnError when MFA July 2015

adapter throws an exception in
3075610 Trust relationships are lost on secondary July 2015

AD FS server after you add or remove
claims provider in Windows Server 2012
R2
3070080 Home Realm Discovering not working June 2015

correctly for Non-claims Aware Relying
Party Trust
3052122 Update adds support for compound ID May 2015

claims in AD FS tokens in Windows
Server 2012 R2
3045711 MS15-040: Vulnerability in Active April 2015

Directory Federation Services could
allow information disclosure
3042127 "HTTP 400 - Bad Request" error when March 2015

you open a shared mailbox through
WAP in Windows Server 2012 R2
3042121 AD FS token replay protection for Web March 2015

Application Proxy authentication tokens
in Windows Server 2012 R2
3035025 Hotfix for update password feature so January 2015

that users are not required to use
registered device in Windows Server
2012 R2
3033917 AD FS cannot process SAML response in January 2015

3025080 Operation fails when you try to save an January 2015

Office file through Web Application
Proxy in Windows Server 2012 R2
3025078 You are not prompted for username January 2015

again when you use an incorrect
username to log on to Windows Server
2012 R2
3020813 You are prompted for authentication January 2015

when you run a web application in
Windows Server 2012 R2 AD FS
3020773 Time-out failures after initial January 2015

deployment of Device Registration
service in Windows Server 2012 R2
3018886 You are prompted for a username and January 2015

password two times when you access
Windows Server 2012 R2 AD FS server
from intranet
3013769 Windows Server 2012 R2 Update Roll- December 2014

up
3000850 Windows Server 2012 R2 Update Roll- November 2014

up
2975719 Windows Server 2012 R2 Update Roll- August 2014

up
2967917 Windows Server 2012 R2 Update Roll- July 2014

up
2962409 Windows Server 2012 R2 Update Roll- June 2014

up
2955164 Windows Server 2012 R2 Update Roll- May 2014

up
2919355 Windows Server 2012 R2 Update Roll- April 2014

up
Updates for AD FS in Windows Server 2012 (AD FS 2.1) and AD FS 2.0

Below is the list of hotfixes and update rollups that have been released for AD FS 2.0 and 2.1.
KB # DESCRIPTION DATE RELEASED APPLIES TO:
3197878 Authentication through November 2016 Quality AD FS 2.1

proxy fails in Windows Server Rollup
2012 (this is the general
release of hotfix 3094446)
3197869 Authentication through November 2016 Quality AD FS 2.0

proxy fails in Windows Server Rollup
2008 R2 SP1 (this is the
general release of hotfix
3094446)
3094446 Authentication through September 2015 AD FS 2.0 and 2.1

proxy fails in Windows Server
2012 or Windows Server
2008 R2 SP1
3070078 AD FS 2.1 throws an July 2015 AD FS 2.1

exception when you
authenticate against an
encryption certificate in
Windows Server 2012
3062577 MS15-062: Vulnerability in June 2015 AD FS 2.0 / 2.1

Active Directory federation
services could allow
elevation of privilege
3003381 MS14-077: Vulnerability in November 2014 AD FS 2.0 / 2.1

Active Directory Federation
Services could allow
information disclosure: April
14, 2015
2987843 Memory usage of AD FS July 2014 AD FS 2.1

federation server keeps
increasing when many users
log on a web application in
Windows Server 2012
2957619 The relying party trust in AD May 2014 AD FS 2.1

FS is stopped when a
request is made to AD FS for
a delegated token
2926658 ADFS SQL farm deployment October 2014 AD FS 2.1

fails if you do not have SQL
permissions
KB # DESCRIPTION DATE RELEASED APPLIES TO:
2896713 or 2989956 Update is available to fix November 2013 AD FS 2.0 / 2.1

several issues after you September 2014
install security update
2843638 on an AD FS server
2877424 Update enables you to use October 2013 AD FS 2.1

one certificate for multiple
Relying Party Trusts in an AD
FS 2.1 farm
2873168 FIX: An error occurs when September 2013 AD FS 2.0

you use a third-party CSP
and HSM and then configure
a claims provider trust in
Update Rollup 3 for AD FS
2.0 on Windows Server 2008
R2 Service Pack 1
2861090 A comma in the subject August 2013 AD FS 2.0

name of an encryption
certificate causes an
exception in Windows Server
2008 R2 SP1
2843639 [Security] Vulnerability in November 2013 AD FS 2.1

Services Could Allow
Information Disclosure
2843638 MS13-066: Description of August 2013 AD FS 2.0

the security update for
Services 2.0: August 13,
2013
2827748 Federationmetadata.xml file May 2013 AD FS 2.1

does not contain the MEX
endpoint information for the
WS-Trust and WS-Federation
endpoints in Windows Server
2012
2790338 Description of Update Rollup March 2013 AD FS 2.0

3 for Active Directory
Federation Services (AD FS)
2.0
Setup Geographic Redundancy with SQL Server
Replication
IMPORTANT
If you want to create an AD FS farm and use SQL Server to store your configuration data, you can use SQL Server 2008 or
higher.
If you are using SQL Server as your AD FS configuration database, you can set up geo-redundancy for your AD FS
farm using SQL Server replication. Geo-redundancy replicates data between two geographically distant sites so
that applications can switch from one site to another. This way, in case of the failure of one site, you can still have all
the configuration data available at the second site. For more information, see the “SQL Server geographic
redundancy section” in Federation Server Farm Using SQL Server.
Prerequisites
Install and configure a SQL server farm. For more information, see
https://technet.microsoft.com/evalcenter/hh225126.aspx. On the initial SQL Server, make sure that the SQL Server
Agent service is running and set to automatic start.
Create the second (replica) SQL Server for geo-redundancy

1. Install SQL Server (for more information, see https://technet.microsoft.com/evalcenter/hh225126.aspx.
Copy the resulting CreateDB.sql and SetPermissions.sql script files to the replica SQL server.
2. Ensure SQL Server Agent service is running and set to automatic start
3. Run Export-AdfsDeploymentSQLScript on the primary AD FS node to create CreateDB.sql and
SetPermissions.sql files. For example:
PS:\>Export-AdfsDeploymentSQLScript -DestinationFolder . –ServiceAccountName CONTOSO\gmsa1$ .
4. Copy the scripts to your secondary server. Open the CreateDB.sql script in SQL Management Studio and
click Execute.
5. Open the SetPermissions.sql script in SQL Management Studio and click Execute.
NOTE
You can also use the following from the command line.
c:\>sqlcmd –i CreateDB.sql
c:\>sqlcmd –i SetPermissions.sql
Create publisher settings on the initial SQL Server
1. From the SQL Server Management studio, under Replication, right click Local Publications and choose
New Publication...
2. On the New Publication Wizard screen click Next.

3. On Distributor page, choose local server as distributor and click Next.
4. On the Snapshot folder page, enter \\SQL1\repldata in place of default folder. (NOTE: You may have to
create this share yourself).
5. Choose AdfsConfigurationV3 as the publication database and click Next.
6. On Publication Type, choose Merge publication and click Next.

7. On Subscriber Types, choose SQL Server 2008 or later and click Next.
8. On the Articles page select Tables node to select all tables, then un-check SyncProperties table (this one
should not be replicated)
9. On the Articles page, select User Defined Functions node to select all User Defined Functions and click
Next..
10. On the Article issues page click Next.

11. On the Filter Table Rows page, click Next.
12. On the Snapshot Agent page, choose defaults of Immediate and 14 days, click Next.
You may need to create a domain account for the SQL agent. Use the steps in Configure SQL login for the
domain account CONTOSO\sqlagent to create SQL login for this new AD user and assign specific
permissions.
13. On the Agent Security page, click Security Settings and enter the username/password of a domain
account (not a GMSA) created for the SQL agent and click OK. Click Next.
14. On the Wizard Actions page, click Next.

15. On the Complete the Wizard page, enter a name for your publication and click Finish.
16. Once the publication is created you should see the status of success. Click Close.
17. Back in SQL Server Management Studio, right-click the new Publication and click Launch Replication
Monitor.
Create subscription settings on the replica SQL Server

Make sure that you created the publisher settings on the initial SQL Server as described above and then complete
the following procedure:
1. On the replica SQL Server, from SQL Server Management studio, under Replication, right click Local
Subscriptions and choose New Subscription....
2. On the New Subscription Wizard page, click Next.
3. On the Publication page, select the publisher from the drop-down. Expand AdfsConfigurationV3 and
select the name of the publication created above and click Next.
4. On the Merge Agent Location page, select Run each agent at its Subscriber (pull subscriptions) (the
default) and click Next.
This, along with Subscription Type below, determines the conflict resolution logic. (For more information, see
Detect and Resolve Merge Replication Conflicts.
5. On the Subscribers page, select AdfsConfigurationV3 as the subscriber database and click Next.
6. On the Merge Agent Security page, click ... and enter the username and password of a domain account
(not a GMSA) created for the SQL agent by using the ellipses box and click Next.
7. On Synchronization Schedule, choose Run Continuously and click Next.

8. On Initialize Subscriptions, click Next.
9. On Subscription Type, choose Client and click Next.

Implications of this are documented here and here. Essentially, we take the simple “first to publisher wins”
conflict resolution and we do not need to republish to other subscribers.
10. On the Wizard Actions page, ensure Create the subscription is checked and click Next.
11. On the Complete the Wizard page, click Finish.

12. Once the subscription has finished the creation process, you should see success. Click Close.
Verify the process of initialization and replication

1. On the primary SQL server, right-click the Replication node and click Launch Replication Monitor.
2. In Replication Monitor, click the publication.
3. On the All Subscriptions tab, right click and View Details.
You should be able to see many entries under Actions for the initial replication.
4. Additionally, you can look under the SQL Server Agent\Jobs node to see the job(s) scheduled to execute
the operations of the publication/subscription. Only local jobs are shown, so make sure to check on the
publisher and the subscriber for troubleshooting. Right-click a job and select View History to view
execution history and results.
Configure SQL login for the domain account CONTOSO\sqlagent
1. Create a new login on the primary and replica SQL Server called CONTOSO\sqlagent (the name of the new
domain user created and configured on the Agent Security page in the procedures above.)
2. In SQL Server, right-click the login you created, and select Properties, then under the User Mapping tab,
map this login to AdfsConfiguration and AdfsArtifact databases with public and db_genevaservice roles.
Also map this login to distribution database and add db_owner role for both distribution and
adfsconfiguration tables. Do this as applicable on both primary and replica SQL server. For more
information, see Replication Agent Security Model.
3. Give the corresponding domain account read and write permissions on the share configured as distributor.
Make sure that you set read and write permissions both on the share permissions and the local file
permissions.
Configure AD FS node(s) to point to the SQL Server replica farm

Now that you have set up geo redundancy, the AD FS farm nodes can be configured to point to your replica SQL
Server farm using the standard AD FS “join” farm capabilities, either from the AD FS Configuration Wizard UI or
using Windows PowerShell.
If you use the AD FS Configuration Wizard UI, select Add a federation server to a federation server farm. Do
NOT select Create the first federation server in a federation server farm.
If you use Windows PowerShell, run Add-AdfsFarmNode. Do NOT run Install-AdfsFarm.
When prompted, provide the host and instance name of the replica SQL Server, NOT the initial SQL server.
Set up the lab environment for AD FS in Windows
Server 2012 R2
This topic outlines the steps to configure a test environment that can be used to complete the walkthroughs in the
following walkthrough guides:
Walkthrough Guide: Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications
NOTE
We do not recommend that you install the web server and the federation server on the same computer.
To set up this test environment, complete the following steps:

1. Step 1: Configure the domain controller (DC1)
2. Step 2: Configure the federation server (ADFS1) with Device Registration Service
3. Step 3: Configure the web server (WebServ1) and a sample claims-based application
4. Step 4: Configure the client computer (Client1)
Step 1: Configure the domain controller (DC1)

For the purposes of this test environment, you can call your root Active Directory domain contoso.com and
specify pass@word1 as the administrator password.
Install the AD DS role service and install Active Directory Domain Services (AD DS ) to make your computer a
domain controller in Windows Server 2012 R2 . This action upgrades your AD DS schema as part of the
domain controller creation. For more information and step-by-step instructions,
seehttps://technet.microsoft.com/library/hh472162.aspx.
Create test Active Directory accounts
After your domain controller is functional, you can create a test group and test user accounts in this domain and
add the user account to the group account. You use these accounts to complete the walkthroughs in the
walkthrough guides that are referenced earlier in this topic.
Create the following accounts:
User: Robert Hatley with the following credentials: User name: RobertH and password: P@ssword
Group: Finance
For information about how to create user and group accounts in Active Directory (AD ), see
https://technet.microsoft.com/library/cc783323%28v.aspx.
Add the Robert Hatley account to the Finance group. For information on how to add a user to a group in Active
Directory, see https://technet.microsoft.com/library/cc737130%28v=ws.10%29.aspx.
Create a GMSA account
The group Managed Service Account (GMSA) account is required during the Active Directory Federation Services
(AD FS ) installation and configuration.
To c r e a t e a G M SA a c c o u n t
1. Open a Windows PowerShell command window and type:
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

New-ADServiceAccount FsGmsa -DNSHostName adfs1.contoso.com -ServicePrincipalNames http/adfs1.contoso.com
Step 2: Configure the federation server (ADFS1) by using Device

Registration Service
To set up another virtual machine, install Windows Server 2012 R2 and connect it to the domain contoso.com. Set
up the computer after you have joined it to the domain, and then proceed to install and configure the AD FS role.
For a video, see Active Directory Federation Services How -To Video Series: Installing an AD FS Server Farm.
Install a server SSL certificate
You must install a server Secure Socket Layer (SSL ) certificate on the ADFS1 server in the local computer store.
The certificate MUST have the following attributes:
Subject Name (CN ): adfs1.contoso.com
Subject Alternative Name (DNS ): adfs1.contoso.com
Subject Alternative Name (DNS ): enterpriseregistration.contoso.com
For more information about setting up SSL certificates, see Configure SSL/TLS on a Web site in the domain with
an Enterprise CA.
Active Directory Federation Services How -To Video Series: Updating Certificates.
Install the AD FS server role
To i n st a l l t h e F e d e r a t i o n Se r v i c e r o l e se r v i c e
1. Log on to the server by using the domain administrator account administrator@contoso.com.

2. Start Server Manager. To start Server Manager, click Server Manager on the Windows Start screen, or
click Server Manager on the Windows taskbar on the Windows desktop. On the Quick Start tab of the
Welcome tile on the Dashboard page, click Add roles and features. Alternatively, you can click Add
Roles and Features on the Manage menu.
4. On the Select installation type page, click Role-based or feature-based installation, and then click
Next.
5. On the Select destination server page, click Select a server from the server pool, verify that the target
computer is selected, and then click Next.
6. On the Select server roles page, click Active Directory Federation Services, and then click Next.
8. On the Active Directory Federation Service (AD FS ) page, click Next.
9. After you verify the information on the Confirm installation selections page, select the Restart the
destination server automatically if required check box, and then click Install.
10. On the Installation progress page, verify that everything installed correctly, and then click Close.
Configure the federation server
The next step is to configure the federation server.
To c o n fi g u r e t h e fe d e r a t i o n se r v e r
1. On the Server Manager Dashboard page, click the Notifications flag, and then click Configure the
federation service on the server.
The Active Directory Federation Service Configuration Wizard opens.
2. On the Welcome page, select Create the first federation server in a federation server farm, and then
click Next.
3. On the Connect to AD DS page, specify an account with domain administrator rights for the contoso.com
Active Directory domain that this computer is joined to, and then click Next.
4. On the Specify Service Properties page, do the following, and then click Next:
Import the SSL certificate that you have obtained earlier. This certificate is the required service
authentication certificate. Browse to the location of your SSL certificate.
To provide a name for your federation service, type adfs1.contoso.com. This value is the same value
that you provided when you enrolled an SSL certificate in Active Directory Certificate Services (AD
CS ).
To provide a display name for your federation service, type Contoso Corporation.
5. On the Specify Service Account page, select Use an existing domain user account or group
Managed Service Account, and then specify the GMSA account fsgmsa that you created when you
created the domain controller.
6. On the Specify Configuration Database page, select Create a database on this server using Windows
Internal Database, and then click Next.
7. On the Review Options page, verify your configuration selections, and then click Next.
8. On the Pre-requisite Checks page, verify that all prerequisite checks were successfully completed, and then
click Configure.
9. On the Results page, review the results, check whether the configuration has completed successfully, and
then click Next steps required for completing your federation service deployment.
Configure Device Registration Service
The next step is to configure Device Registration Service on the ADFS1 server. For a video, see Active Directory
Federation Services How -To Video Series: Enabling the Device Registration Service.
To c o n fi g u r e D e v i c e R e g i st r a t i o n Se r v i c e fo r W i n d o w s Se r v e r 2 0 1 2 R T M
1. IMPORTANT
The following step applies to the Windows Server 2012 R2 RTM build.
Open a Windows PowerShell command window and type:

Initialize-ADDeviceRegistration
When you are prompted for a service account, type contoso\fsgmsa$.

Now run the Windows PowerShell cmdlet.
Enable-AdfsDeviceRegistration
2. On the ADFS1 server, in the AD FS Management console, navigate to Authentication Policies. Select
Edit Global Primary Authentication. Select the check box next to Enable Device Authentication, and
then click OK.
Add Host (A ) and Alias (CNAME) Resource Records to DNS
On DC1, you must ensure that the following Domain Name System (DNS ) records are created for Device
Registration Service.
ENTRY TYPE ADDRESS
adfs1 Host (A) IP address of the AD FS server
enterpriseregistration Alias (CNAME) adfs1.contoso.com
You can use the following procedure to add a host (A) resource record to corporate DNS name servers for the
federation server and Device Registration Service.
Membership in the Administrators group or an equivalent is the minimum requirement to complete this procedure.
Review details about using the appropriate accounts and group memberships in the HYPERLINK
"https://go.microsoft.com/fwlink/?LinkId=83477" Local and Domain Default Groups
(https://go.microsoft.com/fwlink/p/?LinkId=83477).
To a d d a h o st (A ) a n d a l i a s (C N A M E) r e so u r c e r e c o r d s t o D N S fo r y o u r fe d e r a t i o n se r v e r
1. On DC1, from Server Manager, on the Tools menu, click DNS to open the DNS snap-in.
2. In the console tree, expand DC1, expand Forward Lookup Zones, right-click contoso.com, and then click
New Host (A or AAAA ).
3. In Name, type the name you want to use for your AD FS farm. For this walkthrough, type adfs1.
4. In IP address, type the IP address of the ADFS1 server. Click Add Host.
5. Right-click contoso.com, and then click New Alias (CNAME ).
6. In the New Resource Record dialog box, type enterpriseregistration in the Alias name box.
7. In the Fully Qualified Domain Name (FQDN ) of the target host box, type adfs1.contoso.com, and then click
OK.
IMPORTANT
In a real-world deployment, if your company has multiple user principal name (UPN) suffixes, you must create multiple
CNAME records, one for each of those UPN suffixes in DNS.
Step 3: Configure the web server (WebServ1) and a sample claims-

based application
Set up a virtual machine (WebServ1) by installing the Windows Server 2012 R2 operating system and connect it to
the domain contoso.com. After it is joined to the domain, you can proceed to install and configure the Web Server
role.
To complete the walkthroughs that were referenced earlier in this topic, you must have a sample application that is
secured by your federation server (ADFS1).
You can download Windows Identity Foundation SDK (https://www.microsoft.com/download/details.aspx?
id=4451, which includes a sample claims-based application.
You must complete the following steps to set up a web server with this sample claims-based application.
NOTE
These steps have been tested on a web server that runs the Windows Server 2012 R2 operating system.
1. Install the Web Server Role and Windows Identity Foundation

2. Install Windows Identity Foundation SDK
3. Configure the simple claims app in IIS
4. Create a relying party trust on your federation server
Install the Web Server role and Windows Identity Foundation
1. NOTE
You must have access to the Windows Server 2012 R2 installation media.
Log on to WebServ1 by using administrator@contoso.com and the password pass@word1.

2. From Server Manager, on the Quick Start tab of the Welcome tile on the Dashboard page, click Add
roles and features. Alternatively, you can click Add Roles and Features on the Manage menu.
Next.
6. On the Select server roles page, select the check box next to Web Server (IIS ), click Add Features, and
then click Next.
7. On the Select features page, select Windows Identity Foundation 3.5, and then click Next.
8. On the Web Server Role (IIS ) page, click Next.
9. On the Select role services page, select and expand Application Development. Select ASP.NET 3.5,
click Add Features, and then click Next.
10. On the Confirm installation selections page, click Specify an alternate source path. Enter the path to
the Sxs directory that is located in the Windows Server 2012 R2 installation media. For example
D:\Sources\Sxs. Click OK, and then click Install.
Install Windows Identity Foundation SDK
1. Run WindowsIdentityFoundation-SDK-3.5.msi to install Windows Identity Foundation SDK 3.5
(https://www.microsoft.com/download/details.aspx?id=4451). Choose all of the default options.
Configure the simple claims app in IIS
1. Install a valid SSL certificate in the computer certificate store. The certificate should contain the name of
your web server, webserv1.contoso.com.
2. Copy the contents of C:\Program Files (x86)\Windows Identity Foundation SDK\v3.5\Samples\Quick
Start\Web Application\PassiveRedirectBasedClaimsAwareWebApp to C:\Inetpub\Claimapp.
3. Edit the Default.aspx.cs file so that no claim filtering takes place. This step is performed to ensure that the
sample application displays all the claims that are issued by the federation server. Do the following:
a. Open Default.aspx.cs in a text editor.
b. Search the file for the second instance of ExpectedClaims .
c. Comment out the entire IF statement and its braces. Indicate comments by typing "//" (without the
quotes) at the beginning of a line.
d. Your FOREACH statement should now look like this code example.
Foreach (claim claim in claimsIdentity.Claims)

{
//Before showing the claims validate that this is an expected claim
//If it is not in the expected claims list then don't show it
//if (ExpectedClaims.Contains( claim.ClaimType ) )
// {
writeClaim( claim, table );
//}
}
e. Save and close Default.aspx.cs.

f. Open web.config in a text editor.
g. Remove the entire <microsoft.identityModel> section. Remove everything starting from
including <microsoft.identityModel> and up to and including </microsoft.identityModel> .
h. Save and close web.config.
4. Configure IIS Manager
a. Open Internet Information Services (IIS ) Manager.
b. Go to Application Pools, right-click DefaultAppPool to select Advanced Settings. Set Load User
Profile to True, and then click OK.
c. Right-click DefaultAppPool to select Basic Settings. Change the .NET CLR Version to .NET CLR
Version v2.0.50727.
d. Right-click Default Web Site to select Edit Bindings.
e. Add an HTTPS binding to port 443 with the SSL certificate that you have installed.
f. Right-click Default Web Site to select Add Application.
g. Set the alias to claimapp and the physical path to c:\inetpub\claimapp.
5. To configure claimapp to work with your federation server, do the following:
a. Run FedUtil.exe, which is located in C:\Program Files (x86)\Windows Identity Foundation
SDK\v3.5.
b. Set the application configuration location to C:\inetput\claimapp\web.config and set the
application URI to the URL for your site, https://webserv1.contoso.com /claimapp/. Click Next.
c. Select Use an existing STS and browse to your AD FS server's metadata URL
https://adfs1.contoso.com/federationmetadata/2007-06/federationmetadata.xml. Click
Next.
d. Select Disable certificate chain validation, and then click Next.
e. Select No encryption, and then click Next. On the Offered claims page, click Next.
f. Select the check box next to Schedule a task to perform daily WS -Federation metadata
updates. Click Finish.
g. Your sample application is now configured. If you test the application URL
https://webserv1.contoso.com/claimapp, it should redirect you to your federation server. The
federation server should display an error page because you have not yet configured the relying party
trust. In other words, you have not secured this test application by AD FS.
You must now secure your sample application that runs on your web server with AD FS. You can do this by adding
a relying party trust on your federation server (ADFS1). For a video, see Active Directory Federation Services How -
To Video Series: Add a Relying Party Trust.
Create a relying party trust on your federation server
1. On you federation server (ADFS1), in the AD FS Management console, navigate to Relying Party Trusts,
and then click Add Relying Party Trust.
2. On the Select Data Source page, select Import data about the relying party published online or on a
local network, enter the metadata URL for claimapp, and then click Next. Running FedUtil.exe created a
metadata .xml file. It is located at https://webserv1.contoso.com/claimapp/federationmetadata/2007-
06/federationmetadata.xml.
3. On the Specify Display Name page, specify the display name for your relying party trust, claimapp, and
then click Next.
4. On the Configure Multi-factor Authentication Now? page, select I do not want to specify multi-
factor authentication setting for this relying party trust at this time, and then click Next.
5. On the Choose Issuance Authorization Rules page, select Permit all users to access this relying party,
6. On the Ready to Add Trust page, click Next.
7. On the Edit Claim Rules dialog box, click Add Rule.
8. On the Choose Rule Type page, select Send Claims Using a Custom Rule, and then click Next.
9. On the Configure Claim Rule page, in the Claim rule name box, type All Claims. In the Custom rule
box, type the following claim rule.
c:[ ]
=> issue(claim = c);
10. Click Finish, and then click OK.
Step 4: Configure the client computer (Client1)

Set up another virtual machine and install Windows 8.1. This virtual machine must be on the same virtual network
as the other machines. This machine should NOT be joined to the Contoso domain.
The client MUST trust the SSL certificate that is used for the federation server (ADFS1), which you set up in Step 2:
Configure the federation server (ADFS1) with Device Registration Service. It must also be able to validate
certificate revocation information for the certificate.
You also must set up and use a Microsoft account to log on to Client1.
See Also
Active Directory Federation Services How -To Video Series: Installing an AD FS Server Farm
Active Directory Federation Services How -To Video Series: Updating Certificates
Active Directory Federation Services How -To Video Series: Add a Relying Party Trust
Active Directory Federation Services How -To Video Series: Enabling the Device Registration Service
Active Directory Federation Services How -To Video Series: Installing the Web Application Proxy
Upgrading to AD FS in Windows Server 2016 using a
WID database
Applies To: Windows Server 2019, Windows Server 2016
Upgrading a Windows Server 2012 R2 or 2016 AD FS farm to Windows

Server 2019
The following document will describe how to upgrade your AD FS farm to AD FS in Windows Server 2019 when
you are using a WID database.
AD FS Farm Behavior Levels (FBL )
In AD FS for Windows Server 2016, the farm behavior level (FBL ) was introduced. This is farm-wide setting that
determines the features the AD FS farm can use.
The following table lists the FBL values by Windows Server version:
WINDOWS SERVER VERSION FBL AD FS CONFIGURATION DATABASE NAME
2012 R2 1 AdfsConfiguration
2016 3 AdfsConfigurationV3
2019 4 AdfsConfigurationV4
NOTE
Upgrading the FBL creates a new AD FS configuration database. See the table above for the names of the configuration
database for each Windows Server AD FS version and FBL value
New vs Upgraded farms

By default, the FBL in a new AD FS farm matches the value for the Windows Server version of the first farm node
installed.
An AD FS server of a later version can be joined to an AD FS 2012 R2 or 2016 farm, and the farm will operate at
the same FBL as the existing node(s). When you have multiple Windows Server versions operating in the same
farm at the FBL value of the lowest version, your farm is said to be "mixed". However, you will not be able to take
advantage of the features of the later versions until the FBL is raised. With a mixed farm:
Administrators can add new Windows Server 2019 federation servers to an existing Windows Server 2012
R2 or 2016 farm. As a result, the farm is in "mixed mode" and operates at the same farm behavior level as
the original farm. To ensure consistent behavior across the farm, features of the newer Windows Server AD
FS versions cannot be configured or used.
Before the FBL can be raised, administrators must remove the AD FS nodes of previous Windows Server
versions from the farm. In the case of a WID farm, note that this requires one of the new Windows Server
2019 federation servers tp be promoted to the role of primary node in the farm.
Once all federation servers in the farm are at the same Windows Server version, the FBL can be raised. As a
result, any new AD FS Windows Server 2019 features can then be configured and used.
Be aware that while in mixed farm mode, the AD FS farm is not capable of any new features or functionality
introduced in AD FS in Windows Server 2019. This means organizations that want to try out new features cannot
do this until the FBL is raised. So if your organization is looking to test the new features prior to rasing the FBL,
you will need to deploy a separate farm to do this.
The remainder of the is document provides the steps for adding a Windows Server 2019 federation server to a
Windows Server 2016 or 2012 R2 environment and then raising the FBL to Windows Server 2019. These steps
were performed in a test environment outlined by the architectural diagram below.
NOTE
Before you can move to AD FS in Windows Server 2019 FBL, you must remove all of the Windows Server 2016 or 2012 R2
nodes. You cannot just upgrade a Windows Server 2016 or 2012 R2 OS to Windows Server 2019 and have it become a 2019
node. You will need to remove it and replace it with a new 2019 node.
To u p g r a d e y o u r A D F S fa r m t o W i n d o w s Se r v e r 2 0 1 9 F a r m B e h a v i o r L e v e l
1. Using Server Manager, install the Active Directory Federation Services Role on the Windows Server 2019
2. Using the AD FS Configuration wizard, join the new Windows Server 2019 server to the existing AD FS
farm.
3. On the Windows Server 2019 federation server, open AD FS management. Note that management
capabilities are not available because this federation server is not the primary server.
4. On the Windows Server 2019 server, open an elevated PowerShell command window and run the following
cmdlt: Set-AdfsSyncProperties -Role PrimaryComputer
5. On the AD FS server that was previously configured as primary, open an elevated PowerShell command
window and run the following cmdlt:
Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName {FQDN}
6. On each Web Application Proxy, re-configure the WAP by executing the following PowerShell command in
an elevated window:
$trustcred = Get-Credential -Message "Enter Domain Administrator credentials"

Install-WebApplicationProxy -CertificateThumbprint {SSLCert} -fsname fsname -
FederationServiceTrustCredential $trustcred
7. Now on the Windows Server 2016 federation server open AD FS Management. Note that now all of the
admin capabilities appear because the primary role has been transferred to this server.
8. If you are upgrading an AD FS 2012 R2 farm to 2016 or 2019, the farm upgrade requires the AD schema to
be at least level 85. To upgrade the schema, With the Windows Server 2016 installation media, open a
command prompt and navigate to support\adprep directory. Run the following: adprep /forestprep
Once that completes run adprep/domainprep
NOTE
Prior to running the next step, ensure Windows Server is current by running Windows Update from Settings.
Continue this process until no further updates are needed.
9. Now on the Windows Server 2016 Server open PowerShell and run the following cmdlt:
NOTE
All 2012 R2 servers must be removed from the farm before running the next step.
Invoke-AdfsFarmBehaviorLevelRaise
10. When prompted, type Y. This will begin raising the level. Once this completes you have successfully raised
the FBL.
11. Now, if you go to AD FS Management, you will see the new capabilities have been added for the later AD
FS version
12. Likewise, you can use the PowerShell cmdlt: Get-AdfsFarmInformation to show you the current FBL.
Deploying Active Directory Federation Services in
Azure
AD FS provides simplified, secured identity federation and Web single sign-on (SSO ) capabilities. Federation with
Azure AD or O365 enables users to authenticate using on-premises credentials and access all resources in cloud.
As a result, it becomes important to have a highly available AD FS infrastructure to ensure access to resources
both on-premises and in the cloud. Deploying AD FS in Azure can help achieve the high availability required with
minimal efforts. There are several advantages of deploying AD FS in Azure, a few of them are listed below:
High Availability - With the power of Azure Availability Sets, you ensure a highly available infrastructure.
Easy to Scale – Need more performance? Easily migrate to more powerful machines by just a few clicks in
Azure
Cross-Geo Redundancy – With Azure Geo Redundancy you can be assured that your infrastructure is highly
available across the globe
Easy to Manage – With highly simplified management options in Azure portal, managing your infrastructure
is very easy and hassle-free
Design principles
The diagram above shows the recommended basic topology to start deploying your AD FS infrastructure in
Azure. The principles behind the various components of the topology are listed below:
DC / ADFS Servers: If you have fewer than 1,000 users you can simply install AD FS role on your domain
controllers. If you do not want any performance impact on the domain controllers or if you have more than
1,000 users, then deploy AD FS on separate servers.
WAP Server – it is necessary to deploy Web Application Proxy servers, so that users can reach the AD FS
when they are not on the company network also.
DMZ: The Web Application Proxy servers will be placed in the DMZ and ONLY TCP/443 access is allowed
between the DMZ and the internal subnet.
Load Balancers: To ensure high availability of AD FS and Web Application Proxy servers, we recommend
using an internal load balancer for AD FS servers and Azure Load Balancer for Web Application Proxy servers.
Availability Sets: To provide redundancy to your AD FS deployment, it is recommended that you group two
or more virtual machines in an Availability Set for similar workloads. This configuration ensures that during
either a planned or unplanned maintenance event, at least one virtual machine will be available
Storage Accounts: It is recommended to have two storage accounts. Having a single storage account can lead
to creation of a single point of failure and can cause the deployment to become unavailable in an unlikely
scenario where the storage account goes down. Two storage accounts will help associate one storage account
for each fault line.
Network segregation: Web Application Proxy servers should be deployed in a separate DMZ network. You
can divide one virtual network into two subnets and then deploy the Web Application Proxy server(s) in an
isolated subnet. You can simply configure the network security group settings for each subnet and allow only
required communication between the two subnets. More details are given per deployment scenario below
Steps to deploy AD FS in Azure

The steps mentioned in this section outline the guide to deploy the below depicted AD FS infrastructure in Azure.
1. Deploying the network
As outlined above, you can either create two subnets in a single virtual network or else create two completely
different virtual networks (VNet). This article will focus on deploying a single virtual network and divide it into two
subnets. This is currently an easier approach as two separate VNets would require a VNet to VNet gateway for
communications.
1.1 Create virtual network
In the Azure portal, select virtual network and you can deploy the virtual network and one subnet immediately
with just one click. INT subnet is also defined and is ready now for VMs to be added. The next step is to add
another subnet to the network, i.e. the DMZ subnet. To create the DMZ subnet, simply
Select the newly created network
In the properties select subnet
In the subnet panel click on the add button
Provide the subnet name and address space information to create the subnet
1.2. Creating the network security groups

A Network security group (NSG ) contains a list of Access Control List (ACL ) rules that allow or deny network
traffic to your VM instances in a Virtual Network. NSGs can be associated with either subnets or individual VM
instances within that subnet. When an NSG is associated with a subnet, the ACL rules apply to all the VM
instances in that subnet. For the purpose of this guidance, we will create two NSGs: one each for an internal
network and a DMZ. They will be labeled NSG_INT and NSG_DMZ respectively.
After the NSG is created, there will be 0 inbound and 0 outbound rules. Once the roles on the respective servers
are installed and functional, then the inbound and outbound rules can be made according to the desired level of
security.
After the NSGs are created, associate NSG_INT with subnet INT and NSG_DMZ with subnet DMZ. An example
screenshot is given below:
Click on Subnets to open the panel for subnets
Select the subnet to associate with the NSG
After configuration, the panel for Subnets should look like below:
1.3. Create Connection to on-premises

We will need a connection to on-premises in order to deploy the domain controller (DC ) in azure. Azure offers
various connectivity options to connect your on-premises infrastructure to your Azure infrastructure.
Point-to-site
Virtual Network Site-to-site
ExpressRoute
It is recommended to use ExpressRoute. ExpressRoute lets you create private connections between Azure
datacenters and infrastructure that’s on your premises or in a co-location environment. ExpressRoute connections
do not go over the public Internet. They offer more reliability, faster speeds, lower latencies and higher security
than typical connections over the Internet. While it is recommended to use ExpressRoute, you may choose any
connection method best suited for your organization. To learn more about ExpressRoute and the various
connectivity options using ExpressRoute, read ExpressRoute technical overview.
2. Create storage accounts
In order to maintain high availability and avoid dependence on a single storage account, you can create two
storage accounts. Divide the machines in each availability set into two groups and then assign each group a
separate storage account.
3. Create availability sets
For each role (DC/AD FS and WAP ), create availability sets that will contain 2 machines each at the minimum. This
will help achieve higher availability for each role. While creating the availability sets, it is essential to decide on the
following:
Fault Domains: Virtual machines in the same fault domain share the same power source and physical network
switch. A minimum of 2 fault domains are recommended. The default value is 3 and you can leave it as is for
the purpose of this deployment
Update domains: Machines belonging to the same update domain are restarted together during an update.
You want to have minimum of 2 update domains. The default value is 5 and you can leave it as is for the
purpose of this deployment
Create the following availability sets
AVAILABILITY SET ROLE FAULT DOMAINS UPDATE DOMAINS
contosodcset DC/ADFS 3 5
contosowapset WAP 3 5
4. Deploy virtual machines

The next step is to deploy virtual machines that will host the different roles in your infrastructure. A minimum of
two machines are recommended in each availability set. Create four virtual machines for the basic deployment.
STORAGE
MACHINE ROLE SUBNET AVAILABILITY SET ACCOUNT IP ADDRESS
contosodc1 DC/ADFS INT contosodcset contososac1 Static
contosodc2 DC/ADFS INT contosodcset contososac2 Static

STORAGE
MACHINE ROLE SUBNET AVAILABILITY SET ACCOUNT IP ADDRESS
contosowap1 WAP DMZ contosowapset contososac1 Static
contosowap2 WAP DMZ contosowapset contososac2 Static
As you might have noticed, no NSG has been specified. This is because azure lets you use NSG at the subnet level.
Then, you can control machine network traffic by using the individual NSG associated with either the subnet or
else the NIC object. Read more on What is a Network Security Group (NSG ). Static IP address is recommended if
you are managing the DNS. You can use Azure DNS and instead in the DNS records for your domain, refer to the
new machines by their Azure FQDNs. Your virtual machine pane should look like below after the deployment is
completed:
5. Configuring the domain controller / AD FS servers

In order to authenticate any incoming request, AD FS will need to contact the domain controller. To save the costly
trip from Azure to on-premises DC for authentication, it is recommended to deploy a replica of the domain
controller in Azure. In order to attain high availability, it is recommended to create an availability set of at-least 2
domain controllers.
DOMAIN CONTROLLER ROLE STORAGE ACCOUNT
contosodc1 Replica contososac1
contosodc2 Replica contososac2
Promote the two servers as replica domain controllers with DNS

Configure the AD FS servers by installing the AD FS role using the server manager.
6. Deploying Internal Load Balancer (ILB )
6.1. Create the ILB
To deploy an ILB, select Load Balancers in the Azure portal and click on add (+).
NOTE
if you do not see Load Balancers in your menu, click Browse in the lower left of the portal and scroll until you see Load
Balancers. Then click the yellow star to add it to your menu. Now select the new load balancer icon to open the panel to
begin configuration of the load balancer.
Name: Give any suitable name to the load balancer
Scheme: Since this load balancer will be placed in front of the AD FS servers and is meant for internal network
connections ONLY, select “Internal”
Virtual Network: Choose the virtual network where you are deploying your AD FS
Subnet: Choose the internal subnet here
IP Address assignment: Static
After you click create and the ILB is deployed, you should see it in the list of load balancers:
Next step is to configure the backend pool and the backend probe.
6.2. Configure ILB backend pool
Select the newly created ILB in the Load Balancers panel. It will open the settings panel.
1. Select backend pools from the settings panel
2. In the add backend pool panel, click on add virtual machine
3. You will be presented with a panel where you can choose availability set
4. Choose the AD FS availability set
6.3. Configuring probe
In the ILB settings panel, select Health probes.
1. Click on add
2. Provide details for probe a. Name: Probe name b. Protocol: HTTP c. Port: 80 (HTTP ) d. Path: /adfs/probe e.
Interval: 5 (default value) – this is the interval at which ILB will probe the machines in the backend pool f.
Unhealthy threshold limit: 2 (default value) – this is the threshold of consecutive probe failures after which
ILB will declare a machine in the backend pool non-responsive and stop sending traffic to it.
We are using the /adfs/probe endpoint that was created explictly for health checks in an AD FS environment
where a full HTTPS path check cannot happen. This is substantially better than a basic port 443 check, which does
not accurately reflect the status of a modern AD FS deployment. More information on this can be found at
https://blogs.technet.microsoft.com/applicationproxyblog/2014/10/17/hardware-load-balancer-health-checks-
and-web-application-proxy-ad-fs-2012-r2/.
6.4. Create load balancing rules
In order to effectively balance the traffic, the ILB should be configured with load balancing rules. In order to create
a load balancing rule,
1. Select Load balancing rule from the settings panel of the ILB
2. Click on Add in the Load balancing rule panel
3. In the Add load balancing rule panel a. Name: Provide a name for the rule b. Protocol: Select TCP c. Port: 443
d. Backend port: 443 e. Backend pool: Select the pool you created for the AD FS cluster earlier f. Probe:
Select the probe created for AD FS servers earlier
6.5. Update DNS with ILB
Go to your DNS server and create a CNAME for the ILB. The CNAME should be for the federation service with
the IP address pointing to the IP address of the ILB. For example if the ILB DIP address is 10.3.0.8, and the
federation service installed is fs.contoso.com, then create a CNAME for fs.contoso.com pointing to 10.3.0.8. This
will ensure that all communication regarding fs.contoso.com end up at the ILB and are appropriately routed.
7. Configuring the Web Application Proxy server
7.1. Configuring the Web Application Proxy servers to reach AD FS servers
In order to ensure that Web Application Proxy servers are able to reach the AD FS servers behind the ILB, create a
record in the %systemroot%\system32\drivers\etc\hosts for the ILB. Note that the distinguished name (DN )
should be the federation service name, for example fs.contoso.com. And the IP entry should be that of the ILB’s IP
address (10.3.0.8 as in the example).
7.2. Installing the Web Application Proxy role
After you ensure that Web Application Proxy servers are able to reach the AD FS servers behind ILB, you can next
install the Web Application Proxy servers. Web Application Proxy servers need not be joined to the domain. Install
the Web Application Proxy roles on the two Web Application Proxy servers by selecting the Remote Access role.
The server manager will guide you to complete the WAP installation. For more information on how to deploy
WAP, read Install and Configure the Web Application Proxy Server.
8. Deploying the Internet Facing (Public) Load Balancer
8.1. Create Internet Facing (Public) Load Balancer
In the Azure portal, select Load balancers and then click on Add. In the Create load balancer panel, enter the
following information
1. Name: Name for the load balancer
2. Scheme: Public – this option tells Azure that this load balancer will need a public address.
3. IP Address: Create a new IP address (dynamic)
After deployment, the load balancer will appear in the Load balancers list.
8.2. Assign a DNS label to the public IP

Click on the newly created load balancer entry in the Load balancers panel to bring up the panel for configuration.
Follow below steps to configure the DNS label for the public IP:
1. Click on the public IP address. This will open the panel for the public IP and its settings
2. Click on Configuration
3. Provide a DNS label. This will become the public DNS label that you can access from anywhere, for example
contosofs.westus.cloudapp.azure.com. You can add an entry in the external DNS for the federation service (like
fs.contoso.com) that resolves to the DNS label of the external load balancer
(contosofs.westus.cloudapp.azure.com).
8.3. Configure backend pool for Internet Facing (Public) Load Balancer
Follow the same steps as in creating the internal load balancer, to configure the backend pool for Internet Facing
(Public) Load Balancer as the availability set for the WAP servers. For example, contosowapset.
8.4. Configure probe
Follow the same steps as in configuring the internal load balancer to configure the probe for the backend pool of
WAP servers.
8.5. Create load balancing rule(s)

Follow the same steps as in ILB to configure the load balancing rule for TCP 443.
9. Securing the network
9.1. Securing the internal subnet
Overall, you need the following rules to efficiently secure your internal subnet (in the order as listed below )
RULE DESCRIPTION FLOW
AllowHTTPSFromDMZ Allow the HTTPS communication from Inbound

DMZ
DenyInternetOutbound No access to internet Outbound
9.2. Securing the DMZ subnet
RULE DESCRIPTION FLOW
AllowHTTPSFromInternet Allow HTTPS from internet to the DMZ Inbound
DenyInternetOutbound Anything except HTTPS to internet is Outbound

blocked
NOTE
If client user certificate authentication (clientTLS authentication using X509 user certificates) is required, then AD FS requires
TCP port 49443 be enabled for inbound access.
10. Test the AD FS sign-in

The easiest way is to test AD FS is by using the IdpInitiatedSignon.aspx page. In order to be able to do that, it is
required to enable the IdpInitiatedSignOn on the AD FS properties. Follow the steps below to verify your AD FS
setup
1. Run the below cmdlet on the AD FS server, using PowerShell, to set it to enabled. Set-AdfsProperties -
EnableIdPInitiatedSignonPage $true
2. From any external machine, access https://adfs-server.contoso.com/adfs/ls/IdpInitiatedSignon.aspx.
3. You should see the AD FS page like below:
On successful sign-in, it will provide you with a success message as shown below:
Template for deploying AD FS in Azure

The template deploys a 6 machine setup, 2 each for Domain Controllers, AD FS and WAP.
AD FS in Azure Deployment Template
You can use an existing virtual network or create a new VNET while deploying this template. The various
parameters available for customizing the deployment are listed below with the description of usage of the
parameter in the deployment process.
PARAMETER DESCRIPTION
Location The region to deploy the resources into, e.g. East US.
StorageAccountType The type of the Storage Account created
VirtualNetworkUsage Indicates if a new virtual network will be created or use an

existing one
VirtualNetworkName The name of the Virtual Network to Create, mandatory on

both existing or new virtual network usage
VirtualNetworkResourceGroupName Specifies the name of the resource group where the existing
virtual network resides. When using an existing virtual
network, this becomes a mandatory parameter so the
deployment can find the ID of the existing virtual network
VirtualNetworkAddressRange The address range of the new VNET, mandatory if creating a

new virtual network
InternalSubnetName The name of the internal subnet, mandatory on both virtual

network usage options (new or existing)
InternalSubnetAddressRange The address range of the internal subnet, which contains the
Domain Controllers and ADFS servers, mandatory if creating a
new virtual network.
DMZSubnetAddressRange The address range of the dmz subnet, which contains the
Windows application proxy servers, mandatory if creating a
new virtual network.
DMZSubnetName The name of the internal subnet, mandatory on both virtual

network usage options (new or existing).
ADDC01NICIPAddress The internal IP address of the first Domain Controller, this IP

address will be statically assigned to the DC and must be a
valid ip address within the Internal subnet
ADDC02NICIPAddress The internal IP address of the second Domain Controller, this

IP address will be statically assigned to the DC and must be a
ADFS01NICIPAddress The internal IP address of the first ADFS server, this IP address
will be statically assigned to the ADFS server and must be a
ADFS02NICIPAddress The internal IP address of the second ADFS server, this IP

address will be statically assigned to the ADFS server and
must be a valid ip address within the Internal subnet
WAP01NICIPAddress The internal IP address of the first WAP server, this IP address
will be statically assigned to the WAP server and must be a
valid ip address within the DMZ subnet
WAP02NICIPAddress The internal IP address of the second WAP server, this IP

address will be statically assigned to the WAP server and must
be a valid ip address within the DMZ subnet
ADFSLoadBalancerPrivateIPAddress The internal IP address of the ADFS load balancer, this IP

address will be statically assigned to the load balancer and
must be a valid ip address within the Internal subnet
ADDCVMNamePrefix Virtual Machine name prefix for Domain Controllers
ADFSVMNamePrefix Virtual Machine name prefix for ADFS servers
WAPVMNamePrefix Virtual Machine name prefix for WAP servers
ADDCVMSize The vm size of the Domain Controllers
ADFSVMSize The vm size of the ADFS servers
WAPVMSize The vm size of the WAP servers
AdminUserName The name of the local Administrator of the virtual machines

AdminPassword The password for the local Administrator account of the

virtual machines
Additional resources
Availability Sets
Azure Load Balancer
Internal Load Balancer
Internet Facing Load Balancer
Storage Accounts
Azure Virtual Networks
AD FS and Web Application Proxy Links
Next steps
Integrating your on-premises identities with Azure Active Directory
Configuring and managing your AD FS using Azure AD Connect
High availability cross-geographic AD FS deployment in Azure with Azure Traffic Manager
High availability cross-geographic AD FS deployment
in Azure with Azure Traffic Manager
AD FS deployment in Azure provides step-by-step guideline as to how you can deploy a simple AD FS
infrastructure for your organization in Azure. This article provides the next steps to create a cross-geographic
deployment of AD FS in Azure using Azure Traffic Manager. Azure Traffic Manager helps create a geographically
spread high availability and high-performance AD FS infrastructure for your organization by making use of range
of routing methods available to suit different needs from the infrastructure.
A highly available cross-geographic AD FS infrastructure enables:
Elimination of single point of failure: With failover capabilities of Azure Traffic Manager, you can achieve a
highly available AD FS infrastructure even when one of the data centers in a part of the globe goes down
Improved performance: You can use the suggested deployment in this article to provide a high-performance
AD FS infrastructure that can help users authenticate faster.
Design principles
The basic design principles will be same as listed in Design principles in the article AD FS deployment in Azure.
The diagram above shows a simple extension of the basic deployment to another geographical region. Below are
some points to consider when extending your deployment to new geographical region
Virtual network: You should create a new virtual network in the geographical region you want to deploy
additional AD FS infrastructure. In the diagram above you see Geo1 VNET and Geo2 VNET as the two virtual
networks in each geographical region.
Domain controllers and AD FS servers in new geographical VNET: It is recommended to deploy domain
controllers in the new geographical region so that the AD FS servers in the new region do not have to contact a
domain controller in another far away network to complete an authentication and thereby improving the
performance.
Storage accounts: Storage accounts are associated with a region. Since you will be deploying machines in a
new geographic region, you will have to create new storage accounts to be used in the region.
Network Security Groups: As storage accounts, Network Security Groups created in a region cannot be used
in another geographical region. Therefore, you will need to create new network security groups similar to those
in the first geographical region for INT and DMZ subnet in the new geographical region.
DNS Labels for public IP addresses: Azure Traffic Manager can refer to endpoints ONLY via DNS labels.
Therefore, you are required to create DNS labels for the External Load Balancers’ public IP addresses.
Azure Traffic Manager: Microsoft Azure Traffic Manager allows you to control the distribution of user traffic
to your service endpoints running in different datacenters around the world. Azure Traffic Manager works at
the DNS level. It uses DNS responses to direct end-user traffic to globally-distributed endpoints. Clients then
connect to those endpoints directly. With different routing options of Performance, Weighted and Priority, you
can easily choose the routing option best suited for your organization’s needs.
V -net to V -net connectivity between two regions: You do not need to have connectivity between the
virtual networks itself. Since each virtual network has access to domain controllers and has AD FS and WAP
server in itself, they can work without any connectivity between the virtual networks in different regions.
Steps to integrate Azure Traffic Manager

Deploy AD FS in the new geographical region
Follow the steps and guidelines in AD FS deployment in Azure to deploy the same topology in the new
geographical region.
DNS labels for public IP addresses of the Internet Facing (public) Load Balancers
As mentioned above, the Azure Traffic Manager can only refer to DNS labels as endpoints and therefore it is
important to create DNS labels for the External Load Balancers’ public IP addresses. Below screenshot shows how
you can configure your DNS label for the public IP address.
Deploying Azure Traffic Manager

Follow the steps below to create a traffic manager profile. For more information, you can also refer to Manage an
Azure Traffic Manager profile.
1. Create a Traffic Manager profile: Give your traffic manager profile a unique name. This name of the
profile is part of the DNS name and acts as a prefix for the Traffic Manager domain name label. The name /
prefix is added to .trafficmanager.net to create a DNS label for your traffic manager. The screenshot below
shows the traffic manager DNS prefix being set as mysts and resulting DNS label will be
mysts.trafficmanager.net.
2. Traffic routing method: There are three routing options available in traffic manager:
Priority
Performance
Weighted
Performance is the recommended option to achieve highly responsive AD FS infrastructure.
However, you can choose any routing method best suited for your deployment needs. The AD FS
functionality is not impacted by the routing option selected. See Traffic Manager traffic routing
methods for more information. In the sample screenshot above you can see the Performance
method selected.
3. Configure endpoints: In the traffic manager page, click on endpoints and select Add. This will open an
Add endpoint page similar to the screenshot below
For the different inputs, follow the guideline below:

Type: Select Azure endpoint as we will be pointing to an Azure public IP address.
Name: Create a name that you want to associate with the endpoint. This is not the DNS name and has no
bearing on DNS records.
Target resource type: Select Public IP address as the value to this property.
Target resource: This will give you an option to choose from the different DNS labels you have available
under your subscription. Choose the DNS label corresponding to the endpoint you are configuring.
Add endpoint for each geographical region you want the Azure Traffic Manager to route traffic to. For more
information and detailed steps on how to add / configure endpoints in traffic manager, refer to Add, disable,
enable or delete endpoints
4. Configure probe: In the traffic manager page, click on Configuration. In the configuration page, you need
to change the monitor settings to probe at HTTP port 80 and relative path /adfs/probe
NOTE
Ensure that the status of the endpoints is ONLINE once the configuration is complete. If all endpoints are in
‘degraded’ state, Azure Traffic Manager will do a best attempt to route the traffic assuming that the diagnostics is
incorrect and all endpoints are reachable.
5. Modifying DNS records for Azure Traffic Manager: Your federation service should be a CNAME to the
Azure Traffic Manager DNS name. Create a CNAME in the public DNS records so that whoever is trying to
reach the federation service actually reaches the Azure Traffic Manager.
For example, to point the federation service fs.fabidentity.com to the Traffic Manager, you would need to
update your DNS resource record to be the following:
fs.fabidentity.com IN CNAME mysts.trafficmanager.net
Test the routing and AD FS sign-in
Routing test
A very basic test for the routing would be to try ping the federation service DNS name from a machine in each
geographic region. Depending on the routing method chosen, the endpoint it actually pings will be reflected in the
ping display. For example, if you selected the performance routing, then the endpoint nearest to the region of the
client will be reached. Below is the snapshot of two pings from two different region client machines, one in
EastAsia region and one in West US.
AD FS sign-in test
The easiest way to test AD FS is by using the IdpInitiatedSignon.aspx page. In order to be able to do that, it is
required to enable the IdpInitiatedSignOn on the AD FS properties. Follow the steps below to verify your AD FS
setup
1. Run the below cmdlet on the AD FS server, using PowerShell, to set it to enabled. Set-AdfsProperties -
EnableIdPInitiatedSignonPage $true
2. From any external machine access https:///adfs/ls/IdpInitiatedSignon.aspx
3. You should see the AD FS page like below:
and on successful sign-in, it will provide you with a success message as shown below:
Related links
Basic AD FS deployment in Azure
Microsoft Azure Traffic Manager
Traffic Manager traffic routing methods
Next steps
Manage an Azure Traffic Manager profile
Add, disable, enable or delete endpoints
Upgrading to AD FS in Windows Server 2016 with
SQL Server
Moving from a Windows Server 2012 R2 AD FS farm to a Windows

Server 2016 AD FS farm
The following document will describe how to upgrade your AD FS Windows Server 2012 R2 farm to AD FS in
Windows Server 2016 when you are using a SQL Server for the AD FS database.
Upgrading AD FS to Windows Server 2016 FBL
New in AD FS for Windows Server 2016 is the farm behavior level feature (FBL ). This features is farm wide and
determines the features that the AD FS farm can use. By default, the FBL in a Windows Server 2012 R2 AD FS
farm is at the Windows Server 2012 R2 FBL.
A Windows Server 2016 AD FS server can be added to a Windows Server 2012 R2 farm and it will operate at the
same FBL as a Windows Server 2012 R2. When you have a Windows Server 2016 AD FS server operating in this
fashion, your farm is said to be "mixed". However, you will not be able to take advantage of the new Windows
Server 2016 features until the FBL is raised to Windows Server 2016. With a mixed farm:
Administrators can add new, Windows Server 2016 federation servers to an existing Windows Server 2012
R2 farm. As a result, the farm is in "mixed mode" and operates the Windows Server 2012 R2 farm behavior
level. To ensure consistent behavior across the farm, new Windows Server 2016 features cannot be
configured or used in this mode.
Once all Windows Server 2012 R2 federation servers have been removed from the mixed mode farm, and
in the case of a WID farm, one of the new Windows Serve 2016 federation servers has been promoted to
the role of primary node, the administrator can then raise the FBL from Windows Server 2012 R2 to
Windows Server 2016. As a result, any new AD FS Windows Server 2016 features can then be configured
and used.
As a result of the mixed farm feature, AD FS Windows Server 2012 R2 organizations looking to upgrade to
Windows Server 2016 will not have to deploy an entirely new farm, export and import configuration data.
Instead, they can add Windows Server 2016 nodes to an existing farm while it is online and only incur the
relatively brief downtime involved in the FBL raise.
Be aware that while in mixed farm mode, the AD FS farm is not capable of any new features or functionality
introduced in AD FS in Windows Server 2016. This means organizations that want to try out new features cannot
do this until the FBL is raised. So if your organization is looking to test the new features prior to rasing the FBL,
you will need to deploy a separate farm to do this.
The remainder of the is document provides the steps for adding a Windows Server 2016 federation server to a
Windows Server 2012 R2 environment and then raising the FBL to Windows Server 2016. These steps were
performed in a test environment outlined by the architectural diagram below.
NOTE
Before you can move to AD FS in Windows Server 2016 FBL, you must remove all of the Windows 2012 R2 nodes. You
cannot just upgrade a Windows Server 2012 R2 OS to Windows Server 2016 and have it become a 2016 node. You will need
to remove it and replace it with a new 2016 node.
To following architectural diagram shows the setup that was used to validate and record the steps below.
Join the Windows 2016 AD FS Server to the AD FS farm

1. Using Server Manager install the Active Directory Federation Services Role on the Windows Server 2016
2. Using the AD FS Configuration wizard, join the new Windows Server 2016 server to the existing AD FS
farm. On the Welcome screen click Next.
3. On the Connect to Active Directory Domain Services screen, specify an administrator account with
permissions to perform the federation services configuration and click Next.
4. On the Specify Farm screen, enter the name of the SQL server and instance and then click Next.
5. On the Specify SSL Certificate screen, specify the certificate and click Next.
6. On the Specify Service Account screen, specify the service account and click Next.
7. On the Review Options screen, review the options and click Next.
8. On the Pre-requisites Checks screen, ensure that all of the pre-requisite checks have passed and click
Configure.
9. On the Results screen, ensure that server was successfully configured and click Close.
Remove the Windows Server 2012 R2 AD FS server
NOTE
You do not need to set the primary AD FS server using Set-AdfsSyncProperties -Role when using SQL as the database. This is
because all of the nodes are considered primary in this configuration.
1. On the Windows Server 2012 R2 AD FS server in Server Manager use Remove Roles and Features under
Manage.
2. On the Before you Begin screen, click Next.
3. On the Server Selection Screen, click Next.
4. On the Server Roles screen, remove the check next to Active Directory Federation Services and click Next.
5. On the Features Screen, click Next.

6. On the Confirmation Screen, click Remove.
7. Once this completes, restart the server.
Raise the Farm Behavior Level (FBL)
Prior to this step you need to ensure that forestprep and domainprep have been run on your Active Directory
environment and that Active Directory has the Windows Server 2016 schema. This document started with a
Windows 2016 domain controller and did not require running these because they were run when AD was installed.
NOTE
Before starting the process below, ensure Windows Server 2016 is current by running Windows Update from Settings.
Continue this process until no further updates are needed.
1. Now on the Windows Server 2016 Server open PowerShell and run the following: $cred = Get-Credential
and hit enter.
2. Enter credentials that have admin privileges on the SQL Server.
3. Now in PowerShell, enter the following: Invoke-AdfsFarmBehaviorLevelRaise -Credential $cred
4. When prompted, type Y. This will begin raising the level. Once this completes you have successfully raised the
FBL.
5. Now, if you go to AD FS Management, you will see the new nodes that have been added for AD FS in Windows
Server 2016
6. Likewise, you can use the PowerShell cmdlt: Get-AdfsFarmInformation to show you the current FBL.
Windows Server 2016 and 2012 R2 AD FS
Deployment Guide
You can use Active Directory Federation Services (AD FS ) with the Windows Server 2016 and 2012 R2 operating
system to build a federated identity management solutions that extend distributed identification, authentication,
and authorization services to Web-based applications across organization and platform boundaries. By deploying
AD FS, you can extend your organization’s existing identity management capabilities to the Internet.
See Also
AD FS Deployment
In order to deploy a federation server farm, complete the tasks in this checklist in order. When a reference link takes
you to a conceptual topic, return to this checklist after you review the conceptual topic so that you can proceed with
the remaining tasks in this checklist.
Checklist: Deploying a Federation Server Farm
TASK REFERENCE
Review important concepts and AD FS Design Guide in Windows

considerations as you prepare to deploy Server 2012 R2
Active Directory Federation Services (AD
FS). Note: Understanding Key AD FS Concepts
If you decide to use Microsoft SQL SQL Server Warning: In Windows

Server for your AD FS configuration Server 2012 R2, if you want to create an
store, ensure to deploy a functional AD FS farm and use SQL Server to store
instance of SQL Server. your configuration data, you can use
SQL Server 2008 and newer versions,
including SQL Server 2012.
Join your computer to an Active Join a Computer to a Domain

Directory domain.
Enroll a Secure Socket Layer (SSL) Enroll an SSL Certificate for AD FS

certificate for AD FS.
Install the AD FS role service. Install the AD FS Role Service
Configure a federation server. Configure a Federation Server
Optional step: Configure a federation Configure a federation server with

server with Device Registration Service Device Registration Service
(DRS).
Add a host (A) and alias (CNAME) Configure Corporate DNS for the
resource record to corporate Domain Federation Service and DRS
Name System (DNS) for the federation
service and DRS.
Verify that a federation server is Verify That a Federation Server Is

operational. Operational
See Also
AD FS Deployment
Windows Server 2012 R2 AD FS Deployment Guide
Join a Computer to a Domain
For Active Directory Federation Services (AD FS ) to function, each computer that functions as a federation server
must be joined to a domain. federation server proxies may be joined to a domain, but this is not a requirement.
You do not have to join a Web server to a domain if the Web server is hosting claims-aware applications only.
Membership in Administrators, or equivalent, on the local computer is the minimum required to complete this
procedure. Review details about using the appropriate accounts and group memberships at Local and Domain
Default Groups.
To join a computer to a domain
1. On the Start screen, type Control Panel, and then press ENTER.
2. Navigate to System and Security, and then click System.
3. Under Computer name, domain, and workgroup settings, click Change settings.
4. On the Computer Name tab, click Change.
5. Under Member of, click Domain, type the name of the domain that you wish this computer to join, and
then click OK.
6. Click OK, and then restart the computer.
Additional references
Enroll an SSL Certificate for AD FS
Active Directory Federation Services (AD FS ) requires a certificate for Secure Socket Layer (SSL ) server
authentication on each federation server in your federation server farm. The same certificate can be used on each
federation server in a farm. You must have both the certificate and its private key available. For example, if you have
the certificate and its private key in a .pfx file, you can import the file directly into the Active Directory Federation
Services Configuration Wizard. This SSL certificate must contain the following:
1. The subject name and subject alternative name must contain your federation service name, such as
fs.contoso.com.
2. The subject alternative name must contain the value enterpriseregistration that is followed by the User
Principal Name (UPN ) suffix of your organization, for example, enterpriseregistration.corp.contoso.com.
WARNING
Specify the subject alternative name if you plan to enable the Device Registration Service (DRS) for Workplace Join.
IMPORTANT
If your organization uses multiple UPN suffixes, and you plan to enable the DRS, the SSL certificate must contain a subject
alternative name entry for each suffix.
See Also
AD FS Deployment
Install the AD FS Role Service
You can use the following procedure to install the AD FS role service on a computer that is running Windows
Server 2012 R2 to become the first federation server in a federation server farm or a federation server in an
existing federation server farm.
Membership in Administrators, or equivalent, on the local computer is the minimum requirement to complete this
Default Groups.
To install the AD FS server role via the Add roles and features wizard
1. Open Server Manager. To open Server Manager, click Server Manager on the Start screen, or Server
Manager in the taskbar on the desktop. In the Quick Start tab of the Welcome tile on the Dashboard
page, click Add roles and features. Alternatively, you can click Add Roles and Features on the Manage
menu.
3. On the Select installation type page, click Role-based or Feature-based installation, and then click
Next.
6. On the Select features page, click Next. The required prerequisites are preselected for you. You do not
have to select any other features.
8. After you verify the information on the Confirm installation selections page, click Install.
To install the AD FS server role via Windows PowerShell
1. On the computer that you want to configure as a federation server, open the Windows PowerShell command
window, and then run the following command: Install-windowsfeature adfs-federation –IncludeManagementTools .
See Also
AD FS Deployment
Configure a Federation Server
After you install the Active Directory Federation Services (AD FS ) role service on your computer, you are ready to
configure this computer to become a federation server. You can do one of the following:
Configure the first federation server in a new federation server farm
Add a federation server to an existing federation server farm
Configure the first federation server in a new federation server farm

To configure the first federation server in a new federation server farm by using the Active Directory Federation
Service Configuration Wizard
NOTE
Ensure that you have domain administrator permissions or have domain administrator credentials available before you
perform this procedure.
click Next.
3. On the Connect to AD DS page, specify an account by using domain administrator permissions for the
Active Directory (AD ) domain to which this computer is joined, and then click Next.
Import the .pfx file that contains the Secure Socket Layer (SSL ) certificate and key that you have
obtained earlier. In Step 2: Enroll an SSL Certificate for AD FS, you have obtained this certificate and
copied it onto the computer that you want to configure as a federation server. To import the .pfx file
via the wizard, click Import, and then browse to the file’s location. Enter the password for the .pfx file
when you are prompted.
Provide a name for your federation service. For example, fs.contoso.com. This name must match
one of the subject or subject alternative names in the certificate.
Provide a display name for your federation service. For example, Contoso Corporation. Users see
this name on the Active Directory Federation Services (AD FS ) sign-in page.
5. On the Specify Service Account page, specify a service account. You can either create or use an existing
group Managed Service Account (gMSA) or use an existing domain user account. If you select the option to
create a new gMSA account, specify a name for the new account. If you select the option to use an existing
gMSA or domain account, click Select to select an account.
NOTE
The benefit of using a gMSA account is its auto-negotiated password update feature.
WARNING
If you want to use a gMSA account, you must have at least one domain controller in your environment that is
running the Windows Server 2012 operating system.
If the gMSA option is disabled, and you see an error message, such as Group Managed Service Accounts are not
available because the KDS Root Key has not been set, you can enable gMSA in your domain by running the
following Windows PowerShell command on a domain controller, which runs Windows Server 2012 or later, in your
Active Directory domain: Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10) . Then return to the wizard,
click Previous, and then click Next to re-enter the Specify Service Account page. The gMSA option should now be
enabled. You can select it and enter a gMSA account name that you want to use.
6. On the Specify Configuration Database page, specify an AD FS configuration database, and then click
Next. You can either create a database on this computer by using Windows Internal Database (WID ), or you
can specify the location and the instance name of Microsoft SQL Server.
For more information, see The Role of the AD FS Configuration Database.
IMPORTANT
If you want to create an AD FS farm and use SQL Server to store your configuration data, you can use SQL Server
2008 and newer versions, including SQL Server 2012 and SQL Server 2014.
8. On the Pre-requisite Checks page, verify that all prerequisite checks are successfully completed, and then
click Configure.
9. On the Results page, review the results and check whether the configuration is completed successfully, and
then click Next steps required for completing your federation service deployment. For more
information, see Next steps for completing your AD FS installation. Click Close to exit the wizard.
To configure the first federation server in a new federation server farm via Windows PowerShell
You can create a new federation server farm by using either a new or existing gMSA account or an existing domain
user account.
If you want to create a new federation server by using a new gMSA account, do the following:
IMPORTANT
You must have domain administrator permissions to create the first federation server in a new federation server farm.
1. On the computer that you want to configure as a federation server, ensure that the required SSL
certificate has been imported into the Local Computer\My Store directory. You can verify whether
the SSL certificate has been imported by running the following command in the Windows
PowerShell command window: dir Cert:\LocalMachine\My . The certificate is listed by its thumbprint
in the Local Computer\My Store directory.
2. On your domain controller, open the Windows PowerShell command window and run the following
command to verify whether the KDS Root Key has been created in your domain:
Get-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10) . If it has not been created so that the output
displays no information, run the following command to create the key:
Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10) .
3. On the computer that you want to configure as a federation server, open the Windows PowerShell
command window, and run the following command:
Install-AdfsFarm -CertificateThumbprint <certificate_thumbprint> -FederationServiceName

<federation_service_name> -GroupServiceAccountIdentifier <domain>\<GMSA_Name>$
WARNING
The $ sign at the end of the previous command is required.
To obtain the value for <certificate_thumbprint> , run dir Cert:\LocalMachine\My , and then select the
thumbprint of your SSL certificate. The value of <federation_service_name> is the name of your
federation service, for example, fs.contoso.com.
NOTE
If this is NOT the first time that you run this command, add the OverwriteConfiguration parameter.
NOTE
The previous command creates a WID farm. If you want to create a SQL Server server farm, you must have an
instance of SQL Server already installed and operational.
You can use the following command to create the first federation server in a new farm that uses an instance of
SQL Server:
<federation_service_name> -GroupServiceAccountIdentifier <domain>\<GMSA_name>$ -
SQLConnectionString "Data Source=<SQL_Host_Name?\<SQL_instance_ name>;Integrated
Security=True"
where <SQL_Host_Name> is the name of the server on which SQL Server is running, and
<SQL_instance_name> is the name of the instance of SQL Server. If you use the default instance of SQL
Server, use a SQLConnectionString value of "Data Source=<SQL_Host_Name>;Integrated
Security=True".
IMPORTANT
If you want to create an AD FS farm and use SQL Server to store your configuration data, you can use SQL
Server 2008 and newer versions, including SQL Server 2012.
If you want to create a new federation server by using an existing domain user account, do the
following:
command window, and then run the following command: $fscred = Get-Credential . Enter the
domain user account credentials that you want to use for the federation service account in the format
domain\user name.
3. In the same Windows PowerShell command window, run the following command:

<federation_service_name> -ServiceAccountCredential $fscred
To obtain the value for <certificate_thumbprint>, run dir Cert:\LocalMachine\My , and then select
the thumbprint of your SSL certificate. The value of <federation_service_name> is the name of
your federation service, for example, fs.contoso.com.
NOTE
NOTE
The previous command creates a WID farm. If you want to create a SQL Server farm, you must have the
instance of SQL Server already installed and operational.
You can use the following command to create the first federation server in a new farm that uses an instance of
SQL Server:
<federation_service_name> -ServiceAccountCredential $fscredential -SQLConnectionString "Data
Source=<SQL_Host_Name>\<SQL_instance_ name>;Integrated Security=True"
where SQL_Host_Name is the name of the server on which SQL Server is running, and SQL_instance_name
is the name of the instance of SQL Server. If you use the default instance of SQL Server, use a
SQLConnectionString value of "Data Source=<SQL_Host_Name>;Integrated Security=True".
IMPORTANT
Server 2008 and newer versions, including SQL Server 2012 and SQL Server 2014.
Add a federation server to an existing federation server farm

IMPORTANT
Ensure that you have completed Step 3: Install the AD FS Role Service, before you start any of the procedures in this section.
IMPORTANT
Ensure that you have obtained a valid SSL server authentication certificate before you complete this procedure.
To add a federation server to an existing federation server farm via the Active Directory Federation Service
Configuration Wizard
2. On the Welcome page, select Add a federation server to a federation server farm, and then click Next.
3. On the Connect to AD DS page, specify an account by using domain administrator permissions for the AD
domain to which this computer is joined, and then click Next.
4. On the Specify Farm page, provide the name of the primary federation server in a farm that uses WID or
specify the database host name and the database instance name of an existing federation server farm that
uses SQL Server.
WARNING
In Windows Server® 2012 R2, there is a workaround to specify the default instance of SQL Server. The workaround is
to not use the user interface. Instead, use the steps in To configure the first federation server in a new federation
server farm via Windows PowerShell.
IMPORTANT
If you want to create an AD FS farm and use SQL Server to store your configuration data, you can use SQL Server
2008 and newer versions, including SQL Server 2012.
5. On the Specify SSL Certificate page, import the .pfx file that contains the SSL certificate and key that you
have obtained previously. This certificate is the required service authentication certificate. In Step 2: Enroll an
SSL Certificate for AD FS, you have obtained this certificate and copied it to the computer that you want to
configure as a federation server. To import the .pfx file via the wizard, click Import and browse to the file’s
location. Enter the password for the .pfx file when you are prompted.
6. On the Specify Service Account page, specify the same service account that you configured when you
created the first federation server in the farm. You can use an existing group Managed Service Account or an
existing domain user account.
IMPORTANT
The account that you specify must be the same account as the account that was used on the primary federation
server in this farm.
8. On the Pre-requisite Checks page, verify that all prerequisite checks are successfully completed, and then
click Configure.
9. On the Results page, review the results and check whether the configuration is completed successfully, and
then click Next steps required for completing your federation service deployment. For more
information, see Next steps for completing your AD FS installation. Click Close to exit the wizard.
To add a federation server to an existing federation server farm via Windows PowerShell
You can add a federation server to an existing farm by using either an existing gMSA account or an existing domain
user account.
If you want to join a federation server to a farm by using an existing gMSA account, do the following:
command window, and run the following command.
Add-AdfsFarmNode -GroupServiceAccountIdentifier <domain>\<GMSA_name>$ -PrimaryComputerName

<first_federation_server_hostname> -CertificateThumbprint <certificate_thumbprint>
<domain>\<GMSA_name> is your AD domain and the name of your gMSA account in that domain.
<first_federation_server_hostname> is the host name of the primary federation server in this existing
farm.
You can obtain the value for <certificate_thumbprint> by running dir Cert:\LocalMachine\My in the
previous step.
NOTE
NOTE
The previous command creates a WID farm node. If you want to create a server farm node of computers
running SQL Server, you must have the instance of SQL Server already installed and operational.
You can use the following command to add a federation server to an existing farm that is using an instance of
SQL Server:
Add-AdfsFarmNode -GroupServiceAccountIdentifier <domain>\<GMSA_name>$ -SQLConnectionString
"Data Source=<SQL_Host_Name>\<SQL_instance_ name>;Integrated Security=True"
where SQL_Host_Name is the name of the server on which SQL Server is running, and SQL_instance_name
is the name of the instance of SQL Server. If you use the default instance of SQL Server, use a
SQLConnectionString value of "Data Source=<SQL_Host_Name>;Integrated Security=True".
IMPORTANT
If you want to join a federation server to a farm by using an existing domain user account, do the following:
1. On the computer that you want to configure as a federation server, open the Windows
PowerShellcommand window, and then run the following command: $fscred = get-credential . Enter
the domain user account credentials that you want to use for the federation service account in the
format domain\user name.
PowerShellcommand window: dir Cert:\LocalMachine\My . The certificate is listed by its thumbprint in
the Local Computer\My Store directory.
3. In the same Windows PowerShell command window, run the following command.
Add-AdfsFarmNode -ServiceAccountCredential $fscred -PrimaryComputerName

<first_federation_server_hostname> -CertificateThumbprint <certificate_thumbprint>
NOTE
NOTE
The previous command creates a WID farm node. If you want to create a server farm node of computers
running SQL Server, you must have the instance of SQL Server already installed and operational. You can use
the following command to add a federation server to an existing farm by using an instance of SQL Server:
Add-AdfsFarmNode -ServiceAccountCredential $fscred -SQLConnectionString "Data Source=
<SQL_Host_Name>\<SQL_instance_ name>;Integrated Security=True"
where SQL_Host_Name is the name of the server on which the instance of SQL Server is running, and
SQL_instance_name is the name of the instance of SQL Server. If you use the default instance of SQL Server,
use a SQLConnectionString value of "Data Source=<SQL_Host_Name>;Integrated Security=True".
IMPORTANT
See Also
AD FS Deployment
Configure a federation server with Device
You can enable Device Registration Service (DRS ) on your federation server after you complete the procedures in
Step 4: Configure a Federation Server. The Device Registration Service provides an onboarding mechanism for
seamless second factor authentication, persistent single sign-on (SSO ), and conditional access to consumers that
require access to company resources. For more information about DRS, see Join to Workplace from Any Device for
SSO and Seamless Second Factor Authentication Across Company Applications
Prepare your Active Directory forest to support devices

NOTE
This is a one-time operation that you must run to prepare your Active Directory forest to support devices. You must be
logged on with enterprise administrator permissions and your Active Directory forest must have the Windows Server 2012 R2
schema to complete this procedure.
Additionally, DRS requires that you have at least one global catalog server in your forest root domain. The global catalog
server is required in order to run Initialize-ADDeviceRegistration and during AD FS authentication. AD FS initializes an in-
memory representation of the DRS config object on each authentication request and if the DRS config object cannot be found
on a DC in the current domain, the request is attempted against the GC on which the DRS objects were provisioned during
Initialize-ADDeviceRegistration.
To prepare the Active Directory forest

1. On your federation server, open a Windows PowerShell command window and type:
2. When prompted for ServiceAccountName, enter the name of the service account you selected as the service
account for AD FS. If it is a gMSA account, enter the account in the domain\accountname$ format. For a
domain account, use the format domain\accountname.
Enable Device Registration Service on a federation server farm node

NOTE
You must be logged on with domain administrator permissions to complete this procedure.
To enable Device Registration Service

1. On your federation server, open a Windows PowerShell command window and type:
2. Repeat this step on each federation farm node in your AD FS farm..

Enable seamless second factor authentication
Seamless second factor authentication is an enhancement in AD FS that provides an added level of access
protection to corporate resources and applications from external devices that are trying to access them. When a
personal device is Workplace Joined, it becomes a ‘known’ device and administrators can use this information to
drive conditional access and gate access to resources.
To enable seamless second factor authentication, persistent single sign-on (SSO) and conditional access for Workplace Joined devices
1. In the AD FS Management console, navigate to Authentication Policies. Select Edit Global Primary
Authentication. Select the check box next to Enable Device Authentication, and then click OK.
Update the Web Application Proxy configuration

IMPORTANT
You do not need to publish the Device Registration Service to the Web Application Proxy. The Device Registration Service will
be available through the Web Application Proxy once it is enabled on a federation server. You may need to complete this
procedure to update the Web Application Proxy configuration if it was deployed prior to enabling the Device Registration
Service.
To update the Web Application Proxy Configuration

1. On your Web Application Proxy server, open a Windows PowerShell command window and type
Update-WebApplicationProxyDeviceRegistration
2. When prompted for credentials, enter the credentials of an account that has administrative rights to your
federation servers.
See Also
AD FS Deployment
Configure Corporate DNS for the Federation Service
and DRS
Step 6: Add a Host (A) and Alias (CNAME) Resource Record to

Corporate DNS for the Federation Service and DRS
You must add the following resource records to corporate Domain Name System (DNS ) for your federation service
and Device Registration Service that you configured in previous steps.
ENTRY TYPE ADDRESS
federation_service_name Host (A) IP address of the AD FS server or the IP

address of the load balancer that is
configured in front of your AD FS server
farm
enterpriseregistration Alias (CNAME) federation_server_name.contoso.com
You can use the following procedure to add a host (A) and alias (CNAME ) resource records to corporate DNS for
the federation server and the Device Registration Service.
Membership in Administrators, or equivalent, is the minimum requirement to complete this procedure. Review
details about using the appropriate accounts and group memberships at Local and Domain Default Groups.
To add a host (A) and alias (CNAME) resource records to DNS for your federation server
1. On you domain controller, in Server Manager, on the Tools menu, click DNS to open the DNS snap-in.
2. In the console tree, expand the domain_controller_name node, expand Forward Lookup Zones, right-
click domain_name, and then click New Host (A or AAAA ).
3. In the Name box, type the name to use for your AD FS farm.
4. In the IP address box, type the IP address of your federation server. Click Add Host.
5. Right-click the domain_name node, and then click New Alias (CNAME ).
7. In the fully qualified domain name (FQDN ) of the target host box, type
federation_service_farm_name.domain_name.com, and then click OK.
IMPORTANT
In a real world deployment, if your company has multiple User Principal Name (UPN) suffixes, you must create multiple
CNAME records for each of those UPN suffixes in DNS.
See Also
AD FS Deployment
Verify your Windows Server 2012 R2 Federation
Server is Operational
You can use the following procedures to verify that a federation server is operational; that is, that any client on the
same network can reach a new federation server.
Membership in Users, Backup Operators, Power Users, Administrators or equivalent, on the local computer is
the minimum required to complete this procedure. Review details about using the appropriate accounts and group
memberships at Local and Domain Default Groups.
Procedure 1: To verify that a federation server is operational
1. To verify that Internet Information Services (IIS ) is configured correctly on the federation server, log on to a
client computer that is located in the same forest as the federation server.
2. Open a browser window, in the address bar type the federation server’s DNS host name, and then append
/adfs/fs/federationserverservice.asmx to it for the new federation server, for example:
https://fs1.fabrikam.com/adfs/fs/federationserverservice.asmx
3. Press ENTER, and then complete the next procedure on the federation server computer. If you see the
message There is a problem with this website’s security certificate, click Continue to this website.
The expected output is a display of XML with the service description document. If this page appears, IIS on
the federation server is operational and serving pages successfully.
Default Groups.
1. Log on to the new federation server as an administrator.
2. On the Start screen, typeEvent Viewer, and then press ENTER.
3. In the details pane, double-click Applications and Services Logs, double-click AD FS Eventing, and then
click Admin.
4. In the Event ID column, look for event ID 100. If the federation server is configured properly, you see a new
event—in the Application log of Event Viewer—with the event ID 100. This event verifies that the federation
server was able to successfully communicate with the Federation Service.
See Also
AD FS Deployment
In Active Directory Federation Services (AD FS ) in Windows Server 2012 R2 , the role of a federation server proxy
is handled by a new Remote Access role service called Web Application Proxy. To enable your AD FS for
accessibility from outside the corporate network, which was the purpose of deploying a federation server proxy in
legacy versions of AD FS, such as AD FS 2.0 and AD FS in Windows Server 2012 , you can deploy one or more
web application proxies for AD FS in Windows Server 2012 R2 .
In the context of AD FS, Web Application Proxy functions as an AD FS federation server proxy. In addition to this,
Web Application Proxy provides reverse proxy functionality for web applications inside your corporate network to
enable users on any device to access them from outside the corporate network. For more information, about the
Web Application Proxy role service, see Web Application Proxy Overview.
To plan the deployment of Web Application proxy, you can review the information in the following topics:
Plan the Web Application Proxy Infrastructure (WAP )
To deploy Web Application proxy, you can follow the procedures in the following topics:
Configure the Web Application Proxy Infrastructure
Install and Configure the Web Application Proxy Server
See Also
AD FS Deployment
Azure AD Connect will integrate your on-premises directories with Azure Active Directory. This allows you to
provide a common identity for your users for Office 365, Azure, and SaaS applications integrated with Azure AD. .
For more information see Integrating your on-premises identities with Azure Active Directory.
Windows Server 2012 AD FS Deployment Guide
You can use Active Directory® Federation Services (AD FS ) with the Windows Server® 2012 operating system to
build a federated identity management solution that extends distributed identification, authentication, and
authorization services to Web-based applications across organization and platform boundaries. By deploying AD
FS, you can extend your organization’s existing identity management capabilities to the Internet.
You can deploy AD FS to:
Provide your employees or customers with a Web-based, single-sign-on (SSO ) experience when they need
remote access to internally hosted Web sites or services.
Provide your employees or customers with a Web-based, SSO experience when they access cross-
organizational Web sites or services from within the firewalls of your network.
Provide your employees or customers with seamless access to Web-based resources in any federation
partner organization on the Internet without requiring employees or customers to log on more than once.
Retain complete control over your employee or customer identities without using other sign-on providers
(Windows Live ID, Liberty Alliance, and others).
About this guide

This guide is intended for use by system administrators and system engineers. It provides detailed guidance for
deploying an AD FS design that has been preselected by you or an infrastructure specialist or system architect in
your organization.
If a design has not yet been selected, we recommend that you wait to follow the instructions in this guide until after
you have reviewed the design options in the AD FS Design Guide in Windows Server 2012 and you have selected
the most appropriate design for your organization. For more information about using this guide with a design that
has already been selected, see Implementing Your AD FS Design Plan.
After you select your design from the design guide and gather the required information about claims, token types,
attribute stores, and other items, you can use this guide to deploy your AD FS design in your production
environment. This guide provides steps for deploying either of the following primary AD FS designs:
Web SSO
Federated Web SSO
Use the checklists in Implementing Your AD FS Design Plan to determine how best to use the instructions in this
guide to deploy your particular design. For information about hardware and software requirements for deploying
AD FS, see the Appendix A: Reviewing AD FS Requirements in the AD FS Design Guide.
What this guide does not provide
This guide does not provide:
Guidance regarding when and where to place federation servers, federation server proxies, or Web servers
in your existing network infrastructure. For this information, see Planning Federation Server Placement and
Planning Federation Server Proxy Placement in the AD FS Design Guide.
Guidance for using certification authorities (CAs) to set up AD FS
Guidance for setting up or configuring specific Web-based applications
Setup instructions that are specific to setting up a test lab environment.
Information about how to customize federated logon screens, web.config files, or the configuration database.
In this guide
Configuring Partner Organizations
After you collect information about your environment and you decide on an Active Directory Federation Services
(AD FS ) design by following the guidance in the AD FS Design Guide in Windows Server 2012, you can begin to
plan the deployment of your organization's AD FS design. With the completed design and the information in this
topic, you can determine which tasks to perform to deploy AD FS in your organization.
Reviewing your AD FS design

If the design team that constructed the original AD FS design for your organization is different from the
deployment team that will actually implement the deployment, make sure that the deployment team reviews the
final design with the design team. Review the following points regarding the design:
The design team's strategy to determine the best physical topology for the placement of federation servers
in your corporate network or perimeter network. The deployment team can refer to documentation about
this subject by reviewing the following topics in the AD FS Design Guide:
It is possible that the design team might leave the subject of federation server or federation server proxy
placement for the deployment team. The deployment team is then responsible for documenting and
implementing the physical topology of the servers.
The business reasons for your organization's designation as a claims provider, relying party, or both, within
the scope of the documented AD FS design. Ensure that members of the deployment team understand the
reasons why AD FS is being deployed and what other companies or organizations are involved in the
federation partnership. Ensure that members of the deployment team also understand the constraints that
exist for the other companies or organizations (limited hardware, no extranet environment, and so forth) that
may limit the scope of the design in some way. For more information about partner organizations, see
Planning Your Deployment.
After the design teams and deployment teams agree on these issues, they can proceed with the deployment of the
AD FS design. For more information, see Implementing Your AD FS Design Plan.
The following environmental conditions and requirements are important factors in the implementation of your
Active Directory Federation Services (AD FS ) design plan:
Supported partners: You usually use AD FS to work with partner organizations. To establish identity
federation, determine the organizations with which you want to form a partnership. After a baseline AD FS
deployment is in place, operating with partners involves adding partners, deleting partners, and updating
partner information. Changes to partnerships may occur for a variety of reasons. For example, your AD FS
deployment might require partnership updates if your partner changes its business significantly, your
organization becomes part of a larger organization or a federation of organizations, or your organization is
acquired by a different company. In any scenario in which you federate identities from multiple domains, you
will need to know the domains (partners) that you are currently supporting and all the additional domains
that represent potential partners.
Supported application and service types: Some applications and services require access to operating
system resources, while others are "claims aware." It is important to understand the types of applications
and services that AD FS supports so that you can formulate administration requirements.
Logical and physical architectural diagrams or deployment topology: You will need to know:
Whether federation servers will function in a set of farmed servers or on a single server.
Where your network deploys firewalls and proxies.
The location of resources and whether users are accessing resources from within your organization,
outside the organization, or both.
How to implement your AD FS design using this guide

The next step in implementing your design is to determine in what order each deployment task must be performed.
This guide uses checklists to help you walk through the various server and application deployment tasks that are
required to implement your design plan. Parent and child checklists are used as necessary to represent the order in
which tasks for a specific AD FS design must be processed.
Use the following parent checklists in this section of the guide to become familiar with the deployment tasks for
implementing your organization's preferred AD FS design:
This parent checklist includes cross-reference links to important concepts about the Web Single-Sign-On (SSO )
design for Active Directory Federation Services (AD FS ). It also contains links to subordinate checklists that will
help you complete the tasks that are required to implement this design.
NOTE
Complete the tasks in this checklist in order. When a reference link takes you to a conceptual topic or to a subordinate
checklist, return to this topic after you review the conceptual topic or complete the tasks in the subordinate checklist so that
you can proceed with the remaining tasks in this checklist.
TASK REFERENCE
Review important concepts about the Web SSO Design

Web SSO design and determine which
AD FS deployment goals you can use to Identifying Your AD FS Deployment
customize this design to meet the needs Goals
of your organization. Note:
Review the hardware, software, Appendix A: Reviewing AD FS

certificate, Domain Name System (DNS), Requirements
attribute store, and client requirements
for deploying AD FS in your
organization.
According to your design plan, install Checklist: Setting Up a Federation

one or more federation servers in the Server
corporate network or in the perimeter
network. Note: The Web SSO design
requires only one federation server to
function successfully. A single federation
server acts in both the claims provider
role and the relying party role.
(Optional) Determine whether or not Checklist: Setting Up a Federation

your organization needs a federation Server Proxy
server proxy in the perimeter network.
Depending on your Web SSO design Checklist: Configuring the Account

plan and how you intend to use it, add Partner Organization
the appropriate attribute store, relying
party trusts, claims, and claim rules to
the Federation Service.
TASK REFERENCE
If you are an administrator in the Windows Identity Foundation

resource partner organization, claims-
enable your Web browser application, Windows Identity Foundation SDK
Web service application, or Microsoft®
Office SharePoint® Server application
using WIF and the WIF SDK. Note:
Checklist: Implementing a Federated Web SSO
Design
This parent checklist includes cross-reference links to important concepts about the Federated Web Single-Sign-
On (SSO ) design for Active Directory Federation Services (AD FS ). It also contains links to subordinate checklists
that will help you complete the tasks that are required to implement this design.
NOTE
Complete the tasks in this checklist in order. When a reference link takes you to a conceptual topic or to a subordinate
checklist, return to this topic after you review the conceptual topic or you complete the tasks in the subordinate checklist so
that you can proceed with the remaining tasks in this checklist.
TASK REFERENCE
Review important concepts about the Federated Web SSO Design

Federated Web SSO design and
determine which AD FS deployment Identifying Your AD FS Deployment
goals you can use to customize this Goals
design to meet the needs of your
organization. Planning Your Deployment
Review the hardware, software, Appendix A: Reviewing AD FS

certificate, Domain Name System (DNS), Requirements
attribute store, and client requirements
for deploying AD FS in your
organization.
Review important concepts about Understanding Key AD FS Concepts

claims, claim rules, attribute stores, and
the AD FS configuration database
before deploying AD FS in both partner
organizations.
According to your design plan, install Checklist: Setting Up a Federation

one or more federation servers in each Server
partner organization. Note: For the
Federated Web SSO design, you need at
least one federation server in the
account partner organization and at
least one federation server in the
resource partner organization.
TASK REFERENCE
(Optional) Determine whether or not Checklist: Setting Up a Federation

your organization needs a federation Server Proxy
server proxy. If your design plan calls for
a proxy, you can install one or more
federation server proxies in each
partner organization.
According to your design plan, share Checklist: Configuring the Account

certificates, configure clients, and Partner Organization
configure the trust relationships in both
partner organizations so that they can Checklist: Configuring the Resource
communicate over a federation trust. Partner Organization
If you are an administrator in the Windows Identity Foundation

resource partner organization, claims-
enable your Web browser application, Windows Identity Foundation SDK
Web service application, or Microsoft®
Office SharePoint® Server application
using WIF and the WIF SDK.
Configuring Partner Organizations
To deploy a new partner organization in Active Directory Federation Services (AD FS ), complete the tasks in either
Checklist: Configuring the Resource Partner Organization or Checklist: Configuring the Account Partner
Organization, depending on your AD FS design.
NOTE
When you use either of these checklists, we strongly recommend that you first read the references to account partner or
resource partner planning guidance in the AD FS Design Guide in Windows Server 2012 before continuing to the procedures
for setting up the new partner organization. Following the checklist in this way will help provide a better understanding of the
full AD FS design and deployment story for the account partner or resource partner organization.
About account partner organizations

An account partner is the organization in the federation trust relationship that physically stores user accounts in an
AD FS –supported attribute store. The account partner is responsible for collecting and authenticating a user's
credentials, building up claims for that user, and packaging the claims into security tokens. These tokens can then be
presented across a federation trust to enable access to Web-based resources that are located in the resource
In other words, an account partner represents the organization for whose users the account-side federation server
issues security tokens. The federation server in the account partner organization authenticates local users and
creates security tokens that the resource partner uses in making authorization decisions.
With regard to attribute stores, the account partner in AD FS is conceptually equivalent to a single Active Directory
forest whose accounts need access to resources that are physically located in another forest. Accounts in this forest
can access resources in the resource forest only when an external trust or forest trust relationship exists between
the two forests and the resources to which the users are trying to gain access have been set with the proper
authorization permissions.
About resource partner organizations

The resource partner is the organization in an AD FS deployment where Web servers are located. The resource
partner trusts the account partner to authenticate users. Therefore, to make authorization decisions, the resource
partner consumes the claims that are packaged in security tokens that come from users in the account partner.
In other words, a resource partner represents the organization whose Web servers are protected by the resource-
side federation server. The federation server at the resource partner uses the security tokens that are produced by
the account partner to make authorization decisions for Web servers in the resource partner.
To function as an AD FS resource, Web servers in the resource partner organization must either have Windows
Identity Foundation (WIF ) installed or have the Active Directory Federation Services (AD FS ) 1.x Claims-Aware
Web Agent role services installed. Web servers that function as an AD FS resource can host either Web-browser-
based or Web-service-based applications.
Checklist: Configuring the Account Partner
Organization
The account partner organization contains the users that will access Web-based applications in the resource
partner. Administrators in this organization must use the AD FS Management snap-in to create relying party trusts
to represent their trust relationships with resource partner organizations. In turn, the resource partner
administrator must create claims provider trusts for each account partner organization that they want to trust.
This checklist includes tasks for deploying Active Directory Federation Services (AD FS ) in the account partner
organization. It also includes tasks for configuring the components that are required to establish one-half of a
federation partnership.
If you are deploying a Web SSO Design, you do not have to follow this checklist. However, you do have to
complete the tasks in this checklist to successfully deploy a Federated Web SSO Design.
IMPORTANT
Make sure that the administrator in the resource partner organization follows the guidance in Checklist: Configuring the
Resource Partner Organization to ensure that all necessary deployment tasks will be completed to successfully create the
second half of the federation partnership.
NOTE
Complete the tasks in this checklist in order. When a reference link takes you to a procedure, return to this topic after you
complete the steps in that procedure so that you can proceed with the remaining tasks in this checklist.
Checklist: Configuring the account partner organization
TASK REFERENCE
If you have an existing AD FS 1.0 or 1.1 Planning a Migration to AD FS 2.0

deployment in your production
environment today, see the link to the
right for information about how to
migrate settings from your current
Federation Service to a new AD FS
Federation Service. If you are deploying
AD FS for the first time in your
organization using AD FS, you can skip
this step and continue to the next task
in this checklist for information about
how to set up a new account partner
organization.
TASK REFERENCE
Based on your deployment goals, review Provide Your Active Directory Users
information about the components that Access to Your Claims-Aware
are required to provide users with Applications and Services
access to the federated applications.
Provide Your Active Directory Users
Provide Users in Another

Organization Access to Your Claims-
Aware Applications and Services
Determine which AD FS design this Web SSO Design

account partner organization will be
associated with. Federated Web SSO Design
Before you begin deploying your AD FS Determine Your AD FS Deployment

servers, review the; 1.) advantages and Topology
disadvantages of choosing either
Windows Internal Database (WID) or AD FS Deployment Topology
SQL Server to store the AD FS Considerations
configuration database 2.) AD FS
deployment topology types and their
associated server placement and
network layout recommendations.
Review AD FS capacity planning Planning for AD FS Server Capacity

guidance to determine the proper
number of federation server and
federation server proxy servers you
should use in your production
environment.
To effectively plan and implement the Checklist: Setting Up a Federation

physical topology for the account Server
partner deployment, determine whether
your AD FS design requires one or more Checklist: Setting Up a Federation
federation servers or federation server Server Proxy
proxies.
Determine the type of attribute store The Role of Attribute Stores

that you want to add to AD FS. Then,
add the attribute store using the AD FS Add an Attribute Store
Management snap-in.
If you will need to send claims to or Planning for Interoperability with AD

consume claims from a resource partner FS 1.x
who is using either an AD FS 1.0 or 1.1
Federation Service, see the link to the
configure AD FS to interoperate with
previous versions of AD FS. If the
resource partner organization is also
using AD FS to send or consume claims
to your organization, you can skip this
step and continue with the next task in
this checklist.
TASK REFERENCE
After you deploy the first federation Create a Relying Party Trust Manually
server in the account partner
organization, create a relying party trust Create a Relying Party Trust Using
relationship using the AD FS Federation Metadata
Management snap-in. You can create a
relying party trust by entering data
about a resource partner manually or
by using a federation metadata URL
that the administrator of the resource
partner organization provides to you.
You can use the federation metadata to
retrieve the data for the resource
partner automatically. Note: If the
resource partner publishes its federation
metadata or can provide a file copy of it
for you to use, we recommend that you
retrieve the data automatically because
it can save time.
Depending on the needs of your Checklist: Creating Claim Rules for a

organization, create one or more claim Relying Party Trust
rule sets for each relying party trust
that is specified in the AD FS
Management snap-in so that claims will
be issued appropriately.
A claim description must be created if Add a Claim Description

one does not already exist that will fulfill
the needs of your organization. AD FS
ships with a default set of claim
descriptions that are exposed in the AD
FS Management snap-in.
Determine whether your organization When to Use Identity Delegation

will need to use identity delegation to
authorize or constrain a specified
account to "act as" or impersonate
other users. This is often a requirement
when front-end Web applications must
interact with back-end Web services.
Prepare client computers for federation Prepare Client Computers in the

by: Account Partner
- Adding the URL for the account Configure Client Computers to Trust
partner federation server to the trusted the Account Federation Server
sites list for the client browser.
- Using Group Policy to push the Distribute Certificates to Client
appropriate Secure Sockets Layer (SSL) Computers by Using Group Policy
certificates to client computers.
Checklist: Configuring the Resource Partner
Organization
The resource partner organization contains the Web servers hosting the Web-based applications that will be
accessed by users in the account partner. Administrators in this organization must use the AD FS Management
snap-in to create claims provider trusts to represent their trust relationships with account partner organizations. In
turn, the account partner administrator must create relying party trusts for each account partner organization that
they want to trust.
This checklist includes the tasks that are necessary for deploying Active Directory Federation Services (AD FS ) in
the resource partner organization. It also includes tasks for configuring the components that are required to
establish one-half of a federation partnership.
If you are deploying a Web SSO Design, you do not have to follow this checklist. However, you do have to
complete the tasks in this checklist to successfully deploy a Federated Web SSO Design.
IMPORTANT
Make sure that the administrator of the account partner organization follows the guidance in Checklist: Configuring the
Account Partner Organization to ensure that all necessary deployment tasks will be completed to successfully create the
second half of the federation partnership
NOTE
Checklist: Configuring the resource partner organization
TASK REFERENCE
If you have an existing AD FS 1.0 or 1.1 Planning a Migration to AD FS

deployment in your production
environment today, see the link to the
migrate settings from your current
Federation Service to a new AD FS
Federation Service. If you are deploying
AD FS for the first time in your
organization using AD FS, you can skip
this step and continue to the next task
in this checklist for information about
how to set up a new resource partner
organization.
TASK REFERENCE
Based on your deployment goals, review Provide Your Active Directory Users
information about the components that Access to Your Claims-Aware
are required to provide users with Applications and Services
access to the federated applications.
Provide Your Active Directory Users
Provide Users in Another

Organization Access to Your Claims-
Aware Applications and Services
Determine which AD FS design this Web SSO Design

resource partner organization will be
associated with. Federated Web SSO Design
Review the different application types, Determine Your Federated

and decide which application to deploy. Application Strategy in the Resource
Partner

servers, review the; 1.) advantages and Topology
disadvantages of choosing either
Windows Internal Database (WID) or AD FS Deployment Topology
SQL Server to store the AD FS Considerations
configuration database 2.) AD FS
deployment topology types and their
Review AD FS capacity planning Planning for AD FS Server Capacity

guidance to determine the proper
number of federation server and
federation server proxy servers you
environment.
To effectively plan and implement the Checklist: Setting Up a Federation

physical topology for the account Server
partner deployment, determine whether
your AD FS design requires one or more Checklist: Setting Up a Federation
federation servers or federation server Server Proxy
proxies.
Determine the type of attribute store The Role of Attribute Stores

that you want to add to AD FS. Then,
add the attribute store using the AD FS Add an Attribute Store
Management snap-in.
TASK REFERENCE
If you will need to send claims to or Planning for Interoperability with AD

consume claims from an account FS 1.x
partner who is using either an AD FS
1.0 or 1.1 Federation Service, see the
link to the right for information about
how to configure AD FS to interoperate
with previous versions of AD FS. If the
account partner organization is also
using AD FS to send or consume claims
to your organization, you can skip this
step and continue with the next task in
this checklist.
After you deploy the first federation Create a Relying Party Trust Manually
server in the resource partner
organization, create a claims provider Create a Relying Party Trust Using
trust relationship by using the AD FS Federation Metadata
Management snap-in. You can create a
claims provider trust by entering data
about an account partner manually or
by using a federation metadata URL
that the administrator of the account
partner organization provides to you.
You can use the federation metadata to
retrieve the data for the resource
partner automatically. Note: If the
account partner publishes its federation
metadata or can provide a file copy of it
for you to use, we recommend that you
retrieve the data automatically because
it can save time.
Depending on the needs of your Checklist: Creating Claim Rules for a

organization, create one or more claim Claims Provider Trust
rule sets for each claims provider trust
that is specified in the AD FS
Management snap-in so that incoming
claims will be passed through,
transformed, or mapped appropriately
to corresponding claims in the resource
partner.
(Optional) A claim description may have Add a Claim Description

to be created if one does not already
exist that will fulfill the needs of your
organization. AD FS includes a default
set of claim descriptions that are
exposed in the AD FS Management
snap-in.
Add an Attribute Store
User accounts and computer accounts that require access to a resource that is protected by Active Directory
Federation Services (AD FS ) are stored in an attribute store, such as Active Directory Domain Services (AD DS ).
The claims issuance engine uses attribute stores to gather data that is necessary to issue claims. Data from the
attribute stores is then projected as claims.
You can use the following procedure to add an attribute store to the Federation Service.
Default Groups.
To add an attribute store
1. Open AD FS Management.
2. Under Actions click Add an attribute store.
1. In the Add an attribute store dialog box, configure the following properties for the attribute store that you
want to add:
In Display name, type the name that you want to use to identify the attribute store.
In Attribute store type, select a supported attribute store type, either Active Directory, LDAP, or
SQL.
In Connection string, if you have selected either a Lightweight Directory Access Protocol (LDAP )
store or a Structured Query Language (SQL ) store, enter the string that you used to establish a
connection to the attribute store. For Active Directory attribute stores, no connection string is
necessary; therefore, this field is disabled.
NOTE
1. Click OK.
AD FS Operations
The Role of Attribute Stores
To add a new claims provider trust by using the AD FS Management snap-in and manually configure the settings,
perform the following procedure on a resource partner federation server in the resource partner organization.
Default Groups.
To create a claims provider trust manually

1. In Server Manager, click Tools, and then select AD FS Management.
2. Under Actions, click Add Claims Provider Trust.
3. On the Welcome page, click Start.

4. On the Select Data Source page, click Enter claims provider trust data manually, and then click Next.
5. On the Specify Display Name page, type a Display name, under Notes, type a description for this claims
provider trust, and then click Next.
6. On the Configure URL page, specify the WS -Federation Passive URL if applicable and click Next.
7. On the Configure Identifier page, under Claims provider trust identifier, type the appropriate identifier,
8. On the Configure Certificates page, click Add to locate a certificate file and add it to the list of certificates,
9. On the Ready to Add Trust page, click Next to save your claims provider trust information.
10. On the Finish page, click Close. This action automatically displays the Edit Claim Rules dialog box. For
more information about how to proceed with adding claim rules for this claims provider trust, see the
following additional references.
To create a claims provider trust using federation metadata
To add a new claims provider trust, using the AD FS Management snap-in, by automatically importing
configuration data about the partner from federation metadata that the partner has published to a local network or
to the Internet, perform the following procedure on a federation server in the resource partner organization.
NOTE
Though it has long been common practice to use certificates with unqualified host names such as https://myserver, these
certificates have no security value and can enable an attacker to impersonate a Federation Service that is publishing
federation metadata. Therefore, when querying federation metadata, you should only use a fully qualified domain name such
as https://myserver.contoso.com.

2. Under Actions, click Add Relying Party Trust.

4. On the Select Data Source page, click Import data about the claims provider published online or on
a local network. In Federation metadata address (host name or URL ), type the federation metadata URL
or host name for the partner, and then click Next.
5. On the Specify Display Name page type a Display name, under Notes type a description for this claims
7. On the Finish page, click Close. This will automatically display the Edit Claim Rules dialog box. For more
information about how to proceed with adding claim rules for this claims provider trust, see the Additional
references section below.
Checklist: Configuring the Resource Partner Organization
See Also
AD FS Operations
The following document provides information on creating a relying party trust manually and using federation
metadata.
To create a claims aware Relying Party Trust manually

To add a new relying party trust by using the AD FS Management snap-in and manually configure the settings,
perform the following procedure on a federation server.
Default Groups.
3. On the Welcome page, choose Claims aware and click Start.

4. On the Select Data Source page, click Enter data about the relying party manually, and then click
Next.
5. On the Specify Display Name page, type a name in Display name, under Notes type a description for
this relying party trust, and then click Next.
6. On the Configure Certificate page, if you have an optional token encryption certificate, click Browse to
locate a certificate file, and then click Next.
7. On the Configure URL page, do one or both of the following, click Next, and then go to step 8:
Select the Enable support for the WS -Federation Passive protocol check box. Under Relying
party WS -Federation Passive protocol URL, type the URL for this relying party trust, and then
click Next.
Select the Enable support for the SAML 2.0 WebSSO protocol check box. Under Relying party
SAML 2.0 SSO service URL, type the Security Assertion Markup Language (SAML ) service
endpoint URL for this relying party trust, and then click Next.
8. On the Configure Identifiers page, specify one or more identifiers for this relying party, click Add to add
them to the list, and then click Next.
9. On the Choose Access Control Policy select a policy and click Next. For more information about Access
Control Policies, see Access Control Policies in AD FS.
10. On the Ready to Add Trust page, review the settings, and then click Next to save your relying party trust
information.
11. On the Finish page, click Close. This action automatically displays the Edit Claim Rules dialog box.
To create a claims aware Relying Party Trust using federation metadata

To add a new relying party trust, using the AD FS Management snap-in, by automatically importing configuration
data about the partner from federation metadata that the partner published to a local network or to the Internet,
perform the following procedure on a federation server in the account partner organization.
NOTE
Default Groups.

4. On the Select Data Source page, click Import data about the relying party published online or on a
local network*. In **Federation metadata address (host name or URL ), type the federation metadata
URL or host name for the partner, and then click Next.
5. On the Specify Display Name page type a name in Display name, under Notes type a description for this
relying party trust, and then click Next.
6. On the Choose Issuance Authorization Rules page, select either Permit all users to access this relying
party or Deny all users access to this relying party, and then click Next.
information.
8. On the Finish page, click Close. This action automatically displays the Edit Claim Rules dialog box. For more
information about how to proceed with adding claim rules for this relying party trust, see the Additional
references.
See Also
AD FS Operations
Add a Claim Description
In an account partner organization, administrators create claims to represent a user's membership in a group or
role or to represent some data about a user, for example, a user’s employee identification number.
In a resource partner organization, administrators create corresponding claims to represent groups and users that
can be recognized as resource users. Because outgoing claims in the account partner organization map to incoming
claims in the resource partner organization, the resource partner is able to accept the credentials that the account
partner provides.
You can use the following procedure to add a claim.
Default Groups.
To add a claim description

2. Expand Service and on the right click Add Claim Description.
3. On the Add a Claim Description dialog box, in Display name, type a unique name that identifies the group
or role for this claim.
4. Add a Short Name.
5. In Claim identifier, type a URI that is associated with the group or role of the claim that you will be using.
6. Under Description, type text that best describes the purpose of this claim.
7. Depending on the needs of your organization, select either of the following check boxes, as appropriate, to
publish this claim into federation metadata:
- To publish this claim to make partners aware that this server can accept this claim, click **Publish this
claim in federation metadata as a claim type that this Federation Service can accept**.
- To publish this claim to make partners aware that this server can issue this claim, click **Publish this
claim in federation metadata as a claim type that this Federation Service can send**.
1. Click OK.
See Also
AD FS Operations
Configure Client Computers to Trust the Account
Federation Server
So that client computers can successfully access federated applications using Active Directory Federation Services
(AD FS ), you must first configure the Internet Explorer settings on each client computer so that the browser trusts
the account federation server. You can do this manually or through Group Policy, depending on your administrative
preference, by completing one of the following procedures.
Configuring Internet Explorer settings manually

You can use the following procedure to manually configure each user's Internet Explorer settings to support
federation through AD FS. If multiple users use a single computer, complete this procedure multiple times—once
for each user profile.
To perform this procedure, log on as the user who will be accessing federated applications. This is a profile-specific
setting. Therefore, it requires that you manually add this setting for each profile that exists on a specific computer.
To manually configure client computers to trust the account federation server
1. On the client computer, start Internet Explorer.
2. On the Tools menu, click Internet Options.
3. On the Security tab, click the Local intranet icon, and then click Sites.
4. Click Advanced, and in Add this Web site to the zone, type the full Domain Name System (DNS ) name
of the account federation server (for example, https://fs1.fabrikam.com), and then click Add.
5. Click OK three times.
Configuring Internet Explorer settings by using Group Policy

For most deployments, we recommend that you use Group Policy to push the appropriate Internet Explorer
settings to each client computer.
Membership in Domain Admins or Enterprise Admins, or equivalent, in Active Directory Domain Services (AD
DS ) is the minimum required to complete this procedure. Review details about using the appropriate accounts and
group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
To configure client computers to trust the account federation server by using Group Policy
1. On a domain controller in the forest of the account partner organization, start the Group Policy
Management snap-in.
2. Find the appropriate Group Policy Object (GPO ), right-click it, and then click Edit.
3. In the console tree, open User Configuration\Preferences\Windows Settings\Internet Explorer
Maintenance, and then click Security.
4. In the details pane, double-click Security Zones and Content Ratings.
5. Under Security Zones and Privacy, click Import the current security zones and privacy settings, and
then click Modify Settings.
6. Click Local intranet, and then click Sites.
7. In Add this Web site to the zone, type the full DNS name of the account federation server (for example,
https://fs1.fabrikam.com), click Add, and then click Close.
8. Click OK two times to apply these changes to Group Policy.
Distribute Certificates to Client Computers by Using
Group Policy
You can use the following procedure to push down the appropriate Secure Sockets Layer (SSL ) certificates (or
equivalent certificates that chain to a trusted root) for account federation servers, resource federation servers, and
Web servers to each client computer in the account partner forest by using Group Policy.
Membership in Domain Admins or Enterprise Admins, or equivalent, in Active Directory Domain Services (AD
DS ) is the minimum required to complete this procedure. Review details about using the appropriate accounts and
group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
To distribute certificates to client computers by using Group Policy
1. On a domain controller in the forest of the account partner organization, start the Group Policy
Management snap-in.
2. Find an existing Group Policy Object (GPO ) or create a new GPO to contain the certificate settings. Ensure
that the GPO is associated with the domain, site, or organizational unit (OU ) where the appropriate user and
computer accounts reside.
3. Right-click the GPO, and then click Edit.
4. In the console tree, open Computer Configuration\Policies\Windows Settings\Security
Settings\Public Key Policies, right-click Trusted Root Certification Authorities, and then click Import.
5. On the Welcome to the Certificate Import Wizard page, click Next.
6. On the File to Import page, type the path to the appropriate certificate files (for example, \\fs1\c$\fs1.cer),
7. On the Certificate Store page, click Place all certificates in the following store, and then click Next.
8. On the Completing the Certificate Import Wizard page, verify that the information you provided is
accurate, and then click Finish.
9. Repeat steps 2 through 6 to add additional certificates for each of the federation servers in the farm.
In a claims-based identity model, the function of Active Directory Federation Services (AD FS ) as federation
services is to issue a token that contains a set of claims. Claims rules govern the decision in regard of claims that
AD FS issues. Claim rules and all server configuration data are stored in the AD FS configuration database.
AD FS makes issuance decisions that are based on identity information that is provided to it in the form of claims
and other contextual information. At a high level, AD FS operates as a rules processor by taking one set of claims as
input, performs a number of transformations, and then returns a different set of claims as output.
Create a Rule to Pass Through or Filter an Incoming Claim
Create a Rule to Send an AD FS 1.x Compatible Claim
Create a Rule to Send LDAP Attributes as Claims
AD FS Operations
Checklist: Creating Claim Rules for a Claims Provider
Trust
This checklist includes tasks for planning, designing, and deploying claim rules that are associated with a claims
provider trust in Active Directory Federation Services (AD FS ).
NOTE
Checklist: Creating a claim rule set for a claims provider trust
TASK REFERENCE
Review concepts about claims, claim The Role of Claims

rules, claim rule sets, and claim rule
templates and how they are associated The Role of Claim Rules
with federated trusts.
Review concepts about how a claim The Role of the Claims Pipeline
flows through all the stages in the
claims issuance pipeline and how rules The Role of the Claims Engine
are processed by the claims issuance
engine.
To effectively plan and implement the Determine the Type of Claim Rule
output claims that will be issued over Template to Use
this claims provider trust, determine
whether one or more claim rules are
needed and which claim rules you
should use with this claims provider
trust.
Review concepts about when to create When to Use a Pass Through or Filter
one claim rule over another and how Claim Rule
you can use the claim rule language to
provide more complex logic than When to Use a Transform Claim Rule
standard rules in order to provide a
desired result in the ideal output claim When to Use a Send LDAP Attributes
set. as Claims Rule
When to Use a Send Group

Membership as a Claim Rule
When to Use a Custom Claim Rule

TASK REFERENCE

Depending on the needs of your Create a Rule to Pass Through or

organization, create one or more claim Filter an Incoming Claim
rules for the acceptance transform rules
set that is associated with this claims Create a Rule to Send LDAP
provider trust so that claims will be Attributes as Claims
issued appropriately.
Create a Rule to Send Group
Membership as a Claim
Create a Rule to Transform an

Incoming Claim
Create a Rule to Send an

Authentication Method Claim
Create a Rule to Send an AD FS 1.x

Compatible Claim
Create a Rule to Send Claims Using a

Custom Rule
Checklist: Creating Claim Rules for a Relying Party
Trust
This checklist includes the tasks that are necessary for planning, designing, and deploying claim rules that are
associated with a relying party trust in Active Directory Federation Services (AD FS ).
NOTE
Checklist: Creating a claim rule set for a relying party trust
TASK REFERENCE
Review concepts about claims, claim The Role of Claims

rules, claim rule sets, and claim rule
templates and how they are associated The Role of Claim Rules
with federated trusts.
Review concepts about how a claim The Role of the Claims Pipeline
flows through all the stages in the
claims issuance pipeline and how rules The Role of the Claims Engine
are processed by the claims issuance
engine.
To effectively plan and implement the Determine the Type of Claim Rule
output claims that will be issued over Template to Use
this relying party trust, determine
whether one or more claim rules are
needed and which claim rules you
should use with this relying party trust.
TASK REFERENCE
Review concepts about when to create When to Use a Pass Through or Filter
one claim rule over another and how Claim Rule
you can use the claim rule language to
provide more complex logic than When to Use a Transform Claim Rule
standard rules in order to provide a
desired result in the ideal output claim When to Use a Send LDAP Attributes
set. as Claims Rule

Membership as a Claim Rule
When to Use an Authorization Claim

Rule
When to Use a Custom Claim Rule

Depending on the needs of your Create a Rule to Pass Through or

organization, create one or more claim Filter an Incoming Claim
rules for the rule sets that are
associated with this relying party trust Create a Rule to Send LDAP
so that claims will be issued Attributes as Claims
appropriately.
Create a Rule to Send Group
Membership as a Claim
Create a Rule to Transform an

Incoming Claim
Create a Rule to Send an

Authentication Method Claim
Create a Rule to Send an AD FS 1.x

Compatible Claim
Create a Rule to Send Claims Using a

Custom Rule
Depending on the needs of your Create a Rule to Permit All Users

organization, create one or more claim
rules for either the issuance Create a Rule to Permit or Deny
authorization rules set or the delegation Users Based on an Incoming Claim
authorization rules set that is associated
with this relying party trust so that
users will be permitted access to the
relying party.
Create a Rule to Pass Through or Filter an Incoming
Claim
Using the Pass Through or Filter an Incoming Claim rule template in Active Directory Federation Services (AD FS ),
you can pass through all incoming claims with a selected claim type. You can also filter the values of incoming
claims with a selected claim type. For example, you can use this rule template to create a rule that will send all
incoming group claims. You can also use this rule to send only user principal name (UPN ) claims that end with
@fabrikam.
You can use the following procedure to create a claim rule with the AD FS Management snap-in.
Default Groups.
To create a rule to pass through or filter an incoming claim on a Relying

Party Trust in Windows Server 2016
2. In the console tree, under AD FS, click Relying Party Trusts.
3. Right-click the selected trust, and then click Edit Claim Issuance Policy.
4. In the Edit Claim Issuance Policy dialog box, under Issuance Transform Rules click Add Rule to start
the rule wizard.

5. On the Select Rule Template page, under Claim rule template, select Pass Through or Filter an
Incoming Claim from the list, and then click Next.
6. On the Configure Rule page under Claim rule name type the display name for this rule, in Incoming
claim type select a claim type in the list, and then select one of the following options, depending on the
needs of your organization:
Pass through all claim values
Pass through only a specific claim value
Pass through only claim values that match a specific email suffix value
Pass through only claim values that start with a specific value
7. Click the Finish button.
8. In the Edit Claim Rules dialog box, click OK to save the rule.
To create a rule to pass through or filter an incoming claim on a Claims

Provider Trust in Windows Server 2016
2. In the console tree, under AD FS, click Claims Provider Trusts.
3. Right-click the selected trust, and then click Edit Claim Rules.
4. In the Edit Claim Rules dialog box, under Acceptance Transform Rules click Add Rule to start the rule
wizard.
To create a rule to pass through or filter an incoming claim in Windows

Server 2012 R2
2. In the console tree, under AD FSAD FS\Trust Relationships, click either Claims Provider Trusts or
Relying Party Trusts, and then click a specific trust in the list where you want to create this rule.
4. In the Edit Claim Rules dialog box, select one the following tabs, depending on the trust you are editing
and which rule set you want to create this rule in, and then click Add Rule to start the rule wizard that is
associated with that rule set:
Acceptance Transform Rules
Issuance Transform Rules
Issuance Authorization Rules
Delegation Authorization Rules

When to Use a Pass Through or Filter Claim Rule
The Role of Claims
In situations in which you are using Active Directory Federation Services (AD FS ) to issue claims that will be
received by federation servers running AD FS 1.0 (Windows Server 2003 R2) or AD FS 1.1 (Windows Server 2008
or Windows Server 2008 R2), you must do the following:
Create a rule that will send a Name ID claim type with a format of UPN, Email, or Common Name.
All other claims that are sent must have one of the following claim types:
AD FS 1.x Email Address
AD FS 1.x UPN
Common Name
Group
Any other claim type that begins with https://schemas.xmlsoap.org/claims/, such as
https://schemas.xmlsoap.org/claims/EmployeeID
Depending on the needs of your organization, use one of the following procedures to create an AD FS 1.x
compatible NameID claim:
Create this rule to issue an AD FS 1.x Name ID claim using the Pass Through or Filter an Incoming
Claim rule template
Create this rule to issue an AD FS 1.x Name ID claim using the Transform an Incoming Claim rule
template. You can use this rule template in situations in which you want to change the existing claim type to
a new claim type that will work with AD FS 1. x claims.
NOTE
For this rule to work as expected, make sure that the relying party trust or claims provider trust where you are creating this
rule has been configured to use the AD FS 1.0 and 1.1 profile.
To create a rule to issue an AD FS 1.x Name ID claim using the Pass

Through or Filter an Incoming Claim rule template on a Relying Party
Trust in Windows Server 2016
the rule wizard.
6. On the Configure Rule page, type a claim rule name.

7. In Incoming claim type, select Name ID in the list.
8. In Incoming name ID format, select one of the following AD FS 1.x-compatible claim formats from the
list:
UPN
E -Mail
Common Name
9. Select one of the following options, depending on the needs of your organization:
10. Click Finish, and then click OK to save the rule.

Through or Filter an Incoming Claim rule template on a Claims Provider
wizard.
list:
UPN
E -Mail
Common Name
To create a rule to transform an incoming claim on a Relying Party Trust

in Windows Server 2016
the rule wizard.

5. On the Select Rule Template page, under Claim rule template, select Transform an Incoming Claim
from the list, and then click Next.
7. In Incoming claim type, select the type of incoming claim that you want to transform in the list.
8. In Outgoing claim type, select Name ID in the list.
9. In Outgoing name ID format, select one of the following AD FS 1.x-compatible claim formats from the
list:
UPN
E -Mail
Common Name
Replace an incoming claim value with a different outgoing claim value
Replace incoming e-mail suffix claims with a new e-mail suffix
To create a rule to transform an incoming claim on a Claims Provider

wizard.
list:
UPN
E -Mail
Common Name

Through or Filter an Incoming Claim rule template on Windows Server
2012 R2
1. In Server Manager, click Tools, and then click AD FS Management.
2. In the console tree, under AD FS\Trust Relationships, click either Claims Provider Trusts or Relying
Party Trusts, and then click a specific trust in the list where you want to create this rule.

list:
UPN
E -Mail
Common Name
To create a rule to issue an AD FS 1.x Name ID claim using the

Transform an Incoming Claim rule template in Windows Server 2012 R2
4. In the Edit Claim Rules dialog box, select one the following tabs, which depends on the trust that you are
editing and in which rule set you want to create this rule, and then click Add Rule to start the rule wizard
that is associated with that rule set:

list:
UPN
E -Mail
Common Name
When to Use an Authorization Claim Rule
The Role of Claims
In Windows Server 2016, you can use an Access Control Policy to create a rule that will give all users access to a
relying party. In Windows Server 2012 R2, using the Permit All Users rule template in Active Directory Federation
Services (AD FS ), you can create an authorization rule that will give all users access to the relying party.
You can use additional authorization rules to further restrict access. Users who are permitted to access the relying
party from the Federation Service may still be denied service by the relying party.
You can use the following procedures to create a claim rule with the AD FS Management snap-in.
Default Groups.
To create a rule to permit all users in Windows Server 2016

3. Right-click the Relying Party Trust that you want to permit access to and select Edit Access Control
Policy.
4. On the Access control policy select Permit everyone and then click Apply and Ok.
To create a rule to permit all users in Windows Server 2012 R2

2. In the console tree, under AD FS\Trust Relationships\Relying Party Trusts, click a specific trust in the list
where you want to create this rule.
4. In the Edit Claim Rules dialog box, click the Issuance Authorization Rules tab or the Delegation
Authorization Rules tab (based on the type of authorization rule you require), and then click Add Rule to
start the Add Authorization Claim Rule Wizard.
5. On the Select Rule Template page, under Claim rule template, select Permit All Users from the list, and
then click Next.
6. On the Configure Rule page, click Finish.
The Role of Claims
Create a Rule to Permit or Deny Users Based on an
Incoming Claim
In Windows Server 2016, you can use an Access Control Policy to create a rule that will permit or deny users
based on an incoming claim. In Windows Server 2012 R2, using the Permit or Deny Users Based on an
Incoming Claim rule template in Active Directory Federation Services (AD FS ), you can create an authorization
rule that will grant or deny user’s access to the relying party based on the type and value of an incoming claim.
For example, you can use this to create a rule that will permit only users that have a group claim with a value of
Domain Admins to access the relying party. If you want to permit all users to access the relying party, use the
Permit Everyone Access Control Policy or the Permit All Users rule template depending on your version of
Windows Server. Users who are permitted to access the relying party from the Federation Service may still be
denied service by the relying party.
Default Groups.
To create a rule to permit users based on an incoming claim on

Windows Server 2016
2. In the console tree, under AD FS, click Access Control Policies.
3. Right-click and select Add Access Control Policy.

4. In the name box, enter a name for your policy, a description and click Add.
5. On the Rule Editor, under users, place a check in with specific claims in the request and click the
underlined specific at the bottom.
6. On the Select Claims screen, click the Claims radio button, select the Claim type, the Operator, and the
Claim Value then click Ok.
7. On the Rule Editor click Ok. On the Add Access Control Policy screen, click Ok.
8. In the AD FS Management console tree, under AD FS, click Relying Party Trusts.
Policy.
10. On the Access control policy select your policy and then click Apply and Ok.
To create a rule to deny users based on an incoming claim on Windows
Server 2016
2. In the console tree, under AD FS, click Access Control Policies.
3. Right-click and select Add Access Control Policy.

4. In the name box, enter a name for your policy, a description and click Add.
5. On the Rule Editor, make sure everyone is selected and under Except place a check in with specific
claims in the request and click the underlined specific at the bottom.
6. On the Select Claims screen, click the Claims radio button, select the Claim type, the Operator, and the
Claim Value then click Ok.
7. On the Rule Editor click Ok. On the Add Access Control Policy screen, click Ok.
8. In the AD FS Management console tree, under AD FS, click Relying Party Trusts.
Policy.
10. On the Access control policy select your policy and then click Apply and Ok.
To create a rule to permit or deny users based on an incoming claim on
2. In the console tree, under AD FS\Trust Relationships\Relying Party Trusts, click a specific trust in the list
where you want to create this rule.
4. In the Edit Claim Rules dialog box, click the Issuance Authorization Rules tab or the Delegation
Authorization Rules tab (based on the type of authorization rule you require), and then click Add Rule to
start the Add Authorization Claim Rule Wizard.
5. On the Select Rule Template page, under Claim rule template, select Permit or Deny Users Based on
an Incoming Claim from the list, and then click Next.
claim type select a claim type in the list, under Incoming claim value type a value or click Browse (if it is
available) and select a value, and then select one of the following options, depending on the needs of your
organization:
Permit access to users with this incoming claim
Deny access to users with this incoming claim
7. Click Finish.
The Role of Claims
Using the Send LDAP Attributes as Claims rule template in Active Directory Federation Services (AD FS ), you can
create a rule that will select attributes from a Lightweight Directory Access Protocol (LDAP ) attribute store, such as
Active Directory, to send as claims to the relying party. For example, you can use this rule template to create a Send
LDAP Attributes as Claims rule that will extract attribute values for authenticated users from the displayName and
telephoneNumber Active Directory attributes and then send those values as two different outgoing claims.
You can also use this rule to send all the user’s group memberships. If you want to send only individual group
memberships, use the Send Group Membership as a Claim rule template. You can use the following procedure to
create a claim rule with the AD FS Management snap-in.
Default Groups.
To create a rule to send LDAP attributes as claims for a Relying Party

the rule wizard.

5. On the Select Rule Template page, under Claim rule template, select Send LDAP Attributes as Claims
6. On the Configure Rule page under Claim rule name type the display name for this rule, select the
Attribute Store, and then select the LDAP attribute and map it to the outgoing claim type.

To create a rule to send LDAP attributes as claims for a Claims Provider

wizard.
6. On the Configure Rule page under Claim rule name type the display name for this rule, select the
Attribute Store, and then select the LDAP attribute and map it to the outgoing claim type.

To create a rule to send LDAP attributes as claims for Windows Server

2012 R2
2. In the console tree, under AD FSAD FS\Trust Relationships, click either Claims Provider Trusts or
Relying Party Trusts, and then click a specific trust in the list where you want to create this rule.
4. In the Edit Claim Rules dialog box, select one the following tabs, depending on the trust that you are
editing and which rule set you want to create this rule in, and then click Add Rule to start the rule wizard
6. On the Configure Rule page under Claim rule name type the display name for this rule, under Attribute
store select Active Directory, and under Mapping of LDAP attributes to outgoing claim types select
the desired LDAP Attribute and corresponding Outgoing Claim Type types from the drop-down lists.
You have to select a new LDAP attribute and outgoing claim type pair on a different row for each Active
Directory attribute that you want to issue a claim for as part of this rule.

The Role of Claims
Using the Send Group Membership as a Claim rule template in Active Directory Federation Services (AD FS ), you
can create a rule that will make it possible for you to select an Active Directory security group to send as a claim.
Only a single claim will be emitted from this rule, based on the group that you select. For example, you can use this
rule template to create a rule that will send a group claim with a value of Admin if the user is a member of the
Domain Admins security group. This rule should be used only for users in the local Active Directory domain.
Default Groups.
To create a rule to send group membership as a claim on a Relying

the rule wizard.

5. On the Select Rule Template page, under Claim rule template, select Send Group Membership as
Claim from the list, and then click Next.
6. On the Configure Rule page under Claim rule name type the display name for this rule, in User’s group
click Browse and select a group, under Outgoing claim type select the desired claim type, and then under
Outgoing Claim Type type a value.

To create a rule to send group membership as a claim on a Claims

wizard.

To create a rule to send group membership as a claim in Windows

Server 2012 R2
5. On the Select Rule Template page, under Claim rule template, select Send Group Membership as a
7. Click Finish.
The Role of Claims
By using the Transform an Incoming Claim rule template in Active Directory Federation Services (AD FS ), you
can select an incoming claim, change its claim type, and change its claim value. For example, you can use this rule
template to create a rule that sends a role claim with the same claim value of an incoming group claim. You can also
use this rule to send a group claim with a claim value of Purchasers when there is an incoming group claim with a
value of Admins, or you can send only user principal name (UPN ) claims that end with @fabrikam.
Default Groups.

the rule wizard.

6. On the Configure Rule page, under Claim rule name, type the display name for this rule. In Incoming
claim type, select a claim type in the list. In Outgoing claim type, select a claim type in the list, and then
select one of the following options, which depends on the requirements of your organization:
NOTE
If you are setting up the Dynamic Access Control scenario that uses AD FS-issued claims, first create a transform rule on the
claims provider trust, and in Incoming claim type, type the name for the incoming claim, or, if a claim description was
previously created, select it from the list. Second, in Outgoing claim type, select the claim URL that you want, and then
create a transform rule on the relying party trust to issue the device claim.
For more information about Dynamic Access Control scenarios, see Dynamic Access Control Content Roadmap or Using AD
DS Claims with AD FS.

wizard.
NOTE
To create a rule to transform an incoming claim in Windows Server 2012

R2
NOTE
1. Click Finish.
The Role of Claims
Create a Rule to Send an Authentication Method
Claim
You can use either the Send Group Membership as Claims rule template or the Transform an Incoming Claim
rule template to send an authentication method claim. The relying party can use an authentication method claim to
determine the logon mechanism that the user uses to authenticate and obtain claims from Active Directory
Federation Services (AD FS ). You can also use the Authentication Mechanism Assurance feature of Active Directory
Federation Services (AD FS ) in Windows Server 2012 R2 as input to generate authentication method claims for
situations in which the relying party wants to determine the level of access that is based on smart card logons. For
example, a developer can assign different levels of access to federated users of the relying party application. The
levels of access are based on whether the users log on with their user name and password credentials, as opposed
to their smart cards.
Depending on the requirements of your organization, use one of the following procedures:
Create this rule by using the Send Group Membership as Claims rule template - You can use this rule
template when you want the group that you specify in this template to ultimately determine what
authentication method claim to issue.
Create this rule by using the Transform an Incoming Claim rule template - You can use this rule template
when you want to change the existing authentication method to a new authentication method that works
with a product that does not recognize standard AD FS authentication method claims.
To create by using the Send Group Membership as Claims rule

template on a Relying Party Trust in Windows Server 2016
the rule wizard.

7. Click Browse, select the group whose members should receive this authentication method claim, and then
click OK.
8. In Outgoing claim type, select Authentication method in the list.
9. In Outgoing claim value, type one of the default uniform resource identifier (URI) values in the following
table, depending on your preferred authentication method, click Finish, and then click OK to save the rule.
ACTUAL AUTHENTICATION METHOD CORRESPONDING URI
User name and password authentication https://schemas.microsoft.com/ws/2008/06/identity/authentic

ationmethod/password
Windows authentication https://schemas.microsoft.com/ws/2008/06/identity/authentic

ationmethod/windows
Transport Layer Security (TLS) Mutual authentication that uses https://schemas.microsoft.com/ws/2008/06/identity/authentic

X.509 certificates ationmethod/tlsclient
X.509-based authentication that does not use TLS https://schemas.microsoft.com/ws/2008/06/identity/authentic

ationmethod/x509
To create by using the Send Group Membership as Claims rule

template on a Claims Provider Trust in Windows Server 2016
wizard.
click OK.


ationmethod/windows


ationmethod/x509
To create this rule by using the transform an incoming claim rule
template on a Relying Party Trust in Windows Server 2016
the rule wizard.

7. In Incoming claim type, select Authentication method in the list.
9. Select Replace an incoming claim value with a different outgoing claim value, and then do the
following:
a. In Incoming claim value, type one of the following URI values that are based on the actual
authentication method URI that was used originally, click Finish, and then click OK to save the rule.
b. In Outgoing claim value, type one of the default URI values in the following table, which depends
on your new preferred authentication method choice, click Finish, and then click OK to save the rule.


ationmethod/windows
TLS mutual authentication that uses X.509 certificates https://schemas.microsoft.com/ws/2008/06/identity/authentic

ationmethod/tlsclient

ationmethod/x509
NOTE
Other URI values can be used in addition to the values in the table. The URI values that are shown ion the previous table
reflect the URIs that the relying party accepts by default.
To create this rule by using the transform an incoming claim rule

template on a Claims Provider Trust in Windows Server 2016
wizard.
following:


ationmethod/windows


ationmethod/x509
To create this rule by using the Send Group Membership as Claims rule
template in Windows Server 2012 R2
5. On the Select Rule Template page, under Claim rule template, select Send Group Membership as a

click OK.


ationmethod/windows


ationmethod/x509
NOTE
Other URI values can be used in addition to the values in the table. The URI values that are shown in the previous table reflect
the URIs that the relying party accepts by default.
To create this rule by using the Transform an Incoming Claim rule

template in Windows Server 2012 R2

following:


ationmethod/windows


ationmethod/x509
NOTE
Other URI values can be used in addition to the values in the table. The URI values that are shown ion the previous table
reflect the URIs that the relying party accepts by default.
The Role of Claims
By using the Send Claims Using a Custom Rule template in Active Directory Federation Services (AD FS ), you
can create custom claim rules for situation in which a standard rule template does not satisfy the requirements of
your organization. Custom claim rules are written in the claim rule language and must then be copied into the
Custom rule text box before they can be used in a rule set. For information about constructing the syntax for an
advanced rule, see The Role of the Claim Rule Language.
You can use the following procedure to create a claim rule by using the AD FS Management snap-in.
Default Groups.
To create a rule to pass through or filter an incoming claim on a Relying

the rule wizard.

5. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom
Rule from the list, and then click Next.
6. On the Configure Rule page, under Claim rule name, type the display name for this rule. Under Custom
rule, type or paste the claim rule language syntax that you want for this rule.
7. Click Finish.
To create a rule to pass through or filter an incoming claim on a Claims

wizard.
7. Click Finish.
To create a rule to send claims by using a custom claim in Windows

Server 2012 R2
7. Click Finish.
The Role of Claims
To deploy federation servers in Active Directory Federation Services (AD FS ), complete each of the tasks in
Checklist: Setting Up a Federation Server.
NOTE
When you use this checklist, we recommend that you first read the references to federation server planning in the AD FS
Design Guide in Windows Server 2012 before you begin the procedures for configuring the servers. Following the checklist in
this way provides a better understanding of the design and deployment process for federation servers.
About federation servers

Federation servers are computers running Windows Server 2008 with the AD FS software installed that have been
configured to act in the federation server role. Federation servers authenticate or route requests from user
accounts in other organizations and from client computers that can be located anywhere on the Internet.
The act of installing the AD FS software on a computer and using the AD FS Federation Server Configuration
Wizard to configure it for the federation server role makes that computer a federation server. It also makes the AD
FS Management snap-in available on that computer in the Start\Administrative Tools\ menu so that you can
specify the following:
The AD FS host name where partner organizations and applications will send token requests and responses
The AD FS identifier that partner organizations and applications will use to identify the unique name or
location of your organization
The token-signing certificate that all federation servers in a server farm will use to issue and sign tokens
The location of customized ASP.NET Web pages for client logon, logoff, and account partner discovery that
will enhance the client experience
NOTE
The majority of these core user interface (UI) settings are contained in the web.config file on each federation server.
The AD FS host name and AD FS identifier values are not specified in the web.config file.
Federation servers host a claims issuance engine that issues tokens based on the credentials (for example, user
name and password) that are presented to it. A security token is a cryptographically signed data unit that expresses
one or more claims. A claim is a statement that a server makes (for example, name, identity, key, group, privilege, or
capability) about a client. After the credentials are verified on the federation server (through the user logon
process), claims for the user are collected through examination of the user attributes that are stored in the specified
attribute store.
In Federated Web Single-Sign-On (SSO ) designs (AD FS designs in which two or more organizations are
involved), claims can be modified by claim rules for a specific relying party. The claims are built into a token that is
sent to a federation server in the resource partner organization. After a federation server in the resource partner
receives the claims as incoming claims, it executes the claims issuance engine to run a set of claim rules to filter,
pass through, or transform those claims. The claims are then built into a new token that is sent to the Web server in
the resource partner.
In the Web SSO design (an AD FS design in which only one organization is involved), a single federation server
can be used so that employees can log on once and still access multiple applications.
This checklist includes the deployment tasks that are necessary to prepare a server running Windows Server®
2012 for the federation server role in Active Directory Federation Services (AD FS ).
NOTE
Checklist: Setting up a federation server
TASK REFERENCE

federation servers, review the; 1.) Topology
advantages and disadvantages of
choosing either Windows Internal AD FS Deployment Topology
Database (WID) or SQL Server to store Considerations
the AD FS configuration database 2.) AD
FS deployment topology types and their
Review AD FS capacity planning Planning for Federation Server

guidance to determine the proper Capacity
number of federation servers you
environment.
Review information in the AD FS Design Planning Federation Server Placement

Guide about where to place federation
servers in your organization Where to Place a Federation Server
Determine whether a stand-alone When to Create a Federation Server

federation server or a federation server
farm is better for your deployment. When to Create a Federation Server
Farm
Determine whether this new federation Review the Role of the Federation
server will be created in the account Server in the Account Partner
partner organization or in the resource
partner organization. Review the Role of the Federation
Server in the Resource Partner
TASK REFERENCE
Review information about how Certificate Requirements for

federation servers use service Federation Servers
communication certificates and token-
signing certificates to securely
authenticate client and federation server
proxy requests. Caution: Though it has
long been common practice to use
certificates with unqualified host names
such as https://myserver, these
certificates have no security value and
can enable an attacker to impersonate
the AD FS Federation Service to
enterprise clients. Therefore, it is
recommended that you use a fully
qualified domain name (FQDN) such as
https://myserver.contoso.com and only
use SSL certificates issued to the FQDN
of your Federation Service.
Review information about how to Name Resolution Requirements for

update the corporate network Domain Federation Servers
Name System (DNS) so that successful
name resolution to federation servers
can occur.
Join the computer that will become the Join a Computer to a Domain
federation server to a domain in the
account partner forest or resource
partner forest where it will be used to
authenticate the users of that forest or
from trusting forests. Note: If you want
to set up a federation server in the
account partner organization, the
computer must first be joined to any
domain in the forest where your
federation server will be used to
authenticate users from that forest or
from trusting forests.
Create a new resource record in the Add a Host (A) Resource Record to
corporate network DNS that points the Corporate DNS for a Federation Server
DNS host name of the federation server
to the IP address of the federation
server.
TASK REFERENCE
(Optional) If you will be adding a Export the Private Key Portion of a

federation server to a federation server Server Authentication Certificate
farm, you might have to first export the
private key of the existing token-signing
certificate (on the first federation server
in the farm) so that you have a file
format of the certificate ready when
other federation servers must import
the same certificate.
Exporting the private key is not required

when your issued server authentication
certificate can be reused by multiple
computers (without the need to export)
or when you will be obtaining unique
server authentication certificates for
each federation server in the farm.
Note: The AD FS Management snap-in
refers to server authentication
certificates for federation servers as
service communication certificates.
After you obtain a server authentication Import a Server Authentication

certificate (or private key) from a Certificate to the Default Web Site
certification authority (CA), you must
then import the certificate file to the
default Web site for each federation
server. Note: Installing this certificate
on the default Web site is a requirement
before you can use the AD FS
Federation Server Configuration Wizard.
(Optional) As an alternative to obtaining IIS: Create a Self-Signed Server

a server authentication certificate from Certificate and then complete the
a CA, you can use Internet Information procedure Import a Server
Services (IIS) to create a sample Authentication Certificate to the Default
certificate for your federation server. Web Site
Caution: It is not a security best
practice to deploy a federation server in
a production environment by using a
self-signed server authentication
certificate.
If you will be configuring a federation Manually Configure a Service Account

server farm environment in an account for a Federation Server Farm
partner organization, you must create
and configure a dedicated service
account in Active Directory Domain
Services (AD DS) where the farm will
reside and configure each federation
server in the farm to use this account.
By performing this procedure, you will
allow clients on the corporate network
to authenticate to any of the federation
servers in the farm using Windows
Integrated Authentication.
TASK REFERENCE
Install the Federation Service role Install the Federation Service Role
service on the computer that will Service
become the federation server.
Configure the AD FS software on the Create a Stand-Alone Federation

computer to act in the federation server Server
role by using the AD FS Federation
Server Configuration Wizard. Create the First Federation Server in a
Federation Server Farm
Follow this procedure when you want to
set up a stand-alone federation server, Add a Federation Server to a
create the first federation server in a Federation Server Farm
new farm or join a computer to an
existing federation server farm. Note:
For the Federated Web Single Sign-On
(SSO) design, you must have at least
one federation server in the account
partner organization and at least one
federation server in the resource
(Optional) Use the AD FS Management Add a Token-Signing Certificate

snap-in to add and configure the
necessary AD FS certificates required to Add a Token-Decrypting Certificate
deploy your design. For more
information about when to add or Set a Service Communications
change certificates using the snap-in, Certificate
see Certificate Requirements for
Federation Servers.
If this is the first federation server in Checklist: Configuring the Account

your organization, configure the Partner Organization
Federation Service so that it conforms
to your AD FS design. Checklist: Configuring the Resource
Partner Organization
From a client computer, verify that the Verify That a Federation Server Is
federation server is operational. Operational
Add a Host (A) Resource Record to Corporate DNS
for a Federation Server
For clients on the corporate network to successfully access a federation server using Windows Integrated
authentication, a host (A) resource record must first be created in the corporate Domain Name System (DNS ) that
resolves the host name of the account federation server (for example, fs.fabrikam.com) to the IP address of the
federation server or federation server cluster. You can use the following procedure to add a host (A) resource
record to corporate DNS for a federation server.
Membership in Administrators, or equivalent, is the minimum required to complete this procedure. Review details
about using the appropriate accounts and group memberships at Local and Domain Default Groups.
To add a host (A ) resource record to corporate DNS for a federation server
1. On a DNS server for the corporate network, open the DNS snap-in.
2. In the console tree, right-click the applicable forward lookup zone, and then click New Host (A or AAAA ).
3. In Name, type only the computer name of the federation server or federation server cluster; for example, for
the fully qualified domain name (FQDN ) fs.fabrikam.com, type fs.
4. In IP address, type the IP address for the federation server or federation server cluster, for example,
192.168.1.4.
5. Click Add Host.
Name Resolution Requirements for Federation Servers
Manually Configure a Service Account for a
If you intend to configure a federation server farm environment in Active Directory Federation Services (AD FS ),
you must create and configure a dedicated service account in Active Directory Domain Services (AD DS ) where the
farm will reside. You then configure each federation server in the farm to use this account. You must complete the
following tasks in your organization when you want to allow client computers on the corporate network to
authenticate to any of the federation servers in an AD FS farm using Windows Integrated Authentication.
NOTE
You have to perform the tasks in this procedure only one time for the entire federation server farm. Later, when you create a
federation server by using the AD FS Federation Server Configuration Wizard, you must specify this same account on the
Service Account wizard page on each federation server in the farm.
Create a dedicated service account

1. Create a dedicated user/service account in the Active Directory forest that is located in the identity provider
organization. This account is necessary for the Kerberos authentication protocol to work in a farm scenario
and to allow pass-through authentication on each of the federation servers. Use this account only for the
purposes of the federation server farm.
2. Edit the user account properties, and select the Password never expires check box. This action ensures that
this service account's function is not interrupted as a result of domain password change requirements.
NOTE
Using the Network Service account for this dedicated account will result in random failures when access is attempted
through Windows Integrated Authentication, as a result of Kerberos tickets not validating from one server to another.
To set the SPN of the service account

1. Because the application pool identity for the AD FS AppPool is running as a domain user/service account,
you must configure the Service Principal Name (SPN ) for that account in the domain with the Setspn.exe
command-line tool. Setspn.exe is installed by default on computers running Windows Server 2008 . Run the
following command on a computer that is joined to the same domain where the user/service account
resides:
setspn -a host/<server name> <service account>
For example, in a scenario in which all federation servers are clustered under the Domain Name System
(DNS ) host name fs.fabrikam.com and the service account name that is assigned to the AD FS AppPool is
named adfs2farm, type the command as follows, and then press ENTER:
setspn -a host/fs.fabrikam.com adfs2farm

It is necessary to complete this task only once for this account.
2. After the AD FS AppPool identity is changed to the service account, set the access control lists (ACLs) on the
SQL Server database to allow Read access to this new account so that the AD FS AppPool can read the
policy data.
Install the Federation Service Role Service
Now that you have properly configured a computer with the prerequisite applications and certificates, you are
ready to install the Federation Service role service of Active Directory Federation Services (AD FS ). When you
install the Federation Service on a computer, that computer becomes a federation server.
NOTE
For the Federated Web Single-Sign-On (SSO) design, you must have at least one federation server in the account partner
organization and at least one federation server in the resource partner organization. For more information, see Where to
Place a Federation Server.
You can use the following procedure to install the Federation Service role service of AD FS on a computer that will
become the first federation server or on a computer that will become a federation server for an existing federation
server farm.
Prerequisites
Verify that an SSL certificate with the private key has already been installed or imported into the local certificate
store (Personal store) before you start this procedure. If you will be using a token-signing certificate that is issued
by a certification authority (CA), verify that a token-signing certificate with the private key has already been
installed or imported into the local certificate store (Personal store) before you start this procedure. As an
alternative, you can create a self-signed, token-signing certificate using the Add Roles Wizard, as described in this
procedure. For more information about token-signing certificates, see Certificate Requirements for Federation
Servers.
Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
To install the Federation Service role service
1. On the Start screen, typeServer Manager, and then press ENTER.
2. Click Manage, and then click Add Roles and Features to start the Add Roles and Features Wizard.
4. On the Select installation type page, click Role-based or Feature-based installation, and click Next.
computer is highlighted, and then click Next.
6. On the Select server roles page, click Active Directory Federation Services, and then click next.
NOTE
If you are prompted to install additional .NET Framework or Windows Process Activation Service features, click Add
Features to install them.
7. On the Select features page, verify that the features are set, and then click Next.
9. On the Select role services page, select the Federation Service check box, and then click Next.
11. On the Select role services page, click Next.
Create the First Federation Server in a Federation
Server Farm
After you install the Federation Service role service and configure the required certificates on a computer, you are
ready to configure the computer to become a federation server. You can use the following procedure to set up the
computer to become the first federation server in a new federation server farm using the AD FS Federation Server
Configuration Wizard.
The act of creating the first federation server in a farm also creates a new Federation Service and makes this
computer the primary federation server. This means that this computer will be configured with a read/write copy of
the AD FS configuration database. All other federation servers in this farm must replicate any changes that are
made on the primary federation server to their read-only copies of the AD FS configuration database that they
store locally. For more information about this replication process, see The Role of the AD FS Configuration
Database.
NOTE
Membership in Domain Admins, or a delegated domain account that has been granted write access to the Program
Data container in Active Directory, is the minimum required to complete this procedure.
To create the first federation server in a federation server farm
1. There are two ways to start the AD FS Federation Server Configuration Wizard. To start the wizard, do one
of the following:
After the Federation Service role service installation is complete, open the AD FS Management snap-
in and click the AD FS Federation Server Configuration Wizard link on the Overview page or in
the Actions pane.
Any time after the setup wizard is complete, open Windows Explorer, navigate to the
C:\Windows\ADFS folder, and then double-click FsConfigWizard.exe.
2. On the Welcome page, verify that Create a new Federation Service is selected, and then click Next.
3. On the Select Stand-Alone or Farm Deployment page, click New federation server farm, and then
click Next.
4. On the Specify the Federation Service Name page, verify that the SSL certificate that is showing is
correct. If this is not the correct certificate, select the appropriate certificate from the SSL certificate list.
This certificate is generated from the Secure Sockets Layer (SSL ) settings for the Default Web Site. If the
Default Web Site has only one SSL certificate configured, that certificate is presented and automatically
selected for use. If multiple SSL certificates are configured for the Default Web Site, all those certificates are
listed here and you must select from among them. If there are no SSL settings configured for the Default
Web Site, the list is generated from the certificates that are available in the personal certificates store on the
local computer.
NOTE
The wizard will not allow you to override the certificate if an SSL certificate is configured for IIS. This ensures that any
intended prior IIS configuration for SSL certificates is preserved. To work around this restriction, you can remove the
certificate or reconfigure it manually with the IIS Management Console.
5. If the AD FS database that you selected already exists, the Existing AD FS Configuration Database
Detected page appears. If that page appears, click Delete database, and then click Next.
Cau t i on
Select this option only when you are sure that the data in this AD FS database is not important or that it is
not used in a production federation server farm.
6. On the Specify a Service Account page, click Browse. In the Browse dialog box, locate the domain
account that will be used as the service account in this new federation server farm, and then click OK. Type
the password for this account, confirm it, and then click Next.
NOTE
See Manually Configure a Service Account for a Federation Server Farm for more information about specifying a
service account for a federation server farm. Each federation server in the federation server farm must specify the
same service account for the farm to be operational. For example, if the service account that was created was
contoso\ADFS2SVC, each computer that you configure for the federation server role and that will participate in the
same farm must specify contoso\ADFS2SVC at this step in the Federation Server Configuration Wizard for the farm to
be operational.
7. On the Ready to Apply Settings page, review the details. If the settings appear to be correct, click Next to
begin configuring AD FS with these settings.
8. On the Configuration Results page, review the results. When all the configuration steps are finished, click
Close to exit the wizard.
IMPORTANT
For secure deployment purposes, artifact resolution and reply detection are disabled when you use the AD FS
Federation Server Configuration Wizard to configure a federation server farm. This wizard automatically configures the
Windows Internal Database for storing service configuration data. You might, however, mistakenly undo this change
by enabling the Artifact Resolution endpoint using either the Endpoints node in the AD FS Management snap-in or
the Enable-ADFSEndpoint cmdlet in Windows PowerShell. Be careful to not reconfigure the default setting so that this
endpoint remains disabled when you use a federation server farm and the Windows Internal Database together.
Create a Stand-Alone Federation Server
ready to configure the computer to become a federation server. You can use the following procedure to set up the
computer to become a stand-alone federation server. The act of creating a stand-alone federation server also
creates a new Federation Service. You do create a federation server with the AD FS Federation Server
NOTE
To create a stand-alone federation server
of the following:
the Actions pane.
Anytime after the setup wizard is complete, open Windows Explorer, navigate to the
C:\Windows\ADFS folder, and then double-click FsConfigWizard.exe.
2. On the Welcome page, verify that Create a new Federation Service is selected, and then click Next.
3. On the Select Stand-Alone or Farm Deployment page, click Stand-alone federation server, and then
click Next.
IMPORTANT
When you select the Stand-alone federation server option in the AD FS Federation Server Configuration Wizard, the
service account associated with this Federation Service will automatically be assigned to the NETWORK SERVICE
account. Using NETWORK SERVICE as the service account is only recommended in situations where you are
evaluating AD FS in a test lab environment. If you intend to use the Stand-alone federation server option to deploy a
federation server in a production environment, it is important that you change this service account to a more
appropriate service account that can be dedicated to serving requests for this new Federation Service. Changing the
service account to an account other than NETWORK SERVICE will mitigate possible attack vectors that would
otherwise make your federation server vulnerable to malicious attacks.
4. On the Specify the Federation Service Name page, verify that the SSL certificate that is showing is
correct. If not, select the appropriate certificate from the SSL certificate list.
This certificate is generated from the Secure Sockets Layer (SSL ) settings for the Default Web Site. If the
Default Web Site has only one SSL certificate configured, that certificate is presented and automatically
selected for use. If multiple SSL certificates are configured for the Default Web Site, all those certificates are
listed here and you must select from among them. If there are no SSL settings configured for the Default
Web Site, the list is generated from the certificates that are available in the personal certificates store on the
local computer.
NOTE
The wizard will not allow you to override the certificate if an SSL certificate is configured for IIS. This ensures that any
intended prior IIS configuration for SSL certificates is preserved. To work around this restriction, you can remove the
certificate or reconfigure manually it with the IIS Management Console.
Detected page appears. If that occurs, click Delete database, and then click Next.
Cau t i on
Add a Federation Server to a Federation Server Farm
ready to configure the computer to become a federation server. You can use the following procedure to join a
computer to a new federation server farm.
You join a computer to a farm with the AD FS Federation Server Configuration Wizard. When you use this wizard
to join a computer to an existing farm, the computer is configured with a read-only copy of the AD FS configuration
database and it must receive updates from a primary federation server.
NOTE
To add a federation server to a federation server farm
of the following:
the Actions pane.
C:\Windows\ADFS folder, and double-click FsConfigWizard.exe.
2. On the Welcome page, verify that Add a federation server to an existing Federation Service is
selected, and then click Next.
Detected page appears. If that occurs, click Delete database, and then click Next.
Cau t i on
4. On the Specify the Primary Federation Server and Service Account page, under Primary federation
server name, type the computer name of the primary federation server in the farm, and then click Browse.
In the Browse dialog box, locate the domain account that is used as the service account by all other
federation servers in the existing federation server farm, and then click OK. Type the password and confirm
it, and then click Next:
NOTE
For more information about specifying a service account for a federation server farm, see Manually Configure a
Service Account for a Federation Server Farm. Each federation server in the federation server farm must specify the
same service account for the farm to be operational. For example, if the service account that was created was
contoso\ADFS2SVC, each computer you configure for the federation server role and that will participate in the same
farm must specify contoso\ADFS2SVC at this step in the Federation Server Configuration Wizard for the farm to be
operational.
Add a Token-Signing Certificate
Federation servers in Active Directory Federation Services (AD FS ) require token-signing certificates to prevent
attackers from altering or counterfeiting security tokens in an attempt to gain unauthorized access to federated
resources. Every token-signing certificate contains cryptographic private keys and public keys that are used to
digitally sign (by means of the private key) a security token. Later, after these keys are received by a partner
federation server, they validate the authenticity (by means of the public key) of the encrypted security token.
Cau t i on
Certificates used for token-signing are critical to the stability of the Federation Service. Because loss or unplanned
removal of any certificates configured for this purpose can disrupt service, you should backup any certificates
configured for this purpose.
The token-signing certificate should chain to a trusted root in the Federation Service. You can use the following
procedure to add the token-signing certificate to the AD FS Management snap-in from a file that you have
exported.
To add a token-signing certificate
1. On the Start screen, typeAD FS Management, and then press ENTER.
2. In the console tree, double-click Service, and then click Certificates.
3. In the Actions pane, click the Add Token-Signing Certificate link.
4. In the Browse for Certificate file dialog box, navigate to the certificate file that you want to add, select the
certificate file, and then click Open.
Add a Token-Decrypting Certificate
Federation servers use a token-decryption certificate when a relying party federation server must decrypt tokens
that are issued with an older certificate after a new certificate is set as the primary decryption certificate. Active
Directory Federation Services (AD FS ) uses the Secure Sockets Layer (SSL ) certificate for Internet Information
Services (IIS ) as the default decryption certificate.
Cau t i on
Certificates used for token-decrypting are critical to the stability of the Federation Service. Because loss or
unplanned removal of any certificates configured for this purpose can disrupt service, you should backup any
certificates configured for this purpose.
You can use the following procedure to add the token-decrypting certificate to the AD FS Management snap-in
from a file that you have exported.
To add a token-decrypting certificate
3. In the Actions pane, click the Add Token-Decrypting Certificate link.
4. In the Browse for Certificate file dialog box, navigate to the certificate file that you want to add, select the
certificate file, and then click Open.
Set a Service Communications Certificate
Federation servers in Active Directory Federation Services (AD FS ) use the service communications certificate to
secure Web services traffic for Secure Sockets Layer (SSL ) communication with Web clients or with federation
server proxies. This is the same certificate that a federation server uses as the SSL certificate in Internet
Information Services (IIS ).
You can use the following procedure to change the service communications certificate with the AD FS
Management snap-in.
NOTE
The AD FS Management snap-in refers to server authentication certificates for federation servers as service communication
certificates.
To set a service communications certificate
3. In the Actions pane, click the Set Service Communications Certificate link.
4. In the Select a service communications certificate dialog box, navigate to the certificate file that you
want to set as the service communications certificate, select the certificate file, and then click Open.
Verify That a Federation Server Is Operational
You can use the following procedures to verify that a federation server is operational; that is, that any client on the
same network can reach a new federation server.
the minimum required to complete this procedure. Review details about using the appropriate accounts and group
memberships at Local and Domain Default Groups.
1. To verify that Internet Information Services (IIS ) is configured correctly on the federation server, log on to a
client computer that is located in the same forest as the federation server.
2. Open a browser window, in the address bar type the federation server’s DNS host name, and then append
/adfs/fs/federationserverservice.asmx to it for the new federation server, for example:
https://fs1.fabrikam.com/adfs/fs/federationserverservice.asmx
3. Press ENTER, and then complete the next procedure on the federation server computer. If you see the
message There is a problem with this website’s security certificate, click Continue to this website.
The expected output is a display of XML with the service description document. If this page appears, IIS on
the federation server is operational and serving pages successfully.
Default Groups.
1. Log on to the new federation server as an administrator.
2. On the Start screen, type Event Viewer, and then press ENTER.
click Admin.
4. In the Event ID column, look for event ID 100. If the federation server is configured properly, you see a new
event—in the Application log of Event Viewer—with the event ID 100. This event verifies that the federation
server was able to successfully communicate with the Federation Service.
To deploy federation server proxies in Active Directory Federation Services (AD FS ), complete each of the tasks in
NOTE
When you use this checklist, we recommend that you first read the references to federation server proxy planning guidance in
the AD FS Design Guide in Windows Server 2012 before you begin the procedures for configuring the servers. Following the
checklist provides a better understanding of the design and deployment process for federation server proxies.
About federation server proxies

Federation server proxies are computers that run Windows Server® 2012 and AD FS software that have been
configured manually to act in the proxy role. You can use federation server proxies in your organization to provide
intermediary services between an Internet client and a federation server that is behind a firewall on your corporate
network.
NOTE
Although the federation server and the federation server proxy roles cannot be installed on the same computer, a federation
server can perform federation server proxy functions. For more information, see When to Create a Federation Server.
The act of installing the AD FS software on a Windows Server® 2012 computer and configuring it to serve in the
proxy role makes that computer a federation server proxy.
This checklist includes the deployment tasks for preparing a server running Windows Server® 2012 for the
federation server proxy role in Active Directory Federation Services (AD FS ).
NOTE
Checklist: Setting Up a federation server proxy
TASK REFERENCE

federation server proxies, review the AD Topology
FS deployment topology types and their
associated server placement and Planning Federation Server Proxy
network layout recommendations. Placement

Proxy
Review AD FS capacity planning Planning for Federation Server Proxy

guidance to determine the proper Capacity
number of federation server proxies you
environment.
Determine whether a single federation When to Create a Federation Server

server proxy or a federation server Proxy
proxy farm is better for your
deployment. Note: Federation servers When to Create a Federation Server
also perform federation server proxy Proxy Farm
responsibilities.
Determine whether this new federation Review the Role of the Federation
server proxy will be created in the Server Proxy in the Account Partner
perimeter network of the account
partner organization or the resource Review the Role of the Federation
partner organization. Server Proxy in the Resource Partner
Before you install AD FS on a computer Certificate Requirements for

that will become a federation server Federation Server Proxies
proxy, read about the importance of
obtaining a server authentication
certificate—for federation server proxy
farms—adding or sharing certificates
across all the servers in a farm.
TASK REFERENCE
Review information in the AD FS Design Name Resolution Requirements for

Guide about how to update Domain Federation Server Proxies
Name System (DNS) in the perimeter
network so that successful name
resolution for federation servers and
federation server proxies can occur.
Determine whether the federation Join a Computer to a Domain

server proxy must be joined to a
domain. Although federation server
proxies do not have to be joined to a
domain, they are easier to manage with
remote administration and Group Policy
features when they are joined to a
domain.
Depending on how the DNS Configure Name Resolution for a

infrastructure in your perimeter network Federation Server Proxy in a DNS Zone
is configured, complete one of the That Serves Only the Perimeter Network
procedures in the topics on the right
before you deploy a federation server Configure Name Resolution for a
proxy in your organization. Note: Do Federation Server Proxy in a DNS Zone
not perform both procedures. Read That Serves Both the Perimeter Network
Name Resolution Requirements for and Internet Clients
Federation Server Proxies to determine
which procedure best suits the
requirements of your organization.
After you obtain a server authentication Import a Server Authentication

certificate, you must install it in Internet Certificate to the Default Web Site
Information Services (IIS) on the default
Web site of the federation server proxy.
(Optional) As an alternative to obtaining IIS: Create a Self-Signed Server

a server authentication certificate from Certificate
a certification authority (CA), you can
use IIS to acquire a sample certificate for
your federation server proxy.
Because IIS generates a self-signed

certificate that does not originate from
a trusted source, use it to create a self-
signed certificate only in the following
scenarios:
- When you have to create a Secure

Sockets Layer (SSL) channel between
your server and a limited, known group
of users
- When you have to troubleshoot third-
party certificate problems Caution: It is
not a security best practice to deploy a
federation server proxy in a production
environment using a self-signed, server
authentication certificate.
Install the Federation Service Proxy role Install the Federation Service Proxy
service on the computer that will Role Service
become the federation server proxy.
TASK REFERENCE
Configure the AD FS software on the Configure a Computer for the

computer to act in the federation server Federation Server Proxy Role
proxy role by using the AD FSFederation
Server Proxy Configuration Wizard.
Using Event Viewer, verify that the Verify That a Federation Server Proxy
federation server proxy service has Is Operational
started.
Join a Computer to a Domain
For Active Directory Federation Services (AD FS ) to function, each computer that functions as a federation server
must be joined to a domain. federation server proxies may be joined to a domain, but this is not a requirement.
You do not have to join a Web server to a domain if the Web server is hosting claims-aware applications only.
Default Groups.
To join a computer to a domain
1. On the Start screen, type Control Panel, and then press ENTER.
2. Navigate to System and Security, and then click System.
3. Under Computer name, domain, and workgroup settings, click Change settings.
4. On the Computer Name tab, click Change.
5. Under Member of, click Domain, type the name of the domain that you wish this computer to join, and
then click OK.
6. Click OK, and then restart the computer.
Configure Name Resolution for a Federation Server
Proxy in a DNS Zone That Serves Only the Perimeter
Network
So that name resolution can work successfully for a federation server in an Active Directory Federation Services
(AD FS ) scenario in which one or more Domain Name System (DNS ) zones serve only the perimeter network, the
following tasks must be completed:
The hosts file on the federation server proxy must be updated to add the IP address of a federation server.
DNS in the perimeter network must be configured to resolve all client requests for the AD FS host name to
the federation server proxy. To do this, you add a host (A) resource record to perimeter DNS for the
NOTE
These procedures assume that a host (A) resource record for the federation server has already been created in the corporate
network DNS. If this record does not yet exist, create this record, and then perform these procedures. For more information
about how to create the host (A) resource record for the federation server, see Add a Host (A) Resource Record to Corporate
DNS for a Federation Server.
Add the IP address of a federation server to the hosts file

So that a federation server proxy can work as expected in the perimeter network of an account partner, you must
add an entry to the hosts file on that federation server proxy that points to a federation server's DNS host name
(for example, fs.fabrikam.com) and IP address (for example, 192.168.1.4) in the corporate network of the account
partner. Adding this entry to the hosts file prevents the federation server proxy from contacting itself to resolve a
client-initiated call to a federation server in the account partner.
Default Groups.
To add the IP address of a federation server to the hosts file
1. Navigate to the %systemroot%\Winnt\System32\Drivers directory folder and locate the hosts file.
2. Start Notepad, and then open the hosts file.
3. Add the IP address and the host name of a federation server in the account partner to the hosts file, as
shown in the following example:
192.168.1.4fs.fabrikam.com
4. Save and close the file.
Add a host (A) resource record to perimeter DNS for a federation

server proxy
So that clients on the Internet can successfully access a federation server through a newly deployed federation
server proxy, you must first create a host (A) resource record in the perimeter DNS. This resource record resolves
the host name of the account federation server (for example, fs.fabrikam.com) to the IP address of the account
federation server proxy (for example, 131.107.27.68) in the perimeter network.
NOTE
It is assumed that you are using a DNS server, running Windows 2000 Server, Windows Server 2003, or Windows Server
2008 with the DNS Server service, to control the perimeter DNS zone.
To add a host (A) resource record to perimeter DNS for a federation server proxy
1. On a DNS server for the perimeter network, open the DNS snap-in. Click Start, point to Administrative
Tools, and then click DNS.
3. In Name, type only the computer name of the federation server. For example, for the fully qualified domain
name (FQDN ) fs.fabrikam.com, type fs.
4. In IP address, type the IP address for the new federation server proxy, for example, 131.107.27.68.
5. Click Add Host.
Configure Name Resolution for a Federation Server
Proxy in a DNS Zone That Serves Both the Perimeter
Network and Internet Clients
So that name resolution can work successfully for a federation server proxy in an Active Directory Federation
Services (AD FS ) scenario in which one or more Domain Name System (DNS ) zones serve both the perimeter
network and Internet clients, the following tasks must be completed:
DNS in the Internet zone that you control must be configured to resolve all Internet client requests for the
AD FS host name to the federation server proxy. To accomplish this, you add a host (A) resource record to
the Internet DNS zone for the federation server proxy.
DNS in the perimeter network must be configured to resolve all incoming client requests for the AD FS host
name to the federation server. To accomplish this, you add a host (A) resource record to the perimeter DNS
zone for the federation server proxy.
NOTE
It is assumed that a host (A) resource record for the federation server has already been created in the corporate network
DNS. If this record does not yet exist, create this record and then perform these procedures. For more information about how
to create a host (A) resource record for the federation server, see Add a Host (A) Resource Record to Corporate DNS for a
Federation Server.
Add a host (A) resource record to the Internet DNS zone for a
federation server proxy
So that client computers on the Internet can successfully access a federation server through a newly deployed
federation server proxy, you must first create a host (A) resource record in the Internet DNS zone that you control.
This resource record resolves the host name of the account federation server (for example, fs.fabrikam.com) to the
IP address of the account federation server proxy (for example, 131.107.27.68) in the perimeter network.
NOTE
It is assumed that you are using a DNS server running Windows 2000 Server, Windows Server 2003, or Windows Server 2008
with the DNS Server service to control the Internet DNS zone.
To add a host (A) resource record to the Internet DNS zone for a federation server proxy
1. On a DNS server for the Internet DNS zone, open the DNS snap-in.
3. In Name, type only the computer name of the federation server. For example, for the fully qualified domain
name (FQDN ) fs.fabrikam.com, type fs.
4. In IP address, type the IP address for the new federation server proxy, for example, 131.107.27.68.
5. Click Add Host.
Add a host (A) resource record to the perimeter DNS zone for a
federation server proxy
So that Internet client requests can be processed successfully by the federation server proxy and reach the
federation server after they are resolved by the Internet DNS zone, you must create a host (A) resource record in
the perimeter DNS zone. This resource record resolves the host name of the account federation server (for
example, fs. fabrikam.com) to the IP address of the account federation server (for example, 192.168.1.4) in the
corporate network.
NOTE
It is assumed that you are using a DNS server running Windows 2000 Server, Windows Server 2003, Windows Server 2008 ,
or Windows Server® 2012 with the DNS Server service to control the perimeter DNS zone.
To add a host (A) resource record to the perimeter DNS zone for a federation server proxy
1. On a DNS server for the perimeter network, open the DNS snap-in.
3. In Name, type only the computer name of the federation server. For example, for the FQDN
fs.fabrikam.com, type fs.
4. In the IP address text box, type the IP address for the federation server in the corporate network, for
example, 192.168.1.4.
5. Click Add Host.
Export the Private Key Portion of a Server
Authentication Certificate
Every federation server in an Active Directory Federation Services (AD FS ) farm must have access to the private
key of the server authentication certificate. If you are implementing a server farm of federation servers or Web
servers, you must have a single authentication certificate. This certificate must be issued by an enterprise
certification authority (CA), and it must have an exportable private key. The private key of the server authentication
certificate must be exportable so that it can be made available to all the servers in the farm.
This same concept is true of federation server proxy farms in the sense that all federation server proxies in a farm
must share the private key portion of the same server authentication certificate.
NOTE
certificates.
Depending on which role this computer will play, use this procedure on the federation server computer or
federation server proxy computer where you installed the server authentication certificate with the private key.
When you finish the procedure, you can then import this certificate on the Default Web Site of each server in the
farm. For more information, see Import a Server Authentication Certificate to the Default Web Site.
Default Groups.
To export the private key portion of a server authentication certificate
1. On the Start screen, typeInternet Information Services (IIS ) Manager, and then press ENTER.
2. In the console tree, click ComputerName.
3. In the center pane, double-click Server Certificates.
4. In the center pane, right-click the certificate that you want to export, and then click Export.
5. In the Export Certificate dialog box, click the … button.
6. In File name, type C:\NameofCertificate, and then click Open.
7. Type a password for the certificate, confirm it, and then click OK.
8. Validate the success of your export by confirming that the file you specified is created at the specified
location.
IMPORTANT
So that this certificate can be imported to the local certificate store on the new server, you must transfer the file to
physical media and protect its security during transport to the new server. It is extremely important to guard the
security of the private key. If this key is compromised, the security of your entire AD FS deployment (including
resources within your organization and in resource partner organizations) is compromised.
9. Import the exported server authentication certificate into the certificate store on the new server before you
install the Federation Service. For information about how to import the certificate, see Import a Server
Certificate (http://go.microsoft.com/fwlink/?LinkId=108283).
Import a Server Authentication Certificate to the
Default Web Site
After you obtain a server authentication certificate from a certification authority (CA), you must manually install
that certificate on the Default Web Site for each federation server or federation server proxy in a server farm.
For Web servers, you must manually install the server authentication certificate on the appropriate Web site or
virtual directory where your federated application resides.
If you are setting up a farm, be sure to perform this procedure identically—using the exact same settings—on each
of the servers in your farm.
NOTE
certificates.
Default Groups.
To import a server authentication certificate to the Default Web Site
1. On the Start screen, typeInternet Information Services (IIS ) Manager, and then press ENTER.
2. In the console tree, click ComputerName.
3. In the center pane, double-click Server Certificates.
4. In the Actions pane, click Import.
5. In the Import Certificate dialog box, click the … button.
6. Browse to the location of the pfx certificate file, highlight it, and then click Open.
7. Type a password for the certificate, and then click OK.
Install the Federation Service Proxy Role Service
After you configure a computer with the prerequisite applications and certificates, you are ready to install the
Federation Service Proxy role service of Active Directory Federation Services (AD FS ). You can use the following
procedure to install the Federation Service Proxy role service. When you install the Federation Service Proxy role
service on a computer, that computer becomes a federation server proxy.
Default Groups.
To install the Federation Service Proxy role service using the Server Manager
1. On the Start screen, typeServer Manager, and then press ENTER.
2. Click Manage, and then click Add Roles and Features to start the Add Roles and Features Wizard.
4. On the Select installation type page, click Role-based or Feature-based installation, and click Next.
computer is highlighted, and then click Next.
6. On the Select server roles page, click Remote Access, and then click next.
NOTE
If you are prompted to install additional .NET Framework or Windows Process Activation Service features, click Add
Features to install them.
7. On the Select role services page, select the Federation Service Proxy check box, and then click Next.
To install the Federation Service Proxy role service using PowerShell
1. Open Windows PowerShell (Run as Administrator)
2. Type the following command and press Enter:
Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools
Configure a Computer for the Federation Server
Proxy Role
After you configure a computer with the required certificates and have installed the Federation Service Proxy role
service, you are ready to configure the computer to become a federation server proxy. You can use the following
procedure so that the computer acts in the federation server proxy role.
IMPORTANT
Before you use this procedure to configure the federation server proxy computer, make sure that you have followed all the
steps in Checklist: Setting Up a Federation Server Proxy in the order that they are listed. Make sure that at least one
federation server is deployed and that all the necessary credentials for authorizing a federation server proxy configuration are
implemented. You must also configure Secure Sockets Layer (SSL) bindings on the Default Web Site, or this wizard will not
start. All these tasks must be completed before this federation server proxy can function.
After you finish setting up the computer, verify that the federation server proxy is working as expected. For more
information, see Verify That a Federation Server Proxy Is Operational.
Default Groups.
To configure a computer for the federation server proxy role
of the following:
On the Start screen, typeAD FS Federation Server Proxy Configuration Wizard, and then press
ENTER.
C:\Windows\ADFS folder, and then double-click FspConfigWizard.exe.
2. Using either method, start the wizard, and on the Welcome page, click Next.
3. On the Specify Federation Service Name page, under Federation Service name, type the name that
represents the Federation Service for which this computer will act in the proxy role.
4. Based on your specific network requirements, determine whether you will need to use an HTTP proxy server
to forward requests to the Federation Service. If so, select the Use an HTTP proxy server when sending
requests to this Federation Service check box, under HTTP proxy server address type the address of
the proxy server, click Test Connection to verify connectivity, and then click Next.
5. When you are prompted, specify the credentials that are necessary to establish a trust between this
federation server proxy and the Federation Service.
By default, only the service account used by the Federation Service or a member of the local
BUILTIN\Administrators group can authorize a federation server proxy.
begin configuring this computer with these proxy settings.
There is no Microsoft Management Console (MMC ) snap-in to use for administering federation server
proxys. To configure settings for each of the federation server proxys in your organization, use Windows
PowerShell cmdlets.
Configuring an Alternate TCP/IP Port for Proxy Operations

By default, the federation server proxy service is configured to use TCP port 443 for HTTPS traffic and port 80 for
HTTP traffic for communication with the federation server. To configure different ports, such as TCP port 444 for
HTTPS and port 81 for HTTP, the following tasks must be completed.
NOTE
If you intend to initially deploy AD FS to operate under alternate TCP/IP ports, you should first modify ports in your IIS
protocol bindings for HTTP and HTTPS on both the federation server and federation server proxy computers. This should
occur before you run the AD FS configuration wizards for initial configuration. If you configure Internet Information Services
(IIS) first, your alternate TCP/IP port settings are discovered when wizard-based configuration occurs within AD FS, and the
following procedure is not necessary. If you want to change the port settings later, update IIS protocol bindings first, and then
use the following procedure to update port settings appropriately. For more information about editing IIS bindings, see article
149605 in the Microsoft Knowledge Base.
To configure alternate TCP/IP ports for the federation server proxy to use
1. Configure the federation server to use the nondefault ports.
To do this, specify the nondefault port number by including it with the HttpsPort and HttpPort options as
part of the Set-ADFSProperties cmdlet. For example, to configure these ports, use the following
commands in the Windows PowerShell session on the federation server computer:
Set-ADFSProperties -HttpsPort 444

Set-ADFSProperties -HttpPort 81
2. Configure the federation server proxy to use the nondefault port.

To do this, specify the nondefault port number by including it with the HttpsPort and HttpPort options as
part of the Set-ADFSProxyProperties cmdlet. For example, to configure these ports, use the following
commands in the Windows PowerShell session on the federation server computer:
Set-ADFSProxyProperties -HttpsPort 444

Set-ADFSProxyProperties -HttpPort 81
NOTE
Endpoint URLs are not enabled by default for the federation server proxy service. If you are configuring a new
federation server installation, you must enable federation server proxy service endpoints first. For example, it is
assumed that for all the endpoints that the example in this procedure refers to you have enabled them for proxy by
selecting them in the AD FS Management snap-in and then selecting Enable on proxy.
3. Update the IIS installation at the federation server proxy so that Security Assertion Markup Language
(SAML ) and WS -Trust endpoints are configured to reflect the updated port number. To do this, you can use
Notepad to modify the following in the Web.config file, which is located at systemdrive%\inetpub\adfs\ls\ on
the federation server proxy computer. For example, assuming that you have a federation server named
sts1.contoso.com and the new port number is 444, browse to and open the Web.config file in Notepad on
the federation server proxy computer, locate the following section, modify the port number as highlighted
below, and then save and exit Notepad.
<securityTokenService
samlProtocolEndpoint="https://sts1.contoso.com:444/adfs/services/trust/samlprotocol/proxycertificatetran
sport"
wsTrustEndpoint="https://sts1.contoso.com:444/adfs/services/trust/proxycertificatetransport" />
4. Add the federation server proxy service user account to the access control list (ACL ) for the related endpoint
URLs. For example, if the port number is 1234 and the user account that is used to run the AD FSfederation
server proxy service under is the built-in Network Service account, type the following command at a
command prompt:
netsh http add urlacl https://+:444/adfs/fs/federationserverservice.asmx/ user="NT Authority\Network

Service"
netsh http add urlacl https://+:444/FederationMetadata/2007-06/ user="NT Authority\Network Service"
netsh http add urlacl https://+:444/adfs/services/ user="NT Authority\Network Service"
netsh http add urlacl http://+:81/adfs/services/ user="NT Authority\Network Service"
The previous commands must be run on both the federation server and the federation server proxy
computers.
Verify That a Federation Server Proxy Is Operational
You can use the following procedure to verify that the federation server proxy can communicate with the
Federation Service in Active Directory Federation Services (AD FS ). You run this procedure after you run the AD
FS Federation Server Proxy Configuration Wizard to configure the computer to run in the federation server
proxy role. For more information about how to run this wizard, see Configure a Computer for the Federation
Server Proxy Role.
IMPORTANT
The result of this test is the successful generation of a specific event in Event Viewer on the federation server proxy computer.
Default Groups.
To verify that a federation server proxy is operational
1. Log on to the federation server proxy as an administrator.
2. On the Start screen, typeEvent Viewer, and then press ENTER.
click Admin.
4. In the Event ID column, look for event ID 198.
If the federation server proxy is configured properly, you see a new event in the Application log of Event
Viewer, with the event ID 198. This event verifies that the federation server proxy service was started
successfully and now is online.
Configure Performance Monitoring
AD FS includes its own dedicated performance counters to help you monitor the performance of both federation
servers and federation server proxy computers. To use Performance Monitor to monitor the performance of your
AD FS servers, it’s useful to create a new data collector set and add the AD FS counters to that view. The following
procedure describes how to configure performance monitoring for AD FS.
To configure performance monitoring for AD FS using Performance Monitor
1. On the Start screen, type Performance Monitor, and then press ENTER.
2. In the console tree, expand Data Collector Sets, right-click User Defined, point to New, and then click
Data Collector Set.
The Create New Data Collector Set Wizard appears.
3. In Create New Data Collector Set, for Name type a name for the new data collector set (such as "AD FS
performance"), click Create manually (Advanced), and then click Next.
4. For the type of data to include, verify that Create data logs is selected, and then click the check boxes for
the following data types: Performance counter, Event trace data, System configuration information.
5. For performance counters, expand AD FS in the Available counters list, and then click Add.
The AD FS performance counters should appear in the Added counters list.
6. When you are prompted to add event trace providers, click Add, select AD FS Eventing and AD FS
Tracing from the list of providers.
7. When you are prompted to add registry keys to monitor, click Next.
8. When you are prompted to specify the location to save the performance data, you can accept the default
location (%systemdrive%\PerfLogs\Admin\<data_collector_set>, and then click Next.
9. When you are prompted to create the data collector set, select Save and close, and then click Finish.
The new data collector set appears in the console tree under the User Defined node.
10. Use the following steps to work with the AD FS performance counters:
To begin performance monitoring using AD FS -related counters, right-click the data collector set that
you added (such as "AD FS performance"), and then click Start.
To create a report to view the performance monitoring results, right-click the data collector set that
you added (such as "AD FS performance"), and then click Latest Report.
To end a capture of performance data so that you can view the latest report, right-click the data
collector set that you added (such as "AD FS performance"), and then click Stop.
The latest report is added and numbered automatically (starting at 000001) under the Report\User
Defined\<data_collector_set> node in the console tree.
AD FS performance counters
The following table lists the AD FS performance counters and describes how they are useful for monitoring activity
that relates to either a federation server or federation server proxy.
COUNTER DESCRIPTION CAN BE USED ON:
Token Requests Monitors the number of token requests Federation Servers

sent to the federation server including
SSOAuth token requests.
Token Requests/sec Monitors the number of token requests Federation Servers

sent to the federation server including
SSOAuth token requests per second.
Federation Metadata Requests Monitors the number of incoming Federation Servers

federation metadata requests sent to
the federation server.
Federation Metadata Requests/sec Monitors the number of incoming Federation Servers

federation metadata requests per
second that are sent to the federation
server.
Artifact Resolution Requests Monitors the number of incoming Federation Servers

federation metadata requests per
second that are sent to the federation
server.
Artifact Resolution Requests/sec Monitors the number of requests to the Federation Servers
artifact resolution endpoint per second
that are sent to the federation server.
Proxy Requests Monitors the number of incoming Federation Server Proxies

requests sent to the federation server
proxy.
Proxy Requests/sec Monitors the number of incoming Federation Server Proxies

requests per second that are sent to the
Proxy MEX Requests Monitors the number of incoming WS- Federation Server Proxies
Metadata Exchange (MEX) requests that
are sent to the federation server proxy.
Proxy MEX Requests/sec Monitors the number of incoming MEX Federation Server Proxies
requests per second that are sent to the
For interoperability between Active Directory Federation Services (AD FS ) in Windows Server® 2012 and AD FS
1.x, complete one or more of the following tasks, depending on the needs of your organization:
Plan for interoperability between AD FS in Windows Server 2012 and previous versions of AD FS, and learn
more about the Name ID claim type. For more information, see Planning for Interoperability with AD FS 1.x.
If you will be sending claims from an AD FS Federation Service in Windows Server 2012 that can be
consumed by an AD FS 1.x Federation Service, see Checklist: Configuring AD FS to Send Claims to an AD
FS 1.x Federation Service.
If you will be sending claims from an AD FS Federation Service in Windows Server 2012 that can be
consumed by an application that is hosted by a Web server running the AD FS 1.x claims-aware Web agent,
see Checklist: Configuring AD FS to Send Claims to an AD FS 1.x Claims-Aware Web Agent.
If you will be sending claims from an AD FS 1.x Federation Service to be consumed by an AD FS Federation
Service in Windows Server 2012 , see Checklist: Configuring AD FS to Consume Claims from AD FS 1.x.
Differences between Federation Service settings

Although most of the AD FS 1.x Federation Service settings work in a similar manner as the AD FS Federation
Service in Windows Server 2012 settings, some setting names have changed. The following table lists the names of
settings for an AD FS 1.x Federation Service and their equivalent names for an AD FS Federation Service in
Windows Server 2012 .
EQUIVALENT AD FS FEDERATION SERVICE IN WINDOWS SERVER

AD FS 1.X FEDERATION SERVICE SETTING 2012 SETTING
Account Partner Claims provider trust
Resource Partner Relying party trust
Application Relying party trust
Application Properties Relying party trust properties
Application URL Relying party identifier and WS-Federation Passive Endpoint

URL
Federation Service URI Federation Service identifier
Federation Service endpoint URL WS-Federation Passive Endpoint URL
See Also
AD FS and AD FS 1.x Interoperability
Checklist: Configuring AD FS to Consume Claims
from AD FS 1.x
Checklist: Configuring AD FS to consume claims from AD FS 1.x

This checklist includes the tasks that are necessary for configuring your Active Directory Federation Services (AD
FS ) Federation Service in Windows Server 2012 to consume claims that are sent by an AD FS 1.x Federation
Service.
NOTE
Checklist: Configuring AD FS to consume claims from AD FS 1.x
TASK REFERENCE
Plan for interoperability between AD FS Planning for Interoperability with AD

in Windows Server 2012 and previous FS 1.x
versions of AD FS, and learn more about
the Name ID claim type.
TASK REFERENCE
Before you can interoperate with a Create a Claims Provider Trust

previous version of AD FS, you must Manually
first create a claims provider trust in the
AD FS Federation Service. Note: You
cannot create a trust with an AD FS 1.x
Federation Service by using federation
metadata.
When you set up the trust using the

procedure in the link to the right, you
must do the following in the Add Claims
Provider Trust Wizard to set up this
trust to interoperate with an AD FS 1.x
Federation Service:
1. On the Select Data Source page,

select Enter data about the relying
party trust manually.
2. On the Choose Profile page, select
AD FS 1.0 and 1.1 profile.
3. On the Configure URL page, under
WS-Federation Passive URL, type the
Federation Service endpoint URL as
defined in the AD FS 1.x Federation
Service of the partner.
4. On the Configure Identifiers page,
under Claims provider trust
identifier, type the Federation
Service URI as defined in the AD FS 1.x
Federation Service of the partner.
On the claims provider trust that you Create a Rule to Send an AD FS 1.x
created earlier, you must create a claim Compatible Claim
rule that will take claims that are
incoming from the AD FS 1.x Federation
Service and pass through, filter, or
transform them into a Name ID claim
type.
When the Name ID claim type has been

passed through, filtered, or transformed,
it can be used as input to another rule
or rules so that it can be understood
and consumed by the AD FS Federation
Service in Windows Server 2012 .
Contact the administrator of the AD FS N/A

1.x Federation Service and have the
administrator of the AD FS 1.x
Federation Service set up a new
resource partner trust. Also, provide
that administrator with the Federation
Service URI (in the Federation Service
properties), the Federation Service
endpoint URL, and an exported token-
signing certificate file (with public key
only). The administrator will need these
items to set up the trust.
Checklist: Configuring AD FS to Send Claims to an
AD FS 1.x Federation Service
Checklist: Configuring AD FS to send claims to an AD FS 1.x Federation

Service
FS ) Federation Service in Windows Server 2012 to send claims that can be understood by an AD FS 1.x Federation
Service.
NOTE
Checklist: Configuring AD FS to send claims to an AD FS 1.x Federation Service
TASK REFERENCE

versions of AD FS and learn more about
TASK REFERENCE
Before you can achieve interoperability Create a Relying Party Trust Manually
with a previous version of AD FS, you
must first create a relying party trust in
the AD FS Federation Service to the AD
FS 1.x Federation Service. Note: You
cannot create a trust with an AD FS 1.x
Federation Service by using federation
metadata.

must do the following in the Add
Relying Party Trust Wizard to set up this
Federation Service:

Federation Service endpoint URL as
under Relying part trust identifier,
type the Federation Service URI as
On the relying party trust that you Create a Rule to Send an AD FS 1.x
created earlier, you must create claim Compatible Claim
rules that will take incoming claims that
were extracted from an attribute store
and pass through, filter, or transform
them into a Name ID claim type that
can be understood and consumed by
the AD FS 1.x Federation Service. Note:
Before you create this rule, make sure
that the claim rule set where you are
creating this rule has a rule that comes
before it that first extracts a Lightweight
Directory Access Protocol (LDAP)
attribute claim from an attribute store.
This claim will be used as input to the
rule that you create to send an AD FS
1.x-compatible claim. For more
information about how to create a rule
to extract an LDAP attribute, see Create
a Rule to Send LDAP Attributes as
Claims.
TASK REFERENCE
Contact the administrator of the AD FS N/A

1.x Federation Service and have the
administrator of the AD FS 1.x
Federation Service set up a new account
partner trust. Also, provide that
administrator with the Federation
Service URI (in the Federation Service
properties), the WS-Federation Passive
endpoint URL (the Federation Service
endpoint URL), and an exported token-
signing certificate file (with public key
only). That administrator will need these
items to set up the trust.
Checklist: Configuring AD FS to Send Claims to an
AD FS 1.x Claims-Aware Web Agent
Checklist: Configuring AD FS to send claims to an AD FS 1.x claims-

aware Web agent
FS ) Federation Service in Windows Server 2012 to send claims that can be understood by an application that is
hosted by a Web server running the AD FS 1.x claims-aware Web agent.
NOTE
Checklist: Configuring AD FS to send claims to an AD FS 1.x claims-aware Web agent
TASK REFERENCE

versions of AD FS and learn more about
If you have not already done so, use the Checklist: Configuring AD FS to Send
link on the right to first create a relying Claims to an AD FS 1.x Federation
party trust between the AD FS Service
Federation Service in Windows Server
2012 and the AD FS 1.x Federation
Service.
TASK REFERENCE
Before you can achieve interoperation Create a Relying Party Trust Manually
with an application that is hosted by the
AD FS 1.x claims-aware Web agent, you
must first create a relying party trust in
the AD FS Federation Service in
Windows Server 2012 to the AD FS 1. x
claims-aware Web agent. Note:
Creating this trust in the AD FS
Federation Service is the equivalent of
adding a new Application to the AD FS
1.x Federation Service (Federation
Service\Trust Policy\My
Organization\Application). This
relying party trust is necessary because
AD FS does not have an equivalent
Application node in its own snap-in.
However, it still must have a secure
channel to the application.

must do the following in the Add
Relying Party Trust Wizard to set up this
claims-aware Web agent:

Application URL as defined in the AD
FS 1.x Federation Service of the partner.
under Relying part trust identifier,
type the Application URL as defined in
the AD FS 1.x claims-aware Web agent
Contact the administrator of the Web N/A

server running the AD FS 1.x claims-
aware Web agent and have that
administrator edit the web.config file
that is associated with the claims-aware
application (under the Default Web Site
in Internet Information Services (IIS)) to
point the Web agent at the AD FS
Federation Service.
For example, replace

myresourcefederationserver in the tag
<fs>https://myresourcefederationserver/adfs/fs/federationserverservice.asmx</fs>
of the web.config file with a valid AD FS
federation server name.
This is necessary for the application and

AD FS 1.x claims-aware Web agent to
be able to consume the claims that are
sent to it from the AD FS Federation
Service in Windows Server 2012 .
TASK REFERENCE
On the relying party trust that you Create a Rule to Send an AD FS 1.x
created earlier, you have to create claim Compatible Claim
rules that will take incoming claims that
were extracted from an attribute store
and pass through, filter, or transform
them into a Name ID claim type that
can be understood and consumed by
the AD FS 1.x claims-aware Web agent.
Note: Before you create this rule, make
sure that the claim rule set where you
are creating this rule has a rule that
comes before it that first extracts a
Lightweight Directory Access Protocol
(LDAP) attribute claim from an attribute
store. This claim will be used as input to
the rule that you create to send an AD
FS 1.x-compatible claim. For more
information about how to create a rule
to extract an LDAP attribute, see Create
a Rule to Send LDAP Attributes as
Claims.
metadata.

Default Groups.

Next.
click Next.
information.

NOTE
Default Groups.

information.
references.
See Also
AD FS Operations
Default Groups.


NOTE


See Also
AD FS Operations
In situations in which you are using Active Directory Federation Services (AD FS ) to issue claims that will be
received by federation servers running AD FS 1.0 (Windows Server 2003 R2) or AD FS 1.1 (Windows Server 2008
or Windows Server 2008 R2), you must do the following:
Create a rule that will send a Name ID claim type with a format of UPN, Email, or Common Name.
All other claims that are sent must have one of the following claim types:
AD FS 1.x Email Address
AD FS 1.x UPN
Common Name
Group
Any other claim type that begins with https://schemas.xmlsoap.org/claims/, such as
https://schemas.xmlsoap.org/claims/EmployeeID
Depending on the needs of your organization, use one of the following procedures to create an AD FS 1.x
compatible NameID claim:
Create this rule to issue an AD FS 1.x Name ID claim using the Pass Through or Filter an Incoming
Claim rule template
Create this rule to issue an AD FS 1.x Name ID claim using the Transform an Incoming Claim rule
template. You can use this rule template in situations in which you want to change the existing claim type to
a new claim type that will work with AD FS 1. x claims.
NOTE
For this rule to work as expected, make sure that the relying party trust or claims provider trust where you are creating this
rule has been configured to use the AD FS 1.0 and 1.1 profile.

Through or Filter an Incoming Claim rule template on a Relying Party
the rule wizard.

list:
UPN
E -Mail
Common Name

Through or Filter an Incoming Claim rule template on a Claims Provider
wizard.
list:
UPN
E -Mail
Common Name

the rule wizard.

list:
UPN
E -Mail
Common Name

wizard.
list:
UPN
E -Mail
Common Name

Through or Filter an Incoming Claim rule template on Windows Server
2012 R2

list:
UPN
E -Mail
Common Name
To create a rule to issue an AD FS 1.x Name ID claim using the

Transform an Incoming Claim rule template in Windows Server 2012 R2

list:
UPN
E -Mail
Common Name
The Role of Claims
Migrate Active Directory Federation Services Role
Services to Windows Server 2012 R2
This document provides instructions to migrate the following role services to Active Directory Federation Services
(AD FS ) that is installed with Windows Server 2012 R2:
AD FS 2.0 federation server installed on Windows Server 2008 or Windows Server 2008 R2
AD FS federation server installed on Windows Server 2012
Supported migration scenarios

The migration instructions in this guide consist of the following tasks:
Exporting the AD FS 2.0 configuration data from your server that is running Windows Server 2008,
Windows Server 2008 R2, or Windows Server 2012
Performing an in-place upgrade of the operating system of this server from Windows Server 2008,
Windows Server 2008 R2 or Windows Server 2012 to Windows Server 2012 R2.
Recreating the original AD FS configuration and restoring the remaining AD FS service settings on this
server, which is now running the AD FS server role that is installed with Windows Server 2012 R2.
This guide does not include instructions to migrate a server that is running multiple roles. If your server is
running multiple roles, we recommend that you design a custom migration process specific to your server
environment, based on the information provided in other role migration guides. Migration guides for
additional roles are available on the Windows Server Migration Portal.
Supported operating systems
Destination server operating system:
Windows Server 2012 R2 (Server Core and full installation options)
Destination server processor:
x64-based
SOURCE SERVER PROCESSOR SOURCE SERVER OPERATING SYSTEM
x86- or x64-based Windows Server 2008, both full and Server Core installation
options
x64-based Windows Server 2008 R2
x64-based Server Core installation option of Windows Server 2008 R2
x64-based Server Core and full installation options of Windows Server

2012
NOTE
The versions of operating systems that are listed in the preceding table are the oldest combinations of operating systems
and service packs that are supported.
The Foundation, Standard, Enterprise, and Datacenter editions of the Windows Server operating system are
supported as the source or the destination server.
Migrations between physical operating systems and virtual operating systems are supported.
Supported AD FS role services and features

The following table describes the migration scenarios of the AD FS role services and their respective settings that
are described in this guide.
FROM TO AD FS INSTALLED WITH WINDOWS SERVER 2012 R2
AD FS 2.0 federation server installed on Windows Server 2008 Migration on the same server is supported. For more
or Windows Server 2008 R2 information, see:
Preparing to Migrate the AD FS Federation Server
Migrating the AD FS Federation Server
AD FS federation server installed on Windows Server 2012 Migration on the same server is supported. For more
information see:
Next Steps
Migrating the AD FS Federation Server Proxy
Verifying the AD FS Migration to Windows Server 2012 R2
to AD FS on Windows Server 2012 R2
This document describes how to migrate an AD FS 2.0 or Windows Server 2012 federation server farm to a
Windows Server 2012 R2 AD FS farm. The steps can be used with AD FS farms that use either WID or SQL
Server as the underlying database.
Migration Process Outline
New AD FS functionality in Windows Server 2012 R2
AD FS Requirements in Windows Server 2012 R2
Increasing your Windows PowerShell limits
Other migration tasks and considerations
Migration Process Outline

To complete the migration of your AD FS federation server farm to Windows Server 2012 R2, you must complete
the following tasks:
1. Export, record, and backup the following configuration data in your existing AD FS farm. For detailed
instructions on how to complete these tasks, see Migrating the AD FS Federation Server.
The following settings are migrated with the scripts located in the \support\adfs folder on the Windows Server
2012 R2 installation CD:
Claims provider trusts, with the exception of custom claim rules on the Active Directory Claims provider
trust. For more information, see Migrating the AD FS Federation Server.
Relying party trusts.
AD FS internally generated, self-signed token signing and token decryption certificates.
Any of the following custom settings must be migrated manually:
Service settings:
Non-default token signing and token decryption certificates that were issued by an enterprise or
public certification authority.
The SSL server authentication certificate used by AD FS.
The service communications certificate used by AD FS (by default, this is the same certificate as the
SSL certificate.
Non-default values for any federation service properties, such as AutoCertificateRollover or
SSO lifetime.
Non-default AD FS endpoint settings and claim descriptions.
Custom claim rules on the Active Directory claims provider trust.
AD FS sign-in page customizations
For more information, see Migrating the AD FS Federation Server.
1. Create a Windows Server 2012 R2 federation server farm.
2. Import the original configuration data into this new Windows Server 2012 R2 AD FS farm.
3. Configure and customize the AD FS sign-in pages.
New AD FS functionality in Windows Server 2012 R2

The following AD FS functionality changes in Windows Server 2012 R2 impact a migration from AD FS 2.0 or
AD FS in Windows Server 2012:
IIS dependency
AD FS in Windows Server 2012 R2 is self-hosted and does not require IIS installation. Make sure you note the
following as a result of this change:
SSL certificate management for both federation servers and proxy computers in your AD FS farm must now
be performed via Windows PowerShell.
Changes to AD FS sign-in pages’ settings and customizations
In AD FS in Windows Server 2012 R2, there are several changes intended to improve the sign-in experience
for both administrators and users. The IIS -hosted web pages that existed in the previous version of AD FS are
now removed. The look and feel of the AD FS sign-in web pages are self-hosted in AD FS and can now be
customized to tailor the user experience. The changes include:
Customizing the AD FS sign-in experience, including the customization of the company name, logo,
illustration, and sign-in description.
Customizing the error messages.
Customizing the ADFS Home Realm Discovery experience, which includes the following:
Configuring your identity provider to use certain email suffixes.
Configuring an identity provider list per relying party.
Bypassing Home Realm Discovery for intranet.
Creating custom web themes.
For detailed instructions on configuring the look and feel of the AD FS sign-in pages, see Customizing the AD FS
Sign-in Pages.
If you have web page customization in your existing AD FS farm that you want to migrate to Windows Server
2012 R2, you can recreate them as part of the migration process using the new customization features in
Other changes
AD FS in Windows Server 2012 R2 is based on Windows Identity Foundation (WIF ) 3.5, not WIF
4.5. Therefore, some specific features of WIF 4.5 (for example, Kerberos claims and dynamic access
control) are not supported in AD FS in Windows Server 2012 R2.
Device Registration Service (DRS ) in Windows Server 2012 R2 operates on port 443; ClientTLS for
user certificate authentication operates on port 49443
For active, non-browser clients using certificate transport mode authentication that are
specifically hard-coded to point to port 443, a code change is required to continue to use user
certificate authentication on port 49443.
For passive applications no change is required because AD FS redirects to the correct port for
user certificate authentication.
Firewall ports between the client and the proxy must enable port 49443 traffic to pass
through for user certificate authentication.
AD FS Requirements in Windows Server 2012 R2

In order to successfully migrate your AD FS farm to Windows Server 2012 R2, you must meet the following
requirements:
For AD FS to function, each computer that you want to be a federation must be joined to a domain.
For AD FS running on Windows Server 2012 R2 to function, your Active Directory domain must run either of the
following:
Windows Server 2012
Windows Server 2008
If you plan to use a group Managed Service Account (gMSA) as the service account for AD FS, you must
have at least one domain controller in your environment that is running on Windows Server 2012 or
Windows Server 2012 R2 operating system.
If you plan to deploy Device Registration Service (DRS ) for AD Workplace Join as a part of your AD FS
deployment, the AD DS schema needs to be updated to the Windows Server 2012 R2 level. There are
three ways to update the schema:
1. In an existing Active Directory forest, run adprep /forestprep from the \support\adprep folder of the Windows
Server 2012 R2 operating system DVD on any 64-bit server that runs Windows Server 2008 or later. In this
case, no additional domain controller needs to be installed, and no existing domain controllers need to be
upgraded.
To run adprep/forestprep, you must be a member of the Schema Admins group, the Enterprise Admins group,
and the Domain Admins group of the domain that hosts the schema master.
1. In an existing Active Directory forest, install a domain controller that runs Windows Server 2012 R2. In this
case, adprep /forestprep runs automatically as part of the domain controller installation.
During the domain controller installation, you may need to specify additional credentials in order to run adprep
/forestprep.
1. Create a new Active Directory forest by installing AD DS on a server that runs Windows Server 2012 R2. In
this case, adprep /forestprep does not need to be run because the schema will be initially created with all the
necessary containers and objects to support DRS.
SQL Server support for AD FS in Windows Server 2012 R2
Server 2008 and newer versions, including SQL Server 2012.
Increasing your Windows PowerShell limits

If you have more than 1000 claims provider trusts and relying party trusts in your AD FS farm, or if you see the
following error while trying to run the AD FS migration export/import tool, you must increase your Windows
PowerShell limits:
'Exception of type 'System.OutOfMemoryException' was thrown. At
E:\dev\ds\security\ADFSv2\Product\Migration\Export-FederationConfiguration.ps1:176 char:21 + $configData =
Invoke-Command -ScriptBlock $GetConfig -Argume ...
This error is thrown because the Windows PowerShell session default memory limit is too low. In Windows
PowerShell 2.0, the session default memory is 150MB. In Windows PowerShell 3.0, the session default memory is
1024MB. You can verify Windows PowerShell remote session memory limit using the following command:
Get-Item wsman:localhost\Shell\MaxMemoryPerShellMB . You can increase the limit by running the following
command: Set-Item wsman:localhost\Shell\MaxMemoryPerShellMB 512 .
Other migration tasks and considerations

In order to successfully migrate your AD FS farm to Windows Server 2012 R2, make sure you are aware of the
following:
The migration scripts located in the \support\adfs folder on the Windows Server 2012 R2 installation CD
require that you retain the same federation server farm name and service account identity name that you
used in your legacy AD FS farm when you migrate it to Windows Server 2012 R2.
If you want to migrate a SQL Server AD FS farm, note that the migration process involves creating a new
SQL database instance into which you must import the original configuration data.
Next Steps
Migrate Active Directory Federation Services Role Services to Windows Server 2012 R2
Migrate the AD FS 2.0 federation server to AD FS
on Windows Server 2012 R2
To migrate an AD FS federation server that belongs to a single-node AD FS farm, a WIF farm, or a SQL Server
farm to Windows Server 2012 R2, you must perform the following tasks:
1. Export and backup the AD FS configuration data
2. Create a Windows Server 2012 R2 federation server farm
3. Import the original configuration data into the Windows Server 2012 R2 AD FS farm
Export and backup the AD FS configuration data

To export the AD FS configuration settings, perform the following procedures:
To export service settings
1. Make sure that you have access to the following certificates and their private keys in a .pfx file:
The SSL certificate that is used by the federation server farm that you want to migrate
The service communication certificate (if it is different from the SSL certificate) that is used by the
federation server farm that you want to migrate
All third-party party token-signing or token-encryption/decryption certificates that are used by the
federation server farm that you want to migrate
To find the SSL certificate, open the Internet Information Services (IIS ) management console, Select Default
Web Site in the left pane, click Bindings… in the Action pane, find and select the https binding, click Edit, and
then click View.
You must export the SSL certificate used by the federation service and its private key to a .pfx file. For more
information, see Export the Private Key Portion of a Server Authentication Certificate.
NOTE
If you plan to deploy the Device Registration Service as part of running your AD FS in Windows Server 2012 R2, you must
obtain a new SSL cert. For more information, see Enroll an SSL Certificate for AD FS and Configure a federation server with
Device Registration Service.
To view the token signing, token decryption and service communication certificates that are used, run the
following Windows PowerShell command to create a list of all certificates in use in a file:
Get-ADFSCertificate | Out-File “.\certificates.txt”
1. Export AD FS federation service properties, such as the federation service name, federation service display
name, and federation server identifier to a file.
To export federation service properties, open Windows PowerShell and run the following command:
Get-ADFSProperties | Out-File “.\properties.txt”`.
The output file will contain the following important configuration values:
FEDERATION SERVICE PROPERTY NAME AS REPORTED BY GET- FEDERATION SERVICE PROPERTY NAME IN AD FS MANAGEMENT
ADFSPROPERTIES CONSOLE
HostName Federation Service name
Identifier Federation Service identifier
DisplayName Federation Service display name
1. Back up the application configuration file. Among other settings, this file contains the policy database
connection string.
To back up the application configuration file, you must manually copy the
%programfiles%\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config file to
a secure location on a backup server.
NOTE
Make note of the database connection string in this file, located immediately after “policystore connectionstring=”. If the
connection string specifies a SQL Server database, the value is needed when restoring the original AD FS configuration on
The following is an example of a WID connection string:
“Data Source=\\.\pipe\mssql$microsoft##ssee\sql\query;Initial Catalog=AdfsConfiguration;Integrated
Security=True"
. The following is an example of a SQL Server connection string:
"Data Source=databasehostname;Integrated Security=True" .
1. Record the identity of the AD FS federation service account and the password of this account.
To find the identity value, examine the Log On As column of AD FS 2.0 Windows Service in the Services
console and manually record this value.
NOTE
For a stand-alone federation service, the built-in NETWORK SERVICE account is used. In this case, you do not need to have
a password.
1. Export the list of enabled AD FS endpoints to a file.

To do this, open Windows PowerShell and run the following command:
Get-ADFSEndpoint | Out-File “.\endpoints.txt”`.
1. Export any custom claim descriptions to a file.

To do this, open Windows PowerShell and run the following command:
Get-ADFSClaimDescription | Out-File “.\claimtypes.txt”`.

1. If you have custom settings such as useRelayStateForIdpInitiatedSignOn configured in the web.config file,
ensure you back up the web.config file for reference. You can copy the file from the directory that is mapped
to the virtual path “/adfs/ls” in IIS. By default, it is in the %systemdrive%\inetpub\adfs\ls directory.
To export claims provider trusts and relying party trusts
1. To export AD FS claims provider trusts and relying party trusts, you must log in as Administrator (however,
not as the Domain Administrator) onto your federation server and run the following Windows PowerShell
script that is located in the media/server_support/adfs folder of the Windows Server 2012 R2 installation
CD: export-federationconfiguration.ps1 .
IMPORTANT
The export script takes the following parameters:
Export-FederationConfiguration.ps1 -Path <string> [- ComputerName <string>] [- Credential <pscredential>] [-
Force] [- CertificatePassword <securestring>]
Force] [- CertificatePassword <securestring>] [- RelyingPartyTrustIdentifier <string[]>] [-
ClaimsProviderTrustIdentifier <string[]>]
Force] [- CertificatePassword <securestring>] [- RelyingPartyTrustName <string[]>] [- ClaimsProviderTrustName
<string[]>]
-RelyingPartyTrustIdentifier <string[]> - the cmdlet only exports relying party trusts whose identifiers are
specified in the string array. The default is to export NONE of the relying party trusts. If none of
RelyingPartyTrustIdentifier, ClaimsProviderTrustIdentifier, RelyingPartyTrustName, and ClaimsProviderTrustName is
specified, the script will export all relying party trusts and claims provider trusts.
-ClaimsProviderTrustIdentifier <string[]> - the cmdlet only exports claims provider trusts whose identifiers are
specified in the string array. The default is to export NONE of the claims provider trusts.
-RelyingPartyTrustName <string[]> - the cmdlet only exports relying party trusts whose names are specified in
the string array. The default is to export NONE of the relying party trusts.
-ClaimsProviderTrustName <string[]> - the cmdlet only exports claims provider trusts whose names are
specified in the string array. The default is to export NONE of the claims provider trusts.
-Path <string> - the path to a folder that will contain the exported files.
-ComputerName <string> - specifies the STS server host name. The default is the local computer. If you are
migrating AD FS 2.0 or AD FS in Windows Server 2012 to AD FS in Windows Server 2012 R2, this is the host name
of the legacy AD FS server.
-Credential <PSCredential> - specifies a user account that has permission to perform this action. The default is
the current user.
-Force – specifies to not prompt for user confirmation.
-CertificatePassword <SecureString> - specifies a password for exporting AD FS certificates’ private keys. If not
specified, the script will prompt for a password if an AD FS certificate with private key needs to be exported.
Inputs: None
Outputs: string - this cmdlet returns the export folder path. You can pipe the returned object to Import-
FederationConfiguration.
To back up custom attribute stores

1. You must manually export all custom attribute stores that you want to keep in your new AD FS farm in
NOTE
In Windows Server 2012 R2, AD FS requires custom attribute stores that are based on .NET Framework 4.0 or above.
Follow the instructions in Microsoft .NET Framework 4.5 to install and setup .Net Framework 4.5.
You can find information about custom attribute stores in use by AD FS by running the following Windows
PowerShell command:
Get-ADFSAttributeStore
The steps to upgrade or migrate custom attribute stores vary.

1. You must also manually export all .dll files of the custom attribute stores that you want to keep in your new
AD FS farm in Windows Server 2012 R2. The steps to upgrade or migrate .dll files of custom attribute stores
vary.
Create a Windows Server 2012 R2 federation server farm

1. Install the Windows Server 2012 R2 operating system on a computer that you want to function as a
federation server and then add the AD FS server role. For more information, see Install the AD FS Role
Service. Then configure your new federation service either through the Active Directory Federation Service
Configuration Wizard or via Windows PowerShell. For more information, see “Configure the first federation
server in a new federation server farm” in Configure a Federation Server.
While completing this step, you must follow these instructions:
You must have Domain Administrator privileges in order to configure your federation service.
You must use the same federation service name (farm name) as was used in the AD FS 2.0 or AD FS in
Windows Server 2012. If you do not use the same federation service name, the certificates that you
backed up will not function in the Windows Server 2012 R2 federation service that you are trying to
configure.
Specify whether this is a WID or SQL Server federation server farm. If it is a SQL farm, specify the SQL
Server database location and instance name.
You must provide a pfx file containing the SSL server authentication certificate that you backed up as part
of preparing for the AD FS migration process.
You must specify the same service account identity that was used in the AD FS 2.0 or AD FS in Windows
Server 2012 farm.
1. Once the initial node is configured, you can add additional nodes to your new farm. For more information, see
“Add a federation server to an existing federation server farm” in Configure a Federation Server.
Import the original configuration data into the Windows Server 2012
R2 AD FS farm
Now that you have an AD FS federation server farm running in Windows Server 2012 R2, you can import the
original AD FS configuration data into it.
1. Import and configure other custom AD FS certificates, including externally enrolled token-signing and token-
decryption/encryption certificates, and the service communication certificate if it is different from the SSL
certificate.
In the AD FS management console, select Certificates. Verify the service communications, token-
encryption/decryption, and token-signing certificates by checking each against the values you exported into the
certificates.txt file while preparing for the migration.
To change the token-decrypting or token-signing certificates from the default self-signed certificates to external
certificates, you must first disable the automatic certificate rollover feature that is enabled by default. To do this,
you can use the following Windows PowerShell command:
Set-ADFSProperties –AutoCertificateRollover $false
1. Configure any custom AD FS service settings such as AutoCertificateRollover or SSO lifetime using the
Set-AdfsProperties cmdlet.
2. To import AD FS relying party trusts and claims provider trusts, you must be logged in as Administrator
(however, not as the Domain Administrator) onto your federation server and run the following Windows
PowerShell script that is located in the \support\adfs folder of the Windows Server 2012 R2 installation
CD:
import-federationconfiguration.ps1
IMPORTANT
The import script takes the following parameters:
Import-FederationConfiguration.ps1 -Path <string> [- ComputerName <string>] [- Credential <pscredential>] [-
Force] [- LogPath <string>] [- CertificatePassword <securestring>]
Force] [- LogPath <string>] [- CertificatePassword <securestring>] [- RelyingPartyTrustIdentifier <string[]>] [-
ClaimsProviderTrustIdentifier <string[]>
Force] [- LogPath <string>] [- CertificatePassword <securestring>] [- RelyingPartyTrustName <string[]>] [-
ClaimsProviderTrustName <string[]>]
-RelyingPartyTrustIdentifier <string[]> - the cmdlet only imports relying party trusts whose identifiers are
specified in the string array. The default is to import NONE of the relying party trusts. If none of
RelyingPartyTrustIdentifier, ClaimsProviderTrustIdentifier, RelyingPartyTrustName, and ClaimsProviderTrustName is
specified, the script will import all relying party trusts and claims provider trusts.
-ClaimsProviderTrustIdentifier <string[]> - the cmdlet only imports claims provider trusts whose identifiers are
specified in the string array. The default is to import NONE of the claims provider trusts.
-RelyingPartyTrustName <string[]> - the cmdlet only imports relying party trusts whose names are specified in
the string array. The default is to import NONE of the relying party trusts.
-ClaimsProviderTrustName <string[]> - the cmdlet only imports claims provider trusts whose names are
specified in the string array. The default is to import NONE of the claims provider trusts.
-Path <string> - the path to a folder that contains the configuration files to be imported.
-LogPath <string> - the path to a folder that will contain the import log file. A log file named “import.log” will be
created in this folder.
-ComputerName <string> - specifies host name of the STS server. The default is the local computer. If you are
migrating AD FS 2.0 or AD FS in Windows Server 2012 to AD FS in Windows Server 2012 R2, this parameter should
be set to the hostname of the legacy AD FS server.
-Credential <PSCredential>- specifies a user account that has permission to perform this action. The default is
the current user.
-Force – specifies to not prompt for user confirmation.
-CertificatePassword <SecureString> - specifies a password for importing AD FS certificates’ private keys. If not
specified, the script will prompt for a password if an AD FS certificate with private key needs to be imported.
Inputs: string - this command takes the import folder path as input. You can pipe Export-FederationConfiguration
to this command.
Outputs: None.
Any trailing spaces in the WSFedEndpoint property of a relying party trust may cause the import script to error.
In this case, manually remove the spaces from the file prior to import. For example, these entries cause errors:
```
<URI N="WSFedEndpoint">https://127.0.0.1:444 /</URI>
```
```
<URI N="WSFedEndpoint">https://myapp.cloudapp.net:83 /</URI>
```
They must be edited to:
```
<URI N="WSFedEndpoint">https://127.0.0.1:444/</URI>
```
```
<URI N="WSFedEndpoint">https://myapp.cloudapp.net:83/</URI>
```
IMPORTANT
If you have any custom claim rules (rules other than the AD FS default rules) on the Active Directory claims provider trust
in the source system, these will not be migrated by the scripts. This is because Windows Server 2012 R2 has new defaults.
Any custom rules must be merged by adding them manually to the Active Directory claims provider trust in the new
Windows Server 2012 R2 farm.
1. Configure all custom AD FS endpoint settings. In the AD FS Management console, select Endpoints.
Check the enabled AD FS endpoints against the list of enabled AD FS endpoints that you exported to a
file while preparing for the AD FS migration.
- And -
Configure any custom claim descriptions. In the AD FS Management console, select Claim Descriptions.
Check the list of AD FS claim descriptions against the list of claim descriptions that you exported to a file
while preparing for the AD FS migration. Add any custom claim descriptions included in your file but not
included in the default list in AD FS. Note that Claim identifier in the management console maps to the
ClaimType in the file.
2. Install and configure all backed up custom attribute stores. As an administrator, ensure any custom
attribute store binaries are upgrade to .NET Framework 4.0 or higher before updating the AD FS
configuration to point to them.
3. Configure service properties that map to the legacy web.config file parameters.
If useRelayStateForIdpInitiatedSignOn was added to the web.config file in your AD FS 2.0 or
AD FS in Windows Server 2012 farm, then you must configure the following service properties in
your AD FS in Windows Server 2012 R2 farm:
AD FS in Windows Server 2012 R2 includes a
%systemroot%\ADFS\Microsoft.IdentityServer.Servicehost.exe.config file. Create an
element with the same syntax as the web.config file element:
<useRelayStateForIdpInitiatedSignOn enabled="true" /> . Include this element as part of
<microsoft.identityserver.web> section of the
Microsoft.IdentityServer.Servicehost.exe.config file.
If <persistIdentityProviderInformation enabled="true|false" lifetimeInDays="90"
enablewhrPersistence=”true|false” /> was added to the web.config file in your AD FS 2.0 or
AD FS in Windows Server 2012 farm, then you must configure the following service properties in
your AD FS in Windows Server 2012 R2 farm:
a. In AD FS in Windows Server 2012 R2, run the following Windows PowerShell command:
Set-AdfsWebConfig –HRDCookieEnabled –HRDCookieLifetime .
If <singleSignOn enabled="true|false" /> was added to the web.config file in your AD FS 2.0
or AD FS in Windows Server 2012 farm, you do not need to set any additional service properties
in your AD FS in Windows Server 2012 R2 farm. Single sign-on is enabled by default in AD FS in
Windows Server 2012 R2 farm.
If localAuthenticationTypes settings were added to the web.config file in your AD FS 2.0 or AD FS
in Windows Server 2012 farm, then you must configure the following service properties in your
AD FS in Windows Server 2012 R2 farm:
Integrated, Forms, TlsClient, Basic Transform list into equivalent AD FS in Windows Server
2012 R2 has global authentication policy settings to support both federation service and proxy
authentication types. These settings can be configured in the AD FS in Management snap-in
under the Authentication Policies.
After you import the original configuration data, you can customize the AD FS sign in pages as needed.
For more information, see Customizing the AD FS Sign-in Pages.
Next Steps
Migrate the Active Directory Federation Services
Proxy Server to Windows Server 2012 R2
In Active Directory Federation Services (AD FS ) in Windows Server 2012 R2, the role of a federation server proxy
is handled by a new Remote Access role service called Web Application Proxy. In Windows Server 2012 R2, to
enable your AD FS for accessibility from outside of the corporate network, you can deploy one or more Web
Application Proxies. However, you cannot migrate a federation server proxy running on Windows Server 2008 R2
or Windows Server 2012 to a Web Application Proxy running on Windows Server 2012 R2.
IMPORTANT
The migration of a federation server proxy running on Windows Server 2008, Windows Server 2008 R2, or Windows Server
2012 to a Web Application Proxy running on Windows Server 2012 R2 is NOT supported.
If you want to configure AD FS in a Windows Server 2012 R2 migrated farm for extranet access, you must
perform a fresh deployment of one or more Web Application Proxy computers as part of your AD FS
infrastructure.
To plan Web Application Proxy deployment, you can review the information in the following topics:
Plan the Web Application Proxy Infrastructure
To deploy Web Application proxy, you can follow the procedures in the following topics:
Configure the Web Application Proxy Infrastructure
Install and Configure the Web Application Proxy Server
Next Steps
Verify the AD FS 2.0 migration to Windows Server
2012 R2
Once you complete the same server migration of your Active Directory Federation Service (AD FS ) farm to
Windows Server 2012 R2, you can use the following procedure to verify that federation servers in your farm are
operational; that is, that any client on the same network can reach your federtation servers.
the minimum required to complete this procedure.
To verify that a federation server is operational
1. Open a browser window and in the address bar, type the federation servers name, and then append it with
federationmetadata/2007-06/federationmetadata.xml to browse to the federation service metadata endpoint. For
example, https://fs.contoso.com/federationmetadata/2007-06/federationmetadata.xml .
If in your browser window you can see the federation server metadata without any SSL errors or warnings, your
federation server is operational.
1. You can also browse to the AD FS sign-in page (your federation service name appended with
adfs/ls/idpinitiatedsignon.htm , for example, https://fs.contoso.com/adfs/ls/idpinitiatedsignon.htm ). This
displays the AD FS sign-in page where you can sign in with domain administrator credentials.
IMPORTANT
Make sure to configure your browser settings to trust the federation server role by adding your federation service name (for
example, https://fs.contoso.com ) to the browser’s local intranet zone.
Next Steps
Migrate Active Directory Federation Services Role
Services to Windows Server 2012
The following provides instructions on migrating the following role services to Active Directory Federation
Services (AD FS ) on Windows Server 2012:
AD FS 1.1 Windows token-based agent and AD FS 1.1 claims-aware agent installed with Windows Server
2008 or Windows Server 2008 R2
AD FS 2.0 federation server and AD FS 2.0 federation server proxy installed on Windows Server 2008 or
Supported migration scenarios

The migration instructions contains the following tasks:
Exporting the AD FS 2.0 configuration data from your server that is running Windows Server 2008 or
Performing an in-place upgrade of the operating system of this server from Windows Server 2008 or
Windows Server 2008 R2 to Windows Server 2012.
Recreating the original AD FS configuration and restoring the remaining AD FS service settings on this
server, which is now running the AD FS server role that is installed with Windows Server 2012.
This guide does not include instructions to migrate a server that is running multiple roles. If your server is
running multiple roles, we recommend that you design a custom migration process specific to your server
environment, based on the information provided in other role migration guides. Migration guides for
additional roles are available on the Windows Server Migration Portal.
Supported operating systems

Destination server operating system:
Windows Server 2012 or Windows Server 2008 R2 (Server Core and full installation options)
Destination server processor:
x64-based
x86- or x64-based Windows Server 2003 with Service Pack 2
x86- or x64-based Windows Server 2003 R2
x86- or x64-based Windows Server 2008, both full and Server Core installation
options
x64-based Windows Server 2008 R2

x64-based Server Core installation option of Windows Server 2008 R2
x64-based Server Core and full installation options of Windows Server

2012
NOTE
The versions of operating systems that are listed in the preceding table are the oldest combinations of operating systems
and service packs that are supported.
The Foundation, Standard, Enterprise, and Datacenter editions of the Windows Server operating system are
supported as the source or the destination server.
Migrations between physical operating systems and virtual operating systems are supported.
Supported AD FS role services and features

The following table describes the migration scenarios of the AD FS role services and their respective settings that
are described in this guide.
FROM TO AD FS INSTALLED WITH WINDOWS SERVER 2012
AD FS 1.0 federation server installed with Windows Server Migration is not supported
2003 R2
AD FS 1.0 federation server proxy installed with Windows Migration is not supported
Server 2003 R2
AD FS 1.0 Windows token-based agent installed with Migration is not supported

AD FS 1.0 claims-aware agent installed with Windows Server Migration is not supported
2003 R2)
AD FS 1.1 federation server installed with Windows Server Migration is not supported
AD FS 1.1 federation server proxy installed with Windows Migration is not supported
Server 2008 or Windows Server 2008 R2
AD FS 1.1 Windows token-based agent installed with Migration on the same server is supported, but the migrated
Windows Server 2008 or Windows Server 2008 R2 AD FS Windows token-based agent will function only with an
AD FS 1.1 federation service installed with Windows Server
2008 or Windows Server 2008 R2. For more information, see:

FROM TO AD FS INSTALLED WITH WINDOWS SERVER 2012
AD FS 1.1 claims-aware agent installed with Windows Server Migration on the same server is supported. The migrated AD
2008 or Windows Server 2008 R2) FS 1.1 claims-aware web agent will function with the following:
AD FS 1.1 federation service installed with Windows Server

AD FS 2.0 federation service installed on Windows Server

AD FS federation service installed with Windows Server 2012
For more information, see:
AD FS 2.0 federation server installed on Windows Server 2008 Migration on the same server is supported. For more
or Windows Server 2008 R2 information, see:
AD FS 2.0 federation server proxy installed on Windows Server Migration on the same server is supported. For more
2008 or Windows Server 2008 R2 information see:
See Also
This document is the starting point for preparing to migrate your AD FS 2.0 Federation Server to Windows
Server 2012. Choose the one that best fits your migration scenario:
Prepare to migrate a stand-alone AD FS federation server or a single-node AD FS farm
Prepare to migrate a WID farm
Prepare to migrate a SQL Server farm
Next Steps
Prepare to migrate a stand-alone AD FS federation
server or a single-node AD FS farm
To prepare to migrate (same server migration) a stand-alone AD FS 2.0 federation server or a single-node AD FS
farm to Windows Server 2012, you must export and back up the AD FS configuration data from this server.
To export the AD FS configuration data, perform the following tasks:
Step 1: Export service settings
Step 2: Export claims provider trusts
Step 3: Export relying party trusts
Step 4: Back up custom attribute stores
Step 5: Back up webpage customizations

To export service settings, perform the following procedure:
1. Record the certificate subject name and thumbprint value of the SSL certificate used by the federation service.
To find the SSL certificate, open the Internet Information Services (IIS ) management console, Select Default
then click View.
NOTE
Optionally, you can also export the SSL certificate used by the federation service and its private key to a .pfx file. For more
information, see Export the Private Key Portion of a Server Authentication Certificate.
Exporting the SSL certificate is optional because this certificate is stored in the local computer Personal certificates store and
is preserved in the operating system upgrade.
1. Record the configuration of the AD FS Service communications, token-decrypting and token-signing

certificates. To view all the certificates that are used, open Windows PowerShell and run the following
command to add the AD FS cmdlets to your Windows PowerShell session:
PSH:>add-pssnapin “Microsoft.adfs.powershell” . Then run the following command to create a list of all
certificates in use in a file PSH:>Get-ADFSCertificate | Out-File “.\certificates.txt”
NOTE
Optionally, you can also export any token-signing, token-encryption, or service-communications certificates and keys that
are not internally generated, in addition to all self-signed certificates. You can view all the certificates that are in use on your
server by using Windows PowerShell. Open Windows PowerShell and run the following command to add the AD FS cmdlets
to your Windows PowerShell session: PSH:>add-pssnapin “Microsoft.adfs.powershell . Then run the following command
to view all certificates that are in use on your server PSH:>Get-ADFSCertificate . The output of this command includes
StoreLocation and StoreName values that specify the store location of each certificate. You can then use the guidance in
Export the Private Key Portion of a Server Authentication Certificate to export each certificate and its private key to a .pfx file.
Exporting these certificates is optional because all external certificates are preserved during the operating system upgrade.
1. Export AD FS 2.0 federation service properties, such as the federation service name, federation service display
name, and federation server identifier to a file.
To export federation service properties, open Windows PowerShell and run the following command to add the AD
FS cmdlets to your Windows PowerShell session: PSH:>add-pssnapin “Microsoft.adfs.powershell” . Then run the
following command to export federation service properties:
PSH:> Get-ADFSProperties | Out-File “.\properties.txt” .
The output file will contain the following important configuration values:
connection string.
%programfiles%\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config file to a
secure location on a backup server.
NOTE
Make note of the database connection string in this file, located immediately after “policystore connectionstring=”). If the
connection string specifies a SQL Server database, the value is needed when restoring the original AD FS configuration on
The following is an example of a WID connection string:
“Data Source=\\.\pipe\mssql$microsoft##ssee\sql\query;Initial Catalog=AdfsConfiguration;Integrated
Security=True"
. The following is an example of a SQL Server connection string:
"Data Source=databasehostname;Integrated Security=True" .
1. Record the identity of the AD FS 2.0 federation service account and the password of this account.
console and manually record this value.
NOTE
For a stand-alone federation service, the built-in NETWORK SERVICE account is used. In this case, you do not need to have a
password.
1. Export the list of enabled AD FS endpoints to a file.

To do this, open Windows PowerShell and run the following command to add the AD FS cmdlets to your
Windows PowerShell session: PSH:>add-pssnapin “Microsoft.adfs.powershell” . Then run the following command
to export the list of enabled AD FS endpoints to a file: PSH:> Get-ADFSEndpoint | Out-File “.\endpoints.txt” .
1. Export any custom claim descriptions to a file.
To do this, open Windows PowerShell and run the following command to add the AD FS cmdlets to your
Windows PowerShell session: PSH:>add-pssnapin “Microsoft.adfs.powershell” . Then run the following command
to export any custom claim descriptions to a file: Get-ADFSClaimDescription | Out-File “.\claimtypes.txt” .
Step 2: Export claims provider trusts

To export the claims provider trusts, perform the following procedure:
To export claims provider trusts
1. You can use Windows PowerShell to export all claims provider trusts. Open Windows PowerShell and run the
following command to add the AD FS cmdlets to your Windows PowerShell session:
PSH:>add-pssnapin “Microsoft.adfs.powershell” . Then run the following command to export all claims provider
trusts: PSH:>Get-ADFSClaimsProviderTrust | Out-File “.\cptrusts.txt” .
Step 3: Export relying party trusts

To export relying party trusts, perform the following procedure:
To export relying party trusts
1. To export all relying party trusts, open Windows PowerShell and run the following command to add the AD FS
cmdlets to your Windows PowerShell session: PSH:>add-pssnapin “Microsoft.adfs.powershell” . Then run the
following command to export all relying party trusts:
PSH:>Get-ADFSRelyingPartyTrust | Out-File “.\rptrusts.txt” .

You can find information about custom attribute stores in use by AD FS by using Windows PowerShell. Open
Windows PowerShell and run the following command to add the AD FS cmdlets to your Windows PowerShell
session: PSH:>add-pssnapin “Microsoft.adfs.powershell” . Then run the following command to find information
about the custom attribute stores: PSH:>Get-ADFSAttributeStore . The steps to upgrade or migrate custom attribute
stores vary.

To back up any webpage customizations, copy the AD FS webpages and the web.config file from the directory
that is mapped to the virtual path “/adfs/ls” in IIS. By default, it is in the %systemdrive%\inetpub\adfs\ls
directory.
Next Steps
Prepare to migrate an AD FS 2.0 WID farm
To prepare to migrate AD FS 2.0 federation servers that belong to a Windows Internal Database (WID ) farm to
Windows Server 2012, you must export and back up the AD FS configuration data from these servers.
Step 1: - Export service settings

To find the SSL certificate, open the Internet Information Services (IIS ) management console, select Default
Web Site in the left pane, click Bindings… in the Action pane, find and select the https binding, click Edit,
then click View.
NOTE
Optionally, you can also export the SSL certificate and its private key to a .pfx file. For more information, see Export the
Private Key Portion of a Server Authentication Certificate.
This step is optional because this certificate is stored in the local computer Personal certificates store and will be preserved in
the operating system upgrade.
1. Export any token-signing, token-encryption, or service-communications certificates and keys that are not
internally generated, in addition to self-signed certificates.
You can view all the certificates that are in use on your server by using Windows PowerShell. Open Windows
PowerShell and run the following command to add the AD FS cmdlets to your Windows PowerShell session:
PSH:>add-pssnapin “Microsoft.adfs.powershell” . Then run the following command to view all certificates that are
in use on your server PSH:>Get-ADFSCertificate . The output of this command includes StoreLocation and
StoreName values that specify the store location of each certificate. You can then use the guidance in Export the
Private Key Portion of a Server Authentication Certificate to export each certificate and its private key to a .pfx file.
NOTE
This step is optional, because all external certificates are preserved during the operating system upgrade.
console and manually record the value.
stores vary.

directory.
Next Steps
Prepare to migrate a SQL Server farm
To prepare to migrate AD FS 2.0 federation servers that belong to a SQL Server farm to Windows Server 2012,
you must export and back up the AD FS configuration data from these servers.

To find the SSL certificate, open the Internet Information Services (IIS ) management console, select Default
then click View.
NOTE
Optionally, you can also export the SSL) certificate and its private key to a .pfx file. For more information, see Export the
Private Key Portion of a Server Authentication Certificate.
This step is optional because this certificate is stored in the local computer Personal certificates store and will be preserved in
the operating system upgrade.
1. Export any other token-signing, token-encryption, or service-communications certificates and keys that are not
internally generated by AD FS.
You can view all certificates that are in use by AD FS on your server by using Windows PowerShell. Open
session: PSH:>add-pssnapin “Microsoft.adfs.powershell” . Then run the following command to view all certificates
that are in use on your server PSH:>Get-ADFSCertificate . The output of this command includes StoreLocation and
StoreName values that specify the store location of each certificate.
NOTE
Optionally, you can then use the guidance in Export the Private Key Portion of a Server Authentication Certificate to export
each certificate and its private key to a .pfx file. This step is optional, because all external certificates are preserved during the
operating system upgrade.
connection string.
%programfiles%\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config file to a
secure location on a backup server.
NOTE
Record the SQL Server connection string after “policystore connectionstring=” in the following file:
%programfiles%\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config . You
need this string when you restore the original AD FS configuration on the federation server.
console and manually record the value.

stores vary.

directory.
Next Steps
Proxy
To prepare to migrate an AD FS 2.0 federation server proxy to Windows Server 2012, you must export and back
up the AD FS configuration data from this server proxy. The steps in this topic apply to a scenario with one
proxy federation server or multiple proxy federation servers.
Step 1: Export proxy service settings
Step 1: Export proxy service settings

To export federation server proxy service settings, perform the following procedure:
To export proxy service settings
1. Export the Secure Sockets Layer (SSL ) certificate and its private key to a .pfx file. For more information, see
Export the Private Key Portion of a Server Authentication Certificate.
NOTE
This step is optional because this certificate is preserved during the operating system upgrade.
1. Export AD FS 2.0 federation proxy properties to a file. You can do that by using Windows PowerShell.
Open Windows PowerShell and run the following command to add the AD FS cmdlets to your Windows
PowerShell session: PSH:>add-pssnapin “Microsoft.adfs.powershell” . Then run the following command to export
federation proxy properties to a file: PSH:> Get-ADFSProxyProperties | out-file “.\proxyproperties.txt” .
1. Ensure you know the credentials of an account that is either an administrator of the AD FS federation
server or the service account under which the AD FS federation service runs. This information is required
for the proxy trust setup.
Completing this step results in gathering the following information that is required to configure your AD
FS federation server proxy:
AD FS federation service name
Name of the domain account that is required for the proxy trust setup
The address and the port of the HTTP proxy (if there is an HTTP proxy between the AD FS federation
server proxy and the AD FS federation servers)

To back up webpage customizations, copy the AD FS proxy webpages and the web.config file from the
directory that is mapped to the virtual path “/adfs/ls” in IIS. By default, it is in the
%systemdrive%\inetpub\adfs\ls directory.
Next Steps
Migrate the AD FS 2.0 federation server
This document is the starting point for migrating your AD FS 2.0 Federation Server to Windows Server 2012.
Choose the one that best fits your migration scenario:
Migrate a stand-alone AD FS federation server or a single-node AD FS farm
Migrate a WID farm
Migrate a SQL Server farm
Next Steps
Migrate a stand-alone AD FS federation server or a
single-node AD FS farm
This document provides detailed information on migrating an AD FS 2.0 stand alone server to Windows Server
2012.
Migrate a stand-alone AD FS 2.0 server

Use the following procedure to migrate the AD FS 2.0 server to Windows Server 2012.
1. Review and perform the procedures in Prepare to migrate a stand-alone AD FS federation server or a
single-node AD FS farm.
2. Perform an in-place upgrade of the operating system on your server from Windows Server 2008 R2 or
Windows Server 2008 to Windows Server 2012. For more information, see Installing Windows Server
2012.
IMPORTANT
As the result of the operating system upgrade, the AD FS configuration on this server is lost and the AD FS 2.0 server role is
removed. The Windows Server 2012 AD FS server role is installed instead, but it is not configured. You must manually create
the original AD FS configuration and restore the remaining AD FS settings to complete the federation server migration.
1. Create the original AD FS configuration. You can create the original AD FS configuration by using either of the
following methods:
Use the AD FS Federation Server Configuration Wizard to create a new federation server. For more
information, see Create the First Federation Server in a Federation Server Farm.
As you go through the wizard, use the information you gathered while preparing to migrate your AD FS federation
server as follows:
FEDERATION SERVER CONFIGURATION WIZARD INPUT OPTION USE THE FOLLOWING VALUE
SSL Certificate on the Specify the Federation Service Select the SSL certificate whose subject name and thumbprint
Name page you recorded while preparing for the AD FS federation server
migration.
Service account and Password on the Specify a Service Enter the service account information that you recorded while
Account page preparing for the AD FS federation server migration. Note: If
you select stand-alone federation server on the second page
of the wizard, NETWORK SERVICE is used automatically as the
service account.
IMPORTANT
You can employ this method only if you are using Windows Internal Database (WID) to store the AD FS configuration
database for your stand-alone federation server or a single-node AD FS farm.
If you are using SQL Server to store the AD FS configuration database for your single-node AD FS farm, you must use
Windows PowerShell to create the original AD FS configuration on your federation server.
Use Windows PowerShell
IMPORTANT
You must use Windows PowerShell if you are using SQL Server to store the AD FS configuration database for your stand-
alone federation server or a single-node AD FS farm.
The following is an example of how to use Windows PowerShell to create the original AD FS configuration on a
federation server in a single-node SQL Server farm. Open the Windows PowerShell module and run the following
command: $fscredential = Get-Credential . Enter the name and the password of the service account that you
recorded while preparing your SQL server farm for migration. Then run the following command:
C:\PS> Add-AdfsFarmNode -ServiceAccountCredential $fscredential -SQLConnectionString "Data Source=<Data
Source>;Integrated Security=True"
where is the data source value in the policy store connection string value in the following file:
Data Source
%programfiles%\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config .
1. Restore the remaining AD FS service settings and trust relationships. This is a manual step during which you
can use the files that you exported and the values that you collected while preparing for the AD FS migration.
For detailed instructions, see Restoring the Remaining AD FS Farm Configuration.
NOTE
This step is only required if you are migrating a stand-alone federation server or a single node WID farm. If the federation
server uses a SQL Server database as the configuration store, the service settings and trust relationships are preserved in the
database.
1. Update your AD FS webpages. This is a manual step. If you backed up your customized AD FS webpages
while preparing for the migration, use your backup data to overwrite the default AD FS webpages that were
created by default in the %systemdrive%\inetpub\adfs\ls directory as a result of the AD FS configuration
on Windows Server 2012.
2. Restore any remaining AD FS customizations, such as custom attribute stores.
Restoring the Remaining AD FS Farm Configuration

Restore the following AD FS service settings to a single node WID farm or stand-alone federation service
as follows:
In the AD FS management console, select Service and click Edit Federation Service…. Verify the
federation service settings by checking each of the values against the values you exported into the
properties.txt file while preparing for the migration:

In the AD FS management console, select Certificates. Verify the service communications, token-decrypting,
and token-signing certificates by checking each against the values you exported into the certificates.txt file while
preparing for the migration.
To change the token-decrypting or token-signing certificates from the default self-signed certificates to external
certificates, you must first disable the automatic certificate rollover feature that is enabled by default. To do this,
you can use the following Windows PowerShell command:
PSH: Set-ADFSProperties –AutoCertificateRollover $false .
In the AD FS Management console, select Endpoints. Check the enabled AD FS endpoints against the list
of enabled AD FS endpoints that you exported to a file while preparing for the AD FS migration.
In the AD FS Management console, select Claim Descriptions. Check the list of AD FS claim descriptions
against the list of claim descriptions that you exported to a file while preparing for the AD FS migration.
Add any custom claim descriptions included in your file but not included in the default list in AD FS. Note
that Claim identifier in the management console maps to the ClaimType in the file. For more information on
adding claim descriptions, see Add a Claim Description. For more information, see the “Step 1 - Export
Service Settings” section in Prepare to Migrate the AD FS 2.0 Federation Server.
In the AD FS Management console, select Claims Provider Trusts. You must recreate each Claims Provider
trust manually using the Add Claims Provider Trust Wizard. Use the list of claims provider trusts that you
exported and recorded while preparing for the AD FS migration. You can disregard the claims provider trust
with Identifier “AD AUTHORITY” in the file because this is the “Active Directory” claims provider trust that
is part of the default AD FS configuration. However, check for any custom claim rules you may have added
to the Active Directory trust prior to the migration. For more information on creating claims provider trusts,
see Create a Claims Provider Trust Using Federation Metadata or Create a Claims Provider Trust Manually.
In the AD FS Management console, select Relying Party Trusts. You must recreate each Relying Party
trust manually using the Add Relying Party Trust Wizard. Use the list of relying party trusts that you
exported and recorded while preparing for the AD FS migration. For more information on creating relying
party trusts, see Create a Relying Party Trust Using Federation Metadata or Create a Relying Party Trust
Manually.
Next Steps
Migrate an AD FS 2.0 WID farm
This document provides detailed information on migrating an AD FS 2.0 Windows Internal Database (WID ) farm
to Windows Server 2012.
Migrate an AD FS WID farm

To migrate a WID farm to Windows Server 2012, perform the following procedure:
1. For every node (server) in the WID farm, review and perform the procedures in Prepare to migrate a WID
farm.
2. Remove any non-primary nodes from the load balancer.
3. Upgrade of the operating system on this server from Windows Server 2008 R2 or Windows Server 2008 to
Windows Server 2012. For more information, see Installing Windows Server 2012.
IMPORTANT
removed. The Windows Server 2012 AD FS server role is installed instead, but it is not configured. You must create the
original AD FS configuration and restore the remaining AD FS settings to complete the federation server migration.
1. Create the original AD FS configuration on this server.

You can create the original AD FS configuration by using the AD FS Federation Server Configuration Wizard
to add a federation server to a WID farm. For more information, see Add a Federation Server to a Federation
Server Farm.
NOTE
When you reach the Specify the Primary Federation Server and a Service Account page in the AD FS Federation
Server Configuration Wizard, enter the name of the primary federation server of the WID farm and be sure to enter the
service account information that you recorded while preparing for the AD FS migration. For more information, see Prepare to
Migrate the AD FS 2.0 Federation Server.
When you reach the Specify the Federation Service Name page, be sure to select the same SSL certificate you recorded in
the “Prepare to migrate a WID farm” in Prepare to Migrate the AD FS 2.0 Federation Server.
1. Update your AD FS webpages on this server. If you backed up your customized AD FS webpages while
preparing for the migration, you need to use your backup data to overwrite the default AD FS webpages
that were created by default in the %systemdrive%\inetpub\adfs\ls directory as a result of the AD FS
configuration on Windows Server 2012.
2. Add the server that you just upgraded to Windows Server 2012 to the load balancer.
3. Repeat steps 1 through 6 for the remaining secondary servers in your WID farm.
4. Promote one of the upgraded secondary servers to be the primary server in your WID farm. To do this,
open Windows PowerShell and run the following command:
PSH:> Set-AdfsSyncProperties –Role PrimaryComputer .
5. Remove the original primary server of your WID farm from the load balancer.
6. Demote the original primary server in your WID farm to be a secondary server by using Windows
PowerShell. Open Windows PowerShell and run the following command to add the AD FS cmdlets to your
Windows PowerShell session: PSH:>add-pssnapin “Microsoft.adfs.powershell” . Then run the following
command to demote the original primary server to be a secondary server:
PSH:> Set-AdfsSyncProperties – Role SecondaryComputer –PrimaryComputerName <FQDN of the Primary
Federation Server>
.
7. Upgrade of the operating system on this last node (server) in your WID farm from Windows Server 2008
R2 or Windows Server 2008 to Windows Server 2012. For more information, see Installing Windows
Server 2012.
IMPORTANT
As the result of upgrading the operating system, the AD FS configuration on this server is lost and the AD FS 2.0 server role
is removed. The Windows Server 2012 AD FS server role is installed instead, but it is not configured. You must manually
create the original AD FS configuration and restore the remaining AD FS settings to complete the federation server
migration.
1. Create the original AD FS configuration on this last node (server) in your WID farm.
You can create the original AD FS configuration by using the AD FS Federation Server Configuration Wizard
to add a federation server to a WID farm. For more information, see Add a Federation Server to a Federation
Server Farm.
NOTE
When you reach the Specify the Primary Federation server and a Service Account page in the AD FS Federation
Server Configuration Wizard, enter the service account information that you recorded while preparing for the AD FS
migration. For more information, see Prepare to Migrate the AD FS 2.0 Federation Server.
When you reach the Specify the Federation Service Name page, be sure to select the same SSL certificate you recorded in
Prepare to Migrate the AD FS 2.0 Federation Server.
1. Update your AD FS webpages on this last server in your WID farm. If you backed up your customized AD
FS webpages while preparing for the migration, use your backup data to overwrite the default AD FS
webpages that were created by default in the %systemdrive%\inetpub\adfs\ls directory as a result of the
AD FS configuration on Windows Server 2012.
2. Add this last server of your WID farm that you just upgraded to Windows Server 2012 to the load balancer.
3. Restore any remaining AD FS customizations, such as custom attribute stores.
Next Steps
Migrate an AD FS 2.0 WID farm
This document provides detailed information on migrating an AD FS 2.0 SQL farm to Windows Server 2012.
Migrate a SQL Server farm

To migrate a SQL Server farm to Windows Server 2012, perform the following procedure:
1. For each server in your SQL Server farm, review and perform the procedures in Migrate a SQL Server
farm.
2. Remove any server in your SQL Server farm from the load balancer.
3. Upgrade the operating system on this server in your SQL Server farm from Windows Server 2008 R2 or
2012.
IMPORTANT
removed. The Windows Server 2012 AD FS server role is installed instead, but it is not configured. You must manually create
the original AD FS configuration and restore the remaining AD FS settings to complete the federation server migration.
1. Create the original AD FS configuration on this server in your SQL Server farm by using AD FS Windows
PowerShell cmdlets to add a server to an existing farm.
IMPORTANT
You must use Windows PowerShell to create the original AD FS configuration if you are using SQL Server to store your AD FS
Open Windows PowerShell and run the following command: $fscredential = Get-Credential .
Enter the name and the password of the service account that you recorded while preparing your SQL Server
farm for migration.
Run the following command:
Add-AdfsFarmNode -ServiceAccountCredential $fscredential -SQLConnectionString "Data Source=<Data
Source>;Integrated Security=True"
, where Data Sourceis the data source value in the policy store connection string value in the following file:
%programfiles%\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config .
1. Add the server that you just upgraded to Windows Server 2012 to the load balancer.
2. Repeat steps 2 through 6 for the remaining nodes in your SQL Server farm.
3. When all of the servers in your SQL Server farm are upgraded to Windows Server 2012, restore any
remaining AD FS customizations, such as custom attribute stores.
Next Steps
Migrate the AD FS 2.0 federation server proxy
This document provides detailed information on migrating an AD FS 2.0 federation proxy server to Windows
Server 2012.
Migrate the proxy

To migrate an AD FS 2.0 federation server proxy to Windows Server 2012, perform the following procedure:
1. For every federation server proxy that you plan to migrate to Windows Server 2012, review and perform
the procedures in Prepare to Migrate the AD FS 2.0 Federation Server Proxy.
2. Remove a federation server proxy from the load balancer.
3. Perform an in-place upgrade of the operating system on this server from Windows Server 2008 R2 or
2012.
IMPORTANT
As the result of the operating system upgrade, the AD FS proxy configuration on this server is lost and the AD FS 2.0
server role is removed. The Windows Server 2012 AD FS server role is installed instead, but it is not configured. You must
manually create the original AD FS proxy configuration and restore the remaining AD FS proxy settings to complete the
federation server proxy migration.
1. Create the original AD FS proxy configuration by using the AD FS Federation Server Proxy
Configuration Wizard. For more information, see Configure a Computer for the Federation Server Proxy
Role. As you execute the wizard, use the information you gathered in Prepare to Migrate the AD FS 2.0
Federation Server Proxy as follows:
FEDERATION SERVER PROXY WIZARD INPUT OPTION USE THE FOLLOWING VALUE
Federation Service Name Enter the BaseHostName value from proxyproperties.txt file
Use an HTTP proxy server when sending requests to Check this box if your proxyproperties.txt file contains a
this Federation Service check box value for the ForwardProxyUrl property
HTTP proxy server address Enter the ForwardProxyUrl value from proxyproperties.txt file
Credential prompt Enter the credentials of an account that is either an

administrator of the AD FS federation server or the service
account under which the AD FS federation service runs.
1. Update your AD FS webpages on this server. If you backed up your customized AD FS proxy webpages
while preparing your federation server proxy for the migration, use your backup data to overwrite the
default AD FS webpages that were created by default in the %systemdrive%\inetpub\adfs\ls directory
as a result of the AD FS proxy configuration in Windows Server 2012.
2. Add this server back to the load balancer.
3. If you have other AD FS 2.0 federation server proxies to migrate, repeat steps 2 through 6 for the
remaining federation server proxy computers.
Next Steps
Migrate the AD FS web agent
To migrate the AD FS 1.1 Windows token-based agent or the AD FS 1.1 claims-aware agent that is installed
with Windows Server 2008 R2 or Windows Server 2008 to Windows Server 2012, perform an in-place
upgrade of the operating system of the computer that hosts either agent to Windows Server 2012. For more
information, see Installing Windows Server 2012. No further configuration is required.
IMPORTANT
The migrated AD FS 1.1 Windows token-based agent functions only with an AD FS 1.1 federation service that is installed
with Windows Server 2008 R2 or Windows Server 2008. For more information, see Interoperating with AD FS 1.x.
The migrated AD FS 1.1 claims-aware web agent functions with the following:
AD FS 1.1 federation service installed with Windows Server 2008 R2 or Windows Server 2008
AD FS 2.0 federation service installed on Windows Server 2008 R2 or Windows Server 2008
AD FS federation service installed with Windows Server 2012
For more information, see Interoperating with AD FS 1.x.
Next Steps
AD FS Development
This document contains a list of all of the documentation walkthroughs for AD FS for Windows Server 2016. This
Build a web application using OpenID Connect with AD FS 2016
Build a single page web application using OAuth and ADAL.JS with AD FS 2016
Build a server side application using OAuth confidential clients with AD FS 2016
Build a multi-tiered application using On-Behalf-Of (OBO ) using OAuth with AD FS 2016
Build a native client application using OAuth public clients with AD FS 2012 R2 or higher
Build a native client application using OAuth public clients with AD FS 2016
Customize claims to be emitted in id_token when using OpenID Connect or OAuth with AD FS 2016
Identity delegation with AD FS
Single log-out for OpenID Connect with AD FS 2016
Customize claims to be emitted in id_token when
using OpenID Connect or OAuth with AD FS 2016
Overview
The article here shows how to build an app that uses AD FS for OpenID Connect sign on. However, by default
there are only a fixed set of claims available in the id_token. AD FS 2016 has the capability to customize the
id_token in OpenID Connect scenarios.
When are custom ID token used?

In certain scenarios it is possible that the client application does not have a resource that it is trying to access.
Therefore, it doesn’t really need an access token. In such cases, the client application essentially needs only an ID
token but with some additional claims to help in the functionality.
What are the restrictions on getting custom claims in ID token?

Scenario 1
1. response_mode is set as form_post

2. Only public clients can get custom claims in ID token
3. Relying Party Identifier should be same as client identifier
Scenario 2
With KB4019472 installed on your AD FS servers
1. response_mode is set as form_post
2. Assign scope allatclaims to the client – RP pair. You can assign the scope by using the Grant-
ADFSApplicationPermission cmdlet as indicated in the example below:
Grant-AdfsApplicationPermission -ClientRoleIdentifier "https://my/privateclient" -ServerRoleIdentifier

"https://rp/fedpassive" -ScopeNames "allatclaims","openid"
Creating an OAuth application to handle custom claims in ID token

Use the article here to create an application app that uses AD FS for OpenID Connect sign on. Then follow the
steps below to configure the application in AD FS for receiving ID token with custom claims.
Create the Application Group in AD FS 2016
1. Create an application group based on the new template, shown below, called CustomTokenClient.
1. This template creates a confidential client. Note the identifier and specify the return URI as the SSL URL of the
VS project.
1. In the next step, select Generate a shared secret to create client credentials and copy the client credentials
generated.
1. Click Next and proceed to complete the wizard.
Create the Relying Party
In order to add custom claims in ID token, you need to create a RP whose claims will be added in the ID token. Use
the Add Relying Party Trust wizard to create a new relying party as shown below:
After relying party is created, right click on the relying party entry and select Edit claim issuance policy to add
claims issuance rules. Add the required custom claims for ID token as shown below:
Assign “allatclaims” scope to the pair of client and relying party
Using PowerShell on AD FS server, assign the new allatclaims scope as given in the example below (change the
clientID and server:
Grant-AdfsApplicationPermission -ClientRoleIdentifier "5db77ce4-cedf-4319-85f7-cc230b7022e0" -

ServerRoleIdentifier "https://customidrp1/" -ScopeNames "allatclaims","openid"
NOTE
Change the ClientRoleIdentifier and ServerRoleIdentifier according to your application settings
Test the custom claims in ID token

Then, using the same bit of code you have always used to access claims, you can see the additional claims that will
become part of the id_token. For example, in a .NET MVC sample app, open one of the controller files and enter
code like the below:
[Authorize]
public ActionResult About()
{
ClaimsPrincipal cp = ClaimsPrincipal.Current;
string userName = cp.FindFirst(ClaimTypes.GivenName).Value;

ViewBag.Message = String.Format("Hello {0}!", userName);
return View();
NOTE
Please be aware that the resource parameter is required in the Oauth2 request.
Bad example:
https://sts.contoso.com/adfs/oauth2/authorize?
response_type=id_token&scope=openid&redirect_uri=https://myportal/auth&nonce=b3ceb943fc756d927777&cli
ent_id=6db3ec2a-075a-4c72-9b22-ca7ab60cb4e7&state=42c2c156aef47e8d0870&resource=6db3ec2a-075a-4c72-
9b22-ca7ab60cb4e7
Good example:
https://sts.contoso.com/adfs/oauth2/authorize?
response_type=id_token&scope=openid&redirect_uri=https://myportal/auth&nonce=b3ceb943fc756d927777&cli
ent_id=6db3ec2a-075a-4c72-9b22-
ca7ab60cb4e7&state=42c2c156aef47e8d0870&resource=https://customidrp1/&response_mode=form_post
If the resource parameter is not in the request you may receive an error or a token without any custom claims.
Next Steps
AD FS Development
Build a multi-tiered application using On-Behalf-Of
(OBO) using OAuth with AD FS 2016
This walkthrough provides instruction for implementing an on-behalf-of (OBO ) authentication using AD FS in
Windows Server 2016 TP5. To learn more about OBO authentication please read AD FS Scenarios for Developers
WARNING: The example that you can build here is for educational purposes only. These instructions are for
the simplest, most minimal implementation possible to expose the required elements of the model. The
example may not include all aspects of error handling and other relate functionality and focuses ONLY on
getting a successful OBO authentication.
Overview
In this sample we will be creating an authentication flow where a client will be accessing a middle-tier Web Service
and the web service will then act on behalf of the authenticated client to get an access token.
Below is the authentication flow that the sample will achieve

1. Client authenticates to AD FS authorization end point and requests an authorization code
2. Authorization endpoint returns authentication code to client
3. Client uses authentication code and presents it to the AD FS token endpoint to request access token for Middle
Tier Web Service as WebAPI
4. AD FS returns the access token to Mid Tier Web Service. For additional functionality, Middle Tier Service needs
access to the Backend WebAPI
5. Client uses the access token to use Middle Tier service.
6. Middle Tier service provides the access token to the AD FS token end point and requests access token for
Backend WebAPI on-behalf-of the authenticated user
7. AD FS returns access token for backend WebAPI to Middle Tier Service actiing as client
8. Middle Tier Service uses the access token provided by AD FS in step 7 to access the backend WebAPI as client
and perform the necessary functions
Sample Structure
Sample will comprise of three modules
MODULE DESCRIPTION
ToDoClient Native client with which the user interacts
ToDoService Middle Tier web API which acts as a client for the backend
WebAPI
WebAPIOBO Backend web api that is used by ToDoService to perform the

requisite operation when user adds a ToDoItem
Setting up the development box

This walk-through uses Visual Studio 2015. The project heavily uses Active Directory Authentication Library
(ADAL ). To learn about ADAL please read Active Directory Authentication Library .NET
The sample also uses SQL LocalDB v11.0. Install the SQL LocalDB prior to working on the sample.
Setting up the environment

We will be working with a basic setup of:
1. DC: Domain controller for the domain in which AD FS will be hosted
2. AD FS Server: The AD FS Server for the domain
3. Development Machine: Machine where we have Visual Studio installed and will be developing our sample
You can, if you want, use only two machines. One for DC/ADFS and the other for developing the sample.
How to setup the domain controller and AD FS is beyond the scope of this article. For additional deployment
information see:
AD DS Deployment
AD FS Deployment
The sample is based on the existing OBO sample against Azure created by Vittorio Bertocci and available here.
Follow the instructions to clone the project on your development machine and create a copy of the sample to start
working with.
Clone or download this repository

From your shell or command line:
git clone https://github.com/Azure-Samples/active-directory-dotnet-webapi-onbehalfof.git

Modifying the sample
As soon as you open the solution WebAPI-OnBehalfOf-DotNet.sln, you will notice that you have two projects in
the solution -
ToDoListClient: This will serve as the OpenID client which the user will be interacting with
ToDoListService: This will be the middle-tier WebServer APP / Service that will be interacting with another
backend WebAPI OBO the authenticated user
As you can see, we will need to add another project later which will act as the resource that will be accessed by the
middle-tier ToDoListService.
Configuring AD FS for the Client and WebServer App
In the current form of the sample, the authentication is configured to be done against Azure AD. We want to
change the authentication mechanism and direct it towards AD FS deployed on-premises. In order to do so, we
need to configure AD FS to recognize the client and WebServer App we have in the sample.
Creating an application group
Open the AD FS management MMC and add a new application group. Select Native-Application-WebAPI
template.
Click on Next and you will be presented with the page for providing information about Client App. Give an
appropriate name to the client App in AD FS. Copy the client Identifier and save it somewhere you can access later
as this will be required in the application config in visual studio.
Note: The Redirect URI can be any arbitrary URI as it is really not used in case of native clients
Click on Next and you will be presented with the page for providing information about WebAPI. Give a suitable
name for the AD FS entry for the WebAPI and enter the redirect URI as the URI you see in Visual Studio for the
ToDoListService
Click on Next and you will see the Choose Access Control Policy Page. Ensure you see "Permit everyone" in the
Policy section.
Click on Next and you will be presented with the configure Application Permissions page. On this page, select the
permitted scopes as openid (selected by default) and user_impersonation. The scope 'user_impersonation' is
necessary to be successfully able to request an on-behalf-of access token from AD FS.
Click next will display the summary page. Go through the rest of the wizard and finish the configuration.
In order to enable on-behalf-of authentication, we need to ensure that AD FS returns an access token with scope
user_impersonation to the client. Modify the claims issuance for ToDoListServiceWebApi to include the following
three custom rules:
@RuleName = "All claims"

c:[]
@RuleName = "Issue open id scope"

=> issue(Type = "https://schemas.microsoft.com/identity/claims/scope", Value = "openid");
@RuleName = "Issue user_impersonation scope"

=> issue(Type = "https://schemas.microsoft.com/identity/claims/scope", Value = "user_impersonation");
Adding ToDoListService as a client in the application group
At this stage we need to make an additional entry in AD FS for the WebServer App to act as a client and not just as
a resource. Open the application group you just created and click on Add Application.
You will be presented with the "Add a new application to MySampleGroup" page. On that page, select "Server
Application or Website" as the standalone application
Click Next and you will be presented with the page to provide application details. Provide a suitable name for the
configuration entry in the Name section. Ensure that the Client Identifier is same as the identifier for the
ToDoListServiceWebAPI
Click on Next and you will be presented with the page to configure the application credentials. Click on "Generate a
shared secret". You will be presented with a secret that is automatically generated. Copy the secret at some location
as this will be required while we configure the ToDoListService in visual studio.
Click on Next and complete the wizard.

Modifying the ToDoListClient code
Modify the Application Config
Go to your the ToDoListClient project in WebAPI-OnBehalfOf-DotNet solution. Open the App.config file and make
the following modifications
Comment the ida:Tenant key entry
For the ida:RedirectURI enter the arbitrary URI that you provided while configuring the
MySampleGroup_ClientApplication in AD FS.
For the ida:ClientID key, provide the client ID identifier that AD FS gave while configuring the
MySampleGroup_ClientApplication.
For the ida:ToDoListResourceID provide the resource ID you gave while configuring the
ToDoListServiceWebApi in AD FS
Comment the key ida:AADInstance
For the ida:ToDoListBaseAddress enter the resource ID of the ToDoListServiceWebApi. This will be used while
calling the ToDoList WebAPI.
Add a key ida:Authority and provide the value as the URI for AD FS.
Your appSettings in App.Config should look similar to this:
<appSettings>

<add key="ida:ClientId" value="c7f7b85c-497c-4589-877f-b17a0bd13398" />
<add key="ida:RedirectUri" value="https://arbitraryuri.com/" />
<add key="ida:TodoListResourceId" value="https://localhost:44321/" />

<add key="ida:TodoListBaseAddress" value="https://localhost:44321" />
<add key="ida:Authority" value="https://fs.anandmsft.com/adfs/"/>
</appSettings>
Modifying the code

MainWindow.xaml.cs
Comment the line reading the tenant information from the application config
//private static string aadInstance = ConfigurationManager.AppSettings["ida:AADInstance"];

//private static string tenant = ConfigurationManager.AppSettings["ida:Tenant"];
Change the value of string authority to
private static string authority = ConfigurationManager.AppSettings["ida:Authority"];
Change the code to read correct values of ToDoListResourceId and ToDoListBaseAddress
private static string todoListResourceId = ConfigurationManager.AppSettings["ida:TodoListResourceId"];

private static string todoListBaseAddress = ConfigurationManager.AppSettings["ida:TodoListBaseAddress"];
In the function MainWindow () change the authcontext initialization as:
authContext = new AuthenticationContext(authority, false);
Adding the backend resource

In order to complete the on-behalf-of flow, you need to create a backend resource that the ToDoListService will be
accessing on-behalf-of the authenticated user. The choice of the backend resource can vary as per the requirement,
but for the purpose of this sample you can create a basic WebAPI.
Right click on solution 'WebAPI-OnBehalfOf-DotNet' in the solution explorer and select Add -> New Project
Choose ASP.NET Web Application template
On the next prompt click on 'Change Authentication'
Select 'Work and School Accounts' and on the right drop down list select 'On-Premises'
Enter the federationmetadata.xml path for your AD FS deployment and provide an App URI (provide any URI
for now, and you will change it later) and click Ok to add the project to the solution.
Right click on Controllers in the solution explorer under the new project created. Select Add -> Controller
In the template selection, select 'Web API 2 Controller - Empty' and click Ok.
Give appropriate controller name
Add the following code in the controller
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Web.Http;
namespace WebAPIOBO.Controllers
{
public class WebAPIOBOController : ApiController
{
public IHttpActionResult Get()
{
return Ok("WebAPI via OBO");
}
}
}
This code will simply return the string when anyone puts a Get request for the WebAPI WebAPIOBO
Adding the new backend WebAPI to AD FS
Open the MySampleGroup application group. Click on Add application and select Web API template and click on
Next.
On the Configure Web API page provide an appropriate name for the WebAPI entry and the identifier. The
identifier should be the value SSL URL from WebAPIOBO project in visual studio (similar to what we did for
BackendWebAPIAdfsAdd).
Continue through the rest of the wizard same as when we configured the ToDoListService WebAPI. At the end
your application group should look like below:
Modifying the ToDoListService code

Modifying the application config
Open the Web.config file
Modify the following keys
KEY VALUE
ida:Audience ID of the ToDoListService as given to AD FS while configuring

the ToDoListService WebAPI, for example,
https://localhost:44321/
ida:ClientID ID of the ToDoListService as given to AD FS while configuring

the ToDoListService WebAPI, for example,
https://localhost:44321/
It is very important that the ida:Audience and
ida:ClientID match each other
ida:ClientSecret This is the secret that AD FS generated when you were

configuring the ToDoListService client in AD FS
ida:ADFSMetadata This is the URL to your AD FS metadata, for e.g.

https://fs.anandmsft.com/federationmetadata/2007-
06/federationmetadata.xml
ida:OBOWebAPIBase This is the base address that we will use to call the backend
API, for e.g. https://localhost:44300
ida:Authority This is the URL for your AD FS service, example

https://fs.anandmsft.com/adfs/
All other ida:XXXXXXX keys in the appsettings node can be commented out or deleted
Change authentication from Azure AD to AD FS
Open the file Startup.Auth.cs
Remove the following code
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
Audience = ConfigurationManager.AppSettings["ida:Audience"],
Tenant = ConfigurationManager.AppSettings["ida:Tenant"],
TokenValidationParameters = new TokenValidationParameters{ SaveSigninToken = true }
});
with
app.UseActiveDirectoryFederationServicesBearerAuthentication(
new ActiveDirectoryFederationServicesBearerAuthenticationOptions
{
MetadataEndpoint = ConfigurationManager.AppSettings["ida:AdfsMetadataEndpoint"],
TokenValidationParameters = new TokenValidationParameters()
{
SaveSigninToken = true,
ValidAudience = ConfigurationManager.AppSettings["ida:Audience"]
}
});
Modifying the ToDoListController

Add reference to System.Web.Extensions. Modify the class members by replacing the code below
//
// The Client ID is used by the application to uniquely identify itself to Azure AD.
// The App Key is a credential used by the application to authenticate to Azure AD.
// The Tenant is the name of the Azure AD tenant in which this application is registered.
// The AAD Instance is the instance of Azure, for example public Azure or Azure China.
// The Authority is the sign-in URL of the tenant.
//
private static string aadInstance = ConfigurationManager.AppSettings["ida:AADInstance"];
private static string tenant = ConfigurationManager.AppSettings["ida:Tenant"];
private static string clientId = ConfigurationManager.AppSettings["ida:ClientId"];
private static string appKey = ConfigurationManager.AppSettings["ida:AppKey"];
//
// To authenticate to the Graph API, the app needs to know the Grah API's App ID URI.
// To contact the Me endpoint on the Graph API we need the URL as well.
//
private static string graphResourceId = ConfigurationManager.AppSettings["ida:GraphResourceId"];
private static string graphUserUrl = ConfigurationManager.AppSettings["ida:GraphUserUrl"];
private const string TenantIdClaimType = "https://schemas.microsoft.com/identity/claims/tenantid";
with
//
// The Client ID is used by the application to uniquely identify itself to Azure AD.
// The client secret is the credentials for the WebServer Client

private static string clientSecret = ConfigurationManager.AppSettings["ida:ClientSecret"];
// Base address of the WebAPI

private static string OBOWebAPIBase = ConfigurationManager.AppSettings["ida:OBOWebAPIBase"];
Modify the claim used for Name

From AD FS we are issuing the Nmae claim but we are not issuing NameIdentifier claim. The sample uses
NameIdentifier to uniquely key in the ToDo items. For simplicity, you can safely remove the NameIdentifier with
Name claim in the code. Find and replace all occurrences of NameIdentifier wiht Name.
Modify Post routine and CallGraphAPIOnBehalfOfUser()
Copy and paste the code below in ToDoListController.cs and replace the code for Post and
CallGraphAPIOnBehalfOfUser
// POST api/todolist
public async Task Post(TodoItem todo)
{
if
(!ClaimsPrincipal.Current.FindFirst("https://schemas.microsoft.com/identity/claims/scope").Value.Contains("user
_impersonation"))
{
throw new HttpResponseException(new HttpResponseMessage { StatusCode = HttpStatusCode.Unauthorized,
ReasonPhrase = "The Scope claim does not contain 'user_impersonation' or scope claim not found" });
}
//
// Call the WebAPIOBO On Behalf Of the user who called the To Do list web API.
//
string augmentedTitle = null;
string custommessage = await CallGraphAPIOnBehalfOfUser();
if (custommessage != null)
{
augmentedTitle = String.Format("{0}, Message: {1}", todo.Title, custommessage);
}
else
{
augmentedTitle = todo.Title;
}
if (null != todo && !string.IsNullOrWhiteSpace(todo.Title))

{
db.TodoItems.Add(new TodoItem { Title = augmentedTitle, Owner =
ClaimsPrincipal.Current.FindFirst(ClaimTypes.Name).Value });
db.SaveChanges();
}
}
public static async Task<string> CallGraphAPIOnBehalfOfUser()

{
string accessToken = null;
AuthenticationResult result = null;
AuthenticationContext authContext = null;
HttpClient httpClient = new HttpClient();
string custommessage = "";
//
// Use ADAL to get a token On Behalf Of the current user. To do this we will need:
// The Resource ID of the service we want to call.
// The current user's access token, from the current request's authorization header.
// The credentials of this application.
// The username (UPN or email) of the user calling the API
//
ClientCredential clientCred = new ClientCredential(clientId, clientSecret);
var bootstrapContext = ClaimsPrincipal.Current.Identities.First().BootstrapContext as
System.IdentityModel.Tokens.BootstrapContext;
string userName = ClaimsPrincipal.Current.FindFirst(ClaimTypes.Upn) != null ?
ClaimsPrincipal.Current.FindFirst(ClaimTypes.Upn).Value :
ClaimsPrincipal.Current.FindFirst(ClaimTypes.Email).Value;
string userAccessToken = bootstrapContext.Token;
UserAssertion userAssertion = new UserAssertion(bootstrapContext.Token, "urn:ietf:params:oauth:grant-
type:jwt-bearer", userName);
string userId = ClaimsPrincipal.Current.FindFirst(ClaimTypes.Name).Value;

authContext = new AuthenticationContext(authority, false);
// In the case of a transient error, retry once after 1 second, then abandon.
// Retrying is optional. It may be better, for your application, to return an error immediately to the
user and have the user initiate the retry.
bool retry = false;
int retryCount = 0;
do
{
retry = false;
try
{
result = await authContext.AcquireTokenAsync(...);
accessToken = result.AccessToken;
}
catch (AdalException ex)
{
if (ex.ErrorCode == "temporarily_unavailable")
{
// Transient error, OK to retry.
retry = true;
retryCount++;
Thread.Sleep(1000);
}
}
} while ((retry == true) && (retryCount < 1));
if (accessToken == null)
{
// An unexpected error occurred.
return (null);
}
// Once the token has been returned by ADAL, add it to the http authorization header, before making the
call to access the To Do list service.
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer",
result.AccessToken);
// Call the WebAPIOBO.

HttpResponseMessage response = await httpClient.GetAsync(OBOWebAPIBase + "/api/WebAPIOBO");
if (response.IsSuccessStatusCode)
{
// Read the response and databind to the GridView to display To Do items.
string s = await response.Content.ReadAsStringAsync();
JavaScriptSerializer serializer = new JavaScriptSerializer();
custommessage = serializer.Deserialize<string>(s);
return custommessage;
}
else
{
custommessage = "Unsuccessful OBO operation : " + response.ReasonPhrase;
}
// An unexpected error occurred calling the Graph API. Return a null profile.
return (null);
}
Running the solution

By default visual studio is configured to run one project when you hit debug to run.
Right click on the solution and select properties.
In the properties page select Multiple Startup projects and change the Action to start for all three entries.
Hit F5 and execute the solution

Click on the sign-in button. You will be prompted to sign-in using AD FS
After you sign-in, add a ToDo item in the list. Behind the scenes we are going to do a Post operation to the
ToDoListService which further will do a Post to the WebAPIOBO web API.
On successful operation you will see that the item has been added to the list with the additional message from the
backend Web API which was accessed using OBO auth-flow.
You can also see the detailed traces on Fiddler. Launch Fiddler and enable HTTPS decryption. You can see that we
make two requests to the /adfs/oautincludes endpoint. In the first interaction, we present the access code to the
token endpoint and get an access token for https://localhost:44321/
In the second interaction with the token endpoint, you can see that we have requested_token_use set as
on_behalf_of and we are using the access token obtained for the middle-tier web service, i.e.
https://localhost:44321/ as the assertion to obtain the on-behalf-of token.
Next Steps
AD FS Development
Build a web application using OpenID Connect with
AD FS 2016
Building on the initial Oauth support in AD FS in Windows Server 2012 R2, AD FS 2016 introduces support for
using the OpenId Connect sign-on.
Pre-requisites
The following are a list of pre-requisites that are required prior to completing this document. This document
assumes that AD FS has been installed and an AD FS farm has been created.
GitHub client tools
AD FS in Windows Server 2016 TP4 or later
Visual Studio 2013 or later.
Create an Application Group in AD FS 2016

The following section describes how to configure the application group in AD FS 2016.
Create Application Group
1. In AD FS Management, right-click on Application Groups and select Add Application Group.
2. On the Application Group Wizard, for the name enter ADFSSSO and under Standalone applications
select the Server application or Website template. Click Next.
3. Copy the Client Identifier value. It will be used later as the value for ida:ClientId in the applications
web.config file.
4. Enter the following for Redirect URI: - https://localhost:44320/. Click Add. Click Next.
5. On the Configure Application Credentials screen, place a check in Generate a shared secret and copy
the secret. Click Next
6. On the Summary screen, click Next.

7. On the Complete screen, click Close.
8. Now, on the right-click the new Application Group and select Properties.
9. On the ADFSSSO Properties click Add application.
10. On the Add a new application to Sample Application select Web API and click Next.
11. On the Configure Web API screen, enter the following for Identifier - https://contoso.com/WebApp.
Click Add. Click Next.
12. On the Choose Access Control Policy screen, select Permit everyone and click Next.
13. On the Configure Application Permissions screen, make sure openid is selected and click Next.

16. On the Sample Application Properties click OK.
Download and Modify MVP App to Authenticate via OpenId Connect

and AD FS
This section discusses how to download the sample Web API and modify it in Visual Studio. We will be using the
Azure AD sample that is here.
To download the sample project, use Git Bash and type the following:
git clone https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect
To Modify the app

1. Open the sample using Visual Studio.
2. Compile the app so that all of the missing NuGets are restored.
3. Open the web.config file. Modify the following values so the look like the following:
<add key="ida:ClientId" value="8219ab4a-df10-4fbd-b95a-8b53c1d8669e" />

<add key="ida:ADFSDiscoveryDoc" value="https://adfs.contoso.com/adfs/.well-known/openid-configuration"
/>

<add key="ida:PostLogoutRedirectUri" value="https://localhost:44320/" />
4. Open the Startup.Auth.cs file and make the following changes:
Comment out the following:
//public static readonly string Authority = String.Format(CultureInfo.InvariantCulture,

aadInstance, tenant);
Tweak the OpenId Connect middleware initialization logic with the following changes:

private static string metadataAddress = ConfigurationManager.AppSettings["ida:ADFSDiscoveryDoc"];
private static string postLogoutRedirectUri =
ConfigurationManager.AppSettings["ida:PostLogoutRedirectUri"];
Farther down, modify the OpenId Connect middleware options as in the following:
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions
{
ClientId = clientId,
//Authority = authority,
MetadataAddress = metadataAddress,
RedirectUri = postLogoutRedirectUri,
PostLogoutRedirectUri = postLogoutRedirectUri
By changing the above we are doing the following:
Instead of using the Authority for communicating data about the trusted issuer, we specify the
discovery doc location directly via MetadataAddress
Azure AD does not enforce the presence of a redirect_uri in the request, but ADFS does. So, we
need to add it here
Verify the app is working

Once the above changes have been made, hit F5. This will bring up the sample page. Click on sign in.
You will be re-directed to the AD FS sign-in page. Go ahead and sign in.
Once this is successful you should see that you are now signed in.
Next Steps
AD FS Development
Build a server side application using OAuth
confidential clients with AD FS 2016
Building on the initial Oauth support in AD FS in Windows Server 2012 R2, AD FS 2016 introduces support for
clients capable of maintaining their own secret, such as an app or service running on a web server. These clients are
known as confidential clients.
Below is a schematic of a web application running on a web server and serving as a confidential client to AD FS:
Pre-requisites
An Azure AD subscription (a free trial is fine)
GitHub client tools
AD FS in Windows Server 2016 TP4 or later
Visual Studio 2013 or later.
Create an Application Group in AD FS 2016

The following section describes how to configure the application group in AD FS 2016.
Create the Application Group
2. On the Application Group Wizard, for the name enter ADFSOAUTHCC and under Standalone
applications select the Server application or Website template. Click Next.
3. Copy the Client Identifier value. It will be used later as the value for ida:ClientId in the applications
web.config file.
4. Enter the following for Redirect URI: - https://localhost:44323. Click Add. Click Next.
5. On the Configure Application Credentials screen, place a check in Generate a shared secretand copy
the secret. This will be used later as the value for ida:AppKey in the applications web.config file. Click Next.
8. Now, on the right-click the new Application Group and select Properties.
9. On ADFSOAUTHCC Properties click Add application.
10. On the Add a new application to Sample Application select Web APIand click Next.
11. On the Configure Web API screen, enter the following for Identifier - https://contoso.com/WebApp.
Click Add. Click Next. This value will be used later for ida:GraphResourceId in the applications web.config
file.
12. On the Choose Access Control Policy screen, select Permit everyone and click Next.
13. On the Configure Application Permissions screen, make sureuser_impersonation is selected and click
Next.

16. On the ADFSOAUTHCC Properties click OK.
Upgrade the database

Visual Studio 2015 was used in creating this walkthrough. In order to get the example working with Visual Studio
2015 you will need to update the database file. Use the following procedure to do this.
This section discusses how to download the sample Web API and upgrade the database in Visual Studio 2015. We
will be using the Azure AD sample that is here.
To download the sample project, use Git Bash and type the following:
git clone https://github.com/Azure-Samples/active-directory-dotnet-webapp-webapi-oauth2-useridentity.git

To upgrade the database file
1. Open the project in Visual Studio, there will be a pop-up telling you that the app requires SQL Server 2102
Express or you will need to upgrade the database. Click Ok.
2. Next compile the application by selecting Build -> Build Solution at the top. This will restore all of the NuGet
packages.
3. Now at the top, select View -> Server Explorer. Once that opens, under Data Connections, right-click
DefaultConnection and select Modify Connection.
4. On Modify Connection, select Advanced.

5. On the Advanced Properties, locate Data Source and use the drop-down to change it from
(LocalDb\v11.0) to (LoaclDB )MSSQLLocalDB.
6. Click Ok. Click Ok. Click Yes to upgrade the database.

7. When this completes, over on the right, copy the value in the box next to Connection String.
8. Now, open the Web.config file and replace the value that is in connectionString with the value you copied
above. Save the Web.config file.
NOTE
The steps above are necessary so that we can get the new connectionString. Otherwise, when we run Update-
Database below it will error out.
9. At the top of Visual Studio, select View -> Other Windows -> Package Manager Console.
10. At the bottom, in the Package Manager Console enter: Enable-Migrations and hit enter.
NOTE
If you get an error that says Enable-Migrations is not recognized as a cmdlet, enter Install-Package EntityFramework
to update the EntityFramework.
11. At the bottom, in the Package Manager Console enter: Add-Migration <anynamehere> and hit enter.
12. At the bottom, in the Package Manager Console enter: Update-Database and hit enter.
Modify the WebApi in Visual Studio
To Modify the Sample Web API
1. Open the sample using Visual Studio.
2. Open the web.config file. Modify the following values:
ida:ClientId - enter the value from #3 above.
ida:AppKey - enter the value from #5 above.
ida:GraphResourceId - enter the value from #11 above.
3. Open the Startup.Auth.cs file under App_Start and make the following changes:
Comment out the following lines:

//public static readonly string Authority = String.Format(CultureInfo.InvariantCulture,
aadInstance, tenant);
Add the following in it's place:
public static readonly string Authority = "https://<your_fsname>/adfs";
where <your_fsname> is replaced with the DNS portion of your federation service url, for example
adfs.contoso.com
4. Open the UserProfileController.cs file and make the following changes:

//authContext = new AuthenticationContext(Startup.Authority, new TokenDbCache(userObjectID));
Replace both occurrences with the following:
authContext = new AuthenticationContext(Startup.Authority, false, new

TokenDbCache(userObjectID));
//authContext = new AuthenticationContext(Startup.Authority);
Replace both occurrences with the following:
authContext = new AuthenticationContext(Startup.Authority, false);
Now comment out all instances of the following:
Uri redirectUri = new Uri(Request.Url.GetLeftPart(UriPartial.Authority.ToString() + "/OAuth");
Replace all occurrences with the following:
Uri redirectUri = new Uri(Request.Url.GetLeftPart(UriPartial.Authority.ToString());

Test the Solution
In this section we will test the confidential client solution. Use the following procedure to test the solution.
Testing the confidential client solution
1. At the top of Visual Studio, make sure Internet Explorer is selected and click the green arrow.
2. Once the ASP.Net page comes up, click on Register.

3. Enter a username and password and then click Register. This creates a local account in the SQL database.
4. Notice now, the ASP.NET site says Hello bsimon!. Click Profile.
5. This brings up a page without any information and says that we must click here to sign-in. Click here.
6. You will now be prompted to sign-in to AD FS.

Next Steps
AD FS Development
Single log-out for OpenID Connect with AD FS
Overview
Building on the initial Oauth support in AD FS in Windows Server 2012 R2, AD FS 2016 introduced the support
for OpenId Connect sign-on. With KB4038801, AD FS 2016 now supports single log-out for OpenId Connect
scenarios. This article provides an overview of the single log-out for OpenId Connect scenario and provides
guidance on how to use it for your OpenId Connect applications in AD FS.
Discovery doc
OpenID Connect uses a JSON document called a "Discovery document" to provide details about configuration.
This includes URIs of the authentication, token, userinfo, and public-endpoints. The following is an example of the
discovery doc.
{
"issuer":"https://fs.fabidentity.com/adfs",
"authorization_endpoint":"https://fs.fabidentity.com/adfs/oauth2/authorize/",
"token_endpoint":"https://fs.fabidentity.com/adfs/oauth2/token/",
"jwks_uri":"https://fs.fabidentity.com/adfs/discovery/keys",
"token_endpoint_auth_methods_supported":
["client_secret_post","client_secret_basic","private_key_jwt","windows_client_authentication"],
"response_types_supported":["code","id_token","code id_token","id_token token","code token","code id_token
token"],
"response_modes_supported":["query","fragment","form_post"],
"grant_types_supported":
["authorization_code","refresh_token","client_credentials","urn:ietf:params:oauth:grant-type:jwt-
bearer","implicit","password","srv_challenge"],
"subject_types_supported":["pairwise"],
"scopes_supported":
["allatclaims","email","user_impersonation","logon_cert","aza","profile","vpn_cert","winhello_cert","openid"],
"id_token_signing_alg_values_supported":["RS256"],
"token_endpoint_auth_signing_alg_values_supported":["RS256"],
"access_token_issuer":"http://fs.fabidentity.com/adfs/services/trust",
"claims_supported":
["aud","iss","iat","exp","auth_time","nonce","at_hash","c_hash","sub","upn","unique_name","pwd_url","pwd_exp",
"sid"],
"microsoft_multi_refresh_token":true,
"userinfo_endpoint":"https://fs.fabidentity.com/adfs/userinfo",
"capabilities":[],
"end_session_endpoint":"https://fs.fabidentity.com/adfs/oauth2/logout",
"as_access_token_token_binding_supported":true,
"as_refresh_token_token_binding_supported":true,
"resource_access_token_token_binding_supported":true,
"op_id_token_token_binding_supported":true,
"rp_id_token_token_binding_supported":true,
"frontchannel_logout_supported":true,
"frontchannel_logout_session_supported":true
}
The following additional values will be available in the discovery doc to indicate support for Front Channel Logout:
frontchannel_logout_supported: value will be 'true'
frontchannel_logout_session_supported: value will be 'true'.
end_session_endpoint: this is the OAuth logout URI that the client can use to initiate logout on the server.
AD FS server configuration
The AD FS property EnableOAuthLogout will be enabled by default. This property tells the AD FS server to
browse for the URL (LogoutURI) with the SID to initiate logout on the client. If you do not have KB4038801
installed you can use the following PowerShell command:
Set-ADFSProperties -EnableOAuthLogout $true
NOTE
EnableOAuthLogout parameter will be marked as obsolete after installing KB4038801. EnableOAUthLogout will always be
true and will have no impact on the logout functionality.
NOTE
frontchannel_logout is supported only after installtion of KB4038801
Client configuration
Client needs to implement a url which 'logs off' the logged in user. Administrator can configure the LogoutUri in
the client configuration using the following PowerShell cmdlets.
(Add | Set)-AdfsNativeApplication
(Add | Set)-AdfsServerApplication
(Add | Set)-AdfsClient
Set-AdfsClient -LogoutUri <url>
The LogoutUri is the url used by AF FS to "log off" the user. For implementing the LogoutUri , the client needs to
ensure it clears the authentication state of the user in the application, for example, dropping the authentication
tokens that it has. AD FS will browse to that URL, with the SID as the query parameter, signaling the relying party
/ application to log off the user.
1. OAuth token with session ID: AD FS includes session id in the OAuth token at the time of id_token token
issuance. This will be used later by AD FS to identify the relevant SSO cookies to be cleaned up for the user.
2. User initiates logout on App1: The user can initiate a logout from any of the logged in applications. In this
example scenario, a user initiates a logout from App1.
3. Application sends logout request to AD FS: After the user initiates logout, the application sends a GET
request to end_session_endpoint of AD FS. The application can optionally include id_token_hint as a parameter
to this request. If id_token_hint is present, AD FS will use it in conjunction with session ID to figure out which
URI the client should be redirected to after logout (post_logout_redirect_uri). The post_logout_redirect_uri
should be a valid uri registered with AD FS using the RedirectUris parameter.
4. AD FS sends sign-out to logged-in clients: AD FS uses the session identifier value to find the relevant
clients the user is logged in to. The identified clients are sent request on the LogoutUri registered with AD FS to
initiate a logout on the client side.
FAQs
Q: I do not see the frontchannel_logout_supported and frontchannel_logout_session_supported parameters in the
discovery doc.
A: Ensure that you have KB4038801 installed on all the AD FS servers. Refer to Single log-out in Server 2016 with
KB4038801.
Q: I have configured single logout as directed, but user stays logged-in on other clients.
A: Ensure that LogoutUri is set for all the clients where the user is logged-in. Also, AD FS does a best-case attempt
to send the sign-out request on the registered LogoutUri . Client must implement logic to handle the request and
take action to sign-out the user from application.
Q: If after logout, one of the clients goes back to AD FS with a valid refresh token, will AD FS issue an access
token?
A: Yes. It is the responsibility of the client application to drop all authenticated artifacts after a sign-out request was
received at the registered LogoutUri .
Next Steps
AD FS Development
Build a single page web application using OAuth and
ADAL.JS with AD FS 2016
This walkthrough provides instruction for authenticating against AD FS using ADAL for JavaScript securing an
AngularJS based single page application, implemented with an ASP.NET Web API backend.
In this scenario, when the user signs in, the JavaScript front end uses Active Directory Authentication Library for
JavaScript (ADAL.JS ) and the implicit authorization grant to obtain an ID token (id_token) from Azure AD. The
token is cached and the client attaches it to the request as the bearer token when making calls to its Web API back
end, which is secured using the OWIN middleware.
WARNING: The example that you can build here is for educational purposes only. These instructions are for the
simplest, most minimal implementation possible to expose the required elements of the model. The example
may not include all aspects of error handling and other relate functionality.
NOTE
This walkthrough is applicable only to AD FS Server 2016 and higher
Overview
In this sample we will be creating an authentication flow where a single page application client will be
authenticating against AD FS to secure access to the WebAPI resources on the backend. Below is the overall
authentication flow
When using a single page application, the user navigates to a starting location, from where starting page and a
collection of JavaScript files and HTML views are loaded. You need to configure the Active Directory Authentication
Library (ADAL ) to know the critical information about your application, i.e. the AD FS instance, client ID, so that it
can direct the authentication to your AD FS.
If ADAL sees a trigger for authentication, it uses the information provided by the application and directs the
authentication to your AD FS STS. The single page application, which is registered as a public client in AD FS, is
automatically configured for implicit grant flow. The authorization request results in an ID token that is returned
back to the application via a #fragment. Further calls to the backend WebAPI will carry this ID token as the bearer
token in the header to gain access to the WebAPI.
Setting up the development box

This walk-through uses Visual Studio 2015. The project uses ADAL JS library. To learn about ADAL please read
Active Directory Authentication Library .NET.
Setting up the environment

For this walkthrough we will be using a basic setup of:
1. DC: Domain controller for the domain in which AD FS will be hosted
2. AD FS Server: The AD FS Server for the domain
3. Development Machine: Machine where we have Visual Studio installed and will be developing our sample
You can, if you want, use only two machines. One for DC/AD FS and the other for developing the sample.
How to setup the domain controller and AD FS is beyond the scope of this article. For additional deployment
information see:
AD DS Deployment
AD FS Deployment
Clone or download this repository

We will be using the sample application created for integrating Azure AD into an AngularJS single page app and
modifying it to instead secure the backend resource by using AD FS.
From your shell or command line:
git clone https://github.com/Azure-Samples/active-directory-angularjs-singlepageapp.git
About the Code

The key files containing authentication logic are the following:
App.js - injects the ADAL module dependency, provides the app configuration values used by ADAL for driving
protocol interactions with AAD and indicates whihc routes should not be accessed without previous authentication.
index.html - contains a reference to adal.js
HomeController.js- shows how to take advantage of the login() and logOut() methods in ADAL.
UserDataController.js - shows how to extract user information from the cached id_token.
Startup.Auth.cs - contains configuration for the WebAPI to use Active Directory Federation Service for bearer
authentication.
Registering the public client in AD FS

In the sample, the WebAPI is configured to listen at https://localhost:44326/. The application group Web browser
accessing a web application can be used for configuring implicit grant flow application.
1. Open the AD FS management console and click on Add Application Group. In the Add Application
Group Wizard enter the name of the application, description and select the Web browser accessing a
web application template from the Client-Server applications section as shown below
2. On the next page Native application, provide the application client identifier and redirect URI as shown
below
3. On the next page Apply Access Control Policy leave the permissions as Permit everyone
4. The summary page should look similar to below
5. Click on Next to complete the addition of the application group and close the wizard.
Modifying the sample

Configure ADAL JS
Open the app.js file and change the adalProvider.init definition to:
adalProvider.init(
{
instance: 'https://fs.contoso.com/', // your STS URL
tenant: 'adfs', // this should be adfs
clientId: 'https://localhost:44326/', // your client ID of the
//cacheLocation: 'localStorage', // enable this for IE, as sessionStorage does not work for localhost.
},
$httpProvider
);
CONFIGURATION DESCRIPTION
instance Your STS URL, e.g. https://fs.contoso.com/
tenant Keep it as 'adfs'
clientID This is the client ID you specified while configuring the public
client for your single page application
Configure WebAPI to use AD FS

Open the Startup.Auth.cs file in the sample and add the following at the beginning:
using System.IdentityModel.Tokens;
remove:
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
Audience = ConfigurationManager.AppSettings["ida:Audience"],
Tenant = ConfigurationManager.AppSettings["ida:Tenant"]
});
and add:
{
{
ValidAudience = ConfigurationManager.AppSettings["ida:Audience"],
ValidIssuer = ConfigurationManager.AppSettings["ida:Issuer"]
}
}
);
ValidAudience This configures the value of 'audience' that will be checked

against in the token
ValidIssuer This configures the value of 'issuer that will be checked against
in the token
MetadataEndpoint This points to the metadata information of your STS
Add application configuration for AD FS

Change the appsettings as below:
<appSettings>
<add key="ida:Audience" value="https://localhost:44326/" />
<add key="ida:AdfsMetadataEndpoint" value="https://fs.contoso.com/federationmetadata/2007-
06/federationmetadata.xml" />
<add key="ida:Issuer" value="https://fs.contoso.com/adfs" />
</appSettings>
Running the solution

Clean the solution, rebuild the solution and run it. If you want to see detailed traces, launch Fiddler and enable
HTTPS decryption.
The browser will load the SPA and you will be presented with the following screen:
Click on Login. The ToDo List will trigger the authentication flow and ADAL JS will direct the authentication to AD
FS
In Fiddler you can see the token being returned as part of the URL in the # fragment.
You will be able to now call the backend API to add ToDo List items for the logged-in user:
Next Steps
AD FS Development
Build a native client application using OAuth public
clients with AD FS 2016
Overview
This article shows how to build a native application that interacts with a Web API protected by AD FS 2016.
1. The .Net TodoListClient WPF application uses the Active Directory Authentication Library (ADAL ) to obtain a
JWT access token from Azure Active Directory (Azure AD ) through the OAuth 2.0 protocol
2. The access token is used as a bearer token to authenticate the user when calling the /todolist endpoint of the
TodoListService web API. We will be using the application example for Azure AD here and then modify it for
AD FS 2016.
Pre-requisites
GitHub client tools
AD FS in Windows Server 2016
Visual Studio 2013 or later
Creating the sample walkthrough
Create the application group in AD FS
2. On the Application Group Wizard, for the name enter any name you prefer, e.g. NativeToDoListAppGroup.
Select the Native application accessing a web API template . Click Next.
3. On the Native application page, note the identifier generated by AD FS. This is the id with which AD FS
will recognize the public client app. Copy the Client Identifier value. It will be used later as the value for
ida:ClientId in the application code. If you wish you can give any custom identifier here. The redirect URI is
any arbitrary value, example, put https://ToDoListClient
4. On the Configure Web API page, set the identifier value for the Web API. For this example, this should be
the value of the SSL URL where the Web App is supposed to be running. You can get this value by clicking
on the properties of the TooListServer project in the solution. This will be later used as the
todo:TodoListResourceId value in App.config file of the native client application and also as the
todo:TodoListBaseAddress.
5. Go through the Apply Access Control Policy and Configure Application Permissions with the default
values in place. The summary page should look like below.
Click next and then complete the wizard.

Add the NameIdentifier claim to the list of claims issued
The demo application uses the value in NameIdentifier claim at various places. Unlike Azure AD, AD FS does not
issue a NameIdentifier claim by default. Therefore, we need to add a claim rule to issue the NameIdentifier claim
so that the application can use the correct value. In this example, the given name of the user is issued as the
NameIdentifier value for the user in the token. To configure the claim rule, open the application group just created,
and double click on the Web API. Select the Issuance Transform Rules tab and then click on Add Rule button. In
the type of claim rule, choose Custom claim rule and then add the claim rule as shown below.
Modify the application code

Modify ToDoListClient
This project in the solution represents the native client application. We need to make sure that the client application
knows:
1. Where to go to get the user authenticated when required?
2. What is the ID that client needs to provide to the authenticating authority (AD FS )?
3. What is the ID of the resource that we are asking the access token for?
4. What is the base address of the Web API?
The following code changes are needed in order to get the above information to the native client application.
App.config
Add the key ida:Authority with the value depicting the AD FS service, example, https://fs.contoso.com/adfs/
Modify ida:ClientId key with the value from the Native Application page during the Application Group
creation in AD FS. For ex, 3f07368b-6efd-4f50-a330-d93853f4c855
Modify the todo:TodoListBaseAddress to the base address of the Web API, e.g. https://localhost:44321/
Set the value of ida:RedirectUri to the value you put in the Native Application page during Add Application
Group in AD FS.
For ease of reading you can remove / comment the key for ida:Tenant and ida:AADInstance.
MainWindow.xaml.cs
Remove the line for aadInstance
Add the value for authority as below
Delete the line for creating the authority value from aadInstance and tenant
private static string authority = String.Format(CultureInfo.InvariantCulture, aadInstance, tenant);
In the function MainWindow, change the authContext instantiation as
authContext = new AuthenticationContext(authority,false);
ADAL does not support validating AD FS as authority and therefore we have to pass a false value flag for
validateAuthority parameter.
Modify TodoListService
Two files need changes in this project – Web.config and Startup.Auth.cs. Web.Config changes are required to get
the correct values of the parameters. Startup.Auth.cs changes are required to set the WebAPI to authenticate
against AD FS rather than Azure AD.
Web.config
Delete the key ida:Tenant as we don’t need it
Add the key for ida:Authority with value indicating the FQDN of the federation service, example,
https://fs.contoso.com/adfs/
Modify key ida:Audience with the value of the Web API identifier that you specified in the Configure Web
API page during Add Application Group in AD FS.
Add key ida:AdfsMetadataEndpoint with value corresponding to the federation metadata URL of the AD FS
service, for ex: https://fs.contoso.com/federationmetadata/2007-06/federationmetadata.xml
Startup.Auth.cs
Modify the ConfigureAuth function as below
public void ConfigureAuth(IAppBuilder app)

{
{
{
SaveSigninToken = true,
ValidAudience = ConfigurationManager.AppSettings["ida:Audience"]
}
});
}
Essentially, we are configuring the authentication to use AD FS and further provide information about the AD FS
metadata, and to validate the token, the audience claim should be the value expected by the Web API. Running the
application
1. On the solution NativeClient-DotNet, right click and go to properties. Change the Startup Project as shown
below to Multiple Startup projects and set both TodoListClient and TodoListService to Start.
2. Press F5 button or select Debug > Continue in the menu bar. This will launch both the native application
and the WebAPI. Click on Sign-in button on the native application and it will pop-up an interactive logon
from AD AL and redirect to your AD FS service. Enter the credentials of a valid user.
In this step, the native application redirected to AD FS and got an ID token and an access token for the Web API
1. Enter a to do item in the text box and click on Add item. In this step, the application reaches out to the Web API
to add the to do item, and in order to do so, presents the access token to the WebAPI obtained from AD FS. The
Web API matches the audience value to make sure the token is intended for it and verifies the token signature
using the info from the federation metadata.
Next Steps
AD FS Development
AD FS 2016 Operations
This document contains a list of all of the documentation operations for AD FS for Windows Server 2016. This
Access Control Policies in AD FS
Additional Authentication methods in AD FS 2019
AD FS Prompt login parameter support
AD FS 2016 Single Sign On Settings
AD FS Paginated sign-in
Compound authentication and AD DS claims in AD FS
Configure AD FS Extranet Soft Lockout Protection
Configure AD FS Extranet Smart Lockout Protection
Configure AD FS Extranet Banned IPs
Configure AD FS for User Certificate Authentication
Configure AD FS to authenticate users stored in LDAP directories
Configure Additional Authentication Methods for AD FS
Configure Device-based Conditional Access on-Premises
Configure intranet forms-based authentication for devices that do not support WIA
Create a Non-Claims Aware Relying Party Trust
Device Authentication Controls in AD FS
Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company
Applications
Controlling Access to Organizational Data with Active
Directory Federation Services
This document provides an overview of access control with AD FS across on premises, hybrid and cloud scenarios.
AD FS and Conditional Access to On Premises Resources

Since the introduction of Active Directory Federation Services, authorization policies have been available to restrict
or allow users access to resources based on attributes of the request and the resource. As AD FS has moved from
version to version, how these policies are implemented has changed. For detailed information on access control
features by version see:
Access Control Policies in AD FS in Windows Server 2016
Access control in AD FS in Windows Server 2012 R2
AD FS and Conditional Access in a Hybrid Organization

AD FS provides the on premises component of conditional access policy in a hybrid scenario. AD FS based
authorization rules should be used for non Azure AD resources, such as on premises applications federated directly
to AD FS. The cloud component is provided by Azure AD Conditional Access. Azure AD Connect provides the
control plane connecting the two.
For example, when you register devices with Azure AD for conditional access to cloud resources, the Azure AD
Connect device write back capability makes device registration information available on premises for AD FS
policies to consume and enforce. This way, you have a consistent approach to access control policies for both on
premises and cloud resources.
The evolution of Client Access Policies for Office 365

Many of you are using client access policies with AD FS to limit access to Office 365 and other Microsoft Online
services based on factors such as the location of the client and the type of client application being used.
Client access policies in Windows Server 2012 R2 AD FS
Client access policies in AD FS 2.0
Some examples of these policies include:
Block all extranet client access to Office 365
Block all extranet client access to Office 365, except for devices accessing Exchange Online for Exchange Active
Sync
Often the underlying need behind these policies is to mitigate risk of data leakage by ensuring only authorized
clients, applications that do not cache data, or devices that can be disabled remotely can get access to resources.
While the above documented policies for AD FS work in the specific scenarios documented, they have limitations
because they depend on client data that is not consistently available. For example, the identity of the client
application has only been available for Exchange Online based services and not for resources such as SharePoint
Online, where the same data might be accessed via the browser or a �thick client� such as Word or Excel. Also
AD FS is unaware of the resource within Office 365 being accessed, such as SharePoint Online or Exchange Online.
To address these limitations and provide a more robust way to use polices to manage access to business data in
Office 365 or other Azure AD based resources, Microsoft has introduced Azure AD Conditional Access. Azure AD
Conditional Access policies can be configured for a specific resource, or for any or all resources within Office 365,
SaaS or custom applications in Azure AD. These policies pivot on device trust, location, and other factors.
To find out more about Azure AD Conditional Access, see Conditional Access in Azure Active Directory
A key change enabling these scenarios is modern authentication, a new way of authenticating users and devices
that works the same way across Office clients, Skype, Outlook, and browsers.
Next Steps
For more information on controlling access across the cloud and on premises see:
Conditional Access in Azure Active Directory
Access Control Policies in AD FS 2016
Access Control Policies in Windows Server 2016 AD
FS
Access Control Policy Templates in AD FS

Active Directory Federation Services now supports the use of access control policy templates. By using access
control policy templates, an administrator can enforce policy settings by assigning the policy template to a group of
relying parties (RPs). Administrator can also make updates to the policy template and the changes will be applied
to the relying parties automatically if there is no user interaction needed.
What are Access Control Policy Templates?

The AD FS core pipeline for policy processing has three phases: authentication, authorization and claim issuance.
Currently, AD FS administrators have to configure a policy for each of these phases separately. This also involves
understanding the implications of these policies and if these policies have inter-dependency. Also, administrators
have to understand the claim rule language and author custom rules to enable some simple/common policy (ex.
block external access).
What access control policy templates do is replace this old model where administrators have to configure Issuance
Authorization Rules using claims language. The old PowerShell cmdlets of issuance authorization rules still apply
but it is mutually exclusive of the new model. Administrators can choose either to use the new model or the old
model. The new model allows administrators to control when to grant access, including enforcing multi-factor
authentication.
Access control policy templates use a permit model. This means by default, no one has access and that access must
be explicitly granted. However, this is not just an all or nothing permit. Administrators can add exceptions to the
permit rule. For example, an administrator may wish to grant access based on a specific network by selecting this
option and specifying the IP address range. But the administrator may add and exception, for instance, the
administrator may add an exception from a specific network and specify that IP address range.
Built-in access control policy templates vs custom access control policy
templates
AD FS includes several built-in access control policy templates. These target some common scenarios which have
the same set of policy requirements, for example client access policy for Office 365. These templates cannot be
modified.
To provide increased flexibility to address your business needs, administrators can create their own access policy
templates. These can be modified after creation and changes to custom policy template will apply to all the RPs
which are controlled by those policy templates. To add a custom policy template simply click Add Access Control
Policy from within AD FS management.
To create a policy template, an administrator needs to first specify under which conditions a request will be
authorized for token issuance and/or delegation. Condition and action options are shown in the table below.
Conditions in bold can be further configured by the administrator with different or new values. Admin can also
specify exceptions if there is any. When a condition is met, a permit action will not be triggered if there is an
exception specified and the incoming request matches the condition specified in the exception.
PERMIT USERS EXCEPT
From specific network From specific network
From specific groups
From devices with specific trust levels
With specific claims in the request
From specific groups From specific network

PERMIT USERS EXCEPT
From devices with specific trust levels From specific network
With specific claims in the request From specific network
And require multi-factor authentication From specific network
If an administrator selects multiple conditions, they are of AND relationship. Actions are mutually exclusive and for
one policy rule you can only choose one action. If admin selects multiple exceptions, they are of an OR relationship.
A couple of policy rule examples are shown below:
POLICY POLICY RULES
Extranet access requires MFA Rule #1
All users are permitted from extranet
and with MFA
Permit
Rule#2
from intranet
Permit
POLICY POLICY RULES
External access are not permitted except non-FTE Rule #1
Intranet access for FTE on workplace joined device are From extranet
permitted
and from non-FTE group
Permit
Rule #2
from intranet
and from workplace joined device
and from FTE group
Permit
Extranet access requires MFA except "service admin" Rule #1
All users are permitted to access from extranet
and with MFA
Permit
Except service admin group
Rule #2
always
Permit
POLICY POLICY RULES
non-work place joined device accessing from extranet requires Rule #1

MFA
from intranet
Permit AD fabric for intranet and extranet access
And from AD Fabric group
Permit
Rule #2
from extranet
and from non-workplace joined device
and from AD Fabric group
and with MFA
Permit
Rule #3
from extranet
and from workplace joined device
and from AD Fabric group
Permit
Parameterized policy template vs non-parameterized policy template

Access control policies can be
A parameterized policy template is a policy template that has parameters. An Administrator needs to input the
value for those parameters when assigning this template to RPs.An administrator cannot make changes to
parameterized policy template after it has been created. An example of a parameterized policy is the built-in policy,
Permit specific group. Whenever this policy is applied to an RP, this parameter needs to be specified.
A non-parameterized policy template is a policy template that does not have parameters. An administrator can
assign this template to RPs without any input needed and can make changes to a non-parameterized policy
template after it has been created. An example of this is the built-in policy, Permit everyone and require MFA.
How to create a non-parameterized access control policy

To create a non-parameterized access control policy use the following procedure
To create a non-parameterized access control policy
1. From AD FS Management on the left select Access Control Policies and on the right click Add Access
Control Policy.
2. Enter a name and a description. For example: Permit users with authenticated devices.
3. Under Permit access if any of the following rules are met, click Add.
4. Under permit, place a check in the box next to from devices with specific trust level
5. At the bottom, select the underlined specific
6. From the window that pops-up, select authenticated from the drop-down. Click Ok.
7. Click Ok. Click Ok.

How to create a parameterized access control policy
To create a parameterized access control policy use the following procedure
To create a parameterized access control policy
Control Policy.
2. Enter a name and a description. For example: Permit users with a specific claim.
4. Under permit, place a check in the box next to with specific claims in the request
6. From the window that pops-up, select Parameter specified when the access control policy is assigned.
Click Ok.
How to create a custom access control policy with an exception

To create a access control policy with an exception use the following procedure.
To create a custom access control policy with an exception
Control Policy.
2. Enter a name and a description. For example: Permit users with authenticated devices but not managed.
4. Under permit, place a check in the box next to from devices with specific trust level
6. From the window that pops-up, select authenticated from the drop-down. Click Ok.
7. Under except, place a check in the box next to from devices with specific trust level
8. At the bottom under except, select the underlined specific
9. From the window that pops-up, select managed from the drop-down. Click Ok.
How to create a custom access control policy with multiple permit

conditions
To create a access control policy with multiple permit conditions use the following procedure
To create a parameterized access control policy
Control Policy.
2. Enter a name and a description. For example: Permit users with a specific claim and from specific group.
4. Under permit, place a check in the box next to from a specific group and with specific claims in the
request
5. At the bottom, select the underlined specific for the first condition, next to groups
6. From the window that pops-up, select Parameter specified when the policy is assigned. Click Ok.
7. At the bottom, select the underlined specific for the second condition, next to claims
8. From the window that pops-up, select Parameter specified when the access control policy is assigned.
Click Ok.
How to assign an access control policy to a new application

Assigning an access control policy to a new application is pretty straight forward and has now been integrated into
the wizard for adding an RP. From the Relying Party Trust Wizard you can select the access control policy that you
wish to assign. This is a requirement when creating a new relying party trust.
How to assign an access control policy to an existing application
Assigning an access control policy to a existing application simply select the application from Relying Party Trusts
and on the right click Edit Access Control Policy.
From here you can select the access control policy and apply it to the application.
See Also
AD FS Operations
Access Control Policies in Windows Server 2012 R2
and Windows Server 2012 AD FS
Applies To: Windows Server 2012 R2 and Windows Server 2012
The policies described in this article make use of two kinds of claims
1. Claims AD FS creates based on information the AD FS and Web Application proxy can inspect and verify,
such as the IP address of the client connecting directly to AD FS or the WAP.
2. Claims AD FS creates based on information forwarded to AD FS by the client as HTTP headers
Important: The policies as documented below will block Windows 10 domain join and sign on scenarios that
require access to the following additional endpoints
AD FS endpoints required for Windows 10 Domain Join and sign on

[federation service name]/adfs/services/trust/2005/windowstransport
[federation service name]/adfs/services/trust/13/windowstransport
[federation service name]/adfs/services/trust/2005/usernamemixed
[federation service name]/adfs/services/trust/13/usernamemixed
[federation service name]/adfs/services/trust/2005/certificatemixed
[federation service name]/adfs/services/trust/13/certificatemixed
To resolve, update any policies that deny based on the endpoint claim to allow exception for the endpoints above.
For example, the rule below:
c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[Type ==
"http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value != "/adfs/ls/"]
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = " DenyUsersWithClaim");
would be updated to:

c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[Type ==
"http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value != "(/adfs/ls/)|
(/adfs/services/trust/2005/windowstransport)|(/adfs/services/trust/13/windowstransport)|
(/adfs/services/trust/2005/usernamemixed)|(/adfs/services/trust/13/usernamemixed)|
(/adfs/services/trust/2005/certificatemixed)|(/adfs/services/trust/13/certificatemixed)"] => issue(Type =
"http://schemas.microsoft.com/authorization/claims/deny", Value = " DenyUsersWithClaim");
NOTE
Claims from this category should only be used to implement business policies and not as security policies to protect access to
your network. It is possible for unauthorized clients to send headers with false information as a way to gain access.
The policies described in this article should always be used with another authentication method, such as username
and password or multi factor authentication.
Client Access Policies Scenarios

SCENARIO DESCRIPTION
Scenario 1: Block all external access to Office 365 Office 365 access is allowed from all clients on the internal
corporate network, but requests from external clients are
denied based on the IP address of the external client.
Scenario 2: Block all external access to Office 365 except Office 365 access is allowed from all clients on the internal
Exchange ActiveSync corporate network, as well as from any external client devices,
such as smart phones, that make use of Exchange ActiveSync.
All other external clients, such as those using Outlook, are
blocked.
Scenario 3: Block all external access to Office 365 except Blocks external access to Office 365, except for passive
browser-based applications (browser-based) applications such as Outlook Web Access or
SharePoint Online.
Scenario 4: Block all external access to Office 365 except for This scenario is used for testing and validating client access
designated Active Directory groups policy deployment. It blocks external access to Office 365 only
for members of one or more Active Directory group. It can
also be used to provide external access only to members of a
group.
Enabling Client Access Policy

To enable client access policy in AD FS in Windows Server 2012 R2, you must update the Microsoft Office 365
Identity Platform relying party trust. Choose one of the example scenarios below to configure the claim rules on the
Microsoft Office 365 Identity Platform relying party trust that best meets the needs of your organization.
Scenario 1: Block all external access to Office 365
This client access policy scenario allows access from all internal clients and blocks all external clients based on the
IP address of the external client. You can use the following procedures to add the correct Issuance Authorization
rules to the Office 365 relying party trust for your chosen scenario.
To c r e a t e r u l e s t o b l o c k a l l e x t e r n a l a c c e ss t o O ffi c e 3 6 5
1. From Server Manager, click Tools, then click AD FS Management.

2. In the console tree, under AD FS\Trust Relationships, click Relying Party Trusts, right-click the Microsoft
Office 365 Identity Platform trust, and then click Edit Claim Rules.
3. In the Edit Claim Rules dialog box, select the Issuance Authorization Rules tab, and then click Add Rule
to start the Claim Rule Wizard.
Rule, and then click Next.
5. On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “If
there is any IP claim outside the desired range, deny”. Under Custom rule, type or paste the following claim
rule language syntax (replace the value above for “x-ms-forwarded-client-ip” with a valid IP expression):
c1:[Type == " http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && c2:
[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~
"^(?!192\.168\.1\.77|10\.83\.118\.23)"] => issue(Type =
"http://schemas.microsoft.com/authorization/claims/deny", Value = " DenyUsersWithClaim");
6. Click Finish. Verify that the new rule appears in the Issuance Authorization Rules list before to the default
Permit Access to All Users rule (the Deny rule will take precedence even though it appears earlier in the
list). If you do not have the default permit access rule, you can add one at the end of your list using the claim
rule language as follows:
c:[] => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");
7. To save the new rules, in the Edit Claim Rules dialog box, click OK. The resulting list should look like the
following.
Scenario 2: Block all external access to Office 365 except Exchange ActiveSync
The following example allows access to all Office 365 applications, including Exchange Online, from internal clients
including Outlook. It blocks access from clients residing outside the corporate network, as indicated by the client IP
address, except for Exchange ActiveSync clients such as smart phones.
To c r e a t e r u l e s t o b l o c k a l l e x t e r n a l a c c e ss t o O ffi c e 3 6 5 e x c e p t Ex c h a n g e A c t i v e Sy n c

there is any IP claim outside the desired range, issue ipoutsiderange claim”. Under Custom rule, type or
paste the following claim rule language syntax (replace the value above for “x-ms-forwarded-client-ip” with a
valid IP expression):
c1:[Type == " http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && c2:
"^(?!192\.168\.1\.77|10\.83\.118\.23)"] => issue(Type = "http://custom/ipoutsiderange", Value = "true");
6. Click Finish. Verify that the new rule appears in the Issuance Authorization Rules list.
7. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to
start the Claim Rule Wizard again.
there is an IP outside the desired range AND there is a non-EAS x-ms-client-application claim, deny”. Under
Custom rule, type or paste the following claim rule language syntax:
`c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[Type ==

"http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value !=
"Microsoft.Exchange.ActiveSync"] => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny",
Value = "DenyUsersWithClaim");`
4. On the Configure Rule page, under Claim rule name, type the display name for this rule, for example
“check if application claim exists”. Under Custom rule, type or paste the following claim rule language
syntax:
NOT EXISTS([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-

application"]) => add(Type = "http://custom/xmsapplication", Value = "fail");
“deny users with ipoutsiderange true and application fail”. Under Custom rule, type or paste the following
claim rule language syntax:
c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[Type == "http://custom/xmsapplication",
Value == "fail"] => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value =
"DenyUsersWithClaim");
1. Click Finish. Verify that the new rule appears immediately below the previous rule and before to the default
Permit Access to All Users rule in the Issuance Authorization Rules list (the Deny rule will take precedence even
though it appears earlier in the list).
If you do not have the default permit access rule, you can add one at the end of your list using the claim rule
language as follows:
following.
Scenario 3: Block all external access to Office 365 except browser-based applications
To c r e a t e r u l e s t o b l o c k a l l e x t e r n a l a c c e ss t o O ffi c e 3 6 5 e x c e p t b r o w se r- b a se d a p p l i c a t i o n s

there is any IP claim outside the desired range, issue ipoutsiderange claim”. Under Custom rule, type or
paste the following claim rule language syntax(replace the value above for “x-ms-forwarded-client-ip” with a
c1:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && c2:
"^(?!192\.168\.1\.77|10\.83\.118\.23)"] => issue(Type = "http://custom/ipoutsiderange", Value = "true");
there is an IP outside the desired range AND the endpoint is not /adfs/ls, deny”. Under Custom rule, type or
paste the following claim rule language syntax:
`c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[Type ==

"http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value != "/adfs/ls/"]
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = " DenyUsersWithClaim");`
1. Click Finish. Verify that the new rule appears in the Issuance Authorization Rules list before to the default
Permit Access to All Users rule (the Deny rule will take precedence even though it appears earlier in the
list).
following.
Scenario 4: Block all external access to Office 365 except for designated Active Directory groups
The following example enables access from internal clients based on IP address. It blocks access from clients
residing outside the corporate network that have an external client IP address, except for those individuals in a
specified Active Directory Group.Use the following steps to add the correct Issuance Authorization rules to the
Microsoft Office 365 Identity Platform relying party trust using the Claim Rule Wizard:
To c r e a t e r u l e s t o b l o c k a l l e x t e r n a l a c c e ss t o O ffi c e 3 6 5 , e x c e p t fo r d e si g n a t e d A c t i v e D i r e c t o r y g r o u p s

there is any IP claim outside the desired range, issue ipoutsiderange claim.” Under Custom rule, type or
paste the following claim rule language syntax(replace the value above for “x-ms-forwarded-client-ip” with a
`c1:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~

"^(?!192\.168\.1\.77|10\.83\.118\.23)"] && c2:[Type ==
"http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type =
"http://custom/ipoutsiderange", Value = "true");`
“check group SID”. Under Custom rule, type or paste the following claim rule language syntax (replace
"groupsid" with the actual SID of the AD group you are using):
NOT EXISTS([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-
32-100"]) => add(Type = "http://custom/groupsid", Value = "fail");
“deny users with ipoutsiderange true and groupsid fail”. Under Custom rule, type or paste the following
claim rule language syntax:
c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[Type == "http://custom/groupsid",
Value == "fail"] => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value =
"DenyUsersWithClaim");
9. Click Finish. Verify that the new rule appears immediately below the previous rule and before to the default
Permit Access to All Users rule in the Issuance Authorization Rules list (the Deny rule will take precedence
even though it appears earlier in the list).
following.
Building the IP address range expression
The x-ms-forwarded-client-ip claim is populated from an HTTP header that is currently set only by Exchange
Online, which populates the header when passing the authentication request to AD FS. The value of the claim may
be one of the following:
NOTE
Exchange Online currently supports only IPV4 and not IPV6 addresses.
A single IP address: The IP address of the client that is directly connected to Exchange Online
NOTE
The IP address of a client on the corporate network will appear as the external interface IP address of the organization’s
outbound proxy or gateway.
Clients that are connected to the corporate network by a VPN or by Microsoft DirectAccess (DA) may appear as
internal corporate clients or as external clients depending upon the configuration of VPN or DA.
One or more IP addresses: When Exchange Online cannot determine the IP address of the connecting client, it
will set the value based on the value of the x-forwarded-for header, a non-standard header that can be included
in HTTP -based requests and is supported by many clients, load balancers, and proxies on the market.
NOTE
1. Multiple IP addresses, indicating the client IP address and the address of each proxy that passed the request, will be
separated by a comma.
a. IP addresses related to Exchange Online infrastructure will not on the list.
Regular Expressions
When you have to match a range of IP addresses, it becomes necessary to construct a regular expression to
perform the comparison. In the next series of steps, we will provide examples for how to construct such an
expression to match the following address ranges (note that you will have to change these examples to match your
public IP range):
192.168.1.1 – 192.168.1.25
10.0.0.1 – 10.0.0.14
First, the basic pattern that will match a single IP address is as follows: \b###\.###\.###\.###\b
Extending this, we can match two different IP addresses with an OR expression as follows:
\b###\.###\.###\.###\b|\b###\.###\.###\.###\b
So, an example to match just two addresses (such as 192.168.1.1 or 10.0.0.1) would be:
\b192\.168\.1\.1\b|\b10\.0\.0\.1\b
This gives you the technique by which you can enter any number of addresses. Where a range of address
need to be allowed, for example 192.168.1.1 – 192.168.1.25, the matching must be done character by
character: \b192\.168\.1\.([1-9]|1[0-9]|2[0-5])\b
Please note the following:
The IP address is treated as string and not a number.
The rule is broken down as follows: \b192\.168\.1\.
This matches any value beginning with 192.168.1.
The following matches the ranges required for the portion of the address after the final decimal point:
([1-9] Matches addresses ending in 1-9
|1[0-9] Matches addresses ending in 10-19
|2[0-5]) Matches addresses ending in 20-25
Note that the parentheses must be correctly positioned, so that you don’t start matching other portions of IP
addresses.
With the 192 block matched, we can write a similar expression for the 10 block: \b10\.0\.0\.([1-9]|1[0-4])\b
And putting them together, the following expression should match all the addresses for “192.168.1.1～25”
and “10.0.0.1～14”: \b192\.168\.1\.([1-9]|1[0-9]|2[0-5])\b|\b10\.0\.0\.([1-9]|1[0-4])\b
Testing the Expression
Regex expressions can become quite tricky, so we highly recommend using a regex verification tool. If you do an
internet search for “online regex expression builder”, you will find several good online utilities that will allow you to
try out your expressions against sample data.
When testing the expression, it’s important that you understand what to expect to have to match. The Exchange
online system may send many IP addresses, separated by commas. The expressions provided above will work for
this. However, it’s important to think about this when testing your regex expressions. For example, one might use
the following sample input to verify the examples above:
192.168.1.1, 192.168.1.2, 192.169.1.1. 192.168.12.1, 192.168.1.10, 192.168.1.25, 192.168.1.26, 192.168.1.30,
1192.168.1.20
10.0.0.1, 10.0.0.5, 10.0.0.10, 10.0.1.0, 10.0.1.1, 110.0.0.1, 10.0.0.14, 10.0.0.15, 10.0.0.10, 10,0.0.1
Claim Types
AD FS in Windows Server 2012 R2 provides request context information using the following claim types:
X -MS -Forwarded-Client-IP
Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip
This AD FS claim represents a “best attempt” at ascertaining the IP address of the user (for example, the Outlook
client) making the request. This claim can contain multiple IP addresses, including the address of every proxy that
forwarded the request. This claim is populated from an HTTP. The value of the claim can be one of the following:
A single IP address - The IP address of the client that is directly connected to Exchange Online
NOTE
One or more IP addresses

If Exchange Online cannot determine the IP address of the connecting client, it will set the value based
on the value of the x-forwarded-for header, a non-standard header that can be included in HTTP
based requests and is supported by many clients, load balancers, and proxies on the market.
Multiple IP addresses indicating the client IP address and the address of each proxy that passed the
request will be separated by a comma.
NOTE
IP addresses related to Exchange Online infrastructure will not be present in the list.
WARNING
Exchange Online currently supports only IPV4 addresses; it does not support IPV6 addresses.
X -MS -Client-Application
Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application
This AD FS claim represents the protocol used by the end client, which corresponds loosely to the application being
used. This claim is populated from an HTTP header that is currently only set by Exchange Online, which populates
the header when passing the authentication request to AD FS. Depending on the application, the value of this claim
will be one of the following:
In the case of devices that use Exchange Active Sync, the value is Microsoft.Exchange.ActiveSync.
Use of the Microsoft Outlook client may result in any of the following values:
Microsoft.Exchange.Autodiscover
Microsoft.Exchange.OfflineAddressBook
Microsoft.Exchange.RPCMicrosoft.Exchange.WebServices
Microsoft.Exchange.RPCMicrosoft.Exchange.WebServices
Other possible values for this header include the following:
Microsoft.Exchange.Powershell
Microsoft.Exchange.SMTP
Microsoft.Exchange.Pop
Microsoft.Exchange.Imap
X -MS -Client-User-Agent
Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent
This AD FS claim provides a string to represent the device type that the client is using to access the service. This
can be used when customers would like to prevent access for certain devices (such as particular types of smart
phones). Example values for this claim include (but are not limited to) the values below.
The below are examples of what the x-ms-user-agent value might contain for a client whose x-ms-client-application
is “Microsoft.Exchange.ActiveSync”
Vortex/1.0
Apple-iPad1C1/812.1
Apple-iPhone3C1/811.2
Apple-iPhone/704.11
Moto-DROID2/4.5.1
SAMSUNGSPHD700/100.202
Android/0.3
It is also possible that this value is empty.
X -MS -Proxy
Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy
This AD FS claim indicates that the request has passed through the Web Application proxy. This claim is populated
by the Web Application proxy, which populates the header when passing the authentication request to the back end
Federation Service. AD FS then converts it to a claim.
The value of the claim is the DNS name of the Web Application proxy that passed the request.
InsideCorporateNetwork
Claim type: http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork
Similar to the above x-ms-proxy claim type, this claim type indicates whether the request has passed through the
web application proxy. Unlike x-ms-proxy, insidecorporatenetwork is a boolean value with True indicating a request
directly to the federation service from inside the corporate network.
X -MS -Endpoint-Absolute -Path (Active vs Passive )
Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path
This claim type can be used for determining requests originating from “active” (rich) clients versus “passive” (web-
browser-based) clients. This enables external requests from browser-based applications such as the Outlook Web
Access, SharePoint Online, or the Office 365 portal to be allowed while requests originating from rich clients such
as Microsoft Outlook are blocked.
The value of the claim is the name of the AD FS service that received the request.
See Also
AD FS Operations
Client Access Control policies in AD FS 2.0
A client access policies in Active Directory Federation Services 2.0 allow you to restrict or grant users access to
resources. This document describes how to enable client access policies in AD FS 2.0 and how to configure the
most common scenarios.
Enabling Client Access Policy in AD FS 2.0

To enable client access policy, follow the steps below.
Step 1: Install the Update Rollup 2 for AD FS 2.0 package on your AD FS servers
Download the Update Rollup 2 for Active Directory Federation Services (AD FS ) 2.0 package and install it on all
federation server and federation server proxies.
Step 2: Add five claim rules to the Active Directory Claims Provider trust
Once Update Rollup 2 has been installed on all of the AD FS servers and proxies, use the following procedure to
add a set of claims rules that makes the new claim types available to the policy engine.
To do this, you will be adding five acceptance transform rules for each of the new request context claim types using
the following procedure.
On the Active Directory claims provider trust, create a new acceptance transform rule to pass through each of the
new request context claim types.
To add a claim rule to the Active Directory claims provider trust for each of the five context claim types:
1. Click Start, point to Programs, point to Administrative Tools, and then click AD FS 2.0 Management.
2. In the console tree, under AD FS 2.0\Trust Relationships, click Claims Provider Trusts, right-click Active
Directory, and then click Edit Claim Rules.
3. In the Edit Claim Rules dialog box, select the Acceptance Transform Rules tab, and then click Add Rule to start
the Rule wizard.
4. On the Select Rule Template page, under Claim rule template, select Pass Through or Filter an Incoming Claim
5. On the Configure Rule page, under Claim rule name, type the display name for this rule; in Incoming claim type,
type the following claim type URL, and then select Pass through all claim values.
https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip
6. To verify the rule, select it in the list and click Edit Rule, then click View Rule Language. The claim rule language
should appear as follows:
c:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip"] =>
issue(claim = c);
7. Click Finish.
8. In the Edit Claim Rules dialog box, click OK to save the rules.
9. Repeat steps 2 through 6 to create an additional claim rule for each of the remaining four claim types shown
below until all five rules have been created.
https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application
`https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent`
`https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy`
`https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path`
Step 3: Update the Microsoft Office 365 Identity Platform relying party trust
Choose one of the example scenarios below to configure the claim rules on the Microsoft Office 365 Identity
Platform relying party trust that best meets the needs of your organization.
Client access policy scenarios for AD FS 2.0

The following sections will describe the scenarios that exist for AD FS 2.0
Scenario 1: Block all external access to Office 365
This client access policy scenario allows access from all internal clients and blocks all external clients based on the
IP address of the external client. The rule set builds on the default Issuance Authorization rule Permit Access to All
Users. You can use the following procedure to add an Issuance Authorization rule to the Office 365 relying party
trust.
To create a rule to block all external access to Office 365
2. In the console tree, under AD FS 2.0\Trust Relationships, click Relying Party Trusts, right-click the Microsoft
3. In the Edit Claim Rules dialog box, select the Issuance Authorization Rules tab, and then click Add Rule to start
the Claim Rule Wizard.
4. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and
then click Next.
5. On the Configure Rule page, under Claim rule name, type the display name for this rule. Under Custom rule,
type or paste the following claim rule language syntax:
exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) && NOT
exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip",
Value=~"customer-provided public ip address regex"]) => issue(Type =
"https://schemas.microsoft.com/authorization/claims/deny", Value = "true");
6. Click Finish. Verify that the new rule appears immediately below the Permit Access to All Users rule in the
Issuance Authorization Rules list.
7. To save the rule, in the Edit Claim Rules dialog box, click OK.
NOTE
You will have to replace the value above for “public ip address regex” with a valid IP expression; see Building the IP address
range expression for more information.
Scenario 2: Block all external access to Office 365 except Exchange ActiveSync
The following example allows access to all Office 365 applications, including Exchange Online, from internal clients
including Outlook. It blocks access from clients residing outside the corporate network, as indicated by the client IP
address, except for Exchange ActiveSync clients such as smart phones. The rule set builds on the default Issuance
Authorization rule titled Permit Access to All Users. Use the following steps to add an Issuance Authorization rule
to the Office 365 relying party trust using the Claim Rule Wizard:
To create a rule to block all external access to Office 365
then click Next.
exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application",
Value=="Microsoft.Exchange.Autodiscover"]) && NOT exists([Type ==
"https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application",
Value=="Microsoft.Exchange.ActiveSync"]) && NOT exists([Type ==
"https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value=~"customer-
provided public ip address regex"]) => issue(Type =
NOTE
You will have to replace the value above for “public ip address regex” with a valid IP expression; see Building the IP address
range expression for more information.
Scenario 3: Block all external access to Office 365 except browser-based applications
The rule set builds on the default Issuance Authorization rule titled Permit Access to All Users. Use the following
steps to add an Issuance Authorization rule to the Microsoft Office 365 Identity Platform relying party trust using
the Claim Rule Wizard:
NOTE
This scenario is not supported with a third-party proxy because of limitations on client access policy headers with passive
(Web-based) requests.
To create a rule to block all external access to Office 365 except browser-based applications
then click Next.
exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip",
Value=~"customer-provided public ip address regex"]) && NOT exists([Type ==
"https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value ==
"/adfs/ls/"]) => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "true");
Scenario 4: Block all external access to Office 365 for designated Active Directory groups
The following example enables access from internal clients based on IP address. It blocks access from clients
residing outside the corporate network that have an external client IP address, except for those individuals in a
specified Active Directory Group.The rule set builds on the default Issuance Authorization rule titled Permit Access
to All Users. Use the following steps to add an Issuance Authorization rule to the Microsoft Office 365 Identity
Platform relying party trust using the Claim Rule Wizard:
To create a rule to block all external access to Office 365 for designated Active Directory groups
then click Next.
exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) && exists([Type ==
"https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "Group SID value of allowed AD
group"]) && NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-
client-ip", Value=~"customer-provided public ip address regex"]) => issue(Type =
Descriptions of the claim rule language syntax used in the above scenarios
DESCRIPTION CLAIM RULE LANGUAGE SYNTAX
Default AD FS rule to Permit Access to All Users. This rule => issue(Type =
should already exist in the Microsoft Office 365 Identity "https://schemas.microsoft.com/authorization/claims/permit",
Platform relying party trust Issuance Authorization Rules list. Value = "true");
Adding this clause to a new, custom rule specifies that the

request has come from the federation server proxy (i.e., it has
the x-ms-proxy header)
It is recommended that all rules include this. exists([Type ==

"https://schemas.microsoft.com/2012/01/requestcontext/claim
s/x-ms-proxy"])
Used to establish that the request is from a client with an IP in NOT exists([Type ==
the defined acceptable range. "https://schemas.microsoft.com/2012/01/requestcontext/claim
s/x-ms-forwarded-client-ip", Value=~"customer-provided
public ip address regex"])
This clause is used to specify that if the application being NOT exists([Type ==
accessed is not Microsoft.Exchange.ActiveSync the request "https://schemas.microsoft.com/2012/01/requestcontext/claim
should be denied. s/x-ms-client-application",
Value=="Microsoft.Exchange.ActiveSync"])
This rule allows you to determine whether the call was through NOT exists([Type ==
a Web browser, and will not be denied. "https://schemas.microsoft.com/2012/01/requestcontext/claim
s/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"])
DESCRIPTION CLAIM RULE LANGUAGE SYNTAX
This rule states that the only users in a particular Active exists([Type ==
Directory group (based on SID value) should be denied. "https://schemas.microsoft.com/ws/2008/06/identity/claims/gr
Adding NOT to this statement means a group of users will be oupsid", Value =~ "{Group SID value of allowed AD group}"])
allowed, regardless of location.
This is a required clause to issue a deny when all preceding => issue(Type =
conditions are met. "https://schemas.microsoft.com/authorization/claims/deny",
Value = "true");
Building the IP address range expression

The x-ms-forwarded-client-ip claim is populated from an HTTP header that is currently set only by Exchange
Online, which populates the header when passing the authentication request to AD FS. The value of the claim may
be one of the following:
NOTE
Exchange Online currently supports only IPV4 and not IPV6 addresses.
A single IP address: The IP address of the client that is directly connected to Exchange Online
NOTE
Clients that are connected to the corporate network by a VPN or by Microsoft DirectAccess (DA) may appear as
internal corporate clients or as external clients depending upon the configuration of VPN or DA.
One or more IP addresses: When Exchange Online cannot determine the IP address of the connecting client, it will
set the value based on the value of the x-forwarded-for header, a non-standard header that can be included in
HTTP -based requests and is supported by many clients, load balancers, and proxies on the market.
NOTE
Multiple IP addresses, indicating the client IP address and the address of each proxy that passed the request, will be separated
by a comma.
IP addresses related to Exchange Online infrastructure will not appear on the list.
Regular Expressions
When you have to match a range of IP addresses, it becomes necessary to construct a regular expression to
perform the comparison. In the next series of steps, we will provide examples for how to construct such an
expression to match the following address ranges (note that you will have to change these examples to match your
public IP range):
192.168.1.1 – 192.168.1.25
10.0.0.1 – 10.0.0.14
First, the basic pattern that will match a single IP address is as follows: \b###.###.###.###\b
Extending this, we can match two different IP addresses with an OR expression as follows:
\b###.###.###.###\b|\b###.###.###.###\b
So, an example to match just two addresses (such as 192.168.1.1 or 10.0.0.1) would be:
\b192.168.1.1\b|\b10.0.0.1\b
This gives you the technique by which you can enter any number of addresses. Where a range of address need to
allowed, for example 192.168.1.1 – 192.168.1.25, the matching must be done character by character: \b192.168.1.
([1-9]|1[0-9]|2[0-5])\b
NOTE
The IP address is treated as string and not a number.
The rule is broken down as follows: \b192.168.1.

This matches any value beginning with 192.168.1.
The following matches the ranges required for the portion of the address after the final decimal point:
([1-9] Matches addresses ending in 1-9
|1[0-9] Matches addresses ending in 10-19
|2[0-5]) Matches addresses ending in 20-25
NOTE
The parentheses must be correctly positioned, so that you don’t start matching other portions of IP addresses.
With the 192 block matched, we can write a similar expression for the 10 block: \b10.0.0.([1-9]|1[0-4])\b
And putting them together, the following expression should match all the addresses for “192.168.1.1～25” and
“10.0.0.1～14”: \b192.168.1.([1-9]|1[0-9]|2[0-5])\b|\b10.0.0.([1-9]|1[0-4])\b
Testing the Expression
Regex expressions can become quite tricky, so we highly recommend using a regex verification tool. If you do an
internet search for “online regex expression builder”, you will find several good online utilities that will allow you to
try out your expressions against sample data.
When testing the expression, it’s important that you understand what to expect to have to match. The Exchange
online system may send many IP addresses, separated by commas. The expressions provided above will work for
this. However, it’s important to think about this when testing your regex expressions. For example, one might use
the following sample input to verify the examples above:
192.168.1.1, 192.168.1.2, 192.169.1.1. 192.168.12.1, 192.168.1.10, 192.168.1.25, 192.168.1.26, 192.168.1.30,
1192.168.1.20
10.0.0.1, 10.0.0.5, 10.0.0.10, 10.0.1.0, 10.0.1.1, 110.0.0.1, 10.0.0.14, 10.0.0.15, 10.0.0.10, 10,0.0.1
Validating the Deployment

Security Audit Logs
To verify that the new request context claims are being sent and are available to the AD FS claims processing
pipeline, enable audit logging on the AD FS server. Then send some authentication requests and check for the claim
values in the standard security audit log entries.
To enable the logging of audit events to the security log on an AD FS server, follow the steps at Configure auditing
for AD FS 2.0.
Event Logging
By default, failed requests are logged to the application event log located under Applications and Services Logs \
AD FS 2.0 \ Admin.For more information on event logging for AD FS, see Set up AD FS 2.0 event logging.
Configuring Verbose AD FS Tracing Logs
AD FS tracing events are logged to the AD FS 2.0 debug log. To enable tracing, see Configure debug tracing for AD
FS 2.0.
After you have enabled tracing, use the following command line syntax to enable the verbose logging level:
wevtutil.exe sl “AD FS 2.0 Tracing/Debug” /l:5
Related
For more information on the new claim types see AD FS Claims Types.
Additional authentication methods in AD FS 2019
Organizations are experiencing attacks that attempt to brute force, compromise, or otherwise lock out user
accounts by sending password based authentication requests. To help protect organizations from compromise, AD
FS has introduced capabilities such as extranet “smart” lockout and IP address based blocking.
However, these mitigations are reactive. To provide a proactive way, to reduce the severity of these attacks, AD FS
has the ability to prompt for non-password factors prior to collecting the password.
For example, AD FS 2016 introduced Azure MFA as primary authentication so that OTP codes from the
Authenticator App could be used as the first factor. Building on this, with AD FS 2019 you can configure external
authentication providers as primary authentication factors.
There are two key scenarios this enables:
Scenario 1: protect the password

Protect password-based login from brute-force attacks and lockouts by prompting for an additional, external factor
first. Only if the external authentication is successfully completed does the user then see a password prompt. This
eliminates a convenient way attackers have been trying to compromise or disable accounts.
This scenario consists of two components:
Prompting for Azure MFA or an external authentication factor as primary authentication
Username and password as additional authentication in AD FS
Scenario 2: password-free!
Eliminate passwords entirely but completing a strong, multi-factor authentication using entirely non password
based methods in AD FS
Azure MFA with Authenticator app
Windows 10 Hello for Business
Certificate authentication
External authentication providers
Concepts
What primary authentication really means is that it is the method the user is prompted for first, prior to
additional factors. Previously the only primary methods available in AD FS were built in methods for Active
Directory or Azure MFA, or other LDAP authentication stores. External methods could be configured as “additional”
authentication, which takes place after primary authentication has successfully completed.
In AD FS 2019, the external authentication as primary capability means that any external authentication providers
registered on the AD FS farm (using Register-AdfsAuthenticationProvider) become available for primary
authentication as well as “additional” authentication. They can be enabled the same way as the built in providers
such as Forms Authentication and Certificate Authentication, for intranet and/or extranet use.
Once an external provider is enabled for extranet, intranet, or both, it becomes available for users to use. If more
than one method is enabled, users will see a choice page and be able to choose a primary method, just as they do
for additional authentication.
Pre-requisites
Before configuring external authentication providers as primary, ensure you have the following pre-requisites in
place
The AD FS farm behavior level (FBL ) has been raised to ‘4’ (this value translates to AD FS 2019)
This is the default FBL value for new AD FS 2019 farms
For AD FS farms based on Windows Server 2012 R2 or 2016, the FBL can be raised using the
PowerShell commandlet Invoke-AdfsFarmBehaviorLevelRaise. For more details on upgrading an AD FS
farm, see the farm upgrade article for SQL farms or WID farms
You can check the FBL value using the cmdlet Get-AdfsFarmInformation
The AD FS 2019 farm is configured to use the new 2019 ‘paginated’ user facing pages
This is the default behavior for new AD FS 2019 farms
For AD FS farms upgraded from Windows Server 2012 R2 or 2016, the paginated flows are enabled
automatically when external authentication as primary (the feature described in this document) is enabled
as described below.
Enable external authentication methods as primary

Once you have verified the prerequisites, there are two ways to configure AD FS additional authentication
providers as primary:
Using PowerShell
PS C:\> Set-AdfsGlobalAuthenticationPolicy -AllowAdditionalAuthenticationAsPrimary $true

The AD FS service must be restarted after enabling or disabling additional authentication as primary.
Using the AD FS Management console
In the AD FS Management console, under Service -> Authentication Methods, under Primary
Authentication Methods, click Edit
Click the checkbox for Allow additional authentication providers as primary.
The AD FS service must be restarted after enabling or disabling additional authentication as primary.
Enable username and password as additional authentication

To complete the “protect the password” scenario, enable username and password as additional authentication using
either PowerShell or the AD FS Management console
Using PowerShell
PS C:\> $providers = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
PS C:\>$providers = $providers + "FormsAuthentication"
PS C:\>Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $providers
Using the AD FS Management console

In the AD FS Management console, under Service -> Authentication Methods, under Additional
Authentication Methods, click Edit
Click the checkbox for Forms Authentication to enable username and password as additional authentication.
Active Directory Federation Services prompt=login
parameter support
The following document describes the native support for the prompt=login parameter that is available in AD FS.
What is prompt=login?
Some Office 365 applications (with modern authentication enabled) send the prompt=login parameter to Azure
AD as part of each authentication request. By default, Azure AD translates this into two parameters:
wauth=urn:oasis:names:tc:SAML:1.0:am:password , and wfresh=0 .
This can cause problems with corporate intranet and multi-factor authentication scenarios in which an
authentication type other than username and password is desired.
AD FS in Windows Server 2012 R2 with the July 2016 update rollup introduced native support for the
prompt=login parameter. This means, you now have the option of configuring Azure AD to send this parameter as-
is to your AD FS service as part of Azure AD and Office 365 authentication requests.
AD FS versions that support prompt=login
The following is a list of AD FS versions that support the prompt=login parameter.
AD FS in Windows Server 2012 R2 with the July 2016 update rollup
AD FS in Windows Server 2016
How do to configure your Azure AD tenant to send prompt=login to

AD FS
Use the Azure AD PowerShell module to configure the setting.
NOTE
The prompt=login capability (enabled by the PromptLoginBehavior property) is currently available only in the ‘version 1.0’
Azure AD Powershell module, in which the cmdlets have names that include “Msol”, such as Set-
MsolDomainFederationSettings. It is not currently available via ‘version 2.0’ Azure AD PowerShell module, whose cmdlets
have names like “Set-AzureAD*”.
To configure prompt=login behavior, the cmdlet syntax below:

Example 1:
Set-MsolDomainFederationSettings –DomainName <your domain name> -PreferredAuthenticationProtocol <your

current protocol setting>
Example 2:
Set-MsolDomainFederationSettings –DomainName <your domain name> -SupportsMfa <$True|$False>
Example 3:
Set-MsolDomainFederationSettings –DomainName <your domain name> -PromptLoginBehavior
<TranslateToFreshPasswordAuth|NativeSupport|Disabled>
The PreferredAuthenticationProtocol, SupportsMfa, and PromptLoginBehavior property values can be found by

viewing the output from the cmdlet:
Get-MsolDomainFederationSettings -DomainName <your_domain_name> | fl *
NOTE
By default, when running Get-MsolDomainFederationSettings, certain properties are not displayed in the console. To view
these parameters it is recommended that you use the | fl * to force the output of all of the properties of the object.
The following is more information about the PromptLoginBehavior parameter and its settings.
TranslateToFreshPasswordAuth means the default Azure AD behavior of sending wauth and wfresh to AD
FS instead of prompt=login
NativeSupport means that the prompt=login parameter will be sent as is to AD FS
Disabled means nothing will be sent to AD FS
AD FS paginated sign-in
For AD FS 2019, we’ve redesigned the sign-in UI. Now, the AD FS sign-in will have the same look and feel of
Azure AD. This will provide users a more consistent sign-in experience, incorporating a centered and paginated
user flow.
What’s changing
In AD FS 2012 R2 and 2016, your sign-in screen looked something like this:
We’re moving away from displaying a single form located on the right side of the screen.
In AD FS 2019, these are the major design changes that you’ll see:
A centered UI. Previously, the sign-in UI existed on the right side of the screen, as shown above. We’ve moved
the UI front and center to modernize the experience.
Pagination. Instead of providing you a long form to fill out, we’ve incorporated a new flow that will take you
through the sign-in experience step-by-step. Our telemetry shows that with this approach, our customers have
more successful sign-ins. It also provides us more flexibility to incorporate various authentication methods, such
us phone factor authentication.
On the first page, you’ll be asked to enter your username. You may also select the option to “Keep me signed in” to
reduce the frequency of sign-in prompts and remain signed in when it’s safe to do so. (This option is disabled by
default.)
On the second page, you’ll be presented with authentication options, configured by your administrator. If allowing
external authentication as primary is enabled, this will be included as well.
On the third page, you’ll be asked to enter your password (assuming you selected “Password” as your
authentication option).
How to get the new experience

If you are a new customer to AD FS, you’ll receive the new design by default. However, if you are an existing
customer with AD FS 2012 R2 or 2016, there are several steps you’ll need to take to receive the new design:
1. Upgrade your servers to AD FS 2019.
2. Enable your FBL to 2019.
3. Enable the new sign-in experience.
4. Allow the new sign-in via PowerShell. In PowerShell, run the following command to enable pagination:
Set-AdfsGlobalAuthenticationPolicy -EnablePaginatedAuthenticationPages $true
5. Allow external authentication as primary, either via PowerShell or through the AD FS Server Manager. In
PowerShell, run the following command to allow external authentication as primary:
Set-AdfsGlobalAuthenticationPolicy -AllowAdditionalAuthenticationAsPrimary $true
Customization
The options for customization will still be applicable for AD FS 2019. Below are some links to other documents for
your reference.
• For those who do not plan to upgrade their servers to AD FS 2019 but still want the new design: Using an Azure
AD UX Web Theme in Active Directory Federation Services
• A central location for customization: AD FS user sign-in customization
AD FS Single Sign-On Settings
Single Sign-On (SSO ) allows users to authenticate once and access multiple resources without being prompted for
additional credentials. This article describes the default AD FS behavior for SSO, as well as the configuration
settings that allow you to customize this behavior.
Supported types of Single Sign-On

AD FS supports several types of Single Sign-On experiences:
Session SSO
Session SSO cookies are written for the authenticated user which eliminates further prompts when the user
switches applications during a particular session. However, if a particular session ends, the user will be
prompted for their credentials again.
AD FS will set session SSO cookies by default if users’ devices are not registered. If the browser session has
ended and is restarted, this session cookie is deleted and is not valid any more.
Persistent SSO
Persistent SSO cookies are written for the authenticated user which eliminates further prompts when the
user switches applications for as long as the persistent SSO cookie is valid. The difference between
persistent SSO and session SSO is that persistent SSO can be maintained across different sessions.
AD FS will set persistent SSO cookies if the device is registered. AD FS will also set a persistent SSO cookie
if a user selects the “keep me signed in” option. If the persistent SSO cookie is not valid any more, it will be
rejected and deleted.
Application specific SSO
In the OAuth scenario, a refresh token is used to maintain the SSO state of the user within the scope of a
particular application.
If a device is registered, AD FS will set the expiration time of a refresh token based on the persistent SSO
cookies lifetime for a registered device which is 7 days by default. If a user selects the “keep me signed in”
option, the expiration time of the refresh token will equal the persistent SSO cookies lifetime for “keep me
signed in” which is 1 day by default with maximum of 7 day. Otherwise, refresh token lifetime equals session
SSO cookie lifetime which is 8 hours by default
As mentioned above, users on registered devices will always get a persistent SSO unless the persistent SSO
is disabled. For un-registered devices, persistent SSO can be achieved by enabling the “keep me signed in”
(KMSI) feature.
For Windows Server 2012 R2, to enable PSSO for the “Keep me signed in” scenario, you need to install this
hotfix which is also part of the of August 2014 update rollup for Windows RT 8.1, Windows 8.1, and
Single Sign-On and authenticated devices

After providing credentials for the first time, by default users with registered devices get single Sign-On for a
maximum period of 90 days, provided they use the device to access AD FS resources at least once every 14 days. If
they wait 15 days after providing credentials, users will be prompted for credentials again.
Persistent SSO is enabled by default. If it is disabled, no PSSO cookie will be written.|
Set-AdfsProperties –EnablePersistentSso <Boolean\>
The device usage window (14 days by default) is governed by the AD FS property DeviceUsageWindowInDays.
Set-AdfsProperties -DeviceUsageWindowInDays
The maximum single Sign-On period (90 days by default) is governed by the AD FS property
PersistentSsoLifetimeMins.
Set-AdfsProperties -PersistentSsoLifetimeMins
Keep Me Signed in for unauthenticated devices

For non-registered devices, the single sign-on period is determined by the Keep Me Signed In (KMSI ) feature
settings. KMSI is disabled by default and can be enabled by setting the AD FS property KmsiEnabled to True.
Set-AdfsProperties -EnableKmsi $true
With KMSI disabled, the default single sign-on period is 8 hours. This can be configured using the property
SsoLifetime. The property is measured in minutes, so its default value is 480.
Set-AdfsProperties –SsoLifetime <Int32\>
With KMSI enabled, the default single sign-on period is 24 hours. This can be configured using the property
KmsiLifetimeMins. The property is measured in minutes, so its default value is 1440.
Set-AdfsProperties –KmsiLifetimeMins <Int32\>
Multi-factor authentication (MFA) behavior

It's important to note that, while providing relatively long periods of single sign on, AD FS will prompt for
additional authentication (multi factor authentication) when a previous sign on was based on primary credentials
and not MFA, but the current sign on requires MFA. This is regardless of SSO configuration. AD FS, when it
receives an authentication request, first determines whether or not there is an SSO context (such as a cookie) and
then, if MFA is required (such as if the request is coming in from outside) it will assess whether or not the SSO
context contains MFA. If not, MFA is prompted.
PSSO revocation
To protect security, AD FS will reject any persistent SSO cookie previously issued when the following conditions
are met. This will require the user to provide their credentials in order to authenticate with AD FS again.
User changes password
Persistent SSO setting is disabled in AD FS
Device is disabled by the administrator in lost or stolen case
AD FS receives a persistent SSO cookie which is issued for a registered user but the user or the device is not
registered anymore
AD FS receives a persistent SSO cookie for a registered user but the user re-registered
AD FS receives a persistent SSO cookie which is issued as a result of “keep me signed in” but “keep me
signed in” setting is disabled in AD FS
AD FS receives a persistent SSO cookie which is issued for a registered user but device certificate is missing
or altered during authentication
AD FS administrator has set a cutoff time for persistent SSO. When this is configured, AD FS will reject any
persistent SSO cookie issued before this time
To set the cutoff time, run the following PowerShell cmdlet:
Set-AdfsProperties -PersistentSsoCutoffTime <DateTime>
Enable PSSO for Office 365 users to access SharePoint Online

Once PSSO is enabled and configured in AD FS, AD FS will write a persistent cookie after a user has
authenticated. The next time the user comes in, if a persistent cookie is still valid, a user does not need to provide
credentials to authenticate again. You can also avoid the additional authentication prompt for Office 365 and
SharePoint Online users by configuring the following two claims rules in AD FS to trigger persistence at Microsoft
Azure AD and SharePoint Online. To enable PSSO for Office 365 users to access SharePoint online, you need to
install this hotfix which is also part of the of August 2014 update rollup for Windows RT 8.1, Windows 8.1, and
An Issuance Transform rule to pass through the InsideCorporateNetwork claim
@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through claim - InsideCorporateNetwork"
c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork"]
A custom Issuance Transform rule to pass through the persistent SSO claim
@RuleName = "Pass Through Claim - Psso"
c:[Type == "http://schemas.microsoft.com/2014/03/psso"]
Overview
Today AD FS is made highly available by setting up an AD FS farm. Some organizations would like a way to have a
single server AD FS deployment, eliminating the need for multiple AD FS servers and network load balancing
infrastructure, while still having some assurance that service can be restored quickly if there is a problem. The new
AD FS Rapid Restore tool provides a way to restore AD FS data without requiring a full backup and restore of the
operating system or system state. You can use the new tool to export AD FS configuration either to Azure or to an
on-premises location. Then you can apply the exported data to a fresh AD FS installation, re-creating or duplicating
the AD FS environment.
Scenarios
The AD FS Rapid Restore tool can be used in the following scenarios:
1. Quickly restore AD FS functionality after a problem
Use the tool to create a cold standby installation of AD FS that can be quickly deployed in place of the
online AD FS server
2. Deploy identical test and production environments
Use the tool to quickly create an accurate copy of the production AD FS in a test environment, or to
quickly deploy a validated test configuration to production
What is backed up
The tool backs up the following AD FS configuration
AD FS configuration database (SQL or WID )
Configuration file (located in AD FS folder)
Automatically generated token signing and decrypting certificates and private keys (from the Active Directory
DKM container)
SSL certificate and any externally enrolled certificates (token signing, token decryption and service
communication) and corresponding private keys (note: private keys must be exportable and the user running
the script must have permissions to access them)
A list of the custom authentication providers, attribute stores, and local claims provider trusts that are installed.
How to use the tool

First, download and install the MSI to your AD FS server.
Run the following command from a PowerShell prompt:
import-module 'C:\Program Files (x86)\ADFS Rapid Recreation Tool\ADFSRapidRecreationTool.dll'

NOTE
If you are using the Windows Integrated Database (WID), then this tool needs to be run on the primary AD FS server. You can
use the Get-AdfsSyncProperties PowerShell cmdlet to determine whether or not the server you are on is the primary
server.
System requirements
This tool works for AD FS in Windows Server 2012 R2 and later.
The required .NET framework is at least 4.0.
The restore must be done on an AD FS server of the same version as the backup and that uses the same Active
Directory account as the AD FS service account.
Create a backup
To create a backup, use the Backup-ADFS cmdlet. This cmdlet backs up the AD FS configuration, database, SSL
certificates, etc.
The user has to be at least a local admin to run this cmdlet. To backup the Active Directory DKM container (required
in the default AD FS configuration), the user either has to be domain admin, needs to pass in the AD FS service
account credentials, or has access to the DKM container. If you are using a gMSA account, the user must be domain
admin or have permissions to the container; you cannot provide the gMSA credentials.
The backup will be named according to the pattern "adfsBackup_ID_Date-Time". It will contain the version number,
date and time that the backup was done. The cmdlet takes the following parameters:
Parameter Sets
Detailed description
BackupDKM - Backs up the Active Directory DKM container that contains the AD FS keys in the default
configuration (automatically generated token signing and decrypting certificates). This uses an AD Tool
'ldifde' to export the AD Container and all its subtrees.
-StorageType <string> - The type of storage the user wants to use. "FileSystem" indicates that the user
wants to store it in a folder locally or in the network "Azure" indicates the user wants to store it in the Azure
Storage Container When the user performs the backup, they select the backup location, either the File
System or in the cloud. For Azure to be used, Azure Storage Credentials should be passed to the cmdlet. The
storage credentials contains the account name and key. In addition to this, a container name must also be
passed in. If the container doesn’t exist, it is created during the backup. For the file system to be used, a
storage path must be given. In that directory, a new directory will be created for each backup. Each directory
created will contain the backed up files.
EncryptionPassword <string> - The password that is going to be used to encrypt all the backed up files
before storing it
AzureConnectionCredentials <pscredential> - The account name and key for the Azure storage account
AzureStorageContainer <string> - The storage container where the backup will be stored in Azure
StoragePath <string> - The location the backups will be stored in
ServiceAccountCredential <pscredential> - specifies the service account being used for the AD FS
Service running currently. This parameter is only needed if the user would like to backup the DKM and is not
domain admin or does not have access to the container's contents.
BackupComment <string[]> - An informational string about the backup that will be displayed during the
restore, similar to the concept of Hyper-V checkpoint naming. The default is an empty string
Backup examples
The following are backup examples for using the AD FS Rapid Restore Tool.
Backup the AD FS configuration, with the DKM, to the File System, and has access to the DKM container
contents (either domain admin or delegated)
Backup-ADFS -StorageType "FileSystem" -StoragePath "C:\Users\administrator\testExport\" -EncryptionPassword

"password" -BackupComment "Clean Install of ADFS (FS)" -BackupDKM
Backup the AD FS configuration, with the DKM, to the file system with the service account credential, running as
local admin

"password" -BackupComment "Clean Install of ADFS (FS)" -BackupDKM -ServiceAccountCredential $cred
Backup the AD FS configuration without the DKM to the Azure Storage Container.
Backup-ADFS -StorageType "Azure" -AzureConnectionCredentials $cred -AzureStorageContainer "adfsbackups" -

EncryptionPassword "password" -BackupComment "Clean Install of ADFS"
Backup the AD FS configuration without the DKM to the File System

"password" -BackupComment "Clean Install of ADFS (FS)"
Restore from backup

To apply a configuration created using Backup-ADFS to a new AD FS installation, use the Restore-ADFS cmdlet.
This cmdlet creates a new AD FS farm using the cmdlet Install-AdfsFarm and restores the AD FS configuration,
database, certificates, etc. If the AD FS role has not been installed on the server, the cmdlet will install it. The cmdlet
checks the restore location for existing backups and prompts the user to choose an appropriate backup based on
the date/time it was taken and any backup comment that the user might have attached to the backup. If there are
multiple AD FS configurations with different federation service names, then the user is prompted to first choose
the appropriate AD FS configuration. The user has to be both local and domain admin to run this cmdlet.
NOTE
Before using the AD FS Rapid Recovery Tool, ensure that the server is joined to the domain prior to restoring the backup.
The cmdlet takes the following parameters:

Detailed description
StorageType <string> - The type of storage the user wants to use. "FileSystem" indicates that the user
wants to store it in a folder locally or in the network "Azure" indicates the user wants to store it in the Azure
Storage Container
DecryptionPassword <string> - The password that was used to encrypt all the backed up files
AzureConnectionCredentials <pscredential> - The account name and key for the Azure storage account
AzureStorageContainer <string> - The storage container where the backup will be stored in Azure
StoragePath <string> - The location the backups will be stored in
ADFSName < string > - The name of the federation that was backed up and is going to be restored. If this
is not provided and there is only one federation service name then that will be used. If there is more than
one federation service backed up to the location, then the user is prompted to choose one of the backed up
Federation Services.
ServiceAccountCredential < pscredential > - specifies the service account that will be used for the new
AD FS Service being restored
GroupServiceAccountIdentifier <string> - The GMSA that the user wants to use for the new AD FS
Service being restored. By default, if neither is provided then the backed up account name is used if it was
GMSA, else the user is prompted to put in a service account
DBConnectionString <string> - If the user would like to use a different DB for the restore, then they
should pass the SQL Connection String or type in WID for WID.
Force <bool> - Skip the prompts that the tool might have once the backup is chosen
RestoreDKM <bool> - Restore the DKM Container to the AD, should be set if going to a new AD and the
DKM was backed up initially.
Restore examples
Restore the AD FS configuration without the DKM from the Azure Storage Container
Restore-ADFS -StorageType "Azure" -AzureConnectionCredential $cred -DecryptionPassword "password" -

AzureStorageContainer "adfsbackups"
Restore the AD FS configuration without the DKM from the File System
Restore-ADFS -StorageType "FileSystem" -StoragePath "C:\uSERS\administrator\testExport\" -DecryptionPassword

"password"
Restore the AD FS configuration with the DKM to the File System

"password" -RestoreDKM
Restore the AD FS Configuration to WID

"password" -DBConnectionString "WID"
Restore the AD FS Configuration to SQL

"password" -DBConnectionString "Data Source=TESTMACHINE\SQLEXPRESS; Integrated Security=True"
Restores the AD FS Configuration with the specified GMSA

"password" -GroupServiceAccountIdentifier "mangupd1\adfsgmsa$"
Restore the AD FS Configuration with the specified service account creds

"password" -ServiceAccountCredential $cred
Encryption information
All backup data is encrypted before pushing it to the cloud or storing it in the file system.
Each document that is created as part of the backup is encrypted using AES -256. The password passed into the
tool is used as a pass phrase to generate a new password using the Rfc2898DeriveBytes Class.
RngCryptoServiceProvider is used to generate the salt used by AES and the Rfc2898DeriveBytes Class.
Log Files
Every time a backup or restore is performed a log file is created. These can be found at the following location:
%localappdata%\ADFSRapidRecreationTool
NOTE
When performing a restore a PostRestore_Instructions file might be created containing an overview of the additional
authentication providers, attribute stores and local claims provider trusts to be installed manually before starting the AD FS
service.
Version Release History

Version: 1.0.75.0
Release: August 2018
Fixed issues:
Update Backup-ADFS when using the -BackupDKM switch. The tool will determine if the current context has
access to the DKM container. If so, it will not require either Domain Admin privileges or service account
credentials. This allows automated backups to happen without explicitly providing credentials or running as a
Domain Administrator account.
Version: 1.0.73.0
Release: August 2018
Fixed issues:
Update the encryption algorithms so that the application is FIPS compliant
NOTE
Old backups will not work with the new version due to changes in encryption algorithms as per FIPS compliance
Add support for SQL clusters that use merge replication

Version: 1.0.72.0
Release: July 2018
Fixed issues:
Bug fix: Fixed the .MSI installer to support in-place upgrades
1.0.18.0
Release: July 2018
Fixed issues:
Bug fix: handle service account passwords that have special characters in them (ie, ‘&’)
Bug fix: restoration fails because Microsoft.IdentityServer.Servicehost.exe.config is being used by another
process
1.0.0.0
Released: October 2016
Initial release of AD FS Rapid Restore Tool
AD FS support for alternate hostname binding for
certificate authentication
On many networks the local firewall policies might not allow traffic through non-standard ports like 49443. This
became an issue when trying to accomplish certificate authentication with AD FS prior to AD FS in Windows
Server 2016. This is because you could not have different bindings for device authentication and user certificate
authentication on the same host. The default port 443 is bound to receive device certificates and cannot be altered
to support multiple binding in the same channel. The results were that smart card authentication would not work
and users were unaware of what happened since there is no indication of what really happened.
With AD FS in Windows Server 2016 this can be accomplished.
In AD FS on Windows Server 2016 this has changed. Now we support two modes, the first uses the same host (i.e.
adfs.contoso.com) with different ports (443, 49443). The second used different hosts (adfs.contoso.com and
certauth.adfs.contoso.com) with the same port (443). This will require an SSL certificate to support "certauth." as an
alternate subject name. This can be done at the time of the farm creation or later via PowerShell.
How to configure alternate host name binding for certificate

authentication
There are two ways that you can add the alternate host name binding for certificate authentication. The first is when
setting up a new AD FS farm with AD FS for Windows Server 2016, if the certificate contains a subject alternative
name (SAN ), then it will automatically be setup to use the second method mentioned above. That is, it will
automatically setup two different hosts (sts.contoso.com and certauth.sts.contoso.com with the same port. If the
certificate does not contain a SAN, then you will see a warning telling you that certificate subject alternative names
does not support certauth.*. See the screenshots below. The first one shows an installation where the certificate had
a SAN and the second one shows a certificate that did not.
Likewise, once AD FS in Windows Server 2016 has been deployed you can use the PowerShell cmdlet: Set-
AdfsAlternateTlsClientBinding.
Set-AdfsAlternateTlsClientBinding -Member DC1.contoso.com -Thumbprint '<thumbprint of cert>'

When prompted, click Yes to confirm. And that should be it.
Managing SSL Certificates in AD FS and WAP in Windows Server 2016
AD FS provides a number of options for administrators to customize and tailor the end-user experience to meet
their corporate needs. The following page will serve as a central location for customization. You can use the table
below to quickly find your customization option.
TOPIC DESCRIPTION
AD FS Customization in Windows Server 2016 New customization options available for AD FS in Windows
Server 2016
Change the company name Steps for displaying your companies name on the sign-in page
Change the company logo Steps for changing the logo that appears on the sign-in-page
Change the illustration Steps for changing the illustration that appears on the sign-in
page
Add sign-in description Steps for adding a description to the sign-in page
Add help desk link Steps for adding a help desk link
Add home link Steps for adding a home link
Add privacy link Steps for adding a privacy link
Custom web themes Information on using custom web themes

TOPIC DESCRIPTION
Custom error messages Steps for customizing error messages
Home Realm Discovery Steps for customizing Home Realm Discovery
Update Password Customization Steps for enabling and customizing the update password page
Multi-factor authentication and external auth providers Information on using MFA and external auth providers
customization
Customization for Localization Information on localization considerations
Removing the Microsoft copyright Steps on removing the Microsoft copyright
Customizing the display names and descriptions for Steps on customizing display names and descriptions for
authentication methods authentication methods
Advanced Customization Advanced customization options using the onload.js file.

User accounts and computer accounts that require access to a resource that is protected by Active Directory
Federation Services (AD FS ) are stored in an attribute store, such as Active Directory Domain Services (AD DS ).
The claims issuance engine uses attribute stores to gather data that is necessary to issue claims. Data from the
attribute stores is then projected as claims.
You can use the following procedure to add an attribute store to the Federation Service.
Default Groups.
To add an attribute store
1. Open AD FS Management.
2. Under Actions click Add an attribute store.
1. In the Add an attribute store dialog box, configure the following properties for the attribute store that you
want to add:
In Display name, type the name that you want to use to identify the attribute store.
In Attribute store type, select a supported attribute store type, either Active Directory, LDAP, or
SQL.
In Connection string, if you have selected either a Lightweight Directory Access Protocol (LDAP )
store or a Structured Query Language (SQL ) store, enter the string that you used to establish a
connection to the attribute store. For Active Directory attribute stores, no connection string is
necessary; therefore, this field is disabled.
NOTE
1. Click OK.
AD FS Operations
Compound authentication and AD DS claims in AD
FS
Windows Server 2012 enhances Kerberos authentication by introducing compound authentication. Compound
authentication enables a Kerberos Ticket-Granting Service (TGS ) request to include two identities:
the identity of the user
the identity of the user’s device.
Windows accomplishes compound authentication by extending Kerberos Flexible Authentication Secure Tunneling
(FAST), or Kerberos armoring.
AD FS 2012 and later versions allows consumption of AD DS issued user or device claims that reside in a Kerberos
authentication ticket. In previous versions of AD FS, the claims engine could only read user and group security IDs
(SIDs) from Kerberos but was not able to read any claims information contained within a Kerberos ticket.
You can enable richer access control for federated applications by using Active Directory Domain Services (AD
DS )-issued user and device claims together, with Active Directory Federation Services (AD FS ).
Requirements
1. The Computers accessing federated applications, must Authenticate to AD FS using Windows Integrated
Authentication.
Windows Integrated Authentication is only available when connecting to the Backend AD FS Servers.
Computers must be able to reach the Backend AD FS Servers for Federation Service Name
AD FS Servers must offer Windows Integrated Authentication as a Primary Authentication method in its
Intranet settings.
2. The policy Kerberos client support for claims compound authentication and Kerberos armoring
must be applied to all Computers accessing federated applications that are protected by Compound
Authentication. This is applicable in case of single forest or cross forest scenarios.
3. The Domain housing the AD FS Servers must have the KDC support for claims compound
authentication and Kerberos armoring policy setting applied to the Domain Controllers.
Steps for configuring AD FS in Windows Server 2012 R2

Use the following steps for configuring compound authentication and claims
Step 1: Enable KDC support for claims, compound authentication, and Kerberos armoring on the Default Domain
Controller Policy
1. In Server Manager, select Tools, Group Policy Management.
2. Navigate down to the Default Domain Controller Policy, right-click and select edit.
3. On the Group Policy Management Editor, under Computer Configuration, expand Policies, expand
Administrative Templates, expand System, and select KDC.
4. In the right pane, double-click KDC support for claims, compound authentication, and Kerberos
armoring.
5. In the new dialog window, set KDC support for claims to Enabled.
6. Under Options, select Supported from the drop-down menu and then click Apply and OK.
Step 2: Enable Kerberos client support for claims, compound authentication, and Kerberos armoring on
computers accessing federated applications
1. On a Group Policy applied to the computers accessing federated applications, in the Group Policy
Management Editor, under Computer Configuration, expand Policies, expand Administrative Templates,
expand System, and select Kerberos.
2. In the right pane of the Group Policy Management Editor window, double-click Kerberos client support for
claims, compound authentication, and Kerberos armoring.
3. In the new dialog window, set Kerberos client support to Enabled and click Apply and OK.
4. Close the Group Policy Management Editor.
Step 3: Ensure the AD FS servers have been updated.
You need to ensure that the following updates are installed on your AD FS servers.
UPDATE DESCRIPTION
KB2919355 Cumulative security update(includes

KB2919355,KB2932046,KB2934018,KB2937592,KB2938439)
KB2959977 Update for Server 2012 R2
Hotfix 3052122 This update adds support for compound ID claims in Active
Directory Federation Services.
Step 4: Configure the Primary Authentication Provider

1. Set the Primary Authentication Provider to Windows Authentication for AD FS Intranet settings.
2. In AD FS Management, under Authentication Policies, select Primary Authentication and under Global
Settings click edit.
3. On Edit Global Authentication Policy under Intranet select Windows Authentication.
4. Click Apply and Ok.
1. Using PowerShell you can use the Set-AdfsGlobalAuthenticationPolicy cmdlet.
Set-AdfsGlobalAuthenticationPolicy -PrimaryIntranetAuthenticationProvider 'WindowsAuthentication'
NOTE
In a WID based farm, the PowerShell command must be executed on the Primary AD FS Server. In a SQL based farm, the
PowerShell command may be executed on any AD FS server that is a member of the farm.
Step 5: Add the claim description to AD FS

1. Add the following Claim Description to the farm. This Claim Description is not present by default in ADFS 2012
R2 and needs to be manually added.
2. In AD FS Management, under Service, right-click Claim description and select Add claim description
3. Enter the following information in the claim description
Display Name: 'Windows device group'
Claim Description: 'https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsdevicegroup' `
4. Place a check in both boxes.
5. Click OK.
1. Using PowerShell you can use the Add-AdfsClaimDescription cmdlet.
powershell Add-AdfsClaimDescription -Name 'Windows device group' -ClaimType
'https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsdevicegroup' ` -ShortName
'windowsdevicegroup' -IsAccepted $true -IsOffered $true -IsRequired $false -Notes 'The windows group SID of
the device'
NOTE
Step 6: Enable the compound authentication bit on the msDS -SupportedEncryptionTypes attribute
1. Enable compound authentication bit on the msDS -SupportedEncryptionTypes attribute on the account you
designated to run the AD FS service using the Set-ADServiceAccount PowerShell cmdlet.
NOTE
If you change the service account, then you must manually enable compound authentication by running the Set-ADUser -
compoundIdentitySupported:$true Windows PowerShell cmdlets.
Set-ADServiceAccount -Identity “ADFS Service Account” -CompoundIdentitySupported:$true
1. Restart the ADFS Service.
NOTE
Once ‘CompoundIdentitySupported’ is set to true, installation of the same gMSA on new Servers (2012R2/2016) fails with the
following error – Install-ADServiceAccount : Cannot install service account. Error Message: 'The provided context did
not match the target.'.
Solution: Temporarily set CompoundIdentitySupported to $false. This step causes ADFS to stop issuing
WindowsDeviceGroup claims. Set-ADServiceAccount -Identity 'ADFS Service Account' -CompoundIdentitySupported:$false
Install the gMSA on the new Server and then enable CompoundIdentitySupported back to $True. Disabling
CompoundIdentitySupported and then reenabling does not need ADFS service to be restarted.
Step 7: Update the AD FS Claims Provider Trust for Active Directory
1. Update the AD FS Claims Provider Trust for Active Directory to include the following ‘Pass-through’ Claim rule
for ‘WindowsDeviceGroup’ Claim.
2. In AD FS Management, click Claims Provider Trusts and in the right pane, righ-click Active Directory and
select Edit Claim Rules.
3. On the Edit Claim Rules for Active Director click Add Rule.
4. On the Add Transform Claim Rule Wizard select Pass Through or Filter an Incoming Claim and click
Next.
5. Add a display name and select Windows device group from the Incoming claim type drop-down.
6. Click Finish. Click Apply and Ok.
Step 8: On the Relying Party where the ‘WindowsDeviceGroup’ claims are expected, add a similar ‘Pass-through’
Or ‘Transform’ claim rule.
1. In AD FS Management, click Relying Party Trusts and in the right pane, righ-click your RP and select Edit
Claim Rules.
2. On the Issuance Transform Rules click Add Rule.
Next.
Steps for configuring AD FS in Windows Server 2016
The following will detail the steps for configuring compound authentication on AD FS for Windows Server 2016.
Step 1: Enable KDC support for claims, compound authentication, and Kerberos armoring on the Default Domain
Controller Policy
1. In Server Manager, select Tools, Group Policy Management.
2. Navigate down to the Default Domain Controller Policy, right-click and select edit.
3. On the Group Policy Management Editor, under Computer Configuration, expand Policies, expand
Administrative Templates, expand System, and select KDC.
4. In the right pane, double-click KDC support for claims, compound authentication, and Kerberos
armoring.
5. In the new dialog window, set KDC support for claims to Enabled.
6. Under Options, select Supported from the drop-down menu and then click Apply and OK.
Step 2: Enable Kerberos client support for claims, compound authentication, and Kerberos armoring on
computers accessing federated applications
1. On a Group Policy applied to the computers accessing federated applications, in the Group Policy
Management Editor, under Computer Configuration, expand Policies, expand Administrative Templates,
expand System, and select Kerberos.
2. In the right pane of the Group Policy Management Editor window, double-click Kerberos client support for
claims, compound authentication, and Kerberos armoring.
3. In the new dialog window, set Kerberos client support to Enabled and click Apply and OK.
4. Close the Group Policy Management Editor.
Step 3: Configure the Primary Authentication Provider
1. Set the Primary Authentication Provider to Windows Authentication for AD FS Intranet settings.
2. In AD FS Management, under Authentication Policies, select Primary Authentication and under Global
Settings click edit.
3. On Edit Global Authentication Policy under Intranet select Windows Authentication.
4. Click Apply and Ok.
5. Using PowerShell you can use the Set-AdfsGlobalAuthenticationPolicy cmdlet.
Set-AdfsGlobalAuthenticationPolicy -PrimaryIntranetAuthenticationProvider 'WindowsAuthentication'
NOTE
Step 4: Enable the compound authentication bit on the msDS -SupportedEncryptionTypes attribute
1. Enable compound authentication bit on the msDS -SupportedEncryptionTypes attribute on the account you
designated to run the AD FS service using the Set-ADServiceAccount PowerShell cmdlet.
NOTE
If you change the service account, then you must manually enable compound authentication by running the Set-ADUser -
compoundIdentitySupported:$true Windows PowerShell cmdlets.
Set-ADServiceAccount -Identity “ADFS Service Account” -CompoundIdentitySupported:$true
1. Restart the ADFS Service.
NOTE
Once ‘CompoundIdentitySupported’ is set to true, installation of the same gMSA on new Servers (2012R2/2016) fails with the
following error – Install-ADServiceAccount : Cannot install service account. Error Message: 'The provided context did
not match the target.'.
Solution: Temporarily set CompoundIdentitySupported to $false. This step causes ADFS to stop issuing
WindowsDeviceGroup claims. Set-ADServiceAccount -Identity 'ADFS Service Account' -CompoundIdentitySupported:$false
Install the gMSA on the new Server and then enable CompoundIdentitySupported back to $True. Disabling
CompoundIdentitySupported and then reenabling does not need ADFS service to be restarted.
Step 5: Update the AD FS Claims Provider Trust for Active Directory

1. Update the AD FS Claims Provider Trust for Active Directory to include the following ‘Pass-through’ Claim rule
for ‘WindowsDeviceGroup’ Claim.
2. In AD FS Management, click Claims Provider Trusts and in the right pane, righ-click Active Directory and
select Edit Claim Rules.
3. On the Edit Claim Rules for Active Director click Add Rule.
Next.
Step 6: On the Relying Party where the ‘WindowsDeviceGroup’ claims are expected, add a similar ‘Pass-through’
Or ‘Transform’ claim rule.
1. In AD FS Management, click Relying Party Trusts and in the right pane, righ-click your RP and select Edit
Claim Rules.
2. On the Issuance Transform Rules click Add Rule.
Next.
Validation
To validate the release of ‘WindowsDeviceGroup’ claims, create a test Claims Aware Application using .Net 4.6.
With WIF SDK 4.0. Configure the Application as a Relying Party in ADFS and update it with Claim Rule as specified
in steps above. When authenticating to the Application using Windows Integrated Authentication provider of
ADFS, the following claims are casted.
The Claims for the computer/device may now be consumed for richer access controls.
For example – The following AdditionalAuthenticationRules Tells AD FS to invoke MFA if – The Authenticating
User is not member of the security group “-1-5-21-2134745077-1211275016-3050530490-1117” AND the
Computer (where is the user is Authenticating from) is not member of the security group "S -1-5-21-2134745077-
1211275016-3050530490-1115 (WindowsDeviceGroup)"
However, if any of the above conditions are met, do not invoke MFA.
'NOT EXISTS([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsdevicegroup", Value =~

"S-1-5-21-2134745077-1211275016-3050530490-1115"])
&& NOT EXISTS([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-5-21-
2134745077-1211275016-3050530490-1117"])
=> issue(Type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value =
"https://schemas.microsoft.com/claims/multipleauthn");'
Configuring AD FS for user certificate authentication
AD FS can be configured for x509 user certificate authentication using one of the modes described in this article.
This capability can be used with Azure Active Directory or on its own, to enable clients and devices provisioned with
user certificates to access AD FS resources from the intranet or the extranet.
Prerequisites
Ensure that your user certificates are trusted by all AD FS and WAP servers
Ensure that the root certificate of the chain of trust for your user certificates is in the NTAuth store in Active
Directory
If using AD FS in alternate certificate authentication mode, ensure that your AD FS and WAP servers have SSL
certificates that contain the AD FS hostname prefixed with "certauth", for example "certauth.fs.contoso.com",
and that traffic to this hostname is allowed through the firewall
If using certificate authentication from the extranet, ensure that at least one AIA and at least one CDP or OCSP
location from the list specified in your certificates are accessible from the internet.
If you are configuring AD FS for Azure AD certificate authentication, ensure that you have configured the Azure
AD settings and the AD FS claim rules required for certificate Issuer and Serial Number
Also for Azure AD certificate authentication, for Exchange ActiveSync clients, the client certificate must have the
users routable email address in Exchange online in either the Principal Name or the RFC822 Name value of the
Subject Alternative Name field. (Azure Active Directory maps the RFC822 value to the Proxy Address attribute
in the directory.)
Configure AD FS for user certificate authentication

Enable user certificate authentication as an intranet or extranet authentication method in AD FS, using either the
AD FS Management console or the PowerShell cmdlet Set-AdfsGlobalAuthenticationPolicy
Ensure that the entire chain of trust, including any intermediate certificates, is installed on every AD FS and
WAP server. The intermediate certificates should be installed in the local computer intermediate certification
authorities store on all AD FS and WAP servers.
If you wish to use claims based on certificate fields and extensions in addition to EKU (claim type
https://schemas.microsoft.com/2012/12/certificatecontext/extension/eku), configure additional claim pass
through rules on the Active Directory claims provider trust. See below for a complete list of available certificate
claims.
[Optional] Configure allowed issuing certification authorities for client certificates using the guidance under
"Management of trusted issuers for client authentication" in this article.
Configure Seamless Certificate Authentication for Chrome browser on

Windows Desktops
When multiple user certificates (such as Wi-Fi certificates) are present on the machine that satisfy the purposes of
client authentication, the Chrome browser on Windows desktop will prompt the user to select the right certificate.
This may be confusing to the end user. To optimize this experience, you can set a policy for Chrome to auto-select
the right certificate for a better user experience. This policy can be set manually by making a registry change or
configured automatically via GPO (to set the registry keys). This requires your user client certificates for
authentication against AD FS to have distinct issuers from other use cases.
For more information on configuring this for Chrome, please refer to this link.
Troubleshooting
If certificate authentication requests fail with an HTTP 204 "No Content from https://certauth.fs.contoso.com"
response, verify that the root and any intermediate CA certificates are installed, respectively, to the trusted root
CA and intermediate CA certificate stores on all federation servers.
If certificate authentication requests are failing for unknown reasons, export the client certificate to a .cer file,
and run the command
certutil -f -urlfetch -verify certificatefilename.cer
Ensure any CRL and delta CRL locations resolve. Note that delta CRL locations are found based on the contents of
the Base CRL.
Reference: Complete list of user certificate claim types and example

values
CLAIM TYPE EXAMPLE VALUE
https://schemas.microsoft.com/2012/12/certificatecontext/field 3
/x509version
https://schemas.microsoft.com/2012/12/certificatecontext/field sha256RSA
/signaturealgorithm
https://schemas.microsoft.com/2012/12/certificatecontext/field CN=entca, DC=domain, DC=contoso, DC=com

/issuer
https://schemas.microsoft.com/2012/12/certificatecontext/field CN=entca, DC=domain, DC=contoso, DC=com

/issuername
https://schemas.microsoft.com/2012/12/certificatecontext/field 12/05/2016 20:50:18

/notbefore
https://schemas.microsoft.com/2012/12/certificatecontext/field 12/05/2017 20:50:18

/notafter
https://schemas.microsoft.com/2012/12/certificatecontext/field E=user@contoso.com, CN=user, CN=Users, DC=domain,

/subject DC=contoso, DC=com
https://schemas.microsoft.com/2012/12/certificatecontext/field E=user@contoso.com, CN=user, CN=Users, DC=domain,

/subjectname DC=contoso, DC=com
https://schemas.microsoft.com/2012/12/certificatecontext/field {Base64 encoded digital certificate data}

/rawdata
https://schemas.microsoft.com/2012/12/certificatecontext/exte DigitalSignature
nsion/keyusage
https://schemas.microsoft.com/2012/12/certificatecontext/exte KeyEncipherment
nsion/keyusage
CLAIM TYPE EXAMPLE VALUE
https://schemas.microsoft.com/2012/12/certificatecontext/exte 9D11941EC06FACCCCB1B116B56AA97F3987D620A
nsion/subjectkeyidentifier
https://schemas.microsoft.com/2012/12/certificatecontext/exte KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd 36 6a d5 0b 51 f3
nsion/authoritykeyidentifier 0b 25 7f
https://schemas.microsoft.com/2012/12/certificatecontext/exte User
nsion/certificatetemplatename
https://schemas.microsoft.com/2012/12/certificatecontext/exte Other Name:Principal Name=user@contoso.com, RFC822

nsion/san Name=user@contoso.com
https://schemas.microsoft.com/2012/12/certificatecontext/exte 1.3.6.1.4.1.311.10.3.4
nsion/eku
If your organization is federated with Azure AD, you can use Azure Multi-Factor Authentication to secure AD FS
resources, both on-premises and in the cloud. Azure MFA enables you to eliminate passwords and provide a more
secure way to authenticate. Starting with Windows Server 2016, you can now configure Azure MFA for primary
authentication.
Unlike with AD FS in Windows Server 2012 R2, the AD FS 2016 Azure MFA adapter integrates directly with Azure
AD and does not require an on premises Azure MFA server. The Azure MFA adapter is built in to Windows Server
2016, and there is no need for additional installation.
Registering users for Azure MFA with AD FS 2016

AD FS does not support inline "proof up", or registration of Azure MFA security verification information such as
phone number or mobile app. This means users must get proofed up by visiting
https://account.activedirectory.windowsazure.com/Proofup.aspx prior to using Azure MFA to authenticate to AD
FS applications. When a user who has not yet proofed up in Azure AD tries to authenticate with Azure MFA at AD
FS, they will get an AD FS error. As an AD FS administrator, you can customize this error experience to guide the
user to the proofup page instead. You can do this using onload.js customization to detect the error message string
within the AD FS page and show a new message to guide the users to visit https://aka.ms/mfasetup, then re-
attempt authentication. For detailed guidance see the "Customize the AD FS web page to guide users to register
MFA verification methods" below in this article.
NOTE
Previously, users were required to authenticate with MFA for registration (visiting
https://account.activedirectory.windowsazure.com/Proofup.aspx, for example via the shortcut https://aka.ms/mfasetup). Now,
an AD FS user who has not yet registered MFA verification information can access Azure AD"s proofup page via the shortcut
https://aka.ms/mfasetup using only primary authentication (such as Windows Integrated Authentication or username and
password via the AD FS web pages). If the user has no verification methods configured, Azure AD will perform inline
registration in which the user sees the message "Your admin has required that you set up this account for additional security
verification", and the user can then select to "Set it up now". Users who already have at least one MFA verification method
configured will still be prompted to provide MFA when visiting the proofup page.
Recommended deployment topologies

Azure MFA as Primary Authentication
There are a couple of great reasons to use Azure MFA as Primary Authentication with AD FS:
To avoid passwords for sign-in to Azure AD, Office 365 and other AD FS apps
To protect password based sign-in by requiring an additional factor such as verification code prior to the
password
If you wish to use Azure MFA as a primary authentication method in AD FS to achieve these benefits, you
probably also want to keep the ability to use Azure AD conditional access including "true MFA" by prompting for
additional factors in AD FS.
You can now do this by configuring the Azure AD domain setting to do MFA on premises (setting "SupportsMfa"
to $True). In this configuration, AD FS can be prompted by Azure AD to perform additional authentication or "true
MFA" for conditional access scenarios that require it.
As described above, any AD FS user who has not yet registered (configured MFA verification information) should
be prompted via a customized AD FS error page to visit https://aka.ms/mfasetup to configure verification
information, then re-attempt AD FS login.
Because Azure MFA as primary is considered a single factor, after initial configuration users will need to provide an
additional factor to manage or update their verification information in Azure AD, or to access other resources that
require MFA.
Azure MFA as Additional authentication to Office 365
Previously, if you wished to have Azure MFA as an additional authentication method in AD FS for Office 365 or
other relying parties, the best option was to configure Azure AD to do compound MFA, in which primary
authentication is performed on premises in AD FS and MFA is triggered by Azure AD. Now, you can use Azure
MFA as additional authentication in AD FS when the domain SupportsMfa setting is set to $True.
As described above, any AD FS user who has not yet registered (configured MFA verification information) should
be prompted via a customized AD FS error page to visit https://aka.ms/mfasetup to configure verification
information, then re-attempt AD FS login.
Pre-Requisites
The following pre-requisites are required when using Azure MFA for authentication with AD FS:
An Azure subscription with Azure Active Directory.
Azure Multi-Factor Authentication
Web app proxy is able to communticate with the following over ports 80 and 443
https://adnotifications.windowsazure.com
https://login.microsoftonline.com
NOTE
Azure AD and Azure MFA are included in Azure AD Premium and the Enterprise Mobility Suite (EMS). If you have either of
these you do not need individual subscriptions.
A Windows Server 2016 AD FS on-premises environment.
The server needs to be able to communicate with the following URLs over ports 80 and 443.
https://adnotifications.windowsazure.com
https://login.microsoftonline.com
Your on-premises environment is federated with Azure AD.
Windows Azure Active Directory Module for Windows PowerShell.
Global administrator permissions on your instance of Azure AD to configure it using Azure AD PowerShell.
Enterprise administrator credentials to configure the AD FS farm for Azure MFA.
Configure the AD FS Servers

In order to complete configuration for Azure MFA for AD FS, you need to configure each AD FS server using the
steps described.
NOTE
Ensure that these steps are performed on all AD FS servers in the farm. If you have multiple AD FS servers in your farm, you
can perform the necessary configuration remotely using Azure AD Powershell.
Step 1: Generate a certificate for Azure MFA on each AD FS server using the New-AdfsAzureMfaTenantCertificate
cmdlet
The first thing you need to do is generate a certificate for Azure MFA to use. This can be done using PowerShell.
The certificate generated can be found in the local machines certificate store, and it is marked with a subject name
containing the TenantID for your Azure AD directory.
Note that TenantID is the name of your directory in Azure AD. Use the following PowerShell cmdlet to generate
the new certificate.
$certbase64 = New-AdfsAzureMfaTenantCertificate -TenantID <tenantID>
Step 2: Add the new credentials to Azure Multi-Factor Auth Client SPN
In order to enable the AD FS servers to communicate with the Azure Multi-Factor Auth Client, you need to add the
credentials to the SPN for the Azure Multi-Factor Auth Client. The certificates generated using the
New-AdfsAzureMFaTenantCertificate cmdlet will serve as these credentials. Do the following using PowerShell to
add the new credentials to the Azure Multi-Factor Auth Client SPN.
NOTE
In order to complete this step you need to connect to your instance of Azure AD with PowerShell using Connect-MsolService.
These steps assume you have already connected via PowerShell. For information see Connect-MsolService.
Set the certificate as the new credential against the Azure Multi-Factor Auth Client
New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type asymmetric -Usage
verify -Value $certBase64
IMPORTANT
This command needs to be run on all of the AD FS servers in your farm. Azure AD MFA will fail on servers that have not have
the certificate set as the new credential against the Azure Multi-Factor Auth Client.
NOTE
981f26a1-7f43-403b-a875-f8b09b8cd720 is the GUID for Azure Multi-Factor Auth Client.
Configure the AD FS Farm

Once you have completed the previous section on each AD FS server, you will need to run the
Set-AdfsAzureMfaTenant cmdlet.
This cmdlet needs to be executed only once for an AD FS farm. Use PowerShell to complete this step.
NOTE
You will need to restart the AD FS service on each server in the farm before these changes take affect.
Set-AdfsAzureMfaTenant -TenantId <tenant ID> -ClientId 981f26a1-7f43-403b-a875-f8b09b8cd720
After this, you will see that Azure MFA is available as a primary authentication method for intranet and extranet
use.
Renew and Manage AD FS Azure MFA Certificates

The following guidance takes you through how to manage the Azure MFA certificates on your AD FS servers. By
default, when you configure AD FS with Azure MFA, the certificates generated via the New -
AdfsAzureMfaTenantCertificate PowerShell cmdlet are valid for 2 years. To determine how close to expiration your
certificates are, and then to renew and install new certificates, use the following procedure.
Assess AD FS Azure MFA certificate expiration date
On each AD FS server, in the local computer My store, there will be a self signed certificate with "OU=Microsoft
AD FS Azure MFA" in the Issuer and Subject. This is the Azure MFA certificate. Check the validity period of this
certificate on each AD FS server to determine the expiration date.
Create new AD FS Azure MFA Certificate on each AD FS server
If the validity period of your certificates is nearing its end, start the renewal process by generating a new Azure
MFA certificate on each AD FS server. In a powershell command window, generate a new certificate on each AD
FS server using the following cmdlet:
PS C:\> $newcert = New-AdfsAzureMfaTenantCertificate -TenantId <tenant id such as contoso.onmicrosoft.com> -

Renew $true
As a result of this cmdlet, a new certificate that is valid from 2 days in the future to 2 days + 2 years will be
generated. AD FS and Azure MFA operations will not be affected by this cmdlet or the new certificate. (Note: the 2
day delay is intentional and provides time to execute the steps below to configure the new certificate in the tenant
before AD FS starts using it for Azure MFA.)
Configure each new AD FS Azure MFA certificate in the Azure AD tenant
Using the Azure AD PowerShell module, for each new certificate (on each AD FS server), update your Azure AD
tenant settings as follows (Note: you must first connect to the tenant using Connect-MsolService to run the
following commands).
PS C:/> New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type

Asymmetric -Usage Verify -Value $newcert
$certbase64 is the new certificate. The base64 encoded certificate can be obtained by exporting the certificate
(without the private key) as a DER encoded file and opening in Notepad.exe, then copy/pasting to the PSH session
and assigning to the variable $certbase64
Verify that the new certificate (s) will be used for Azure MFA
Once the new certificate(s) become valid, AD FS will pick them up and start using each respective certificate for
Azure MFA within a few hours to a day. Once this occurs, on each server you will see an event logged in the AD FS
Admin event log with the following information: Log Name: AD FS/Admin Source: AD FS Date: 2/27/2018
7:33:31 PM Event ID: 547 Task Category: None Level: Information Keywords: AD FS User: DOMAIN\adfssvc
Computer: ADFS.domain.contoso.com Description: The tenant certificate for Azure MFA has been renewed.
TenantId: contoso.onmicrosoft.com. Old thumbprint: 7CC103D60967318A11D8C51C289EF85214D9FC63. Old
expiration date: 9/15/2019 9:43:17 PM. New thumbprint: 8110D7415744C9D4D5A4A6309499F7B48B5F3CCF.
New expiration date: 2/27/2020 2:16:07 AM.
Customize the AD FS web page to guide users to register MFA

verification methods
Use the following examples to customize your AD FS web pages for users who have not yet proofed up
(configured MFA verification information).
Find the error
First, there are a couple of different error messages AD FS will return in the case in which the user lacks
verification information. If you are using Azure MFA as primary authentication, the un-proofed user will see an AD
FS error page containing the following messages:
<div id="errorArea">
<div id="openingMessage" class="groupMargin bigText">
An error occurred
</div>
<div id="errorMessage" class="groupMargin">
Authentication attempt failed. Select a different sign in option or close the web browser and sign
in again. Contact your administrator for more information.
</div>
When Azure AD as additional authentication is being attempted, the un-proofed user will see an AD FS error page
containing the following messages:
<div id='mfaGreetingDescription' class='groupMargin'>For security reasons, we require additional information to

verify your account (mahesh@jenfield.net)</div>
<div id="errorArea">
<div id="openingMessage" class="groupMargin bigText">
An error occurred
</div>
<div id="errorMessage" class="groupMargin">
The selected authentication method is not available for 'username@contoso.com'. Choose
another authentication method or contact your system administrator for details.
</div>
Catch the error and update the page text

To catch the error and show the user custom guidance simply append the javascript to the end of the onload.js file
that is part of the AD FS web theme. This allows you to do the following:
search for the identifying error string(s)
provide custom web content.
(For guidance in general on how to customize the onload.js file, see the article Advanced Customization of AD FS
Sign-in Pages.)
Here is a simple example, you may want to extend:
1. Open Windows PowerShell on your primary AD FS server and create a new AD FS Web Theme by running
the following command:
New-AdfsWebTheme –Name ProofUp –SourceName default
2. Next, export the default AD FS Web Theme:
Export-AdfsWebTheme –Name default –DirectoryPath c:\Theme
3. Open the C:\Theme\script\onload.js file in a text editor

4. Append the following code to the end of the onload.js file
//Custom Code
//Customize MFA exception
//Begin
var domain_hint = "<YOUR_DOMAIN_NAME_HERE>";

var mfaSecondFactorErr = "The selected authentication method is not available for";
var mfaProofupMessage = "You will be automatically redirected in 5 seconds to set up your account for
additional security verification. Once you have completed the setup, please return to the application
you are attempting to access.<br><br>If you are not redirected automatically, please click <a
href='{0}'>here</a>."
var authArea = document.getElementById("authArea");
if (authArea) {
var errorMessage = document.getElementById("errorMessage");
if (errorMessage.innerHTML.indexOf(mfaSecondFactorErr) >= 0) {
//Hide the error message

var openingMessage = document.getElementById("openingMessage");
if (openingMessage) {
openingMessage.style.display = 'none'
}
var errorDetailsLink = document.getElementById("errorDetailsLink");
if (errorDetailsLink) {
errorDetailsLink.style.display = 'none'
}
//Provide a message and redirect to Azure AD MFA Registration Url

var mfaRegisterUrl = "https://account.activedirectory.windowsazure.com/proofup.aspx?
proofup=1&whr=" + domain_hint;
errorMessage.innerHTML = "<br>" + mfaProofupMessage.replace("{0}", mfaRegisterUrl);
window.setTimeout(function () { window.location.href = mfaRegisterUrl; }, 5000);
}
}
//End Customize MFA Exception

//End Custom Code
IMPORTANT
You need to change "<YOUR_DOMAIN_NAME_HERE>"; to use your domain name. For example:
var domain_hint = "contoso.com";
5. Save the onload.js file

6. Import the onload.js file into your custom theme by typing the following Windows PowerShell command:
Set-AdfsWebTheme -TargetName ProofUp -AdditionalFileResource

@{Uri=’/adfs/portal/script/onload.js’;path="c:\theme\script\onload.js"}
7. Finally, apply the custom AD FS Web Theme by typing the following Windows PowerShell command:
Set-AdfsWebConfig -ActiveThemeName
Next steps
Manage TLS/SSL Protocols and Cipher Suites used by AD FS and Azure MFA
Configure AD FS Extranet Lockout Protection
In AD FS on Windows Server 2012 R2, we introduced a security feature called Extranet Lockout. With this feature,
AD FS will "stop" authenticating the "malicious" user account from outside for a period of time. This prevents your
user accounts from being locked out in Active Directory. In addition to protecting your users from an AD account
lockout, AD FS extranet lockout also protects against brute force password guessing attacks
NOTE
This feature only works for the extranet scenario where the authentication requests come through the Web Application
Proxy and only applies to username and password authentication.
Advantages of Extranet Lockout

Extranet lockout provides the following key advantages:
It protects your user accounts from brute force attacks where an attacker tries to guess a user's password by
continuously sending authentication requests. In this case, AD FS will lock out the malicious user account for
extranet access
It protects your user accounts from malicious account lockout where an attacker wants to lock out a user
account by sending authentication requests with wrong passwords. In this case, although the user account will
be locked out by AD FS for extranet access, the actual user account in AD is not locked out and the user can still
access corporate resources within the organization. This is known as a soft lockout.
How it Works
There are 3 settings in AD FS that you need to configure to enable this feature:
EnableExtranetLockout <Boolean> set this Boolean value to be True if you want to enable Extranet Lockout.
ExtranetLockoutThreshold <Integer> this defines the maximum number of bad password attempts. Once
the threshold is reached, AD FS will immediately rejects the requests from extranet without attempting to
contact the domain controller for authentication, no matter whether password is good or bad, until the extranet
observation window is passed. This means the value of badPwdCount attribute of an AD account will not
increase while the account is soft-locked out.
ExtranetObservationWindow <TimeSpan> this determines for how long the user account will be soft-
locked out. AD FS will start to perform username and password authentication again when the window is
passed. AD FS uses the AD attribute badPasswordTime as the reference for determining whether the extranet
observation window has passed or not. The window has passed if current time > badPasswordTime +
ExtranetObservationWindow.
NOTE
AD FS extranet lockout functions independently from the AD lockout policies. However, we strongly recommend that you set
the ExtranetLockoutThreshold parameter value to a value that is less than the AD account lockout threshold. Failing to do
so would result in AD FS being unable to protect accounts from being locked out in Active Directory.
An example of enabling Extranet Lockout feature with maximum of 15 number of bad password attempts and 30
mins soft-lockout duration is as follows:
Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow (new-

timespan -Minutes 30)
These settings will apply to all domains that the AD FS service can authenticate. The way that it works is that when
AD FS receives an authentication request, it will access the Primary Domain Controller (PDC ) through an LDAP call
and perform a lookup for the badPwdCount attribute for the user on the PDC. If AD FS finds the value of
badPwdCount >= ExtranetLockoutThreshold setting and the time defined in the Extranet Observation Window
has not passed yet, AD FS will reject the request immediately, which means no matter whether the user enters a
good or bad password from extranet, the logon will fail because AD FS does not send the credentials to AD. AD FS
does not maintain any state with regard to badPwdCount or locked out user accounts. AD FS uses AD for all state
tracking.
WARNING
When AD FS Extranet lockout on Server 2012 R2 is enabled all authentication requests through the WAP are validated by AD
FS on the PDC. When the PDC is unavailable, users will be unable to authenticate from the extranet.
Server 2016 offers an additional parameter that allows AD FS to fallback to another domain controller when the
PDC is unavailable:
ExtranetLockoutRequirePDC <Boolean> - When enabled: extranet lockout requires a primary domain
controller (PDC ). When disabled: extranet lockout will fallback to another domain controller in case the PDC is
unavailable.
You can use the following Windows PowerShell command to configure the AD FS extranet lockout on Server 2016:
Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow (new-

timespan -Minutes 30) -ExtranetLockoutRequirePDC $false
Working with the Active Directory Lockout Policy

The Extranet Lockout feature in AD FS works independently from the AD lockout policy. However, you do need to
make sure the settings for the Extranet Lockout is properly configured so that it can serve its security purpose with
the AD lockout policy. Let's take a look at AD lockout policy first. There are three settings regarding lockout policy
in AD:
Account Lockout Threshold: this setting is similar to the ExtranetLockoutThreshold setting in AD FS. It
determines the number of failed logon attempts that will cause a user account to be locked out. In order to
protect your user accounts from a malicious account lockout attack, you want to set the value of
ExtranetLockoutThreshold in AD FS < the Account Lockout Threshold value in AD
Account Lockout Duration: this setting determines for how long a user account is locked out. This setting
does not matter much in this conversation as Extranet Lockout should always happen before AD lockout
happens if configured properly
Reset Account Lockout Counter After: this setting determines how much time must elapse from user's last
logon failure before badPwdCount is reset to 0. In order for Extranet Lockout feature in AD FS to work well
with AD lockout policy, you want to make sure the value of ExtranetObservationWindow in AD FS > the Reset
Account Lockout Counter After value in AD. The examples below will explain why.
Let's take a look at two examples and see how badPwdCount changes over time based on different settings and
states. Let's assume in both examples Account Lockout Threshold = 4 and ExtranetLockoutThreshold = 2.
The red arrow represents bad password attempt, the green arrow represents a good password attempt. In example
#1, ExtranetObservationWindow > Reset Account Lockout Counter After. In example #2,
ExtranetObservationWindow < Reset Account Lockout Counter After.
Example 1
Example 2
As you can see from the above, there are two conditions when badPwdCount will be reset to 0. One is when there
is a successful logon. The other is when it is time to reset this counter as defined in Reset Account Lockout
Counter After setting. When Reset Account Lockout Counter After < ExtranetObservationWindow, an
account does not have any risk of being locked out by AD. However, if Reset Account Lockout Counter After >
ExtranetObservationWindow, there is a chance that an account may be locked out by AD but in a "delayed
fashion". It may take a while to get an account locked out by AD depending on your configuration as AD FS will
only allow one bad password attempt during its observation window until badPwdCount reaches Account
Lockout Threshold.
For more information, see Configuring Account Lockout.
Known Issues
There is a known issue where the AD user account cannot authenticate with AD FS because the badPwdCount
attribute is not replicated to the domain controller that ADFS is querying. See 2971171 for more details. You can
find all AD FS QFEs that have been released so far here.
Key points to remember

The Extranet Lockout feature only works for the extranet scenario where the authentication requests come
through the Web Application Proxy
The Extranet Lockout feature only applies to username & password authentication
AD FS does not keep any track of badPwdCount or users that are soft-locked out. AD FS uses AD for all state
tracking
AD FS performs a lookup for the badPwdCount attribute through LDAP call for the user on the PDC for every
authentication attempt
AD FS older than 2016 will fail if it cannot access the PDC. AD FS 2016 introduced improvements that will
allow AD FS to fall back to other domain controllers in case of the PDC is not available.
AD FS will allow authentication requests from extranet if badPwdCount < ExtranetLockoutThreshold
If badPwdCount >= ExtranetLockoutThreshold AND badPasswordTime +
ExtranetObservationWindow < Current time, AD FS will reject authentication requests from extranet
To avoid malicious account lockout, you should make sure ExtranetLockoutThreshold < Account Lockout
Threshold AND ExtranetObservationWindow > Reset Account Lockout Counter
Set-AdfsProperties
AD FS Operations
AD FS Extranet Lockout and Extranet Smart Lockout
Overview
Applies To: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
In AD FS on Windows Server 2012 R2, we introduced a security feature called Extranet Soft Lockout. With this
feature, AD FS stops authenticating users from the extranet for a period of time. This prevents your user accounts
from being locked out in Active Directory. In addition to protecting your users from an AD account lockout, AD FS
extranet lockout also protects against brute force password guessing attacks.
In June 2018, AD FS on Windows Server 2016 introduced Extranet Smart Lockout (ESL ). ESL enables AD FS to
differentiate between sign-in attempts that look like they're from the valid user and sign-ins from what may be an
attacker. As a result, AD FS can lock out attackers while letting valid users continue to use their accounts. This
prevents denial-of-service on the user and protects against targeted attacks such as "password-spray" attacks.
ESL is available for AD FS in Windows Server 2016 and is built into AD FS in Windows Server 2019.
NOTE
This feature only works for the extranet scenario in which authentication requests come through the Web Application Proxy
and only applies to username and password authentication.
Advantages of Extranet Smart Lockout in AD FS 2016

Extranet soft lockout in AD FS 2012 R2 provided the following key advantages:
Protects your user accounts from brute force attacks in which an attacker tries to guess a user's password by
continuously sending authentication requests and from password spray attacks where attackers attempt to
use common passwords with many different accounts
Protects your user accounts from Active Directory account lockout from malicious authentication requests
with wrong passwords. In this case, although the user account will be locked out for extranet access, the user can
still login to AD from the corporate network. This is known as a soft lockout.
Extranet Smart Lockout builds on the advantages of extranet soft lockout by adding the following:
Protects your users from experiencing extranet account lockout from malicious authentication requests.
Smart lockout will prevent potentially malicious requests from unfamiliar locations while allowing the real user
to sign on from the extranet from familiar locations (locations from which the user has successfully logged in
before).
Has a log only mode so that the system can learn good and potentially malicious signon activity without
disabling any accounts
Additional advantages of Extranet Smart Lockout in AD FS 2019

Extranet Smart Lockout in AD FS 2019 adds the following advantages compared to AD FS 2016:
Set independent lockout thresholds for familiar and unfamiliar locations so that users in known good locations
can have more room for error than requests from suspect locations
Enable audit mode for smart lockout while continuing to enforce previous soft lockout behavior
Pre-requisites for Extranet Smart Lockout in AD FS 2016

The following pre-requisites are required for ESL with AD FS 2019.
Install updates on all nodes in the farm
First, ensure all Windows Server 2016 AD FS servers are up to date as of the June 2018 Windows Updates and
that the AD FS 2016 farm is running at the 2016 farm behavior level.
Update artifact database permissions
Extranet smart lockout requires the AD FS service account to have permissions to a new table in the ADFS artifact
database. Grant this permission by executing the following command in a PowerShell command window:
PS C:\>$cred = Get-Credential
PS C:\>Update-AdfsArtifactDatabasePermission -Credential $cred
Where $cred is an account with AD FS administrator permissions (AD FS administrator permissions are required
to make the database change.)
NOTE
In a multiple server farm that uses the WID database, the above cmdlet requires that Windows Remote management be
enabled on every AD FS server
If you do not have AD FS administrator permissions, you can configure database permissions manually in SQL or
WID by running the following command when connected to the AdfsArtifactStore database.
sp_addrolemember 'db_owner', 'db_genevaservice'
Ensure AD FS Security Audit Logging is enabled

This feature makes use of Security Audit logs, so auditing must be enabled in AD FS as well as the local policy on
all AD FS servers.
Pre-requisites for Extranet Smart Lockout in AD FS 2019

The following pre-requisites are required for ESL with AD FS 2016.
Ensure AD FS Security Audit Logging is enabled
This feature makes use of Security Audit logs, so auditing must be enabled in AD FS as well as the local policy on
all AD FS servers.
Lockout Settings
Extranet smart lockout consists of a set of new capabilities governed by new and existing AD FS properties.
Extranet Lockout Enabled
Extranet smart lockout uses the same AD FS property that previously was used just to control “soft” extranet
lockout. The property is called ExtranetLockoutEnabled and can be viewed via Get-AdfsProperties.
Extranet Smart Lockout Mode
A new AD FS property called ExtranetLockoutMode has been added to control smart vs “soft” lockout behavior. It
can be set via Set-AdfsProperties and contains 3 values:
- **ADPasswordCounter** – This is the legacy ADFS “extranet soft lockout” mode which does not differentiate
based on location. This is the default value.
- **ADFSSmartLockoutLogOnly** – This is Extranet Smart Lockout, but instead of rejecting authentication

requests, AD FS will only write admin and audit events.
- **ADFSSmartLockoutEnforce** - This is Extranet Smart Lockout with full support for blocking unfamiliar
requests when the thresholds are reached.
In AD FS 2019, the values ADPasswordCounter and ADFSSmartLockoutLogOnly can be combined so that soft
lockout continues to be enforced while you are preparing for smart lockout.
Lockout Threshold and Observation Window
Smart lockout in AD FS 2019 uses the same two AD FS properties as soft lockout used previously:
ExtranetObservationWindow and ExtranetLockoutThreshold.
ExtranetLockoutThreshold <Integer> this defines the maximum number of bad password attempts. Once
the threshold is reached, in ADFSSmartLockoutEnforce mode AD FS will reject requests from the extranet until
the observation window has passed. In ADFSSmartLockoutLogOnly mode, AD FS will write log entries only.
ExtranetObservationWindow <TimeSpan> this determines for how long username and password requests
from unfamiliar locations will be locked out. AD FS will start to perform username and password authentication
again when the window is passed.
NOTE
AD FS extranet lockout functions independently from the AD lockout policies. We recommend that you set the
ExtranetLockoutThreshold parameter value to a value that is less than the AD account lockout threshold. Failing to do so
would result in AD FS being unable to protect accounts from being locked out in Active Directory.
In AD FS 2019, we have introduced a new lockout threshold specific to known good locations:
ExtranetLockoutThresholdFamiliarLocation.
ExtranetLockoutThresholdFamiliarLocation <Integer> this defines the maximum number of bad password
attempts from familiar locations. In AD FS 2019, the original parameter ExtranetLockoutThreshold applies to
unfamiliar locations (IP addresses not known to be good).
Primary Domain Controller Requirement
AD FS 2016 offers a parameter that allows fallback to another domain controller when the PDC is unavailable.
ExtranetLockoutRequirePDC <Boolean> When enabled, extranet lockout requires a primary domain
controller (PDC ). When disabled, extranet lockout will fallback to another domain controller in case the PDC
is unavailable.
The following example shows the cmdlet to enable lockout with the PDC requirement disabled:
Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow

(new-timespan -Minutes 30) -ExtranetLockoutRequirePDC $false
Configuring AD FS with Smart Lockout in Log Only Mode

AD FS 2016
We recommend that you first set the lockout behavior to log only by running the following cmdlet:
PS C:\>Set-AdfsProperties -ExtranetLockoutMode AdfsSmartlockoutLogOnly
In this mode, AD FS populates users familiar location information and writes security audit events, but does not
block any requests. This mode is used to validate that smart lockout is running and to enable AD FS to “learn”
familiar locations for users before enabling “enforce” mode. As AD FS learns, it stores login activity per user
(whether in log only mode or enforce mode).
NOTE
Configuring ExtranetLockoutMode to AdfsSmartlockoutLogOnly will cause the legacy AD FS “extranet soft lockout”
behavior to no longer be in effect, even if the EnableExtranetLockout property is set to True. This means that users who
exceed lockout thresholds from familiar or unfamiliar IP addresses will not be locked out. This is intended to be a temporary
state so that the system can learn login behavior prior to re-introducing lockout enforcement with the new smart lockout
behavior.
For the new mode to take effect, restart the AD FS service on all nodes in the farm
PS C:\>Restart-service adfssrv
Once the mode is configured, you can enable smart lockout using the EnableExtranetLockout parameter
PS C:\>Set-AdfsProperties -EnableExtranetLockout $true
Note that you can use the same cmdlet to disable lockout
Example: Disable lockout
PS C:\>Set-AdfsProperties -EnableExtranetLockout $false
AD FS 2019
If you are not presently using AD FS Extranet Soft Lockout, we recommend that you follow the same guidance as
for AD FS 2016 above. If you are using soft lockout, however, we recommend that you set the AD FS 2019 lockout
behavior to log for smart lockout, but keep enforcing soft lockout, using the below powershell:
PS C:\>Set-AdfsProperties -ExtranetLockoutMode 3
Once you execute this cmdlet, you can then use Get-AdfsProperties to query the value of the ExtranetLockoutMode
AD FS property. You will see that its value has been updated to a bitwise combination of ADPasswordCounter and
ADFSSmartLockoutLogOnly.
Observing Audit Events

AD FS will write extranet lockout events to the security audit log:
When a user is locked out (reaches the lockout threshold for unsuccessful login attempts)
When AD FS receives a login attempt for a user who is already in lockout state
While in log only mode, you can check the security audit log for lockout events. For any events found, you can
check the user state using the Get-ADFSAccountActivity cmdlet to determine if the lockout occurred from familiar
or unfamiliar IP addresses, and to double check the list of familiar IP addresses for that user.
Example event:
Log Name: Security

Source: AD FS Auditing
Date: 5/21/2018 12:55:59 AM
Event ID: 1210
Task Category: (3)
Level: Information
Keywords: Classic,Audit Failure
User: CONTOSO\adfssvc
Computer: ADFS2016FS1.corp.contoso.com
Description:
An extranet lockout event has occurred. See XML for failure details.
Activity ID: fa7a8052-0694-48f0-84e2-b51cde40ac3d
Additional Data
XML: <?xml version="1.0" encoding="utf-16"?>
<AuditBase xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ExtranetLockoutAudit">
<AuditType>ExtranetLockout</AuditType>
<AuditResult>Failure</AuditResult>
<FailureType>ExtranetLockoutError</FailureType>
<ErrorCode>AccountRestrictedAudit</ErrorCode>
<ContextComponents>
<Component xsi:type="ResourceAuditComponent">
<RelyingParty>http://fs.contoso.com/adfs/services/trust</RelyingParty>
<ClaimsProvider>N/A</ClaimsProvider>
<UserId>CONTOSO\user</UserId>
</Component>
<Component xsi:type="RequestAuditComponent">
<Server>N/A</Server>
<AuthProtocol>WSFederation</AuthProtocol>
<NetworkLocation>Extranet</NetworkLocation>
<IpAddress>64.187.173.10</IpAddress>
<ForwardedIpAddress>64.187.173.10</ForwardedIpAddress>
<ProxyIpAddress>N/A</ProxyIpAddress>
<NetworkIpAddress>N/A</NetworkIpAddress>
<ProxyServer>ADFS2016PROXY2</ProxyServer>
<UserAgentString>Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/66.0.3359.181 Safari/537.36</UserAgentString>
<Endpoint>/adfs/ls/</Endpoint>
</Component>
<Component xsi:type="LockoutConfigAuditComponent">
<CurrentBadPasswordCount>5</CurrentBadPasswordCount>
<ConfigBadPasswordCount>5</ConfigBadPasswordCount>
<LastBadAttempt>05/21/2018 00:55:05</LastBadAttempt>
<LockoutWindowConfig>00:30:00</LockoutWindowConfig>
</Component>
</ContextComponents>
</AuditBase>
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="AD FS Auditing" />
<EventID Qualifiers="0">1210</EventID>
<Level>0</Level>
<Task>3</Task>
<Keywords>0x8090000000000000</Keywords>
<TimeCreated SystemTime="2018-05-21T00:55:59.921880300Z" />
<EventRecordID>35521235</EventRecordID>
<Channel>Security</Channel>
<Computer>ADFS2016FS1.contoso.com</Computer>
<Security UserID="S-1-5-21-1156273042-1594504307-2076964089-1104" />
</System>
<EventData>
<Data>fa7a8052-0694-48f0-84e2-b51cde40ac3d</Data>
<Data><?xml version="1.0" encoding="utf-16"?>
<Data><?xml version="1.0" encoding="utf-16"?>
<ContextComponents>
<RelyingParty>http://fs.contoso.com/adfs/services/trust</RelyingParty>
<UserId>CONTOSO\user</UserId>
</Component>
<NetworkLocation>Extranet</NetworkLocation>
<ForwardedIpAddress>64.187.173.10</ForwardedIpAddress>
<ProxyIpAddress>N/A</ProxyIpAddress>
<NetworkIpAddress>N/A</NetworkIpAddress>
<ProxyServer>ADFS2016PROXY2</ProxyServer>
<Endpoint>/adfs/ls/</Endpoint>
</Component>
</Component>
</AuditBase></Data>
</EventData>
</Event>
Observing User Activity

AD FS provides powershell cmdlets to view and manage user account activity data. To read the current account
activity for a user account. Use the cmdlet below
PS C:\>Get-ADFSAccountActivity user@contoso.com
Example output
Identifier : CONTOSO\user
BadPwdCountFamiliar : 0
BadPwdCountUnknown : 0
LastFailedAuthFamiliar : 1/1/0001 12:00:00 AM
LastFailedAuthUnknown : 1/1/0001 12:00:00 AM
FamiliarLockout : False
UnknownLockout : False
FamiliarIps : {}
The current activity output contains the following data:

Identifier: this is the username
BadPwdCountFamiliar: this is the current count of incorrect password login attempts from IP addresses that
were on the list of “FamiliarIps” at the time of the attempt
BadPwdCountUnknown: this is the current count of incorrect password login attempts from IP addresses that
were not on the list of “FamiliarIps” at the time of the attempt
LastFailedAuthFamiliar: this is the time of the last incorrect password login attempt from an IP address that was
on the list of “FamiliarIps” at the time of the attempt
LastFailedAuthUnknown: this is the time of the last incorrect password login attempt from an IP address that
was not on the list of “FamiliarIps” at the time of the attempt
FamiliarLockout: this indicates if the user is currently in a state of lockout for correct password attempts from IP
addresses on the list of “FamiliarIps”
UnknownLockout: this indicates if the user is currently in a state of lockout for correct password attempts from IP
addresses not on the list of “FamiliarIps” FamiliarIps: this is the current list of familiar IP addresses for the user
Adjust threshold and window

Once you have been running in log only mode for a sufficient amount of time for AD FS to learn login locations,
you may wish to adjust the threshold or observation window from the default settings. This is done using
Set-AdfsProperties as in the examples below:
The observation window is set using ExtranetObservationWindow :

Example:
PS C:\>Set-AdfsProperties -ExtranetObservationWindow ( new-timespan -minutes 30 )
Where the value is a TimeSpan

Setting threshold value in AD FS 2016
In AD FS 2016, the threshold is set using ExtranetLockoutThreshold:
Example:
PS C:\>Set-AdfsProperties -ExtranetLockoutThreshold 5
Setting threshold values in AD FS 2019

In AD FS 2019, there are distinct threshold values for known good and unfamiliar locations
To set the threshold value for unfamiliar locations, use the same property used for AD FS 2016 above:
Example:
PS C:\>Set-AdfsProperties -ExtranetLockoutThreshold 5
To set the threshold value for known good locations, use the new property
ExtranetLockoutThresholdFamiliarLocation, as shown in the example below:
Example:
PS C:\>Set-AdfsProperties -ExtranetLockoutThresholdFamiliarLocation 10
Enable enforce mode

Once you have been running in log only mode for sufficient time for AD FS to learn login locations and to observe
any lockout activity, and once you are comfortable with the lockout threshold and observation window, smart
lockout can be moved to “enforce” mode using the PSH cmdlet below:
PS C:\>Set-AdfsProperties -ExtranetLockoutMode AdfsSmartLockoutEnforce
For the new mode to take effect, restart the AD FS service on all nodes in the farm
PS C:\>Restart-service adfssrv
Manage User Account Activity

AD FS provides 3 cmdlets to manage user account activity data. These cmdlets automatically connect to the node in
the farm which holds the master role (though this behavior can be overridden by passing the -Server parameter)
Get-ADFSAccountActivity
Read the current account activity for a user account. The cmdlet always automatically connects to the farm master
using the Account Activity REST endpoint, so all data should always be consistent
Get-ADFSAccountActivity user@contoso.com
Set-ADFSAccountActivity
Update the account activity for a user account. This can be used to add new familiar locations or erase state for any
account
Set-ADFSAccountActivity user@upnsuffix.com -FamiliarLocation “1.2.3.4”
Reset-ADFSAccountLockout
Resets the lockout counter for a user account
Reset-ADFSAccountLockout user@upnsuffix.com -Familiar
Troubleshooting ESL
The following can assist you with troubleshooting the extranet smart lockout feature.
Updating database permissions for ESL
If any errors are returned from the Update-AdfsArtifactDatabasePermission cmdlet, verify the following
1. The list of farm nodes is correct. If a node is in the AD FS farm list but no longer active patch verification will fail.
This can be remedied by running remove-adfsnode <node name >
2. Verify the patch is deployed on all nodes in the farm
3. Verify the credentials passed to the cmdlet have permission to modify the owner of the ad fs artifact database
schema.
Logging / Auditing
When an authentication request is rejected because the account exceeds the lockout threshold, AD FS will write an
ExtranetLockoutEvent to the security audit stream.
Example event:
An extranet lockout event has occurred. See XML for failure details.
Activity ID: 172332e1-1301-4e56-0e00-0080000000db
Additional Data
XML: <?xml version="1.0" encoding="utf-16"?>
<ContextComponents>
<RelyingParty>http://contoso.com/adfs/services/trust</RelyingParty>
<UserId>TQDFTD\Administrator</UserId>
</Component>
<NetworkLocation>Intranet</NetworkLocation>
<ForwardedIpAddress />
<ProxyIpAddress>1.2.3.4</ProxyIpAddress>
<NetworkIpAddress>1.2.3.4</NetworkIpAddress>
<ProxyServer>N/A</ProxyServer>
<Endpoint>/adfs/ls</Endpoint>
</Component>
</Component>
</AuditBase>
Banned IP addresses
In addition to the extranet smart lockout capabilities, the AD FS June 2018 update enables you to configure a set of
IP addresses globally in AD FS, so that requests coming from those IP addresses, or that have those IP addresses
in the x-forwarded-for or x-ms-forwarded-client-ip headers, will be blocked by AD FS.
A ddi n g ban n ed IPs
To add banned IPs to the global list, use the below Powershell cmdlet:
PS C:\ >Set-AdfsProperties -AddBannedIps "1.2.3.4", "::3", "1.2.3.4/16"
Allowed formats
1. IPv4
2. IPv6
3. CIDR format with IPv4 or v6
4. IP range with IPv4 or v6 ( i.e. 1.2.3.4-1.2.3.6 )
Removing banned IPs
To remove banned IPs from the global list, use the below Powershell cmdlet:
PS C:\ >Set-AdfsProperties -RemoveBannedIps "1.2.3.4"
Read banned IPs

To read the current set of banned IP addresses, use the below Powershell cmdlet:
PS C:\ >Get-AdfsProperties
Example output:
BannedIpList : {1.2.3.4, ::3,1.2.3.4/16}
Set-AdfsProperties
AD FS Operations
AD FS and banned IP addresses
In June 2018, AD FS on Windows Server 2016 introduced Banned IPs with the AD FS June 2018 update. This
update enables you to configure a set of IP addresses globally in AD FS, so that requests coming from those IP
addresses, or that have those IP addresses in the x-forwarded-for or x-ms-forwarded-client-ip headers, will be
blocked by AD FS.
Adding banned IPs

To add banned IPs to the global list, use the below Powershell cmdlet:
PS C:\ >Set-AdfsProperties -AddBannedIps "1.2.3.4", "::3", "1.2.3.4/16"
Allowed formats
1. IPv4
2. IPv6
3. CIDR format with IPv4 or v6
4. IP range with IPv4 or v6 ( i.e. 1.2.3.4-1.2.3.6 )
There is a limit of 300 entries for banned IP addresses. You can use CIDR or range format to deny a large block of
entries with a single entry.
Removing banned IPs

To remove banned IPs from the global list, use the below Powershell cmdlet:
PS C:\ >Set-AdfsProperties -RemoveBannedIps "1.2.3.4"
Read banned IPs

To read the current set of banned IP addresses, use the below Powershell cmdlet:
PS C:\ >Get-AdfsProperties
Example output:
BannedIpList : {1.2.3.4, ::3,1.2.3.4/16}
Set-AdfsProperties
AD FS Operations
Configure AD FS to authenticate users stored in LDAP
directories
The following topic describes the configuration required to enable your AD FS infrastructure to authenticate users
whose identities are stored in Lightweight Directory Access Protocol (LDAP ) v3-compliant directories.
In many organizations, identity management solutions consist of a combination of Active Directory, AD LDS, or
third-party LDAP directories. With the addition of AD FS support for authenticating users stored in LDAP v3-
compliant directories, you can benefit from the entire enterprise-grade AD FS feature set regardless of where your
user identities are stored. AD FS supports any LDAP v3-compliant directory.
NOTE
Some of the AD FS features include single sign-on (SSO), device authentication, flexible conditional access policies, support for
work-from-anywhere through the integration with the Web Application Proxy, and seamless federation with Azure AD which
in turn enables you and your users to utilize the cloud, including Office 365 and other SaaS applications. For more
information, see Active Directory Federation Services Overview.
In order for AD FS to authenticate users from an LDAP directory, you must connect this LDAP directory to your
AD FS farm by creating a local claims provider trust. A local claims provider trust is a trust object that represents
an LDAP directory in your AD FS farm. A local claims provider trust object consists of a variety of identifiers,
names, and rules that identify this LDAP directory to the local federation service.
You can support multiple LDAP directories, each with its own configuration, within the same AD FS farm by adding
multiple local claims provider trusts. In addition, AD DS forests that are not trusted by the forest that AD FS lives
in can also be modeled as local claims provider trusts. You can create local claims provider trusts by using Windows
PowerShell.
LDAP directories (local claims provider trusts) can co-exist with AD directories (claims provider trusts) on the same
AD FS server, within the same AD FS farm, therefore, a single instance of AD FS is capable of authenticating and
authorizing access for users that are stored in both AD and non-AD directories.
Only forms-based authentication is supported for authenticating users from LDAP directories. Certificate-based
and Integrated Windows authentication are not supported for authenticating users in LDAP directories.
All passive authorization protocols that are supported by AD FS, including SAML, WS -Federation, and OAuth are
also supported for identities that are stored in LDAP directories.
The WS -Trust active authorization protocol is also supported for identities that are stored in LDAP directories.
Configure AD FS to authenticate users stored in an LDAP directory

To configure your AD FS farm to authenticate users from an LDAP directory, you can complete the following steps:
1. First, configure a connection to your LDAP directory using the New-AdfsLdapServerConnection cmdlet:
$DirectoryCred = Get-Credential
$vendorDirectory = New-AdfsLdapServerConnection -HostName dirserver -Port 50000 -SslMode None -
AuthenticationMethod Basic -Credential $DirectoryCred
NOTE
It is recommended that you create a new connection object for each LDAP server you want to connect to. AD FS can
connect to multiple replica LDAP servers and automatically fail over in case a specific LDAP server is down. For such a
case, you can create one AdfsLdapServerConnection for each of these replica LDAP servers and then add the array of
connection objects using the -LdapServerConnection parameter of the Add-AdfsLocalClaimsProviderTrust
cmdlet.
NOTE: Your attempt to use Get-Credential and type in a DN and password to be used to bind to an LDAP
instance might result in a failure because the of the user interface requirement for specific input formats, for
example, domain\username or user@domain.tld. You can instead use the ConvertTo-SecureString cmdlet as
follows (the example below assumes uid=admin,ou=system as the DN of the credentials to be used to bind
to the LDAP instance):
$ldapuser = ConvertTo-SecureString -string "uid=admin,ou=system" -asplaintext -force

$DirectoryCred = Get-Credential -username $ldapuser -Message "Enter the credentials to bind to the LDAP
instance:"
Then enter the password for the uid=admin and complete the rest of the steps.
2. Next, you can perform the optional step of mapping LDAP attributes to the existing AD FS claims using the
New-AdfsLdapAttributeToClaimMapping cmdlet. In the example below, you map givenName, Surname,
and CommonName LDAP attributes to the AD FS claims:
#Map given name claim

$GivenName = New-AdfsLdapAttributeToClaimMapping -LdapAttribute givenName -ClaimType
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
# Map surname claim
$Surname = New-AdfsLdapAttributeToClaimMapping -LdapAttribute sn -ClaimType
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
# Map common name claim
$CommonName = New-AdfsLdapAttributeToClaimMapping -LdapAttribute cn -ClaimType
"http://schemas.xmlsoap.org/claims/CommonName"
This mapping is done in order to make attributes from the LDAP store available as claims in AD FS in order
to create conditional access control rules in AD FS. It also enables AD FS to work with custom schemas in
LDAP stores by providing an easy way to map LDAP attributes to claims.
3. Finally, you must register the LDAP store with AD FS as a local claims provider trust using the Add-
AdfsLocalClaimsProviderTrust cmdlet:
Add-AdfsLocalClaimsProviderTrust -Name "Vendors" -Identifier "urn:vendors" -Type Ldap
# Connection info
-LdapServerConnection $vendorDirectory
# How to locate user objects in directory

-UserObjectClass inetOrgPerson -UserContainer "CN=VendorsContainer,CN=VendorsPartition" -
LdapAuthenticationMethod Basic
# Claims for authenticated users

-AnchorClaimLdapAttribute mail -AnchorClaimType
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -LdapAttributeToClaimMapping @($GivenName,
$Surname, $CommonName)
# General claims provider properties

-AcceptanceTransformRules "c:[Type != ''] => issue(claim=c);" -Enabled $true
# Optional - supply user name suffix if you want to use Ws-Trust

-OrganizationalAccountSuffix "vendors.contoso.com"
In the example above, you are creating a local claims provider trust called "Vendors". You are specifying
connection information for AD FS to connect to the LDAP directory this local claims provider trust
represents by assigning $vendorDirectory to the -LdapServerConnection parameter. Note that in step one,
you've assigned $vendorDirectory a connection string to be used when connecting to your specific LDAP
directory. Finally, you are specifying that the $GivenName , $Surname , and $CommonName LDAP attributes
(which you mapped to the AD FS claims) are to be used for conditional access control, including multi-factor
authentication policies and issuance authorization rules, as well as for issuance via claims in AD FS -issued
security tokens. In order to use active protocols like Ws-Trust with AD FS, you must specify the
OrganizationalAccountSuffix parameter, which enables AD FS to disambiguate between local claims
provider trusts when servicing an active authorization request.
See Also
AD FS Operations
You can configure Active Directory Federation Services (AD FS ) to send password expiry claims to the relying party
trusts (applications) that are protected by ADFS. How these claims are used depends on the application. For
example, with Office 365 as your relying party, updates have been implemented to Exchange and Outlook to notify
federated users of their soon-to-be-expired passwords.
To configure AD FS to send password expiry claims to a relying party trust, you must add the following claim rules
to this relying party trust:
@RuleName = "Issue Password Expiry Claims"

c1:[Type == "http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime"]
=> issue(store = "_PasswordExpiryStore", types =
("http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime",
"http://schemas.microsoft.com/ws/2012/01/passwordexpirationdays",
"http://schemas.microsoft.com/ws/2012/01/passwordchangeurl"), query = "{0};", param = c1.Value);
NOTE
Password expiry claims are only available for username and password and Microsoft Passport for Work authentication types.
If the user authenticates using Windows integrated authentication and Passport is not configured, the claims will not be
available and the users will not see password expiry notifications.
NOTE
There is a 14 days window so the sent claims will only be populated if the password is expiring within 14 days.
See Also
AD FS Operations
Configure Additional Authentication Methods for AD
FS
In order to enable multi-factor authentication (MFA), you must select at least one additional authentication method.
By default, in Active Directory Federation Services (AD FS ) in Windows Server 2012 R2, you can select Certificate
Authentication (in other words, smart card-based authentication) as an additional authentication method.
NOTE
If you select Certificate Authentication, ensure that the smart card certificates have been provisioned securely and have pin
requirements.
Did you know that Microsoft Azure provides similar functionality in the cloud? Learn more about Microsoft Azure
identity solutions.
Create a hybrid identity solution in Microsoft Azure:

- Learn about Azure Multi-Factor Authentication.
- Manage identities for single-forest hybrid environments using cloud authentication.
- Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications.|
Microsoft and third-party additional authentication methods

You can also configure and enable Microsoft and third-party authentication methods in AD FS in Windows Server
2012 R2. Once installed and registered with AD FS, you can enforce MFA as part of the global or per-relying-party
authentication policy.
Below is an alphabetical list of Microsoft and third-party providers with MFA offerings currently available for AD
FS in Windows Server 2012 R2.
Provider Offering Link to learn more
Duo Security Duo MFA Adapter for AD FS Duo Authentication for AD FS
Gemalto Gemalto Identity & Security Services http://www.gemalto.com/identity
inWebo Technologies inWebo Enterprise Authentication inWebo Enterprise Authentication

service
Login People Login People MFA API connector for AD https://www.loginpeople.com

FS 2012 R2 (public beta)
Microsoft Corp. Microsoft Azure MFA Walkthrough Guide: Manage Risk with
Additional Multi-Factor Authentication
for Sensitive Applications (see step 3)
One Identity Starling 2FA AD FS Starling 2FA AD FS Adapter
One Identity Defender AD FS Defender AD FS Adapter
Ping Identity PingID MFA Adapter for AD FS PingID MFA Adapter for AD FS
RSA, The Security Division of EMC RSA SecurID Authentication Agent for RSA SecurID Authentication Agent for
Microsoft Active Directory Federation Microsoft Active Directory Federation
Services Services
SafeNet, Inc. SafeNet Authentication Service (SAS) SafeNet Authentication Service: AD FS

Agent for AD FS Agent Configuration Guide
Swisscom Mobile ID Authentication Service and Mobile ID Authentication Service

Signature Services
Symantec Symantec Validation and ID Protection Symantec Validation and ID Protection

Service (VIP) Service (VIP)
Trusona Essential (passwordless MFA) and Trusona Multi-factor Authentication

Executive (Essential + Identity Proofing)
Custom Authentication Method for AD FS in Windows Server 2012 R2

We now provide instructions for building your own custom authentication method for AD FS in Windows Server
2012 R2. For more information, see Build a Custom Authentication Method for AD FS in Windows Server 2012
R2.
See Also
In AD FS, in Windows Server 2012 R2, both access control and the authentication mechanism are enhanced with
multiple factors that include user, device, location, and authentication data. These enhancements enable you, either
through the user interface or through Windows PowerShell, to manage the risk of granting access permissions to
AD FS -secured applications via multi-factor access control and multi-factor authentication that are based on user
identity or group membership, network location, device data that is workplace-joined, and the authentication state
when multi-factor authentication (MFA) was performed.
For more information about MFA and multi-factor access control in Active Directory Federation Services (AD FS )
in Windows Server 2012 R2 , see the following topics:
Applications
Configure authentication policies via the AD FS Management snap-in

Membership in Administrators, or equivalent, on the local computer is the minimum requirement to complete
these procedures. Review details about using the appropriate accounts and group memberships at Local and
Domain Default Groups.
In AD FS, in Windows Server 2012 R2, you can specify an authentication policy at a global scope that is applicable
to all applications and services that are secured by AD FS. You can also set authentication policies for specific
applications and services that rely on party trusts and are secured by AD FS. Specifying an authentication policy for
a particular application per relying party trust does not override the global authentication policy. If either global or
per relying party trust authentication policy requires MFA, MFA is triggered when the user tries to authenticate to
this relying party trust. The global authentication policy is a fallback for relying party trusts for applications and
services that do not have a specific configured authentication policy.
To configure primary authentication globally in Windows Server 2012

R2
2. In AD FS snap-in, click Authentication Policies.
3. In the Primary Authentication section, click Edit next to Global Settings. You can also right-click
Authentication Policies, and select Edit Global Primary Authentication, or, under the Actions pane,
select Edit Global Primary Authentication.
4. In the Edit Global Authentication Policy window, on the Primary tab, you can configure the following
settings as part of the global authentication policy:
Authentication methods to be used for primary authentication. You can select available authentication
methods under the Extranet and Intranet.
Device authentication via the Enable device authentication check box. For more information, see
Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across
Company Applications.
To configure primary authentication per relying party trust
2. In AD FS snap-in, click Authentication Policies\Per Relying Party Trust, and then click the relying party
trust for which you want to configure authentication policies.
3. Either right-click the relying party trust for which you want to configure authentication policies, and then
select Edit Custom Primary Authentication, or, under the Actions pane, select Edit Custom Primary
Authentication.
4. In the Edit Authentication Policy for <relying_party_trust_name> window, under the Primary tab, you
can configure the following setting as part of the Per Relying Party Trust authentication policy:
Whether users are required to provide their credentials each time at sign-in via the Users are required
to provide their credentials each time at sign-in check box.
To configure multi-factor authentication globally

2. In AD FS snap-in, click Authentication Policies.
3. In the Multi-factor Authentication section, click Edit next to Global Settings. You can also right-click
Authentication Policies, and select Edit Global Multi-factor Authentication, or, under the Actions
pane, select Edit Global Multi-factor Authentication.
4. In the Edit Global Authentication Policy window, under the Multi-factor tab, you can configure the
following settings as part of the global multi-factor authentication policy:
Settings or conditions for MFA via available options under the Users/Groups, Devices, and
Locations sections.
To enable MFA for any of these settings, you must select at least one additional authentication
method. Certificate Authentication is the default available option. You can also configure other
custom additional authentication methods, for example, Windows Azure Active Authentication. For
more information, see Walkthrough Guide: Manage Risk with Additional Multi-Factor Authentication
for Sensitive Applications.
WARNING
You can only configure additional authentication methods globally.
To configure multi-factor authentication per relying party trust

2. In AD FS snap-in, click Authentication Policies\Per Relying Party Trust, and then click the relying party
trust for which you want to configure MFA.
3. Either right-click the relying party trust for which you want to configure MFA, and then select Edit Custom
Multi-factor Authentication, or, under the Actions pane, select Edit Custom Multi-factor
Authentication.
4. In the Edit Authentication Policy for <relying_party_trust_name> window, under the Multi-factor tab,
you can configure the following settings as part of the per-relying party trust authentication policy:
Settings or conditions for MFA via available options under the Users/Groups, Devices, and Locations
sections.
Configure authentication policies via Windows PowerShell

Windows PowerShell enables greater flexibility in using various factors of access control and the authentication
mechanism that are available in AD FS in Windows Server 2012 R2 to configure authentication policies and
authorization rules that are necessary to implement true conditional access for your AD FS -secured resources.
Membership in Administrators, or equivalent, on the local computer is the minimum requirement to complete
these procedures. Review details about using the appropriate accounts and group memberships at Local and
Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
To configure an additional authentication method via Windows PowerShell
1. On your federation server, open the Windows PowerShell command window and run the following command.
`Set-AdfsGlobalAuthenticationPolicy –AdditionalAuthenticationProvider CertificateAuthentication `
WARNING
To verify that this command ran successfully, you can run the Get-AdfsGlobalAuthenticationPolicy command.
To configure MFA per-relying party trust that is based on a user’s group membership data
1. On your federation server, open the Windows PowerShell command window and run the following command:
`$rp = Get-AdfsRelyingPartyTrust –Name relying_party_trust`
WARNING
Ensure to replace <relying_party_trust> with the name of your relying party trust.
$MfaClaimRule = “c:[Type == ‘“https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid’”, Value =~

‘“^(?i) <group_SID>$’”] => issue(Type =
‘“https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod’”, Value
‘“https://schemas.microsoft.com/claims/multipleauthn’”);”
Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules $MfaClaimRule
NOTE
Ensure to replace <group_SID> with the value of the security identifier (SID) of your Active Directory (AD) group.
To configure MFA globally based on users' group membership data

$MfaClaimRule = “c:[Type == ‘" https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid’", Value ==

‘"group_SID’"]
=> issue(Type = ‘"https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod’", Value =
‘"https://schemas.microsoft.com/claims/multipleauthn’");”
Set-AdfsAdditionalAuthenticationRule $MfaClaimRule
NOTE
Ensure to replace <group_SID> with the value of the SID of your AD group.
To configure MFA globally based on user’s location

$MfaClaimRule = “c:[Type == ‘" https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork’", Value ==

‘"true_or_false’"]
‘"https://schemas.microsoft.com/claims/multipleauthn’");”
NOTE
Ensure to replace <true_or_false> with either true or false . The value depends on your specific rule condition that is
based on whether the access request comes from the extranet or the intranet.
To configure MFA globally based on user’s device data

$MfaClaimRule = "c:[Type == ‘" https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser’",

Value == ‘"true_or_false"']
‘"https://schemas.microsoft.com/claims/multipleauthn’");"
NOTE
Ensure to replace <true_or_false> with either true or false . The value depends on your specific rule condition that is
based on whether the device is workplace-joined or not.
To configure MFA globally if the access request comes from the extranet and from a non-workplace -joined
device
`Set-AdfsAdditionalAuthenticationRule "c:[Type ==
'"https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser'", Value == '"true_or_false'"] &&
c2:[Type == '"https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork'", Value == '" true_or_false '"]
=> issue(Type = '"https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod'", Value
='"https://schemas.microsoft.com/claims/multipleauthn'");" `
NOTE
Ensure to replace both instances of <true_or_false> with either true or false , which depends on your specific rule
conditions. The rule conditions are based on whether the device is workplace-joined or not and whether the access request
comes from the extranet or intranet.
To configure MFA globally if access comes from an extranet user that belongs to a certain group
Set-AdfsAdditionalAuthenticationRule "c:[Type ==
`"https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid`", Value == `"group_SID`"] && c2:[Type ==
`"https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork`", Value== `"true_or_false`"] => issue(Type =
`"https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod`", Value
=`"https://schemas.microsoft.com/claims/
NOTE
Ensure to replace <group_SID> with the value of the group SID and <true_or_false> with either true or false , which
depends on your specific rule condition that is based on whether the access request comes from the extranet or intranet.
To grant access to an application based on user data via Windows PowerShell

1. On your federation server, open the Windows PowerShell command window and run the following
command.
$rp = Get-AdfsRelyingPartyTrust –Name relying_party_trust
NOTE
Ensure to replace <relying_party_trust> with the value of your relying party trust.
$GroupAuthzRule = "@RuleTemplate = `“Authorization`” @RuleName = `"Foo`" c:[Type ==

`"https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid`", Value =~ `"^(?i)<group_SID>$`"]
=>issue(Type = `"https://schemas.microsoft.com/authorization/claims/deny`", Value =
`"DenyUsersWithClaim`");"
Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –IssuanceAuthorizationRules $GroupAuthzRule
NOTE
Ensure to replace <group_SID> with the value of the SID of your AD group.
To grant access to an application that is secured by AD FS only if this user’s identity was validated with MFA
`$rp = Get-AdfsRelyingPartyTrust –Name relying_party_trust `
NOTE
$GroupAuthzRule = "@RuleTemplate = `"Authorization`"
@RuleName = `"PermitAccessWithMFA`"
c:[Type == `"https://schemas.microsoft.com/claims/authnmethodsreferences`", Value =~ `"^(?
i)https://schemas\.microsoft\.com/claims/multipleauthn$`"] => issue(Type =
`"https://schemas.microsoft.com/authorization/claims/permit`", Value = ‘“PermitUsersWithClaim’");"
To grant access to an application that is secured by AD FS only if the access request comes from a workplace -
joined device that is registered to the user
command.
$rp = Get-AdfsRelyingPartyTrust –Name relying_party_trust
NOTE

@RuleName = `"PermitAccessFromRegisteredWorkplaceJoinedDevice`"
c:[Type == `"https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser`", Value =~ `"^(?
i)true$`"] => issue(Type = `"https://schemas.microsoft.com/authorization/claims/permit`", Value =
`"PermitUsersWithClaim`");
To grant access to an application that is secured by AD FS only if the access request comes from a workplace -
joined device that is registered to a user whose identity has been validated with MFA
`$rp = Get-AdfsRelyingPartyTrust –Name relying_party_trust `
NOTE
$GroupAuthzRule = ‘@RuleTemplate = “Authorization”

@RuleName = “RequireMFAOnRegisteredWorkplaceJoinedDevice”
c1:[Type == `"https://schemas.microsoft.com/claims/authnmethodsreferences`", Value =~ `"^(?
i)http://schemas\.microsoft\.com/claims/multipleauthn$`"] &&
c2:[Type == `"https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser`", Value =~
`"^(?i)true$”] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit`", Value =
`"PermitUsersWithClaim`");"
To grant extranet access to an application secured by AD FS only if the access request comes from a user whose
identity has been validated with MFA
`$rp = Get-AdfsRelyingPartyTrust –Name relying_party_trust`

NOTE

@RuleName = `"RequireMFAForExtranetAccess`"
c1:[Type == `"https://schemas.microsoft.com/claims/authnmethodsreferences`", Value =~ `"^(?
i)http://schemas\.microsoft\.com/claims/multipleauthn$`"] &&
c2:[Type == `"https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork`", Value =~ `"^(?i)false$`"] =>
issue(Type = `"https://schemas.microsoft.com/authorization/claims/permit`", Value = `"PermitUsersWithClaim`");"
AD FS Operations
In a claims-based identity model, the function of Active Directory Federation Services (AD FS ) as federation
services is to issue a token that contains a set of claims. Claims rules govern the decisions with regard to claims that
AD FS issues. Claim rules and all server configuration data are stored in the AD FS configuration database.
AD FS makes issuance decisions that are based on identity information that is provided to it in the form of claims
and other contextual information. At a high level, AD FS operates as a rules processor by taking one set of claims as
input, performs a number of transformations, and then returns a different set of claims as output.
The following topics will assist you in creating the rules that AD FS will process:
Create a Rule to Pass Through or Filter an Incoming Claim
See Also
AD FS Operations
Configure On-Premises Conditional Access using
registered devices
The following document will guide you through installing and configuring on-premises conditional access with
registered devices.
Infrastructure pre-requisites
The following per-requisites are required before you can begin with on-premises conditional access.
REQUIREMENT DESCRIPTION
An Azure AD subscription with Azure AD Premium To enable device write back for on premises conditional access
- a free trial is fine
Intune subscription only required for MDM integration for device compliance
scenarios -a free trial is fine
Azure AD Connect November 2015 QFE or later. Get the latest version here.
Windows Server 2016 Build 10586 or newer for AD FS
Windows Server 2016 Active Directory schema Schema level 85 or higher is required.
Windows Server 2016 domain controller This is only required for Hello For Business key-trust
deployments. Additional information can be found at here.
REQUIREMENT DESCRIPTION
Windows 10 client Build 10586 or newer, joined to the above domain is required
for Windows 10 Domain Join and Microsoft Passport for Work
scenarios only
Azure AD user account with Azure AD Premium license For registering the device
assigned
Upgrade your Active Directory Schema

In order to use on-premises conditional access with registered devices, you must first upgrade your AD schema.
The following conditions must be met:
The schema should be version 85 or later
This is only required for the forest that AD FS is joined to
NOTE
If you installed Azure AD Connect prior to upgrading to the schema version (level 85 or greater) in Windows Server 2016, you
will need to re-run the Azure AD Connect installation and refresh the on-premises AD schema to ensure the synchronization
rule for msDS-KeyCredentialLink is configured.
Verify your schema level

To verify your schema level, do the following:
1. You can use ADSIEdit or LDP and connect to the Schema Naming Context.
2. Using ADSIEdit, right-click on "CN=Schema,CN=Configuration,DC=,DC= and select properties. Relpace
domain and the com portions with your forest information.
3. Under the Attribute Editor locate the objectVersion attribute and it will tell you, your version.
You can also use the following PowerShell cmdlet (replace the object with your schema naming context
information):
Get-ADObject "cn=schema,cn=configuration,dc=domain,dc=local" -Property objectVersion
For additional information on upgrading, see Upgrade Domain Controllers to Windows Server 2016.
Enable Azure AD Device Registration

To configure this scenario, you must configure the device registration capability in Azure AD.
To do this, follow the steps under Setting up Azure AD Join in your organization
Setup AD FS
1. Create the a new AD FS 2016 farm.
2. Or migrate a farm to AD FS 2016 from AD FS 2012 R2
3. Deploy Azure AD Connect using the Custom path to connect AD FS to Azure AD.
Configure Device Write Back and Device Authentication

NOTE
If you ran Azure AD Connect using Express Settings, the correct AD objects have been created for you. However, in most AD
FS scenarios, Azure AD Connect was run with Custom Settings to configure AD FS, so the below steps are necessary.
Create AD objects for AD FS Device Authentication

If your AD FS farm is not already configured for Device Authentication (you can see this in the AD FS Management
console under Service -> Device Registration), use the following steps to create the correct AD DS objects and
configuration.
Note: The below commands require Active Directory administration tools, so if your federation server is not
also a domain controller, first install the tools using step 1 below. Otherwise you can skip step 1.
1. Run the Add Roles & Features wizard and select feature Remote Server Administration Tools -> Role
Administration Tools -> AD DS and AD LDS Tools -> Choose both the Active Directory module for
Windows PowerShell and the AD DS Tools.
1. On your AD FS primary server, ensure you are logged in as AD DS user with Enterprise Admin (EA )
privileges and open an elevated powershell prompt. Then, execute the following PowerShell commands:
Import-module activedirectory
PS C:\> Initialize-ADDeviceRegistration -ServiceAccountName "<your service account>"
2. On the pop-up window hit Yes.
Note: If your AD FS service is configured to use a GMSA account, enter the account name in the format
"domain\accountname$"
The above PSH creates the following objects:

RegisteredDevices container under the AD domain partition
Device Registration Service container and object under Configuration --> Services --> Device Registration
Configuration
Device Registration Service DKM container and object under Configuration --> Services --> Device Registration
Configuration
1. Once this is done, you will see a successful completion message.
Create Service Connection Point (SCP) in AD

If you plan to use Windows 10 domain join (with automatic registration to Azure AD ) as described here, execute
the following commands to create a service connection point in AD DS
1. Open Windows PowerShell and execute the following:
PS C:>Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory
Connect\AdPrep\AdSyncPrep.psm1"
Note: if necessary, copy the AdSyncPrep.psm1 file from your Azure AD Connect server. This file is located in
Program Files\Microsoft Azure Active Directory Connect\AdPrep
1. Provide your Azure AD global administrator credentials
PS C:>$aadAdminCred = Get-Credential
1. Run the following PowerShell command

PS C:>Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount [AD connector account name] -
AzureADCredentials $aadAdminCred
Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when
adding your on-premises AD DS directory.
The above commands enable Windows 10 clients to find the correct Azure AD domain to join by creating the
serviceConnectionpoint object in AD DS.
Prepare AD for Device Write Back
To ensure AD DS objects and containers are in the correct state for write back of devices from Azure AD, do the
following.
1. Open Windows PowerShell and execute the following:
PS C:>Initialize-ADSyncDeviceWriteBack -DomainName <AD DS domain name> -AdConnectorAccount [AD connector
account name]
Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when
adding your on-premises AD DS directory in domain\accountname format
The above command creates the following objects for device write back to AD DS, if they do not exist already, and
allows access to the specified AD connector account name
RegisteredDevices container in the AD domain partition
Device Registration Service container and object under Configuration --> Services --> Device Registration
Configuration
Enable Device Write Back in Azure AD Connect
If you have not done so before, enable device write back in Azure AD Connect by running the wizard a second time
and selecting "Customize Synchronization Options", then checking the box for device write back and selecting
the forest in which you have run the above cmdlets
Configure Device Authentication in AD FS
Using an elevated PowerShell command window, configure AD FS policy by executing the following command
PS C:>Set-AdfsGlobalAuthenticationPolicy -DeviceAuthenticationEnabled $true -DeviceAuthenticationMethod All
Check your configuration

For your reference, below is a comprehensive list of the AD DS devices, containers and permissions required for
device write-back and authentication to work
object of type ms-DS -DeviceContainer at CN=RegisteredDevices,DC=<domain>
read access to the AD FS service account
read/write access to the Azure AD Connect sync AD connector account
Container CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=<domain>
Container Device Registration Service DKM under the above container
object of type serviceConnectionpoint at CN=<guid>, CN=Device Registration
Configuration,CN=Services,CN=Configuration,DC=<domain>
read/write access to the specified AD connector account name on the new object
object of type msDS -DeviceRegistrationServiceContainer at CN=Device Registration Services,CN=Device
Registration Configuration,CN=Services,CN=Configuration,DC=&ltdomain>
object of type msDS -DeviceRegistrationService in the above container
See it work
To evaluate the new claims and policies, first register a device. For example, you can Azure AD Join a Windows 10
computer using the Settings app under System -> About, or you can setup Windows 10 domain join with
automatic device registration following the additional steps here. For information on joining Windows 10 mobile
devices, see the document here.
For easiest evaluation, sign on to AD FS using a test application that shows a list of claims. You will be able to see
new claims including isManaged, isCompliant, and trusttype. If you enable Microsoft Passport for work, you will
also see the prt claim.
Configure Additional Scenarios

Automatic Registration for Windows 10 Domain Joined computers
To enable automatic device registration for Windows 10 domain joined computers, follow steps 1 and 2 here.
This will help you achieve the following:
1. Ensure your service connection point in AD DS exists and has the proper permissions (we created this object
above, but it does not hurt to double check).
2. Ensure AD FS is configured properly
3. Ensure your AD FS system has the correct endpoints enabled and claim rules configured
4. Configure the group policy settings required for automatic device registration of domain joined computers
Microsoft Passport for Work
For information on enabling Windows 10 with Microsoft Passport for Work, see Enable Microsoft Passport for
Work in your organization.
Automatic MDM enrollment
To enable automatic MDM enrollment of registered devices so that you can use the isCompliant claim in your
access control policy, follow the steps here.
Troubleshooting
1. if you get an error on Initialize-ADDeviceRegistration that complains about an object already existing in the
wrong state, such as "The drs service object has been found without all the required attributes", you may have
executed Azure AD Connect powershell commands previously and have a partial configuration in AD DS. Try
deleting manually the objects under CN=Device Registration
Configuration,CN=Services,CN=Configuration,DC=<domain> and trying again.
2. For Windows 10 domain joined clients
a. To verify that device authentication is working, sign on to the domain joined client as a test user account.
To trigger provisioning quickly, lock and unlock the desktop at least one time.
b. Instructions to check for stk key credential link on AD DS object (does sync still have to run twice?)
3. If you get an error upon trying to register a Windows computer that the device was already enrolled, but you
are unable or have already unenrolled the device, you may have a fragment of device enrollment configuration
in the registry. To investigate and remove this, use the following steps:
a. On the Windows computer, open Regedit and navigate to HKLM\Software\Microsoft\Enrollments
b. Under this key, there will be many subkeys in the GUID form. Navigate to the subkey which has ~17
values in it and has "EnrollmentType" of "6" [MDM joined] or "13" (Azure AD joined)
c. Modify EnrollmentType to 0
d. Try the device enrollment or registration again
Related Articles
Securing access to Office 365 and other apps connected to Azure Active Directory
Conditional access device policies for Office 365 services
Setting up on-premises conditional access using Azure Active Directory Device Registration
Connect domain-joined devices to Azure AD for Windows 10 experiences
Configuring intranet forms-based authentication for
devices that do not support WIA
By default, Windows Integrated Authentication (WIA) is enabled in Active Directory Federation Services (AD FS ) in
Windows Server 2012 R2 for authentication requests that occur within the organization’s internal network
(intranet) for any application that uses a browser for its authentication. For example, these can be browser-based
applications that use WS -Federation or SAML protocols and rich applications that use the OAuth protocol. WIA
provides end users with seamless logon to the applications without having to manually entering their credentials.
However, some devices and browsers are not capable of supporting WIA and as a result authentication requests
from these devices fail. Also, the experience on certain browsers that negotiate to NTLM is not desirable. The
recommended approach is to fallback to forms-based authentication for such devices and browsers.
AD FS in Windows Server 2016 and Windows Server 2012 R2 provides the administrators with the ability to
configure the list of user agents that support the fallback to forms-based authentication. The fallback is made
possible by two configurations:
The WIASupportedUserAgentStrings property of the Set-ADFSProperties commandlet
The WindowsIntegratedFallbackEnabled property of the Set-AdfsGlobalAuthenticationPolicy commandlet
The WIASupportedUserAgentStrings defines the user agents which support WIA. AD FS analyzes the user
agent string when performing logins in a browser or browser control. If the component of the user agent string
does not match any of the components of the user agent strings that are configured in
WIASupportedUserAgentStrings property, AD FS will fall back to providing forms-based authentication,
provided that the WindowsIntegratedFallbackEnabled flag is set to True.
By default, a new AD FS installation has a set of user agent string matches created. However, these may be out of
date based on changes to browsers and devices. Particularly, Windows devices have similar user agent strings with
minor variations in the tokens. The following Windows PowerShell example provides the best guidance for the
current set of devices that are on the market today that support seamless WIA:
Set-AdfsProperties -WIASupportedUserAgents @("MSIE 6.0", "MSIE 7.0; Windows NT", "MSIE 8.0", "MSIE 9.0", "MSIE
10.0; Windows NT 6", "Windows NT 6.3; Trident/7.0", "Windows NT 6.3; Win64; x64; Trident/7.0", "Windows NT 6.3;
WOW64; Trident/7.0", "Windows NT 6.2; Trident/7.0", "Windows NT 6.2; Win64; x64; Trident/7.0", "Windows NT 6.2;
WOW64; Trident/7.0", "Windows NT 6.1; Trident/7.0", "Windows NT 6.1; Win64; x64; Trident/7.0", "Windows NT 6.1;
WOW64; Trident/7.0", "MSIPC", "Windows Rights Management Client")
The command above will ensure that AD FS only covers the following use cases for WIA:
USER AGENTS USE CASES
MSIE 6.0 IE 6.0
MSIE 7.0; Windows NT IE 7, IE in intranet zone. The “Windows NT” fragment is sent by
desktop operation system.
MSIE 8.0 IE 8.0 (no devices send this, so need to make more specific)
USER AGENTS USE CASES
MSIE 9.0 IE 9.0 (no devices send this, so no need to make this more
specific)
MSIE 10.0; Windows NT 6 IE 10.0 for Windows XP and newer versions of desktop
operating system
Windows Phone 8.0 devices (with preference set to mobile) are
excluded because they send
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows

Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA;
Lumia 920)
Windows NT 6.3; Trident/7.0 Windows 8.1 desktop operating system, different platforms
Windows NT 6.3; Win64; x64; Trident/7.0
Windows NT 6.3; WOW64; Trident/7.0
Windows NT 6.2; Trident/7.0 Windows 8 desktop operating system, different platforms

Windows NT 6.1; Trident/7.0 Windows 7 desktop operating system, different platforms

MSIPC Microsoft Information Protection and Control Client
Windows Rights Management Client Windows Rights Management Client
In order to enable fallback to form based authentication for user agents other than those mentioned in the
WIASupportedUserAgents string, set the WindowsIntegratedFallbackEnabled flag to true
Set-AdfsGlobalAuthenticationPolicy -WindowsIntegratedFallbackEnabled $true
Also ensure that the forms based authentication is enabled for intranet.
Configuring WIA for Chrome

You can add Chrome or other user agents to the AD FS configuration that supports WIA. This enables seamless
logon to applications without having to manually enter credentials when you access resources protected by AD FS.
Follow the steps below to enable WIA on Chrome:
Add a user agent string for Chrome in AD FS configuration
Set-AdfsProperties -WIASupportedUserAgents ((Get-ADFSProperties | Select -ExpandProperty

WIASupportedUserAgents) + “Chrome”)
Confirm that the user agent string for Chrome is now set in the AD FS properties
Get-AdfsProperties | Select -ExpandProperty WIASupportedUserAgents

NOTE
As new browsers and devices are released, it is recommended that you reconcile the capabilities of those user agents and
update the AD FS configuration accordingly to optimize the user’s authentication experience when using said browser and
devices. More specifically, it is recommended that you re-evaluate the WIASupportedUserAgents setting in AD FS when
adding a new device or browser type to your support matrix for WIA.
Applies To: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
What is Alternate Login ID?

In most scenarios, users use their UPN (User Principal Names) to login to their accounts. However, in some
environments due to corporate policies or on-premises line-of-business application dependencies, the users may
be using some other form of sign-in.
NOTE
Microsoft’s recommended best practices are to match UPN to primary SMTP address. This article addresses the small
percentage of customers that cannot remediate UPN’s to match.
For example, they can be using their email-id for sign-in and that can be different from their UPN. This is
particularly a common occurrence in scenarios where their UPN is non-routable. Consider a user Jane Doe with
UPN jdoe@contoso.local and email address jdoe@contoso.com. Jane might not be even aware of the UPN as she
has always used her email id for signing-in. Use of any other sign-in method instead of UPN constitutes alternate
ID. For more information on how the UPN is creates see, Azure AD UserPrincipalName population.
Active Directory Federation Services (AD FS ) enables federated applications using AD FS to sign-in using alternate
ID. This enables administrators to specify an alternative to the default UPN to be used for sign-in. AD FS already
supports using any form of user identifier that is accepted by Active Directory Domain Services (AD DS ). When
configured for alternate ID, AD FS allows users to sign in using the configured alternate ID value, say email-id.
Using the alternate ID enables you to adopt SaaS providers, such as Office 365 without modifying your on-
premises UPNs. It also enables you to support line-of-business service applications with consumer-provisioned
identities.
Alternate id in Azure AD
An organization may have to use alternate ID in the following scenarios:
1. The on-premises domain name is non-routable, ex. Contoso.local and as a result the default user principal name
is non-routable (jdoe@contoso.local). Existing UPN cannot be changed due to local application dependencies or
company policies. Azure AD and Office 365 require all domain suffixes associated with Azure AD directory to be
fully internet routable.
2. The on-premises UPN is not same as the user’s email address and to sign-in to Office 365, users use email
address and UPN cannot be used due to organizational constraints. In the above-mentioned scenarios, alternate
ID with AD FS enables users to sign-in to Azure AD without modifying your on-premises UPNs.
End-User Experience with Alternate Login ID

The end-user experience varies depending on the authentication method used with alternate login id. Currently
there three different ways in which using alternate login id can be achieved. They are:
Regular Authentication (Legacy)- uses the basic authentication protocol.
Modern Authentication - brings Active Directory Authentication Library (ADAL )-based sign-in to
applications. This enables sign-in features such as Multi-Factor Authentication (MFA), SAML -based third-party
Identity Providers with Office client applications, smart card and certificate-based authentication.
Hybrid Modern Authentication - Provides all of the benefits of Modern Authentication and provides users
the ability to access on-premises applications using authorization tokens obtained from the cloud.
NOTE
For the best possible experience, Microsoft highly recommends Hybrid Modern Authentication.
Configure alternate logon ID

Using Azure AD Connect We recommend using Azure AD connect to configure alternate logon ID for your
environment.
For new configuration of Azure AD Connect, see Connect to Azure AD for detailed instruction on how to
configure alternate ID and AD FS farm.
For existing Azure AD Connect installations, see Changing the user sign-in method for instructions on changing
sign-in method to AD FS
When Azure AD Connect is provided details about AD FS environment, it automatically checks for the presence of
the right KB on your AD FS and configures AD FS for alternate ID including all necessary right claim rules for
Azure AD federation trust. There is no additional step required outside wizard to configure alternate ID.
NOTE
Microsoft recommends using Azure AD Connect to configure alternate logon ID.
Manually configure alternate ID

In order to configure alternate login ID, you must perform the following tasks: Configure your AD FS claims
provider trusts to enable alternate login ID
1. If you have Server 2012R2, ensure you have KB2919355 installed on all the AD FS servers. You can get it
via Windows Update Services or download it directly.
2. Update the AD FS configuration by running the following PowerShell cmdlet on any of the federation
servers in your farm (if you have a WID farm, you must run this command on the primary AD FS server in
your farm):
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID <attribute> -LookupForests

<forest domain>
AlternateLoginID is the LDAP name of the attribute that you want to use for login.
LookupForests is the list of forest DNS that your users belong to.
To enable alternate login ID feature, you must configure both -AlternateLoginID and -LookupForests parameters
with a non-null, valid value.
In the following example, you are enabling alternate login ID functionality such that your users with accounts in
contoso.com and fabrikam.com forests can log in to AD FS -enabled applications with their "mail" attribute.
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID mail -LookupForests

contoso.com,fabrikam.com
1. To disable this feature, set the value for both parameters to be null.
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID $NULL -LookupForests $NULL
Hybrid Modern Authentication with Alternate-ID

IMPORTANT
The following has only been tested against AD FS and not 3rd party identity providers.
Exchange and Skype for Business

If you are using alternate login id with Exchange and Skype for Business, the user experience varies depending on
whether or not you are using HMA.
NOTE
For the best end-user experience, Microsoft recommends using Hybrid Modern Authentication.
or more information see, Hybrid Modern Authentication Overview

Pre -requisites for Exchange and Skype for Business
The following are pre-requisites for achieving SSO with alternate ID.
Exchange Online should have Modern Authentication turned ON.
Skype for Business (SFB ) Online should have Modern Authentication turned ON.
Exchange on-premises should have Modern Authentication turned ON. Exchange 2013 CU19 or Exchange
2016 CU18 and up is required on all Exchange servers. No Exchange 2010 in the environment.
Skype for Business on-premises should have Modern Authentication turned ON.
You must use Exchange and Skype clients that have Modern Authentication enabled. All servers must be
running SFB Server 2015 CU5.
Skype for Business Clients that are Modern Authentication capable
iOS, Android, Windows Phone
SFB 2016 (MA is ON by default, but make sure it has not been disabled.)
SFB 2013 (MA is OFF by default, so ensure MA has been turned ON.)
SFB Mac desktop
Exchange Clients that are Modern Authentication capable and support AltID regkeys
Office Pro Plus 2016 only
Supported Office version
Configuring your directory for SSO with alternate-id Using alternate-id can cause extra prompts for authentication
if these additional configurations are not completed. Refer to the article for possible impact on user experience with
alternate-id.
With the following additional configuration, the user experience is improved significantly, and you can achieve near
zero prompts for authentication for alternate-id users in your organization.
St e p 1 . U p d a t e t o r e q u i r e d o ffi c e v e r si o n
Office version 1712 (build no 8827.2148) and above have updated the authentication logic to handle the alternate-
id scenario. In order to leverage the new logic, the client machines need to be updated to office version 1712 (build
no 8827.2148) and above.
St e p 2 . C o n fi g u r e r e g i st r y fo r i m p a c t e d u se r s u si n g g r o u p p o l i c y
The office applications rely on information pushed by the directory administrator to identify the alternate-id
environment. The following registry keys need to be configured to help office applications authenticate the user
with alternate-id without showing any extra prompts
REGKEY DATA NAME,

REGKEY TO ADD TYPE, AND VALUE WINDOWS 7/8 WINDOWS 10 DESCRIPTION
HKEY_CURRENT_USER DomainHint Required Required The value of this

\Software\Microsoft\A REG_SZ regkey is a verified
uth contoso.com custom domain name
in the tenant of the
organization. For
example, Contoso
corp can provide a
value of Contoso.com
in this regkey if
Contoso.com is one of
the verified custom
domain names in the
tenant
Contoso.onmicrosoft.c
om.
HKEY_CURRENT_USER EnableAlternateIdSup Required for Outlook Required for Outlook The value of this
\Software\Microsoft\ port 2016 ProPlus 2016 ProPlus regkey can be 1 / 0 to
Office\16.0\Common\ REG_DWORD indicate to Outlook
Identity 1 application whether it
should engage the
improved alternate-id
authentication logic.
HKEY_CURRENT_USER DisableADALatopWA Not applicable Required. This ensures that

\SOFTWARE\Microsof MOverride Office does not use
t\Office\16.0\Commo REG_DWORD WAM as alt-id is not
n\Identity 1 supported by WAM.
HKEY_CURRENT_USER DisableAADWAM Not applicable Required. This ensures that

\SOFTWARE\Microsof REG_DWORD Office does not use
t\Office\16.0\Commo 1 WAM as alt-id is not
n\Identity supported by WAM.
HKEY_CURRENT_USER * Required Required This regkey can be

\Software\Microsoft\ REG_DWORD used to set the STS as
Windows\CurrentVers 1 a trusted Zone in the
ion\Internet internet settings.
Settings\ZoneMap\Do Standard ADFS
mains\contoso.com\st deployment
s recommends adding
the ADFS namespace
to the Local Intranet
Zone for Internet
Explorer
New authentication flow after additional configuration

1. a: User is provisioned in Azure AD using alternate-id
b: Directory administrator pushes required regkey settings to impacted client machines
2. User authenticates on the local machine and opens an office application
3. Office application takes the local session credentials
4. Office application authenticates to Azure AD using domain hint pushed by administrator and local credentials
5. Azure AD successfully authenticates the user by directing to correct federation realm and issue a token
Applications and user experience after the additional configuration

Non-Exchange and Skype for Business Clients
CLIENT SUPPORT STATEMENT REMARKS
Microsoft Teams Supported Microsoft Teams supports AD FS

(SAML-P, WS-Fed, WS-Trust, and
OAuth) and Modern Authentication.
Core Microsoft Teams such as
Channels, chats and files functionalities
does work with Alternate Login ID.
1st and 3rd party apps must be
separately investigated by the customer.
This is because each application has
their own supportability authentication
protocols.
OneDrive for Business Supported - client-side registry key With Alternate ID configured you see
recommended the on-premises UPN is pre-populated
In the verification field. This needs to be
changed to the alternate Identity that is
being used. We recommend using the
client side registry key noted in this
article: Office 2013 and Lync 2013
periodically prompt for credentials to
SharePoint Online, OneDrive, and Lync
Online.
OneDrive for Business Mobile Client Supported

CLIENT SUPPORT STATEMENT REMARKS
Office 365 Pro Plus activation page Supported - client-side registry key With Alternate ID configured you see
recommended the on-premises UPN is pre-populated
in the verification field. This needs to be
changed to the alternate Identity that is
being used. We recommend using the
client-side registry key noted in this
article: Office 2013 and Lync 2013
periodically prompt for credentials to
SharePoint Online, OneDrive, and Lync
Online.
Exchange and Skype for Business Clients

CLIENT SUPPORT STATEMENT - WITH HMA SUPPORT STATEMENT - WITHOUT HMA
Outlook Supported, no extra prompts Supported

With Modern Authentication for
Exchange Online: Supported
With regular authentication for

Exchange Online: Supported with
following caveats:
You must be on a domain joined
machine and connected to the
corporate network
You can only use Alternate ID in
environments that do not allow external
access for mailbox users. This means
that users can only authenticate to their
mailbox in a supported way when they
are connected and joined to the
corporate network, on a VPN, or
connected via Direct Access machines,
but you get a couple of extra prompts
when configuring your Outlook profile.
Hybrid Public Folders Supported, no extra prompts. With Modern Authentication for
Exchange Online: Supported
With regular authentication for
Exchange Online: Not Supported
Hybrid Public Folders are not able to

expand if Alternate ID's are used and
therefore should not be used today with
regular authentication methods.
Cross premises Delegation See Configure Exchange to support See Configure Exchange to support
delegated mailbox permissions in a delegated mailbox permissions in a
hybrid deployment hybrid deployment
Archive mailbox access (Mailbox on- Supported, no extra prompts Supported - Users get an extra prompt
premises - archive in the cloud) for credentials when accessing the
archive, they have to provide their
alternate ID when prompted.
Outlook Web Access Supported Supported

CLIENT SUPPORT STATEMENT - WITH HMA SUPPORT STATEMENT - WITHOUT HMA
Outlook Mobile Apps for Android, IOS, Supported Supported

and Windows Phone
Skype for Business/ Lync Supported, with no extra prompts Supported (except as noted) but there is
a potential for user confusion.
On mobile clients, Alternate Id is
supported only if SIP address= email
address = Alternate ID.
Users may need to sign-in twice to the

Skype for Business desktop client, first
using the on-premises UPN and then
using the Alternate ID. (Note that the
“Sign-in address” is actually the SIP
address which may not be the same as
the “User name”, though often is). When
first prompted for a User name, the user
should enter the UPN, even if it is
incorrectly pre-populated with the
Alternate ID or SIP address. After the
user clicks sign-in with the UPN, the
User name prompt reappears, this time
prepopulated with the UPN. This time
the user must replace this with the
Alternate ID and click Sign in to
complete the sign in process. On mobile
clients, users should enter the on-
premises user ID in the advanced page,
using SAM-style format
(domain\username), not UPN format.
After successful sign-in, if Skype for

Business or Lync says "Exchange needs
your credentials", you need to provide
the credentials that are valid for where
the mailbox is located. If the mailbox is
in the cloud you need to provide the
Alternate ID. If the Mailbox is on-
premises you need to provide the on-
premises UPN.
Additional Details & Considerations

The Alternate login ID feature is available for federated environments with AD FS deployed. It is not
supported in the following scenarios:
Non-routable domains (e.g. Contoso.local) that cannot be verified by Azure AD.
Managed environments that do not have AD FS deployed.
When enabled, the alternate login ID feature is only available for username/password authentication across
all the user name/password authentication protocols supported by AD FS (SAML -P, WS -Fed, WS -Trust, and
OAuth).
When Windows Integrated Authentication (WIA) is performed (for example, when users try to access a
corporate application on a domain-joined machine from intranet and AD FS administrator has configured
the authentication policy to use WIA for intranet), UPN isused for authentication. If you have configured any
claim rules for the relying parties for alternate login ID feature, you should make sure those rules are still
valid in the WIA case.
When enabled, the alternate login ID feature requires at least one global catalog server to be reachable from
the AD FS server for each user account forest that AD FS supports. Failure to reach a global catalog server
in the user account forest results in AD FS falling back to use UPN. By default all the domain controllers are
global catalog servers.
When enabled, if the AD FS server finds more than one user object with the same alternate login ID value
specified across all the configured user account forests, it fails the login.
When alternate login ID feature is enabled, AD FS tries to authenticate the end user with alternate login ID
first and then fall back to use UPN if it cannot find an account that can be identified by the alternate login ID.
You should make sure there are no clashes between the alternate login ID and the UPN if you want to still
support the UPN login. For example, setting one's mail attribute with the other's UPN blocks the other user
from signing in with his UPN.
If one of the forests that is configured by the administrator is down, AD FS continues to look up user
account with alternate login ID in other forests that are configured. If AD FS server finds a unique user
objects across the forests that it has searched, a user logs in successfully.
You may additionally want to customize the AD FS sign-in page to give end users some hint about the
alternate login ID. You can do it by either adding the customized sign-in page description (for more
information, see Customizing the AD FS Sign-in Pages or customizing "Sign in with organizational account"
string above username field (for more information, see Advanced Customization of AD FS Sign-in Pages.
The new claim type that contains the alternate login ID value is
http:schemas.microsoft.com/ws/2013/11/alternateloginid
Events and Performance Counters

The following performance counters have been added to measure the performance of AD FS servers when
alternate login ID is enabled:
Alternate Login Id Authentications: number of authentications performed by using alternate login ID
Alternate Login Id Authentications/Sec: number of authentications performed by using alternate login ID
per second
Average Search Latency for Alternate Login ID: average search latency across the forests that an
administrator has configured for alternate login ID
The following are various error cases and corresponding impact on a user's sign-in experience with events logged
by AD FS:
ERROR CASES IMPACT ON SIGN-IN EXPERIENCE EVENT
Unable to get a value for Login failure Event ID 364 with exception message
SAMAccountName for the user object MSIS8012: Unable to find
samAccountName for the user: '{0}'.
The CanonicalName attribute is not Login failure Event ID 364 with exception message
accessible MSIS8013: CanonicalName: '{0}' of the
user:'{1}' is in bad format.
Multiple user objects are found in one Login failure Event ID 364 with exception message
forests MSIS8015: Found multiple user
accounts with identity '{0}' in forest '{1}'
with identities: {2}
ERROR CASES IMPACT ON SIGN-IN EXPERIENCE EVENT
Multiple user objects are found across Login failure Event ID 364 with exception message
multiple forests MSIS8014: Found multiple user
accounts with identity '{0}' in forests: {1}
See Also
AD FS Operations
Default Groups.


NOTE


See Also
AD FS Operations
Create a Non-Claims-Aware Relying Party Trust
In the AD FS Management snap-in, non-claims-aware relying party trusts are objects that are created to represent
the trust between the federation service and a single web-based application that is not claims-aware and that is
accessed through the Web Application Proxy.
A non-claims-aware relying party trust is a relying party trust which consists of identifiers, names, and rules for
authentication and authorization when the relying party trust is accessed through the Web Application Proxy. These
web-based applications that do not rely on claims, in other words, these Integrated Windows Authentication-based
applications, can have authorization rules that enforce access that is based on claims when the access is external to
the corporate network through the Web Application Proxy.
To add a new non-claims-aware relying party trust, by using the AD FS Management snap-in, perform the
following procedure.
Default Groups.
To create a non-claims aware Relying Party Trust manually

3. On the Welcome page, choose Non claims aware and click Start.
information.
See Also
AD FS Operations
metadata.

Default Groups.

Next.
click Next.
information.

NOTE
Default Groups.

information.
references.
See Also
AD FS Operations
Device authentication controls in AD FS
The following document shows how to enable device authentication controls in Windows Server 2016 and 2012
R2.
Device Authentication controls in AD FS 2012 R2

Originally in AD FS 2012 R2 there was one global authentication property called DeviceAuthenticationEnabled that
controlled device authentication.
To configure the setting, the Set-AdfsGlobalAuthenticationPolicy cmdlet was used as shown below:
PS:\>Set-AdfsGlobalAuthenticationPolicy –DeviceAuthenticationEnabled $true
To disable device authentication, the same cmdlet was used to set the value to $false.
Device Authentication controls in AD FS 2016

The only type of device authentication supported in 2012 R2 was clientTLS. In AD FS 2016, in addition to clientTLS
there are two new types of device authentication for modern devices authentication. These are:
PKeyAuth
PRT
To control the new behavior, the DeviceAuthenticationEnabled property is used in combination with a new property
called DeviceAuthenticationMethod .
The device authentication method determines the type of device authentication that will be done: PRT, PKeyAuth,
clientTLS, or some combination. It has the following values:
SignedToken: PRT only
PKeyAuth: PRT + PKeyAuth
ClientTLS: PRT + clientTLS
All: All of the above
As you can see, PRT is part of all device authentication methods, making it in effect the default method that is
always enabled when DeviceAuthenticationEnabled is set to $true .
Example: To configure the method(s), use the DeviceAuthenticationEnabled cmdlet as above, along with new
property:
PS:\>Set-AdfsGlobalAuthenticationPolicy –DeviceAuthenticationEnabled $true
NOTE
Enabling device authentication (setting DeviceAuthenticationEnabled to $true ) means the
DeviceAuthenticationMethod is implicitly set to SignedToken , which equates to PRT.
PS:\>Set-AdfsGlobalAuthenticationPolicy –DeviceAuthenticationMethod All
NOTE
The default device authentication method is SignedToken . Other values are PKeyAuth,ClientTLS, and All.
The meanings of the DeviceAuthenticationMethod values have changed slightly since AD FS 2016 was released. See
the table below for the meaning of each value, depending on the update level:
AD FS VERSION DEVICEAUTHENTICATIONMETHOD VALUE MEANS
2016 RTM SignedToken PRT + PkeyAuth
clientTLS clientTLS
All PRT + PkeyAuth + clientTLS
2016 RTM + up to date with Windows SignedToken (changed meaning) PRT (only)
Update
PkeyAuth (new) PRT + PkeyAuth
clientTLS PRT + clientTLS
All PRT + PkeyAuth + clientTLS
See Also
AD FS Operations
AD FS in Windows Server 2016 contains additional SAML protocol support, including support for importing trusts
based on metadata that contains multiple entities. This enables you to configure AD FS to participate in
confederations such as InCommon Federation and other implementations conforming to the eGov 2.0 standard.
The new capability is based on groups of relying party or claims provider trusts. Each group is an EntitiesDescriptor
(<md:EntitiesDescriptor>) element as specified in the eGov 2.0 profile, containing one or many EntityDescriptor
elements. The groups have common authorization rules, and all other properties can be modified like individual
trust objects.
Once the trust groups are imported into AD FS, AD FS automatically updates the trusts as a group based on the
metadata document.
Enabling these scenarios is as simple as using the new PowerShell commandlets that Add and Remove
AdfsClaimsProviderTrustsGroup and AdfsRelyingPartyTrustsGroup objects. This can be done using a metadata
URL or a file, as shown in the examples below.
Additionally, AD FS 2016 has support for the scoping parameter as described in the SAML Core specification,
section 3.4.1.2. This element allows relying parties to specify one or more identity providers for an authentication
request.
Examples
Add-AdfsClaimsProviderTrustsGroup -MetadataUrl "https://www.contosoconsortium.com/metadata/metadata.xml"
Add-AdfsClaimsProviderTrustsGroup -MetadataFile "C:\metadata.xml"
References
The eGov 2.0 profile can be found here.
The SAML Core specification can be found here.
Join to Workplace from Any Device for SSO and
Seamless Second Factor Authentication Across
Company Applications
The rapid increase in the number of consumer devices and ubiquitous information access is changing the way that
people perceive their technology. The constant use of information technology throughout the day, along with easy
access of information, is blurring traditional boundaries between work and home life. These shifting boundaries are
accompanied by a belief that personal technology-selected and customized to fit users' personalities, activities, and
schedules-should extend into the workplace. To accommodate the growing requirement of personal consumer
devices to be connected to enterprise networks, we are introducing the following value propositions:
Administrators can control who has access to company resources that are based on application, user, device,
and location.
Employees can access applications and data everywhere, on any device. Employees can use Single Sign-On
in browser applications or enterprise applications.
Key concepts introduced in the solution

Workplace Join
By using Workplace Join, information workers can join their personal devices with their company's workplace
computers to access company resources and services. When you join your personal device to your workplace, it
becomes a known device and provides seamless second factor authentication and Single Sign-On to workplace
resources and applications. When a device is joined by Workplace Join, attributes of the device can be retrieved
from the directory to drive conditional access for the purpose of authorizing issuance of security tokens for
applications. Windows 8.1 and iOS 6.0+, and Android 4.0+ devices can be joined by using Workplace Join.
Azure Active Directory Device Registration service
Workplace Join is made possible by the Azure Active Directory Device Registration service. When a device is joined
by Workplace Join, the service provisions a device object in Azure Active Directory and then sets a key on the local
device that is used to represent the device identity. This device identity can then be used with access control rules
for applications that are hosted in the cloud and on-premises.
For more details, see Introduction to device management in Azure Active Directory.
Workplace Join as a seamless second factor authentication
Companies can manage the risk that is related to information access and drive governance and compliance while
granting consumer devices access to corporate resources. Workplace Join on devices provides the following
capabilities to administrators:
Identifies known devices with device authentication. Administrators can use this information to drive
conditional access and control access to resources.
Provides a more seamless sign-in experience for users to access company resources from trusted devices.
Single Sign-On
Single Sign-On (SSO ) in the context of this scenario is the functionality that reduces the number of password
prompts that the end user has to enter to access company resources from known devices. This functionality implies
that users are prompted only one time during the lifetime of SSO to access company applications and resource
from this device. If a device uses Workplace Join, the user who is registered to use this device gets persistent SSO,
by default for seven days. This user has a seamless sign-in experience in the same session or in new sessions.
Solution Overview
As part of this solution, you learn how to use Workplace Join on a supported device and experience Single Sign-On
to a company resource.
NOTE
To support Windows 8.1, iOS 6.0+, and Android 4.0+ devices, you MUST configure Azure Active Directory Device Registration
along with device object write-back, see Step-by-Step Guide for On-premises Conditional Access using Azure Active Directory
Device Registration Service
This solution guides takes you through the following walkthrough steps:
1. Walkthrough: Workplace Join with a Windows Device
2. Walkthrough: Workplace Join with an iOS Device
3. Walkthrough: Workplace Join with an Android Device
See Also
Configure a federation server with Device Registration Service
Manage Risk with Additional Multi-Factor
Authentication for Sensitive Applications

Configure Additional Authentication Methods for AD FS
In this guide
This guide provides the following information:
Authentication mechanisms in AD FS - description of the authentication mechanisms available in Active
Directory Federation Services (AD FS ) in Windows Server 2012 R2
Scenario Overview - a description of a scenario where you use Active Directory Federation Services (AD FS )
to enable multifactor authentication (MFA) based on user's group membership.
NOTE
In AD FS in Windows Server 2012 R2 you can enable MFA based on the network location, device identity, and user
identity or group membership.
For detailed step-by-step walkthrough instructions for configuring and verifying this scenario, see
Walkthrough Guide: Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications.
Key Concepts - Authentication mechanisms in AD FS

Benefits of authentication mechanisms in AD FS
Active Directory Federation Services (AD FS ) in Windows Server 2012 R2 provides IT administrators with a richer,
more flexible set of tools for authenticating users who want to access corporate resources. It empowers
administrators with flexible control over the primary and the additional authentication methods, provides a rich
management experience for configuring authentication polices (both through the user interface and Windows
PowerShell), and enhances the experience for the end users that access applications and services that are secured
by AD FS. The following are some of the benefits of securing your application and services with AD FS in Windows
Server 2012 R2:
Global authentication policy - a central management capability, from which an IT administrator can choose
what authentication methods are used to authenticate users based on the network location from which they
access protected resources. This enables administrators to do the following:
Mandate the use of more secure authentication methods for access requests from the extranet.
Enable device authentication for seamless second-factor authentication. This ties the user's identity to
the registered device that is used to access the resource, thus offering more secure compound identity
verification before protected resources are accessed.
NOTE
For more information about device object, Device Registration Service, Workplace Join, and the device as
seamless second-factor authentication and SSO, see Join to Workplace from Any Device for SSO and Seamless
Second Factor Authentication Across Company Applications.
Set MFA requirement for all extranet access or conditionally based on the user's identity, network
location or a device that is used to access protected resources.
Greater flexibility in configuring authentication policies: you can configure custom authentication policies for
AD FS -secured resources with varying business values. For example, you can require MFA for application
with high business impact.
Ease of use: simple and intuitive management tools such as the GUI-based AD FS Management MMC snap-
in and the Windows PowerShell cmdlets enable IT administrators to configure authentication policies with
relative ease. With Windows PowerShell, you can script your solutions for use at scale and to automate
mundane administrative tasks.
Greater control over corporate assets: since as an administrator you can use AD FS to configure an
authentication policy that applies to a specific resource, you have greater control over how corporate
resources are secured. Applications cannot override the authentication policies specified by IT
administrators. For sensitive applications and services, you can enable MFA requirement, device
authentication, and optionally fresh authentication every time the resource is accessed.
Support for custom MFA providers: for organizations that leverage third-party MFA methods, AD FS offers
the ability to incorporate and use these authentication methods seamlessly.
Authentication scope
In AD FS in Windows Server 2012 R2 you can specify an authentication policy at a global scope that is applicable
to all applications and services that are secured by AD FS. You can also set authentication policies for specific
applications and services (relying party trusts) that are secured by AD FS. Specifying an authentication policy for a
particular application (per relying party trust) does not override the global authentication policy. If either global or
per relying party trust authentication policy requires MFA, MFA will be triggered when the user tries to
authenticate to this relying party trust. The global authentication policy is a fallback for relying party trusts
(applications and services) that do not have a specific authentication policy configured.
A global authentication policy applies to all relying parties that are secured by AD FS. You can configure the
following settings as part of the global authentication policy:
Authentication methods to be used for primary authentication
Settings and methods for MFA
Whether device authentication is enabled. For more information, see Join to Workplace from Any Device for
SSO and Seamless Second Factor Authentication Across Company Applications.
Per-relying party trust authentication policies apply specifically to attempts to access that relying party trust
(application or service). You can configure the following settings as part of the per-relying party trust authentication
policy:
Whether users are required to provide their credentials each time at sign-in
MFA settings based on the user/group, device registration, and access request location data
Primary and additional authentication methods
With AD FS in Windows Server 2012 R2, in addition to the primary authentication mechanism, administrators can
configure additional authentication methods. Primary authentication methods are built-in and are intended to
validate users' identities. You can configure additional authentication factors to request that more information
about the user's identity is provided and consequently ensure stronger authentication.
With primary authentication in AD FS in Windows Server 2012 R2, you have the following options:
For resources published to be accessed from outside the corporate network, Forms Authentication is
selected by default. In addition, you can also enable Certificate Authentication (in other words, smart card-
based authentication or user client certificate authentication that works with AD DS ).
For intranet resources, Windows Authentication is selected by default. In addition you can also enable Forms
and/or Certificate Authentication.
By selecting more than one authentication method, you enable your users to have a choice of what method to
authenticate with at the sign-in page for your application or service.
You can also enable device authentication for seamless second-factor authentication. This ties the user's identity to
the registered device that is used to access the resource, thus offering more secure compound identity verification
before protected resources are accessed.
NOTE
For more information about device object, Device Registration Service, Workplace Join, and the device as seamless second-
factor authentication and SSO, see Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication
Across Company Applications.
If you specify Windows Authentication method (default option) for your intranet resources, authentication requests
undergo this method seamlessly on browsers that support Windows authentication.
NOTE
Windows authentication is not supported on all browsers. The authentication mechanism in AD FS in Windows Server 2012
R2 detects the user's browser user agent and uses a configurable setting to determine whether that user agent supports
Windows Authentication. Administrators can add to this list of user agents (via the Windows PowerShell
Set-AdfsProperties -WIASupportedUserAgents command, in order to specify alternate user agent strings for browsers that
support Windows Authentication. If the client's user agent does not support Windows Authentication, the default fallback
method is Forms Authentication.
Configuring MFA
There are two parts to configure MFA in AD FS in Windows Server 2012 R2: specifying the conditions under which
MFA is required, and selecting an additional authentication method. For more information about additional
authentication methods, see Configure Additional Authentication Methods for AD FS.
MFA settings
The following options are available for MFA settings (conditions under which to require MFA):
You can require MFA for specific users and groups in the AD domain that your federation server is joined to.
You can require MFA for either registered (workplace joined) or unregistered (not workplace joined) devices.
Windows Server 2012 R2 takes a user-centric approach to modern devices where device objects represent a
relationship between user@device and a company. Device objects are a new class in AD in Windows Server
2012 R2 that can be used to offer compound-identity when providing access to applications and services. A
new component of AD FS - the device registration service (DRS ) - provisions a device identity in Active
Directory and sets a certificate on the consumer device that will be used to represent the device identity. You
can then use this device identity to workplace join your device, in other words, to connect your personal
device to the Active Directory of your workplace. When you join your personal device to your workplace, it
becomes a known device and will provide seamless second-factor authentication to protected resources and
applications. In other words, after a device is workplace joined, the user's identity is tied to this device and
can be used for a seamless compound identity verification before a protected resource is accessed.
For more information on workplace join and leave, see Join to Workplace from Any Device for SSO and
Seamless Second Factor Authentication Across Company Applications.
You can require MFA when the access request for the protected resources comes from either the extranet or
the intranet.
Scenario Overview
In this scenario, you enable MFA based on the user's group membership data for a specific application. In other
words, you will set up an authentication policy on your federation server to require MFA when users that belong to
a certain group request access to a specific application that is hosted on a web server.
More specifically, in this scenario, you enable an authentication policy for a claims-based test application called
claimapp, whereby an AD user Robert Hatley will be required to undergo MFA since he belongs to an AD group
Finance.
The step-by step instructions to set up and verify this scenario are provided in Walkthrough Guide: Manage Risk
with Additional Multi-Factor Authentication for Sensitive Applications. In order to complete the steps in this
walkthrough, you must set up a lab environment and follow the steps in Set up the lab environment for AD FS in
Other scenarios of enabling MFA in AD FS include the following:
Enable MFA, if the access request comes from the extranet. You can modify the code presented in the "Set up
MFA Policy" section of Walkthrough Guide: Manage Risk with Additional Multi-Factor Authentication for
Sensitive Applications with the following:
'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] =>

issue(type="https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value =
"https://schemas.microsoft.com/claims/multipleauthn" );'
Enable MFA, if the access request comes from a non-workplace joined device. You can modify the code
presented in the "Set up MFA Policy" section of Walkthrough Guide: Manage Risk with Additional Multi-
Factor Authentication for Sensitive Applications with the following:
'NOT EXISTS([type=="https://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid"]) =>

issue (type="https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value =
Enable MFA, if the access is coming from a user with a device that is workplace joined but not registered to
this user. You can modify the code presented in the "Set up MFA Policy" section of Walkthrough Guide:
Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications with the following:
'c:[type=="https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", value ==
"false"] => issue (type="https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod",
value = "https://schemas.microsoft.com/claims/multipleauthn");'
See Also
Walkthrough Guide: Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications Set up the
lab environment for AD FS in Windows Server 2012 R2
Key concepts-conditional access control in AD FS

Managing Risk with Conditional Access Control
Key concepts - conditional access control in AD FS

The overall function of AD FS is to issue an access token that contains a set of claims. The decision regarding what
claims AD FS accepts and then issues is governed by claim rules.
Access control in AD FS is implemented with issuance authorization claim rules that are used to issue a permit or
deny claims that will determine whether a user or a group of users will be allowed to access AD FS -secured
resources or not. Authorization rules can only be set on relying party trusts.
RULE OPTION RULE LOGIC
Permit all users If incoming claim type equals any claim type and value equals
any value, then issue claim with value equals Permit
Permit access to users with this incoming claim If incoming claim type equals specified claim type and value
equals specified claim value, then issue claim with value
equals Permit
Deny access to users with this incoming claim If incoming claim type equals specified claim type and value
equals specified claim value, then issue claim with value
equals Deny
For more information about these rule options and logic, see When to Use an Authorization Claim Rule.
In AD FS in Windows Server 2012 R2, access control is enhanced with multiple factors, including user, device,
location, and authentication data. This is made possible by a greater variety of claim types available for the
authorization claim rules. In other words, in AD FS in Windows Server 2012 R2, you can enforce conditional access
control based on user identity or group membership, network location, device (whether it is workplace joined, for
more information, see Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication
Across Company Applications), and the authentication state (whether multifactor authentication (MFA) was
performed ).
Conditional access control in AD FS in Windows Server 2012 R2, offers the following benefits:
Flexible and expressive per-application authorization policies, whereby you can permit or deny access based
on user, device, network location, and authentication state
Creating issuance authorization rules for relying party applications
Rich UI experience for the common conditional access control scenarios
Rich claims language & Windows PowerShell support for advanced conditional access control scenarios
Custom (per relying party application) 'Access Denied' messages. For more information, see Customizing
the AD FS Sign-in Pages. By being able to customize these messages, you can explain why a user is being
denied access and also facilitate self-service remediation where it is possible, for example, prompt users to
workplace join their devices. For more information, see Join to Workplace from Any Device for SSO and
Seamless Second Factor Authentication Across Company Applications.
The following table includes all the claim types available in AD FS in Windows Server 2012 R2 to be used for
implementing conditional access control.
CLAIM TYPE DESCRIPTION
Email Address The email address of the user.
Given Name The given name of the user.
Name The unique name of the user,
UPN The user principal name (UPN) of the user.
Common Name The common name of the user.
AD FS 1 x E-mail Address The email address of the user when interoperating with AD FS
1.1 or AD FS 1.0.
Group A group that the user is a member of.
AD FS 1 x UPN The UPN of the user when interoperating with AD FS 1.1 or

AD FS 1.0.
Role A role that the user has.
Surname The surname of the user.
PPID The private identifier of the user.
Name ID The SAML name identifier of the user.
Authentication time stamp Used to display the time and date that the user was
authenticated.
Authentication method The method used to authenticate the user.
Deny only group SID The deny-only group SID of the user.
Deny only primary SID The deny-only primary SID of the user.
Deny only primary group SID The deny-only primary group SID of the user.
Group SID The group SID of the user.
Primary group SID The primary group SID of the user.
Primary SID The primary SID of the user.
Windows account name The domain account name of the user in the form of
domain\user.
Is Registered User User is registered to use this device.
Device Identifier Identifier of the device.
Device Registration Identifier Identifier for Device Registration.
Device Registration Display Name Display name of Device Registration.
Device OS Type Operating system type of the device.
Device OS Version Operating system version of the device.
Is Managed Device Device is managed by a management service.
Forwarded Client IP IP address of the user.
Client Application Type of the client application.
Client User Agent Device type the client is using to access the application.
Client IP IP address of the client.
Endpoint Path Absolute Endpoint path which can be used to determine active
versus passive clients.
Proxy DNS name of the federation server proxy that passed the
request.
Application Identifier Identifier for the relying party.
Application policies Application policies of the certificate.
Authority Key Identifier The authority key identifier extension of the certificate that
signed an issued certificate.
Basic Constraint One of the basic constraints of the certificate.
Enhanced Key Usage Describes one of the enhanced key usages of the certificate.
Issuer The name of the certification authority that issued the X.509
certificate.
Issuer Name The distinguished name of the certificate issuer.
Key Usage One of the key usages of the certificate.
Not After Date in local time after which a certificate is no longer valid.
Not Before The date in local time on which a certificate becomes valid.
Certificate Policies The policies under which the certificate has been issued.
Public Key Public key of the certificate.
Certificate Raw Data The raw data of the certificate.
Subject Alternative Name One of the alternative names of the certificate.
Serial Number The serial number of the certificate.
Signature Algorithm The algorithm used to create the signature of a certificate.
Subject The subject from the certificate.
Subject Key Identifier The subject key identifier of the certificate.
Subject Name The subject distinguished name from a certificate.
V2 Template Name The name of the version 2 certificate template used wen
issuing or renewing a certificate. This is a Microsoft-specific
value.
V1 Template Name The name of the version 1 certificate template used when
issuing or renewing a certificate. This is a Microsoft-specific
value.
Thumbprint Thumbprint of the certificate.
X 509 Version The X.509 format version of the certificate.
Inside Corporate Network Used to indicate if a request originated from inside the
corporate network.
Password Expiration Time Used to display the time when the password expires.
Password Expiration Days Used to display the number of days to password expiry.
Update Password URL Used to display the web address of update password service.
Authentication Methods References Used to indicate al authentication methods used to

authenticate the user.
Managing Risk with Conditional Access Control

Using the available settings, there are many ways in which you can manage risk by implementing conditional
access control.
Common Scenarios
For example, imagine a simple scenario of implementing conditional access control based on the user's group
membership data for a particular application (relying party trust). In other words, you can set up an issuance
authorization rule on your federation server to permit users that belong to a certain group in your AD domain
access to a particular application that is secured by AD FS. The detailed step by step instructions (using the UI and
Windows PowerShell) for implementing this scenario are covered in Walkthrough Guide: Manage Risk with
Conditional Access Control. In order to complete the steps in this walkthrough, you must set up a lab environment
and follow the steps in Set up the lab environment for AD FS in Windows Server 2012 R2.
Advanced Scenarios
Other examples of implementing conditional access control in AD FS in Windows Server 2012 R2 include the
following:
Permit access to an application secured by AD FS only if this user's identity was validated with MFA
You can use the following code:
@RuleTemplate = "Authorization"
@RuleName = "PermitAccessWithMFA"
c:[Type == "https://schemas.microsoft.com/claims/authnmethodsreferences", Value =~ "^(?
i)https://schemas\.microsoft\.com/claims/multipleauthn$"] => issue(Type =
"https://schemas.microsoft.com/authorization/claims/permit", Value = "PermitUsersWithClaim");
Permit access to an application secured by AD FS only if the access request is coming from a workplace
joined device that is registered to the user
@RuleName = "PermitAccessFromRegisteredWorkplaceJoinedDevice"
c:[Type == "https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value =~ "^(?
i)true$"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value =
"PermitUsersWithClaim");
Permit access to an application secured by AD FS only if the access request is coming from a workplace
joined device that is registered to a user whose identity has been validated with MFA
You can use the following code
@RuleName = "RequireMFAOnRegisteredWorkplaceJoinedDevice"
c1:[Type == "https://schemas.microsoft.com/claims/authnmethodsreferences", Value =~ "^(?
i)http://schemas\.microsoft\.com/claims/multipleauthn$"] &&
c2:[Type == "https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value =~ "^(?
i)true$"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value =
Permit extranet access to an application secured by AD FS only if the access request is coming from a user
whose identity has been validated with MFA.
@RuleName = "RequireMFAForExtranetAccess"
c1:[Type == "https://schemas.microsoft.com/claims/authnmethodsreferences", Value =~ "^(?
i)http://schemas\.microsoft\.com/claims/multipleauthn$"] &&
c2:[Type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value =~ "^(?i)false$"]
=> issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value =
See Also
Walkthrough Guide: Manage Risk with Conditional Access Control Set up the lab environment for AD FS in
Managing SSL Certificates in AD FS and WAP in
Windows Server 2016
This article describes how to deploy a new SSL certificate to your AD FS and WAP servers.
NOTE
The recommended way to replace the SSL certificate going forward for an AD FS farm is to use Azure AD Connect. For more
information see Update the SSL certificate for an Active Directory Federation Services (AD FS) farm
Obtaining your SSL Certificates

For production AD FS farms a publicly trusted SSL certificate is recommended. This is usually obtained by
submitting a certificate signing request (CSR ) to a third party, public certificate provider. There are a variety of
ways to generate the CSR, including from a Windows 7 or higher PC. Your vendor should have documentation for
this.
Make sure the certificate meets the AD FS and Web Application Proxy SSL certificate requirements
How many certificates are needed
It is recommended that you use a common SSL certificate across all AD FS and Web Application Proxy servers.
For detailed requirements see the document AD FS and Web Application Proxy SSL certificate requirements
SSL Certificate Requirements
For requirements including naming, root of trust and extensions see the document AD FS and Web Application
Proxy SSL certificate requirements
Replacing the SSL certificate for AD FS

NOTE
The AD FS SSL certificate is not the same as the AD FS Service communications certificate found in the AD FS Management
snap-in. To change the AD FS SSL certificate, you will need to use PowerShell.
First, determine which certificate binding mode your AD FS servers are running: default certificate authentication
binding, or alternate client TLS binding mode.
Replacing the SSL certificate for AD FS running in default certificate authentication binding mode
AD FS by default performs device certificate authentication on port 443 and user certificate authentication on port
49443 (or a configurable port that is not 443). In this mode, use the powershell cmdlet Set-AdfsSslCertificate to
manage the SSL certificate.
Follow the steps below:
1. First, you will need to obtain the new certificate. This is usually done by submitting a certificate signing
request (CSR ) to a third party, public certificate provider. There are a variety of ways to generate the CSR,
including from a Windows 7 or higher PC. Your vendor should have documentation for this.
2. Once you get the response from your certificate provider, import it to the Local Machine store on each AD
FS and Web Application Proxy server.
3. On the primary AD FS server, use the following cmdlet to install the new SSL certificate
Set-AdfsSslCertificate -Thumbprint '<thumbprint of new cert>'
The certificate thumbprint can be found by executing this command:
dir Cert:\LocalMachine\My\
Additional Notes
The Set-AdfsSslCertificate cmdlet is a multi-node cmdlet; this means it only has to run from the primary and all
nodes in the farm will be updated. This is new in Server 2016. On Server 2012 R2 you had to run Set-
AdfsSslCertificate on each server.
The Set-AdfsSslCertificate cmdlet has to be run only on the primary server. The primary server has to be
running Server 2016 and the Farm Behavior Level should be raised to 2016.
The Set-AdfsSslCertificate cmdlet will use PowerShell Remoting to configure the other AD FS servers, make
sure port 5985 (TCP ) is open on the other nodes.
The Set-AdfsSslCertificate cmdlet will grant the adfssrv principal read permissions to the private keys of the
SSL certificate. This principal represents the AD FS service. It's not necessary to grant the AD FS service
account read access to the private keys of the SSL certificate.
Replacing the SSL certificate for AD FS running in alternate TLS binding mode
When configured in alternate client TLS binding mode, AD FS performs device certificate authentication on port
443 and user certificate authentication on port 443 as well, on a different hostname. The user certificate hostname
is the AD FS hostname pre-pended with "certauth", for example "certauth.fs.contoso.com". In this mode, use the
powershell cmdlet Set-AdfsAlternateTlsClientBinding to manage the SSL certificate. This will manage not only the
alternative client TLS binding but all other bindings on which AD FS sets the SSL certificate as well.
Follow the steps below:
1. First, you will need to obtain the new certificate. This is usually done by submitting a certificate signing
request (CSR ) to a third party, public certificate provider. There are a variety of ways to generate the CSR,
including from a Windows 7 or higher PC. Your vendor should have documentation for this.
2. Once you get the response from your certificate provider, import it to the Local Machine store on each AD
FS and Web Application Proxy server.
3. On the primary AD FS server, use the following cmdlet to install the new SSL certificate
Set-AdfsAlternateTlsClientBinding -Thumbprint '<thumbprint of new cert>'
The certificate thumbprint can be found by executing this command:
dir Cert:\LocalMachine\My\
Additional Notes
The Set-AdfsAlternateTlsClientBinding cmdlet is a multi-node cmdlet; this means it only has to run from the
primary and all nodes in the farm will be updated.
The Set-AdfsAlternateTlsClientBinding cmdlet has to be run only on the primary server. The primary server has
to be running Server 2016 and the Farm Behavior Level should be raised to 2016.
The Set-AdfsAlternateTlsClientBinding cmdlet will use PowerShell Remoting to configure the other AD FS
servers, make sure port 5985 (TCP ) is open on the other nodes.
The Set-AdfsAlternateTlsClientBinding cmdlet will grant the adfssrv principal read permissions to the private
keys of the SSL certificate. This principal represents the AD FS service. It's not necessary to grant the AD FS
service account read access to the private keys of the SSL certificate.
Replacing the SSL certificate for the Web Application Proxy

For configuring both the default certificate authentication binding or alternate client TLS binding mode on the
WAP we can use the Set-WebApplicationProxySslCertificate cmdlet. To replace the Web Application Proxy SSL
certificate, on each Web Application Proxy server use the following cmdlet to install the new SSL certificate:
Set-WebApplicationProxySslCertificate '<thumbprint of new cert>'
If the above cmdlet fails because the old certificate has already expired, reconfigure the proxy using the following
cmdlets:
$cred = Get-Credential
Enter the credentials of a domain user who is local administrator on the AD FS server
Install-WebApplicationProxy -FederationServiceTrustCredential $cred -CertificateThumbprint '<thumbprint of new

cert>' -FederationServiceName 'fs.contoso.com'
AD FS and certificate KeySpec property Information
Managing SSL/TLS Protocols and Cipher Suites for
AD FS
The following documentation provides information on how to disable and enable certain TLS/SSL protocols and
cipher suites that are used by AD FS
TLS/SSL, SChannel and Cipher Suites in AD FS

The Transport Layer Security (TLS ) and Secure Sockets Layer (SSL ) are protocols that provide for secure
communications. Active Directory Federation Services uses these protocols for communications. Today several
versions of these protocols exist.
Schannel is a Security Support Provider (SSP ) that implements the SSL, TLS and DTLS Internet standard
authentication protocols. The Security Support Provider Interface (SSPI) is an API used by Windows systems to
perform security-related functions including authentication. The SSPI functions as a common interface to several
Security Support Providers (SSPs), including the Schannel SSP.
A cipher suite is a set of cryptographic algorithms. The schannel SSP implementation of the TLS/SSL protocols use
algorithms from a cipher suite to create keys and encrypt information. A cipher suite specifies one algorithm for
each of the following tasks:
Key exchange
Bulk encryption
Message authentication
AD FS uses Schannel.dll to perform its secure communications interactions. Currently AD FS supports all of the
protocols and cipher suites that are supported by Schannel.dll.
Managing the TLS/SSL Protocols and Cipher Suites

IMPORTANT
This section contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the
registry incorrectly. Therefore, make sure that you follow these steps carefully.
Be aware that changing the default security settings for SCHANNEL could break or prevent communications between certain
clients and servers. This will occur if secure communication is required and they do not have a protocol to negotiate
communications with.
If you are applying these changes, they must be applied to all of your AD FS servers in your farm. After applying these
changes a reboot is required.
In todays day and age, hardening your servers and removing older or weak cipher suites is becoming a major
priority for many organizations. Software suites are available that will test your servers and provide detailed
infomation on these protocols and suites. In order to remain compliant or achieve secure ratings, removing or
disabling weaker protocols or cipher suites has become a must. The remainder of this document will provide
guidance on how to enable or disable certain protocols and cipher suites.
The registry keys below are located in the same location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols. Use
regedit or PowerShell to enable or disable these protocols and cipher suites.
Enable and Disable SSL 2.0

Use the following registry keys and their values to enable and disable SSL 2.0.
Enable SSL 2.0
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL
2.0\Server] "Enabled"=dword:00000001
2.0\Server] "DisabledByDefault"=dword:00000000
2.0\Client] "Enabled"=dword:00000001
2.0\Client] "DisabledByDefault"=dword:00000000
Disable SSL 2.0
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SL
Using PowerShell to disable SSL 2.0
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server' -Force |
Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL

2.0\Server' -name 'Enabled' -value '0' -PropertyType 'DWord' -Force | Out-Null

2.0\Server' -name 'DisabledByDefault' -value 1 -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client' -Force |

Out-Null

2.0\Client' -name 'Enabled' -value '0' -PropertyType 'DWord' -Force | Out-Null

2.0\Client' -name 'DisabledByDefault' -value 1 -PropertyType 'DWord' -Force | Out-Null
Write-Host 'SSL 2.0 has been disabled.'
Enable and Disable SSL 3.0

Use the following registry keys and their values to enable and disable SSL 3.0.
Enable SSL 3.0
Disable SSL 3.0
Using PowerShell to disable SSL 3.0
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server' -
Force | Out-Null


New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client' -

Force | Out-Null


Write-Host 'SSL 3.0 has been disabled.'
Enable and Disable TLS 1.0

Use the following registry keys and their values to enable and disable TLS 1.0.
IMPORTANT
Disabling TLS 1.0 will break the WAP to AD FS trust. If you disable TLS 1.0 you should enable strong auth for your
applications. See Enable Strong Authentication
Enable TLS 1.0

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
Disable TLS 1.0
Using PowerShell to disable TLS 1.0
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -
Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS


New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client' -

Force | Out-Null


Write-Host 'TLS 1.0 has been disabled.'

Enable TLS 1.1
Disable TLS 1.1
Force | Out-Null



Force | Out-Null



Enable TLS 1.2
Disable TLS 1.2
Force | Out-Null



Force | Out-Null


Enable and Disable RC4

Use the following registry keys and their values to enable and disable RC4. This cipher suite's registry keys are
located here:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\
Enable RC4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4
128/128] "Enabled"=dword:00000001
40/128] "Enabled"=dword:00000001
56/128] "Enabled"=dword:00000001
Disable RC4
128/128] "Enabled"=dword:00000000
40/128] "Enabled"=dword:00000000
56/128] "Enabled"=dword:00000000
Using PowerShell
([Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine,$env:COMPUTERNAM
E)).CreateSubKey('SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128')
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4
128/128' -name 'Enabled' -value '0' -PropertyType 'DWord' -Force | Out-Null
Enabling or Disabling additional cipher suites

You can disable certain specific ciphers by removing them from
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\0001000
2
To enable a cipher suite, add its string value to the Functions multi-string value key. For example, if we want to
enable TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521 then we would add it to the string.
For a full list of supported Cipher suites see Cipher Suites in TLS/SSL (Schannel SSP ). This document provides a
table of suites that are enabled by default and those that are supported but not enabled by default. To prioritize the
cipher suites see Prioritizing Schannel Cipher Suites.
Enabling Strong Authentication for .NET applications

The .NET Framework 3.5/4.0/4.5.x applications can switch the default protocol to TLS 1.2 by enabling the
SchUseStrongCrypto registry key. This registry key will force .NET applications to use TLS 1.2.
IMPORTANT
For AD FS on Windows Server 2016 and Windows Server 2012 R2 you need to use the .NET Framework 4.0/4.5.x key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
For the .NET Framework 3.5 use the following registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
"SchUseStrongCrypto"=dword:00000001
For the .NET Framework 4.0/4.5.x use the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
"SchUseStrongCrypto"=dword:00000001
New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -name 'SchUseStrongCrypto' -

value '1' -PropertyType 'DWord' -Force | Out-Null
Additional Information
Cipher Suites in TLS/SSL (Schannel SSP )
TLS Cipher Suites in Windows 8.1
Prioritizing Schannel Cipher Suites
Speaking in Ciphers and other Enigmatic tongues
This document describes conditional access policies based on devices in a hybrid scenario where the on-premises
directories are connected to Azure AD using Azure AD Connect.
AD FS and Hybrid conditional access

devices with Azure AD for conditional access to cloud resources, the Azure AD Connect device write back capability
makes device registration information available on premises for AD FS policies to consume and enforce. This way,
you have a consistent approach to access control policies for both on premises and cloud resources.
Types of registered devices

There are three kinds of registered devices, all of which are represented as Device objects in Azure AD and can be
used for conditional access with AD FS on premises as well.
ADD WORK OR SCHOOL

Description Users add their work or Users join their Windows 10 Windows 10 domain joined
school account to their work device to Azure AD. devices automatically
BYOD device interactively. register with Azure AD.
Note: Add Work or School
Account is the replacement
for Workplace Join in
Windows 8/8.1
ADD WORK OR SCHOOL
How users log in to the No login to Windows as the Login to Windows as the Login using AD account.
device work or school account. (work or school) account
Login using a Microsoft that registered the device.
account.
How devices are managed MDM Policies (with MDM Policies (with Group Policy, System Center
additional Intune enrollment) additional Intune enrollment) Configuration Manager
(SCCM)
Azure AD Trust type Workplace joined Azure AD joined Domain joined
W10 Settings location Settings > Accounts > Your Settings > System > About Settings > System > About
account > Add a work or > Join Azure AD > Join a domain
school account
Also available for iOS and Yes No No

Android Devices?
For more information on the different ways to register devices, see also:
Using Windows 10 devices in your workplace
Setting up Windows 10 devices for work
Join Windows 10 Mobile to Azure Active Directory
How Windows 10 User and Device Sign on is different from previous versions
For Windows 10 and AD FS 2016 there are some new aspects of device registration and authentication you should
know about (especially if you are very familiar with device registration and "workplace join" in previous releases).
First, in Windows 10 and AD FS in Windows Server 2016, device registration and authentication is no longer based
solely on an X509 user certificate. There is a new and more robust protocol that provides better security and a
more seamless user experience. The key differences are that, for Windows 10 Domain Join and Azure AD Join,
there is an X509 computer certificate and a new credential called a PRT. You can read all about it here and here.
Second, Windows 10 and AD FS 2016 support user authentication using Microsoft Passport for Work, which you
can read about here and here.
AD FS 2016 provides seamless device and user SSO based on both PRT and Passport credentials. Using the steps
in this document, you can enable these capabilities and see them work.
Device Access Control Policies
Devices can be used in simple AD FS access control rules such as:
allow access only from a registered device
require multi factor authentication when a device is not registered
These rules can then be combined with other factors such as network access location and multi factor
authentication, creating rich conditional access policies such as:
require multi factor authentication for unregistered devices accessing from outside the corporate network,
except for members of a particular group or groups
With AD FS 2016, these policies can be configured specifically to require a particular device trust level as well:
either authenticated, managed, or compliant.
For more information on configuring AD FS access control policies, see Access control policies in AD FS.
Authenticated devices
Authenticated devices are registered devices that are not enrolled in MDM (Intune and 3rd party MDMs for
Windows 10, Intune only for iOS and Android).
Authenticated devices will have the isManaged AD FS claim with value FALSE. (Whereas devices that are not
registered at all will lack this claim.) Authenticated devices (and all registered devices) will have the isKnown AD FS
claim with value TRUE.
Managed Devices:
Managed devices are registered devices that are enrolled with MDM.
Managed devices will have the isManaged AD FS claim with value TRUE.
Devices compliant (with MDM or Group Policies )
Compliant devices are registered devices that are not only enrolled with MDM but compliant with the MDM
policies. (Compliance information originates with the MDM and is written to Azure AD.)
Compliant devices will have the isCompliant AD FS claim with value TRUE.
For complete list of AD FS 2016 device and conditional access claims, see Reference.
Reference
Complete list of new AD FS 2016 and device claims
https://schemas.microsoft.com/ws/2014/01/identity/claims/anchorclaimtype
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/implicitupn
https://schemas.microsoft.com/2014/03/psso
https://schemas.microsoft.com/2015/09/prt
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
https://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid
https://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid
https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
https://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid
https://schemas.microsoft.com/2012/01/devicecontext/claims/displayname
https://schemas.microsoft.com/2012/01/devicecontext/claims/identifier
https://schemas.microsoft.com/2012/01/devicecontext/claims/ostype
https://schemas.microsoft.com/2012/01/devicecontext/claims/osversion
https://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged
https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser
https://schemas.microsoft.com/2014/02/devicecontext/claims/isknown
https://schemas.microsoft.com/2014/02/deviceusagetime
https://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant
https://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype
https://schemas.microsoft.com/claims/authnmethodsreferences
https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent
https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path
https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork
https://schemas.microsoft.com/2012/01/requestcontext/claims/client-request-id
https://schemas.microsoft.com/2012/01/requestcontext/claims/relyingpartytrustid
https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-ip
https://schemas.microsoft.com/2014/09/requestcontext/claims/userip
https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod
This topic outlines the steps to configure a test environment that can be used to complete the walkthroughs in the
following walkthrough guides:
NOTE
We do not recommend that you install the web server and the federation server on the same computer.
To set up this test environment, complete the following steps:

1. Step 1: Configure the domain controller (DC1)
2. Step 2: Configure the federation server (ADFS1) with Device Registration Service
3. Step 3: Configure the web server (WebServ1) and a sample claims-based application
4. Step 4: Configure the client computer (Client1)
Step 1: Configure the domain controller (DC1)

For the purposes of this test environment, you can call your root Active Directory domain contoso.com and
specify pass@word1 as the administrator password.
Install the AD DS role service and install Active Directory Domain Services (AD DS ) to make your computer a
domain controller in Windows Server 2012 R2 . This action upgrades your AD DS schema as part of the
domain controller creation. For more information and step-by-step instructions,
seehttps://technet.microsoft.com/ library/hh472162.aspx.
Create test Active Directory accounts
After your domain controller is functional, you can create a test group and test user accounts in this domain and
add the user account to the group account. You use these accounts to complete the walkthroughs in the
walkthrough guides that are referenced earlier in this topic.
Create the following accounts:
User: Robert Hatley with the following credentials: User name: RobertH and password: P@ssword
Group: Finance
For information about how to create user and group accounts in Active Directory (AD ), see
https://technet.microsoft.com/library/cc783323%28v=ws.10%29.aspx.
Add the Robert Hatley account to the Finance group. For information on how to add a user to a group in Active
Directory, see https://technet.microsoft.com/library/cc737130%28v=ws.10%29.aspx.
Create a GMSA account
The group Managed Service Account (GMSA) account is required during the Active Directory Federation Services
(AD FS ) installation and configuration.
To c r e a t e a G M SA a c c o u n t
1. Open a Windows PowerShell command window and type:
Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10)

New-ADServiceAccount FsGmsa -DNSHostName adfs1.contoso.com -ServicePrincipalNames http/adfs1.contoso.com
Step 2: Configure the federation server (ADFS1) by using Device

To set up another virtual machine, install Windows Server 2012 R2 and connect it to the domain contoso.com. Set
up the computer after you have joined it to the domain, and then proceed to install and configure the AD FS role.
For a video, see Active Directory Federation Services How -To Video Series: Installing an AD FS Server Farm.
Install a server SSL certificate
You must install a server Secure Socket Layer (SSL ) certificate on the ADFS1 server in the local computer store.
The certificate MUST have the following attributes:
Subject Name (CN ): adfs1.contoso.com
Subject Alternative Name (DNS ): adfs1.contoso.com
Subject Alternative Name (DNS ): enterpriseregistration.contoso.com
For more information about setting up SSL certificates, see Configure SSL/TLS on a Web site in the domain with
an Enterprise CA.
Active Directory Federation Services How -To Video Series: Updating Certificates.
Install the AD FS server role
To i n st a l l t h e F e d e r a t i o n Se r v i c e r o l e se r v i c e
1. Log on to the server by using the domain administrator account administrator@contoso.com.

2. Start Server Manager. To start Server Manager, click Server Manager on the Windows Start screen, or
click Server Manager on the Windows taskbar on the Windows desktop. On the Quick Start tab of the
Welcome tile on the Dashboard page, click Add roles and features. Alternatively, you can click Add
Roles and Features on the Manage menu.
Next.
Configure the federation server
The next step is to configure the federation server.
To c o n fi g u r e t h e fe d e r a t i o n se r v e r
click Next.
3. On the Connect to AD DS page, specify an account with domain administrator rights for the contoso.com
Active Directory domain that this computer is joined to, and then click Next.
Import the SSL certificate that you have obtained earlier. This certificate is the required service
authentication certificate. Browse to the location of your SSL certificate.
To provide a name for your federation service, type adfs1.contoso.com. This value is the same value
that you provided when you enrolled an SSL certificate in Active Directory Certificate Services (AD
CS ).
To provide a display name for your federation service, type Contoso Corporation.
5. On the Specify Service Account page, select Use an existing domain user account or group
Managed Service Account, and then specify the GMSA account fsgmsa that you created when you
created the domain controller.
6. On the Specify Configuration Database page, select Create a database on this server using Windows
Internal Database, and then click Next.
8. On the Pre-requisite Checks page, verify that all prerequisite checks were successfully completed, and then
click Configure.
9. On the Results page, review the results, check whether the configuration has completed successfully, and
then click Next steps required for completing your federation service deployment.
Configure Device Registration Service
The next step is to configure Device Registration Service on the ADFS1 server. For a video, see Active Directory
Federation Services How -To Video Series: Enabling the Device Registration Service.
To c o n fi g u r e D e v i c e R e g i st r a t i o n Se r v i c e fo r W i n d o w s Se r v e r 2 0 1 2 R T M
1. IMPORTANT
The following step applies to the Windows Server 2012 R2 RTM build.
Open a Windows PowerShell command window and type:
When you are prompted for a service account, type contosofsgmsa$.
Now run the Windows PowerShell cmdlet.
2. On the ADFS1 server, in the AD FS Management console, navigate to Authentication Policies. Select
Edit Global Primary Authentication. Select the check box next to Enable Device Authentication, and
then click OK.
Add Host (A ) and Alias (CNAME) Resource Records to DNS
On DC1, you must ensure that the following Domain Name System (DNS ) records are created for Device
Registration Service.
ENTRY TYPE ADDRESS
adfs1 Host (A) IP address of the AD FS server
enterpriseregistration Alias (CNAME) adfs1.contoso.com
You can use the following procedure to add a host (A) resource record to corporate DNS name servers for the
federation server and Device Registration Service.
Membership in the Administrators group or an equivalent is the minimum requirement to complete this procedure.
Review details about using the appropriate accounts and group memberships in the HYPERLINK
"https://go.microsoft.com/fwlink/?LinkId=83477" Local and Domain Default Groups
(https://go.microsoft.com/fwlink/p/?LinkId=83477).
To a d d a h o st (A ) a n d a l i a s (C N A M E) r e so u r c e r e c o r d s t o D N S fo r y o u r fe d e r a t i o n se r v e r
1. On DC1, from Server Manager, on the Tools menu, click DNS to open the DNS snap-in.
2. In the console tree, expand DC1, expand Forward Lookup Zones, right-click contoso.com, and then click
New Host (A or AAAA ).
3. In Name, type the name you want to use for your AD FS farm. For this walkthrough, type adfs1.
4. In IP address, type the IP address of the ADFS1 server. Click Add Host.
5. Right-click contoso.com, and then click New Alias (CNAME ).
7. In the Fully Qualified Domain Name (FQDN ) of the target host box, type adfs1.contoso.com, and then click
OK.
IMPORTANT
In a real-world deployment, if your company has multiple user principal name (UPN) suffixes, you must create multiple
CNAME records, one for each of those UPN suffixes in DNS.
Step 3: Configure the web server (WebServ1) and a sample claims-

based application
Set up a virtual machine (WebServ1) by installing the Windows Server 2012 R2 operating system and connect it to
the domain contoso.com. After it is joined to the domain, you can proceed to install and configure the Web Server
role.
To complete the walkthroughs that were referenced earlier in this topic, you must have a sample application that is
secured by your federation server (ADFS1).
You can download Windows Identity Foundation SDK (https://www.microsoft.com/download/details.aspx?
id=4451, which includes a sample claims-based application.
You must complete the following steps to set up a web server with this sample claims-based application.
NOTE
These steps have been tested on a web server that runs the Windows Server 2012 R2 operating system.
1. Install the Web Server Role and Windows Identity Foundation

2. Install Windows Identity Foundation SDK
3. Configure the simple claims app in IIS
4. Create a relying party trust on your federation server
Install the Web Server role and Windows Identity Foundation
1. NOTE
You must have access to the Windows Server 2012 R2 installation media.
Log on to WebServ1 by using administrator@contoso.com and the password pass@word1.

2. From Server Manager, on the Quick Start tab of the Welcome tile on the Dashboard page, click Add
roles and features. Alternatively, you can click Add Roles and Features on the Manage menu.
Next.
6. On the Select server roles page, select the check box next to Web Server (IIS ), click Add Features, and
then click Next.
7. On the Select features page, select Windows Identity Foundation 3.5, and then click Next.
9. On the Select role services page, select and expand Application Development. Select ASP.NET 3.5,
click Add Features, and then click Next.
10. On the Confirm installation selections page, click Specify an alternate source path. Enter the path to
the Sxs directory that is located in the Windows Server 2012 R2 installation media. For example
D:SourcesSxs. Click OK, and then click Install.
Install Windows Identity Foundation SDK
1. Run WindowsIdentityFoundation-SDK-3.5.msi to install Windows Identity Foundation SDK 3.5
(https://www.microsoft.com/download/details.aspx?id=4451). Choose all of the default options.
Configure the simple claims app in IIS
1. Install a valid SSL certificate in the computer certificate store. The certificate should contain the name of
your web server, webserv1.contoso.com.
2. Copy the contents of C:Program Files (x86)Windows Identity Foundation SDKv3.5SamplesQuick StartWeb
ApplicationPassiveRedirectBasedClaimsAwareWebApp to C:InetpubClaimapp.
3. Edit the Default.aspx.cs file so that no claim filtering takes place. This step is performed to ensure that the
sample application displays all the claims that are issued by the federation server. Do the following:
a. Open Default.aspx.cs in a text editor.
b. Search the file for the second instance of ExpectedClaims .
c. Comment out the entire IF statement and its braces. Indicate comments by typing “//” (without the
quotes) at the beginning of a line.
d. Your FOREACH statement should now look like this code example.
Foreach (claim claim in claimsIdentity.Claims)

{
//Before showing the claims validate that this is an expected claim
//If it is not in the expected claims list then don’t show it
//if (ExpectedClaims.Contains( claim.ClaimType ) )
// {
writeClaim( claim, table );
//}
}
e. Save and close Default.aspx.cs.

f. Open web.config in a text editor.
g. Remove the entire <microsoft.identityModel>section. Remove everything starting from
including <microsoft.identityModel> and up to and including </microsoft.identityModel> .
h. Save and close web.config.
4. Configure IIS Manager
a. Open Internet Information Services (IIS ) Manager.
b. Go to Application Pools, right-click DefaultAppPool to select Advanced Settings. Set Load User
Profile to True, and then click OK.
c. Right-click DefaultAppPool to select Basic Settings. Change the .NET CLR Version to .NET CLR
Version v2.0.50727.
d. Right-click Default Web Site to select Edit Bindings.
e. Add an HTTPS binding to port 443 with the SSL certificate that you have installed.
f. Right-click Default Web Site to select Add Application.
g. Set the alias to claimapp and the physical path to c:inetpubclaimapp.
5. To configure claimapp to work with your federation server, do the following:
a. Run FedUtil.exe, which is located in C:Program Files (x86)Windows Identity Foundation
SDKv3.5.
b. Set the application configuration location to C:inetputclaimappweb.config and set the application
URI to the URL for your site, https://webserv1.contoso.com /claimapp/. Click Next.
c. Select Use an existing STS and browse to your AD FS server's metadata URL
https://adfs1.contoso.com/federationmetadata/2007-06/federationmetadata.xml. Click
Next.
d. Select Disable certificate chain validation, and then click Next.
e. Select No encryption, and then click Next. On the Offered claims page, click Next.
f. Select the check box next to Schedule a task to perform daily WS -Federation metadata
updates. Click Finish.
g. Your sample application is now configured. If you test the application URL
https://webserv1.contoso.com/claimapp, it should redirect you to your federation server. The
federation server should display an error page because you have not yet configured the relying party
trust. In other words, you have not secured this test application by AD FS.
You must now secure your sample application that runs on your web server with AD FS. You can do this by adding
a relying party trust on your federation server (ADFS1). For a video, see Active Directory Federation Services How -
To Video Series: Add a Relying Party Trust.
Create a relying party trust on your federation server
1. On you federation server (ADFS1), in the AD FS Management console, navigate to Relying Party Trusts,
and then click Add Relying Party Trust.
2. On the Select Data Source page, select Import data about the relying party published online or on a
local network, enter the metadata URL for claimapp, and then click Next. Running FedUtil.exe created a
metadata .xml file. It is located at
https://webserv1.contoso.com/claimapp/federationmetadata/2007-06/federationmetadata.xml.
3. On the Specify Display Name page, specify the display name for your relying party trust, claimapp, and
then click Next.
4. On the Configure Multi-factor Authentication Now? page, select I do not want to specify multi-
factor authentication setting for this relying party trust at this time, and then click Next.
5. On the Choose Issuance Authorization Rules page, select Permit all users to access this relying party,
6. On the Ready to Add Trust page, click Next.
7. On the Edit Claim Rules dialog box, click Add Rule.
8. On the Choose Rule Type page, select Send Claims Using a Custom Rule, and then click Next.
9. On the Configure Claim Rule page, in the Claim rule name box, type All Claims. In the Custom rule
box, type the following claim rule.
c:[ ]
10. Click Finish, and then click OK.
Step 4: Configure the client computer (Client1)

Set up another virtual machine and install Windows 8.1. This virtual machine must be on the same virtual network
as the other machines. This machine should NOT be joined to the Contoso domain.
The client MUST trust the SSL certificate that is used for the federation server (ADFS1), which you set up in Step 2:
Configure the federation server (ADFS1) with Device Registration Service. It must also be able to validate
certificate revocation information for the certificate.
You also must set up and use a Microsoft account to log on to Client1.
See Also
Active Directory Federation Services How -To Video Series: Installing an AD FS Server Farm
Active Directory Federation Services How -To Video Series: Updating Certificates
Active Directory Federation Services How -To Video Series: Add a Relying Party Trust
Active Directory Federation Services How -To Video Series: Enabling the Device Registration Service
Active Directory Federation Services How -To Video Series: Installing the Web Application Proxy
Walkthrough Guide: Manage Risk with Additional
Multi-Factor Authentication for Sensitive Applications
About This Guide

This walkthrough provides instructions for configuring multifactor authentication (MFA) in Active Directory
Federation Services (AD FS ) in Windows Server 2012 R2 based on the user's group membership data.
For more information about MFA and authentication mechanisms in AD FS, see Manage Risk with Additional
Multi-Factor Authentication for Sensitive Applications.
This walkthrough consists of the following sections:
Step 1: Setting up the lab environment
Step 2: Verify the default AD FS authentication mechanism
Step 3: Configure MFA on your federation server
Step 4: Verify MFA mechanism

In order to complete this walkthrough, you need an environment that consists of the following components:
An Active Directory domain with a test user and group accounts, running on Windows Server 2012 R2 or an
Active Directory domain running on Windows Server 2008, Windows Server 2008 R2, or Windows Server
2012 with its schema upgraded to Windows Server 2012 R2
A federation server running on Windows Server 2012 R2
A web server that hosts your sample application
A client computer from which you can access the sample application
WARNING
It is highly recommended (both in a production and test environments) that you do not use the same computer to be your
federation server and your web server.
In this environment, the federation server issues the claims that are required so that users can access the sample
application. The Web server hosts a sample application that will trust the users who present the claims that the
federation server issues.
For instructions on how to set up this environment, see Set up the lab environment for AD FS in Windows Server
2012 R2.
Step 2: Verify the default AD FS authentication mechanism

In this step you will verify the default AD FS access control mechanism (Forms Authentication for extranet and
Windows Authentication for intranet), where the user is redirected to the AD FS sign-in page, provides valid
credentials, and is granted access to the application. You can use the Robert Hatley AD account and the claimapp
sample application that you configured in Set up the lab environment for AD FS in Windows Server 2012 R2.
1. On your client computer, open a browser window, and navigate to your sample application:
https://webserv1.contoso.com/claimapp.
This action automatically redirects the request to the federation server and you are prompted to sign in with
a username and password.
2. Type in the credentials of the Robert Hatley AD account that you created in Set up the lab environment for
AD FS in Windows Server 2012 R2.
You will be granted access to the application.
Step 3: Configure MFA on your federation server

There are two parts to configuring MFA in AD FS in Windows Server 2012 R2:
Select an additional authentication method
Set up MFA policy
Select an additional authentication method
In order to set up MFA, you must select an additional authentication method. In this walkthrough, for additional
authentication method, you can choose between the following options:
Select Certificate authentication method that is available in AD FS in Windows Server 2012 R2 by default
Configure and select Windows Azure Multi-Factor Authentication
Certificate authentication
Complete either of the following procedures to select Certificate authentication as the additional authentication
method:
To c o n f i g u re C e rt i f i c a t e a u t h e n t i c a t i o n a s a n a d d i t i o n a l a u t h e n t i c a t i o n me t h o d v i a t h e A D F S M a n a g e me n t C o n s o l e
1. On your federation server, in the AD FS Management Console, navigate to the Authentication Policies
node, and under Multi-factor Authentication section, click the Edit link next to the Global Settings sub-
section.
2. In the Edit Global Authentication Policy window, select Certificate Authentication as an additional
authentication method, and then click OK.
To c o n f i g u re C e rt i f i c a t e a u t h e n t i c a t i o n a s a n a d d i t i o n a l a u t h e n t i c a t i o n me t h o d v i a W i n d o w s P o w e r Sh e l l
command:
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider CertificateAuthentication
WARNING
To verify that this command ran successfully, you can run the Get-AdfsGlobalAuthenticationPolicy command.
Windows Azure Multi-Factor Authentication

Complete the following procedures in order to download and configure and select Windows Azure Multi-Factor
Authentication as additional authentication on your federation server:
1. Create a Multi-Factor Authentication Provider via the Windows Azure Portal
2. Download the Windows Azure Multi-Factor Authentication Server
3. Install the Windows Azure Multi-Factor Authentication Server on your Federation Server
4. Configure Windows Azure Multi-Factor Authentication as an additional authentication method
Cr eat e a Mu l t i -Fac t o r A u t h en t i c at i o n Pr o vi der vi a t h e W i n do w s A z u r e Po r t al
1. Log on to the Windows Azure Portal as an Administrator.

2. On the left, select Active Directory.
3. On the Active Directory page, at the top, select Multi-Factor Auth Providers. Then at the bottom, click
New.
4. Under App Services->Active Directory, select Multi-Factor Auth Provider, and select Quick Create.
5. Under App Services, select Active Auth Providers, and select Quick Create.
6. Fill in the following fields and select Create.
a. Name - The name of the Multi-Factor Auth Provider.
b. Usage Model - The usage model of the Multi-Factor Authentication Provider.
Per Authentication - purchasing model that charges per authentication. Typically used for
scenarios that use Windows Azure Multi-Factor Authentication in a consumer-facing
application.
Per Enabled User - purchasing model that charges per enabled user. Typically used for
employee-facing scenarios such as Office 365.
For additional information on usage models, see Windows Azure pricing details.
c. Directory - The Windows Azure Active Directory tenant that the Multi-Factor Authentication
Provider is associated with. This is optional as the provider does not have to be linked to Windows
Azure Active Directory when securing on-premises applications.
7. Once you click create, the Multi-Factor Authentication Provider will be created and you should see a
message stating: Successfully created Multi-Factor Authentication Provider. Click Ok.
Next, you must download the Windows Azure Multi-Factor Authentication Server. You can do this by launching the
Windows Azure Multi-Factor Authentication Portal through the Windows Azure portal.
D o w n l o a d t h e W i n d o w s A z u r e M u l t i - F a c t o r A u t h e n t i c a t i o n Se r v e r
1. Log on to the Windows Azure Portal as an Administrator, and click on the Multi-Factor Authentication
Provider you created in the procedure above. Then click the Manage button.
This launches the Windows Azure Multi-Factor Authentication portal.
2. In the Windows Azure Multi-Factor Authentication portal, click Downloads, and then click Download
to download a copy of the Windows Azure Multi-Factor Authentication Server.
Once you have downloaded the executable for the Windows Azure Multi-Factor Authentication Server, you must
install it on your federation server.
I n st a l l t h e W i n d o w s A z u r e M u l t i - F a c t o r A u t h e n t i c a t i o n Se r v e r o n y o u r F e d e r a t i o n Se r v e r
1. Download and double-click on the executable for the Windows Azure Multi-Factor Authentication Server.
This will begin the installation.
2. On the License Agreement screen, read the agreement, select I Agree and click Next.
3. Ensure that the destination folder is correct and click Next.
4. Once the installation complete, click Finish.
You are now ready to launch the Windows Azure Multi-Factor Authentication server that you installed on your
federation server and configure it as an additional authentication method.
C o n fi g u r e W i n d o w s A z u r e M u l t i - F a c t o r A u t h e n t i c a t i o n a s a n a d d i t i o n a l a u t h e n t i c a t i o n m e t h o d
1. Launch Windows Azure Multi-Factor Authentication from where you installed it on your federation
server, and on the Welcome page, check the Skip using the Authentication Configuration Wizard
checkbox and click Next.
2. To activate the Multi-Factor Authentication Server, go back to the page in the Multi-Factor Authentication
management portal where you downloaded the Multi-Factor Authentication Server and click the Generate
Activation Credentials button. In the Multi-Factor Authentication Server user interface, enter the
credentials that were generated and click Activate.
3. Next, the Multi-Factor Authentication Server user interface prompts you to run the Multi-Server
Configuration Wizard. Select No.
IMPORTANT
You can skip completing the Multi-Server Configuration Wizard given the lab environment with only one
federation server that is used to complete this walkthrough. However, if your environment contains several federation
servers, you must install the Multi-Factor Authentication Server and complete the Multi-Server Configuration
Wizard on each federation server in order to enable replication between the Multi-Factor servers running on your
federation servers.
4. In the Multi-Factor Authentication Server user interface, select the Users icon, click Import from Active
Directory, select the Robert Hatley account to provision it in Windows Azure Multi-Factor Authentication,
and then click Import.
5. In the Users list, select the Robert Hatley account, click Edit, and in the Edit User window, provide a cell
phone number of this account, make sure the Enabled checkbox is checked, and then click Apply.
6. In the Users list, select the Robert Hatley account, and click Test. In the Test User window, provide the
credentials for the Robert Hatley account. When the cell phone rings, press '#' to complete the account
verification.
7. In the Multi-Factor Authentication Server user interface, select the AD FS icon, make sure that Allow
user enrollment, Allow users to select method (including Phone call and Text message), Use security
questions for fallback and Enable logging checkboxes are checked, click Install AD FS Adapter, and
complete the Multi-Factor Authentication AD FS Adapter installation wizard.
NOTE
The Multi-Factor Authentication AD FS Adapter installation wizard creates a security group called PhoneFactor
Admins in your Active Directory and then adds the AD FS service account of your federation service to this group.
It is recommended that you verify on your domain controller that the PhoneFactor Admins group is indeed created
and that the AD FS service account is a member of this group.
If necessary, add the AD FS service account to the PhoneFactor Admins group on your domain controller manually.
For additional details on installing the AD FS Adapter, click the Help link in the top right corner of the Multi-
Factor Authentication Server.
8. To register the adapter in your federation service, on your federation server, launch the Windows PowerShell
command window, and run the following command:
. The
\Program Files\Multi-Factor Authentication Server\Register-MultiFactorAuthenticationAdfsAdapter.ps1
adapter is now registered as WindowsAzureMultiFactorAuthentication. You must restart your AD FS
service for the registration to take effect.
9. To configure Windows Azure Multi-Factor Authentication as the additional authentication method, in the AD
FS Management Console, navigate to the Authentication Policies node, and under Multi-factor
Authentication section, click the Edit link next to the Global Settings sub-section. In the Edit Global
Authentication Policy window, select Multi-Factor Authentication as an additional authentication
method, and then click OK.
NOTE
You can customize the name and description of the Windows Azure Multi-Factor Authentication method, as well as
any configured third-party authentication method, as it appears in your AD FS UI, by running the Set-
AdfsAuthenticationProviderWebContent cmdlet. For more information, see
https://technet.microsoft.com/library/dn479401.aspx
Set up MFA policy

In order to enable MFA, you must set up the MFA policy on your federation server. For this walkthrough, per our
MFA policy, Robert Hatley account is required to undergo MFA because he belongs to the Finance group that
you set up in Set up the lab environment for AD FS in Windows Server 2012 R2.
You can set up the MFA policy either via the AD FS Management Console or using the Windows PowerShell.
To c o n fi g u r e t h e M F A p o l i c y b a se d o n u se r ' s g r o u p m e m b e r sh i p d a t a fo r ' c l a i m a p p ' v i a t h e A D F S M a n a g e m e n t C o n so l e
1. On your federation server, in the AD FS Management Console, navigate to Authentication Policies\Per

Relying Party Trust node, and select the relying party trust that represents your sample application
(claimapp).
2. Either in the Actions page or by right-clicking claimapp, select Edit Custom Multi-factor
Authentication.
3. In the Edit Relying Party Trust for claimapp window, click the Add button next to the Users/Groups list.
Type in Finance for the name of your AD group that you created in Set up the lab environment for AD FS in
Windows Server 2012 R2, and click Check Names, and when the name is resolved, click OK.
4. Click OK in the Edit Relying Party Trust for claimapp window.
To c o n fi g u r e t h e M F A p o l i c y b a se d o n u se r ' s g r o u p m e m b e r sh i p d a t a fo r ' c l a i m a p p ' v i a W i n d o w s P o w e r Sh e l l
command:
$rp = Get-AdfsRelyingPartyTrust -Name claimapp
$GroupMfaClaimTriggerRule = 'c:[Type ==
"https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "^(?i) <group_SID>$"] =>
issue(Type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value =
Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AdditionalAuthenticationRules
$GroupMfaClaimTriggerRule
NOTE
Make sure to replace <group_SID> with the value of the SID of your AD group Finance.
Step 4: Verify MFA mechanism

In this step you will verify the MFA functionality that you set up in the previous step. You can use the following
procedure to verify that Robert Hatley AD user can access your sample application and this time is required to
undergo MFA because he belongs to the Finance group.
2. Type in the credentials of the Robert Hatley AD account.
At this point, because of the MFA policy that you configured, the user will be prompted to undergo
additional authentication. The default message text is For security reasons, we require additional
information to verify your account. However, this text is fully customizable. For more information about
how to customize the sign-in experience, see Customizing the AD FS Sign-in Pages.
If you configured Certificate authentication as the additional authentication method, the default message text
is Select a certificate that you want to use for authentication. If you cancel the operation, please
close your browser and try again.
If you configured Windows Azure Multi-Factor Authentication as the additional authentication method, the
default message text is A call will be placed to your phone to complete your authentication. For more
information about signing in with Windows Azure Multi-Factor Authentication and using various options for
the preferred method of verification, see Windows Azure Multi-Factor Authentication Overview.
See Also
Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications Set up the lab environment for
AD FS in Windows Server 2012 R2
Walkthrough Guide: Manage Risk with Conditional
Access Control
About This Guide

This walkthrough provides instructions for managing risk with one of the factors (user data) available through the
conditional access control mechanism in Active Directory Federation Services (AD FS ) in Windows Server 2012
R2. For more information about conditional access control and authorization mechanisms in AD FS in Windows
Server 2012 R2, see Manage Risk with Conditional Access Control.
This walkthrough consists of the following sections:
Step 2: Verify the default AD FS access control mechanism
Step 3: Configure conditional access control policy based on user data
Step 4: Verify conditional access control mechanism

In order to complete this walkthrough, you need an environment that consists of the following components:
An Active Directory domain with a test user and group accounts, running on Windows Server 2008,
Windows Server 2008 R2, or Windows Server 2012 with its schema upgraded to Windows Server 2012 R2
or an Active Directory domain running on Windows Server 2012 R2
A federation server running on Windows Server 2012 R2
A web server that hosts your sample application
A client computer from which you can access the sample application
WARNING
It is highly recommended (both in production or test environments) that you do not use the same computer to be your
federation server and your web server.
In this environment, the federation server issues the claims that are required so that users can access the sample
application. The Web server hosts a sample application that will trust the users who present the claims that the
federation server issues.
For instructions on how to set up this environment, see Set up the lab environment for AD FS in Windows Server
2012 R2.
Step 2: Verify the default AD FS access control mechanism

In this step you will verify the default AD FS access control mechanism, where the user is redirected to the AD FS
sign-in page, provides valid credentials, and is granted access to the application. You can use the Robert Hatley AD
account and the claimapp sample application that you configured in Set up the lab environment for AD FS in
To verify the default AD FS access control mechanism
Step 3: Configure conditional access control policy based on user data

In this step you will set up an access control policy based on the user group membership data. In other words, you
will configure an Issuance Authorization Rule on your federation server for a relying party trust that represents
your sample application - claimapp. By this rule's logic, Robert Hatley AD user will be issued claims that are
required to access this application because he belongs to a Finance group. You have added the Robert Hatley
account to the Finance group in Set up the lab environment for AD FS in Windows Server 2012 R2.
You can complete this task using either AD FS Management Console or via Windows PowerShell.
To configure conditional access control policy based on user data via the AD FS Management Console
1. In the AD FS Management Console, navigate to Trust Relationships, and then Relying Party Trusts.
2. Select the relying party trust that represents your sample application ( claimapp), and then either in the
Actions pane or by right-clicking this relying party trust, select Edit Claim Rules.
3. In the Edit Claim Rules for claimapp window, select Issuance Authorization Rules tab and click Add
Rule.
4. In the Add Issuance Authorization Claim Rule Wizard, on the Select Rule Template page, select
Permit or Deny Users Based on an Incoming Claim claim rule template and then click Next.
5. On the Configure Rule page, do all of the following and then click Finish:
a. Enter a name for the claim rule, for example TestRule.
b. Select Group SID as Incoming claim type.
c. Click Browse, type in Finance for the name of your AD test group, and resolve it for the Incoming
claim value field.
d. Select the Deny access to users with this incoming claim option.
6. In the Edit Claim Rules for claimapp window, make sure to delete the Permit Access to All Users rule
that was created by default when you created this relying party trust.
To configure conditional access control policy based on user data via Windows PowerShell
1. On your federation server, open the Windows PowerShell command window and run the following command:
`$rp = Get-AdfsRelyingPartyTrust -Name claimapp`
`$GroupAuthzRule = '@RuleTemplate = "Authorization" @RuleName = "Foo" c:[Type ==
"https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "^(?i)<group_SID>$"] =>issue(Type
= "https://schemas.microsoft.com/authorization/claims/deny", Value = "DenyUsersWithClaim");'
Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -IssuanceAuthorizationRules $GroupAuthzRule`
NOTE
Make sure to replace <group_SID> with the value of the SID of your AD Finance group.
Step 4: Verify conditional access control mechanism

In this step you will verify the conditional access control policy that you set up in the previous step. You can use the
following procedure to verify that Robert Hatley AD user can access your sample application because he belongs
to the Finance group and AD users who do not belong to the Finance group cannot access the sample application.
https://webserv1.contoso.com/claimapp
3. Type in the credentials of another AD user that does NOT belong to the Finance group. (For more
information on how to create user accounts in AD, see
https://technet.microsoft.com/library/cc7833232.aspx.
At this point, because of the access control policy that you set up in the previous step, an 'access denied'
message is displayed for this AD user that does NOT belong to the Finance group. The default message text
is You are not authorized to access this site. Click here to sign out and sign in again or contact your
administrator for permissions. However, this text is fully customizable. For more information about how
to customize the sign-in experience, see Customizing the AD FS Sign-in Pages.
See Also
Manage Risk with Conditional Access Control Set up the lab environment for AD FS in Windows Server 2012 R2
This topic demonstrates how to use Workplace Join to connect your Windows device with your workplace and how
to access a web application by using Single Sign-On. You must complete the steps in the Set up the lab
environment for AD FS in Windows Server 2012 R2 section before you can try out this walkthrough.
Access the web application before device registration

In this walkthrough, you access a company web application before you join your device to the workplace. The
webpage displays the claims that were included in your security token. Notice that the list of claims does not
include any information about your device. You might also observe that you do not have Single Sign-On.
To access the web application before you use Workplace Join on your device
1. Log on to Client1 with your Microsoft account.
2. Open Internet Explorer and browse to your generic claims app, https://webserv1.contoso.com/claimapp.
3. Log on to the webpage by using a company domain account: roberth@contoso.com, password:
P@ssword.
4. The webpage lists all the claims in your security token. Only user claims are present in your security token.
5. Close Internet Explorer.
6. Open Internet Explorer and navigate to the same claims app, https://webserv1.contoso.com/claimapp.
7. Notice that you are prompted to enter your credentials again. You are not connected to the workplace from a
device with Workplace Join and therefore do not have Single Sign-On.
Join your device with Workplace Join

IMPORTANT
For Workplace Join to succeed, the client computer (Client1) must trust the SSL certificate that was used to configure Active
Directory Federation Services (AD FS) in Step 2: Configure the Federation Server with Device Registration Service (ADFS1). It
must also be able to validate revocation information for the certificate. If you have any issues with Workplace Join, you can
view the event log on Client1.
To see the event log, open Event Viewer, expand Applications and Services Logs, expand Microsoft, expand Windows,
and then click Workplace Join.
To join your device with Workplace Join

2. On the Start screen, open the Charms bar, and then select the Settings charm. Select Change PC Settings.
3. On the PC Settings page, select Network, and then click Workplace.
4. In the Enter your UserID to get workplace access or turn on device management box, type
roberth@contoso.com, and then click Join.
5. When you are prompted for credentials, type roberth@contoso.com, and password: P@ssword. Click OK.
6. You should now see the message: "This device has joined your workplace network."
Access the web application after joining the workplace
In this part of the demonstration, you access a company web application from your device that is connected with
Workplace Join. The webpage displays the claims that were included in your security token. Notice that the list of
claims includes both device and user information. You might also observe that you now have Single Sign-On.
To a c c e ss t h e w e b a p p l i c a t i o n a ft e r j o i n i n g t h e w o r k p l a c e

2. Open Internet Explorer and browse to your generic claims app, https://webserv1.contoso.com/claimapp.
3. Log on to the webpage by using a company domain account: roberth@contoso.com, password:
P@ssword.
4. The webpage lists claims in your security token. Your token contains both user and device claims.
5. Close Internet Explorer.
6. Open Internet Explorer and navigate to the same claims app, https://webserv1.contoso.com/claimapp.
7. Notice that you are not prompted to enter your credentials again. You are connected from a device with
Workplace Join and therefore have Single Sign-On.
See Also
Applications Set up the lab environment for AD FS in Windows Server 2012 R2 Walkthrough: Workplace Join with
an iOS Device
IMPORTANT
This method is relevant for only fully on-prem customers. Hybrid or cloud-only customers must not use this method to
register their iOS devices. And this method is not compatible when the on-prem customers decide to move to cloud. The
device must be unregistered and registered with the cloud.
This topic demonstrates Workplace Join on an iOS device. You must complete the steps in the Set up the lab
environment for AD FS in Windows Server 2012 R2 section before you can try out this walkthrough. You can use
the device to access the same company web application that you accessed in Walkthrough: Workplace Join with a
Windows Device.
Join an iOS device with Workplace Join

IMPORTANT
When on-premises DRS is configured, the iOS device must trust the Secure Socket Layer (SSL) certificate that was used to
configure Active Directory Federation Services (AD FS) in Step 2: Configure the federation server (ADFS1) with Device
Registration Service, for Workplace Join to succeed.
If the AD FS SSL certificate was issued from a test certification authority (CA), you must install the certification authority
certificate on your iOS device.
If your certification authority certificate is published on a website, you can browse to the website from your iOS device and
install the certificate.
In this demonstration, you join the device to the workplace.

To join an iOS device to a workplace
1. When Azure Active Directory Device Registration service is the configured DRS: Open Apple
Safari and navigate to Azure Active Directory Device Registration service Over-the-Air Profile
endpoint for iOS devices, <
https://enterpriseregistration.windows.net/enrollmentserver/otaprofile/<yourdomainname > Where <
yourdomainname > is the domain name that you have configured with Azure Active Directory. For
example, if your domain name is contoso.com, the URL would be:
https://enterpriseregistration.windows.net/enrollmentserver/otaprofile/contoso.com
When On-premises DRS is the configured DRS: Open Apple Safari and navigate to the Device
Registration Service (DRS ) Over-the-Air Profile endpoint for iOS devices,
https://adf1s.contoso.com/enrollmentserver/otaprofile
There are many ways to communicate this URL to your users. One recommended way is to publish this URL
in a custom application access denied message in AD FS. This is covered in the upcoming section: Create an
application access policy and custom access denied message
2. Log on to the webpage by using a company domain account: roberth@contoso.com and password:
P@ssword.
3. You are prompted to install a profile. On the Install Profile screen, click Install.
4. When prompted to confirm installation of the profile, click Install Now.
5. If your device requires a PIN to unlock the device, you are prompted to enter your PIN.
6. The profile installation is finished when you see the Profile Installed screen. Click Done.
Return to Safari. A message informs you that you can close or leave Safari.
TIP
To view or remove the Workplace Join profile, browse to Settings, click General, and then click Profiles on your iOS device.
See Also
Applications
Walkthrough: Workplace Join to an Android device
Join your device with Workplace Join

NOTE
Android workplace join requires Azure Active Directory Device Registration Service. In order to enforce conditional device
policies on-premises, Directory Synchronization Tool (DirSync) must be deployed with device object write-back option enabled.
At the present time, device write-back to Active Directory from Azure Active Directory can take up-to 3 hours. As such, users
must wait for 3 hours to access on-premises web applications, after creating a work account. For more information about
deploying Azure Active Directory Device Registration service, see, Azure Active Directory Device Registration Service Overview
Create a Work account that joins your device with workplace Join
1. You will need to install Azure Authenticator application on your device to create a work account that joins your
device with Workplace join. The following URL has instructions on how to install Azure authenticator app on
your Android device and add a work account. The work account makes your Android device into a trusted
device and provides Single Sign-On (SSO ) to the applications on device. You can use the trusted device to
access web applications and modern line-of-business applications as recommended by your IT administrator.
For more information, see Azure Authenticator for Android.
See Also
Applications Setting up On-premises Conditional Access using Azure Active Directory Device Registration Service
Troubleshooting AD FS
AD FS has a lot of moving pieces, touches many different things and has many different dependencies. Naturally,
this can give rise to various issues. This document is designed to get you started on troubleshooting these issues.
This document will introduce you to the typical areas that you should focus on, how to enable features for
additional information, and various tools that can be used to track down problems.
NOTE
For additional information see ADFS Help which provides effective tools in one place that makes it easier for users and
administrators to resolve authentication issues at a quicker pace.
What to Check First

Before you dive into in-depth troubleshooting, there are a few things that you should check first. They are:
DNS Configuration - can you resolve the name of the federation service? This should resolve to either the
load balancer's IP address or the IP address of one of the AD FS servers in your farm. For more information
see AD FS Troubleshooting - DNS.
AD FS Endpoints - can you browse to the AD FS endpoints? By browsing to this you can determine whether
or not your AD FS web server is responding to requests. If you can get to this file, then you know that AD FS
is servicing requests over 443 just fine. For more information see AD FS Troubleshooting - Endpoints.
Idp-Initiated Sign On - can you log in and authenticate via the Idp-Initiated Sign On page? You need to
ensure that this page was enabled because it is disabled by default. Use
Set-AdfsProperties -EnableIdPInitiatedSignOn $true to enable the page. If you can sign in and authenticate
then you know that AD FS is working in this area. For more information see AD FS Troubleshooting - SignOn.
## Common Troubleshooting Areas
NAME DESCRIPTION
Event Logging and Auditing Use the Windows Event Logs to view high level and low level
information via the Admin and Trace logs. It can also be used
to view security auditing.
SQL Connectivity Information on testing the connectivity between your AD FS

servers and the backend SQL databases
Claims Issuance Information on determining whether AD FS is issuing claims

correctly.
Loop Detection Information on determining and preventing users from being

bounced back and forth between the Idp and an RP.
Certificates Typcial certificate issues that can arise
Fiddler Information on how to install and using Fiddler
WS-Federation with Fiddler Detailed Fiddler trace of a WS-Federation interaction

NAME DESCRIPTION
Claim Rules Information on troubleshooting claim rules and their syntax
Integrated Windows Authentication Information on troubleshooting integrated authentication.
Azure AD Information on troubleshooting AD FS interaction with Azure

AD.
AD FS Diagnostics Analyzer AD FS Help Diagnostics Analyzer can help perform basic AD

FS checks using the diagnostics PowerShell module.
AD FS Help Diagnostics Analyzer
AD FS has numerous settings that support the wide variety of functionality it provides for authentication and
application development. During troubleshooting, it is recommended to ensure that all of the AD FS settings are
correctly configured. Doing a manual check of these settings can sometimes be time consuming. AD FS Help
Diagnostics Analyzer can help perform the basic checks using the ADFSToolbox PowerShell module. After
performing the checks, AD FS Help provides the Diagnostics Analyzer to help you easily visualize the results and
offer remediation steps.
The complete operation takes 3 simple steps:
1. Setup the ADFSToolbox module on the primary AD FS server or WAP server
2. Execute the diagnostics and upload the file to AD FS Help
3. View diagnostics analysis and resolve any issues
Go to AD FS Help Diagnostics Analyzer (https://aka.ms/adfsdiagnosticsanalyzer) to start troubleshooting.
Step 1: Setup the ADFSToolbox module on AD FS server

To run the Diagnostics Analyzer, you must install the ADFSToolbox PowerShell module. If the AD FS server has
connectivity to the internet, you can install the ADFSToolbox module directly from the PowerShell gallery. In case
of no connectivity to the internet, clone the GitHub repository for manual installation.
Setup using PowerShell gallery
If the AD FS server has internet connectivity, it is recommended to install the ADFSToolbox module directly from
the PowerShell gallery using the PowerShell commands given below.
Install-Module -Name ADFSToolbox -force

Import-Module ADFSToolbox -force
Setup manually by cloning the repository

The ADFSToolbox module can be installed manually from GitHub directly. Follow the instructions below for
cloning the repository and installing the ADFSToolbox module on the AD FS server.
1. Download the repository
2. Unzip the downloaded file and copy the adfsToolbox-master folder to %SYSTEMDRIVE%\Program
Files\WindowsPowerShell\Modules\.
3. Import the PowerShell Module. In an elevated PowerShell window, run the following:
Import-Module ADFSToolbox -Force
Step 2: Execute the diagnostics and upload the file to AD FS Help

A single command can be used to conveniently execute the diagnostics tests across all the AD FS servers in the
farm. The PowerShell module will use remote PS sessions to execute the diagnostics tests across different servers
in the farm.
Export-AdfsDiagnosticsFile [-adfsServers <list of servers>]
In a Server 2016 AD FS farm, the command will read the list of AD FS servers from AD FS configuration. The
diagnostics tests are then attempted against each server in the list. If the list of AD FS servers is not available
(example 2012R2), then the tests are run against the local machine. To specify a list of servers against which the
tests are to be executed, use the adfsServers argument to provide a list of servers. An example is provided below
Export-AdfsDiagnosticsFile -adfsServers @("sts1.contoso.com", "sts2.contoso.com", "sts3.contoso.com")
The result is a JSON file which is created in the same directory where the command was run. The name of the file
is ADFSDiagnosticsFile-<timestamp>. An example file name is ADFSDiagnosticsFile-20180716124030.
In step 2 on https://aka.ms/adfsdiagnosticsanalyzer use the file browser to select the result file to upload.
Click on Upload to finish the upload and move to the next step.
Step 3: View diagnostics analysis and resolve any issues

There are four sections of the test results:
1. Failed: This section contains list of tests that failed. Each result comprises of:
2. Warning: This section contains a list of tests that have resulted in a warning. These issues will not likely result in
any issues around authentication on a broader scale but should be addressed at the earliest.
3. Not applicable: This section contains the list of tests that were not executed because they were not applicable
for the particular server on which the command was executing.
4. Passed: This section contains the list of tests that passed and have no action item for the user.
Each test result is displayed with details that describe the test and the resolution the steps:
1. Test Name: Name of the test that was executed
2. Details: Description of the overall operation that was performed during the test
3. Resolution steps: The suggested steps to resolve the issue highlighted by the test
Next
Use AD FS Help troublehsooting guides
AD FS Troubleshooting - Azure AD
With the growth of the cloud, a lot of companies have been moving to use Azure AD for their various apps and
services. Federating with Azure AD has become a standard practice with many organizations. This document will
cover some of the aspects of troubleshooting issues that arise with this federation. Several of the topics in the
general troubleshooting document still pertain to federating with Azure so this document will focus on just
specifics with Azure AD and AD FS interaction.
Redirection to AD FS
Redirection occurs when you sign-in to an application such as Office 365 and you are "redirected" to your
organizations AD FS servers to sign-in.
First things to check

If redirection is not occurring there are a few things you want to check
1. Make sure that your Azure AD tenant is enabled for federation by signing in to the Azure portal and checking
under Azure AD Connect.
1. Make sure that your custom domain is verified by clicking on the domain next to Federation in the Azure
portal.
2. Finally, you want to check DNS and make sure that your AD FS servers or WAP servers are resolving from
the internet. Verify that this resolves and that you are able to navigate to it.
3. You can also use the PowerShell cmdlt Get-AzureADDomain to get this information also.
You are receiving an Unknown Auth method error

You may encounter an "Unknown Auth method” error stating that AuthnContext is not supported at the AD FS or
STS level when you are redirected from Azure.
This is most common when Azure AD redirects to the AD FS or STS by using a parameter that enforces an
authentication method.
To enforce an authentication method, use one of the following methods:
For WS -Federation, use a WAUTH query string to force a preferred authentication method.
For SAML2.0, use the following:
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
When the enforced authentication method is sent with an incorrect value, or if that authentication method is
not supported on AD FS or STS, you receive an error message before you are authenticated.
METHOD OF AUTHENTICATION WANTED WAUTH URI
User name and password authentication urn:oasis:names:tc:SAML:1.0:am:password
SSL client authentication urn:ietf:rfc:2246
Windows integrated authentication urn:federation:authentication:windows
Supported SAML authentication context classes
AUTHENTICATION METHOD AUTHENTICATION CONTEX T CLASS URI
User name and password urn:oasis:names:tc:SAML:2.0:ac:classes:Password
Password protected transport urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTran

sport
Transport Layer Security (TLS) client urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
X.509 certificate urn:oasis:names:tc:SAML:2.0:ac:classes:X509
Integrated Windows authentication urn:federation:authentication:windows

AUTHENTICATION METHOD AUTHENTICATION CONTEX T CLASS URI
Kerberos urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos
To make sure that the authentication method is supported at the AD FS level, check the following.
AD FS 2.0
Under /adfs/ls/web.config, make sure that the entry for the authentication type is present.
<microsoft.identityServer.web>
<localAuthenticationTypes>
<add name="Forms" page="FormsSignIn.aspx" />
<add name="Integrated" page="auth/integrated/" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>
AD FS 2012 R2
Under AD FS Management, click Authentication Policies in the AD FS snap-in.
In the Primary Authentication section, click Edit next to Global Settings. You can also right-click Authentication
Policies and then select Edit Global Primary Authentication. Or, in the Actions pane, select Edit Global Primary
Authentication.
In the Edit Global Authentication Policy window, on the Primary tab, you can configure settings as part of the
global authentication policy. For example, for primary authentication, you can select available authentication
methods under Extranet and Intranet.
**Make sure that the required authentication method check box is selected.
AD FS 2016
Under AD FS Management, click Service and Authentication Methods in the AD FS snap-in.
In the Primary Authentication section, click Edit.
In the Edit Authentication Methods window, on the Primary tab, you can configure settings as part of the
authentication policy.
Tokens issued by AD FS
Azure AD throws error after token issuance
After AD FS issues a token, Azure AD may throw an error. In this situation, check for the following issues:
The claims that are issued by AD FS in token should match the respective attributes of the user in Azure AD.
the token for Azure AD should contain the following required claims:
WSFED:
UPN: The value of this claim should match the UPN of the users in Azure AD.
ImmutableID: The value of this claim should match the sourceAnchor or ImmutableID of the user
in Azure AD.
To get the User attribute value in Azure AD, run the following command line:
Get-AzureADUser –UserPrincipalName <UPN>
SAML 2.0:
IDPEmail: The value of this claim should match the user principal name of the users in Azure AD.
NAMEID: The value of this claim should match the sourceAnchor or ImmutableID of the user in Azure
AD.
For more information, see Use a SAML 2.0 identity provider to implement single sign-on.
Token-signing certificate mismatch between AD FS and Azure AD.
AD FS uses the token-signing certificate to sign the token that's sent to the user or application. The trust between
the AD FS and Azure AD is a federated trust that's based on this token-signing certificate.
However, if the token-signing certificate on the AD FS side is changed because of Auto Certificate Rollover or by
some intervention, the details of the new certificate must be updated on the Azure AD side for the federated
domain. When the Primary token-signing certificate on the AD FS is different from Azure ADs, the token that's
issued by AD FS is not trusted by Azure AD. Therefore, the federated user is not allowed to log on.
To fix this you can use the steps outline in Renew federation certificates for Office 365 and Azure Active Directory.
Other common things to check

The following is a quick list of things to check if you are having issues with AD FS and Azure AD interaction.
stale or cached credentials in Windows Credential Manager
Secure Hash Algorithm that's configured on the Relying Party Trust for Office 365 is set to SHA1
Next Steps
AD FS Troubleshooting - Certificates
AD FS requires the following certificates in order to work correctly. If any of these have not been setup or
configured properly then issues can arise.
Required certificates
AD FS requires the following certificates:
Federation trust – This requires that either a certificate chained to a mutually trusted Internet root Certificate
Authority (CA) is present in the trusted root store of both the claims provider and relying party Federation
Servers, a cross-certification design has been implemented in which each side has exchanged its root CA with
its partner, or self-signed certificates that have been imported on each side where appropriate.
Token-signing – Each Federation Service computer requires a token-signing certificate. The claims provider
token-signing certificate must be trusted by the relying party Federation Server. The relying party token-
signing certificate must be trusted by all applications that receive tokens from the RP Federation Server.
Secure Sockets Layer (SSL ) – The SSL certificate for the Federation Service must be present in a trusted
store on the Federation Server proxy computer and has a valid chain to a trusted Certificate Authority (CA)
store.
Certificate Revocation List (CRL ) – For any certificate that has a CRL published, the CRL must be accessible
to all clients and servers who need to access the certificate.
If any of the above are not configured correctly, AD FS will not work.
Common things to check with certificates

The following is a list of things that can arise and should be verified when trying to resolve a certificate issue.
Make sure that the certificate is trusted
SSL certs need to be trusted by the clients
Token signing certificates need to be trusted by the relying parties
Check the trust chain - every cert in the chain needs to be valid.
Verify the certificate expiration date
Check Certificate Revocation List (CRL ) accessibility
Make sure the CDP field is populated
Manually browse to the CDP
Make sure the certificate has not been revoked
Common certificate errors

The following table is a list of common errors and possible causes.
EVENT CAUSE RESOLUTION
Event 249 - A certificate could not be The certificate in question is not present Ensure that the certificate is installed in
found in the certificate store. In in the local certificate store, or the the LocalMAchine\My store on the AD
certificate rollover scenarios, this can service account does not have FS server. Ensure that the AD FS service
potentially cause a failure when the permission to the certificate’s private account has read access to the private
Federation Service is signing or key. key of the certificate.
decrypting using this certificate.
Event 315 - An error occurred during The certificate has been revoked. Ensure that the certificate is valid and
an attempt to build the certificate chain The certificate chain cannot be verified. has not been revoked.
for the claims provider trust signing Ensure that the CRL is accessible.
certificate. The certificate is expired or is not yet
valid.
for the relying party trust signing Ensure that the CRL is accessible.
valid.
for the relying party trust encryption Ensure that the CRL is accessible.
valid.
Event 319 -An error occurred while the The certificate has been revoked. Ensure that the certificate is valid and
certificate chain for the client certificate The certificate chain cannot be verified. has not been revoked.
was being built. Ensure that the CRL is accessible.
The certificate is expired or is not yet
valid.
Event 360 - A request was made to a The root CA that issued the client Ensure that the root CA that issued the
certificate transport endpoint, but the certificate is not trusted. client certificate is present in the trusted
request did not include a client The client certificate is expired. root store.
certificate. Ensure that the client certificate is not
The client certificate is self-signed and is expired.
not trusted.
If the client certificate is self-signed,
ensure that it has been added to the list
of trusted certificates, or replace the
self-signed certificate with a trusted
certificate.
Event 374 - An error occurred while The certificate has been revoked. Ensure that the certificate is valid and
building the certificate chain for the The certificate chain cannot be verified. has not been revoked.
claims provider trust encryption Ensure that the CRL is accessible.
valid.
Event 381 - An error occurred during One of the certificates configured for Ensure that all configured certificates
an attempt to build the certificate chain use on the AD FS server is expired or have not been revoked and have not
for configuration certificate. has been revoked. expired.
EVENT CAUSE RESOLUTION
Event 385 - AD FS detected that one or One of the certificates configured for Update the expired or soon-to-expire
more certificates in the AD FS use on the AD FS server has expired or certificate with a replacement. (If you
configuration database needs to be is nearing its expiration date. are using self-signed certificates and
updated manually. automatic certificate rollover is enabled,
this error may be ignored as it will self-
resolve.)
Event 387 - AD FS detected that one or The AD FS service account does not Ensure that the AD FS service account
more of the certificates that are have read permissions to the private has read permission to the private key
specified in the Federation Service were key of one or more configured of all configured certificates.
not accessible to the service account certificates.
that is used by the AD FS Windows
Service.
Event 389 - AD FS detected that one or One of your configured partner’s If you have manually created this trust,
more of your trusts require their certificates has expired, or is about to update the certificate configuration
certificates to be updated manually expire. This can apply to either a claims manually. If you used federation
because they are expired, or will expire provider trust or to a relying party metadata to create the trust, the
soon. trust. certificate will update automatically as
soon as the partner updates the
certificate.
Next Steps
AD FS Troubleshooting - Claims Rules Syntax
A claim is a statement that one subject makes about itself or another subject. Claims are issued by a relying party,
and they are given one or more values and then packaged in security tokens that are issued by the AD FS server.
This article deals with the claims syntax and creation. For information on claims issuance see AD FS
Troubleshooting - Claims Issuance.
NOTE
You can use ClaimsXRay on the ADFS Help site to assist in troubleshooting claims issues.
How claim rules are processed

Claim rules are processed through the claims pipeline using the claims engine. The claims engine is a logical
component of the Federation Service that examines the set of incoming claims presented by a user, and will then,
depending on the logic in each rule, produce an output set of claims.
How to create a claim rule

Claim rules are created separately for each federated trust relationship within the Federation Service and are not
shared across multiple trusts. You can either create a rule from a claim rule template, start from scratch by
authoring the rule using the claim rule language or use Windows PowerShell to customize a rule.
Understanding the components of the claim rule language

The claim rule language consists of the following components, separated by the “ =>” operator:
A condition - Used to check input claims and determine whether the issuance statement of the rule should
be executed. It represents a logical expression that must be evaluated to true to execute the rule body part.
An issuance statement
Example:
c:[type == "Name", value == "domain user"] => issue(type = "Role", value = "employee");
The following claim has the following:

condition - c:[type == "Name", value == "domain user"] - evaluates the input claim of whether the windows
account name is a domain user
issuance - issue(type = "Role", value = "employee") - if the condition is true, adds a new claim to the input
claim with the role of employee.
For more information on claims and the syntax see The Role of the Claims Rule Language.
Claims rule editor

Syntax checking is performed by the claims rule editor once you have completed the claim and click OK. So if you
have the incorrect syntax then the editor will let you know.
Event logs
When looking trying to troubleshoot a claim using the logs the best approach is to look for claims output. You can
look for 1000 and 1001 events in the event log.
Creating a sample application

You can also create a sample application the echoes your claims. For example you can use a sample application and
create a relying party that has the same claim you are trying to troubleshoot and see if the app has any issues with
that claim.
A good sample web app is available here. This app is a simple web app that echoes back the claims that it receives
from the relying party. In order to use this you need to edit the web.config app by:
changing https://app1.contoso.com/sampapp to the URL the you will be using for hosting the sampapp
changing all instances of sts.contoso.com to point you AD FS federation server
Replacing the thumbprint with your thumbprint
The following blog article has excellent, in-depth instructions, for setting this up.
Next Steps
AD FS Troubleshooting - DNS
One of the first things to check, if AD FS is not working or responding, is DNS name resolution. These are basic
tests to determine if the AD FS servers or WAP servers are being found on your network. For internal users, these
tests should resolve to the AD FS servers (STS ). For external users, these tests should resolve to the WAP servers.
The remainder of this document will show how to do some quick name resolution checks using command-line
tools.
Ping test
Verifies IP -level connectivity to another TCP/IP computer by sending Internet Control Message Protocol (ICMP )
Echo Request messages. The receipt of corresponding Echo Reply messages are displayed, along with round-trip
times. For more information, see Ping.
NOTE
Be aware that some organizations block this port on their servers and you may get a Request timed out response.
To use a PING test

1. Open a command prompt
2. Enter PING a. Example: PING sts.contoso.com
3. You should see a reply from the server
NSLookup
Displays information that you can use to diagnose Domain Name System (DNS ) infrastructure. For more
information, see NSLookup.
To use a NSLookup
2. Enter PING a. Example: nslookup sts.contoso.com
3. You should see the dns information for the server
Tracert
Determines the path taken to a destination by sending Internet Control Message Protocol (ICMP ) Echo Request or
ICMPv6 messages to the destination with incrementally increasing Time to Live (TTL ) field values. For more
information, see Tracert.
To use Tracert
2. Enter tracert a. Example: tracert sts.contoso.com
3. You should see the destination path used to reach the server
Next Steps
AD FS Troubleshooting - AD FS metadata endpoints
Endpoints provide access to the federation server functionality of AD FS, such as publishing federation metadata.
To verify that the AD FS server is responding to web requests, we can check the various endpoints.
Federation metadata test

Passive federation refers to scenarios where your browser is re-directed to the AD FS sign-in page. By testing the
metadata endpoint we can determine if the AD FS server is responding to web requests in these passive scenarios.
Use the following procedure to test the endpoint.
1. Using a web browser, navigate to your AD FS Federation metadata endpoint. For example:
https://sts.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml
2. The xml file should download locally to your machine.
3. Open it and verify that it contains information similar to the infomration below:
WS-MEX test (Active test)

WS -MetaDataExchange is a web services protocol and is part of the WS -Federation roadmap. It uses a SOAP
message to request metadata. By testing the endpoint we can determine if the AD FS server is responding to web
requests for WS -MetaDataExchange. Use the following procedure to test the endpoint.
1. Using a web browser, navigate to your AD FS Federation metadata endpoint. For example:
https://sts.contoso.com/adfs/services/trust/mex
2. The xml file should be displayed in the browser automatically. It should look like the image below:
Next Steps
AD FS Troubleshooting - Fiddler - WS-Federation
Step 1 and 2
This is the beginning of our trace. In this frame we see the following:
Request:
HTTP GET to our relying party ( http://sql1.contoso.com/SampApp)
Response:
The Response is a HTTP 302 (Redirect). The Transport data in the Response header shows where to redirect to
(https://sts.contoso.com/adfs/ls)
The redirect URL contains wa=wsignin 1.0 which tells us that our RP application has built a WS -Federation
sign-in request for us and sent this to the AD FS's /adfs/ls/ endpoint. This is known as Redirect binding.
Step 3 and 4
Request:
HTTP GET to our AD FS server(sts.contoso.com)
Response:
The Response is a prompt for credentials. This indicates that we are using forms authnetication
By clicking on the WebView of the Response you can see the credentials prompt.
Step 5 and 6
Request:
HTTP POST with our username and password.
We present our credentials. By looking at the Raw data in the request we can see the credentials
Response:
The response is Found and the MSIAuth encrypted cookie is created and returned. This is used to validate the
SAML assertion produced by our client. This is also known as the "authentication cookie" and will only be
present when AD FS is the Idp.
Step 7 and 8
Request:
Now that we have authenticated we do another HTTP GET to the AD FS server and present our authentication
token
Response:
The response is an HTTP OK which means that AD FS has authenticated the user based on the credentials
provided
Also, we set 3 cookies back to the client
MSISAuthenticated contains a base64-encoded timestamp value for when the client was authenticated.
MSISLoopDetectionCookie is used by the AD FS infinite loop detection mechanism to stop clients who
have ended up in an infinite redirection loop to the Federation Server. The cookie data is a timestamp
that is base64 encoded.
MSISSignout is used to keep track of the IdP and all RPs visited for the SSO session. This cookie is
utilized when a WS -Federation sign-out is invoked. You can see the contents of this cookie using a
base64 decoder.
Step 9 and 10
Request:
HTTP POST
Response:
The response is a Found
Step 11 and 12
Request:
HTTP GET
Response:
The response is OK
Next Steps
AD FS Troubleshooting - Fiddler
Fiddler is a tool that can be used to capture HTTP/HTTPS web traffic. This tool can be used to assist in
troubleshooting the claim issuance process. By looking at the traffic we can get a better understanding of where
the interaction is breaking down. This document will describe how to install and setup Fiddler to capture AD FS
traffic. For an example fiddler trace using WS -Federation see AD FS Troubleshooting - Fiddler - WS -Federation
Download and install Fiddler

You can download Fiddler here. Once you have downloaded it go ahead and install it.
Configure Fiddler to capture AD FS traffic

In order to capture AD FS traffic, we need to configure Fiddler to decrypt SSL traffic.
Configure the Fiddler SSL certificate
Use the following procedure to setup Fiddler to decrypt SSL traffic.
1. Open Fiddler
2. At the top, under Tools, select Fiddler Options.
3. Click on the HTTPS tab.
4. Place a check in Decrypt HTTPS traffic and select from browsers only from the drop-down.
5. Place a check in Ignore server certificate errors.
6. Click OK.
Next Steps
AD FS Troubleshooting - Idp-Initiated Sign On
The AD FS sign-on page can be used to test whether or not authentication is working. This is done by navigating
to the page and signing in. Also, we can use the sign-in page to verify that all SAML 2.0 relying parties are listed.
Enable the Idp-Intiated Sign on page

By default, AD FS in Windows 2016 does not have the sign on page enabled. In order to enable it you can use the
PowerShell command Set-AdfsProperties. Use the following procedure to enable the page:
1. Open Windows PowerShell
2. Enter: Get-AdfsProperties and hit enter
3. Verify that EnableIdpInitiatedSignonPage is set to false
4. In PowerShell, enter: Set-AdfsProperties -EnableIdpInitiatedSignonPage $true

5. You will not see a confirmation so enter Get-AdfsProperties again and verify that
EnableIdpInitatedSignonPage is set to true.
Test authentication
Use the following procedure to test AD FS authentication with the Idp-Initiated Sign on page.
1. Open a web browser and navigate to the Idp sign on page. Example:
https://sts.contoso.com/adfs/ls/idpinitiatedsignon.htm
2. You should be prompted to sign-in. Enter your credentials.
3. If this was successful you should be signed in.
Test authentication using a seamless logon experience

You can test the seamless logon experience by making sure that the URL for your AD FS servers are added the
local intranet zone of your internet options. Use the following procedure:
1. On a Windows 10 client, click start and type internet options and select internet options.
2. Click the security tab, click on local intranet, and click the sites button.
3. Click Advanced.
4. Enter your url and click Add. Click close.

5. Click Ok. Click Ok. This should close the internet options.
6. Open a web browser and navigate to the Idp sign on page. Example:
https://sts.contoso.com/adfs/ls/idpinitiatedsignon.htm
7. Click the sign in button. You should automatically sign in and not be prompted for credentials.
Next Steps
AD FS Troubleshooting - Integrated Windows
Authentication
Integrated Windows authentication enables users to log in with their Windows credentials and experience single-
sign on (SSO ), using Kerberos or NTLM.
Reason integrated windows authentication fails

There are three main reason why integrated windows authentication will fail. They are:
Service Principal Name(SPN ) misconfiguration
Channel Binding Token
Internet Explorer configuration
SPN misonfiguration
A service principal name (SPN ) is a unique identifier of a service instance. SPNs are used by Kerberos
authentication to associate a service instance with a service logon account. This allows a client application to
request that the service authenticate an account even if the client does not have the account name.
An example of an how an SPN is used with AD FS is as follows:
1. A web browser queries Active Directory to determine which service account is running sts.contoso.com
2. Active Directory tells the browser that it's the AD FS service account.
3. The browser will get a Kerberos ticket for the AD FS service account.
If the AD FS service account has a misconfigured or the wrong SPN then this can cause issues. Looking at network
traces, you may see errors such as KRB Error: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.
Using network traces (such as Wireshark) you can determine what SPN the browser is trying to resolve and then
using the command line tool, setspn - Q , you can do a lookup on that SPN. It may not be found or it may be
assigned to another account other than the AD FS service account.
You can verify the SPN by looking at the properties of the AD FS service account.
Channel Binding Token

Currently, when a client application authenticates itself to the server using Kerberos, Digest, or NTLM using
HTTPS, a Transport Level Security (TLS ) channel is first established and authentication takes place using this
channel.
The Channel Binding Token is a property of the TLS -secured outer channel, and is used to bind the outer channel
to a conversation over the client-authenticated inner channel.
If there is a "man-in-the-middle" attack occurring and they are de-crypting and re-encrypting the SSL traffic, then
the key will not match. AD FS will determine that there is something sitting in the middle between the web browse
r and itself. This will cause the Kerberos authentication to fail and the user will be prompted with a 401 dialog
instead of an SSO experience.
This can be cause by:
anything sitting in between the browser and AD FS
Fiddler
Reverse proxies performing SSL bridging
By default, AD FS has this set to "allow". You can change this setting using the PowerShell cmdlt
Set-ADFSProperties -ExtendProtectionTokenCheck
For more information on this see Best Practices for Secure Planning and Deployment of AD FS.
Internet Explorer configuration

By default, Internet explorer will be have the following way:
1. Internet explorer will receive a 401 response from AD FS with the word NEGOTIATE in the header.
2. This tells the web browser to get a Kerberos or NTLM ticket to send back to AD FS.
3. By default IE will try to do this (SPNEGO ) without user interaction if the word NEGOTIATE is in the header. It
will only work for intranet sites.
There are 2 main things that can prevent this from happeing.
Enable Integrated Windows Authentication is not checked in the properties of IE. This located under
Internet Options -> Advanced -> Security.
Security zones are not configured properly
FQDNs are not in the intranet zone
AD FS URL is not in the intranet zone.
Next Steps
AD FS Troubleshooting - Events and Logging
AD FS provides two primary logs that can be used in troubleshooting. They are:
the Admin Log
the Trace Log
Each of these logs will be explained below.
Admin Log
The Admin log provides high level information on issues that are occurring and is enabled by default.
To view the admin log
1. Open Event Viewer
2. Expand Applications and Services Log.
3. Expand AD FS.
4. Click on Admin.
Trace Log
The Trace log is where detailed messages are logged, and will be the most useful log when troubleshooting. Since
a lot of trace log information can be generated in a short amount of time, which can impact system performance,
the trace logs are disabled by default.
To enable and view the trace log
1. Open Event Viewer
2. Right-click on Applications and Services Log and select view and click on Show Analytic and Debug Logs.
This will show additional nodes on the left.
3. Expand AD FS Tracing
4. Right-click on Debug and select Enable Log.
Event auditing information for AD FS on Windows Server 2016

By default, AD FS in Windows Server 2016 has a basic level of auditing enabled. With basic auditing,
administrators will see 5 or less events for a single request. This marks a significant decrease in the number of
events administrators have to look at, in order to see a single request. The auditing level can be raised or lowered
using the PowerShell cmdlt:
Set-AdfsProperties -AuditLevel
The table below explains the available auditing levels.
AUDIT LEVEL POWERSHELL SYNTAX DESCRIPTION
None Set-AdfsProperties - AuditLevel None Auditing is disabled and no events will

be logged.
Basic (Default) Set-AdfsProperties - AuditLevel Basic No more than 5 events will be logged
for a single request
AUDIT LEVEL POWERSHELL SYNTAX DESCRIPTION
Verbose Set-AdfsProperties - AuditLevel All events will be logged. This will log a
Verbose significant amount of information per
request.
To view the current auditing level, you can use the PowerShell cmdlt: Get-AdfsProperties.
The auditing level can be raised or lowered using the PowerShell cmdlt: Set-AdfsProperties -AuditLevel.
Types of Events
AD FS events can be of different types, based on the different types of requests processed by AD FS. Each type of
event has specific data associated with it. The type of events can be differentiated between login requests (i.e. token
requests) versus system requests (server-server calls including fetching configuration information).
The table below describes the basic types of events.
EVENT TYPE EVENT ID DESCRIPTION
Fresh Credential Validation Success 1202 A request where fresh credentials are
validated successfully by the Federation
Service. This includes WS-Trust, WS-
Federation, SAML-P (first leg to
generate SSO) and OAuth Authorize
Endpoints.
Fresh Credential Validation Error 1203 A request where fresh credential

validation failed on the Federation
Service. This includes WS-Trust, WS-Fed,
SAML-P (first leg to generate SSO) and
OAuth Authorize Endpoints.
EVENT TYPE EVENT ID DESCRIPTION
Application Token Success 1200 A request where a security token is

issued successfully by the Federation
Service. For WS-Federation, SAML-P
this is logged when the request is
processed with the SSO artifact. (such
as the SSO cookie).
Application Token Failure 1201 A request where security token issuance

failed on the Federation Service. For
WS-Federation, SAML-P this is logged
when the request was processed with
the SSO artifact. (such as the SSO
cookie).
Password Change Request Success 1204 A transaction where the password

change request was successfully
processed by the Federation Service.
Password Change Request Error 1205 A transaction where the password

change request failed to be processed
by the Federation Service.
Sign Out Success 1206 Describes a successful sign-out request.
Sign Out Failure 1207 Describes a failed sign-out request.
Security Auditing
Securtity auditing of the AD FS service account can sometimes assist in tracking down issues with password
updates, request/response logging, request contect headers and device registration results. Auditing of the AD FS
service account is disabled by default.
To enable security auditing
1. Click Start, point to Programs, point to Administrative Tools, and then click Local Security Policy.
2. Navigate to the Security Settings\Local Policies\User Rights Management folder, and then double-click
Generate security audits.
3. On the Local Security Setting tab, verify that the AD FS service account is listed. If it is not present, click Add
User or Group and add it to the list, and then click OK.
4. Open a command prompt with elevated privileges and run the following command to enable auditing
auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable
5. Close Local Security Policy, and then open the AD FS Management snap-in.
To open the AD FS Management snap-in, click Start, point to Programs, point to Administrative Tools, and then
click AD FS Management.
1. In the Actions pane, click Edit Federation Service Properties
2. In the Federation Service Properties dialog box, click the Events tab.
3. Select the Success audits and Failure audits check boxes.
4. Click OK.
NOTE
The above instructions are used only when AD FS is on a stand-alone member server. If AD FS is running on a domain
controller, instead of the Local Security Policy, use the Default Domain Controller Policy located in Group Policy
Management/Forest/Domains/Domain Controllers. Click edit and navigate to Computer
Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Management
Windows Communication Foundation and Windows Identity

Foundation messages
In addition to trace logging, sometimes you may need to view Windows Communication Foundation (WCF ) and
Windows Identity Foundation (WIF ) messages in order to troubleshoot an issue. This can be done by modifying
the Microsoft.IdentityServer.ServiceHost.Exe.Config file on the AD FS server.
This file is located in <%system root%>\Windows\ADFS and is in XML format. The relevant portions of the file
are shown below:

<source name="Microsoft.IdentityModel" switchValue="Off"> … </source>

<source name="System.ServiceModel" switchValue="Off" > … </source>
After you apply these changes, save the configuration, and restart the AD FS service. After you enable these traces
by setting the appropriate switches, they will appear in the AD FS trace log in the Windows Event Viewer.
Correlating Events
One of the hardest things to troubleshoot is access issues that generate a lot of error or debug events.
To help with this, AD FS correlates all events that are recorded to the Event Viewer, in both the admin and the
debug logs, which correspond to a particular request by using a unique Globally Unique Identifier (GUID ) called
the Activity ID. This ID is generated when the token issuance request is initially presented to the web application
(for applications using the passive requestor profile) or requests sent directly to the claims provider (for
applications using WS -Trust).
This activity ID remains the same for the entire duration of the request, and is logged as part of every event
recorded in the Event Viewer for that request. This means:
that filtering or searching the Event Viewer using this activity ID can help keep track of all related events that
correspond to the token request
the same activity ID is logged across different machines which allows you to troubleshooting a user request
across multiple machines such as the Federation Server proxy (FSP )
the activity ID will also appear in the user’s browser if the AD FS request fails in any way, thus allowing the user
to communicate this ID to help desk or IT Support.
To aid in the troubleshooting process, AD FS also logs the caller ID event whenever the token-issuance process
fails on an AD FS server. This event contains the claim type and value of one of the following claim types,
assuming that this information was passed to the Federation Service as part of a token request:
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountnameh
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upnh
http://schemas.microsoft.com/ws/2008/06/identity/claims/upn
http://schemas.xmlsoap.org/claims/UPN
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddressh
http://schemas.microsoft.com/ws/2008/06/identity/claims/emailaddress
http://schemas.xmlsoap.org/claims/EmailAddress
http://schemas.microsoft.com/ws/2008/06/identity/claims/name
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier
The caller ID event also logs the activity ID to allow you to use that activity ID to filter or search the event logs for a
particular request.
Next Steps
AD FS Troubleshooting - Loop Detection
Looping in AD FS occurs when a relying party continuously rejects a valid security token and redirects back to AD
FS.
Loop detection cookie

To prevent this from happening, AD FS has implemented what is called a loop detection cookie. By default, AD FS
writes a cookie to web passive clients named MSISLoopDetectionCookie. This cookie holds a timestamp value
and a number of tokens issued value. This allows AD FS to keep track of how often and how many times a client
has visited the Federation Service within a specific timespan.
If a passive client visits the Federation Service for a token five (5) times within 20 seconds, AD FS throws the
following error:
MSIS7042: The same client browser session has made '{0}' requests in the last '{1}' seconds. Contact
your administrator for details.
Entering into infinite loops is often caused by a misbehaving relying party application that is not successfully
consuming the token issued by AD FS, and the application is sending the passive client back to AD FS, repeatedly,
for a new token. AD FS is will issue the passive client a new token each time, as long as they do not exceed 5
requests within 20 seconds.
Adjusting the loop detection cookie

You can use PowerShell to change the number of tokens issued value and the timespan value.
Set-AdfsProperties -LoopDetectionMaximumTokensIssuedInterval 5 -LoopDetectionTimeIntervalInSeconds 20
The minimum value for LoopDetectionMaximumTokensIssuedInterval is 1.

The minimum value for LoopDetectionTimeIntervalInSeconds is 5.
You can also disable loop detection when you are doing performance testing.
Set-AdfsProperties -EnableLoopDetection $false
IMPORTANT
It is not recommend to permanently disable loop detection as this prevents users from entering into infinite loop states.
Next Steps
AD FS Troubleshooting - SQL Connectivity
AD FS provides the ability to use remote SQL Server's for the AD FS farm data. You will see issues if the AD FS
servers in your farm cannot communicate with the backend SQL servers. The following document will provide
some basic steps to testing the communication with the backend servers.
Acquire the SQL database connection string

The first thing to test when checking SQL connectivity is, if AD FS has the correct SQL connection information.
This can be done using PowerShell.
To acquire the SQL connection string
1. Open Windows PowerShell
2. Enter the following: $adfs = gwmi -Namespace root/ADFS -Class SecurityTokenService and hit Enter
3. Enter the following: $adfs.ConfigurationDatabaseConnectionString and hit enter.
4. You should see the connect string information.
Create a Universal Data Link (UDL) file to test connectivity

A Universal Data Link file or UDL file is basically a text file that contains the a database connection string. By using
the information we obtained above we can test whether or not the SQL server is responding to connections.
To create a udl file to test connectivity
1. Open Notepad and save the file as test.udl. Make sure that you have All Files selected from the drop-down for
Save as type.
2. Double-click on test.udl
3. Fill in the following information: a. Select or enter a server name: Use the Data Source from the connection
string above b. Enter information to log on to the server: Use the AD FS service account or an account that
has permissions to logon remotely. If the account is a windows account use integrated authentication otherwise
enter the username and password. c. Select the database on the server: Use the Initial Catalog from the
string above. Example: AdfsConfigurationV3.
4. Click Test Connection.
Use SQL Server Management Studio to test connectivity

You can also download and install SSMS to test database connectivity.
To test connectivity with SSMS
1. Download and install SQL Server Management Studio.
2. Open SSMS, enter the Server Name. The data source from above.
3. Use the AD FS service account or an account that has permissions to logon remotely. If the account is a
windows account use integrated authentication otherwise enter the username and password.
4. You should see the left side populated. Expand databases and verify that you see the AD FS databases.
Next Steps
AD FS and certificate KeySpec property information

Device Registration Technical Reference
AD FS Password Attack Protection
TIP
You can find additional AD FS 2.0 design content at the AD FS 2.0 Content Map page on the Microsoft TechNet Wiki. This
page is managed by members of the AD FS 2.0 Community and is monitored on a regular basis by the AD FS Product Team.
See Also
NOTE
This article provides steps for how to delete personal data from the device and can be used to support your obligations under
the GDPR. If you’re looking for general info about GDPR, see the GDPR section of the Service Trust Center.
NOTE
If you’re interested in viewing or deleting personal data, please see the Azure Data Subject Requests for the GDPR article. If
you’re looking for general info about GDPR, see the GDPR section of the Service Trust Center.
Next steps
Review the Microsoft Privacy policy on Trust Center
AD FS and certificate KeySpec property Information
Key Specification (“KeySpec”) is a property associated with a certificate and key. It specifies whether a private key
associated with a certificate can be used for signing, encryption, or both.
An incorrect KeySpec value can cause AD FS and Web Application Proxy errors such as:
Failure to establish a SSL/TLS connection to AD FS or the Web Application Proxy, with no AD FS events logged
(though SChannel 36888 and 36874 events may be logged)
Failure to login at the AD FS or WAP forms based authentication page, with no error message shown on the
page.
You may see the following in the event log:
Log Name: AD FS Tracing/Debug

Source: AD FS Tracing
Date: 2/12/2015 9:03:08 AM
Event ID: 67
Task Category: None
Level: Error
Keywords: ADFSProtocol
User: S-1-5-21-3723329422-3858836549-556620232-1580884
Computer: ADFS1.contoso.com
Description:
Ignore corrupted SSO cookie.
What causes the problem

The KeySpec property identifies how a key generated or retrieved by Microsoft CryptoAPI (CAPI), from a Microsoft
legacy Cryptographic Storage Provider (CSP ), can be used.
A KeySpec value of 1, or AT_KEYEXCHANGE, can be used for signing and encryption. A value of 2, or
AT_SIGNATURE, is only used for signing.
The most common KeySpec mis-configuration is using a value of 2 for a certificate other than the token signing
certificate.
For certificates whose keys were generated using Cryptography Next Generation (CNG ) providers, there is no
concept of key specification, and the KeySpec value will always be zero.
See how to check for a valid KeySpec value below.
Example
An example of a legacy CSP is the Microsoft Enhanced Cryptographic Provider.
Microsoft RSA CSP key blob format includes an algorithm identifier, either CALG_RSA_KEYX or
CALG_RSA_SIGN, respectively, to service requests for either AT_KEYEXCHANGE **or **AT_SIGNATURE keys.
The RSA key algorithm identifiers map to KeySpec values as follows
PROVIDER SUPPORTED ALGORITHM KEY SPECIFICATION VALUE FOR CAPI CALLS
CALG_RSA_KEYX : RSA key that can be used for signing and AT_KEYEXCHANGE (or KeySpec=1)
decryption
CALG_RSA_SIGN : RSA signature only key AT_SIGNATURE (or KeySpec=2)
KeySpec values and associated meanings

The following are the meanings of the various KeySpec values:
KEYSPEC VALUE MEANS RECOMMENDED AD FS USE
0 The certificate is a CNG cert SSL certificate only
1 For a legacy CAPI (non-CNG) cert, the SSL, token signing, token decrypting,
key can be used for signing and service communication certificates
decryption
2 For a legacy CAPI (non-CNG) cert, the not recommended

key can be used only for signing
How to check the KeySpec value for your certificates / keys

To see a certificates value you can use the certutil command line tool.
The following is an example: certutil –v –store my. This will dump the certificate information to the screen.
Under CERT_KEY_PROV_INFO_PROP_ID look for two things:

1. ProviderType: this denotes whether the certificate uses a legacy Cryptographic Storage Provider (CSP ) or a
Key Storage Provider based on newer Certificate Next Generation (CNG ) APIs. Any non-zero value indicates a
legacy provider.
2. KeySpec: The following are valid KeySpec values for an AD FS certificate:
Legacy CSP provider (ProviderType not equal to 0):
AD FS CERTIFICATE PURPOSE VALID KEYSPEC VALUES
Service Communication 1
Token Decrypting 1
Token Signing 1 and 2
SSL 1
CNG provider (ProviderType = 0):

AD FS CERTIFICATE PURPOSE VALID KEYSPEC VALUES
SSL 0
How to change the keyspec for your certificate to a supported value

Changing the KeySpec value does not require the certificate to be re-generated or re-issued by the Certificate
Authority. The KeySpec can be changed by re-importing the complete certificate and private key from a PFX file
into the certificate store using the steps below:
1. First, check and record the private key permissions on the existing certificate so that they can be re-configured if
necessary after the re-import.
2. Export the certificate including private key to a PFX file.
3. Perform the following steps for each AD FS and WAP server
a. Delete the certificate (from the AD FS / WAP server)
b. Open an elevated PowerShell command prompt and import the PFX file on each AD FS and WAP server
using the cmdlet syntax below, specifying the AT_KEYEXCHANGE value (which works for all AD FS
certificate purposes):
a. C:>certutil –importpfx certfile.pfx AT_KEYEXCHANGE
b. Enter PFX password
c. Once the above completes, do the following
a. check the private key permissions
b. restart the adfs or wap service
2016
Currently, in AD FS for Windows Server 2012 R2 there are numerous audit events generated for a single request
and the relevant information about a log-in or token issuance activity is either absent (in some versions of AD FS )
or spread across multiple audit events. By default the AD FS audit events are turned off due to their verbose
nature.
With the release of AD FS in Windows Server 2016, auditing has become more streamlined and less verbose.
Auditing levels in AD FS for Windows Server 2016

By default, AD FS in Windows Server 2016 has basic auditing enabled. With basic auditing, administrators will see
5 or less events for a single request. This marks a significant decrease in the number of events administrators have
to look at, in order to see a single request. The auditing level can be raised or lowered using the PowerShell cmdlt:
Set-AdfsProperties -AuditLevel. The table below explains the available auditing levels.
Audit Level PowerShell syntax Description
None Set-AdfsProperties - AuditLevel None Auditing is disabled and no events will

be logged.
Basic (Default) Set-AdfsProperties - AuditLevel Basic No more than 5 events will be logged
for a single request
Verbose Set-AdfsProperties - AuditLevel All events will be logged. This will log a
Verbose significant amount of information per
request.
To view the current auditing level, you can use the PowerShell cmdlt: Get-AdfsProperties.
The auditing level can be raised or lowered using the PowerShell cmdlt: Set-AdfsProperties -AuditLevel.
Types of Audit Events
AD FS Audit Events can be of different types, based on the different types of requests processed by AD FS. Each
type of Audit Event has specific data associated with it. The type of audit events can be differentiated between
login requests (i.e. token requests) versus system requests (server-server calls including fetching configuration
information).
The table below describes the basic types of audit events.
Audit Event Type Event ID Description
Fresh Credential Validation Success 1202 A request where fresh credentials are
validated successfully by the Federation
Service. This includes WS-Trust, WS-
Federation, SAML-P (first leg to
generate SSO) and OAuth Authorize
Endpoints.
Fresh Credential Validation Error 1203 A request where fresh credential

validation failed on the Federation
Service. This includes WS-Trust, WS-Fed,
SAML-P (first leg to generate SSO) and
OAuth Authorize Endpoints.
Application Token Success 1200 A request where a security token is

issued successfully by the Federation
Service. For WS-Federation, SAML-P
this is logged when the request is
processed with the SSO artifact. (such
as the SSO cookie).
Application Token Failure 1201 A request where security token issuance

failed on the Federation Service. For
WS-Federation, SAML-P this is logged
when the request was processed with
the SSO artifact. (such as the SSO
cookie).
Password Change Request Success 1204 A transaction where the password

change request was successfully
processed by the Federation Service.
Password Change Request Error 1205 A transaction where the password

change request failed to be processed
by the Federation Service.
Sign Out Success 1206 Describes a successful sign-out request.
Sign Out Failure 1207 Describes a failed sign-out request.


It is recommended that you learn about the important concepts for Active Directory Federation Services and
become familiar with its feature set.
TIP
You can find additional AD FS resource links at the AD FS Content Map page on the Microsoft TechNet Wiki. This page is
managed by members of the AD FS Community and is monitored on a regular basis by the AD FS Product Team.
AD FS terminology used in this guide

AD FS TERM DEFINITION
Account partner organization A federation partner organization that is represented by a

claims provider trust in the Federation Service. The account
partner organization contains the users that will access Web-
based applications in the resource partner.
Account federation server The federation server in the account partner organization. The
account federation server issues security tokens to users
based on user authentication. The server authenticates the
user, extracts the relevant attributes and group membership
information out of the attribute store, packages this
information into claims, and generates and signs a security
token (which contains the claims) to return to the user—either
to be used in its own organization or to be sent to a partner
organization.
AD FS configuration database A database used to store all configuration data that represents
a single AD FS instance or Federation Service. This
configuration data can be stored in either a SQL Server
database or using the Windows Internal Database feature
included with Windows Server 2016, Windows Server 2012
and 2012 R2, and Windows Server 2008 and 2008 R2.
You can create the AD FS configuration database for SQL
Server using the Fsconfig.exe command-line tool and for
Windows Internal Database using the AD FS Federation Server
Claims provider The organization that provides claims to its users. See account
Claims provider trust In the AD FS Management snap-in, claims provider trusts are
trust objects typically created in resource partner
organizations to represent the organization in the trust
relationship whose accounts will be accessing resources in the
resource partner organization. A claims provider trust object
consists of a variety of identifiers, names, and rules that
identify this partner to the local Federation Service.
Local Claims Provider Trust A trust object that represents AD LDS or third-party LDAP-
based directories in an AD FS farm. A local claims provider
trust object consists of a variety of identifiers, names, and rules
that identify this LDAP-based directory to the local Federation
Service.
Federation metadata The data format for communicating configuration information

between a claims provider and a relying party to facilitate
proper configuration of claims provider trusts and relying
party trusts. The data format is defined in Security Assertion
Markup Language (SAML) 2.0, and it is extended in WS-
Federation.
Federation server A Windows Server that has been configured using the AD FS
Federation Server Configuration Wizard to act in the
federation server role. A federation server issues tokens and
serves as part of a Federation Service.
Federation server proxy A Windows Server that has been configured using the AD FS
Federation Server Proxy Configuration Wizard to act as an
intermediary proxy service between an Internet client and a
Federation Service that is located behind a firewall on a
corporate network.
Primary federation server A Windows Server that has been configured in the federation
server role using the AD FS Federation Server Configuration
Wizard and has a read/write copy of the AD FS configuration
database.
The primary federation server is created when you use the AD
FS Federation Server Configuration Wizard and select the
option to create a new Federation Service and make that
computer the first federation server in the farm. All other
federation servers in this farm must replicate changes made
on the primary federation server to a read-only copy of the
AD FS configuration database that is stored locally. The term
“primary federation server” does not apply when the AD FS
configuration database is stored in an SQL database as all
federation servers can equally read and write to a
configuration database stored on a SQL Server.
Relying party The organization that receives and processes claims. See
resource partner organization.
Relying party trust In the AD FS Management snap-in, relying party trusts are
trust objects typically created in:
- Account partner organizations to represent the organization

in the trust relationship whose accounts will be accessing
resources in the resource partner organization.
- Resource partner organizations to represent the trust
between the Federation Service and a single web-based
application.
A relying party trust object consists of a variety of identifiers,

names, and rules that identify this partner or web-application
to the local Federation Service.
Resource federation server The federation server in the resource partner organization. The
resource federation server typically issues security tokens to
users based on a security token that is issued by an account
federation server. The server receives the security token,
verifies the signature, applies claim rule logic to the
unpackaged claims to produce the desired outgoing claims,
generates a new security token (with the outgoing claims)
based on information in the incoming security token, and
signs the new token to return to the user and ultimately to
the Web application.
Resource partner organization A federation partner that is represented by a relying party

trust in the Federation Service. The resource partner issues
claims-based security tokens that contains published Web-
based applications that users in the account partner can
access.
Overview of AD FS
AD FS is an identity access solution that provides client computers (internal or external to your network) with
seamless SSO access to protected Internet-facing applications or services, even when the user accounts and
applications are located in completely different networks or organizations.
When an application or service is in one network and a user account is in another network, typically the user is
prompted for secondary credentials when he or she attempts to access the application or service. These secondary
credentials represent the user's identity in the realm where the application or service resides. They are usually
required by the Web server that hosts the application or service so that it can make the most appropriate
authorization decision.
With AD FS, organizations can bypass requests for secondary credentials by providing trust relationships
(federation trusts) that these organizations can use to project a user's digital identity and access rights to trusted
partners. In this federated environment, each organization continues to manage its own identities, but each
organization can also securely project and accept identities from other organizations.
The Role of Claims
Determine the Type of Claim Rule Template to Use

Active Directory Federation Services uses the term “attribute stores” to refer to directories or databases that an
organization uses to store its user accounts and their associated attribute values. After it is configured in an identity
provider organization, AD FS retrieves these attribute values from the store and creates claims based on that
information so that a Web application or service that is hosted in a relying party organization can make the
appropriate authorization decisions whenever a federated user (a user whose account is stored in the identity
provider organization) attempts to access the application or service.
For more information about how claims are generated, see The Role of Claims.
How attribute stores fit in with your AD FS deployment goals

The location of the user attribute store and the location from which users authenticate determine how you design
AD FS to support the user identities. Depending on where the attribute store is located and where users will access
the application (in an intranet or on the Internet), you can use one of the following deployment goals:
Provide Your Active Directory Users Access to Your Claims-Aware Applications and Services—In this goal,
users in your organization access an AD FS –secured application or service (either your own application or
service or a partner’s application or service) when the users are logged on to Active Directory in the
corporate intranet.
Provide Your Active Directory Users Access to the Applications and Services of Other Organizations—In this
goal, users in your organization access an AD FS –secured application or service (either your own application
or service or a partner’s application or service) when the users are logged on to an attribute store in the
corporate intranet and when they log on remotely from the Internet.
Provide Users in Another Organization Access to Your Claims-Aware Applications and Services—In this
goal, user accounts in another organization that are located in an attribute store on that organization’s
corporate intranet must access an AD FS –secured application in your organization. This goal also works
when consumer-based user accounts that are located in an attribute store in your organization’s perimeter
network must be provided with access to an AD FS –secured application in your organization.
Depending on attribute store placement and other requirements of your organization, you can combine several of
these deployment goals to complete the design of your AD FS deployment.
Attribute stores that are supported by AD FS

AD FS supports a wide range of directory and database stores that you can use for extracting administrator-
defined attribute values and populating claims with those values. AD FS supports any of the following directories
or databases as attribute stores:
Active Directory in Windows Server 2003, Active Directory Domain Services (AD DS ) in Windows Server
2008, AD DS in Windows Server 2012 and 2012 R2, and Windows Server 2016.
All editions of Microsoft SQL Server 2005, SQL Server 2008, SQL Server 2012, SQL Server 2014, and SQL
Server 2016
Custom attribute stores

The AD FS configuration database stores all the configuration data that represents a single instance of Active
Directory Federation Services (AD FS ) (that is, the Federation Service). The AD FS configuration database defines
the set of parameters that a Federation Service requires to identify partners, certificates, attribute stores, claims,
and various data about these associated entities. You can store this configuration data in either a Microsoft SQL
Server® database or the Windows Internal Database (WID ) feature that is included with Windows Server® 2008,
Windows Server 2008 R2 and Windows Server® 2012.
NOTE
The entire contents of the AD FS configuration database can be stored either in an instance of WID or in an instance of the
SQL database, but not both. This means that you cannot have some federation servers using WID and others using a SQL
Server database for the same instance of the AD FS configuration database.
You can use the following information in this topic along with the content provided in AD FS Deployment Topology
Considerations to learn about the advantages and disadvantages of choosing either WID or SQL Server to store
the AD FS configuration database:
WID uses a relational data store and does not have its own management user interface (UI). Instead, administrators
can modify the contents of the AD FS configuration database by using either the AD FS Management snap-in,
Fsconfig.exe, or Windows PowerShell™ cmdlets.
Using WID to store the AD FS configuration database

You can create the AD FS configuration database using WID as the store by using either the Fsconfig.exe
command-line tool or the AD FS Federation Server Configuration Wizard. When you use either of these tools, you
can choose any of the following options to create your federation server topology. Each of these options uses WID
for storing the AD FS configuration database:
Create a stand-alone federation server
Create the first federation server in a federation server farm
Add a federation server to a federation server farm
If you select the stand-alone option, WID is used to store a single instance of the AD FS configuration database.
This instance cannot be shared across multiple federation servers. It is meant for test lab environments only. For
more information about the stand-alone federation server option or how to set one up, see Stand-Alone Federation
Server Using WID or Create a Stand-Alone Federation Server.
If you select the first federation server in a federation server farm option, WID is configured for scalability that will
permit additional federation servers to be added to the farm at a later time. For more information about deploying
a WID farm or how to set one up, see Federation Server Farm Using WID or Create the First Federation Server in a
If you select the add a federation server option, WID is configured to replicate configuration database changes to
the new federation server at set intervals. For more information about adding a federation server to a WID farm,
see Federation Server Farm Using WID or Add a Federation Server to a Federation Server Farm.
NOTE
When you deploy a federation server farm using WID, some features of AD FS may not be available. To have access to the full
feature set when you configure your server farm, consider using Microsoft SQL Server to store the AD FS configuration
database instead. For more information, see AD FS Deployment Topology Considerations.
How a WID federation server farm works

This section describes important concepts that describe how the WID federation server farm replicates data
between a primary federation server and secondary federation servers. .
Primary federation server
A primary federation server is a computer running Windows Server 2008, Windows Server 2008 R2 or Windows
Server® 2012 that has been configured in the federation server role with the AD FS Federation Server
Configuration Wizard and that has a read/write copy of the AD FS configuration database. The primary federation
server is always created when you use the AD FS Federation Server Configuration Wizard and select the option to
create a new Federation Service and make that computer the first federation server in the farm. All other federation
servers in this farm, also known as secondary federation servers, must synchronize changes that are made on the
primary federation server to a copy of the AD FS configuration database that is stored locally.
Secondary federation servers
Secondary federation servers store a copy of the AD FS configuration database from the primary federation server,
but these copies are read-only. Secondary federation servers connect to and synchronize the data with the primary
federation server in the farm by polling it at regular intervals to check whether data has changed. The secondary
federation servers exist to provide fault tolerance for the primary federation server while acting to load-balance
access requests that are made in different sites throughout your network environment.
NOTE
If a primary federation server crashes and is offline, all secondary federation servers continue to process requests as normal.
However, no new changes can be made to the Federation Service until the primary federation server has been brought back
online. You can also nominate a secondary federation server to become the primary federation server by using Windows
PowerShell. For more information, see the AD FS Administration with Windows PowerShell.
How the AD FS configuration database is synchronized

Because of the important role that the AD FS configuration database plays, it is made available on all the federation
servers in the network to provide fault tolerance and load-balancing capabilities when processing requests (when
network load-balancers are used). However, for secondary federation servers to serve in this capacity, the AD FS
configuration database that is stored on the primary federation server must be synchronized.
When you add a federation server to the farm, the new computer that will become a secondary federation server
connects to the primary federation server to replicate the copy of the AD FS configuration database. From this
point forward, the new federation server continues to pull updates from the primary federation server on a regular
basis, as shown in the following illustration.
Each secondary federation server polls the primary federation server every five minutes for changes. You can
adjust this default five-minute value or force an immediate synchronization anytime by using a Windows
PowerShell cmdlet. For more information about how to do this, see AD FS Administration with Windows
PowerShell.
The WID synchronization process also supports incremental transfers for more efficient transfers of intermediate
changes. The incremental transfer process requires substantially less traffic on a network, and transfers are
completed much faster.
NOTE
The migration of an AD FS configuration database from WID to an instance of SQL Server is supported. For more information
about how to do this, see AD FS: Migrate Your AD FS Configuration Database to SQL Server on the TechNet Wiki site.
Using SQL Server to store the AD FS configuration database

You can create the AD FS configuration database using a single SQL Server database instance as the store by using
the Fsconfig.exe command-line tool. Using a SQL Server database as the AD FS configuration database provides
the following benefits over WID:
Administrators can leverage the high availability features of SQL Server
It provides additional performance increases for high traffic.
It provides feature support of SAML artifact resolution and SAML/WS -Federation token replay detection
(described below ).
The term “primary federation server” does not apply when the AD FS configuration database is stored in a SQL
database instance because all federation servers can equally read and write to the AD FS configuration database
that is using the same clustered SQL Server instance, as shown in the following illustration.
You can use SQL Server to configure two or more servers to work together as a server cluster to ensure that AD
FS is made highly available to service incoming client requests. High availability provides a scale-out architecture in
which you can increase server capacity by adding additional servers. Single points of failure are mitigated by
automatic cluster failover.
You can achieve high availability by using the network load-balancing and failover services that SQL clustering
technologies provide. For more information about how to configure SQL Server for high availability, see High
Availability Solutions Overview.
SAML artifact resolution
Security Assertion Markup Language (SAML ) artifact resolution is an endpoint based on the part of the SAML 2.0
protocol that describes how a relying party can retrieve a token directly from a claims provider. In the first stage of
the resolution process, a browser client contacts a resource federation server and provides it with an artifact. In the
second stage, resource federation servers send the artifact to a SAML artifact endpoint URL that is hosted
somewhere in an account partner organization in order to resolve the artifact message. In the final stage, the
account federation server issues the token to the federation server on behalf of the browser client.
NOTE
If you are an administrator in an account partner organization, make sure to assign or bind an SSL certificate, which chains to
a root certificate of a member of the Windows Root Certificate Program, to the federation passive Web site in IIS
(\Sites\Default Web Site\adfs\ls) on all the account federation servers in the farm. This is important to prevent resource
federation servers from having to manually add the SSL certificate to the Local Computers Trusted People certificate store or
from being unable to resolve the artifact that is published in your organization.
SAML/WS - Federation token replay detection

The term token replay refers to the act by which a browser client in an account partner organization attempts to
send the same token it received from an account federation server multiple times to authenticate to a resource
federation server. This act occurs when a user clicks the Back button of their browser in an effort to resubmit the
authentication page.
AD FS provides a feature referred to as token replay detection by which multiple token requests using the same
token can be detected and then discarded. When this feature is enabled, token replay detection protects the
integrity of authentication requests in both the WS -Federation passive profile and the SAML WebSSO profile by
making sure that the same token is never used more than once. This feature should be enabled in situations where
security is a very high concern such as when using kiosks.
In the kiosk example, a user can log off of all Web sites and later a malicious user can attempt to use the browser
history in order to resubmit the federated authentication page that was loaded by the previous user. This feature
mitigates this concern by storing additional information about each successful authentication made by an account
partner organization in order to detect subsequent replays of the token and prevent multiple authentication
attempts from succeeding.
The Role of Claims

In the claims-based identity model, claims play a pivotal role in the federation process, They are the key component
by which the outcome of all Web-based authentication and authorization requests are determined. This model
enables organizations to securely project digital identity and entitlement rights, or claims, across security and
enterprise boundaries in a standardized way.
What are claims?

In its simplest form, claims are simply statements (for example, name, identity, group), made about users, that are
used primarily for authorizing access to claims-based applications located anywhere on the Internet. Each
statement corresponds to a value that is stored in the claim.
How claims are sourced
The Federation Service in Active Directory Federation Services (AD FS ) defines which claims are exchanged
between federated partners. However, before it can do this it must first populate or source the claim with either a
retrieved value or a calculated value. Each claim value represents a value of a user, group, or entity and is sourced in
one of two ways:
1. When the value that makes up the claim is retrieved from an attribute store, for example, when an attribute
value of Sales Department is retrieved from the properties of an Active Directory user account. For more
information, see The Role of Attribute Stores.
2. When the value of an incoming claim is transformed into another value based on the logic expressed in a
rule. For example, when an incoming claim with the value of Domain Admins is transformed into a new
value of Administrators before it is sent as an outgoing claim. For more information, see The Role of Claim
Rules.
Claims can include values such as an e-mail address, User Principal Name (UPN ), group membership, and other
account attributes.
How claims flow
Other parties rely on the values of the claims to perform authorization tasks for Web-based applications that they
host. These parties are referred to as relying parties in the AD FS Management snap-in. The Federation Service is
responsible for brokering trust between many disparate parties. It is designed to process and flow the trusted
exchange of claims from an organization that initially sources the claims, also referred to as claims providers in the
AD FS Management snap-in, to a relying party. A relying party then uses these claims to make authorization
decisions.
The flow of claims using this process is known as the claims pipeline. There are three steps in the flow of claims
through the claims pipeline:
1. The claims that are received from the claims provider are processed by the acceptance transform rules on
the claims provider trust. These rules determine which claims are accepted from the claims provider.
2. The output of the acceptance transform rules is used as input to the issuance authorization rules. These rules
determine whether the user is permitted to access the relying party.
3. The output of the acceptance transform rules is used as input to the issuance transform rules. These rules
determine the claims that will be sent to the relying party.
For more information, see The Role of the Claims Pipeline
How claims are issued
When you write claim rules, the source of the incoming claims for the claim rules varies based on whether you are
writing rules on a claims provider trust or a relying party trust. When you write claim rules for a claims provider
trust, the incoming claims are the claims sent from the trusted claims provider to the Federation Service. When you
write rules for a relying party trust, the incoming claims are the claims that are output by the claim rules of the
applicable claims provider trust. For more information about incoming claims and outgoing claims, see The Role of
the Claims Pipeline and The Role of the Claims Engine.
What are claim types?

A claim type provides context for the claim value. It is usually expressed as a Uniform Resource Identifier (URI). AD
FS can support any claim type, and it is configured with the claim types in the following table by default.
NAME DESCRIPTION URI
E-Mail Address The e-mail address of the user http://schemas.xmlsoap.org/ws/2005/05

/identity/claims/emailaddress
Given Name The given name of the user http://schemas.xmlsoap.org/ws/2005/05

/identity/claims/givenname
Name The unique name of the user http://schemas.xmlsoap.org/ws/2005/05

/identity/claims/name
UPN The user principal name (UPN) of the http://schemas.xmlsoap.org/ws/2005/05

user /identity/claims/upn
Common Name The common name of the user http://schemas.xmlsoap.org/claims/Com

monName
AD FS 1.x E-Mail Address The e-mail address of the user when http://schemas.xmlsoap.org/claims/Email
interoperating with AD FS 1.1 or ADFS Address
1.0
Group A group that the user is a member of http://schemas.xmlsoap.org/claims/Grou

p
AD FS 1.x UPN The UPN of the user when http://schemas.xmlsoap.org/claims/UPN

interoperating with AD FS 1.1 or ADFS
1.0
Role A role that the user has http://schemas.microsoft.com/ws/2008/

06/identity/claims/role
Surname The surname of the user http://schemas.xmlsoap.org/ws/2005/05

/identity/claims/surname
PPID The private identifier of the user http://schemas.xmlsoap.org/ws/2005/05

/identity/claims/privatepersonalidentifier
NAME DESCRIPTION URI
Name Identifier The SAML name identifier of the user http://schemas.xmlsoap.org/ws/2005/05

/identity/claims/nameidentifier
Authentication Method The method used to authenticate the http://schemas.microsoft.com/ws/2008/

user 06/identity/claims/authenticationmetho
d
Deny Only Group SID The deny-only group SID of the user http://schemas.xmlsoap.org/ws/2005/05
/identity/claims/denyonlysid
Deny only primary SID The deny-only primary SID of the user http://schemas.microsoft.com/ws/2008/
06/identity/claims/denyonlyprimarysid
Deny only primary group SID The deny-only primary group SID of the http://schemas.microsoft.com/ws/2008/
user 06/identity/claims/denyonlyprimarygrou
psid
Group SID The group SID of the user http://schemas.microsoft.com/ws/2008/

06/identity/claims/groupsid
Primary group SID The primary group SID of the user http://schemas.microsoft.com/ws/2008/
06/identity/claims/primarygroupsid
Primary SID The primary SID of the user http://schemas.microsoft.com/ws/2008/

06/identity/claims/primarysid
Windows account name The domain account name of the user in http://schemas.microsoft.com/ws/2008/
the form of <domain>\<user> 06/identity/claims/windowsaccountnam
e
What are claim descriptions?

Claim descriptions represent a list of claims types that AD FS supports and that may be published in federation
metadata. The claim types mentioned in the previous table are configured as claims descriptions in the AD FS
Management snap-in.
The collection of claim descriptions that will be published to federation metadata is stored in the AD FS
configuration database. These claim descriptions are used by various components of the Federation Service.
Each claim description includes a claim type URI, name, publishing state, and description. You can manage the
claim description collection by using the Claim Descriptions node in the AD FS Management snap-in. You can
modify the publishing state of a claim description using the snap-in. The following settings are available:
Publish this claim in federation metadata as a claim type that this Federation Service can accept
(Publish as Accepted)—Indicates the claim types that will be accepted from other claims providers by this
Federation Service.
Publish this claim in federation metadata as a claim type that this Federation Service can send
(Publish as Sent)—Indicates the claim types that are offered by this Federation Service. These are the claim
types the Federation Service publishes to others as those it is willing to send. The actual claim types sent by
the claims provider are often a subset of this list.
For more information about how to set the publishing state of a claim type, see Add a Claim Description in the AD
FS Deployment Guide.
When generating Federation Metadata
Federation Metadata includes all the claim descriptions that are marked for publishing.
When claims rules are processed
When you keep configuration information about claims descriptions, it is easier for you to configure rules about
claims. For more information about the claim rules that can be used in the claims provider organization, see The
Role of Claim Rules.

The overall function of the Federation Service in Active Directory Federation Services (AD FS ) is to issue a token
that contains a set of claims. The decision regarding what claims AD FS accepts and then issues is governed by
claim rules.
What are claim rules?

A claim rule represents an instance of business logic that will take one or more incoming claims, apply conditions to
them (if x then y) and produce one or more outgoing claims based on the condition parameters. For more
information about incoming and outgoing claims, see The Role of Claims.
You use claim rules when you need to implement business logic that will control the flow of claims through the
claims pipeline. While the claims pipeline is more a logical concept of the end-to-end process for flowing claims,
claim rules are an actual administrative element that you can use to customize the flow of claims through the claims
issuance process.
For more information about the claims pipeline, see The Role of the Claims Engine.
Claim rules provide the following benefits:
Provide a mechanism for administrators to apply run-time business logic for trusting claims from claims
providers
Provide a mechanism for administrators to define what claims are released to relying parties
Provide rich and detailed claims-based authorization capabilities to administrators who want to permit or
deny access to specific users
How claim rules are processed
Claim rules are processed through the claims pipeline using the claims engine. The claims engine is a logical
component of the Federation Service that examines the set of incoming claims presented by a user, and will then,
depending on the logic in each rule, produce an output set of claims.
Together, the claims rule engine and the set of claim rules associated with a given federated trust determine
whether incoming claims should be passed through as they are, filtered to meet a specific condition’s criteria or
transformed into an entirely new set of claims before they are issued as outgoing claims by your Federation
Service.
For more information about this process, see The Role of the Claims Engine.
What are claim rule templates?

AD FS includes a predefined set of claim rule templates that are designed to help you easily select and create the
most appropriate claim rules for your particular business need. Claim rule templates are only used during the claim
rule creation process.
In the AD FS Management snap-in, rules can only be created using claim rule templates. After you use the snap-in
to select a claim rule template, input the necessary data for the rule logic and save it to the configuration database,
it will be (from that point forward) referred to in the UI as a claim rule.
How claim rule templates work
At first glance, claim rule templates appear to be just input forms provided by the snap-in to collect data and
process specific logic on incoming claims. However, at a much more detailed level, claim rule templates store the
necessary claim rule language framework that make up the base logic necessary for you to quickly create a rule
without needing to know the language intimately.
Each template that is provided in the user interface (UI) represents a prepopulated claim rule language syntax,
based on the most commonly required administrative tasks. There is one rule template however, that is the
exception. This template is referred to as the custom rule template. With this template, no syntax is prepopulated.
Instead you must directly author the claim rule language syntax in the body of the claim rule template form using
the claim rule language syntax.
For more information about how to use the claim rule language syntax, see The Role of the Claim Rule Language in
the AD FS Deployment Guide.
TIP
You can view the claim rule language associated with a rule at any time by clicking the View Rule Language button on the
properties of a claim rule.
How to create a claim rule

Claim rules are created separately for each federated trust relationship within the Federation Service and are not
shared across multiple trusts. You can either create a rule from a claim rule template, start from scratch by
authoring the rule using the claim rule language or use Windows PowerShell to customize a rule.
All of these options coexist to provide you with the flexibility of choosing the appropriate method for a given
scenario. For more information about how to create a claim rule, see Configuring Claim Rules in the AD
FSDeployment Guide.
Using claim rule templates
Claim rule templates are only used during the claim rule creation process. You can use any of the following
templates to create a claim rule:
Pass Through or Filter an Incoming Claim
Transform an Incoming Claim
Send LDAP Attributes as Claims
Send Group Membership as a Claim
Send Claims Using a Custom Rule
Permit or Deny Users Based on an Incoming Claim
Permit All Users
For more information describing each of these claim rule templates, see Determine the Type of Claim Rule
Template to Use.
Using the claim rule language
For business rules that are beyond the scope of standard claim rule templates, you can use a custom rule template
to express a series of complex logic conditions using the claim rule language. For more information about using a
custom rule, see When to Use a Custom Claim Rule.
Using Windows PowerShell
You can also use the ADFSClaimRuleSet cmdlet object with Windows PowerShell to create or administer rules in
AD FS. For more information about how you can use Windows PowerShell with this cmdlet, see AD FS
Administration with Windows PowerShell.
What is a claim rule set?

As shown in the following illustration, a claim rule set is a grouping of one or more rules for a given federated trust
that will define how claims will be processed by the claims rule engine. When an incoming claim is received by the
Federation Service the claim rule engine applies the logic specified by the appropriate claim rule set. It is the final
sum of the logic from each rule in the set that will determine how claims will be issued for a given trust in its
entirety.
Claim rules are processed by the claims engine in chronological order within a given rule set. This order is
important, because the output of one rule can be used as the input to the next rule in the set.
What are claim rule set types?

A claim rule set type is a logical segment of a federated trust that categorically identifies whether the claim rule set
associated with the trust will be used for claims issuance, authorization or acceptance. Each federated trust can have
one or more claim rule set types associated with it, depending on the type of trust that is used.
The following table describes the various types of claim rule sets and explains its relation with either a claims
provider trust or relying party trust.
CLAIM RULE SET TYPE DESCRIPTION USED ON

Acceptance transform rule set A set of claim rules that you use on a Claims provider trusts
particular claims provider trust to
specify the incoming claims that will be
accepted from the claims provider
organization and the outgoing claims
that will be sent to the relying party
trust.
The incoming claims that will be used to

source this rule set, will be the claims
that are output by the issuance
transform rule set as specified in the
claims provider organization.
By default, the claims provider trust

node contains a claim provider trust
named Active Directory which is used
to represent the source attribute store
for the acceptance transform rule set.
This trust object is used to represent the
connection from your Federation Service
to an Active Directory database on your
network. This default trust is what
processes claims for users that have
been authenticated by Active Directory
and it cannot be deleted.
Issuance Transform Rule Set A set of claim rules that you use on a Relying party trusts
relying party trust to specify the claims
that will be issued to the relying party.
The incoming claims that will be used to

source this rule set, will initially be the
claims that are output by the
acceptance transform rules.
Issuance Authorization Rule Set A set of claim rules that you use on a Relying party trusts
relying party trust to specify the users
that will be permitted to receive a token
for the relying party.
These rules determine whether a user

can receive claims for a relying party
and, therefore, access to the relying
party.
Unless you specify an issuance

authorization rule, all users will be
denied access by default.
Delegation Authorization Rule Set A set of claim rules that you use on a Relying party trusts
relying party trust to specify the users
that will be permitted to act as
delegates for other users to the relying
party.
These rules determine whether the

requester is permitted to impersonate a
user while still identifying the requester
in the token that is sent to the relying
party.
Unless you specify an issuance

authorization rule, no users can act as
delegates by default.
Impersonation Authorization Rule Set A set of claim rules that you configure Relying party trust
using Windows PowerShell to determine
whether a user can fully impersonate
another user to the relying party.
These rules determine whether the

requester is permitted to impersonate a
user without identifying the requester in
the token that is sent to the relying
party.
Impersonating another user in this way

is a very powerful capability, because
the relying party will not know that the
user is being impersonated.
For more information about select the appropriate claim rules to use in your organization, see Determine the Type
of Claim Rule Template to Use.

At its highest level, the claims engine in Active Directory Federation Services (AD FS ) is a rule-based engine that is
dedicated to serving and processing claim requests for the Federation Service. The claims engine is the sole entity
within the Federation Service that is responsible for running each of the rule sets across all of the federated trust
relationships you have configured and handing the output result over to the claims pipeline.
While the claims pipeline is more a logical concept of the end-to-end process for flowing claims, claim rules are an
actual administrative element that you can use to customize the flow of claims during the claim rules execution
process. For more information about the pipeline process, see The Role of the Claims Pipeline.
As shown in the following illustration, the act of accepting incoming claims (acceptance rules), authorizing claims
requesters (authorization rules) and issuing outgoing claims (issuance rules) through claim rules across all of the
federated trust relationships in your organization is performed by the claims engine.
Claim rules execution process

When you configure a claims provider trust or relying party trust in your organization with claim rules, the claim
rule set(s) for that trust act as a gatekeeper for incoming claims by invoking the claims engine to apply the
necessary logic in the claim rules to determine whether to issue any claims and which claims to issue.
The following section outlines each of the steps that occur by the engine during the flow of claims through the
claim rules execution process. Each of the steps as outlined below occurs for each stage described in the claims
pipeline process. These steps include:
Step 1 – Initialization
Step 2 – Execution
Step 3 – Execution result
For more information about the pipeline process, see The Role of the Claims Pipeline.
Step 1 – Initialization
In the first step of the claim rules execution process, the claims engine accepts incoming claims by first adding them
to the input claim set. An input claim set is analogous to a cache in memory that is used to temporarily store data
only as long as a required process requires that data to be made available for retrieval. The input claim set data is
discarded after the rule execution finishes.
Adding a claim to the input claim set for a rule set
The input claim set is created by the claims engine when it needs to temporarily store claim data in memory while it
processes the logic associated with a claim rule set. The claims engine copies all of the incoming claims to the input
claim set where they can be retrieved by the first rule in the rule set.
For example, in the illustration below, the claims engine reads the claims of A and B from the incoming claims and
copies them to the input claim set. After they are in the input claim set, the claims engine retrieves and processes
claims A and B as input for the logic in the first rule in the claim rule set.
All the rules in a claim rule set share the same input claim set. Each rule in that set can add to the shared input claim
set, thus affecting all subsequent rules in the set.
Step 2 – Execution
In this step of the claim rules process, claim rules are processed when the claims engine chronologically steps
through all of the rules within a particular rule set one at a time. Each rule within a rule set only runs once and is
executed in the order in which they appear from top to bottom as displayed in the Edit Claim Rules dialog box in
the AD FS Management snap-in. The claim rule that is at the top of the rule set is processed first and then
subsequent rules are processed until all of the rules have been run.
As defined in the claim rule language, a claim rule consists of two parts, condition and issuance statement. The
claims engine first processes the condition part by using the data in the input claim set to determine whether the
condition specified within the rule holds true for the claims contained in the input claim set (the claims that match
the rule’s condition are referred to as a matching claims). If any matching claims are found, the claims engine
executes the issuance statement of the rule for each set of the matching claims. The issuance statement of the rule
can perform either of the following tasks with matching claims:
1. Copy a matching claim into the output claim set
2. Transform the claim fields and create a new claim in either just the input claim set or in both evaluation and
output claim sets.
3. Use the matching claim(s) as a key to lookup more information from an attribute store to create new claim(s)
in either just the input claim set or in both input and output claim sets.
Adding a claim to the output claim set for a rule set
The output claim set is a location in memory that is initially empty and is important because the claims engine will
only return claims that reside in the output claim set after the execution process completes. This means that any
claims that reside only in the input claim set and not in the output claim set will be ignored when it comes time to
calculate the final set of outgoing claims.
Adding a claim to both claim sets for a rule set
As a rule is processed, claims are either added in the input claim set or in both the input claim set and output claim
set based on the statement that’s used in the rule’s issuance statement. The claim rule language refers to these
statements as either add or issue.
If the add statement is used, the claims are added to just the input claim set and the claims will exist only for the
purposes of the execution and will cease to exist once the execution completes. If the issue statement is used, the
claims are added to both the input claim set and the output claim set and the claims will be returned in the output
claim set once the execution completes. For more information about these statements, see The Role of the Claim
Rule Language.
If the condition part of a rule within a rule set does not match any claims in the input claim set, the issuance
statement part of the rule is ignored and thus no claims are added to either the output claim set or to the input
claim set. The following illustration and corresponding steps show what happens when the claims engine executes
a transform rule:
1. Incoming claims are added to the input claim set by the claims engine.
2. When the first rule executes, it sees the A and B claims, which are at that moment in time the only claims in
the input claim set, and processes the conditional part of the rule logic in rule 1.
3. Since the A claim is present in the input claim set, the condition of the rule is determined to be true
(matching the claim A) and a new C claim is added to both the input claim set and the output claim set.
4. Rule 2 can now use the A, B and C claims (all claims in the input claim set) as input for processing its logic.
For more information about claims transformation, see When to Use a Transform Claim Rule.
Step 3 – Execution Result
The final stage of the claim rule set execution begins once all rules have been run within a given rule set and the
final set of claims is present in the output claim set. At this point, the claims engine returns the context of the output
claim set as the output of the rule set execution. From this point forward it is the claims pipeline that takes over and
moves this final output to the next stage in its process.
Sending the execution output to the claims pipeline

When the claims engine processes a rule set, that rule set has its own dedicated locations in memory for its input
and output claim sets. This means that the input and output claim sets used by one rule set are separate from the
input and output claim sets used in another rule set.
After the entire process has run for a give rule set (steps 1, 2, and 3), the newly issued outgoing claims (content of
the output claim set) will be used as input to the next rule set in the claims pipeline. This allows for claims to flow
from the output of one rule set to the input for another rule set, as shown in the following illustration.
NOTE
Although the issuance rule set is also a critical stage in the pipeline, the illustration above does not show it only for purposes
of simplifying the illustration. For an illustration that shows the issuance rule set and how it fits into the claims pipeline, see
The Role of the Claims Pipeline.
In this case, the output of the acceptance rules is used by the pipeline to flow the final set of claims produced by the
acceptance rules to the second stage in the pipeline, which is the processing of authorization rules. At this point, the
entire claim rules execution process (steps 1, 2, and 3 above) would run again for the authorization rule set. This
cycle continues until the issuance rule set (the final stage in the pipeline) has been completed.
Once the finalized outgoing claims have been returned from the engine for the issuance rule set, they will be
packaged into a SAML token and the Federation Service will send the token back to the client.
Processing authorization rules

If the claim rule set that is being executed during step 2 of the claim rules execution process consists of
Authorization rules (which have a different input and output claim sets than either acceptance or issuance rules),
then those authorization rules will run to determine whether a token requester is authorized to obtain a security
token for a given relying party from the Federation Service based on the requester’s claims.
The goal of authorization rules is to issue a permit or deny claim based on whether the user is to be allowed to
obtain a token for the given relying party or not. As shown in the following illustration, the output of the
authorization execution is used by the pipeline to determine whether the issuance rule set is executed or not—
based on presence or absence of the permit and/or deny claim—but the authorization execution output itself is not
used as an input to the claim rule set.
For more information about claims authorization, see When to Use an Authorization Claim Rule.

The claims pipeline in Active Directory Federation Services (AD FS ) represents the path that claims must follow
through the Federation Service before they can be issued. The Federation Service manages the entire end-to-end
process of flowing claims through the various stages of the claims pipeline, which also includes the processing of
claim rules by the claim rule engine.
For more information about claim rules, see The Role of Claim Rules. For more information about how the claim
rule engine processes rules, see The Role of the Claims Engine.
The following section discusses the process that the Federation Service oversees in greater detail.
Claims pipeline process

The claims pipeline process consists of three high-level stages. Each stage in this process initializes the claim rule
engine to process claim rules that are specific to that stage. These stages include (in the order that they occur):
1. Accepting incoming claims—This stage in the claims pipeline is used to extract the incoming claims from the
token and eliminate claims that are not expected or trusted. After they are extracted, the acceptance rules
that make up the acceptance transform rule set for a claims provider trust are run. These rules can be used to
pass through or add new claims that can then be used in the subsequent stages of the claims pipeline. The
output of this stage is used as an input to second and third stage.
2. Authorizing the claims requester—This stage is used by the claims engine to issue permit or deny claims
based on whether the token requester is allowed to obtain a token for the given relying party or not.
However, before this can occur the authorization rules that make up either the issuance authorization rule
set or the delegation authorization rule set for a relying party trust are ran.
3. Issuing outgoing claims—This stage is used to issue outgoing claims and send them along the pipeline
where they will be packaged into a security token. However, before this can occur the issuance rules that
make up the issuance transform rule set for a relying party trust are ran, which will determine what claims
will be issued as outgoing claims.
All three stages above perform claims rules processing but use a different set of rules. As described above, each
stage has an associated set of rules based on either the issuer of the incoming claims (the acceptance rules) or the
target service for which the claimincludes are being issued (authorization and issuance rules).
Claims are token-agnostic but are transmitted over the network encapsulated in security tokens. The claim rules
operate over claims regardless of the format of the incoming or outgoing security token.
Claims rules contain the administrator-defined logic by which the claims engine will accept the incoming claims,
authorize claims based on the requester’s identity and issue claims that are needed by a relying party. Ultimately, it
is the claims engine that determines what claims will go into the security token that will be issued after the claim
has been flowed through the claims pipeline.
As shown in the following illustration, the claims pipeline is responsible for the entire end-to-end process of
flowing a claim through the various pipeline stages in order to end up with an issued claim that will be sent over a
relying party trust. The outgoing claim in the illustration represents the issued claim.
Although it is not shown in the illustration, it is the claims engine that performs the actual processing of the rules at
each stage. For more information, see The Role of the Claims Engine.

The Active Directory Federation Services (AD FS ) claim rule language acts as the administrative building block for the
behavior of incoming and outgoing claims, while the claims engine acts as the processing engine for the logic in the
claim rule language that defines the custom rule. For more information about how all rules are processed by the claims
engine, see The Role of the Claims Engine.
Creating custom claim rules using the claim rule language

AD FS provides administrators with the option to define custom rules that they can use to determine the behavior of
identity claims with the claim rule language. You can use the claim rule language syntax examples in this topic to create a
custom rule that enumerates, adds, deletes, and modifies claims to meet the needs of your organization. You can build
custom rules by typing in the claim rule language syntax in the Send Claims Using a Custom Claim rule template.
Rules are separated from each other with semicolons.
For more information about when to use custom rules, see When to Use a Custom Claim Rule.
Using claim rule templates to learn about the claim rule language syntax
AD FS also provides a set of predefined claim issuance and claim acceptance rule templates that you can use to
implement common claim rules. In the Edit Claim Rules dialog box for a given trust, you can create a predefined rule—
and view the claim rule language syntax that makes up that rule—by clicking the View Rule Language tab for that rule.
Using the information in this section and the View Rule Language technique can provide insight into how to construct
your own custom rules.
For more detailed information about claim rules and claim rule templates, see The Role of Claim Rules.
Understanding the components of the claim rule language

The claim rule language consists of the following components, separated by the “ =>” operator:
A condition
An issuance statement
Conditions
You can use conditions in a rule to check input claims and determine whether the issuance statement of the rule should
be executed. A condition represents a logical expression that must be evaluated to true to execute the rule body part. If
this part is missing, a logical true is assumed; that is, the rule’s body is always executed. The conditions part contains a
list of conditions that are combined together with the conjunction logical operator (“&&” ). All conditions in the list must
be evaluated to true for the whole conditional part to be evaluated to true. The condition can be either a claims selection
operator or an aggregate function call. These two are mutually exclusive, which means that claim selectors and
aggregate functions cannot be combined in a single rule conditions part.
Conditions are optional in rules. For example, the following rule does not have a condition:
=> issue(type = "http://test/role", value = "employee");

There are three types of conditions:
Single condition—This is the simplest form of a condition. Checks are made for only one expression; for example,
windows account name = domain user.
Multiple condition—This condition requires additional checks to process multiple expressions in the rule body;
for example, windows account name = domain user and group = contosopurchasers.
NOTE
Another condition exists, but it is a subset of either the single condition or the multiple condition. It is referred to as a regular
expression (Regex ) condition. It is used to take an input expression and match the expression with a given pattern. An example of
how it is can be used is shown below.
The following examples show a few of the syntax constructions, which are based on the condition types, that you can use
to create custom rules.
Single -condition examples
Single -expression conditions are described in the following table. They are constructed to simply check for a claim with
a specified claim type or for a claim with a specified claim type and claim value.
CONDITION DESCRIPTION CONDITION SYNTAX EXAMPLE
This rule has a condition to check for an input claim with a c: [type == "http://test/name"] => issue(claim = c );
specified claim type ("http://test/name" ). If a matching claim is in
the input claims, the rule copies the matching claim or claims to
the output claims set.
This rule has a condition to check for an input claim with a c: [type == "http://test/name", value == "Terry"] =>
specified claim type ("http://test/name" ) and claim value (“Terry” issue(claim = c);
). If a matching claim is in the input claims, the rule copies the
matching claim or claims to the output claims set.
More -complex conditions are shown in the next section, including conditions to check for multiple claims, conditions to
check the issuer of a claim, and conditions to check for values that match a regular expression pattern.
Multiple -condition examples
The following table provides an example of multiple -expression conditions.
This rule has a condition to check for two input claims, each with c1: [type == "http://test/name"] && c2: [type ==
a specified claim type ("http://test/name" and "http://test/email" ). "http://test/email"] => issue (claim = c1 );
If the two matching claims are in the input claims, the rule copies
the name claim to the output claims set.
Regular -condition examples

The following table provides an example of a regular, expression -based condition.
This rule has a condition that uses a regular expression to check c: [type == "http://test/email", value =~ "^.
for an e -mail claim ending in “@fabrikam.com”. If a matching +@fabrikam.com$" ] => issue (claim = c );
claim is found in the input claims, the rule copies the matching
claim to the output claims set.
Issuance statements
Custom rules are processed based on the issuance statements (issue or add ) that you program into the claim rule.
Depending on the desired outcome, either the issue statement or add statement can be written into the rule to populate
the input claim set or the output claim set. A custom rule that uses the add statement explicitly populates claim values
only to the input claim set while a custom claim rule that uses the issue statement populates claim values in both the
input claim set and in the output claim set. This can be useful when a claim value is intended to be used only by future
rules in the set of claim rules.
For example, in the following illustration, the incoming claim is added to the input claim set by the claims issuance
engine. When the first custom claim rule executes and the criteria of domain user is satisfied, the claims issuance engine
processes the logic in the rule using the add statement, and the value of Editor is added to the input claim set. Because
the value of Editor is present in the input claim set, Rule 2 can successfully process the issue statement in its logic and
generate a new value of Hello, which is added to both the output claim set and to the input claim set for use by the next
rule in the rule set. Rule 3 can now use all of the values that are present in the input claim set as input for processing its
logic.
Claim issuance actions

The rule body represents a claim issuance action. There are two claim issuance actions that the language recognizes:
Issue statement: The issue statement creates a claim that goes to both input and output claim sets. For example,
the following statement issues a new claim based on its input claim set:
c:[type == "Name"] => issue(type = "Greeting", value = "Hello " + c.value);
Add statement: The add statement creates a new claim that is added only to the input claim set collection. For
example, the following statement adds a new claim to the input claim set:
c:[type == "Name", value == "domain user"] => add(type = "Role", value = "Editor");
The issuance statement of a rule defines what claims will be issued by the rule when the conditions are matched. There
are two forms of issuance statements regarding arguments and the statement behavior:
Normal—Normal issuance statements can issue claims by using literal values in the rule or the values from
claims that match the conditions. A normal issuance statement can consist of one or both of the following
formats:
Claim copy: The claim copy creates a copy of the existing claim in the output claim set. This issuance form
only makes sense when it is combined with the “issue” issuance statement. When it is combined with the
“add” issuance statement, it does not have any effect.
New claim: This format creates a new claim, given the values for various claim properties. Claim.Type
must be specified; all other claim properties are optional. The order of arguments for this form is ignored.
Attribute Store—This form creates claims with values that are retrieved from an attribute store. It is possible to
create multiple claim types by using a single issuance statement, which is important for attribute stores that make
network or disk input/output (I/O ) operations during the attribute retrieval. Therefore, it is desirable to limit the
number of round trips between the policy engine and the attribute store. It is also legal to create multiple claims
for a given claim type. When the attribute store returns multiple values for a given claim type, the issuance
statement automatically creates a claim for each returned claim value. An attribute store implementation uses the
param arguments to substitute the placeholders in the query argument with values that are provided in param
arguments. The placeholders use the same syntax as the .NET String.Format ( ) function (for example, {1}, {2}, and
so on ). The order of the arguments for this form of issuance is important, and it must be the order which is
prescribed in the following grammar.
The following table describes some common syntax constructions for both types of issuance statements in claim rules.
ISSUANCE STATEMENT TYPE ISSUANCE STATEMENT DESCRIPTION ISSUANCE STATEMENT SYNTAX EXAMPLE
Normal The following rule always emits the same c: [type == "http://test/employee",
claim whenever a user has the specified value == "true"] => issue (type =
"http://test/role", value =
claim type and value: "employee");
Normal The following rule converts one claim type c: [type == "http://test/group" ]
into another. Notice that the value of the => issue (type =
"http://test/role", value = c.Value
claim that matches the condition "c" is );
used in the issuance statement.
Attribute store The following rule uses the value of an c: [Type == "http://test/name" ] =>
incoming claim to query the Active issue (store = "Enterprise AD
Attribute Store", types =
Directory attribute store: ("http://test/email" ), query =
";mail;{0}", param = c.Value )
Attribute store The following rule uses the value of an c: [type == "http://test/name"] => issue
incoming claim to query a previously (store = "Custom SQL store", types =
("http://test/email","http://test/displayname"
configured Structured Query Language ), query = "SELECT mail, displayname FROM
(SQL ) attribute store: users WHERE name ={0}", param = c.value );
Expressions
Expressions are used on the right side for both claims selector constraints and issuance statement parameters. There are
various kinds of expressions that the language supports. All expressions in the language are string based, which means
that they take strings as input and produce strings. Numbers or other data types, such as date/time, in expressions are
not supported. The following are the types of expressions that the language supports:
String literal: String value, delimited by the quote (“ ) character on both sides.
String concatenation of expressions: The result is a string that is produced by concatenation of the left and right
values.
Function call: The function is identified by an identifier, and the parameters are passed as a comma -delimited list
of expressions enclosed in brackets (“ ( )” ).
Claim’s property access in the form of a variable name DOT property name: The result of the value of the
identified claim’s property for a given variable valuation. The variable must first be bound to a claims selector
before it can be used in this way. It is illegal to use the variable that is bound to a claims selector inside the
constraints for that same claims selector.
The following claim properties are available for access:
Claim.Type
Claim.Value
Claim.Issuer
Claim.OriginalIssuer
Claim.ValueType
Claim.Properties[property_name] (This property returns an empty string if the property _name cannot be found
in the claim’s properties collection. )
You can use the RegexReplace function to call inside an expression. This function takes an input expression and matches
it with the given pattern. If the pattern matches, the output of the match is replaced with the replacement value.
Exists functions
The Exists function can be used in a condition to evaluate whether a claim that matches the condition exists in the input
claim set. If any matching claim exists, the issuance statement is called only once. In the following example, the “origin”
claim is issued exactly once—if there is at least one claim in the input claim set collection that has the issuer set to
“MSFT”, no matter how many claims have the issuer set to “MSFT”. Using this function prevents duplicate claims from
being issued.
exists([issuer == "MSFT"])
=> issue(type = "origin", value = "Microsoft");
Rule body
The rule body can contain only a single issuance statement. If conditions are used without using the Exists function, the
rule body is executed once for each time that the conditions part is matched.
Determine the Type of Claim Rule Template to Use
An important part of designing an Active Directory Federation Services (AD FS ) infrastructure is determining the
complete set of claim rules—and which corresponding claim rule templates you should use to create them—for
each partner that will participate in federation with your organization. You create rules by using claim rule
templates in the AD FS Management snap-in.
Each set of claim rules you configure can only be associated with one federated trust. This means that you cannot
create a set of rules on one trust and use them for other trusts in your Federation Service. Instead you can easily
create rules from claim rule templates to more quickly help produce a desired set of claims that are agreed upon
between each federated partner and your organization.
For more information about rules and rule templates, see The Role of Claim Rules.
Before you begin to determine the types of claim rule templates you should use, consider the following questions:
What claims will be provided by your trusted claims providers?
What claims do you trust from each claims provider?
What claims are required by the relying parties that trust this Federation Service?
What claims are you willing to divulge to each relying party?
Which users should have access to each relying party?
Answering these questions will help you plan a solid claim rule design. It will also assist you in creating a smooth
authorization and access control strategy and make your deployment team more efficient during the rollout.
In this next section you can learn about the type of rule templates to select for your environment based on your
business needs.
Claim rule template types

The following table describes all of the types of claim rule templates that you can use to create rules using the AD
FS Management snap-in, and the benefits of using one template type over another.
RULE TEMPLATE TYPE DESCRIPTION ADVANTAGES DISADVANTAGES
Pass Through or Filter an Used to create a rule that - Can be used to select - Claim type and value
Incoming Claim will pass through all claim particular claims to be cannot be changed
values for a selected claim accepted or issued
type or filter claims based on unchanged
the claim values so that only
certain claim values for a
selected claim type will pass
through.
For more information, see

When to Use a Pass Through
or Filter Claim Rule.
Transform an Incoming Used to create a rule that - Can be used to normalize - More complex string
Claim can select an incoming claim claim types or values replacements require a
and map it to a different - Can replace an e-mail suffix custom rule
claim type or map its claim of an incoming claim
value to a new claim value.

When to Use a Transform
Claim Rule.
Send LDAP Attributes as Used to create a rule that - Can source claims from any - Performance – slow as a
Claims will select attributes from an AD DS/AD LDS attribute result of account lookup
LDAP attribute store to send store - Cannot use a custom LDAP
as claims to the relying - Multiple claims can be filter for querying
party. issued using a single rule

When to Use a Send LDAP
Attributes as Claims Rule.
Send Group Membership as Used to create a rule that - Fast performance for - User must be a member of
a Claim can send a specified claim issuing group claims – no a local Active Directory
type and value when a user account lookup group
is a member of an Active
Directory security group.
Only a single claim will be
sent using this rule, based
on the group that you select.

Membership as a Claim Rule.
Send Claims Using a Custom Used to create a custom rule - Can be used to source - More difficult to configure
Rule that will provide more claims from an SQL attribute - Some ramp up time may
advanced options than a store be needed to initially gain
standard rule template. You - Can be used to specify a knowledge of the claim rule
write custom rules with the custom LDAP filter language
AD FS claim rule language. - Can be used to issue a
PPID
For more information, see - Can be used with a custom
When to Use a Custom attribute store
Claim Rule. - Can be used to add claims
only to the input claim set
- Can be used to send claims
based on more than one
incoming claim
Permit or Deny Users Based Used to create a rule that - Simplifies the authorization - Requires that only one
on an Incoming Claim will permit or deny access by process claim type and one claim
users to the relying party, value be specified
based on the type and value - Does not support pattern
of an incoming claim. matching for claim values

When to Use an
Authorization Claim Rule.
Permit All Users Used to create a rule that - Simple to configure - Less secure than using the
will permit all users to access Permit or Deny Users Based
the relying party. on an Incoming Claim
template
When to Use an
Authorization Claim Rule.

A Uniform Resource Identifier (URI) is a string of characters that is used as a unique identifier. In AD FS, URIs are
used to identify both partner network addresses and configuration objects. When used to identify partner network
addresses, the URI is always a URL. When used to identify configuration objects, the URI may be a URN or a URL.
For more general information about URIs, see RFC 2396 and RFC 3986.
URIs as partner network addresses

The following are the network address URLs that are most often handled by administrators in AD FS.
The URLs of the Federation Service, including WS -Federation, SAML, WS -Trust, Federation Metadata, WS -
MetadataExchange, Privacy and Organization URLs
The URLs of a relying party trust, including WS -Federation, SAML, and Federation Metadata URLs
The URLs of a claims provider trust, including WS -Federation, SAML, and Federation Metadata URLs
URIs as object identifiers

The following table describes the identifiers that are most often handled by administrators in AD FS.
IDENTIFIER NAME DESCRIPTION COMPARISONS
Federation Service identifier This identifier is used to identify the When a user requests claims from a
Federation Service. It is used by relying claims provider for this Federation
parties that use claims from this Service, the Federation Service identifier
Federation Service, as well as claims will be used to identify the target for the
providers that issue claims to this claims.
Federation Service.
When this Federation Service receives
the claims from a claims provider, it will
check to ensure the claims are scoped
for it by looking for its Federation
Service identifier.
When a relying party is receiving claims

from this Federation Service, the relying
party will check that the issuer of the
claims matches the Federation Service
identifier.
IDENTIFIER NAME DESCRIPTION COMPARISONS
Relying party identifier This identifier is used to identify the When a user requests claims from this
relying party to this Federation Service. Federation Service for the relying party,
It is used when issuing claims to the the relying party identifier will be used
relying party. to identify the relying party for which
the claims should be targeted. This
comparison is done using prefix
matching (see below).
When the relying party receives the

claims, it will check for its identifier in
the security token to ensure the claims
are targeted for it.
Claims provider identifier This identifier is used to identify the When this Federation Service is
claims provider to this Federation receiving claims from the claims
Service. It is used when receiving claims provider, this Federation Service will
from the claims provider. check that the issuer of the claims
matches the claims provider identifier.
Claim type This identifier is used to define the type When the Federation Service receives
of claim. It is used by this Federation claims from a claims provider, the claim
Service, claims providers, and relying rules associated with the corresponding
parties when sending and receiving claims provider trust allow the
claims. administrator to compare claim types
and process claims. The claim rules
associated with a relying party trust also
allow the administrator to compare
claim types from the claims coming out
of the claims provider trust rules, and
decide which claims to issue.
URI prefix matching for relying party identifiers

The path syntax of a URI is organized hierarchically and is delimited by either all “/” characters or all “:”characters.
Thus the path may be split into path sections based on the delimiting character. When prefix matching, each section
must be a full match according to the matching rules (these rules govern the casing of matches). For more
information about matching rules, see the RFC’s mentioned above.
When a relying party is identified in a request to the Federation Service, AD FS uses prefix matching logic to
determine if there is a matching relying party trust in the AD FS configuration database.
For example, if the relying party identifier in the AD FS configuration database (URI1) is a prefix to the relying
party identifier in the incoming request (URI2), then the following must be true:
Trailing delimiters (slashes and colons) of path sections or authorities must be ignored
The scheme and authority parts of URI1 and URI2 must be a case insensitive exact match
Each path section of URI1 must be an exact match (based on the case sensitivity chosen) to the
corresponding path section of URI2
URI2 may have more path sections than URI1, but URI1 must not have more path sections than URI2
URI1 cannot have more path sections than URI2
If URI1 has a query string, it must match exactly to a URI2 query string
If URI1 has a fragment, it must match exactly to a URI2 fragment
The following table provides additional examples.
RELYING PARTY IDENTIFIER IN REQUEST IDENTIFIER MATCHES

AD FS CONFIGURATION RELYING PARTY IDENTIFIER IN THE CONFIGURATION
DATABASE REQUEST MESSAGE IDENTIFIER? REASON
http://contoso.com http://contoso.com TRUE Exact match
http://contoso.com/ http://contoso.com TRUE Trailing slashes are ignored
http://contoso.com http://contoso.com/ TRUE Trailing slashes are ignored
http://contoso.com http://contoso.com/hr TRUE URI1 has no path and

matches scheme and
authority to URI2
http://contoso.com/hr http://contoso.com/hr/web TRUE First path sections match,

URI1 has no second path
section
http://contoso.com/hr http://contoso.com/hr/web/? TRUE Same reasons as above,

m=t query string doesn’t change
anything
http://contoso.com/hr/ http://contoso.com/hrw/mai FALSE URI1 path section 1 does

n not match URI2 path section
1
http://contoso.com/hr http://contoso.com FALSE URI1 has more path sections

than URI2
http://contoso.com/hr http://contoso.com/hrweb FALSE First path sections do not

match
http://contoso.com/?m=t http://contoso.com/?m=f FALSE Query string parts do not

match
https://contoso.com http://contoso.com FALSE Scheme parts do not match
http://sts.contoso.com http://contoso.com FALSE Authority parts do not

match
http://contoso.com http://sts.contoso.com FALSE Authority parts do not

match
Device Registration Technical Reference

The Device Registration Service (DRS ) is a new Windows service that is included with the Active Directory
Federation Service Role on Windows Server 2012 R2. The DRS must be installed and configured on all of the
federation servers in your AD FS farm. For information on deploying DRS, see Configure a federation server with
Device Registration Service.
Active Directory objects created when a device is registered

The following Active Directory objects are created as part of Device Registration Service.
Device Registration Configuration
The Device Registration Configuration is stored in the Configuration naming context of the Active Directory forest.
(For example, CN=Device Registration Configuration,CN=Services,<configuration-naming-context>).
This object is created when the Active Directory forest is initialed for Device Registration.
The Device Registration Configuration includes the following elements:
Issuer keys
The public and private keys used to issue the X.509 certificate that is associated with a registered device. The
private keys are DKM protected.
Device Registration Service Configuration
Policies relating to the Device Registration Service.
Registered devices container
The device object container is created under one of the domains in the Active Directory forest. This object container
will contain all of the device objects for the Active Directory forest.
By default, the container is created in the same domain as AD FS. (For example, CN=RegisteredDevices,DC=
<default-naming-context>).This object is created when the Active Directory forest is initialed for Device
Registration.
Registered devices
Device objects are new, light weight objects in Active Directory. They are used to represent the relationship
between: a user, a device, and the company. Device objects use a certificate signed by AD FS to anchor the physical
device to the logical device object in Active Directory.
Registered devices includes the following elements:
Display Name
Friendly name of the device. For windows devices, this is the host name of the computer.
Device Id
A GUID that is generated by the Device Registration server.
Certificate Thumbprint
The certificate thumbprint of the X.509 certificate that is used with the registered device.
OS Type
The operating system type on the device.
OS Version
The version of the operating system on the device.
Is Enabled
A Boolean that indicates if the device is enabled in Active Directory. Only enabled devices are allowed to
access to services.
Approximate Last Use Time
The approximate time the device was used to access a resource. To limit replication traffic, this is only
updated once every 14 days.
Registered Owner
The Security Identity (SID ) of the user that joined this device to the workplace.
AD FS/DRS Server SSL certificate revocation checking

The Workplace Join client checks the validity of the AD FS Server SSL certificate. If the AD FS Server SSL
certificate includes a Certificate Revocation List (CRL ) endpoint, the client must be able to reach the endpoint
specified to validate the certificate.
If you are using a test environment and a test certificate authority (CA) to issue your server SSL certificates then
you can choose to not include the CRL endpoint in the server certificates issued by your CA. Doing so will allow the
Workplace Join client to bypass the CRL check.
Cau t i on
This is never recommended for production systems

AD FS Password Attack protection
What is a password attack?

A requirement for federated single sign-on is the availability of endpoints to authenticate over the internet. The
availability of authentication endpoints on the internet enables users to access the applications even when they are
not on a corporate network.
However, this also means that some bad actors can take advantage of the federated endpoints available on the
internet and use these endpoints to try and determine passwords or to create denial of service attacks. One such
attack that is becoming more common is called a password attack.
There are 2 types of common password attacks. Password spray attack & brute force password attack.
Password Spray Attack
In a password spray attack, these bad actors will try the most common passwords across many different accounts
and services to gain access to any password protected assets they can find. Usually these span many different
organizations and identity providers. For example, an attacker will use a commonly available toolkit to enumerate
all of the users in several organizations and then try “P@$$w0rd” and “Password1” against all of those accounts.
To give you the idea, an attack might look like:
TARGET USER TARGET PASSWORD
User1@org1.com Password1
… …
User1@org1.com P@$$w0rd
This attack pattern evades most detection techniques because from the vantage point of an individual user or
company, the attack just looks like an isolated failed login.
For attackers, it’s a numbers game: they know that there are some passwords out there that are very common. The
attacker will get a few successes for every thousand accounts attacked, and that’s enough to be effective. They use
the accounts to get data from emails, harvest contact info, and send phishing links or just expand the password
spray target group. The attackers don’t care much about who those initial targets are—just that they have some
success that they can leverage.
They use the accounts to get data from emails, harvest contact info, and send phishing links or just expand the
password spray target group. The attackers don’t care much about who those initial targets are—just that they
have some success that they can leverage.
But by taking a few steps to configure the AD FS and network correctly, AD FS endpoints can be secured against
these type of attacks. This article covers 3 areas that need to be configured properly to help secure against these
attacks.
Brute Force Password Attack
In this form of attack, an attacker will attempt multiple password attempts against a targeted set of accounts. In
many cases these accounts will be targeted against users that have a higher level of access within the organization.
These could be executives within the organization or admins who manage critical infrastructure.
This type of attack could also result in DOS patterns. This could be at the service level where ADFS is unable to
process a large # of requests due to insufficient # of servers or could be at a user level where a user is locked out of
their account.
Securing AD FS against password attacks

But by taking a few steps to configure the AD FS and network correctly, AD FS endpoints can be secured against
these types of attacks. This article covers 3 areas that need to be configured properly to help secure against these
attacks.
Level 1, Baseline: These are the basic settings that must be configured on an AD FS server to ensure that bad
actors cannot brute force attack federated users.
Level 2, Protecting the extranet: These are the settings that must be configured to ensure the extranet access is
configured to use secure protocols, authentication policies and appropriate applications.
Level 3, Move to password-less for extranet access: These are advanced settings and guidelines to enable access
to federated resources with more secure credentials rather than passwords which are prone to attack.
Level 1: Baseline
1. If ADFS 2016, implement extranet smart lockout Extranet smart lockout tracks familiar locations and will
allow a valid user to come through if they have previously logged in successfully from that location. By
using extranet smart lockout, you can ensure that bad actors will not be able to brute force attack the users
and at the same time will let legitimate user be productive.
If you are not on AD FS 2016, we strongly recommend you upgrade to AD FS 2016. It is a simple
upgrade path from AD FS 2012 R2. If you are on AD FS 2012 R2, implement extranet lockout. One
disadvantage of this approach is that valid users may be blocked from extranet access if you are in a
brute force pattern. AD FS on Server 2016 does not have this disadvantage.
2. Monitor & Block suspicious IP addresses
If you have Azure AD Premium, implement Connect Health for ADFS and use the Risky IP report
notifications that it provides.
a. Licensing is not for all users and requires 25 licenses/ADFS/WAP server which may be easy for a
customer.
b. You can now investigate IP’s that are generating large # of failed logins
c. This will require you to enable auditing on your ADFS servers.
3. Block suspicious IP's. This potentially blocks DOS attacks.
a. If on 2016, use the Extranet Banned IP addresses feature to block any requests from IP’s flagged by #3
(or manual analysis).
b. If you are on AD FS 2012 R2 or lower, block the IP address directly at Exchange Online and optionally on
your firewall.
4. If you have Azure AD Premium, use Azure AD Password Protection to prevent guessable passwords from
getting into Azure AD
a. Note that if you have guessable passwords, you can crack them with just 1-3 attempts. This feature
prevents these from getting set.
b. From our preview stats, nearly 20-50% of new passwords get blocked from being set. This implies that %
of users are vulnerable to easily guessed passwords.
Level 2: Protect your extranet

1. Move to modern authentication for any clients accessing from the extranet. Mail clients are a big part of this.
a. You will need to use Outlook Mobile for mobile devices. The new iOS native mail app supports modern
authentication as well.
b. You will need to use Outlook 2013 (with the latest CU patches) or Outlook 2016.
2. Enable MFA for all extranet access. This gives you added protection for any extranet access.
a. If you have Azure AD premium, use Azure AD Conditional Access policies to control this. This is better
than implementing the rules at AD FS. This is because modern client apps are enforced on a more frequent
basis. This occurs, at Azure AD, when requesting a new access token (typically every hour) using a refresh
token.
b. If you don’t have Azure AD premium or have additional apps on AD FS that you allow internet based
access, implement MFA (Can be Azure MFA as well on AD FS 2016) and do a global MFA policy for all
extranet access.
Level 3: Move to password less for extranet access

1. Move to Window 10 and use Hello For Business.
2. For other devices, if on AD FS 2016, you can use Azure MFA OTP as the first factor and password as the
2nd factor.
3. For mobile devices, if you only allow MDM managed devices, you can use Certificates to log the user in.
Urgent Handling
If the AD FS environment is under active attack, the following steps should be implemented at the earliest:
Disable U/P endpoint in ADFS and require everyone to VPN to get access or be inside your network. This
requires you to have step Level 2 #1a completed. Otherwise, all internal Outlook requests will still be routed
via the cloud via EXO proxy auth.
If the attack is only coming via EXO, you can disable basic authentication for Exchange protocols (POP, IMAP,
SMTP, EWS, etc) using Authentication Policies, these protocols and authentication methods are being used on
the vast majority of these attacks. Additionally, Client Access Rules in EXO and per-mailbox protocol
enablement are evaluated post-authentication and won’t help on mitigating the attacks.
Selectively offer extranet access using Level 3 #1-3.
Next steps
Upgrade to AD FS server 2016
Extranet smart lockout in AD FS 2016
Configure conditional access policies
Azure AD password protection
AD FS Frequently Asked Questions (FAQ)
The following documentation is a home to frequently asked questions with regard to Active Directory Federation
Services. The document has been split into groups based on the type of question.
Deployment
How can I upgrade/migrate from previous versions of AD FS
You can upgrade AD FS using one of the following:
Windows Server 2012 R2 AD FS to Windows Server 2016 AD FS
Windows Server 2012 AD FS to Windows Server 2012 R2 AD FS
Migrate to AD FS on Windows Server 2012 R2
AD FS 2.0 to Windows Server 2012 AD FS
Migrate to AD FS on Windows Server 2012
AD FS 1.x to AD FS 2.0
Upgrade from AD FS 1.x to AD FS 2.0
If you need to upgrade from AD FS 2.0 or 2.1 (Windows Server 2008 R2 or Windows Server 2012), you must use
the in-box scripts (located in C:\Windows\ADFS ).
Why does AD FS installation require a reboot of the server?
HTTP/2 support was added in Windows Server 2016, but HTTP/2 can't be used for client certificate authentication.
Because many AD FS scenarios make use of client certificate authentication, and a significant number of clients do
not support retrying requests using HTTP/1.1, AD FS farm configuration re-configures the local server's HTTP
settings to HTTP/1.1. This requires a reboot of the server.
Is using Windows 2016 WAP Servers to publish the AD FS farm to the internet without upgrading the back-end
AD FS farm supported?
Yes, this configuration is supported, however no new AD FS 2016 features would be supported in this
configuration. This configuration is meant to be temporary during the migration phase from AD FS 2012 R2 to AD
FS 2016 and should not be deployed for long periods of time.
Is it possible to deploy AD FS for Office 365 without publishing a proxy to Office 365?
Yes, this is supported. However, as a side effect
1. You will need to manually manage updating token signing certificates because Azure AD will not be able to
access the federation metadata. For more information on manually updating token signing certificate read
Renew federation certificates for Office 365 and Azure Active Directory
2. You will not be able to leverage legacy auth flows (e.g. ExO proxy auth flow )
What are load balancing requirements for AD FS and WAP servers?
AD FS is a stateless system. Hence, load balancing is fairly simple for logins. The following are key
recommendations for load balancing systems.
Load balancers SHOULD not be configured with IP affinity. This may put undue load on a subset of your
servers in certain Exchange Online scenarios.
Load balancers MUST not terminate the HTTPS connections and reinitiate a new connection to the ADFS
server.
Load balancers SHOULD ensure that the connecting IP address should be translated as the source IP in the
HTTP packet when being sent to ADFS. In the event that a load balancer cannot send the source IP in the HTTP
packet, the load balancer MUST add (or append in case of existing) the IP address to the x-forwarded-for header.
This is required for the correct handling of certain IP related features (Banned IP, Extranet Smart Lockout,…) and
could lead to reduced security if improperly configured.
Load balancers SHOULD support SNI. In the event it does not, ensure that AD FS is configured to create
HTTPS bindings to handle non SNI capable clients.
Load balancers SHOULD use the AD FS HTTP health probe endpoint to detect if the AD FS or WAP servers are
up and running and exclude them if a 200 OK Is not returned.
What multi-forest configurations are supported by AD FS?
AD FS supports multiple multi-forest configuration and relies on the underlying AD DS trust network to
authenticate users across multiple trusted realms. We strongly recommend 2-way forests trusts as this is a simpler
setup to ensure that the trust subsystem works correctly without issues. Additionally,
In the event of a one way forest trust such as a DMZ forest containing partner identities, we recommend
deploying ADFS in the corp forest and treating the DMZ forest as another local claims provider trust connected
via LDAP. In the event you cannot pursue this option, you would need to run ADFS in the “trusting” forest using
a service account in the “trusted forest” that has full access to the users in the “trusting” forest.
While domain level trusts are supported and can work, we highly recommend you moving to a forest level trust
model. Additionally, you would need to ensure that UPN routing and NETBIOS name resolution of names need
to work accurately.
Design
What third party multi-factor authentication providers are available for AD FS?
Below is a list of third party providers we are aware of. There may always be providers available that we do not
know about and we will update the list as we learn about them.
Gemalto Identity & Security Services
inWebo Enterprise Authentication service
Login People MFA API connector
RSA SecurID Authentication Agent for Microsoft Active Directory Federation Services
SafeNet Authentication Service (SAS ) Agent for AD FS
Swisscom Mobile ID Authentication Service
Symantec Validation and ID Protection Service (VIP )
Are third party proxies supported with AD FS?
Yes, third party proxies can be placed in front of the Web Application Proxy, but any third party proxy must support
the MS -ADFSPIP protocol to be used in place of the Web Application Proxy.
What third party proxies are available for AD FS that support MS -ADFSPIP?
Below is a list of third party providers we are aware of. There may always be providers available that we do not
know about and we will update the list as we learn about them.
F5 Access Policy Manager
Where is the capacity planning sizing spreadsheet for AD FS 2016?
The AD FS 2016 version of the spreadsheet can be downloaded here. This can also be used for AD FS in Windows
Server 2012 R2.
How can I ensure my AD FS and WAP servers support Apple's ATP requirements?
Apple has released a set of requirements called App Transport Security (ATS ) that may impact calls from iOS apps
that authenticate to AD FS. You can ensure your AD FS and WAP servers comply by making sure they support the
requirements for connecting using ATS.
In particular, you should verify that your AD FS and WAP servers support TLS 1.2 and that the TLS connection's
negotiated cipher suite will support perfect forward secrecy.
You can enable and disable SSL 2.0 and 3.0 and TLS versions 1.0, 1.1, and 1.2 using Manage SSL Protocols in AD
FS.
To ensure your AD FS and WAP servers negotiate only TLS cipher suites that support ATP, you can disable all
cipher suites that are not in the list of ATP compliant cipher suites. To do this, use the Windows TLS PowerShell
cmdlets.
Developer
When generating an id_token with ADFS for a user authenticated against AD, how is the “sub” claim generated in
the id_token?
The value of “sub” claim is the hash of client ID + anchor claim value.
What is the lifetime of the refresh token/access token when the user logs in via a remote claims provider trust
over WS -Fed/SAML -P?
The lifetime of refresh token will be the lifetime of the token that ADFS got from remote claims provider trust. The
lifetime of the access token will be the token lifetime of the relying party for which access token is being issued.
I need to return profile and email scopes as well in addition to the OpenId scope. Can I obtain additional
information using scopes? How to do it in AD FS?
You can use customized id_token to add relevant information in the id_token itself. For more information, see the
article Customize claims to be emitted in id_token.
How to issue json blobs inside JWT tokens?
A special ValueType("http://www.w3.org/2001/XMLSchema#json" ) and escape character(\x22) for this was added
in AD FS 2016. Please the sample below for the issuance rule and also the final output from the access token.
Sample issuance rule:
=> issue(Type = "array_in_json", ValueType = "http://www.w3.org/2001/XMLSchema#json", Value = "{\x22Items\x22:

[{\x22Name\x22:\x22Apple\x22,\x22Price\x22:12.3},
{\x22Name\x22:\x22Grape\x22,\x22Price\x22:3.21}],\x22Date\x22:\x2221/11/2010\x22}");
Claim issued in Access token:
"array_in_json":{"Items":[{"Name":"Apple","Price":12.3},{"Name":"Grape","Price":3.21}],"Date":"21/11/2010"}
Can I pass resource value as part of the scope value like how requests are done against Azure AD?
With AD FS on Server 2019, you can now pass the resource value embedded in the scope parameter. The scope
parameter can now be organized as a space separated list where each entry is structure as resource/scope. For
example
Does AD FS support PKCE extension?
AD FS in Server 2019 supports Proof Key for Code Exchange (PKCE ) for OAuth Authorization Code Grant flow
Operations
How do I replace the SSL certificate for AD FS?
The AD FS SSL certificate is not the same as the AD FS Service communications certificate found in the AD FS
Management snap-in. To change the AD FS SSL certificate, you’ll need to use PowerShell. Follow the guidance in
the article below:
How can I enable or disable TLS/SSL settings for AD FS
To disable or enable SSL protocols and cipher suites, use the following:
Manage SSL Protocols in AD FS
Does the proxy SSL certificate have to be the same as the AD FS SSL certificate?
Use the following guidance with regard to the proxy SSL certificate and the AD FS SSL certificate:
If the proxy is used to proxy AD FS requests that use Windows Integrated Authentication, the proxy SSL
If the AD FS property "ExtendedProtectionTokenCheck" is enabled (the default setting in AD FS ), the proxy SSL
Otherwise, the proxy SSL certificate can have a different key from the AD FS SSL certificate, but must meet the
same requirements
How can I configure prompt=login behavior for AD FS?
For information on how to configure prompt=login, see Active Directory Federation Services prompt=login
parameter support.
How can I configure browsers to use Windows Integrated Authentication (WIA ) with AD FS?
For information on how to configure browsers see Configure browsers to use Windows Integrated Authentication
(WIA) with AD FS.
Can I trun off BrowserSsoEnabled?
If you don't have Access control policies based on device on ADFS or Windows Hello for Business Certificate
enrollment using ADFS; you can turn off BrowserSsoEnabled. BrowserSsoEnabled allows ADFS to collect a
PRT(Primary Refresh Token) from client which contains device information. Without that device authentication of
ADFS will not work on Windows 10 devices.
How long are AD FS tokens valid?
Often this question means ‘how long do users get single sign on (SSO ) without having to enter new credentials,
and how can I as an admin control that?’ This behavior, and the configuration settings that control it, are described
in the article AD FS Single Sign-On Settings.
The default lifetimes of the various cookies and tokens are listed below (as well as the parameters that govern the
lifetimes):
Registered Devices
PRT and SSO cookies: 90 days maximum, governed by PSSOLifeTimeMins. (Provided device is used at least
every 14 days, which is controlled by DeviceUsageWindow )
Refresh token: calculated based on the above to provide consistent behavior
access_token: 1 hour by default, based on the relying party
id_token: same as access token
Un-registered Devices
SSO cookies: 8 hours by default, governed by SSOLifetimeMins. When Keep Me Signed in (KMSI) is
enabled, default is 24 hours and configurable via KMSILifetimeMins.
Refresh token: 8 hours by default. 24 hours with KMSI enabled
access_token: 1 hour by default, based on the relying party
id_token: same as access token
Does AD FS support HTTP Strict Transport Security (HSTS )?
HTTP Strict Transport Security (HSTS ) is a web security policy mechanism which helps mitigate protocol
downgrade attacks and cookie hijacking for services that have both HTTP and HTTPS endpoints. It allows web
servers to declare that web browsers (or other complying user agents) should only interact with it using HTTPS
and never via the HTTP protocol.
All AD FS endpoints for web authentication traffic are opened exclusively over HTTPS. As a result, AD FS
effectively mitigates the threats that HTTP Strict Transport Security policy mechanism provides (by design there is
no downgrade to HTTP since there are no listeners in HTTP ). In addition, AD FS prevents the cookies from being
sent to another server with HTTP protocol endpoints by marking all cookies with the secure flag.
Therefore, implementing HSTS on an AD FS server is not required because it can never be downgraded. For
compliance purposes, AD FS servers meet these requirements because they can never use HTTP and all cookies
are marked secure.
X -ms-forwarded-client-ip does not contain the IP of the client but contains IP of the firewall in front of the
proxy. Where can I get the right IP of the client?
It is not recommended to do SSL termination before WAP. In case SSL termination is done in front of the WAP, the
X-ms-forwarded-client-ip will contain the IP of the network device in front of WAP. Below is a brief description of
the various IP related claims that are supported by AD FS:
x-ms-client-ip : Network IP of device which connected to the STS. In the case of an extranet request this always
contains the IP of the WAP.
x-ms-forwarded-client-ip : Multi-valued claim which will contain any values forwarded to ADFS by Exchange
Online plus the IP address of the device which connected to the WAP.
Userip: For extranet requests this claim will contain the value of x-ms-forwarded-client-ip. For intranet requests,
this claim will contain the same value as x-ms-client-ip.
I am trying to get additional claims on the user info endpoint, but its only returning subject. How can I get
additional claims?
The ADFS userinfo endpoint always returns the subject claim as specified in the OpenID standards. AD FS does
not provide additional claims requested via the UserInfo endpoint. If you need additional claims in ID token, refer
to Custom ID Tokens in AD FS.
Why do I see a lot of 1021 errors on my AD FS servers?
This event is logged usually for an invalid resource access on AD FS for resource 00000003-0000-0000-c000-
000000000000. This error is caused by an erroneous behavior of the client where it tries to get an access token for
the Azure AD Graph service. Since the resource is not present on AD FS, this results in event ID 1021 on the AD
FS servers. It’s safe to ignore any warnings or errors for resource 00000003-0000-0000-c000-000000000000 on
AD FS.
Why am I seeing a warning for failure to add the AD FS service account to the Enterprise Key Admins group?
This group is only created when a Windows 2016 Domain Controller with the FSMO PDC role exists in the
Domain. To resolve the error, you can create the Group manually and follow the below to give the required
permission after adding the service account as member of the group.
2. Right-click your domain name from the navigation pane and click Properties.
3. Click Security (if the Security tab is missing, turn on Advanced Features from the View menu).
4. Click Advanced. Click Add. Click Select a principal.
5. The Select User, Computer, Service Account, or Group dialog box appears. In the Enter the object name to select
text box, type Key Admin Group. Click OK.
6. In the Applies to list box, select Descendant User objects.
7. Using the scroll bar, scroll to the bottom of the page and click Clear all.
8. In the Properties section, select Read msDS -KeyCredentialLink and Write msDS -KeyCredentialLink.
Why does modern authentication from Android devices fail if the server does not send all the intermediate
certificates in the chain with the SSL cert?
Federated users may experience authentication to Azure AD for apps that use the Android ADAL library failing. The
app will get an AuthenticationException when it tries to show the login page. In chrome the AD FS login page
might be called out as unsafe.
Android - across all versions and all devices - does not support downloading additional certificates from the
authorityInformationAccess field of the certificate. This is true of the Chrome browser as well. Any Server
Authentication certificate that’s missing intermediate certificates will result in this error if the entire certificate chain
is not passed from AD FS.
A proper solution to this problem is to configure the AD FS and WAP servers to send the necessary intermediate
certificates along with the SSL certificate.
When exporting the SSL certificate, from one machine, to be imported to the computer’s personal store, of the AD
FS and WAP server(s), make sure to export the Private key and select Personal Information Exchange - PKCS
#12.
It is important that the check box to Include all certificates in the certificate path if possible is checked, as well
as Export all extended properties.
Run certlm.msc on the Windows servers and import the *.PFX into the Computer’s Personal Certificate store. This
will cause the server to pass the entire certificate chain to the ADAL library.
NOTE
The certificate store of Network Load Balancers should also be updated to include the entire certificate chain if present
Does AD FS support HEAD requests?

AD FS does not support HEAD requests. Applications should not be using HEAD requests against AD FS
endpoints. This may cause HTTP error responses that are unexpected and/or delayed. Additionally, you may see
unexpected error events in the AD FS event log.
Why am I not seeing a refresh token when I am logging in with a remote IdP?
A refresh token is not issued if the token issued by IdP has a validty of less than 1 hour. To ensure a refresh token is
issued, increase the validity of token issued by the IdP to more than 1 hour.
Do we have any way to change RP token encryption algorithm?
By default the RP token encryption is set to AES256 and it cannot be changed to any other value.
On a mixed-mode farm, I get error when trying to set the new SSL certificate using Set-AdfsSslCertificate -
Thumbprint. How can I update the SSL certificate in a mixed mode AD FS farm?
On WAP servers you can still use Set-WebApplicationProxySslCertificate. On the ADFS servers, you need to use
netsh. Follow the steps as given below:
1. Select subset of ADFS 2016 servers for maintenance (e.g. remove from load balancer)
2. On the servers selected in #1, import the new certificate via MMC
3. Delete the existing certificates
a. netsh http delete sslcert hostnameport=fs.contoso.com:443 b. netsh http delete sslcert
hostnameport=localhost:443 c. netsh http delete sslcert hostnameport=fs.contoso.com:49443
4. Add the new cert
a. netsh http add sslcert hostnameport=fs.contoso.com:443 certhash=CERTTHUMBPRINT appid=
{5d89a20c-beab-4389-9447-324788eb944a} certstorename=MY sslctlstorename=AdfsTrustedDevices
b. netsh http add sslcert hostnameport=localhost:443 certhash=CERTTHUMBPRINT appid={5d89a20c-
beab-4389-9447-324788eb944a} certstorename=MY sslctlstorename=AdfsTrustedDevices
c. netsh http add sslcert hostnameport=fs.contoso.com:49443 certhash=CERTTHUMBPRINT appid=
{5d89a20c-beab-4389-9447-324788eb944a} certstorename=MY sslctlstorename=AdfsTrustedDevices
5. Restart ADFS service on the selected server
6. Remove subset of WAP servers for maintenance
7. On the selected WAP servers, import the new certificate via MMC
8. Set the new cert on WAP using cmdlet
a. Set-WebApplicationProxySslCertificate -Thumbprint " CERTTHUMBPRINT"
9. Restart service on the selected WAP servers
10. Put the selected WAP and AD FS servers back in production environment.
Perform the update on the rest of AD FS and WAP servers in similar fashion.
Is ADFS supported when Web Application Proxy (WAP) servers are behind Azure Web Application
Firewall(WAF )?
ADFS and Web Application servers support any firewall that does not perform SSL termination on the endpoint.
Additionally, ADFS/WAP servers have built in mechanisms to prevent common web attacks such as cross-site
scripting, ADFS proxy and satisfy all requirements defined by the MS -ADFSPIP protocol.
Securing Privileged Access
Securing privileged access is a critical first step to establishing security assurances for business assets in a modern
organization. The security of most or all business assets in an organization depends on the integrity of the
privileged accounts that administer and manage IT systems. Cyber-attackers are targeting these accounts and
other elements of privileged access to rapidly gain access to targeted data and systems using credential theft
attacks like Pass-the-Hash and Pass-the-Ticket.
Protecting administrative access against determined adversaries requires you to take a complete and thoughtful
approach to isolate these systems from risks. This figure depicts the three stages of recommendations for
separating and protecting administration in this roadmap:
Roadmap Objectives:
2-4 week plan: quickly mitigate the most frequently used attack techniques
1-3 month plan: build visibility and control of admin activity
6+ month plan: continue building defenses to a more proactive security posture
Microsoft recommends you follow this roadmap to secure privileged access against determined adversaries. You
may adjust this roadmap to accommodate your existing capabilities and specific requirements in your
organizations.
NOTE
Securing privileged access requires a broad range of elements including technical components (host defenses, account
protections, identity management, etc.) as well as changes to process, and administrative practices and knowledge.
Why is Securing Privileged Access important?

In most organizations, the security of most or all business assets depends on the integrity of the privileged
accounts that administer and manage IT systems. Cyber-attackers are focusing on privileged access to systems like
Active Directory to rapidly gain access to all of an organizations targeted data.
Traditional security approaches have focused on using the ingress and egress points of an organizations network as
the primary security perimeter, but the effectiveness of network security has been significantly diminished by two
trends:
Organizations are hosting data and resources outside the traditional network boundary on mobile
enterprise PCs, devices like mobile phones and tablets, cloud services, and BYOD devices
Adversaries have demonstrated a consistent and ongoing ability to obtain access on workstations inside the
network boundary through phishing and other web and email attacks.
The natural replacement for the network security perimeter in a complex modern enterprise is the authentication
and authorization controls in an organization's identity layer. Privileged administrative accounts are effectively in
control of this new "security perimeter" so it's critical to protect privileged access:
An adversary that gains control of an administrative account can use those privileges to pursue their gain at the
expense of the target organization as depicted below:
For more information on the types of attacks that commonly lead to attackers in control of administrative accounts,
please visit the Pass The Hash web site for informative white papers, videos and more.
This figure depicts the separate "channel" for administration that the roadmap establishes to isolate privileged
access tasks from high risk standard user tasks like web browsing and accessing email.
Because the adversary can gain control of privileged access using a variety of methods, mitigating this risk requires
a holistic and detailed technical approach as outlined in this roadmap. The roadmap will isolate and harden the
elements in your environment that enable privileged access by building mitigations in each area of the defense
column in this figure:
Security privileged access roadmap

The roadmap is designed to maximize the use of technologies that you already have deployed, take advantage of
key current and upcoming security technologies, and integrate any 3rd party security tools you may already have
deployed.
The roadmap of Microsoft recommendations is broken into 3 stages:
2-4 week plan - Quickly mitigate the most frequently used attack techniques
1-3 month plan - Build visibility and control of admin activity
6+ month plan - Continue building defenses to a more proactive security posture
Each stage of the roadmap is designed to raise the cost and difficulty for adversaries to attack privileged access for
your on-premises and cloud assets. The roadmap is prioritized to schedule the most effective and the quickest
implementations first based on our experiences with these attacks and solution implementation.
NOTE
The timelines for the roadmap are approximate and are based on our experience with customer implementations. The
duration will vary in your organization depending on the complexity of your environment and your change management
processes.
Security Privileged Access Roadmap: Stage 1

Stage 1 of the roadmap is focused on quickly mitigating the most frequently used attack techniques of credential
theft and abuse. Stage 1 is designed to be implemented in approximately 2-4 weeks and is depicted in this diagram:
Stage 1 of the Security Privileged Access roadmap includes these components:
1. Separate Admin account for admin tasks
To help separate internet risks (phishing attacks, web browsing) from administrative privileges, create a dedicated
account for all personnel with administrative privileges. Additional guidance on this is included in the PAW
instructions published here.
2. Privileged Access Workstations (PAWs) Phase 1: Active Directory admins
To help separate internet risks (phishing attacks, web browsing) from domain administrative privileges, create
dedicated privileged access workstations (PAWs) for personnel with AD administrative privileges. This is the first
step of a PAW program and is Phase 1 of the guidance published here.
3. Unique Local Admin Passwords for Workstations
4. Unique Local Admin Passwords for Servers
To mitigate the risk of an adversary stealing a local administrator account password hash from the local SAM
database and abusing it to attack other computers, you should use the LAPS tool to configure unique random
passwords on each workstation and server and register those passwords in Active Directory. You can obtain the
Local Administrator Password Solution for use on workstations and servers here.
Additional guidance for operating an environment with LAPS and PAWs can be found here.
Stage 2 builds on the mitigations from Stage 1 and is designed to be implemented in approximately 1-3 months.
The steps of this stage are depicted in this diagram:
1. PAW Phases 2 and 3: all admins and additional hardening
To separate internet risks from all privileged administrative accounts, continue with the PAW you started in stage 1
and implement dedicated workstations for all personnel with privileged access. This maps to Phase 2 and 3 of the
guidance published here.
2. Time-bound privileges (no permanent administrators)
To lower the exposure time of privileges and increase visibility into their use, provide privileges just in time (JIT)
using an appropriate solution such as the ones below:
For Active Directory Domain Services (AD DS ), use Microsoft Identity Manager (MIM )'s Privileged Access
Manager (PAM ) capability.
For Azure Active Directory, use Azure AD Privileged Identity Management (PIM ) capability.
3. Multi-factor for time-bound elevation
To increase the assurance level of administrator authentication, you should require multi-factor authentication
before granting privileges. This can be accomplished with MIM PAM and Azure AD PIM using Azure Multi-factor
authentication (MFA).
4. Just Enough Admin (JEA ) for DC Maintenance
To reduce the quantity of accounts with domain administration privileges and associated risk exposure, use the Just
Enough Administration (JEA) feature in PowerShell to perform common maintenance operations on domain
controllers. The JEA technology allows specific users to perform specific administrative tasks on servers (like
Domain Controllers) without giving them administrator rights. Download this guidance from TechNet.
5. Lower attack surface of Domain and DCs
To reduce opportunities for adversaries to take control of a forest, you should reduce the pathways an attacker can
take to gain control of Domain Controllers or objects in control of the domain. Follow guidance to reduce this risk
published here.
6. Attack Detection
To get visibility into active credential theft and identity attacks so that you can respond quickly to events and
contain damage, deploy and configure Microsoft Advanced Threat Analytics (ATA).
Prior to installing ATA, you should ensure you have a process in place to handle a major security incident that ATA
may detect.
For more information on setting up an incident response process, see Responding to IT Security Incidents
and the "Respond to suspicious activity" and "Recover from a breach" sections of Mitigating Pass-the-Hash
and Other Credential Theft, version 2.
For more information on engaging Microsoft services to assist with preparing your IR process for ATA
generated events and deploying ATA, contact your Microsoft representative by accessing this page.
Access this page for more information on engaging Microsoft services to assist with investigating and
recovering from an incident.
To Implement ATA, follow the deployment guide available here.
Stage 3 of the roadmap builds on the mitigations from Stages 1 and 2 to strengthen and add mitigations across the
spectrum. Stage 3 is depicted visually in this diagram:
These capabilities will build on the mitigations from previous phases and move your defenses into a more
proactive posture.
1. Modernize Roles and Delegation Model
To reduce security risk, you should redesign all aspects of your roles and delegation model to be compliant with the
rules of the tier model, accommodate cloud service administrative roles, and incorporate administrator usability as
a key tenet. This model should leverage the JIT and JEA capabilities deployed in the earlier stages as well as task
automation technology to achieve these goals.
2. Smartcard or Passport Authentication for all admins
To increase the assurance level and usability of administrator authentication, you should require strong
authentication for all administrative accounts hosted in Azure Active Directory and in your Windows Server Active
Directory (including accounts federated to a cloud service).
3. Admin Forest for Active Directory administrators
To provide the strongest protection for Active Directory administrators, set up an environment that has no security
dependencies on your production Active Directory and is isolated from attacks from all but the most trusted
systems in your production environment. For more information on the ESAE architecture visit this page.
4. Windows Defender Device Guard for DCs (Server 2016)
To limit the risk of unauthorized programs on your domain controllers from adversary attack operations and
inadvertent administrative errors, configure Windows Defender Device Guard virtualization-based security for
kernel (also known as Hypervisor Code Integrity, HVCI) and Windows Defender Application Control policies (also
known as Configurable Code Integrity, Configurable CI) for applications to only allow authorized executables to
run on the machine. For more information on Windows Defender Device Guard visit this page.
5. Shielded VMs for virtual DCs (Server 2016 Hyper-V Fabric)
To protect virtualized domain controllers from attack vectors that exploit a virtual machine's inherent loss of
physical security, use this new Server 2016 Hyper-V capability to help prevent the theft of Active Directory secrets
from Virtual DCs. Using this solution, you can encrypt Generation 2 VMs to protect the VM data against
inspection, theft, and tampering by storage and network administrators as well as harden the access to the VM
against Hyper-V host administrators attacks. For more information on Shielded VMs visit this page.
Am I done?
Completing this roadmap will gain you strong privileged access protections for the attacks that are currently
known and available to adversaries today. Unfortunately, security threats will constantly evolve and shift, so we
recommend you view security as an ongoing process focused on raising the cost and reducing the success rate of
adversaries targeting your environment.
Securing privileged access is a critical first step to establishing security assurances for business assets in a modern
organization, but it is not the only part of a complete security program that would include elements like policy,
operations, information security, servers, applications, PCs, devices, cloud fabric, and other components provide the
security assurances you require.
For more information on building a complete security roadmap, see the "Customer responsibilities and roadmap"
section of the Microsoft Cloud Security for Enterprise Architects document available here.
For more information on engaging Microsoft services to assist with any of these topics, contact your Microsoft
representative or visit this page.
Related topics
Taste of Premier: How to Mitigate Pass-the-Hash and Other Forms of Credential Theft
Microsoft Advanced Threat Analytics
Protect derived domain credentials with Credential Guard
Device Guard Overview
Protecting high-value assets with secure admin workstations
Isolated User Mode in Windows 10 with Dave Probert (Channel 9)
Isolated User Mode Processes and Features in Windows 10 with Logan Gabriel (Channel 9)
More on Processes and Features in Windows 10 Isolated User Mode with Dave Probert (Channel 9)
Mitigating Credential Theft using the Windows 10 Isolated User Mode (Channel 9)
Enabling Strict KDC Validation in Windows Kerberos
What's New in Kerberos Authentication for Windows Server 2012
Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide
Trusted Platform Module
Privileged Access Workstations
Privileged Access Workstations (PAWs) provide a dedicated operating system for sensitive tasks that is protected
from Internet attacks and threat vectors. Separating these sensitive tasks and accounts from the daily use
workstations and devices provides very strong protection from phishing attacks, application and OS vulnerabilities,
various impersonation attacks, and credential theft attacks such as keystroke logging, see Pass-the-Hash, and Pass-
The-Ticket.
Architecture Overview
The diagram below depicts a separate "channel" for administration (a highly sensitive task) that is created by
maintaining separate dedicated administrative accounts and workstations.
This architectural approach builds on the protections found in the Windows 10 Credential Guard and Device
Guard features and goes beyond those protections for sensitive accounts and tasks.
This methodology is appropriate for accounts with access to high value assets:
Administrative Privileges the PAWs provide increased security for high impact IT administrative roles and
tasks. This architecture can be applied to administration of many types of systems including Active Directory
Domains and Forests, Microsoft Azure Active Directory tenants, Office 365 tenants, Process Control
Networks (PCN ), Supervisory Control and Data Acquisition (SCADA) systems, Automated Teller Machines
(ATMs), and Point of Sale (PoS ) devices.
High Sensitivity Information workers the approach used in a PAW can also provide protection for highly
sensitive information worker tasks and personnel such as those involving pre-announcement Merger and
Acquisition activity, pre-release financial reports, organizational social media presence, executive
communications, unpatented trade secrets, sensitive research, or other proprietary or sensitive data. This
guidance does not discuss the configuration of these information worker scenarios in depth or include this
scenario in the technical instructions.
NOTE
Microsoft IT uses PAWs (internally referred to as "secure admin workstations", or SAWs) to manage secure access to
internal high-value systems within Microsoft. This guidance has additional details below on PAW usage at Microsoft
in the section "How Microsoft uses admin workstations". For more detailed information on this high value asset
environment approach, please refer to the article, Protecting high-value assets with secure admin workstations.
This document will describe why this practice is recommended for protecting high impact privileged accounts,
what these PAW solutions look like for protecting administrative privileges, and how to quickly deploy a PAW
solution for domain and cloud services administration.
This document provides detailed guidance for implementing several PAW configurations and includes detailed
implementation instructions to get you started on protecting common high impact accounts:
Phase 1 - Immediate Deployment for Active Directory Administrators this provides a PAW quickly
that can protect on premises domain and forest administration roles
Phase 2 - Extend PAW to all administrators this enables protection for administrators of cloud services
like Office 365 and Azure, enterprise servers, enterprise applications, and workstations
Phase 3 - Advanced PAW security this discusses additional protections and considerations for PAW
security
Why a dedicated workstation?
The current threat environment for organizations is rife with sophisticated phishing and other internet attacks that
create continuous risk of security compromise for internet exposed accounts and workstations.
This threat environment requires an organizations to adopt an "assume breach" security posture when designing
protections for high value assets like administrative accounts and sensitive business assets. These high value assets
need to be protected against both direct internet threats as well as attacks mounted from other workstations,
servers, and devices in the environment.
This figure depicts risk to managed assets if an attacker gains control of a user workstation where sensitive
credentials are used.
An attacker in control of an operating system has numerous ways in which to illicitly gain access to all activity on
the workstation and impersonate the legitimate account. A variety of known and unknown attack techniques can be
used to gain this level of access. The increasing volume and sophistication of cyberattacks have made it necessary
to extend that separation concept to completely separate client operating systems for sensitive accounts. For more
information on these types of attacks, please visit the Pass The Hash web site for informative white papers, videos
and more.
The PAW approach is an extension of the well-established recommended practice to use separate admin and user
accounts for administrative personnel. This practice uses an individually assigned administrative account that is
completely separate from the user's standard user account. PAW builds on that account separation practice by
providing a trustworthy workstation for those sensitive accounts.
This PAW guidance is intended to help you implement this capability for protecting high value accounts such as
high-privileged IT administrators and high sensitivity business accounts. The guidance helps you:
Restrict exposure of credentials to only trusted hosts
Provide a high-security workstation to administrators so they can easily perform administrative tasks.
Restricting the sensitive accounts to using only hardened PAWs is a straightforward protection for these accounts
that is both highly usable for administrators and very difficult for an adversary to defeat.
Alternate approaches - Limitations, considerations, and integration
This section contains information on how the security of alternate approaches compares to PAW and how to
correctly integrate these approaches within a PAW architecture. All of these approaches carry significant risks when
implemented in isolation, but can add value to a PAW implementation in some scenarios.
Credential Guard and Windows Hello for Business
Introduced in Windows 10, Credential Guard uses hardware and virtualization-based security to mitigate common
credential theft attacks, such as Pass-the-Hash, by protecting the derived credentials. The private key for credentials
used by Windows Hello for Business can be also be protected by Trusted Platform Module (TPM ) hardware.
These are powerful mitigations, but workstations can still be vulnerable to certain attacks even if the credentials are
protected by Credential Guard or Windows Hello for Business. Attacks can include abusing privileges and use of
credentials directly from a compromised device, reusing previously stolen credentials prior to enabling Credential
Guard and abuse of management tools and weak application configurations on the workstation.
The PAW guidance in this section includes the use of many of these technologies for high sensitivity accounts and
tasks.
Administrative VM
An administrative virtual machine (Admin VM ) is a dedicated operating system for administrative tasks hosted on
a standard user desktop. While this approach is similar to PAW in providing a dedicated OS for administrative
tasks, it has a fatal flaw in that the administrative VM is dependent on the standard user desktop for its security.
The diagram below depicts the ability of attackers to follow the control chain to the target object of interest with an
Admin VM on a User Workstation and that it is difficult to create a path on the reverse configuration.
The PAW architecture does not allow for hosting an Admin VM on a User Workstation, but a User VM with a
standard corporate image can be hosted on an Admin PAW to provide personnel with a single PC for all
responsibilities.
Jump Server
Administrative "Jump Server" architectures set up a small number administrative console servers and restrict
personnel to using them for administrative tasks. This is typically based on remote desktop services, a 3rd-party
presentation virtualization solution, or a Virtual Desktop Infrastructure (VDI) technology.
This approach is frequently proposed to mitigate risk to administration and does provide some security assurances,
but the jump server approach by itself is vulnerable to certain attacks because it violates the "clean source"
principle. The clean source principle requires all security dependencies to be as trustworthy as the object being
secured.
This figure depicts a simple control relationship. Any subject in control of an object is a security dependency of that
object. If an adversary can control a security dependency of a target object (subject), they can control that object.
The administrative session on the jump server relies on the integrity of the local computer accessing it. If this
computer is a user workstation subject to phishing attacks and other internet-based attack vectors, then the
administrative session is also subject to those risks.
The figure above depicts how attackers can follow an established control chain to the target object of interest.
While some advanced security controls like multi-factor authentication can increase the difficulty of an attacker
taking over this administrative session from the user workstation, no security feature can fully protect against
technical attacks when an attacker has administrative access of the source computer (e.g. injecting illicit commands
into a legitimate session, hijacking legitimate processes, and so on.)
The default configuration in this PAW guidance installs administrative tools on the PAW, but a jump server
architecture can also be added if required.
This figure shows how reversing the control relationship and accessing user apps from an admin workstation gives
the attacker no path to the targeted object. The user jump server is still exposed to risk so appropriate protective
controls, detective controls, and response processes should still be applied for that internet-facing computer.
This configuration requires administrators to follow operational practices closely to ensure that they don't
accidentally enter administrator credentials into the user session on their desktop.
This figure shows how accessing an administrative jump server from a PAW adds no path for the attacker into the
administrative assets. A jump server with a PAW allows in this case you to consolidate the number of locations for
monitoring administrative activity and distributing administrative applications and tools. This adds some design
complexity, but can simplify security monitoring and software updates if a large number of accounts and
workstations are used in your PAW implementation. The jump server would need to be built and configured to
similar security standards as the PAW.
Privilege Management Solutions
Privileged Management solutions are applications that provide temporary access to discrete privileges or
privileged accounts on demand. Privilege management solutions are an extremely valuable component of a
complete strategy to secure privileged access and provide critically important visibility and accountability of
administrative activity.
These solutions typically use a flexible workflow to grant access and many have additional security features and
capabilities like service account password management and integration with administrative jump servers. There
are many solutions on the market that provide privilege management capabilities, one of which is Microsoft
Identity Manager (MIM ) privileged access management (PAM ).
Microsoft recommends using a PAW to access privilege management solutions. Access to these solutions should
be granted only to PAWs. Microsoft does not recommend using these solutions as a substitute for a PAW because
accessing privileges using these solutions from a potentially compromised user desktop violates the clean source
principle as depicted in the diagram below:
Providing a PAW to access these solutions enables you to gain the security benefits of both PAW and the privilege
management solution, as depicted in this diagram:
NOTE
These systems should be classified at the highest tier of the privilege they manage and be protected at or above that level of
security. These are commonly configured to manage Tier 0 solutions and Tier 0 assets and should be classified at Tier 0. For
more information on the tier model, see http://aka.ms/tiermodel For more information on Tier 0 groups, see Tier 0
equivalency in Securing Privileged Access Reference Material.
For more information on deploying Microsoft Identity Manager (MIM ) privileged access management (PAM ), see
http://aka.ms/mimpamdeploy
How Microsoft is using administrative workstations
Microsoft uses the PAW architectural approach both internally on our systems as well as with our customers.
Microsoft uses administrative workstations internally in a number of capacities including administration of
Microsoft IT infrastructure, Microsoft cloud fabric infrastructure development and operations, and other high value
assets.
This guidance is directly based on the Privileged Access Workstation (PAW ) reference architecture deployed by our
cybersecurity professional services teams to protect customers against cybersecurity attacks. The administrative
workstations are also a key element of the strongest protection for domain administration tasks, the Enhanced
Security Administrative Environment (ESAE ) administrative forest reference architecture.
For more details on the ESAE administrative forest, see ESAE Administrative Forest Design Approach section in
Securing Privileged Access Reference Material.
For more information on engaging Microsoft services to deploy a PAW or ESAE for your environment, contact
your Microsoft representative or visit this page.
What is a Privileged Access Workstation (PAW)?
In simplest terms, a PAW is a hardened and locked down workstation designed to provide high security assurances
for sensitive accounts and tasks. PAWs are recommended for administration of identity systems, cloud services,
and private cloud fabric as well as sensitive business functions.
NOTE
The PAW architecture doesn't require a 1:1 mapping of accounts to workstations, though this is a common configuration.
PAW creates a trusted workstation environment that can be used by one or more accounts.
In order to provide the greatest security, PAWs should always run the most up-to-date and secure operating
system available: Microsoft strongly recommends Windows 10 Enterprise, which includes a number of additional
security features not available in other editions (in particular, Credential Guard and Device Guard).
NOTE
Organizations without access to Windows 10 Enterprise can use Windows 10 Pro, which includes many of the critical
foundational technologies for PAWs, including Trusted Boot, BitLocker, and Remote Desktop. Education customers can use
Windows 10 Education. Windows 10 Home should not be used for a PAW.
For a comparison matrix of the different editions of Windows 10, read this article.
The security controls in PAW are focused on mitigating the highest impact and most likely risks of compromise.
These include mitigating attacks on the environment and mitigating risks that the PAW controls may degrade over
time:
Internet attacks - Most attacks originate directly or indirectly from internet sources and use the internet for
exfiltration and command and control (C2). Isolating the PAW from the open internet is a key element to
ensuring the PAW is not compromised.
Usability risk - If a PAW is too difficult to use for daily tasks, administrators will be motivated to create
workarounds to make their jobs easier. Frequently, these workarounds open the administrative workstation
and accounts to significant security risks, so it's critical to involve and empower the PAW users to mitigate
these usability issues securely. This is frequently accomplished by listening to their feedback, installing tools
and scripts required to perform their jobs, and ensuring all administrative personnel are aware of why they
need to use a PAW, what a PAW is, and how to use it correctly and successfully.
Environment risks - Because many other computers and accounts in the environment are exposed to
internet risk directory or indirectly, a PAW must be protected against attacks from compromised assets in
the production environment. This requires limiting the management tools and accounts that have access to
the PAWs to the absolute minimum required to secure and monitor these specialized workstations.
Supply chain tampering - While it's impossible to remove all possible risks of tampering in the supply
chain for hardware and software, taking a few key actions can mitigate critical attack vectors that are readily
available to attackers. This includes validating the integrity of all installation media (Clean Source Principle)
and using a trusted and reputable supplier for hardware and software.
Physical attacks - Because PAWs can be physically mobile and used outside of physically secure facilities,
they must be protected against attacks that leverage unauthorized physical access to the computer.
NOTE
A PAW will not protect an environment from an adversary that has already gained administrative access over an Active
Directory Forest. Because many existing implementations of Active Directory Domain Services have been operating for years
at risk of credential theft, organizations should assume breach and consider the possibility that they may have an undetected
compromise of domain or enterprise administrator credentials. An organization that suspects domain compromise should
consider the use of professional incident response services.
For more information on response and recovery guidance, see the "Respond to suspicious activity" and "Recover from a
breach" sections of Mitigating Pass-the-Hash and Other Credential Theft, version 2.
Visit Microsoft's Incident Response and Recovery services page for more information.
PAW Hardware Profiles

Administrative personnel are also standard users too - they need not only a PAW, but also a standard user
workstation to check email, browse the web, and access corporate line of business applications. Ensuring that
administrators can remain both productive and secure is essential to the success of any PAW deployment. A secure
solution that dramatically limits productivity will be abandoned by the users in favor of one that enhances
productivity (even if it is done in an insecure manner).
In order to balance the need for security with the need for productivity, Microsoft recommends using one of these
PAW hardware profiles:
Dedicated hardware - Separate dedicated devices for user tasks vs. administrative tasks
Simultaneous Use - Single device that can run user tasks and administrative tasks concurrently by taking
advantage of OS or presentation virtualization.
Organizations may use only one profile or both. There are no interoperability concerns between the hardware
profiles, and organizations have the flexibility to match the hardware profile to the specific need and situation of a
given administrator.
NOTE
It is critical that, in all of these scenarios, administrative personnel are issued a standard user account that is separate from
designated administrative account(s). The administrative account(s) should only be used on the PAW administrative operating
system.
This table summarizes the relative advantages and disadvantages of each hardware profile from the perspective of
operational ease-of-use and productivity and security. Both hardware approaches provide strong security for
administrative accounts against credential theft and reuse.
SCENARIO ADVANTAGES DISADVANTAGES
Dedicated hardware - Strong signal for sensitivity of tasks - Additional desk space
- Strongest security separation - Additional weight (for remote work)
- Hardware Cost
Simultaneous use - Lower hardware cost - Sharing single keyboard/mouse

- Single device experience creates risk of inadvertent errors/risks
This guidance contains the detailed instructions for the PAW configuration for the dedicated hardware approach. If
you have requirements for the simultaneous use hardware profiles, you can adapt the instructions based on this
guidance yourself or hire a professional services organization like Microsoft to assist with it.
Dedicated Hardware
In this scenario, a PAW is used for administration that is completely separate from the PC that is used for daily
activities like email, document editing, and development work. All administrative tools and applications are
installed on the PAW and all productivity applications are installed on the standard user workstation. The step by
step instructions in this guidance are based on this hardware profile.
Simultaneous Use - Adding a local user VM
In this simultaneous use scenario, a single PC is used for both administration tasks and daily activities like email,
document editing, and development work. In this configuration, the user operating system is available while
disconnected (for editing documents and working on locally cached email), but requires hardware and support
processes that can accommodate this disconnected state.
The physical hardware runs two operating systems locally:

Admin OS - The physical host runs Windows 10 on the PAW host for Administrative tasks
User OS - A Windows 10 client Hyper-V virtual machine guest runs a corporate image
With Windows 10 Hyper-V, a guest virtual machine (also running Windows 10) can have a rich user experience
including sound, video, and Internet communications applications such as Skype for Business.
In this configuration, daily work that does not require administrative privileges is done in the user OS virtual
machine which has a regular corporate Windows 10 image and is not subject to restrictions applied to the PAW
host. All administrative work is done on the Admin OS.
To configure this, follow the instructions in this guidance for the PAW host, add Client Hyper-V features, create a
User VM, and then install a Windows 10 corporate image on the User VM.
Read Client Hyper-V article for more information about this capability. Please note that the operating system in
guest virtual machines will need to be licensed per Microsoft product licensing, also described here.
Simultaneous Use - Adding RemoteApp, RDP, or a VDI
In this simultaneous use scenario, a single PC is used for both administration tasks and daily activities like email,
document editing and development work. In this configuration, the user operating systems are deployed and
managed centrally (on the cloud or in your datacenter), but aren't available while disconnected.
The physical hardware runs a single PAW operating system locally for administrative tasks and contacts a
Microsoft or 3rd party remote desktop service for user applications such as email, document editing, and line of
business applications.
In this configuration, daily work that does not require administrative privileges is done in the Remote OS (es) and
applications which are not subject to restrictions applied to the PAW host. All administrative work is done on the
Admin OS.
To configure this, follow the instructions in this guidance for the PAW host, allow network connectivity to the
Remote Desktop services, and then add shortcuts to the PAW user's desktop to access the applications. The remote
desktop services could be hosted in many ways including:
An existing Remote Desktop or VDI service (on-premises or in the cloud)
A new service you install on-premises or in the cloud
Azure RemoteApp using pre-configured Office 365 templates or your own installation images
For more information on Azure RemoteApp, visit this page.
PAW Scenarios
This section contains guidance on which scenarios this PAW guidance should be applied to. In all scenarios,
administrators should be trained to only use PAWs for performing support of remote systems. To encourage
successful and secure usage, all PAW users should be also be encouraged to provide feedback to improve the PAW
experience and this feedback should be reviewed carefully for integration with your PAW program.
In all scenarios, additional hardening in later phases and different hardware profiles in this guidance may be used
to meet the usability or security requirements of the roles.
NOTE
This guidance explicitly differentiates between requiring access to specific services on the internet (such as Azure and Office
365 administrative portals) and the "Open Internet" of all hosts and services.
See the Tier model page for more information on the Tier designations.
SCENARIOS USE PAW? SCOPE AND SECURITY CONSIDERATIONS
Active Directory Admins - Tier 0 Yes A PAW built with Phase 1 guidance is
sufficient for this role.
- An administrative forest can be added

to provide the strongest protection for
this scenario. For more information on
the ESAE administrative forest, see ESAE
Administrative Forest Design Approach
- A PAW can be used to managed
multiple domains or multiple forests.
- If Domain Controllers are hosted on
an Infrastructure as a Service (IaaS) or
on-premises virtualization solution, you
should prioritize implementing PAWs
for the administrators of those
solutions.
Admin of Azure IaaS and PaaS services Yes A PAW built using the guidance
- Tier 0 or Tier 1 (see Scope and Design provided in Phase 2 is sufficient for this
Considerations) role.
- PAWs should be used for at least the

Global administrator and Subscription
Billing administrator. You should also
use PAWs for delegated administrators
of critical or sensitive servers.
- PAWs should be used for managing
the operating system and applications
that provide Directory Synchronization
and Identity Federation for cloud
services such as Azure AD Connect and
(ADFS).
- The outbound network restrictions
must allow connectivity only to
authorized cloud services using the
guidance in Phase 2. No open internet
access should be allowed from PAWs.
- Windows Defender Exploit Guard
should be configured on the
workstation Note: A subscription is
considered to be Tier 0 for a Forest if
Domain Controllers or other Tier 0
hosts are in the subscription. A
subscription is Tier 1 if no Tier 0 servers
are hosted in Azure.
Admin Office 365 Tenant Yes A PAW built using the guidance
- Tier 1 provided in Phase 2 is sufficient for this
role.
- PAWs should be used for at least the

Subscription Billing administrator, Global
administrator, Exchange administrator,
SharePoint administrator, and User
management administrator roles. You
should also strongly consider the use of
PAWs for delegated administrators of
highly critical or sensitive data.
workstation.
Microsoft services using the guidance in
Phase 2. No open internet access
should be allowed from PAWs.
Other IaaS or PaaS cloud service admin A PAW built using the guidance
- PAWs should be used for any role that

has administrative rights over cloud
hosted VMs including the ability to
install agents, export hard disk files, or
access storage where hard drives with
operating systems, sensitive data, or
business critical data is stored.
Microsoft services using the guidance in
Phase 2. No open internet access
should be allowed from PAWs.
workstation. Note: A subscription is Tier
0 for a Forest if Domain Controllers or
other Tier 0 hosts are in the
subscription. A subscription is Tier 1 if
no Tier 0 servers are hosted in Azure.
Virtualization Administrators Yes A PAW built using the guidance

- PAWs should be used for any role that

has administrative rights over VMs
including the ability to install agents,
export virtual hard disk files, or access
storage where hard drives with guest
operating system information, sensitive
data, or business critical data is stored.
Note: A virtualization system (and its
admins) are considered Tier 0 for a
Forest if Domain Controllers or other
Tier 0 hosts are in the subscription. A
subscription is Tier 1 if no Tier 0 servers
are hosted in the virtualization system.
Server Maintenance Admins Yes A PAW built using the guidance

- Tier 1 provided in Phase 2 is sufficient for this
role.
- A PAW should be used for

administrators that update, patch, and
troubleshoot enterprise servers and
apps running Windows server, Linux,
and other operating systems.
- Dedicated management tools may
need to be added for PAWs to handle
the larger scale of these admins.
User Workstation Admins Yes A PAW built using guidance provided in

- Tier 2 Phase 2 is sufficient for roles that have
administrative rights on end user
devices (such as helpdesk and deskside
support roles).
- Additional applications may need to

be installed on PAWs to enable ticket
management and other support
functions.
workstation.
Dedicated management tools may need
to be added for PAWs to handle the
larger scale of these admins.
SQL, SharePoint, or line of business A PAW built with Phase 2 guidance is

(LOB) Admin sufficient for this role.
- Tier 1
- Additional management tools may
need to be installed on PAWs to allow
administrators to manage applications
without needing to connect to servers
using Remote Desktop.
Users Managing Social Media Presence Partially A PAW built using the guidance
provided in Phase 2 can be used as a
starting point to provide security for
these role.
- Protect and manage social media

accounts using Azure Active Directory
(AAD) for sharing, protecting, and
tracking access to social media
accounts.
For more information on this capability
read this blog post.
must allow connectivity to these
services. This can be done by allowing
open internet connections (much higher
security risk that negates many PAW
assurances) or by allowing only required
DNS addresses for the service (may be
challenging to obtain).
Standard Users No While many hardening steps can be

used for standard users, PAW is
designed to isolate accounts from the
open internet access that most users
require for job duties.
Guest VDI/Kiosk No While many hardening steps can be

used for a kiosk system for guests, the
PAW architecture is designed to provide
higher security for high sensitivity
accounts, not higher security for lower
sensitivity accounts.
VIP User (Executive, Researcher, etc.) Partially A PAW built using guidance provided in
Phase 2 can be used as a starting point
to provide security for these roles.
- This scenario is similar to a standard

user desktop, but typically has a smaller,
simpler, and well-known application
profile. This scenario typically requires
discovering and protecting sensitive
data, services, and applications (which
may or may not be installed on the
desktops).
- These roles typically require a high
degree of security and very high degree
of usability, which require design
changes to meet user preferences.
Industrial control systems (e.g. SCADA, Partially A PAW built using guidance provided in
PCN, and DCS) Phase 2 can be used as a starting point
to provide security for these roles as
most ICS consoles (including such
common standards as SCADA and PCN)
don't require browsing the open
Internet and checking email.
- Applications used for controlling

physical machinery would have to be
integrated and tested for compatibility
and protected appropriately.
Embedded Operating System No While many hardening steps from PAW

can be used for embedded operating
systems, a custom solution would need
to be developed for hardening in this
scenario.
NOTE
Combination scenarios some personnel may have administrative responsibilities that span multiple scenarios. In these
cases, the key rules to keep in mind are that the Tier model rules must be followed at all times. See the Tier model page for
more information.
NOTE
Scaling the PAW Program as your PAW program scales to encompass more admins and roles, you need to continue to
ensure that you maintain adherence to the security standards and usability. This may require you to update your IT support
structures or create new ones to resolve PAW specific challenges such as PAW onboarding process, incident management,
configuration management, and gathering feedback to address usability challenges. One example may be that your
organization decides to enable work-from-home scenarios for administrators, which would necessitate a shift from desktop
PAWs to laptop PAWs - a shift which may necessitate additional security considerations. Another common example is to
create or update training for new administrators - training which must now include content on the appropriate use of a PAW
(including why its important and what a PAW is and isn't). For more considerations which must be addressed as you scale
your PAW program, see Phase 2 of the instructions.
This guidance contains the detailed instructions for the PAW configuration for the scenarios as noted above. If you
have requirements for the other scenarios, you can adapt the instructions based on this guidance yourself or hire a
professional services organization like Microsoft to assist with it.
For more information on engaging Microsoft services to design a PAW tailored for your environment, contact your
Microsoft representative or visit this page.
PAW Installation instructions
Because the PAW must provide a secure and trusted source for administration, it's essential that the build process
is secure and trusted. This section will provide detailed instructions which will allow you to build your own PAW
using general principles and concepts very similar to those used by Microsoft IT and Microsoft cloud engineering
and service management organizations.
The instructions are divided into three phases which focus on putting the most critical mitigations in place quickly
and then progressively increasing and expanding the usage of PAW for the enterprise.
Phase 1 - Immediate Deployment for Active Directory Administrators
Phase 2 - Extend PAW to all administrators
Phase 3 - Advanced PAW security
It is important to note that the phases should always be performed in order even if they are planned and
implemented as part of the same overall project.
Phase 1 - Immediate Deployment for Active Directory Administrators
Purpose: Provides a PAW quickly that can protect on-premises domain and forest administration roles.
Scope: Tier 0 Administrators including Enterprise Admins, Domain Admins (for all domains), and administrators of
other authoritative identity systems.
Phase 1 focuses on the administrators who manage your on-premises Active Directory domain, which are critically
important roles frequently targeted by attackers. These identity systems will work effectively for protecting these
admins whether your Active Directory Domain Controllers (DCs) are hosted in on-premises datacenters, on Azure
Infrastructure as a Service (IaaS ), or another IaaS provider.
During this phase, you will create the secure administrative Active Directory organizational unit (OU ) structure to
host your privileged access workstation (PAW ), as well as deploy the PAWs themselves. This structure also includes
the group policies and groups required to support the PAW. You will create most of the structure using PowerShell
scripts which are available at TechNet Gallery.
The scripts will create the following OUs and Security Groups:
Organizational Units (OU )
Six new top-level OUs: Admin; Groups; Tier 1 Servers; Workstations; User Accounts; and Computer
Quarantine. Each top-level OU will contain a number of child OUs.
Groups
Six new security-enabled global groups: Tier 0 Replication Maintenance; Tier 1 Server Maintenance;
Service Desk Operators; Workstation Maintenance; PAW Users; PAW Maintenance.
You will also create a number of group policy objects: PAW Configuration - Computer; PAW Configuration - User;
RestrictedAdmin Required - Computer; PAW Outbound Restrictions; Restrict Workstation Logon; Restrict Server
Logon.
Phase 1 includes the following steps:
1. Complete the Prerequisites
a. Ensure that all administrators use separate, individual accounts for administration and end
user activities (including email, Internet browsing, line-of-business applications, and other non-
administrative activities). Assigning an administrative account to each authorized personnel separate
from their standard user account is fundamental to the PAW model, as only certain accounts will be
permitted to log onto the PAW itself.
NOTE
Each administrator should use his or her own account for administration. Do not share an administrative
account.
b. Minimize the number of Tier 0 privileged administrators. Because each administrator must use
a PAW, reducing the number of administrators reduces the number of PAWs required to support
them and the associated costs. The lower count of administrators also results in lower exposure of
these privileges and associated risks. While it is possible for administrators in one location to share a
PAW, administrators in separate physical locations will require separate PAWs.
c. Acquire hardware from a trusted supplier that meets all technical requirements. Microsoft
recommends acquiring hardware that meets the technical requirements in the article Protect domain
credentials with Credential Guard.
NOTE
PAW installed on hardware without these capabilities can provide significant protections, but advanced
security features such as Credential Guard and Device Guard will not be available. Credential Guard and
Device Guard are not required for Phase 1 deployment, but are strongly recommended as part of Phase 3
(advanced hardening).
Ensure that the hardware used for the PAW is sourced from a manufacturer and supplier whose
security practices are trusted by the organization. This is an application of the clean source principle
to supply chain security.
NOTE
For more background on the importance of supply chain security, visit this site.
d. Acquire and validate the required Windows 10 Enterprise Edition and application software. Obtain
the software required for PAW and validate it using the guidance in Clean Source for installation
media.
Windows 10 Enterprise Edition
Remote Server Administration Tools for Windows 10
Windows 10 Security Baselines
NOTE
Microsoft publishes MD5 hashes for all operating systems and applications on MSDN, but not all
software vendors provide similar documentation. In those cases, other strategies will be required. For
additional information on validating software, please refer to Clean Source for installation media.
e. Ensure you have WSUS server available on the intranet. You will need a WSUS server on the
intranet to download and install updates for PAW. This WSUS server should be configured to
automatically approve all security updates for Windows 10 or an administrative personnel should
have responsibility and accountability to rapidly approve software updates.
NOTE
For more information, see the "Automatically Approve Updates for Installation" section in the Approving
Updates guidance.
2. Deploy the Admin OU Framework to host the PAWs

a. Download the PAW script library from TechNet Gallery
NOTE
Download all of the files and save them to the same directory, and run them in the order specified below.
Create-PAWGroups depends on the OU structure created by Create-PAWOUs, and Set-PAWOUDelegation
depends on the groups created by Create-PAWGroups. Do not modify any of the scripts or the comma-
separated value (CSV) file.
b. Run the Create-PAWOUs.ps1 script. This script will create the new organizational unit (OU )
structure in Active Directory, and block GPO inheritance on the new OUs as appropriate.
c. Run the Create-PAWGroups.ps1 script. This script will create the new global security groups in the
appropriate OUs.
NOTE
While this script will create the new security groups, it will not populate them automatically.
d. Run the Set-PAWOUDelegation.ps1 script. This script will assign permissions to the new OUs to
the appropriate groups.
3. Move Tier 0 accounts to the Admin\Tier 0\Accounts OU. Move each account that is a member of the
Domain Admin, Enterprise Admin, or Tier 0 equivalent groups (including nested membership) to this OU. If
your organization has your own groups that are added to these groups, you should move these to the
Admin\Tier 0\Groups OU.
NOTE
For more information on which groups are Tier 0, see "Tier 0 Equivalency" in Securing Privileged Access Reference
Material.
4. Add the appropriate members to the relevant groups

a. PAW Users - Add the Tier 0 administrators with Domain or Enterprise Admin groups that you
identified in Step 1 of Phase 1.
b. PAW Maintenance - Add at least one account that will be used for PAW maintenance and
troubleshooting tasks. The PAW Maintenance Account(s) will be used only rarely.
NOTE
Do not add the same user account or group to both PAW Users and PAW Maintenance. The PAW security
model is based partly on the assumption that the PAW user account has privileged rights on managed
systems or over the PAW itself, but not both.
This is important for building good administrative practices and habits in Phase 1.
This is critically important for Phase 2 and beyond to prevent escalation of privilege through PAW as
PAWs being to span Tiers.
Ideally, no personnel are assigned to duties at multiple tiers to enforce the principle of segregation of duties,
but Microsoft recognizes that many organizations may have limited staff (or other organizational
requirements) that don't allow for this full segregation. In these cases, the same personnel may be assigned to
both roles, but should not use the same account for these functions.
5. Create "PAW Configuration - Computer" group policy object (GPO ) and link to the Tier 0 Devices
OU ("Devices" under Tier 0\Admin). In this section, you will create a new "PAW Configuration - Computer"
GPO which provide specific protections for these PAWs.
NOTE
Do not add these settings to the Default Domain Policy. Doing so will potentially impact operations on your
entire Active Directory environment. Only configure these settings in the newly-created GPOs described here, and
only apply them to the PAW OU.
a. PAW Maintenance Access - this setting will set the membership of specific privileged groups on
the PAWs to a specific set of users. Go to Computer Configuration\Preferences\Control Panel
Settings\Local Users and Groups and follow the steps below:
a. Click New and click Local Group
b. Select the Update action, and select "Administrators (built-in)" (do not use the Browse button
to select the domain group Administrators).
c. Select the Delete all member users and Delete all member groups check boxes
d. Add PAW Maintenance (pawmaint) and Administrator (again, do not use the Browse button to
select Administrator).
NOTE
Do not add the PAW Users group to the membership list for the local Administrators group. To
ensure that PAW Users cannot accidentally or deliberately modify the security settings of the PAW
itself, they should not be members of the local Administrators groups.
For more information on using Group Policy Preferences to modify group membership, please
refer to the TechNet article Configure a Local Group Item.
b. Restrict Local Group Membership - this setting will ensure that the membership of local admin
groups on the workstation is always empty
a. Go to Computer Configuration\Preferences\Control Panel Settings\Local Users and Groups
and follow the steps below:
a. Click New and click Local Group
b. Select the Update action, and select "Backup Operators (built-in)" (do not use the
Browse button to select the domain group Backup Operators).
c. Select the Delete all member users and Delete all member groups check boxes.
d. Do not add any members to the group. Simply click OK. By assigning an empty list,
group policy will automatically remove all members and ensure a blank membership
list each time group policy is refreshed.
b. Complete the above steps for the following additional groups:
Cryptographic Operators
Hyper-V Administrators
Network Configuration Operators
Power Users
Remote Desktop Users
Replicators
c. PAW Logon Restrictions - this setting will limit the accounts which can log onto the PAW.
Follow the steps below to configure this setting:
a. Go to Computer Configuration\Policies\Windows Settings\Security Settings\Local
Policies\User Rights Assignment\Allow log on locally.
b. Select Define these policy settings and add "PAW Users" and Administrators (again, do
not use the Browse button to select Administrators).
d. Block Inbound Network Traffic - This setting will ensure that no unsolicited inbound
network traffic is allowed to the PAW. Follow the steps below to configure this setting:
a. Go to Computer Configuration\Policies\Windows Settings\Security Settings\Windows
Firewall with Advanced Security\Windows Firewall with Advanced Security and follow
the steps below:
a. Right click on Windows Firewall with Advanced Security and select Import
policy.
b. Click Yes to accept that this will overwrite any existing firewall policies.
c. Browse to PAWFirewall.wfw and select Open.
d. Click OK.
NOTE
You may add addresses or subnets which must reach the PAW with unsolicited traffic
at this point (e.g. security scanning or management software. The settings in the WFW
file will enable the firewall in "Block - Default" mode for all firewall profiles, turn off rule
merging and enable logging of both dropped and successful packets. These settings
will block unsolicitied traffic while still allowing bidirectional communication on
connections initiated from the PAW, prevent users with local administrative access
from creating local firewall rules that would override the GPO settings and ensure that
traffic in and out of the PAW is logged. Opening up this firewall will expand the
attack surface for the PAW and increase security risk. Before adding any
addresses, consult the Managing and Operating PAW section in this guidance.
e. Configure Windows Update for WSUS - follow the steps below to change the settings to
configure Windows Update for the PAWs:
a. Go to Computer Configuration\Policies\Administrative Templates\Windows
Components\Windows Updates and follow the steps below:
a. Enable the Configure Automatic Updates policy.
b. Select option 4 - Auto download and schedule the install.
c. Change the option Scheduled install day to 0 - Every Day and the option
Scheduled install time to your organizational preference.
d. Enable option Specify intranet Microsoft update service location policy, and
specify in both options the URL of the ESAE WSUS server.
f. Link the "PAW Configuration - Computer" GPO as follows:
POLICY LINK LOCATION
PAW Configuration - Computer Admin\Tier 0\Devices
6. Create "PAW Configuration - User" group policy object (GPO ) and link to the Tier 0 Accounts OU
("Accounts" under Tier 0\Admin). In this section, you will create a new "PAW Configuration - User" GPO
which provide specific protections for these PAWs.
NOTE
Do not add these settings to the Default Domain Policy
a. Block internet browsing - To deter inadvertent internet browsing, this will set a proxy address of a
loopback address (127.0.0.1).
a. Go to User Configuration\Preferences\Windows Settings\Registry. Right-click Registry, select
New > Registry Item and configure the following settings:
a. Action: Replace
b. Hive: HKEY_CURRENT_USER
c. Key Path: Software\Microsoft\Windows\CurrentVersion\Internet Settings
d. Value name: ProxyEnable
NOTE
Do not select the Default box to the left of Value name.
e. Value type: REG_DWORD

f. Value data: 1
a. a. Click the Common tab and select Remove this item when it is no longer
applied.
b. On the Common tab select Item level targeting and click Targeting.
c. Click New Item and select Security group.
d. Select the "..." button and browse for the PAW Users group.
e. Click New Item and select Security group.
f. Select the "..." button and browse for the Cloud Services Admins group.
g. Click on the Cloud Services Admins item and click Item Options.
h. Select Is not.
i. Click OK on the targeting window.
g. Click OK to complete the ProxyServer group policy setting
b. Go to User Configuration\Preferences\Windows Settings\Registry. Right-click Registry, select
New > Registry Item and configure the following settings:
Action: Replace
Hive: HKEY_CURRENT_USER
Key Path: Software\Microsoft\Windows\CurrentVersion\Internet Settings
Value name: ProxyServer
NOTE
Value type: REG_SZ

Value data: 127.0.0.1:80
a. Click the Common tab and select Remove this item when it is no longer
applied.
b. On the Common tab select Item level targeting and click Targeting.
c. Click New Item and select security group.
d. Select the "..." button and add the PAW Users group.
e. Click New Item and select security group.
f. Select the "..." button and browse for the Cloud Services Admins group.
g. Click on the Cloud Services Admins item and click Item Options.
h. Select Is not.
i. Click OK on the targeting window.
c. Click OK to complete the ProxyServer group policy setting,
b. Go to User Configuration\Policies\Administrative Templates\Windows Components\Internet
Explorer, and enable the options below. These settings will prevent the administrators from manually
overriding the proxy settings.
a. Enable the Disable changing Automatic Configuration settings.
b. Enable the Prevent changing proxy settings.
7. Restrict Administrators from logging onto lower tier hosts. In this section, we will configure group
policies to prevent privileged administrative accounts from logging onto lower tier hosts.
a. Create the new Restrict Workstation Logon GPO - this setting will restrict Tier 0 and Tier 1
administrator accounts from logging onto standard workstations. This GPO should be linked to the
"Workstations" top-level OU and have the following settings:
(i) In Computer Configuration\Policies\Windows Settings\Security Settings\Local
Policies\User Rights Assignment\Deny log on as a batch job, select Define these policy
settings and add the Tier 0 and Tier 1 groups:
Groups to add to policy settings:
Enterprise Admins
Domain Admins
Schema Admins
DOMAIN\Administrators
Account Operators
Backup Operators
Print Operators
Server Operators
Domain Controllers
Read-Only Domain Controllers
Group Policy Creators Owners
NOTE
Built-in Tier 0 Groups, see Tier 0 equivalency for more details.
Other Delegated Groups
NOTE
Any custom created groups with effective Tier 0 access, see Tier 0 equivalency for more details.
Tier 1 Admins
NOTE
This Group was created earlier in Phase 1.
(ii) In Computer Configuration\Policies\Windows Settings\Security Settings\Local

Policies\User Rights Assignment\Deny log on as a service, select Define these policy
settings and add the Tier 0 and Tier 1 groups:
Enterprise Admins
Domain Admins
Schema Admins
Account Operators
Backup Operators
Print Operators
Server Operators
Domain Controllers
NOTE
Note: Built-in Tier 0 Groups, see Tier 0 equivalency for more details.
NOTE
Note: Any custom created groups with effective Tier 0 access, see Tier 0 equivalency for more details.
Tier 1 Admins
NOTE
Note: This Group was created earlier in Phase 1
b. Create the new Restrict Server Logon GPO - this setting will restrict Tier 0 administrator accounts
from logging onto Tier 1 servers. This GPO should be linked to the "Tier 1 Servers" top-level OU and
have the following settings:
(i) In Computer Configuration\Policies\Windows Settings\Security Settings\Local
Policies\User Rights Assignment\Deny log on as a batch job, select Define these policy
settings and add the Tier 0 groups:
Enterprise Admins
Domain Admins
Schema Admins
Account Operators
Backup Operators
Print Operators
Server Operators
Domain Controllers
NOTE
NOTE
(ii) In Computer Configuration\Policies\Windows Settings\Security Settings\Local

Policies\User Rights Assignment\Deny log on as a service, select Define these policy
settings and add the Tier 0 groups:
Enterprise Admins
Domain Admins
Schema Admins
Account Operators
Backup Operators
Print Operators
Server Operators
Domain Controllers
NOTE

NOTE
(iii) In Computer Configuration\Policies\Windows Settings\Security Settings\Local

Policies\User Rights Assignment\Deny log on locally, select Define these policy settings
and add the Tier 0 groups:
Enterprise Admins
Domain Admins
Schema Admins
Account Operators
Backup Operators
Print Operators
Server Operators
Domain Controllers
NOTE
Note: Built-in Tier 0 Groups, see Tier 0 equivalency for more details.
NOTE
Note: Any custom created groups with effective Tier 0 access, see Tier 0 equivalency for more details.
8. Deploy your PAW (s)
NOTE
Ensure that the PAW is disconnected from the network during the operating system build process.
a. Install Windows 10 using the clean source installation media that you obtained earlier.
NOTE
You may use Microsoft Deployment Toolkit (MDT) or another automated image deployment system to
automate PAW deployment, but you must ensure the build process is as trustworthy as the PAW. Adversaries
specifically seek out corporate images and deployment systems (including ISOs, deployment packages, etc.) as
a persistence mechanism so preexisting deployment systems or images should not be used.
If you automate deployment of the PAW, you must:
Build the system using installation media validated using the guidance in Clean Source for installation
media.
Ensure that the automated deployment system is disconnected from the network during the operating
system build process.
b. Set a unique complex password for the local Administrator account. Do not use a password that has
been used for any other account in the environment.
NOTE
Microsoft recommends using Local Administrator Password Solution (LAPS) to manage the local
Administrator password for all workstations, including PAWs. If you use LAPS, ensure that you only grant the
PAW Maintenance group the right to read LAPS-managed passwords for the PAWs.
c. Install Remote Server Administration Tools for Windows 10 using the clean source installation media.
d. Configure Windows Defender Exploit Guard
NOTE
Configuration guidance to follow
e. Connect the PAW to the network. Ensure that the PAW can connect to at least one Domain Controller
(DC ).
f. Using an account that is a member of the PAW Maintenance group, run the following PowerShell
command from the newly-created PAW to join it to the domain in the appropriate OU:
Add-Computer -DomainName Fabrikam -OUPath "OU=Devices,OU=Tier 0,OU=Admin,DC=fabrikam,DC=com"
Replace the references to Fabrikam with your domain name, as appropriate. If your domain name
extends to multiple levels (e.g. child.fabrikam.com), add the additional names with the "DC="
identifier in the order in which they appear in the domain's fully-qualified domain name.
NOTE
If you have deployed an ESAE Administrative Forest (for Tier 0 admins in Phase 1) or a Microsoft Identity
Manager (MIM) privileged access management (PAM) (for Tier 1 and 2 admins in Phase 2), you would join the
PAW to the domain in that environment here instead of the production domain.
g. Apply all critical and important Windows Updates before installing any other software (including
administrative tools, agents, etc.).
h. Force the Group Policy application.
a. Open an elevated command prompt and enter the following command:
Gpupdate /force /sync
b. Restart the computer

i. (Optional) Install additional required tools for Active Directory Admins. Install any other tools or
scripts required to perform job duties. Ensure to evaluate the risk of credential exposure on the target
computers with any tool before adding it to a PAW. Access this page to obtain more information on
evaluating administrative tools and connection methods for credential exposure risk. Ensure to obtain
all installation media using the guidance in Clean Source for installation media.
NOTE
Using a jump server for a central location for these tools can reduce complexity, even if it doesn't serve as a
security boundary.
j. (Optional) Download and install required remote access software. If administrators will be using the
PAW remotely for administration, install the remote access software using security guidance from
your remote access solution vendor. Ensure to obtain all installation media using the guidance in
Clean Source for installation media.
NOTE
Carefully consider all of the risks involved in allowing remote access via a PAW. While a mobile PAW enables
many important scenarios, including work from home, remote access software can potentially be vulnerable
to attack and used to compromise a PAW.
k. Validate the integrity of the PAW system by reviewing and confirming that all appropriate settings are
in place using the steps below:
a. Confirm that only the PAW -specific group policies are applied to the PAW
a. Open an elevated command prompt and enter the following command:
Gpresult /scope computer /r
b. Review the resulting list and ensure that the only group policies that appear are the
ones you created above.
b. Confirm that no additional user accounts are members of privileged groups on the PAW using
the steps below:
a. Open Edit Local Users and Groups (lusrmgr.msc), select Groups, and confirm that
the only members of the local Administrators group are the local Administrator account
and the PAW Maintenance global security group.
NOTE
The PAW Users group should not be a member of the local Administrators group. The only
members should be the local Administrator account and the PAW Maintenance global security
group (and PAW Users should not be a member of that global group either).
b. Also using Edit Local Users and Groups, ensure that the following groups have no
members:
Backup Operators
Hyper-V Administrators
Network Configuration Operators
Power Users
Remote Desktop Users
Replicators
l. (Optional) If your organization uses a security information and event management (SIEM ) solution,
ensure that the PAW is configured to forward events to the system using Windows Event Forwarding
(WEF ) or is otherwise registered with the solution so that the SIEM is actively receiving events and
information from the PAW. The details of this operation will vary based on your SIEM solution.
NOTE
If your SIEM requires an agent which runs as system or a local administrative account on the PAWs, ensure
that the SIEMs are managed with the same level of trust as your domain controllers and identity systems.
m. (Optional) If you chose to deploy LAPS to manage the password for the local Administrator account
on your PAW, verify that the password is registered successfully.
Using an account with permissions to read LAPS -managed passwords, open Active Directory
Users and Computers (dsa.msc). Ensure that Advanced Features is enabled, and then right-click
the appropriate computer object. Select the Attribute Editor tab and confirm that the value for
msSVSadmPwd is populated with a valid password.
Phase 2 - Extend PAW to All Administrators
Scope: All users with administrative rights over mission-critical applications and dependencies. This should include
at least administrators of application servers, operational health and security monitoring solutions, virtualization
solutions, storage systems, and network devices.
NOTE
The instructions in this phase assume that Phase 1 has been completed in its entirety. Do not begin Phase 2 until you have
completed all of the steps in Phase 1.
Once you confirm that all steps were done, perform the steps below to complete Phase 2:
1. (Recommended) Enable RestrictedAdmin mode - Enable this feature on your existing servers and
workstations, then enforce the use of this feature. This feature will require the target servers to be running
Windows Server 2008 R2 or later and target workstations to be running Windows 7 or later.
a. Enable RestrictedAdmin mode on your servers and workstations by following the instructions
available in this page.
NOTE
Before enabling this feature for internet facing servers, you should consider the risk of adversaries being able
to authenticate to these servers with a previously-stolen password hash.
b. Create "RestrictedAdmin Required - Computer" group policy object (GPO ). This section creates a
GPO which enforces the use of the /RestrictedAdmin switch for outgoing Remote Desktop
connections, protecting accounts from credential theft on the target systems
Go to Computer Configuration\Policies\Administrative Templates\System\Credentials
Delegation\Restrict delegation of credentials to remote servers and set to Enabled.
c. Link the RestrictedAdmin Required - Computer to the appropriate Tier 1 and/or Tier 2 Devices by
using the Policy options below:
PAW Configuration - Computer
-> Link Location: Admin\Tier 0\Devices (Existing)
PAW Configuration - User
-> Link Location: Admin\Tier 0\Accounts
RestrictedAdmin Required - Computer
->Admin\Tier1\Devices or -> Admin\Tier2\Devices (Both are optional)
NOTE
This is not necessary for Tier 0 systems as these systems are already in full control of all assets in the
environment.
2. Move Tier 1 Objects to the appropriate OUs.

a. Move Tier 1 groups To the Admin\Tier 1\Groups OU. Locate all groups that grant the following
administrative rights and move them to this OU.
Local administrator on more than one server
Administrative Access to cloud services
Administrative Access to enterprise applications
b. Move Tier 1 accounts to the Admin\Tier 1\Accounts OU. Move each account that is a member of
those Tier 1 groups (including nested membership) to this OU.
3. Add the appropriate members to the relevant groups
Tier 1 Admins - This group will contain the Tier 1 Admins that will be restricted from logging onto
Tier 2 hosts. Add all of your Tier 1 administrative groups that have administrative privileges over
servers or internet services.
NOTE
If administrative personnel have duties to manage assets at multiple tiers, you will need to create a separate
admin account per tier.
4. Enable Credential Guard to reduce risk of credential theft and reuse. Credential Guard is a new feature of
Windows 10 that restricts application access to credentials, preventing credential theft attacks (including
Pass-the-Hash). Credential Guard is completely transparent to the end user and requires minimal setup time
and effort. For further information on Credential Guard, including deployment steps and hardware
requirements, please refer to the article, Protect domain credentials with Credential Guard.
NOTE
Device Guard must be enabled in order to configure and use Credential Guard. However, you are not required to
configure any other Device Guard protections in order to use Credential Guard.
5. (Optional) Enable Connectivity to Cloud Services. This step allows management of cloud services like
Azure and Office 365 with appropriate security assurances. This step is also required for Microsoft Intune to
manage the PAWs.
NOTE
Skip this step if no cloud connectivity is required for administration of cloud services or management by Intune.
These steps will restrict communication over the internet to only authorized cloud services (but not the open
internet) and add protections to the browsers and other applications that will process content from the
internet. These PAWs for administration should never be used for standard user tasks like internet
communications and productivity.
To enable connectivity to PAW services follow the steps below:
a. Configure PAW to allow only authorized Internet destinations. As you extend your PAW deployment
to enable cloud administration, you need to allow access to authorized services while filtering out
access from the open internet where attacks can more easily be mounted against your admins.
a. Create Cloud Services Admins group and add all of the accounts to it that require access to
cloud services on the internet.
b. Download the PAW proxy.pac file from TechNet Gallery and publish it on an internal website.
NOTE
You will need to update the proxy.pac file after downloading to ensure that it is up-to-date and
complete.
Microsoft publishes all current Office 365 and Azure URLs in the Office Support Center.
You may need to add other valid Internet destinations to add to this list for other IaaS provider, but
do not add productivity, entertainment, news, or search sites to this list.
You may also need to adjust the PAC file to accommodate a valid proxy address to use for these
addresses.
NOTE
You can also restrict access from the PAW using a web proxy as well for defense in depth. We don't
recommend using this by itself without the PAC file as it will only restrict access for PAWs while
connected to the corporate network.
These instructions assume that you will be using Internet Explorer (or Microsoft Edge) for
administration of Office 365, Azure, and other cloud services. Microsoft recommends
configuring similar restrictions for any 3rd party browsers that you require for administration.
Web browsers on PAWs should only be used for administration of cloud services, and never
for general web browsing.
c. Once you have configured the proxy.pac file, update the PAW Configuration - User GPO.
a. Go to User Configuration\Preferences\Windows Settings\Registry. Right-click Registry,
select New > Registry Item and configure the following settings:
a. Action: Replace
b. Hive: HKEY_ CURRENT_USER
c. Key Path: Software\Microsoft\Windows\CurrentVersion\Internet Settings
d. Value name: AutoConfigUrl
NOTE
e. Value type: REG_SZ

f. Value data: enter the complete URL to the proxy.pac file, including http:// and the
file name - for example http://proxy.fabrikam.com/proxy.pac. The URL can also
be a single-label URL - for example, http://proxy/proxy.pac
NOTE
The PAC file can also be hosted on a file share, with the syntax of
file://server.fabrikan.com/share/proxy.pac but this requires allowing the file:// protocol.
See the "NOTE: File://-based Proxy Scripts Deprecated" section of this Understanding
Web Proxy Configuration blog for additional detail on configuring the required registry
value.
g. Click the Common tab and select Remove this item when it is no longer
applied.
h. On the Common tab select Item level targeting and click Targeting.
i. Click New Item and select security group.
j. Select the "..." button and browse for the Cloud Services Admins group.
k. Click New Item and select security group.
l. Select the "..." button and browse for the PAW Users group.
m. Click on the PAW Users item and click Item Options.
n. Select Is not.
o. Click OK on the targeting window.
p. Click OK to complete the AutoConfigUrl group policy setting.
b. Apply Windows 10 Security baselines and Cloud Service Access Link the security baselines for
Windows and for cloud service access (if required) to the correct OUs using the steps below:
a. Extract the contents of the Windows 10 Security Baselines ZIP file.
b. Create these GPOs, import the policy settings, and link per this table. Link each policy to each
location and ensure the order follows the table (lower entries in table should be applied later
and higher priority):
Policies:
CM Windows 10 - Domain Security N/A - Do Not Link Now
SCM Windows 10 TH2 - Computer Admin\Tier 0\Devices
Admin\Tier 1\Devices
SCM Windows 10 TH2- BitLocker Admin\Tier 0\Devices
SCM Windows 10 - Credential Guard Admin\Tier 0\Devices
SCM Internet Explorer - Computer Admin\Tier 0\Devices
PAW Configuration - Computer Admin\Tier 0\Devices (Existing)
Admin\Tier 1\Devices (New Link)
RestrictedAdmin Required - Computer Admin\Tier 0\Devices
SCM Windows 10 - User Admin\Tier 0\Devices
SCM Internet Explorer - User Admin\Tier 0\Devices
PAW Configuration - User Admin\Tier 0\Devices (Existing)

NOTE
The "SCM Windows 10 - Domain Security" GPO may be linked to the domain independently of PAW,
but will affect the entire domain.
6. (Optional) Install additional required tools for Tier 1 Admins. Install any other tools or scripts required to
perform job duties. Ensure to evaluate the risk of credential exposure on the target computers with any tool
before adding it to a PAW. For more information on evaluating administrative tools and connection methods
for credential exposure risk visit this page. Ensure to obtain all installation media using the guidance in
Clean Source for installation media
7. Identify and safely obtain software and applications required for administration. This is similar to the work
performed in Phase 1, but with a broader scope due to the increased number of applications, services, and
systems being secured.
NOTE
Ensure that you protect these new applications (including web browsers) by opting them into the protections
provided by Windows Defender Exploit Guard.
Examples of additional software and applications include:

Microsoft Azure PowerShell
Office 365 PowerShell (also known as Microsoft Online Services Module)
Application or service management software based on the Microsoft Management Console
Proprietary (non-MMC -based) application or service management software
NOTE
Many applications are now exclusively managed via web browsers, including many cloud services. While this
reduces the number of applications which need to be installed on a PAW, it also introduces the risk of browser
interoperability issues. You may need to deploy a non-Microsoft web browser onto specific PAW instances to
enable administration of specific services. If you do deploy an additional web browser, ensure that you follow
all clean source principles and secure the browser according to the vendor's security guidance.
8. (Optional) Download and install any required management agents.
NOTE
If you choose to install additional management agents (monitoring, security, configuration management, etc.), it is
vital that you ensure the management systems are trusted at the same level as domain controllers and identity
systems. See the Managing and Updating PAWs for additional guidance.
9. Assess your infrastructure to identify systems which require the additional security protections provided by
a PAW. Ensure that you know exactly which systems must be protected. Ask critical questions about the
resources themselves, such as:
Where are the target systems which must be managed? Are they collected in a single physical
location, or connected to a single well-defined subnet?
How many systems are there?
Do these systems depend on other systems (virtualization, storage, etc.), and if so, how are those
systems managed? How are the critical systems exposed to these dependencies, and what are the
additional risks associated with those dependencies?
How critical are the services being managed, and what is the expected loss if those services are
compromised?
NOTE
Include your cloud services in this assessment - attackers increasingly target insecure cloud deployments, and
it is vital that you administer those services as securely as you would your on-premises mission-critical
applications.
Use this assessment to identify the specific systems which require additional protection, and then
extend your PAW program to the administrators of those systems. Common examples of systems
which benefit greatly from PAW -based administration include SQL Server (both on-premises and
SQL Azure), human resources applications, and financial software.
NOTE
If a resource is managed from a Windows system, it can be managed with a PAW, even if the application itself
runs on an operating system other than Windows or on a non-Microsoft cloud platform. For example, the
owner of an Amazon Web Services subscription should only use a PAW to administer that account.
10. Develop a request and distribution method for deploying PAWs at scale in your organization. Depending on
the number of PAWs you choose to deploy in Phase 2, you may need to automate the process.
Consider developing a formal request and approval process for administrators to use to obtain a
PAW. This process would help standardize the deployment process, ensure accountability for PAW
devices, and help identify gaps in PAW deployment.
As stated previously, this deployment solution should be separate from existing automation methods
(which may have already been compromised) and should follow the principles outlined in Phase 1.
NOTE
Any system which manages resources should itself managed at the same or higher trust level.
11. Review and if necessary deploy additional PAW hardware profiles. The hardware profile you chose for Phase
1 deployment may not be suitable for all administrators. Review the hardware profiles and if appropriate
select additional PAW hardware profiles to match the needs of the administrators. For example, the
Dedicated Hardware profile (separate PAW and daily use workstations) may be unsuitable for an
administrator who travels often - in this case, you might choose to deploy the Simultaneous Use profile
(PAW with user VM ) for that administrator.
12. Consider the cultural, operational, communications, and training needs which accompany an extended PAW
deployment. Such a significant change to an administrative model will naturally require change
management to some degree, and it is essential to build that into the deployment project itself. Consider at a
minimum the following:
How will you communicate the changes to senior leadership to ensure their support? Any project
without senior leadership backing is likely to fail, or at the very least struggle for funding and broad
acceptance.
How will you document the new process for administrators? These changes must be documented
and communicated not only to existing administrators (who must change their habits and manage
resources in a different way), but also for new administrators (those promoted from within or hired
from outside the organization). It is essential that the documentation is clear and fully articulates the
importance of the threats, PAW's role in protecting the admins, and how to use PAW correctly.
NOTE
This is especially important for roles with high turnover, including but not limited to help desk personnel.
How will you ensure compliance with the new process? While the PAW model includes a number of
technical controls to prevent the exposure of privileged credentials, it is impossible to fully prevent all
possible exposure purely using technical controls. For example, although it is possible to prevent an
administrator from successfully logging onto a user desktop with privileged credentials, the simple
act of attempting the logon can expose the credentials to malware installed on that user desktop. It is
therefore essential that you articulate not only the benefits of the PAW model, but the risks of non-
compliance. This should be complemented by auditing and alerting so that credential exposure can
be quickly detected and addressed.
Phase 3: Extend and Enhance Protection
Scope: These protections enhance the systems built in Phase 1, bolstering the basic protection with advanced
features including multi-factor authentication and network access rules.
NOTE
This phase can be performed at any time after Phase 1 has been completed. It is not dependent on completion of Phase 2,
and thus can be performed before, concurrent with, or after Phase 2.
Follow the steps below to configure this phase:

1. Enable multi-factor authentication for privileged accounts. Multi-factor authentication strengthens account
security by requiring the user to provide a physical token in addition to credentials. Multi-factor
authentication complements authentication policies extremely well, but it does not depend on authentication
policies for deployment (and, similarly, authentication policies do not require multi-factor authentication).
Microsoft recommends using one of these forms of multi-factor authentication:
Smart card: A smart card is a tamper-resistant and portable physical device which provides a second
verification during the Windows logon process. By requiring an individual to possess a card for
logon, you can reduce the risk of stolen credentials being reused remotely. For details on smart card
logon in Windows, please refer to the article Smart Card Overview.
Virtual smart card: A virtual smart card provides the same security benefits as physical smart cards,
with the added benefit of being linked to specific hardware. For details on deployment and hardware
requirements, please refer to the articles, Virtual Smart Card Overview and Get Started with Virtual
Smart Cards: Walkthrough Guide.
Windows Hello for Business: Windows Hello for Business lets users authenticate to a Microsoft
account, an Active Directory account, a Microsoft Azure Active Directory (Azure AD ) account, or non-
Microsoft service that supports Fast ID Online (FIDO ) authentication. After an initial two-step
verification during Windows Hello for Business enrollment, a Windows Hello for Business is set up
on the user's device and the user sets a gesture, which can be Windows Hello or a PIN. Windows
Hello for Business credentials are an asymmetric key pair, which can be generated within isolated
environments of Trusted Platform Modules (TPMs). For more information on Windows Hello for
Business read Windows Hello for Business article.
Azure multi-factor authentication: Azure multi-factor authentication (MFA) provides the security
of a second verification factor as well as enhanced protection through monitoring and machine-
learning-based analysis. Azure MFA can secure not only Azure administrators but many other
solutions as well, including web applications, Azure Active Directory, and on-premises solutions like
remote access and Remote Desktop. For more information on Azure multi-factor authentication,
please refer to the article Multi-Factor Authentication.
2. Whitelist trusted applications using Windows Defender Application Control and/or AppLocker. By
limiting the ability of untrusted or unsigned code to run on a PAW, you further reduce the likelihood of
malicious activity and compromise. Windows includes two primary options for application control:
AppLocker: AppLocker helps administrators control which applications can run on a given system.
AppLocker can be centrally controlled through group policy, and applied to specific users or groups
(for targeted application to users of PAWs). For more information on AppLocker, please refer to the
TechNet article AppLocker Overview.
Windows Defender Application Control: the new Windows Defender Application Control feature
provides enhanced hardware-based application control which, unlike AppLocker, cannot be
overridden on the impacted device. Like AppLocker, Windows Defender Application Control can be
controlled via group policy and targeted to specific users. For more information on restricting
application usage with Windows Defender Application Control, please refer to Windows Defender
Application Control Deployment Guide.
3. Use Protected Users, Authentication Policies, and Authentication Silos to further protect
privileged accounts. The members of Protected Users are subject to additional security policies which
protect the credentials stored in the local security agent (LSA) and greatly minimize the risk of credential
theft and reuse. Authentication policies and silos control how privileged users can access resources in the
domain. Collectively, these protections dramatically strengthen the account security of these privileged
users. For additional details on these features, please refer to the web article How to Configure Protected
Accounts.
NOTE
These protections are meant to complement, not replace, existing security measures in Phase 1. Administrators
should still use separate accounts for administration and general use.
Managing and Updating PAWs

PAWs must have anti-malware capabilities and software updates must be rapidly applied to maintain integrity of
these workstations.
Additional configuration management, operational monitoring, and security management can also be used with
PAWs, but the integration of these must be considered carefully because each management capability also
introduces risk of PAW compromise through that tool. Whether it makes sense to introduce advanced
management capabilities depends on a number of factors including:
The security state and practices of the management capability (including software update practices for the
tool, administrative roles and accounts in those roles, operating systems the tool is hosted on or managed
from, and any other hardware or software dependencies of that tool)
The frequency and quantity of software deployments and updates on your PAWs
Requirements for detailed inventory and configuration information
Security monitoring requirements
Organizational standards and other organizational-specific factors
Per the clean source principle, all tools used to manage or monitor the PAWs must be trusted at or above the level
of the PAWs. This typically requires those tools to be managed from a PAW to ensure no security dependency from
lower privilege workstations.
This table outlines different approaches that may be used to manage and monitor the PAWs:
APPROACH CONSIDERATIONS
Default in PAW - No additional cost

- Performs basic required security functions
- Windows Server Update Services - Instructions included in this guidance
- Windows Defender
Manage with Intune Provides cloud based visibility and control
Software Deployment
o Manage software updates
Windows Firewall policy management
Anti-malware protection
Remote assistance
Software license management.
No server infrastructure required
Requires following "Enable Connectivity to Cloud
Services" steps in Phase 2
If the PAW computer is not joined to a domain, this
requires applying the SCM baselines to the local
images using the tools provided in the security
baseline download.
New System Center instance(s) for managing PAWs - Provides visibility and control of configuration, software
deployment, and security updates
- Requires separate server infrastructure, securing it to level of
PAWs, and staffing skills for those highly privileged personnel
Manage PAWs with existing management tool(s) - Creates significant risk to compromise of PAWs unless the
existing management infrastructure is brought up to security
level of PAWs Note: Microsoft would generally discourage this
approach unless your organization has a specific reason to use
it. In our experience, there is typically a very high cost of
bringing all of these tools (and their security dependencies) up
to the security level of the PAWs.
- Most of these tools provide visibility and control of
configuration, software deployment, and security updates
APPROACH CONSIDERATIONS
Security Scanning or monitoring tools requiring admin access Includes any tool that installs an agent or requires an account
with local administrative access.
- Requires bringing tool security assurance up to level of

PAWs.
- May require lowering security posture of PAWs to support
tool functionality (open ports, install Java or other middleware,
etc.), creating a security trade-off decision,
Security information and event management (SIEM) If SIEM is agentless
Can access events on PAWs without

administrative access by using an account in
the Event Log Readers group
Will require opening up network ports to allow
inbound traffic from the SIEM servers
If SIEM requires an agent, see other row Security
Scanning or monitoring tools requiring admin
access.
Windows Event Forwarding - Provides an agentless method of forwarding security events

from the PAWs to an external collector or SIEM
- Can access events on PAWs without administrative access
- Does not require opening up network ports to allow
inbound traffic from the SIEM servers
Operating PAWs
The PAW solution should be operated using the standards in Operational Standards based on Clean Source
Principle.
Related Topics
Engaging Microsoft Cybersecurity Services
Taste of Premier: How to Mitigate Pass-the-Hash and Other Forms of Credential Theft
Microsoft Advanced Threat Analytics
Protect derived domain credentials with Credential Guard
Device Guard Overview
Protecting high-value assets with secure admin workstations
Isolated User Mode in Windows 10 with Dave Probert (Channel 9)
Isolated User Mode Processes and Features in Windows 10 with Logan Gabriel (Channel 9)
More on Processes and Features in Windows 10 Isolated User Mode with Dave Probert (Channel 9)
Mitigating Credential Theft using the Windows 10 Isolated User Mode (Channel 9)
Enabling Strict KDC Validation in Windows Kerberos
What's New in Kerberos Authentication for Windows Server 2012
Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide
Trusted Platform Module
Securing Privileged Access Reference Material
This section contains reference information for Securing Privileged Access including:
Active Directory administrative tier model
Clean source principle
ESAE Administrative Forest Design Approach
Tier 0 Equivalency
Administrative Tools and Logon Types
Active Directory administrative tier model

The purpose of this tier model is to protect identity systems using a set of buffer zones between full control of the
Environment (Tier 0) and the high risk workstation assets that attackers frequently compromise.
The Tier model is composed of three levels and only includes administrative accounts, not standard user accounts:
Tier 0 - Direct Control of enterprise identities in the environment. Tier 0 includes accounts, groups, and
other assets that have direct or indirect administrative control of the Active Directory forest, domains, or
domain controllers, and all the assets in it. The security sensitivity of all Tier 0 assets is equivalent as they
are all effectively in control of each other.
Tier 1 - Control of enterprise servers and applications. Tier 1 assets include server operating systems,
cloud services, and enterprise applications. Tier 1 administrator accounts have administrative control of a
significant amount of business value that is hosted on these assets. A common example role is server
administrators who maintain these operating systems with the ability to impact all enterprise services.
Tier 2 - Control of user workstations and devices. Tier 2 administrator accounts have administrative control
of a significant amount of business value that is hosted on user workstations and devices. Examples include
Help Desk and computer support administrators because they can impact the integrity of almost any user
data.
NOTE
The tiers also serve as a basic prioritization mechanism for protecting administrative assets, but it is important to consider
that an attacker with control of all assets at any tier can access most or all business assets. The reason it is useful as a basic
prioritization mechanism is attacker difficulty/cost. It is easier for an attacker to operate with full control of all identities (Tier
0) or servers and cloud services (Tier 1) than it is if they must access each individual workstation or user device (Tier 2) to get
your organization's data.
Containment and security zones

The tiers are relative to a specific security zone. While they have gone by many names, security zones are a well-
established approach that provide containment of security threats through network layer isolation between them.
The tier model complements the isolation by providing containment of adversaries within a security zone where
network isolation isn't effective. Security zones can span both on-premises and cloud infrastructure, such as in the
example where Domain Controllers and domain members in the same domain are hosted on-premises and in
Azure.
The Tier model prevents escalation of privilege by restricting what administrators can control and where they can
log on (because logging on to a computer grants control of those credentials and all assets managed by those
credentials).
Control restrictions
Control restrictions are shown in the figure below:
Primary responsibilities and critical restrictions

Tier 0 administrator - manage the identity store and a small number of systems that are in effective control of it,
and:
Can manage and control assets at any level as required
Can only log on interactively or access assets trusted at the Tier 0 level
Tier 1 administrator - manage enterprise servers, services, and applications, and:
Can only manage and control assets at the Tier 1 or Tier 2 level
Can only access assets (via network logon type) that are trusted at the Tier 1 or Tier 0 levels
Can only interactively log on to assets trusted at the Tier 1 level
Tier 2 administrator - manage enterprise desktops, laptops, printers, and other user devices, and:
Can only manage and control assets at the Tier 2 level
Can access assets (via network logon type) at any level as required
Can only interactively log on to assets trusted at Tier 2 level
Logon restrictions
Logon restrictions are shown in the figure below:
NOTE
Note that some assets can have Tier 0 impact to availability of the environment, but do not directly impact the
confidentiality or integrity of the assets. These include the DNS Server service and critical network devices like Internet
proxies.
Clean source principle

The clean source principle requires all security dependencies to be as trustworthy as the object being secured.
Any subject in control of an object is a security dependency of that object. If an adversary can control anything in
effective control of a target object, they can control that target object. Because of this, you must ensure that the
assurances for all security dependencies are at or above the desired security level of the object itself.
While simple in principle, applying this requires understanding the control relationships of an asset of interest
(Object) and performing a dependency analysis of it to discover all security dependencies (Subject(s)).
Because control is transitive, this principle has to be repeated recursively. For example if A controls B and B
controls C, then A also indirectly controls C.
An attacker that compromises A gets access to everything A controls (including B ), and everything B controls
(including C ). Using the language of security dependencies on this same example, both B and A are security
dependencies of C and have to be secured at the desired assurance level of C in order for C to have that assurance
level.
For IT infrastructure and identity systems, this principle should be applied to the most common means of control
including the hardware where systems are installed, the installation media for the systems, the architecture and
configuration of the system, and daily operations.
Clean Source for installation media
Applying the clean source principle to installation media requires you to ensure that the installation media has not
been tampered with since being released by the manufacturer (as best you are able to determine). This figure
depicts an attacker using this path to compromise a computer:
Applying the clean source principle to installation media requires validating the software integrity throughout the
cycle you possess it including during acquisition, storage, and transfer up until it is used.
Software acquisition
The source of the software should be validated through one of the following means:
Software is obtained from physical media that is known to come from the manufacturer or a reputable
source, typically manufactured media shipped from a vendor.
Software is obtained from the Internet and validated with vendor-provided file hashes.
Software is obtained from the Internet and validated by downloading and comparing two independent
copies:
Download to two hosts with no security relationship (not in the same domain and not managed by
the same tools), preferably from separate Internet connections.
Compare the downloaded files using a utility like certutil:
certutil -hashfile <filename>
When possible, all application software, such as application installers and tools should be digitally signed and
verified using Windows Authenticode with the Windows Sysinternals tool, sigcheck.exe, with revocation checking.
Some software may be required where the vendor may not provide this type of digital signature.
Software storage and transfer
After obtaining the software, it should be stored in a location that is protected from modification, especially by
internet-connected hosts or personnel trusted at a lower level than the systems where the software or operating
system will be installed. This storage can be physical media or a secure electronic location.
Software usage
Ideally, the software should be validated at the time it is used, such as when it is manually installed, packaged for a
configuration management tool, or imported into a configuration management tool.
Clean source for architecture and design
Applying the clean source principle to the system architecture requires you to ensure that the system is not
dependent on lower trust systems. A system can be dependent on a higher trust system, but not on a lower trust
system with lower security standards.
As an example, its acceptable for Active Directory to control a standard user desktop but it's a significant
escalation of privilege risk for a standard user desktop to be in control of the Active Directory.
The control relationship can be introduced through many means including security Access Control Lists (ACLs) on
objects like filesystems, membership in the local administrators group on a computer, or agents installed on a
computer running as System (with the ability to run arbitrary code and scripts).
A frequently overlooked example is exposure through logon, which creates a control relationship by exposing
administrative credentials of a system to another system. This is the underlying reason why credential theft attacks
like pass the hash are so powerful. When an administrator logs in to a standard user desktop with Tier 0
credentials, they are exposing those credentials to that desktop, putting it in control of AD, and creating an
escalation of privilege path to AD. For more information on these attacks, see this page.
Because of the large number of assets that depend on identity systems like Active Directory, you should minimize
the number of systems your Active Directory and Domain Controllers depend on.
For more information on hardening the top risks of active directory, see this page.
Operational standards based on clean source principle
This section describes the operational standards and expectations for administrative personnel. These standards
are designed to secure administrative control of an organization's information technology systems against risks
that could be created by operational practices and processes.
Integrating the standards

You can integrate these standards into your organization's overall standards and practices. You can adapt these to
the specific requirements, available tools, and risk appetite of your organization, but we recommend only
minimum modifications to reduce risk. We recommend you use the defaults in this guidance as the benchmark for
your ideal end state and manage any deltas as exceptions to be addressed in priority order.
The standards guidance is organized into these sections:
Assumptions
Change Advisory Board
Operational Practices
Summary
Standards Details
Assumptions
The standards in this section assume that the organization has the following attributes:
Most or all servers and workstations in scope are joined to Active Directory.
All servers to be managed are running Windows Server 2008 R2 or later and have RDP RestrictedAdmin
mode enabled.
All workstations to be managed are running Windows 7 or later and have RDP RestrictedAdmin mode
enabled.
NOTE
To enable RDP RestrictedAdmin mode, see this page.
Smart cards are available and issued to all administrative accounts.

The Builtin\Administrator for each domain has been designated as an emergency access account
An enterprise identity management solution is deployed.
LAPS has been deployed to servers and workstations to manage the local administrator account password
There is a privileged access management solution, such as Microsoft Identity Manager, in place, or there is
a plan to adopt one.
Personnel are assigned to monitor security alerts and respond to them.
The technical capability to rapidly apply Microsoft security updates is available.
Baseboard management controllers on servers will not be used, or will adhere to strict security controls.
Administrator accounts and groups for servers (Tier 1 admins) and workstations (Tier 2 admins) will be
managed by domain admins (Tier 0).
There is a Change Advisory Board (CAB ) or another designated authority in place for approving Active
Directory changes.
Change advisory board
A Change Advisory Board (CAB ) is the discussion forum and approval authority for changes that could impact the
security profile of the organization. Any exceptions to these standards should be submitted to the CAB with a risk
assessment and justification.
Each standard in this document is broken out by the criticality of meeting the standard for a given Tier level.
All exceptions for Mandatory items (marked with red octagon or an orange triangle in this document) are
considered temporary, and they need to be approved by the CAB. Guidelines include:
The initial request requires justification risk acceptance signed by personnel's immediate supervisor, and it
expires after six months.
Renewals require justification and risk acceptance signed by a business unit director, and they expire after
six months.
All exceptions for Recommended items (marked with a yellow circle in this document) are considered temporary,
and need to be approved by the CAB. Guidelines include:
The initial request requires justification risk acceptance signed by personnel's immediate supervisor, and it
expires after 12 months.
Renewals require justification and risk acceptance signed by a business unit director, and they expire after
12 months.
Operational practices standards summary
The Tier columns in this table refer to the Tier level of the administrative account, the control of which typically
impacts all assets in that tier.
Operational decisions that are made on a regular basis are critical to maintaining the security posture of the
environment. These standards for processes and practices help ensure that an operational error does not lead to
an exploitable operational vulnerability in the environment.
A d m i n i st r a t o r e n a b l e m e n t a n d a c c o u n t a b i l i t y
Administrators must be informed, empowered, trained, and held accountable to operate the environment as
securely as possible.
A d mi n i s t ra t i v e p e rs o n n e l s t a n d a rd s
Assigned administrative personnel must be vetted to ensure they are trustworthy and have a need for
administrative privileges:
Perform background checks on personnel prior to assigning administrative privileges.
Review administrative privileges each quarter to determine which personnel still have a legitimate business
need for administrative access.
A d mi n i s t ra t i v e s e c u ri t y b ri e f i n g a n d a c c o u n t a b i l i t y
Administrators must be informed and accountable for the risks to the organization and their role in managing that
risk. Administrators should be trained yearly on:
General threat environment
Determined adversaries
Attack techniques including pass-the-hash and credential theft
Organization-specific threats and incidents
Administrator's roles in protecting against attacks
Managing credential exposure with the Tier model
Use of administrative workstations
Use of Remote Desktop Protocol RestrictedAdmin mode
Organization-specific administrative practices
Review all operational guidelines in this standard
Implement the following key rules:
Do not use administrative accounts on anything but administrative workstations
Do not disable or dismantle security controls on your account or workstations (for example,
logon restrictions or attributes required for smart cards)
Report issues or unusual activity
To provide accountability, all personnel with administrative accounts should sign an Administrative Privilege Code
of Conduct document that says they intend to follow organization-specific administrative policy practices.
P ro v i s i o n i n g a n d d e p ro v i s i o n i n g p ro c e s s e s f o r a d mi n i s t ra t i v e a c c o u n t s
The following standards must be met for meeting lifecycle requirements.

All administrative accounts must be approved by the Approving Authority outlined in the following table.
Approval must only be granted if the personnel have a legitimate business need for administrative
privileges.
Approval for administrative privileges should not exceed six months.
Access to administrative privileges must be immediately deprovisioned when:
Personnel change positions.
Personnel leave the organization.
Accounts must be immediately disabled following personnel leaving the organization.
Disabled accounts must be deleted within six months and the record of their deletion must be entered into
change approval board records.
Review all privileged account memberships monthly to ensure that no unauthorized permissions have been
granted. This can be replaced by an automated tool that alerts changes.
ACCOUNT PRIVILEGE LEVEL APPROVING AUTHORITY MEMBERSHIP REVIEW FREQUENCY
Tier 0 Administrator Change approval board Monthly or automated
Tier 1 Administrator Tier 0 administrators or security Monthly or automated
Tier 2 Administrator Tier 0 administrators or security Monthly or automated
O p e r a t i o n a l i z e l e a st p r i v i l e g e
These standards help achieve least privilege by reducing the number of administrators in role and the amount of
time that they have privileges.
NOTE
Achieving least privilege in your organization will require understanding the organizational roles, their requirements, and
their designing mechanisms to ensure that they are able to accomplish their job by using least privilege. Achieving a state of
least privilege in an administrative model frequently requires the use of multiple approaches:
Limit the count of administrators or members of privileged groups
Delegate fewer privileges to accounts
Provide time-bound privileges on demand
Provide ability for other personnel to perform tasks (a concierge approach)
Provide processes for emergency access and rare-use scenarios
L i mi t c o u n t o f a d mi n i s t ra t o rs
A minimum of two qualified personnel should be assigned to each administrative role to ensure business
continuity.
If the number of personnel assigned to any role exceeds two, the change approval board must approve the specific
reasons for assigning privileges to each individual member (including the original two). The justification for the
approval must include:
What technical tasks are performed by the administrators that require the administrative privileges
How often are the tasks performed
Specific reason why the tasks cannot be performed by another administrator on their behalf
Document all other known alternative approaches to granting the privilege and why each isn't acceptable
Dy n a mi c a l l y a s s i g n p ri v i l e g e s
Administrators are required to obtain permissions "just-in-time" to use them as they perform tasks. No
permissions will be permanently assigned to administrative accounts.
NOTE
Permanently assigned administrative privileges naturally create a "most privilege" strategy because administrative personnel
require rapid access to permissions to maintain operational availability if there is an issue. Just-in-time permissions provide
the ability to:
Assign permissions more granularly, getting closer to least privilege.
Reduce the exposure time of privileges
Tracking permissions use to detect abuse or attacks.
M a n a g e R i sk o f C r e d e n t i a l Ex p o su r e
Use the following practices to proper manage risk of credential exposure.

Se p a ra t e a d mi n i s t ra t i v e a c c o u n t s
All personnel that are authorized to possess administrative privileges must have separate accounts for
administrative functions that are distinct from user accounts.
Standard user accounts - Granted standard user privileges for standard user tasks, such as email, web
browsing, and using line-of-business applications. These accounts should not be granted administrative
privileges.
Administrative accounts - Separate accounts created for personnel who are assigned the appropriate
administrative privileges. An administrator who is required to manage assets in each Tier should have a
separate account for each Tier. These accounts should have no access to email or the public Internet.
A d mi n i s t ra t o r l o g o n p ra c t i c e s
Before an administrator can log on to a host interactively (locally over standard RDP, by using RunAs, or by using
the virtualization console), that host must meet or exceed the standard for the admin account Tier (or a higher
Tier).
Administrators can only sign in to admin workstations with their administrative accounts. Administrators only log
on to managed resources by using the approved support technology described in the next section.
NOTE
This is required because logging onto a host interactively grants control of the credentials to that host.
See the Administrative Tools and Logon Types for details about logon types, common management tools, and credential
exposure.
Us e o f a p p ro v e d s u p p o rt t e c h n o l o g y a n d me t h o d s
Administrators who support remote systems and users must follow these guidelines to prevent an adversary in
control of the remote computer from stealing their administrative credentials.
The primary support options should be used if they are available.
The secondary support options should only be used if the primary support option is not available.
Forbidden support methods may never be used.
No internet browsing or email access may be performed by any administrative account at any time.
Ti e r 0 f o re s t , d o ma i n , a n d DC a d mi n i s t ra t i o n
Ensure that the following practices are applied for this scenario:
Remote server support - When remotely accessing a server, Tier 0 administrators must follow these
guidelines:
Primary (tool) - Remote tools that use network logons (type 3). For more information, see
Administrative Tools and Logon Types.
Primary (interactive) - Use RDP RestrictedAdmin or a Standard RDP Session from an admin
workstation with a domain account
NOTE
If you have a Tier 0 privilege management solution, add "that uses permissions obtained just-in-time from a
privileged access management solution."
Physical server support - When physically present at a server console or at a virtual machine console
(Hyper-V or VMWare tools), these accounts have no specific administrative tool usage restrictions, only the
general restrictions from standard user tasks like email and browsing the open internet.
NOTE
Tier 0 administration is different from administration of other tiers because all Tier 0 assets already have direct or
indirect control of all assets. As an example, an attacker in control of a DC has no need to steal credentials from
logged on administrators as they already have access to all domain credentials in the database.
Ti e r 1 s e rv e r a n d e n t e rp ri s e a p p l i c a t i o n s u p p o rt
Ensure that the following practices are applied for this scenario:
Remote server support - When remotely accessing a server, Tier 1 administrators must follow these
guidelines:
Primary (tool) - Remote tools that use network logons (type 3). For more information, see
Mitigating Pass-the-Hash and Other Credential Theft v1 (pp 42-47).
Primary (interactive) - Use RDP RestrictedAdmin from an admin workstation with a domain
account that uses permissions obtained just-in-time from a privileged access management solution.
Secondary - Log on to the server by using a local account password that is set by LAPS from an
admin workstation.
Forbidden - Standard RDP may not be used with a domain account.
Forbidden - Using the domain account credentials while in the session (for example, using RunAs or
authenticating to a share). This exposes the logon credentials to the risk of theft.
Physical server support - When physically present at a server console or at a virtual machine console
(Hyper-V or VMWare tools), Tier 1 administrators must retrieve the local account password from LAPS
prior to accessing the server.
Primary - Retrieve the local account password set by LAPS from an admin workstation before
logging on to the server.
Forbidden - Logging on with a domain account is not allowed in this scenario.
Forbidden - Using the domain account credentials while in the session (for example, RunAs or
authenticating to a share). This exposes the logon credentials to the risk of theft.
Ti e r 2 h e l p d e s k a n d u s e r s u p p o rt
Help Desk and user support organizations perform support for end users (which doesn't require administrative
privileges) and the user workstations (which does require administrative privileges).
User support - Tasks include assisting users with performing tasks that require no modification to the
workstation, frequently showing them how to use an application feature or operating system feature.
Desk-side user support - The Tier 2 support personnel is physically at the user's workspace.
Primary - "Over the shoulder" support can be provided with no tools.
Forbidden - Logging on with domain account administrative credentials is not allowed in this
scenario. Switch to desk-side workstation support if administrative privileges are required.
Remote user support - The Tier 2 support personnel is physically remote to the user.
Primary - Remote Assistance, Skype for Business, or similar user-screen sharing may be used. For
more information, see What is Windows Remote Assistance?
scenario. Switch to workstation support if administrative privileges are required.
Workstation support - Tasks include performing workstation maintenance or troubleshooting that
requires access to a system for viewing logs, installing software, updating drivers, and so on.
Desk-side workstation support - The Tier 2 support personnel is physically at the user's
workstation.
Primary - Retrieve the local account password set by LAPS from an admin workstation
before connecting to user workstation.
scenario.
Remote workstation support - The Tier 2 support personnel is physically remote to the
workstation.
Primary - Use RDP RestrictedAdmin from an admin workstation with a domain account that
uses permissions obtained just-in-time from a privileged access management solution.
Secondary - Retrieve a local account password set by LAPS from an admin workstation
before connecting to user workstation.
Forbidden - Use standard RDP with a domain account.
N o b ro w s i n g t h e p u b l i c I n t e rn e t w i t h a d mi n a c c o u n t s o r f ro m a d mi n w o rk s t a t i o n s
Administrative personnel cannot browse the open Internet while logged on with an administrative account or
while logged on to an administrative workstation. The only authorized exceptions are the use of a web browser to
administer a cloud-based service, such as Microsoft Azure, Amazon Web Services, Microsoft Office 365, or
enterprise Gmail.
N o a c c e s s i n g e ma i l w i t h a d mi n a c c o u n t s o r f ro m a d mi n w o rk s t a t i o n s
Administrative personnel cannot access email while logged on with an administrative account or while logged on
to an administrative workstation.
St o re s e rv i c e a n d a p p l i c a t i o n a c c o u n t p a s s w o rd s i n a s e c u re l o c a t i o n
The following guidelines should be used for the physical security processes that control access to the password:
Lock the service account passwords in a physical safe.
Ensure that only personnel trusted at or above the Tier classification of the account have access to the
account password.
Limit the number of people who access to the passwords to a minimum number to for accountability.
Ensure that all access to the password is logged, tracked, and monitored by a disinterested party, such as a
manager who is not trained to perform IT administration.
St r o n g A u t h e n t i c a t i o n
Use the following practices to proper configure strong authentication.

E n f o rc e s ma rt c a rd mu l t i -f a c t o r a u t h e n t i c a t i o n ( M F A ) f o r a l l a d mi n a c c o u n t s
No administrative account is allowed to use a password for authentication. The only authorized exceptions are the
emergency access accounts that are protected by the appropriate processes.
Link all administrative accounts to a smart card and enable the attribute "Smart Card Required for Interactive
Logon."
A script should be implemented to automatically and periodically reset the random password hash value by
disabling and immediately re-enabling the attribute "Smart Card Required for Interactive Logon."
Allow no exceptions for accounts used by human personnel beyond the emergency access accounts.
E n f o rc e M u l t i -F a c t o r A u t h e n t i c a t i o n f o r A l l C l o u d A d mi n A c c o u n t s
All accounts with administrative privileges in a cloud service, such as Microsoft Azure and Office 365, must use
multi-factor authentication.
R a r e U se e m e r g e n c y p r o c e d u r e s
Operational practices must support the following standards:

Ensure outages can be resolved quickly.
Ensure rare high-privilege tasks can be completed as needed.
Ensure safe procedures are used to protect the credentials and privileges.
Ensure appropriate tracking and approval processes are followed.
C o rre c t l y f o l l o w a p p ro p ri a t e p ro c e s s e s f o r a l l e me rg e n c y a c c e s s a c c o u n t s
Ensure that each emergency access account has a tracking sheet in the safe.
The procedure documented on the password tracking sheet should be followed for each account, which includes
changing the password after each use and logging out of any workstations or servers used after completion.
All use of emergency access accounts should be approved by the change approval board in advanced or after-the-
fact as an approved emergency usage.
R e s t ri c t a n d mo n i t o r u s a g e o f e me rg e n c y a c c e s s a c c o u n t s
For all use of emergency access accounts:

Only authorized domain admins can access the emergency access accounts with domain admin privileges.
The emergency access accounts can be used only on domain controllers and other Tier 0 hosts.
This account should be used only to:
Perform troubleshooting and correction of technical issues that are preventing the use of the correct
administrative accounts.
Perform rare tasks, such as:
Schema administration
Forest-wide tasks that require enterprise administrative privileges Note that topology
management including Active Directory site and subnet management is delegated to limit the
use of these privileges.
All usage of one of these accounts should have written authorization by the security group lead
The procedure on the tracking sheet for each emergency access account requires the password to be
changed for each use. A security team member should validate that this happened correctly.
Te mp o ra ri l y a s s i g n e n t e rp ri s e a d mi n a n d s c h e ma a d mi n me mb e rs h i p
Privileges should be added as needed and removed after use. The emergency account should have these
privileges assigned for only the duration of the task to be completed, and for a maximum of 10 hours. All usage
and duration of these privileges should be captured in the change approval board record after the task is
completed.
ESAE Administrative Forest Design Approach

This section contains an approach for an administrative forest based on the Enhanced Security Administrative
Environment (ESAE ) reference architecture deployed by Microsoft's cybersecurity professional services teams to
protect customers against cybersecurity attacks.
Dedicated administrative forests allow organizations to host administrative accounts, workstations, and groups in
an environment that has stronger security controls than the production environment.
This architecture enables a number of security controls that aren't possible or easily configured in a single forest
architecture, even one managed with Privileged Access Workstations (PAWs). This approach allows the
provisioning of accounts as standard non-privileged users in the administrative forest that are highly privileged in
the production environment, enabling greater technical enforcement of governance. This architecture also enables
the use of the selective authentication feature of a trust as a means to restrict logons (and credential exposure) to
only authorized hosts. In situations in which a greater level of assurance is desired for the production forest
without incurring the cost and complexity of a complete rebuild, an administrative forest can provide an
environment that increases the assurance level of the production environment.
While this approach does add a forest to an Active Directory environment, the cost and complexity are limited by
the fixed design, small hardware/software footprint, and small number of users.
NOTE
This approach works well for administering Active Directory, but many applications aren't compatible with being
administered by accounts from an external forest using a standard trust.
This figure depicts an ESAE forest used for administration of Tier 0 Assets and a PRIV forest configured for use
with Microsoft Identity Manager's Privileged Access Management capability. For more information on deploying
a MIM PAM instance, see Privileged Identity Management for Active Directory Domain Services (AD DS ) article.
A dedicated administrative forest is a standard single domain Active Directory forest dedicated to the function of
Active Directory management. Administrative forests and domains may be hardened more stringently than
production forests because of the limited use cases.
An administrative forest design should include the following considerations:
Limited scope - The primary value of an admin forest is the high level of security assurance and reduced
attack surface resulting in lower residual risk. The forest can be used to house additional management
functions and applications, but each increase in scope will increase the attack surface of the forest and its
resources. The objective is to limit the functions of the forest and admin users inside to keep the attack
surface minimal, so each scope increase should be considered carefully.
Trust configurations - Configure trust from managed forests(s) or domain(s) to the administrative forest
A one-way trust is required from production environment to the admin forest. This can be a domain
trust or a forest trust. The admin forest/domain does not need to trust the managed domains/forests
to manage Active Directory, though additional applications may require a two-way trust relationship,
security validation, and testing.
Selective authentication should be used to restrict accounts in the admin forest to only logging on to
the appropriate production hosts. For maintaining domain controllers and delegating rights in Active
Directory, this typically requires granting the "Allowed to logon" right for domain controllers to
designated Tier 0 admin accounts in the admin forest. See Configuring Selective Authentication
Settings for more information.
Privileges and domain hardening - The administrative forest should be configured to least privilege
based on the requirements for Active Directory administration.
Granting rights to administer domain controllers and delegate permissions requires adding admin
forest accounts to the BUILTIN\Administrators domain local group. This is because the Domain
Admins global group cannot have members from an external domain.
One caveat to using this group to grant rights is that they won't have administrative access to new
group policy objects by default. This can be changed by following the procedure in this knowledge
base article to change the schema default permissions.
Accounts in the admin forest that are used to administer the production environment should not be
granted administrative privileges to the admin forest, domains in it, or workstations in it.
Administrative privileges over the admin forest should be tightly controlled by an offline process to
reduce the opportunity for an attacker or malicious insider to erase audit logs. This also helps ensure
that personnel with production admin accounts cannot relax the restrictions on their accounts and
increase risk to the organization.
The administrative forest should follow the Microsoft Security Compliance Baseline (SCB )
configurations for the domain, including strong configurations for authentication protocols.
All admin forest hosts should be automatically updated with security updates. While this may create
risk of interrupting domain controller maintenance operations, it provides a significant mitigation of
security risk of unpatched vulnerabilities.
NOTE
A dedicated Windows Server Update Services instance can be configured to automatically approve updates.
For more information, see the "Automatically Approve Updates for Installation" section in Approving
Updates.
Workstation Hardening - Build the administrative workstations using the Privileged Access Workstations
(through Phase 3), but change the domain membership to the administrative forest instead of the
production environment.
Server and DC hardening - For all domain controllers and servers in the administrative forest:
Ensure all media is validated using the guidance in Clean Source for installation media
Ensure the administrative forest servers should have the latest operating systems installed, even if
this is not feasible in production.
Admin forest hosts should be automatically updated with security updates.
NOTE
Windows Server Update Services can be configured to automatically approve updates. For more information,
see the "Automatically Approve Updates for Installation" section in Approving Updates.
Security Baselines should be used as starting configurations.
NOTE
Customers can use the Microsoft Security Compliance Toolkit (SCT) for configuring the baselines on the
administrative hosts.
Secure Boot to mitigate against attackers or malware attempting to load unsigned code into the boot
process.
NOTE
This feature was introduced in Windows 8 to leverage the Unified Extensible Firmware Interface (UEFI).
Full volume encryption to mitigate against physical loss of computers, such as administrative laptops
used remotely.
NOTE
See BitLocker for more information.
USB restrictions to protect against physical infection vectors.
NOTE
See Control Read or Write Access to Removable Devices or Media for more information.
Network isolation to protect against network attacks and inadvertent admin actions. Host firewalls
should block all incoming connections except those explicitly required and block all outbound
Internet access.
Antimalware to protect against known threats and malware.
Attack surface analysis to prevent introduction of new attack vectors to Windows during installation
of new software.
NOTE
Use of tools such as the Attack Surface Analyzer (ASA) will help assess configuration settings on a host and
identify attack vectors introduced by software or configuration changes.
Account hardening
Multi-factor authentication should be configured for all accounts in the admin forest, except one
account. At least one administrative account should be password based to ensure access will work in
case the multi-factor authentication process breaks. This account should be protected by a stringent
physical control process.
Accounts configured for multi-factor authentication should be configured to set a new NTLM hash
on accounts regularly. This can be accomplished by disabling and enabling the account attribute
Smart card is required for interactive logon.
NOTE
This can interrupt operations in progress that are using this account, so this process should be initiated only
when administrators won't be using the account, such as at night or on weekends.
Detective controls
Detective controls for the administrative forest should be designed to alert on anomalies in the admin
forest. The limited number of authorized scenarios and activities can help tune these controls more
accurately than the production environment.
For more information engaging about Microsoft services to design and deploy an ESAE for your environment, see
this page.
Tier 0 Equivalency
Most organizations control membership to powerful Tier 0 Active Directory groups like Administrators, Domain
Admins, and Enterprise Admins. Many organizations overlook the risk of other groups that are effectively
equivalent in privilege in a typical active directory environment. These groups offer a relatively easy escalation
path for an attacker to the same explicit Tier 0 privileges using various different attack methods.
As an example, a server operator could gain access to a backup media of a domain controller and extract all the
credentials from the files in that media and use them to escalate privileges.
Organizations should control and monitor membership in all of the Tier 0 groups (including nested membership)
including:
Enterprise Admins
Domain Admins
Schema Admin
BUILTIN\Administrators
Account Operators
Backup Operators
Print Operators
Server Operators
Domain Controllers
Read-only Domain Controllers
Distributed COM Users
NOTE
"Other delegated groups" refers to groups that may be created by your organization to manage directory
operations that may also have effective Tier 0 access.
Administrative Tools and Logon Types

This is reference information to help identify the risk of credential exposure associated with using different
administrative tools for remote administration.
In a remote administration scenario, credentials are always exposed on the source computer so a trustworthy
privileged access workstation (PAW ) is always recommended for sensitive or high impact accounts. Whether
credentials are exposed to potential theft on the target (remote) computer depends primarily on the windows
logon type used by the connection method.
This table includes guidance for the most common administrative tools and connection methods:
CONNECTION REUSABLE CREDENTIALS ON

METHOD LOGON TYPE DESTINATION COMMENTS
Log on at console Interactive v Includes hardware remote

access / lights-out cards and
network KVMs.
RUNAS Interactive v
RUNAS /NETWORK NewCredentials v Clones current LSA session

for local access, but uses
new credentials when
connecting to network
resources.
Remote Desktop (success) RemoteInteractive v If the remote desktop client

is configured to share local
devices and resources, those
may be compromised as
well.
Remote Desktop (failure - RemoteInteractive - By default, if RDP logon fails

logon type was denied) credentials are only stored
very briefly. This may not be
the case if the computer is
compromised.
Net use * \\SERVER Network -
Net use * \\SERVER /u:user Network -
MMC snap-ins to remote Network - Example: Computer

computer Management, Event Viewer,
Device Manager, Services
PowerShell WinRM Network - Example: Enter-PSSession

server
PowerShell WinRM with NetworkClearText v New-PSSession server

CredSSP -Authentication Credssp
-Credential cred
PsExec without explicit creds Network - Example: PsExec \\server

cmd
PsExec with explicit creds Network + Interactive v PsExec \\server -u user -p

pwd cmd
Creates multiple logon
sessions.
Remote Registry Network -
Remote Desktop Gateway Network - Authenticating to Remote

Desktop Gateway.
Scheduled task Batch v Password will also be saved

as LSA secret on disk.
Run tools as a service Service v Password will also be saved

as LSA secret on disk.
Vulnerability scanners Network - Most scanners default to

using network logons,
though some vendors may
implement non-network
logons and introduce more
credential theft risk.
For web authentication, use the reference from the table below:

IIS "Basic Authentication" NetworkCleartext v

(IIS 6.0+)
Interactive
(prior to IIS 6.0)
IIS "Integrated Windows Network - NTLM and Kerberos

Authentication" Providers.
Column Definitions:
Logon type identifies the logon type initiated by the connection.
Reusable credentials on destination indicates that the following credential types will be stored in LSASS
process memory on the destination computer where the specified account is logged on locally:
LM and NT hashes
Kerberos TGTs
Plaintext password (if applicable).
-
The symbols in this table defined as follows:
(-) denotes when credentials are not exposed.
(v) denotes when credentials are exposed.
For management applications that are not in this table, you can determine the logon type from the logon type field
in the audit logon events. For more information, see Audit logon events.
In Windows-based computers, all authentications are processed as one of several logon types, regardless of which
authentication protocol or authenticator is used. This table includes most common logon types and their attributes
relative to credential theft:
REUSABLE
AUTHENTICATORS CREDENTIALS IN LSA
LOGON TYPE # ACCEPTED SESSION EXAMPLES
Interactive (a.k.a., 2 Password, Smartcard, Yes Console logon;

Logon locally) other RUNAS;
Hardware remote
control solutions
(such as Network
KVM or Remote
Access / Lights-Out
Card in server)
IIS Basic Auth (before
IIS 6.0)
Network 3 Password, No (except if NET USE;

NT Hash, delegation is enabled, RPC calls;
Kerberos ticket then Kerberos tickets Remote registry;
present) IIS integrated
Windows auth;
SQL Windows auth;
Batch 4 Password (usually Yes Scheduled tasks

stored as LSA secret)
Service 5 Password (usually Yes Windows services

stored as LSA secret)
NetworkCleartext 8 Password Yes IIS Basic Auth (IIS 6.0

and newer);
Windows PowerShell
with CredSSP
NewCredentials 9 Password Yes RUNAS /NETWORK
RemoteInteractive 10 Password, Smartcard, Yes Remote Desktop

other (formerly known as
"Terminal Services")
Column definitions:
Logon type is the type of logon requested.
# is the numeric identifier for the logon type that is reported in audit events in the Security event log.
Authenticators accepted indicates which types of authenticators are able to initiate a logon of this type.
Reusable credentials in LSA session indicates whether the logon type results in the LSA session holding
credentials, such as plaintext passwords, NT hashes, or Kerberos tickets that could be used to authenticate
to other network resources.
Examples list common scenarios in which the logon type is used.
NOTE
For more information about Logon Types, see SECURITY_LOGON_TYPE enumeration.
Software Restriction Policies
This topic for the IT professional describes Software Restriction Policies (SRP ) in Windows Server 2012 and
Windows 8, and provides links to technical information about SRP beginning with Windows Server 2003.
For procedures and troubleshooting tips, see Administer Software Restriction Policies and Troubleshoot Software
Restriction Policies.
Software Restriction Policies description

Software Restriction Policies (SRP ) is Group Policy-based feature that identifies software programs running on
computers in a domain, and controls the ability of those programs to run. Software restriction policies are part of
the Microsoft security and management strategy to assist enterprises in increasing the reliability, integrity, and
manageability of their computers.
You can also use software restriction policies to create a highly restricted configuration for computers, in which
you allow only specifically identified applications to run. Software restriction policies are integrated with Microsoft
Active Directory and Group Policy. You can also create software restriction policies on stand-alone computers.
Software restriction policies are trust policies, which are regulations set by an administrator to restrict scripts and
other code that is not fully trusted from running.
You can define these policies through the Software Restriction Policies extension of the Local Group Policy Editor
or the Local Security Policies snap-in to the Microsoft Management Console (MMC ).
For in-depth information about SRP, see the Software Restriction Policies Technical Overview.
Administrators can use software restriction policies for the following tasks:
Define what is trusted code
Design a flexible Group Policy for regulating scripts, executable files, and ActiveX controls
Software restriction policies are enforced by the operating system and by applications (such as scripting
applications) that comply with software restriction policies.
Specifically, administrators can use software restriction policies for the following purposes:
Specify which software (executable files) can run on clients
Prevent users from running specific programs on shared computers
Specify who can add trusted publishers to clients
Set the scope of the software restriction policies (specify whether policies affect all users or a subset of
users on clients)
Prevent executable files from running on the local computer, organizational unit (OU ), site, or domain. This
would be appropriate in cases when you are not using software restriction policies to address potential
issues with malicious users.
New and changed functionality
There are no changes in functionality for Software Restriction Policies.
Removed or deprecated functionality

There is no removed or deprecated functionality for Software Restriction Policies.
The Software Restriction Policies extension to the Local Group Policy Editor can be accessed through the MMC.
The following features are required to create and maintain software restriction policies on the local computer:
Local Group Policy Editor
Windows Installer
Authenticode and WinVerifyTrust
If your design calls for domain deployment of these policies, in addition to the above list, the following features are
required:
Group Policy
Server Manager information

Software Restriction Policies is an extension of the Local Group Policy Editor and is not installed through Server
Manager, Add Roles and Features.
See also
The following table provides links to relevant resources in understanding and using SRP.
Product evaluation Application Lockdown with Software Restriction Policies
Planning Software Restriction Policies Technical Overview ( Windows

Server 2012 )
Software Restriction Policies Technical Reference (Windows

Server 2003)
Deployment No resources available.
Operations Administer Software Restriction Policies ( Windows Server

2012 )
Software Restriction Policies Product Help (Windows Server

2003)
Troubleshooting Troubleshoot Software Restriction Policies ( Windows Server

2012 )
Software Restriction Policies Troubleshooting (Windows Server

2003)
Security Threats and Countermeasures for Software Restriction Polices

(Windows Server 2008)
Threats and Countermeasures for Software Restriction Polices

(Windows Server 2008 R2)
Tools and settings Software Restriction Policies Tools and Settings (Windows
Server 2003)
Community resources Application Lockdown with Software Restriction Policies

Software Restriction Policies Technical Overview
This topic describes software restriction policies, when and how to use the feature, what changes have been
implemented in past releases, and provides links to additional resources to help you create and deploy software
restriction policies beginning with Windows Server 2008 and Windows Vista.
Introduction
Software restriction policies provide administrators with a Group Policy-driven mechanism to identify software
and control its ability to run on the local computer. These policies can be used to protect computers running
Microsoft Windows operating systems (beginning with Windows Server 2003 and Windows XP Professional)
against known conflicts and safeguard the computers against security threats such as malicious viruses and Trojan
horse programs. You can also use software restriction policies to create a highly restricted configuration for
computers, in which you allow only specifically identified applications to run. Software restriction policies are
integrated with Microsoft Active Directory and Group Policy. You can also create software restriction policies on
stand-alone computers.
Software restriction policies are trust policies, which are regulations set by an administrator to restrict scripts and
other code that is not fully trusted from running. The Software Restriction Policies extension to the Local Group
Policy Editor provides a single user interface through which the settings for restricting the use of applications can
be managed on the local computer or throughout a domain.
Procedures
Determine Allow -Deny List and Application Inventory for Software Restriction Policies
Use Software Restriction Policies to Help Protect Your Computer Against an Email Virus
Software restriction policy usage scenarios

Business users collaborate by using e-mail, instant messaging, and peer-to-peer applications. As these
collaborations increase, especially with the use of the Internet in business computing, so do the threats from
malicious code, such as worms, viruses, and malicious user or attacker threats.
Users might receive hostile code in many forms, ranging from native Windows executable files (.exe files), to
macros in documents (such as .doc files), to scripts (such as .vbs files). Malicious users or attackers often use social
engineering methods to get users to run code containing viruses and worms. (Social engineering is a term for
tricking people into revealing their password or some form of security information.) If such code is activated, it can
generate denial-of-service attacks on the network, send sensitive or private data to the Internet, put the security of
the computer at risk, or damage the contents of the hard disk drive.
IT organizations and users must be able to determine which software is safe to run and which is not. With the
large numbers and forms that hostile code can take, this becomes a difficult task.
To help protect their network computers from both hostile code and unknown or unsupported software,
organizations can implement software restriction policies as part of their overall security strategy.
Administrators can use software restriction policies for the following tasks:
Define what is trusted code
Design a flexible Group Policy for regulating scripts, executable files, and ActiveX controls
Software restriction policies are enforced by the operating system and by applications (such as scripting
applications) that comply with software restriction policies.
Specifically, administrators can use software restriction policies for the following purposes:
Specify which software (executable files) can run on client computers
Prevent users from running specific programs on shared computers
Specify who can add trusted publishers to client computers
Set the scope of the software restriction policies (specify whether policies affect all users or a subset of
users on client computers)
Prevent executable files from running on the local computer, organizational unit (OU ), site, or domain. This
would be appropriate in cases when you are not using software restriction policies to address potential
issues with malicious users.
Differences and changes in functionality

There are no changes in functionality in SRP for Windows Server 2012 and Windows 8.
Supported versions
Software Restriction Policies can only be configured on and applied to computers running at least Windows
Server 2003, including Windows Server 2012 , and at least Windows XP, including Windows 8.
NOTE
Certain editions of the Windows client operating system beginning with Windows Vista do not have Software Restrictions
Policies. Computers not administered in a domain by Group Policy might not receive distributed policies.
Comparing application control functions in Software Restriction Policies and AppLocker

The following table compares the features and functions of the Software Restriction Policies (SRP ) feature and
AppLocker.
APPLICATION CONTROL FUNCTION SRP APPLOCKER
Scope SRP policies can be applied to all AppLocker policies apply only to
Windows operating systems beginning Windows Server 2008 R2, Windows
with Windows XP and Windows Server Server 2012 , Windows 7, and Windows
2003. 8.
Policy creation SRP policies are maintained through AppLocker policies are maintained
Group Policy and only the administrator through Group Policy and only the
of the GPO can update the SRP policy. administrator of the GPO can update
The administrator on the local the policy. The administrator on the
computer can modify the SRP policies local computer can modify the
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 using AppLocker policies can be updated by
the Local Security Policy snap-in (if the using the Local Security Policy snap-in
policies are created locally) or the Group (if the policies are created locally), or the
Policy Management Console (GPMC). GPMC, or the 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 rules "allow list mode" where only those files
for files that they do not want to allow are allowed to run for which there is a
in this Enterprise whereas the rest of matching allow rule.
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 types: AppLocker can control the following file
types:
- Executables
- Dlls - Executables
- Scripts - Dlls
- Windows Installers - Scripts
- Windows Installers
SRP cannot control each file type - Packaged apps and installers (
separately. All SRP rules are in a single Windows Server 2012 and Windows 8)
rule collection.
AppLocker maintains a separate rule
collection for each of the five file types.
Designated file types SRP supports an extensible list of file AppLocker does not support this.
types that are considered executable. AppLocker currently supports the
Administrators can add extensions for following file extensions:
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
- Path - Hash
- Signature - Path
- Internet zone - Publisher
Editing the hash value SRP allows administrators to provide AppLocker computes the hash value
custom hash values. itself. Internally it uses the SHA1
Authenticode hash for Portable
Executables (Exe and Dll) and Windows
Installers and a SHA1 flat file hash for
the rest.
Support for different security levels With SRP administrators can specify the AppLocker does not support security
permissions with which an app can run. levels.
So, an administrator 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 Packaged Unable .appx is a valid file type which
app installers AppLocker can manage.
Targeting a rule to a user or a group of SRP rules apply to all users on a AppLocker rules can be targeted to a
users particular computer. specific user or a group of users.
Support for rule exceptions SRP does not support rule exceptions AppLocker rules can have 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. The AppLocker supports audit mode which
only way to test SRP policies is to set up allows administrators to test the effect
a test environment and run a few of their policy in the real production
experiments. environment without impacting the
user experience. Once you are satisfied
with the results, you can start enforcing
the policy.
Support for exporting and importing SRP does not support policy AppLocker supports the importing and
policies import/export. 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 and
happens in the user-mode which is less Dlls are enforced in the kernel-mode
secure. which is more secure than enforcing
them in the user-mode.
System requirements
Software restriction policies can only be configured on and applied to computers running at least Windows Server
2003, and at least Windows XP. Group Policy is required to distribute Group Policy Objects that contain software
restriction policies.
Software restriction policies components and architecture

Software restriction policies provide a mechanism for the operating system and applications compliant with
software restriction policies to restrict the runtime execution of software programs.
At a high level, software restriction policies consist of the following components:
Software restriction policies API. The Application Programming Interfaces (APIs) are used to create and
configure the rules that constitute the software restriction policy. There also are software restriction policies
APIs for querying, processing, and enforcing software restriction policies.
A software restriction policies management tool. This consists of the Software Restriction Policies
extension of the Local Group Policy Object Editor snap-in, which administrators use to create and edit
the software restriction policies.
A set of operating system APIs and applications that call the software restriction policies APIs to provide
enforcement of the software restriction policies at runtime.
Active Directory and Group Policy. Software restriction policies depend on the Group Policy infrastructure
to propagate the software restriction policies from the Active Directory to the appropriate clients, and for
scoping and filtering the application of these policies to the appropriate target computers.
Authenticode and WinVerify Trust APIs which are used to process signed executable files.
Event Viewer. The functions used by software restriction policies log events to the Event Viewer logs.
Resultant Set of Policies (RSoP ), which can aid in the diagnosing of the effective policy that will be applied
to a client.
For more information about SRP architecture, how SRP manages rules, processes and interactions, see How
Software Restriction Policies Work in the Windows Server 2003 Technical Library.
Best practices
Do not modify the default domain policy.
If you do not edit the default domain policy, you always have the option of reapplying the default domain policy
if something goes wrong with your customized domain policy.
Create a separate Group Policy Object for software restriction policies.
If you create a separate Group Policy Object (GPO ) for software restriction policies, you can disable software
restriction policies in an emergency without disabling the rest of your domain policy.
If you experience problems with applied policy settings, restart Windows in Safe Mode.
Software restriction policies do not apply when Windows is started in Safe Mode. If you accidentally lock down
a workstation with software restriction policies, restart the computer in Safe Mode, log on as a local
administrator, modify the policy, run gpupdate, restart the computer, and then log on normally.
Use caution when defining a default setting of Disallowed.
When you define a default setting of Disallowed, all software is disallowed except for software that has
been explicitly allowed. Any file that you want to open has to have a software restriction policies rule that
allows it to open.
To protect administrators from locking themselves out of the system, when the default security level is set to
Disallowed, four registry path rules are automatically created. You can delete or modify these registry path
rules; however, this is not recommended.
For best security, use access control lists in conjunction with software restriction policies.
Users might try to circumvent software restriction policies by renaming or moving disallowed files or by
overwriting unrestricted files. As a result, it is recommended that you use access control lists (ACLs) to deny
users the access necessary to perform these tasks.
Test new policy settings thoroughly in test environments before applying the policy settings to your domain.
New policy settings might act differently than originally expected. Testing diminishes the chance of
encountering a problem when you deploy policy settings across your network.
You can set up a test domain, separate from your organization's domain, in which to test new policy settings.
You can also test the policy settings by creating a test GPO and linking it to a test organizational unit. When
you have thoroughly tested the policy settings with test users, you can link the test GPO to your domain.
Do not set programs or files to Disallowed without testing to see what the effect may be. Restrictions on
certain files can seriously affect the operation of your computer or network.
Information that is entered incorrectly or typing mistakes can result in a policy setting that does not
perform as expected. Testing new policy settings before applying them can prevent unexpected behavior.
Filter user policy settings based on membership in security groups.
You can specify users or groups for which you do not want a policy setting to apply by clearing the Apply
Group Policy and Read check boxes, which are located on the Security tab of the properties dialog box
for the GPO.
When the Read permission is denied, the policy setting is not downloaded by the computer. As a result, less
bandwidth is consumed by downloading unnecessary policy settings, which enables the network to function
more quickly. To deny the Read permission, select Deny for the Read check box, which is located on the
Security tab of the properties dialog box for the GPO.
Do not link to a GPO in another domain or site.
Linking to a GPO in another domain or site can result in poor performance.
Additional resources
Planning Software Restriction Policies Technical Reference
Operations Administer Software Restriction Policies
Troubleshooting Software Restriction Policies Troubleshooting (2003)
Security Threats and Countermeasures for Software Restriction Polices

(2008)
Threats and Countermeasures for Software Restriction Polices

(2008 R2)
Tools and settings Software Restriction Policies Tools and Settings (2003)
Community resources Application Lockdown with Software Restriction Policies

This topic for the IT professional contains procedures how to administer application control policies using
Software Restriction Policies (SRP ) beginning with Windows Server 2008 and Windows Vista.
Introduction
computers in a domain, and controls the ability of those programs to run. You use software restriction policies to
create a highly restricted configuration for computers, in which you allow only specifically identified applications
to run. These are integrated with Microsoft Active Directory Domain Services and Group Policy but can also be
configured on stand-alone computers. For more information about SRP, see the Software Restriction Policies.
Beginning with Windows Server 2008 R2 and Windows 7 , Windows AppLocker can be used instead of or in
concert with SRP for a portion of your application control strategy.
This topic contains:
To open Software Restriction Policies
To create new software restriction policies
To add or delete a designated file type
To prevent software restriction policies from applying to local administrators
To change the default security level of software restriction policies
To apply software restriction policies to DLLs
For information about how to accomplish specific tasks using SRP, see the following:
Determine Allow -Deny List and Application Inventory for Software Restriction Policies
To open Software Restriction Policies

For your local computer
For a domain, site, or organizational unit, and you are on a member server or on a workstation that is
joined to a domain
For a domain or organizational unit, and you are on a domain controller or on a workstation that has the
Remote Server Administration Tools installed
For a site, and you are on a domain controller or on a workstation that has the Remote Server
Administration Tools installed
1. Open Local Security Settings.
2. In the console tree, click Software Restriction Policies.
Where?
Security Settings/Software Restriction Policies
NOTE
To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have
been delegated the appropriate authority.
For a domain, site, or organizational unit, and you are on a member server or on a workstation that is joined to a
domain
1. Open Microsoft Management Console (MMC ).
2. On the File menu, click Add/Remove Snap-in, and then click Add.
3. Click Local Group Policy Object Editor, and then click Add.
4. In Select Group Policy Object, click Browse.
5. In Browse for a Group Policy Object, select a Group Policy Object (GPO ) in the appropriate domain, site,
or organizational unit-or create a new one, and then click Finish.
6. Click Close, and then click OK.
Where?
Group Policy Object [ComputerName] Policy/Computer Configuration or
User Configuration/Windows Settings/Security Settings/Software Restriction Policies
NOTE
To perform this procedure, you must be a member of the Domain Admins group.
For a domain or organizational unit, and you are on a domain controller or on a workstation that has the Remote
Server Administration Tools installed
1. Open Group Policy Management Console.
2. In the console tree, right-click the Group Policy Object (GPO ) that you want to open software restriction
policies for.
3. Click Edit to open the GPO that you want to edit. You can also click New to create a new GPO, and then
click Edit.
Where?
NOTE
To perform this procedure, you must be a member of the Domain Admins group.
For a site, and you are on a domain controller or on a workstation that has the Remote Server Administration
Tools installed
1. Open Group Policy Management Console.
2. In the console tree, right-click the site that you want to set Group Policy for.
Where?
Active Directory Sites and Services [Domain_Controller_Name.Domain_Name]/Sites/Site
3. Click an entry in Group Policy Object Links to select an existing Group Policy Object (GPO ), and then
click Edit. You can also click New to create a new GPO, and then click Edit.
Where
NOTE
been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group
might be able to perform this procedure.
To set policy settings that will be applied to computers, regardless of which users log on to them, click Computer
Configuration.
To set policy settings that will be applied to users, regardless of which computer they log on to, click User
Configuration.

1. Open Software Restriction Policies.
2. On the Action menu, click New Software Restriction Policies.
WARNING
Different administrative credentials are required to perform this procedure, depending on your environment:
If you create new software restriction policies for your local computer: Membership in the local Administrators
group, or equivalent, is the minimum required to complete this procedure.
If you create new software restriction policies for a computer that is joined to a domain, members of the Domain
Admins group can perform this procedure.
If software restriction policies have already been created for a Group Policy Object (GPO), the New Software
Restriction Policies command does not appear on the Action menu. To delete the software restriction policies that are
applied to a GPO, in the console tree, right-click Software Restriction Policies, and then click Delete Software
Restriction Policies. When you delete software restriction policies for a GPO, you also delete all software restriction
policies rules for that GPO. After you delete software restriction policies, you can create new software restriction policies
for that GPO.
2. In the details pane, double-click Designated File Types.
3. Do one of the following:
To add a file type, in File name extension, type the file name extension, and then click Add.
To delete a file type, in Designated file types, click the file type, and then click Remove.
NOTE
Different administrative credentials are required to perform this procedure, depending on the environment in which
you add or delete a designated file type:
If you add or delete a designated file type for your local computer: Membership in the local Administrators
group, or equivalent, is the minimum required to complete this procedure.
If you create new software restriction policies for a computer that is joined to a domain, members of the Domain
Admins group can perform this procedure.
It may be necessary to create a new software restriction policy setting for the Group Policy Object (GPO) if you have not
already done so.
The list of designated file types is shared by all rules for both Computer Configuration and User Configuration for a GPO.
To prevent software restriction policies from applying to local

administrators
2. In the details pane, double-click Enforcement.
3. Under Apply software restriction policies to the following users, click All users except local
administrators.
WARNING
Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.
already done so.
If it is common for users to be members of the local Administrators group on their computers in your organization, you
may not want to enable this option.
If you are defining a software restriction policy setting for your local computer, use this procedure to prevent local
administrators from having software restriction policies applied to them. If you are defining a software restriction policy
setting for your network, filter user policy settings based on membership in security groups through Group Policy.
To change the default security level of software restriction policies

2. In the details pane, double-click Security Levels.
3. Right-click the security level that you want to set as the default, and then click Set as default.
Cau t i on
In certain directories, setting the default security level to Disallowed can adversely affect your operating system.
NOTE
Different administrative credentials are required to perform this procedure, depending on the environment for which you
change the default security level of software restriction policies.
It may be necessary to create a new software restriction policy setting for this Group Policy Object (GPO) if you have not
already done so.
In the details pane, the current default security level is indicated by a black circle with a check mark in it. If you right-click
the current default security level, the Set as default command does not appear in the menu.
Software restriction policies rules are created to specify exceptions to the default security level. When the default security
level is set to Unrestricted, rules can specify software that is not allowed to run. When the default security level is set to
Disallowed, rules can specify software that is allowed to run.
At installation, the default security level of software restriction policies on all files on your system is set to Unrestricted.
To apply software restriction policies to DLLs

2. In the details pane, double-click Enforcement.
3. Under Apply software restriction policies to the following, click All software files.
NOTE
been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group
might be able to perform this procedure.
By default, software restriction policies do not check dynamic-link libraries (DLLs). Checking DLLs can decrease system
performance, because software restriction policies must be evaluated every time a DLL is loaded. However, you may
decide to check DLLs if you are concerned about receiving a virus that targets DLLs. If the default security level is set to
Disallowed, and you enable DLL checking, you must create software restriction policies rules that allow each DLL to run.
Determine Allow-Deny List and Application
Inventory for Software Restriction Policies
This topic for the IT professional gives guidance how to create an allow and deny list for applications to be
managed by Software Restriction Policies (SRP ) beginning with Windows Server 2008 and Windows Vista.
Introduction
create a highly restricted configuration for computers, in which you allow only specifically identified applications to
run. These are integrated with Microsoft Active Directory Domain Services and Group Policy but can also be
configured on stand-alone computers. For a starting point for SRP, see the Software Restriction Policies.
For information about how to accomplish specific tasks using SRP, see the following:
What default rule to choose: Allow or Deny
Software restriction policies can be deployed in one of two modes that are the basis of your default rule: Allow List
or Deny List. You can create a policy that identifies every application that is allowed to run in your environment;
the default rule within your policy is Restricted and will block all applications that you do not explicitly allow to run.
Or you can create a policy that identifies every application that cannot run; the default rule is Unrestricted and
restricts only the applications that you have explicitly listed.
IMPORTANT
The Deny List mode might be a high-maintenance strategy for your organization regarding application control. Creating and
maintaining an evolving list that prohibits all malware and other problematic applications would be time consuming and
susceptible to mistakes.
Create an inventory of your applications for the Allow list

To effectively use the Allow default rule, you need to determine exactly which applications are required in your
organization. There are tools designed to produce an application inventory, such as the Inventory Collector in the
Microsoft Application Compatibility Toolkit. But SRP has an advanced logging feature to help you understand
exactly what applications are running in your environment.
To d i sc o v e r w h i c h a p p l i c a t i o n s t o a l l o w
1. In a test environment, deploy Software Restriction Policy with the default rule set to Unrestricted and
remove any additional rules. If you enable SRP without forcing it to restrict any applications, SPR will be
able to monitor what applications are being run.
2. Create the following registry value in order to enable the advanced logging feature and set the path to
where the log file should be written.
"HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\ CodeIdentifiers"
String Value: NameLogFile path to NameLogFile
Because SRP is evaluating all applications when they run, an entry is written to the log file NameLogFile
each time that application is run.
3. Evaluate the log file
Each log entry states:
the caller of the software restriction policy and the process ID (PID ) of the calling process
the target being evaluated
the SRP rule that was encountered when that application ran
an identifier for the SRP rule.
An example of the output written to a log file:
explorer.exe (PID = 4728) identifiedC:\Windows\system32\onenote.exe as Unrestricted usingpath rule,
Guid ={320bd852-aa7c-4674-82c5-9a80321670a3} All applications and associated code that SRP checks and
set to block will be noted in the log file, which you then can use to determine which executables should be
considered for your Allowed list.
This topic describes procedures working with certificate, path, internet zone and hash rules using Software
Restriction Policies.
Introduction
With software restriction policies, you can protect your computing environment from untrusted software by
identifying and specifying what software is allowed to run. You can define a default security level of Unrestricted
or Disallowed for a Group Policy Object (GPO ) so that software is either allowed or not allowed to run by
default. You can make exceptions to this default security level by creating software restriction policies rules for
specific software. For example, if the default security level is set to Disallowed, you can create rules that allow
specific software to run. The types of rules are as follows:
Certificate rules
For procedures, see Working with certificate rules.
Hash rules
For procedures, see Working with hash rules.
Internet zone rules
For procedures, see Working with Internet Zone rules.
Path rules
For procedures, see Working with path rules.
For information about other tasks to manage Software Restriction Policies, see Administer Software Restriction
Policies.
Working with certificate rules

Software restriction policies can also identify software by its signing certificate. You can create a certificate rule
that identifies software and then allows or does not allow the software to run, depending on the security level. For
example, you can use certificate rules to automatically trust software from a trusted source in a domain without
prompting the user. You can also use certificate rules to run files in disallowed areas of your operating system.
Certificate rules are not enabled by default.
When rules are created for the domain using Group Policy, you must have permissions to create or modify a
Group Policy Object. If you are creating rules for the local computer, you must have administrative credentials on
that computer.
To create a certificate rule
2. In either the console tree or the details pane, right-click Additional Rules, and then click New Certificate
Rule.
3. Click Browse, and then select a certificate or signed file.
4. In Security level, click either Disallowed or Unrestricted.
5. In Description, type a description for this rule, and then click OK.
NOTE
It might be necessary to create a new software restriction policy setting for the Group Policy Object (GPO) if you have
not already done so.
Certificate rules are not enabled by default.
The only file types that are affected by certificate rules are those that are listed in Designated file types in the details
pane for Software Restriction Policies. There is one list of designated file types that is shared by all rules.
For software restriction policies to take effect, users must update policy settings by logging off from and logging on to
their computers.
When more than one software restriction policies rule is applied to policy settings, there is a precedence of rules for
handling conflicts.
Enabling certificate rules

There are different procedures for enabling certificate rules depending on your environment:
For a Group Policy Object, and you are on a server that is joined to a domain
For a Group Policy Object, and you are on a domain controller or a on workstation that has the Remote
For only domain controllers, and you are on a domain controller or on a workstation that has the Remote
Server Administration Tools Pack installed
To enable certificate rules for your local computer
1. Open Local Security Settings.
2. In the console tree, click Security Options located under Security Settings/Local Policies.
3. In the details pane, double-click System settings: Use Certificate Rules on Windows Executables for
Software Restriction Policies.
4. Do one of the following, and then click OK:
To enable certificate rules, click Enabled.
To disable certificate rules, click Disabled.
To enable certificate rules For a Group Policy Object, and you are on a server that is joined to a domain
1. Open Microsoft Management Console (MMC ).
2. On the File menu, click Add/Remove snap-in, and then click Add.
3. Click Local Group Policy Object Editor, and then click Add.
4. In Select Group Policy Object, click Browse.
5. In Browse for a Group Policy Object, select a Group Policy Object (GPO ) in the appropriate domain, site,
or organizational unit-or create a new one, and then click Finish.
6. Click Close, and then click OK.
7. In the console tree, click Security Options located under GroupPolicyObject [ComputerName]
Policy/Computer Configuration/Windows Settings/Security Settings/Local Policies/.
9. If this policy setting has not yet been defined, select the Define these policy settings check box.
To enable certificate rules for a Group Policy Object, and you are on a domain controller or on a workstation that has the Remote
2. In the console tree, right-click the Group Policy Object (GPO ) for which you want to enable certificate rules.
3. Click Properties, and then click the Group Policy tab.
4. Click Edit to open the GPO that you want to edit. You can also click New to create a new GPO, and then
click Edit.
5. In the console tree, click Security Options located under GroupPolicyObject[ComputerName]
Policy/Computer Configuration/Windows Settings/Security Settings/Local Policies.
To enable certificate rules for only domain controllers, and you are on a domain controller or on a workstation that has the Remote
1. Open Domain Controller Security Settings.
2. In the console tree, click Security Options located under GroupPolicyObject [ComputerName]
Policy/Computer Configuration/Windows Settings/Security Settings/Local Policies.
NOTE
You must perform this procedure before certificate rules can take effect.
Set trusted publisher options

Software signing is being used by a growing number of software publishers and application developers to verify
that their applications come from a trusted source. However, many users do not understand or pay little attention
to the signing certificates associated with applications that they install.
The policy settings in the Trusted Publishers tab of the certificate path validation policy allows administrators to
control which certificates can be accepted as coming from a trusted publisher.
To c o n fi g u r e t h e t r u st e d p u b l i sh e r s p o l i c y se t t i n g s fo r a l o c a l c o m p u t e r
1. On the Start screen, typegpedit.msc and then press ENTER.

2. In the console tree under Local Computer Policy\Computer Configuration\Windows
Settings\Security Settings, click Public Key Policies.
3. Double-click Certificate Path Validation Settings, and then click the Trusted Publishers tab.
4. Select the Define these policy settings check box, select the policy settings that you want to apply, and
then click OK to apply the new settings.
To c o n fi g u r e t h e t r u st e d p u b l i sh e r s p o l i c y se t t i n g s fo r a d o m a i n
1. Open Group Policy Management.

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 console tree under Computer Configuration\Windows Settings\Security Settings, click Public
Key Policies.
6. Select the Define these policy settings check box, select the policy settings that you want to apply, and
then click OK to apply the new settings.
To a l l o w o n l y a d m i n i st r a t o r s t o m a n a g e c e r t i fi c a t e s u se d fo r c o d e si g n i n g fo r a l o c a l c o m p u t e r
1. On the Start screen, type, gpedit.msc in the Search programs and files or in Windows 8, on the
Desktop, and then press ENTER.
2. In the console tree under Default Domain Policy or Local Computer Policy, double-click Computer
Configuration, Windows Settings, and Security Settings, and then click Public Key Policies.
4. Select the Define these policy settings check box.
5. Under Trusted publisher management, click Allow only all administrators to manage Trusted
Publishers, and then click OK to apply the new settings.
To a l l o w o n l y a d m i n i st r a t o r s t o m a n a g e c e r t i fi c a t e s u se d fo r c o d e si g n i n g fo r a d o m a i n
1. Open Group Policy Management.

2. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default
Domain Policy GPO that you want to edit.
3. Right-click the Default Domain Policy GPO, and then click Edit.
4. In the console tree under Computer Configuration\Windows Settings\Security Settings, click Public
Key Policies.
6. Select the Define these policy settings check box, implement the changes you want, and then click OK to
apply the new settings.
Working with hash rules
A hash is a series of bytes with a fixed length that uniquely identifies a software program or file. The hash is
computed by a hash algorithm. When a hash rule is created for a software program, software restriction policies
calculate a hash of the program. When a user tries to open a software program, a hash of the program is
compared to existing hash rules for software restriction policies. The hash of a software program is always the
same, regardless of where the program is located on the computer. However, if a software program is altered in
any way, its hash also changes, and it no longer matches the hash in the hash rule for software restriction policies.
For example, you can create a hash rule and set the security level to Disallowed to prevent users from running a
certain file. A file can be renamed or moved to another folder and still result in the same hash. However, any
changes to the file itself also change its hash value and allow the file to bypass restrictions.
To create a hash rule
2. In either the console tree or the details pane, right-click Additional Rules, and then click New Hash Rule.
3. Click Browse to find a file.
NOTE
In Windows XP it is possible to paste a pre-calculated hash in File hash. In Windows Server 2008 R2 , Windows 7
and later versions, this option is not available.

NOTE
already done so.
A hash rule can be created for a virus or a Trojan horse to prevent them from running.
If you want other people to use a hash rule so that a virus cannot run, calculate the hash of the virus by using software
restriction policies, and then e-mail the hash value to the other people. Never e-mail the virus itself.
If a virus has been sent through e-mail, you can also create a path rule to prevent execution of e-mail attachments.
A file that is renamed or moved to another folder results in the same hash. Any change to the file itself results in a
different hash.
The only file types that are affected by hash rules are those that are listed in Designated File Types in the details pane
for Software Restriction Policies. There is one list of designated file types that is shared by all rules.
their computers.
handling conflicts.
Working with Internet Zone rules

Internet zone rules apply only to Windows Installer packages. A zone rule can identify software from a zone that is
specified through Internet Explorer. These zones are Internet, Local intranet, Restricted sites, Trusted sites, and My
Computer. An Internet Zone rule is designed to prevent users from downloading and installing software.
To create an Internet zone rule
2. In either the console tree or the details pane, right-click Additional Rules, and then click New Internet
Zone Rule.
3. In Internet zone, click an Internet zone.
4. In Security level, click either Disallowed or Unrestricted, and then click OK.
NOTE
already done so.
Zone rules only apply to files with an .msi file type, which are Windows Installer packages.
their computers.
handling conflicts.
Working with path rules

A path rule identifies software by its file path. For example, if you have a computer that has a default security level
of Disallowed, you can still grant unrestricted access to a specific folder for each user. You can create a path rule
by using the file path and setting the security level of the path rule to Unrestricted. Some common paths for this
type of rule are %userprofile%, %windir%, %appdata%, %programfiles%, and %temp%. You can also create
registry path rules that use the registry key of the software as its path.
Because these rules are specified by the path, if a software program is moved, the path rule no longer applies.
To create a path rule
2. In either the console tree or the details pane, right-click Additional Rules, and then click New Path Rule.
3. In Path, type a path, or click Browse to find a file or folder.
Cau t i on
On certain folders, such as the Windows folder, setting the security level to Disallowed can adversely affect
the operation of your operating system. Make sure that you do not disallow a crucial component of the
operating system or one of its dependent programs.
NOTE
It may be necessary to create new software restriction policies for the Group Policy Object (GPO) if you have not already
done so.
If you create a path rule for software with a security level of Disallowed, users can still run the software by copying it to
another location.
The wildcard characters that are supported by the path rule are * and ?.
You can use environment variables, such as %programfiles% or %systemroot%, in the path rule.
If you want to create a path rule for software when you do not know where it is stored on a computer but you have its
registry key, you can create a registry path rule.
To prevent users from executing e-mail attachments, you can create a path rule for your e-mail program's attachment
directory that prevents users from running e-mail attachments.
The only file types that are affected by path rules are those that are listed in Designated File Types in the details pane
for Software Restriction Policies. There is one list of designated file types that is shared by all rules.
their computers.
handling conflicts.
To create a registry path rule

1. On the Start screen, type regedit.
2. In the console tree, right-click the registry key that you want to create a rule for, and then click Copy Key
Name. Note the value name in the details pane.
4. In either the console tree or the details pane, right-click Additional Rules, and then click New Path Rule.
5. In Path, paste the registry key name, followed by the value name.
6. Enclose the registry path in percent signs (%), for example,
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PlatformSDK\Directories\InstallDir%.
Use Software Restriction Policies to Help Protect Your
Computer Against an Email Virus
This topic provides information how to set application control polices using Software Restriction Policies (SRP ) to
help protect your computer against e-mail virus beginning with Windows Server 2008 and Windows Vista.
Introduction
configured on stand-alone computers. For a starting point for SRP, see the Software Restriction Policies.
Configure SRP to help protect against an e-mail virus
1. Review the best practices for software restriction policies to understand how SRP works.
Best practices
How Software Restriction Policies Work
For a domain, site, or organizational unit, and you are on a member server or on a workstation that
is joined to a domain
3. If you have not previously defined software restriction policies, create new software restriction policies.
4. Create a path rule for the folder that your e-mail program uses to run e-mail attachments, and then set the
security level to Disallowed.
Working with path rules
5. Specify the file types to which the rule applies.
6. Modify policy settings so that they apply to the users and groups that you want:
Specify users or groups to which you do not want the Group Policy Object's (GPO ) policy settings to
apply.
Exclude local administrators from the software restriction policies of a specific policy setting in
Group Policy and still have the rest of Group Policy apply to the administrators.
To prevent software restriction policies from applying to local administrators
7. Test the policy.
This topic describes common problems and their solutions when troubleshooting Software Restriction Policies
(SRP ) beginning with Windows Server 2008 and Windows Vista.
Introduction
configured on stand-alone computers. For more information about SRP, see the Software Restriction Policies.
Windows cannot open a program
Users receive a message that says "Windows cannot open this program because it has been prevented by a
software restriction policy. For more information, open Event Viewer or contact your system administrator." Or, on
the command line, a message says "The system cannot execute the specified program."
Cause: The default security level (or a rule) was created so that the software program is set as Disallowed, and as
a result it will not start.
Solution: Look in the event log for an in-depth description of the message. The event log message indicates what
software program is set as Disallowed and what rule is applied to the program.
Modified software restriction policies are not taking effect
Cause: Software restriction policies that are specified in a domain through Group Policy override any policy
settings that are configured locally. This might imply that there is a policy setting from the domain that is
overriding your policy setting.
Cause: Group Policy might not have refreshed its policy settings. Group Policy applies changes to policy settings
periodically; therefore, it is likely that the policy changes that were made in the directory have not yet been
refreshed.
Solutions:
1. The computer on which you modify software restriction policies for the network must be able to contact a
domain controller. Ensure the computer can contact a domain controller.
2. Refresh policy by logging off of the network and then logging on to the network again. If any policy is
applied through Group Policy, logging back in will refresh those policies.
3. You can refresh policy settings with the command-line utility gpupdate or by logging off from and then
logging back on to your computer. For best results, run gpupdate, and then log off from and log back on to
your computer. Generally, the security settings are refreshed every 90 minutes on a workstation or server
and every 5 minutes on a domain controller. The settings are also refreshed every 16 hours, whether or not
there are any changes. These are configurable settings so refresh intervals might be different in each
domain.
4. Check which policies apply. Check domain level policies for No Override settings.
5. Software restriction policies that are specified in a domain through Group Policy override any policies that
are configured locally. Use Gpresult command-line tool to determine what the net effect of the policy is.
This might imply that there is a policy from the domain that is overriding your local setting.
6. If SRP and AppLocker policy settings are in the same GPO, AppLocker settings will take precedence on
Windows 7 , Windows Server 2008 R2 , and later. It is recommended to put SRP and AppLocker policy
settings in different GPOs.
After adding a rule through SRP, you cannot log on to your computer
Cause: Your computer accesses many programs and files when it starts. You might have inadvertently set one of
these programs or files to Disallowed. Because the computer cannot access the program or file, it cannot start
properly.
Solution: Start the computer in Safe Mode, log on as a local administrator, and then change software restriction
policies to allow the program or file to run.
A new policy setting is not applying to a specific file name extension
Cause: The filename extension is not in the list of supported file types.
Solution: Add the filename extension to the list of file types supported by SRP.
Software restriction policies address the problem of regulating unknown or untrusted code. Software restriction
policies are security settings to identify software and control its ability to run on a local computer, in a site, domain,
or OU and can be implemented through a GPO.
A default rule is not restricting as expected
Cause: Rules which are applied in a particular order which can cause default rules to be overridden by specific
rules. SRP applies rules in the following order (most specific to general):
1. Hash rules
2. Certificate rules
3. Path rules
4. Internet Zone rules
5. Default rules
Solution: Evaluate the rules restricting the application and, if appropriate, remove all but the Default rule.
Unable to discover which restrictions are applied
Cause: There is no apparent cause for the unexpected behavior, and GPO refresh has not solved the issue so
further investigation is necessary.
Solutions:
1. Investigate the System Event Log, filtering on source of "Software Restriction Policy." The entries explicitly
state which rule is implemented for each application.
2. Enable advanced logging. See Determine Allow -Deny List and Application Inventory for Software
Restriction Policies for more information.

Identity - Access PDF

Caricato da

Informazioni sul documento

Titolo originale

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

Identity - Access PDF

Caricato da

Copyright:

Formati disponibili

Contents

Identity and Access

Privileged Access Management for Active Directory Domain Services & AD DS

Windows 10 for the enterprise: Ways to use devices for work

Active Directory Domain Services

Active Directory Federation Services

Solutions and Scenario Guides

GUIDE HOW CAN THIS GUIDE HELP YOU

Dynamic Access Control Content Roadmap

Scenario: Access- Scenario: Access- Plan for Access- Deploy Access-Denied

Scenario: Scenario: Plan to deploy for Deploy Encryption of

Reliance on data and

Scenario: Scenario: Implement Plan for Retention of Deploy Implementing

Product evaluation - Dynamic Access Control Reviewers Guide

Planning - Planning a Central Access Policy Deployment

Deployment - Active Directory Deployment

Operations Dynamic Access Control PowerShell Reference

Tools and settings Data Classification Toolkit

Community resources Directory Services Forum

Figure 1 Central access and audit policy concepts

Figure 2 Central access policy workflow

Roles and features included in this scenario

ROLE/FEATURE HOW IT SUPPORTS THIS SCENARIO

Deploy the central access policy Deploy the policy.

Set up a test environment

1.1 Business determines that a central To protect finance information that is

1.3 Express the access policy in Windows Targeting:

Allow read memberOf(FinanceException)

1.4 Determine the file properties required Tag files with:

1.5 Determine the claim types and groups Claim types:

Implement: Configure the components and policy

2.1 Create claim types Create the following claim types:

2.2 Create resource properties Create and enable the following

*Windows PowerShell equivalent commands*

New-ADClaimType country -SourceAttribute c -SuggestedValues:@((New-Object

*Windows PowerShell equivalent commands*

New-ADResourceProperty Country -IsSecured $true -ResourcePropertyValueType MS-DS-MultivaluedChoice -

New-ADCentralAccessPolicy "Finance Policy" Add-ADCentralAccessPolicyMember

Deploy the central access policy

Maintain: Change and stage the policy

Number Step Example

To set up group policy setting to enable claims for devices

*Windows PowerShell equivalent commands*

Figure 4 Central auditing experiences

Roles and features included in this scenario

ROLE/FEATURE HOW IT SUPPORTS THIS SCENARIO

Configure global object access policy

Update Group Policy settings

3. Type gpupdate /force and then press ENTER.

Features included in this scenario

FEATURE HOW IT SUPPORTS THIS SCENARIO

Step 1: Configure access-denied assistance

*Windows PowerShell equivalent commands*

Set-GPRegistryValue -Name "Name of GPO" -key "HKLM\Software\Policies\Microsoft\Windows\ADR\AccessDenied" -

*Windows PowerShell equivalent commands*

*Windows PowerShell equivalent commands*

Set-GPRegistryValue -Name "Name of GPO" -key "HKLM\SOFTWARE\Policies\Microsoft\Windows\Explore" -ValueName

*Windows PowerShell equivalent commands*

Step 2: Configure the email notification settings

*Windows PowerShell equivalent commands*

set-FSRMSetting -SMTPServer "server1" -AdminEmailAddress "fileadmin@contoso.com" -FromEmailAddress

Step 3: Verify that access-denied assistance is configured correctly

Figure 6 Classification-based RMS protection

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands

Windows PowerShell equivalent commands