Everything About Active Directory

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
Configuring Certificate Enrollment Web Service for certificate key-based renewal on
a custom port
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
Running Active Directory on Azure VMs
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
Using ETW to troubleshoot LDAP connections
Troubleshooting Active Directory Replication Problems
Additional Resources
Active Directory Federation Services
AD FS Overview
What's new in Active Directory Federation Services
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
Create an AD FS Farm without domain admin privileges
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
AD FS OpenID Connect/OAuth Concepts
AD FS OpenID Connect/OAuth flows and Application Scenarios
Build a Custom Authentication Method for AD FS
Build Plug-ins with AD FS 2019 Risk Assessment Model
Single log-out for OpenID Connect with AD FS
ADAL
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 Page Application with AD FS
Build a native client application using OAuth public clients with AD FS
MSAL
Native app calling Web API
Web API calling Web API (On Behalf of Scenario)
Web app (server app) calling web APIs
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
AlwaysOn Availability Groups
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
Customize HTTP security response headers with AD FS
Delegate AD FS Powershell Commandlet Access to Non-Admin Users
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
SQL fine tuning and addressing latency
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
Active Directory Rights Management Service
Upgrading AD RMS to Windows Server 2016
Administrative tools and logon types reference
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
Solutions and Scenario Guides
3/5/2021 • 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 H O W C A N T H IS GUIDE H EL P Y O U
Secure access to company resources from any location on This guide shows how to allow employees to use personal
any device and 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.
Configuring Certificate Enrollment Web Service for certificate This article provides step-by-step instructions to implement
key-based renewal on a custom port the Certificate Enrollment Web Service (or Certificate
Enrollment Policy (CEP) / Certificate Enrollment Service (CES))
on a custom port other than 443 for certificate key-based
renewal to take advantage of the automatic renewal feature
of CEP and CES.
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

SC EN A RIO EVA L UAT E PLAN DEP LO Y O P ERAT E
Scenario: Central Dynamic Access Plan: A Central Deploy a Central - Modeling a central
Access Policy Control: Scenario Access Policy Access Policy access policy
Creating Central Overview Deployment (Demonstration
access policies for Deploy Claims - Process to map Steps)
files allow Across Forests a business Deploy Claims
organizations to request to a Across Forests
centrally deploy central access (Demonstration
and manage policy Steps)
authorization - Delegating of
policies that administration
include for Dynamic
conditional Access Control
expressions using - Exception
user claims, Mechanisms for
device claims, Planning Central
and resource Access Policies
properties. These
polices are based Best Practices for
on compliance Using User
and business Claims
regulatory - Choosing the
requirements. right
These policies are configuration to
created and enable claims in
hosted in Active your user
Directory, domain
therefore making - Operations to
it easier to enable user
manage and claims
deploy. - Considerations
Deploying for using user
Claims Across claims in the file
Forests server
discretionary
In Windows ACLs without
Server 2012 , the using Central
AD DS maintains Access Policies
a 'claims
dictionary' in Using Device
each forest and Claims and
all claim types in Device Security
use within the Groups
forest are defined - Considerations
at the Active for using static
Directory forest device claims
level. There are - Operations to
many scenarios enable device
where a principal claims
may need to
traverse a trust Tools for
boundary. This Deployment
scenario - Data
describes how a Classification
claim traverses a Toolkit
trust boundary.
Scenario: File Scenario: File Access Plan for File Access Deploy Security - Monitor the Central
Access Auditing Auditing Auditing Auditing with Central Access Policies that
Security auditing Audit Policies Apply on a File
is one of the (Demonstration Server
most powerful Steps) - Monitor the Central
tools to help Access Policies
maintain the Associated with Files
security of an and Folders
enterprise. One - Monitor the
of the key goals Resource Attributes
of security audits on Files and Folders
is regulatory - Monitor Claim
compliance. For Types
example, - Monitor User and
industry Device Claims During
standards such Sign-in
as Sarbanes - Monitor Central
Oxley, HIPAA, Access Policy and
and Payment Rule Definitions
Card Industry - Monitor Resource
(PCI) require Attribute Definitions
enterprises to - Monitor the Use of
follow a strict set Removable Storage
of rules related Devices.
to data security
and privacy.
Security audits
help 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 Assistance Denied Assistance Denied Assistance Denied Assistance
Today, when - Determine the (Demonstration
users try to access-denied Steps)
access a remote assistance model
file on the file - Determine who
server, the only should handle
indication that access requests
they would get is - Customize the
that access is access-denied
denied. This assistance
generates message
requests to - Plan for
helpdesk or IT exceptions
administrators - Determine how
that need to access-denied
figure out what assistance is
the issue is and deployed
often the
administrators
have a 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- Classification-Based classification-based Office Files
Based Encr yption Encryption for Office encryption of (Demonstration
for Office Documents documents Steps)
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 Insight Plan for Automatic Deploy Automatic

Scenario: Get Insight Plan for Automatic Deploy Automatic
Scenario: Get into
SC EN A RIO EVA LYour
UAT EData by File
P L A Classification
N File
DEP Classification
LO Y O P ERAT E
Insight into Your Using Classification (Demonstration
Data by Using 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 Servers Servers
File Ser vers (Demonstration
A retention Steps)
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
C O N T EN T T Y P E REF EREN C ES
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.
Depar tmental 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
Deploy a Central Access Policy (Demonstration Steps)
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.
RO L E/ F EAT URE H O W IT SUP P O RT S T H IS SC EN A RIO
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.
Deploy a Central Access Policy (Demonstration
Steps)
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:
P H A SE DESC RIP T IO N
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.
ST EP # ST EP EXA M P L E
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.
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.
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.
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 compound authentication and
Kerberos armoring. Kerberos 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 depar tment . This should
populate the Display name field with depar tment . 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 countr y .
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 Proper ties .
2. Right-click Resource Proper ties , click New , and then click Reference Resource Proper ty .
TIP
You can also choose a resource property from the Tasks pane. Click New and then click Reference Resource
Proper ty .
3. In Select a claim type to share its suggested values list , click countr y .
4. In the Display name field, type countr y , and then click OK .
5. Double-click the Resource Proper ties list, scroll down to the Depar tment resource property. Right-
click, and then click Enable . This will enable the built-in Depar tment resource property.
6. In the Resource Proper ties 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 ] [Depar tment ] [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 entr y for Permissions dialog box, click Select a principal , type Authenticated
Users , and then click OK .
7. In the Permission Entr y for Permissions dialog box, click Add a condition , and add the following
conditions: [User ] [countr y ] [Any of ] [Resource ] [countr y ] Click Add a condition . [And ] Click [User ]
[Depar tment ] [Any of ] [Resource ] [Depar tment ]. 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.

$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 Star t 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 , FileSer verOU .
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 Proper ties . 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 Suppor t for claims, compound authentication and Kerberos armoring . In the
KDC Suppor t for claims, compound authentication and Kerberos armoring dialog box, click
Enabled and select Suppor ted 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
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 Star t , type file ser ver
resource manager , and then click File Ser ver Resource Manager .
3. In the File Server Resource Manager, click File Classification Management , right-click Classification
Proper ties and then click Refresh .
4. Open Windows Explorer, and in the left pane, click drive D. Right-click the Finance Documents folder,
and click Proper ties .
5. Click the Classification tab, click Countr y , and then select US in the Value field.
6. Click Depar tment , 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
Proper ties .
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

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 suppor t 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
countr y 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 Proper ties .
5. In the Proposed Permissions section, select the Enable permission staging configuration check
box, click Edit , and then click Add . In the Permission Entr y 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 ] [countr y ] [Any of ] [Resource ]
[Countr y ].
7. Click Add a condition again, and add the following condition: [And ] [Device ] [countr y ] [Any of ]
[Resource ] [Countr y ]
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, Ser vice
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 4818 under 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).
Depar tmental 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 dictionar y . 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.
TA SK DESC RIP T IO N
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 Ser vers .
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 Ever yone , and then click OK .
12. In the Auditing Entr y 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 ]
[Depar tment ] [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 ser ver 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.
F EAT URE H O W IT SUP P O RT S T H IS SC EN A RIO
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 Ser ver
Resource Manager .
2. Right-click File Ser ver 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
Resource Manager .
2. Expand File Ser ver Resource Manager (Local) , and then click Classification Management .
3. Right-click Classification Proper ties , and then click Set Folder Management Proper ties .
4. In the Proper ty 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.
Resource Manager .
2. Right-click File Ser ver Resource Manager (Local) , and then click Configure Options .
3. Click the Email Notifications tab.
4. Configure the following settings:
In the SMTP ser ver 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
File Server Resource Manager 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. 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:
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 Proper ties .
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
Proper ty Lists , and then double-click Global Resource Proper ty 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 with the password pass@word1 .
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.
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 Proper ties , 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 proper ty to files , select
Content Classifier from the drop-down list.
11. Under Choose a proper ty 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 proper ty values , click Over write the
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 proper ty to files , select
Content Classifier from the drop-down list.
9. Under Choose a proper ty 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 Parameters window, 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 proper ty values , Over write the 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 Encr yption . 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 Proper ty , 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 Proper ties .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 Proper ties .
5. Click the Classification tab, and notice that the Personally Identifiable Information proper ty
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
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 Proper ties . 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 Proper ties .
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:
Practical applications
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
Director y Administrative Center .
3. Expand Dynamic Access Control , and then click Resource Proper ties .
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-
FsrmClassificationProper tyDefinition and then press ENTER. This will synchronize the property
definitions created on the domain controller to the file server.
Resource 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 proper ty to files box, ensure that Content Classifier is
selected.
In the Choose a proper ty 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 proper ty values check box, click
Over write 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.
FsrmClassificationProper tyDefinition , and then press ENTER. This will synchronize the property
definitions that are created on the domain controller to the file server.
Resource 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
7. On the Classification tab, configure the following:
In the Choose a method to assign a proper ty to files box, ensure that Content Classifier is
selected.
In the Choose a proper ty 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 proper ty values check box, click
Over write 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: Star t-
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 Proper ties .
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
Director y Administrative Center .
3. Expand Dynamic Access Control , and then click Resource Proper ties .
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
FsrmClassificationProper tyDefinition , and then press ENTER. This will synchronize the property
definitions that are created on the domain controller to the file server.
Resource Manager .
4. Right-click File Ser ver Resource Manager (local) , and then click Configure Options .
5. On the Email Notifications tab, configure the following:
In the SMTP ser ver 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
Resource 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
6. On the Action tab, in the Type box, click File expiration . In the Expiration director y 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 Proper ty list, click Discoverability . In the Operator list, click Not equal . In the Value list,
click Hold .
In the Proper ty 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 Proper ties .
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 Proper ties .
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 Proper ties .
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:
O B JEC T S DETA IL S
Users Jeff Low, Contoso
User claims on Adatum and Contoso ID: ad://ext/Company:ContosoAdatum,

Source attribute: company
Suggested values: Contoso, Adatum Impor tant: 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.
SC EN A RIO P O L IC Y
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 Director y : 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 cer tain type
Exact type
C1:[type=="XYZ"] => Issue (claim = C1);
Using Regex
C1: [type =~ "XYZ*"] => Issue (claim = C1);
Disallow a cer tain 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: POLICY0002: Could not parse policy data. 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:
POLICY0002: Could not parse policy data. 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:
POLICY0002: Could not parse policy data. 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.
ST RIN G T ERM IN A L
"=>" IMPLY
";" SEMICOLON
":" COLON
"," COMMA
"." DOT
"[" O_SQ_BRACKET
ST RIN G T ERM IN A L
"]" 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.
T ERM DEF IN IT IO N
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.
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 Star t , and then click Server Manager.

2. In the Roles Summary area of the Server Manager main window, click Add Roles .
3. On the Select Ser ver Roles page, click Hyper-V .
4. On the Create Vir tual 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 Vir tual Network Manager .
3. Under Create vir tual network , select the Internal .
4. Click Add . The New Vir tual 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
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 ser ver page, click Next .
6. On the Select ser ver roles page, click Active Director y Domain Ser vices . 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 Director y Domain Ser vices 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 ser ver 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:
GRO UP N A M E EM A IL A DDRESS
FinanceAdmin financeadmin@contoso.com
FinanceException financeexception@contoso.com
3. Create the following organizational unit (OU):
OU NAME C O M P UT ERS
FileServerOU FILE1
4. Create the following users with the attributes indicated:
EM A IL C O UN T RY / REGI
USER USERN A M E A DDRESS DEPA RT M EN T GRO UP ON
Myriam MDelesalle MDelesalle@co Finance US

Delesalle ntoso.com
Miles Reid MReid MReid@contos Finance FinanceAdmin US

o.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. HR US

com
EM A IL C O UN T RY / REGI
USER USERN A M E A DDRESS DEPA RT M EN T GRO UP ON
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 FileSer verOU . 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 suppor t 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 ser ver page, click Next .
5. On the Select Ser ver Roles page, expand File and Storage Ser vices , select the check-box next to File
and iSCSI Ser vices , expand, and select File Ser ver 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 Ser ver Resource Manager , and then
click Configure options . The File Ser ver 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 Salar y, Star ting Date, Super visor name,
Depar tment . Add an additional section in the document that has a form for Super visor
Signature, Approved Salar y, 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 Ser ver Targets screen, click Next .
6. On the Select Ser ver Roles screen, select the box next to Active Director y Rights Management
Ser vices , and then click Next .
7. In the Add features that are required for Active Director y Rights Management Ser vices?
dialog box, click Add Features .
8. On the Select Ser ver Roles screen, click Next .
9. On the Select Features to Install screen, click Next .
10. On the Active Director y Rights Management Ser vices screen, click Next.
11. On the Select Role Ser vices screen, click Next .
12. On the Web Ser ver Role (IIS) screen, click Next .
13. On the Select Role Ser vices 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 ser ver , 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 Ser vice 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 Cr yptographic Mode screen, click Cr yptographic 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 unencr ypted connection option, in the Fully
Qualified Domain Name box, type FILE1.contoso.com , and then click Next .
25. On the Licensor Cer tificate 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 Ser ver in the console tree, then click Tools ,
and then click Active Director y Rights Management Ser vices .
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
command prompt, type:
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 ser ver page, click Select a ser ver from the ser ver 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 Ser ver Roles page, click Active Director y Domain Ser vices . 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 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 ser ver to a domain controller link.
IMPORTANT
If you close the installation wizard at this point rather than click Promote this ser ver 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 Star t 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 Director y 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 Proper ties .
4. Select Company from the Resource Proper ties list, right-click and select Proper ties . 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 Proper ties 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 suppor t 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 Entr y 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.
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-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 Star t 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
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 Star t screen, type Group Policy Management , in the Search box. Open Group Policy
Management from the Administrative Tools folder.
TIP
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
Proper ties .
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.
Configuring Certificate Enrollment Web Service for
certificate key-based renewal on a custom port
Authors: Jitesh Thakur, Meera Mohideen, Technical Advisors with the Windows Group. Ankit Tyagi Support
Engineer with the Windows Group
Summary
This article provides step-by-step instructions to implement the Certificate Enrollment Policy Web Service (CEP)
and Certificate Enrollment Web Service (CES) on a custom port other than 443 for certificate key-based renewal
to take advantage of the automatic renewal feature of CEP and CES.
This article also explains how CEP and CES works and provides setup guidelines.
NOTE
The workflow that's included in this article applies to a specific scenario. The same workflow may not work for a different
situation. However, the principles remain the same.
Disclaimer: This setup is created for a specific requirement in which you do not want to use port 443 for the default
HTTPS communication for CEP and CES servers. Although this setup is possible, it has limited supportability. Customer
Services and Support can best assist you if you follow this guide carefully using minimal deviation from the provided web
server configuration.
Scenario
For this example, the instructions are based on an environment that uses the following configuration:
A Contoso.com forest that has an Active Directory Certificate Services (AD CS) public key infrastructure
(PKI).
Two CEP/CES instances that are configured on one server that’s running under a service account. One
instance uses username and password for initial enrollment. The other uses certificate-based
authentication for key-based renewal in renewal only mode.
A user has a workgroup or non-domain-joined computer for which he will be enrolling the computer
certificate by using username and password credentials.
The connection from the user to CEP and CES over HTTPS occurs on a custom port such as 49999. (This
port is selected from a dynamic port range and is not used as a static port by any other service.)
When the certificate lifetime is nearing its end, the computer uses certificate-based CES key-based
renewal to renew the certificate over the same channel.
Configuration instructions
Overview
1. Configure the template for key-based renewal.
2. As a prerequisite, configure a CEP and CES server for username and password authentication. In this
environment, we refer to the instance as "CEPCES01".
3. Configure another CEP and CES instance by using PowerShell for certificate-based authentication on the
same server. The CES instance will use a service account.
In this environment, we refer to the instance as “CEPCES02”. The service account that’s used is
”cepcessvc”.
4. Configure client-side settings.
Configuration
This section provides the steps to configure the initial enrollment.
NOTE
You can also configure any user service account, MSA, or GMSA for CES to work.
As a prerequisite, you must configure CEP and CES on a server by using username and password authentication.
Configure the template for key-based renewal
You can duplicate an existing computer template, and configure the following settings of the template:
1. On the Subject Name tab of the certificate template, make sure that the Supply in the Request and
Use subject information from existing cer tificates for autoenrollment renewal requests
options are selected.
2. Switch to the Issuance Requirements tab, and then select the CA cer tificate manager approval
check box.
3. Assign the Read and Enroll permission to the cepcessvc service account for this template.
4. Publish the new template on the CA.
NOTE
Make sure the compatibility settings on the template is set to Windows Ser ver 2012 R2 as there is a known issue in
which the templates are not visible if the compatibility is set to Windows Server 2016 or later version. For more
informaiton, see Cannot select Windows Server 2016 CA-compatible certificate templates from Windows Server 2016 or
later-based CAs or CEP servers.
Configure the CEPCES01 instance

St e p 1 : I n st a l l t h e i n st a n c e
To install the CEPCES01 instance, use either of the following methods.

Method 1
See the following articles for step-by-step guidance to enable CEP and CES for username and password
authentication:
Certificate Enrollment Policy Web Service Guidance
Certificate Enrollment Web Service Guidance
NOTE
Make sure that you do not select the “Enable Key-Based Renewal” option if you configure both CEP and CES instances of
username and password authentication.
Method 2
You can use the following PowerShell cmdlets to install the CEP and CES instances:
Import-Module ServerManager
Add-WindowsFeature Adcs-Enroll-Web-Pol
Add-WindowsFeature Adcs-Enroll-Web-Svc
Install-AdcsEnrollmentPolicyWebService -AuthenticationType Username -SSLCertThumbprint "sslCertThumbPrint"
This command installs the Certificate Enrollment Policy Web Service (CEP) by specifying that a username and
password is used for authentication.
NOTE
In this command, <SSLCer tThumbPrint > is the thumbprint of the certificate that will be used to bind IIS.
Install-AdcsEnrollmentWebService -ApplicationPoolIdentity -CAConfig "CA1.contoso.com\contoso-CA1-CA" -

SSLCertThumbprint "sslCertThumbPrint" -AuthenticationType Username
This command installs the Certificate Enrollment Web Service (CES) to use the certification authority for a
computer name of CA1.contoso.com and a CA common name of contoso-CA1-CA . The identity of the CES is
specified as the default application pool identity. The authentication type is username . SSLCertThumbPrint is
the thumbprint of the certificate that will be used to bind IIS.
St e p 2 C h e c k t h e I n t e r n e t I n fo r m a t i o n Se r v i c e s (I I S) M a n a g e r c o n so l e
After a successful installation, you expect to see the following display in the Internet Information Services (IIS)
Manager console.
Under Default Web Site , select ADPolicyProvider_CEP_UsernamePassword , and then open Application
Settings . Note the ID and the URI .
You can add a Friendly Name for management.
Configure the CEPCES02 instance
St e p 1 : I n st a l l t h e C E P a n d C E S fo r k e y - b a se d r e n e w a l o n t h e sa m e se r v e r.
Run the following command in PowerShell:
Install-AdcsEnrollmentPolicyWebService -AuthenticationType Certificate -SSLCertThumbprint

"sslCertThumbPrint" -KeyBasedRenewal
This command installs the Certificate Enrollment Policy Web Service (CEP) and specifies that a certificate is used
for authentication.
NOTE
In this command, <SSLCertThumbPrint> is the thumbprint of the certificate that will be used to bind IIS.
Key-based renewal lets certificate clients renew their certificates by using the key of their existing certificate for
authentication. When in key-based renewal mode, the service will return only certificate templates that are set
for key-based renewal.
Install-AdcsEnrollmentWebService -CAConfig "CA1.contoso.com\contoso-CA1-CA" -SSLCertThumbprint

"sslCertThumbPrint" -AuthenticationType Certificate -ServiceAccountName "Contoso\cepcessvc" -
ServiceAccountPassword (read-host "Set user password" -assecurestring) -RenewalOnly -AllowKeyBasedRenewal
This command installs the Certificate Enrollment Web Service (CES) to use the certification authority for a
computer name of CA1.contoso.com and a CA common name of contoso-CA1-CA .
In this command, the identity of the Certificate Enrollment Web Service is specified as the cepcessvc service
account. The authentication type is cer tificate . SSLCer tThumbPrint is the thumbprint of the certificate that
will be used to bind IIS.
The RenewalOnly cmdlet lets CES run in renewal only mode. The AllowKeyBasedRenewal cmdlet also
specifies that the CES will accept key based renewal requests for the enrollment server. These are valid client
certificates for authentication that do not directly map to a security principal.
NOTE
The service account must be part of IIS_IUSRS group on the server.
St e p 2 C h e c k t h e I I S M a n a g e r c o n so l e
After a successful installation, you expect to see the following display in the IIS Manager console.
Select KeyBasedRenewal_ADPolicyProvider_CEP_Cer tificate under Default Web Site and open

Application Settings . Take a note of the ID and the URI . You can add a Friendly Name for management.
NOTE
If the instance is installed on a new server double check the ID to make sure that the ID is the same one that was
generated in the CEPCES01 instance. You can copy and paste the value directly if it is different.
Complete Certificate Enrollment Web Services configuration

To be able to enroll the certificate on behalf of the functionality of CEP and CES, you have to configure the
workgroup’s computer account in Active Directory and then configure constrained delegation on the service
account.
St e p 1 : C r e a t e a c o m p u t e r a c c o u n t o f t h e w o r k g r o u p c o m p u t e r i n A c t i v e D i r e c t o r y
This account will be used for authentication towards key-based renewal and the “Publish to Active Directory”
option on the certificate template.
NOTE
You do not have to domain join the client machine. This account comes into picture while doing certificate based
authentication in KBR for dsmapper service.
St e p 2 : C o n fi g u r e t h e se r v i c e a c c o u n t fo r C o n st r a i n e d D e l e g a t i o n (S4 U 2 Se l f )
Run the following PowerShell command to enable constrained delegation (S4U2Self or any authentication
protocol):
Get-ADUser -Identity cepcessvc | Set-ADAccountControl -TrustedToAuthForDelegation $True

Set-ADUser -Identity cepcessvc -Add @{'msDS-
AllowedToDelegateTo'=@('HOST/CA1.contoso.com','RPCSS/CA1.contoso.com')}
NOTE
In this command, <cepcessvc> is the service account, and <CA1.contoso.com> is the Certification Authority.
IMPORTANT
We are not enabling the RENEWALONBEHALOF flag on the CA in this configuration because we are using constrained
delegation to do the same job for us. This lets us to avoid adding the permission for the service account to the CA’s
security.
St e p 3 : C o n fi g u r e a c u st o m p o r t o n t h e I I S w e b se r v e r
1. In the IIS Manager console, select Default Web Site.

2. In the action pane, select Edit Site Binding.
3. Change the default port setting from 443 to your custom port. The example screenshot shows a port
setting of 49999.
St e p 4 : Ed i t t h e C A e n r o l l m e n t se r v i c e s O b j e c t o n A c t i v e D i r e c t o r y
1. On a domain controller, open adsiedit.msc.

2. Connect to the Configuration partition, and navigate to your CA enrollment services object:
CN=ENTCA,CN=Enrollment Services,CN=Public Key
Services,CN=Services,CN=Configuration,DC=contoso,DC=com
3. Right click and edit the CA Object. Change the msPKI-Enrollment-Ser vers attribute by using the
custom port with your CEP and CES server URIs that were found in the application settings. For example:
140https://cepces.contoso.com:49999/ENTCA_CES_UsernamePassword/service.svc/CES0
181https://cepces.contoso.com:49999/ENTCA_CES_Certificate/service.svc/CES1
Configure the client computer

On the client computer, set up the Enrollment policies and Auto-Enrollment policy. To do this, follow these steps:
1. Select Star t > Run , and then enter gpedit.msc .
2. Go to Computer Configuration > Windows Settings > Security Settings , and then click Public
Key Policies .
3. Enable the Cer tificate Ser vices Client - Auto-Enrollment policy to match the settings in the
following screenshot.
4. Enable Cer tificate Ser vices Client - Cer tificate Enrollment Policy .
a. Click Add to add enrollment policy and enter the CEP URI with UsernamePassword that we edited in
ADSI.
b. For Authentication type , select Username/password .
c. Set a priority of 10 , and then validate the policy server.
NOTE
Make sure that the port number is added to the URI and is allowed on the firewall.
5. Enroll the first certificate for the computer through certlm.msc.

Select the KBR template and enroll the certificate.
6. Open gpedit.msc again. Edit the Cer tificate Ser vices Client – Cer tificate Enrollment Policy , and
then add the key-based renewal enrollment policy:
a. Click Add , enter the CEP URI with Cer tificate that we edited in ADSI.
b. Set a priority of 1 , and then validate the policy server. You will be prompted to authenticate and choose
the certificate we enrolled initially.
NOTE
Make sure that the priority value of the key-based renewal enrollment policy is lower than the priority of the Username
Password enrollment policy priority. The first preference is given to the lowest priority.
Testing the setup

To make sure that Auto-Renewal is working, verify that manual renewal works by renewing the certificate with
the same key using mmc. Also, you should be prompted to select a certificate while renewing. You can choose
the certificate we enrolled earlier. The prompt is expected.
Open the computer personal certificate store, and add the “archived certificates” view. To do this, add the local
computer account snap-in to mmc.exe, highlight Cer tificates (Local Computer) by clicking on it, click view
from the action tab at the right or the top of mmc, click view options , select Archived cer tificates , and then
click OK .
Method 1
Run the following command:
certreq -machine -q -enroll -cert <thumbprint> renew
Method 2
Advance the time and date on the client machine into the renewal time of the certificate template.
For example, the certificate template has a 2-day validity setting and an 8-hour renewal setting configured. The
example certificate was issued at 4:00 A.M. on 18th day of the month, expires at 4:00 A.M. on the 20th. The Auto-
Enrollment engine is triggered on restart and at every 8-hour interval (approximately).
Therefore, if you advance the time to 8:10 P.M. on the 19th since our renewal window was set to 8-hour on the
template, running Certutil -pulse (to trigger the AE engine) enrolls the certificate for you.
After the test finishes, revert the time setting to the original value, and then restart the client computer.
NOTE
The previous screenshot is an example to demonstrate that the Auto-Enrollment engine works as expected because the
CA date is still set to the 18th. Therefore, it continues to issue certificates. In a real-life situation, this large amount of
renewals will not occur.
References
Test Lab Guide: Demonstrating Certificate Key-Based Renewal
Certificate Enrollment Web Services
Install-AdcsEnrollmentPolicyWebService
Install-AdcsEnrollmentWebService
See also
Windows Server Security Forum
Active Directory Certificate Services (AD CS) Public Key Infrastructure (PKI) Frequently Asked Questions (FAQ)
Windows PKI Documentation Reference and Library
Windows PKI Blog
How to configure Kerberos Constrained Delegation (S4U2Proxy or Kerberos Only) on a custom service account
for Web Enrollment proxy pages
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
What's 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, tablets) 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
Applies To: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
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.
TO P IC DESC RIP T IO N
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 quer y 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 ser vice 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
Domain 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.
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 Ser ver 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
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 Proper ties .
6. Click Members , click Add , type test1;test2 , and then click OK .

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

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.
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.
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 Proper ties 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 to 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 needed 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 Proper ties in the Tasks pane.
5. Under Enforce password histor y , 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 Proper ties .
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 Histor y 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 Histor y 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 Director y 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 theFilter box)
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

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 Proper ties 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 Star t 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,systemFlag
s,userAccountControl,displayName,description,whenChanged,location,managedBy,memberOf,primaryGroupID,o
bjectSid,msDS-User-Account-Control-
Computed,sAMAccountName,lastLogonTimestamp,lastLogoff,mail,accountExpires,msDS-
PhoneticCompanyName,msDS-PhoneticDepartment,msDS-PhoneticDisplayName,msDS-PhoneticFirstName,msDS-
PhoneticLastName,pwdLastSet,operatingSystem,operatingSystemServicePack,operatingSystemVersion,telepho
neNumber,physicalDeliveryOfficeName,department,company,manager,dNSHostName,groupType,c,l,employeeID,g
ivenName,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:
ERRO R O P ERAT IO N
"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 Shown when trying to select a domain node in the Active
running 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
Safely virtualizing Active Directory Domain Services
(AD DS)
Applies To: Windows Server
Beginning with Windows Server 2012, AD DS provides greater support for virtualizing domain controllers by
introducing virtualization-safe capabilities. This article explains the role of USNs and InvocationIDs in Domain
Controller replication and discusses some potential issues that can occur.
Update sequence number and InvocationID

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.
Effects of USN rollback

When USN rollbacks occur, modifications to objects and attributes are not inbound replicated by destination
domain controllers that have previously seen the USN.
Because these destination domain controllers believe they are up to date, no replication errors are reported in
Directory Service event logs or by monitoring and diagnostic tools.
USN rollback may affect the replication of any object or attribute in any partition. The most frequently observed
side effect is that user accounts and computer accounts that are created on the rollback domain controller do
not exist on one or more replication partners. Or, the password updates that originated on the rollback domain
controller do not exist on replication partners.
A USN rollback can prevent any object type in any Active Directory partition from replicating. These object types
include the following:
The Active Directory replication topology and schedule
The existence of domain controllers in the forest and the roles that these domain controllers hold
The existence of domain and application partitions in the forest
The existence of security groups and their current group memberships
DNS record registration in Active Directory-integrated DNS zones
The size of the USN hole may represent hundreds, thousands, or even tens of thousands of changes to users,
computers, trusts, passwords, and security groups. The USN hole is defined by the difference between the
highest USN number that existed when the restored system state backup was made and the number of
originating changes that were created on the rolled-back domain controller before it was taken offline.
Detecting a USN rollback

Because a USN rollback is difficult to detect, a domain controller logs event 2095 when a source domain
controller sends a previously acknowledged USN number to a destination domain controller without a
corresponding change in the invocation ID.
To prevent unique originating updates to Active Directory from being created on the incorrectly restored
domain controller, the Net Logon service is paused. When the Net Logon service is paused, user and computer
accounts cannot change the password on a domain controller that will not outbound-replicate such changes.
Similarly, Active Directory administration tools will favor a healthy domain controller when they make updates
to objects in Active Directory.
On a domain controller, event messages that resemble the following are recorded if the following conditions are
true:
A source domain controller sends a previously acknowledged USN number to a destination domain
controller.
There is no corresponding change in the invocation ID.
These events may be captured in the Directory Service event log. However, they may be overwritten before they
are observed by an administrator.
If you suspect a USN rollback has occurred but do not see a corresponding event in the event logs, check for the
DSA Not Writable entry in the registry. This entry provides forensic evidence that a USN rollback has occurred.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Registry entry: Dsa Not Writable
Value: 0x4
WARNING
Deleting or manually changing the Dsa Not Writable registry entry value puts the rollback domain controller in a
permanently unsupported state. Therefore, such changes are not supported. Specifically, modifying the value removes the
quarantine behavior added by the USN rollback detection code. The Active Directory partitions on the rollback domain
controller will be permanently inconsistent with direct and transitive replication partners in the same Active Directory
forest.
More information on this registry key and resolution steps can be found in the support article Active Directory
Replication Error 8456 or 8457: "The source | destination server is currently rejecting replication requests".
Virtualization based safeguards

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).
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.
Recovering from a USN rollback

There are two approaches to recover from a USN rollback:
Remove the Domain Controller from the domain
Restore the system state of a good backup
Remove the Domain Controller from the domain
1. Remove Active Directory from the domain controller to force it to be a stand-alone server.
2. Shut down the demoted server.
3. On a healthy domain controller, clean up the metadata of the demoted domain controller.
4. If the incorrectly restored domain controller hosts operations master roles, transfer these roles to a healthy
domain controller.
5. Restart the demoted server.
6. If you are required to, install Active Directory on the stand-alone server again.
7. If the domain controller was previously a global catalog, configure the domain controller to be a global
catalog.
8. If the domain controller previously hosted operations master roles, transfer the operations master roles back
to the domain controller.
Restore the system state of a good backup
Evaluate whether valid system state backups exist for this domain controller. If a valid system state backup was
made before the rolled-back domain controller was incorrectly restored, and the backup contains recent
changes that were made on the domain controller, restore the system state from the most recent backup.
You can also use the snapshot as a source of a backup. Or you can set the database to give itself a new
invocation ID using the procedure in the section Restoring a virtual domain controller when an appropriate
system state data backup is not available
Next steps
For more troubleshooting information about virtualized domain controllers, see Virtualized Domain
Controller Troubleshooting.
Detailed information about Windows Time Service (W32Time)
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.
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 retr y 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).
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.
SUP P O RT S VIRT UA L IZ ED DO M A IN C O N T RO L L ERS A N D
VIRT UA L IZ AT IO N P RO DUC T VM GID
Microsoft Windows Ser ver 2012 ser ver with Hyper- Yes
V Feature
Microsoft Windows Ser ver 2012 Hyper-V Ser ver Yes
Microsoft Windows 8 with Hyper-V Client Feature Yes
Windows Ser ver 2008 R2 and Windows Ser ver 2008 No
Non-Microsoft vir tualization 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, vir tualized 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 Proper ties , 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 Director y Administrative Center , right-click the domain head, click Proper ties , 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.
A C T IVEDIREC TO RY
C M DL ET
A RGUM EN T S EXP L A N AT IO N
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.
A C T IVEDIREC TO RY
A RGUM EN T S EXP L A N AT IO N
C M DL ET
-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.
-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 Expor t .
2. Select an existing folder as the export container.
3. Wait for the Status column to stop showing Expor ting .
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:
1. DSA Working Directory
2. %windir%\NTDS
3. Removable read/write media, in order of drive letter, at the root of the drive
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)
2. DSA Working Directory
3. %windir%\NTDS
4. Removable read/write media, in order of drive letter, at the root of the drive
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
"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

"2002:4898:e0:31fc:d61:2b0a:c9c9:2ccc" -Path F:\Windows\NTDS
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 Impor t Vir tual Machine
2. On the Locate Folder page, select the exported VM definition file using the Browse button
3. On the Select Vir tual Machine page, click the source computer.
4. On the Choose Impor t Type page, click Copy the vir tual 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.
SO URC E H Y P ERVISO R TA RGET H Y P ERVISO R 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
Install a new Active Directory forest using Azure CLI
AD DS can run on an Azure virtual machine (VM) in the same way it runs in many on-premises instances. This
article walks you through deploying a new AD DS Forest, on two new domain controllers, in an Azure
availability set using the Azure portal and Azure CLI. Many customers find this guidance helpful when creating a
lab or preparing to deploy domain controllers in Azure.
Components
A resource group to put everything in.
An Azure Virtual Network, subnet, network security group, and rule to allow RDP access to VMs.
An Azure virtual machine availability set to put two Active Directory Domain Services (AD DS) domain
controllers in.
Two Azure virtual machines to run AD DS and DNS.
Items that are not covered
Creating a site-to-site VPN connection from an on-premises location
Securing network traffic in Azure
Designing the site topology
Planning operations master role placement
Deploying Azure AD Connect to synchronize identities to Azure AD
Build the test environment

We use the Azure portal and Azure CLI for creating the environment.
The Azure CLI is used to create and manage Azure resources from the command line or in scripts. This tutorial
details using the Azure CLI to deploy virtual machines running Windows Server 2019. Once deployment is
complete, we connect to the servers and install AD DS.
If you don't have an Azure subscription, create a free account before you begin.
Using Azure CLI
The following script automates the process of building two Windows Server 2019 VMs, for the purpose of
building domain controllers for a new Active Directory Forest in Azure. An administrator can modify the
variables below to suit their needs, then complete, as one operation. The script creates the necessary resource
group, network security group with a traffic rule for Remote Desktop, virtual network and subnet, and
availability group. The VMs are each then built with a 20 GB data disk with caching disabled for AD DS to be
installed to.
The script below can be run directly from the Azure portal. If you choose to install and use the CLI locally, this
quickstart requires that you are running the Azure CLI version 2.0.4 or later. Run az --version to find the
version. If you need to install or upgrade, see Install Azure CLI 2.0.
VA RIA B L E N A M E P URP O SE
AdminUsername Username to be configured on each VM as the local

administrator.
VA RIA B L E N A M E P URP O SE
AdminPassword Cleartext password to be configured on each VM as the local

administrator password.
ResourceGroupName Name to be used for resource group. Should not duplicate

an existing name.
Location Azure location name that you would like to deploy to. List
supported regions for the current subscription using
az account list-locations .
VNetName Name to assign the Azure virtual network Should not

duplicate an existing name.
VNetAddress IP scope to use for Azure networking. Should not duplicate

an existing range.
SubnetName Name to assign the IP subnet. Should not duplicate an

existing name.
SubnetAddress Subnet address for the domain controllers. Should be a

subnet inside of the VNet.
AvailabilitySet Name of the availability set the domain controller VMs will
join.
VMSize Standard Azure VM Size available in the location for

deployment.
DataDiskSize Size in GB for the data disk where AD DS installs.
DomainController1 Name of first domain controller.
DC1IP IP address for first domain controller.
DomainController2 Name of second domain controller.
DC2IP IP address for second domain controller.
#Update based on your organizational requirements

Location=westus2
ResourceGroupName=ADonAzureVMs
NetworkSecurityGroup=NSG-DomainControllers
VNetName=VNet-AzureVMsWestUS2
VNetAddress=10.10.0.0/16
SubnetName=Subnet-AzureDCsWestUS2
SubnetAddress=10.10.10.0/24
AvailabilitySet=DomainControllers
VMSize=Standard_DS1_v2
DataDiskSize=20
AdminUsername=azureuser
AdminPassword=ChangeMe123456
DomainController1=AZDC01
DC1IP=10.10.10.11
DomainController2=AZDC02
DC2IP=10.10.10.12
# Create a resource group.
az group create --name $ResourceGroupName \
--location $Location
# Create a network security group

az network nsg create --name $NetworkSecurityGroup \
--resource-group $ResourceGroupName \
# Create a network security group rule for port 3389.

az network nsg rule create --name PermitRDP \
--nsg-name $NetworkSecurityGroup \
--priority 1000 \
--access Allow \
--source-address-prefixes "*" \
--source-port-ranges "*" \
--direction Inbound \
--destination-port-ranges 3389
# Create a virtual network.

az network vnet create --name $VNetName \
--address-prefixes $VNetAddress \
--location $Location \
# Create a subnet
az network vnet subnet create --address-prefix $SubnetAddress \
--name $SubnetName \
--vnet-name $VNetName \
--network-security-group $NetworkSecurityGroup
# Create an availability set.

az vm availability-set create --name $AvailabilitySet \
# Create two virtual machines.

az vm create \
--availability-set $AvailabilitySet \
--name $DomainController1 \
--size $VMSize \
--image Win2019Datacenter \
--admin-username $AdminUsername \
--admin-password $AdminPassword \
--data-disk-sizes-gb $DataDiskSize \
--data-disk-caching None \
--nsg $NetworkSecurityGroup \
--private-ip-address $DC1IP \
--no-wait
az vm create \
--availability-set $AvailabilitySet \
--name $DomainController2 \
--size $VMSize \
--image Win2019Datacenter \
--admin-username $AdminUsername \
--admin-password $AdminPassword \
--data-disk-sizes-gb $DataDiskSize \
--data-disk-caching None \
--nsg $NetworkSecurityGroup \
--private-ip-address $DC2IP
DNS and Active Directory
If the Azure virtual machines created as part of this process will be an extension of an existing on-premises
Active Directory infrastructure, the DNS settings on the virtual network must be changed to include your on-
premises DNS servers before deployment. This step is important to allow the newly created Domain Controllers
in Azure to resolve on-premises resources and allow for replication to occur. More information about DNS,
Azure, and how to configure settings can be found in the section Name resolution that uses your own DNS
server.
After promoting the new domain controllers in Azure, they will need to be set to the primary and secondary
DNS Servers for the virtual network, and any on-premises DNS Servers would be demoted to tertiary and
beyond. More information on changing DNS Servers can be found in the article Create, change, or delete a
virtual network.
Information about extending an on-premises network to Azure can be found in the article Creating a site-to-site
VPN connection.
Configure the VMs and install Active Directory Domain Services

After the script completes, browse to the Azure portal, then Vir tual machines .
Configure the first Domain Controller
Connect to AZDC01 using the credentials you provided in the script.
Initialize and format the data disk as F:
Open the Start menu and browse to Computer Management
Browse to Storage > Disk Management
Initialize the disk as MBR
Create a New Simple Volume and Assign the drive letter F: you can provide a Volume label if you wish
Install Active Directory Domain Services using Server Manager
Promote the domain controller as the first in a new forest
Leave Domain Name System (DNS) server and Global Catalog (GC) checked on the Domain Controller
Options page
Specify a Directory Services Restore Mode password based on your organizational requirements
Change the paths from C: to point to the F: drive we created when prompted for their location
Review the selections made in the wizard and choose Next
NOTE
The Prerequisites Check will warn you that the physical network adapter does not have static IP address(es) assigned, you
can safely ignore this as static IPs are assigned in the Azure virtual network.
Choose Install
When the wizard completes the install process, the VM reboots.
When the VM has completed rebooting, log back in with the credentials used before, but this time as a member
of the domain you created.
NOTE
The first logon after promotion to a domain controller may take longer than normal and this is OK. Grab a cup of tea,
coffee, water, or other beverage of choice.
Azure virtual networks do now support IPv6 , but in case you want to set your VMs to prefer IPv4 over IPv6,
information on how to complete this task can be found in the KB article Guidance for configuring IPv6 in
Windows for advanced users.
Configure DNS
After promoting the first server in Azure, the servers will need to be set to the primary and secondary DNS
Servers for the virtual network, and any on-premises DNS Servers would be demoted to tertiary and beyond.
More information on changing DNS Servers can be found in the article Create, change, or delete a virtual
network.
Configure the second Domain Controller
Connect to AZDC02 using the credentials you provided in the script.
Initialize and format the data disk as F:
Open the Start menu and browse to Computer Management
Browse to Storage > Disk Management
Initialize the disk as MBR
Create a New Simple Volume and Assign the drive letter F: (you can provide a Volume label if you
wish)
Install Active Directory Domain Services using Server Manager
Promote the domain controller
Add a domain controller to an existing domain - CONTOSO.com
Supply credentials to perform the operation
Change the paths from C: to point to the F: drive we created when prompted for their location
Ensure Domain Name System (DNS) server and Global Catalog (GC) are checked on the Domain
Controller Options page
Specify a Directory Services Restore Mode password based on your organizational requirements
Review the selections made in the wizard and choose Next
NOTE
The Prerequisites Check will warn you that the physical network adapter does not have static IP address(es) assigned. You
can safely ignore this, as static IPs are assigned in the Azure virtual network.
Choose Install
When the wizard completes the install process, the VM reboots.
When the VM has completed rebooting, log back in with the credentials used before, but this time as a member
of the CONTOSO.com domain
Azure virtual networks do now support IPv6, but in case you want to set your VMs to prefer IPv4 over IPv6,
information on how to complete this task can be found in the KB article Guidance for configuring IPv6 in
Windows for advanced users.
Wrap up
At this point, the environment has a pair of domain controllers, and we have configured the Azure virtual
network so that additional servers may be added to the environment. Post-install tasks for Active Directory
Domain Services, like configuring sites and services, auditing, backup, and securing the built-in administrator
account, should be completed at this point.
Removing the environment

To remove the environment, when you have completed testing, the resource group we created above can be
deleted. This step removes all of the components that are part of that resource group.
Remove using the Azure portal
From the Azure portal, browse to Resource groups and choose the resource group we created (in this example
ADonAzureVMs), then select Delete resource group . The process asks for confirmation before deleting all the
resources contained inside of the resource group.
Remove using the Azure CLI
From Azure CLI run the following command:
az group delete --name ADonAzureVMs
Next steps
Safely virtualizing Active Directory Domain Services (AD DS)
Azure AD Connect
Backup and recovery
Site to site VPN connectivity
Monitoring
Security and policy
Maintenance and updates
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 vir tualization
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.
M A C H IN E C O N F IGURAT IO N 1 C O N F IGURAT IO N 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.
M EA SUREM EN T T EST P H Y SIC A L VIRT UA L DELTA
Searches/sec Search for 11508 10276 -10.71%

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

of 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 1438 1374 -4.45%

binds/sec binds (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 Director y Ser vices 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 suppor ted 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 Star t , 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\Ser vices\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 entr y 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 Star t , click Control
Panel , double-click Administrative Tools , and then double-click Event Viewer .
8. Expand Application and Ser vices Logs , and then click the Director y Ser vices log. Ensure that events
appear in the details pane.
9. Right-click the Director y Ser vices 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.
O P ERAT IO N LO G
Cloning - Event viewer\Windows logs\System

- Event viewer\Applications and services logs\Directory
Service
- %systemroot%\debug\dcpromo.log
Promotion - %systemroot%\debug\dcpromo.log
Service
- 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
Director y 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
EVEN T S DESC RIP T IO N
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.
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.
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 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,
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,
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
requests to the local 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
into DSRM 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
into DSRM 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)
read-only domain 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
read-only domain 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
\NTDS\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 party application that may be blocking
privilege usage.
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 party application that may be blocking
privilege usage.
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 C LO N IN G FA IL S, DSRM
Symptoms Clone boots into Directory Services Restore Mode

ISSUE C LO N IN G FA IL S, DSRM
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 EXT RA IP L EA SES W H EN USIN G DH C P TO C LO N E
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 C LO N IN G FA IL S IN TO DSRM A F T ER VERY LO N G DEL AY
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.
C LO N IN G DO ES N OT REC REAT E A L L SERVIC E P RIN C IPA L

ISSUE N A M ES
C LO N IN G DO ES N OT REC REAT E A L L SERVIC E P RIN C IPA L
ISSUE N A M ES
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.
C LO N IN G FA IL S, B O OT S IN TO DSRM , GEN ERA L

ISSUE N ET W O RK IN G ERRO RS
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
C LO N IN G FA IL S, B O OT S IN TO DSRM A S A DUP L IC AT E O F
ISSUE T H E SO URC E DC
C LO N IN G FA IL S, B O OT S IN TO DSRM A S A DUP L IC AT E O F
ISSUE T H E SO URC E 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 C LO N IN G FA IL S, B O OT S IN TO DSRM , ERRO R 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.
C LO N IN G FA IL S, B O OT S IN TO DSRM , GEN ERA L

ISSUE N ET W O RK IN G ERRO RS
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 C LO N IN G FA IL S, B O OT S IN TO DSRM
Symptoms Clone boots into Directory Services Repair Mode

ISSUE C LO N IN G FA IL S, B O OT S IN TO DSRM
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:DCCloneC
onfig">
N O LO GO N SERVERS A RE AVA IL A B L E ERRO R LO GGIN G IN TO

ISSUE DSRM
Symptoms Clone boots into Directory Services Repair Mode. You

attempt to logon and receive error:
There are currently no logon ser vers are
available to ser vice 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 C LO N E SO URC E FA IL S IN TO DSRM , ERRO R
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.
N EW - A DDC C LO N EC O N F IGF IL E ERRO R " IN DEX WA S O UT O F

ISSUE RA N GE"
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 C LO N IN G FA IL S, DUP L IC AT E 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.
N EW - A DDC C LO N EC O N F IGF IL E FA IL S W IT H T H E SERVER IS

N OT O P ERAT IO N A L ERRO R W H EN IT C H EC K S IF T H E
SO URC E DO M A IN C O N T RO L L ER IS A M EM B ER O F T H E
C LO N EA B L E DO M A IN C O N T RO L L ERS GRO UP IF A GC IS N OT
ISSUE AVA IL A B L E.
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.
EVEN T ID SO URC E M ESSA GE

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\Service
s\Netlogon\Parameters
Registry Value:
UseDynamicDns
Registry Value data:
0
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:
s\Dnscache\Parameters
Registry Value:
RegistrationEnabled
0
"Information 2/7/2012 3:12:49 PM
Microsoft-Windows-
ActiveDirectory_DomainService
2191 Internal Configuration"
set the following registry value to
disable DNS updates.
Registry Key:
s\Tcpip\Parameters
Registry Value:
DisableDynamicUpdate
1
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 Active
Directory Domain Services
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.
Directory Domain Services-aware
backup application.
1000 ActiveDirectory_DomainService Microsoft Active Directory Domain

Services startup complete.
1394 ActiveDirectory_DomainService All problems preventing updates to

the Active Directory Domain Services
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, [2] 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.016, [2] 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.000, [2] 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.031, [2] 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.

as follows:
backup application.
1168 ActiveDirectory_DomainService Internal error: An Active Directory

Domain Services error has occurred.
Additional Data
Error value (decimal):
2
Error value (hexadecimal):
2
Internal ID:
7011658
1110 ActiveDirectory_DomainService 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

engine stopped the instance (0).
Dirty Shutdown: 0
0.000, [2] 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:
6
1000 ActiveDirectory_DomainService Microsoft Active Directory Domain

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

the Active Directory Domain Services
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:
0
Previous property USN:
0
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\
Netlogon.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.201
20207-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.
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] 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] 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 command prompt, type:
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
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
into instead of replicating the file
from some other replicating
partner.
Space can be recovered at any
time by deleting the files in
."
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

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"".
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.
O P ERAT IO N LO G
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
- Event viewer\Applications and services logs\File Replication
Service
- Event viewer\Applications and services logs\DFS Replication
- 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
EVEN T DESC RIP T IO N
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
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
state. needed to initialize a non-authoritative restore on
the local SYSVOL replica. This was done by stopping the
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
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
the local SYSVOL replica. This is done by stopping the
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
hosts 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
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.
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.
C A N N OT C REAT E N EW SEC URIT Y P RIN C IPA L S O N REC EN T LY

ISSUE SA F E RESTO RED DO M A IN C O N T RO L L ER
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.
RESTO RED DO M A IN C O N T RO L L ERS DO N OT SH A RE SY SVO L ,

ISSUE A DVERT ISE
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
RESTO RED DO M A IN C O N T RO L L ERS DO N OT SH A RE SY SVO L ,
ISSUE A DVERT ISE
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 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.
Directory 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
snapshot, after a virtual machine
import 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
snapshot, after a virtual machine
import operation, or after a live
migration operation.

as follows:
backup 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

virtual machine that hosts the domain
controller was reverted to a previous
state. Active Directory Domain
Services has finished replication to
bring the domain controller current.

stopped the FRS or DFSR service used
to replicate the SYSVOL folder.
Service name:
DFSR
Active Directory detected that the
virtual machine that hosts the
domain controller was reverted to
a previous state. Active Directory
Domain Services 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.
Domain Services 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
Domain Services 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.

the stopped state.

the 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, [2] 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, [2] 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

Information\DFSR\database\dfsr.db:
The database engine created a new
database (1, \\.\C:\System Volume
Information\DFSR\database\dfsr.db).
(Time=0 seconds)
0.000, [2] 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.

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.
Share
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".
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
appear.
controllers."
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
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 other replicating
partner.
In some cases, the File Replication
Service may copy a file from
into instead of replicating the file
from some other replicating
partner.
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:
(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 ""
13554 NTFRS The File Replication Service successfully

added the connections shown below
to the replica set:
(SYSVOL 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.000, [2] 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, [2] 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, [2] 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, [2] 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, [2] 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, [2] 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, [2] 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.016, [2] 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.000, [2] 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.
Impor t/Expor t - 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
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.
P L A N N ED FA ILO VER UN P L A N N ED FA ILO VER
Supported Supported
Test case: The test case is the same as for a planned failover, with these
- DC1 and DC2 are running Windows Server 2012. exceptions:
- Any AD updates received on DC2 but not yet
- DC2 is shut down and a failover is performed on DC2- replicated by AD to a replication partner before the
Rec. The failover can be either planned or unplanned. failover event will be lost.
- After DC2-Rec starts, it checks whether the value of - AD updates received on DC2 after the time of the
VMGenID that it has in its database is the same as the recovery point that were replicated by AD to DC1 will be
value from the virtual machine driver saved by the replicated from DC1 back to DC2-Rec.
Hyper-V Replica 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.
Supported but not recommended because DCs that run Not supported
these versions of Windows Server do not support VMGenID Note: Unplanned failover would be supported where
or use associated virtualization safeguards. This places them USN rollback is not a risk, such as a single DC in the
at risk for USN rollback. For more information, see USN and forest (a configuration that is not recommended).
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 Active Directory in
Exchange Server organizations.
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 Guide: Migrating and Restructuring Active Directory Domains.
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.
A D DS DESIGN A N D DEP LO Y IN G A D DS IN A DEP LO Y IN G A D DS IN A

DEP LO Y M EN T DEP LO Y IN G A D DS IN A W IN DO W S SERVER 2003 W IN DO W S 2000
REQ UIREM EN T S N EW O RGA N IZ AT IO N O RGA N IZ AT IO N O RGA N IZ AT IO N
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 Yes No No

Server 2008 Forest Root
Domain
Deploying Windows Server Yes Yes Yes

2008 Regional Domains
A D DS DESIGN A N D DEP LO Y IN G A D DS IN A DEP LO Y IN G A D DS IN A
DEP LO Y M EN T DEP LO Y IN G A D DS IN A W IN DO W S SERVER 2003 W IN DO W S 2000
REQ UIREM EN T S N EW O RGA N IZ AT IO N O RGA N IZ AT IO N O RGA N IZ AT IO N
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 Windows Server 2008
before you set the domain before you set the domain
or forest functional level to or forest functional level to
Windows Server 2008. Windows Server 2008.
Upgrading Active Directory No Yes Yes

Domains to Windows
Server 2008 and Windows
Server 2008 R2 AD DS
Domains
ADMT Guide: Migrating Yes, if you want to migrate Yes, if you want to merge Yes, if you want to merge
and Restructuring Active a pilot domain into your with another organization with another organization
Directory Domains production environment, and consolidate the two IT and consolidate the two IT
merge with another infrastructures or infrastructures or
organization and consolidate resource and consolidate resource and
consolidate the two account domains that you account domains that you
information technology (IT) upgraded in place from upgraded in place from
infrastructures, or Windows 2000 or Windows Windows 2000 or Windows
consolidate resource and Server 2003 environments. Server 2003 environments.
account domains that you
upgraded in place from
Windows 2000 or Windows
Server 2003 environments.
ADMT Guide: Migrating No Yes, if you need to reduce Yes, if you need to reduce
and Restructuring Active the number of domains, the number of domains,
Directory Domains reduce replication traffic reduce replication traffic
and the amount of required and the amount of required
user and group user and group
administration, or simplify administration, or simplify
the administration of Group the administration of Group
Policy. 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.
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 Guide: Migrating
and Restructuring Active Directory Domains.
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.
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 Guide: Migrating and Restructuring Active Directory Domains.
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 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
2003 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 maintaining a directory that is available both internally and externally (such as
those publicly accessible to 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:
Ser vice 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:
Ser vice 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.
L IM IT ED DATA SERVIC E SERVIC E

SC EN A RIO C O N N EC T IVIT Y DATA ISO L AT IO N A UTO N O M Y ISO L AT IO N A UTO N O M Y
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
L IM IT ED DATA SERVIC E SERVIC E
SC EN A RIO C O N N EC T IVIT Y DATA ISO L AT IO N A UTO N O M Y ISO L AT IO N A UTO N O M Y
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
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 non-restricted 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
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
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.
T Y P E O F SERVIC E M A N A GEM EN T A SSO C IAT ED TA SK S
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
T Y P E O F SERVIC E M A N A GEM EN T A SSO C IAT ED TA SK S
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.
C O ST IM P L IC AT IO N S
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 Group Policy settings that need to be applied forest-wide
are 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 AD DS Fine-Grained Password and Account
Lockout Policy Step-by-Step Guide.
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.
SLO W EST L IN K M A XIM UM N UM B ER O F M A XIM UM N UM B ER O F M A XIM UM N UM B ER O F

C O N N EC T IN G A DO M A IN USERS IF 1- P ERC EN T USERS IF 5- P ERC EN T USERS IF 10- P ERC EN T
C O N T RO L L ER ( K B P S) B A N DW IDT H IS AVA IL A B L E B A N DW IDT H IS AVA IL A B L E B A N DW IDT H IS AVA IL A B L E
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
domains.
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:

of 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
domains.

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:

of 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
2003 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 ADMT Guide:
Migrating and Restructuring Active Directory Domains.
For a worksheet to assist you in documenting your plans for new and upgraded domains, download
2003 Deployment Kit 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.
RUL E EXP L A N AT IO N
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 A-Z, a-z, 0-9, and (-), but not entirely numerical.
only.
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 Deployment
and operation of Active Directory domains that are configured by using single-label DNS names.
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
2003 Deployment Kit 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 Deployment and operation of Active Directory
domains that are configured by using single-label DNS names. 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.
RUL E EXP L A N AT IO N
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 A-Z, a-z, 0-9, and (-), but not entirely numerical.
only.
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
2003 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. For more information about how DNS
supports AD DS, see the DNS Support for Active Directory Technical Reference.
In this section
DNS and AD DS
Integrating AD DS into an Existing DNS Infrastructure
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 OUs.
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.
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.
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, The SPN does not appear in the list of services that can be
delegated to an account when you try to configure constrained delegation on a computer that is
running Windows Server 2003 (404).
If you want to delegate permissions to modify SPNs to subordinate administrators, see Delegating
Authority to Modify SPNs.
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, How to enable LDAP over SSL with a third-party certification authority.
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
Lightweight Directory Access Protocol (LDAP) over Secure Sockets Layer (SSL) (LDAPS) authentication for
Windows Server 2003, see article 938703 in the Microsoft Knowledge Base, How to troubleshoot LDAP over SSL
connection problems.
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.
Integrating AD DS into an Existing DNS
Infrastructure
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 EL EM EN T C O N F IGURAT IO N
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 IP V4 A DDRESS IP V6 A DDRESS
Forwarding
NAME IP V4 A DDRESS IP V6 A DDRESS P H Y SIC A L LO C AT IO N
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
2003 Deployment Kit 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.
W EL L - K N O W N USERS A N D GRO UP S B UILT - IN A C C O UN T S
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 P URP O SE
Users Contains user accounts for nonadministrative personnel.

OU P URP O SE
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.
For more information about delegated authentication and constrained delegation, see Delegating
authentication.
For more information about configuring firewalls for use with AD DS, see Active Directory in Networks
Segmented by Firewalls.
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 ADMT Guide:
Migrating and Restructuring Active Directory Domains.
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.
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.
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.
For more information about how to delegate permissions to modify SPNs to subordinate administrators,
see Delegating Authority to Modify SPNs.
For more information about domain controller certificate requirements, see article 321051 in the
Microsoft Knowledge Base, How to enable LDAP over SSL with a third-party certification authority.
For more information about Lightweight Directory Access Protocol (LDAP) over Secure Sockets Layer
(SSL) (LDAPS) authentication for Windows Server 2003, see article 938703 in the Microsoft Knowledge
Base, How to troubleshoot LDAP over SSL connection problems.
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.
For more information about fine-grained password and account lockout policies, see the AD DS Fine-
Grained Password and Account Lockout Policy Step-by-Step Guide.
For more information about naming conventions in AD DS, see article 909264 in the Microsoft
Knowledge Base, Naming conventions in Active Directory for computers, domains, sites, and OUs.
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.
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 a 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
(https://go.microsoft.com/fwlink/?LinkID=93578).
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 2008 RODCs, the normal functioning of the KCC provides some rebalancing. 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\Ser vices\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. For information about how to deploy an RODC, see the Read-Only Domain Controllers
Step-by-Step Guide
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
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
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.
N ET W O RK T Y P E SP EED
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 logarithm of the available bandwidth, as measured in Kbps.
AVA IL A B L E B A N DW IDT H ( K B P S) C O ST
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 Tr y 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 Tr y 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 Tr y 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 Tr y 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 Tr y 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 Tr y 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 Tr y 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 Tr y 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 Tr y 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:
WA SH IN GTO N ,
SIT ES SEAT T L E B O STO N LO S A N GEL ES N EW Y O RK 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.
WA SH IN GTO N ,
SIT ES SEAT T L E B O STO N LO S A N GEL ES N EW Y O RK 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 websites:
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.
For more information about spanning trees and Active Directory replication topology, see Active
Directory Replication Topology Technical Reference.
For more information about using Adlb.exe and managing environments that have 100 or more branch
sites, see Review Bridgehead Server Load-Balancing Improvements with Windows Server 2008 RODCs.
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.
For more information about shortcut trusts between domains, see Understanding When to Create a
Shortcut Trust.
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 AD DS Design and Planning.
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.
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.
For more information about read-only domain controller (RODC) features, see AD DS: Read-Only Domain
Controllers.
For information about how to deploy an RODC, see the Read-Only Domain Controllers Step-by-Step
Guide.
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).
LO C AT IO N N ET W O RK SUB N ET P REF IX
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
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 Server 2003, 2008, and 2008 R2, these domain controllers (DCs) need to be
updated to Windows Server 2012, 2012 R2, 2016, or 2019. As a result, any domain controller that runs
Windows Server 2008 R2 and older 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 2016 RS1 is the last
Windows Server release that includes FRS.
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 2008
functional level. The domain also has to use DFS-R as the engine to replicate SYSVOL.
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 2016
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 and Windows Server 2008 R2 AD DS Domains.
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.
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
Domains.
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, Known issues that may occur when you use ADMT 3.1 to migrate to a domain that
contains Windows Server 2008 R2 domain controllers.
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.
For more information about upgrading an Active Directory domain to Windows Server 2008, see
Domains.
For more information about deploying AD DS, see the Step-by-Step Guide for Windows Server 2008 AD
DS Installation and Removal Step-by-Step Guide.
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.com 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 expor t 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 smar t card credentials fails if the target
ser ver 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).
Upgrade Domain Controllers to Windows Server
2016

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 the 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
IN STA L L AT IO N A C T IO N C REDEN T IA L REQ UIREM EN T S
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 Y O U A RE RUN N IN G T H IS EDIT IO N : Y O U C A N UP GRA DE TO T H ESE EDIT IO N S:
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 Ser ver Manager , under Add Roles and Features , install Active Director y Domain Ser vices on
the new Windows Server 2016. This will automatically run adprep on the 2012 R2 forest and domain.
4. In Ser ver Manager , click the yellow triangle, and from the drop-down click Promote the ser ver 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 Director y Ser vices 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 Ser ver Manager , under tools, select Active Director y
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 Ser ver Manager ,
under tools , select Active Director y 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 Windows Server 2016.
Next Steps
Windows Server 2016 Functional Levels
Upgrade Domain Controllers to Windows Server
2012 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)
Windows Server 2012 forum about domain controllers
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.
F EAT URE DESC RIP T IO N
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.
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).
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.
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 Supports the creation and management of Active Directory
PowerShell 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-restar t 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.
SC EN A RIO REC O M M EN DED C O N F IGURAT IO N ( S)
WSUS managed Set machines to auto-install, prevent auto-reboot until

- Install updates once per week desired time
- 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
- Stagger installs across different hours/days should be updated together
Use above steps for previous scenario
Set different deadlines for different target groups
Not WSUS-managed - no suppor t for deadlines Policy : Configure Automatic Updates (Enabled)
- Stagger installs at different times Configure automatic updating: 4 - Auto download and
schedule the install
Registr y 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 How to
reduce your chances of being prompted to restart your computer.
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 described in the page How to prevent
Windows from storing a LAN manager hash of your password in Active Directory and local SAM
databases.
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:
W IN DO W S SERVER 2012
EN C RY P T IO N T Y P E O R W IN DO W S SERVER 2008 A N D W IN DO W S SERVER
P O L IC Y DEFA ULT 2008 R2 DEFA ULT C O M M EN T
W IN DO W S SERVER 2012
EN C RY P T IO N T Y P E O R W IN DO W S SERVER 2008 A N D W IN DO W S SERVER
P O L IC Y DEFA ULT 2008 R2 DEFA ULT C O M M EN T
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/f
wlink/?LinkId=164558).
DES Enabled Disabled Article 977321 in the

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

Integrated Authentication Advisory (937811)
wlink/?LinkId=164559) and
article 976918 in the
wlink/?LinkId=178251).
Review and install the
hotfix in article 977073
(https://go.microsoft.co
m/fwlink/?
LinkId=186394) in the
Microsoft Knowledge
Base as required.
LMv2 Enabled Disabled Article 976918 in the

wlink/?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.
REQ UIREM EN T VA L UE
Processor 1.4 Ghz 64-bit processor

REQ UIREM EN T VA L UE
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:
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 Y O U A RE RUN N IN G T H ESE EDIT IO N S Y O U C A N UP GRA DE TO T H ESE EDIT IO N S
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 suppor t 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.
P RO DUC T N OT ES
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."
P RO DUC T N OT ES
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:
Datacenter
Minimum requirements for front-end web servers and
application servers in a farm:
Datacenter.
Configuration Manager 2012 Configuration Manager 2012 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 8 Enterprise
- Windows Server 2012 Standard
- 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:
Microsoft Endpoint Configuration Manager (current branch) Supported operating systems for Configuration Manager
site system servers.
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.
P RO DUC T N OT ES
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 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
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.
P RO DUC T N OT ES
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:
K B A RT IC L E N UM B ER A N D T IT L E T EC H N O LO GY A REA IM PA C T ED ISSUE/ DESC RIP T IO N
2830145: SID S-1-18-1 and SID S-1- AD DS Management/App compat Applications that map SID S-1-18-1
18-2 can't be mapped on Windows 7 and SID S-1-18-2, which are new in
or Windows Server 2008 R2-based Windows Server 2012, may fail
computers in a domain environment because 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 the last DC in a domain where pre-
you try to remove Active Directory created RODC accounts still exist. This
Domain Services from a domain affects Windows Server 2012,
controller Windows Server 2008 R2, and
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 AD DS Installation IFM verification can have limitations as
in Windows Server 2012 Server explained in the KB article.
Manager
2737535: Install- AD DS Installation You can receive an error when you try
AddsDomainController cmdlet returns to attach a server to an RODC account
parameter set error for RODC if you specify arguments that are
already populated on the pre-created
RODC account.
2737560: "Unable to perform AD DS Installation Prerequisite check fails when you

Exchange schema conflict check" error, configure the first Windows Server
and prerequisites check fails 2012 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
incorrect DNS results be.
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
stalls at the "Creating the NTDS local Administrator password matches
settings object" stage the 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
configuration error when you computer because NTLM
configure a server by using Server authentication is disabled.
Manager
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
application" error on Windows Server Windows Server 2012 Adprep cannot
2003, 64-bit version be run on 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
Internet Explorer 10 changes in Internet Explorer 10.
2741537: Remote Group Policy Group Policy This is due to scheduled tasks run in
updates are visible to users the 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
SYSVOL in the GPMC Infrastructure in progress" because GPMC
Status option Infrastructure 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 Virtual DC cloning This happens because the cloned
created for each domain controller domain controller received a lease
when you 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 cloning failed for any of a variety of
in Windows Server 2012 reasons listed in the KB article.
2742874: Domain controller cloning Virtual DC cloning Some three-part SPNs are not
does not re-create all service principal recreated on the cloned DC because of
names a 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
fails with error 8610 in dcpromo.log emulator 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 name or a duplicate NetBIOS name
parameter was specified for this was specified.
replication operation"
2742970: DC Cloning fails with no Virtual DC cloning The cloned virtual DC boots in
DSRM, duplicate source and clone Directory Services Repair Mode
computer (DSRM), using a 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 because the server cannot contact a
Server 2012 global catalog server.
2747974: Domain controller cloning Virtual DC cloning Event ID 2224 incorrectly states that
event 2224 provides incorrect managed service accounts must be
guidance 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
upgrade to Windows 8 on 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 Director ySer vices-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
P ROTO C O L S
USED
T EST N A M E EXP L A N AT IO N A N D N OT ES
VerifyAdminTrusted LDAP Validates that you have the "Enable

ForDelegationProvider computer and user accounts to be
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
P ROTO C O L S
USED
VerifyADPrep LDAP Discovers and contacts the Schema

Prerequisites (forest) Master using the rootDSE
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

Prerequisites (domain and RODC) Infrastructure Master using the
rootDSE 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

Membership RPC over SMB (LSARPC) Domain Admins or Enterprise Admins
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

GroupMembership RPC over SMB (LSARPC) Schema Admins and Enterprise Admins
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

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

GroupMembership RPC over SMB (LSARPC) Enterprise Admins group and has the
Manage Audit and Security Event Logs
VerifyInitSync LDAP Validate that the Schema Master has

AfterReboot replicated at least once since it
restarted by setting a dummy value on
rootDSE attribute
becomeSchemaMaster
P ROTO C O L S
USED
VerifySFUHotFix LDAP Validate the existing forest schema

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

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

LDAP, passed to the promotion code and test
promotion. Validate the forest or
DNS domain does not already exist if
RPC over SMB (SAMR) creating new.
VerifyOutbound LDAP, DRSR over SMB, RPC over SMB Validate the existing domain controller
ReplicationEnabled (LSARPC) specified as the replication partner has
outbound replication enabled by
checking the NTDS Settings object's
options attribute for
NTDSDSA_OPT_DISABLE_OUTBOUND_
REPL (0x00000004)
VerifyMachineAdmin DRSR over RPC, Validate the safe mode password set
Password LDAP, for DSRM meets domain complexity
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 Ser vers 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 Impor t-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 impor t-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:
M EN U IT EM EXP L A N AT IO N
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

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
A RGUM EN T DESC RIP T IO N
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 according to the rules of Get-Credential and a PSCredential
to 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 Specifies the application directory partitions to replicate. This
no equivalent option in the UI. If you install using the UI, or argument is applied only when you specify the -
using 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 Indicates whether to create a DNS delegation that references
argument when you run the Add- the new DNS server that you are installing along with the
ADDSReadOnlyDomainController 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. Impor tant:
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

Required for Install-ADDSForest and Install- install an additional domain controller.
ADDSDomainController cmdlets.
DomainNetbiosName Use with Install-ADDSForest. Assigns a NetBIOS name to the

Required for Install-ADDSForest if FQDN prefix name is new forest root domain.
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. Impor tant:
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

Required for Install-ADDSDomain if FQDN prefix name is the new domain. The default value is derived from the value
longer than 15 characters. of "NewDomainName .
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
ADDSDomain cmdlet this 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

Required for the Add- installed. There is no "sitename argument when you run
addsreadonlydomaincontrolleraccount cmdlet Install-ADDSForest because the first site created is
Default-First-Site-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 .
Impor tant: 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.
T EST C M DL ET DESC RIP T IO N
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 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)
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 ser ver page, click Select a ser ver from the ser ver 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 ser ver roles page, click Active Director y Domain Ser vices , then on the Add Roles
and Features Wizard dialog box, click Add Features , and then click Next .
6. On the Select features page, select any additional features you want to install and click Next .
7. On the Active Director y Domain Ser vices page, review the information and then click Next .
9. On the Results page, verify that the installation succeeded, and click Promote this ser ver 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) ser ver , specify the DSRM password, and then click Next .
If you are adding a domain controller to an existing domain, click Domain Name System (DNS)
ser ver , 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 Star t , click Administrative Tools , and then click Active Director y 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 Star t , click Administrative Tools , and then click Active Director y 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 Director y Domain Ser vices 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 ser ver : 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 Summar y 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 Expor t 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 Director y Domain Ser vices 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 ser ver page, click Select a ser ver from the ser ver pool , click the name
of the server where you want to install AD DS and then click Next .
6. On the Select ser ver roles page, click Active Director y Domain Ser vices , 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 Director y Domain Ser vices page, review the information and then click Next .
10. On the Results page, verify Installation succeeded , and click Promote this ser ver 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
Troubleshooting Domain Controller Deployment Install a New Windows Server 2012 Active Directory Forest
(Level 200) Install a New Windows Server 2012 Active Directory Child or Tree Domain (Level 200) Install a
Replica Windows Server 2012 Domain Controller in an Existing Domain (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 Ser vers to Manage on the dashboard welcome tile
Click the Manage menu and select Add Ser vers
Right-click All Ser vers and choose Add Ser vers
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 Ser vers dialog to add selected servers to dashboard role groups. Or Click Manage ,
and then click Create Ser ver Group , or click Create Ser ver Group on the dashboard Welcome to Ser ver
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 Ser ver . This is invoking Install-WindowsFeature AD-Domain-Ser vices .
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 Ser vices 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 Ser ver 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 Director y Domain Ser vices 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 Director y Domain Ser vices 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
ser ver 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 Director y Domain Ser vices
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 Director y Ser vices 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 ser ver 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.
A RGUM EN T S ( B O L D A RGUM EN T S A RE REQ UIRED.

ITA L IC IZ ED A RGUM EN T S C A N B E SP EC IF IED B Y USIN G
W IN DO W S P O W ERSH EL L O R T H E A D DS C O N F IGURAT IO N
SERVERM A N A GER C M DL ET W IZ A RD. )
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 -expandproper ty argument returns interesting data:
NOTE
The Select-Object -expandproper ty 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 .

A DDSDEP LO Y M EN T C M DL ET W IZ A RD. )
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.Cr yptography 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 ser ver , 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.
the 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
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.Cr yptography 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 ser ver 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.
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.
operating systems.
For more information about the specific prerequisite checks, see Prerequisite Checking.
-skipprechecks
WARNING
AD 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-
addsdomaincontroller 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
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
Wizard using 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 ser ver 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
impersonate the domain controller itself, elevating their privileges to the highest level in an AD forest. An additional set of
steps using System.Security.Cr yptography 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
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
#
#
Install-ADDSDomain `
-NoGlobalCatalog:$false `
-DomainMode "Win2012" `
-DomainType "ChildDomain" `
-InstallDNS:$true `
-NewDomainName "research" `
-NewDomainNetBIOSName "RESEARCH" `
-ParentDomainName "corp.contoso.com" `
-Norebootoncompletion:$false `
-SiteName "Default-First-Site-Name" `
-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.
tests pass.
operating systems.
For more information on the specific prerequisite checks, see Prerequisite Checking.
-skipprechecks
WARNING
AD 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 Ser ver 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 Director y Domain Ser vices 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 Ser ver 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 Summar y 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 Expor t Settings to save an answer file in the obsolete dcpromo unattend file format.
Creation
The Active Director y Domain Ser vices 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 screenshots 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 ser ver exists in the director y. 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
cmdlet 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:
-safemodeadministratorpassword (read-host -prompt Password: -assecurestring)
WARNING
-safemodeadministratorpassword (convertto-securestring Password1 -asplaintext -force)
$file = c:\pw.txt
$pw = read-host -prompt Password: -assecurestring

WARNING
Additional Options
The Additional Options page provides configuration options to name a domain controller as the replication
ensure the provided path is valid media.
Guidelines for the IFM source:
Media used by the IFM option is created with Windows Server Backup or Ntdsutil.exe from another existing
Windows Server Domain Controller with the same operating system version only. For example, you cannot
use a Windows Server 2008 R2 or previous operating system to create media for a Windows Server 2012
domain controller.
The IFM source data should be from a writable Domain Controller. While a source from RODC will technically
work to create a new RODC, there are false positive replication warnings that the IFM source RODC is not
replicating.
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
-logpath <string>

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
#
#
-DatabasePath C:\Windows\NTDS `
-DomainName corp.contoso.com `
-LogPath C:\Windows\NTDS `
-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
Prerequisites Check
run the tests as many times as required. The domain controller installation process cannot continue until all
prerequisite tests pass.
operating systems. For more information about the prerequisite checks, see Prerequisite Checking.
-skipprechecks
WARNING
AD 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
Wizard using 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 ser ver , 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
the server. Always choose a strong, complex password or preferably, a passphrase.The Domain Controller
Options ADDSDeployment Windows PowerShell arguments are:
-UseExistingAccount <{$true | $false}>

IMPORTANT
cmdlet 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:
-safemodeadministratorpassword (read-host -prompt Password: -assecurestring)
WARNING
-safemodeadministratorpassword (convertto-securestring Password1 -asplaintext -force)
$file = c:\pw.txt
$pw = read-host -prompt Password: -assecurestring
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
ensure the provided path is valid media.
Guidelines for the IFM source:
Media used by the IFM option is created with Windows Server Backup or Ntdsutil.exe from another existing
Windows Server Domain Controller with the same operating system version only. For example, you cannot
use a Windows Server 2008 R2 or previous operating system to create media for a Windows Server 2012
domain controller.
The IFM source data should be from a writable Domain Controller. While a source from RODC will technically
work to create a new RODC, there are false positive replication warnings that the IFM source RODC is not
replicating.
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
-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.

This page simply enables you to review and confirm your settings before continuing the configuration.
#
#
-AllowPasswordReplicationAccountName @(CORP\Allowed RODC Password Replication Group, CORP\Chicago RODC
Admins, CORP\Chicago RODC Users and Computers) `
-DatabasePath C:\Windows\NTDS `
-DelegatedAdministratorAccountName CORP\Chicago RODC Admins `
-DenyPasswordReplicationAccountName @(BUILTIN\Administrators, BUILTIN\Server Operators, BUILTIN\Backup
Operators, BUILTIN\Account Operators, CORP\Denied RODC Password Replication Group) `
-DomainName corp.contoso.com `
-InstallDNS:$true `
-LogPath C:\Windows\NTDS `
-ReadOnlyReplica:$true `
-SiteName Default-First-Site-Name `
-SYSVOLPath C:\Windows\SYSVOL
-Force:$true
NOTE
safemodeadministratorpassword argument. To force a confirmation prompt, omit the value when running cmdlet
interactively.
Prerequisites Check
tests pass.
operating systems.
-skipprechecks
Installation
See the ADDSDeployment Cmdlet table at the beginning 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

A DDSDEP LO Y M EN T A N D SERVERM A N A GER C M DL ET S W IZ A RD. )
A DDSDEP LO Y M EN T A N D SERVERM A N A GER C M DL ET S W IZ A RD. )
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 Ser vers on the navigation pane. Scroll down to the Roles and Features section.
Right-click Active Director y Domain Ser vices in the Roles and Features list and click Remove Role
or Feature . This interface skips the Ser ver 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 Ser ver 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 Director y Domain Ser vices 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 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 ser ver for zone , Remove application par titions , and Remove DNS Delegation to
enable 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 Par titions 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
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-ADDSDomainController
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.
of 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 -removeapplicationpar titions :
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 Proper ties , 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. Before
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 Director y 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
Director y 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 Director y Domain Ser vices 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 Director y Domain Ser vices 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 Director y Sites and Ser vices , 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 Ser vers , expand the name of the
domain controller, right-click the NTDS Settings object, and then click Delete .
4. In the Active Director y Sites and Ser vices 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 Director y Domain Ser vices 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 Director y Domain Ser vices 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 Star t 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 Ser ver 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 Ser vers 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
deployment 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 ser ver 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 ser ver 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 page

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.
Schema Update in Windows Server 2019

Sch88.ldf is the only new file introduced with 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

Sch70.ldf through Sch87.ldf are introduced with Windows Server 2016.
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==
showInAdvancedViewOnly: TRUE
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-DS-Device,CN=Schema,CN=Configuration,DC=X
-
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
-
dn: CN=ms-DS-Device-OS-Version,CN=Schema,CN=Configuration,DC=X
replace: searchFlags
searchFlags: 1
-
dn: CN=ms-DS-Device-OS-Type,CN=Schema,CN=Configuration,DC=X
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
omObjectClass:: KwwCh3McAIVK
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
isSingleValued: FALSE
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.
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
objectClass: classSchema
ldapDisplayName: msDS-KeyCredential
adminDisplayName: msDS-KeyCredential
adminDescription: An instance of this class contains key material.
governsId: 1.2.840.113556.1.5.297
objectClassCategory: 1
rdnAttId: cn
schemaIdGuid:: Q1Uf7i58akeLP+EfSvbEmA==
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLOLORCWOWDSDDTDTSW;;;EA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
defaultHidingValue: FALSE
systemOnly: FALSE
systemFlags: 16
instanceType: 4
subClassOf: top
systemPossSuperiors: 1.2.840.113556.1.3.23
systemMustContain: 1.2.840.113556.1.4.2315
add:systemMayContain
-
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
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
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

msDS-OptionalFeatureGUID:: KbW388juRVatNjmTdiXpNg==
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:
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_RENAME0x08000000
# FLAG_DOMAIN_DISALLOW_MOVE0x04000000
-

# FLAG_DOMAIN_DISALLOW_RENAME0x08000000
# FLAG_DOMAIN_DISALLOW_MOVE0x04000000
-

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
objectClass: controlAccessRight
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==
defaultHidingValue: TRUE
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
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;CC;;;AU)(A;;RPLCLORC;;;WD)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;CO)
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
attributeId: 1.2.840.113556.1.4.2350
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
# schemaIdGuid {aacd2170-482a-44c6-b66e-42c2f66a285c}
schemaIdGuid:: cCHNqipIxkS2bkLC9mooXA==
systemFlags: 16
dn: CN=ms-DS-AuthN-Policy,CN=Schema,CN=Configuration,DC=X
-
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
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
# 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 through Sch69.ldf are introduced with Windows Server 2012 R2.
Sch57.ldf
dn: CN=ms-DS-Issuer-Certificates,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Issuer-Certificates
adminDisplayName: 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
dn: CN=ms-DS-Registration-Quota,CN=Schema,CN=Configuration,DC=X
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
dn: CN=ms-DS-Maximum-Registration-Inactivity-Period,CN=Schema,CN=Configuration,DC=X
cn: ms-DS-Maximum-Registration-Inactivity-Period
adminDisplayName: ms-DS-Maximum-Registration-Inactivity-Period
adminDescription: The maximum amount 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
dn: CN=ms-DS-Is-Enabled,CN=Schema,CN=Configuration,DC=X
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
dn: CN=ms-DS-Device-Physical-IDs,CN=Schema,CN=Configuration,DC=X
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
dn: CN=ms-DS-Device-ID,CN=Schema,CN=Configuration,DC=X
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
rangeUpper: 16
searchFlags: 1
systemOnly: FALSE
schemaIdGuid:: x4EBw0Jj+0GyeffFZsvgpw==
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-DS-Device-Registration-Service-Container,CN=Schema,CN=Configuration,DC=X
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)
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
governsId: 1.2.840.113556.1.5.289
instanceType: 4
schemaIdGuid:: WIyefBuQqE627E656fwOEQ==
systemOnly: FALSE
systemFlags: 16
subClassOf: top
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-DS-Device-Registration-Service,CN=Schema,CN=Configuration,DC=X
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
governsId: 1.2.840.113556.1.5.284
governsId: 1.2.840.113556.1.5.284
instanceType: 4
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: CN=ms-DS-Resource-Property-List,CN=Schema,CN=Configuration,DC=X
replace: defaultHidingValue
-
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
-
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
instanceType: 4
searchFlags: 0
systemOnly: TRUE
schemaIdGuid:: yFb74+hd9UWxsdK2zTHnYg==
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
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
replace: isSingleValued
-
searchFlags: 1
-
-
replace: omSyntax
omSyntax: 64
-
replace: attributeSyntax
-
replace: rangeUpper
rangeUpper: 1024
-
dn:
changetype: modify
schemaUpdateNow: 1
-
add: systemMustContain
-
-
-
-
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
# This constructed attribute transitively expands the
# linked attribute "member"
lDAPDisplayName: msds-memberTransitive
adminDisplayName: msds-memberTransitive
adminDescription: msds-memberTransitive
attributeID: 1.2.840.113556.1.4.2238
oMSyntax: 127
systemOnly: TRUE
# 0x800(only return on base search)
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
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 keysof 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)
-
defaultSecurityDescriptor: D:(A;;RPLCLORC;;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)
-
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 63
-
Sch64.ldf
defaultSecurityDescriptor: D:(A;;RPLCLORC;;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;EA)
-
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-Registered-Owner,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ms-DS-Registered-Users,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ms-DS-Approximate-Last-Logon-Time-Stamp,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-Device-Object-Version,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
RangeUpper: 132096
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
adminDisplayName: User Authentication Policy Backlink
adminDescription: This attribute is the backlink for msDS-UserAuthNPolicy.
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
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
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
-
dn: CN=ms-DS-AuthN-Policy-Silo,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicySilo
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
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
dn: CN=ms-DS-AuthN-Policy-Silo,CN=Schema,CN=Configuration,DC=X
add: defaultHidingValue
-
add: defaultHidingValue
-
objectVersion: 69
-
dn:
changetype: modify
schemaUpdateNow: 1
-
Schema Updates in Windows Server 2012

Sch48.ldf through Sch56.ldf are introduced with 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
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
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
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==
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
dn: CN=ms-DS-Resource-Property-List,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ResourcePropertyList
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
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
subClassOf: 1.2.840.113556.1.5.269
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:
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
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==
schemaIdGuid:: fJuGKcRk/kKX1fvC+hJBYA==
systemFlags: 16
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
omSyntax: 2
systemOnly: FALSE
searchFlags: 8
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
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
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
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
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
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
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 attribute for msDS-IsPrimaryComputer.
attributeId: 1.2.840.113556.1.4.2168
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
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
resource properties.
attributeId: 1.2.840.113556.1.4.2188
omSyntax: 127
systemOnly: TRUE
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
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
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=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
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
dn: CN=ms-DS-Applies-To-Resource-Types,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AppliesToResourceTypes
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
linkID: 2190
systemFlags: 16
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
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
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
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
-
-
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-
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-
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
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
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
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==
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
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
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
-
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
-
Schema Updates in previous versions of Windows Server

Sch0.ldf through Sch47.ldf are introduced with Windows Server 2000 to Windows Server 2008 R2.
Sch0.ldf
# Make a system-only mod first. If they haven't got the binary

# support necessary, it will fail right here, and the tool can
# later be rerun.
dn: CN=User-Principal-Name,CN=Schema,CN=Configuration,DC=X
changetype: modify
add: systemFlags
systemFlags: 2
-
# Add these two objects first. If the DC is running a 1717.IDS schema,

# these were deleted just before this. So add them first so that
# the system does not run without them for long
# They are not dependent on any schema changes
dn: CN=container-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
objectClass: displaySpecifier
hideFromAB: TRUE
adminPropertyPages: 1,{6384e23e-736d-11d1-bd0d-00c04fd8d5b6}
adminPropertyPages: 2,{6dfe6488-a212-11d0-bcd5-00c04fd8d5b6}
adminPropertyPages: 3,{4E40F770-369C-11d0-8922-00A024AB2DBB}
shellPropertyPages: 1,{f2c3faae-c8ac-11d0-bcdb-00c04fd8d5b6}
contextMenu: 0,{62AE1F9A-126A-11D0-A14B-0800361B1103}
adminContextMenu: 0,{6971d64e-f335-11d0-b0bc-00c04fd8dca6}
adminContextMenu: 1,{6BA3F852-23C6-11D1-B91F-00A0C9A06D2D}
classDisplayName: Container
attributeDisplayNames: cn,Name
attributeDisplayNames: description,Description
dn: CN=default-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
# Attribute Adds
dn: CN=Pek-List,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: pekList
adminDisplayName: Pek-List
adminDescription: Pek-List
attributeId: 1.2.840.113556.1.4.865
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gzA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
systemFlags: 1
dn: CN=FRS-Flags,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSFlags
adminDisplayName: FRS-Flags
adminDescription: FRS-Flags
attributeId: 1.2.840.113556.1.4.874
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fSUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Site-List,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: siteList
adminDisplayName: Site-List
adminDescription: Site-List
attributeId: 1.2.840.113556.1.4.821
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 3CwM1VGJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Msi-Script,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msiScript
adminDisplayName: Msi-Script
adminDescription: Msi-Script
attributeId: 1.2.840.113556.1.4.814
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: E4Ph2TmJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Version,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSVersion
adminDisplayName: FRS-Version
adminDescription: FRS-Version
attributeId: 1.2.840.113556.1.4.882
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32
schemaIdGuid:: hSUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Treat-As-Leaf,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: treatAsLeaf
adminDisplayName: Treat-As-Leaf
adminDescription: Treat-As-Leaf
attributeId: 1.2.840.113556.1.4.806
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 40TQjx930RGurgAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Product-Code,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: productCode
adminDisplayName: Product-Code
adminDescription: Product-Code
attributeId: 1.2.840.113556.1.4.818
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 16
schemaIdGuid:: F4Ph2TmJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=DNS-Host-Name,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: dNSHostName
adminDisplayName: DNS-Host-Name
adminDescription: DNS-Host-Name
attributeId: 1.2.840.113556.1.4.619
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2048
schemaIdGuid:: R5Xjchh70RGt7wDAT9jVzQ==
hideFromAB: TRUE
dn: CN=Create-Dialog,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: createDialog
adminDisplayName: Create-Dialog
adminDescription: Create-Dialog
attributeId: 1.2.840.113556.1.4.810
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ipUJKzGJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-SCP-BL,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootSCPBL
adminDisplayName: netboot-SCP-BL
adminDescription: netboot-SCP-BL
attributeId: 1.2.840.113556.1.4.864
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gjA4B9+R0RGuvAAA+ANnwQ==
linkID: 101
hideFromAB: TRUE
systemFlags: 1
dn: CN=Site-Link-List,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: siteLinkList
adminDisplayName: Site-Link-List
adminDescription: Site-Link-List
attributeId: 1.2.840.113556.1.4.822
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 3SwM1VGJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Tools,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootTools
adminDisplayName: netboot-Tools
adminDescription: netboot-Tools
attributeId: 1.2.840.113556.1.4.858
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fzA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Msi-Script-Name,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msiScriptName
adminDisplayName: Msi-Script-Name
adminDescription: Msi-Script-Name
attributeId: 1.2.840.113556.1.4.845
omSyntax: 64
systemOnly: FALSE
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Yt2nlhiR0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Server,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootServer
adminDisplayName: netboot-Server
adminDescription: netboot-Server
attributeId: 1.2.840.113556.1.4.860
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gTA4B9+R0RGuvAAA+ANnwQ==
linkID: 100
hideFromAB: TRUE
dn: CN=Msi-Script-Size,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msiScriptSize
adminDisplayName: Msi-Script-Size
adminDescription: Msi-Script-Size
attributeId: 1.2.840.113556.1.4.846
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Y92nlhiR0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=LDAP-IPDeny-List,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: lDAPIPDenyList
adminDisplayName: LDAP-IPDeny-List
adminDescription: LDAP-IPDeny-List
attributeId: 1.2.840.113556.1.4.844
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: U6NZc/eQ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Install-Ui-Level,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: installUiLevel
adminDisplayName: Install-Ui-Level
adminDescription: Install-Ui-Level
attributeId: 1.2.840.113556.1.4.847
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ZN2nlhiR0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Terminal-Server,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: terminalServer
adminDisplayName: Terminal-Server
adminDescription: Terminal-Server
attributeId: 1.2.840.113556.1.4.885
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: HJq2bSKU0RGuvQAA+ANnwQ==
hideFromAB: TRUE
dn: CN=LDAP-Admin-Limits,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: lDAPAdminLimits
adminDisplayName: LDAP-Admin-Limits
adminDescription: LDAP-Admin-Limits
attributeId: 1.2.840.113556.1.4.843
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: UqNZc/eQ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Create-Wizard-Ext,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: createWizardExt
adminDisplayName: Create-Wizard-Ext
adminDescription: Create-Wizard-Ext
attributeId: 1.2.840.113556.1.4.812
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: i5UJKzGJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Purported-Search,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: purportedSearch
adminDisplayName: Purported-Search
adminDescription: Purported-Search
attributeId: 1.2.840.113556.1.4.886
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2048
schemaIdGuid:: UE61tDqU0RGuvQAA+ANnwQ==
hideFromAB: TRUE
dn: CN=ms-RRAS-Attribute,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRRASAttribute
adminDisplayName: ms-RRAS-Attribute
adminDescription: ms-RRAS-Attribute
attributeId: 1.2.840.113556.1.4.884
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: rZib842T0RGuvQAA+ANnwQ==
hideFromAB: TRUE
dn: CN=File-Ext-Priority,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fileExtPriority
adminDisplayName: File-Ext-Priority
adminDescription: File-Ext-Priority
attributeId: 1.2.840.113556.1.4.816
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: FYPh2TmJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Can-Upgrade-Script,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: canUpgradeScript
adminDisplayName: Can-Upgrade-Script
adminDescription: Can-Upgrade-Script
attributeId: 1.2.840.113556.1.4.815
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: FIPh2TmJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=App-Schema-Version,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: appSchemaVersion
adminDisplayName: App-Schema-Version
adminDescription: App-Schema-Version
attributeId: 1.2.840.113556.1.4.848
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Zd2nlhiR0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Primary-Member,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSPrimaryMember
adminDisplayName: FRS-Primary-Member
adminDescription: FRS-Primary-Member
attributeId: 1.2.840.113556.1.4.878
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
linkId: 106
schemaIdGuid:: gSUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Remote-Storage-GUID,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: remoteStorageGUID
adminDisplayName: Remote-Storage-GUID
adminDescription: Remote-Storage-GUID
attributeId: 1.2.840.113556.1.4.809
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: sMU5KmCJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Max-Clients,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootMaxClients
adminDisplayName: netboot-Max-Clients
adminDescription: netboot-Max-Clients
attributeId: 1.2.840.113556.1.4.851
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: eDA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Member-Reference,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSMemberReference
adminDisplayName: FRS-Member-Reference
adminDescription: FRS-Member-Reference
attributeId: 1.2.840.113556.1.4.875
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fiUTKnOT0RGuvAAA+ANnwQ==
linkID: 104
hideFromAB: TRUE
systemFlags: 2
dn: CN=Upgrade-Product-Code,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: upgradeProductCode
adminDisplayName: Upgrade-Product-Code
adminDescription: Upgrade-Product-Code
attributeId: 1.2.840.113556.1.4.813
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 16
schemaIdGuid:: EoPh2TmJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Time-Last-Command,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSTimeLastCommand
adminDisplayName: FRS-Time-Last-Command
adminDescription: FRS-Time-Last-Command
attributeId: 1.2.840.113556.1.4.880
omSyntax: 23
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gyUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-New-Machine-OU,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootNewMachineOU
adminDisplayName: netboot-New-Machine-OU
adminDescription: netboot-New-Machine-OU
attributeId: 1.2.840.113556.1.4.856
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fTA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Limit-Clients,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootLimitClients
adminDisplayName: netboot-Limit-Clients
adminDescription: netboot-Limit-Clients
attributeId: 1.2.840.113556.1.4.850
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: dzA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Signature-Algorithms,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: signatureAlgorithms
adminDisplayName: Signature-Algorithms
adminDescription: Signature-Algorithms
attributeId: 1.2.840.113556.1.4.824
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ssU5KmCJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Partner-Auth-Level,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSPartnerAuthLevel
adminDisplayName: FRS-Partner-Auth-Level
adminDescription: FRS-Partner-Auth-Level
attributeId: 1.2.840.113556.1.4.877
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gCUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Enrollment-Providers,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: enrollmentProviders
adminDisplayName: Enrollment-Providers
adminDescription: Enrollment-Providers
attributeId: 1.2.840.113556.1.4.825
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: s8U5KmCJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Member-Reference-BL,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSMemberReferenceBL
adminDisplayName: FRS-Member-Reference-BL
adminDescription: FRS-Member-Reference-BL
attributeId: 1.2.840.113556.1.4.876
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fyUTKnOT0RGuvAAA+ANnwQ==
linkID: 105
hideFromAB: TRUE
systemFlags: 1
dn: CN=Certificate-Templates,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: certificateTemplates
adminDisplayName: Certificate-Templates
adminDescription: Certificate-Templates
attributeId: 1.2.840.113556.1.4.823
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: scU5KmCJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Pek-Key-Change-Interval,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: pekKeyChangeInterval
adminDisplayName: Pek-Key-Change-Interval
adminDescription: Pek-Key-Change-Interval
attributeId: 1.2.840.113556.1.4.866
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: hDA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Localized-Description,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: localizedDescription
adminDisplayName: Localized-Description
adminDescription: Localized-Description
attributeId: 1.2.840.113556.1.4.817
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: FoPh2TmJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Frs-Computer-Reference,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: frsComputerReference
adminDisplayName: Frs-Computer-Reference
adminDescription: Frs-Computer-Reference
attributeId: 1.2.840.113556.1.4.869
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: eCUTKnOT0RGuvAAA+ANnwQ==
linkID: 102
systemFlags: 2
hideFromAB: TRUE
dn: CN=Alt-Security-Identities,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: altSecurityIdentities
adminDisplayName: Alt-Security-Identities
adminDescription: Alt-Security-Identities
attributeId: 1.2.840.113556.1.4.867
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: DPP7AP6R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Answer-Requests,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootAnswerRequests
adminDisplayName: netboot-Answer-Requests
adminDescription: netboot-Answer-Requests
attributeId: 1.2.840.113556.1.4.853
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ejA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Bridgehead-Server-List-BL,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: bridgeheadServerListBL
adminDisplayName: Bridgehead-Server-List-BL
adminDescription: Bridgehead-Server-List-BL
attributeId: 1.2.840.113556.1.4.820
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 2ywM1VGJ0RGuvAAA+ANnwQ==
linkID: 99
hideFromAB: TRUE
systemFlags: 1
dn: CN=Frs-Computer-Reference-BL,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: frsComputerReferenceBL
adminDisplayName: Frs-Computer-Reference-BL
adminDescription: Frs-Computer-Reference-BL
attributeId: 1.2.840.113556.1.4.870
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: eSUTKnOT0RGuvAAA+ANnwQ==
linkID: 103
hideFromAB: TRUE
systemFlags: 1
dn: CN=FRS-Control-Data-Creation,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSControlDataCreation
adminDisplayName: FRS-Control-Data-Creation
adminDescription: FRS-Control-Data-Creation
attributeId: 1.2.840.113556.1.4.871
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32
schemaIdGuid:: eiUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Is-Critical-System-Object,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: isCriticalSystemObject
adminDisplayName: Is-Critical-System-Object
adminDescription: Is-Critical-System-Object
attributeId: 1.2.840.113556.1.4.868
omSyntax: 1
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: DfP7AP6R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Allow-New-Clients,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootAllowNewClients
adminDisplayName: netboot-Allow-New-Clients
adminDescription: netboot-Allow-New-Clients
attributeId: 1.2.840.113556.1.4.849
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: djA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Time-Last-Config-Change,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSTimeLastConfigChange
adminDisplayName: FRS-Time-Last-Config-Change
adminDescription: FRS-Time-Last-Config-Change
attributeId: 1.2.840.113556.1.4.881
omSyntax: 23
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: hCUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Bridgehead-Transport-List,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: bridgeheadTransportList
adminDisplayName: Bridgehead-Transport-List
adminDescription: Bridgehead-Transport-List
attributeId: 1.2.840.113556.1.4.819
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 2iwM1VGJ0RGuvAAA+ANnwQ==
linkID: 98
hideFromAB: TRUE
dn: CN=FRS-Service-Command-Status,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSServiceCommandStatus
adminDisplayName: FRS-Service-Command-Status
adminDescription: FRS-Service-Command-Status
attributeId: 1.2.840.113556.1.4.879
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 512
schemaIdGuid:: giUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Control-Inbound-Backlog,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSControlInboundBacklog
adminDisplayName: FRS-Control-Inbound-Backlog
adminDescription: FRS-Control-Inbound-Backlog
attributeId: 1.2.840.113556.1.4.872
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32
schemaIdGuid:: eyUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-IntelliMirror-OSes,CN=Schema,CN=Configuration,DC=X
changetype: add
changetype: add
ldapDisplayName: netbootIntelliMirrorOSes
adminDisplayName: netboot-IntelliMirror-OSes
adminDescription: netboot-IntelliMirror-OSes
attributeId: 1.2.840.113556.1.4.857
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fjA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Control-Outbound-Backlog,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSControlOutboundBacklog
adminDisplayName: FRS-Control-Outbound-Backlog
adminDescription: FRS-Control-Outbound-Backlog
attributeId: 1.2.840.113556.1.4.873
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32
schemaIdGuid:: fCUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Current-Client-Count,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootCurrentClientCount
adminDisplayName: netboot-Current-Client-Count
adminDescription: netboot-Current-Client-Count
attributeId: 1.2.840.113556.1.4.852
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: eTA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=IPSEC-Negotiation-Policy-Type,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: iPSECNegotiationPolicyType
adminDisplayName: IPSEC-Negotiation-Policy-Type
adminDescription: IPSEC-Negotiation-Policy-Type
attributeId: 1.2.840.113556.1.4.887
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: dDA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=ms-RRAS-Vendor-Attribute-Entry,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRRASVendorAttributeEntry
adminDisplayName: ms-RRAS-Vendor-Attribute-Entry
adminDescription: ms-RRAS-Vendor-Attribute-Entry
attributeId: 1.2.840.113556.1.4.883
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: rJib842T0RGuvQAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Locally-Installed-OSes,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootLocallyInstalledOSes
adminDisplayName: netboot-Locally-Installed-OSes
adminDescription: netboot-Locally-Installed-OSes
attributeId: 1.2.840.113556.1.4.859
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gDA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=IPSEC-Negotiation-Policy-Action,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: iPSECNegotiationPolicyAction
adminDisplayName: IPSEC-Negotiation-Policy-Action
adminDescription: IPSEC-Negotiation-Policy-Action
attributeId: 1.2.840.113556.1.4.888
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: dTA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-New-Machine-Naming-Policy,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootNewMachineNamingPolicy
adminDisplayName: netboot-New-Machine-Naming-Policy
adminDescription: netboot-New-Machine-Naming-Policy
attributeId: 1.2.840.113556.1.4.855
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fDA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Answer-Only-Valid-Clients,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootAnswerOnlyValidClients
adminDisplayName: netboot-Answer-Only-Valid-Clients
adminDescription: netboot-Answer-Only-Valid-Clients
attributeId: 1.2.840.113556.1.4.854
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ezA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=UPN-Suffixes,CN=Schema,CN=Configuration,DC=X
changetype: add
lDAPDisplayName: uPNSuffixes
adminDescription: UPN-Suffixes
adminDisplayName: UPN-Suffixes
attributeID: 1.2.840.113556.1.4.890
oMSyntax: 64
schemaIDGUID:: v2AhAySY0RGuwAAA+ANnwQ==
searchFlags: 0
systemOnly: FALSE
hideFromAB: TRUE
dn: CN=Additional-Trusted-Service-Names,CN=Schema,CN=Configuration,DC=X
changetype: add
lDAPDisplayName: additionalTrustedServiceNames
adminDescription: Additional-Trusted-Service-Names
adminDisplayName: Additional-Trusted-Service-Names
attributeID: 1.2.840.113556.1.4.889
oMSyntax: 64
schemaIDGUID:: vmAhAySY0RGuwAAA+ANnwQ==
searchFlags: 0
systemOnly: FALSE
hideFromAB: TRUE
# Here because OID got reused with different syntax

# We will delete Replica-Set-Type, and add FRS-Replica-Set-Type
# with a new OID.
dn: CN=NTFRS-Replica-Set,CN=schema,CN=configuration,DC=X
changetype: modify
-
dn: CN=Replica-Set-Type,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=FRS-Replica-Set-Type,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSReplicaSetType
adminDisplayName: FRS-Replica-Set-Type
adminDescription: FRS-Replica-Set-Type
attributeId: 1.2.840.113556.1.4.31
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: a3PZJnBg0RGpxgAA+ANnwQ==
hideFromAB: TRUE
# Attribute Renames, plus some modifies in some cases
dn: CN=Replication-DS-Poll,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-DS-Poll
deleteoldrdn: 1
deleteoldrdn: 1
dn: CN=FRS-DS-Poll,CN=schema,CN=configuration,DC=X
changetype: modify
replace: ldapDisplayName
ldapDisplayName: fRSDSPoll
-
replace: adminDisplayName
adminDisplayName: FRS-DS-Poll
-
adminDescription: FRS-DS-Poll
-
dn: CN=Com-Unique-Cat-Id,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: Category-Id
deleteoldrdn: 1
dn: CN=Category-Id,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: categoryId
-
adminDisplayName: Category-Id
-
adminDescription: Category-Id
-
dn: CN=Replication-Root-Path,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Root-Path
deleteoldrdn: 1
dn: CN=FRS-Root-Path,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSRootPath
-
adminDisplayName: FRS-Root-Path
-
adminDescription: FRS-Root-Path
-
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 2048
-
dn: CN=Replication-File-Filter,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-File-Filter
deleteoldrdn: 1
dn: CN=FRS-File-Filter,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSFileFilter
-
adminDisplayName: FRS-File-Filter
-
-
adminDescription: FRS-File-Filter
-
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 2048
-
dn: CN=Replication-Level-Limit,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Level-Limit
deleteoldrdn: 1
dn: CN=FRS-Level-Limit,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSLevelLimit
-
adminDisplayName: FRS-Level-Limit
-
adminDescription: FRS-Level-Limit
-
dn: CN=Replication-Extensions,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Extensions
deleteoldrdn: 1
dn: CN=FRS-Extensions,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSExtensions
-
adminDisplayName: FRS-Extensions
-
adminDescription: FRS-Extensions
-
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 65536
-
dn: CN=Replication-Staging-Path,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Staging-Path
deleteoldrdn: 1
dn: CN=FRS-Staging-Path,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSStagingPath
-
adminDisplayName: FRS-Staging-Path
-
adminDescription: FRS-Staging-Path
-
add: rangeLower
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 2048
-
dn: CN=Code-Package,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: Msi-Script-Path
deleteoldrdn: 1
dn: CN=Msi-Script-Path,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: msiScriptPath
-
adminDisplayName: Msi-Script-Path
-
adminDescription: Msi-Script-Path
-
dn: CN=Replication-DB-Path,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Working-Path
deleteoldrdn: 1
dn: CN=FRS-Working-Path,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSWorkingPath
-
adminDisplayName: FRS-Working-Path
-
adminDescription: FRS-Working-Path
-
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 2048
-
dn: CN=Replica-Version-GUID,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Version-GUID
deleteoldrdn: 1
dn: CN=FRS-Version-GUID,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSVersionGuid
-
adminDisplayName: FRS-Version-GUID
-
adminDescription: FRS-Version-GUID
-
add: rangeLower
rangeLower: 16
-
add: rangeUpper
add: rangeUpper
rangeUpper: 16
-
dn: CN=Replication-Root-Security,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Root-Security
deleteoldrdn: 1
dn: CN=FRS-Root-Security,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSRootSecurity
-
adminDisplayName: FRS-Root-Security
-
adminDescription: FRS-Root-Security
-
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 65535
-
dn: CN=Replication-Update-Timeout,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Update-Timeout
deleteoldrdn: 1
dn: CN=FRS-Update-Timeout,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSUpdateTimeout
-
adminDisplayName: FRS-Update-Timeout
-
adminDescription: FRS-Update-Timeout
-
dn: CN=Replication-Service-Command,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Service-Command
deleteoldrdn: 1
dn: CN=FRS-Service-Command,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSServiceCommand
-
adminDisplayName: FRS-Service-Command
-
adminDescription: FRS-Service-Command
-
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 512
-
dn: CN=Replica-Set-GUID,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Replica-Set-GUID
deleteoldrdn: 1
dn: CN=FRS-Replica-Set-GUID,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSReplicaSetGuid
-
adminDisplayName: FRS-Replica-Set-GUID
-
adminDescription: FRS-Replica-Set-GUID
-
dn: CN=Replication-Status,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Fault-Condition
deleteoldrdn: 1
dn: CN=FRS-Fault-Condition,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSFaultCondition
-
adminDisplayName: FRS-Fault-Condition
-
adminDescription: FRS-Fault-Condition
-
add: rangeLower
rangeLower: 1
-
add: rangeUpper
rangeUpper: 16
-
dn: CN=Replication-Directory-Filter,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Directory-Filter
deleteoldrdn: 1
dn: CN=FRS-Directory-Filter,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSDirectoryFilter
-
adminDisplayName: FRS-Directory-Filter
-
adminDescription: FRS-Directory-Filter
-
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 2048
-
dn: CN=Created-Entry,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: rpc-Ns-Entry-Flags
deleteoldrdn: 1
dn: CN=rpc-Ns-Entry-Flags,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: rpcNsEntryFlags
-
adminDisplayName: rpc-Ns-Entry-Flags
-
adminDescription: rpc-Ns-Entry-Flags
-
dn:
schemaUpdateNow: 1
-
# Class Adds
dn: CN=NTFRS-Member,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: nTFRSMember
adminDisplayName: NTFRS-Member
adminDescription: NTFRS-Member
governsId: 1.2.840.113556.1.5.153
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: hiUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=NTFRS-Member,CN=Schema,CN=Configuration,DC=X
dn: CN=Site-Link-Bridge,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: siteLinkBridge
adminDisplayName: Site-Link-Bridge
adminDescription: Site-Link-Bridge
governsId: 1.2.840.113556.1.5.148
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Site-Link-Bridge,CN=Schema,CN=Configuration,DC=X
dn: CN=RRAS-Administration-Connection-Point,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: rRASAdministrationConnectionPoint
adminDisplayName: RRAS-Administration-Connection-Point
adminDescription: RRAS-Administration-Connection-Point
governsId: 1.2.840.113556.1.5.150
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.94
schemaIdGuid:: vsU5KmCJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=RRAS-Administration-Connection-Point,CN=Schema,CN=Configuration,DC=X
dn: CN=NTFRS-Subscriptions,CN=Schema,CN=Configuration,DC=X
changetype: add
lDAPDisplayName: nTFRSSubscriptions
adminDescription: NTFRS-Subscriptions
adminDisplayName: NTFRS-Subscriptions
governsID: 1.2.840.113556.1.5.154
rDNAttID: 2.5.4.3
subClassOf: 2.5.6.0
schemaIDGUID:: hyUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=NTFRS-Subscriptions,CN=Schema,CN=Configuration,DC=X
dn: CN=Remote-Storage-Service-Point,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: remoteStorageServicePoint
adminDisplayName: Remote-Storage-Service-Point
adminDescription: Remote-Storage-Service-Point
governsId: 1.2.840.113556.1.5.146
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.94
schemaIdGuid:: vcU5KmCJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Remote-Storage-Service-Point,CN=Schema,CN=Configuration,DC=X
dn: CN=Intellimirror-Group,CN=Schema,CN=Configuration,DC=X
changetype: add
lDAPDisplayName: intellimirrorGroup
adminDescription: Intellimirror-Group
adminDisplayName: Intellimirror-Group
governsID: 1.2.840.113556.1.5.152
rDNAttID: 2.5.4.3
schemaIDGUID:: hjA4B9+R0RGuvAAA+ANnwQ==
subClassOf: 2.5.6.0
subClassOf: 2.5.6.0
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Intellimirror-Group,CN=Schema,CN=Configuration,DC=X
dn: CN=Site-Link,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: siteLink
adminDisplayName: Site-Link
adminDescription: Site-Link
governsId: 1.2.840.113556.1.5.147
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Site-Link,CN=Schema,CN=Configuration,DC=X
dn: CN=Intellimirror-SCP,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: intellimirrorSCP
adminDisplayName: Intellimirror-SCP
adminDescription: Intellimirror-SCP
governsId: 1.2.840.113556.1.5.151
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.94
schemaIdGuid:: hTA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Intellimirror-SCP,CN=Schema,CN=Configuration,DC=X
dn: CN=NTFRS-Subscriber,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: nTFRSSubscriber
adminDisplayName: NTFRS-Subscriber
adminDescription: NTFRS-Subscriber
governsId: 1.2.840.113556.1.5.155
rdnAttId: 2.5.4.3
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: iCUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=NTFRS-Subscriber,CN=Schema,CN=Configuration,DC=X
dn: CN=RRAS-Administration-Dictionary,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: rRASAdministrationDictionary
adminDisplayName: RRAS-Administration-Dictionary
adminDescription: RRAS-Administration-Dictionary
governsId: 1.2.840.113556.1.5.156
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: rpib842T0RGuvQAA+ANnwQ==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=RRAS-Administration-Dictionary,CN=Schema,CN=Configuration,DC=X
# Syntax in two attributes got modified. USN-Source and

# Transport-Address-Type. We don't propagate the changes.
# We will delete both and add new attributes
# to replace them.
# Attribute and Class Modifications
dn: CN=Object-Class,CN=Schema,CN=Configuration,DC=X
changetype: modify
searchFlags: 0
-
dn: CN=Surname,CN=Schema,CN=Configuration,DC=X
changetype: modify
add: attributeSecurityGuid
-
dn: CN=State-Or-Province-Name,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Street-Address,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
dn: CN=Title,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Postal-Address,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Postal-Code,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Phone-Office-Other,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Post-Office-Box,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Physical-Delivery-Office-Name,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Phone-Home-Primary,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Telephone-Number,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Telex-Number,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Teletex-Terminal-Identifier,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Facsimile-Telephone-Number,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=X121-Address,CN=Schema,CN=Configuration,DC=X
changetype: modify
changetype: modify
-
dn: CN=International-ISDN-Number,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Registered-Address,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Preferred-Delivery-Method,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Picture,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Phone-Mobile-Primary,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Phone-Pager-Primary,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Initials,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Voice-Mail-Password,CN=Schema,CN=Configuration,DC=X
changetype: modify
attributeSecurityGuid:: spVX5FWU0RGuvQAA+ANnwQ==
-
dn: CN=Voice-Mail-Recorded-Name,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Voice-Mail-Greetings,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Voice-Mail-Flags,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Voice-Mail-Volume,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Voice-Mail-Speed,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Voice-Mail-Recording-Length,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Forwarding-Address,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Personal-Title,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Address-Home,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Phone-Pager-Other,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Phone-Fax-Other,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Phone-Mobile-Other,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Telex-Primary,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Phone-ISDN-Primary,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Assistant,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Categories,CN=Schema,CN=Configuration,DC=X
changetype: modify
add: rangeLower
rangeLower: 36
-
add: rangeUpper
rangeUpper: 36
-
dn: CN=Creator,CN=Schema,CN=Configuration,DC=X
changetype: modify
searchFlags: 0
-
dn: CN=Phone-Ip-Primary,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Phone-Ip-Other,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=WWW-Page-Other,CN=Schema,CN=Configuration,DC=X
changetype: modify
attributeSecurityGuid:: s5VX5FWU0RGuvQAA+ANnwQ==
-
dn: CN=Group-Type,CN=Schema,CN=Configuration,DC=X
changetype: modify
searchFlags: 1
-
add: systemFlags
systemFlags: 2
-
dn: CN=User-Shared-Folder,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=User-Shared-Folder-Other,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Address,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Service-Principal-Name,CN=Schema,CN=Configuration,DC=X
changetype: modify
add: systemFlags
add: systemFlags
systemFlags: 2
-
dn: CN=Phone-Home-Other,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=AutoReply,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=AutoReply-Message,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Package-Flags,CN=Schema,CN=Configuration,DC=X
changetype: modify
searchFlags: 1
-
dn: CN=AutoReply-Subject,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=WWW-Home-Page,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Cross-Ref-Container,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
dn: CN=Inter-Site-Transport,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
dn: CN=Group-Of-Names,CN=Schema,CN=Configuration,DC=X
changetype: modify
replace: objectClassCategory
-
changetype: modify
changetype: modify
-
-
dn: CN=Sam-Domain,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Domain,CN=Schema,CN=Configuration,DC=X
changetype: modify
replace: defaultObjectCategory
defaultObjectCategory: CN=Domain-DNS,CN=Schema,CN=Configuration,DC=X
-
changetype: modify
-
dn: CN=ACS-Policy,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
changetype: modify
-
dn: CN=ACS-Subnet,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Class-Registration,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Inter-Site-Transport-Container,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
delete: systemPossSuperiors
-
changetype: modify
-
dn: CN=Certification-Authority,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Server,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Print-Queue,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Remote-Mail-Recipient,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
-
dn: CN=Storage,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Class-Store,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
changetype: modify
-
dn: CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Package-Registration,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
dn: CN=NTDS-Site-Settings,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=NTDS-Connection,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
-
dn: CN=Category-Registration,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Display-Specifier,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=NTFRS-Settings,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
-
-
-
dn: CN=NTFRS-Replica-Set,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
dn: CN=Query-Policy,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
dn: CN=Ipsec-Negotiation-Policy,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Address-Book-Container,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
dn: CN=Service-Connection-Point,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
# Attribute and Class deletes
# First delete some objects in Config NC before deleting their classes
dn: CN=RPC,CN=Inter-Site Transports,CN=Site Connectors,CN=sites,CN=configuration,DC=X

changetype: delete
dn: CN=Inter-Site Transports,CN=Site Connectors,CN=sites,CN=configuration,DC=X

changetype: delete
dn: CN=Site Connectors,CN=sites,CN=configuration,DC=X

changetype: delete
dn: CN=RAS-X400-Link,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Information-Store-Cfg,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=MHS-Link-Monitoring-Config,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=LocalGroup,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Exchange-Admin-Service,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Eicon-X25-X400-Link,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=X400-Link,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Protocol-Cfg-POP,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DX-Requestor,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Protocol-Cfg-LDAP-Site,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Protocol-Cfg-LDAP-Server,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=COM-Interface,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Mailbox-Agent,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Eicon-X25-Stack,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
dn: CN=Directory-Cfg,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=NNTP-Newsfeed,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=RAS-Stack,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Site-Connector,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Encryption-Cfg,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=View-Container,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Site-Server,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Application-Registration,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Protocol-Cfg-IMAP,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=MHS-Server-Monitoring-Config,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Site-Addressing,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Admin-Extension,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Protocol-Cfg-HTTP,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=MHS-Public-Store,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Add-In,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Transport-Stack,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Protocol-Cfg-NNTP,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Protocol-Cfg-LDAP,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=MHS-Message-Store,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Protocol-Cfg,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Protocol-Cfg-Shared-Site,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=MTA-Cfg,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=MHS-Monitoring-Config,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Mail-Gateway,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Distribution-List,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Protocol-Cfg-Shared-Server,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Local-DXA,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=NTFRS-Site-Settings,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=MTA,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Addr-Type,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=View-Root,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Remote-DXA,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Protocol-Cfg-Shared,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=ADMD,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=PRMD,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Run-As,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Req-Seq,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=To-Site,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Runs-On,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Enabled,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Encrypt,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=COM-App-Id,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=App-Flags,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Form-Data,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=INSAdmin,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=N-Address,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Send-TNEF,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Line-Wrap,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Auth-Orig,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=From-Site,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Types,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Inbound-DN,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=View-Flags,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Imp-Seq,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Req-Seq,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Assistant-Name,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=P-Selector,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Rid-Server,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=S-Selector,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=T-Selector,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=HTTP-Pub-PF,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=OWA-Server,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Svr-Seq,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Domain-Name,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-ReqName,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Conf-Seq,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Auth-Orig-BL,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=COM-PS-CLSID,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Netboot-NIC,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=HTTP-Pub-GAL,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=RAS-Account,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Remote-Site,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Port-Number,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Require-SSL,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Target-MTAs,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Trust-Level,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Can-Create-PF,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Log-Filename,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Contact-Name,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Inbound-Host,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Password,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=RAS-Password,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Content-Type,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Routing-List,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=HTTP-Servers,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=COM-Package-Id,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=MTA-Local-Cred,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Group-By-Attr-1,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=Character-Set,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Delegate-User,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DL-Member-Rule,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Admin-Copy,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Do-OAB-Version,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=COM-Unique-IID,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Computer-Name,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Newsfeed-Type,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Monitor-Clock,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=N-Address-Type,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Inbound-Sites,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Referral-List,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Imp-Seq-USN,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Employee-Type,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Req-Seq-USN,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Role-Occupant,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Site-Affinity,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Unauth-Orig-BL,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Import-Now,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=USN-Intersite,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Outbound-Host,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Export-Now,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Svr-Seq-USN,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=LDAP-Search-Cfg,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Can-Create-PF-BL,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Can-Create-PF-DL,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Local-Admin,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=MTA-Local-Desig,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Imp-Seq-Time,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Req-Seq-Time,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Conf-Seq-USN,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Svr-Seq-Time,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Property-Pages,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Outbound-Sites,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Use-Site-Values,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Newsgroup-List,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Report-To-Owner,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=RTS-Window-Size,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Unauth-Orig,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Admin-Update,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Domain-Replicas,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Can-Not-Create-PF,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Append-ReqCN,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Recipient-CP,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=MDB-Unread-Limit,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Off-Line-AB-Style,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Conf-Req-Time,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Can-Preserve-DNs,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Employee-Number,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Connection-Type,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=RAS-Phone-Number,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Authorized-User,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Site-Folder-GUID,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Site-Proxy-Space,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=SMIME-Alg-List-NA,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Local-Bridge-Head,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Monitor-Servers,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=View-Definition,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Trans-Retry-Mins,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Can-Create-PF-DL-BL,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Logging-Level,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Off-Line-AB-Server,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Inbound-Newsfeed,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Maximum-Object-ID,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=House-Identifier,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Remote-Client,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=HTTP-Pub-GAL-Limit,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Anonymous-Access,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Import-Container,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Monitor-Services,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Supporting-Stack,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Control-Msg-Rules,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Remote-Bridge-Head,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Send-EMail-Message,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Inbound-Accept-All,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Can-Not-Create-PF-BL,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Can-Not-Create-PF-DL,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Connected-Domains,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Gateway-Local-Cred,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Clock-Alert-Repair,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Clock-Alert-Offset,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-In-Template-Map,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Folders-Container,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DL-Mem-Reject-Perms,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Character-Set-List,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Expand-DLs-Locally,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Authorized-Domain,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Local-Initial-Turn,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Home-Public-Server,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Encrypt-Alg-List-NA,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Incoming-Password,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DL-Mem-Submit-Perms,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Outbound-Newsfeed,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=P-Selector-Inbound,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Anonymous-Account,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Num-Of-Open-Retries,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Export-Containers,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Monitored-Servers,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Replica-Set-Server,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Service-Realm-Name,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Aliased-Object-Name,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Site-Folder-Server,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=S-Selector-Inbound,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Outbound-Host-Type,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Off-Line-AB-Schedule,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Trans-Timeout-Mins,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=T-Selector-Inbound,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=RAS-Callback-Number,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=X25-Leased-Line-Port,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=X25-Remote-MTA-Phone,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=X400-Attachment-Type,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Bridgehead-Servers,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Gateway-Local-Desig,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=GWART-Last-Modified,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=X400-Selector-Syntax,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Admin-Extension-DLL,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=List-Public-Folders,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Lockout-Disconnect,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Display-Name-Suffix,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Certificate-Chain-V3,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Out-Template-Map,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=SMIME-Alg-List-Other,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Space-Last-Computed,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Over-Site-Connector,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=RAS-Remote-SRVR-Name,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=RTS-Checkpoint-Size,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Proxy-Generator-DLL,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Remote-Out-BH-Server,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Open-Retry-Interval,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=XMIT-Timeout-Normal,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=NNTP-Distributions,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=XMIT-Timeout-Urgent,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=MDB-Backoff-Interval,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Import-Sensitivity,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=SMIME-Alg-Selected-NA,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Can-Not-Create-PF-DL-BL,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Enabled-Protocol-Cfg,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DL-Mem-Reject-Perms-BL,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Clock-Warning-Repair,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Replication-Stagger,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Clock-Warning-Offset,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=X25-Leased-or-Switched,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Exchange-Options,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Control-Msg-Folder-ID,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Service-Action-Other,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Service-Action-First,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DL-Mem-Submit-Perms-BL,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Temp-Assoc-Threshold,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Template-Options,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Gateway-Routing-Tree,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Authorized-Password,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Group-By-Attr-Value-DN,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Return-Exact-Msg-Size,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Client-Access-Enabled,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Report-To-Originator,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=RTS-Recovery-Timeout,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Off-Line-AB-Containers,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Enable-Compatibility,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Association-Lifetime,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Service-Action-Second,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Cross-Certificate-CRL,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Responsible-Local-DXA,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Encapsulation-Method,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Inbound-Newsfeed-Type,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=MDB-Msg-Time-Out-Period,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Service-Restart-Delay,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Authentication-To-Use,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=HTTP-Pub-AB-Attributes,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Encrypt-Alg-List-Other,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Group-By-Attr-Value-Str,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Hide-DL-Membership,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Filter-Local-Addresses,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Encrypt-Alg-Selected-NA,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Default-Message-Format,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Conf-Container-List,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Translation-Table-Used,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Disabled-Gateway-Proxy,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Native-Address-Type,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Template-TimeStamp,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Monitoring-Alert-Delay,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Replication-Boot-State,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Connection-List-Filter,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Assoc-Protocol-Cfg-NNTP,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Monitoring-Recipients,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Prev-Remote-Entries,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Num-Of-Transfer-Retries,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=CA-Exchange-Certificate,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Outgoing-Msg-Size-Limit,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Monitoring-Alert-Units,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=OOF-Reply-To-Originator,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Disable-Deferred-Commit,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Turn-Request-Threshold,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=XMIT-Timeout-Non-Urgent,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=SMIME-Alg-Selected-Other,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Service-Restart-Message,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=COM-Auto-Convert-Class-Id,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=RAS-Phonebook-Entry-Name,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=NNTP-Distributions-Flag,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Local-Bridge-Head-Address,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Transfer-Timeout-Normal,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Transfer-Retry-Interval,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Transfer-Timeout-Urgent,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Message-Tracking-Enabled,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=CA-Signature-Certificate,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Bidirectional-Connector,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=X25-Call-User-Data-Incoming,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Available-Distributions,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Replication-Mail-Msg-Size,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=X25-Call-User-Data-Outgoing,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Transport-Expedited-Data,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-UnConf-Container-List,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Prev-Exchange-Options,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Monitoring-Warning-Delay,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Session-Disconnect-Timer,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Prev-Template-Options,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Quota-Notification-Style,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Root-Newsgroups-Folder-ID,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Monitoring-Warning-Units,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Remote-Bridge-Head-Address,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Export-Custom-Recipients,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Support-SMIME-Signatures,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Encrypt-Alg-Selected-Other,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Container-Administrators,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Monitoring-Recipients-NDR,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Two-Way-Alternate-Facility,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Preserve-Internet-Content,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Prev-Export-Native-Only,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=X25-Facilities-Data-Incoming,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=X25-Facilities-Data-Outgoing,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Default-Intra-Site-Schedule,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Default-Inter-Site-Schedule,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Connection-List-Filter-Type,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Transfer-Timeout-Non-Urgent,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Quota-Notification-Schedule,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=CA-Exchange-Certificate-Chain,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Authorized-Password-Confirm,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Monitoring-Normal-Poll-Units,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=CA-Signature-Certificate-Chain,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Certificate-Revocation-List-V1,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
dn: CN=Monitoring-Hotsite-Poll-Units,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Enabled-Authorization-Packages,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Prev-In-Exchange-Sensitivity,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Monitoring-Normal-Poll-Interval,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Monitoring-Escalation-Procedure,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=DXA-Prev-Replication-Sensitivity,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Monitoring-Hotsite-Poll-Interval,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Available-Authorization-Packages,CN=Schema,CN=Configuration,DC=X
changetype: delete
# Changes for earlier schemas
dn: CN=Application-Entity,CN=schema,CN=configuration,DC=X
changetype: modify
systemMustContain: presentationAddress
-
dn: CN=DMD,CN=schema,CN=configuration,DC=X
changetype: modify
systemMayContain: foreignDSAs
-
dn: CN=NTDS-DSA,CN=schema,CN=configuration,DC=X
changetype: modify
systemMayContain: presentationAddress
-
dn: CN=Top,CN=schema,CN=configuration,DC=X
changetype: modify
systemMayContain: masterDSA
-
dn: CN=Foreign-DSAs,CN=schema,CN=configuration,dc=X
changetype: delete
dn: CN=Presentation-Address,CN=schema,CN=configuration,dc=X
changetype: delete
dn: CN=Ref-Full-Replicas,CN=schema,CN=configuration,dc=X
changetype: delete
dn: CN=Ref-Master-DSA,CN=schema,CN=configuration,dc=X
changetype: delete
# End of changes for earlier schemas
dn:
changetype: modify
schemaUpdateNow: 1
-
# Config NC changes
# Extended rights
dn: CN=Open-Address-Book,CN=Extended-Rights,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
hideFromAB: TRUE
appliesTo: 3e74f60f-3e73-11d1-a9c0-0000f80367c1
displayName: Open Address Book
rightsGuid: a1990816-4298-11d1-ade2-00c04fd8d5cd
changetype: add
hideFromAB: TRUE
appliesTo: bf967aba-0de6-11d0-a285-00aa003049e2
displayName: Modify Personal Information
rightsGuid: 77B5B886-944A-11d1-AEBD-0000F80367C1
dn: CN=Email-Information,CN=Extended-Rights,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
displayName: Modify Email Information
rightsGuid: E45795B2-9455-11d1-AEBD-0000F80367C1
dn: CN=Web-Information,CN=Extended-Rights,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
displayName: Modify Web Information
# Display-Specifiers
dn: CN=localGroup-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: delete
dn: CN=nTFRSSettings-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
adminPropertyPages: 1,{9da6fd68-c63b-11d0-b94d-00c04fd8d5b0}
adminContextmenu: 0,{6971d64e-f335-11d0-b0bc-00c04fd8dca6}
classDisplayName: NTFRS Settings
dn: CN=nTFRSReplicaSet-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
classDisplayName: NTFRS Replica Set
dn: CN=mSFTFRS-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
adminPropertyPages: 1,{9da6fd6a-c63b-11d0-b94d-00c04fd8d5b0}
classDisplayName: Microsoft FRS
dn: CN=user-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
add: treatAsLeaf
treatAsLeaf: TRUE
-
delete: adminPropertyPages
-
adminPropertyPages: 5,{FD57D295-4FD9-11D1-854E-00C04FC31FD3}
-
delete: attributeDisplayNames
attributeDisplayNames: comment,Comment
attributeDisplayNames: company,Company
attributeDisplayNames: distinguishedName,X500 DN
attributeDisplayNames: facsimileTelephoneNumber, Facsimile Telephone Numbers
attributeDisplayNames: generationQualifier, Generation Qualifier
attributeDisplayNames: internationalISDNNumber, International ISDN Number
attributeDisplayNames: mobile,Cellular Phone Number
attributeDisplayNames: personalTitle,Personal Title
attributeDisplayNames: physicalDeliveryOfficeName,Delivery Office
attributeDisplayNames: postalCode,ZIP Code
attributeDisplayNames: primaryGroupID,Primary Group SID
attributeDisplayNames: streetAddress,Address
attributeDisplayNames: telephoneNumber,Telephone Number
attributeDisplayNames: title,Title
attributeDisplayNames: url,Web Page Address
attributeDisplayNames: userAccountControl,User Account Control Flags
-
add: attributeDisplayNames
attributeDisplayNames: assistant,Assistant
attributeDisplayNames: comment,User Account Comment
attributeDisplayNames: co,Company
attributeDisplayNames: distinguishedName,X500 Distinguished Name
attributeDisplayNames: facsimileTelephoneNumber,Facsimile Telephone Number
attributeDisplayNames: generationQualifier,Name Suffix
attributeDisplayNames: internationalISDNNumber, International ISDN Number (Others)
attributeDisplayNames: ipPhone,IP Phone Number
attributeDisplayNames: mobile,Primary Mobile Phone Number
attributeDisplayNames: otherFacsimileTelephoneNumber,Facsimile Telephone Number (Others)
attributeDisplayNames: otherHomePhone,Home Phone (Others)
attributeDisplayNames: otherIpPhone,IP Phone Number (Others)
attributeDisplayNames: otherMailbox,E-Mail Address (Others)
attributeDisplayNames: otherMobile,Mobile Phone Number (Others)
attributeDisplayNames: otherPager,Pager Number (Others)
attributeDisplayNames: otherTelephone,Office Telephone Number (Others)
attributeDisplayNames: personalTitle,Title
attributeDisplayNames: physicalDeliveryOfficeName,Office Location
attributeDisplayNames: postalCode,ZIP/Postal Code
attributeDisplayNames: primaryInternationalISDNNumber,International ISDN Number
attributeDisplayNames: primaryTelexNumber,Telex Number
attributeDisplayNames: streetAddress,Other Address
attributeDisplayNames: telephoneNumber,Primary Phone
attributeDisplayNames: telexNumber,Telex Number (Others)
attributeDisplayNames: url,Web Page Address (Others)
attributeDisplayNames: userPrincipalName,Logon Name
attributeDisplayNames: wWWHomePage,Web Page Address
-
dn: CN=group-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
attributeDisplayNames: desctription,Description
attributeDisplayNames: contactName,Contact Name
attributeDisplayNames: groupAttributes,Group Attribute Flags
-
attributeDisplayNames: managedBy,Managed By
-
changetype: modify
delete: classDisplayName
classDisplayName: Domain (DNS)
-
add: classDisplayName
classDisplayName: Domain
-
-
dn: CN=contact-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
attributeDisplayNames: department,Department
attributeDisplayNames: directReports,Direct Reports
attributeDisplayNames: division,Division
attributeDisplayNames: employeeID,Employee ID
attributeDisplayNames: givenName,First Name
attributeDisplayNames: homePhone,Home Phone
attributeDisplayNames: homePostalAddress,Home Address
attributeDisplayNames: info,Notes
attributeDisplayNames: initials,Initials
attributeDisplayNames: internationalISDNNumber,International ISDN Number (Others)
attributeDisplayNames: l,City
attributeDisplayNames: mail,E-Mail Address
attributeDisplayNames: manager,Manager
attributeDisplayNames: memberOf,Group Membership
attributeDisplayNames: middleName,Middle Name
attributeDisplayNames: otherHomePhone,Home Phone Number (Others)
attributeDisplayNames: otherTelephone,Telephone Number (Others)
attributeDisplayNames: postOfficeBox,Post Office Box
attributeDisplayNames: sn,Last Name
attributeDisplayNames: st,State
-
dn: CN=domainPolicy-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
adminPropertyPages: 4,{AAD30A04-E1D0-11d0-B859-00A024CDD4DE}
-
-
dn: CN=serviceAdministrationPoint-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
classDisplayName: Service Administration Point
-
classDisplayName: Service
-
changetype: modify
attributeDisplayNames: operatingSystem,Operating System
attributeDisplayNames: operatingSystemVersion,Operating System Version
attributeDisplayNames: type,Type
-
dn: CN=printQueue-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
attributeDisplayNames: cn,Directory Service Name
attributeDisplayNames: uNCName,Network Name
attributeDisplayNames: assetNumber,Asset Number
attributeDisplayNames: bytesPerMinute,Bytes per Minute
attributeDisplayNames: contactName,Contact
attributeDisplayNames: description,Comment
attributeDisplayNames: driverName,Model
attributeDisplayNames: driverVersion,Driver Version
attributeDisplayNames: location,Location
attributeDisplayNames: portName,Port
attributeDisplayNames: printBinNames,Input Trays
attributeDisplayNames: printCollate,Supports Collation
attributeDisplayNames: printColor,Supports Color Printing
attributeDisplayNames: printDuplexSupported,Supports Double-sided Printing
attributeDisplayNames: printerName,Name
attributeDisplayNames: printFormName,Form Name
attributeDisplayNames: printLanguage,Data Format
attributeDisplayNames: printMACAddress,Physical Network Address
attributeDisplayNames: printMaxCopies,Maximum Number of Copies
attributeDisplayNames: printMaxResolutionSupported,Maximum Resolution
attributeDisplayNames: printMaxXExtent,Maximum Printable Width
attributeDisplayNames: printMaxYExtent,Maximum Printable Height
attributeDisplayNames: printMediaReady,Paper Available
attributeDisplayNames: printMediaSupported,Paper Types Supported
attributeDisplayNames: printMemory,Installed Memory
attributeDisplayNames: printMinXExtent,Minimum Printable Width
attributeDisplayNames: printMinYExtent,Minimum Printable Height
attributeDisplayNames: printNetworkAddress,Network Address
attributeDisplayNames: printNumberUp,Supports N-Up Printing
attributeDisplayNames: printOrientationsSupported,Orientations Supported
attributeDisplayNames: printOwner,Owner Name
attributeDisplayNames: printRate,Speed
attributeDisplayNames: printRateUnit,Speed Units
attributeDisplayNames: printPagesPerMinute,Pages per Minute
attributeDisplayNames: printShareName,Share Name
attributeDisplayNames: printStaplingSupported,Supports Stapling
attributeDisplayNames: printStatus,State
attributeDisplayNames: priority,Print Job Priority
attributeDisplayNames: serverName,Server Name
attributeDisplayNames: versionNumber,Object Version
attributeDisplayNames: whenChanged,Date Modified
attributeDisplayNames: whenCreated,Date Created
-
dn: CN=organizationalUnit-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
-
dn: CN=trustedDomain-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
-
dn: CN=volume-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
attributeDisplayNames: uNCName,Network Path
-
classDisplayName: Volume
-
classDisplayName: Shared Folder
-
dn: CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=X

changetype: add
objectClass: interSiteTransportContainer
hideFromAB: TRUE
dn: CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=X

changetype: add
objectClass: interSiteTransport
transportDllName: ismip.dll
hideFromAB: TRUE
dn: CN=SMTP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=X

changetype: add
transportDllName: ismsmtp.dll
hideFromAB: TRUE
dn: CN=Default Query Policy,CN=Query-Policies,CN=Directory Service,CN=Windows

changetype: delete

changetype: add
objectClass: queryPolicy
lDAPAdminLimits: MaxConnections=1000
lDAPAdminLimits: InitRecvTimeout=120
lDAPAdminLimits: AllowDeepNonIndexSearch=False
lDAPAdminLimits: MaxConnIdleTime=900
lDAPAdminLimits: MaxActiveQueries=20
lDAPAdminLimits: MaxNotificationPerConn=5
lDAPAdminLimits: MaxPageSize=1000
lDAPAdminLimits: MaxQueryDuration=120
lDAPAdminLimits: MaxTempTableSize=10000
lDAPAdminLimits: MaxResultSetSize=262144
lDAPAdminLimits: MaxPoolThreads=4
lDAPAdminLimits: MaxDatagramRecv=4096
hideFromAB: TRUE
# Used to decide if earlier changes are present,

# so delete this last
dn: CN=Master-DSA,CN=schema,CN=configuration,dc=X
changetype: delete
# Object-Version on schema container
dn: CN=schema,CN=configuration,DC=X
changetype: modify
add: objectVersion
objectVersion: 1
-
Sch00.ldf
changetype: delete
changetype: delete
Sch1.ldf
changetype: add
hideFromAB: TRUE
classDisplayName: Container
changetype: add
hideFromAB: TRUE
# Attribute Adds
dn: CN=Pek-List,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: pekList
adminDisplayName: Pek-List
adminDescription: Pek-List
attributeId: 1.2.840.113556.1.4.865
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gzA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
systemFlags: 1
dn: CN=FRS-Flags,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSFlags
adminDisplayName: FRS-Flags
adminDescription: FRS-Flags
attributeId: 1.2.840.113556.1.4.874
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fSUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Site-List,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: siteList
adminDisplayName: Site-List
adminDescription: Site-List
attributeId: 1.2.840.113556.1.4.821
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 3CwM1VGJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Msi-Script,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msiScript
adminDisplayName: Msi-Script
adminDescription: Msi-Script
attributeId: 1.2.840.113556.1.4.814
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: E4Ph2TmJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Version,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSVersion
adminDisplayName: FRS-Version
adminDescription: FRS-Version
attributeId: 1.2.840.113556.1.4.882
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32
schemaIdGuid:: hSUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Treat-As-Leaf,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: treatAsLeaf
adminDisplayName: Treat-As-Leaf
adminDescription: Treat-As-Leaf
attributeId: 1.2.840.113556.1.4.806
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 40TQjx930RGurgAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Product-Code,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: productCode
adminDisplayName: Product-Code
adminDescription: Product-Code
attributeId: 1.2.840.113556.1.4.818
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 16
schemaIdGuid:: F4Ph2TmJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
changetype: add
ldapDisplayName: dNSHostName
adminDisplayName: DNS-Host-Name
adminDescription: DNS-Host-Name
attributeId: 1.2.840.113556.1.4.619
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2048
schemaIdGuid:: R5Xjchh70RGt7wDAT9jVzQ==
hideFromAB: TRUE
dn: CN=Create-Dialog,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: createDialog
adminDescription: Create-Dialog
attributeId: 1.2.840.113556.1.4.810
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ipUJKzGJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
changetype: add
ldapDisplayName: netbootSCPBL
adminDisplayName: netboot-SCP-BL
adminDescription: netboot-SCP-BL
attributeId: 1.2.840.113556.1.4.864
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gjA4B9+R0RGuvAAA+ANnwQ==
linkID: 101
hideFromAB: TRUE
systemFlags: 1
dn: CN=Site-Link-List,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: siteLinkList
adminDisplayName: Site-Link-List
adminDescription: Site-Link-List
attributeId: 1.2.840.113556.1.4.822
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 3SwM1VGJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Tools,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootTools
adminDisplayName: netboot-Tools
adminDescription: netboot-Tools
attributeId: 1.2.840.113556.1.4.858
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fzA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Msi-Script-Name,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msiScriptName
adminDisplayName: Msi-Script-Name
adminDescription: Msi-Script-Name
attributeId: 1.2.840.113556.1.4.845
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Yt2nlhiR0RGuvAAA+ANnwQ==
hideFromAB: TRUE
changetype: add
ldapDisplayName: netbootServer
adminDisplayName: netboot-Server
adminDescription: netboot-Server
attributeId: 1.2.840.113556.1.4.860
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gTA4B9+R0RGuvAAA+ANnwQ==
linkID: 100
hideFromAB: TRUE
dn: CN=Msi-Script-Size,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msiScriptSize
adminDisplayName: Msi-Script-Size
adminDescription: Msi-Script-Size
attributeId: 1.2.840.113556.1.4.846
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Y92nlhiR0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=LDAP-IPDeny-List,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: lDAPIPDenyList
adminDisplayName: LDAP-IPDeny-List
adminDescription: LDAP-IPDeny-List
attributeId: 1.2.840.113556.1.4.844
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: U6NZc/eQ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Install-Ui-Level,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: installUiLevel
adminDisplayName: Install-Ui-Level
adminDescription: Install-Ui-Level
attributeId: 1.2.840.113556.1.4.847
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ZN2nlhiR0RGuvAAA+ANnwQ==
hideFromAB: TRUE
changetype: add
adminDisplayName: Terminal-Server
adminDescription: Terminal-Server
attributeId: 1.2.840.113556.1.4.885
omSyntax: 4
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: HJq2bSKU0RGuvQAA+ANnwQ==
hideFromAB: TRUE
dn: CN=LDAP-Admin-Limits,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: lDAPAdminLimits
adminDisplayName: LDAP-Admin-Limits
adminDescription: LDAP-Admin-Limits
attributeId: 1.2.840.113556.1.4.843
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: UqNZc/eQ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Create-Wizard-Ext,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: createWizardExt
adminDisplayName: Create-Wizard-Ext
adminDescription: Create-Wizard-Ext
attributeId: 1.2.840.113556.1.4.812
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: i5UJKzGJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Purported-Search,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: purportedSearch
adminDisplayName: Purported-Search
adminDescription: Purported-Search
attributeId: 1.2.840.113556.1.4.886
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2048
schemaIdGuid:: UE61tDqU0RGuvQAA+ANnwQ==
hideFromAB: TRUE
changetype: add
ldapDisplayName: msRRASAttribute
adminDisplayName: ms-RRAS-Attribute
adminDescription: ms-RRAS-Attribute
attributeId: 1.2.840.113556.1.4.884
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: rZib842T0RGuvQAA+ANnwQ==
hideFromAB: TRUE
dn: CN=File-Ext-Priority,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fileExtPriority
adminDisplayName: File-Ext-Priority
adminDescription: File-Ext-Priority
attributeId: 1.2.840.113556.1.4.816
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: FYPh2TmJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Can-Upgrade-Script,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: canUpgradeScript
adminDisplayName: Can-Upgrade-Script
adminDescription: Can-Upgrade-Script
attributeId: 1.2.840.113556.1.4.815
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: FIPh2TmJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=App-Schema-Version,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: appSchemaVersion
adminDisplayName: App-Schema-Version
adminDescription: App-Schema-Version
attributeId: 1.2.840.113556.1.4.848
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Zd2nlhiR0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Primary-Member,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSPrimaryMember
adminDisplayName: FRS-Primary-Member
adminDescription: FRS-Primary-Member
attributeId: 1.2.840.113556.1.4.878
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
linkId: 106
schemaIdGuid:: gSUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
changetype: add
ldapDisplayName: remoteStorageGUID
adminDisplayName: Remote-Storage-GUID
adminDescription: Remote-Storage-GUID
attributeId: 1.2.840.113556.1.4.809
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: sMU5KmCJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Max-Clients,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootMaxClients
adminDisplayName: netboot-Max-Clients
adminDescription: netboot-Max-Clients
attributeId: 1.2.840.113556.1.4.851
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: eDA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Member-Reference,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSMemberReference
adminDisplayName: FRS-Member-Reference
adminDescription: FRS-Member-Reference
attributeId: 1.2.840.113556.1.4.875
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fiUTKnOT0RGuvAAA+ANnwQ==
linkID: 104
hideFromAB: TRUE
systemFlags: 2
dn: CN=Upgrade-Product-Code,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: upgradeProductCode
adminDisplayName: Upgrade-Product-Code
adminDescription: Upgrade-Product-Code
attributeId: 1.2.840.113556.1.4.813
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 16
schemaIdGuid:: EoPh2TmJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Time-Last-Command,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSTimeLastCommand
adminDisplayName: FRS-Time-Last-Command
adminDescription: FRS-Time-Last-Command
attributeId: 1.2.840.113556.1.4.880
omSyntax: 23
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gyUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-New-Machine-OU,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootNewMachineOU
adminDisplayName: netboot-New-Machine-OU
adminDescription: netboot-New-Machine-OU
attributeId: 1.2.840.113556.1.4.856
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fTA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Limit-Clients,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootLimitClients
adminDisplayName: netboot-Limit-Clients
adminDescription: netboot-Limit-Clients
attributeId: 1.2.840.113556.1.4.850
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: dzA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Signature-Algorithms,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: signatureAlgorithms
adminDisplayName: Signature-Algorithms
adminDescription: Signature-Algorithms
attributeId: 1.2.840.113556.1.4.824
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ssU5KmCJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Partner-Auth-Level,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSPartnerAuthLevel
adminDisplayName: FRS-Partner-Auth-Level
adminDescription: FRS-Partner-Auth-Level
attributeId: 1.2.840.113556.1.4.877
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gCUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
changetype: add
ldapDisplayName: enrollmentProviders
adminDisplayName: Enrollment-Providers
adminDescription: Enrollment-Providers
attributeId: 1.2.840.113556.1.4.825
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: s8U5KmCJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
changetype: add
ldapDisplayName: fRSMemberReferenceBL
adminDisplayName: FRS-Member-Reference-BL
adminDescription: FRS-Member-Reference-BL
attributeId: 1.2.840.113556.1.4.876
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fyUTKnOT0RGuvAAA+ANnwQ==
linkID: 105
hideFromAB: TRUE
systemFlags: 1
dn: CN=Certificate-Templates,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: certificateTemplates
adminDisplayName: Certificate-Templates
adminDescription: Certificate-Templates
attributeId: 1.2.840.113556.1.4.823
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: scU5KmCJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Pek-Key-Change-Interval,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: pekKeyChangeInterval
adminDisplayName: Pek-Key-Change-Interval
adminDescription: Pek-Key-Change-Interval
attributeId: 1.2.840.113556.1.4.866
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: hDA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Localized-Description,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: localizedDescription
adminDisplayName: Localized-Description
adminDescription: Localized-Description
attributeId: 1.2.840.113556.1.4.817
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: FoPh2TmJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Frs-Computer-Reference,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: frsComputerReference
adminDisplayName: Frs-Computer-Reference
adminDescription: Frs-Computer-Reference
attributeId: 1.2.840.113556.1.4.869
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: eCUTKnOT0RGuvAAA+ANnwQ==
linkID: 102
systemFlags: 2
hideFromAB: TRUE
changetype: add
ldapDisplayName: altSecurityIdentities
adminDisplayName: Alt-Security-Identities
adminDescription: Alt-Security-Identities
attributeId: 1.2.840.113556.1.4.867
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: DPP7AP6R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Answer-Requests,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootAnswerRequests
adminDisplayName: netboot-Answer-Requests
adminDescription: netboot-Answer-Requests
attributeId: 1.2.840.113556.1.4.853
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ejA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
changetype: add
ldapDisplayName: bridgeheadServerListBL
adminDisplayName: Bridgehead-Server-List-BL
adminDescription: Bridgehead-Server-List-BL
attributeId: 1.2.840.113556.1.4.820
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
linkID: 99
hideFromAB: TRUE
hideFromAB: TRUE
systemFlags: 1
changetype: add
ldapDisplayName: frsComputerReferenceBL
adminDisplayName: Frs-Computer-Reference-BL
adminDescription: Frs-Computer-Reference-BL
attributeId: 1.2.840.113556.1.4.870
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: eSUTKnOT0RGuvAAA+ANnwQ==
linkID: 103
hideFromAB: TRUE
systemFlags: 1
dn: CN=FRS-Control-Data-Creation,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSControlDataCreation
adminDisplayName: FRS-Control-Data-Creation
adminDescription: FRS-Control-Data-Creation
attributeId: 1.2.840.113556.1.4.871
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32
schemaIdGuid:: eiUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Is-Critical-System-Object,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: isCriticalSystemObject
adminDisplayName: Is-Critical-System-Object
adminDescription: Is-Critical-System-Object
attributeId: 1.2.840.113556.1.4.868
omSyntax: 1
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: DfP7AP6R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Allow-New-Clients,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootAllowNewClients
adminDisplayName: netboot-Allow-New-Clients
adminDescription: netboot-Allow-New-Clients
attributeId: 1.2.840.113556.1.4.849
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
hideFromAB: TRUE
dn: CN=FRS-Time-Last-Config-Change,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSTimeLastConfigChange
adminDisplayName: FRS-Time-Last-Config-Change
adminDescription: FRS-Time-Last-Config-Change
attributeId: 1.2.840.113556.1.4.881
omSyntax: 23
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: hCUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Bridgehead-Transport-List,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: bridgeheadTransportList
adminDisplayName: Bridgehead-Transport-List
adminDescription: Bridgehead-Transport-List
attributeId: 1.2.840.113556.1.4.819
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
linkID: 98
hideFromAB: TRUE
dn: CN=FRS-Service-Command-Status,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSServiceCommandStatus
adminDisplayName: FRS-Service-Command-Status
adminDescription: FRS-Service-Command-Status
attributeId: 1.2.840.113556.1.4.879
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 512
schemaIdGuid:: giUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Control-Inbound-Backlog,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSControlInboundBacklog
adminDisplayName: FRS-Control-Inbound-Backlog
adminDescription: FRS-Control-Inbound-Backlog
attributeId: 1.2.840.113556.1.4.872
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32
schemaIdGuid:: eyUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-IntelliMirror-OSes,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootIntelliMirrorOSes
adminDisplayName: netboot-IntelliMirror-OSes
adminDescription: netboot-IntelliMirror-OSes
attributeId: 1.2.840.113556.1.4.857
attributeId: 1.2.840.113556.1.4.857
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fjA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=FRS-Control-Outbound-Backlog,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fRSControlOutboundBacklog
adminDisplayName: FRS-Control-Outbound-Backlog
adminDescription: FRS-Control-Outbound-Backlog
attributeId: 1.2.840.113556.1.4.873
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32
schemaIdGuid:: fCUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Current-Client-Count,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootCurrentClientCount
adminDisplayName: netboot-Current-Client-Count
adminDescription: netboot-Current-Client-Count
attributeId: 1.2.840.113556.1.4.852
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: eTA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=IPSEC-Negotiation-Policy-Type,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: iPSECNegotiationPolicyType
adminDisplayName: IPSEC-Negotiation-Policy-Type
adminDescription: IPSEC-Negotiation-Policy-Type
attributeId: 1.2.840.113556.1.4.887
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: dDA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=ms-RRAS-Vendor-Attribute-Entry,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRRASVendorAttributeEntry
adminDisplayName: ms-RRAS-Vendor-Attribute-Entry
adminDescription: ms-RRAS-Vendor-Attribute-Entry
attributeId: 1.2.840.113556.1.4.883
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: rJib842T0RGuvQAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Locally-Installed-OSes,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootLocallyInstalledOSes
adminDisplayName: netboot-Locally-Installed-OSes
adminDescription: netboot-Locally-Installed-OSes
attributeId: 1.2.840.113556.1.4.859
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gDA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=IPSEC-Negotiation-Policy-Action,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: iPSECNegotiationPolicyAction
adminDisplayName: IPSEC-Negotiation-Policy-Action
adminDescription: IPSEC-Negotiation-Policy-Action
attributeId: 1.2.840.113556.1.4.888
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: dTA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-New-Machine-Naming-Policy,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootNewMachineNamingPolicy
adminDisplayName: netboot-New-Machine-Naming-Policy
adminDescription: netboot-New-Machine-Naming-Policy
attributeId: 1.2.840.113556.1.4.855
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fDA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=netboot-Answer-Only-Valid-Clients,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: netbootAnswerOnlyValidClients
adminDisplayName: netboot-Answer-Only-Valid-Clients
adminDescription: netboot-Answer-Only-Valid-Clients
attributeId: 1.2.840.113556.1.4.854
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ezA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
dn: CN=UPN-Suffixes,CN=Schema,CN=Configuration,DC=X
changetype: add
lDAPDisplayName: uPNSuffixes
adminDescription: UPN-Suffixes
adminDisplayName: UPN-Suffixes
attributeID: 1.2.840.113556.1.4.890
attributeID: 1.2.840.113556.1.4.890
oMSyntax: 64
schemaIDGUID:: v2AhAySY0RGuwAAA+ANnwQ==
searchFlags: 0
systemOnly: FALSE
hideFromAB: TRUE
dn: CN=Additional-Trusted-Service-Names,CN=Schema,CN=Configuration,DC=X
changetype: add
lDAPDisplayName: additionalTrustedServiceNames
adminDescription: Additional-Trusted-Service-Names
adminDisplayName: Additional-Trusted-Service-Names
attributeID: 1.2.840.113556.1.4.889
oMSyntax: 64
schemaIDGUID:: vmAhAySY0RGuwAAA+ANnwQ==
searchFlags: 0
systemOnly: FALSE
hideFromAB: TRUE
# Change because OID got reused with different syntax.

# We will delete Replica-Set-Type, and add FRS-Replica-Set-Type
# with a new OID.
dn: CN=NTFRS-Replica-Set,CN=schema,CN=configuration,DC=X
changetype: modify
-
dn: CN=Replica-Set-Type,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn:
changetype: modify
schemaUpdateNow: 1
-
changetype: add
ldapDisplayName: fRSReplicaSetType
attributeId: 1.2.840.113556.1.4.31
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: a3PZJnBg0RGpxgAA+ANnwQ==
hideFromAB: TRUE
# End of change
# Attribute Renames, plus some modifies in some cases
dn: CN=Replication-DS-Poll,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-DS-Poll
deleteoldrdn: 1
dn: CN=FRS-DS-Poll,CN=schema,CN=configuration,DC=X
changetype: modify
changetype: modify
ldapDisplayName: fRSDSPoll
-
adminDisplayName: FRS-DS-Poll
-
adminDescription: FRS-DS-Poll
-
dn: CN=Com-Unique-Cat-Id,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: Category-Id
deleteoldrdn: 1
dn: CN=Category-Id,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: categoryId
-
adminDisplayName: Category-Id
-
adminDescription: Category-Id
-
dn: CN=Replication-Root-Path,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Root-Path
deleteoldrdn: 1
dn: CN=FRS-Root-Path,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSRootPath
-
adminDisplayName: FRS-Root-Path
-
adminDescription: FRS-Root-Path
-
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 2048
-
dn: CN=Replication-File-Filter,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-File-Filter
deleteoldrdn: 1
dn: CN=FRS-File-Filter,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSFileFilter
-
adminDisplayName: FRS-File-Filter
-
adminDescription: FRS-File-Filter
-
-
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 2048
-
dn: CN=Replication-Level-Limit,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Level-Limit
deleteoldrdn: 1
dn: CN=FRS-Level-Limit,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSLevelLimit
-
adminDisplayName: FRS-Level-Limit
-
adminDescription: FRS-Level-Limit
-
dn: CN=Replication-Extensions,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Extensions
deleteoldrdn: 1
dn: CN=FRS-Extensions,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSExtensions
-
adminDisplayName: FRS-Extensions
-
adminDescription: FRS-Extensions
-
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 65536
-
dn: CN=Replication-Staging-Path,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Staging-Path
deleteoldrdn: 1
dn: CN=FRS-Staging-Path,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSStagingPath
-
adminDisplayName: FRS-Staging-Path
-
adminDescription: FRS-Staging-Path
-
add: rangeLower
rangeLower: 0
-
add: rangeUpper
add: rangeUpper
rangeUpper: 2048
-
dn: CN=Code-Package,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: Msi-Script-Path
deleteoldrdn: 1
dn: CN=Msi-Script-Path,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: msiScriptPath
-
adminDisplayName: Msi-Script-Path
-
adminDescription: Msi-Script-Path
-
dn: CN=Replication-DB-Path,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Working-Path
deleteoldrdn: 1
dn: CN=FRS-Working-Path,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSWorkingPath
-
adminDisplayName: FRS-Working-Path
-
adminDescription: FRS-Working-Path
-
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 2048
-
dn: CN=Replica-Version-GUID,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Version-GUID
deleteoldrdn: 1
dn: CN=FRS-Version-GUID,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSVersionGuid
-
adminDisplayName: FRS-Version-GUID
-
adminDescription: FRS-Version-GUID
-
add: rangeLower
rangeLower: 16
-
add: rangeUpper
rangeUpper: 16
-
dn: CN=Replication-Root-Security,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Root-Security
deleteoldrdn: 1
dn: CN=FRS-Root-Security,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSRootSecurity
-
adminDisplayName: FRS-Root-Security
-
adminDescription: FRS-Root-Security
-
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 65535
-
dn: CN=Replication-Update-Timeout,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Update-Timeout
deleteoldrdn: 1
dn: CN=FRS-Update-Timeout,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSUpdateTimeout
-
adminDisplayName: FRS-Update-Timeout
-
adminDescription: FRS-Update-Timeout
-
dn: CN=Replication-Service-Command,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Service-Command
deleteoldrdn: 1
dn: CN=FRS-Service-Command,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSServiceCommand
-
adminDisplayName: FRS-Service-Command
-
adminDescription: FRS-Service-Command
-
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 512
-
dn: CN=Replica-Set-GUID,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Replica-Set-GUID
deleteoldrdn: 1
dn: CN=FRS-Replica-Set-GUID,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSReplicaSetGuid
-
adminDisplayName: FRS-Replica-Set-GUID
-
adminDescription: FRS-Replica-Set-GUID
-
dn: CN=Replication-Status,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Fault-Condition
deleteoldrdn: 1
dn: CN=FRS-Fault-Condition,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSFaultCondition
-
adminDisplayName: FRS-Fault-Condition
-
adminDescription: FRS-Fault-Condition
-
add: rangeLower
rangeLower: 1
-
add: rangeUpper
rangeUpper: 16
-
dn: CN=Replication-Directory-Filter,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: FRS-Directory-Filter
deleteoldrdn: 1
dn: CN=FRS-Directory-Filter,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: fRSDirectoryFilter
-
adminDisplayName: FRS-Directory-Filter
-
adminDescription: FRS-Directory-Filter
-
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 2048
-
dn: CN=Created-Entry,CN=schema,CN=configuration,DC=X
changetype: modrdn
newrdn: rpc-Ns-Entry-Flags
deleteoldrdn: 1
dn: CN=rpc-Ns-Entry-Flags,CN=schema,CN=configuration,DC=X
changetype: modify
ldapDisplayName: rpcNsEntryFlags
-
adminDisplayName: rpc-Ns-Entry-Flags
-
adminDescription: rpc-Ns-Entry-Flags
-
# Class Adds
dn: CN=NTFRS-Member,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: nTFRSMember
adminDisplayName: NTFRS-Member
adminDescription: NTFRS-Member
governsId: 1.2.840.113556.1.5.153
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: hiUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=NTFRS-Member,CN=Schema,CN=Configuration,DC=X
dn: CN=Site-Link-Bridge,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: siteLinkBridge
adminDisplayName: Site-Link-Bridge
adminDescription: Site-Link-Bridge
governsId: 1.2.840.113556.1.5.148
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Site-Link-Bridge,CN=Schema,CN=Configuration,DC=X
dn: CN=RRAS-Administration-Connection-Point,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: rRASAdministrationConnectionPoint
adminDisplayName: RRAS-Administration-Connection-Point
adminDescription: RRAS-Administration-Connection-Point
governsId: 1.2.840.113556.1.5.150
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.94
schemaIdGuid:: vsU5KmCJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=RRAS-Administration-Connection-Point,CN=Schema,CN=Configuration,DC=X
dn: CN=NTFRS-Subscriptions,CN=Schema,CN=Configuration,DC=X
changetype: add
lDAPDisplayName: nTFRSSubscriptions
adminDescription: NTFRS-Subscriptions
adminDisplayName: NTFRS-Subscriptions
governsID: 1.2.840.113556.1.5.154
rDNAttID: 2.5.4.3
subClassOf: 2.5.6.0
schemaIDGUID:: hyUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=NTFRS-Subscriptions,CN=Schema,CN=Configuration,DC=X
dn: CN=Remote-Storage-Service-Point,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: remoteStorageServicePoint
adminDisplayName: Remote-Storage-Service-Point
adminDescription: Remote-Storage-Service-Point
governsId: 1.2.840.113556.1.5.146
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.94
schemaIdGuid:: vcU5KmCJ0RGuvAAA+ANnwQ==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Remote-Storage-Service-Point,CN=Schema,CN=Configuration,DC=X
changetype: add
lDAPDisplayName: intellimirrorGroup
adminDescription: Intellimirror-Group
adminDisplayName: Intellimirror-Group
governsID: 1.2.840.113556.1.5.152
rDNAttID: 2.5.4.3
schemaIDGUID:: hjA4B9+R0RGuvAAA+ANnwQ==
subClassOf: 2.5.6.0
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Intellimirror-Group,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: siteLink
adminDisplayName: Site-Link
adminDescription: Site-Link
governsId: 1.2.840.113556.1.5.147
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Site-Link,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: intellimirrorSCP
adminDisplayName: Intellimirror-SCP
adminDescription: Intellimirror-SCP
governsId: 1.2.840.113556.1.5.151
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.94
schemaIdGuid:: hTA4B9+R0RGuvAAA+ANnwQ==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Intellimirror-SCP,CN=Schema,CN=Configuration,DC=X
dn: CN=NTFRS-Subscriber,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: nTFRSSubscriber
adminDisplayName: NTFRS-Subscriber
adminDescription: NTFRS-Subscriber
governsId: 1.2.840.113556.1.5.155
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: iCUTKnOT0RGuvAAA+ANnwQ==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=NTFRS-Subscriber,CN=Schema,CN=Configuration,DC=X
dn: CN=RRAS-Administration-Dictionary,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: rRASAdministrationDictionary
adminDisplayName: RRAS-Administration-Dictionary
adminDescription: RRAS-Administration-Dictionary
governsId: 1.2.840.113556.1.5.156
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: rpib842T0RGuvQAA+ANnwQ==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=RRAS-Administration-Dictionary,CN=Schema,CN=Configuration,DC=X
# Syntax in two attributes have been modified. USN-Source and

# Transport-Address-Type. We don't propagate the changes.
# We will delete both and add new attributes
# to replace them.
# Attribute and Class Modifications
changetype: modify
searchFlags: 0
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
dn: CN=Postal-Code,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Phone-Office-Other,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Post-Office-Box,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Physical-Delivery-Office-Name,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
changetype: modify
-
dn: CN=Telex-Number,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Teletex-Terminal-Identifier,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
dn: CN=X121-Address,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=International-ISDN-Number,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Registered-Address,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Preferred-Delivery-Method,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
dn: CN=Phone-Mobile-Primary,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Phone-Pager-Primary,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
dn: CN=Voice-Mail-Password,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Voice-Mail-Recorded-Name,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Voice-Mail-Greetings,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Voice-Mail-Flags,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Voice-Mail-Volume,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Voice-Mail-Speed,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Voice-Mail-Recording-Length,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Forwarding-Address,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Personal-Title,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
changetype: modify
-
dn: CN=Phone-Fax-Other,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Phone-Mobile-Other,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Telex-Primary,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Phone-ISDN-Primary,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Assistant,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
add: systemFlags
add: systemFlags
systemFlags: 2
-
dn: CN=Categories,CN=Schema,CN=Configuration,DC=X
changetype: modify
add: rangeLower
rangeLower: 36
-
add: rangeUpper
rangeUpper: 36
-
dn: CN=Creator,CN=Schema,CN=Configuration,DC=X
changetype: modify
searchFlags: 0
-
changetype: modify
-
dn: CN=Phone-Ip-Other,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=WWW-Page-Other,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
searchFlags: 1
-
add: systemFlags
systemFlags: 2
-
dn: CN=User-Shared-Folder,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=User-Shared-Folder-Other,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Address,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
add: systemFlags
systemFlags: 2
-
dn: CN=Phone-Home-Other,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=AutoReply,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=AutoReply-Message,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Package-Flags,CN=Schema,CN=Configuration,DC=X
changetype: modify
searchFlags: 1
-
dn: CN=AutoReply-Subject,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=WWW-Home-Page,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
-
changetype: modify
-
changetype: modify
-
-
changetype: modify
-
dn: CN=Domain,CN=Schema,CN=Configuration,DC=X
changetype: modify
replace: defaultObjectCategory
defaultObjectCategory: CN=Domain-DNS,CN=Schema,CN=Configuration,DC=X
-
changetype: modify
-
changetype: modify
-
-
changetype: modify
-
changetype: modify
-
dn: CN=Class-Registration,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Inter-Site-Transport-Container,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
dn: CN=Remote-Mail-Recipient,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
-
dn: CN=Storage,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Class-Store,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
changetype: modify
-
changetype: modify
-
dn: CN=Package-Registration,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
changetype: modify
-
changetype: modify
-
-
-
dn: CN=Category-Registration,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
changetype: modify
-
-
-
-
-
changetype: modify
-
-
dn: CN=Query-Policy,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
dn: CN=Ipsec-Negotiation-Policy,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Address-Book-Container,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
-
changetype: modify
-
# Attribute and Class deletes
# First delete some objects in Config NC before deleting their classes
dn: CN=RPC,CN=Inter-Site Transports,CN=Site Connectors,CN=sites,CN=configuration,DC=X

changetype: delete
dn: CN=Inter-Site Transports,CN=Site Connectors,CN=sites,CN=configuration,DC=X

changetype: delete
dn: CN=Site Connectors,CN=sites,CN=configuration,DC=X

changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=LocalGroup,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
dn: CN=Eicon-X25-X400-Link,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=COM-Interface,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
dn: CN=Eicon-X25-Stack,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=View-Container,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
dn: CN=Application-Registration,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=Distribution-List,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
dn: CN=NTFRS-Site-Settings,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
dn: CN=View-Root,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=Run-As,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
dn: CN=To-Site,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=COM-App-Id,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=App-Flags,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=From-Site,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=Netboot-NIC,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=Contact-Name,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=COM-Package-Id,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=COM-Unique-IID,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=Property-Pages,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=Domain-Replicas,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=Replica-Set-Server,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Service-Realm-Name,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Aliased-Object-Name,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=GWART-Last-Modified,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=Lockout-Disconnect,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=Space-Last-Computed,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Over-Site-Connector,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=Group-By-Attr-Value-DN,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=Group-By-Attr-Value-Str,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=Replication-Boot-State,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=CA-Exchange-Certificate,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=COM-Auto-Convert-Class-Id,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=CA-Signature-Certificate,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Bidirectional-Connector,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=Container-Administrators,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=Default-Intra-Site-Schedule,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Default-Inter-Site-Schedule,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn: CN=CA-Exchange-Certificate-Chain,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
dn: CN=CA-Signature-Certificate-Chain,CN=Schema,CN=Configuration,DC=X
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
changetype: delete
dn:
changetype: modify
schemaUpdateNow: 1
-
# Config NC changes
# Extended rights
changetype: add
hideFromAB: TRUE
appliesTo: 3e74f60f-3e73-11d1-a9c0-0000f80367c1
displayName: Open Address Book
rightsGuid: a1990816-4298-11d1-ade2-00c04fd8d5cd
changetype: add
hideFromAB: TRUE
displayName: Modify Personal Information
rightsGuid: 77B5B886-944A-11d1-AEBD-0000F80367C1
changetype: add
hideFromAB: TRUE
displayName: Modify Email Information
changetype: add
hideFromAB: TRUE
displayName: Modify Web Information
# Display-Specifiers
dn: CN=localGroup-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: delete
changetype: add
hideFromAB: TRUE
adminContextmenu: 0,{6971d64e-f335-11d0-b0bc-00c04fd8dca6}
classDisplayName: NTFRS Settings
changetype: add
hideFromAB: TRUE
classDisplayName: NTFRS Replica Set
changetype: add
hideFromAB: TRUE
classDisplayName: Microsoft FRS
changetype: modify
add: treatAsLeaf
treatAsLeaf: TRUE
-
-
-
attributeDisplayNames: facsimileTelephoneNumber, Facsimile Telephone Numbers
attributeDisplayNames: generationQualifier, Generation Qualifier
attributeDisplayNames: internationalISDNNumber, International ISDN Number
attributeDisplayNames: mobile,Cellular Phone Number
attributeDisplayNames: postalCode,ZIP Code
attributeDisplayNames: primaryGroupID,Primary Group SID
attributeDisplayNames: streetAddress,Address
attributeDisplayNames: title,Title
attributeDisplayNames: userAccountControl,User Account Control Flags
-
attributeDisplayNames: internationalISDNNumber, International ISDN Number (Others)
attributeDisplayNames: otherHomePhone,Home Phone (Others)
attributeDisplayNames: userPrincipalName,Logon Name
-
changetype: modify
attributeDisplayNames: desctription,Description
attributeDisplayNames: contactName,Contact Name
attributeDisplayNames: groupAttributes,Group Attribute Flags
-
-
changetype: modify
classDisplayName: Domain (DNS)
-
classDisplayName: Domain
-
-
changetype: modify
attributeDisplayNames: department,Department
attributeDisplayNames: directReports,Direct Reports
attributeDisplayNames: division,Division
attributeDisplayNames: employeeID,Employee ID
attributeDisplayNames: givenName,First Name
attributeDisplayNames: homePhone,Home Phone
attributeDisplayNames: homePostalAddress,Home Address
attributeDisplayNames: initials,Initials
attributeDisplayNames: internationalISDNNumber,International ISDN Number (Others)
attributeDisplayNames: l,City
attributeDisplayNames: mail,E-Mail Address
attributeDisplayNames: manager,Manager
attributeDisplayNames: memberOf,Group Membership
attributeDisplayNames: middleName,Middle Name
attributeDisplayNames: otherHomePhone,Home Phone Number (Others)
attributeDisplayNames: postOfficeBox,Post Office Box
attributeDisplayNames: sn,Last Name
-
changetype: modify
-
-
changetype: modify
classDisplayName: Service Administration Point
-
-
changetype: modify
-
changetype: modify
attributeDisplayNames: cn,Directory Service Name
attributeDisplayNames: uNCName,Network Name
attributeDisplayNames: assetNumber,Asset Number
attributeDisplayNames: bytesPerMinute,Bytes per Minute
attributeDisplayNames: contactName,Contact
attributeDisplayNames: description,Comment
attributeDisplayNames: driverName,Model
attributeDisplayNames: driverVersion,Driver Version
attributeDisplayNames: location,Location
attributeDisplayNames: portName,Port
attributeDisplayNames: printBinNames,Input Trays
attributeDisplayNames: printCollate,Supports Collation
attributeDisplayNames: printColor,Supports Color Printing
attributeDisplayNames: printDuplexSupported,Supports Double-sided Printing
attributeDisplayNames: printFormName,Form Name
attributeDisplayNames: printLanguage,Data Format
attributeDisplayNames: printMACAddress,Physical Network Address
attributeDisplayNames: printMaxCopies,Maximum Number of Copies
attributeDisplayNames: printMaxResolutionSupported,Maximum Resolution
attributeDisplayNames: printMaxXExtent,Maximum Printable Width
attributeDisplayNames: printMaxYExtent,Maximum Printable Height
attributeDisplayNames: printMediaReady,Paper Available
attributeDisplayNames: printMediaSupported,Paper Types Supported
attributeDisplayNames: printMemory,Installed Memory
attributeDisplayNames: printMinXExtent,Minimum Printable Width
attributeDisplayNames: printMinYExtent,Minimum Printable Height
attributeDisplayNames: printNetworkAddress,Network Address
attributeDisplayNames: printNumberUp,Supports N-Up Printing
attributeDisplayNames: printOrientationsSupported,Orientations Supported
attributeDisplayNames: printOwner,Owner Name
attributeDisplayNames: printRate,Speed
attributeDisplayNames: printRateUnit,Speed Units
attributeDisplayNames: printPagesPerMinute,Pages per Minute
attributeDisplayNames: printStaplingSupported,Supports Stapling
attributeDisplayNames: printStatus,State
attributeDisplayNames: priority,Print Job Priority
attributeDisplayNames: serverName,Server Name
attributeDisplayNames: versionNumber,Object Version
attributeDisplayNames: whenChanged,Date Modified
attributeDisplayNames: whenCreated,Date Created
-
changetype: modify
-
changetype: modify
-
changetype: modify
attributeDisplayNames: uNCName,Network Path
-
classDisplayName: Volume
-
classDisplayName: Shared Folder
-
dn: CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=X

changetype: add
objectClass: interSiteTransportContainer
hideFromAB: TRUE

changetype: add
hideFromAB: TRUE

changetype: add
transportDllName: ismsmtp.dll
hideFromAB: TRUE

changetype: delete

changetype: add
objectClass: queryPolicy
lDAPAdminLimits: MaxConnections=1000
lDAPAdminLimits: InitRecvTimeout=120
lDAPAdminLimits: AllowDeepNonIndexSearch=False
lDAPAdminLimits: MaxConnIdleTime=900
lDAPAdminLimits: MaxActiveQueries=20
lDAPAdminLimits: MaxPageSize=1000
lDAPAdminLimits: MaxQueryDuration=120
lDAPAdminLimits: MaxTempTableSize=10000
lDAPAdminLimits: MaxResultSetSize=262144
lDAPAdminLimits: MaxPoolThreads=4
hideFromAB: TRUE
# Object-Version on schema container
dn: CN=schema,CN=configuration,DC=X
changetype: modify
add: objectVersion
objectVersion: 1
-
Sch2.ldf
dn: CN=GP-Link,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: gPLink
adminDisplayName: GP-Link
adminDescription: GP-Link
attributeId: 1.2.840.113556.1.4.891
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: vjsO8/Cf0RG2AwAA+ANnwQ==
hideFromAB: TRUE
dn: CN=GP-Options,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: gPOptions
adminDisplayName: GP-Options
adminDescription: GP-Options
attributeId: 1.2.840.113556.1.4.892
omSyntax: 2
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: vzsO8/Cf0RG2AwAA+ANnwQ==
hideFromAB: TRUE
dn: CN=GPC-File-Sys-Path,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: gPCFileSysPath
adminDisplayName: GPC-File-Sys-Path
adminDescription: GPC-File-Sys-Path
attributeId: 1.2.840.113556.1.4.894
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: wTsO8/Cf0RG2AwAA+ANnwQ==
hideFromAB: TRUE
dn: CN=GPC-Functionality-Version,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: gPCFunctionalityVersion
adminDisplayName: GPC-Functionality-Version
adminDescription: GPC-Functionality-Version
attributeId: 1.2.840.113556.1.4.893
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: wDsO8/Cf0RG2AwAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Transport-Address-Attribute,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: transportAddressAttribute
adminDisplayName: Transport-Address-Attribute
adminDescription: Transport-Address-Attribute
attributeId: 1.2.840.113556.1.4.895
omSyntax: 6
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fIbcwWGi0RG2BgAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Group-Policy-Container,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: groupPolicyContainer
adminDisplayName: Group-Policy-Container
adminDescription: Group-Policy-Container
governsId: 1.2.840.113556.1.5.157
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.23
schemaIdGuid:: wjsO8/Cf0RG2AwAA+ANnwQ==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Group-Policy-Container,CN=Schema,CN=Configuration,DC=X
# To take care of change of OID for USN-Source
changetype: modify
-
dn: CN=USN-Source,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=USN-Source,CN=Schema,CN=Configuration,DC=X
changetype: add
lDAPDisplayName: uSNSource
adminDescription: USN-Source
adminDisplayName: USN-Source
attributeID: 1.2.840.113556.1.4.896
mAPIID: 33111
oMSyntax: 65
schemaIDGUID:: rVh3FvNH0RGpwwAA+ANnwQ==
searchFlags: 0
systemOnly: FALSE
hideFromAB: TRUE
changetype: modify
-
changetype: modify
-
-
dn: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=X
changetype: modify
systemMayContain: 2.5.4.6
-
-
changetype: modify
-
changetype: modify
-
-
changetype: modify
-
dn: CN=Domain-Policy,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Container,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
-
changetype: modify
-
-
changetype: modify
-
changetype: modify
-
dn: CN=Site,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
-
dn: CN=Object-Category,CN=Schema,CN=Configuration,DC=X
changetype: modify
add: systemFlags
systemFlags: 2
-
# Change of OID of FRS-Replica-Set-Type

# Delete by name, not by OID.
changetype: modify
systemMayContain: fRSReplicaSetType
-
changetype: delete
changetype: add
lDAPDisplayName: fRSReplicaSetType
attributeID: 1.2.840.113556.1.4.31
hideFromAB: TRUE
oMSyntax: 2
schemaIDGUID:: a3PZJnBg0RGpxgAA+ANnwQ==
searchFlags: 0
systemOnly: FALSE
changetype: modify
-
dn: CN=Builtin-Sync,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Policy-Name,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Policy-Link,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Policy-Options,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn: CN=Change-Pwd-Logon-Required,CN=Schema,CN=Configuration,DC=X
changetype: delete
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=DS-Replication-Get-Changes,CN=Extended-Rights,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
appliesTo: bf967a8f-0de6-11d0-a285-00aa003049e2
displayName: Replicating Directory Changes
rightsGUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
dn: CN=DS-Replication-Synchronize,CN=Extended-Rights,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
displayName: Replication Synchronization
rightsGUID: 1131f6ab-9c07-11d1-f79f-00c04fc2dcd2
dn: CN=DS-Replication-Manage-Topology,CN=Extended-Rights,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
displayName: Manage Replication Topology
rightsGUID: 1131f6ac-9c07-11d1-f79f-00c04fc2dcd2
dn: CN=IntellimirrorGroup-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
adminPropertyPages: 1,{C641CF88-892F-11d1-BBEB-0060081692B3}
classDisplayName: IntelliMirror-Group
shellPropertyPages: 1,{C641CF88-892F-11d1-BBEB-0060081692B3}
dn: CN=IntellimirrorSCP-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
adminPropertyPages: 1,{AC409538-741C-11d1-BBE6-0060081692B3}
classDisplayName: IntelliMirror-Service
shellPropertyPages: 1,{AC409538-741C-11d1-BBE6-0060081692B3}
changetype: modify
adminPropertyPages: 10,{0F65B1BF-740F-11d1-BBE6-0060081692B3}
-

changetype: modify
add: transportAddressAttribute
transportAddressAttribute: dnsHostName
-

changetype: modify
add: transportAddressAttribute
transportAddressAttribute: mailAddress
-
changetype: modify
objectVersion: 2
-
Sch3.ldf
# Existing Extended-Rights Mod
dn: CN=User-Force-Change-Password,CN=Extended-Rights,CN=Configuration,DC=X
changetype: modify
replace: displayName
displayName: Reset Password
-
add: appliesTo
-
# New Display-Specifier adds
dn: CN=server-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
adminContextMenu: 1,{08eb4fa6-6ffd-11d1-b0e0-00c04fd8dca6}
classDisplayName: Server
dn: CN=siteLink-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
adminPropertyPages: 1,{50d30561-9911-11d1-b9af-00c04fd8d5b0}
classDisplayName: Site Link
dn: CN=siteLinkBridge-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
classDisplayName: Site Link Bridge
dn: CN=interSiteTransport-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
adminPropertyPages: 1,{6DFE6491-AC8D-11D0-B945-00C04FD8D5B0}
classDisplayName: Inter-Site Transport
dn: CN=licensingSiteSettings-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
adminPropertyPages: 1,{717ef500-ac8d-11d0-b945-00c04fd8d5b0}
classDisplayName: Licensing Site Settings
dn: CN=nTDSSiteSettings-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
adminPropertyPages: 1,{2f280288-bb6d-11d0-b948-00c04fd8d5b0}
classDisplayName: NTDS Site Settings
dn: CN=nTFRSMember-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
classDisplayName: NTFRS Member
dn: CN=nTFRSSubscriber-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
adminPropertyPages: 1,{50d3055f-9911-11d1-b9af-00c04fd8d5b0}
classDisplayName: NTFRS Subscriber
dn: CN=nTFRSSubscriptions-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
classDisplayName: NTFRS Subscriptions
dn: CN=rpcContainer-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
classDisplayName: RPC Services
# Existing display-specifier mods
changetype: delete
changetype: modify
adminPropertyPages: 3,{6dfe648a-a212-11d0-bcd5-00c04fd8d5b6}
adminPropertyPages: 4,{B52C1E50-1DD2-11D1-BC43-00C04FC31FD3}
-
adminPropertyPages: 3,{B52C1E50-1DD2-11D1-BC43-00C04FC31FD3}
-
attributeDisplayNames: userWorkstations,Logon Workstations
-
changetype: modify
adminPropertyPages: 2,{6dfe648a-a212-11d0-bcd5-00c04fd8d5b6}
adminPropertyPages: 3,{6dfe648b-a212-11d0-bcd5-00c04fd8d5b6}
-
-
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
dn: CN=localPolicy-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
dn: CN=site-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
-
dn: CN=nTDSSettings-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
-
dn: CN=nTDSDSA-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
-
dn: CN=nTDSConnection-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
changetype: modify
-
dn: CN=subnet-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
# New Extended-Rights adds
dn: CN=Change-Schema-Master,CN=Extended-Rights,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
displayName: Change Schema Master
rightsGUID: e12b56b6-0a95-11d1-adbb-00c04fd8d5cd
dn: CN=Change-Rid-Master,CN=Extended-Rights,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
appliesTo: 6617188d-8f3c-11d0-afda-00c04fd930c9
displayName: Change Rid Master
rightsGUID: d58d5f36-0a98-11d1-adbb-00c04fd8d5cd
dn: CN=Abandon-Replication,CN=Extended-Rights,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
displayName: Abandon Replication
rightsGUID: ee914b82-0a98-11d1-adbb-00c04fd8d5cd
dn: CN=Do-Garbage-Collection,CN=Extended-Rights,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
displayName: Do Garbage Collection
rightsGUID: fec364e0-0a98-11d1-adbb-00c04fd8d5cd
dn: CN=Recalculate-Hierarchy,CN=Extended-Rights,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
displayName: Recalculate Hierarchy
rightsGUID: 0bc1554e-0a99-11d1-adbb-00c04fd8d5cd
dn: CN=Allocate-Rids,CN=Extended-Rights,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
displayName: Allocate Rids
rightsGUID: 1abd7cf8-0a99-11d1-adbb-00c04fd8d5cd
rightsGUID: 1abd7cf8-0a99-11d1-adbb-00c04fd8d5cd
dn: CN=Change-PDC,CN=Extended-Rights,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
displayName: Change PDC
rightsGUID: bae50096-4752-11d1-9052-00c04fc2d4cf
dn: CN=Add-GUID,CN=Extended-Rights,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
displayName: Add GUID
rightsGUID: 440820ad-65b4-11d1-a3da-0000f875ae0d
dn: CN=Change-Domain-Master,CN=Extended-Rights,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
appliesTo: ef9e60e0-56f7-11d1-a9c6-0000f80367c1
displayName: Change Domain Master
rightsGUID: 014bf69c-7b3b-11d1-85f6-08002be74fab
# Bump up the schema version

changetype: modify
objectVersion: 3
-
Sch4.ldf
# Renames.
dn: CN=DXA-Flags,CN=Schema,CN=Configuration,DC=X
changetype: modrdn
newrdn: Deleted-Item-Flags
deleteoldrdn: 1
dn: CN=Deleted-Item-Flags,CN=Schema,CN=Configuration,DC=X
changetype: modify
ldapDisplayName: deletedItemFlags
-
adminDisplayName: Deleted-Item-Flags
-
adminsDescription: Deleted-Item-Flags
-
dn: CN=DXA-Task,CN=Schema,CN=Configuration,DC=X
changetype: modrdn
newrdn: Message-Size-Limit
deleteoldrdn: 1
dn: CN=Message-Size-Limit,CN=Schema,CN=Configuration,DC=X
changetype: modify
ldapDisplayName: messageSizeLimit
-
adminDisplayName: Message-Size-Limit
-
adminsDescription: Message-Size-Limit
-
dn: CN=Assoc-NT-Account,CN=Schema,CN=Configuration,DC=X
changetype: modrdn
newrdn: Assoc-NT-Account-Unused
deleteoldrdn: 1
dn: CN=Assoc-NT-Account-Unused,CN=Schema,CN=Configuration,DC=X
changetype: modify
ldapDisplayName: assocNTAccountUnused
-
adminDisplayName: Assoc-NT-Account-Unused
-
adminsDescription: Assoc-NT-Account-Unused
-
changetype: add
ldapDisplayName: assocNTAccount
adminDisplayName: Assoc-NT-Account
adminDescription: Assoc-NT-Account
attributeId: 1.2.840.113556.1.4.1213
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
hideFromAB: TRUE
dn: CN=ANR,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: aNR
adminDisplayName: ANR
adminDescription: ANR
attributeId: 1.2.840.113556.1.4.1208
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ABWwRRnE0RG7yQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ADMD
adminDisplayName: ADMD
adminDescription: ADMD
attributeId: 1.2.840.113556.1.2.232
omSyntax: 19
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeLower: 1
rangeUpper: 16
schemaIdGuid:: kHPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32841
hideFromAB: TRUE
changetype: add
ldapDisplayName: PRMD
adminDisplayName: PRMD
adminDescription: PRMD
attributeId: 1.2.840.113556.1.2.224
omSyntax: 19
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 16
schemaIdGuid:: TXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33038
hideFromAB: TRUE
changetype: add
ldapDisplayName: ReqSeq
adminDisplayName: Req-Seq
adminDescription: Req-Seq
attributeId: 1.2.840.113556.1.2.173
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: YHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33058
hideFromAB: TRUE
changetype: add
ldapDisplayName: RunsOn
adminDisplayName: Runs-On
adminDescription: Runs-On
attributeId: 1.2.840.113556.1.2.185
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: a3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33066
hideFromAB: TRUE
changetype: add
ldapDisplayName: Enabled
adminDisplayName: Enabled
adminDescription: Enabled
attributeId: 1.2.840.113556.1.2.557
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 8nPfqOrF0RG7ywCAx2ZwwA==
mapiID: 35873
hideFromAB: TRUE
dn: CN=Telephone-Home-Fax,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: homeFax
adminDisplayName: Telephone-Home-Fax
adminDescription: Telephone-Home-Fax
attributeId: 1.2.840.113556.1.2.609
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 128
schemaIdGuid:: hXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 14885
hideFromAB: TRUE
changetype: add
ldapDisplayName: Encrypt
adminDisplayName: Encrypt
adminDescription: Encrypt
attributeId: 1.2.840.113556.1.2.236
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
mapiID: 32931
hideFromAB: TRUE
changetype: add
ldapDisplayName: FormData
adminDisplayName: Form-Data
adminDescription: Form-Data
attributeId: 1.2.840.113556.1.2.607
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: AHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 35941
hideFromAB: TRUE
changetype: add
ldapDisplayName: INSAdmin
adminDisplayName: INSAdmin
adminDescription: INSAdmin
attributeId: 1.2.840.113556.1.2.543
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: FnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33221
hideFromAB: TRUE
hideFromAB: TRUE
changetype: add
ldapDisplayName: NAddress
adminDisplayName: N-Address
adminDescription: N-Address
attributeId: 1.2.840.113556.1.2.282
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 50
schemaIdGuid:: NHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33009
hideFromAB: TRUE
changetype: add
ldapDisplayName: SendTNEF
adminDisplayName: Send-TNEF
adminDescription: Send-TNEF
attributeId: 1.2.840.113556.1.2.492
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: b3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33169
hideFromAB: TRUE
changetype: add
ldapDisplayName: LineWrap
adminDisplayName: Line-Wrap
adminDescription: Line-Wrap
attributeId: 1.2.840.113556.1.2.449
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: GHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32964
hideFromAB: TRUE
changetype: add
ldapDisplayName: AuthOrig
adminDisplayName: Auth-Orig
adminDescription: Auth-Orig
attributeId: 1.2.840.113556.1.2.129
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
oMObjectClass:: VgYBAgULHQ==
schemaIdGuid:: l3PfqOrF0RG7ywCAx2ZwwA==
linkID: 110
hideFromAB: TRUE
dn: CN=MSMQ-QM-ID,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQQMID
adminDisplayName: MSMQ-QM-ID
adminDescription: MSMQ-QM-ID
attributeId: 1.2.840.113556.1.4.951
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: PsMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXATypes
adminDisplayName: DXA-Types
adminDescription: DXA-Types
attributeId: 1.2.840.113556.1.2.119
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 7XPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32928
hideFromAB: TRUE
dn: CN=MSMQ-Cost,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQCost
adminDisplayName: MSMQ-Cost
adminDescription: MSMQ-Cost
attributeId: 1.2.840.113556.1.4.946
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: OsMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Site-1,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQSite1
adminDisplayName: MSMQ-Site-1
adminDescription: MSMQ-Site-1
attributeId: 1.2.840.113556.1.4.943
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: N8MNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Site-2,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQSite2
adminDisplayName: MSMQ-Site-2
adminDescription: MSMQ-Site-2
attributeId: 1.2.840.113556.1.4.944
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: OMMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Label,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQLabel
adminDisplayName: MSMQ-Label
adminDescription: MSMQ-Label
attributeId: 1.2.840.113556.1.4.922
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: JcMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: InboundDN
adminDisplayName: Inbound-DN
adminDescription: Inbound-DN
attributeId: 1.2.840.113556.1.2.553
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: EHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 35870
hideFromAB: TRUE
changetype: add
ldapDisplayName: ViewFlags
adminDisplayName: View-Flags
adminDescription: View-Flags
attributeId: 1.2.840.113556.1.2.546
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: mnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 35864
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAImpSeq
adminDisplayName: DXA-Imp-Seq
adminDescription: DXA-Imp-Seq
attributeId: 1.2.840.113556.1.2.116
omSyntax: 19
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeLower: 1
rangeUpper: 32
mapiID: 32899
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAReqSeq
adminDisplayName: DXA-Req-Seq
adminDescription: DXA-Req-Seq
attributeId: 1.2.840.113556.1.2.101
omSyntax: 19
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 32
schemaIdGuid:: 5HPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32918
hideFromAB: TRUE
changetype: add
ldapDisplayName: secretary
adminDisplayName: Assistant-Name
adminDescription: Assistant-Name
attributeId: 1.2.840.113556.1.2.444
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: lHPfqOrF0RG7ywCAx2ZwwA==
mapiID: 14896
hideFromAB: TRUE
changetype: add
ldapDisplayName: PSelector
adminDisplayName: P-Selector
adminDescription: P-Selector
attributeId: 1.2.840.113556.1.2.285
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 16
schemaIdGuid:: SHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33030
hideFromAB: TRUE
changetype: add
ldapDisplayName: RidServer
adminDisplayName: Rid-Server
adminDescription: Rid-Server
attributeId: 1.2.840.113556.1.2.346
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ZHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33060
hideFromAB: TRUE
changetype: add
ldapDisplayName: SSelector
adminDisplayName: S-Selector
adminDescription: S-Selector
attributeId: 1.2.840.113556.1.2.284
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 16
schemaIdGuid:: bHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33067
hideFromAB: TRUE
changetype: add
ldapDisplayName: TSelector
adminDisplayName: T-Selector
adminDescription: T-Selector
attributeId: 1.2.840.113556.1.2.283
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 32
schemaIdGuid:: gXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33088
hideFromAB: TRUE
changetype: add
ldapDisplayName: HTTPPubPF
adminDisplayName: HTTP-Pub-PF
adminDescription: HTTP-Pub-PF
attributeId: 1.2.840.113556.1.2.505
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 1024
schemaIdGuid:: C3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33182
hideFromAB: TRUE
changetype: add
ldapDisplayName: OWAServer
adminDisplayName: OWA-Server
adminDescription: OWA-Server
attributeId: 1.2.840.113556.1.2.608
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 128
schemaIdGuid:: R3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 35942
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXASvrSeq
adminDisplayName: DXA-Svr-Seq
adminDescription: DXA-Svr-Seq
attributeId: 1.2.840.113556.1.2.360
omSyntax: 19
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 32
mapiID: 32922
hideFromAB: TRUE
dn: CN=From-Entry,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: fromEntry
adminDisplayName: From-Entry
adminDescription: From-Entry
attributeId: 1.2.840.113556.1.4.910
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: Sdl6mlPK0RG70ACAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Sites,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQSites
adminDisplayName: MSMQ-Sites
adminDescription: MSMQ-Sites
attributeId: 1.2.840.113556.1.4.927
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: KsMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Quota,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQQuota
adminDisplayName: MSMQ-Quota
adminDescription: MSMQ-Quota
attributeId: 1.2.840.113556.1.4.919
omSyntax: 2
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: IsMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DomainName
adminDisplayName: Domain-Name
adminDescription: Domain-Name
attributeId: 1.2.840.113556.1.2.147
omSyntax: 20
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 362
schemaIdGuid:: yHPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32886
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAReqName
adminDisplayName: DXA-ReqName
adminDescription: DXA-ReqName
attributeId: 1.2.840.113556.1.2.446
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: 53PfqOrF0RG7ywCAx2ZwwA==
mapiID: 32921
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAConfSeq
adminDisplayName: DXA-Conf-Seq
adminDescription: DXA-Conf-Seq
attributeId: 1.2.840.113556.1.2.184
omSyntax: 19
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 32
schemaIdGuid:: znPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32894
hideFromAB: TRUE
changetype: add
ldapDisplayName: AuthOrigBL
adminDisplayName: Auth-Orig-BL
adminDescription: Auth-Orig-BL
attributeId: 1.2.840.113556.1.2.290
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: mHPfqOrF0RG7ywCAx2ZwwA==
linkID: 111
mapiID: 32851
hideFromAB: TRUE
systemFlags: 1
changetype: add
ldapDisplayName: HTTPPubGAL
adminDisplayName: HTTP-Pub-GAL
adminDescription: HTTP-Pub-GAL
attributeId: 1.2.840.113556.1.2.502
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: CXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33179
hideFromAB: TRUE
dn: CN=MSMQ-Site-ID,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQSiteID
adminDisplayName: MSMQ-Site-ID
adminDescription: MSMQ-Site-ID
attributeId: 1.2.840.113556.1.4.953
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: QMMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: RASAccount
adminDisplayName: RAS-Account
adminDescription: RAS-Account
attributeId: 1.2.840.113556.1.2.519
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: UXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33197
hideFromAB: TRUE
changetype: add
ldapDisplayName: RemoteSite
adminDisplayName: Remote-Site
adminDescription: Remote-Site
attributeId: 1.2.840.113556.1.2.27
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: W3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33053
hideFromAB: TRUE
changetype: add
ldapDisplayName: PortNumber
adminDisplayName: Port-Number
adminDescription: Port-Number
attributeId: 1.2.840.113556.1.2.527
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 65535
schemaIdGuid:: SnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33205
hideFromAB: TRUE
changetype: add
ldapDisplayName: RequireSSL
adminDisplayName: Require-SSL
adminDescription: Require-SSL
attributeId: 1.2.840.113556.1.2.560
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: YXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 35877
hideFromAB: TRUE
changetype: add
ldapDisplayName: TargetMTAs
adminDisplayName: Target-MTAs
adminDescription: Target-MTAs
attributeId: 1.2.840.113556.1.2.259
omSyntax: 20
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 36
schemaIdGuid:: g3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33090
hideFromAB: TRUE
changetype: add
ldapDisplayName: TrustLevel
adminDisplayName: Trust-Level
adminDescription: Trust-Level
attributeId: 1.2.840.113556.1.2.70
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 100
schemaIdGuid:: knTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33103
hideFromAB: TRUE
changetype: add
ldapDisplayName: UnauthOrig
adminDisplayName: Unauth-Orig
adminDescription: Unauth-Orig
attributeId: 1.2.840.113556.1.2.221
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: lXTfqOrF0RG7ywCAx2ZwwA==
linkID: 114
hideFromAB: TRUE
dn: CN=MSMQ-OS-Type,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQOSType
adminDisplayName: MSMQ-OS-Type
adminDescription: MSMQ-OS-Type
attributeId: 1.2.840.113556.1.4.935
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: MMMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: CanCreatePF
adminDisplayName: Can-Create-PF
adminDescription: Can-Create-PF
attributeId: 1.2.840.113556.1.2.11
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: oXPfqOrF0RG7ywCAx2ZwwA==
linkID: 124
mapiID: 32856
hideFromAB: TRUE
changetype: add
ldapDisplayName: LogFilename
adminDisplayName: Log-Filename
adminDescription: Log-Filename
attributeId: 1.2.840.113556.1.2.192
omSyntax: 64
systemOnly: FALSE
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: HXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32970
hideFromAB: TRUE
dn: CN=Is-Ephemeral,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: isEphemeral
adminDisplayName: Is-Ephemeral
adminDescription: Is-Ephemeral
attributeId: 1.2.840.113556.1.4.1212
omSyntax: 1
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: 8FPE9PHF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: InboundHost
adminDisplayName: Inbound-Host
adminDescription: Inbound-Host
attributeId: 1.2.840.113556.1.2.489
omSyntax: 19
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 512
schemaIdGuid:: EXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33166
hideFromAB: TRUE
dn: CN=MSMQ-CSP-Name,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQCSPName
adminDisplayName: MSMQ-CSP-Name
adminDescription: MSMQ-CSP-Name
attributeId: 1.2.840.113556.1.4.940
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: NMMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAPassword
adminDisplayName: DXA-Password
adminDescription: DXA-Password
attributeId: 1.2.840.113556.1.2.305
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 12
rangeUpper: 12
mapiID: 32908
hideFromAB: TRUE
dn: CN=MSMQ-Digests,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQDigests
adminDisplayName: MSMQ-Digests
adminDescription: MSMQ-Digests
attributeId: 1.2.840.113556.1.4.948
omSyntax: 4
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: PMMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Foreign,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQForeign
adminDisplayName: MSMQ-Foreign
adminDescription: MSMQ-Foreign
attributeId: 1.2.840.113556.1.4.934
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: L8MNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Owner-ID,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQOwnerID
adminDisplayName: MSMQ-Owner-ID
adminDescription: MSMQ-Owner-ID
attributeId: 1.2.840.113556.1.4.925
omSyntax: 4
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: KMMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Sign-Key,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQSignKey
adminDisplayName: MSMQ-Sign-Key
adminDescription: MSMQ-Sign-Key
attributeId: 1.2.840.113556.1.4.937
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: MsMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Journal,CN=Schema,CN=Configuration,DC=X
changetype: add
changetype: add
ldapDisplayName: mSMQJournal
adminDisplayName: MSMQ-Journal
adminDescription: MSMQ-Journal
attributeId: 1.2.840.113556.1.4.918
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: IcMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ContentType
adminDisplayName: Content-Type
adminDescription: Content-Type
attributeId: 1.2.840.113556.1.2.481
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 4
schemaIdGuid:: uXPfqOrF0RG7ywCAx2ZwwA==
mapiID: 33158
hideFromAB: TRUE
changetype: add
ldapDisplayName: RASPassword
adminDisplayName: RAS-Password
adminDescription: RAS-Password
attributeId: 1.2.840.113556.1.2.520
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: U3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33198
hideFromAB: TRUE
dn: CN=MSMQ-Version,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQVersion
adminDisplayName: MSMQ-Version
adminDescription: MSMQ-Version
attributeId: 1.2.840.113556.1.4.942
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: NsMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msNPVersion,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msNPVersion
adminDisplayName: msNPVersion
adminDescription: msNPVersion
adminDescription: msNPVersion
attributeId: 1.2.840.113556.1.4.1135
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: k5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: RoutingList
adminDisplayName: Routing-List
adminDescription: Routing-List
attributeId: 1.2.840.113556.1.2.354
omSyntax: 20
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 2243
schemaIdGuid:: Z3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33062
hideFromAB: TRUE
changetype: add
ldapDisplayName: HTTPServers
adminDisplayName: HTTP-Servers
adminDescription: HTTP-Servers
attributeId: 1.2.840.113556.1.2.517
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: DHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33195
hideFromAB: TRUE
changetype: add
ldapDisplayName: MTALocalCred
adminDisplayName: MTA-Local-Cred
adminDescription: MTA-Local-Cred
attributeId: 1.2.840.113556.1.2.270
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: MnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33007
hideFromAB: TRUE
changetype: add
ldapDisplayName: CharacterSet
adminDisplayName: Character-Set
adminDescription: Character-Set
attributeId: 1.2.840.113556.1.2.480
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: rXPfqOrF0RG7ywCAx2ZwwA==
mapiID: 33157
hideFromAB: TRUE
changetype: add
ldapDisplayName: DelegateUser
adminDisplayName: Delegate-User
adminDescription: Delegate-User
attributeId: 1.2.840.113556.1.2.591
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: vnPfqOrF0RG7ywCAx2ZwwA==
mapiID: 35913
hideFromAB: TRUE
changetype: add
ldapDisplayName: DLMemberRule
adminDisplayName: DL-Member-Rule
adminDescription: DL-Member-Rule
attributeId: 1.2.840.113556.1.2.330
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 4096
schemaIdGuid:: xnPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32884
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAAdminCopy
adminDisplayName: DXA-Admin-Copy
adminDescription: DXA-Admin-Copy
attributeId: 1.2.840.113556.1.2.378
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: yXPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32888
hideFromAB: TRUE
changetype: add
ldapDisplayName: DoOABVersion
adminDisplayName: Do-OAB-Version
adminDescription: Do-OAB-Version
attributeId: 1.2.840.113556.1.2.575
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: x3PfqOrF0RG7ywCAx2ZwwA==
mapiID: 35898
hideFromAB: TRUE
dn: CN=MSMQ-Migrated,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQMigrated
adminDisplayName: MSMQ-Migrated
adminDescription: MSMQ-Migrated
attributeId: 1.2.840.113556.1.4.952
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: P8MNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ComputerName
adminDisplayName: Computer-Name
adminDescription: Computer-Name
attributeId: 1.2.840.113556.1.2.20
omSyntax: 20
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: tHPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32869
hideFromAB: TRUE
changetype: add
ldapDisplayName: MonitorClock
adminDisplayName: Monitor-Clock
adminDescription: Monitor-Clock
attributeId: 1.2.840.113556.1.2.163
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: I3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 32982
hideFromAB: TRUE
changetype: add
ldapDisplayName: NAddressType
adminDisplayName: N-Address-Type
adminDescription: N-Address-Type
attributeId: 1.2.840.113556.1.2.222
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: NXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33010
hideFromAB: TRUE
changetype: add
ldapDisplayName: InboundSites
adminDisplayName: Inbound-Sites
adminDescription: Inbound-Sites
attributeId: 1.2.840.113556.1.2.71
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: FHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32956
hideFromAB: TRUE
dn: CN=msNPSequence,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msNPSequence
adminDisplayName: msNPSequence
adminDescription: msNPSequence
attributeId: 1.2.840.113556.1.4.1131
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: j5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msNPVendorID,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msNPVendorID
adminDisplayName: msNPVendorID
adminDescription: msNPVendorID
attributeId: 1.2.840.113556.1.4.1134
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: kpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: NewsfeedType
adminDisplayName: Newsfeed-Type
adminDescription: Newsfeed-Type
attributeId: 1.2.840.113556.1.2.495
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2
schemaIdGuid:: NnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33172
mapiID: 33172
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAImpSeqUSN
adminDisplayName: DXA-Imp-Seq-USN
adminDescription: DXA-Imp-Seq-USN
attributeId: 1.2.840.113556.1.2.86
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
mapiID: 32901
hideFromAB: TRUE
changetype: add
ldapDisplayName: employeeType
adminDisplayName: Employee-Type
adminDescription: Employee-Type
attributeId: 1.2.840.113556.1.2.613
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
mapiID: 35945
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAReqSeqUSN
adminDisplayName: DXA-Req-Seq-USN
adminDescription: DXA-Req-Seq-USN
attributeId: 1.2.840.113556.1.2.182
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
mapiID: 32920
hideFromAB: TRUE
dn: CN=MSMQ-Services,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQServices
adminDisplayName: MSMQ-Services
adminDescription: MSMQ-Services
attributeId: 1.2.840.113556.1.4.950
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: PcMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ReferralList
adminDisplayName: Referral-List
adminDescription: Referral-List
attributeId: 1.2.840.113556.1.2.510
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 1024
schemaIdGuid:: V3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33187
hideFromAB: TRUE
changetype: add
ldapDisplayName: roleOccupant
adminDisplayName: Role-Occupant
adminDescription: Role-Occupant
attributeId: 2.5.4.33
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ZXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33061
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAImportNow
adminDisplayName: DXA-Import-Now
adminDescription: DXA-Import-Now
attributeId: 1.2.840.113556.1.2.376
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
mapiID: 32902
hideFromAB: TRUE
changetype: add
ldapDisplayName: OutboundHost
adminDisplayName: Outbound-Host
adminDescription: Outbound-Host
attributeId: 1.2.840.113556.1.2.488
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 1024
schemaIdGuid:: QnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33165
hideFromAB: TRUE
changetype: add
ldapDisplayName: SiteAffinity
adminDisplayName: Site-Affinity
adminDescription: Site-Affinity
attributeId: 1.2.840.113556.1.2.434
omSyntax: 20
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: dnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33079
hideFromAB: TRUE
dn: CN=msAscendFRN391,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRN391
adminDisplayName: msAscendFRN391
adminDescription: msAscendFRN391
attributeId: 1.2.840.113556.1.4.1035
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: MZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAExportNow
adminDisplayName: DXA-Export-Now
adminDescription: DXA-Export-Now
attributeId: 1.2.840.113556.1.2.377
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
mapiID: 32897
hideFromAB: TRUE
changetype: add
ldapDisplayName: UnauthOrigBL
adminDisplayName: Unauth-Orig-BL
adminDescription: Unauth-Orig-BL
attributeId: 1.2.840.113556.1.2.292
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: lnTfqOrF0RG7ywCAx2ZwwA==
linkID: 115
mapiID: 33106
hideFromAB: TRUE
systemFlags: 1
changetype: add
ldapDisplayName: DXASvrSeqUSN
adminDisplayName: DXA-Svr-Seq-USN
adminDescription: DXA-Svr-Seq-USN
attributeId: 1.2.840.113556.1.2.124
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
mapiID: 32924
hideFromAB: TRUE
dn: CN=msAscendFRT391,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRT391
adminDisplayName: msAscendFRT391
adminDescription: msAscendFRT391
attributeId: 1.2.840.113556.1.4.1038
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: NJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendFRT392,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRT392
adminDisplayName: msAscendFRT392
adminDescription: msAscendFRT392
attributeId: 1.2.840.113556.1.4.1039
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: NZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: USNIntersite
adminDisplayName: USN-Intersite
adminDescription: USN-Intersite
attributeId: 1.2.840.113556.1.2.469
omSyntax: 2
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: mHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33146
hideFromAB: TRUE
changetype: add
ldapDisplayName: LDAPSearchCfg
adminDisplayName: LDAP-Search-Cfg
adminDescription: LDAP-Search-Cfg
attributeId: 1.2.840.113556.1.2.552
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2
schemaIdGuid:: F3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 35869
hideFromAB: TRUE
dn: CN=Canonical-Name,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: canonicalName
adminDisplayName: Canonical-Name
adminDescription: Canonical-Name
attributeId: 1.2.840.113556.1.4.916
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: Rdl6mlPK0RG70ACAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: CanCreatePFBL
adminDisplayName: Can-Create-PF-BL
adminDescription: Can-Create-PF-BL
attributeId: 1.2.840.113556.1.2.339
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: onPfqOrF0RG7ywCAx2ZwwA==
linkID: 125
mapiID: 32857
hideFromAB: TRUE
systemFlags: 1
changetype: add
ldapDisplayName: CanCreatePFDL
adminDisplayName: Can-Create-PF-DL
adminDescription: Can-Create-PF-DL
attributeId: 1.2.840.113556.1.2.62
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: o3PfqOrF0RG7ywCAx2ZwwA==
linkID: 126
mapiID: 32858
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXALocalAdmin
adminDisplayName: DXA-Local-Admin
adminDescription: DXA-Local-Admin
attributeId: 1.2.840.113556.1.2.113
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
mapiID: 32904
hideFromAB: TRUE
changetype: add
ldapDisplayName: MTALocalDesig
adminDisplayName: MTA-Local-Desig
adminDescription: MTA-Local-Desig
attributeId: 1.2.840.113556.1.2.271
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 32
schemaIdGuid:: M3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33008
hideFromAB: TRUE
dn: CN=Object-Classes,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: objectClasses
adminDisplayName: Object-Classes
adminDescription: Object-Classes
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: S9l6mlPK0RG70ACAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAImpSeqTime
adminDisplayName: DXA-Imp-Seq-Time
adminDescription: DXA-Imp-Seq-Time
attributeId: 1.2.840.113556.1.2.117
omSyntax: 23
systemOnly: FALSE
searchFlags: 0
mapiID: 32900
hideFromAB: TRUE
dn: CN=msAscendGroup,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendGroup
adminDisplayName: msAscendGroup
adminDescription: msAscendGroup
attributeId: 1.2.840.113556.1.4.1042
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: OJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAReqSeqTime
adminDisplayName: DXA-Req-Seq-Time
adminDescription: DXA-Req-Seq-Time
attributeId: 1.2.840.113556.1.2.114
omSyntax: 23
systemOnly: FALSE
searchFlags: 0
mapiID: 32919
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAConfSeqUSN
adminDisplayName: DXA-Conf-Seq-USN
adminDescription: DXA-Conf-Seq-USN
attributeId: 1.2.840.113556.1.2.45
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: z3PfqOrF0RG7ywCAx2ZwwA==
mapiID: 32895
hideFromAB: TRUE
dn: CN=MSMQ-Long-Lived,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQLongLived
adminDisplayName: MSMQ-Long-Lived
adminDescription: MSMQ-Long-Lived
attributeId: 1.2.840.113556.1.4.941
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: NcMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Site-Gates,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQSiteGates
adminDisplayName: MSMQ-Site-Gates
adminDescription: MSMQ-Site-Gates
attributeId: 1.2.840.113556.1.4.945
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: OcMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msNPTimeOfDay,CN=Schema,CN=Configuration,DC=X
changetype: add
changetype: add
ldapDisplayName: msNPTimeOfDay
adminDisplayName: msNPTimeOfDay
adminDescription: msNPTimeOfDay
attributeId: 1.2.840.113556.1.4.1133
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: kZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSClass,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSClass
adminDisplayName: msRADIUSClass
adminDescription: msRADIUSClass
attributeId: 1.2.840.113556.1.4.1146
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: nZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXASvrSeqTime
adminDisplayName: DXA-Svr-Seq-Time
adminDescription: DXA-Svr-Seq-Time
attributeId: 1.2.840.113556.1.2.361
omSyntax: 23
systemOnly: FALSE
searchFlags: 0
mapiID: 32923
hideFromAB: TRUE
dn: CN=MSMQ-Name-Style,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQNameStyle
adminDisplayName: MSMQ-Name-Style
adminDescription: MSMQ-Name-Style
attributeId: 1.2.840.113556.1.4.939
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: M8MNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: OutboundSites
adminDisplayName: Outbound-Sites
adminDescription: Outbound-Sites
attributeId: 1.2.840.113556.1.2.0
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: RXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33029
hideFromAB: TRUE
dn: CN=MSMQ-Queue-Type,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQQueueType
adminDisplayName: MSMQ-Queue-Type
adminDescription: MSMQ-Queue-Type
attributeId: 1.2.840.113556.1.4.917
omSyntax: 4
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: IMMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: NewsgroupList
adminDisplayName: Newsgroup-List
adminDescription: Newsgroup-List
attributeId: 1.2.840.113556.1.2.497
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: N3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33174
hideFromAB: TRUE
changetype: add
ldapDisplayName: ReportToOwner
adminDisplayName: Report-To-Owner
adminDescription: Report-To-Owner
attributeId: 1.2.840.113556.1.2.207
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: X3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33057
hideFromAB: TRUE
dn: CN=Telephone-Personal-Pager,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: personalPager
adminDisplayName: Telephone-Personal-Pager
adminDescription: Telephone-Personal-Pager
attributeId: 1.2.840.113556.1.2.612
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 128
rangeUpper: 128
schemaIdGuid:: h3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 35944
hideFromAB: TRUE
changetype: add
ldapDisplayName: RTSWindowSize
adminDisplayName: RTS-Window-Size
adminDescription: RTS-Window-Size
attributeId: 1.2.840.113556.1.2.153
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 10
schemaIdGuid:: anTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33065
hideFromAB: TRUE
changetype: add
ldapDisplayName: UseSiteValues
adminDisplayName: Use-Site-Values
adminDescription: Use-Site-Values
attributeId: 1.2.840.113556.1.2.478
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: l3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33155
hideFromAB: TRUE
dn: CN=msAscendBridge,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendBridge
adminDisplayName: msAscendBridge
adminDescription: msAscendBridge
attributeId: 1.2.840.113556.1.4.989
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: A5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendFRDLCI,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRDLCI
adminDisplayName: msAscendFRDLCI
adminDescription: msAscendFRDLCI
attributeId: 1.2.840.113556.1.4.1030
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: LJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendBackup,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendBackup
adminDisplayName: msAscendBackup
adminDescription: msAscendBackup
attributeId: 1.2.840.113556.1.4.985
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: /48M2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendForce56,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendForce56
adminDisplayName: msAscendForce56
adminDescription: msAscendForce56
attributeId: 1.2.840.113556.1.4.1023
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: JZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAAdminUpdate
adminDisplayName: DXA-Admin-Update
adminDescription: DXA-Admin-Update
attributeId: 1.2.840.113556.1.2.381
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ynPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32890
hideFromAB: TRUE
changetype: add
ldapDisplayName: CanNotCreatePF
adminDisplayName: Can-Not-Create-PF
adminDescription: Can-Not-Create-PF
attributeId: 1.2.840.113556.1.2.63
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: pXPfqOrF0RG7ywCAx2ZwwA==
linkID: 128
mapiID: 32860
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAAppendReqCN
adminDisplayName: DXA-Append-ReqCN
adminDisplayName: DXA-Append-ReqCN
adminDescription: DXA-Append-ReqCN
attributeId: 1.2.840.113556.1.2.174
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: y3PfqOrF0RG7ywCAx2ZwwA==
mapiID: 32891
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXARecipientCP
adminDisplayName: DXA-Recipient-CP
adminDescription: DXA-Recipient-CP
attributeId: 1.2.840.113556.1.2.384
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 24
mapiID: 32916
hideFromAB: TRUE
changetype: add
ldapDisplayName: MDBUnreadLimit
adminDisplayName: MDB-Unread-Limit
adminDescription: MDB-Unread-Limit
attributeId: 1.2.840.113556.1.2.69
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: IXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32979
hideFromAB: TRUE
dn: CN=msAscendMetric,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendMetric
adminDisplayName: msAscendMetric
adminDescription: msAscendMetric
attributeId: 1.2.840.113556.1.4.1065
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: T5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: OffLineABStyle
adminDisplayName: Off-Line-AB-Style
adminDescription: Off-Line-AB-Style
attributeId: 1.2.840.113556.1.2.390
omSyntax: 2
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: P3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33019
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAConfReqTime
adminDisplayName: DXA-Conf-Req-Time
adminDescription: DXA-Conf-Req-Time
attributeId: 1.2.840.113556.1.2.122
omSyntax: 23
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: zXPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32893
hideFromAB: TRUE
changetype: add
ldapDisplayName: CanPreserveDNs
adminDisplayName: Can-Preserve-DNs
adminDescription: Can-Preserve-DNs
attributeId: 1.2.840.113556.1.2.455
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: qXPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32864
hideFromAB: TRUE
changetype: add
ldapDisplayName: employeeNumber
adminDisplayName: Employee-Number
adminDescription: Employee-Number
attributeId: 1.2.840.113556.1.2.610
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 512
mapiID: 35943
hideFromAB: TRUE
changetype: add
ldapDisplayName: ConnectionType
adminDisplayName: Connection-Type
adminDescription: Connection-Type
attributeId: 1.2.840.113556.1.2.525
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
searchFlags: 0
schemaIdGuid:: uHPfqOrF0RG7ywCAx2ZwwA==
mapiID: 33203
hideFromAB: TRUE
dn: CN=msAscendFRType,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRType
adminDisplayName: msAscendFRType
adminDescription: msAscendFRType
attributeId: 1.2.840.113556.1.4.1040
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: NpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msNPIPPoolName,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msNPIPPoolName
adminDisplayName: msNPIPPoolName
adminDescription: msNPIPPoolName
attributeId: 1.2.840.113556.1.4.1128
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: jJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSAnyVSA,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSAnyVSA
adminDisplayName: msRADIUSAnyVSA
adminDescription: msRADIUSAnyVSA
attributeId: 1.2.840.113556.1.4.1137
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: lJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRASUseRADIUS,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRASUseRADIUS
adminDisplayName: msRASUseRADIUS
adminDescription: msRASUseRADIUS
attributeId: 1.2.840.113556.1.4.1192
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: yJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: AuthorizedUser
adminDisplayName: Authorized-User
adminDisplayName: Authorized-User
adminDescription: Authorized-User
attributeId: 1.2.840.113556.1.2.276
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 512
schemaIdGuid:: nXPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32854
hideFromAB: TRUE
dn: CN=msNPConstraint,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msNPConstraint
adminDisplayName: msNPConstraint
adminDescription: msNPConstraint
attributeId: 1.2.840.113556.1.4.1126
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: i5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=Attribute-Types,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: attributeTypes
adminDisplayName: Attribute-Types
adminDescription: Attribute-Types
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: RNl6mlPK0RG70ACAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: LocalBridgeHead
adminDisplayName: Local-Bridge-Head
adminDescription: Local-Bridge-Head
attributeId: 1.2.840.113556.1.2.311
omSyntax: 20
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: GnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32966
hideFromAB: TRUE
dn: CN=msRADIUSPrompt,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSPrompt
adminDisplayName: msRADIUSPrompt
adminDescription: msRADIUSPrompt
attributeId: 1.2.840.113556.1.4.1170
attributeId: 1.2.840.113556.1.4.1170
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: tZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Encrypt-Key,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQEncryptKey
adminDisplayName: MSMQ-Encrypt-Key
adminDescription: MSMQ-Encrypt-Key
attributeId: 1.2.840.113556.1.4.936
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: McMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: RASPhoneNumber
adminDisplayName: RAS-Phone-Number
adminDescription: RAS-Phone-Number
attributeId: 1.2.840.113556.1.2.314
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 128
schemaIdGuid:: VHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33046
hideFromAB: TRUE
changetype: add
ldapDisplayName: MonitorServers
adminDisplayName: Monitor-Servers
adminDescription: Monitor-Servers
attributeId: 1.2.840.113556.1.2.156
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: JHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32983
hideFromAB: TRUE
changetype: add
ldapDisplayName: SiteFolderGUID
adminDisplayName: Site-Folder-GUID
adminDescription: Site-Folder-GUID
attributeId: 1.2.840.113556.1.2.456
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: d3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33126
hideFromAB: TRUE
changetype: add
ldapDisplayName: SiteProxySpace
adminDisplayName: Site-Proxy-Space
adminDescription: Site-Proxy-Space
attributeId: 1.2.840.113556.1.2.385
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 1123
schemaIdGuid:: eXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33080
hideFromAB: TRUE
changetype: add
ldapDisplayName: SMIMEAlgListNA
adminDisplayName: SMIME-Alg-List-NA
adminDescription: SMIME-Alg-List-NA
attributeId: 1.2.840.113556.1.2.568
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: enTfqOrF0RG7ywCAx2ZwwA==
mapiID: 35891
hideFromAB: TRUE
changetype: add
ldapDisplayName: CanCreatePFDLBL
adminDisplayName: Can-Create-PF-DL-BL
adminDescription: Can-Create-PF-DL-BL
attributeId: 1.2.840.113556.1.2.340
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: pHPfqOrF0RG7ywCAx2ZwwA==
linkID: 127
mapiID: 32859
hideFromAB: TRUE
systemFlags: 1
dn: CN=Telephone-Personal-Mobile,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: personalMobile
adminDisplayName: Telephone-Personal-Mobile
adminDescription: Telephone-Personal-Mobile
attributeId: 1.2.840.113556.1.2.611
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 128
schemaIdGuid:: hnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 14877
hideFromAB: TRUE
changetype: add
ldapDisplayName: TransRetryMins
adminDisplayName: Trans-Retry-Mins
adminDescription: Trans-Retry-Mins
attributeId: 1.2.840.113556.1.2.219
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: inTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33095
hideFromAB: TRUE
changetype: add
ldapDisplayName: ViewDefinition
adminDisplayName: View-Definition
adminDescription: View-Definition
attributeId: 1.2.840.113556.1.2.549
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 2048
schemaIdGuid:: mXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 35867
hideFromAB: TRUE
dn: CN=msAscendDataSvc,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendDataSvc
adminDisplayName: msAscendDataSvc
adminDescription: msAscendDataSvc
attributeId: 1.2.840.113556.1.4.1009
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: F5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXALoggingLevel
adminDisplayName: DXA-Logging-Level
adminDescription: DXA-Logging-Level
attributeId: 1.2.840.113556.1.2.382
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 1
mapiID: 32905
hideFromAB: TRUE
changetype: add
ldapDisplayName: OffLineABServer
adminDisplayName: Off-Line-AB-Server
adminDescription: Off-Line-AB-Server
attributeId: 1.2.840.113556.1.2.392
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: PnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33018
hideFromAB: TRUE
changetype: add
ldapDisplayName: InboundNewsfeed
adminDisplayName: Inbound-Newsfeed
adminDescription: Inbound-Newsfeed
attributeId: 1.2.840.113556.1.2.494
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: EnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33171
hideFromAB: TRUE
changetype: add
ldapDisplayName: MaximumObjectID
adminDisplayName: Maximum-Object-ID
adminDescription: Maximum-Object-ID
attributeId: 1.2.840.113556.1.2.458
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 22
schemaIdGuid:: HnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33129
hideFromAB: TRUE
changetype: add
ldapDisplayName: houseIdentifier
adminDisplayName: House-Identifier
adminDescription: House-Identifier
attributeId: 1.2.840.113556.1.2.596
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 128
schemaIdGuid:: B3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 35924
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXARemoteClient
adminDisplayName: DXA-Remote-Client
adminDescription: DXA-Remote-Client
attributeId: 1.2.840.113556.1.2.112
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
mapiID: 32917
hideFromAB: TRUE
dn: CN=msAscendPPPVJ1172,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendPPPVJ1172
adminDisplayName: msAscendPPPVJ1172
adminDescription: msAscendPPPVJ1172
attributeId: 1.2.840.113556.1.4.1080
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: XpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msNPAllowDialin,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msNPAllowDialin
adminDisplayName: msNPAllowDialin
adminDescription: msNPAllowDialin
attributeId: 1.2.840.113556.1.4.1119
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: hZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendRouteIP,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendRouteIP
adminDisplayName: msAscendRouteIP
adminDescription: msAscendRouteIP
attributeId: 1.2.840.113556.1.4.1096
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: bpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
hideFromAB: TRUE
changetype: add
ldapDisplayName: HTTPPubGALLimit
adminDisplayName: HTTP-Pub-GAL-Limit
adminDescription: HTTP-Pub-GAL-Limit
attributeId: 1.2.840.113556.1.2.503
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: CnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33180
hideFromAB: TRUE
changetype: add
ldapDisplayName: AnonymousAccess
adminDisplayName: Anonymous-Access
adminDescription: Anonymous-Access
attributeId: 1.2.840.113556.1.2.482
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: knPfqOrF0RG7ywCAx2ZwwA==
mapiID: 33159
hideFromAB: TRUE
changetype: add
ldapDisplayName: ImportContainer
adminDisplayName: Import-Container
adminDescription: Import-Container
attributeId: 1.2.840.113556.1.2.110
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: DXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32954
hideFromAB: TRUE
dn: CN=Modify-Time-Stamp,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: modifyTimeStamp
adminDisplayName: Modify-Time-Stamp
adminDescription: Modify-Time-Stamp
omSyntax: 24
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: Stl6mlPK0RG70ACAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendFRDCEN392,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRDCEN392
adminDisplayName: msAscendFRDCEN392
adminDescription: msAscendFRDCEN392
attributeId: 1.2.840.113556.1.4.1025
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: J5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendFRDCEN393,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRDCEN393
adminDisplayName: msAscendFRDCEN393
adminDescription: msAscendFRDCEN393
attributeId: 1.2.840.113556.1.4.1026
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: KJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=DIT-Content-Rules,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: dITContentRules
adminDisplayName: DIT-Content-Rules
adminDescription: DIT-Content-Rules
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: Rtl6mlPK0RG70ACAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: MonitorServices
adminDisplayName: Monitor-Services
adminDescription: Monitor-Services
attributeId: 1.2.840.113556.1.2.160
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: JXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32984
hideFromAB: TRUE
dn: CN=msAscendFRDTEN392,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRDTEN392
adminDisplayName: msAscendFRDTEN392
adminDescription: msAscendFRDTEN392
attributeId: 1.2.840.113556.1.4.1031
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: LZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendFRDTEN393,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRDTEN393
adminDisplayName: msAscendFRDTEN393
adminDescription: msAscendFRDTEN393
attributeId: 1.2.840.113556.1.4.1032
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: LpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Service-Type,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQServiceType
adminDisplayName: MSMQ-Service-Type
adminDescription: MSMQ-Service-Type
attributeId: 1.2.840.113556.1.4.930
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: LcMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ControlMsgRules
adminDisplayName: Control-Msg-Rules
adminDescription: Control-Msg-Rules
attributeId: 1.2.840.113556.1.2.485
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 32767
schemaIdGuid:: u3PfqOrF0RG7ywCAx2ZwwA==
mapiID: 33162
hideFromAB: TRUE
dn: CN=Short-Server-Name,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: shortServerName
adminDisplayName: Short-Server-Name
adminDescription: Short-Server-Name
attributeId: 1.2.840.113556.1.4.1209
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ARWwRRnE0RG7yQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: SupportingStack
adminDisplayName: Supporting-Stack
adminDescription: Supporting-Stack
attributeId: 1.2.840.113556.1.2.28
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gHTfqOrF0RG7ywCAx2ZwwA==
linkID: 132
mapiID: 33086
hideFromAB: TRUE
dn: CN=msAscendCallback,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendCallback
adminDisplayName: msAscendCallback
adminDescription: msAscendCallback
attributeId: 1.2.840.113556.1.4.992
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: BpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendCBCPMode,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendCBCPMode
adminDisplayName: msAscendCBCPMode
adminDescription: msAscendCBCPMode
attributeId: 1.2.840.113556.1.4.1000
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: DpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: RemoteBridgeHead
adminDisplayName: Remote-Bridge-Head
adminDescription: Remote-Bridge-Head
attributeId: 1.2.840.113556.1.2.191
omSyntax: 20
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: WHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33050
hideFromAB: TRUE
dn: CN=msAscendDataRate,CN=Schema,CN=Configuration,DC=X
dn: CN=msAscendDataRate,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendDataRate
adminDisplayName: msAscendDataRate
adminDescription: msAscendDataRate
attributeId: 1.2.840.113556.1.4.1008
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: FpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: HideDLMembership
adminDisplayName: Hide-DL-Membership
adminDescription: Hide-DL-Membership
attributeId: 1.2.840.113556.1.2.297
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: BXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32952
hideFromAB: TRUE
changetype: add
ldapDisplayName: SendEMailMessage
adminDisplayName: Send-EMail-Message
adminDescription: Send-EMail-Message
attributeId: 1.2.840.113556.1.2.566
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: bnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 35889
hideFromAB: TRUE
changetype: add
ldapDisplayName: InboundAcceptAll
adminDisplayName: Inbound-Accept-All
adminDescription: Inbound-Accept-All
attributeId: 1.2.840.113556.1.2.555
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: D3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 35872
hideFromAB: TRUE
changetype: add
ldapDisplayName: CanNotCreatePFBL
adminDisplayName: Can-Not-Create-PF-BL
adminDescription: Can-Not-Create-PF-BL
attributeId: 1.2.840.113556.1.2.341
attributeId: 1.2.840.113556.1.2.341
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: pnPfqOrF0RG7ywCAx2ZwwA==
linkID: 129
mapiID: 32861
hideFromAB: TRUE
systemFlags: 1
changetype: add
ldapDisplayName: CanNotCreatePFDL
adminDisplayName: Can-Not-Create-PF-DL
adminDescription: Can-Not-Create-PF-DL
attributeId: 1.2.840.113556.1.2.300
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: p3PfqOrF0RG7ywCAx2ZwwA==
linkID: 130
mapiID: 32862
hideFromAB: TRUE
changetype: add
ldapDisplayName: ConnectedDomains
adminDisplayName: Connected-Domains
adminDescription: Connected-Domains
attributeId: 1.2.840.113556.1.2.211
omSyntax: 20
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 1243
schemaIdGuid:: tXPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32870
hideFromAB: TRUE
changetype: add
ldapDisplayName: GatewayLocalCred
adminDisplayName: Gateway-Local-Cred
adminDescription: Gateway-Local-Cred
attributeId: 1.2.840.113556.1.2.37
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: AXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32944
hideFromAB: TRUE
dn: CN=msAscendFRDirect,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRDirect
adminDisplayName: msAscendFRDirect
adminDescription: msAscendFRDirect
attributeId: 1.2.840.113556.1.4.1027
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: KZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendIPDirect,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendIPDirect
adminDisplayName: msAscendIPDirect
adminDescription: msAscendIPDirect
attributeId: 1.2.840.113556.1.4.1053
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Q5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ClockAlertRepair
adminDisplayName: Clock-Alert-Repair
adminDescription: Clock-Alert-Repair
attributeId: 1.2.840.113556.1.2.164
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: sXPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32866
hideFromAB: TRUE
dn: CN=msAscendIPXAlias,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendIPXAlias
adminDisplayName: msAscendIPXAlias
adminDescription: msAscendIPXAlias
attributeId: 1.2.840.113556.1.4.1055
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: RZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ClockAlertOffset
adminDisplayName: Clock-Alert-Offset
adminDescription: Clock-Alert-Offset
attributeId: 1.2.840.113556.1.2.165
omSyntax: 2
systemOnly: FALSE
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: sHPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32865
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAInTemplateMap
adminDisplayName: DXA-In-Template-Map
adminDescription: DXA-In-Template-Map
attributeId: 1.2.840.113556.1.2.363
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 128
mapiID: 32903
hideFromAB: TRUE
changetype: add
ldapDisplayName: DLMemRejectPerms
adminDisplayName: DL-Mem-Reject-Perms
adminDescription: DL-Mem-Reject-Perms
attributeId: 1.2.840.113556.1.2.47
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: wnPfqOrF0RG7ywCAx2ZwwA==
linkID: 116
hideFromAB: TRUE
changetype: add
ldapDisplayName: CharacterSetList
adminDisplayName: Character-Set-List
adminDescription: Character-Set-List
attributeId: 1.2.840.113556.1.2.477
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 128
schemaIdGuid:: rnPfqOrF0RG7ywCAx2ZwwA==
mapiID: 33154
hideFromAB: TRUE
changetype: add
ldapDisplayName: ExpandDLsLocally
adminDisplayName: Expand-DLs-Locally
adminDescription: Expand-DLs-Locally
attributeId: 1.2.840.113556.1.2.201
omSyntax: 1
systemOnly: FALSE
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: +3PfqOrF0RG7ywCAx2ZwwA==
mapiID: 32932
hideFromAB: TRUE
changetype: add
ldapDisplayName: AuthorizedDomain
adminDisplayName: Authorized-Domain
adminDescription: Authorized-Domain
attributeId: 1.2.840.113556.1.2.202
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 15
schemaIdGuid:: mnPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32852
hideFromAB: TRUE
changetype: add
ldapDisplayName: FoldersContainer
adminDisplayName: Folders-Container
adminDescription: Folders-Container
attributeId: 1.2.840.113556.1.2.235
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: /3PfqOrF0RG7ywCAx2ZwwA==
mapiID: 32942
hideFromAB: TRUE
dn: CN=msAscendCallType,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendCallType
adminDisplayName: msAscendCallType
adminDescription: msAscendCallType
attributeId: 1.2.840.113556.1.4.997
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: C5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendFRLinkUp,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRLinkUp
adminDisplayName: msAscendFRLinkUp
adminDescription: msAscendFRLinkUp
attributeId: 1.2.840.113556.1.4.1034
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: MJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendHostInfo,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendHostInfo
adminDisplayName: msAscendHostInfo
adminDescription: msAscendHostInfo
attributeId: 1.2.840.113556.1.4.1049
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: P5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: LocalInitialTurn
adminDisplayName: Local-Initial-Turn
adminDescription: Local-Initial-Turn
attributeId: 1.2.840.113556.1.2.39
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: HHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32968
hideFromAB: TRUE
changetype: add
ldapDisplayName: HomePublicServer
adminDisplayName: Home-Public-Server
adminDescription: Home-Public-Server
attributeId: 1.2.840.113556.1.2.441
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: BnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32831
hideFromAB: TRUE
dn: CN=msAscendMenuItem,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendMenuItem
adminDisplayName: msAscendMenuItem
adminDescription: msAscendMenuItem
attributeId: 1.2.840.113556.1.4.1063
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: TZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendRemoteFW,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendRemoteFW
adminDisplayName: msAscendRemoteFW
adminDescription: msAscendRemoteFW
attributeId: 1.2.840.113556.1.4.1092
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: apAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: EncryptAlgListNA
adminDisplayName: Encrypt-Alg-List-NA
adminDescription: Encrypt-Alg-List-NA
attributeId: 1.2.840.113556.1.2.130
omSyntax: 19
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 32
mapiID: 32832
hideFromAB: TRUE
changetype: add
ldapDisplayName: IncomingPassword
adminDisplayName: Incoming-Password
adminDescription: Incoming-Password
attributeId: 1.2.840.113556.1.2.521
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: FXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33199
hideFromAB: TRUE
dn: CN=msAscendSendAuth,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendSendAuth
adminDisplayName: msAscendSendAuth
adminDescription: msAscendSendAuth
attributeId: 1.2.840.113556.1.4.1101
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: c5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DLMemSubmitPerms
adminDisplayName: DL-Mem-Submit-Perms
adminDescription: DL-Mem-Submit-Perms
attributeId: 1.2.840.113556.1.2.144
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: xHPfqOrF0RG7ywCAx2ZwwA==
linkID: 112
hideFromAB: TRUE
dn: CN=msAscendFT1Caller,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFT1Caller
adminDisplayName: msAscendFT1Caller
adminDescription: msAscendFT1Caller
attributeId: 1.2.840.113556.1.4.1041
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: N5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendIPXRoute,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendIPXRoute
adminDisplayName: msAscendIPXRoute
adminDescription: msAscendIPXRoute
attributeId: 1.2.840.113556.1.4.1058
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: SJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendRouteIPX,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendRouteIPX
adminDisplayName: msAscendRouteIPX
adminDescription: msAscendRouteIPX
attributeId: 1.2.840.113556.1.4.1097
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: b5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendXmitRate,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendXmitRate
adminDisplayName: msAscendXmitRate
adminDescription: msAscendXmitRate
attributeId: 1.2.840.113556.1.4.1118
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: hJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Authenticate,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQAuthenticate
adminDisplayName: MSMQ-Authenticate
adminDescription: MSMQ-Authenticate
attributeId: 1.2.840.113556.1.4.923
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: JsMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSFilterId,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSFilterId
adminDisplayName: msRADIUSFilterId
adminDescription: msRADIUSFilterId
attributeId: 1.2.840.113556.1.4.1148
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: n5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: AnonymousAccount
adminDisplayName: Anonymous-Account
adminDescription: Anonymous-Account
attributeId: 1.2.840.113556.1.2.561
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: k3PfqOrF0RG7ywCAx2ZwwA==
mapiID: 35878
hideFromAB: TRUE
changetype: add
ldapDisplayName: ExportContainers
adminDisplayName: Export-Containers
adminDescription: Export-Containers
attributeId: 1.2.840.113556.1.2.111
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: /HPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32933
hideFromAB: TRUE
changetype: add
ldapDisplayName: MonitoredServers
adminDisplayName: Monitored-Servers
adminDescription: Monitored-Servers
attributeId: 1.2.840.113556.1.2.179
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: JnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32986
hideFromAB: TRUE
dn: CN=MSMQ-Base-Priority,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQBasePriority
adminDisplayName: MSMQ-Base-Priority
adminDescription: MSMQ-Base-Priority
attributeId: 1.2.840.113556.1.4.920
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: I8MNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: NumOfOpenRetries
adminDisplayName: Num-Of-Open-Retries
adminDescription: Num-Of-Open-Retries
attributeId: 1.2.840.113556.1.2.148
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: OnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33012
hideFromAB: TRUE
changetype: add
ldapDisplayName: OutboundNewsfeed
adminDisplayName: Outbound-Newsfeed
adminDescription: Outbound-Newsfeed
attributeId: 1.2.840.113556.1.2.496
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: RHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33173
hideFromAB: TRUE
dn: CN=MSMQ-Journal-Quota,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQJournalQuota
adminDisplayName: MSMQ-Journal-Quota
adminDisplayName: MSMQ-Journal-Quota
adminDescription: MSMQ-Journal-Quota
attributeId: 1.2.840.113556.1.4.921
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: JMMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: PSelectorInbound
adminDisplayName: P-Selector-Inbound
adminDescription: P-Selector-Inbound
attributeId: 1.2.840.113556.1.2.52
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 16
schemaIdGuid:: SXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33031
hideFromAB: TRUE
dn: CN=MSMQ-Computer-Type,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQComputerType
adminDisplayName: MSMQ-Computer-Type
adminDescription: MSMQ-Computer-Type
attributeId: 1.2.840.113556.1.4.933
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: LsMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: OutboundHostType
adminDisplayName: Outbound-Host-Type
adminDescription: Outbound-Host-Type
attributeId: 1.2.840.113556.1.2.522
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Q3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33200
hideFromAB: TRUE
changetype: add
ldapDisplayName: SSelectorInbound
adminDisplayName: S-Selector-Inbound
adminDescription: S-Selector-Inbound
attributeId: 1.2.840.113556.1.2.46
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 16
schemaIdGuid:: bXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33068
hideFromAB: TRUE
changetype: add
ldapDisplayName: OffLineABSchedule
adminDisplayName: Off-Line-AB-Schedule
adminDescription: Off-Line-AB-Schedule
attributeId: 1.2.840.113556.1.2.389
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 84
rangeUpper: 84
schemaIdGuid:: PXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33017
hideFromAB: TRUE
dn: CN=msAscendCBCPDelay,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendCBCPDelay
adminDisplayName: msAscendCBCPDelay
adminDescription: msAscendCBCPDelay
attributeId: 1.2.840.113556.1.4.998
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: DJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: RASCallbackNumber
adminDisplayName: RAS-Callback-Number
adminDescription: RAS-Callback-Number
attributeId: 1.2.840.113556.1.2.315
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 48
schemaIdGuid:: UnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33045
hideFromAB: TRUE
changetype: add
ldapDisplayName: SiteFolderServer
adminDisplayName: Site-Folder-Server
adminDescription: Site-Folder-Server
attributeId: 1.2.840.113556.1.2.457
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: eHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33127
hideFromAB: TRUE
changetype: add
ldapDisplayName: TSelectorInbound
adminDisplayName: T-Selector-Inbound
adminDescription: T-Selector-Inbound
attributeId: 1.2.840.113556.1.2.5
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 32
schemaIdGuid:: gnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33089
hideFromAB: TRUE
changetype: add
ldapDisplayName: TransTimeoutMins
adminDisplayName: Trans-Timeout-Mins
adminDescription: Trans-Timeout-Mins
attributeId: 1.2.840.113556.1.2.220
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: i3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33096
hideFromAB: TRUE
changetype: add
ldapDisplayName: BridgeheadServers
adminDisplayName: Bridgehead-Servers
adminDescription: Bridgehead-Servers
attributeId: 1.2.840.113556.1.2.463
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: oHPfqOrF0RG7ywCAx2ZwwA==
mapiID: 33140
hideFromAB: TRUE
changetype: add
ldapDisplayName: GatewayLocalDesig
adminDisplayName: Gateway-Local-Desig
adminDescription: Gateway-Local-Desig
attributeId: 1.2.840.113556.1.2.29
omSyntax: 22
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 32
schemaIdGuid:: AnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32945
hideFromAB: TRUE
dn: CN=msAscendHandleIPX,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendHandleIPX
adminDisplayName: msAscendHandleIPX
adminDescription: msAscendHandleIPX
attributeId: 1.2.840.113556.1.4.1043
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: OZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendIdleLimit,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendIdleLimit
adminDisplayName: msAscendIdleLimit
adminDescription: msAscendIdleLimit
attributeId: 1.2.840.113556.1.4.1050
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: QJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendIFNetmask,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendIFNetmask
adminDisplayName: msAscendIFNetmask
adminDescription: msAscendIFNetmask
attributeId: 1.2.840.113556.1.4.1051
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: QZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=Extended-Class-Info,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: extendedClassInfo
adminDisplayName: Extended-Class-Info
adminDescription: Extended-Class-Info
attributeId: 1.2.840.113556.1.4.908
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: SNl6mlPK0RG70ACAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendDHCPReply,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendDHCPReply
adminDisplayName: msAscendDHCPReply
adminDescription: msAscendDHCPReply
attributeId: 1.2.840.113556.1.4.1014
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: HJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendFRLinkMgt,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRLinkMgt
adminDisplayName: msAscendFRLinkMgt
adminDescription: msAscendFRLinkMgt
attributeId: 1.2.840.113556.1.4.1033
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: L5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: AdminExtensionDLL
adminDisplayName: Admin-Extension-DLL
adminDescription: Admin-Extension-DLL
attributeId: 1.2.840.113556.1.2.95
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 255
schemaIdGuid:: kXPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32844
hideFromAB: TRUE
dn: CN=msAscendFirstDest,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFirstDest
adminDisplayName: msAscendFirstDest
adminDescription: msAscendFirstDest
attributeId: 1.2.840.113556.1.4.1022
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: JJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ListPublicFolders
adminDisplayName: List-Public-Folders
adminDisplayName: List-Public-Folders
adminDescription: List-Public-Folders
attributeId: 1.2.840.113556.1.2.592
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: GXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 35920
hideFromAB: TRUE
changetype: add
ldapDisplayName: DisplayNameSuffix
adminDisplayName: Display-Name-Suffix
adminDescription: Display-Name-Suffix
attributeId: 1.2.840.113556.1.2.586
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: wXPfqOrF0RG7ywCAx2ZwwA==
mapiID: 35908
hideFromAB: TRUE
dn: CN=msRADIUSEapTypeID,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSEapTypeID
adminDisplayName: msRADIUSEapTypeID
adminDescription: msRADIUSEapTypeID
attributeId: 1.2.840.113556.1.4.1210
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 4I3dYZnF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
dn: CN=Allowed-Attributes,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: allowedAttributes
adminDisplayName: Allowed-Attributes
adminDescription: Allowed-Attributes
attributeId: 1.2.840.113556.1.4.913
omSyntax: 6
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: QNl6mlPK0RG70ACAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: CertificateChainV3
adminDisplayName: Certificate-Chain-V3
adminDescription: Certificate-Chain-V3
attributeId: 1.2.840.113556.1.2.562
omSyntax: 4
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: qnPfqOrF0RG7ywCAx2ZwwA==
mapiID: 35879
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAOutTemplateMap
adminDisplayName: DXA-Out-Template-Map
adminDescription: DXA-Out-Template-Map
attributeId: 1.2.840.113556.1.2.364
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 128
mapiID: 32907
hideFromAB: TRUE
dn: CN=msAscendEventType,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendEventType
adminDisplayName: msAscendEventType
adminDescription: msAscendEventType
attributeId: 1.2.840.113556.1.4.1019
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: IZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Transactional,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQTransactional
adminDisplayName: MSMQ-Transactional
adminDescription: MSMQ-Transactional
attributeId: 1.2.840.113556.1.4.926
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: KcMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSFramedMTU,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSFramedMTU
adminDisplayName: msRADIUSFramedMTU
adminDescription: msRADIUSFramedMTU
attributeId: 1.2.840.113556.1.4.1156
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: p5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=Possible-Inferiors,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: possibleInferiors
adminDisplayName: Possible-Inferiors
adminDescription: Possible-Inferiors
attributeId: 1.2.840.113556.1.4.915
omSyntax: 6
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: TNl6mlPK0RG70ACAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Privacy-Levell,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQPrivacyLevell
adminDisplayName: MSMQ-Privacy-Levell
adminDescription: MSMQ-Privacy-Levell
attributeId: 1.2.840.113556.1.4.924
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2
schemaIdGuid:: J8MNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: RASRemoteSRVRName
adminDisplayName: RAS-Remote-SRVR-Name
adminDescription: RAS-Remote-SRVR-Name
attributeId: 1.2.840.113556.1.2.78
omSyntax: 20
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 15
schemaIdGuid:: VnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33048
hideFromAB: TRUE
changetype: add
ldapDisplayName: ProxyGeneratorDLL
adminDisplayName: Proxy-Generator-DLL
adminDescription: Proxy-Generator-DLL
attributeId: 1.2.840.113556.1.2.328
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 255
schemaIdGuid:: TnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33039
hideFromAB: TRUE
changetype: add
ldapDisplayName: RemoteOutBHServer
adminDisplayName: Remote-Out-BH-Server
adminDescription: Remote-Out-BH-Server
attributeId: 1.2.840.113556.1.2.310
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: WnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33052
hideFromAB: TRUE
changetype: add
ldapDisplayName: RTSCheckpointSize
adminDisplayName: RTS-Checkpoint-Size
adminDescription: RTS-Checkpoint-Size
attributeId: 1.2.840.113556.1.2.152
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 100
schemaIdGuid:: aHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33063
hideFromAB: TRUE
dn: CN=msAscendBACPEnable,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendBACPEnable
adminDisplayName: msAscendBACPEnable
adminDescription: msAscendBACPEnable
attributeId: 1.2.840.113556.1.4.986
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: AJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendCBCPEnable,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendCBCPEnable
adminDisplayName: msAscendCBCPEnable
adminDescription: msAscendCBCPEnable
attributeId: 1.2.840.113556.1.4.999
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: DZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSPortLimit,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSPortLimit
adminDisplayName: msRADIUSPortLimit
adminDescription: msRADIUSPortLimit
attributeId: 1.2.840.113556.1.4.1169
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: tJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: OpenRetryInterval
adminDisplayName: Open-Retry-Interval
adminDescription: Open-Retry-Interval
attributeId: 1.2.840.113556.1.2.143
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: QXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33024
hideFromAB: TRUE
changetype: add
ldapDisplayName: NNTPDistributions
adminDisplayName: NNTP-Distributions
adminDescription: NNTP-Distributions
attributeId: 1.2.840.113556.1.2.498
omSyntax: 19
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 4096
schemaIdGuid:: OHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33175
hideFromAB: TRUE
changetype: add
ldapDisplayName: SMIMEAlgListOther
adminDisplayName: SMIME-Alg-List-Other
adminDescription: SMIME-Alg-List-Other
attributeId: 1.2.840.113556.1.2.569
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: e3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 35892
hideFromAB: TRUE
dn: CN=SubSchemaSubEntry,CN=Schema,CN=Configuration,DC=X
changetype: add
changetype: add
ldapDisplayName: subSchemaSubEntry
adminDisplayName: SubSchemaSubEntry
adminDescription: SubSchemaSubEntry
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: Tdl6mlPK0RG70ACAx2ZwwA==
hideFromAB: TRUE
dn: CN=Well-Known-Objects,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: wellKnownObjects
adminDisplayName: Well-Known-Objects
adminDescription: Well-Known-Objects
attributeId: 1.2.840.113556.1.4.618
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: g4kwBYh20RGt7QDAT9jVzQ==
hideFromAB: TRUE
changetype: add
ldapDisplayName: X25LeasedLinePort
adminDisplayName: X25-Leased-Line-Port
adminDescription: X25-Leased-Line-Port
attributeId: 1.2.840.113556.1.2.321
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 3
schemaIdGuid:: n3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33117
hideFromAB: TRUE
dn: CN=msAscendCallByCall,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendCallByCall
adminDisplayName: msAscendCallByCall
adminDescription: msAscendCallByCall
attributeId: 1.2.840.113556.1.4.995
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: CZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSCallbackId,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSCallbackId
adminDisplayName: msRADIUSCallbackId
adminDisplayName: msRADIUSCallbackId
adminDescription: msRADIUSCallbackId
attributeId: 1.2.840.113556.1.4.1144
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: m5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: X25RemoteMTAPhone
adminDisplayName: X25-Remote-MTA-Phone
adminDescription: X25-Remote-MTA-Phone
attributeId: 1.2.840.113556.1.2.373
omSyntax: 19
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 55
schemaIdGuid:: oXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33119
hideFromAB: TRUE
changetype: add
ldapDisplayName: MDBBackoffInterval
adminDisplayName: MDB-Backoff-Interval
adminDescription: MDB-Backoff-Interval
attributeId: 1.2.840.113556.1.2.72
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: H3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 32975
hideFromAB: TRUE
changetype: add
ldapDisplayName: X400AttachmentType
adminDisplayName: X400-Attachment-Type
adminDescription: X400-Attachment-Type
attributeId: 1.2.840.113556.1.2.99
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: onTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33120
hideFromAB: TRUE
changetype: add
ldapDisplayName: ImportSensitivity
adminDisplayName: Import-Sensitivity
adminDescription: Import-Sensitivity
attributeId: 1.2.840.113556.1.2.383
omSyntax: 2
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: DnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32955
hideFromAB: TRUE
dn: CN=msAscendAddSeconds,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendAddSeconds
adminDisplayName: msAscendAddSeconds
adminDescription: msAscendAddSeconds
attributeId: 1.2.840.113556.1.4.978
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: +I8M2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: SMIMEAlgSelectedNA
adminDisplayName: SMIME-Alg-Selected-NA
adminDescription: SMIME-Alg-Selected-NA
attributeId: 1.2.840.113556.1.2.570
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: fHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 35893
hideFromAB: TRUE
changetype: add
ldapDisplayName: X400SelectorSyntax
adminDisplayName: X400-Selector-Syntax
adminDescription: X400-Selector-Syntax
attributeId: 1.2.840.113556.1.2.443
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 1
schemaIdGuid:: o3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33121
hideFromAB: TRUE
changetype: add
ldapDisplayName: CanNotCreatePFDLBL
adminDisplayName: Can-Not-Create-PF-DL-BL
adminDescription: Can-Not-Create-PF-DL-BL
attributeId: 1.2.840.113556.1.2.342
omSyntax: 127
systemOnly: FALSE
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: qHPfqOrF0RG7ywCAx2ZwwA==
linkID: 131
mapiID: 32863
hideFromAB: TRUE
systemFlags: 1
changetype: add
ldapDisplayName: XMITTimeoutNormal
adminDisplayName: XMIT-Timeout-Normal
adminDescription: XMIT-Timeout-Normal
attributeId: 1.2.840.113556.1.2.67
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: pXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33124
hideFromAB: TRUE
changetype: add
ldapDisplayName: EnabledProtocolCfg
adminDisplayName: Enabled-Protocol-Cfg
adminDescription: Enabled-Protocol-Cfg
attributeId: 1.2.840.113556.1.2.515
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
mapiID: 33192
hideFromAB: TRUE
dn: CN=msAscendDataFilter,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendDataFilter
adminDisplayName: msAscendDataFilter
adminDescription: msAscendDataFilter
attributeId: 1.2.840.113556.1.4.1007
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: FZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendCallFilter,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendCallFilter
adminDisplayName: msAscendCallFilter
adminDescription: msAscendCallFilter
attributeId: 1.2.840.113556.1.4.996
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: CpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendDialNumber,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendDialNumber
adminDisplayName: msAscendDialNumber
adminDescription: msAscendDialNumber
attributeId: 1.2.840.113556.1.4.1015
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: HZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: XMITTimeoutUrgent
adminDisplayName: XMIT-Timeout-Urgent
adminDescription: XMIT-Timeout-Urgent
attributeId: 1.2.840.113556.1.2.53
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: pnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33125
hideFromAB: TRUE
dn: CN=msAscendRemoteAddr,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendRemoteAddr
adminDisplayName: msAscendRemoteAddr
adminDescription: msAscendRemoteAddr
attributeId: 1.2.840.113556.1.4.1091
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: aZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendTSIdleMode,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendTSIdleMode
adminDisplayName: msAscendTSIdleMode
adminDescription: msAscendTSIdleMode
attributeId: 1.2.840.113556.1.4.1110
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
changetype: add
ldapDisplayName: DLMemRejectPermsBL
adminDisplayName: DL-Mem-Reject-Perms-BL
adminDescription: DL-Mem-Reject-Perms-BL
attributeId: 1.2.840.113556.1.2.293
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: w3PfqOrF0RG7ywCAx2ZwwA==
linkID: 117
mapiID: 32882
hideFromAB: TRUE
systemFlags: 1
dn: CN=msAscendDBAMonitor,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendDBAMonitor
adminDisplayName: msAscendDBAMonitor
adminDescription: msAscendDBAMonitor
attributeId: 1.2.840.113556.1.4.1010
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: GJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ClockWarningRepair
adminDisplayName: Clock-Warning-Repair
adminDescription: Clock-Warning-Repair
attributeId: 1.2.840.113556.1.2.166
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: s3PfqOrF0RG7ywCAx2ZwwA==
mapiID: 32868
hideFromAB: TRUE
dn: CN=msAscendPPPAddress,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendPPPAddress
adminDisplayName: msAscendPPPAddress
adminDescription: msAscendPPPAddress
attributeId: 1.2.840.113556.1.4.1078
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: XJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendSendSecret,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendSendSecret
adminDisplayName: msAscendSendSecret
adminDescription: msAscendSendSecret
adminDescription: msAscendSendSecret
attributeId: 1.2.840.113556.1.4.1103
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: dZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSEapKeyFlag,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSEapKeyFlag
adminDisplayName: msRADIUSEapKeyFlag
adminDescription: msRADIUSEapKeyFlag
attributeId: 1.2.840.113556.1.4.1211
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 4Y3dYZnF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ClockWarningOffset
adminDisplayName: Clock-Warning-Offset
adminDescription: Clock-Warning-Offset
attributeId: 1.2.840.113556.1.2.177
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: snPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32867
hideFromAB: TRUE
dn: CN=msAscendSendPasswd,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendSendPasswd
adminDisplayName: msAscendSendPasswd
adminDescription: msAscendSendPasswd
attributeId: 1.2.840.113556.1.4.1102
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: dJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAExchangeOptions
adminDisplayName: DXA-Exchange-Options
adminDescription: DXA-Exchange-Options
attributeId: 1.2.840.113556.1.2.359
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 3
rangeUpper: 3
mapiID: 32896
hideFromAB: TRUE
changetype: add
ldapDisplayName: ControlMsgFolderID
adminDisplayName: Control-Msg-Folder-ID
adminDescription: Control-Msg-Folder-ID
attributeId: 1.2.840.113556.1.2.483
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 1024
schemaIdGuid:: unPfqOrF0RG7ywCAx2ZwwA==
mapiID: 33160
hideFromAB: TRUE
dn: CN=msAscendTargetUtil,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendTargetUtil
adminDisplayName: msAscendTargetUtil
adminDescription: msAscendTargetUtil
attributeId: 1.2.840.113556.1.4.1106
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: eJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ReplicationStagger
adminDisplayName: Replication-Stagger
adminDescription: Replication-Stagger
attributeId: 1.2.840.113556.1.2.349
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: XXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33055
hideFromAB: TRUE
dn: CN=msRADIUSVendorName,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSVendorName
adminDisplayName: msRADIUSVendorName
adminDescription: msRADIUSVendorName
attributeId: 1.2.840.113556.1.4.1182
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: wZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DLMemSubmitPermsBL
adminDisplayName: DL-Mem-Submit-Perms-BL
adminDescription: DL-Mem-Submit-Perms-BL
attributeId: 1.2.840.113556.1.2.291
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: xXPfqOrF0RG7ywCAx2ZwwA==
linkID: 113
mapiID: 32883
hideFromAB: TRUE
systemFlags: 1
changetype: add
ldapDisplayName: ServiceActionFirst
adminDisplayName: Service-Action-First
adminDescription: Service-Action-First
attributeId: 1.2.840.113556.1.2.161
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2
schemaIdGuid:: cHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33073
hideFromAB: TRUE
dn: CN=msNPAllowedEapType,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msNPAllowedEapType
adminDisplayName: msNPAllowedEapType
adminDescription: msNPAllowedEapType
attributeId: 1.2.840.113556.1.4.1120
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: hpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ServiceActionOther
adminDisplayName: Service-Action-Other
adminDescription: Service-Action-Other
attributeId: 1.2.840.113556.1.2.59
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2
schemaIdGuid:: cXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33074
hideFromAB: TRUE
dn: CN=Telephone-Assistant,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: TelephoneAssistant
adminDisplayName: Telephone-Assistant
adminDescription: Telephone-Assistant
attributeId: 1.2.840.113556.1.2.79
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: hHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 14894
hideFromAB: TRUE
changetype: add
ldapDisplayName: TempAssocThreshold
adminDisplayName: Temp-Assoc-Threshold
adminDescription: Temp-Assoc-Threshold
attributeId: 1.2.840.113556.1.2.329
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 32767
schemaIdGuid:: iHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33092
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXATemplateOptions
adminDisplayName: DXA-Template-Options
adminDescription: DXA-Template-Options
attributeId: 1.2.840.113556.1.2.358
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 3
mapiID: 32926
hideFromAB: TRUE
changetype: add
ldapDisplayName: GatewayRoutingTree
adminDisplayName: Gateway-Routing-Tree
adminDescription: Gateway-Routing-Tree
attributeId: 1.2.840.113556.1.2.167
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: A3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 32947
hideFromAB: TRUE
changetype: add
ldapDisplayName: X25LeasedorSwitched
adminDisplayName: X25-Leased-or-Switched
adminDescription: X25-Leased-or-Switched
attributeId: 1.2.840.113556.1.2.372
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: oHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33118
hideFromAB: TRUE
changetype: add
ldapDisplayName: AuthorizedPassword
adminDisplayName: Authorized-Password
adminDescription: Authorized-Password
attributeId: 1.2.840.113556.1.2.193
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 512
schemaIdGuid:: m3PfqOrF0RG7ywCAx2ZwwA==
mapiID: 32853
hideFromAB: TRUE
changetype: add
ldapDisplayName: ReturnExactMsgSize
adminDisplayName: Return-Exact-Msg-Size
adminDescription: Return-Exact-Msg-Size
attributeId: 1.2.840.113556.1.2.594
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Y3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 35922
hideFromAB: TRUE
changetype: add
ldapDisplayName: ClientAccessEnabled
adminDisplayName: Client-Access-Enabled
adminDescription: Client-Access-Enabled
attributeId: 1.2.840.113556.1.2.559
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: r3PfqOrF0RG7ywCAx2ZwwA==
mapiID: 35876
hideFromAB: TRUE
changetype: add
ldapDisplayName: ReportToOriginator
adminDisplayName: Report-To-Originator
adminDescription: Report-To-Originator
attributeId: 1.2.840.113556.1.2.206
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: XnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33056
hideFromAB: TRUE
dn: CN=msRADIUSTunnelType,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSTunnelType
adminDisplayName: msRADIUSTunnelType
adminDescription: msRADIUSTunnelType
attributeId: 1.2.840.113556.1.4.1181
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: wJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: RTSRecoveryTimeout
adminDisplayName: RTS-Recovery-Timeout
adminDescription: RTS-Recovery-Timeout
attributeId: 1.2.840.113556.1.2.151
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: aXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33064
hideFromAB: TRUE
dn: CN=Allowed-Child-Classes,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: allowedChildClasses
adminDisplayName: Allowed-Child-Classes
adminDescription: Allowed-Child-Classes
attributeId: 1.2.840.113556.1.4.911
omSyntax: 6
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: Qtl6mlPK0RG70ACAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendFRNailedGrp,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRNailedGrp
adminDisplayName: msAscendFRNailedGrp
adminDisplayName: msAscendFRNailedGrp
adminDescription: msAscendFRNailedGrp
attributeId: 1.2.840.113556.1.4.1036
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: MpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendAuthenAlias,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendAuthenAlias
adminDisplayName: msAscendAuthenAlias
adminDescription: msAscendAuthenAlias
attributeId: 1.2.840.113556.1.4.984
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: /o8M2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendIPXNodeAddr,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendIPXNodeAddr
adminDisplayName: msAscendIPXNodeAddr
adminDescription: msAscendIPXNodeAddr
attributeId: 1.2.840.113556.1.4.1056
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: RpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: EnableCompatibility
adminDisplayName: Enable-Compatibility
adminDescription: Enable-Compatibility
attributeId: 1.2.840.113556.1.2.567
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
mapiID: 35890
hideFromAB: TRUE
changetype: add
ldapDisplayName: AssociationLifetime
adminDisplayName: Association-Lifetime
adminDescription: Association-Lifetime
attributeId: 1.2.840.113556.1.2.149
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: lnPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32850
hideFromAB: TRUE
changetype: add
ldapDisplayName: OffLineABContainers
adminDisplayName: Off-Line-AB-Containers
adminDescription: Off-Line-AB-Containers
attributeId: 1.2.840.113556.1.2.391
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: PHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33016
hideFromAB: TRUE
changetype: add
ldapDisplayName: CrossCertificateCRL
adminDisplayName: Cross-Certificate-CRL
adminDescription: Cross-Certificate-CRL
attributeId: 1.2.840.113556.1.2.565
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: vHPfqOrF0RG7ywCAx2ZwwA==
mapiID: 35888
hideFromAB: TRUE
dn: CN=msAscendIPXPeerMode,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendIPXPeerMode
adminDisplayName: msAscendIPXPeerMode
adminDescription: msAscendIPXPeerMode
attributeId: 1.2.840.113556.1.4.1057
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: R5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendTSIdleLimit,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendTSIdleLimit
adminDisplayName: msAscendTSIdleLimit
adminDescription: msAscendTSIdleLimit
attributeId: 1.2.840.113556.1.4.1109
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: e5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendMultilinkID,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendMultilinkID
adminDisplayName: msAscendMultilinkID
adminDescription: msAscendMultilinkID
attributeId: 1.2.840.113556.1.4.1074
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: WJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendUserAcctKey,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendUserAcctKey
adminDisplayName: msAscendUserAcctKey
adminDescription: msAscendUserAcctKey
attributeId: 1.2.840.113556.1.4.1114
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msNPCalledStationID,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msNPCalledStationID
adminDisplayName: msNPCalledStationID
adminDescription: msNPCalledStationID
attributeId: 1.2.840.113556.1.4.1123
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: iZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: EncapsulationMethod
adminDisplayName: Encapsulation-Method
adminDescription: Encapsulation-Method
attributeId: 1.2.840.113556.1.2.448
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
mapiID: 32930
hideFromAB: TRUE
dn: CN=msAscendPPPAsyncMap,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendPPPAsyncMap
adminDisplayName: msAscendPPPAsyncMap
adminDescription: msAscendPPPAsyncMap
attributeId: 1.2.840.113556.1.4.1079
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: XZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendMaximumTime,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendMaximumTime
adminDisplayName: msAscendMaximumTime
adminDescription: msAscendMaximumTime
attributeId: 1.2.840.113556.1.4.1062
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: TJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendRequireAuth,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendRequireAuth
adminDisplayName: msAscendRequireAuth
adminDescription: msAscendRequireAuth
attributeId: 1.2.840.113556.1.4.1094
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: bJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendModemSlotNo,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendModemSlotNo
adminDisplayName: msAscendModemSlotNo
adminDescription: msAscendModemSlotNo
attributeId: 1.2.840.113556.1.4.1069
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: U5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ResponsibleLocalDXA
adminDisplayName: Responsible-Local-DXA
adminDescription: Responsible-Local-DXA
attributeId: 1.2.840.113556.1.2.298
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: YnTfqOrF0RG7ywCAx2ZwwA==
linkID: 122
mapiID: 33059
hideFromAB: TRUE
changetype: add
ldapDisplayName: InboundNewsfeedType
adminDisplayName: Inbound-Newsfeed-Type
adminDescription: Inbound-Newsfeed-Type
attributeId: 1.2.840.113556.1.2.554
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: E3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 35871
hideFromAB: TRUE
dn: CN=msAscendModemPortNo,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendModemPortNo
adminDisplayName: msAscendModemPortNo
adminDescription: msAscendModemPortNo
attributeId: 1.2.840.113556.1.4.1067
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: UZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: MDBMsgTimeOutPeriod
adminDisplayName: MDB-Msg-Time-Out-Period
adminDescription: MDB-Msg-Time-Out-Period
attributeId: 1.2.840.113556.1.2.64
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: IHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32976
hideFromAB: TRUE
dn: CN=msRADIUSFramedRoute,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSFramedRoute
adminDisplayName: msRADIUSFramedRoute
adminDescription: msRADIUSFramedRoute
attributeId: 1.2.840.113556.1.4.1158
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: qZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=Presentation-Address,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: presentationAddress
adminDisplayName: Presentation-Address
adminDescription: Presentation-Address
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
oMObjectClass:: KwwCh3McAIVc
schemaIdGuid:: S3TfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendThirdPrompt,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendThirdPrompt
adminDisplayName: msAscendThirdPrompt
adminDescription: msAscendThirdPrompt
attributeId: 1.2.840.113556.1.4.1107
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: eZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSIdleTimeout,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSIdleTimeout
adminDisplayName: msRADIUSIdleTimeout
adminDescription: msRADIUSIdleTimeout
attributeId: 1.2.840.113556.1.4.1160
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: q5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: AuthenticationToUse
adminDisplayName: Authentication-To-Use
adminDescription: Authentication-To-Use
attributeId: 1.2.840.113556.1.2.501
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 128
schemaIdGuid:: mXPfqOrF0RG7ywCAx2ZwwA==
mapiID: 33178
hideFromAB: TRUE
changetype: add
ldapDisplayName: EncryptAlgListOther
adminDisplayName: Encrypt-Alg-List-Other
adminDescription: Encrypt-Alg-List-Other
attributeId: 1.2.840.113556.1.2.399
omSyntax: 19
omSyntax: 19
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 32
schemaIdGuid:: +HPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32833
hideFromAB: TRUE
changetype: add
ldapDisplayName: HTTPPubABAttributes
adminDisplayName: HTTP-Pub-AB-Attributes
adminDescription: HTTP-Pub-AB-Attributes
attributeId: 1.2.840.113556.1.2.516
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 128
schemaIdGuid:: CHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33193
hideFromAB: TRUE
dn: CN=msRADIUSLoginIPHost,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSLoginIPHost
adminDisplayName: msRADIUSLoginIPHost
adminDescription: msRADIUSLoginIPHost
attributeId: 1.2.840.113556.1.4.1161
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: rJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSServiceType,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSServiceType
adminDisplayName: msRADIUSServiceType
adminDescription: msRADIUSServiceType
attributeId: 1.2.840.113556.1.4.1171
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: tpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msNPSessionsAllowed,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msNPSessionsAllowed
adminDisplayName: msNPSessionsAllowed
adminDescription: msNPSessionsAllowed
attributeId: 1.2.840.113556.1.4.1132
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
searchFlags: 0
schemaIdGuid:: kJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ServiceActionSecond
adminDisplayName: Service-Action-Second
adminDescription: Service-Action-Second
attributeId: 1.2.840.113556.1.2.60
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2
schemaIdGuid:: cnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33075
hideFromAB: TRUE
changetype: add
ldapDisplayName: ServiceRestartDelay
adminDisplayName: Service-Restart-Delay
adminDescription: Service-Restart-Delay
attributeId: 1.2.840.113556.1.2.162
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: c3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33076
hideFromAB: TRUE
dn: CN=msAscendFRDirectDLCI,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRDirectDLCI
adminDisplayName: msAscendFRDirectDLCI
adminDescription: msAscendFRDirectDLCI
attributeId: 1.2.840.113556.1.4.1028
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: KpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendUserAcctBase,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendUserAcctBase
adminDisplayName: msAscendUserAcctBase
adminDescription: msAscendUserAcctBase
attributeId: 1.2.840.113556.1.4.1112
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendFCPParameter,CN=Schema,CN=Configuration,DC=X
changetype: add
changetype: add
ldapDisplayName: msAscendFCPParameter
adminDisplayName: msAscendFCPParameter
adminDescription: msAscendFCPParameter
attributeId: 1.2.840.113556.1.4.1021
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: I5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: FilterLocalAddresses
adminDisplayName: Filter-Local-Addresses
adminDescription: Filter-Local-Addresses
attributeId: 1.2.840.113556.1.2.44
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: /nPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32941
hideFromAB: TRUE
dn: CN=msAscendModemShelfNo,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendModemShelfNo
adminDisplayName: msAscendModemShelfNo
adminDescription: msAscendModemShelfNo
attributeId: 1.2.840.113556.1.4.1068
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: UpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: EncryptAlgSelectedNA
adminDisplayName: Encrypt-Alg-Selected-NA
adminDescription: Encrypt-Alg-Selected-NA
attributeId: 1.2.840.113556.1.2.401
omSyntax: 19
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 32
schemaIdGuid:: +XPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32835
hideFromAB: TRUE
changetype: add
ldapDisplayName: DefaultMessageFormat
adminDisplayName: Default-Message-Format
adminDescription: Default-Message-Format
attributeId: 1.2.840.113556.1.2.572
attributeId: 1.2.840.113556.1.2.572
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: vXPfqOrF0RG7ywCAx2ZwwA==
mapiID: 35895
hideFromAB: TRUE
dn: CN=msAscendEndpointDisc,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendEndpointDisc
adminDisplayName: msAscendEndpointDisc
adminDescription: msAscendEndpointDisc
attributeId: 1.2.840.113556.1.4.1018
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: IJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendUserAcctTime,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendUserAcctTime
adminDisplayName: msAscendUserAcctTime
adminDescription: msAscendUserAcctTime
attributeId: 1.2.840.113556.1.4.1116
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAConfContainerList
adminDisplayName: DXA-Conf-Container-List
adminDescription: DXA-Conf-Container-List
attributeId: 1.2.840.113556.1.2.180
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: zHPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32892
hideFromAB: TRUE
dn: CN=msAscendMenuSelector,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendMenuSelector
adminDisplayName: msAscendMenuSelector
adminDescription: msAscendMenuSelector
attributeId: 1.2.840.113556.1.4.1064
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: TpAM2/LB0RG7xQCAx2ZwwA==
schemaIdGuid:: TpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Sign-Certificates,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQSignCertificates
adminDisplayName: MSMQ-Sign-Certificates
adminDescription: MSMQ-Sign-Certificates
attributeId: 1.2.840.113556.1.4.947
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: O8MNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendAssignIPPool,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendAssignIPPool
adminDisplayName: msAscendAssignIPPool
adminDescription: msAscendAssignIPPool
attributeId: 1.2.840.113556.1.4.982
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: /I8M2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendUserAcctHost,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendUserAcctHost
adminDisplayName: msAscendUserAcctHost
adminDescription: msAscendUserAcctHost
attributeId: 1.2.840.113556.1.4.1113
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: f5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendPreemptLimit,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendPreemptLimit
adminDisplayName: msAscendPreemptLimit
adminDescription: msAscendPreemptLimit
attributeId: 1.2.840.113556.1.4.1082
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: YJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendUserAcctType,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendUserAcctType
adminDisplayName: msAscendUserAcctType
adminDescription: msAscendUserAcctType
attributeId: 1.2.840.113556.1.4.1117
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: g5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DisabledGatewayProxy
adminDisplayName: Disabled-Gateway-Proxy
adminDescription: Disabled-Gateway-Proxy
attributeId: 1.2.840.113556.1.2.541
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 1024
schemaIdGuid:: wHPfqOrF0RG7ywCAx2ZwwA==
mapiID: 33219
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXANativeAddressType
adminDisplayName: DXA-Native-Address-Type
adminDescription: DXA-Native-Address-Type
attributeId: 1.2.840.113556.1.2.331
omSyntax: 19
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 32
mapiID: 32906
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXATemplateTimeStamp
adminDisplayName: DXA-Template-TimeStamp
adminDescription: DXA-Template-TimeStamp
attributeId: 1.2.840.113556.1.2.365
omSyntax: 23
systemOnly: FALSE
searchFlags: 0
mapiID: 32927
hideFromAB: TRUE
changetype: add
ldapDisplayName: MonitoringAlertDelay
adminDisplayName: Monitoring-Alert-Delay
adminDescription: Monitoring-Alert-Delay
attributeId: 1.2.840.113556.1.2.158
attributeId: 1.2.840.113556.1.2.158
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: J3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 32988
hideFromAB: TRUE
dn: CN=msAscendUserAcctPort,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendUserAcctPort
adminDisplayName: msAscendUserAcctPort
adminDescription: msAscendUserAcctPort
attributeId: 1.2.840.113556.1.4.1115
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ConnectionListFilter
adminDisplayName: Connection-List-Filter
adminDescription: Connection-List-Filter
attributeId: 1.2.840.113556.1.2.475
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 10240
schemaIdGuid:: tnPfqOrF0RG7ywCAx2ZwwA==
mapiID: 33152
hideFromAB: TRUE
dn: CN=msNPCallingStationID,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msNPCallingStationID
adminDisplayName: msNPCallingStationID
adminDescription: msNPCallingStationID
attributeId: 1.2.840.113556.1.4.1124
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ipAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSArapFeatures,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSArapFeatures
adminDisplayName: msRADIUSArapFeatures
adminDescription: msRADIUSArapFeatures
attributeId: 1.2.840.113556.1.4.1138
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
searchFlags: 0
schemaIdGuid:: lZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSLoginLATNode,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSLoginLATNode
adminDisplayName: msRADIUSLoginLATNode
adminDescription: msRADIUSLoginLATNode
attributeId: 1.2.840.113556.1.4.1163
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: rpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSLoginService,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSLoginService
adminDisplayName: msRADIUSLoginService
adminDescription: msRADIUSLoginService
attributeId: 1.2.840.113556.1.4.1166
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: sZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: AssocProtocolCfgNNTP
adminDisplayName: Assoc-Protocol-Cfg-NNTP
adminDescription: Assoc-Protocol-Cfg-NNTP
attributeId: 1.2.840.113556.1.2.512
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: lXPfqOrF0RG7ywCAx2ZwwA==
linkID: 140
mapiID: 33189
hideFromAB: TRUE
changetype: add
ldapDisplayName: MonitoringRecipients
adminDisplayName: Monitoring-Recipients
adminDescription: Monitoring-Recipients
attributeId: 1.2.840.113556.1.2.159
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: LnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33001
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAPrevRemoteEntries
adminDisplayName: DXA-Prev-Remote-Entries
adminDescription: DXA-Prev-Remote-Entries
attributeId: 1.2.840.113556.1.2.265
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
mapiID: 32912
hideFromAB: TRUE
dn: CN=msRADIUSArapSecurity,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSArapSecurity
adminDisplayName: msRADIUSArapSecurity
adminDescription: msRADIUSArapSecurity
attributeId: 1.2.840.113556.1.4.1139
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: lpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=Text-Encoded-OR-Address,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: textEncodedORAddress
adminDisplayName: Text-Encoded-OR-Address
adminDescription: Text-Encoded-OR-Address
attributeId: 0.9.2342.19200300.100.1.2
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 1024
schemaIdGuid:: iXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 35949
hideFromAB: TRUE
dn: CN=msRADIUSLoginLATPort,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSLoginLATPort
adminDisplayName: msRADIUSLoginLATPort
adminDescription: msRADIUSLoginLATPort
attributeId: 1.2.840.113556.1.4.1164
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: r5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: NumOfTransferRetries
adminDisplayName: Num-Of-Transfer-Retries
adminDisplayName: Num-Of-Transfer-Retries
adminDescription: Num-Of-Transfer-Retries
attributeId: 1.2.840.113556.1.2.134
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: O3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33013
hideFromAB: TRUE
dn: CN=ACS-Non-Reserved-Tx-Size,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: aCSNonReservedTxSize
adminDisplayName: ACS-Non-Reserved-Tx-Size
adminDescription: ACS-Non-Reserved-Tx-Size
attributeId: 1.2.840.113556.1.4.898
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: DSNy8PWu0RG9zwAA+ANnwQ==
hideFromAB: TRUE
dn: CN=msAscendCallbackDelay,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendCallbackDelay
adminDisplayName: msAscendCallbackDelay
adminDescription: msAscendCallbackDelay
attributeId: 1.2.840.113556.1.4.993
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: B5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: TranslationTableUsed
adminDisplayName: Translation-Table-Used
adminDescription: Translation-Table-Used
attributeId: 1.2.840.113556.1.2.396
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: kHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33101
hideFromAB: TRUE
dn: CN=msRADIUSLoginTCPPort,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSLoginTCPPort
adminDisplayName: msRADIUSLoginTCPPort
adminDescription: msRADIUSLoginTCPPort
attributeId: 1.2.840.113556.1.4.1167
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: spAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: OutgoingMsgSizeLimit
adminDisplayName: Outgoing-Msg-Size-Limit
adminDescription: Outgoing-Msg-Size-Limit
attributeId: 1.2.840.113556.1.2.490
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: RnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33167
hideFromAB: TRUE
changetype: add
ldapDisplayName: MonitoringAlertUnits
adminDisplayName: Monitoring-Alert-Units
adminDescription: Monitoring-Alert-Units
attributeId: 1.2.840.113556.1.2.57
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2
schemaIdGuid:: KHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32989
hideFromAB: TRUE
changetype: add
ldapDisplayName: OOFReplyToOriginator
adminDisplayName: OOF-Reply-To-Originator
adminDescription: OOF-Reply-To-Originator
attributeId: 1.2.840.113556.1.2.438
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: QHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33023
hideFromAB: TRUE
changetype: add
ldapDisplayName: DisableDeferredCommit
adminDisplayName: Disable-Deferred-Commit
adminDescription: Disable-Deferred-Commit
attributeId: 1.2.840.113556.1.2.558
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: v3PfqOrF0RG7ywCAx2ZwwA==
mapiID: 35875
hideFromAB: TRUE
dn: CN=msNPAllowedPortTypes,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msNPAllowedPortTypes
adminDisplayName: msNPAllowedPortTypes
adminDescription: msNPAllowedPortTypes
attributeId: 1.2.840.113556.1.4.1121
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: h5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendBridgeAddress,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendBridgeAddress
adminDisplayName: msAscendBridgeAddress
adminDescription: msAscendBridgeAddress
attributeId: 1.2.840.113556.1.4.990
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: BJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: TurnRequestThreshold
adminDisplayName: Turn-Request-Threshold
adminDescription: Turn-Request-Threshold
attributeId: 1.2.840.113556.1.2.38
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: k3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33104
hideFromAB: TRUE
dn: CN=MSMQ-In-Routing-Servers,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQInRoutingServers
adminDisplayName: MSMQ-In-Routing-Servers
adminDescription: MSMQ-In-Routing-Servers
attributeId: 1.2.840.113556.1.4.929
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: LMMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: XMITTimeoutNonUrgent
adminDisplayName: XMIT-Timeout-Non-Urgent
adminDescription: XMIT-Timeout-Non-Urgent
attributeId: 1.2.840.113556.1.2.84
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: pHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33123
hideFromAB: TRUE
dn: CN=msAscendBillingNumber,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendBillingNumber
adminDisplayName: msAscendBillingNumber
adminDescription: msAscendBillingNumber
attributeId: 1.2.840.113556.1.4.988
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ApAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendFRProfileName,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRProfileName
adminDisplayName: msAscendFRProfileName
adminDescription: msAscendFRProfileName
attributeId: 1.2.840.113556.1.4.1037
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: M5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendFRCircuitName,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRCircuitName
adminDisplayName: msAscendFRCircuitName
adminDescription: msAscendFRCircuitName
attributeId: 1.2.840.113556.1.4.1024
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: JpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendReceiveSecret,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendReceiveSecret
adminDisplayName: msAscendReceiveSecret
adminDescription: msAscendReceiveSecret
adminDescription: msAscendReceiveSecret
attributeId: 1.2.840.113556.1.4.1090
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: aJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: SMIMEAlgSelectedOther
adminDisplayName: SMIME-Alg-Selected-Other
adminDescription: SMIME-Alg-Selected-Other
attributeId: 1.2.840.113556.1.2.571
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: fXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 35894
hideFromAB: TRUE
dn: CN=msAscendClientGateway,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendClientGateway
adminDisplayName: msAscendClientGateway
adminDescription: msAscendClientGateway
attributeId: 1.2.840.113556.1.4.1003
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: EZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendRemoveSeconds,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendRemoveSeconds
adminDisplayName: msAscendRemoveSeconds
adminDescription: msAscendRemoveSeconds
attributeId: 1.2.840.113556.1.4.1093
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: a5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=Extended-Attribute-Info,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: extendedAttributeInfo
adminDisplayName: Extended-Attribute-Info
adminDescription: Extended-Attribute-Info
attributeId: 1.2.840.113556.1.4.909
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
searchFlags: 0
schemaIDGUID:: R9l6mlPK0RG70ACAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRASSavedFramedRoute,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRASSavedFramedRoute
adminDisplayName: msRASSavedFramedRoute
adminDescription: msRASSavedFramedRoute
attributeId: 1.2.840.113556.1.4.1191
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: x5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msNPRADIUSProfileName,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msNPRADIUSProfileName
adminDisplayName: msNPRADIUSProfileName
adminDescription: msNPRADIUSProfileName
attributeId: 1.2.840.113556.1.4.1129
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: jZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ServiceRestartMessage
adminDisplayName: Service-Restart-Message
adminDescription: Service-Restart-Message
attributeId: 1.2.840.113556.1.2.58
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 120
schemaIdGuid:: dHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33077
hideFromAB: TRUE
dn: CN=msAscendTransitNumber,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendTransitNumber
adminDisplayName: msAscendTransitNumber
adminDescription: msAscendTransitNumber
attributeId: 1.2.840.113556.1.4.1108
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: epAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSFramedRouting,CN=Schema,CN=Configuration,DC=X
dn: CN=msRADIUSFramedRouting,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSFramedRouting
adminDisplayName: msRADIUSFramedRouting
adminDescription: msRADIUSFramedRouting
attributeId: 1.2.840.113556.1.4.1159
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: qpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: RASPhonebookEntryName
adminDisplayName: RAS-Phonebook-Entry-Name
adminDescription: RAS-Phonebook-Entry-Name
attributeId: 1.2.840.113556.1.2.313
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: VXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33047
hideFromAB: TRUE
dn: CN=msAscendPRINumberType,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendPRINumberType
adminDisplayName: msAscendPRINumberType
adminDescription: msAscendPRINumberType
attributeId: 1.2.840.113556.1.4.1089
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Z5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: NNTPDistributionsFlag
adminDisplayName: NNTP-Distributions-Flag
adminDescription: NNTP-Distributions-Flag
attributeId: 1.2.840.113556.1.2.511
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: OXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33188
hideFromAB: TRUE
dn: CN=msAscendPPPVJSlotComp,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendPPPVJSlotComp
adminDisplayName: msAscendPPPVJSlotComp
adminDescription: msAscendPPPVJSlotComp
adminDescription: msAscendPPPVJSlotComp
attributeId: 1.2.840.113556.1.4.1081
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: X5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: LocalBridgeHeadAddress
adminDisplayName: Local-Bridge-Head-Address
adminDescription: Local-Bridge-Head-Address
attributeId: 1.2.840.113556.1.2.225
omSyntax: 20
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 1118
schemaIdGuid:: G3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 32967
hideFromAB: TRUE
dn: CN=msRADIUSLoginLATGroup,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSLoginLATGroup
adminDisplayName: msRADIUSLoginLATGroup
adminDescription: msRADIUSLoginLATGroup
attributeId: 1.2.840.113556.1.4.1162
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: rZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendSessionSvrKey,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendSessionSvrKey
adminDisplayName: msAscendSessionSvrKey
adminDescription: msAscendSessionSvrKey
attributeId: 1.2.840.113556.1.4.1104
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: dpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: TransferTimeoutNormal
adminDisplayName: Transfer-Timeout-Normal
adminDescription: Transfer-Timeout-Normal
attributeId: 1.2.840.113556.1.2.137
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: jnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33099
hideFromAB: TRUE
dn: CN=msRADIUSAttributeType,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSAttributeType
adminDisplayName: msRADIUSAttributeType
adminDescription: msRADIUSAttributeType
attributeId: 1.2.840.113556.1.4.1142
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: mZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: TransferRetryInterval
adminDisplayName: Transfer-Retry-Interval
adminDescription: Transfer-Retry-Interval
attributeId: 1.2.840.113556.1.2.133
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: jHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33097
hideFromAB: TRUE
changetype: add
ldapDisplayName: TransferTimeoutUrgent
adminDisplayName: Transfer-Timeout-Urgent
adminDescription: Transfer-Timeout-Urgent
attributeId: 1.2.840.113556.1.2.142
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: j3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33100
hideFromAB: TRUE
changetype: add
ldapDisplayName: MessageTrackingEnabled
adminDisplayName: Message-Tracking-Enabled
adminDescription: Message-Tracking-Enabled
attributeId: 1.2.840.113556.1.2.453
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: InTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32981
hideFromAB: TRUE
dn: CN=msAscendExpectCallback,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendExpectCallback
adminDisplayName: msAscendExpectCallback
adminDescription: msAscendExpectCallback
attributeId: 1.2.840.113556.1.4.1020
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: IpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSPasswordRetry,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSPasswordRetry
adminDisplayName: msRADIUSPasswordRetry
adminDescription: msRADIUSPasswordRetry
attributeId: 1.2.840.113556.1.4.1168
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: s5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSCallbackNumber,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSCallbackNumber
adminDisplayName: msRADIUSCallbackNumber
adminDescription: msRADIUSCallbackNumber
attributeId: 1.2.840.113556.1.4.1145
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: nJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendDialoutAllowed,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendDialoutAllowed
adminDisplayName: msAscendDialoutAllowed
adminDescription: msAscendDialoutAllowed
attributeId: 1.2.840.113556.1.4.1016
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: HpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=MSMQ-Out-Routing-Servers,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQOutRoutingServers
ldapDisplayName: mSMQOutRoutingServers
adminDisplayName: MSMQ-Out-Routing-Servers
adminDescription: MSMQ-Out-Routing-Servers
attributeId: 1.2.840.113556.1.4.928
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: K8MNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendMPPIdlePercent,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendMPPIdlePercent
adminDisplayName: msAscendMPPIdlePercent
adminDescription: msAscendMPPIdlePercent
attributeId: 1.2.840.113556.1.4.1070
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: VJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendAssignIPClient,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendAssignIPClient
adminDisplayName: msAscendAssignIPClient
adminDescription: msAscendAssignIPClient
attributeId: 1.2.840.113556.1.4.981
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: +48M2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: X25CallUserDataIncoming
adminDisplayName: X25-Call-User-Data-Incoming
adminDescription: X25-Call-User-Data-Incoming
attributeId: 1.2.840.113556.1.2.316
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 128
schemaIdGuid:: m3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33113
hideFromAB: TRUE
dn: CN=ACS-Max-No-Of-Account-Files,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: aCSMaxNoOfAccountFiles
adminDisplayName: ACS-Max-No-Of-Account-Files
adminDescription: ACS-Max-No-Of-Account-Files
attributeId: 1.2.840.113556.1.4.901
omSyntax: 2
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ECNy8PWu0RG9zwAA+ANnwQ==
hideFromAB: TRUE
dn: CN=msAscendDHCPPoolNumber,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendDHCPPoolNumber
adminDisplayName: msAscendDHCPPoolNumber
adminDescription: msAscendDHCPPoolNumber
attributeId: 1.2.840.113556.1.4.1013
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: G5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: AvailableDistributions
adminDisplayName: Available-Distributions
adminDescription: Available-Distributions
attributeId: 1.2.840.113556.1.2.486
omSyntax: 19
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 10240
schemaIdGuid:: n3PfqOrF0RG7ywCAx2ZwwA==
mapiID: 33163
hideFromAB: TRUE
dn: CN=msAscendAppletalkRoute,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendAppletalkRoute
adminDisplayName: msAscendAppletalkRoute
adminDescription: msAscendAppletalkRoute
attributeId: 1.2.840.113556.1.4.980
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: +o8M2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendRouteAppletalk,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendRouteAppletalk
adminDisplayName: msAscendRouteAppletalk
adminDescription: msAscendRouteAppletalk
attributeId: 1.2.840.113556.1.4.1095
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: bZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSArapZoneAccess,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSArapZoneAccess
adminDisplayName: msRADIUSArapZoneAccess
adminDescription: msRADIUSArapZoneAccess
attributeId: 1.2.840.113556.1.4.1140
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: l5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendAssignIPServer,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendAssignIPServer
adminDisplayName: msAscendAssignIPServer
adminDescription: msAscendAssignIPServer
attributeId: 1.2.840.113556.1.4.983
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: /Y8M2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAUnConfContainerList
adminDisplayName: DXA-UnConf-Container-List
adminDescription: DXA-UnConf-Container-List
attributeId: 1.2.840.113556.1.2.181
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
mapiID: 32929
hideFromAB: TRUE
changetype: add
ldapDisplayName: ReplicationMailMsgSize
adminDisplayName: Replication-Mail-Msg-Size
adminDescription: Replication-Mail-Msg-Size
attributeId: 1.2.840.113556.1.2.103
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: XHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33128
hideFromAB: TRUE
dn: CN=msAscendCBCPTrunkGroup,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendCBCPTrunkGroup
adminDisplayName: msAscendCBCPTrunkGroup
adminDescription: msAscendCBCPTrunkGroup
adminDescription: msAscendCBCPTrunkGroup
attributeId: 1.2.840.113556.1.4.1001
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: D5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendPreSessionTime,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendPreSessionTime
adminDisplayName: msAscendPreSessionTime
adminDescription: msAscendPreSessionTime
attributeId: 1.2.840.113556.1.4.1087
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ZZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAPrevExchangeOptions
adminDisplayName: DXA-Prev-Exchange-Options
adminDescription: DXA-Prev-Exchange-Options
attributeId: 1.2.840.113556.1.2.216
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 3
mapiID: 32909
hideFromAB: TRUE
changetype: add
ldapDisplayName: MonitoringWarningDelay
adminDisplayName: Monitoring-Warning-Delay
adminDescription: Monitoring-Warning-Delay
attributeId: 1.2.840.113556.1.2.157
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: MHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33005
hideFromAB: TRUE
dn: CN=msAscendNetwaretimeout,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendNetwaretimeout
adminDisplayName: msAscendNetwaretimeout
adminDescription: msAscendNetwaretimeout
attributeId: 1.2.840.113556.1.4.1075
omSyntax: 2
systemOnly: FALSE
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: WZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSFramedProtocol,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSFramedProtocol
adminDisplayName: msRADIUSFramedProtocol
adminDescription: msRADIUSFramedProtocol
attributeId: 1.2.840.113556.1.4.1157
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: qJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendNumberSessions,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendNumberSessions
adminDisplayName: msAscendNumberSessions
adminDescription: msAscendNumberSessions
attributeId: 1.2.840.113556.1.4.1076
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: WpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendNumInMultilink,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendNumInMultilink
adminDisplayName: msAscendNumInMultilink
adminDescription: msAscendNumInMultilink
attributeId: 1.2.840.113556.1.4.1077
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: W5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: SessionDisconnectTimer
adminDisplayName: Session-Disconnect-Timer
adminDescription: Session-Disconnect-Timer
attributeId: 1.2.840.113556.1.2.154
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: dXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33078
hideFromAB: TRUE
changetype: add
ldapDisplayName: TransportExpeditedData
adminDisplayName: Transport-Expedited-Data
adminDescription: Transport-Expedited-Data
attributeId: 1.2.840.113556.1.2.150
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: kXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33102
hideFromAB: TRUE
changetype: add
ldapDisplayName: X25CallUserDataOutgoing
adminDisplayName: X25-Call-User-Data-Outgoing
adminDescription: X25-Call-User-Data-Outgoing
attributeId: 1.2.840.113556.1.2.317
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 128
schemaIdGuid:: nHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33114
hideFromAB: TRUE
dn: CN=msAscendPreInputOctets,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendPreInputOctets
adminDisplayName: msAscendPreInputOctets
adminDescription: msAscendPreInputOctets
attributeId: 1.2.840.113556.1.4.1083
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: YZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msNPAuthenticationType,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msNPAuthenticationType
adminDisplayName: msNPAuthenticationType
adminDescription: msNPAuthenticationType
attributeId: 1.2.840.113556.1.4.1122
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: iJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAPrevTemplateOptions
adminDisplayName: DXA-Prev-Template-Options
adminDescription: DXA-Prev-Template-Options
adminDescription: DXA-Prev-Template-Options
attributeId: 1.2.840.113556.1.2.395
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 3
mapiID: 32914
hideFromAB: TRUE
changetype: add
ldapDisplayName: QuotaNotificationStyle
adminDisplayName: Quota-Notification-Style
adminDescription: Quota-Notification-Style
attributeId: 1.2.840.113556.1.2.388
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2
schemaIdGuid:: UHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33042
hideFromAB: TRUE
changetype: add
ldapDisplayName: RootNewsgroupsFolderID
adminDisplayName: Root-Newsgroups-Folder-ID
adminDescription: Root-Newsgroups-Folder-ID
attributeId: 1.2.840.113556.1.2.524
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 1024
schemaIdGuid:: ZnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33202
hideFromAB: TRUE
dn: CN=MS-MPPE-Encryption-Policy,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMPPEEncryptionPolicy
adminDisplayName: MS-MPPE-Encryption-Policy
adminDescription: MS-MPPE-Encryption-Policy
attributeId: 1.2.840.113556.1.4.977
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 948M2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: MonitoringWarningUnits
adminDisplayName: Monitoring-Warning-Units
adminDisplayName: Monitoring-Warning-Units
adminDescription: Monitoring-Warning-Units
attributeId: 1.2.840.113556.1.2.56
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2
schemaIdGuid:: MXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33006
hideFromAB: TRUE
dn: CN=msRADIUSTunnelPassword,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSTunnelPassword
adminDisplayName: msRADIUSTunnelPassword
adminDescription: msRADIUSTunnelPassword
attributeId: 1.2.840.113556.1.4.1177
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: vJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: RemoteBridgeHeadAddress
adminDisplayName: Remote-Bridge-Head-Address
adminDescription: Remote-Bridge-Head-Address
attributeId: 1.2.840.113556.1.2.94
omSyntax: 20
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 1118
schemaIdGuid:: WXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33051
hideFromAB: TRUE
changetype: add
ldapDisplayName: ExportCustomRecipients
adminDisplayName: Export-Custom-Recipients
adminDescription: Export-Custom-Recipients
attributeId: 1.2.840.113556.1.2.307
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: /XPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32934
hideFromAB: TRUE
dn: CN=msRADIUSSessionTimeout,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSSessionTimeout
adminDisplayName: msRADIUSSessionTimeout
adminDescription: msRADIUSSessionTimeout
attributeId: 1.2.840.113556.1.4.1172
attributeId: 1.2.840.113556.1.4.1172
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: t5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendHomeAgentIPAddr,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendHomeAgentIPAddr
adminDisplayName: msAscendHomeAgentIPAddr
adminDescription: msAscendHomeAgentIPAddr
attributeId: 1.2.840.113556.1.4.1045
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: O5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendDecChannelCount,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendDecChannelCount
adminDisplayName: msAscendDecChannelCount
adminDescription: msAscendDecChannelCount
attributeId: 1.2.840.113556.1.4.1011
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: GZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: SupportSMIMESignatures
adminDisplayName: Support-SMIME-Signatures
adminDescription: Support-SMIME-Signatures
attributeId: 1.2.840.113556.1.2.590
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: f3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 35912
hideFromAB: TRUE
dn: CN=msAscendDisconnectCause,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendDisconnectCause
adminDisplayName: msAscendDisconnectCause
adminDescription: msAscendDisconnectCause
attributeId: 1.2.840.113556.1.4.1017
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: H5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendIncChannelCount,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendIncChannelCount
adminDisplayName: msAscendIncChannelCount
adminDescription: msAscendIncChannelCount
attributeId: 1.2.840.113556.1.4.1052
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: QpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendFRDirectProfile,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendFRDirectProfile
adminDisplayName: msAscendFRDirectProfile
adminDescription: msAscendFRDirectProfile
attributeId: 1.2.840.113556.1.4.1029
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: K5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=ACS-Enable-RSVP-Accounting,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: aCSEnableRSVPAccounting
adminDisplayName: ACS-Enable-RSVP-Accounting
adminDescription: ACS-Enable-RSVP-Accounting
attributeId: 1.2.840.113556.1.4.899
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: DiNy8PWu0RG9zwAA+ANnwQ==
hideFromAB: TRUE
dn: CN=msAscendMinimumChannels,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendMinimumChannels
adminDisplayName: msAscendMinimumChannels
adminDescription: msAscendMinimumChannels
attributeId: 1.2.840.113556.1.4.1066
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: UJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendClientAssignDNS,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendClientAssignDNS
adminDisplayName: msAscendClientAssignDNS
adminDescription: msAscendClientAssignDNS
attributeId: 1.2.840.113556.1.4.1002
omSyntax: 2
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: EJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendMaximumChannels,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendMaximumChannels
adminDisplayName: msAscendMaximumChannels
adminDescription: msAscendMaximumChannels
attributeId: 1.2.840.113556.1.4.1061
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: S5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSFramedIPAddress,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSFramedIPAddress
adminDisplayName: msRADIUSFramedIPAddress
adminDescription: msRADIUSFramedIPAddress
attributeId: 1.2.840.113556.1.4.1153
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: pJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendRoutePreference,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendRoutePreference
adminDisplayName: msAscendRoutePreference
adminDescription: msAscendRoutePreference
attributeId: 1.2.840.113556.1.4.1098
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: cJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendHomeNetworkName,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendHomeNetworkName
adminDisplayName: msAscendHomeNetworkName
adminDescription: msAscendHomeNetworkName
attributeId: 1.2.840.113556.1.4.1048
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: PpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendMulticastClient,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendMulticastClient
adminDisplayName: msAscendMulticastClient
adminDescription: msAscendMulticastClient
attributeId: 1.2.840.113556.1.4.1071
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: VZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: EncryptAlgSelectedOther
adminDisplayName: Encrypt-Alg-Selected-Other
adminDescription: Encrypt-Alg-Selected-Other
attributeId: 1.2.840.113556.1.2.397
omSyntax: 19
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 32
schemaIdGuid:: +nPfqOrF0RG7ywCAx2ZwwA==
mapiID: 32829
hideFromAB: TRUE
dn: CN=msRADIUSFramedIPNetmask,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSFramedIPNetmask
adminDisplayName: msRADIUSFramedIPNetmask
adminDescription: msRADIUSFramedIPNetmask
attributeId: 1.2.840.113556.1.4.1154
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: pZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendConnectProgress,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendConnectProgress
adminDisplayName: msAscendConnectProgress
adminDescription: msAscendConnectProgress
attributeId: 1.2.840.113556.1.4.1006
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: FJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendLinkCompression,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendLinkCompression
adminDisplayName: msAscendLinkCompression
adminDescription: msAscendLinkCompression
attributeId: 1.2.840.113556.1.4.1059
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: SZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendPreInputPackets,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendPreInputPackets
adminDisplayName: msAscendPreInputPackets
adminDescription: msAscendPreInputPackets
attributeId: 1.2.840.113556.1.4.1084
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: YpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSLoginLATService,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSLoginLATService
adminDisplayName: msRADIUSLoginLATService
adminDescription: msRADIUSLoginLATService
attributeId: 1.2.840.113556.1.4.1165
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: sJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: MonitoringRecipientsNDR
adminDisplayName: Monitoring-Recipients-NDR
adminDescription: Monitoring-Recipients-NDR
attributeId: 1.2.840.113556.1.2.387
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: L3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33002
hideFromAB: TRUE
changetype: add
ldapDisplayName: TwoWayAlternateFacility
adminDisplayName: Two-Way-Alternate-Facility
adminDescription: Two-Way-Alternate-Facility
attributeId: 1.2.840.113556.1.2.40
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: lHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33105
hideFromAB: TRUE
hideFromAB: TRUE
dn: CN=msRADIUSAttributeNumber,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSAttributeNumber
adminDisplayName: msRADIUSAttributeNumber
adminDescription: msRADIUSAttributeNumber
attributeId: 1.2.840.113556.1.4.1141
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: mJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSAttributeVendor,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSAttributeVendor
adminDisplayName: msRADIUSAttributeVendor
adminDescription: msRADIUSAttributeVendor
attributeId: 1.2.840.113556.1.4.1143
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: mpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: PreserveInternetContent
adminDisplayName: Preserve-Internet-Content
adminDescription: Preserve-Internet-Content
attributeId: 1.2.840.113556.1.2.556
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: THTfqOrF0RG7ywCAx2ZwwA==
mapiID: 35874
hideFromAB: TRUE
dn: CN=msAscendPreOutputOctets,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendPreOutputOctets
adminDisplayName: msAscendPreOutputOctets
adminDescription: msAscendPreOutputOctets
attributeId: 1.2.840.113556.1.4.1085
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Y5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAPrevExportNativeOnly
adminDisplayName: DXA-Prev-Export-Native-Only
adminDescription: DXA-Prev-Export-Native-Only
adminDescription: DXA-Prev-Export-Native-Only
attributeId: 1.2.840.113556.1.2.203
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
mapiID: 32910
hideFromAB: TRUE
dn: CN=msRASMPPEEncryptionType,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRASMPPEEncryptionType
adminDisplayName: msRASMPPEEncryptionType
adminDescription: msRASMPPEEncryptionType
attributeId: 1.2.840.113556.1.4.1188
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: xJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: X25FacilitiesDataIncoming
adminDisplayName: X25-Facilities-Data-Incoming
adminDescription: X25-Facilities-Data-Incoming
attributeId: 1.2.840.113556.1.2.318
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 109
schemaIdGuid:: nXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33115
hideFromAB: TRUE
dn: CN=msAscendBaseChannelCount,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendBaseChannelCount
adminDisplayName: msAscendBaseChannelCount
adminDescription: msAscendBaseChannelCount
attributeId: 1.2.840.113556.1.4.987
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: AZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRASSavedCallbackNumber,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRASSavedCallbackNumber
adminDisplayName: msRASSavedCallbackNumber
adminDescription: msRASSavedCallbackNumber
attributeId: 1.2.840.113556.1.4.1189
omSyntax: 22
systemOnly: FALSE
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: xZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: X25FacilitiesDataOutgoing
adminDisplayName: X25-Facilities-Data-Outgoing
adminDescription: X25-Facilities-Data-Outgoing
attributeId: 1.2.840.113556.1.2.319
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 109
schemaIdGuid:: nnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33116
hideFromAB: TRUE
dn: CN=msAscendCallAttemptLimit,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendCallAttemptLimit
adminDisplayName: msAscendCallAttemptLimit
adminDescription: msAscendCallAttemptLimit
attributeId: 1.2.840.113556.1.4.991
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: BZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendIPPoolDefinition,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendIPPoolDefinition
adminDisplayName: msAscendIPPoolDefinition
adminDescription: msAscendIPPoolDefinition
attributeId: 1.2.840.113556.1.4.1054
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: RJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendPrimaryHomeAgent,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendPrimaryHomeAgent
adminDisplayName: msAscendPrimaryHomeAgent
adminDescription: msAscendPrimaryHomeAgent
attributeId: 1.2.840.113556.1.4.1088
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ZpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendHomeAgentUDPPort,CN=Schema,CN=Configuration,DC=X
changetype: add
changetype: add
ldapDisplayName: msAscendHomeAgentUDPPort
adminDisplayName: msAscendHomeAgentUDPPort
adminDescription: msAscendHomeAgentUDPPort
attributeId: 1.2.840.113556.1.4.1047
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: PZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendClientPrimaryDNS,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendClientPrimaryDNS
adminDisplayName: msAscendClientPrimaryDNS
adminDescription: msAscendClientPrimaryDNS
attributeId: 1.2.840.113556.1.4.1004
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: EpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSTunnelPreference,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSTunnelPreference
adminDisplayName: msRADIUSTunnelPreference
adminDescription: msRADIUSTunnelPreference
attributeId: 1.2.840.113556.1.4.1178
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: vZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendSecondsOfHistory,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendSecondsOfHistory
adminDisplayName: msAscendSecondsOfHistory
adminDescription: msAscendSecondsOfHistory
attributeId: 1.2.840.113556.1.4.1100
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: cpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendPreOutputPackets,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendPreOutputPackets
adminDisplayName: msAscendPreOutputPackets
adminDescription: msAscendPreOutputPackets
attributeId: 1.2.840.113556.1.4.1086
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ZJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSFramedIPXNetwork,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSFramedIPXNetwork
adminDisplayName: msRADIUSFramedIPXNetwork
adminDescription: msRADIUSFramedIPXNetwork
attributeId: 1.2.840.113556.1.4.1155
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ppAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: ConnectionListFilterType
adminDisplayName: Connection-List-Filter-Type
adminDescription: Connection-List-Filter-Type
attributeId: 1.2.840.113556.1.2.526
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2
schemaIdGuid:: t3PfqOrF0RG7ywCAx2ZwwA==
mapiID: 33204
hideFromAB: TRUE
dn: CN=msAscendHistoryWeighType,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendHistoryWeighType
adminDisplayName: msAscendHistoryWeighType
adminDescription: msAscendHistoryWeighType
attributeId: 1.2.840.113556.1.4.1044
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: OpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSTunnelMediumType,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSTunnelMediumType
adminDisplayName: msRADIUSTunnelMediumType
adminDescription: msRADIUSTunnelMediumType
attributeId: 1.2.840.113556.1.4.1176
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: u5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: TransferTimeoutNonUrgent
adminDisplayName: Transfer-Timeout-Non-Urgent
adminDescription: Transfer-Timeout-Non-Urgent
attributeId: 1.2.840.113556.1.2.136
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: jXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33098
hideFromAB: TRUE
dn: CN=msAscendCallBlockDuration,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendCallBlockDuration
adminDisplayName: msAscendCallBlockDuration
adminDescription: msAscendCallBlockDuration
attributeId: 1.2.840.113556.1.4.994
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: CJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendAppletalkPeerMode,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendAppletalkPeerMode
adminDisplayName: msAscendAppletalkPeerMode
adminDescription: msAscendAppletalkPeerMode
attributeId: 1.2.840.113556.1.4.979
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: +Y8M2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRASSavedFramedIPAddress,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRASSavedFramedIPAddress
adminDisplayName: msRASSavedFramedIPAddress
adminDescription: msRASSavedFramedIPAddress
attributeId: 1.2.840.113556.1.4.1190
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: xpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendDHCPMaximumLeases,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendDHCPMaximumLeases
adminDisplayName: msAscendDHCPMaximumLeases
adminDescription: msAscendDHCPMaximumLeases
attributeId: 1.2.840.113556.1.4.1012
attributeId: 1.2.840.113556.1.4.1012
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: GpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendHomeAgentPassword,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendHomeAgentPassword
adminDisplayName: msAscendHomeAgentPassword
adminDescription: msAscendHomeAgentPassword
attributeId: 1.2.840.113556.1.4.1046
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: PJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msNPSavedCallingStationID,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msNPSavedCallingStationID
adminDisplayName: msNPSavedCallingStationID
adminDescription: msNPSavedCallingStationID
attributeId: 1.2.840.113556.1.4.1130
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: jpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: QuotaNotificationSchedule
adminDisplayName: Quota-Notification-Schedule
adminDescription: Quota-Notification-Schedule
attributeId: 1.2.840.113556.1.2.98
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 84
rangeUpper: 84
schemaIdGuid:: T3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 33041
hideFromAB: TRUE
dn: CN=msRADIUSFramedCompression,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSFramedCompression
adminDisplayName: msRADIUSFramedCompression
adminDescription: msRADIUSFramedCompression
attributeId: 1.2.840.113556.1.4.1152
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: o5AM2/LB0RG7xQCAx2ZwwA==
schemaIdGuid:: o5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSTerminationAction,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSTerminationAction
adminDisplayName: msRADIUSTerminationAction
adminDescription: msRADIUSTerminationAction
attributeId: 1.2.840.113556.1.4.1173
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: uJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendTunnelingProtocol,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendTunnelingProtocol
adminDisplayName: msAscendTunnelingProtocol
adminDescription: msAscendTunnelingProtocol
attributeId: 1.2.840.113556.1.4.1111
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: AuthorizedPasswordConfirm
adminDisplayName: Authorized-Password-Confirm
adminDescription: Authorized-Password-Confirm
attributeId: 1.2.840.113556.1.2.493
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 512
schemaIdGuid:: nHPfqOrF0RG7ywCAx2ZwwA==
mapiID: 33170
hideFromAB: TRUE
dn: CN=msRASMPPEEncryptionPolicy,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRASMPPEEncryptionPolicy
adminDisplayName: msRASMPPEEncryptionPolicy
adminDescription: msRASMPPEEncryptionPolicy
attributeId: 1.2.840.113556.1.4.1187
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: w5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: MonitoringNormalPollUnits
ldapDisplayName: MonitoringNormalPollUnits
adminDisplayName: Monitoring-Normal-Poll-Units
adminDescription: Monitoring-Normal-Poll-Units
attributeId: 1.2.840.113556.1.2.88
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2
schemaIdGuid:: LXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 33000
hideFromAB: TRUE
dn: CN=msAscendSecondaryHomeAgent,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendSecondaryHomeAgent
adminDisplayName: msAscendSecondaryHomeAgent
adminDescription: msAscendSecondaryHomeAgent
attributeId: 1.2.840.113556.1.4.1099
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: cZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendClientSecondaryDNS,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendClientSecondaryDNS
adminDisplayName: msAscendClientSecondaryDNS
adminDescription: msAscendClientSecondaryDNS
attributeId: 1.2.840.113556.1.4.1005
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: E5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=Allowed-Attributes-Effective,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: allowedAttributesEffective
adminDisplayName: Allowed-Attributes-Effective
adminDescription: Allowed-Attributes-Effective
attributeId: 1.2.840.113556.1.4.914
omSyntax: 6
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: Qdl6mlPK0RG70ACAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendMulticastRateLimit,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendMulticastRateLimit
adminDisplayName: msAscendMulticastRateLimit
adminDescription: msAscendMulticastRateLimit
attributeId: 1.2.840.113556.1.4.1073
omSyntax: 2
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: V5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSTunnelAssignmentId,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSTunnelAssignmentId
adminDisplayName: msRADIUSTunnelAssignmentId
adminDescription: msRADIUSTunnelAssignmentId
attributeId: 1.2.840.113556.1.4.1174
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: uZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSVSAAttributeNumber,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSVSAAttributeNumber
adminDisplayName: msRADIUSVSAAttributeNumber
adminDescription: msRADIUSVSAAttributeNumber
attributeId: 1.2.840.113556.1.4.1183
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: wpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendSharedProfileEnable,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendSharedProfileEnable
adminDisplayName: msAscendSharedProfileEnable
adminDescription: msAscendSharedProfileEnable
attributeId: 1.2.840.113556.1.4.1105
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: d5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: CertificateRevocationListV1
adminDisplayName: Certificate-Revocation-List-V1
adminDescription: Certificate-Revocation-List-V1
attributeId: 1.2.840.113556.1.2.564
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: q3PfqOrF0RG7ywCAx2ZwwA==
mapiID: 35881
hideFromAB: TRUE
changetype: add
changetype: add
ldapDisplayName: CertificateRevocationListV3
adminDisplayName: Certificate-Revocation-List-V3
adminDescription: Certificate-Revocation-List-V3
attributeId: 1.2.840.113556.1.2.563
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: rHPfqOrF0RG7ywCAx2ZwwA==
mapiID: 35880
hideFromAB: TRUE
changetype: add
ldapDisplayName: MonitoringHotsitePollUnits
adminDisplayName: Monitoring-Hotsite-Poll-Units
adminDescription: Monitoring-Hotsite-Poll-Units
attributeId: 1.2.840.113556.1.2.87
omSyntax: 10
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2
schemaIdGuid:: K3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 32996
hideFromAB: TRUE
dn: CN=msRADIUSFramedAppleTalkLink,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSFramedAppleTalkLink
adminDisplayName: msRADIUSFramedAppleTalkLink
adminDescription: msRADIUSFramedAppleTalkLink
attributeId: 1.2.840.113556.1.4.1149
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: oJAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msAscendMaximumCallDuration,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendMaximumCallDuration
adminDisplayName: msAscendMaximumCallDuration
adminDescription: msAscendMaximumCallDuration
attributeId: 1.2.840.113556.1.4.1060
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: SpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSFramedAppleTalkZone,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSFramedAppleTalkZone
adminDisplayName: msRADIUSFramedAppleTalkZone
adminDescription: msRADIUSFramedAppleTalkZone
attributeId: 1.2.840.113556.1.4.1151
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: opAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=ACS-RSVP-Account-Files-Location,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: aCSRSVPAccountFilesLocation
adminDisplayName: ACS-RSVP-Account-Files-Location
adminDescription: ACS-RSVP-Account-Files-Location
attributeId: 1.2.840.113556.1.4.900
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: DyNy8PWu0RG9zwAA+ANnwQ==
hideFromAB: TRUE
dn: CN=ACS-Max-Size-Of-RSVP-Account-File,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: aCSMaxSizeOfRSVPAccountFile
adminDisplayName: ACS-Max-Size-Of-RSVP-Account-File
adminDescription: ACS-Max-Size-Of-RSVP-Account-File
attributeId: 1.2.840.113556.1.4.902
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ESNy8PWu0RG9zwAA+ANnwQ==
hideFromAB: TRUE
dn: CN=Allowed-Child-Classes-Effective,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: allowedChildClassesEffective
adminDisplayName: Allowed-Child-Classes-Effective
adminDescription: Allowed-Child-Classes-Effective
attributeId: 1.2.840.113556.1.4.912
omSyntax: 6
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: Q9l6mlPK0RG70ACAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: EnabledAuthorizationPackages
adminDisplayName: Enabled-Authorization-Packages
adminDescription: Enabled-Authorization-Packages
attributeId: 1.2.840.113556.1.2.479
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 128
rangeUpper: 128
mapiID: 33156
hideFromAB: TRUE
dn: CN=msAscendMulticastGLeaveDelay,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msAscendMulticastGLeaveDelay
adminDisplayName: msAscendMulticastGLeaveDelay
adminDescription: msAscendMulticastGLeaveDelay
attributeId: 1.2.840.113556.1.4.1072
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: VpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSTunnelClientEndpoint,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSTunnelClientEndpoint
adminDisplayName: msRADIUSTunnelClientEndpoint
adminDescription: msRADIUSTunnelClientEndpoint
attributeId: 1.2.840.113556.1.4.1175
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: upAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAPrevInExchangeSensitivity
adminDisplayName: DXA-Prev-In-Exchange-Sensitivity
adminDescription: DXA-Prev-In-Exchange-Sensitivity
attributeId: 1.2.840.113556.1.2.90
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
mapiID: 32911
hideFromAB: TRUE
changetype: add
ldapDisplayName: MonitoringNormalPollInterval
adminDisplayName: Monitoring-Normal-Poll-Interval
adminDescription: Monitoring-Normal-Poll-Interval
attributeId: 1.2.840.113556.1.2.187
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: LHTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32999
hideFromAB: TRUE
dn: CN=msRADIUSTunnelPrivateGroupId,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSTunnelPrivateGroupId
adminDisplayName: msRADIUSTunnelPrivateGroupId
adminDescription: msRADIUSTunnelPrivateGroupId
attributeId: 1.2.840.113556.1.4.1179
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: vpAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
dn: CN=msRADIUSTunnelServerEndpoint,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSTunnelServerEndpoint
adminDisplayName: msRADIUSTunnelServerEndpoint
adminDescription: msRADIUSTunnelServerEndpoint
attributeId: 1.2.840.113556.1.4.1180
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: v5AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: MonitoringEscalationProcedure
adminDisplayName: Monitoring-Escalation-Procedure
adminDescription: Monitoring-Escalation-Procedure
attributeId: 1.2.840.113556.1.2.188
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 1064
schemaIdGuid:: KXTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32994
hideFromAB: TRUE
changetype: add
ldapDisplayName: DXAPrevReplicationSensitivity
adminDisplayName: DXA-Prev-Replication-Sensitivity
adminDescription: DXA-Prev-Replication-Sensitivity
attributeId: 1.2.840.113556.1.2.215
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
mapiID: 32913
hideFromAB: TRUE
changetype: add
ldapDisplayName: MonitoringHotsitePollInterval
adminDisplayName: Monitoring-Hotsite-Poll-Interval
adminDescription: Monitoring-Hotsite-Poll-Interval
attributeId: 1.2.840.113556.1.2.186
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: KnTfqOrF0RG7ywCAx2ZwwA==
mapiID: 32995
hideFromAB: TRUE
changetype: add
ldapDisplayName: AvailableAuthorizationPackages
adminDisplayName: Available-Authorization-Packages
adminDescription: Available-Authorization-Packages
attributeId: 1.2.840.113556.1.2.476
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 512
schemaIdGuid:: nnPfqOrF0RG7ywCAx2ZwwA==
mapiID: 33153
hideFromAB: TRUE
dn: CN=ACS-Max-Aggregate-Peak-Rate-Per-User,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: aCSMaxAggregatePeakRatePerUser
adminDisplayName: ACS-Max-Aggregate-Peak-Rate-Per-User
adminDescription: ACS-Max-Aggregate-Peak-Rate-Per-User
attributeId: 1.2.840.113556.1.4.897
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: DCNy8PWu0RG9zwAA+ANnwQ==
hideFromAB: TRUE
dn: CN=msRADIUSFramedAppleTalkNetwork,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSFramedAppleTalkNetwork
adminDisplayName: msRADIUSFramedAppleTalkNetwork
adminDescription: msRADIUSFramedAppleTalkNetwork
attributeId: 1.2.840.113556.1.4.1150
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: oZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
changetype: add
ldapDisplayName: mailGateway
adminDisplayName: Mail-Gateway
adminDescription: Mail-Gateway
governsId: 1.2.840.113556.1.3.51
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: t3TfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Mail-Gateway,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: x400Link
adminDisplayName: X400-Link
adminDescription: X400-Link
governsId: 1.2.840.113556.1.3.29
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.51
schemaIdGuid:: 4HTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=X400-Link,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: informationStoreCfg
adminDisplayName: Information-Store-Cfg
adminDescription: Information-Store-Cfg
governsId: 1.2.840.113556.1.3.5
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: tHTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Information-Store-Cfg,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mHSMonitoringConfig
adminDisplayName: MHS-Monitoring-Config
adminDescription: MHS-Monitoring-Config
governsId: 1.2.840.113556.1.3.6
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: u3TfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=MHS-Monitoring-Config,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgShared
adminDisplayName: Protocol-Cfg-Shared
adminDescription: Protocol-Cfg-Shared
governsId: 1.2.840.113556.1.3.65
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-Shared,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgSharedSite
adminDisplayName: Protocol-Cfg-Shared-Site
adminDescription: Protocol-Cfg-Shared-Site
governsId: 1.2.840.113556.1.3.66
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.65
schemaIdGuid:: 0nTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-Shared-Site,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mTA
adminDisplayName: MTA
adminDescription: MTA
governsId: 1.2.840.113556.1.3.49
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
systemPossSuperiors: container
schemaIdGuid:: p3TfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=MTA,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: exchangeAdminService
adminDisplayName: Exchange-Admin-Service
adminDescription: Exchange-Admin-Service
governsId: 1.2.840.113556.1.3.62
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: snTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Exchange-Admin-Service,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgSharedServer
adminDisplayName: Protocol-Cfg-Shared-Server
adminDescription: Protocol-Cfg-Shared-Server
governsId: 1.2.840.113556.1.3.67
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.65
schemaIdGuid:: 0XTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-Shared-Server,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfg
adminDisplayName: Protocol-Cfg
adminDescription: Protocol-Cfg
governsId: 1.2.840.113556.1.3.68
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: wHTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg,CN=Schema,CN=Configuration,DC=X
dn: CN=RFC1006-X400-Link,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: rFC1006X400Link
adminDisplayName: RFC1006-X400-Link
adminDescription: RFC1006-X400-Link
governsId: 1.2.840.113556.1.3.32
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.29
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=RFC1006-X400-Link,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: remoteDXA
adminDisplayName: Remote-DXA
adminDescription: Remote-DXA
governsId: 1.2.840.113556.1.3.2
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Remote-DXA,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgHTTP
adminDisplayName: Protocol-Cfg-HTTP
adminDescription: Protocol-Cfg-HTTP
governsId: 1.2.840.113556.1.3.79
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.68
schemaIdGuid:: wXTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-HTTP,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgLDAP
adminDisplayName: Protocol-Cfg-LDAP
adminDescription: Protocol-Cfg-LDAP
governsId: 1.2.840.113556.1.3.75
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.68
schemaIdGuid:: x3TfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-LDAP,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgIMAP
adminDisplayName: Protocol-Cfg-IMAP
adminDescription: Protocol-Cfg-IMAP
governsId: 1.2.840.113556.1.3.84
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.68
schemaIdGuid:: xHTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-IMAP,CN=Schema,CN=Configuration,DC=X
dn: CN=Protocol-Cfg-HTTP-Server,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgHTTPServer
adminDisplayName: Protocol-Cfg-HTTP-Server
adminDescription: Protocol-Cfg-HTTP-Server
governsId: 1.2.840.113556.1.3.80
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.79
schemaIdGuid:: wnTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-HTTP-Server,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgNNTP
adminDisplayName: Protocol-Cfg-NNTP
adminDescription: Protocol-Cfg-NNTP
governsId: 1.2.840.113556.1.3.72
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.68
schemaIdGuid:: ynTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-NNTP,CN=Schema,CN=Configuration,DC=X
changetype: add
changetype: add
ldapDisplayName: mailboxAgent
adminDisplayName: Mailbox-Agent
adminDescription: Mailbox-Agent
governsId: 1.2.840.113556.1.3.17
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.22
schemaIdGuid:: uHTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Mailbox-Agent,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: directoryCfg
adminDisplayName: Directory-Cfg
adminDescription: Directory-Cfg
governsId: 1.2.840.113556.1.3.4
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: rXTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Directory-Cfg,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: nNTPNewsfeed
adminDisplayName: NNTP-Newsfeed
adminDescription: NNTP-Newsfeed
governsId: 1.2.840.113556.1.3.78
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: qXTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=NNTP-Newsfeed,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: dXASiteServer
adminDisplayName: DXA-Site-Server
adminDescription: DXA-Site-Server
governsId: 1.2.840.113556.1.3.60
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: sHTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=DXA-Site-Server,CN=Schema,CN=Configuration,DC=X
dn: CN=MSMQ-Site-Link,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQSiteLink
adminDisplayName: MSMQ-Site-Link
adminDescription: MSMQ-Site-Link
governsId: 1.2.840.113556.1.5.164
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: RsMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=MSMQ-Site-Link,CN=Schema,CN=Configuration,DC=X
dn: CN=MSMQ-Settings,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQSettings
adminDisplayName: MSMQ-Settings
adminDescription: MSMQ-Settings
governsId: 1.2.840.113556.1.5.165
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: R8MNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=MSMQ-Settings,CN=Schema,CN=Configuration,DC=X
dn: CN=EAP,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: eAP
adminDisplayName: EAP
adminDescription: EAP
governsId: 1.2.840.113556.1.5.167
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: 2ZAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=EAP,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: transportStack
adminDisplayName: Transport-Stack
adminDescription: Transport-Stack
governsId: 1.2.840.113556.1.3.18
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Transport-Stack,CN=Schema,CN=Configuration,DC=X
dn: CN=Mail-Connector,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mailConnector
adminDisplayName: Mail-Connector
adminDescription: Mail-Connector
governsId: 1.2.840.113556.1.3.61
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.51
schemaIdGuid:: tnTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Mail-Connector,CN=Schema,CN=Configuration,DC=X
dn: CN=MSMQ-Enterprise-Settings,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQEnterpriseSettings
adminDisplayName: MSMQ-Enterprise-Settings
adminDescription: MSMQ-Enterprise-Settings
governsId: 1.2.840.113556.1.5.163
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: RcMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=MSMQ-Enterprise-Settings,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: encryptionCfg
adminDisplayName: Encryption-Cfg
adminDescription: Encryption-Cfg
governsId: 1.2.840.113556.1.3.16
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: sXTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Encryption-Cfg,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: siteConnector
adminDisplayName: Site-Connector
adminDescription: Site-Connector
governsId: 1.2.840.113556.1.3.50
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Site-Connector,CN=Schema,CN=Configuration,DC=X
dn: CN=DX-Server-Conn,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: dXServerConn
adminDisplayName: DX-Server-Conn
adminDescription: DX-Server-Conn
governsId: 1.2.840.113556.1.3.20
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.2
schemaIdGuid:: r3TfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=DX-Server-Conn,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgPOP
adminDisplayName: Protocol-Cfg-POP
adminDescription: Protocol-Cfg-POP
governsId: 1.2.840.113556.1.3.69
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.68
schemaIdGuid:: zXTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-POP,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mHSLinkMonitoringConfig
adminDisplayName: MHS-Link-Monitoring-Config
adminDescription: MHS-Link-Monitoring-Config
governsId: 1.2.840.113556.1.3.12
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.6
schemaIdGuid:: uXTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=MHS-Link-Monitoring-Config,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: siteAddressing
adminDisplayName: Site-Addressing
adminDescription: Site-Addressing
governsId: 1.2.840.113556.1.3.0
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Site-Addressing,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: adminExtension
adminDisplayName: Admin-Extension
adminDescription: Admin-Extension
governsId: 1.2.840.113556.1.3.21
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: rHTfqOrF0RG7ywCAx2ZwwA==
schemaIdGuid:: rHTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Admin-Extension,CN=Schema,CN=Configuration,DC=X
dn: CN=Protocol-Cfg-POP-Server,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgPOPServer
adminDisplayName: Protocol-Cfg-POP-Server
adminDescription: Protocol-Cfg-POP-Server
governsId: 1.2.840.113556.1.3.71
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.69
schemaIdGuid:: znTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-POP-Server,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mHSPublicStore
adminDisplayName: MHS-Public-Store
adminDescription: MHS-Public-Store
governsId: 1.2.840.113556.1.3.28
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: vHTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=MHS-Public-Store,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: addIn
adminDisplayName: Add-In
adminDescription: Add-In
governsId: 1.2.840.113556.1.3.36
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: qnTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Add-In,CN=Schema,CN=Configuration,DC=X
dn: CN=RFC1006-Stack,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: rFC1006Stack
adminDisplayName: RFC1006-Stack
adminDescription: RFC1006-Stack
governsId: 1.2.840.113556.1.3.24
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.18
schemaIdGuid:: 13TfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=RFC1006-Stack,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgLDAPServer
adminDisplayName: Protocol-Cfg-LDAP-Server
adminDescription: Protocol-Cfg-LDAP-Server
governsId: 1.2.840.113556.1.3.77
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.75
schemaIdGuid:: yHTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-LDAP-Server,CN=Schema,CN=Configuration,DC=X
dn: CN=Protocol-Cfg-IMAP-Server,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgIMAPServer
adminDisplayName: Protocol-Cfg-IMAP-Server
adminDescription: Protocol-Cfg-IMAP-Server
governsId: 1.2.840.113556.1.3.85
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.84
schemaIdGuid:: xXTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-IMAP-Server,CN=Schema,CN=Configuration,DC=X
dn: CN=MS-Mail-Connector,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMailConnector
adminDisplayName: MS-Mail-Connector
adminDescription: MS-Mail-Connector
governsId: 1.2.840.113556.1.3.31
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.51
schemaIdGuid:: vnTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=MS-Mail-Connector,CN=Schema,CN=Configuration,DC=X
dn: CN=msRADIUSProfile,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSProfile
adminDisplayName: msRADIUSProfile
adminDescription: msRADIUSProfile
governsId: 1.2.840.113556.1.5.166
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: 2JAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=msRADIUSProfile,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mHSMessageStore
adminDisplayName: MHS-Message-Store
adminDescription: MHS-Message-Store
governsId: 1.2.840.113556.1.3.56
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: unTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=MHS-Message-Store,CN=Schema,CN=Configuration,DC=X
dn: CN=Protocol-Cfg-HTTP-Site,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgHTTPSite
adminDisplayName: Protocol-Cfg-HTTP-Site
adminDescription: Protocol-Cfg-HTTP-Site
governsId: 1.2.840.113556.1.3.81
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.79
schemaIdGuid:: w3TfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-HTTP-Site,CN=Schema,CN=Configuration,DC=X
dn: CN=Protocol-Cfg-NNTP-Site,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgNNTPSite
adminDisplayName: Protocol-Cfg-NNTP-Site
adminDescription: Protocol-Cfg-NNTP-Site
governsId: 1.2.840.113556.1.3.73
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.72
schemaIdGuid:: zHTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-NNTP-Site,CN=Schema,CN=Configuration,DC=X
dn: CN=msRADIUSVendors,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSVendors
adminDisplayName: msRADIUSVendors
adminDescription: msRADIUSVendors
governsId: 1.2.840.113556.1.5.170
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: 3JAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=msRADIUSVendors,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mTACfg
adminDisplayName: MTA-Cfg
adminDescription: MTA-Cfg
governsId: 1.2.840.113556.1.3.3
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: qHTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=MTA-Cfg,CN=Schema,CN=Configuration,DC=X
dn: CN=Virtual-Computer,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: virtualComputer
adminDisplayName: Virtual-Computer
adminDescription: Virtual-Computer
governsId: 1.2.840.113556.1.5.160
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.30
subClassOf: 1.2.840.113556.1.3.30
schemaIdGuid:: QsMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Computer,CN=Schema,CN=Configuration,DC=X
dn: CN=msNetworkPolicy,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msNetworkPolicy
adminDisplayName: msNetworkPolicy
adminDescription: msNetworkPolicy
governsId: 1.2.840.113556.1.5.168
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: 2pAM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=msNetworkPolicy,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mHSServerMonitoringConfig
adminDisplayName: MHS-Server-Monitoring-Config
adminDescription: MHS-Server-Monitoring-Config
governsId: 1.2.840.113556.1.3.7
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.6
schemaIdGuid:: vXTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=MHS-Server-Monitoring-Config,CN=Schema,CN=Configuration,DC=X
dn: CN=Cluster-Organizational-Unit,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: clusterOrganizationalUnit
adminDisplayName: Cluster-Organizational-Unit
adminDescription: Cluster-Organizational-Unit
governsId: 1.2.840.113556.1.5.159
rdnAttId: 2.5.4.11
subClassOf: 2.5.6.5
schemaIdGuid:: QcMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Cluster-Organizational-Unit,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: rASX400Link
adminDisplayName: RAS-X400-Link
adminDescription: RAS-X400-Link
governsId: 1.2.840.113556.1.3.34
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.29
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=RAS-X400-Link,CN=Schema,CN=Configuration,DC=X
dn: CN=X25-Stack,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: x25Stack
adminDisplayName: X25-Stack
adminDescription: X25-Stack
governsId: 1.2.840.113556.1.3.27
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.18
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=X25-Stack,CN=Schema,CN=Configuration,DC=X
dn: CN=Protocol-Cfg-NNTP-Server,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgNNTPServer
adminDisplayName: Protocol-Cfg-NNTP-Server
adminDescription: Protocol-Cfg-NNTP-Server
governsId: 1.2.840.113556.1.3.74
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.72
schemaIdGuid:: y3TfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-NNTP-Server,CN=Schema,CN=Configuration,DC=X
dn: CN=Residential-Person,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: residentialPerson
adminDisplayName: Residential-Person
adminDescription: Residential-Person
governsId: 2.5.6.10
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.6
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Residential-Person,CN=Schema,CN=Configuration,DC=X
dn: CN=TP4-Stack,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: tP4Stack
adminDisplayName: TP4-Stack
adminDescription: TP4-Stack
governsId: 1.2.840.113556.1.3.25
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.18
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=TP4-Stack,CN=Schema,CN=Configuration,DC=X
dn: CN=MSMQ-Configuration,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQConfiguration
adminDisplayName: MSMQ-Configuration
adminDescription: MSMQ-Configuration
governsId: 1.2.840.113556.1.5.162
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: RMMNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=MSMQ-Configuration,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: localDXA
adminDisplayName: Local-DXA
adminDescription: Local-DXA
governsId: 1.2.840.113556.1.3.1
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: tXTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Local-DXA,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: rASStack
adminDisplayName: RAS-Stack
adminDescription: RAS-Stack
governsId: 1.2.840.113556.1.3.26
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.18
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=RAS-Stack,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: addrType
adminDisplayName: Addr-Type
adminDescription: Addr-Type
governsId: 1.2.840.113556.1.3.57
rdnAttId: 2.5.4.3
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: q3TfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Addr-Type,CN=Schema,CN=Configuration,DC=X
dn: CN=Organizational-Role,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: organizationalRole
adminDisplayName: Organizational-Role
adminDescription: Organizational-Role
governsId: 2.5.6.8
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: v3TfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Organizational-Role,CN=Schema,CN=Configuration,DC=X
dn: CN=X25-X400-Link,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: x25X400Link
adminDisplayName: X25-X400-Link
adminDescription: X25-X400-Link
governsId: 1.2.840.113556.1.3.35
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.29
hideFromAB: TRUE
systemOnly: FALSE
systemOnly: FALSE
defaultObjectCategory: CN=X25-X400-Link,CN=Schema,CN=Configuration,DC=X
dn: CN=msRADIUSDictionary,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: msRADIUSDictionary
adminDisplayName: msRADIUSDictionary
adminDescription: msRADIUSDictionary
governsId: 1.2.840.113556.1.5.169
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: 25AM2/LB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=msRADIUSDictionary,CN=Schema,CN=Configuration,DC=X
dn: CN=Protocol-Cfg-POP-Site,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgPOPSite
adminDisplayName: Protocol-Cfg-POP-Site
adminDescription: Protocol-Cfg-POP-Site
governsId: 1.2.840.113556.1.3.70
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.69
schemaIdGuid:: z3TfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-POP-Site,CN=Schema,CN=Configuration,DC=X
# Make the may-contains of subschema class non-constructed.
changetype: modify
delete: systemFlags
-
changetype: modify
delete: systemFlags
-
changetype: modify
delete: systemFlags
-
changetype: modify
delete: systemFlags
-
changetype: modify
changetype: modify
delete: systemFlags
-
changetype: modify
delete: systemFlags
-
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=SubSchema,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: subSchema
adminDisplayName: SubSchema
adminDescription: SubSchema
governsId: 2.5.20.1
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: YTKLWo3D0RG7yQCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=SubSchema,CN=Schema,CN=Configuration,DC=X
changetype: modify
add: systemFlags
-
changetype: modify
add: systemFlags
-
changetype: modify
add: systemFlags
-
changetype: modify
add: systemFlags
-
changetype: modify
add: systemFlags
-
changetype: modify
add: systemFlags
-
changetype: add
ldapDisplayName: dXRequestor
adminDisplayName: DX-Requestor
adminDescription: DX-Requestor
governsId: 1.2.840.113556.1.3.19
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.2
schemaIdGuid:: rnTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=DX-Requestor,CN=Schema,CN=Configuration,DC=X
dn: CN=TP4-X400-Link,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: tP4X400Link
adminDisplayName: TP4-X400-Link
adminDescription: TP4-X400-Link
governsId: 1.2.840.113556.1.3.33
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.29
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=TP4-X400-Link,CN=Schema,CN=Configuration,DC=X
dn: CN=MSMQ-Queue,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: mSMQQueue
adminDisplayName: MSMQ-Queue
adminDescription: MSMQ-Queue
governsId: 1.2.840.113556.1.5.161
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: Q8MNmgDB0RG7xQCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=MSMQ-Queue,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgLDAPSite
adminDisplayName: Protocol-Cfg-LDAP-Site
adminDescription: Protocol-Cfg-LDAP-Site
governsId: 1.2.840.113556.1.3.76
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.75
schemaIdGuid:: yXTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-LDAP-Site,CN=Schema,CN=Configuration,DC=X
dn: CN=Protocol-Cfg-IMAP-Site,CN=Schema,CN=Configuration,DC=X
changetype: add
ldapDisplayName: protocolCfgIMAPSite
adminDisplayName: Protocol-Cfg-IMAP-Site
adminDescription: Protocol-Cfg-IMAP-Site
governsId: 1.2.840.113556.1.3.86
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.84
schemaIdGuid:: xnTfqOrF0RG7ywCAx2ZwwA==
hideFromAB: TRUE
systemOnly: FALSE
defaultObjectCategory: CN=Protocol-Cfg-IMAP-Site,CN=Schema,CN=Configuration,DC=X
# Modifies
dn: CN=Class-Schema,CN=Schema,CN=Configuration,DC=X
changetype: modify
add: systemFlags
-
dn: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X
changetype: modify
add: systemFlags
-
-
changetype: modify
systemMayContain: mail
-
changetype: modify
systemMayContain: c
-
dn: CN=RID-Available-Pool,CN=Schema,CN=Configuration,DC=X
changetype: modify
replace: systemOnly
replace: systemOnly
systemOnly: FALSE
-
dn: CN=Activation-Schedule,CN=Schema,CN=Configuration,DC=X
changetype: modify
add: rangeUpper
rangeUpper: 84
-
add: rangeLower
rangeLower: 84
-
dn: CN=Extension-Attribute-1,CN=Schema,CN=Configuration,DC=X
changetype: modify
ldapDisplayName: extensionAttribute1
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
changetype: modify
-
dn: CN=Common-Name,CN=Schema,CN=Configuration,DC=X
changetype: modify
attributeSecurityGuid:: VAGN5Pi80RGHAgDAT7lgUA==
-
dn: CN=E-mail-Addresses,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Manager,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Description,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Display-Name,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Attribute-Certificate,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Comment,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Proxied-Object-Name,CN=Schema,CN=Configuration,DC=X
changetype: modify
add: systemFlags
systemFlags: 2
-
dn: CN=Trust-Partner,CN=Schema,CN=Configuration,DC=X
changetype: modify
searchFlags: 1
-
dn: CN=User-Cert,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=User-SMIME-Certificate,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
-
dn: CN=Department,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
dn: CN=Company,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Alternate-Security-Identities,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Division,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Display-Name-Printable,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
dn: CN=Reports,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=Flat-Name,CN=Schema,CN=Configuration,DC=X
changetype: modify
searchFlags: 1
-
changetype: modify
-
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
dn: CN=Application-Entity,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
changetype: modify
-
dn: CN=Mailbox,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
changetype: modify
-
changetype: modify
-
-
changetype: modify
-
changetype: modify
-
changetype: modify
-
dn: CN=Remote-Address,CN=Schema,CN=Configuration,DC=X
changetype: modify
-
dn: CN=When-Created,CN=Schema,CN=Configuration,DC=X
changetype: modify
replace: omSyntax
omSyntax: 24
-
dn: CN=When-Changed,CN=Schema,CN=Configuration,DC=X
changetype: modify
replace: omSyntax
omSyntax: 24
-
dn: CN=Schema-Update,CN=Schema,CN=Configuration,DC=X
changetype: modify
replace: omSyntax
omSyntax: 24
-
dn: CN=Schema-Update-Now,CN=Schema,CN=Configuration,DC=X
changetype: modify
replace: omSyntax
omSyntax: 24
-
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=Aggregate,CN=Schema,CN=Configuration,DC=X
changetype: add
objectClass: subschema
dn: CN=User-Change-Password,CN=Extended-Rights,CN=Configuration,DC=X
changetype: modify
add: appliesTo
-
displayName: Change Password
-
changetype: modify
add: appliesTo
-
changetype: modify
add: appliesTo
-
changetype: modify
add: appliesTo
appliesTo: bf967a9c-0de6-11d0-a285-00aa003049e2
-
changetype: modify
add: appliesTo
appliesTo: 5cb41ed0-0e4c-11d0-a286-00aa003049e2
-
changetype: modify
add: appliesTo
appliesTo: 5cb41ed0-0e4c-11d0-a286-00aa003049e2
-
changetype: add
displayName: Public Information
rightsGUID: e48d0154-bcf8-11d1-8702-00c04fb96050
hideFromAB: TRUE
dn: CN=RRAS,CN=Services,CN=Configuration,DC=X
changetype: add
objectClass: container
hideFromAb: TRUE
dn: CN=Radius,CN=Services,CN=Configuration,DC=X
changetype: add
hideFromAb: TRUE
dn: CN=EAPEntries,CN=Services,CN=Configuration,DC=X
changetype: add
hideFromAb: TRUE
dn: CN=IdentityDictionary,CN=RRAS,CN=Services,CN=Configuration,DC=X
changetype: add
objectClass: rRASAdministrationDictionary
hideFromAb: TRUE
msRRASVendorAttributeEntry: 311:0:8:RIP (version 1 or 2)
msRRASVendorAttributeEntry: 311:0:13:OSPF
msRRASVendorAttributeEntry: 311:1:10:IGMP Only
msRRASVendorAttributeEntry: 311::5:1:IPX RIP
msRRASVendorAttributeEntry: 311:5:2:IPX SAP
msRRASVendorAttributeEntry: 311:6:501:IP Forwarding Enabled
msRRASVendorAttributeEntry: 311:6:502:IPX Forwarding Enabled
msRRASVendorAttributeEntry: 311:6:503:AppleTalk Forwarding Enabled
msRRASVendorAttributeEntry: 311:6:601:LAN-to- LAN Router
msRRASVendorAttributeEntry: 311:6:602:Remote Access Server
msRRASVendorAttributeEntry: 311:6:603:Demand Dial Router
msRRASVendorAttributeEntry: 311:6:604:Network Address and Port Translation
msRRASVendorAttributeEntry: 311:6:701:Point-to-Point Tunneling Protocol
msRRASVendorAttributeEntry: 311:6:702:Layer 2 Tunneling Protocol
msRRASVendorAttributeEntry: 311:6:703:Frame Relay
msRRASVendorAttributeEntry: 311:6:704:ATM
msRRASVendorAttributeEntry: 311:6:705:ISDN
msRRASVendorAttributeEntry: 311:6:706:Modem
msRRASVendorAttributeEntry: 311:6:707:SONET
msRRASVendorAttributeEntry: 311:6:708:Switched 56
msRRASVendorAttributeEntry: 311:6:709:IrDA
msRRASVendorAttributeEntry: 311:6:710:X.25
msRRASVendorAttributeEntry: 311:6:711:Generic WAN
msRRASVendorAttributeEntry: 311:6:711:Generic WAN
msRRASVendorAttributeEntry: 311:6:712:Generic LAN
msRRASVendorAttributeEntry: 311:6:713:Point to point serial connection
msRRASVendorAttributeEntry: 311:6:714:Point to point parallel connection
msRRASVendorAttributeEntry: 311:6:801:NT Domain Authentication
msRRASVendorAttributeEntry: 311:6:802:RADIUS Authentication
msRRASVendorAttributeEntry: 311:6:803:RADIUS Accouting
dn: CN=RadiusProfiles,CN=Radius,CN=Services,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
dn: CN=NetworkPolicy,CN=Radius,CN=Services,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
dn: CN=Dictionary,CN=Radius,CN=Services,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
dn: CN=Vendors,CN=Radius,CN=Services,CN=Configuration,DC=X
changetype: add
hideFromAB: TRUE
dn: CN=MD5 Challenge,CN=EAPEntries,CN=Services,CN=Configuration,DC=X

changetype: add
objectClass: EAP
msRADIUSEapTypeID: 4
msRADIUSEapKeyFlag: TRUE
hideFromAB: TRUE
dn: CN=Transport Layer Security,CN=EAPEntries,CN=Services,CN=Configuration,DC=X

changetype: add
objectClass: EAP
msRADIUSEapTypeID: 13
msRADIUSEapKeyFlag: TRUE
hideFromAB: TRUE

changetype: modify
delete: lDAPAdminLimits
-
add: lDAPAdminLimits
-
changetype: modify
objectVersion: 4
-
Sch5.ldf
Does not exist
Sch6.ldf
dn: CN=Hide-From-Address-Book,CN=Schema,CN=Configuration,DC=X
newrdn: Show-In-Advanced-View-Only
deleteoldrdn: 1
dn: CN=Show-In-Advanced-View-Only,CN=Schema,CN=Configuration,DC=X
adminDisplayName: Show-In-Advanced-View-Only
-
adminDescription: Show-In-Advanced-View-Only
-
ldapDisplayName: showInAdvancedViewOnly
-
dn: CN=Creation-Time,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: creationTime
-
dn:
schemaUpdateNow: 1
-
dn: CN=Create-Time-Stamp,CN=Schema,CN=Configuration,DC=X
lDAPDisplayName: createTimeStamp
adminDescription: Create-Time-Stamp
adminDisplayName: Create-Time-Stamp
attributeID: 2.5.18.1
oMSyntax: 24
systemOnly: TRUE
searchFlags: 0
schemaIDGUID:: cw35LZ8A0hGqTADAT9fYOg==
dn: CN=msCiscoAV,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msCiscoAV
adminDisplayName: msCiscoAV
adminDescription: msCiscoAV
attributeId: 1.2.840.113556.1.4.1230
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: eg35LZ8A0hGqTADAT9fYOg==
dn: CN=Parent-GUID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: parentGUID
adminDisplayName: Parent-GUID
adminDescription: Parent-GUID
attributeId: 1.2.840.113556.1.4.1224
omSyntax: 4
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: dA35LZ8A0hGqTADAT9fYOg==
dn: CN=msNPAction,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msNPAction
adminDisplayName: msNPAction
adminDescription: msNPAction
attributeId: 1.2.840.113556.1.4.1234
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fg35LZ8A0hGqTADAT9fYOg==
dn: CN=msRASFilter,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msRASFilter
adminDisplayName: msRASFilter
adminDescription: msRASFilter
attributeId: 1.2.840.113556.1.4.1229
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: eQ35LZ8A0hGqTADAT9fYOg==
dn: CN=MSMQ-Ds-Service,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: mSMQDsService
adminDisplayName: MSMQ-Ds-Service
adminDescription: MSMQ-Ds-Service
attributeId: 1.2.840.113556.1.4.1238
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gg35LZ8A0hGqTADAT9fYOg==
dn: CN=Netboot-SIF-File,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: netbootSIFFile
adminDisplayName: Netboot-SIF-File
adminDescription: Netboot-SIF-File
attributeId: 1.2.840.113556.1.4.1240
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: hA35LZ8A0hGqTADAT9fYOg==
dn: CN=MSMQ-Ds-Services,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: mSMQDsServices
adminDisplayName: MSMQ-Ds-Services
adminDescription: MSMQ-Ds-Services
attributeId: 1.2.840.113556.1.4.1228
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: eA35LZ8A0hGqTADAT9fYOg==
dn: CN=MSMQ-Queue-Name-Ext,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: mSMQQueueNameExt
adminDisplayName: MSMQ-Queue-Name-Ext
adminDescription: MSMQ-Queue-Name-Ext
attributeId: 1.2.840.113556.1.4.1243
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 92
schemaIdGuid:: hw35LZ8A0hGqTADAT9fYOg==
dn: CN=DN-Reference-Update,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: dNReferenceUpdate
adminDisplayName: DN-Reference-Update
adminDescription: DN-Reference-Update
attributeId: 1.2.840.113556.1.4.1242
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: hg35LZ8A0hGqTADAT9fYOg==
dn: CN=MSMQ-Prev-Site-Gates,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: mSMQPrevSiteGates
adminDisplayName: MSMQ-Prev-Site-Gates
adminDescription: MSMQ-Prev-Site-Gates
attributeId: 1.2.840.113556.1.4.1225
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: dQ35LZ8A0hGqTADAT9fYOg==
dn: CN=MSMQ-Routing-Service,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: mSMQRoutingService
ldapDisplayName: mSMQRoutingService
adminDisplayName: MSMQ-Routing-Service
adminDescription: MSMQ-Routing-Service
attributeId: 1.2.840.113556.1.4.1237
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gQ35LZ8A0hGqTADAT9fYOg==
dn: CN=MSMQ-Routing-Services,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: mSMQRoutingServices
adminDisplayName: MSMQ-Routing-Services
adminDescription: MSMQ-Routing-Services
attributeId: 1.2.840.113556.1.4.1227
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: dw35LZ8A0hGqTADAT9fYOg==
dn: CN=msRADIUSReplyMessage,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msRADIUSReplyMessage
adminDisplayName: msRADIUSReplyMessage
adminDescription: msRADIUSReplyMessage
attributeId: 1.2.840.113556.1.4.1235
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fw35LZ8A0hGqTADAT9fYOg==
dn: CN=Netboot-Mirror-Data-File,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: netbootMirrorDataFile
adminDisplayName: Netboot-Mirror-Data-File
adminDescription: Netboot-Mirror-Data-File
attributeId: 1.2.840.113556.1.4.1241
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: hQ35LZ8A0hGqTADAT9fYOg==
dn: CN=msNPOverrideUserDialin,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msNPOverrideUserDialin
adminDisplayName: msNPOverrideUserDialin
adminDescription: msNPOverrideUserDialin
attributeId: 1.2.840.113556.1.4.1233
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
searchFlags: 0
schemaIdGuid:: fQ35LZ8A0hGqTADAT9fYOg==
dn: CN=msNPAuthenticationType2,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msNPAuthenticationType2
adminDisplayName: msNPAuthenticationType2
adminDescription: msNPAuthenticationType2
attributeId: 1.2.840.113556.1.4.1236
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gA35LZ8A0hGqTADAT9fYOg==
dn: CN=MSMQ-Dependent-Client-Service,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: mSMQDependentClientService
adminDisplayName: MSMQ-Dependent-Client-Service
adminDescription: MSMQ-Dependent-Client-Service
attributeId: 1.2.840.113556.1.4.1239
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gw35LZ8A0hGqTADAT9fYOg==
dn: CN=msRADIUSRasServerGroupGUID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msRADIUSRasServerGroupGUID
adminDisplayName: msRADIUSRasServerGroupGUID
adminDescription: msRADIUSRasServerGroupGUID
attributeId: 1.2.840.113556.1.4.1231
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ew35LZ8A0hGqTADAT9fYOg==
dn: CN=MSMQ-Dependent-Client-Services,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: mSMQDependentClientServices
adminDisplayName: MSMQ-Dependent-Client-Services
adminDescription: MSMQ-Dependent-Client-Services
attributeId: 1.2.840.113556.1.4.1226
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: dg35LZ8A0hGqTADAT9fYOg==
dn: CN=msRADIUSRasServerSetupFlags,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msRADIUSRasServerSetupFlags
ldapDisplayName: msRADIUSRasServerSetupFlags
adminDisplayName: msRADIUSRasServerSetupFlags
adminDescription: msRADIUSRasServerSetupFlags
attributeId: 1.2.840.113556.1.4.1232
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fA35LZ8A0hGqTADAT9fYOg==
dn: CN=Address-Book-Roots,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: addressBookRoots
adminDisplayName: Address-Book-Roots
adminDescription: Address-Book-Roots
attributeId: 1.2.840.113556.1.4.1244
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: SG4L9/QG0hGqUwDAT9fYOg==
dn: CN=Global-Address-List,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: globalAddressList
adminDisplayName: Global-Address-List
adminDescription: Global-Address-List
attributeId: 1.2.840.113556.1.4.1245
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: SMdU9/QG0hGqUwDAT9fYOg==
dn: CN=Infrastructure-Update,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: infrastructureUpdate
adminDisplayName: Infrastructure-Update
adminDescription: Infrastructure-Update
governsId: 1.2.840.113556.1.5.175
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: iQ35LZ8A0hGqTADAT9fYOg==
systemOnly: TRUE
defaultObjectCategory: CN=Infrastructure-Update,CN=Schema,CN=Configuration,DC=X
dn: CN=msRADIUSConfigSettings,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msRADIUSConfigSettings
adminDisplayName: msRADIUSConfigSettings
adminDescription: msRADIUSConfigSettings
governsId: 1.2.840.113556.1.5.174
governsId: 1.2.840.113556.1.5.174
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: iA35LZ8A0hGqTADAT9fYOg==
systemOnly: FALSE
defaultObjectCategory: CN=msRADIUSConfigSettings,CN=Schema,CN=Configuration,DC=X
dn: CN=msExch-Configuration-Container,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msExchConfigurationContainer
adminDisplayName: msExch-Configuration-Container
adminDescription: msExch-Configuration-Container
governsId: 1.2.840.113556.1.5.176
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.23
schemaIdGuid:: WGg90PQG0hGqUwDAT9fYOg==
systemOnly: FALSE
defaultObjectCategory: CN=msExch-Configuration-Container,CN=Schema,CN=Configuration,DC=X
replace: rangeLower
rangeLower: 0
-
replace: attributeSecurityGUID
attributeSecurityGUID:: Qi+6WaJ50BGQIADAT8LTzw==
-
dn: CN=MSMQ-Site-Gates,CN=Schema,CN=Configuration,DC=X
add: oMObjectClass
-
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCRCWOWDSDSW;;;DA)(A;;RPWPCRCCDCLCRCWOWDSDSW;;;SY)
(A;;RPLCRC;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)S:(AU;SAFA;WDWOSDWPCRCCDCSW;;;WD)
-
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;CC;;;AU)(A;;RPLCLORC;;;WD)S:(AU;SAFA;WDWOSDDTWPCRCCDCSW;;;WD)
-
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;CO)(A;;RPLCLORC;;;WD)S:
(AU;SAFA;WDWOSDDTWPCRCCDCSW;;;WD)
-
defaultSecurityDescriptor: D:(A;;RP;;;WD)(OA;;RPWPCR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;ED)
(OA;;RPWPCR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;ED)(OA;;RPWPCR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;ED)
(OA;;RPWPCR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;BA)(OA;;RPWPCR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;BA)
(OA;;RPWPCR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;BA)(A;;RPLCRC;;;AU)(A;;RPWPCRLCLOCCRCWDWOSW;;;DA)
(A;CIOI;RPWPCRLCLOCCRCWDWOSDSW;;;BA)(A;;RPWPCRLCLOCCDCRCWDWOSDSW;;;SY)S:(AU;SAFA;WDWOSDWPCRCCDCSW;;;WD)
-
defaultSecurityDescriptor: D:(A;;RP;;;WD)(OA;;RPWPCR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;ED)
(OA;;RPWPCR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;ED)(OA;;RPWPCR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;ED)
(OA;;RPWPCR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;BA)(OA;;RPWPCR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;BA)
(OA;;RPWPCR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;BA)(A;;RPLCRC;;;AU)(A;;RPWPCRLCLOCCDCRCWDWOSW;;;DA)
(A;CIOI;RPWPCRLCLOCCRCWDWOSDSW;;;BA)(A;;RPWPCRLCLOCCDCRCWDWOSDSW;;;SY)S:(AU;SAFA;WDWOSDWPCRCCDCSW;;;WD)
-
-
dn: CN=RID-Set,CN=Schema,CN=configuration,DC=X
systemPossSuperiors: User
-
dn: CN=NTFRS-Subscriptions,CN=Schema,CN=configuration,DC=X
systemPossSuperiors: User
-
-
add: systemAuxiliaryClass
-
-
-
-
-
-
dn: CN=msRADIUSProfile,CN=Schema,CN=Configuration,DC=X
-
dn: CN=msNetworkPolicy,CN=Schema,CN=Configuration,DC=X
-
replace: mAPIID
mAPIID: 33036
-
replace: mAPIID
mAPIID: 14870
-
replace: mAPIID
mAPIID: 14856
-
replace: mAPIID
mAPIID: 35950
-
# Delete Owner's and owner-BL's mapiid before adding the same

# to Managed-By and Managed-Objects.
dn: CN=Owner,CN=Schema,CN=Configuration,DC=X
delete: mAPIID
-
dn: CN=Owner-BL,CN=Schema,CN=Configuration,DC=X
delete: mAPIID
delete: mAPIID
-
dn: CN=Managed-By,CN=Schema,CN=Configuration,DC=X
add: mAPIID
mAPIID: 32780
-
dn: CN=Managed-Objects,CN=Schema,CN=Configuration,DC=X
add: mAPIID
mAPIID: 32804
-
delete: mAPIID
-
delete: mAPIID
-
delete: mAPIID
-
delete: mAPIID
-
dn: CN=Presentation-Address,CN=Schema,CN=Configuration,DC=X
delete: mAPIID
-
dn: CN=Additional-Information,CN=Schema,CN=Configuration,DC=X
delete: mAPIID
-
dn: CN=Tagged-X509-Cert,CN=Schema,CN=Configuration,DC=X
delete: mAPIID
-
dn: CN=Show-In-Address-Book,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Legacy-Exchange-DN,CN=Schema,CN=Configuration,DC=X
-
attributeSecurityGUID:: +IhwA+EK0hG0IgCgyWj5OQ==
-
dn: CN=msNPCallingStationId,CN=Schema,CN=Configuration,DC=X
-
dn: CN=msNPConstraint,CN=Schema,CN=Configuration,DC=X
-
-
-
-
-
dn: CN=Obj-Dist-Name,CN=Schema,CN=Configuration,DC=X
attributeSecurityGUID:: VAGN5Pi80RGHAgDAT7lgUA==
-
dn: CN=Object-Guid,CN=Schema,CN=Configuration,DC=X
-
dn: CN=System-Flags,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Allowed-Attributes,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Allowed-Attributes-Effective,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Allowed-Child-Classes,CN=Schema,CN=Configuration,DC=X
-
-
dn: CN=Allowed-Child-Classes-Effective,CN=Schema,CN=Configuration,DC=X
-
dn: CN=COM-ClassID,CN=Schema,CN=Configuration,DC=X
delete: rangeLower
-
delete: rangeUpper
-
dn:
schemaUpdateNow: 1
-
# New Extended right add
dn: CN=Apply-Group-Policy,CN=Extended-Rights,CN=Configuration,DC=X
rightsGUID: edacfd8f-ffb3-11d1-b41d-00a0c968f939
displayName: Apply Group Policy
appliesTo: f30e3bc2-9ff0-11d1-b603-0000f80367c1
dn: CN=RAS-Information,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Remote Access Information
rightsGUID: 037088f8-0ae1-11d2-b422-00a0c968f939
# Modify exisiting Extended right
# Modrdns in config container require FLAG_CONFIG_ALLOW_RENAME

# For all such renames, we will set the flag, rename, and then
# delete the flag. Currently, none of the objects modified here
# has the flag set. The flag is 0x40000000, we set the decimal
dn: CN=msmq-Open-Conector,CN=Extended-Rights,CN=Configuration,DC=X
add: systemFlags
-
dn: CN=msmq-Open-Conector,CN=Extended-Rights,CN=Configuration,DC=X
newrdn: msmq-Open-Connector
deleteoldrdn: 1
dn: CN=msmq-Open-Connector,CN=Extended-Rights,CN=Configuration,DC=X
delete: systemFlags
-
# Display Specifier Changes
dn: CN=user-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
attributeDisplayNames: userFullName,User Full Name
-
-
attributeDisplayNames: displayName,Display Name
-
dn: CN=user-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
delete: adminContextMenu
-
adminContextMenu: 2,{8c5b1b50-d46e-11d1-8091-00a024c48131}
-
adminPropertyPages: 7,{8c5b1b50-d46e-11d1-8091-00a024c48131}
-
dn: CN=group-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=domainDNS-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=contact-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=domainPolicy-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=localPolicy-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=serviceAdministrationPoint-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=computer-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=printQueue-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=site-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
-
dn: CN=server-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=nTDSSettings-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=nTDSDSA-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=nTDSConnection-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=nTFRSSettings-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=nTFRSReplicaSet-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=subnet-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=siteLink-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=siteLinkBridge-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=interSiteTransport-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=licensingSiteSettings-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=nTDSSiteSettings-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=nTFRSMember-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=nTFRSSubscriber-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=nTFRSSubscriptions-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=organizationalUnit-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=container-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=rpcContainer-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=trustedDomain-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=volume-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=sitesContainer-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=interSiteTransportContainer-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=subnetContainer-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=serversContainer-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=nTDSService-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=queryPolicy-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=mSMQQueue-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
add: creationWizard
creationWizard: {E62F8206-B71C-11D1-808D-00A024C48131}
-
dn: CN=mSMQSiteLink-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
add: creationWizard
creationWizard: {87b31390-d46d-11d1-8091-00a024c48131}
-
dn: CN=remoteStorageServicePoint-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
replace: classDisplayName
classDisplayName: Remote Storage Service
-
adminContextMenu: 0,&Manage ...,RsAdmin.msc
-
adminContextMenu: 0,&Manage...,RsAdmin.msc
-
dn: CN=foreignSecurityPrincipal-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: Foreign Security Principal
dn: CN=Settings,CN=Radius,CN=Services,CN=Configuration,DC=X
# name change for well-known-security-principals
dn: CN=CreatorOwner,CN=WellKnown Security Principals,CN=Configuration,DC=X

add: systemFlags
-
-
dn: CN=CreatorOwner,CN=WellKnown Security Principals,CN=Configuration,DC=X

newrdn: Creator Owner
deleteoldrdn: 1
dn: CN=Creator Owner,CN=WellKnown Security Principals,CN=Configuration,DC=X

delete: systemFlags
-
dn: CN=CreatorGroup,CN=WellKnown Security Principals,CN=Configuration,DC=X

add: systemFlags
-
dn: CN=CreatorGroup,CN=WellKnown Security Principals,CN=Configuration,DC=X

newrdn: Creator Group
deleteoldrdn: 1
dn: CN=Creator Group,CN=WellKnown Security Principals,CN=Configuration,DC=X

delete: systemFlags
-
dn: CN=PrincipalSelf,CN=WellKnown Security Principals,CN=Configuration,DC=X

add: systemFlags
-
dn: CN=PrincipalSelf,CN=WellKnown Security Principals,CN=Configuration,DC=X

newrdn: Principal Self
deleteoldrdn: 1
dn: CN=Principal Self,CN=WellKnown Security Principals,CN=Configuration,DC=X

delete: systemFlags
-
dn: CN=AuthenticatedUser,CN=WellKnown Security Principals,CN=Configuration,DC=X

add: systemFlags
-
dn: CN=AuthenticatedUser,CN=WellKnown Security Principals,CN=Configuration,DC=X

newrdn: Authenticated User
deleteoldrdn: 1
dn: CN=Authenticated User,CN=WellKnown Security Principals,CN=Configuration,DC=X

delete: systemFlags
-
# Update schema version
changetype: modify
objectVersion: 6
-
Sch7.ldf
-
newrdn: Proxied-Object-Name-Unused
deleteoldrdn: 1
dn: CN=Proxied-Object-Name-Unused,CN=Schema,CN=Configuration,DC=X
adminDisplayName: Proxied-Object-Name-Unused
-
adminDescription: Proxied-Object-Name-Unused
-
ldapDisplayName: proxiedObjectNameUnused
-
replace: schemaIdGuid
schemaIdGuid:: X55550su0hG6vZjY/cfjDw==
-
ldapDisplayName: proxiedObjectName
adminDisplayName: Proxied-Object-Name
adminDescription: Proxied-Object-Name
attributeId: 1.2.840.113556.1.4.1249
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: AqSu4VvN0BGv/wAA+ANnwQ==
systemFlags: 2
replace: omObjectClass
omObjectClass:: KoZIhvcUAQEBCw==
-
dn: CN=Inter-Site-Topology-Renew,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: interSiteTopologyRenew
adminDisplayName: Inter-Site-Topology-Renew
adminDescription: Inter-Site-Topology-Renew
attributeId: 1.2.840.113556.1.4.1247
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: X57Gt8cs0hGFTgCgyYP2CA==
dn: CN=Inter-Site-Topology-Failover,CN=Schema,CN=Configuration,DC=X
dn: CN=Inter-Site-Topology-Failover,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: interSiteTopologyFailover
adminDisplayName: Inter-Site-Topology-Failover
adminDescription: Inter-Site-Topology-Failover
attributeId: 1.2.840.113556.1.4.1248
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: YJ7Gt8cs0hGFTgCgyYP2CA==
dn: CN=Inter-Site-Topology-Generator,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: interSiteTopologyGenerator
adminDisplayName: Inter-Site-Topology-Generator
adminDescription: Inter-Site-Topology-Generator
attributeId: 1.2.840.113556.1.4.1246
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Xp7Gt8cs0hGFTgCgyYP2CA==
dn: CN=Token-Groups,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: tokenGroups
adminDisplayName: Token-Groups
adminDescription: Token-Groups
attributeId: 1.2.840.113556.1.4.1301
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: bZ7Gt8cs0hGFTgCgyYP2CA==
attributeSecurityGuid:: ksMPBN8z0hGYsgAA+HpX1A==
dn: CN=Token-Groups-No-GC-Acceptable,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: tokenGroupsNoGCAcceptable
adminDisplayName: Token-Groups-No-GC-Acceptable
adminDescription: Token-Groups-No-GC-Acceptable
attributeId: 1.2.840.113556.1.4.1303
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ksMPBN8z0hGYsgAA+HpX1A==
attributeSecurityGuid:: ksMPBN8z0hGYsgAA+HpX1A==
dn: CN=SD-Rights-Effective,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: sDRightsEffective
adminDisplayName: SD-Rights-Effective
adminDisplayName: SD-Rights-Effective
adminDescription: SD-Rights-Effective
attributeId: 1.2.840.113556.1.4.1304
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: pq/bw98z0hGYsgAA+HpX1A==
dn: CN=Parent-GUID,CN=Schema,CN=Configuration,DC=X
-
dn: CN=DN-Reference-Update,CN=Schema,CN=Configuration,DC=X
searchFlags: 8
-
dn: CN=Sub-Class-Of,CN=Schema,CN=Configuration,DC=X
searchFlags: 8
-
searchFlags: 8
-
dn: CN=Instance-Type,CN=Schema,CN=Configuration,DC=X
searchFlags: 8
-
dn: CN=RDN,CN=Schema,CN=Configuration,DC=X
searchFlags: 9
-
searchFlags: 9
-
dn: CN=Repl-Property-Meta-Data,CN=Schema,CN=Configuration,DC=X
searchFlags: 8
-
dn: CN=User-Account-Control,CN=Schema,CN=Configuration,DC=X
searchFlags: 9
-
dn: CN=NC-Name,CN=Schema,CN=Configuration,DC=X
searchFlags: 8
searchFlags: 8
-
dn: CN=USN-Created,CN=Schema,CN=Configuration,DC=X
searchFlags: 9
-
dn: CN=Governs-ID,CN=Schema,CN=Configuration,DC=X
searchFlags: 8
-
dn: CN=Attribute-ID,CN=Schema,CN=Configuration,DC=X
searchFlags: 8
-
dn: CN=Attribute-Syntax,CN=Schema,CN=Configuration,DC=X
searchFlags: 8
-
searchFlags: 8
-
dn: CN=USN-Changed,CN=Schema,CN=Configuration,DC=X
searchFlags: 9
-
searchFlags: 13
-
dn: CN=Object-Sid,CN=Schema,CN=Configuration,DC=X
searchFlags: 9
-
dn: CN=SAM-Account-Name,CN=Schema,CN=Configuration,DC=X
searchFlags: 13
-
dn: CN=OM-Syntax,CN=Schema,CN=Configuration,DC=X
searchFlags: 8
-
searchFlags: 9
-
dn: CN=NT-Security-Descriptor,CN=Schema,CN=Configuration,DC=X
searchFlags: 8
-
dn: CN=System-Flags,CN=Schema,CN=Configuration,DC=X
searchFlags: 8
-
dn: CN=MSMQ-Owner-ID,CN=Schema,CN=Configuration,DC=X
searchFlags: 9
-
dn: CN=LDAP-Display-Name,CN=Schema,CN=Configuration,DC=X
searchFlags: 9
-
-
-
dn: CN=DHCP-Class,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Sam-Server,CN=Schema,CN=Configuration,DC=X
-
-
-
-
-
dn: CN=DMD,CN=Schema,CN=Configuration,DC=X
-
-
dn: CN=Cross-Ref,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Configuration,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Connection-Point,CN=Schema,CN=Configuration,DC=X
-
-
-
dn: CN=Domain-Policy,CN=Schema,CN=Configuration,DC=X
-
-
-
-
-
-
-
-
-
dn: CN=Application-Settings,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Application-Site-Settings,CN=Schema,CN=Configuration,DC=X
-
-
-
dn: CN=Foreign-Security-Principal,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Control-Access-Right,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Assoc-Remote-DXA,CN=Schema,CN=Configuration,DC=X
replace: LinkID
LinkID: 123
-
dn: CN=NNTP-Newsfeeds,CN=Schema,CN=Configuration,DC=X
replace: LinkID
LinkID: 141
-
dn: CN=Supporting-Stack-BL,CN=Schema,CN=Configuration,DC=X
replace: LinkID
LinkID: 133
-
dn:
schemaUpdateNow: 1
-
# name change for MSMQ objects
dn: CN=msmq-Peak-Dead-Letter,CN=Extended-Rights,CN=Configuration,DC=X
add: systemFlags
-
dn: CN=msmq-Peak-Dead-Letter,CN=Extended-Rights,CN=Configuration,DC=X
newrdn: msmq-Peek-Dead-Letter
deleteoldrdn: 1
dn: CN=msmq-Peek-Dead-Letter,CN=Extended-Rights,CN=Configuration,DC=X
delete: systemFlags
-
dn: CN=msmq-Receive-machine-Journal,CN=Extended-Rights,CN=Configuration,DC=X
add: systemFlags
-
dn: CN=msmq-Receive-machine-Journal,CN=Extended-Rights,CN=Configuration,DC=X
newrdn: msmq-Receive-computer-Journal
deleteoldrdn: 1
dn: CN=msmq-Receive-computer-Journal,CN=Extended-Rights,CN=Configuration,DC=X
delete: systemFlags
-
dn: CN=msmq-Peak-machine-Journal,CN=Extended-Rights,CN=Configuration,DC=X
add: systemFlags
-
dn: CN=msmq-Peak-machine-Journal,CN=Extended-Rights,CN=Configuration,DC=X
newrdn: msmq-Peek-computer-Journal
deleteoldrdn: 1
dn: CN=msmq-Peek-computer-Journal,CN=Extended-Rights,CN=Configuration,DC=X
delete: systemFlags
-
dn: CN=msmq-Peak,CN=Extended-Rights,CN=Configuration,DC=X
add: systemFlags
-
dn: CN=msmq-Peak,CN=Extended-Rights,CN=Configuration,DC=X
newrdn: msmq-Peek
deleteoldrdn: 1
dn: CN=msmq-Peek,CN=Extended-Rights,CN=Configuration,DC=X
delete: systemFlags
-
displayName: Peek Dead Letter
-
displayName: Receive Computer Journal
-
displayName: Peek Computer Journal
-
displayName: Peek Message
-
dn: CN=mSMQQueue-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: MSMQ Queue
-
add: treatAsLeaf
treatAsLeaf: TRUE
-
-
dn: CN=mSMQConfiguration-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: MSMQ Configuration
-
dn: CN=mSMQEnterpriseSettings-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: MSMQ Enterprise
-
dn: CN=mSMQSiteLink-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: MSMQ Site Link
-
objectVersion: 7
-
Sch8.ldf
dn: CN=Print-Duplex-Supported,CN=Schema,CN=Configuration,DC=X
newrdn: Print-Duplex-Supported-Unused
deleteoldrdn: 1
dn: CN=Print-Duplex-Supported-Unused,CN=Schema,CN=Configuration,DC=X
adminDisplayName: Print-Duplex-Supported-Unused
-
adminDescription: Print-Duplex-Supported-Unused
-
ldapDisplayName: printDuplexSupportedUnused
-
replace: schemaIdGuid
schemaIdGuid:: AsPDrFY80hGf8LYGeY0bDw==
-
dn: CN=Assoc-NT-Account-Unused,CN=Schema,CN=Configuration,DC=X
newrdn: DS-Heuristics
deleteoldrdn: 1
dn: CN=DS-Heuristics,CN=Schema,CN=Configuration,DC=X
adminDisplayName: DS-Heuristics
-
adminDescription: DS-Heuristics
-
ldapDisplayName: dSHeuristics
-
delete: mapiID
-
dn: cn=print-duplex-supported,cn=schema,cn=configuration,DC=X
lDAPDisplayName: printDuplexSupported
adminDescription: Print-Duplex-Supported
adminDisplayName: Print-Duplex-Supported
attributeID: 1.2.840.113556.1.4.1311
oMSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: zBYUKGgZ0BGijwCqADBJ4g==
dn: CN=Move-Tree-State,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: moveTreeState
adminDisplayName: Move-Tree-State
adminDescription: Move-Tree-State
attributeId: 1.2.840.113556.1.4.1305
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: yMIqH3E70hGQzADAT9kasQ==
dn: CN=PKI-Key-Usage,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: pKIKeyUsage
adminDisplayName: PKI-Key-Usage
adminDescription: PKI-Key-Usage
attributeId: 1.2.840.113556.1.4.1328
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fqiw6Z070hGQzADAT9kasQ==
dn: CN=DNS-Property,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: dNSProperty
adminDisplayName: DNS-Property
adminDescription: DNS-Property
attributeId: 1.2.840.113556.1.4.1306
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: /hVaZ3A70hGQzADAT9kasQ==
dn: CN=DS-Heuristics,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: dSHeuristics
adminDisplayName: DS-Heuristics
attributeId: 1.2.840.113556.1.2.212
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: hv/48JER0BGgYACqAGwz7Q==
dn: CN=MSMQ-Interval1,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: mSMQInterval1
adminDisplayName: MSMQ-Interval1
adminDescription: MSMQ-Interval1
attributeId: 1.2.840.113556.1.4.1308
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: qiWojns70hGQzADAT9kasQ==
dn: CN=MSMQ-Interval2,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: mSMQInterval2
adminDisplayName: MSMQ-Interval2
adminDescription: MSMQ-Interval2
attributeId: 1.2.840.113556.1.4.1309
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Uo+4mXs70hGQzADAT9kasQ==
dn: CN=ACS-Server-List,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: aCSServerList
adminDisplayName: ACS-Server-List
adminDescription: ACS-Server-List
attributeId: 1.2.840.113556.1.4.1312
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: pVm9fJA70hGQzADAT9kasQ==
dn: CN=PKI-Default-CSPs,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: pKIDefaultCSPs
adminDisplayName: PKI-Default-CSPs
adminDescription: PKI-Default-CSPs
attributeId: 1.2.840.113556.1.4.1334
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: bjP2Hp470hGQzADAT9kasQ==
dn: CN=MSMQ-Site-Gates-Mig,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: mSMQSiteGatesMig
adminDisplayName: MSMQ-Site-Gates-Mig
adminDescription: MSMQ-Site-Gates-Mig
attributeId: 1.2.840.113556.1.4.1310
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Ukhw4ns70hGQzADAT9kasQ==
dn: CN=PKI-Overlap-Period,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: pKIOverlapPeriod
adminDisplayName: PKI-Overlap-Period
adminDescription: PKI-Overlap-Period
attributeId: 1.2.840.113556.1.4.1332
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 7KMZEp470hGQzADAT9kasQ==
dn: CN=PKI-Default-Key-Spec,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: pKIDefaultKeySpec
adminDisplayName: PKI-Default-Key-Spec
adminDescription: PKI-Default-Key-Spec
attributeId: 1.2.840.113556.1.4.1327
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: bq5sQp070hGQzADAT9kasQ==
dn: CN=ACS-Minimum-Latency,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: aCSMinimumLatency
adminDisplayName: ACS-Minimum-Latency
adminDescription: ACS-Minimum-Latency
attributeId: 1.2.840.113556.1.4.1316
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: +/4XlZA70hGQzADAT9kasQ==
dn: CN=ACS-Maximum-SDU-Size,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: aCSMaximumSDUSize
adminDisplayName: ACS-Maximum-SDU-Size
adminDisplayName: ACS-Maximum-SDU-Size
adminDescription: ACS-Maximum-SDU-Size
attributeId: 1.2.840.113556.1.4.1314
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: +diih5A70hGQzADAT9kasQ==
dn: CN=Account-Name-History,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: accountNameHistory
adminDisplayName: Account-Name-History
adminDescription: Account-Name-History
attributeId: 1.2.840.113556.1.4.1307
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 7FIZA3I70hGQzADAT9kasQ==
dn: CN=PKI-Max-Issuing-Depth,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: pKIMaxIssuingDepth
adminDisplayName: PKI-Max-Issuing-Depth
adminDescription: PKI-Max-Issuing-Depth
attributeId: 1.2.840.113556.1.4.1329
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: +t6/8J070hGQzADAT9kasQ==
dn: CN=PKI-Extended-Key-Usage,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: pKIExtendedKeyUsage
adminDisplayName: PKI-Extended-Key-Usage
adminDescription: PKI-Extended-Key-Usage
attributeId: 1.2.840.113556.1.4.1333
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 9mqXGJ470hGQzADAT9kasQ==
dn: CN=PKI-Expiration-Period,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: pKIExpirationPeriod
adminDisplayName: PKI-Expiration-Period
adminDescription: PKI-Expiration-Period
attributeId: 1.2.840.113556.1.4.1331
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 0nAVBJ470hGQzADAT9kasQ==
dn: CN=ACS-Minimum-Policed-Size,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: aCSMinimumPolicedSize
adminDisplayName: ACS-Minimum-Policed-Size
adminDescription: ACS-Minimum-Policed-Size
attributeId: 1.2.840.113556.1.4.1315
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: lXEOjZA70hGQzADAT9kasQ==
dn: CN=PKI-Critical-Extensions,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: pKICriticalExtensions
adminDisplayName: PKI-Critical-Extensions
adminDescription: PKI-Critical-Extensions
attributeId: 1.2.840.113556.1.4.1330
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: BpFa/J070hGQzADAT9kasQ==
dn: CN=ACS-Non-Reserved-Peak-Rate,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: aCSNonReservedPeakRate
adminDisplayName: ACS-Non-Reserved-Peak-Rate
adminDescription: ACS-Non-Reserved-Peak-Rate
attributeId: 1.2.840.113556.1.4.1318
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: P6cxo5A70hGQzADAT9kasQ==
dn: CN=ACS-Non-Reserved-Token-Size,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: aCSNonReservedTokenSize
adminDisplayName: ACS-Non-Reserved-Token-Size
adminDescription: ACS-Non-Reserved-Token-Size
attributeId: 1.2.840.113556.1.4.1319
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ydcWqZA70hGQzADAT9kasQ==
dn: CN=ACS-Minimum-Delay-Variation,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: aCSMinimumDelayVariation
adminDisplayName: ACS-Minimum-Delay-Variation
adminDescription: ACS-Minimum-Delay-Variation
attributeId: 1.2.840.113556.1.4.1317
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: mzJlnJA70hGQzADAT9kasQ==
dn: CN=ACS-Max-Token-Bucket-Per-Flow,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: aCSMaxTokenBucketPerFlow
adminDisplayName: ACS-Max-Token-Bucket-Per-Flow
adminDescription: ACS-Max-Token-Bucket-Per-Flow
attributeId: 1.2.840.113556.1.4.1313
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 3+D2gZA70hGQzADAT9kasQ==
dn: CN=ACS-Non-Reserved-Max-SDU-Size,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: aCSNonReservedMaxSDUSize
adminDisplayName: ACS-Non-Reserved-Max-SDU-Size
adminDescription: ACS-Non-Reserved-Max-SDU-Size
attributeId: 1.2.840.113556.1.4.1320
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 48/CrpA70hGQzADAT9kasQ==
dn: CN=ACS-Non-Reserved-Min-Policed-Size,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: aCSNonReservedMinPolicedSize
adminDisplayName: ACS-Non-Reserved-Min-Policed-Size
adminDescription: ACS-Non-Reserved-Min-Policed-Size
attributeId: 1.2.840.113556.1.4.1321
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: FzmHtpA70hGQzADAT9kasQ==
dn: CN=MSMQ-User-Sid,CN=Schema,CN=Configuration,DC=arobindg15,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mSMQUserSid
adminDisplayName: MSMQ-User-Sid
adminDescription: MSMQ-User-Sid
attributeId: 1.2.840.113556.1.4.1337
omSyntax: 4
systemOnly: TRUE
searchFlags: 0
searchFlags: 0
rangeLower: 0
rangeUpper: 128
schemaIdGuid:: Mq6KxflW0hGQ0ADAT9kasQ==
dn: CN=Repl-Interval,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: replInterval
adminDisplayName: Repl-Interval
adminDescription: Repl-Interval
attributeId: 1.2.840.113556.1.4.1336
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Gp26RfpW0hGQ0ADAT9kasQ==
dn: CN=PKI-Enrollment-Access,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: pKIEnrollmentAccess
adminDisplayName: PKI-Enrollment-Access
adminDescription: PKI-Enrollment-Access
attributeId: 1.2.840.113556.1.4.1335
omSyntax: 66
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: eOJrkvlW0hGQ0ADAT9kasQ==
dn: CN=SPN-Mappings,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: sPNMappings
adminDisplayName: SPN-Mappings
adminDescription: SPN-Mappings
attributeId: 1.2.840.113556.1.4.1347
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: bOewKkFw0hGZBQAA+HpX1A==
systemFlags: 16
dn: CN=Template-Roots,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: templateRoots
adminDisplayName: Template-Roots
adminDescription: Template-Roots
attributeId: 1.2.840.113556.1.4.1346
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: oOmd7UFw0hGZBQAA+HpX1A==
systemFlags: 16
systemFlags: 16
dn: CN=DS-UI-Admin-Maximum,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: dSUIAdminMaximum
adminDisplayName: DS-UI-Admin-Maximum
adminDescription: DS-UI-Admin-Maximum
attributeId: 1.2.840.113556.1.4.1344
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 4AqN7pFv0hGZBQAA+HpX1A==
systemFlags: 16
dn: CN=DS-UI-Shell-Maximum,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: dSUIShellMaximum
adminDisplayName: DS-UI-Shell-Maximum
adminDescription: DS-UI-Shell-Maximum
attributeId: 1.2.840.113556.1.4.1345
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: anbK/JFv0hGZBQAA+HpX1A==
systemFlags: 16
dn: CN=DS-UI-Admin-Notification,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: dSUIAdminNotification
adminDisplayName: DS-UI-Admin-Notification
adminDescription: DS-UI-Admin-Notification
attributeId: 1.2.840.113556.1.4.1343
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: lArq9pFv0hGZBQAA+HpX1A==
systemFlags: 16
dn: CN=Localization-Display-Id,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: localizationDisplayId
adminDisplayName: Localization-Display-Id
adminDescription: Localization-Display-Id
attributeId: 1.2.840.113556.1.4.1353
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 0fBGp9B40hGZFgAA+HpX1A==
systemFlags: 16
dn: CN=GPC-User-Extension-Names,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: gPCUserExtensionNames
adminDisplayName: GPC-User-Extension-Names
adminDescription: GPC-User-Extension-Names
attributeId: 1.2.840.113556.1.4.1349
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: xl+nQj940hGZFgAA+HpX1A==
systemFlags: 16
dn: CN=GPC-Machine-Extension-Names,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: gPCMachineExtensionNames
adminDisplayName: GPC-Machine-Extension-Names
adminDescription: GPC-Machine-Extension-Names
attributeId: 1.2.840.113556.1.4.1348
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: zI7/Mj940hGZFgAA+HpX1A==
systemFlags: 16
dn: CN=Scope-Flags,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: scopeFlags
adminDisplayName: Scope-Flags
adminDescription: Scope-Flags
attributeId: 1.2.840.113556.1.4.1354
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: wqTzFnl+0hGZIQAA+HpX1A==
systemFlags: 16
dn: CN=Query-Filter,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: queryFilter
adminDisplayName: Query-Filter
adminDescription: Query-Filter
attributeId: 1.2.840.113556.1.4.1355
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Jgr3y3h+0hGZIQAA+HpX1A==
systemFlags: 16
dn: CN=Valid-Accesses,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: validAccesses
adminDisplayName: Valid-Accesses
adminDescription: Valid-Accesses
attributeId: 1.2.840.113556.1.4.1356
attributeId: 1.2.840.113556.1.4.1356
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gKMvTVR/0hGZKgAA+HpX1A==
systemFlags: 16
dn: CN=DS-Core-Propagation-Data,CN=Schema,CN=Configuration,DC=X
lDAPDisplayName: dSCorePropagationData
adminDescription: DS-Core-Propagation-Data
adminDisplayName: DS-Core-Propagation-Data
attributeID: 1.2.840.113556.1.4.1357
oMSyntax: 24
systemOnly: TRUE
searchFlags: 0
schemaIDGUID:: S6pn0QiL0hGZOQAA+HpX1A==
systemFlags: 17
dn: CN=Schema-Info,CN=schema,CN=configuration,DC=X
lDAPDisplayName: schemaInfo
adminDescription: Schema-Info
adminDisplayName: Schema-Info
attributeID: 1.2.840.113556.1.4.1358
oMSyntax: 4
systemOnly: TRUE
searchFlags: 0
schemaIDGUID:: rmT7+bST0hGZRQAA+HpX1A==
systemFlags: 16
dn: CN=DS-UI-Settings,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: dSUISettings
adminDisplayName: DS-UI-Settings
adminDescription: DS-UI-Settings
governsId: 1.2.840.113556.1.5.183
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: FA+xCZNv0hGZBQAA+HpX1A==
systemOnly: FALSE
defaultObjectCategory: CN=DS-UI-Settings,CN=Schema,CN=Configuration,DC=X
dn: CN=PKI-Enrollment-Service,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: pKIEnrollmentService
adminDisplayName: PKI-Enrollment-Service
adminDisplayName: PKI-Enrollment-Service
adminDescription: PKI-Enrollment-Service
governsId: 1.2.840.113556.1.5.178
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: kqZK7ro70hGQzADAT9kasQ==
systemOnly: FALSE
defaultObjectCategory: CN=PKI-Enrollment-Service,CN=Schema,CN=Configuration,DC=X
dn: CN=PKI-Certificate-Template,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: pKICertificateTemplate
adminDisplayName: PKI-Certificate-Template
adminDescription: PKI-Certificate-Template
governsId: 1.2.840.113556.1.5.177
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: opwg5bo70hGQzADAT9kasQ==
systemOnly: FALSE
defaultObjectCategory: CN=PKI-Certificate-Template,CN=Schema,CN=Configuration,DC=X
dn: CN=MSMQ-Migrated-User,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: mSMQMigratedUser
adminDisplayName: MSMQ-Migrated-User
adminDescription: MSMQ-Migrated-User
governsId: 1.2.840.113556.1.5.179
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: l2l3UD080hGQzADAT9kasQ==
systemOnly: FALSE
defaultObjectCategory: CN=MSMQ-Migrated-User,CN=Schema,CN=Configuration,DC=X
-
-
-
-
dn: CN=NTDS-Service,CN=Schema,CN=Configuration,DC=X
-
-
-
dn: CN=Inter-Site-Transport,CN=Schema,CN=Configuration,DC=arobindg15,DC=nttest,DC=microsoft,DC=com
-
dn: CN=Site-Link,CN=Schema,CN=Configuration,DC=arobindg15,DC=nttest,DC=microsoft,DC=com
-
dn: CN=PKI-Certificate-Template,CN=Schema,CN=Configuration,DC=arobindg15,DC=nttest,DC=microsoft,DC=com
-
dn: CN=MSMQ-Migrated-User,CN=Schema,CN=Configuration,DC=arobindg15,DC=nttest,DC=microsoft,DC=com
-
-
-
-
dn: CN=E-Mail-Addresses,CN=Schema,CN=Configuration,DC=X
add: mapiID
mapiID: 14846
-
add: mapiID
mapiID: 32807
-
delete: mapiID
-
add: mapiID
mapiID: 32807
-
dn: CN=Keywords,CN=Schema,CN=Configuration,DC=X
searchFlags: 1
-
add: isMemberOfPartialAttributeSet
-
dn: CN=Netboot-Machine-File-Path,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Netboot-GUID,CN=Schema,CN=Configuration,DC=X
-
dn: CN=MSMQ-Digests-Mig,CN=Schema,CN=Configuration,DC=X
-
dn: CN=MSMQ-Sign-Certificates-Mig,CN=Schema,CN=Configuration,DC=X
-
-
dn: CN=Manager,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Service-Binding-Information,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Global-Address-List,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Site-Server,CN=Schema,CN=Configuration,DC=X
-
-
-
-
-
dn: CN=Lost-And-Found,CN=Schema,CN=Configuration,DC=X
replace: systemOnly
systemOnly: FALSE
-
dn: CN=Lost-And-Found,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Mailbox,CN=Schema,CN=Configuration,DC=X
-
-
-
-
-
-
-
-
dn: CN=MSMQ-Site-Link,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Remote-Address,CN=Schema,CN=Configuration,DC=X
-
-
-
-
-
dn: CN=Subnet,CN=Schema,CN=Configuration,DC=X
-
dn: CN=rpc-Group,CN=Schema,CN=Configuration,DC=X
-
-
dn: CN=rpc-Profile-Element,CN=Schema,CN=Configuration,DC=X
-
-
ldapDisplayName: company
-
dn: CN=Text-Country,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: co
-
-
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)(A;;RPLCLORC;;;PS)(OA;;RPWPCR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)
(OA;;RPWPCR;ab721a54-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;RPWPCR;ab721a56-1e2f-11d0-9819-00aa0040529b;;PS)
(OA;;RPWPCR;77B5B886-944A-11d1-AEBD-0000F80367C1;;PS)(OA;;RPWPCR;E45795B2-9455-11d1-AEBD-0000F80367C1;;PS)
(OA;;RPWPCR;E45795B3-9455-11d1-AEBD-0000F80367C1;;PS)(OA;;RP;037088f8-0ae1-11d2-b422-00a0c968f939;;RS)
(OA;;RP;4c164200-20c0-11d0-a768-00aa006e0529;;RS)(OA;;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;;RS)
(A;;RC;;;AU)(OA;;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;;AU)(OA;;RP;77B5B886-944A-11d1-AEBD-
0000F80367C1;;AU)(OA;;RP;E45795B3-9455-11d1-AEBD-0000F80367C1;;AU)(OA;;RP;e48d0154-bcf8-11d1-8702-
00c04fb96050;;AU)(OA;;RPWPCR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;;RP;5f202010-79a5-11d0-9020-
00c04fc2d4cf;;RS)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)
-
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;CO)(A;;RPLCLORC;;;AU)(OA;;RPWPCR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)
(OA;;CCDC;;;PS)(OA;;CCDC;bf967aa8-0de6-11d0-a285-00aa003049e2;;PO)(OA;;RPWP;bf967a7f-0de6-11d0-a285-
00aa003049e2;;CA)
-
defaultSecurityDescriptor: D:P(A;;RPWPCCDCLCLOLORCWOWDSDDTSW;;;DA)(A;CIOI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;EA)
(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)
-
dn: CN=X509-Cert,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Country,CN=Schema,CN=Configuration,DC=X
-
-
-
-
dn:
schemaUpdateNow: 1
-
# Config NC changes
dn: CN=nTDSSettings-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: Settings
-
dn: CN=nTDSDSA-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: Domain Controller Settings
-
dn: CN=nTDSConnection-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: Connection
-
classDisplayName: FRS Settings
-
classDisplayName: FRS Replica Set
-
dn: CN=nTDSSiteSettings-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: Site Settings
-
dn: CN=nTFRSMember-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: FRS Member
-
dn: CN=nTFRSSubscriber-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: FRS Subscriber
-
dn: CN=nTFRSSubscriptions-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: FRS Subscriptions
-
dn: CN=nTDSService-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=mSMQSiteLink-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: MSMQ Routing Link
-
adminPropertyPages: 7,{8c5b1b50-d46e-11d1-8091-00a024c48131}
-
attributeDisplayNames: whenCreated,Date Published
-
dn: CN=MsmqServices,CN=Services,CN=Configuration,DC=X
objectClass: mSMQEnterpriseSettings
mSmQVersion: 200
dn: CN=DS-Install-Replica,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Add/Remove Replica In Domain
rightsGUID: 9923a32a-3607-11d2-b9be-0000f87a36b2
dn: CN=Change-Infrastructure-Master,CN=Extended-Rights,CN=Configuration,DC=X
appliesTo: 2df90d89-009f-11d2-aa4c-00c04fd7d83a
displayName: Change Infrastructure Master
rightsGUID: cc17b1fb-33d9-11d2-97d4-00c04fd8d5cd
dn: CN=sitesContainer-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=interSiteTransportContainer-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=interSiteTransport-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
adminPropertyPages: 1,{6DFE6491-AC8D-11D0-B945-00C04FD8D5B0}
-
dn: CN=subnetContainer-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=serversContainer-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=nTDSService-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=queryPolicy-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
attributeDisplayNames: countryCode,Country Code
-
attributeDisplayNames: samAccountName,Downlevel Logon Name
-
-
-
-
-
-
-
-
adminPropertyPages: 3,{77597368-7b15-11d0-a0c2-080036af3f03}
adminPropertyPages: 10,{0F65B1BF-740F-11d1-BBE6-0060081692B3}
-
add: createWizardExt
createWizardExt: 1,{D6D8C25A-4E83-11d2-8424-00C04FA372D4}
-
-
adminPropertyPages: 1,{717EF4FA-AC8D-11D0-B945-00C04FD8D5B0}
adminPropertyPages: 5,{bc019ba0-d46d-11d1-8091-00a024c48131}
-
-
-
-
attributeDisplayNames: keywords,Keywords
-
dn: CN=pKICertificateTemplate-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
adminPropertyPages: 1,{9bff616c-3e02-11d2-a4ca-00c04fb93209}
adminPropertyPages: 3,{4e40f770-369c-11d0-8922-00a024ab2dbb}
shellPropertyPages: 1,{9bff616c-3e02-11d2-a4ca-00c04fb93209}
contextMenu: 0,{9bff616c-3e02-11d2-a4ca-00c04fb93209}
adminContextMenu: 0,{9bff616c-3e02-11d2-a4ca-00c04fb93209}
classDisplayName: Certificate Template
iconPath: 0,capesnpn.dll,-227
dn: CN=DS-UI-Default-Settings,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
objectClass: dSUISettings
displayName: Modify Remote Access Information
-
dn: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=X

add: sPNMappings
spnMappings:
host=alerter,appmgmt,cisvc,clipsrv,browser,dhcp,dnscache,replicator,eventlog,eventsystem,policyagent,oakley,
dmserver,ldp,ldap,dns,mcsvc,fax,msiserver,ias,messenger,netlogon,netman,netdde,netddedsm,nmagent,plugplay,pr
otectedstorage,rasman,rpclocator,rpc,rpcss,remoteaccess,rsvp,samss,scardsvr,scesrv,seclogon,scm,dcom,cifs,sp
ooler,snmp,schedule,tapisrv,trksvr,trkwks,ups,time,wins,www,http,w3svc,iisadmin
-
-
-
-
-
-
-
-
dn: CN=mSMQQueue-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=mSMQConfiguration-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
dn: CN=mSMQEnterpriseSettings-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
-
dn: CN=mSMQSettings-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
-
dn: CN=mSMQSiteLink-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
-
dn: CN=Domain-Administer-Server,CN=Extended-Rights,CN=Configuration,DC=X
add: localizationDisplayId
-
add: validAccesses
validAccesses: 256
-
-
add: validAccesses
validAccesses: 256
-
-
add: validAccesses
validAccesses: 256
-
-
add: validAccesses
validAccesses: 256
-
-
add: validAccesses
validAccesses: 256
-
dn: CN=Send-To,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
dn: CN=Domain-Password,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 48
-
displayName: Domain Password & Lockout Policie
-
dn: CN=General-Information,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 48
-
displayName: General Information
-
-
add: validAccesses
validAccesses: 48
-
displayName: Account Restrictions
-
dn: CN=User-Logon,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 48
-
displayName: Logon Information
-
dn: CN=Membership,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
dn: CN=Lockout-Policy,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 48
-
displayName: Lockout Policy
-
dn: CN=Password-Policy,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 48
-
displayName: Password Policy
-
dn: CN=Domain-Configuration,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 48
-
displayName: Domain Policy Configuration
-
dn: CN=Domain-Policy-Ref,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 48
-
displayName: Domain Policy Reference
-
dn: CN=Privileges,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 48
-
displayName: Privileges
-
dn: CN=Administrative-Access,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 48
-
displayName: Logon Rights
-
dn: CN=Local-Policy-Ref,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 48
-
displayName: Local Policy Reference
-
dn: CN=Audit-Policy,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 48
-
displayName: Audit Policy
-
dn: CN=Builtin-Local-Groups,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 48
-
displayName: Administrative Roles
-
-
add: validAccesses
validAccesses: 256
-
-
add: validAccesses
validAccesses: 48
-
displayName: Phone and Mail Options
-
-
add: validAccesses
validAccesses: 48
-
displayName: Personal Information
-
-
add: validAccesses
validAccesses: 48
-
displayName: Web Information
-
dn: CN=DS-Replication-Get-Changes,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
dn: CN=DS-Replication-Synchronize,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
dn: CN=DS-Replication-Manage-Topology,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
dn: CN=Change-Schema-Master,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
dn: CN=Change-Rid-Master,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
-
add: validAccesses
validAccesses: 256
-
dn: CN=Do-Garbage-Collection,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
validAccesses: 256
-
dn: CN=Recalculate-Hierarchy,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
dn: CN=Allocate-Rids,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
dn: CN=Change-PDC,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
dn: CN=Add-GUID,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
dn: CN=Change-Domain-Master,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
-
add: validAccesses
validAccesses: 48
-
displayName: Public Information
-
dn: CN=msmq-Receive-Dead-Letter,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
-
add: validAccesses
validAccesses: 256
-
-
add: validAccesses
validAccesses: 256
-
-
add: validAccesses
validAccesses: 256
-
dn: CN=msmq-Receive,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
-
add: validAccesses
validAccesses: 256
-
dn: CN=msmq-Send,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
dn: CN=msmq-Receive-journal,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
dn: CN=msmq-Open-Connector,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
validAccesses: 256
-
dn: CN=Apply-Group-Policy,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
-
add: validAccesses
validAccesses: 256
-
dn: CN=DS-Install-Replica,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
dn: CN=Change-Infrastructure-Master,CN=Extended-Rights,CN=Configuration,DC=X
-
add: validAccesses
validAccesses: 256
-
dn: CN=Update-Schema-Cache,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Update Schema Cache
rightsGUID: be2bb760-7f46-11d2-b9ad-00c04f79f805
validAccesses: 256
dn: CN=Recalculate-Security-Inheritance,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Recalculate Security Inheritance
rightsGUID: 62dd28a8-7f46-11d2-b9ad-00c04f79f805
validAccesses: 256
dn: CN=DS-Check-Stale-Phantoms,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Check Stale Phantoms
rightsGUID: 69ae6200-7f46-11d2-b9ad-00c04f79f805
validAccesses: 256
dn: CN=Certificate-Enrollment,CN=Extended-Rights,CN=Configuration,DC=X
appliesTo: e5209ca2-3bba-11d2-90cc-00c04fd91ab1
displayname: Enroll
rightsGuid: 0e10c968-78fb-11d2-90d4-00c04f79dc55
validAccesses: 256
dn: CN=DEFAULTIPSITELINK,CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=X

replace: cost
cost: 100
-
add: replInterval
replInterval: 180
-
classDisplayName: Intellimirror Group
-
classDisplayName: Intellimirror Service
-
-
attributeDisplayNames: cn,Common Name
-
objectVersion: 8
-
Sch9.ldf
newrdn: ms-Exch-Configuration-Container
deleteoldrdn: 1
dn: CN=ms-Exch-Configuration-Container,CN=Schema,CN=Configuration,DC=X
adminDisplayName: ms-Exch-Configuration-Container
-
adminDescription: ms-Exch-Configuration-Container
-
dn: CN=Mime-Types,CN=Schema,CN=Configuration,DC=X
newrdn: Mime-Types-Unused
deleteoldrdn: 1
dn: CN=Mime-Types-Unused,CN=Schema,CN=Configuration,DC=X
adminDisplayName: Mime-Types-Unused
-
adminDescription: Mime-Types-Unused
-
ldapDisplayName: mimeTypesUnused
-
lDAPDisplayName: dSCorePropagationData
adminDescription: DS-Core-Propagation-Data
adminDisplayName: DS-Core-Propagation-Data
attributeID: 1.2.840.113556.1.4.1357
oMSyntax: 24
systemOnly: TRUE
searchFlags: 0
schemaIDGUID:: S6pn0QiL0hGZOQAA+HpX1A==
systemFlags: 17
dn: CN=Schema-Info,CN=schema,CN=configuration,DC=X
lDAPDisplayName: schemaInfo
adminDescription: Schema-Info
adminDisplayName: Schema-Info
attributeID: 1.2.840.113556.1.4.1358
oMSyntax: 4
systemOnly: TRUE
searchFlags: 0
schemaIDGUID:: rmT7+bST0hGZRQAA+HpX1A==
systemFlags: 16
dn: CN=Other-Well-Known-Objects,CN=schema,CN=configuration,DC=X
lDAPDisplayName: otherWellKnownObjects
adminDescription: Other-Well-Known-Objects
adminDisplayName: Other-Well-Known-Objects
attributeID: 1.2.840.113556.1.4.1359
oMSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: XU6mHg+s0hGQ3wDAT9kasQ==
systemFlags: 16
dn: CN=MS-DS-Consistency-Child-Count,CN=Schema,CN=Configuration,DC=X
lDAPDisplayName: mS-DS-ConsistencyChildCount
adminDescription: MS-DS-Consistency-Child-Count
adminDisplayName: MS-DS-Consistency-Child-Count
attributeID: 1.2.840.113556.1.4.1361
oMSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: wnuLFzq20hGQ4QDAT9kasQ==
systemFlags: 16
dn: CN=MS-DS-Consistency-Guid,CN=Schema,CN=Configuration,DC=X
lDAPDisplayName: mS-DS-ConsistencyGuid
adminDescription: MS-DS-Consistency-Guid
adminDisplayName: MS-DS-Consistency-Guid
attributeID: 1.2.840.113556.1.4.1360
oMSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIDGUID:: wj13Izq20hGQ4QDAT9kasQ==
systemFlags: 16
dn: CN=MS-SQL-SPX,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-SPX
adminDisplayName: MS-SQL-SPX
adminDescription: MS-SQL-SPX
attributeId: 1.2.840.113556.1.4.1376
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: BICwhu7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Name,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Name
adminDisplayName: MS-SQL-Name
adminDescription: MS-SQL-Name
attributeId: 1.2.840.113556.1.4.1363
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: 2N8yNe7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Size,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Size
adminDisplayName: MS-SQL-Size
adminDescription: MS-SQL-Size
attributeId: 1.2.840.113556.1.4.1396
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: hIAJ6e7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Type,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Type
adminDisplayName: MS-SQL-Type
adminDescription: MS-SQL-Type
attributeId: 1.2.840.113556.1.4.1391
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: qOtIyu7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Alias,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Alias
adminDisplayName: MS-SQL-Alias
adminDescription: MS-SQL-Alias
attributeId: 1.2.840.113556.1.4.1395
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: rrrG4O7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Build,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Build
adminDisplayName: MS-SQL-Build
adminDescription: MS-SQL-Build
attributeId: 1.2.840.113556.1.4.1368
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: xJQ+YO7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-TCPIP,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-TCPIP
adminDisplayName: MS-SQL-TCPIP
adminDescription: MS-SQL-TCPIP
attributeId: 1.2.840.113556.1.4.1377
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: pmPCiu7M0hGZkwAA+HpX1A==
schemaIdGuid:: pmPCiu7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Vines,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Vines
adminDisplayName: MS-SQL-Vines
adminDescription: MS-SQL-Vines
attributeId: 1.2.840.113556.1.4.1379
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: lGPFlO7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Memory,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Memory
adminDisplayName: MS-SQL-Memory
adminDescription: MS-SQL-Memory
attributeId: 1.2.840.113556.1.4.1367
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: jERdW+7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Status,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Status
adminDisplayName: MS-SQL-Status
adminDescription: MS-SQL-Status
attributeId: 1.2.840.113556.1.4.1380
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: cEd9mu7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Contact,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Contact
adminDisplayName: MS-SQL-Contact
adminDescription: MS-SQL-Contact
attributeId: 1.2.840.113556.1.4.1365
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 2L1sT+7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Version,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Version
adminDisplayName: MS-SQL-Version
adminDescription: MS-SQL-Version
attributeId: 1.2.840.113556.1.4.1388
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: 0MF8wO7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Database,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Database
adminDisplayName: MS-SQL-Database
adminDescription: MS-SQL-Database
attributeId: 1.2.840.113556.1.4.1393
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: 3Nug1e7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Language,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Language
adminDisplayName: MS-SQL-Language
adminDescription: MS-SQL-Language
attributeId: 1.2.840.113556.1.4.1389
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 9HJ/xe7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Location,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Location
adminDisplayName: MS-SQL-Location
adminDescription: MS-SQL-Location
attributeId: 1.2.840.113556.1.4.1366
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: RJYcVu7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Keywords,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Keywords
adminDisplayName: MS-SQL-Keywords
adminDisplayName: MS-SQL-Keywords
adminDescription: MS-SQL-Keywords
attributeId: 1.2.840.113556.1.4.1401
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: iqnpAe/M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-NamedPipe,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-NamedPipe
adminDisplayName: MS-SQL-NamedPipe
adminDescription: MS-SQL-NamedPipe
attributeId: 1.2.840.113556.1.4.1374
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: QMiRe+7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-AppleTalk,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-AppleTalk
adminDisplayName: MS-SQL-AppleTalk
adminDescription: MS-SQL-AppleTalk
attributeId: 1.2.840.113556.1.4.1378
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 9Inaj+7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-GPSHeight,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-GPSHeight
adminDisplayName: MS-SQL-GPSHeight
adminDescription: MS-SQL-GPSHeight
attributeId: 1.2.840.113556.1.4.1387
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Dk/dvO7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Clustered,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Clustered
adminDisplayName: MS-SQL-Clustered
adminDescription: MS-SQL-Clustered
attributeId: 1.2.840.113556.1.4.1373
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: kL14d+7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-SortOrder,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-SortOrder
adminDisplayName: MS-SQL-SortOrder
adminDescription: MS-SQL-SortOrder
attributeId: 1.2.840.113556.1.4.1371
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: wELcbe7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Description,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Description
adminDisplayName: MS-SQL-Description
adminDescription: MS-SQL-Description
attributeId: 1.2.840.113556.1.4.1390
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: PGCGg+/M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-GPSLatitude,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-GPSLatitude
adminDisplayName: MS-SQL-GPSLatitude
adminDescription: MS-SQL-GPSLatitude
attributeId: 1.2.840.113556.1.4.1385
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Droisu7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-CreationDate,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-CreationDate
adminDisplayName: MS-SQL-CreationDate
adminDescription: MS-SQL-CreationDate
attributeId: 1.2.840.113556.1.4.1397
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: VEfh7e7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-CharacterSet,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-CharacterSet
adminDisplayName: MS-SQL-CharacterSet
adminDescription: MS-SQL-CharacterSet
attributeId: 1.2.840.113556.1.4.1370
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: pndhae7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-Applications,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-Applications
adminDisplayName: MS-SQL-Applications
adminDescription: MS-SQL-Applications
attributeId: 1.2.840.113556.1.4.1400
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 6qLN++7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-GPSLongitude,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-GPSLongitude
adminDisplayName: MS-SQL-GPSLongitude
adminDescription: MS-SQL-GPSLongitude
attributeId: 1.2.840.113556.1.4.1386
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: lHxXt+7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-ConnectionURL,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-ConnectionURL
adminDisplayName: MS-SQL-ConnectionURL
adminDescription: MS-SQL-ConnectionURL
attributeId: 1.2.840.113556.1.4.1383
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 2iMtqe7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-MultiProtocol,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-MultiProtocol
adminDisplayName: MS-SQL-MultiProtocol
adminDescription: MS-SQL-MultiProtocol
attributeId: 1.2.840.113556.1.4.1375
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: OPpXge7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-LastBackupDate,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-LastBackupDate
adminDisplayName: MS-SQL-LastBackupDate
adminDescription: MS-SQL-LastBackupDate
attributeId: 1.2.840.113556.1.4.1398
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: yqu28u7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-ServiceAccount,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-ServiceAccount
adminDisplayName: MS-SQL-ServiceAccount
adminDescription: MS-SQL-ServiceAccount
attributeId: 1.2.840.113556.1.4.1369
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: PjqTZO7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-PublicationURL,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-PublicationURL
adminDisplayName: MS-SQL-PublicationURL
adminDescription: MS-SQL-PublicationURL
attributeId: 1.2.840.113556.1.4.1384
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: uBEMru7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-InformationURL,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-InformationURL
adminDisplayName: MS-SQL-InformationURL
adminDescription: MS-SQL-InformationURL
attributeId: 1.2.840.113556.1.4.1382
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ENUspO7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-LastUpdatedDate,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-LastUpdatedDate
adminDisplayName: MS-SQL-LastUpdatedDate
adminDescription: MS-SQL-LastUpdatedDate
attributeId: 1.2.840.113556.1.4.1381
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 1EPMn+7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-RegisteredOwner,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-RegisteredOwner
adminDisplayName: MS-SQL-RegisteredOwner
adminDescription: MS-SQL-RegisteredOwner
attributeId: 1.2.840.113556.1.4.1364
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 6kT9SO7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-UnicodeSortOrder,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-UnicodeSortOrder
adminDisplayName: MS-SQL-UnicodeSortOrder
adminDescription: MS-SQL-UnicodeSortOrder
attributeId: 1.2.840.113556.1.4.1372
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ipHccu7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-LastDiagnosticDate,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-LastDiagnosticDate
adminDisplayName: MS-SQL-LastDiagnosticDate
adminDescription: MS-SQL-LastDiagnosticDate
attributeId: 1.2.840.113556.1.4.1399
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: iN3W9u7M0hGZkwAA+HpX1A==
schemaIdGuid:: iN3W9u7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-InformationDirectory,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-InformationDirectory
adminDisplayName: MS-SQL-InformationDirectory
adminDescription: MS-SQL-InformationDirectory
attributeId: 1.2.840.113556.1.4.1392
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Ltuu0O7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-
AllowAnonymousSubscription,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-AllowAnonymousSubscription
adminDisplayName: MS-SQL-AllowAnonymousSubscription
adminDescription: MS-SQL-AllowAnonymousSubscription
attributeId: 1.2.840.113556.1.4.1394
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Sr532+7M0hGZkwAA+HpX1A==
systemFlags: 16
dn: CN=MS-SQL-SQLServer,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-SQLServer
adminDisplayName: MS-SQL-SQLServer
adminDescription: MS-SQL-SQLServer
governsId: 1.2.840.113556.1.5.184
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.126
schemaIdGuid:: eMj2Be/M0hGZkwAA+HpX1A==
systemOnly: FALSE
defaultObjectCategory: CN=MS-SQL-
SQLServer,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
dn: CN=MS-SQL-OLAPServer,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-OLAPServer
adminDisplayName: MS-SQL-OLAPServer
adminDescription: MS-SQL-OLAPServer
governsId: 1.2.840.113556.1.5.185
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.126
schemaIdGuid:: 6hh+DO/M0hGZkwAA+HpX1A==
systemOnly: FALSE
OLAPServer,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
dn: CN=MS-SQL-SQLPublication,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-SQLPublication
adminDisplayName: MS-SQL-SQLPublication
adminDescription: MS-SQL-SQLPublication
governsId: 1.2.840.113556.1.5.187
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: TvbCF+/M0hGZkwAA+HpX1A==
systemOnly: FALSE
SQLPublication,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
dn: CN=MS-SQL-OLAPDatabase,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-OLAPDatabase
adminDisplayName: MS-SQL-OLAPDatabase
adminDescription: MS-SQL-OLAPDatabase
governsId: 1.2.840.113556.1.5.189
governsId: 1.2.840.113556.1.5.189
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: GgOvIO/M0hGZkwAA+HpX1A==
systemOnly: FALSE
OLAPDatabase,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
dn: CN=MS-SQL-SQLRepository,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-SQLRepository
adminDisplayName: MS-SQL-SQLRepository
adminDescription: MS-SQL-SQLRepository
governsId: 1.2.840.113556.1.5.186
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: XDzUEe/M0hGZkwAA+HpX1A==
systemOnly: FALSE
SQLRepository,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
dn: CN=MS-SQL-SQLDatabase,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-SQLDatabase
adminDisplayName: MS-SQL-SQLDatabase
adminDescription: MS-SQL-SQLDatabase
governsId: 1.2.840.113556.1.5.188
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: SmkIHe/M0hGZkwAA+HpX1A==
systemOnly: FALSE
SQLDatabase,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
dn: CN=MS-SQL-OLAPCube,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
ldapDisplayName: mS-SQL-OLAPCube
adminDisplayName: MS-SQL-OLAPCube
adminDescription: MS-SQL-OLAPCube
governsId: 1.2.840.113556.1.5.190
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: alDwCSjN0hGZkwAA+HpX1A==
systemOnly: FALSE
OLAPCube,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=com
-
-
add: mapiID
mapiID: 14846
-
add: systemFlags
systemFlags: 16
-
dn: CN=Extension-Name,CN=Schema,CN=Configuration,DC=X
add: systemFlags
systemFlags: 16
-
add: systemFlags
systemFlags: 16
-
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)(A;;RPLCLORC;;;PS)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)
(OA;;CR;ab721a54-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;CR;ab721a56-1e2f-11d0-9819-00aa0040529b;;PS)
(OA;;RPWP;77B5B886-944A-11d1-AEBD-0000F80367C1;;PS)(OA;;RPWP;E45795B2-9455-11d1-AEBD-0000F80367C1;;PS)
(OA;;RPWP;E45795B3-9455-11d1-AEBD-0000F80367C1;;PS)(OA;;RP;037088f8-0ae1-11d2-b422-00a0c968f939;;RS)
00c04fb96050;;AU)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;;RP;5f202010-79a5-11d0-9020-
-
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;CO)(A;;RPLCLORC;;;AU)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)
(OA;;CCDC;;;PS)(OA;;CCDC;bf967aa8-0de6-11d0-a285-00aa003049e2;;PO)(OA;;RPWP;bf967a7f-0de6-11d0-a285-
00aa003049e2;;CA)
-
defaultSecurityDescriptor: D:P(A;;RPWPCCDCLCLOLORCWOWDSDDTSW;;;DA)(A;CIOI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;EA)
(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)
-
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;CO)
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)
-
(A;;RPLCLORC;;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)(A;;RPLCLORC;;;PS)(OA;;CR;ab721a55-1e2f-11d0-9819-
00aa0040529b;;AU)
-
dn: CN=Servers-Container,CN=Schema,CN=Configuration,DC=X
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;BA)
-
defaultSecurityDescriptor: D:(A;;RP;;;WD)(OA;;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;ED)(OA;;CR;1131f6ab-
9c07-11d1-f79f-00c04fc2dcd2;;ED)(OA;;CR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;ED)(OA;;CR;1131f6aa-9c07-11d1-
f79f-00c04fc2dcd2;;BA)(OA;;CR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;BA)(OA;;CR;1131f6ac-9c07-11d1-f79f-
00c04fc2dcd2;;BA)(A;;RPLCLORC;;;AU)(A;;RPWPCRLCLOCCRCWDWOSW;;;DA)(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;BA)
(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)(A;CIOI;RPWPCRLCLOCCRCWDWOSDDTSW;;;EA)S:
(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)(A;CIOI;RPWPCRLCLOCCRCWDWOSDDTSW;;;EA)S:
(AU;CIOISAFA;WDWOSDDTWPCRCCDCSW;;;WD)
-
-
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;CO)(A;;RPLCLORC;;;AU)(OA;;CR;ab721a53-
1e2f-11d0-9819-00aa0040529b;;WD)(OA;;CCDC;;;PS)(OA;;CCDC;bf967aa8-0de6-11d0-a285-00aa003049e2;;PO)
(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;PS)
-
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)
(OA;;CCDC;bf967a86-0de6-11d0-a285-00aa003049e2;;AO)(OA;;CCDC;bf967aba-0de6-11d0-a285-00aa003049e2;;AO)
(OA;;CCDC;bf967a9c-0de6-11d0-a285-00aa003049e2;;AO)(OA;;CCDC;bf967aa8-0de6-11d0-a285-00aa003049e2;;PO)
(A;;RPLCLORC;;;AU)
-
-
-
-
-
systemFlags: 18
-
dn: CN=RDN,CN=Schema,CN=Configuration,DC=X
searchFlags: 13
-
defaultHidingVale: TRUE
-
defaultHidingVale: TRUE
-
-
-
-
-
dn: CN=GP-Link,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Sid-History,CN=Schema,CN=Configuration,DC=X
searchFlags: 1
-
dn: CN=Sid-History,CN=Schema,CN=Configuration,DC=X
attributeSecurityGuid:: Qi+6WaJ50BGQIADAT8LTzw==
-
dn: CN=MSMQ-Digests,CN=Schema,CN=Configuration,DC=X
-
-
-
dn: CN=Given-Name,CN=Schema,CN=Configuration,DC=X
-
-
dn: CN=Show-In-Advanced-View-Only,CN=Schema,CN=Configuration,DC=X
delete: mapiID
-
# Need to swap the ldapDisplayName of Comment and Additional-Information,

# so first give a temp name so that we won't fail with dup ldapDisplayName
ldapDisplayName: ms-info
-
ldapDisplayName: info
-
ldapDisplayName: notes
-
systemMayContain: gPLink
systemMayContain: gPOptions
-
systemFlags: 19
-
systemFlags: 19
-
dn: CN=Common-Name,CN=Schema,CN=Configuration,DC=X
systemFlags: 18
-
dn: CN=Country-Name,CN=Schema,CN=Configuration,DC=X
systemFlags: 18
-
dn: CN=Domain-Component,CN=Schema,CN=Configuration,DC=X
dn: CN=Domain-Component,CN=Schema,CN=Configuration,DC=X
systemFlags: 18
-
dn: CN=Organization-Name,CN=Schema,CN=Configuration,DC=X
systemFlags: 18
-
dn: CN=Organizational-Unit-Name,CN=Schema,CN=Configuration,DC=X
systemFlags: 18
-
systemFlags: 18
-
systemFlags: 18
-
dn: CN=Locality-Name,CN=Schema,CN=Configuration,DC=X
systemFlags: 18
-
systemFlags: 19
-
dn: CN=Partial-Attribute-Deletion-List,CN=Schema,CN=Configuration,DC=X
systemFlags: 19
-
dn: CN=Partial-Attribute-Set,CN=Schema,CN=Configuration,DC=X
systemFlags: 19
-
dn: CN=Sub-Refs,CN=Schema,CN=Configuration,DC=X
systemFlags: 19
-
dn: CN=USN-Last-Obj-Rem,CN=Schema,CN=Configuration,DC=X
systemFlags: 19
-
systemFlags: 19
systemFlags: 19
-
dn: CN=Repl-UpToDate-Vector,CN=Schema,CN=Configuration,DC=X
systemFlags: 19
-
dn: CN=Reps-From,CN=Schema,CN=Configuration,DC=X
systemFlags: 19
-
dn: CN=Reps-To,CN=Schema,CN=Configuration,DC=X
systemFlags: 19
-
dn: CN=USN-Changed,CN=Schema,CN=Configuration,DC=X
systemFlags: 19
-
dn: CN=USN-Created,CN=Schema,CN=Configuration,DC=X
systemFlags: 19
-
dn: CN=When-Changed,CN=Schema,CN=Configuration,DC=X
systemFlags: 19
-
-
-
dn:
schemaUpdateNow: 1
-
classDisplayName: Intellimirror Group
-
classDisplayName: Intellimirror Service
-
-
attributeDisplayNames: cn,Common Name
-
attributeDisplayNames: ou,Name
-
dn: CN=DS-UI-Default-Settings,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
add: dSUIAdminNotification
dSUIAdminNotification: 1,{E62F8206-B71C-11D1-808D-00A024C48131}
-
attributeDisplayNames: notes,Notes
-
-
-
-
-
-

delete: ldapAdminLimits
ldapAdminLimits: AllowDeepNonIndexSearch=False
-

delete: ldapAdminLimits
ldapAdminLimits: MaxConnections=1000
-
add: ldapAdminLimits
ldapAdminLimits: MaxConnections=5000
-

add: systemFlags
-

newrdn: Self
deleteoldrdn: 1
dn: CN=Self,CN=WellKnown Security Principals,CN=Configuration,DC=X

delete: systemFlags
-

add: systemFlags
-

newrdn: Authenticated Users
deleteoldrdn: 1
dn: CN=Authenticated Users,CN=WellKnown Security Principals,CN=Configuration,DC=X

delete: systemFlags
-
dn: CN=Restricted Code,CN=WellKnown Security Principals,CN=Configuration,DC=X

add: systemFlags
-
dn: CN=Restricted Code,CN=WellKnown Security Principals,CN=Configuration,DC=X

newrdn: Restricted
deleteoldrdn: 1
dn: CN=Restricted,CN=WellKnown Security Principals,CN=Configuration,DC=X

delete: systemFlags
-
dn: CN=Local System,CN=WellKnown Security Principals,CN=Configuration,DC=X

add: systemFlags
-
dn: CN=Local System,CN=WellKnown Security Principals,CN=Configuration,DC=X

newrdn: System
deleteoldrdn: 1
dn: CN=System,CN=WellKnown Security Principals,CN=Configuration,DC=X

dn: CN=System,CN=WellKnown Security Principals,CN=Configuration,DC=X
delete: systemFlags
-
objectVersion: 9
-
Sch10.ldf
Does not exist
Sch11.ldf
dn: CN=MS-DS-Replicates-NC-Reason,CN=schema,CN=configuration,DC=X
adminDescription: MS-DS-Replicates-NC-Reason
adminDisplayName: MS-DS-Replicates-NC-Reason
attributeID: 1.2.840.113556.1.4.1408
oMSyntax: 127
lDAPDisplayName: mS-DS-ReplicatesNCReason
systemOnly: FALSE
schemaIDGUID:: hCuhDrMI0xGRvAAA+HpX1A==
searchFlags: 0
systemFlags: 16
dn: CN=Mastered-By,CN=schema,CN=configuration,DC=X
adminDescription: Mastered-By
adminDisplayName: Mastered-By
attributeID: 1.2.840.113556.1.4.1409
oMSyntax: 127
lDAPDisplayName: masteredBy
systemOnly: TRUE
schemaIDGUID:: 4GSO5MkS0xGRAgDAT9kasQ==
searchFlags: 0
linkID: 77
systemFlags: 17
dn: CN=MS-DS-Machine-Account-Quota,CN=Schema,CN=Configuration,DC=X
adminDescription: MS-DS-Machine-Account-Quota
adminDisplayName: MS-DS-Machine-Account-Quota
attributeID: 1.2.840.113556.1.4.1411
oMSyntax: 2
lDAPDisplayName: mS-DS-MachineAccountQuota
schemaIDGUID:: aPtk0IAU0xGRwQAA+HpX1A==
systemOnly: FALSE
searchFlags: 0
systemFlags: 16
dn: CN=MS-DS-Creator-Sid,CN=Schema,CN=Configuration,DC=arobindg6,DC=X
adminDescription: MS-DS-Creator-SID
adminDisplayName: MS-DS-Creator-SID
attributeID: 1.2.840.113556.1.4.1410
oMSyntax: 4
lDAPDisplayName: mS-DS-CreatorSID
schemaIDGUID:: MgHmxYAU0xGRwQAA+HpX1A==
systemOnly: TRUE
searchFlags: 1
systemFlags: 16
searchFlags: 5
-
searchFlags: 5
-
replace: rangeUpper
rangeUpper: 64
-
replace: rangeUpper
rangeUpper: 64
-
dn: CN=Poss-Superiors,CN=Schema,CN=Configuration,DC=X
-
dn: CN=System-Poss-Superiors,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Range-Upper,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Range-Lower,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Ldap-Display-Name,CN=Schema,CN=Configuration,DC=X
-
-
-
dn: CN=User-Cert,CN=Schema,CN=Configuration,DC=X
-
-
-
dn: CN=Proxy-Addresses,CN=Schema,CN=Configuration,DC=X
-
-
dn: CN=Member,CN=Schema,CN=Configuration,DC=X
attributeSecurityGUID:: QMIKvKl50BGQIADAT8LUzw==
-
replace: systemOnly
systemOnly: TRUE
-
replace: systemOnly
systemOnly: TRUE
-
replace: systemOnly
systemOnly: TRUE
-
dn: CN=Is-Privilege-Holder,CN=Schema,CN=Configuration,DC=X
replace: systemOnly
systemOnly: TRUE
-
dn: CN=Managed-Objects,CN=Schema,CN=Configuration,DC=X
replace: systemOnly
systemOnly: TRUE
-
replace: systemOnly
systemOnly: TRUE
-
dn: CN=Non-Security-Member-BL,CN=Schema,CN=Configuration,DC=X
replace: systemOnly
systemOnly: TRUE
-
dn: CN=Query-Policy-BL,CN=Schema,CN=Configuration,DC=X
replace: systemOnly
systemOnly: TRUE
-
dn: CN=Server-Reference-BL,CN=Schema,CN=Configuration,DC=X
replace: systemOnly
systemOnly: TRUE
-
dn: CN=Site-Object-BL,CN=Schema,CN=Configuration,DC=X
replace: systemOnly
systemOnly: TRUE
-
-
-
systemMayContain: uPNSuffixes
-
-
-
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPCRLCLORCSDDT;;;CO)(OA;;WP;4c164200-20c0-11d0-a768-
00aa006e0529;;CO)(A;;RPLCLORC;;;AU)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;;CCDC;;;PS)
(OA;;CCDC;bf967aa8-0de6-11d0-a285-00aa003049e2;;PO)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)
(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;PS)
-
dn: CN=FT-Dfs,CN=Schema,CN=Configuration,DC=X
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;CO)(A;;RPLCLORC;;;AU)
-
dn: CN=Manager,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Assistant,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Show-In-Address-Book,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Division,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Account-Expires,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Profile-Path,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Primary-Group-ID,CN=schema,CN=configuration,DC=x
searchFlags: 17
-
dn: CN=Preferred-OU,CN=schema,CN=configuration,DC=x
searchFlags: 16
searchFlags: 16
-
dn: CN=Other-Login-Workstations,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=User-Workstations,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Max-Storage,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Logon-Workstation,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Logon-Hours,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Script-Path,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Locale-Id,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Home-Drive,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Home-Directory,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Country-Code,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Code-Page,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=User-Account-Control,CN=schema,CN=configuration,DC=x
dn: CN=User-Account-Control,CN=schema,CN=configuration,DC=x
searchFlags: 25
-
dn: CN=Employee-Type,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Show-In-Advanced-View-Only,CN=schema,CN=configuration,DC=x
searchFlags: 17
-
dn: CN=Company,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Department,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Text-Country,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Is-Member-Of-DL,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Post-Office-Box,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Postal-Code,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Postal-Address,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=Street-Address,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
dn: CN=State-Or-Province-Name,CN=schema,CN=configuration,DC=x
searchFlags: 16
searchFlags: 16
-
dn: CN=Locality-Name,CN=schema,CN=configuration,DC=x
searchFlags: 17
-
dn: CN=Country-Name,CN=schema,CN=configuration,DC=x
searchFlags: 16
-
00c04fc2dcd2;;BA)(A;;RPLCLORC;;;AU)(A;;RPWPCRLCLOCCRCWDWOSW;;;DA)(A;CI;RPWPCRLCLOCCRCWDWOSDSW;;;BA)
(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)(A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;EA)S:
(AU;CISAFA;WDWOSDDTWPCRCCDCSW;;;WD)
-
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;BA)
-
defaultSecurityDescriptor: D:P(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;DA)(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;EA)
(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;CO)(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;CI;RPLCLORC;;;AU)
(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)
-
systemFlags: 18
-
replace: rangeUpper
rangeUpper: 132096
-
dn:
schemaUpdateNow: 1
-
# Config NC changes
dn: CN=Lockout-Policy,CN=Extended-Rights,CN=Configuration,DC=X
dn: CN=Password-Policy,CN=Extended-Rights,CN=Configuration,DC=X
dn: CN=Domain-Policy-Ref,CN=Extended-Rights,CN=Configuration,DC=X
dn: CN=Privileges,CN=Extended-Rights,CN=Configuration,DC=X
dn: CN=Administrative-Access,CN=Extended-Rights,CN=Configuration,DC=X
dn: CN=Local-Policy-Ref,CN=Extended-Rights,CN=Configuration,DC=X
dn: CN=Audit-Policy,CN=Extended-Rights,CN=Configuration,DC=X
dn: CN=Builtin-Local-Groups,CN=Extended-Rights,CN=Configuration,DC=X
replace: validAccesses
validAccesses: 48
-
replace: validAccesses
validAccesses: 48
-
displayName: Remote Access Information
-
displayName: Group Membership
-
displayName: Open Address List
-
dn: CN=Self-Membership,CN=extended-rights,CN=configuration,DC=X
rightsGuid: bf9679c0-0de6-11d0-a285-00aa003049e2
appliesTo: bf967a9c-0de6-11d0-a285-00aa003049e2
displayName: Add/Remove self as member
validAccesses: 8
dn: CN=Validated-DNS-Host-Name,CN=extended-rights,CN=configuration,DC=X
rightsGuid: 72e39547-7b18-11d1-adef-00c04fd8d5cd
displayName: Validated write to DNS host name
validAccesses: 8
dn: CN=Validated-SPN,CN=extended-rights,CN=configuration,DC=X
rightsGuid: f3a64788-5306-11d1-a9c5-0000f80367c1
displayName: Validated write to service principal name
validAccesses: 8
-
attributeDisplayNames: facsimileTelephoneNumber,Fax Number
attributeDisplayNames: otherFacsimileTelephoneNumber,Fax Number (Others)
attributeDisplayNames: otherTelephone,Phone Number (Others)
attributeDisplayNames: mobile,Mobile Number
attributeDisplayNames: otherMobile,Mobile Number (Others)
-
# The following add is preceded by a delete separately since some DCs may have it.
# If not, this is just skipped
dn: CN=Contact-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
-
-
attributeDisplayNames: facsimileTelephoneNumber,Fax Number
attributeDisplayNames: otherFacsimileTelephoneNumber,Fax Number (Others)
attributeDisplayNames: otherTelephone,Phone Number (Others)
attributeDisplayNames: mobile,Mobile Number
attributeDisplayNames: otherMobile,Mobile Number (Others)
-
dn: CN=mSMQMigratedUser-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: MSMQ Upgraded User
adminPropertyPages: 1,{fc5bf656-0b7f-11d3-883f-006094eb6406}
adminContextMenu: 1,{fc5bf656-0b7f-11d3-883f-006094eb6406}
objectVersion: 11
-
Sch12.ldf
dn: CN=DNS-Tombstoned,CN=Schema,CN=Configuration,DC=X
lDAPDisplayName: dNSTombstoned
adminDescription: DNS-Tombstoned
adminDisplayName: DNS-Tombstoned
attributeID: 1.2.840.113556.1.4.1414
oMSyntax: 1
searchFlags: 1
systemOnly: FALSE
schemaIDGUID:: ty7r1U6+O0aiFGNKRNc5Lg==
systemFlags: 16
dn: CN=Primary-Group-Token,CN=Schema,CN=Configuration,DC=X
lDAPDisplayName: primaryGroupToken
adminDescription: Primary-Group-Token
adminDisplayName: Primary-Group-Token
attributeID: 1.2.840.113556.1.4.1412
oMSyntax: 2
searchFlags: 0
systemOnly: TRUE
schemaIDGUID:: OIftwP1+gUSE2WbS24vjaQ==
systemFlags: 20
dn: CN=ACS-Resource-Limits,CN=Schema,CN=Configuration,DC=X
lDAPDisplayName: aCSResourceLimits
adminDescription: ACS-Resource-Limits
adminDisplayName: ACS-Resource-Limits
governsID: 1.2.840.113556.1.5.191
rDNAttID: cn
subClassOf: top
systemMayContain: aCSMaxTokenRatePerFlow
systemMayContain: aCSServiceType
systemMayContain: aCSMaxPeakBandwidthPerFlow
systemMayContain: aCSMaxPeakBandwidth
systemMayContain: aCSAllocableRSVPBandwidth
schemaIDGUID:: BJuJLjQo0xGR1AAA+HpX1A==
systemOnly: FALSE
systemFlags: 16
(A;;RPLCLORC;;;AU)
replace: rangeUpper
rangeUpper: 1024
-
-
00aa006e0529;;CO)(A;;RPLCLORC;;;AU)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;;CCDC;;;PS)
(OA;;CCDC;bf967aa8-0de6-11d0-a285-00aa003049e2;;PO)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)
(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;PS)(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;CO)
(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;CO)
-
-
dn: CN=Sam-Account-Name,CN=Schema,CN=Configuration,DC=X
replace: rangeUpper
rangeUpper: 256
-
systemMustContain: objectSid
-
systemMayContain: objectSid
-
-
dn: CN=Link-Track-Vol-Entry,CN=Schema,CN=Configuration,DC=X
-
dn:
schemaUpdateNow: 1
-
# Config NC changes
add: appliesTo
-
add: appliesTo
-
dn: CN=Validated-SPN,CN=extended-rights,CN=configuration,DC=X
delete: appliesTo
-
adminPropertyPages: 3,{4e40f770-369c-11d0-8922-00a024ab2dbb}
-
dn: cn=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=X

replace: spnMappings
sPNMappings:
host=alerter,appmgmt,cisvc,clipsrv,browser,dhcp,dnscache,replicator,eventlog,eventsystem,policyagent,oakley,
dmserver,dns,mcsvc,fax,msiserver,ias,messenger,netlogon,netman,netdde,netddedsm,nmagent,plugplay,protectedst
orage,rasman,rpclocator,rpc,rpcss,remoteaccess,rsvp,samss,scardsvr,scesrv,seclogon,scm,dcom,cifs,spooler,snm
p,schedule,tapisrv,trksvr,trkwks,ups,time,wins,www,http,w3svc,iisadmin
-
objectVersion: 12
-
Sch13.ldf
# Schema NC changes
-
-
(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)(A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;EA)(A;CI;LC;;;RU)
(OA;CIIO;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RPLCLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)(A;;RC;;;RU)(OA;CIIO;RPLCLORC;;bf967aba-0de6-
11d0-a285-00aa003049e2;RU)S:(AU;CISAFA;WDWOSDDTWPCRCCDCSW;;;WD)
-
(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)(A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;EA)(A;CI;LC;;;RU)
(OA;CIIO;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RPLCLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)(A;;RC;;;RU)(OA;CIIO;RPLCLORC;;bf967aba-0de6-
11d0-a285-00aa003049e2;RU)S:(AU;CISAFA;WDWOSDDTWPCRCCDCSW;;;WD)
-
dn: CN=SD-Rights-Effective,CN=Schema,CN=Configuration,DC=X
-
dn: CN=MSMQ-Label-Ex,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: mSMQLabelEx
adminDisplayName: MSMQ-Label-Ex
adminDescription: MSMQ-Label-Ex
attributeId: 1.2.840.113556.1.4.1415
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
rangeLower: 0
rangeUpper: 124
schemaIdGuid:: Ja2ARQfU0kitJEPm5WeT1w==
systemFlags: 16
dn: CN=MSMQ-Site-Name-Ex,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: mSMQSiteNameEx
adminDisplayName: MSMQ-Site-Name-Ex
adminDescription: MSMQ-Site-Name-Ex
attributeId: 1.2.840.113556.1.4.1416
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: +kQhQn/BSUaU1pcx7SeE7Q==
systemFlags: 16
dn: CN=MSMQ-Computer-Type-Ex,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: mSMQComputerTypeEx
adminDisplayName: MSMQ-Computer-Type-Ex
adminDescription: MSMQ-Computer-Type-Ex
attributeId: 1.2.840.113556.1.4.1417
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 6A0SGMT0QUO9lTLrW898gA==
systemFlags: 16
dn: CN=Token-Groups-Global-And-Universal,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: tokenGroupsGlobalAndUniversal
adminDisplayName: Token-Groups-Global-And-Universal
adminDescription: Token-Groups-Global-And-Universal
attributeId: 1.2.840.113556.1.4.1418
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: HbGpRq5gWkC36P+KWNRW0g==
# pick up the new attributes so they can be a may-contain below
dn:
schemaUpdateNow: 1
-
-
-
-
-
defaultSecurityDescriptor: D:(A;CI;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPLCLORC;;;AU)
-
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)
-
defaultSecurityDescriptor: D:(A;;CC;;;BA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)
-
# Enable iff schema changes are added above.
dn:
schemaUpdateNow: 1
-
# Config NC changes
adminPropertyPages: 8,{0910dd01-df8c-11d1-ae27-00c04fa35813}
-
attributeDisplayNames: homeDirectory,Home Directory
attributeDisplayNames: samAccountName,Downlevel Logon Name
-
attributeDisplayNames: co,Country
attributeDisplayNames: generationQualifier,Generational Suffix
attributeDisplayNames: homeDirectory,Home Folder
attributeDisplayNames: samAccountName,Logon Name (pre-Windows 2000)
attributeDisplayNames: st,State/Province
attributeDisplayNames: streetAddress,Street Address
attributeDisplayNames: title,Job Title
-
-
attributeDisplayNames: samAccountName,Group name (pre-Windows 2000)
-
-
attributeDisplayNames: c,Country Abbreviation
attributeDisplayNames: co,Country
attributeDisplayNames: displayName,Display Name
attributeDisplayNames: generationQualifier,Generational Suffix
attributeDisplayNames: pager,Pager Number
attributeDisplayNames: st,State/Province
attributeDisplayNames: streetAddress,Street Address
attributeDisplayNames: title,Job Title
-
attributeDisplayNames: samAccountName,Computer name (pre-Windows 2000)
-
# Increase object version
objectVersion: 13
-
Sch14.ldf
# Schema NC changes
systemFlags: 18
-
dn: CN=Server-Reference-BL,CN=Schema,CN=Configuration,DC=X
-
dn: CN=SID-History,CN=Schema,CN=Configuration,DC=X
replace: systemOnly
systemOnly: FALSE
-
replace: systemOnly
systemOnly: TRUE
-
dn: CN=System-Poss-Superiors,CN=Schema,CN=Configuration,DC=X
systemFlags: 18
-
dn: CN=MSMQ-User-Sid,CN=Schema,CN=Configuration,DC=X
systemFlags: 18
-
-
dn: CN=ms-PKI-RA-Policies,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-RA-Policies
adminDisplayName: ms-PKI-RA-Policies
adminDescription: ms-PKI-RA-Policies
attributeId: 1.2.840.113556.1.4.1438
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Iq5G1VEJR02BfhyflvqtRg==
systemFlags: 16
dn: CN=ms-PKI-RA-Signature,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-RA-Signature
adminDisplayName: ms-PKI-RA-Signature
adminDescription: MS PKI Number Of RA Signature Required In Request
attributeId: 1.2.840.113556.1.4.1429
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: S+AX/n2Tfk+ODpKSyNVoPg==
systemFlags: 16
dn: CN=ms-PKI-Enrollment-Flag,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-Enrollment-Flag
adminDisplayName: ms-PKI-Enrollment-Flag
adminDescription: ms-PKI-Enrollment-Flag
attributeId: 1.2.840.113556.1.4.1430
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 2Pde0Sby20auebNOVgvRLA==
systemFlags: 16
dn: CN=ms-PKI-Private-Key-Flag,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-Private-Key-Flag
ldapDisplayName: msPKI-Private-Key-Flag
adminDisplayName: ms-PKI-Private-Key-Flag
adminDescription: ms-PKI-Private-Key-Flag
attributeId: 1.2.840.113556.1.4.1431
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: wkqwujUECUeTByg4DnxwAQ==
systemFlags: 16
dn: CN=ms-PKI-Minimal-Key-Size,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-Minimal-Key-Size
adminDisplayName: ms-PKI-Minimal-Key-Size
adminDescription: ms-PKI-Minimal-Key-Size
attributeId: 1.2.840.113556.1.4.1433
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 9WNq6X9B00a+Utt3A8UD3w==
systemFlags: 16
dn: CN=ms-PKI-Cert-Template-OID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-Cert-Template-OID
adminDisplayName: ms-PKI-Cert-Template-OID
adminDescription: ms-PKI-Cert-Template-OID
attributeId: 1.2.840.113556.1.4.1436
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: asNkMSa6jEaL2sHlzCVnKA==
systemFlags: 16
dn: CN=ms-PKI-Certificate-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-Certificate-Policy
adminDisplayName: ms-PKI-Certificate-Policy
adminDescription: ms-PKI-Certificate-Policy
attributeId: 1.2.840.113556.1.4.1439
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: RiOUOFvMS0Kn2G/9EgKcXw==
systemFlags: 16
dn: CN=ms-PKI-Supersede-Templates,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-Supersede-Templates
adminDisplayName: ms-PKI-Supersede-Templates
adminDescription: ms-PKI-Supersede-Templates
attributeId: 1.2.840.113556.1.4.1437
omSyntax: 64
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fa7onVt6HUK15AYfed/V1w==
systemFlags: 16
dn: CN=ms-PKI-Certificate-Name-Flag,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-Certificate-Name-Flag
adminDisplayName: ms-PKI-Certificate-Name-Flag
adminDescription: ms-PKI-Certificate-Name-Flag
attributeId: 1.2.840.113556.1.4.1432
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: xN0d6v9gbkGMwBfO5TS85w==
systemFlags: 16
dn: CN=ms-PKI-Template-Schema-Version,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-Template-Schema-Version
adminDisplayName: ms-PKI-Template-Schema-Version
adminDescription: ms-PKI-Template-Schema-Version
attributeId: 1.2.840.113556.1.4.1434
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 9ekVDB1JlEWRjzKBOgkdqQ==
systemFlags: 16
dn: CN=ms-PKI-Template-Minor-Revision,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-Template-Minor-Revision
adminDisplayName: ms-PKI-Template-Minor-Revision
adminDescription: ms-PKI-Template-Minor-Revision
attributeId: 1.2.840.113556.1.4.1435
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: bCP1E4QYsUa10EhOOJkNWA==
systemFlags: 16
dn: CN=ms-PKI-Key-Recovery-Agent,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-Key-Recovery-Agent
adminDisplayName: ms-PKI-Key-Recovery-Agent
adminDescription: ms-PKI-Key-Recovery-Agent
governsId: 1.2.840.113556.1.5.195
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.9
schemaIdGuid:: OPLMJo6ghkuagqjJrH7lyw==
(A;;RPLCLORC;;;AU)
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-PKI-Key-Recovery-Agent,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-ds-Schema-Extensions,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDs-Schema-Extensions
adminDisplayName: ms-ds-Schema-Extensions
adminDescription: ms-ds-Schema-Extensions
attributeId: 1.2.840.113556.1.4.1440
omSyntax: 4
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: vmGaswftq0yaSklj7QFB4Q==
systemFlags: 16
dn: CN=Entry-TTL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: entryTTL
adminDisplayName: Entry-TTL
adminDescription: Entry-TTL
attributeId: 1.3.6.1.4.1.1466.101.119.3
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
schemaIdGuid:: zN4T0hrYhEOqwtz8/WMc+A==
systemFlags: 20
dn: CN=ms-DS-Other-Settings,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Other-Settings
adminDisplayName: ms-DS-Other-Settings
adminDescription: ms-DS-Other-Settings
attributeId: 1.2.840.113556.1.4.1621
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: TPPSeX2du0KDj4ZrPkQA4g==
systemFlags: 16
dn: CN=ms-DS-Entry-Time-To-Die,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Entry-Time-To-Die
adminDisplayName: ms-DS-Entry-Time-To-Die
adminDescription: ms-DS-Entry-Time-To-Die
attributeId: 1.2.840.113556.1.4.1622
omSyntax: 24
systemOnly: TRUE
searchFlags: 9
schemaIdGuid:: 17rp4d3GAUGoQ3lM7IWwOA==
schemaIdGuid:: 17rp4d3GAUGoQ3lM7IWwOA==
systemFlags: 16
dn: CN=ms-DS-Site-Affinity,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Site-Affinity
adminDisplayName: ms-DS-Site-Affinity
adminDescription: ms-DS-Site-Affinity
attributeId: 1.2.840.113556.1.4.1443
omSyntax: 4
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: AlZ8wbe88EaWVmNwyohLcg==
systemFlags: 16
dn: CN=ms-DS-Preferred-GC-Site,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Preferred-GC-Site
adminDisplayName: ms-DS-Preferred-GC-Site
adminDescription: ms-DS-Prefered-GC-Site
attributeId: 1.2.840.113556.1.4.1444
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: CrUh2bIKzUKH9gnPg6kYVA==
systemFlags: 16
dn: CN=ms-DS-Cached-Membership,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Cached-Membership
adminDisplayName: ms-DS-Cached-Membership
adminDescription: ms-DS-Cached-Membership
attributeId: 1.2.840.113556.1.4.1441
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: CLDKadTNyUu6uA/zfv4bIA==
systemFlags: 17
dn: CN=ms-DS-Cached-Membership-Time-Stamp,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Cached-Membership-Time-Stamp
adminDisplayName: ms-DS-Cached-Membership-Time-Stamp
adminDescription: ms-DS-Cached-Membership-Time-Stamp
attributeId: 1.2.840.113556.1.4.1442
omSyntax: 65
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: H79mNe6+y02Kvu+J/P7GwQ==
systemFlags: 17
dn: CN=ms-DS-Auxiliary-Classes,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Auxiliary-Classes
adminDisplayName: ms-DS-Auxiliary-Classes
adminDescription: ms-DS-Auxiliary-Classes
attributeId: 1.2.840.113556.1.4.1458
omSyntax: 6
systemOnly: TRUE
searchFlags: 8
schemaIdGuid:: cxCvxFDu4Eu4wImkH+mavg==
systemFlags: 20
dn: CN=Structural-Object-Class,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: structuralObjectClass
adminDisplayName: Structural-Object-Class
adminDescription: The class hierarchy without auxiliary classes
omSyntax: 6
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: n5RgOKj2OEuZUIHstrwpgg==
systemFlags: 20
dn: CN=ms-DS-Replication-Notify-Subsequent-DSA-Delay,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Replication-Notify-Subsequent-DSA-Delay
adminDisplayName: ms-DS-Replication-Notify-Subsequent-DSA-Delay
adminDescription: This attribute controls the delay between notification of each subsequent replica partner
for an NC.
attributeId: 1.2.840.113556.1.4.1664
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: hbM91pLdUkux2A0+zA6Gtg==
systemFlags: 16
dn: CN=ms-WMI-ID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-ID
adminDisplayName: ms-WMI-ID
adminDescription: ms-WMI-ID
attributeId: 1.2.840.113556.1.4.1627
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: A6g5k7iU90eRI6hTuf9+RQ==
systemFlags: 16
dn: CN=ms-WMI-Mof,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-Mof
adminDisplayName: ms-WMI-Mof
adminDescription: ms-WMI-Mof
attributeId: 1.2.840.113556.1.4.1638
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: n4A2Z2QgPkShRYEmKx8TZg==
systemFlags: 16
dn: CN=ms-WMI-Name,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-Name
adminDisplayName: ms-WMI-Name
adminDescription: ms-WMI-Name
attributeId: 1.2.840.113556.1.4.1639
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 5azIxoF+r0KtcndBLFlBxA==
systemFlags: 16
dn: CN=ms-WMI-Query,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-Query
adminDisplayName: ms-WMI-Query
adminDescription: ms-WMI-Query
attributeId: 1.2.840.113556.1.4.1642
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Pvn/ZeM1o0WFrodsZxgpfw==
systemFlags: 16
dn: CN=ms-WMI-intMin,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-IntMin
adminDisplayName: ms-WMI-intMin
adminDescription: ms-WMI-intMin
attributeId: 1.2.840.113556.1.4.1630
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: uuPCaDeYcEyY4PDDNpXQIw==
systemFlags: 16
dn: CN=ms-WMI-intMax,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-IntMax
adminDisplayName: ms-WMI-intMax
adminDescription: ms-WMI-intMax
attributeId: 1.2.840.113556.1.4.1629
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: LAyS+5TyJkSKwdJLQqorzg==
systemFlags: 16
dn: CN=ms-WMI-Author,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-Author
adminDisplayName: ms-WMI-Author
adminDescription: ms-WMI-Author
attributeId: 1.2.840.113556.1.4.1623
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: wcBmY3JpZk6zpR1SrQwFRw==
systemFlags: 16
dn: CN=ms-WMI-int8Min,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-Int8Min
adminDisplayName: ms-WMI-int8Min
adminDescription: ms-WMI-int8Min
attributeId: 1.2.840.113556.1.4.1634
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 0YkU7cxUZkCzaKANqiZk8Q==
systemFlags: 16
dn: CN=ms-WMI-int8Max,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-Int8Max
adminDisplayName: ms-WMI-int8Max
adminDescription: ms-WMI-int8Max
attributeId: 1.2.840.113556.1.4.1633
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: R7XY4z0ARkmjK9x87clrdA==
systemFlags: 16
dn: CN=ms-COM-ObjectId,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msCOM-ObjectId
adminDisplayName: ms-COM-ObjectId
adminDescription: Object ID that COM+ uses. Default = adminDisplayName
attributeId: 1.2.840.113556.1.4.1428
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: i2cPQ5+I8kGYQyA7WmVXLw==
schemaIdGuid:: i2cPQ5+I8kGYQyA7WmVXLw==
systemFlags: 16
dn: CN=ms-COM-UserPartitionSetLink,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msCOM-UserPartitionSetLink
adminDisplayName: ms-COM-UserPartitionSetLink
adminDescription: Link from a User to a PartitionSet. Default = adminDisplayName
attributeId: 1.2.840.113556.1.4.1426
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: igyUjnfkZ0Owjf8v+ULc1w==
linkID: 1048
systemFlags: 16
dn: CN=ms-COM-UserLink,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msCOM-UserLink
adminDisplayName: ms-COM-UserLink
adminDescription: Link from a PartitionSet to a User. Default = adminDisplayName
attributeId: 1.2.840.113556.1.4.1425
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: TTpvniwkN0+waDa1f5/IUg==
linkID: 1049
systemFlags: 17
dn: CN=ms-WMI-ChangeDate,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-ChangeDate
adminDisplayName: ms-WMI-ChangeDate
adminDescription: ms-WMI-ChangeDate
attributeId: 1.2.840.113556.1.4.1624
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: oPfN+UTsN0mnm82RUis6qA==
systemFlags: 16
dn: CN=ms-WMI-intDefault,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-IntDefault
adminDisplayName: ms-WMI-intDefault
adminDescription: ms-WMI-intDefault
attributeId: 1.2.840.113556.1.4.1628
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: +AcMG912YECh4XAIRhnckA==
systemFlags: 16
dn: CN=ms-WMI-TargetPath,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-TargetPath
adminDisplayName: ms-WMI-TargetPath
adminDescription: ms-WMI-TargetPath
attributeId: 1.2.840.113556.1.4.1648
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: mqcGUP5rYUWfUhPPTdPlYA==
systemFlags: 16
dn: CN=ms-WMI-TargetType,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-TargetType
adminDisplayName: ms-WMI-TargetType
adminDescription: ms-WMI-TargetType
attributeId: 1.2.840.113556.1.4.1649
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Higqyism90+0GbwSM1Kk6Q==
systemFlags: 16
dn: CN=ms-WMI-int8Default,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-Int8Default
adminDisplayName: ms-WMI-int8Default
adminDescription: ms-WMI-int8Default
attributeId: 1.2.840.113556.1.4.1632
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: WgjY9FuMhUeVm9xYVWbkRQ==
systemFlags: 16
dn: CN=ms-WMI-TargetClass,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-TargetClass
adminDisplayName: ms-WMI-TargetClass
adminDescription: ms-WMI-TargetClass
attributeId: 1.2.840.113556.1.4.1645
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 1ti2lejJYUaivGpcq8BMYg==
systemFlags: 16
dn: CN=ms-WMI-CreationDate,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-CreationDate
adminDisplayName: ms-WMI-CreationDate
adminDescription: ms-WMI-CreationDate
attributeId: 1.2.840.113556.1.4.1626
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: LgqLdFEzP0uxcS8XQU6neQ==
systemFlags: 16
dn: CN=ms-WMI-TargetObject,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-TargetObject
adminDisplayName: ms-WMI-TargetObject
adminDescription: ms-WMI-TargetObject
attributeId: 1.2.840.113556.1.4.1647
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: pWdPxOV9H0qS2WYrVzZLdw==
systemFlags: 16
dn: CN=ms-WMI-PropertyName,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-PropertyName
adminDisplayName: ms-WMI-PropertyName
adminDescription: ms-WMI-PropertyName
attributeId: 1.2.840.113556.1.4.1641
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gwiSq/jnck20oMBEmJdQnQ==
systemFlags: 16
dn: CN=ms-COM-PartitionLink,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msCOM-PartitionLink
adminDisplayName: ms-COM-PartitionLink
adminDescription: Link from a PartitionSet to a Partition. Default = adminDisplayName
attributeId: 1.2.840.113556.1.4.1423
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: YqyrCT8EAkesK2yhXu5XVA==
linkID: 1040
systemFlags: 16
dn: CN=ms-WMI-QueryLanguage,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-QueryLanguage
adminDisplayName: ms-WMI-QueryLanguage
adminDescription: ms-WMI-QueryLanguage
adminDescription: ms-WMI-QueryLanguage
attributeId: 1.2.840.113556.1.4.1643
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: mPo8fXvBVEKL103puTKjRQ==
systemFlags: 16
dn: CN=ms-WMI-stringDefault,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-StringDefault
adminDisplayName: ms-WMI-stringDefault
adminDescription: ms-WMI-stringDefault
attributeId: 1.2.840.113556.1.4.1636
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: tkIuFcU3VU+rSBYGOEqa6g==
systemFlags: 16
dn: CN=ms-WMI-intValidValues,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-IntValidValues
adminDisplayName: ms-WMI-intValidValues
adminDescription: ms-WMI-intValidValues
attributeId: 1.2.840.113556.1.4.1631
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 9mX1akmnckuWNDxdR+a04A==
systemFlags: 16
dn: CN=ms-DS-Behavior-Version,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Behavior-Version
adminDisplayName: ms-DS-Behavior-Version
adminDescription: ms-DS-Behavior-Version
attributeId: 1.2.840.113556.1.4.1459
omSyntax: 2
systemOnly: TRUE
searchFlags: 0
rangeLower: 0
schemaIdGuid:: V4ca00ckRUWAgTu2EMrL8g==
systemFlags: 16
dn: CN=ms-WMI-int8ValidValues,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-Int8ValidValues
adminDisplayName: ms-WMI-int8ValidValues
adminDescription: ms-WMI-int8ValidValues
attributeId: 1.2.840.113556.1.4.1635
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: qRk1EALAG0SYGrCz4BLIAw==
systemFlags: 16
dn: CN=ms-WMI-TargetNameSpace,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-TargetNameSpace
adminDisplayName: ms-WMI-TargetNameSpace
adminDescription: ms-WMI-TargetNameSpace
attributeId: 1.2.840.113556.1.4.1646
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: H7ZKHCA05USEnYtdv2D+tw==
systemFlags: 16
dn: CN=ms-WMI-ClassDefinition,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-ClassDefinition
adminDisplayName: ms-WMI-ClassDefinition
adminDescription: ms-WMI-ClassDefinition
attributeId: 1.2.840.113556.1.4.1625
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: vA6cK3LCy0WZ0k0OaRYy4A==
systemFlags: 16
dn: CN=ms-WMI-NormalizedClass,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-NormalizedClass
adminDisplayName: ms-WMI-NormalizedClass
adminDescription: ms-WMI-NormalizedClass
attributeId: 1.2.840.113556.1.4.1640
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: j2K66o7r6U+D/Gk75pVVmw==
systemFlags: 16
dn: CN=ms-COM-PartitionSetLink,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msCOM-PartitionSetLink
adminDisplayName: ms-COM-PartitionSetLink
adminDescription: Link from a Partition to a PartitionSet. Default = adminDisplayName
attributeId: 1.2.840.113556.1.4.1424
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: 3CHxZwJ9fUyC9ZrUyVCsNA==
schemaIdGuid:: 3CHxZwJ9fUyC9ZrUyVCsNA==
linkID: 1041
systemFlags: 17
dn: CN=ms-WMI-stringValidValues,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-StringValidValues
adminDisplayName: ms-WMI-stringValidValues
adminDescription: ms-WMI-stringValidValues
attributeId: 1.2.840.113556.1.4.1637
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: MZ1gN7+iWEuPUytk5XoHbQ==
systemFlags: 16
dn: CN=ms-DS-NC-Replica-Locations,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-NC-Replica-Locations
adminDisplayName: ms-DS-NC-Replica-Locations
adminDescription: This is a list of servers that are the replica set for the corresponding Non-Domain Naming
Context.
attributeId: 1.2.840.113556.1.4.1661
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: FZbelze1vEasDxByDzkJ8w==
linkID: 1044
systemFlags: 16
dn: CN=ms-WMI-SourceOrganization,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-SourceOrganization
adminDisplayName: ms-WMI-SourceOrganization
adminDescription: ms-WMI-SourceOrganization
attributeId: 1.2.840.113556.1.4.1644
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: bO33NF1hjUGqAFSafXvgPg==
systemFlags: 16
dn: CN=ms-COM-DefaultPartitionLink,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msCOM-DefaultPartitionLink
adminDisplayName: ms-COM-DefaultPartitionLink
adminDescription: Link to a the default Partition for the PartitionSet. Default = adminDisplayName
attributeId: 1.2.840.113556.1.4.1427
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 9xCLmRqqZEO4Z3U9GX/mcA==
schemaIdGuid:: 9xCLmRqqZEO4Z3U9GX/mcA==
systemFlags: 16
dn: CN=ms-DS-User-Account-Control-Computed,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-User-Account-Control-Computed
adminDisplayName: ms-DS-User-Account-Control-Computed
adminDescription: ms-DS-User-Account-Control-Computed
attributeId: 1.2.840.113556.1.4.1460
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: NrjELD+2QEmNI+p6zwavVg==
systemFlags: 20
dn: CN=ms-DS-Replication-Notify-First-DSA-Delay,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Replication-Notify-First-DSA-Delay
adminDisplayName: ms-DS-Replication-Notify-First-DSA-Delay
adminDescription: This attribute controls the delay between changes to the DS, and notification of the first
replica partner for an NC.
attributeId: 1.2.840.113556.1.4.1663
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 9NSrhYkKSU697G81uyViug==
systemFlags: 16
dn: CN=ms-DS-Approx-Immed-Subordinates,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Approx-Immed-Subordinates
adminDisplayName: ms-DS-Approx-Immed-Subordinates
adminDescription: ms-DS-Approx-Immed-Subordinates
attributeId: 1.2.840.113556.1.4.1669
omSyntax: 2
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: Q9KF4c7220q0lrDABdeCPA==
systemFlags: 20
# Load new attributes into the schema cache for inclusion below
dn:
schemaUpdateNow: 1
-
-
dn: CN=ms-PKI-Enterprise-Oid,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-Enterprise-Oid
adminDisplayName: ms-PKI-Enterprise-Oid
adminDescription: ms-PKI-Enterprise-Oid
governsId: 1.2.840.113556.1.5.196
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: XNjPNxln2EqPnoZ4umJ1Yw==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-PKI-Enterprise-Oid,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
-
-
-
-
dn: CN=ms-WMI-Som,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-Som
adminDisplayName: ms-WMI-Som
adminDescription: ms-WMI-Som
adminDescription: ms-WMI-Som
governsId: 1.2.840.113556.1.5.213
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: eHCFq0IBBkSUWzTJtrEzcg==
(A;;RPCCDCLCLODTRC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-Som,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-WMI-PolicyTemplate,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-PolicyTemplate
adminDisplayName: ms-WMI-PolicyTemplate
adminDescription: ms-WMI-PolicyTemplate
governsId: 1.2.840.113556.1.5.200
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: 8YC84kokWU2sxspcT4Lm4Q==
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-PolicyTemplate,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-WMI-WMIGPO,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-WMIGPO
adminDisplayName: ms-WMI-WMIGPO
adminDescription: ms-WMI-WMIGPO
governsId: 1.2.840.113556.1.5.215
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: AABjBSc53k6/J8qR8nXCbw==
systemOnly: FALSE
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-WMIGPO,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-COM-Partition,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msCOM-Partition
adminDisplayName: ms-COM-Partition
adminDescription: Partition class. Default = adminDisplayName
governsId: 1.2.840.113556.1.5.193
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: dA4ByVhO90mKiV4+I0D8+A==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-COM-Partition,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-WMI-PolicyType,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-PolicyType
adminDisplayName: ms-WMI-PolicyType
adminDescription: ms-WMI-PolicyType
governsId: 1.2.840.113556.1.5.211
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: EyZbWQlBd06QE6O7TvJ3xw==
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-PolicyType,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-WMI-ShadowObject,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-ShadowObject
adminDisplayName: ms-WMI-ShadowObject
adminDescription: ms-WMI-ShadowObject
governsId: 1.2.840.113556.1.5.212
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: 30vk8dONNUKchvkfMfW1aQ==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-ShadowObject,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-COM-PartitionSet,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msCOM-PartitionSet
adminDisplayName: ms-COM-PartitionSet
adminDescription: PartitionSet class. Default = adminDisplayName
governsId: 1.2.840.113556.1.5.194
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: q2QEJRfEekmXWp4NRZp8oQ==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-COM-PartitionSet,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-WMI-Rule,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-Rule
adminDisplayName: ms-WMI-Rule
adminDescription: ms-WMI-Rule
governsId: 1.2.840.113556.1.5.214
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: g29+PA7dG0igwnTNlu8qZg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-Rule,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
-
-
-
-
-
dn: CN=Dynamic-Object,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: dynamicObject
adminDisplayName: Dynamic-Object
adminDescription: Dynamic-Object
governsId: 1.3.6.1.4.1.1466.101.119.2
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
systemMayContain: 1.3.6.1.4.1.1466.101.119.3
schemaIdGuid:: SRLVZlUzH0yyToHyUqyiOw==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=Dynamic-Object,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
# Reload new schema cache to pick up classes used in subclassof
dn:
schemaUpdateNow: 1
-
dn: CN=ms-WMI-MergeablePolicyTemplate,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-MergeablePolicyTemplate
adminDisplayName: ms-WMI-MergeablePolicyTemplate
adminDescription: ms-WMI-MergeablePolicyTemplate
governsId: 1.2.840.113556.1.5.202
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.200
subClassOf: 1.2.840.113556.1.5.200
schemaIdGuid:: FCRQB8r9UUiwShNkWxHSJg==
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-MergeablePolicyTemplate,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
# Reload new schema cache to pick up classes used in possSuperiors
dn:
schemaUpdateNow: 1
-
dn: CN=ms-WMI-RangeParam,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-RangeParam
adminDisplayName: ms-WMI-RangeParam
adminDescription: ms-WMI-RangeParam
governsId: 1.2.840.113556.1.5.203
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: V1r7RRhQD02QVpl8jJEi2Q==
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-RangeParam,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
# Reload new schema cache to pick up classes used in possSuperiors
dn:
schemaUpdateNow: 1
-
dn: CN=ms-WMI-StringSetParam,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-StringSetParam
adminDisplayName: ms-WMI-StringSetParam
adminDescription: ms-WMI-StringSetParam
governsId: 1.2.840.113556.1.5.210
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.203
schemaIdGuid:: onnFC6cd6ky2mYB/O51jpA==
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-StringSetParam,CN=Schema,CN=Configuration,DC=X
defaultObjectCategory: CN=ms-WMI-StringSetParam,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-WMI-UnknownRangeParam,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-UnknownRangeParam
adminDisplayName: ms-WMI-UnknownRangeParam
adminDescription: ms-WMI-UnknownRangeParam
governsId: 1.2.840.113556.1.5.204
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.203
schemaIdGuid:: a8IquNvGmECSxknBijM24Q==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-UnknownRangeParam,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-WMI-RealRangeParam,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-RealRangeParam
adminDisplayName: ms-WMI-RealRangeParam
adminDescription: ms-WMI-RealRangeParam
governsId: 1.2.840.113556.1.5.209
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.203
schemaIdGuid:: 4o/+arxwzkyxZqlvc1nFFA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-RealRangeParam,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-WMI-SimplePolicyTemplate,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-SimplePolicyTemplate
adminDisplayName: ms-WMI-SimplePolicyTemplate
adminDescription: ms-WMI-SimplePolicyTemplate
governsId: 1.2.840.113556.1.5.201
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.200
schemaIdGuid:: tbLIbN8S9kSDB+dPXN7jaQ==
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-SimplePolicyTemplate,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-WMI-IntSetParam,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-WMI-IntSetParam,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-IntSetParam
adminDisplayName: ms-WMI-IntSetParam
adminDescription: ms-WMI-IntSetParam
governsId: 1.2.840.113556.1.5.206
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.203
schemaIdGuid:: mg0vKXbPsEKEH7ZQ8zHfYg==
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-IntSetParam,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-WMI-UintSetParam,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-UintSetParam
adminDisplayName: ms-WMI-UintSetParam
adminDescription: ms-WMI-UintSetParam
governsId: 1.2.840.113556.1.5.208
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.203
schemaIdGuid:: MetLjxlO9UaTLl+gPDObHQ==
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-UintSetParam,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-WMI-IntRangeParam,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-IntRangeParam
adminDisplayName: ms-WMI-IntRangeParam
adminDescription: ms-WMI-IntRangeParam
governsId: 1.2.840.113556.1.5.205
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.203
schemaIdGuid:: fV3KUItc806531tm1JHlJg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-IntRangeParam,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-WMI-UintRangeParam,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-UintRangeParam
adminDisplayName: ms-WMI-UintRangeParam
adminDescription: ms-WMI-UintRangeParam
governsId: 1.2.840.113556.1.5.207
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.203
schemaIdGuid:: spmn2fPOs0i1rfuF+N0yFA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-UintRangeParam,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
# Reload new schema cache
dn:
schemaUpdateNow: 1
-
# Config NC changes
dn: CN=KRA,CN=Public Key Services,CN=Services,CN=Configuration,DC=X

objectClass: Container
dn: CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=X

objectClass: msPKI-Enterprise-Oid
dn: CN=Generate-RSoP,CN=Extended-Rights,CN=Configuration,DC=X
appliesTo: bf967aa5-0de6-11d0-a285-00aa003049e2
displayName: Generate Resultant Set of Policy
rightsGUID: b7b1b3dd-ab09-4242-9e30-9980e5d322f7
validAccesses: 256
dn: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=X

add: msDS-Other-Settings
msDS-Other-Settings: DynamicObjectDefaultTTL=86400
msDS-Other-Settings: DynamicObjectMinTTL=900
-
objectVersion: 14
-
Sch15.ldf
# Schema NC changes
dn: CN=ms-WMI-Parm1,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-Parm1
adminDisplayName: ms-WMI-Parm1
adminDescription: ms-WMI-Parm1
attributeId: 1.2.840.113556.1.4.1682
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: hRToJ7Cxi0q+3c4ZqDfibg==
systemFlags: 16
attributeId: 1.2.840.113556.1.4.1683
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: jlADAEKcdkqo9Di/ZLqw3g==
systemFlags: 16
attributeId: 1.2.840.113556.1.4.1684
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: to+VRb1Szkifn8JxLZ8r/A==
systemFlags: 16
attributeId: 1.2.840.113556.1.4.1685
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: o9UAOM7xgkulmhUo6nlfWQ==
systemFlags: 16
dn: CN=ms-WMI-Class,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-Class
adminDisplayName: ms-WMI-Class
adminDescription: ms-WMI-Class
attributeId: 1.2.840.113556.1.4.1676
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: X5LBkCRKB0uyAr4y6zyLdA==
systemFlags: 16
dn: CN=ms-WMI-Genus,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-Genus
adminDisplayName: ms-WMI-Genus
adminDescription: ms-WMI-Genus
attributeId: 1.2.840.113556.1.4.1677
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: OmfIUFaPFEaTCJ4TQPua8w==
systemFlags: 16
dn: CN=ms-PKI-OID-CPS,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-OID-CPS
adminDisplayName: ms-PKI-OID-CPS
adminDescription: ms-PKI-OID-CPS
attributeId: 1.2.840.113556.1.4.1672
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: DpRJX5+nUUq7bz1EalTcaw==
systemFlags: 16
dn: CN=GPC-WQL-Filter,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: gPCWQLFilter
adminDisplayName: GPC-WQL-Filter
adminDescription: GPC-WQL-Filter
attributeId: 1.2.840.113556.1.4.1694
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: psfUe90aNkSMBDmZqIAVTA==
systemFlags: 16
dn: CN=Extra-Columns,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: extraColumns
adminDisplayName: Extra-Columns
adminDescription: Extra-Columns
attributeId: 1.2.840.113556.1.4.1687
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: RihO0tkdz0uZ16YifMhtpw==
systemFlags: 16
dn: CN=ms-WMI-intFlags1,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-intFlags1
adminDisplayName: ms-WMI-intFlags1
adminDescription: ms-WMI-intFlags1
attributeId: 1.2.840.113556.1.4.1678
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: uQbgGEVk40idz7Xs+8Tfjg==
systemFlags: 16
attributeId: 1.2.840.113556.1.4.1679
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: yUJaB1rFsUWsk+sIazH2EA==
systemFlags: 16
attributeId: 1.2.840.113556.1.4.1680
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Nqef8gne5EuyOuc0wSS6zA==
systemFlags: 16
attributeId: 1.2.840.113556.1.4.1681
omSyntax: 2
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: rKd0vZPEnEy9+lx7EZymsg==
systemFlags: 16
dn: CN=ms-WMI-ScopeGuid,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-ScopeGuid
adminDisplayName: ms-WMI-ScopeGuid
adminDescription: ms-WMI-ScopeGuid
attributeId: 1.2.840.113556.1.4.1686
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: UY23h19Af0uA7SvSh4b0jQ==
systemFlags: 16
dn: CN=ms-FRS-Hub-Member,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msFRS-Hub-Member
adminDisplayName: ms-FRS-Hub-Member
adminDescription: ms-FRS-Hub-Member
attributeId: 1.2.840.113556.1.4.1693
omSyntax: 127
linkID: 1046
searchFlags: 0
schemaIdGuid:: gf9DVrY1qUyVErrwvQoncg==
dn: CN=ms-PKI-OID-Attribute,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-OID-Attribute
adminDisplayName: ms-PKI-OID-Attribute
adminDescription: ms-PKI-OID-Attribute
attributeId: 1.2.840.113556.1.4.1671
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: iBKejChQT0+nBHbQJvJG7w==
systemFlags: 16
dn: CN=ms-FRS-Topology-Pref,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msFRS-Topology-Pref
adminDisplayName: ms-FRS-Topology-Pref
adminDescription: ms-FRS-Topology-Pref
attributeId: 1.2.840.113556.1.4.1692
omSyntax: 64
searchFlags: 0
schemaIdGuid:: 4CeqklBcLUCewe6Efe+XiA==
dn: CN=ms-PKI-OID-User-Notice,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-OID-User-Notice
adminDisplayName: ms-PKI-OID-User-Notice
adminDescription: ms-PKI-OID-User-Notice
attributeId: 1.2.840.113556.1.4.1673
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: etrEBBThaU6I3uKT8tOzlQ==
systemFlags: 16
dn: CN=ms-PKI-RA-Application-Policies,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-RA-Application-Policies
adminDisplayName: ms-PKI-RA-Application-Policies
adminDescription: ms-PKI-RA-Application-Policies
attributeId: 1.2.840.113556.1.4.1675
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: v/uRPHNHzUyoe4XVPnvPag==
systemFlags: 16
dn: CN=Admin-Multiselect-Property-Pages,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: adminMultiselectPropertyPages
adminDisplayName: Admin-Multiselect-Property-Pages
adminDescription: Admin-Multiselect-Property-Pages
attributeId: 1.2.840.113556.1.4.1690
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: fbb5GMZaO0uX29CkBq+3ug==
systemFlags: 16
dn: CN=ms-DS-Security-Group-Extra-Classes,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Security-Group-Extra-Classes
adminDisplayName: ms-DS-Security-Group-Extra-Classes
adminDescription: ms-DS-Security-Group-Extra-Classes
attributeId: 1.2.840.113556.1.4.1688
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 6GoUT/6kAUinMfUYSKT05A==
systemFlags: 16
dn: CN=ms-PKI-Certificate-Application-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-Certificate-Application-Policy
adminDisplayName: ms-PKI-Certificate-Application-Policy
adminDisplayName: ms-PKI-Certificate-Application-Policy
adminDescription: ms-PKI-Certificate-Application-Policy
attributeId: 1.2.840.113556.1.4.1674
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: SAXZ2zeqAkKZZoxTe6XOMg==
systemFlags: 16
dn: CN=ms-DS-Non-Security-Group-Extra-Classes,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Non-Security-Group-Extra-Classes
adminDisplayName: Non-Security-Group-Extra-Classes
adminDescription: ms-DS-Non-Security-Group-Extra-Classes
attributeId: 1.2.840.113556.1.4.1689
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: /EThLVIfb0i99Bb8wwhOVA==
systemFlags: 16
dn: CN=MSMQ-Recipient-FormatName,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msMQ-Recipient-FormatName
adminDisplayName: MSMQ-Recipient-FormatName
adminDescription: MSMQ-Recipient-FormatName
attributeId: 1.2.840.113556.1.4.1695
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 255
schemaIdGuid:: SGf+O0S1WkiwZxsxDEM0vw==
systemFlags: 16
dn: CN=Last-Logon-Timestamp,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: lastLogonTimestamp
adminDisplayName: Last-Logon-Timestamp
adminDescription: Last-Logon-Timestamp
attributeId: 1.2.840.113556.1.4.1696
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: BAriwFoO80+Ugl7+rs1wYA==
attributeSecurityGuid:: ECAgX6V50BGQIADAT8LUzw==
systemFlags: 16
dn: CN=ms-DS-Settings,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Settings
adminDisplayName: ms-DS-Settings
adminDescription: ms-DS-Settings
attributeId: 1.2.840.113556.1.4.1697
attributeId: 1.2.840.113556.1.4.1697
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 10cbDqNASEuNG0ysDBzfIQ==
systemFlags: 16
dn: CN=ms-TAPI-Unique-Identifier,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTAPI-uid
adminDisplayName: msTAPI-uid
adminDescription: msTAPI-uid
attributeId: 1.2.840.113556.1.4.1698
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 120
schemaIdGuid:: 6uekcLmzQ0aJGObdJHG/1A==
systemFlags: 16
dn: CN=ms-TAPI-Ip-Address,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTAPI-IpAddress
adminDisplayName: msTAPI-IpAddress
adminDescription: msTAPI-IpAddress
attributeId: 1.2.840.113556.1.4.1701
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 99fX744XZ0eH+viha4QFRA==
systemFlags: 16
dn: CN=ms-TAPI-Protocol-Id,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTAPI-ProtocolId
adminDisplayName: msTAPI-ProtocolId
adminDescription: msTAPI-ProtocolId
attributeId: 1.2.840.113556.1.4.1699
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: z+vBiV96/UGZyskAsyKZqw==
systemFlags: 16
dn: CN=ms-TAPI-Conference-Blob,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTAPI-ConferenceBlob
adminDisplayName: msTAPI-ConferenceBlob
adminDescription: msTAPI-ConferenceBlob
attributeId: 1.2.840.113556.1.4.1700
omSyntax: 4
systemOnly: FALSE
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: HmDETAFyQUGryD5SmuiIYw==
systemFlags: 16
dn: CN=Is-Member-Of-DL,CN=Schema,CN=Configuration,DC=X
attributeSecurityGuid:: QMIKvKl50BGQIADAT8LUzw==
-
searchFlags: 9
-
dn: CN=ms-DS-Trust-Forest-Trust-Info,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-TrustForestTrustInfo
adminDisplayName: ms-DS-Trust-Forest-Trust-Info
adminDescription: ms-DS-Trust-Forest-Trust-Info
attributeId: 1.2.840.113556.1.4.1702
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: bobMKdNJaUmULh28CSXRgw==
systemFlags: 16
dn: CN=ms-Exch-Owner-BL,CN=Schema,CN=Configuration,DC=X
lDAPDisplayName: ownerBL
adminDescription: ms-Exch-Owner-BL
adminDisplayName: ms-Exch-Owner-BL
attributeID: 1.2.840.113556.1.2.104
oMSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: 9HmWv+YN0BGihQCqADBJ4g==
linkID: 45
systemFlags: 17
# Load the schema cache to pick up new attributes
dn:
schemaUpdateNow: 1
-
dn: CN=ms-WMI-ObjectEncoding,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msWMI-ObjectEncoding
adminDisplayName: ms-WMI-ObjectEncoding
adminDescription: ms-WMI-ObjectEncoding
governsId: 1.2.840.113556.1.5.217
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: yYHdVRLD+UGoTcatvfHo4Q==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-WMI-ObjectEncoding,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=Application-Version,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: applicationVersion
adminDisplayName: Application-Version
adminDescription: Stores versioning information for an application and its schema.
governsId: 1.2.840.113556.1.5.216
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.7000.49
schemaIdGuid:: rJDH3U2vKkSPD6HUyqfdkg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=Application-Version,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
-
-
-
-
-
-
-
-
defaultSecurityDescriptor: D:(A;;RPLCLORC;;;AU)(A;;RPWPCRLCLOCCDCRCWDWOSW;;;DA)(A;;CC;;;PA)
(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)
-
-
-
-
-
-
-
-
dn: CN=ms-WMI-WMIGPO,CN=Schema,CN=Configuration,DC=X
-
-
-
-
-
dn: CN=MSMQ-Group,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msMQ-Group
adminDisplayName: MSMQ-Group
adminDescription: MSMQ-Group
governsId: 1.2.840.113556.1.5.219
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: rHqyRvqq+0+3c+W/Yh7oew==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=MSMQ-Group,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=MSMQ-Custom-Recipient,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msMQ-Custom-Recipient
adminDisplayName: MSMQ-Custom-Recipient
adminDescription: MSMQ-Custom-Recipient
governsId: 1.2.840.113556.1.5.218
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: F2hth8w1bEOs6l73F03Zvg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=MSMQ-Custom-Recipient,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
-
dn: CN=ms-DS-App-Configuration,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-App-Configuration
adminDisplayName: ms-DS-App-Configuration
adminDescription: Stores configuration parameters for an application.
governsId: 1.2.840.113556.1.5.220
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.7000.49
schemaIdGuid:: PjzfkFQYVUSl18rUDVZleg==
schemaIdGuid:: PjzfkFQYVUSl18rUDVZleg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-App-Configuration,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
dn: CN=Application-Settings,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ms-TAPI-Rt-Person,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTAPI-RtPerson
adminDisplayName: msTAPI-RtPerson
adminDescription: msTAPI-RtPerson
governsId: 1.2.840.113556.1.5.222
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: tRzqUwS3+U2Bj1y07IbKwQ==
defaultSecurityDescriptor: D:(A;;GA;;;WD)
systemOnly: FALSE
defaultObjectCategory: CN=ms-TAPI-Rt-Person,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-TAPI-Rt-Conference,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTAPI-RtConference
adminDisplayName: msTAPI-RtConference
adminDescription: msTAPI-RtConference
governsId: 1.2.840.113556.1.5.221
rdnAttId: 1.2.840.113556.1.4.1698
subClassOf: 2.5.6.0
schemaIdGuid:: NZd7yipLSU6Jw5kCUzTclA==
defaultSecurityDescriptor: D:(A;;GA;;;WD)
systemOnly: FALSE
defaultObjectCategory: CN=ms-TAPI-Rt-Conference,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
# Reload the schema cache to pick up altered classes and attributes
dn:
schemaUpdateNow: 1
-
# Config NC changes
dn: CN=msmq-Send,CN=Extended-Rights,CN=Configuration,DC=X
add: appliesTo
appliesTo: 46b27aac-aafa-4ffb-b773-e5bf621ee87b
-
dn: CN=Refresh-Group-Cache,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Refresh Group Cache for Logons
rightsGUID: 9432c620-033c-4db7-8b58-14ef6d0bf477
validAccesses: 256
objectVersion: 15
-
Sch16.ldf
# Schema NC changes
add: rangeLower
rangeLower: 16
-
add: rangeUpper
rangeUpper: 16
-
dn: CN=Other-Well-Known-Objects,CN=Schema,CN=Configuration,DC=X
add: rangeLower
rangeLower: 16
-
add: rangeUpper
rangeUpper: 16
-
-
-
-
-
-
-
-
-
dn: CN=ms-TAPI-Unique-Identifier,CN=Schema,CN=Configuration,DC=X
replace: rangeUpper
rangeUpper: 256
-
-
dn: CN=ms-DS-NC-Repl-Cursors,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-NCReplCursors
adminDisplayName: ms-DS-NC-Repl-Cursors
adminDescription: ms-DS-NC-Repl-Cursors
attributeId: 1.2.840.113556.1.4.1704
omSyntax: 64
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 5HwWiuj560eNePf+gKuyzA==
systemFlags: 20
dn: CN=ms-DS-Filter-Containers,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-FilterContainers
adminDisplayName: ms-DS-Filter-Containers
adminDescription: ms-DS-Filter-Containers
attributeId: 1.2.840.113556.1.4.1703
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: 39wA+zesOkicEqxTpmAwMw==
systemFlags: 16
dn: CN=ms-DS-Repl-Value-Meta-Data,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ReplValueMetaData
adminDisplayName: ms-DS-Repl-Value-Meta-Data
adminDescription: ms-DS-Repl-Value-Meta-Data
attributeId: 1.2.840.113556.1.4.1708
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: RYFcL73hC0GJV4v6gdWs/Q==
systemFlags: 20
dn: CN=ms-DS-Repl-Attribute-Meta-Data,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ReplAttributeMetaData
adminDisplayName: ms-DS-Repl-Attribute-Meta-Data
adminDescription: ms-DS-Repl-Attribute-Meta-Data
attributeId: 1.2.840.113556.1.4.1707
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: QjLF105yOUydTC34ydZseg==
systemFlags: 20
dn: CN=ms-DS-NC-Repl-Inbound-Neighbors,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-NCReplInboundNeighbors
adminDisplayName: ms-DS-NC-Repl-Inbound-Neighbors
adminDescription: ms-DS-NC-Repl-Inbound-Neighbors
attributeId: 1.2.840.113556.1.4.1705
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Wqjbnp4+G0ObGqW26e2nlg==
systemFlags: 20
dn: CN=ms-DS-NC-Repl-Outbound-Neighbors,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-NCReplOutboundNeighbors
adminDisplayName: ms-DS-NC-Repl-Outbound-Neighbors
adminDescription: ms-DS-NC-Repl-Outbound-Neighbors
attributeId: 1.2.840.113556.1.4.1706
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 9S5fhcWhxEy6bTJSKEi2Hw==
systemFlags: 20
dn: CN=ms-DS-Has-Instantiated-NCs,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-HasInstantiatedNCs
adminDisplayName: ms-DS-Has-Instantiated-NCs
adminDescription: DS replication information detailing the state of the NCs present on a particular server.
attributeId: 1.2.840.113556.1.4.1709
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
rangeLower: 4
rangeUpper: 4
schemaIdGuid:: vKXpERdFSUCvnFFVT7D8CQ==
linkID: 2002
systemFlags: 16
dn: CN=ms-DS-Allowed-DNS-Suffixes,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AllowedDNSSuffixes
adminDisplayName: ms-DS-Allowed-DNS-Suffixes
adminDescription: Allowed suffixes for dNSHostName on computer
attributeId: 1.2.840.113556.1.4.1710
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 2048
schemaIdGuid:: G0RphMSaRU6CBb0hnb9nLQ==
systemFlags: 16
dn: CN=Country-Code,CN=Schema,CN=Configuration,DC=X
add: rangeLower
rangeLower: 0
-
add: rangeUpper
rangeUpper: 65535
-
dn: CN=ms-DS-SD-Reference-Domain,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-SDReferenceDomain
adminDisplayName: ms-DS-SD-Reference-Domain
adminDescription: The domain to be used for default security descriptor translation for a Non-Domain Naming
Context.
attributeId: 1.2.840.113556.1.4.1711
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: FuNRTCj2pUOwa/+2lfy08w==
linkID: 2000
systemFlags: 16
dn:
schemaUpdateNow: 1
-
-
-
-
-
-
dn:
schemaUpdateNow: 1
-
# Config NC changes
# Config NC changes
dn: CN=SAM-Enumerate-Entire-Domain,CN=Extended-Rights,CN=Configuration,DC=X
appliesTo: bf967aad-0de6-11d0-a285-00aa003049e2
displayName: Enumerate Entire SAM Domain
rightsGUID: 91d67418-0135-4acc-8d79-c08e857cfbec
validAccesses: 256
dn: CN=Generate-RSoP-Logging,CN=Extended-Rights,CN=Configuration,DC=X
appliesTo: bf967aa5-0de6-11d0-a285-00aa003049e2
displayName: Generate Resultant Set of Policy (Logging)
rightsGUID: b7b1b3de-ab09-4242-9e30-9980e5d322f7
validAccesses: 256
add: systemFlags
-
newrdn: Generate-RSoP-Planning
deleteoldrdn: 1
dn: CN=Generate-RSoP-Planning,CN=Extended-Rights,CN=Configuration,DC=X
delete: systemFlags
-
dn: CN=Generate-RSoP-Planning,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Generate Resultant Set of Policy (Planning)
-
objectVersion: 16
-
Sch17.ldf
# Schema NC changes
systemFlags: 27
-
systemFlags: 24
-
systemFlags: 26
-
dn: CN=ms-PKI-OID-LocalizedName,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-OIDLocalizedName
adminDisplayName: ms-PKI-OID-LocalizedName
adminDescription: ms-PKI-OID-LocalizedName
attributeId: 1.2.840.113556.1.4.1712
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 512
schemaIdGuid:: FqhZfQW7ckqXH1wTMfZ1WQ==
systemFlags: 16
dn: CN=MSMQ-Secured-Source,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: MSMQ-SecuredSource
adminDisplayName: MSMQ-Secured-Source
adminDescription: MSMQ-Secured-Source
attributeId: 1.2.840.113556.1.4.1713
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: GyLwiwZ6Y02R8BSZlBgT0w==
systemFlags: 16
dn: CN=MSMQ-Multicast-Address,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: MSMQ-MulticastAddress
adminDisplayName: MSMQ-Multicast-Address
adminDescription: MSMQ-Multicast-Address
attributeId: 1.2.840.113556.1.4.1714
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 9
schemaIdGuid:: EkQvHQ3xN0ObSG5bElzSZQ==
systemFlags: 16
dn: CN=ms-DS-SPN-Suffixes,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-SPNSuffixes
adminDisplayName: ms-DS-SPN-Suffixes
adminDescription: ms-DS-SPN-Suffixes
attributeId: 1.2.840.113556.1.4.1715
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 255
schemaIdGuid:: 6+GeeI6MTE6M7HmzG3YXtQ==
systemFlags: 16
dn: CN=ms-DS-Has-Instantiated-NCs,CN=Schema,CN=Configuration,DC=X
add: linkID
linkID: 2002
-
dn: CN=ms-DS-IntId,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-IntId
adminDisplayName: ms-DS-IntId
adminDescription: ms-DS-IntId
attributeId: 1.2.840.113556.1.4.1716
omSyntax: 2
systemOnly: TRUE
searchFlags: 8
schemaIdGuid:: aglgvEcbMEuId2Ask/VlMg==
systemFlags: 16
dn: CN=Invocation-Id,CN=Schema,CN=Configuration,DC=X
searchFlags: 1
-
dn:
schemaUpdateNow: 1
-
dn: CN=ms-PKI-Private-Key-Recovery-Agent,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-PrivateKeyRecoveryAgent
adminDisplayName: ms-PKI-Private-Key-Recovery-Agent
adminDescription: ms-PKI-Private-Key-Recovery-Agent
governsId: 1.2.840.113556.1.5.223
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: MqZiFblEfkqi0+QmyWo6zA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-PKI-Private-Key-Recovery-Agent,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
-
dn: CN=MSMQ-Custom-Recipient,CN=Schema,CN=Configuration,DC=X
-
-
-
-
-
-
-
-
dn:
schemaUpdateNow: 1
-
# Config NC changes
objectVersion: 17
-
Sch18.ldf
dn: CN=ms-Exch-Assistant-Name,CN=Schema,CN=Configuration,DC=X
changetype: NtdsSchemaAdd
adminDescription: ms-Exch-Assistant-Name
adminDisplayName: ms-Exch-Assistant-Name
attributeID: 1.2.840.113556.1.2.444
lDAPDisplayName: msExchAssistantName
mapiId: 14896
oMSyntax: 64
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: lHPfqOrF0RG7ywCAx2ZwwA==
searchFlags: 0
dn: CN=ms-Exch-LabeledURI,CN=Schema,CN=Configuration,DC=X
adminDescription: ms-Exch-LabeledURI
adminDisplayName: ms-Exch-LabeledURI
attributeID: 1.2.840.113556.1.2.593
lDAPDisplayName: msExchLabeledURI
mapiId: 35921
name: ms-Exch-LabeledURI
oMSyntax: 64
rangeLower: 1
rangeUpper: 1024
schemaIdGuid:: IFh3FvNH0RGpwwAA+ANnwQ==
searchFlags: 0
dn:
schemaUpdateNow: 1
-
# change the LDN of Exchange schema objects
dn: CN=ms-Exch-Assistant-Name,CN=Schema,CN=Configuration,DC=X
replace: lDAPDisplayName
lDAPDisplayName: msExchAssistantName
-
dn: CN=ms-Exch-LabeledURI,CN=Schema,CN=Configuration,DC=X
replace: lDAPDisplayName
lDAPDisplayName: msExchLabeledURI
-
dn:
schemaUpdateNow: 1
-
# Schema NC changes
dn: CN=uid,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: uid
adminDisplayName: uid
adminDescription: A user ID.
attributeId: 0.9.2342.19200300.100.1.1
omSyntax: 64
systemOnly: FALSE
searchFlags: 8
schemaIdGuid:: oPywC4ken0KQGhQTiU2fWQ==
systemFlags: 0
dn: CN=audio,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: audio
adminDisplayName: audio
adminDescription: The Audio attribute type allows the storing of sounds in the Directory.
attributeId: 0.9.2342.19200300.100.1.55
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeUpper: 250000
schemaIdGuid:: JNLh0KDhzkKi2nk7pSRPNQ==
systemFlags: 0
dn: CN=photo,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: photo
adminDisplayName: photo
adminDescription: An object encoded in G3 fax as explained in recommendation T.4, with an ASN.1 wrapper to
make it compatible with an X.400 BodyPart as defined in X.420.
attributeId: 0.9.2342.19200300.100.1.7
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: aJeXnBq6CEyWMsalwe1kmg==
systemFlags: 0
dn: CN=jpegPhoto,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: jpegPhoto
adminDisplayName: jpegPhoto
adminDescription: Used to store one or more images of a person using the JPEG File Interchange Format
[JFIF].
attributeId: 0.9.2342.19200300.100.1.60
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: cgXIusQJqU+a5nYo162+Dg==
systemFlags: 0
dn: CN=secretary,CN=Schema,CN=Configuration,DC=X
adminDisplayName: secretary
adminDescription: Specifies the secretary of a person.
attributeId: 0.9.2342.19200300.100.1.21
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: mi0HAa2YU0qXROg+KHJ4+w==
systemFlags: 0
dn: CN=userPKCS12,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: userPKCS12
adminDisplayName: userPKCS12
adminDescription: PKCS #12 PFX PDU for exchange of personal identity information.
attributeId: 2.16.840.1.113730.3.1.216
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: tYqZI/hwB0CkwahKODEfmg==
systemFlags: 0
dn: CN=carLicense,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: carLicense
adminDisplayName: carLicense
adminDescription: Vehicle license or registration plate.
attributeId: 2.16.840.1.113730.3.1.1
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: kpwV1H2Vh0qKZ40pNOAWSQ==
systemFlags: 0
dn: CN=labeledURI,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: labeledURI
adminDisplayName: labeledURI
adminDescription: A Uniform Resource Identifier followed by a label. The label is used to describe the
resource to which the URI points, and is intended as a friendly name fit for human consumption.
attributeId: 1.3.6.1.4.1.250.1.57
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: RrtpxYDGvESic+bCJ9cbRQ==
systemFlags: 0
dn: CN=roomNumber,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: roomNumber
adminDisplayName: roomNumber
adminDescription: The room number of an object.
attributeId: 0.9.2342.19200300.100.1.6
attributeId: 0.9.2342.19200300.100.1.6
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: wvjXgSfjDUqRxrQtQAkRXw==
systemFlags: 0
dn: CN=uniqueMember,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: uniqueMember
adminDisplayName: uniqueMember
adminDescription: The distinguished name for the member of a group. Used by groupOfUniqueNames.
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: JoeIjwr410Sx7sud8hOSyA==
systemFlags: 0
dn: CN=departmentNumber,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: departmentNumber
adminDisplayName: departmentNumber
adminDescription: Identifies a department within an organization.
attributeId: 2.16.840.1.113730.3.1.2
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 7vaevsfLIk+ye5aWfn7lhQ==
systemFlags: 0
dn: CN=unstructuredName,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: unstructuredName
adminDisplayName: unstructuredName
adminDescription: The DNS name of the router. For example, router1.microsoft.com. PKCS #9
attributeId: 1.2.840.113549.1.9.2
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 256
schemaIdGuid:: d/GOnM9ByUWWc3cWwMiQGw==
systemFlags: 0
dn: CN=preferredLanguage,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: preferredLanguage
adminDisplayName: preferredLanguage
adminDescription: The preferred written or spoken language for a person.
attributeId: 2.16.840.1.113730.3.1.39
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 0OBrhecY4UaPX37k2QIODQ==
systemFlags: 0
dn: CN=x500uniqueIdentifier,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: x500uniqueIdentifier
adminDisplayName: x500uniqueIdentifier
adminDescription: Used to distinguish between objects when a distinguished name has been reused. This is a
different attribute type from both the "uid" and "uniqueIdentifier" types.
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: H6F90D2KtkKwqnbJYr5xmg==
systemFlags: 0
dn: CN=unstructuredAddress,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: unstructuredAddress
adminDisplayName: unstructuredAddress
adminDescription: The IP address of the router. For example, 100.11.22.33. PKCS #9
attributeId: 1.2.840.113549.1.9.8
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 256
schemaIdGuid:: OQiVUEzMkUSGOvz5QtaEtw==
systemFlags: 0
dn: CN=attributeCertificateAttribute,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: attributeCertificateAttribute
adminDisplayName: attributeCertificateAttribute
adminDescription: A digitally signed or certified identity and set of attributes. Used to bind authorization
information to an identity. X.509
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: u5NG+sJ7uUyBqMmcQ7eQXg==
systemFlags: 0
dn:
schemaUpdateNow: 1
-
dn: CN=inetOrgPerson,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: inetOrgPerson
adminDisplayName: inetOrgPerson
adminDescription: Represents people who are associated with an organization in some way.
governsId: 2.16.840.1.113730.3.2.2
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.9
systemMayContain: 2.16.840.1.113730.3.1.216
systemMayContain: 1.3.6.1.4.1.250.1.57
schemaIdGuid:: FMwoSDcUvEWbB61vAV5fKA==
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)(A;;RPLCLORC;;;PS)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)
(OA;;CR;ab721a54-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;CR;ab721a56-1e2f-11d0-9819-00aa0040529b;;PS)
(OA;;RPWP;77B5B886-944A-11d1-AEBD-0000F80367C1;;PS)(OA;;RPWP;E45795B2-9455-11d1-AEBD-0000F80367C1;;PS)
(OA;;RPWP;E45795B3-9455-11d1-AEBD-0000F80367C1;;PS)(OA;;RP;037088f8-0ae1-11d2-b422-00a0c968f939;;RS)
00c04fb96050;;AU)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;;RP;5f202010-79a5-11d0-9020-
systemOnly: FALSE
defaultObjectCategory: CN=Person,CN=Schema,CN=Configuration,DC=X
systemFlags: 0
dn: CN=groupOfUniqueNames,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: groupOfUniqueNames
adminDisplayName: groupOfUniqueNames
adminDescription: Defines the entries for a group of unique names.
governsId: 2.5.6.17
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: EakQA6OTIU6no1XYWrLEiw==
(A;;RPLCLORC;;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)(A;;RPLCLORC;;;PS)
systemOnly: FALSE
defaultObjectCategory: CN=groupOfUniqueNames,CN=Schema,CN=Configuration,DC=X
systemFlags: 0
dn: CN=Person,CN=Schema,CN=Configuration,DC=X
-
-
add: mayContain
mayContain: 1.2.840.113556.1.2.444
mayContain: 1.2.840.113556.1.2.593
mayContain: 1.3.6.1.4.1.250.1.57
mayContain: 0.9.2342.19200300.100.1.21
-
dn:
schemaUpdateNow: 1
-
add: mayContain
mayContain: 1.3.6.1.4.1.250.1.57
mayContain: 0.9.2342.19200300.100.1.21
-
dn:
schemaUpdateNow: 1
-
# Config NC changes
objectVersion: 18
-
Sch19.ldf
# attributes
dn: CN=ms-DS-Auxiliary-Classes,CN=Schema,CN=Configuration,DC=X
systemFlags: 20
-
dn:
schemaUpdateNow: 1
-
# class changes
(A;;RPLCLORC;;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)(A;;RPLCLORC;;;PS)
-
dn: CN=Force-Logoff,CN=Schema,CN=Configuration,DC=X
attributeSecurityGuid:: 0J8RuPYEYkerekmGx2s/mg==
-
dn: CN=OEM-Information,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Server-State,CN=Schema,CN=Configuration,DC=X
-
dn: CN=UAS-Compat,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Server-Role,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Domain-Replica,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Modified-Count,CN=Schema,CN=Configuration,DC=X
-
dn:
schemaUpdateNow: 1
-
# Config NC changes
dn: CN=Domain-Other-Parameters,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Other Domain Parameters (for use by SAM)
rightsGUID: b8119fd0-04f6-4762-ab7a-4986c76b3f9a
validAccesses: 48
add: appliesTo
appliesTo: 4828CC14-1437-45bc-9B07-AD6F015E5F28
-
dn: CN=General-Information,CN=Extended-Rights,CN=Configuration,DC=X
add: appliesTo
-
add: appliesTo
add: appliesTo
-
add: appliesTo
-
add: appliesTo
-
add: appliesTo
-
add: appliesTo
-
add: appliesTo
-
add: appliesTo
-
add: appliesTo
-
add: appliesTo
-
dn: CN=User-Logon,CN=Extended-Rights,CN=Configuration,DC=X
add: appliesTo
-
add: appliesTo
-
dn: CN=Domain-Password,CN=Extended-Rights,CN=Configuration,DC=X
add: appliesTo
-
objectVersion: 19
-
Sch20.ldf
# attributes
dn: CN=ms-DS-DnsRootAlias,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-DnsRootAlias
adminDisplayName: ms-DS-DnsRootAlias
adminDescription: ms-DS-DnsRootAlias
attributeId: 1.2.840.113556.1.4.1719
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 255
schemaIdGuid:: yqxDIa3uKU21kYX6Sc6Rcw==
systemFlags: 16
dn: CN=ms-DS-UpdateScript,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-UpdateScript
adminDisplayName: ms-DS-UpdateScript
adminDescription: ms-DS-UpdateScript
attributeId: 1.2.840.113556.1.4.1721
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ObZuFJ+7wU+oJeKeAMd5IA==
systemFlags: 16
dn: CN=ms-DS-ReplicationEpoch,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ReplicationEpoch
adminDisplayName: ms-DS-ReplicationEpoch
adminDescription: ms-DS-ReplicationEpoch
attributeId: 1.2.840.113556.1.4.1720
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: earjCBzrtUWve4+UJGyOQQ==
systemFlags: 17
dn: CN=ms-DS-Additional-Dns-Host-Name,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AdditionalDnsHostName
adminDisplayName: ms-DS-Additional-Dns-Host-Name
adminDescription: ms-DS-Additional-Dns-Host-Name
attributeId: 1.2.840.113556.1.4.1717
omSyntax: 64
systemOnly: TRUE
searchFlags: 0
rangeLower: 0
rangeUpper: 2048
schemaIdGuid:: kTeGgOnbuE6Dfn8KtV2axw==
systemFlags: 16
dn: CN=ms-DS-Additional-Sam-Account-Name,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AdditionalSamAccountName
adminDisplayName: ms-DS-Additional-Sam-Account-Name
adminDescription: ms-DS-Additional-Sam-Account-Name
attributeId: 1.2.840.113556.1.4.1718
omSyntax: 64
systemOnly: TRUE
searchFlags: 13
rangeLower: 0
rangeUpper: 256
schemaIdGuid:: 33FVl9WkmkKfWc3GWB2R5g==
systemFlags: 16
dn: CN=Hide-From-AB,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: hideFromAB
adminDisplayName: Hide-From-AB
adminDescription: Hide-From-AB
attributeId: 1.2.840.113556.1.4.1780
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ULcF7Hep/k6OjbpsGm4zqA==
systemFlags: 0
dn: CN=ms-DS-ExecuteScriptPassword,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ExecuteScriptPassword
adminDisplayName: ms-DS-ExecuteScriptPassword
adminDescription: ms-DS-ExecuteScriptPassword
attributeId: 1.2.840.113556.1.4.1783
omSyntax: 4
systemOnly: TRUE
searchFlags: 0
rangeLower: 0
rangeUpper: 64
schemaIdGuid:: WkoFnYfRwUadhULfxEpW3Q==
systemFlags: 17
ldapDisplayName: preferredLanguage
-
adminDisplayName: preferredLanguage
-
dn: CN=Code-Page,CN=Schema,CN=Configuration,DC=X
replace: rangeLower
rangeLower: 0
-
replace: rangeUpper
rangeUpper: 65535
-
dn:
schemaUpdateNow: 1
-
# class changes
-
-
-
-
dn: CN=ms-TAPI-Rt-Conference,CN=Schema,CN=Configuration,DC=X
(A;;RPLCLORC;;;AU)
-
(A;;RPLCLORC;;;AU)
-
dn:
schemaUpdateNow: 1
-
# change objects in configuration container
objectVersion: 20
-
Sch21.ldf
# attributes
dn: CN=ms-DS-Logon-Time-Sync-Interval,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-LogonTimeSyncInterval
adminDisplayName: ms-DS-Logon-Time-Sync-Interval
adminDescription: ms-DS-Logon-Time-Sync-Interval
attributeId: 1.2.840.113556.1.4.1784
oMSyntax: 2
rangeLower: 0
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: +EB5rTrkQkqDvNaI5Z6mBQ==
systemFlags: 16
dn: CN=ms-DS-Allowed-To-Delegate-To,CN=Schema,CN=Configuration,DC=X
lDAPDisplayName: msDS-AllowedToDelegateTo
adminDisplayName: ms-DS-Allowed-To-Delegate-To
adminDescription: Allowed-To-Delegate-To contains a list of SPNs that are used for Constrained Delegation
attributeId: 1.2.840.113556.1.4.1787
oMSyntax: 64
searchFlags: 0
systemOnly: FALSE
schemaIdGuid:: 15QNgKG3oUKxTXyuFCPQfw==
systemFlags: 16
dn: CN=ms-IIS-FTP-Root,CN=Schema,CN=Configuration,DC=X
adminDescription: Virtual FTP Root where user home directory resides.
adminDisplayName: ms-IIS-FTP-Root
attributeID: 1.2.840.113556.1.4.1785
instanceType: 4
lDAPDisplayName: msIIS-FTPRoot
oMSyntax: 64
rangeLower: 1
rangeUpper: 256
searchFlags: 0
schemaIdGuid:: pCd4KoMUpUmdhFLjgSFWtA==
systemOnly: FALSE
systemFlags: 16
dn: CN=ms-IIS-FTP-Dir,CN=Schema,CN=Configuration,DC=X
changetype: ntdsSchemaadd
adminDescription: Relative user directory on an FTP Root share.
adminDisplayName: ms-IIS-FTP-Dir
attributeID: 1.2.840.113556.1.4.1786
instanceType: 4
lDAPDisplayName: msIIS-FTPDir
oMSyntax: 64
rangeLower: 1
rangeUpper: 256
searchFlags: 0
schemaIdGuid:: 6ZlcijAi60a46OWdcS657g==
systemOnly: FALSE
systemFlags: 16
dn: CN=dhcp-Servers,CN=Schema,CN=Configuration,DC=X
replace: extendedCharsAllowed
extendedCharsAllowed: TRUE
-
dn: CN=Extended-Chars-Allowed,CN=Schema,CN=Configuration,DC=X
replace: systemOnly
systemOnly: FALSE
-
dn:
schemaUpdateNow: 1
-
# classes
-
-
-
-
-
dn:
schemaUpdateNow: 1
-
objectVersion: 21
-
Sch22.ldf
# attributes
dn: CN=uid,CN=Schema,CN=Configuration,DC=X
systemFlags: 0
-
dn: CN=audio,CN=Schema,CN=Configuration,DC=X
systemFlags: 0
-
dn: CN=photo,CN=Schema,CN=Configuration,DC=X
systemFlags: 0
-
dn: CN=jpegPhoto,CN=Schema,CN=Configuration,DC=X
systemFlags: 0
-
dn: CN=userPKCS12,CN=Schema,CN=Configuration,DC=X
systemFlags: 0
-
systemFlags: 0
-
dn: CN=roomNumber,CN=Schema,CN=Configuration,DC=X
systemFlags: 0
-
dn: CN=uniqueMember,CN=Schema,CN=Configuration,DC=X
systemFlags: 0
-
dn: CN=departmentNumber,CN=Schema,CN=Configuration,DC=X
systemFlags: 0
-
dn: CN=unstructuredName,CN=Schema,CN=Configuration,DC=X
systemFlags: 0
-
systemFlags: 0
-
dn: CN=x500uniqueIdentifier,CN=Schema,CN=Configuration,DC=X
systemFlags: 0
-
dn: CN=unstructuredAddress,CN=Schema,CN=Configuration,DC=X
systemFlags: 0
-
dn: CN=attributeCertificateAttribute,CN=Schema,CN=Configuration,DC=X
systemFlags: 0
-
attributeSecurityGuid:: R5Xjchh70RGt7wDAT9jVzQ==
-
dn: CN=ms-DS-Additional-Dns-host-name,CN=Schema,CN=Configuration,DC=X
attributeSecurityGuid:: R5Xjchh70RGt7wDAT9jVzQ==
-
dn: CN=MS-DS-Per-User-Trust-Quota,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PerUserTrustQuota
ldapDisplayName: msDS-PerUserTrustQuota
adminDisplayName: MS-DS-Per-User-Trust-Quota
adminDescription: Used to enforce a per-user quota for creating Trusted-Domain objects authorized by the
control access right, "Create inbound Forest trust". This attribute limits the number of Trusted-Domain
objects that can be created by a single non-admin user in the domain.
attributeId: 1.2.840.113556.1.4.1788
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 8K1h0STKk0mjqossmBMC6A==
systemFlags: 16
dn: CN=MS-DS-All-Users-Trust-Quota,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AllUsersTrustQuota
adminDisplayName: MS-DS-All-Users-Trust-Quota
adminDescription: Used to enforce a combined users quota on the total number of Trusted-Domain objects
created by using the control access right, "Create inbound Forest trust".
attributeId: 1.2.840.113556.1.4.1789
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: XEqq0wNOEEiXqisznnpDSw==
systemFlags: 16
dn: CN=MS-DS-Per-User-Trust-Tombstones-Quota,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PerUserTrustTombstonesQuota
adminDisplayName: MS-DS-Per-User-Trust-Tombstones-Quota
adminDescription: Used to enforce a per-user quota for deleting Trusted-Domain objects when authorization is
based on matching the user's SID to the value of MS-DS-Creator-SID on the Trusted-Domain object.
attributeId: 1.2.840.113556.1.4.1790
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: xqZwi/lQo0+nHhzgMEBEmw==
systemFlags: 16
dn: CN=ms-DS-Logon-Time-Sync-Interval,CN=Schema,CN=Configuration,DC=X
replace: rangeLower
rangeLower: 0
-
# Reload the schema cache to pick up attributes
dn:
schemaUpdateNow: 1
-
# classes
systemFlags: 0
systemFlags: 0
-
systemFlags: 0
-
-
-
-
-
-
-
-
-
-
dn: CN=Device,CN=Schema,CN=Configuration,DC=X
-
-
dn:
schemaUpdateNow: 1
-
displayName: DNS Host Name Attributes
rightsGUID: 72e39547-7b18-11d1-adef-00c04fd8d5cd
validAccesses: 48
dn: CN=Create-Inbound-Forest-Trust,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Create Inbound Forest Trust
rightsGUID: e2a36dc9-ae17-47c3-b58b-be34c55ba633
validAccesses: 256
dn: CN=Configuration,DC=X
delete: wellKnownObjects
wellKnownObjects: B:32:ab8153b7768811d1aded00c04fd8d5cd:CN=LostAndFound,CN=Configuration,DC=X
-
dn: CN=Configuration,DC=X
add: wellKnownObjects
wellKnownObjects: B:32:ab8153b7768811d1aded00c04fd8d5cd:CN=LostAndFoundConfig,CN=Configuration,DC=X
-
objectVersion: 22
-
Sch23.ldf
# attributes
dn: CN=Script-Path,CN=Schema,CN=Configuration,DC=X
-
dn: CN=User-Workstations,CN=Schema,CN=Configuration,DC=X
-
dn:
schemaUpdateNow: 1
-
# classes
replace:defaultHidingValue
-
-
-
-
dn:
schemaUpdateNow: 1
-
dn: CN=DS-Replication-Get-Changes-All,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Replicating Directory Changes All
rightsGUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
validAccesses: 256
objectVersion: 23
-
Sch24.ldf
# attributes
systemFlags: 0
-
systemFlags: 0
-
systemFlags: 0
-
systemFlags: 0
-
dn: CN=Lockout-Threshold,CN=Schema,CN=Configuration,DC=X
replace: rangeUpper
rangeUpper: 65535
-
dn: CN=ms-ds-dnsrootalias,CN=Schema,CN=Configuration,DC=X
replace: rangeUpper
rangeUpper: 255
-
dn: CN=ms-DS-Az-LDAP-Query,CN=Schema,CN=Configuration,DC=X
attributeID: 1.2.840.113556.1.4.1792
rangeLower: 0
rangeUpper: 4096
adminDisplayName: MS-DS-Az-LDAP-Query
adminDescription: ms-DS-Az-LDAP-Query
oMSyntax: 64
searchFlags: 0
lDAPDisplayName: msDS-AzLDAPQuery
schemaIDGUID:: izZTXpT8yEWdfdrzHucRLQ==
systemOnly: FALSE
systemFlags: 16
dn: CN=ms-DS-Non-Members,CN=Schema,CN=Configuration,DC=X
attributeID: 1.2.840.113556.1.4.1793
linkID: 2014
adminDisplayName: MS-DS-Non-Members
adminDescription: ms-DS-Non-Members
oMSyntax: 127
searchFlags: 0
lDAPDisplayName: msDS-NonMembers
schemaIDGUID:: 3rH8yjzytUat9x5klXvV2w==
systemOnly: FALSE
systemFlags: 16
dn: CN=ms-DS-Non-Members-BL,CN=Schema,CN=Configuration,DC=X
attributeID: 1.2.840.113556.1.4.1794
linkID: 2015
adminDisplayName: MS-DS-Non-Members-BL
adminDescription: ms-DS-Non-Members-BL
oMSyntax: 127
searchFlags: 0
lDAPDisplayName: msDS-NonMembersBL
schemaIDGUID:: /GiMKno6h06HIP53xRy+dA==
systemOnly: TRUE
systemFlags: 16
dn:
schemaUpdateNow: 1
-
# classes
-
-
dn:
schemaUpdateNow: 1
-

dn: CN=Migrate-SID-History,CN=Extended-Rights,CN=Configuration,DC=X
displayName:Migrate SID History
rightsGUID: BA33815A-4F93-4c76-87F3-57574BFF8109
validAccesses: 256
objectVersion: 24
-
Sch25.ldf
dn: CN=ms-DS-Az-Class-ID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzClassId
adminDisplayName: MS-DS-Az-Class-ID
adminDescription: A class ID required by the AzRoles UI on the AzApplication object
attributeId: 1.2.840.113556.1.4.1816
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 40
schemaIdGuid:: d3I6AS1c70mn3rdls2o/bw==
systemFlags: 16
dn: CN=ms-DS-Az-Biz-Rule,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzBizRule
adminDisplayName: MS-DS-Az-Biz-Rule
adminDescription: Text of the script implementing the business rule
attributeId: 1.2.840.113556.1.4.1801
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 65536
schemaIdGuid:: qB7UM8nAkkyUlPEEh4QT/Q==
systemFlags: 16
dn: CN=ms-DS-Az-Scope-Name,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzScopeName
adminDisplayName: MS-DS-Az-Scope-Name
adminDescription: A string that uniquely identifies a scope object
attributeId: 1.2.840.113556.1.4.1799
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 65536
schemaIdGuid:: BmtaURcmc0GAmdVgXfBDxg==
systemFlags: 16
dn: CN=ms-DS-Az-Operation-ID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzOperationID
adminDisplayName: MS-DS-Az-Operation-ID
adminDescription: Application specific ID that makes the operation unique to the application
attributeId: 1.2.840.113556.1.4.1800
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
schemaIdGuid:: U7XzpXZdvky6P0MSFSyrGA==
systemFlags: 16
dn: CN=ms-DS-Tasks-For-Az-Role,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-TasksForAzRole
adminDisplayName: MS-DS-Tasks-For-Az-Role
adminDescription: List of tasks for Az-Role
attributeId: 1.2.840.113556.1.4.1814
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: gpAxNUqMRkaThsKUnUmJTQ==
linkID: 2024
systemFlags: 16
dn: CN=ms-DS-Tasks-For-Az-Task,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-TasksForAzTask
adminDisplayName: MS-DS-Tasks-For-Az-Task
adminDescription: List of tasks linked to Az-Task
attributeId: 1.2.840.113556.1.4.1810
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 4o4csc1fp0aV8PODM/CWzw==
linkID: 2020
systemFlags: 16
dn: CN=ms-DS-Az-Domain-Timeout,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzDomainTimeout
adminDisplayName: MS-DS-Az-Domain-Timeout
adminDescription: Time (in ms) after a domain is detected to be un-reachable, and before the DC is tried
again
attributeId: 1.2.840.113556.1.4.1795
attributeId: 1.2.840.113556.1.4.1795
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
schemaIdGuid:: avVIZHDKLk6wr9IOTOZT0A==
systemFlags: 16
dn: CN=ms-DS-Az-Script-Timeout,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzScriptTimeout
adminDisplayName: MS-DS-Az-Script-Timeout
adminDescription: Maximum time (in ms) to wait for a script to finish auditing a specific policy
attributeId: 1.2.840.113556.1.4.1797
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
schemaIdGuid:: QfvQh4ss9kG5chH9/VDWsA==
systemFlags: 16
dn: CN=ms-DS-Az-Generate-Audits,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzGenerateAudits
adminDisplayName: MS-DS-Az-Generate-Audits
adminDescription: A boolean field indicating if runtime audits need to be turned on (include audits for
access checks, etc.)
attributeId: 1.2.840.113556.1.4.1805
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: sLoK+WwYGES7hYhEfIciKg==
systemFlags: 16
dn: CN=ms-DS-Members-For-Az-Role,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-MembersForAzRole
adminDisplayName: MS-DS-Members-For-Az-Role
adminDescription: List of member application groups or users linked to Az-Role
attributeId: 1.2.840.113556.1.4.1806
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: zeb3y6SFFEOJOYv+gFl4NQ==
linkID: 2016
systemFlags: 16
dn: CN=ms-DS-KeyVersionNumber,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-KeyVersionNumber
adminDisplayName: ms-DS-KeyVersionNumber
adminDescription: The Kerberos version number of the current key for this account. This is a constructed
attribute.
attribute.
attributeId: 1.2.840.113556.1.4.1782
omSyntax: 2
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: wOkjxbUzyEqJI7V7kn9C9g==
systemFlags: 20
dn: CN=ms-DS-Az-Application-Data,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzApplicationData
adminDisplayName: MS-DS-Az-Application-Data
adminDescription: A string that is used by individual applications to store whatever information they may
need to
attributeId: 1.2.840.113556.1.4.1819
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
schemaIdGuid:: 6MM/UMYcGkaZo57uBPQCpw==
systemFlags: 16
dn: CN=ms-DS-Az-Application-Name,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzApplicationName
adminDisplayName: MS-DS-Az-Application-Name
adminDescription: A string that uniquely identifies an application object
attributeId: 1.2.840.113556.1.4.1798
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 512
schemaIdGuid:: KAdb2whidkiDt5XT5WlSdQ==
systemFlags: 16
dn: CN=ms-DS-Az-Biz-Rule-Language,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzBizRuleLanguage
adminDisplayName: MS-DS-Az-Biz-Rule-Language
adminDescription: Language that the business rule script is in (Jscript, VBScript)
attributeId: 1.2.840.113556.1.4.1802
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 64
schemaIdGuid:: VkuZUmwOB06qXO+df1oOJQ==
systemFlags: 16
dn: CN=ms-DS-Operations-For-Az-Role,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-OperationsForAzRole
ldapDisplayName: msDS-OperationsForAzRole
adminDisplayName: MS-DS-Operations-For-Az-Role
adminDescription: List of operations linked to Az-Role
attributeId: 1.2.840.113556.1.4.1812
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: vgH3k0z6tkO8L02+pxj/qw==
linkID: 2022
systemFlags: 16
dn: CN=ms-DS-Operations-For-Az-Task,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-OperationsForAzTask
adminDisplayName: MS-DS-Operations-For-Az-Task
adminDescription: List of operations linked to Az-Task
attributeId: 1.2.840.113556.1.4.1808
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: NrSsGp0uqUSSmM5N6+tuvw==
linkID: 2018
systemFlags: 16
dn: CN=ms-DS-Az-Application-Version,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzApplicationVersion
adminDisplayName: MS-DS-Az-Application-Version
adminDescription: A version number to indicate that the AzApplication is updated
attributeId: 1.2.840.113556.1.4.1817
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
schemaIdGuid:: IKGEccQ6rkeEj/4KsgeE1A==
systemFlags: 16
dn: CN=ms-DS-Az-Script-Engine-Cache-Max,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzScriptEngineCacheMax
adminDisplayName: MS-DS-Az-Script-Engine-Cache-Max
adminDescription: Maximum number of scripts that are cached by the application
attributeId: 1.2.840.113556.1.4.1796
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
schemaIdGuid:: avYpJpUf80uilo6de54wyA==
systemFlags: 16
dn: CN=ms-DS-Az-Task-Is-Role-Definition,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzTaskIsRoleDefinition
adminDisplayName: MS-DS-Az-Task-Is-Role-Definition
adminDescription: A Boolean field which indicates whether AzTask is a classic task or a role definition
attributeId: 1.2.840.113556.1.4.1818
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: RIUHe4Js6U+HL/9IrSsuJg==
systemFlags: 16
dn: CN=ms-DS-Az-Last-Imported-Biz-Rule-Path,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzLastImportedBizRulePath
adminDisplayName: MS-DS-Az-Last-Imported-Biz-Rule-Path
adminDescription: Last imported business rule path
attributeId: 1.2.840.113556.1.4.1803
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 65536
schemaIdGuid:: XMtaZpK7vE2MWbNjjqsJsw==
systemFlags: 16
dn:
schemaUpdateNow: 1
-
dn: CN=ms-DS-Tasks-For-Az-Role-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-TasksForAzRoleBL
adminDisplayName: MS-DS-Tasks-For-Az-Role-BL
adminDescription: Back-link from Az-Task to Az-Role object(s) linking to it
attributeId: 1.2.840.113556.1.4.1815
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: NtXcoFhR/kKMQMAKetN5WQ==
linkID: 2025
systemFlags: 16
dn: CN=ms-DS-Tasks-For-Az-Task-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-TasksForAzTaskBL
adminDisplayName: MS-DS-Tasks-For-Az-Task-BL
adminDescription: Back-link from Az-Task to the Az-Task object(s) linking to it
attributeId: 1.2.840.113556.1.4.1811
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: Um5E3/q1okykLxP5ilJsjw==
linkID: 2021
systemFlags: 16
dn: CN=ms-DS-Members-For-Az-Role-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-MembersForAzRoleBL
adminDisplayName: MS-DS-Members-For-Az-Role-BL
adminDescription: Back-link from member application group or user to Az-Role object(s) linking to it
attributeId: 1.2.840.113556.1.4.1807
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: IM3s7OCniEaczwLs5eKH9Q==
linkID: 2017
systemFlags: 16
dn: CN=ms-DS-Operations-For-Az-Role-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-OperationsForAzRoleBL
adminDisplayName: MS-DS-Operations-For-Az-Role-BL
adminDescription: Back-link from Az-Operation to Az-Role object(s) linking to it
attributeId: 1.2.840.113556.1.4.1813
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: KGJb+DQ3JUW2tz87siCQLA==
linkID: 2023
systemFlags: 16
dn: CN=ms-DS-Operations-For-Az-Task-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-OperationsForAzTaskBL
adminDisplayName: MS-DS-Operations-For-Az-Task-BL
adminDescription: Back-link from Az-Operation to Az-Task object(s) linking to it
attributeId: 1.2.840.113556.1.4.1809
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: EdI3pjlX0U6JsoiXRUi8WQ==
linkID: 2019
systemFlags: 16
dn:
schemaUpdateNow: 1
-
dn: CN=ms-DS-Az-Admin-Manager,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzAdminManager
adminDisplayName: MS-DS-Az-Admin-Manager
adminDescription: Root of Authorization Policy store instance
governsId: 1.2.840.113556.1.5.234
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: URDuzyhfrkuoY10MwYqO0Q==
(A;;RPLCLORC;;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;CO)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Az-Admin-Manager,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Az-Application,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzApplication
adminDisplayName: MS-DS-Az-Application
adminDescription: Defines an installed instance of an application bound to a particular policy store.
governsId: 1.2.840.113556.1.5.235
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: m9743aXLEk6ELijYtm917A==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Az-Application,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Az-Scope,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzScope
adminDisplayName: MS-DS-Az-Scope
adminDescription: Describes a set of objects managed by an application
governsId: 1.2.840.113556.1.5.237
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: VODqT1XOu0eGDlsSBjpR3g==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Az-Scope,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Az-Operation,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzOperation
adminDisplayName: MS-DS-Az-Operation
adminDescription: Describes a particular operation supported by an application
governsId: 1.2.840.113556.1.5.236
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: N74KhpuapE+z0ris5d+exQ==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Az-Operation,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Az-Task,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzTask
adminDisplayName: MS-DS-Az-Task
adminDescription: Describes a set of operations
governsId: 1.2.840.113556.1.5.238
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: c6TTHhubikG/oDo3uVpTBg==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Az-Task,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Az-Role,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzRole
adminDisplayName: MS-DS-Az-Role
adminDescription: Defines a set of operations that can be performed by a particular set of users within a
particular scope
governsId: 1.2.840.113556.1.5.239
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: yeoTglWd3ESSXOmlK5J2RA==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Az-Role,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
add: mayContain
mayContain: 2.5.4.45
mayContain: 2.16.840.1.113730.3.140
mayContain: 2.16.840.1.113730.3.1.216
mayContain: 0.9.2342.19200300.100.1.1
mayContain: 0.9.2342.19200300.100.1.21
mayContain: 0.9.2342.19200300.100.1.6
mayContain: 2.16.840.1.113730.3.1.39
mayContain: 0.9.2342.19200300.100.1.7
mayContain: 0.9.2342.19200300.100.1.42
mayContain: 0.9.2342.19200300.100.1.41
mayContain: 0.9.2342.19200300.100.1.10
mayContain: 0.9.2342.19200300.100.1.3
mayContain: 1.3.6.1.4.1.250.1.57
mayContain: 0.9.2342.19200300.100.1.60
mayContain: 1.2.840.113556.1.2.617
mayContain: 0.9.2342.19200300.100.1.20
mayContain: 1.2.840.113556.1.2.613
mayContain: 1.2.840.113556.1.2.610
mayContain: 1.2.840.113556.1.2.13
mayContain: 2.16.840.1.113730.3.1.2
mayContain: 2.16.840.1.113730.3.1.1
mayContain: 0.9.2342.19200300.100.1.55
-
-
add: possSuperiors
possSuperiors: 1.2.840.113556.1.5.67
possSuperiors: 2.5.6.5
possSuperiors: 1.2.840.113556.1.3.23
-
-
add: mayContain
-
-
-
add: mayContain
mayContain: 1.2.840.113556.1.2.617
-
-
-
add: mayContain
mayContain: 2.16.840.1.113730.3.140
mayContain: 2.16.840.1.113730.3.1.216
mayContain: 0.9.2342.19200300.100.1.1
mayContain: 0.9.2342.19200300.100.1.21
mayContain: 0.9.2342.19200300.100.1.6
mayContain: 2.16.840.1.113730.3.1.39
mayContain: 0.9.2342.19200300.100.1.7
mayContain: 1.3.6.1.4.1.250.1.57
mayContain: 0.9.2342.19200300.100.1.60
mayContain: 1.2.840.113556.1.2.617
mayContain: 1.2.840.113556.1.2.613
mayContain: 1.2.840.113556.1.2.610
mayContain: 1.2.840.113556.1.2.13
mayContain: 2.16.840.1.113730.3.1.2
mayContain: 2.16.840.1.113730.3.1.1
mayContain: 0.9.2342.19200300.100.1.55
-
-
add: mayContain
-
-
add: mustContain
mustContain: 2.5.4.50
-
-
add: possSuperiors
possSuperiors: 1.2.840.113556.1.5.67
possSuperiors: 1.2.840.113556.1.3.23
-
-
add: mayContain
mayContain: 2.16.840.1.113730.3.140
-
-
dn:
schemaUpdateNow: 1
-
# Config NC changes
dn: CN=Reanimate-Tombstones,CN=Extended-Rights,CN=Configuration,DC=X
displayName:Reanimate Tombstones
rightsGUID: 45EC5156-DB7E-47bb-B53F-DBEB2D03C40F
validAccesses: 256
objectVersion: 25
-
Sch26.ldf
dn: CN=ms-ieee-80211-ID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msieee80211-ID
adminDisplayName: ms-ieee-80211-ID
adminDescription: an indentifier used for wireless policy object on AD
attributeId: 1.2.840.113556.1.4.1823
omSyntax: 64
searchFlags: 0
schemaIdGuid:: de9zf8kUI0yB3t0HoG+eiw==
systemFlags: 16
dn: CN=ms-ieee-80211-Data,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msieee80211-Data
adminDisplayName: ms-ieee-80211-Data
adminDescription: Stores list of preferred network configurations for Group Policy for Wireless
attributeId: 1.2.840.113556.1.4.1821
attributeId: 1.2.840.113556.1.4.1821
omSyntax: 4
searchFlags: 0
schemaIdGuid:: OAkNDlgmgEWp9noKx7Vmyw==
systemFlags: 16
dn: CN=ms-DS-Has-Domain-NCs,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-HasDomainNCs
adminDisplayName: ms-DS-Has-Domain-NCs
adminDescription: DS replication information detailing the domain NCs present on a particular server.
attributeId: 1.2.840.113556.1.4.1820
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
rangeLower: 4
rangeUpper: 4
schemaIdGuid:: R+MXb0KomES4sxXgB9pP7Q==
linkID: 2026
systemFlags: 16
dn: CN=ms-ieee-80211-Data-Type,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msieee80211-DataType
adminDisplayName: ms-ieee-80211-Data-Type
adminDescription: internally used data type for msieee80211-Data blob
attributeId: 1.2.840.113556.1.4.1822
omSyntax: 2
searchFlags: 0
schemaIdGuid:: gLFYZdo1/k6+7VIfj0jK+w==
systemFlags: 16
dn: CN=ms-DS-Az-Major-Version,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzMajorVersion
adminDisplayName: MS-DS-Az-Major-Version
adminDescription: Major version number for AzRoles
attributeId: 1.2.840.113556.1.4.1824
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
schemaIdGuid:: t625z7fEWUCVaB7Z22tySA==
systemFlags: 16
dn: CN=ms-DS-Az-Minor-Version,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzMinorVersion
adminDisplayName: MS-DS-Az-Minor-Version
adminDescription: Minor version number for AzRoles
attributeId: 1.2.840.113556.1.4.1825
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
schemaIdGuid:: k+2F7gmyiEeBZecC9Rv78w==
systemFlags: 16
dn:
schemaUpdateNow: 1
-
dn: CN=Locality,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Organization,CN=Schema,CN=Configuration,DC=X
-
-
dn: CN=Organizational-Role,CN=Schema,CN=Configuration,DC=X
-
-
dn: CN=Residential-Person,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Application-Process,CN=Schema,CN=Configuration,DC=X
-
dn: CN=Application-Entity,CN=Schema,CN=Configuration,DC=X
-
-
-
dn:
schemaUpdateNow: 1
-
dn: CN=ms-ieee-80211-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msieee80211-Policy
adminDisplayName: ms-ieee-80211-Policy
adminDescription: class to store Wireless Network Policy Object
governsId: 1.2.840.113556.1.5.240
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: ki2ae+u3gkOXcsPg+bqvlA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-ieee-80211-Policy,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
-
-
-
-
-
-
dn:
schemaUpdateNow: 1
-
appliesTo: 4828cc14-1437-45bc-9b07-ad6f015e5f28
displayName: Allowed to Authenticate
rightsGUID: 68B1D179-0D15-4d4f-AB71-46152E79A7BC
validAccesses: 256
objectVersion: 26
-
Sch27.ldf
dn: CN=ms-Exch-House-Identifier,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msExchHouseIdentifier
adminDisplayName: ms-Exch-House-Identifier
adminDescription: ms-Exch-House-Identifier
attributeId: 1.2.840.113556.1.2.596
omSyntax: 64
searchFlags: 0
rangeLower: 1
rangeUpper: 128
schemaIdGuid:: B3TfqOrF0RG7ywCAx2ZwwA==
mapiID: 35924
dn: CN=ms-Exch-House-Identifier,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msExchHouseIdentifier
-
dn: CN=host,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: host
adminDisplayName: host
adminDescription: The host attribute type specifies a host computer.
attributeId: 0.9.2342.19200300.100.1.9
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: cd9DYEj6z0arfMvVRkSyLQ==
dn: CN=drink,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: drink
adminDisplayName: drink
adminDescription: The drink (Favourite Drink) attribute type specifies the favorite drink of an object (or
person).
attributeId: 0.9.2342.19200300.100.1.5
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: taUaGi4m9k2vBCz2sNgASA==
dn: CN=userClass,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: userClass
adminDisplayName: userClass
adminDescription: The userClass attribute type specifies a category of computer user.
attributeId: 0.9.2342.19200300.100.1.8
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: iipzEU3hxUy5L9k/UcbY5A==
dn: CN=ms-DS-Integer,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-Integer
adminDisplayName: ms-DS-Integer
adminDescription: An attribute for storing an integer.
attributeId: 1.2.840.113556.1.4.1835
omSyntax: 2
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 6kzGe07AGEOxAj4HKTcaZQ==
dn: CN=buildingName,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: buildingName
adminDisplayName: buildingName
adminDescription: The buildingName attribute type specifies the name of the building where an organization
or organizational unit is based.
attributeId: 0.9.2342.19200300.100.1.48
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: S6V/+MWy10+IwNrMsh2TxQ==
dn: CN=ms-DS-Date-Time,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-DateTime
adminDisplayName: ms-DS-Date-Time
adminDescription: An attribute for storing a data and time value.
attributeId: 1.2.840.113556.1.4.1832
omSyntax: 24
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 2MtPI1L7CEmjKP2fbljkAw==
dn: CN=documentTitle,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: documentTitle
adminDisplayName: documentTitle
adminDescription: The documentTitle attribute type specifies the title of a document.
attributeId: 0.9.2342.19200300.100.1.12
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: nFom3iz/uUeR3G5v4sQwYg==
dn: CN=ms-DS-Byte-Array,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ByteArray
adminDisplayName: ms-DS-Byte-Array
adminDescription: An attribute for storing binary data.
attributeId: 1.2.840.113556.1.4.1831
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeUpper: 1000000
rangeUpper: 1000000
schemaIdGuid:: LpfY8Fvd5UClHQRMfBfs5w==
dn: CN=associatedName,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: associatedName
adminDisplayName: associatedName
adminDescription: The associatedName attribute type specifies an entry in the organizational DIT associated
with a DNS domain.
attributeId: 0.9.2342.19200300.100.1.38
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Rfz796uFpEKkNXgOYveFiw==
dn: CN=documentAuthor,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: documentAuthor
adminDisplayName: documentAuthor
adminDescription: The documentAuthor attribute type specifies the distinguished name of the author of a
document.
attributeId: 0.9.2342.19200300.100.1.14
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: GY6K8V+veESwlm81wn64Pw==
dn: CN=houseIdentifier,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: houseIdentifier
adminDisplayName: houseIdentifier
adminDescription: The houseIdentifier attribute type specifies a linguistic construct used to identify a
particular building, for example a house number or house name relative to a street, avenue, town or city,
etc.
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 32768
schemaIdGuid:: t5hTpErEtk6C0xPBCUbb/g==
dn: CN=documentVersion,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: documentVersion
adminDisplayName: documentVersion
adminDescription: The documentVersion attribute type specifies the version number of a document.
attributeId: 0.9.2342.19200300.100.1.13
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: qaizlBPW7EyarV+8wQRrQw==
dn: CN=ms-DS-External-Key,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ExternalKey
adminDisplayName: ms-DS-External-Key
adminDescription: A string to identifiy an object in an external store such as a record in a database.
attributeId: 1.2.840.113556.1.4.1833
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 10000
schemaIdGuid:: KNUvuaw41ECBjQQzOAg3wQ==
dn: CN=associatedDomain,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: associatedDomain
adminDisplayName: associatedDomain
adminDescription: The associatedDomain attribute type specifies a DNS domain which is associated with an
object.
attributeId: 0.9.2342.19200300.100.1.37
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 256
schemaIdGuid:: OPwgM3nDF0ylEBvfYTPF2g==
dn: CN=documentLocation,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: documentLocation
adminDisplayName: documentLocation
adminDescription: The documentLocation attribute type specifies the location of the document original.
attributeId: 0.9.2342.19200300.100.1.15
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: TrFYuW2sxE6Ikr5wtp9ygQ==
dn: CN=uniqueIdentifier,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: uniqueIdentifier
adminDisplayName: uniqueIdentifier
adminDescription: The uniqueIdentifier attribute type specifies a "unique identifier" for an object
represented in the Directory.
attributeId: 0.9.2342.19200300.100.1.44
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
rangeUpper: 256
schemaIdGuid:: x4QBusU47UulJnVCFHBYDA==
dn: CN=ms-DS-Has-Master-NCs,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-hasMasterNCs
adminDisplayName: ms-DS-Has-Master-NCs
adminDescription: A list of the naming contexts contained by a DC. Deprecates hasMasterNCs.
attributeId: 1.2.840.113556.1.4.1836
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: 4uAtrtdZR02NR+1N/kNXrQ==
linkID: 2036
systemFlags: 16
dn: CN=documentPublisher,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: documentPublisher
adminDisplayName: documentPublisher
adminDescription: The documentPublisher attribute is the person and/or organization that published a
document.
attributeId: 0.9.2342.19200300.100.1.56
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: 1wkPF2nrikSaMPGv7P0y1w==
dn: CN=ms-DS-External-Store,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ExternalStore
adminDisplayName: ms-DS-External-Store
adminDescription: A string to identifiy the location of an external store such as a database.
attributeId: 1.2.840.113556.1.4.1834
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 10000
schemaIdGuid:: zXdIYNucx0ewPT2q2wRJEA==
dn: CN=documentIdentifier,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: documentIdentifier
adminDisplayName: documentIdentifier
adminDescription: The documentIdentifier attribute type specifies a unique identifier for a document.
attributeId: 0.9.2342.19200300.100.1.11
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: gs4hC2P/2UaQ+8i58k6XuQ==
dn: CN=ms-DS-Object-Reference,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ObjectReference
adminDisplayName: ms-DS-Object-Reference
adminDescription: A link to the object that uses the data stored in the object that contains this attribute.
attributeId: 1.2.840.113556.1.4.1840
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 6MKOY+cinECF0hGyG+5y3g==
linkID: 2038
dn: CN=organizationalStatus,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: organizationalStatus
adminDisplayName: organizationalStatus
adminDescription: The organizationalStatus attribute type specifies a category by which a person is often
referred to in an organization.
attributeId: 0.9.2342.19200300.100.1.45
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
rangeUpper: 256
schemaIdGuid:: GWBZKElzL02t/1pimWH5Qg==
dn: CN=ms-DS-Retired-Repl-NC-Signatures,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-RetiredReplNCSignatures
adminDisplayName: ms-DS-Retired-Repl-NC-Signatures
adminDescription: Information about naming contexts that are no longer held on this computer
attributeId: 1.2.840.113556.1.4.1826
omSyntax: 4
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: BlWz1dYZJk2a+xE1esmbXg==
systemFlags: 17
dn: CN=simpleSecurityObject,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: simpleSecurityObject
adminDisplayName: simpleSecurityObject
adminDescription: The simpleSecurityObject object class is used to allow an entry to have a userPassword
attribute when an entry's principal object classes do not allow userPassword as an attribute type.
governsId: 0.9.2342.19200300.100.4.19
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: C5vmX0bhFU+wq8Hl1IjglA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=simpleSecurityObject,CN=Schema,CN=Configuration,DC=X
add: rangeUpper
rangeUpper: 32768
-
dn: CN=Certificate-Revocation-List,CN=Schema,CN=Configuration,DC=X
add: rangeUpper
-
dn: CN=Authority-Revocation-List,CN=Schema,CN=Configuration,DC=X
add: rangeUpper
-
dn: CN=Crl-Partitioned-Revocation-List,CN=Schema,CN=Configuration,DC=X
add: rangeUpper
-
dn: CN=Delta-Revocation-List,CN=Schema,CN=Configuration,DC=X
add: rangeUpper
-
dn: CN=Cross-Certificate-Pair,CN=Schema,CN=Configuration,DC=X
add: rangeUpper
rangeUpper: 32768
-
dn: CN=ms-PKI-OID-CPS,CN=Schema,CN=Configuration,DC=X
add: rangeUpper
rangeUpper: 32768
-
dn: CN=ms-PKI-OID-User-Notice,CN=Schema,CN=Configuration,DC=X
add: rangeUpper
rangeUpper: 32768
-
add: rangeUpper
rangeUpper: 32768
-
add: rangeUpper
rangeUpper: 1024
-
dn: CN=ms-DS-Settings,CN=Schema,CN=Configuration,DC=X
add: rangeUpper
add: rangeUpper
rangeUpper: 1000000
-
systemFlags: 0
-
dn: CN=PKT,CN=Schema,CN=Configuration,DC=X
add: rangeUpper
-
add: rangeUpper
rangeUpper: 64
-
add: rangeUpper
rangeUpper: 32768
-
add: rangeUpper
rangeUpper: 1048576
-
dn: CN=MSMQ-Sign-Certificates-Mig,CN=Schema,CN=Configuration,DC=X
add: rangeUpper
rangeUpper: 1048576
-
dn:
schemaUpdateNow: 1
-
dn: CN=ms-DS-Mastered-By,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDs-masteredBy
adminDisplayName: ms-DS-Mastered-By
adminDescription: Back link for msDS-hasMasterNCs.
attributeId: 1.2.840.113556.1.4.1837
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: aUcjYBlIFUahsknS8RmstQ==
linkID: 2037
systemFlags: 17
dn: CN=ms-DS-Object-Reference-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ObjectReferenceBL
adminDisplayName: ms-DS-Object-Reference-BL
adminDescription: Back link for ms-DS-Object-Reference.
attributeId: 1.2.840.113556.1.4.1841
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: FSVwK/fBO0uxSMDkxs7stA==
linkID: 2039
systemFlags: 1
dn:
schemaUpdateNow: 1
-
dn: CN=ms-DS-App-Data,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AppData
adminDisplayName: ms-DS-App-Data
adminDescription: Stores data that is to be used by an object. For example, profile information for a user
object.
governsId: 1.2.840.113556.1.5.241
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.7000.49
mayContain: 1.2.840.113556.1.4.1840
mayContain: 1.2.840.113556.1.4.1835
mayContain: 1.2.840.113556.1.4.1832
mayContain: 1.2.840.113556.1.4.1831
mayContain: 1.2.840.113556.1.4.653
mayContain: 1.2.840.113556.1.4.48
possSuperiors: 1.2.840.113556.1.3.30
possSuperiors: 1.2.840.113556.1.3.23
schemaIdGuid:: YddnnifjVU28lWgvh14vjg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-App-Data,CN=Schema,CN=Configuration,DC=X
dn: CN=rFC822LocalPart,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: rFC822LocalPart
adminDisplayName: rFC822LocalPart
adminDescription: The rFC822LocalPart object class is used to define entries which represent the local part
of mail addresses.
governsId: 0.9.2342.19200300.100.4.14
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.66
mayContain: 2.5.4.9
mayContain: 2.5.4.4
mayContain: 2.5.4.3
possSuperiors: 1.2.840.113556.1.3.23
schemaIdGuid:: eDo+ua7LXkige170rlBWhg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=rFC822LocalPart,CN=Schema,CN=Configuration,DC=X
dn: CN=room,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: room
adminDisplayName: room
adminDescription: The room object class is used to define entries representing rooms.
governsId: 0.9.2342.19200300.100.4.7
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.2.840.113556.1.4.222
mayContain: 0.9.2342.19200300.100.1.6
possSuperiors: 1.2.840.113556.1.3.23
schemaIdGuid:: 0uVgeLDIu0y9RdlFW+uSBg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=room,CN=Schema,CN=Configuration,DC=X
dn: CN=documentSeries,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: documentSeries
adminDisplayName: documentSeries
adminDescription: The documentSeries object class is used to define an entry which represents a series of
documents.
governsId: 0.9.2342.19200300.100.4.9
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 2.5.4.7
possSuperiors: 1.2.840.113556.1.3.23
schemaIdGuid:: fOArei8wlku8kAeV1miF+A==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=documentSeries,CN=Schema,CN=Configuration,DC=X
dn: CN=friendlyCountry,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: friendlyCountry
adminDisplayName: friendlyCountry
adminDescription: The friendlyCountry object class is used to define country entries in the DIT.
governsId: 0.9.2342.19200300.100.4.18
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.2
mustContain: 1.2.840.113556.1.2.131
schemaIdGuid:: UvGYxGvcSkefUnzbo9fTUQ==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=friendlyCountry,CN=Schema,CN=Configuration,DC=X
dn: CN=account,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: account
adminDisplayName: account
adminDescription: The account object class is used to define entries representing computer accounts.
governsId: 0.9.2342.19200300.100.4.5
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 0.9.2342.19200300.100.1.1
mayContain: 0.9.2342.19200300.100.1.9
mayContain: 2.5.4.7
possSuperiors: 1.2.840.113556.1.3.23
schemaIdGuid:: aqQoJq2m4Eq4VCsS2f5vng==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=account,CN=Schema,CN=Configuration,DC=X
dn: CN=document,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: document
adminDisplayName: document
adminDescription: The document object class is used to define entries which represent documents.
governsId: 0.9.2342.19200300.100.4.6
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 0.9.2342.19200300.100.1.11
mayContain: 0.9.2342.19200300.100.1.56
mayContain: 0.9.2342.19200300.100.1.15
mayContain: 0.9.2342.19200300.100.1.14
mayContain: 0.9.2342.19200300.100.1.13
mayContain: 0.9.2342.19200300.100.1.12
mayContain: 2.5.4.7
mayContain: 2.5.4.3
possSuperiors: 1.2.840.113556.1.3.23
schemaIdGuid:: bdm6OdbCr0uIq35CB2ABFw==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=document,CN=Schema,CN=Configuration,DC=X
dn: CN=domainRelatedObject,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: domainRelatedObject
adminDisplayName: domainRelatedObject
adminDescription: The domainRelatedObject object class is used to define an entry which represents a series
of documents.
governsId: 0.9.2342.19200300.100.4.17
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 0.9.2342.19200300.100.1.37
schemaIdGuid:: PS39i9rvSUWFLPheE3rtxg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=domainRelatedObject,CN=Schema,CN=Configuration,DC=X
add: mayContain
mayContain: 1.2.840.113556.1.4.1841
-
-
-
replace:systemOnly
systemOnly: TRUE
-
replace:systemOnly
systemOnly: TRUE
-
add: mayContain
mayContain: 1.2.840.113556.1.4.1840
-
-
-
add: mayContain
mayContain: 1.2.840.113556.1.4.653
mayContain: 1.2.840.113556.1.4.48
mayContain: 1.2.840.113556.1.4.329
mayContain: 1.2.840.113556.1.4.328
mayContain: 1.2.840.113556.1.4.141
mayContain: 1.2.840.113556.1.4.255
mayContain: 1.2.840.113556.1.4.848
-
-
add: possSuperiors
possSuperiors: 1.2.840.113556.1.3.30
possSuperiors: 1.2.840.113556.1.3.23
-
-
add: mayContain
mayContain: 1.2.840.113556.1.4.1840
mayContain: 1.2.840.113556.1.4.1835
mayContain: 1.2.840.113556.1.4.1832
mayContain: 1.2.840.113556.1.4.1831
mayContain: 1.2.840.113556.1.4.653
mayContain: 1.2.840.113556.1.4.48
-
add: possSuperiors
possSuperiors: 1.2.840.113556.1.3.30
possSuperiors: 1.2.840.113556.1.3.23
-
-
add: mayContain
mayContain: 1.2.840.113556.1.2.596
-
add: mayContain
-
-
dn:
schemaUpdateNow: 1
-
dn: CN=DS-Execute-Intentions-Script,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Execute Forest Update Script
rightsGUID: 2f16c4a5-b98e-432c-952a-cb388ba33f2e
validAccesses: 256
objectVersion: 27
-
Sch28.ldf
dn: CN=DS-Replication-Monitor-Topology,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Monitor Active Directory Replication
rightsGUID: f98340fb-7c5b-4cdb-a00b-2ebdfa115a96
validAccesses: 256
dn: CN=Update-Password-Not-Required-Bit,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Update Password Not Required Bit
rightsGUID: 280f369c-67c7-438e-ae98-1d46f3c6f541
validAccesses: 256
dn: CN=Unexpire-Password,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Unexpire Password
rightsGUID: ccc2dc7d-a6ad-4a7a-8846-c04e3cc53501
validAccesses: 256
dn: CN=Enable-Per-User-Reversibly-Encrypted-Password,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Enable Per User Reversibly Encrypted Password
rightsGUID: 05c74c5e-4deb-43b4-bd9f-86664c2a7fd5
validAccesses: 256
objectVersion: 28
-
Sch29.ldf
dn: CN=ms-DS-Max-Values,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDs-MaxValues
adminDisplayName: ms-DS-Max-Values
adminDescription: Max values allowed.
attributeId: 1.2.840.113556.1.4.1842
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
schemaIdGuid:: pGnh0enrv0mPy4rvOHRZLQ==
systemFlags: 16
dn: CN=MS-DRM-Identity-Certificate,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDRM-IdentityCertificate
adminDisplayName: ms-DRM-Identity-Certificate
adminDescription: The XrML digital rights management certificates for this user.
attributeId: 1.2.840.113556.1.4.1843
omSyntax: 4
searchFlags: 0
rangeLower: 1
rangeUpper: 10240
schemaIdGuid:: BBJe6DQ0rUGbVuKQEij/8A==
systemFlags: 16
dn:
schemaUpdateNow: 1
-
-
dn:
schemaUpdateNow: 1
-
objectVersion: 29
-
Sch30.ldf
dn: CN=ms-DS-Quota-Used,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-QuotaUsed
adminDisplayName: ms-DS-Quota-Used
adminDescription: The current quota consumed by a security principal in the directory database.
attributeId: 1.2.840.113556.1.4.1849
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: CEOotV1ht0uwXy8XRqpDnw==
systemFlags: 20
dn: CN=ms-DS-Quota-Amount,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-QuotaAmount
adminDisplayName: ms-DS-Quota-Amount
adminDescription: The assigned quota in terms of number of objects owned in the database.
attributeId: 1.2.840.113556.1.4.1845
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: DaC5+4w6M0Kc+XGJJkkDoQ==
systemFlags: 16
dn: CN=ms-DS-Default-Quota,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-DefaultQuota
adminDisplayName: ms-DS-Default-Quota
adminDescription: The default quota that will apply to a security principal creating an object in the NC if
no quota specification exists that covers the security principal.
attributeId: 1.2.840.113556.1.4.1846
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: JvcYaEtnG0SKOvQFljdM6g==
systemFlags: 16
dn: CN=ms-DS-Quota-Trustee,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-QuotaTrustee
adminDisplayName: ms-DS-Quota-Trustee
adminDescription: The SID of the security principal for which quota is being assigned.
attributeId: 1.2.840.113556.1.4.1844
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 28
schemaIdGuid:: Bok3FqVOvkmo0b/UHf9PZQ==
systemFlags: 16
dn: CN=ms-DS-Top-Quota-Usage,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-TopQuotaUsage
adminDisplayName: ms-DS-Top-Quota-Usage
adminDescription: The list of top quota users ordered by decreasing quota usage currently in the directory
database.
attributeId: 1.2.840.113556.1.4.1850
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: T858e/Xxtku36yNQSvGedQ==
systemFlags: 20
dn: CN=ms-DS-Quota-Effective,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-QuotaEffective
adminDisplayName: ms-DS-Quota-Effective
adminDescription: The effective quota for a security principal computed from the assigned quotas for a
directory partition.
attributeId: 1.2.840.113556.1.4.1848
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: UrFVZhwQtEizR+H868YBVw==
systemFlags: 20
dn: CN=MS-DRM-Identity-Certificate,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDRM-IdentityCertificate
adminDisplayName: ms-DRM-Identity-Certificate
adminDescription: The XrML digital rights management certificates for this user.
attributeId: 1.2.840.113556.1.4.1843
omSyntax: 4
searchFlags: 0
rangeLower: 1
rangeUpper: 10240
schemaIdGuid:: BBJe6DQ0rUGbVuKQEij/8A==
systemFlags: 16
dn: CN=ms-DS-Tombstone-Quota-Factor,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-TombstoneQuotaFactor
adminDisplayName: ms-DS-Tombstone-Quota-Factor
adminDescription: The factor by which tombstone object count should be reduced for the purpose of quota
accounting.
attributeId: 1.2.840.113556.1.4.1847
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 100
schemaIdGuid:: 10QXRrbzukWHU/uVUqXfMg==
systemFlags: 16
replace: rangeUpper
rangeUpper: 20480
-
dn:
schemaUpdateNow: 1
-
dn: CN=ms-DS-Quota-Container,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-QuotaContainer
adminDisplayName: ms-DS-Quota-Container
adminDescription: A special container that holds all quota specifications for the directory database.
governsId: 1.2.840.113556.1.5.242
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: T/yD2m8H6kq03I9Nq5tZkw==
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPLCLORC;;;BA)(OA;;CR;4ecc03fe-ffc0-
4947-b630-eb672a8a9dbc;;WD)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Quota-Container,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Quota-Control,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-QuotaControl
adminDisplayName: ms-DS-Quota-Control
adminDescription: A class used to represent quota specifications for the directory database.
governsId: 1.2.840.113556.1.5.243
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: JvyR3gK9UkuuJnlZmelvxw==
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPLCLORC;;;BA)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Quota-Control,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn:
schemaUpdateNow: 1
-
dn: CN=DS-Query-Self-Quota,CN=Extended-Rights,CN=Configuration,DC=X
appliesTo:da83fc4f-076f-4aea-b4dc-8f4dab9b5993
displayName:Query Self Quota
rightsGUID:4ecc03fe-ffc0-4947-b630-eb672a8a9dbc
validAccesses: 256
objectVersion: 30
-
Sch31.ldf
dn: CN=Gecos,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: gecos
adminDisplayName: gecos
adminDescription: The GECOS field; the common name (RFC 2307)
attributeId: 1.3.6.1.1.1.1.2
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 10240
schemaIdGuid:: Hz/go1UdU0KgrzDCp4Tkbg==
dn: CN=BootFile,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: bootFile
adminDisplayName: bootFile
adminDescription: Boot image name
attributeId: 1.3.6.1.1.1.1.24
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 10240
schemaIdGuid:: Tsvz4yAP60KXA9L/JuUmZw==
dn: CN=MemberUid,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: memberUid
adminDisplayName: memberUid
adminDescription: This multivalued attribute holds the login names of the members of a group.
attributeId: 1.3.6.1.1.1.1.12
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 256000
schemaIdGuid:: NrLaAy5nYU+rZPd9LcL/qw==
dn: CN=GidNumber,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: gidNumber
adminDisplayName: gidNumber
adminDescription: An integer uniquely identifying a group in an administrative domain (RFC 2307)
attributeId: 1.3.6.1.1.1.1.1
omSyntax: 2
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: DF+5xZ7sxEGEnLRll+1mlg==
dn: CN=ShadowMin,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: shadowMin
adminDisplayName: shadowMin
adminDescription: Minimum number of days between shadow changes.
attributeId: 1.3.6.1.1.1.1.6
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: N4drp6HlaEWwV9wS4Evksg==
dn: CN=UidNumber,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: uidNumber
adminDisplayName: uidNumber
adminDescription: An integer uniquely identifying a user in an administrative domain (RFC 2307)
attributeId: 1.3.6.1.1.1.1.0
omSyntax: 2
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: j8wPhWuc4Ue2cXxlS+TVsw==
dn: CN=ShadowMax,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: shadowMax
adminDisplayName: shadowMax
adminDescription: Maximum number of days password is valid.
attributeId: 1.3.6.1.1.1.1.7
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: UsmF8t1QnkSRYDuIDZmYjQ==
dn: CN=MacAddress,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: macAddress
adminDisplayName: macAddress
adminDescription: MAC address in maximal, colon separated hex notation
attributeId: 1.3.6.1.1.1.1.22
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 128
schemaIdGuid:: 3SKl5nCX4UOJ3h3lBEMo9w==
dn: CN=ShadowFlag,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: shadowFlag
adminDisplayName: shadowFlag
adminDescription: This is a part of the shadow map used to store the flag value.
attributeId: 1.3.6.1.1.1.1.11
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Dbf+jdvFtkaxXqQ4nmzumw==
dn: CN=NisMapName,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: nisMapName
adminDisplayName: nisMapName
adminDescription: The attribute contains the name of the map to which the object belongs.
attributeId: 1.3.6.1.1.1.1.26
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 1024
schemaIdGuid:: eTydlpoOlU2wrL3ef/jzoQ==
dn: CN=LoginShell,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: loginShell
adminDisplayName: loginShell
adminDescription: The path to the login shell (RFC 2307)
attributeId: 1.3.6.1.1.1.1.4
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 1024
schemaIdGuid:: LNFTpTEyXkyK340YlpdyHg==
dn: CN=msSFU-30-Name,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30Name
adminDisplayName: msSFU-30-Name
adminDescription: stores the name of a map
attributeId: 1.2.840.113556.1.6.18.1.309
omSyntax: 22
systemOnly: FALSE
searchFlags: 1
rangeUpper: 1024
schemaIdGuid:: 09HFFsI1YUCocKXO/agE8A==
schemaIdGuid:: 09HFFsI1YUCocKXO/agE8A==
dn: CN=ms-DFSR-Flags,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-Flags
adminDisplayName: ms-DFSR-Flags
adminDescription: DFSR Object Flags
attributeId: 1.2.840.113556.1.6.13.3.16
omSyntax: 2
searchFlags: 0
schemaIdGuid:: lVZR/mE/yEWb+hnBSMV7CQ==
dn: CN=NisMapEntry,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: nisMapEntry
adminDisplayName: nisMapEntry
adminDescription: This holds one map entry of a non standard map.
attributeId: 1.3.6.1.1.1.1.27
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 1024
schemaIdGuid:: biGVSsD8LkC1f1lxYmFIqQ==
dn: CN=OncRpcNumber,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: oncRpcNumber
adminDisplayName: oncRpcNumber
adminDescription: This is a part of the rpc map and stores the RPC number for UNIX RPCs.
attributeId: 1.3.6.1.1.1.1.18
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 9SVoltkBXEqgEdFa6E76VQ==
dn: CN=IpHostNumber,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ipHostNumber
adminDisplayName: ipHostNumber
adminDescription: IP address as a dotted decimal omitting leading zeros
attributeId: 1.3.6.1.1.1.1.19
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 128
schemaIdGuid:: IbeL3tyF3k+2h5ZXaI5mfg==
dn: CN=ShadowExpire,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: shadowExpire
adminDisplayName: shadowExpire
adminDescription: Absolute date to expire account
adminDescription: Absolute date to expire account
attributeId: 1.3.6.1.1.1.1.10
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: AJoVdf8f9EyL/07yaVz2Qw==
dn: CN=ms-DFSR-Enabled,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-Enabled
adminDisplayName: ms-DFSR-Enabled
adminDescription: Specify if the object enabled
attributeId: 1.2.840.113556.1.6.13.3.9
omSyntax: 1
searchFlags: 0
schemaIdGuid:: 52pyA32ORkSKrqkWV8AJkw==
dn: CN=ms-DFSR-DfsPath,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-DfsPath
adminDisplayName: ms-DFSR-DfsPath
adminDescription: Full path of associated DFS link
attributeId: 1.2.840.113556.1.6.13.3.21
omSyntax: 64
searchFlags: 1
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: 4gPJLIw5O0Sshv9rAerHug==
dn: CN=BootParameter,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: bootParameter
adminDisplayName: bootParameter
adminDescription: rpc.bootparamd parameter
attributeId: 1.3.6.1.1.1.1.23
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 10240
schemaIdGuid:: UAcq13yMbkGHFOZfEekIvg==
dn: CN=msSFU-30-Aliases,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30Aliases
adminDisplayName: msSFU-30-Aliases
adminDescription: part of the NIS mail map
attributeId: 1.2.840.113556.1.6.18.1.323
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 153600
schemaIdGuid:: cfHrIJrGMUyyndy4N9iRLQ==
schemaIdGuid:: cfHrIJrGMUyyndy4N9iRLQ==
dn: CN=msSFU-30-Domains,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30Domains
adminDisplayName: msSFU-30-Domains
adminDescription: stores the list of UNIX NIS domains migrated to the same AD NIS domain
attributeId: 1.2.840.113556.1.6.18.1.340
omSyntax: 22
systemOnly: FALSE
searchFlags: 1
rangeUpper: 256000
schemaIdGuid:: 014JkzBv3Uu3NGXVafX3yQ==
dn: CN=IpServicePort,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ipServicePort
adminDisplayName: ipServicePort
adminDescription: This is a part of the services map and contains the port at which the UNIX service is
available.
attributeId: 1.3.6.1.1.1.1.15
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: v64t/2P0WkmEBT5INkHqog==
dn: CN=ms-DFSR-Version,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-Version
adminDisplayName: ms-DFSR-Version
adminDescription: DFSR version number
attributeId: 1.2.840.113556.1.6.13.3.1
omSyntax: 64
rangeUpper: 256
searchFlags: 0
schemaIdGuid:: CBSGGsM46km6dYVIGnfGVQ==
dn: CN=ms-DFSR-Options,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-Options
adminDisplayName: ms-DFSR-Options
adminDescription: DFSR object options
attributeId: 1.2.840.113556.1.6.13.3.17
omSyntax: 2
searchFlags: 0
schemaIdGuid:: hHDW1iDHfUGGR7aWI3oRTA==
dn: CN=ShadowWarning,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: shadowWarning
adminDisplayName: shadowWarning
adminDescription: Number of days before password expiry to warn user
attributeId: 1.3.6.1.1.1.1.8
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: nJzoenYpRkq7ijQPiFYBFw==
dn: CN=ms-DFSR-Schedule,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-Schedule
adminDisplayName: ms-DFSR-Schedule
adminDescription: DFSR Replication schedule
attributeId: 1.2.840.113556.1.6.13.3.14
omSyntax: 4
searchFlags: 0
rangeLower: 336
rangeUpper: 336
schemaIdGuid:: X/GZRh+n4kif9ViXwHWSBQ==
dn: CN=ShadowInactive,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: shadowInactive
adminDisplayName: shadowInactive
adminDescription: Number of days before password expiry to warn user
attributeId: 1.3.6.1.1.1.1.9
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Hx2HhhAzEkOO/a9J3PsmcQ==
dn: CN=ms-DFSR-RootPath,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-RootPath
adminDisplayName: ms-DFSR-RootPath
adminDescription: Full path of the root directory
attributeId: 1.2.840.113556.1.6.13.3.3
omSyntax: 64
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: wejV1x/mT0afzyC74KLsVA==
dn: CN=ms-DFSR-Keywords,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-Keywords
adminDisplayName: ms-DFSR-Keywords
adminDescription: User defined keywords
attributeId: 1.2.840.113556.1.6.13.3.15
omSyntax: 64
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: kkaLBCdiZ0ugdMRDcIPhSw==
dn: CN=ms-DFSR-RootFence,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-RootFence
adminDisplayName: ms-DFSR-RootFence
adminDescription: Root directory fence value
attributeId: 1.2.840.113556.1.6.13.3.22
omSyntax: 2
searchFlags: 0
schemaIdGuid:: lI6SUdgsvkq1UuUEEkRDcA==
dn: CN=msSFU-30-Nis-Domain,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30NisDomain
adminDisplayName: msSFU-30-Nis-Domain
adminDescription: This attribute is used to store the NIS domain
attributeId: 1.2.840.113556.1.6.18.1.339
omSyntax: 22
rangeUpper: 1024
systemOnly: FALSE
searchFlags: 9
schemaIdGuid:: 47LjnvPH+EWMnxOCvkmE0g==
dn: CN=IpNetmaskNumber,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ipNetmaskNumber
adminDisplayName: ipNetmaskNumber
adminDescription: IP netmask as a dotted decimal, omitting leading zeros
attributeId: 1.3.6.1.1.1.1.21
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 128
schemaIdGuid:: zU/2by5GYk+0SppTR2WeuQ==
dn: CN=msSFU-30-Map-Filter,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30MapFilter
adminDisplayName: msSFU-30-Map-Filter
adminDescription: stores a string containing map keys, domain name and so on. The string is used to filter
data in a map
attributeId: 1.2.840.113556.1.6.18.1.306
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 1024
schemaIdGuid:: AW6xt08CI06tDXHxpAa2hA==
dn: CN=ms-DFSR-Extension,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-Extension
adminDisplayName: ms-DFSR-Extension
adminDescription: DFSR Extension attribute
attributeId: 1.2.840.113556.1.6.13.3.2
omSyntax: 4
searchFlags: 0
rangeLower: 0
rangeUpper: 65536
schemaIdGuid:: 7BHweGanGUutz3uB7XgaTQ==
dn: CN=IpNetworkNumber,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ipNetworkNumber
adminDisplayName: ipNetworkNumber
adminDescription: IP network as a dotted decimal, omitting leading zeros
attributeId: 1.3.6.1.1.1.1.20
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 128
schemaIdGuid:: 9FQ4TocwpEKoE7sMUolY0w==
dn: CN=msSFU-30-Key-Values,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30KeyValues
adminDisplayName: msSFU-30-Key-Values
adminDescription: This attribute is internal to Server for NIS and is used as a scratch pad
attributeId: 1.2.840.113556.1.6.18.1.324
omSyntax: 22
rangeUpper: 10240
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: NQKDN+nl8kaSK9jUTwPnrg==
dn: CN=msSFU-30-Yp-Servers,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30YpServers
adminDisplayName: msSFU-30-Yp-Servers
adminDescription: Stores ypserves list, list of "Servers for NIS" in a NIS domain
attributeId: 1.2.840.113556.1.6.18.1.341
omSyntax: 22
rangeUpper: 20480
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: S5RKCFDh/kuTRUDhrtrrug==
dn: CN=ms-DFSR-RdcEnabled,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-RdcEnabled
adminDisplayName: ms-DFSR-RdcEnabled
adminDescription: Enable and disable RDC
attributeId: 1.2.840.113556.1.6.13.3.19
attributeId: 1.2.840.113556.1.6.13.3.19
omSyntax: 1
searchFlags: 0
schemaIdGuid:: BU6046f0eECnMPSGcKdD+A==
dn: CN=ShadowLastChange,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: shadowLastChange
adminDisplayName: shadowLastChange
adminDescription: Last change of shadow information.
attributeId: 1.3.6.1.1.1.1.5
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: nGjy+OgpQ0iBd+i5jhXurA==
dn: CN=ms-DFSR-FileFilter,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-FileFilter
adminDisplayName: ms-DFSR-FileFilter
adminDescription: Filter string applied to files
attributeId: 1.2.840.113556.1.6.13.3.12
omSyntax: 64
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: rHCC1tylQUimrM1ovjjBgQ==
dn: CN=IpProtocolNumber,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ipProtocolNumber
adminDisplayName: ipProtocolNumber
adminDescription: This is part of the protocols map and stores the unique number that identifies the
protocol.
attributeId: 1.3.6.1.1.1.1.17
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 68b16y0OFUSWcBCBmTtCEQ==
dn: CN=UnixUserPassword,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: unixUserPassword
adminDisplayName: unixUserPassword
adminDescription: userPassword compatible with Unix system.
attributeId: 1.2.840.113556.1.4.1910
omSyntax: 4
systemOnly: FALSE
searchFlags: 128
rangeLower: 1
rangeUpper: 128
schemaIdGuid:: R7csYejAkk+SIf3V8VtVDQ==
schemaIdGuid:: R7csYejAkk+SIf3V8VtVDQ==
dn: CN=ms-DFSR-StagingPath,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-StagingPath
adminDisplayName: ms-DFSR-StagingPath
adminDescription: Full path of the staging directory
attributeId: 1.2.840.113556.1.6.13.3.5
omSyntax: 64
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: nqa5hqbwXUCZu3fZd5ksKg==
dn: CN=MemberNisNetgroup,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: memberNisNetgroup
adminDisplayName: memberNisNetgroup
adminDescription: A multivalued attribute that holds the list of netgroups that are members of this
netgroup.
attributeId: 1.3.6.1.1.1.1.13
omSyntax: 22
rangeUpper: 153600
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 3BdqD+VT6EuUQo884vkBKg==
dn: CN=msSFU-30-Order-Number,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30OrderNumber
adminDisplayName: msSFU-30-Order-Number
adminDescription: Every time the data stored in the msSFU-30-Domain-Info object is changed, the value of
this attribute is incremented. Server for NIS uses this object to check if the map has changed. This number
is used to track data changes between ypxfer calls
attributeId: 1.2.840.113556.1.6.18.1.308
omSyntax: 64
rangeUpper: 1024
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: BV9iAu7Rn0+zZlUma+y5XA==
dn: CN=IpServiceProtocol,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ipServiceProtocol
adminDisplayName: ipServiceProtocol
adminDescription: This is a part of the services map and stores the protocol number for a UNIX service.
attributeId: 1.3.6.1.1.1.1.16
omSyntax: 22
rangeUpper: 1024
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: C+yWzdYetEOya/FwtkWIPw==
dn: CN=msSFU-30-Posix-Member,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30PosixMember
adminDisplayName: msSFU-30-Posix-Member
adminDescription: This attribute is used to stores the DN display name of users??? part of a group
attributeId: 1.2.840.113556.1.6.18.1.346
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Ldh1yEgo7Ey7UDxUhtCdVw==
linkID: 2030
dn: CN=UnixHomeDirectory,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: unixHomeDirectory
adminDisplayName: unixHomeDirectory
adminDescription: The absolute path to the home directory (RFC 2307)
attributeId: 1.3.6.1.1.1.1.3
omSyntax: 22
rangeUpper: 2048
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ErotvA8ATUa/HQgIRl2IQw==
dn: CN=msSFU-30-Crypt-Method,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30CryptMethod
adminDisplayName: msSFU-30-Crypt-Method
adminDescription: used to store the method used for encrypting the UNIX passwords, either MD5 or crypt.
attributeId: 1.2.840.113556.1.6.18.1.352
omSyntax: 22
rangeUpper: 1024
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: o9IDRXA9uEGwd9/xI8FYZQ==
dn: CN=NisNetgroupTriple,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: nisNetgroupTriple
adminDisplayName: nisNetgroupTriple
adminDescription: This attribute represents one entry from a netgroup map.
attributeId: 1.3.6.1.1.1.1.14
omSyntax: 22
rangeUpper: 153600
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: dC4DqO8w9U+v/A/CF3g/7A==
dn: CN=ms-DFSR-ConflictPath,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-ConflictPath
ldapDisplayName: msDFSR-ConflictPath
adminDisplayName: ms-DFSR-ConflictPath
adminDescription: Full path of the conflict directory
attributeId: 1.2.840.113556.1.6.13.3.7
omSyntax: 64
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: yLzwXPdg/0u9pq6gNE6xUQ==
dn: CN=msSFU-30-Max-Gid-Number,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30MaxGidNumber
adminDisplayName: msSFU-30-Max-Gid-Number
adminDescription: stores the maximum number of groups migrated to a NIS domain
attributeId: 1.2.840.113556.1.6.18.1.342
omSyntax: 2
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: pmruBDv4mka/WjwA02NGaQ==
dn: CN=msSFU-30-Max-Uid-Number,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30MaxUidNumber
adminDisplayName: msSFU-30-Max-Uid-Number
adminDescription: stores the maximum number of users migrated to a NIS domain
attributeId: 1.2.840.113556.1.6.18.1.343
omSyntax: 2
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: N4SZ7ETZKEqFACF1iK38dQ==
dn: CN=ms-DFSR-RootSizeInMb,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-RootSizeInMb
adminDisplayName: ms-DFSR-RootSizeInMb
adminDescription: Size of the root directory in MB
attributeId: 1.2.840.113556.1.6.13.3.4
omSyntax: 65
searchFlags: 0
rangeLower: 0
rangeUpper: -1
schemaIdGuid:: rGm3kBNEz0OteoZxQudAow==
dn: CN=ms-DFSR-DfsLinkTarget,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-DfsLinkTarget
adminDisplayName: ms-DFSR-DfsLinkTarget
adminDescription: Link target used for the subscription
attributeId: 1.2.840.113556.1.6.13.3.24
omSyntax: 64
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: qVu49/k7j0KqtC7ubVbwYw==
dn: CN=msSFU-30-Posix-Member-Of,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30PosixMemberOf
adminDisplayName: msSFU-30-Posix-Member-Of
adminDescription: stores the display names of groups to which this user belongs to
attributeId: 1.2.840.113556.1.6.18.1.347
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: kmvXe0QyikOtpiT16jQ4Hg==
linkID: 2031
systemFlags: 1
dn: CN=msSFU-30-Key-Attributes,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30KeyAttributes
adminDisplayName: msSFU-30-Key-Attributes
adminDescription: stores the names of the attributes which the Server for NIS will use as keys to search a
map
attributeId: 1.2.840.113556.1.6.18.1.301
omSyntax: 64
rangeUpper: 1024
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: mNbsMp7OlEihNHrXawgugw==
dn: CN=msSFU-30-Field-Separator,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30FieldSeparator
adminDisplayName: msSFU-30-Field-Separator
adminDescription: stores Field Separator for each NIS map
attributeId: 1.2.840.113556.1.6.18.1.302
omSyntax: 64
rangeUpper: 50
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: QhrhooHnoUyn+uwwf2K2oQ==
dn: CN=ms-DFSR-ContentSetGuid,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-ContentSetGuid
adminDisplayName: ms-DFSR-ContentSetGuid
adminDescription: DFSR Content set guid
attributeId: 1.2.840.113556.1.6.13.3.18
omSyntax: 4
searchFlags: 0
rangeLower: 16
rangeLower: 16
rangeUpper: 16
schemaIdGuid:: 4ag1EKhnIUy3uwMc35nXoA==
dn: CN=ms-DFSR-MemberReference,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-MemberReference
adminDisplayName: ms-DFSR-MemberReference
adminDescription: Forward link to DFSR-Member object
attributeId: 1.2.840.113556.1.6.13.3.100
omSyntax: 127
searchFlags: 0
schemaIdGuid:: qjcTJsPxskS76siNSebwxw==
linkID: 2052
dn: CN=msSFU-30-Search-Container,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30SearchContainer
adminDisplayName: msSFU-30-Search-Container
adminDescription: stores the identifier of an object from where each search will begin
attributeId: 1.2.840.113556.1.6.18.1.300
omSyntax: 64
rangeUpper: 2048
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: or/uJ+v7jk+q1sUCR5lCkQ==
dn: CN=ms-DFSR-StagingSizeInMb,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-StagingSizeInMb
adminDisplayName: ms-DFSR-StagingSizeInMb
adminDescription: Size of the staging directory in MB
attributeId: 1.2.840.113556.1.6.13.3.6
omSyntax: 65
searchFlags: 0
rangeLower: 0
rangeUpper: -1
schemaIdGuid:: II8KJfz2WUWuZeSyTGeuvg==
dn: CN=ms-DFSR-DirectoryFilter,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-DirectoryFilter
adminDisplayName: ms-DFSR-DirectoryFilter
adminDescription: Filter string applied to directories
attributeId: 1.2.840.113556.1.6.13.3.13
omSyntax: 64
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: d7THky4fQEu3vwB+jQOMzw==
dn: CN=ms-DFSR-ConflictSizeInMb,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DFSR-ConflictSizeInMb,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-ConflictSizeInMb
adminDisplayName: ms-DFSR-ConflictSizeInMb
adminDescription: Size of the Conflict directory in MB
attributeId: 1.2.840.113556.1.6.13.3.8
omSyntax: 65
searchFlags: 0
rangeLower: 0
rangeUpper: -1
schemaIdGuid:: yT/Tms+qmUK7PtH8bqiOSQ==
dn: CN=msSFU-30-Is-Valid-Container,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30IsValidContainer
adminDisplayName: msSFU-30-Is-Valid-Container
adminDescription: internal to Server for NIS and stores whether the current search root is valid
attributeId: 1.2.840.113556.1.6.18.1.350
omSyntax: 2
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: 9ULqDY0nV0G0p0m1lmSRWw==
dn: CN=msSFU-30-Search-Attributes,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30SearchAttributes
adminDisplayName: msSFU-30-Search-Attributes
adminDescription: stores the names of the attributes Server for NIS needs while searching a map
attributeId: 1.2.840.113556.1.6.18.1.304
omSyntax: 64
rangeUpper: 1024
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 8C2a71cuyEiJUAzGdABHMw==
dn: CN=msSFU-30-Master-Server-Name,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30MasterServerName
adminDisplayName: msSFU-30-Master-Server-Name
adminDescription: The value in this container is returned when Server for NIS processes a yp_master API call
attributeId: 1.2.840.113556.1.6.18.1.307
omSyntax: 64
rangeUpper: 1024
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: ogjJTBieDkGEWfF8xCICCg==
dn: CN=msSFU-30-Result-Attributes,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30ResultAttributes
adminDisplayName: msSFU-30-Result-Attributes
adminDescription: Server for NIS uses this object as a scratch pad
attributeId: 1.2.840.113556.1.6.18.1.305
attributeId: 1.2.840.113556.1.6.18.1.305
omSyntax: 64
rangeUpper: 1024
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: trBn4UVAM0SsNVP5ctRcug==
dn: CN=ms-DFSR-MemberReferenceBL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-MemberReferenceBL
adminDisplayName: ms-DFSR-MemberReferenceBL
adminDescription: Backlink attribute for ms-DFSR-MemberReference
attributeId: 1.2.840.113556.1.6.13.3.102
omSyntax: 127
searchFlags: 0
schemaIdGuid:: xmLerYAY7UG9PDC30l4U8A==
linkID: 2053
systemFlags: 1
dn: CN=ms-DFSR-ComputerReference,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-ComputerReference
adminDisplayName: ms-DFSR-ComputerReference
adminDescription: Forward link to Computer object
attributeId: 1.2.840.113556.1.6.13.3.101
omSyntax: 127
searchFlags: 0
schemaIdGuid:: hVd7bCE9v0GKimJ5QVRNWg==
linkID: 2050
dn: CN=ms-DFSR-RdcMinFileSizeInKb,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-RdcMinFileSizeInKb
adminDisplayName: ms-DFSR-RdcMinFileSizeInKb
adminDescription: Minimum file size to apply RDC
attributeId: 1.2.840.113556.1.6.13.3.20
omSyntax: 65
searchFlags: 0
rangeLower: 0
rangeUpper: -1
schemaIdGuid:: MKMC9OWswU2MyXTZAL+K4A==
dn: CN=msSFU-30-NSMAP-Field-Position,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30NSMAPFieldPosition
adminDisplayName: msSFU-30-NSMAP-Field-Position
adminDescription: This attribute stores the "field position", to extract the key from a non-standard map
attributeId: 1.2.840.113556.1.6.18.1.345
omSyntax: 22
rangeUpper: 1024
rangeUpper: 1024
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Xp1cWJn1B0+c+UNzr0uJ0w==
dn: CN=ms-DFSR-ComputerReferenceBL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-ComputerReferenceBL
adminDisplayName: ms-DFSR-ComputerReferenceBL
adminDescription: Backlink attribute for ms-DFSR-ComputerReference
attributeId: 1.2.840.113556.1.6.13.3.103
omSyntax: 127
searchFlags: 0
schemaIdGuid:: 1ya1XhvXrkSMxpVGAFLmrA==
linkID: 2051
systemFlags: 1
dn: CN=msSFU-30-Intra-Field-Separator,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30IntraFieldSeparator
adminDisplayName: msSFU-30-Intra-Field-Separator
adminDescription: This attribute stores intra field separators for each NIS map
attributeId: 1.2.840.113556.1.6.18.1.303
omSyntax: 64
rangeUpper: 50
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 8K6yleQnuUyICqLZqeojuA==
dn: CN=ms-DFSR-ReplicationGroupGuid,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-ReplicationGroupGuid
adminDisplayName: ms-DFSR-ReplicationGroupGuid
adminDescription: Replication group guid
attributeId: 1.2.840.113556.1.6.13.3.23
omSyntax: 4
searchFlags: 1
rangeLower: 16
rangeUpper: 16
schemaIdGuid:: loetLRl2+E+Wbgpcxnsofw==
dn: CN=msSFU-30-Netgroup-Host-At-Domain,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30NetgroupHostAtDomain
adminDisplayName: msSFU-30-Netgroup-Host-At-Domain
adminDescription: Part of the netgroup map.This attribute represents computed strings such as host@domain
attributeId: 1.2.840.113556.1.6.18.1.348
omSyntax: 22
rangeUpper: 2048
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: Zb/Sl2YEUkiiWuwg9X7jbA==
dn: CN=msSFU-30-Netgroup-User-At-Domain,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30NetgroupUserAtDomain
adminDisplayName: msSFU-30-Netgroup-User-At-Domain
adminDescription: Part of the netgroup map.This attribute represents computed strings such as user@domain
attributeId: 1.2.840.113556.1.6.18.1.349
omSyntax: 22
rangeUpper: 2048
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: 7U7oqTDmZ0u0s8rSqC00Xg==
dn: CN=ms-DFSR-ReplicationGroupType,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-ReplicationGroupType
adminDisplayName: ms-DFSR-ReplicationGroupType
adminDescription: Type of Replication Group
attributeId: 1.2.840.113556.1.6.13.3.10
omSyntax: 2
searchFlags: 0
schemaIdGuid:: yA/t7gEQ7UWAzLv3RJMHIA==
dn: CN=ms-DFSR-TombstoneExpiryInMin,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-TombstoneExpiryInMin
adminDisplayName: ms-DFSR-TombstoneExpiryInMin
adminDescription: Tombstone record lifetime in minutes
attributeId: 1.2.840.113556.1.6.13.3.11
omSyntax: 2
searchFlags: 0
rangeLower: 0
schemaIdGuid:: TF3jIyTjYUiiL+GZFA2uAA==
dn: CN=ms-DS-Source-Object-DN,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-SourceObjectDN
adminDisplayName: ms-DS-Source-Object-DN
adminDescription: The string representation of the DN of the object in another forest that corresponds to
this object.
attributeId: 1.2.840.113556.1.4.1879
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 10240
schemaIdGuid:: r5M+d7TT1Eiz+QZFdgLT0A==
dn:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-DFSR-LocalSettings,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-LocalSettings
adminDisplayName: ms-DFSR-LocalSettings
adminDescription: DFSR settings applicable to local computer
governsId: 1.2.840.113556.1.6.13.4.1
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.2.840.113556.1.6.13.3.2
mayContain: 1.2.840.113556.1.6.13.3.17
mayContain: 1.2.840.113556.1.6.13.3.16
mayContain: 1.2.840.113556.1.6.13.3.1
possSuperiors: 1.2.840.113556.1.3.30
schemaIdGuid:: kcWF+n8ZfkeDvepaQ98iOQ==
defaultSecurityDescriptor: D:(A;;RPLCLORC;;;AU)(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;DA)
(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;CO)(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DFSR-LocalSettings,CN=Schema,CN=Configuration,DC=X
dn: CN=NisMap,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: nisMap
adminDisplayName: nisMap
adminDescription: A generic abstraction of a nis map
governsId: 1.3.6.1.1.1.2.9
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mustContain: 1.3.6.1.1.1.1.26
possSuperiors: 1.2.840.113556.1.3.23
possSuperiors: 1.2.840.113556.1.5.67
schemaIdGuid:: bGZydsECM0+ez/ZJwd2bfA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=NisMap,CN=Schema,CN=Configuration,DC=X
dn: CN=IpProtocol,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ipProtocol
adminDisplayName: ipProtocol
adminDescription: Abstraction of an IP protocol
governsId: 1.3.6.1.1.1.2.4
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mustContain: 1.3.6.1.1.1.1.17
mayContain: 1.2.840.113556.1.6.18.1.323
mayContain: 1.3.6.1.1.1.1.26
mayContain: 1.2.840.113556.1.6.18.1.339
mayContain: 1.2.840.113556.1.6.18.1.309
possSuperiors: 1.2.840.113556.1.3.23
possSuperiors: 1.3.6.1.1.1.2.9
possSuperiors: 1.2.840.113556.1.5.67
schemaIdGuid:: 0sstnPD7x02s4INW3NDwEw==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=IpProtocol,CN=Schema,CN=Configuration,DC=X
dn: CN=PosixGroup,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: posixGroup
adminDisplayName: posixGroup
adminDescription: Abstraction of a group of acconts
governsId: 1.3.6.1.1.1.2.2
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.3.6.1.1.1.1.12
mayContain: 1.3.6.1.1.1.1.1
mayContain: 1.2.840.113556.1.4.1910
mayContain: 2.5.4.3
schemaIdGuid:: uFCTKiwG0E6ZA93hDQbeug==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=PosixGroup,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DFSR-GlobalSettings,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-GlobalSettings
adminDisplayName: ms-DFSR-GlobalSettings
adminDescription: Global settings applicable to all replication group members
governsId: 1.2.840.113556.1.6.13.4.4
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.2.840.113556.1.6.13.3.2
mayContain: 1.2.840.113556.1.6.13.3.17
mayContain: 1.2.840.113556.1.6.13.3.16
possSuperiors: 1.2.840.113556.1.3.23
schemaIdGuid:: rds1e+yzakiq1C/snW6m9g==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DFSR-GlobalSettings,CN=Schema,CN=Configuration,DC=X
dn: CN=IEEE802Device,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ieee802Device
adminDisplayName: ieee802Device
adminDescription: A device with a MAC address
governsId: 1.3.6.1.1.1.2.11
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.3.6.1.1.1.1.22
mayContain: 2.5.4.3
schemaIdGuid:: KeWZpjemfUug+13EZqC4pw==
schemaIdGuid:: KeWZpjemfUug+13EZqC4pw==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=IEEE802Device,CN=Schema,CN=Configuration,DC=X
dn: CN=msSFU-30-Net-Id,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30NetId
adminDisplayName: msSFU-30-Net-Id
adminDescription: stores the netword ID
governsId: 1.2.840.113556.1.6.18.2.212
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.3.6.1.1.1.1.26
mayContain: 1.2.840.113556.1.6.18.1.339
mayContain: 1.2.840.113556.1.6.18.1.309
mayContain: 1.2.840.113556.1.6.18.1.324
possSuperiors: 1.2.840.113556.1.3.23
possSuperiors: 1.2.840.113556.1.5.67
schemaIdGuid:: LBlj4gIq30iXkpTyMoeBoA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=msSFU-30-Net-Id,CN=Schema,CN=Configuration,DC=X
dn: CN=NisNetgroup,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: nisNetgroup
adminDisplayName: nisNetgroup
adminDescription: Abstraction of a netgroup. May refer to other netgroups
governsId: 1.3.6.1.1.1.2.8
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.2.840.113556.1.6.18.1.349
mayContain: 1.2.840.113556.1.6.18.1.348
mayContain: 1.3.6.1.1.1.1.26
mayContain: 1.2.840.113556.1.6.18.1.339
mayContain: 1.2.840.113556.1.6.18.1.309
mayContain: 1.3.6.1.1.1.1.14
mayContain: 1.3.6.1.1.1.1.13
possSuperiors: 1.2.840.113556.1.3.23
possSuperiors: 1.2.840.113556.1.5.67
schemaIdGuid:: hL/vcntuXEqo24p1p8rSVA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=NisNetgroup,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DFSR-ReplicationGroup,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-ReplicationGroup
adminDisplayName: ms-DFSR-ReplicationGroup
adminDescription: Replication Group container
adminDescription: Replication Group container
governsId: 1.2.840.113556.1.6.13.4.5
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mustContain: 1.2.840.113556.1.6.13.3.10
mayContain: 1.2.840.113556.1.6.13.3.1
mayContain: 1.2.840.113556.1.6.13.3.14
mayContain: 1.2.840.113556.1.6.13.3.2
mayContain: 1.2.840.113556.1.6.13.3.17
mayContain: 1.2.840.113556.1.6.13.3.16
mayContain: 1.2.840.113556.1.6.13.3.11
possSuperiors: 1.2.840.113556.1.6.13.4.4
schemaIdGuid:: 4C8zHCoMMk+vyiPF5Fqedw==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DFSR-ReplicationGroup,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DFSR-Topology,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-Topology
adminDisplayName: ms-DFSR-Topology
adminDescription: Container for objects that form the replication topology
governsId: 1.2.840.113556.1.6.13.4.8
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.2.840.113556.1.6.13.3.2
mayContain: 1.2.840.113556.1.6.13.3.17
mayContain: 1.2.840.113556.1.6.13.3.16
possSuperiors: 1.2.840.113556.1.6.13.4.5
schemaIdGuid:: qYqCBEJugE65YuL+AHVNFw==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DFSR-Topology,CN=Schema,CN=Configuration,DC=X
dn: CN=PosixAccount,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: posixAccount
adminDisplayName: posixAccount
adminDescription: Abstraction of an account with posix attributes
governsId: 1.3.6.1.1.1.2.0
rdnAttId: 0.9.2342.19200300.100.1.1
subClassOf: 2.5.6.0
mayContain: 1.3.6.1.1.1.1.2
mayContain: 1.3.6.1.1.1.1.4
mayContain: 1.2.840.113556.1.4.1910
mayContain: 1.2.840.113556.1.4.44
mayContain: 1.3.6.1.1.1.1.3
mayContain: 1.3.6.1.1.1.1.1
mayContain: 1.3.6.1.1.1.1.0
mayContain: 2.5.4.3
mayContain: 0.9.2342.19200300.100.1.1
schemaIdGuid:: QbtErdVniE21dXsgZ0522A==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=PosixAccount,CN=Schema,CN=Configuration,DC=X
dn: CN=ShadowAccount,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: shadowAccount
adminDisplayName: shadowAccount
adminDescription: Additional attributes for shadow passwords
governsId: 1.3.6.1.1.1.2.1
rdnAttId: 0.9.2342.19200300.100.1.1
subClassOf: 2.5.6.0
mayContain: 1.3.6.1.1.1.1.11
mayContain: 1.3.6.1.1.1.1.10
mayContain: 1.3.6.1.1.1.1.9
mayContain: 1.3.6.1.1.1.1.8
mayContain: 1.3.6.1.1.1.1.7
mayContain: 1.3.6.1.1.1.1.6
mayContain: 1.3.6.1.1.1.1.5
mayContain: 0.9.2342.19200300.100.1.1
schemaIdGuid:: Z4RtWxgadEGzUJzG57SsjQ==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ShadowAccount,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DFSR-Content,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-Content
adminDisplayName: ms-DFSR-Content
adminDescription: Container for DFSR-ContentSet objects
governsId: 1.2.840.113556.1.6.13.4.6
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.2.840.113556.1.6.13.3.2
mayContain: 1.2.840.113556.1.6.13.3.17
mayContain: 1.2.840.113556.1.6.13.3.16
possSuperiors: 1.2.840.113556.1.6.13.4.5
schemaIdGuid:: NZt1ZKHT5EK18aPeFiEJsw==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DFSR-Content,CN=Schema,CN=Configuration,DC=X
dn: CN=BootableDevice,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: bootableDevice
adminDisplayName: bootableDevice
adminDescription: A device with boot parameters
governsId: 1.3.6.1.1.1.2.12
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.3.6.1.1.1.1.24
mayContain: 1.3.6.1.1.1.1.23
mayContain: 2.5.4.3
schemaIdGuid:: dyTLS7NLRUWp/Ptm4Ta0NQ==
(A;;RPLCLORC;;;AU)
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=BootableDevice,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-Print-ConnectionPolicy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPrint-ConnectionPolicy
adminDisplayName: ms-Print-ConnectionPolicy
adminDescription: Pushed Printer Connection Policy1
governsId: 1.2.840.113556.1.6.23.2
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.2.840.113556.1.4.137
mayContain: 1.2.840.113556.1.4.223
mayContain: 1.2.840.113556.1.4.247
mayContain: 1.2.840.113556.1.4.300
possSuperiors: 1.2.840.113556.1.3.23
schemaIdGuid:: xzNvodZ/KEiTZENROP2gjQ==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-Print-ConnectionPolicy,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DFSR-Member,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-Member
adminDisplayName: ms-DFSR-Member
adminDescription: Replication group member
governsId: 1.2.840.113556.1.6.13.4.9
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mustContain: 1.2.840.113556.1.6.13.3.101
mayContain: 1.2.840.113556.1.6.13.3.2
mayContain: 1.2.840.113556.1.6.13.3.17
mayContain: 1.2.840.113556.1.6.13.3.16
mayContain: 1.2.840.113556.1.6.13.3.15
mayContain: 1.2.840.113556.1.4.515
possSuperiors: 1.2.840.113556.1.6.13.4.8
schemaIdGuid:: l8gpQhHCfEOlrtv3BbaW5Q==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DFSR-Member,CN=Schema,CN=Configuration,DC=X
dn: CN=OncRpc,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: oncRpc
adminDisplayName: oncRpc
adminDescription: Abstraction of an Open Network Computing (ONC) [RFC1057] Remote Procedure Call (RPC)
binding
governsId: 1.3.6.1.1.1.2.5
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mustContain: 1.3.6.1.1.1.1.18
mayContain: 1.2.840.113556.1.6.18.1.323
mayContain: 1.3.6.1.1.1.1.26
mayContain: 1.2.840.113556.1.6.18.1.339
mayContain: 1.2.840.113556.1.6.18.1.309
possSuperiors: 1.2.840.113556.1.3.23
possSuperiors: 1.2.840.113556.1.5.67
schemaIdGuid:: Xh7dyvz+P0+1qXDplCBDAw==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=OncRpc,CN=Schema,CN=Configuration,DC=X
dn: CN=IpHost,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ipHost
adminDisplayName: ipHost
adminDescription: Abstraction of a host, an IP device.
governsId: 1.3.6.1.1.1.2.6
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 2.5.4.7
mayContain: 0.9.2342.19200300.100.1.1
mayContain: 1.3.6.1.1.1.1.19
mayContain: 2.5.4.3
mayContain: 0.9.2342.19200300.100.1.10
schemaIdGuid:: RhaRqyeIlU+HgFqPAI62jw==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=IpHost,CN=Schema,CN=Configuration,DC=X
dn: CN=msSFU-30-Domain-Info,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30DomainInfo
adminDisplayName: msSFU-30-Domain-Info
adminDescription: Represents an internal data structure used by Server for NIS.
governsId: 1.2.840.113556.1.6.18.2.215
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.2.840.113556.1.6.18.1.352
mayContain: 1.2.840.113556.1.6.18.1.343
mayContain: 1.2.840.113556.1.6.18.1.342
mayContain: 1.2.840.113556.1.6.18.1.308
mayContain: 1.2.840.113556.1.6.18.1.307
mayContain: 1.2.840.113556.1.6.18.1.350
mayContain: 1.2.840.113556.1.6.18.1.300
mayContain: 1.2.840.113556.1.6.18.1.341
mayContain: 1.2.840.113556.1.6.18.1.340
possSuperiors: 1.2.840.113556.1.3.23
schemaIdGuid:: zn0pNmtlI0SrZdq7J3CBng==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=msSFU-30-Domain-Info,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DFSR-Connection,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-Connection
adminDisplayName: ms-DFSR-Connection
adminDescription: Directional connection between two members
governsId: 1.2.840.113556.1.6.13.4.10
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mustContain: 1.2.840.113556.1.4.40
mayContain: 1.2.840.113556.1.6.13.3.2
mayContain: 1.2.840.113556.1.6.13.3.17
mayContain: 1.2.840.113556.1.6.13.3.16
mayContain: 1.2.840.113556.1.6.13.3.14
mayContain: 1.2.840.113556.1.6.13.3.15
mayContain: 1.2.840.113556.1.6.13.3.20
mayContain: 1.2.840.113556.1.6.13.3.19
mayContain: 1.2.840.113556.1.6.13.3.9
possSuperiors: 1.2.840.113556.1.6.13.4.9
schemaIdGuid:: LpeP5bVk70aNi7vD4Yl+qw==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DFSR-Connection,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DFSR-Subscriber,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-Subscriber
adminDisplayName: ms-DFSR-Subscriber
adminDescription: Represents local computer membership of a replication group
governsId: 1.2.840.113556.1.6.13.4.2
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mustContain: 1.2.840.113556.1.6.13.3.23
mustContain: 1.2.840.113556.1.6.13.3.100
mayContain: 1.2.840.113556.1.6.13.3.2
mayContain: 1.2.840.113556.1.6.13.3.17
mayContain: 1.2.840.113556.1.6.13.3.16
possSuperiors: 1.2.840.113556.1.6.13.4.1
schemaIdGuid:: 1wUV4cSS50O/XClYMv/Ilg==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DFSR-Subscriber,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DFSR-ContentSet,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-ContentSet
adminDisplayName: ms-DFSR-ContentSet
adminDescription: DFSR Content Set
governsId: 1.2.840.113556.1.6.13.4.7
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.2.840.113556.1.6.13.3.2
mayContain: 1.2.840.113556.1.6.13.3.17
mayContain: 1.2.840.113556.1.6.13.3.16
mayContain: 1.2.840.113556.1.6.13.3.13
mayContain: 1.2.840.113556.1.6.13.3.12
mayContain: 1.2.840.113556.1.6.13.3.21
possSuperiors: 1.2.840.113556.1.6.13.4.6
possSuperiors: 1.2.840.113556.1.6.13.4.6
schemaIdGuid:: DfQ3SdymSE2Xygbl+/0/Fg==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DFSR-ContentSet,CN=Schema,CN=Configuration,DC=X
dn: CN=msSFU-30-Mail-Aliases,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30MailAliases
adminDisplayName: msSFU-30-Mail-Aliases
adminDescription: represents UNIX mail file data
governsId: 1.2.840.113556.1.6.18.2.211
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.3.6.1.1.1.1.26
mayContain: 1.2.840.113556.1.6.18.1.323
mayContain: 1.2.840.113556.1.6.18.1.339
mayContain: 1.2.840.113556.1.6.18.1.309
possSuperiors: 1.2.840.113556.1.3.23
possSuperiors: 1.2.840.113556.1.5.67
schemaIdGuid:: hQdx1v+Gt0SFtfH4aJUizg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=msSFU-30-Mail-Aliases,CN=Schema,CN=Configuration,DC=X
dn: CN=msSFU-30-Network-User,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30NetworkUser
adminDisplayName: msSFU-30-Network-User
adminDescription: represents network file data
governsId: 1.2.840.113556.1.6.18.2.216
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.3.6.1.1.1.1.26
mayContain: 1.2.840.113556.1.6.18.1.339
mayContain: 1.2.840.113556.1.6.18.1.309
mayContain: 1.2.840.113556.1.6.18.1.324
possSuperiors: 1.2.840.113556.1.3.23
possSuperiors: 1.2.840.113556.1.5.67
schemaIdGuid:: ozRT4fALJ0S2chH12ErMkg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=msSFU-30-Network-User,CN=Schema,CN=Configuration,DC=X
dn: CN=msSFU-30-NIS-Map-Config,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSFU30NISMapConfig
adminDisplayName: msSFU-30-NIS-Map-Config
adminDescription: represents an internal Data Structure used by Server for NIS
governsId: 1.2.840.113556.1.6.18.2.217
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mayContain: 1.2.840.113556.1.6.18.1.306
mayContain: 1.2.840.113556.1.6.18.1.306
mayContain: 1.2.840.113556.1.6.18.1.305
mayContain: 1.2.840.113556.1.6.18.1.304
mayContain: 1.2.840.113556.1.6.18.1.303
mayContain: 1.2.840.113556.1.6.18.1.345
mayContain: 1.2.840.113556.1.6.18.1.302
mayContain: 1.2.840.113556.1.6.18.1.301
possSuperiors: 1.2.840.113556.1.3.23
schemaIdGuid:: 0DP3+uv4z02NdfF1OvalCw==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=msSFU-30-NIS-Map-Config,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DFSR-Subscription,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-Subscription
adminDisplayName: ms-DFSR-Subscription
adminDescription: Represents local computer participation of a content set
governsId: 1.2.840.113556.1.6.13.4.3
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mustContain: 1.2.840.113556.1.6.13.3.23
mustContain: 1.2.840.113556.1.6.13.3.18
mayContain: 1.2.840.113556.1.6.13.3.2
mayContain: 1.2.840.113556.1.6.13.3.17
mayContain: 1.2.840.113556.1.6.13.3.16
mayContain: 1.2.840.113556.1.6.13.3.24
mayContain: 1.2.840.113556.1.6.13.3.22
mayContain: 1.2.840.113556.1.6.13.3.9
mayContain: 1.2.840.113556.1.6.13.3.8
mayContain: 1.2.840.113556.1.6.13.3.7
mayContain: 1.2.840.113556.1.6.13.3.6
mayContain: 1.2.840.113556.1.6.13.3.5
mayContain: 1.2.840.113556.1.6.13.3.4
mayContain: 1.2.840.113556.1.6.13.3.3
possSuperiors: 1.2.840.113556.1.6.13.4.2
schemaIdGuid:: FCQhZ8x7CUaH4AiNrYq97g==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DFSR-Subscription,CN=Schema,CN=Configuration,DC=X
dn: CN=NisObject,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: nisObject
adminDisplayName: nisObject
adminDescription: An entry in a NIS map
governsId: 1.3.6.1.1.1.2.10
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mustContain: 1.3.6.1.1.1.1.27
mustContain: 1.3.6.1.1.1.1.26
mayContain: 1.2.840.113556.1.6.18.1.339
mayContain: 1.2.840.113556.1.6.18.1.309
possSuperiors: 1.2.840.113556.1.3.23
possSuperiors: 1.2.840.113556.1.5.67
schemaIdGuid:: k4pPkFRJX0yx4VPAl6MeEw==
schemaIdGuid:: k4pPkFRJX0yx4VPAl6MeEw==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=NisObject,CN=Schema,CN=Configuration,DC=X
dn: CN=IpService,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ipService
adminDisplayName: ipService
adminDescription: Abstraction of an Internet Protocol service.
governsId: 1.3.6.1.1.1.2.3
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mustContain: 1.3.6.1.1.1.1.15
mustContain: 1.3.6.1.1.1.1.16
mayContain: 1.3.6.1.1.1.1.26
mayContain: 1.2.840.113556.1.6.18.1.323
mayContain: 1.2.840.113556.1.6.18.1.339
mayContain: 1.2.840.113556.1.6.18.1.309
possSuperiors: 1.2.840.113556.1.3.23
possSuperiors: 1.2.840.113556.1.5.67
schemaIdGuid:: 3/oXJZf6rUid5nmsVyH4ZA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=IpService,CN=Schema,CN=Configuration,DC=X
dn: CN=IpNetwork,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ipNetwork
adminDisplayName: ipNetwork
adminDescription: Abstraction of a network. The distinguished value of the cn attribute denotes the
network's canonical name
governsId: 1.3.6.1.1.1.2.7
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
mustContain: 1.3.6.1.1.1.1.20
mayContain: 1.2.840.113556.1.6.18.1.323
mayContain: 1.3.6.1.1.1.1.26
mayContain: 1.2.840.113556.1.6.18.1.339
mayContain: 1.2.840.113556.1.6.18.1.309
mayContain: 2.5.4.7
mayContain: 0.9.2342.19200300.100.1.1
mayContain: 1.3.6.1.1.1.1.21
mayContain: 0.9.2342.19200300.100.1.10
possSuperiors: 1.2.840.113556.1.3.23
possSuperiors: 1.2.840.113556.1.5.67
schemaIdGuid:: wzZY2T4U+0OZKrBX8eyt+Q==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
systemOnly: FALSE
defaultObjectCategory: CN=IpNetwork,CN=Schema,CN=Configuration,DC=X
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.102
-
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.103
-
add: mayContain
mayContain: 1.2.840.113556.1.6.18.1.347
-
add: mayContain
mayContain: 1.2.840.113556.1.6.18.1.346
-
add: mayContain
mayContain: 1.2.840.113556.1.6.18.1.339
-
add: mayContain
mayContain: 1.2.840.113556.1.6.18.1.309
-
add: auxiliaryClass
auxiliaryClass: 1.3.6.1.1.1.2.2
-
add: mayContain
mayContain: 1.2.840.113556.1.4.1879
-
add: mayContain
mayContain: 1.2.840.113556.1.6.18.1.309
-
add: mayContain
mayContain: 1.2.840.113556.1.6.18.1.339
-
add: auxiliaryClass
-
add: auxiliaryClass
-
add: mayContain
mayContain: 1.2.840.113556.1.6.18.1.323
-
add: mayContain
mayContain: 1.3.6.1.1.1.1.26
-
add: mayContain
mayContain: 1.2.840.113556.1.6.18.1.339
-
add: mayContain
mayContain: 1.2.840.113556.1.6.18.1.309
-
add: auxiliaryClass
-
add: auxiliaryClass
-
add: auxiliaryClass
-
-
add: mayContain
mayContain: 1.2.840.113556.1.6.18.1.309
-
add: mayContain
mayContain: 1.3.6.1.1.1.1.26
-
add: mayContain
mayContain: 1.2.840.113556.1.6.18.1.339
-
add: mayContain
mayContain: 1.2.840.113556.1.6.18.1.323
-
add: auxiliaryClass
-
add: mayContain
mayContain: 1.2.840.113556.1.4.1879
-
dn:
changetype: modify
schemaUpdateNow: 1
-
objectVersion: 31
-
Sch32.ldf
dn: CN=ms-DS-KrbTgt-Link,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-KrbTgtLink
adminDisplayName: ms-DS-KrbTgt-Link
adminDescription: For a computer, Identifies the user object (krbtgt), acting as the domain or secondary
domain master secret. Depends on which domain or secondary domain the computer resides in.
attributeId: 1.2.840.113556.1.4.1923
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: yfWPd05vdEuFataDgzE5EA==
linkID: 2100
systemFlags: 16
dn: CN=ms-DS-Revealed-Users,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-RevealedUsers
adminDisplayName: ms-DS-Revealed-Users
adminDescription: For a Directory instance (DSA), Identifies the user objects whose secrets have been
disclosed to that instance
attributeId: 1.2.840.113556.1.4.1924
omSyntax: 127
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: IXhcGEk3OkS9aiiImQca2w==
linkID: 2102
systemFlags: 16
dn: CN=ms-DS-Revealed-List,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-RevealedList
adminDisplayName: ms-DS-Revealed-List
adminDescription: For a Directory instance (DSA), Identifies the user objects whose secrets have been
disclosed to that instance
attributeId: 1.2.840.113556.1.4.1940
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
omObjectClass:: KoZIhvcUAQEBDA==
schemaIdGuid:: HNHay+x/ezhiGToGJ9mvgQ==
systemFlags: 20
dn: CN=ms-DS-Has-Full-Replica-NCs,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-hasFullReplicaNCs
adminDisplayName: ms-DS-Has-Full-Replica-NCs
adminDescription: For a Directory instance (DSA), identifies the partitions held as full replicas
attributeId: 1.2.840.113556.1.4.1925
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: GC08HdBCaEiZ/g7KHm+p8w==
linkID: 2104
systemFlags: 16
dn: CN=ms-DS-Never-Reveal-Group,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-NeverRevealGroup
adminDisplayName: ms-DS-Never-Reveal-Group
adminDescription: For a Directory instance (DSA), identifies the security group whose users will never have
their secrets disclosed to that instance
attributeId: 1.2.840.113556.1.4.1926
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: mVlYFUn9Zk2yXe65arqBdA==
linkID: 2106
systemFlags: 16
dn: CN=ms-DS-Reveal-OnDemand-Group,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-RevealOnDemandGroup
adminDisplayName: ms-DS-Reveal-OnDemand-Group
adminDescription: For a Directory instance (DSA), identifies the security group whose users may have their
secrets disclosed to that instance
attributeId: 1.2.840.113556.1.4.1928
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Sp89MNYdOEuPxTOv6MmIrQ==
linkID: 2110
systemFlags: 16
dn: CN=ms-DS-Secondary-KrbTgt-Number,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-SecondaryKrbTgtNumber
adminDisplayName: ms-DS-Secondary-KrbTgt-Number
adminDescription: For a user object (krbtgt), acting as a secondary domain master secret, identifies the
protocol identification number associated with the secondary domain.
attributeId: 1.2.840.113556.1.4.1929
omSyntax: 2
systemOnly: TRUE
searchFlags: 1
rangeLower: 65536
rangeUpper: 65536
schemaIdGuid:: EmYVqpYjfkataijSP9sYZQ==
systemFlags: 16
dn: CN=ms-DS-Revealed-DSAs,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-RevealedDSAs
adminDisplayName: ms-DS-Revealed-DSAs
adminDescription: Backlink for ms-DS-Revealed-Users; for a user, identifies which Directory instances (DSA)
hold that user's secret
attributeId: 1.2.840.113556.1.4.1930
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: rPL2lG3HXku3H/Myw+k8Ig==
linkID: 2103
systemFlags: 17
dn: CN=ms-DS-KrbTgt-Link-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-KrbTgtLinkBl
adminDisplayName: ms-DS-KrbTgt-Link-BL
adminDescription: Backlink for ms-DS-KrbTgt-Link; for a user object (krbtgt) acting as a domain or secondary
domain master secret, identifies which computers are in that domain or secondary domain
attributeId: 1.2.840.113556.1.4.1931
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: QYzWXd+/i0ObXTnZYYvyYA==
linkID: 2101
systemFlags: 17
dn: CN=ms-DS-Is-Domain-For,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-IsDomainFor
adminDisplayName: ms-DS-Is-Domain-For
adminDescription: Backlink for ms-DS-Has-Domain-NCs; for a partition root object, identifies which Directory
instances (DSA) hold that partition as their primary domain
attributeId: 1.2.840.113556.1.4.1933
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: KloV/+VE4E2DGBOliYjeTw==
linkID: 2027
systemFlags: 17
dn: CN=ms-DS-Is-Full-Replica-For,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-IsFullReplicaFor
adminDisplayName: ms-DS-Is-Full-Replica-For
adminDescription: Backlink for ms-Ds-Has-Full-Replica-NCs; for a partition root object, identifies which
Directory instances (DSA) hold that partition as a full replica
attributeId: 1.2.840.113556.1.4.1932
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: 4HK8yLSm8EiUpf12qIyZhw==
linkID: 2105
systemFlags: 17
dn: CN=ms-DS-Is-Partial-Replica-For,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-IsPartialReplicaFor
adminDisplayName: ms-DS-Is-Partial-Replica-For
adminDescription: Backlink for has-Partial-Replica-NCs; for a partition root object, identifies which
Directory instances (DSA) hold that partition as a partial replica
attributeId: 1.2.840.113556.1.4.1934
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: 9k/JN9TGj0my+cb3+GR4CQ==
linkID: 75
systemFlags: 17
dn:
schemaUpdateNow: 1
-
-
-
-
-
dn:
schemaUpdateNow: 1
-
objectVersion: 32
-
Sch33.ldf
dn: CN=ms-DS-isGC,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-isGC
adminDisplayName: ms-DS-isGC
adminDescription: For a Directory instance (DSA), Identifies the state of the Global Catalog on the DSA
attributeId: 1.2.840.113556.1.4.1959
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: M8/1HeUPnkmQ4elLQnGKRg==
systemFlags: 20
dn: CN=ms-DS-isRODC,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-isRODC
adminDisplayName: ms-DS-isRODC
adminDescription: For a Directory instance (DSA), Identifies whether the DSA is a Read-Only DSA
attributeId: 1.2.840.113556.1.4.1960
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: I6roqGc+8Uqdei8aHWM6yQ==
systemFlags: 20
dn: CN=ms-DS-SiteName,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-SiteName
adminDisplayName: ms-DS-SiteName
adminDescription: For a Directory instance (DSA), Identifies the site name that contains the DSA
attributeId: 1.2.840.113556.1.4.1961
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: bfOnmJU1ikSeb2uJZbrtnA==
systemFlags: 20
dn: CN=ms-DS-AuthenticatedAt-DC,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthenticatedAtDC
adminDisplayName: ms-DS-AuthenticatedAt-DC
adminDescription: Forwardlink for ms-DS-AuthenticatedTo-Accountlist; for a User, identifies which DC a user
has authenticated to
attributeId: 1.2.840.113556.1.4.1958
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: nOkePgRmiUSJ2YR5iolRWg==
linkID: 2112
systemFlags: 16
dn: CN=ms-DS-Promotion-Settings,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PromotionSettings
adminDisplayName: ms-DS-Promotion-Settings
adminDescription: For a Computer, contains a XML string to be used for delegated DSA promotion
attributeId: 1.2.840.113556.1.4.1962
omSyntax: 64
systemOnly: TRUE
searchFlags: 0
rangeUpper: 65536
schemaIdGuid:: 4rSByMBDvk65u1JQqptDTA==
systemFlags: 16
dn: CN=ms-DS-Supported-Encryption-Types,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-SupportedEncryptionTypes
adminDisplayName: msDS-SupportedEncryptionTypes
adminDescription: The encryption algorithms supported by user, computer or trust accounts. The KDC uses this
information while generating a service ticket for this account. Services/Computers may automatically update
information while generating a service ticket for this account. Services/Computers may automatically update
this attribute on their respective accounts in Active Directory, and therefore need write access to this
attribute.
attributeId: 1.2.840.113556.1.4.1963
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: Z5gRIAQdt0qTcc/D1d8K/Q==
systemFlags: 16
dn: CN=ms-DS-AuthenticatedTo-Accountlist,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthenticatedToAccountlist
adminDisplayName: ms-DS-AuthenticatedTo-Accountlist
adminDescription: Backlink for ms-DS-AuthenticatedAt-DC; for a Computer, identifies which users have
authenticated to this Computer
attributeId: 1.2.840.113556.1.4.1957
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: ccmy6N+mvEeNb2J3DVJ6pQ==
linkID: 2113
systemFlags: 17
dn:
schemaUpdateNow: 1
-
dn: CN=ms-DS-Never-Reveal-Group,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ms-DS-Reveal-OnDemand-Group,CN=Schema,CN=Configuration,DC=X
-
-
-
-
-
-
-
-
-
dn:
schemaUpdateNow: 1
-
objectVersion: 33
-
Sch34.ldf
dn: CN=ms-DFSR-ReadOnly,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-ReadOnly
adminDisplayName: DFSR-ReadOnly
adminDescription: Specify whether the content is read-only or read-write
attributeId: 1.2.840.113556.1.6.13.3.28
omSyntax: 1
searchFlags: 0
schemaIdGuid:: IYDEWkfk50adI5LAxqkN+w==
dn: CN=ms-DFSR-Priority,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-Priority
adminDisplayName: DFSR-Priority
adminDescription: Priority level
attributeId: 1.2.840.113556.1.6.13.3.25
omSyntax: 2
searchFlags: 0
schemaIdGuid:: 1ucg660y3kKxQRatJjGwGw==
dn: CN=ms-DS-Az-Object-Guid,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzObjectGuid
adminDisplayName: MS-DS-Az-Object-Guid
adminDescription: The unique and portable identifier of AzMan objects
attributeId: 1.2.840.113556.1.4.1949
omSyntax: 4
systemOnly: TRUE
searchFlags: 1
rangeLower: 16
rangeUpper: 16
schemaIdGuid:: SOWRhDhsZUOnMq8EFWmwLA==
systemFlags: 16
dn: CN=ms-DS-Az-Generic-Data,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AzGenericData
adminDisplayName: MS-DS-Az-Generic-Data
adminDescription: AzMan specific generic data
attributeId: 1.2.840.113556.1.4.1950
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 65536
schemaIdGuid:: SeP3tVt6fECjNKMcP1OLmA==
systemFlags: 16
dn: CN=ms-DFSR-CachePolicy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-CachePolicy
adminDisplayName: DFSR-CachePolicy
adminDescription: On-demand cache policy options
attributeId: 1.2.840.113556.1.6.13.3.29
omSyntax: 2
searchFlags: 0
schemaIdGuid:: 5wh623b8aUWkX/XstmqItQ==
dn: CN=ms-DFSR-DeletedPath,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-DeletedPath
adminDisplayName: DFSR-DeletedPath
adminDescription: Full path of the Deleted directory
attributeId: 1.2.840.113556.1.6.13.3.26
omSyntax: 64
omSyntax: 64
searchFlags: 0
rangeUpper: 32767
schemaIdGuid:: uPB8gZXbFEm4M1oHnvZXZA==
dn: CN=ms-FVE-RecoveryGuid,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msFVE-RecoveryGuid
adminDisplayName: FVE-RecoveryGuid
adminDescription: This attribute contains the GUID associated with a Full Volume Encryption (FVE) recovery
password.
attributeId: 1.2.840.113556.1.4.1965
omSyntax: 4
searchFlags: 9
schemaIdGuid:: vAlp93jmoEews/hqAETAbQ==
systemFlags: 16
dn: CN=ms-TPM-OwnerInformation,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTPM-OwnerInformation
adminDisplayName: TPM-OwnerInformation
adminDescription: This attribute contains the owner information of a particular TPM.
attributeId: 1.2.840.113556.1.4.1966
omSyntax: 64
searchFlags: 8
schemaIdGuid:: bRpOqg1VBU6MNUr8uRep/g==
systemFlags: 16
dn: CN=ms-PKI-DPAPIMasterKeys,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKIDPAPIMasterKeys
adminDisplayName: MS-PKI-DPAPIMasterKeys
adminDescription: Storage of encrypted DPAPI Master Keys for user
attributeId: 1.2.840.113556.1.4.1893
omSyntax: 127
systemOnly: FALSE
searchFlags: 128
schemaIdGuid:: IzD5szmSfE+5nGdF2Hrbwg==
attributeSecurityGuid:: 3kfmkW/ZcEuVV9Y/9PPM2A==
linkID: 2046
systemFlags: 16
dn: CN=ms-DS-Phonetic-Last-Name,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PhoneticLastName
adminDisplayName: ms-DS-Phonetic-Last-Name
adminDescription: Contains the phonetic last name of the person.
attributeId: 1.2.840.113556.1.4.1943
omSyntax: 64
systemOnly: FALSE
searchFlags: 5
rangeLower: 1
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: 7OQX8jYIkEuIry9dS72ivA==
mapiID: 35983
systemFlags: 16
dn: CN=ms-PKI-RoamingTimeStamp,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKIRoamingTimeStamp
adminDisplayName: MS-PKI-RoamingTimeStamp
adminDescription: Time stamp for last change to roaming tokens
attributeId: 1.2.840.113556.1.4.1892
omSyntax: 4
systemOnly: FALSE
searchFlags: 128
schemaIdGuid:: rOQXZvGiq0O2DBH70frPBQ==
systemFlags: 16
dn: CN=ms-DFSR-DeletedSizeInMb,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-DeletedSizeInMb
adminDisplayName: DFSR-DeletedSizeInMb
adminDescription: Size of the Deleted directory in MB
attributeId: 1.2.840.113556.1.6.13.3.27
omSyntax: 65
searchFlags: 0
rangeUpper: -1
schemaIdGuid:: 0ZrtU3WZ9EGD9QwGGhJVOg==
dn: CN=ms-DS-Phonetic-First-Name,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PhoneticFirstName
adminDisplayName: ms-DS-Phonetic-First-Name
adminDescription: Contains the phonetic given name or first name of the person.
attributeId: 1.2.840.113556.1.4.1942
omSyntax: 64
systemOnly: FALSE
searchFlags: 5
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: TrocSy8wNEGsfPAfbHl4Qw==
mapiID: 35982
systemFlags: 16
dn: CN=ms-FVE-RecoveryPassword,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msFVE-RecoveryPassword
adminDisplayName: FVE-RecoveryPassword
adminDescription: This attribute contains the password required to recover a Full Volume Encryption (FVE)
volume.
attributeId: 1.2.840.113556.1.4.1964
omSyntax: 64
omSyntax: 64
searchFlags: 8
schemaIdGuid:: wRoGQ63IzEy3hSv6wg/GCg==
systemFlags: 16
dn: CN=ms-DS-Phonetic-Department,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PhoneticDepartment
adminDisplayName: ms-DS-Phonetic-Department
adminDescription: Contains the phonetic department name where the person works.
attributeId: 1.2.840.113556.1.4.1944
omSyntax: 64
systemOnly: FALSE
searchFlags: 5
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: rz3VbD4A50mnAm+oluem7w==
mapiID: 35984
systemFlags: 16
dn: CN=ms-PKI-AccountCredentials,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKIAccountCredentials
adminDisplayName: MS-PKI-AccountCredentials
adminDescription: Storage of encrypted user credential token blobs for roaming
attributeId: 1.2.840.113556.1.4.1894
omSyntax: 127
systemOnly: FALSE
searchFlags: 128
schemaIdGuid:: RKffuNwx8U6sfIS69++dpw==
linkID: 2048
systemFlags: 16
dn: CN=ms-RADIUS-FramedIpv6Route,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msRADIUS-FramedIpv6Route
adminDisplayName: ms-RADIUS-FramedIpv6Route
adminDescription: This Attribute provides routing information to be configured for the user on the NAS.
attributeId: 1.2.840.113556.1.4.1917
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 4096
schemaIdGuid:: BKhaWoMwY0iU5QGKeaIuwA==
dn: CN=ms-DS-Phonetic-Display-Name,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PhoneticDisplayName
adminDisplayName: ms-DS-Phonetic-Display-Name
adminDescription: The phonetic display name of an object. In the absence of a phonetic display name the
existing display name is used.
attributeId: 1.2.840.113556.1.4.1946
attributeId: 1.2.840.113556.1.4.1946
omSyntax: 64
systemOnly: FALSE
searchFlags: 5
rangeLower: 0
rangeUpper: 256
schemaIdGuid:: 5JQa4mYt5UyzDQ74endv8A==
mapiID: 35986
systemFlags: 16
dn: CN=ms-DS-Phonetic-Company-Name,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PhoneticCompanyName
adminDisplayName: ms-DS-Phonetic-Company-Name
adminDescription: Contains the phonetic company name where the person works.
attributeId: 1.2.840.113556.1.4.1945
omSyntax: 64
systemOnly: FALSE
searchFlags: 5
rangeLower: 1
rangeUpper: 64
schemaIdGuid:: jSDVW/TlrkalFFQ7ycR2WQ==
mapiID: 35985
systemFlags: 16
dn: CN=ms-net-ieee-8023-GP-PolicyData,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ms-net-ieee-8023-GP-PolicyData
adminDisplayName: ms-net-ieee-8023-GP-PolicyData
adminDescription: This attribute contains all of the settings and data which comprise a group policy
configuration for 802.3 wired networks.
attributeId: 1.2.840.113556.1.4.1955
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 1048576
schemaIdGuid:: i5SYg1d0kU29TY1+1mnJ9w==
systemFlags: 16
dn: CN=ms-net-ieee-8023-GP-PolicyGUID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ms-net-ieee-8023-GP-PolicyGUID
adminDisplayName: ms-net-ieee-8023-GP-PolicyGUID
adminDescription: This attribute contains a GUID which identifies a specific 802.3 group policy object on
the domain.
attributeId: 1.2.840.113556.1.4.1954
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 64
schemaIdGuid:: WrCnlLK4WU+cJTnmm6oWhA==
systemFlags: 16
dn: CN=ms-DFSR-MaxAgeInCacheInMin,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-MaxAgeInCacheInMin
adminDisplayName: DFSR-MaxAgeInCacheInMin
adminDescription: Maximum time in minutes to keep files in full form
attributeId: 1.2.840.113556.1.6.13.3.31
omSyntax: 2
searchFlags: 0
schemaIdGuid:: jeSwKk6s/EqD5aNCQNthmA==
dn: CN=ms-net-ieee-80211-GP-PolicyData,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ms-net-ieee-80211-GP-PolicyData
adminDisplayName: ms-net-ieee-80211-GP-PolicyData
adminDescription: This attribute contains all of the settings and data which comprise a group policy
configuration for 802.11 wireless networks.
attributeId: 1.2.840.113556.1.4.1952
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 4194304
schemaIdGuid:: pZUUnHZNjkaZHhQzsKZ4VQ==
systemFlags: 16
dn: CN=ms-RADIUS-FramedIpv6Prefix,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msRADIUS-FramedIpv6Prefix
adminDisplayName: ms-RADIUS-FramedIpv6Prefix
adminDescription: This Attribute indicates an IPv6 prefix (and corresponding route) to be configured for the
user.
attributeId: 1.2.840.113556.1.4.1915
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 16
schemaIdGuid:: ENY+9nzWTUmHvs0eJDWaOA==
systemFlags: 16
dn: CN=ms-net-ieee-80211-GP-PolicyGUID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ms-net-ieee-80211-GP-PolicyGUID
adminDisplayName: ms-net-ieee-80211-GP-PolicyGUID
adminDescription: This attribute contains a GUID which identifies a specific 802.11 group policy object on
the domain.
attributeId: 1.2.840.113556.1.4.1951
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 64
schemaIdGuid:: YnBpNa8ei0SsHjiOC+T97g==
systemFlags: 16
dn: CN=ms-RADIUS-FramedInterfaceId,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msRADIUS-FramedInterfaceId
adminDisplayName: ms-RADIUS-FramedInterfaceId
adminDescription: This Attribute indicates the IPv6 interface identifier to be configured for the user.
attributeId: 1.2.840.113556.1.4.1913
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 8
schemaIdGuid:: I0ryplzWZU2mTzX7aHPCuQ==
systemFlags: 16
dn: CN=ms-DS-NC-RO-Replica-Locations,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-NC-RO-Replica-Locations
adminDisplayName: ms-DS-NC-RO-Replica-Locations
adminDescription: a linked attribute on a cross ref object for a partition. This attribute lists the DSA
instances which should host the partition in a readonly manner.
attributeId: 1.2.840.113556.1.4.1967
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 35P3PViYF0SnAXNaHs6/dA==
linkID: 2114
systemFlags: 16
dn: CN=ms-DS-NC-RO-Replica-Locations-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-NC-RO-Replica-Locations-BL
adminDisplayName: ms-DS-NC-RO-Replica-Locations-BL
adminDescription: backlink attribute for ms-DS-NC-RO-Replica-Locations.
attributeId: 1.2.840.113556.1.4.1968
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: HFFH9SpbzESDWJkqiCWBZA==
linkID: 2115
systemFlags: 17
dn: CN=ms-DFSR-MinDurationCacheInMin,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-MinDurationCacheInMin
adminDisplayName: DFSR-MinDurationCacheInMin
adminDescription: Minimum time in minutes before truncating files
attributeId: 1.2.840.113556.1.6.13.3.30
omSyntax: 2
searchFlags: 0
schemaIdGuid:: emBdTEnOSkSYYoKpX10fzA==
dn: CN=ms-net-ieee-8023-GP-PolicyReserved,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ms-net-ieee-8023-GP-PolicyReserved
adminDisplayName: ms-net-ieee-8023-GP-PolicyReserved
adminDescription: Reserved for future use
attributeId: 1.2.840.113556.1.4.1956
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeUpper: 1048576
schemaIdGuid:: xyfF0wYm602M/RhCb+7Izg==
systemFlags: 16
dn: CN=ms-RADIUS-SavedFramedIpv6Route,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msRADIUS-SavedFramedIpv6Route
adminDisplayName: ms-RADIUS-SavedFramedIpv6Route
adminDescription: This Attribute provides routing information to be configured for the user on the NAS.
attributeId: 1.2.840.113556.1.4.1918
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 4096
schemaIdGuid:: XLtmlp3fQU20Ny7sfifJsw==
dn: CN=ms-net-ieee-80211-GP-PolicyReserved,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ms-net-ieee-80211-GP-PolicyReserved
adminDisplayName: ms-net-ieee-80211-GP-PolicyReserved
adminDescription: Reserved for future use
attributeId: 1.2.840.113556.1.4.1953
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeUpper: 4194304
schemaIdGuid:: LsZpD44I9U+lOukjzsB8Cg==
systemFlags: 16
dn: CN=ms-RADIUS-SavedFramedIpv6Prefix,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msRADIUS-SavedFramedIpv6Prefix
adminDisplayName: ms-RADIUS-SavedFramedIpv6Prefix
adminDescription: This Attribute indicates an IPv6 prefix (and corresponding route) to be configured for the
user.
attributeId: 1.2.840.113556.1.4.1916
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 16
schemaIdGuid:: YqBlCeGxO0C0jVwOsOlSzA==
systemFlags: 16
dn: CN=ms-RADIUS-SavedFramedInterfaceId,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msRADIUS-SavedFramedInterfaceId
adminDisplayName: ms-RADIUS-SavedFramedInterfaceId
adminDescription: This Attribute indicates the IPv6 interface identifier to be configured for the user.
attributeId: 1.2.840.113556.1.4.1914
omSyntax: 22
systemOnly: FALSE
searchFlags: 0
rangeUpper: 8
schemaIdGuid:: iXLapKOS5UK2ttrRbSgKyQ==
systemFlags: 16
dn: CN=SAM-Domain-Updates,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: samDomainUpdates
adminDisplayName: SAM-Domain-Updates
adminDescription: Contains a bitmask of performed SAM operations on active directory
attributeId: 1.2.840.113556.1.4.1969
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeUpper: 1024
schemaIdGuid:: FNHSBJn3m0683JDo9bp+vg==
systemFlags: 16
dn: CN=ms-DFSR-RootSizeInMb,CN=Schema,CN=Configuration,DC=X
delete: rangeUpper
-
dn:
schemaUpdateNow: 1
-
dn: CN=ms-net-ieee-8023-GroupPolicy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ms-net-ieee-8023-GroupPolicy
adminDisplayName: ms-net-ieee-8023-GroupPolicy
adminDescription: This class represents an 802.3 wired network group policy object. This class contains
identifiers and configuration data relevant to an 802.3 wired network.
governsId: 1.2.840.113556.1.5.252
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: ajqgmRmrRkSTUAy4eO0tmw==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-net-ieee-8023-GroupPolicy,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-net-ieee-80211-GroupPolicy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: ms-net-ieee-80211-GroupPolicy
adminDisplayName: ms-net-ieee-80211-GroupPolicy
adminDescription: This class represents an 802.11 wireless network group policy object. This class contains
identifiers and configuration data relevant to an 802.11 wireless network.
governsId: 1.2.840.113556.1.5.251
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: Yxi4HCK4eUOeol/3vcY4bQ==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
systemFlags: 16
dn: CN=ms-FVE-RecoveryInformation,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msFVE-RecoveryInformation
adminDisplayName: FVE-RecoveryInformation
adminDescription: This class contains a Full Volume Encryption recovery password with its associated GUID.
governsId: 1.2.840.113556.1.5.253
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: MF1x6lOP0EC9HmEJGG14LA==
systemOnly: FALSE
defaultObjectCategory: CN=ms-FVE-RecoveryInformation,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=NTDS-DSA-RO,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: nTDSDSARO
adminDisplayName: NTDS-DSA-RO
adminDescription: A subclass of Directory Service Agent which is distinguished by its reduced privilege
level.
governsId: 1.2.840.113556.1.5.254
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.7000.47
schemaIdGuid:: wW7RhZEHyEuKs3CYBgL/jA==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=NTDS-DSA-RO,CN=Schema,CN=Configuration,DC=X
defaultObjectCategory: CN=NTDS-DSA-RO,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.26
mayContain: 1.2.840.113556.1.6.13.3.27
mayContain: 1.2.840.113556.1.6.13.3.28
mayContain: 1.2.840.113556.1.6.13.3.29
mayContain: 1.2.840.113556.1.6.13.3.30
mayContain: 1.2.840.113556.1.6.13.3.31
-
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.4
mayContain: 1.2.840.113556.1.6.13.3.6
mayContain: 1.2.840.113556.1.6.13.3.8
mayContain: 1.2.840.113556.1.6.13.3.12
mayContain: 1.2.840.113556.1.6.13.3.13
mayContain: 1.2.840.113556.1.6.13.3.27
-
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.4
mayContain: 1.2.840.113556.1.6.13.3.6
mayContain: 1.2.840.113556.1.6.13.3.8
mayContain: 1.2.840.113556.1.6.13.3.25
mayContain: 1.2.840.113556.1.6.13.3.27
-
add: mayContain
mayContain: 1.2.840.113556.1.4.1942
mayContain: 1.2.840.113556.1.4.1943
mayContain: 1.2.840.113556.1.4.1944
mayContain: 1.2.840.113556.1.4.1945
mayContain: 1.2.840.113556.1.4.1946
-
-
-
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.25
-
-
-
add: mayContain
mayContain: 1.2.840.113556.1.4.1946
-
-
dn: CN=ms-DS-Az-Application,CN=Schema,CN=Configuration,DC=X
-
-
dn: CN=ms-DS-Az-Scope,CN=Schema,CN=Configuration,DC=X
-
-
-
dn: CN=Sam-Server,CN=Schema,CN=Configuration,DC=X
-
dn:
schemaUpdateNow: 1
-
dn: cn=Private-Information,CN=Extended-Rights,CN=Configuration,DC=X
cn: Private-Information
displayName: Private Information
rightsGUID: 91e647de-d96f-4b70-9557-d63ff4f3ccd8
validAccesses: 48
objectVersion: 34
-
Sch35.ldf
dn: CN=ms-DS-Last-Successful-Interactive-Logon-Time,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-LastSuccessfulInteractiveLogonTime
adminDisplayName: msDS-LastSuccessfulInteractiveLogonTime
adminDescription: The time that the correct password was presented during a C-A-D logon.
attributeId: 1.2.840.113556.1.4.1970
omSyntax: 65
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: 5ikZAV2LWEK2SgCwtJSXRw==
systemFlags: 16
dn: CN=ms-DS-Failed-Interactive-Logon-Count-At-Last-Successful-Logon,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon
adminDisplayName: ms-DS-Failed-Interactive-Logon-Count-At-Last-Successful-Logon
adminDescription: The total number of failed interactive logons up until the last successful C-A-D logon.
attributeId: 1.2.840.113556.1.4.1973
omSyntax: 2
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: 5TTSxUpkA0SmZeJuCu9emA==
systemFlags: 16
dn: CN=ms-DS-Failed-Interactive-Logon-Count,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-FailedInteractiveLogonCount
adminDisplayName: msDS-FailedInteractiveLogonCount
adminDescription: The total number of failed interactive logons since this feature was turned on.
attributeId: 1.2.840.113556.1.4.1972
omSyntax: 2
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: b6g83K1wYEmEJaTWMT2T3Q==
systemFlags: 16
dn: CN=ms-DS-Last-Failed-Interactive-Logon-Time,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-LastFailedInteractiveLogonTime
adminDisplayName: msDS-LastFailedInteractiveLogonTime
adminDescription: The time that an incorrect password was presented during a C-A-D logon.
attributeId: 1.2.840.113556.1.4.1971
omSyntax: 65
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: +trnx8MQi0uazVTxEGN0Lg==
systemFlags: 16
-
dn:
schemaUpdateNow: 1
-
objectVersion: 35
-
Sch36.ldf
dn: CN=ms-DS-Revealed-List-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-RevealedListBL
adminDisplayName: ms-DS-Revealed-List-BL
adminDescription: backlink attribute for ms-DS-Revealed-List.
attributeId: 1.2.840.113556.1.4.1975
omSyntax: 127
systemOnly: TRUE
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: /Ygcqvawn0Kyyp2QImboCA==
systemFlags: 20
dn: CN=From-Server,CN=Schema,CN=Configuration,DC=X
searchFlags: 1
-
searchFlags: 16
-
dn: CN=msNPCallingStationID,CN=Schema,CN=Configuration,DC=X
searchFlags: 16
-
dn: CN=msNPSavedCallingStationID,CN=Schema,CN=Configuration,DC=X
searchFlags: 16
-
searchFlags: 16
-
searchFlags: 16
-
searchFlags: 16
-
searchFlags: 16
-
dn: CN=msRASSavedCallbackNumber,CN=Schema,CN=Configuration,DC=X
searchFlags: 16
-
dn: CN=msRASSavedFramedIPAddress,CN=Schema,CN=Configuration,DC=X
searchFlags: 16
-
dn: CN=msRASSavedFramedRoute,CN=Schema,CN=Configuration,DC=X
searchFlags: 16
-
dn: CN=ms-RADIUS-FramedInterfaceId,CN=Schema,CN=Configuration,DC=X
searchFlags: 16
-
dn: CN=ms-RADIUS-SavedFramedInterfaceId,CN=Schema,CN=Configuration,DC=X
searchFlags: 16
-
dn: CN=ms-RADIUS-FramedIpv6Prefix,CN=Schema,CN=Configuration,DC=X
searchFlags: 16
-
dn: CN=ms-RADIUS-SavedFramedIpv6Prefix,CN=Schema,CN=Configuration,DC=X
searchFlags: 16
-
dn: CN=ms-RADIUS-FramedIpv6Route,CN=Schema,CN=Configuration,DC=X
searchFlags: 16
-
dn: CN=ms-RADIUS-SavedFramedIpv6Route,CN=Schema,CN=Configuration,DC=X
searchFlags: 16
-
searchFlags: 136
-
searchFlags: 137
-
searchFlags: 136
-
-
dn:
schemaUpdateNow: 1
-
dn: cn=Read-Only-Replication-Secret-Synchronization,CN=Extended-Rights,CN=Configuration,DC=X
replace: localizationDisplayId
-
dn: cn=Read-Only-Replication-Secret-Synchronization,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Read Only Replication Secret Synchronization
rightsGUID: 1131f6ae-9c07-11d1-f79f-00c04fc2dcd2
validAccesses: 256
objectVersion: 36
-
Sch37.ldf
dn: CN=ms-DS-User-Password-Expiry-Time-Computed,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-UserPasswordExpiryTimeComputed
adminDisplayName: ms-DS-User-Password-Expiry-Time-Computed
adminDescription: Contains the expiry time for the user's current password
attributeId: 1.2.840.113556.1.4.1996
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: EM/VrQl7SUSa5iU0FI+Kcg==
systemFlags: 20
dn: CN=ms-DS-Principal-Name,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PrincipalName
adminDisplayName: ms-DS-Principal-Name
adminDescription: Account name for the security principal (constructed)
attributeId: 1.2.840.113556.1.4.1865
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: JZNOVlfQQ8GeO0+eXvRvkw==
systemFlags: 20
dn: CN=ms-DFSR-OnDemandExclusionDirectoryFilter,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-OnDemandExclusionDirectoryFilter
adminDisplayName: DFSR-OnDemandExclusionDirectoryFilter
adminDescription: Filter string applied to on demand replication directories
adminDescription: Filter string applied to on demand replication directories
attributeId: 1.2.840.113556.1.6.13.3.36
omSyntax: 64
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: /zpSfRKQskmZJfkioAGGVg==
dn: CN=ms-DFSR-DefaultCompressionExclusionFilter,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-DefaultCompressionExclusionFilter
adminDisplayName: DFSR-DefaultCompressionExclusionFilter
adminDescription: Filter string containing extensions of file types not to be compressed
attributeId: 1.2.840.113556.1.6.13.3.34
omSyntax: 64
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: 1RuBh4vNy0WfXZgPOp4Mlw==
dn: CN=ms-TS-Home-Drive,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSHomeDrive
adminDisplayName: ms-TS-Home-Drive
adminDescription: Terminal Services Home Drive specifies a Home drive for the user. In a network
environment, this property is a string containing a drive specification (a drive letter followed by a colon)
to which the UNC path specified in the TerminalServicesHomeDirectory property is mapped. To set a home
directory in a network environment, you must first set this property and then set the
TerminalServicesHomeDirectory property.
attributeId: 1.2.840.113556.1.4.1978
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: 2SQKX/rf2Uysv6BoDANzHg==
systemFlags: 16
dn: CN=MS-TS-Property01,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSProperty01
adminDisplayName: MS-TS-Property01
adminDescription: Placeholder Terminal Server Property 01
attributeId: 1.2.840.113556.1.4.1991
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: d6mu+lWW10mFPfJ7t6rKDw==
systemFlags: 16
dn: CN=MS-TS-Property02,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSProperty02
adminDisplayName: MS-TS-Property02
adminDescription: Placeholder Terminal Server Property 02
attributeId: 1.2.840.113556.1.4.1992
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: rPaGNbdReEmrQvk2RjGY5w==
systemFlags: 16
dn: CN=ms-TS-Allow-Logon,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSAllowLogon
adminDisplayName: ms-TS-Allow-Logon
adminDescription: Terminal Services Allow Logon specifies whether the user is allowed to log on to the
Terminal Server. The value is 1 if logon is allowed, and 0 if logon is not allowed.
attributeId: 1.2.840.113556.1.4.1979
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ZNQMOlS850CTrqZGpuzEtA==
systemFlags: 16
dn: CN=MS-TS-ExpireDate,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSExpireDate
adminDisplayName: MS-TS-ExpireDate
adminDescription: TS Expiration Date
attributeId: 1.2.840.113556.1.4.1993
omSyntax: 24
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: 9U4AcMMlakSXyJlq6FZndg==
systemFlags: 16
dn: CN=MS-TS-ManagingLS,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSManagingLS
adminDisplayName: MS-TS-ManagingLS
adminDescription: TS Managing License Server
attributeId: 1.2.840.113556.1.4.1995
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: R8W887CFLEOawDBFBr8sgw==
systemFlags: 16
dn: CN=ms-DFSR-Options2,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-Options2
adminDisplayName: DFSR-Options2
adminDescription: Object Options2
attributeId: 1.2.840.113556.1.6.13.3.37
omSyntax: 2
searchFlags: 0
schemaIdGuid:: GEPiEaZMSU+a/uXrGvo0cw==
dn: CN=ms-TS-Profile-Path,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSProfilePath
adminDisplayName: ms-TS-Profile-Path
adminDescription: Terminal Services Profile Path specifies a roaming or mandatory profile path to use when
the user logs on to the Terminal Server. The profile path is in the following network path format:
\\servername\profiles folder name\username
attributeId: 1.2.840.113556.1.4.1976
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: 2zBc5mwxYECjoDh7CD8JzQ==
systemFlags: 16
dn: CN=ms-TS-Max-Idle-Time,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSMaxIdleTime
adminDisplayName: ms-TS-Max-Idle-Time
adminDescription: Terminal Services Session Maximum Idle Time is maximum amount of time, in minutes, that
the Terminal Services session can remain idle. After the specified number of minutes have elapsed, the
session can be disconnected or terminated.
attributeId: 1.2.840.113556.1.4.1983
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: nJ5z/7drDkayIeJQ894PlQ==
systemFlags: 16
dn: CN=ms-TS-Home-Directory,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSHomeDirectory
adminDisplayName: ms-TS-Home-Directory
adminDescription: Terminal Services Home Directory specifies the Home directory for the user. Each user on a
Terminal Server has a unique home directory. This ensures that application information is stored separately
for each user in a multi-user environment. To set a home directory on the local computer, specify a local
path; for example, C:\Path. To set a home directory in a network environment, you must first set the
TerminalServicesHomeDrive property, and then set this property to a UNC path.
attributeId: 1.2.840.113556.1.4.1977
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: 8BA1XefEIkG5H6IK3ZDiRg==
systemFlags: 16
systemFlags: 16
dn: CN=ms-TS-Remote-Control,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSRemoteControl
adminDisplayName: ms-TS-Remote-Control
adminDescription: Terminal Services Remote Control specifies the whether to allow remote observation or
remote control of the user's Terminal Services session. For a description of these values, see the
RemoteControl method of the Win32_TSRemoteControlSetting WMI class. 0 - Disable, 1 - EnableInputNotify, 2 -
EnableInputNoNotify, 3 - EnableNoInputNotify and 4 - EnableNoInputNoNotify
attributeId: 1.2.840.113556.1.4.1980
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: JnIXFUKGi0aMSAPd/QBJgg==
systemFlags: 16
dn: CN=ms-TS-Work-Directory,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSWorkDirectory
adminDisplayName: ms-TS-Work-Directory
adminDescription: Terminal Services Session Work Directory specifies the working directory path for the
user. To set an initial application to start when the user logs on to the Terminal Server, you must first
set the TerminalServicesInitialProgram property, and then set this property.
attributeId: 1.2.840.113556.1.4.1989
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: ZvZEpzw9yEyDS51Pb2h7iw==
systemFlags: 16
dn: CN=ms-TS-Initial-Program,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSInitialProgram
adminDisplayName: ms-TS-Initial-Program
adminDescription: Terminal Services Session Initial Program specifies the Path and file name of the
application that the user wants to start automatically when the user logs on to the Terminal Server. To set
an initial application to start when the user logs on, you must first set this property and then set the
TerminalServicesWorkDirectory property. If you set only the TerminalServicesInitialProgram property, the
application starts in the user's session in the default user directory.
attributeId: 1.2.840.113556.1.4.1990
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: b6wBkmkd+02ALtlVEBCVmQ==
systemFlags: 16
dn: CN=MS-TS-LicenseVersion,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSLicenseVersion
adminDisplayName: MS-TS-LicenseVersion
adminDescription: TS License Version
attributeId: 1.2.840.113556.1.4.1994
attributeId: 1.2.840.113556.1.4.1994
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: iUrpCi838k2uisZKK8RyeA==
systemFlags: 16
dn: CN=ms-TS-Max-Connection-Time,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSMaxConnectionTime
adminDisplayName: ms-TS-Max-Connection-Time
adminDescription: Terminal Services Session maximum Connection Time is Maximum duration, in minutes, of the
Terminal Services session. After the specified number of minutes have elapsed, the session can be
disconnected or terminated.
attributeId: 1.2.840.113556.1.4.1982
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 4g6WHWRklU6ngeO1zV+ViA==
systemFlags: 16
dn: CN=ms-TS-Reconnection-Action,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSReconnectionAction
adminDisplayName: ms-TS-Reconnection-Action
adminDescription: Terminal Services Session Reconnection Action specifies whether to allow reconnection to a
disconnected Terminal Services session from any client computer. The value is 1 if reconnection is allowed
from the original client computer only, and 0 if reconnection from any client computer is allowed.
attributeId: 1.2.840.113556.1.4.1984
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: ytduNhg+f0yrrjUaAeS09w==
systemFlags: 16
dn: CN=ms-TS-Connect-Client-Drives,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSConnectClientDrives
adminDisplayName: ms-TS-Connect-Client-Drives
adminDescription: Terminal Services Session Connect Client Drives At Logon specifies whether to reconnect to
mapped client drives at logon. The value is 1 if reconnection is enabled, and 0 if reconnection is disabled.
attributeId: 1.2.840.113556.1.4.1986
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: rypXI90p6kSw+n6EOLmkow==
systemFlags: 16
dn: CN=ms-DFSR-CommonStagingPath,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-CommonStagingPath
adminDisplayName: DFSR-CommonStagingPath
adminDescription: Full path of the common staging directory
attributeId: 1.2.840.113556.1.6.13.3.38
attributeId: 1.2.840.113556.1.6.13.3.38
omSyntax: 64
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: Qaxuk1fSuUu9VfMQo88JrQ==
dn: CN=ms-TS-Max-Disconnection-Time,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSMaxDisconnectionTime
adminDisplayName: ms-TS-Max-Disconnection-Time
adminDescription: Terminal Services Session Maximum Disconnection Time is maximum amount of time, in
minutes, that a disconnected Terminal Services session remains active on the Terminal Server. After the
specified number of minutes have elapsed, the session is terminated.
attributeId: 1.2.840.113556.1.4.1981
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: iXBvMthThEe4FEbYU1EQ0g==
systemFlags: 16
dn: CN=ms-TS-Default-To-Main-Printer,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSDefaultToMainPrinter
adminDisplayName: ms-TS-Default-To-Main-Printer
adminDescription: Terminal Services Default To Main Printer specifies whether to print automatically to the
client's default printer. The value is 1 if printing to the client's default printer is enabled, and 0 if it
is disabled.
attributeId: 1.2.840.113556.1.4.1988
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: veL/wM/Kx02I1WHp6Vdm9g==
systemFlags: 16
dn: CN=ms-TS-Connect-Printer-Drives,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSConnectPrinterDrives
adminDisplayName: ms-TS-Connect-Printer-Drives
adminDescription: Terminal Services Session Connect Printer Drives At Logon specifies whether to reconnect
to mapped client printers at logon. The value is 1 if reconnection is enabled, and 0 if reconnection is
disabled.
attributeId: 1.2.840.113556.1.4.1987
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: N6nmjBuHkkyyhdmdQDZoHA==
systemFlags: 16
dn: CN=ms-TS-Broken-Connection-Action,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSBrokenConnectionAction
adminDisplayName: ms-TS-Broken-Connection-Action
adminDescription: Terminal Services Session Broken Connection Action specifies the action to take when a
adminDescription: Terminal Services Session Broken Connection Action specifies the action to take when a
Terminal Services session limit is reached. The value is 1 if the client session should be terminated, and 0
if the client session should be disconnected.
attributeId: 1.2.840.113556.1.4.1985
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: uhv0HARWPkaU1hoSh7csow==
systemFlags: 16
dn: CN=ms-DFSR-DisablePacketPrivacy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-DisablePacketPrivacy
adminDisplayName: DFSR-DisablePacketPrivacy
adminDescription: Disable packet privacy on a connection
attributeId: 1.2.840.113556.1.6.13.3.32
omSyntax: 1
searchFlags: 0
schemaIdGuid:: 5e2Eah50/UOd1qoPYVeGIQ==
dn: CN=ms-DFSR-CommonStagingSizeInMb,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-CommonStagingSizeInMb
adminDisplayName: DFSR-CommonStagingSizeInMb
adminDescription: Size of the common staging directory in MB
attributeId: 1.2.840.113556.1.6.13.3.39
omSyntax: 65
searchFlags: 0
rangeLower: 0
rangeUpper: -1
schemaIdGuid:: DrBeE0ZIi0WOoqN1Wa/UBQ==
dn: CN=ms-DFSR-OnDemandExclusionFileFilter,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-OnDemandExclusionFileFilter
adminDisplayName: DFSR-OnDemandExclusionFileFilter
adminDescription: Filter string applied to on demand replication files
attributeId: 1.2.840.113556.1.6.13.3.35
omSyntax: 64
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: 3FmDpoGl5k6QFVOCxg8PtA==
dn: CN=ms-DFSR-StagingCleanupTriggerInPercent,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDFSR-StagingCleanupTriggerInPercent
adminDisplayName: DFSR-StagingCleanupTriggerInPercent
adminDescription: Staging cleanup trigger in percent of free disk space
attributeId: 1.2.840.113556.1.6.13.3.40
omSyntax: 2
searchFlags: 0
searchFlags: 0
schemaIdGuid:: I5xL1vrhe0azF2lk10TWMw==
searchFlags: 1
-
attributeSecurityGuid:: YrwFWMm9KESl4oVqD0wYXg==
-
dn: CN=MS-TS-LicenseVersion,CN=Schema,CN=Configuration,DC=X
-
dn: CN=MS-TS-ManagingLS,CN=Schema,CN=Configuration,DC=X
-
-
dn:
schemaUpdateNow: 1
-
dn: CN=ms-DFSR-LocalSettings,CN=Schema,CN=Configuration,DC=X
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.37
mayContain: 1.2.840.113556.1.6.13.3.38
mayContain: 1.2.840.113556.1.6.13.3.39
mayContain: 1.2.840.113556.1.6.13.3.40
-
dn: CN=ms-DFSR-Subscriber,CN=Schema,CN=Configuration,DC=X
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.37
-
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.35
mayContain: 1.2.840.113556.1.6.13.3.36
mayContain: 1.2.840.113556.1.6.13.3.37
mayContain: 1.2.840.113556.1.6.13.3.40
-
dn: CN=ms-DFSR-GlobalSettings,CN=Schema,CN=Configuration,DC=X
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.37
-
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.34
mayContain: 1.2.840.113556.1.6.13.3.35
mayContain: 1.2.840.113556.1.6.13.3.36
mayContain: 1.2.840.113556.1.6.13.3.37
-
dn: CN=ms-DFSR-Content,CN=Schema,CN=Configuration,DC=X
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.37
-
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.34
mayContain: 1.2.840.113556.1.6.13.3.35
mayContain: 1.2.840.113556.1.6.13.3.36
mayContain: 1.2.840.113556.1.6.13.3.37
-
dn: CN=ms-DFSR-Topology,CN=Schema,CN=Configuration,DC=X
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.37
-
dn: CN=ms-DFSR-Member,CN=Schema,CN=Configuration,DC=X
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.37
-
-
add: mayContain
mayContain: 1.2.840.113556.1.6.13.3.32
mayContain: 1.2.840.113556.1.6.13.3.37
-
-
-
-
-
-
dn: CN=ms-DS-AuthenticatedTo-Accountlist,CN=Schema,CN=Configuration,DC=X
add: adminDescription
adminDescription: Backlink for ms-DS-AuthenticatedAt-DC; for a Computer, identifies which users have
authenticated to this Computer
-
dn:
schemaUpdateNow: 1
-
displayName: MS-TS-GatewayAccess
rightsGuid: ccc2dc7d-a6ad-4a7a-8846-c04e3cc53501
validAccesses: 48
dn: CN=Terminal-Server-License-Server,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Terminal Server License Server
rightsGuid: ccc2dc7d-a6ad-4a7a-8846-c04e3cc53501
appliesTo: 5805bc62-bdc9-4428-a5e2-856a0f4c185e
validAccesses: 48
objectVersion: 37
-
Sch38.ldf
dn: CN=ms-DS-AuthenticatedAt-DC,CN=Schema,CN=Configuration,DC=X
replace: systemOnly
systemOnly: FALSE
-
dn:
schemaUpdateNow: 1
-
objectVersion: 38
-
Sch39.ldf
dn: CN=ms-FVE-KeyPackage,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msFVE-KeyPackage
adminDisplayName: FVE-KeyPackage
adminDescription: This attribute contains a volume's BitLocker encryption key secured by the corresponding
recovery password. Full Volume Encryption (FVE) was the pre-release name for BitLocker Drive Encryption.
attributeId: 1.2.840.113556.1.4.1999
omSyntax: 4
searchFlags: 152
rangeUpper: 102400
schemaIdGuid:: qF7VH6eI3EeBKQ2qlxhqVA==
systemFlags: 16
dn: CN=ms-FVE-VolumeGuid,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msFVE-VolumeGuid
adminDisplayName: FVE-VolumeGuid
adminDescription: This attribute contains the GUID associated with a BitLocker-supported disk volume. Full
Volume Encryption (FVE) was the pre-release name for BitLocker Drive Encryption.
attributeId: 1.2.840.113556.1.4.1998
omSyntax: 4
searchFlags: 27
rangeUpper: 128
schemaIdGuid:: z6Xlhe7cdUCc/aydtqLyRQ==
systemFlags: 16
dn: CN=ms-DS-HAB-Seniority-Index,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-HABSeniorityIndex
adminDisplayName: ms-DS-HAB-Seniority-Index
adminDescription: Contains the seniority index as applied by the organization where the person works.
attributeId: 1.2.840.113556.1.4.1997
omSyntax: 2
systemOnly: FALSE
mapiID: 36000
searchFlags: 1
schemaIdGuid:: 8Un03jv9RUCYz9lljaeItQ==
systemFlags: 16
adminDescription: This attribute contains a password that can recover a BitLocker-encrypted volume. Full
-
add: rangeUpper
rangeUpper: 256
-
searchFlags: 152
-
adminDescription: This attribute contains the GUID associated with a BitLocker recovery password. Full
-
add: rangeUpper
rangeUpper: 128
-
searchFlags: 27
-
add: rangeUpper
rangeUpper: 128
-
searchFlags: 152
-
dn:
schemaUpdateNow: 1
-
-
adminDescription: This class contains BitLocker recovery information including GUIDs, recovery passwords,
and keys. Full Volume Encryption (FVE) was the pre-release name for BitLocker Drive Encryption.
-
dn: CN=msSFU-30-Posix-Member,CN=Schema,CN=Configuration,DC=X
adminDescription: This attribute is used to store the DN display name of users which are a part of the group
-
-
dn: CN=NTDS-DSA-RO,CN=Schema,CN=Configuration,DC=X
replace: systemOnly
systemOnly: TRUE
-
add: mayContain
mayContain: 1.2.840.113556.1.4.1997
-
dn:
schemaUpdateNow: 1
-
objectVersion: 39
-
Sch40.ldf
dn: CN=ms-DS-Password-Reversible-Encryption-Enabled,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PasswordReversibleEncryptionEnabled
adminDisplayName: Password Reversible Encryption Status
adminDescription: Password reversible encryption status for user accounts
attributeId: 1.2.840.113556.1.4.2016
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: j93MdWyvh0S7S2nk04qVnA==
systemFlags: 16
dn: CN=ms-DS-NC-Type,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-NcType
ldapDisplayName: msDS-NcType
adminDisplayName: ms-DS-NC-Type
adminDescription: A bit field that maintains information about aspects of a NC replica that are relevant to
replication.
attributeId: 1.2.840.113556.1.4.2024
omSyntax: 2
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: 16wuWivMz0idmrbxoAJN6Q==
systemFlags: 17
dn: CN=ms-DS-PSO-Applies-To,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PSOAppliesTo
adminDisplayName: Password settings object applies to
adminDescription: Links to objects that this password settings object applies to
attributeId: 1.2.840.113556.1.4.2020
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: SA/IZNLNgUiobU6XtvVh/A==
linkID: 2118
systemFlags: 16
dn: CN=ms-DS-PSO-Applied,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PSOApplied
adminDisplayName: Password settings object applied
adminDescription: Password settings object applied to this object
attributeId: 1.2.840.113556.1.4.2021
omSyntax: 127
systemOnly: TRUE
searchFlags: 16
schemaIdGuid:: MfBsXqi9yEOspI/uQScAWw==
linkID: 2119
systemFlags: 17
dn: CN=ms-DS-Resultant-PSO,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ResultantPSO
adminDisplayName: Resultant password settings object applied
adminDescription: Resultant password settings object applied to this object
attributeId: 1.2.840.113556.1.4.2022
omSyntax: 127
systemOnly: TRUE
searchFlags: 16
schemaIdGuid:: k6B+t9CIgEeamJEfjosdyg==
systemFlags: 20
dn: CN=ms-DS-Lockout-Duration,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-LockoutDuration
adminDisplayName: Lockout Duration
adminDescription: Lockout duration for locked out user accounts
attributeId: 1.2.840.113556.1.4.2018
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
rangeUpper: 0
schemaIdGuid:: mogfQi5H5E+OueHQvGBxsg==
systemFlags: 16
dn: CN=ms-DS-Lockout-Threshold,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-LockoutThreshold
adminDisplayName: Lockout Threshold
adminDescription: Lockout threshold for lockout of user accounts
attributeId: 1.2.840.113556.1.4.2019
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 65535
schemaIdGuid:: XsPIuBlKlUqZ0Gn+REYobw==
systemFlags: 16
dn: CN=ms-DS-Minimum-Password-Age,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-MinimumPasswordAge
adminDisplayName: Minimum Password Age
adminDescription: Minimum Password Age for user accounts
attributeId: 1.2.840.113556.1.4.2012
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
rangeUpper: 0
schemaIdGuid:: ePh0KpxN+UmXs2dn0cvZow==
systemFlags: 16
dn: CN=ms-DS-Maximum-Password-Age,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-MaximumPasswordAge
adminDisplayName: Maximum Password Age
adminDescription: Maximum Password Age for user accounts
attributeId: 1.2.840.113556.1.4.2011
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
rangeUpper: 0
schemaIdGuid:: 9TfT/ZlJzk+yUo/5ybQ4dQ==
systemFlags: 16
dn: CN=ms-DS-Minimum-Password-Length,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-MinimumPasswordLength
adminDisplayName: Minimum Password Length
adminDescription: Minimum Password Length for user accounts
attributeId: 1.2.840.113556.1.4.2013
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 255
schemaIdGuid:: OTQbsjpMHES7XwjyDpsxXg==
systemFlags: 16
dn: CN=ms-DS-Password-History-Length,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PasswordHistoryLength
adminDisplayName: Password History Length
adminDescription: Password History Length for user accounts
attributeId: 1.2.840.113556.1.4.2014
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 65535
schemaIdGuid:: txvY/ox2L0yWQSJF3jR5TQ==
systemFlags: 16
dn: CN=ms-DS-Lockout-Observation-Window,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-LockoutObservationWindow
adminDisplayName: Lockout Observation Window
adminDescription: Observation Window for lockout of user accounts
attributeId: 1.2.840.113556.1.4.2017
omSyntax: 65
systemOnly: FALSE
searchFlags: 0
rangeUpper: 0
schemaIdGuid:: idpbsK92ika4khvlVVjsyA==
systemFlags: 16
dn: CN=ms-DS-Password-Complexity-Enabled,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PasswordComplexityEnabled
adminDisplayName: Password Complexity Status
adminDescription: Password complexity status for user accounts
attributeId: 1.2.840.113556.1.4.2015
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: SwVo28PJ8EuxWw+1JVKmEA==
systemFlags: 16
dn: CN=ms-DS-Password-Settings-Precedence,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DS-Password-Settings-Precedence,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PasswordSettingsPrecedence
adminDisplayName: Password Settings Precedence
adminDescription: Password Settings Precedence
attributeId: 1.2.840.113556.1.4.2023
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
rangeLower: 1
schemaIdGuid:: rHRjRQofF0aTz7xVp8nTQQ==
systemFlags: 16
dn: CN=MS-TS-ManagingLS2,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSManagingLS2
adminDisplayName: MS-TS-ManagingLS2
adminDescription: Issuer name of the second TS per user CAL.
attributeId: 1.2.840.113556.1.4.2002
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
rangeLower: 0
rangeUpper: 255
schemaIdGuid:: VwefNL1RyE+dZj7O6oolvg==
systemFlags: 16
adminDescription: Issuer name of the third TS per user CAL.
attributeId: 1.2.840.113556.1.4.2005
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
rangeLower: 0
rangeUpper: 255
schemaIdGuid:: wdzV+jAhh0yhGHUyLNZwUA==
systemFlags: 16
adminDescription: Issuer name of the fourth TS per user CAL.
attributeId: 1.2.840.113556.1.4.2008
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
rangeLower: 0
rangeUpper: 255
schemaIdGuid:: oLaj9wchQEGzBnXLUhcx5Q==
schemaIdGuid:: oLaj9wchQEGzBnXLUhcx5Q==
systemFlags: 16
dn: CN=MS-TS-ExpireDate2,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSExpireDate2
adminDisplayName: MS-TS-ExpireDate2
adminDescription: Expiration date of the second TS per user CAL.
attributeId: 1.2.840.113556.1.4.2000
omSyntax: 24
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: cc/fVD+8C0+dWkskdruJJQ==
systemFlags: 16
adminDescription: Expiration date of the third TS per user CAL.
attributeId: 1.2.840.113556.1.4.2003
omSyntax: 24
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: BH+8QXK+MEm9EB80OUEjhw==
systemFlags: 16
adminDescription: Expiration date of the fourth TS per user CAL.
attributeId: 1.2.840.113556.1.4.2006
omSyntax: 24
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: Q9wRXkogr0+gCGhjYhxvXw==
systemFlags: 16
dn: CN=MS-TSLS-Property01,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSLSProperty01
adminDisplayName: MS-TSLS-Property01
adminDescription: Placeholder Terminal Server License Server Property 01
attributeId: 1.2.840.113556.1.4.2009
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
rangeLower: 0
rangeUpper: 32767
rangeUpper: 32767
schemaIdGuid:: kDXlhx2XUkqVW0eU0VqErg==
systemFlags: 16
dn: CN=MS-TSLS-Property02,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSLSProperty02
adminDisplayName: MS-TSLS-Property02
adminDescription: Placeholder Terminal Server License Server Property 02
attributeId: 1.2.840.113556.1.4.2010
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
rangeLower: 0
rangeUpper: 32767
schemaIdGuid:: sHvHR24xL06X8Q1MSPyp3Q==
systemFlags: 16
dn: CN=MS-TS-LicenseVersion2,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSLicenseVersion2
adminDisplayName: MS-TS-LicenseVersion2
adminDescription: Version of the second TS per user CAL.
attributeId: 1.2.840.113556.1.4.2001
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
rangeLower: 0
rangeUpper: 255
schemaIdGuid:: A/ENS5eN2UWtaYXDCAuk5w==
systemFlags: 16
adminDescription: Version of the third TS per user CAL.
attributeId: 1.2.840.113556.1.4.2004
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
rangeLower: 0
rangeUpper: 255
schemaIdGuid:: gY+6+KtMc0mjyDptpipeMQ==
systemFlags: 16
adminDescription: Version of the fourth TS per user CAL.
attributeId: 1.2.840.113556.1.4.2007
omSyntax: 64
omSyntax: 64
systemOnly: FALSE
searchFlags: 1
rangeLower: 0
rangeUpper: 255
schemaIdGuid:: l13KcAQjCkmKJ1JnjI0glQ==
systemFlags: 16
dn: CN=ms-DS-Is-User-Cachable-At-Rodc,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-IsUserCachableAtRodc
adminDisplayName: ms-DS-Is-User-Cachable-At-Rodc
adminDescription: For a Read-Only Directory instance (DSA), Identifies whether the specified user's secrets
are cachable.
attributeId: 1.2.840.113556.1.4.2025
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: WiQB/h80VkWVH0jAM6iQUA==
systemFlags: 20
replace: rangeUpper
rangeUpper: 128
-
dn: CN=Last-Logon-Timestamp,CN=Schema,CN=Configuration,DC=X
searchFlags: 1
-
searchFlags: 664
-
searchFlags: 664
-
dn: CN=ms-FVE-KeyPackage,CN=Schema,CN=Configuration,DC=X
searchFlags: 664
-
replace: mapiId
mapiId: 35998
-
dn: CN=ms-DS-Source-Object-DN,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ipServiceProtocol,CN=Schema,CN=Configuration,DC=X
-
dn:
schemaUpdateNow: 1
-
-
dn: CN=ipService,CN=Schema,CN=Configuration,DC=X
add: possSuperiors
possSuperiors: 1.2.840.113556.1.5.67
-
dn: CN=ipService,CN=Schema,CN=Configuration,DC=X
add: possSuperiors
-
dn: CN=ipProtocol,CN=Schema,CN=Configuration,DC=X
add: possSuperiors
possSuperiors: 1.2.840.113556.1.5.67
-
dn: CN=ipProtocol,CN=Schema,CN=Configuration,DC=X
add: possSuperiors
-
dn: CN=ipHost,CN=Schema,CN=Configuration,DC=X
add: mayContain
mayContain: 0.9.2342.19200300.100.1.10
-
dn: CN=ipNetwork,CN=Schema,CN=Configuration,DC=X
add: possSuperiors
possSuperiors: 1.2.840.113556.1.5.67
-
add: possSuperiors
-
add: mayContain
mayContain: 0.9.2342.19200300.100.1.10
-
dn: CN=nisNetgroup,CN=Schema,CN=Configuration,DC=X
add: possSuperiors
possSuperiors: 1.2.840.113556.1.5.67
-
dn: CN=nisNetGroup,CN=Schema,CN=Configuration,DC=X
add: possSuperiors
-
dn: CN=nisMap,CN=Schema,CN=Configuration,DC=X
add: possSuperiors
possSuperiors: 1.2.840.113556.1.5.67
-
dn: CN=nisObject,CN=Schema,CN=Configuration,DC=X
add: possSuperiors
possSuperiors: 1.2.840.113556.1.5.67
-
dn: CN=nisObject,CN=Schema,CN=Configuration,DC=X
add: possSuperiors
-
add: possSuperiors
possSuperiors: 1.2.840.113556.1.5.67
-
add: possSuperiors
-
add: possSuperiors
possSuperiors: 1.2.840.113556.1.5.67
-
add: possSuperiors
-
add: possSuperiors
possSuperiors: 1.2.840.113556.1.5.67
-
add: possSuperiors
-
dn: CN=ms-DS-Password-Settings-Container,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PasswordSettingsContainer
adminDisplayName: ms-DS-Password-Settings-Container
adminDescription: Container for password settings objects
governsId: 1.2.840.113556.1.5.256
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: arAGW/NMwES9FkO8EKmH2g==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Password-Settings-Container,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Password-Settings,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PasswordSettings
adminDisplayName: ms-DS-Password-Settings
adminDescription: Password settings object for accounts
governsId: 1.2.840.113556.1.5.255
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: uJ3NO0v4HEWVL2xSuB+exg==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Password-Settings,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
-
add: mayContain
mayContain: 1.2.840.113556.1.4.1998
mayContain: 1.2.840.113556.1.4.1999
-
-
-
-
-
dn:
schemaUpdateNow: 1
-
dn: CN=Reload-SSL-Certificate,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Reload SSL/TLS Certificate
rightsGuid: 1a60ea8d-58a6-4b20-bcdc-fb71eb8a9ff8
validAccesses: 256
dn: CN=DS-Replication-Get-Changes-In-Filtered-Set,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Replicating Directory Changes In Filtered Set
rightsGuid: 89e95b76-444d-4c62-991a-0facbeda640c
validAccesses: 256
replace: rightsGuid
rightsGuid: ffa6f046-ca4b-4feb-b40d-04dfee722543
-
replace: rightsGuid
rightsGuid: 5805bc62-bdc9-4428-a5e2-856a0f4c185e
-
-
delete: appliesTo
-
objectVersion: 40
-
Sch41.ldf
-
-
-
dn: CN=ms-DS-PSO-Applied,CN=Schema,CN=Configuration,DC=X
searchFlags: 0
-
dn: CN=ms-DS-Resultant-PSO,CN=Schema,CN=Configuration,DC=X
searchFlags: 0
-
dn:
schemaUpdateNow: 1
-
replace: rightsGuid
rightsGuid: ffa6f046-ca4b-4feb-b40d-04dfee722543
-
replace: rightsGuid
rightsGuid: 5805bc62-bdc9-4428-a5e2-856a0f4c185e
-
delete: appliesTo
-
objectVersion: 41
-
Sch42.ldf
dn: CN=account-expires,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
-
dn: cn=address,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=address-book-roots,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=address-entry-display-table,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=address-entry-display-table-msdos,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=address-syntax,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=address-type,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=admin-count,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=admin-display-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=allowed-attributes,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=allowed-attributes-effective,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=allowed-child-classes,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=allowed-child-classes-effective,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=alt-security-identities,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=anr,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=attribute-id,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=attribute-security-guid,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=attribute-syntax,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=attribute-types,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=auditing-policy,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=authentication-options,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=auxiliary-class,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=bad-password-time,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=bad-pwd-count,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
schemaFlagsEx: 1
-
dn: cn=bridgehead-server-list-bl,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=canonical-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=code-page,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=common-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=cost,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=country-code,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=country-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=create-time-stamp,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=creation-time,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=current-value,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=dbcs-pwd,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=default-hiding-value,CN=Schema,CN=Configuration,DC=X
dn: cn=default-hiding-value,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=default-object-category,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=default-security-descriptor,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=description,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=display-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=display-name-printable,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=dit-content-rules,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=dmd-location,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=dn-reference-update,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=dns-host-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=dns-root,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=domain-component,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
schemaFlagsEx: 1
-
dn: cn=domain-cross-ref,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=domain-replica,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ds-core-propagation-data,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ds-heuristics,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=dsa-signature,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=efspolicy,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=enabled,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=enabled-connection,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=extended-attribute-info,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=extended-chars-allowed,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=extended-class-info,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=flat-name,CN=Schema,CN=Configuration,DC=X
dn: cn=flat-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=force-logoff,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=from-entry,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=from-server,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=fsmo-role-owner,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=garbage-coll-period,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=given-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=global-address-list,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=governs-id,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=group-type,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=has-master-ncs,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=has-partial-replica-ncs,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
schemaFlagsEx: 1
-
dn: cn=help-data16,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=help-data32,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=help-file-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=home-directory,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=home-drive,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=initial-auth-incoming,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=initial-auth-outgoing,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=instance-type,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=inter-site-topology-failover,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=inter-site-topology-generator,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=inter-site-topology-renew,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=invocation-id,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=is-critical-system-object,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=is-defunct,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=is-deleted,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=is-member-of-dl,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=is-member-of-partial-attribute-set,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=is-single-valued,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=keywords,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=last-known-parent,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=last-logoff,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=last-logon,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=last-logon-timestamp,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=last-set-time,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ldap-admin-limits,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ldap-display-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ldap-ipdeny-list,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=legacy-exchange-dn,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=link-id,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=lm-pwd-history,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=local-policy-flags,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=locality-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=lock-out-observation-window,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=lockout-duration,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=lockout-threshold,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=lockout-time,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=logo,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=logon-count,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=logon-hours,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=machine-role,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=managed-by,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=mapi-id,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=mastered-by,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=max-pwd-age,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=max-renew-age,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=max-ticket-age,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=may-contain,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=member,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=min-pwd-age,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=min-pwd-length,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=min-ticket-age,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=modified-count,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=modified-count-at-last-prom,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=modify-time-stamp,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-additional-dns-host-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-additional-sam-account-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-all-users-trust-quota,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-allowed-dns-suffixes,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-allowed-to-delegate-to,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-auxiliary-classes,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-approx-immed-subordinates,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-authenticatedat-dc,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-authenticatedto-accountlist,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-az-ldap-query,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-behavior-version,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-cached-membership,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-cached-membership-time-stamp,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-creator-sid,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-default-quota,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-dnsrootalias,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-entry-time-to-die,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-executescriptpassword,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-has-instantiated-ncs,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-has-domain-ncs,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-has-master-ncs,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-intid,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-isgc,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-isrodc,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-keyversionnumber,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-logon-time-sync-interval,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-mastered-by,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-maximum-password-age,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-minimum-password-age,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-minimum-password-length,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-password-history-length,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-password-complexity-enabled,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-password-reversible-encryption-enabled,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-lockout-observation-window,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-lockout-duration,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-lockout-threshold,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-pso-applied,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-resultant-pso,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-password-settings-precedence,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-members-for-az-role,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-nc-type,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-non-members,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-phonetic-display-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-sitename,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-supported-encryption-types,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-trust-forest-trust-info,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-tombstone-quota-factor,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-top-quota-usage,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-machine-account-quota,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
-
dn: cn=ms-ds-other-settings,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-principal-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-quota-amount,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-quota-effective,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-quota-trustee,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-quota-used,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-nc-repl-cursors,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-nc-repl-inbound-neighbors,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-nc-repl-outbound-neighbors,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-nc-replica-locations,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-nc-ro-replica-locations,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-per-user-trust-quota,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-per-user-trust-tombstones-quota,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-preferred-gc-site,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-repl-attribute-meta-data,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-repl-value-meta-data,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-replicates-nc-reason,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-replication-notify-first-dsa-delay,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-replication-notify-subsequent-dsa-delay,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-replicationepoch,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-retired-repl-nc-signatures,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-sd-reference-domain,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-site-affinity,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
-
dn: cn=ms-ds-spn-suffixes,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-port-ssl,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-service-account,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-user-account-disabled,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-user-dont-expire-password,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-user-account-auto-locked,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-user-password-expiry-time-computed,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-user-account-control-computed,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-user-password-expiry-time-computed,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-updatescript,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-krbtgt-link,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-revealed-users,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-has-full-replica-ncs,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-never-reveal-group,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-reveal-ondemand-group,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-secondary-krbtgt-number,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-revealed-dsas,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-krbtgt-link-bl,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-is-user-cachable-at-rodc,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-revealed-list,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-revealed-list-bl,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-last-successful-interactive-logon-time,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-last-failed-interactive-logon-time,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
-
dn: cn=ms-ds-failed-interactive-logon-count,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=ms-ds-failed-interactive-logon-count-at-last-successful-logon,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=msmq-owner-id,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=must-contain,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=nc-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=netbios-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=next-rid,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=nt-mixed-domain,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=nt-pwd-history,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=nt-security-descriptor,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=obj-dist-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=object-category,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=object-class,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=object-class-category,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=object-classes,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=object-guid,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=object-sid,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=object-version,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=oem-information,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=om-object-class,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=om-syntax,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=operating-system,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=operating-system-service-pack,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
schemaFlagsEx: 1
-
dn: cn=operating-system-version,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=operator-count,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=options,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=organization-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=organizational-unit-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=other-well-known-objects,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=parent-guid,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=partial-attribute-deletion-list,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=partial-attribute-set,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=pek-list,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=poss-superiors,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=possible-inferiors,CN=Schema,CN=Configuration,DC=X
dn: cn=possible-inferiors,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=prefix-map,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=primary-group-id,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=primary-group-token,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=prior-set-time,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=prior-value,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=private-key,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=profile-path,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=proxied-object-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=proxy-addresses,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=proxy-lifetime,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=pwd-history-length,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
schemaFlagsEx: 1
-
dn: cn=pwd-last-set,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=pwd-properties,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=query-policy-object,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=range-lower,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=range-upper,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=rdn,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=rdn-att-id,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=repl-property-meta-data,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=repl-topology-stay-of-execution,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=repl-uptodate-vector,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=repl-interval,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=reps-from,CN=Schema,CN=Configuration,DC=X
dn: cn=reps-from,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=reps-to,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=retired-repl-dsa-signatures,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=token-groups,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=token-groups-global-and-universal,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=token-groups-no-gc-acceptable,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=revision,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=rid,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=rid-allocation-pool,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=rid-available-pool,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=rid-manager-reference,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=rid-next-rid,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
schemaFlagsEx: 1
-
dn: cn=rid-previous-allocation-pool,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=rid-set-references,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=rid-used-pool,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=rights-guid,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=root-trust,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=sam-account-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=sam-account-type,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=sam-domain-updates,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=schedule,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=schema-id-guid,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=schema-info,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=script-path,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=sd-rights-effective,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=search-flags,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=security-identifier,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=server-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=server-reference,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=server-reference-bl,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=server-state,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=service-principal-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=show-in-address-book,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=show-in-advanced-view-only,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=sid-history,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=site-link-list,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=site-list,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=site-object,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=smtp-mail-address,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=spn-mappings,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=state-or-province-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=street-address,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=structural-object-class,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=sub-class-of,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=sub-refs,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=subschemasubentry,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=superior-dns-root,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=supplemental-credentials,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=surname,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=system-auxiliary-class,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=system-flags,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=system-may-contain,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=system-must-contain,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=system-only,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=system-poss-superiors,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=template-roots,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=tombstone-lifetime,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=transport-address-attribute,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=transport-dll-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=transport-type,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=trust-attributes,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=trust-auth-incoming,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=trust-auth-outgoing,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=trust-direction,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=trust-parent,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=trust-partner,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=trust-posix-offset,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=trust-type,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=uas-compat,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=unicode-pwd,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=upn-suffixes,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=user-account-control,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=user-comment,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=user-parameters,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=user-password,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=user-principal-name,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=user-workstations,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=usn-changed,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=usn-created,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=usn-dsa-last-obj-removed,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=usn-last-obj-rem,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=valid-accesses,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=well-known-objects,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=when-changed,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=when-created,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
dn: cn=schema-flags-ex,CN=Schema,CN=Configuration,DC=X
replace: systemOnly
systemOnly: TRUE
-
dn: CN=Schema-Flags-Ex,CN=Schema,CN=Configuration,DC=X
add: schemaFlagsEx
schemaFlagsEx: 1
-
objectVersion: 42
-
Sch43.ldf
dn: CN=ms-DFS-Schema-Major-Version,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Schema-Major-Version
attributeID: 1.2.840.113556.1.4.2030
rangeLower: 2
rangeUpper: 2
adminDisplayName: ms-DFS-Schema-Major-Version
adminDescription: Major version of schema of DFS metadata.
oMSyntax: 2
searchFlags: 0
lDAPDisplayName: msDFS-SchemaMajorVersion
schemaIDGUID:: VXht7EpwYU+apsSafB1Uxw==
objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DFS-Schema-Minor-Version,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Schema-Minor-Version
attributeID: 1.2.840.113556.1.4.2031
rangeLower: 0
rangeUpper: 0
adminDisplayName: ms-DFS-Schema-Minor-Version
adminDescription: Minor version of schema of DFS metadata.
oMSyntax: 2
searchFlags: 0
lDAPDisplayName: msDFS-SchemaMinorVersion
schemaIDGUID:: Jaf5/vHoq0O9hmoBFc6eOA==
systemFlags: 16
dn: CN=ms-DFS-Generation-GUID-v2,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Generation-GUID-v2
attributeID: 1.2.840.113556.1.4.2032
rangeLower: 16
rangeUpper: 16
adminDisplayName: ms-DFS-Generation-GUID-v2
adminDescription: To be updated each time the entry containing this attribute is modified.
oMSyntax: 4
searchFlags: 0
lDAPDisplayName: msDFS-GenerationGUIDv2
schemaIDGUID:: 2bO4NY/F1kOTDlBA8vGngQ==
systemFlags: 16
dn: CN=ms-DFS-Namespace-Identity-GUID-v2,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Namespace-Identity-GUID-v2
attributeID: 1.2.840.113556.1.4.2033
rangeLower: 16
rangeUpper: 16
adminDisplayName: ms-DFS-Namespace-Identity-GUID-v2
adminDescription: To be set only when the namespace is created. Stable across rename/move as long as
namespace is not replaced by another namespace having same name.
oMSyntax: 4
searchFlags: 0
lDAPDisplayName: msDFS-NamespaceIdentityGUIDv2
schemaIDGUID:: zjIEIF/sMUmlJdf0r+NOaA==
systemFlags: 16
dn: CN=ms-DFS-Last-Modified-v2,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Last-Modified-v2
attributeID: 1.2.840.113556.1.4.2034
attributeID: 1.2.840.113556.1.4.2034
adminDisplayName: ms-DFS-Last-Modified-v2
adminDescription: To be updated on each write to the entry containing the attribute.
oMSyntax: 24
searchFlags: 0
lDAPDisplayName: msDFS-LastModifiedv2
schemaIDGUID:: il4JPE4xW0aD9auCd7zymw==
systemFlags: 16
dn: CN=ms-DFS-Ttl-v2,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Ttl-v2
attributeID: 1.2.840.113556.1.4.2035
adminDisplayName: ms-DFS-Ttl-v2
adminDescription: TTL associated with DFS root/link. For use at DFS referral time.
oMSyntax: 2
searchFlags: 0
lDAPDisplayName: msDFS-Ttlv2
schemaIDGUID:: MU2U6kqGSUOtpQYuLGFPXg==
systemFlags: 16
dn: CN=ms-DFS-Comment-v2,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Comment-v2
attributeID: 1.2.840.113556.1.4.2036
rangeLower: 0
rangeUpper: 32766
adminDisplayName: ms-DFS-Comment-v2
adminDescription: Comment associated with DFS root/link.
oMSyntax: 64
searchFlags: 0
lDAPDisplayName: msDFS-Commentv2
schemaIDGUID:: yc6Gt/1hI0WywVzrOGC7Mg==
systemFlags: 16
dn: CN=ms-DFS-Properties-v2,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Properties-v2
attributeID: 1.2.840.113556.1.4.2037
rangeLower: 0
rangeUpper: 1024
adminDisplayName: ms-DFS-Properties-v2
adminDescription: Properties associated with DFS root/link.
oMSyntax: 64
searchFlags: 0
lDAPDisplayName: msDFS-Propertiesv2
schemaIDGUID:: xVs+DA7r9UCbUzNOlY3/2w==
systemFlags: 16
dn: CN=ms-DFS-Target-List-v2,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Target-List-v2
attributeID: 1.2.840.113556.1.4.2038
rangeLower: 0
rangeUpper: 2097152
adminDisplayName: ms-DFS-Target-List-v2
adminDescription: Targets corresponding to DFS root/link.
oMSyntax: 4
searchFlags: 0
lDAPDisplayName: msDFS-TargetListv2
schemaIDGUID:: xiaxakH6NkuAnnypFhDUjw==
systemFlags: 16
dn: CN=ms-DFS-Link-Path-v2,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Link-Path-v2
attributeID: 1.2.840.113556.1.4.2039
rangeLower: 0
rangeUpper: 32766
adminDisplayName: ms-DFS-Link-Path-v2
adminDescription: DFS link path relative to the DFS root target share (i.e. without the server/domain and
DFS namespace name components). Use forward slashes (/) instead of backslashes so that LDAP searches can be
done without having to use escapes.
oMSyntax: 64
searchFlags: 0
lDAPDisplayName: msDFS-LinkPathv2
schemaIDGUID:: 9iGwhqsQokCiUh3AzDvmqQ==
systemFlags: 16
dn: CN=ms-DFS-Link-Security-Descriptor-v2,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Link-Security-Descriptor-v2
attributeID: 1.2.840.113556.1.4.2040
adminDisplayName: ms-DFS-Link-Security-Descriptor-v2
adminDescription: Security descriptor of the DFS links's reparse point on the filesystem.
oMSyntax: 66
searchFlags: 0
lDAPDisplayName: msDFS-LinkSecurityDescriptorv2
schemaIDGUID:: 94fPVyY0QUizIgKztunrqA==
systemFlags: 16
dn: CN=ms-DFS-Link-Identity-GUID-v2,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Link-Identity-GUID-v2
attributeID: 1.2.840.113556.1.4.2041
rangeLower: 16
rangeUpper: 16
adminDisplayName: ms-DFS-Link-Identity-GUID-v2
adminDescription: To be set only when the link is created. Stable across rename/move as long as link is not
replaced by another link having same name.
oMSyntax: 4
searchFlags: 0
lDAPDisplayName: msDFS-LinkIdentityGUIDv2
schemaIDGUID:: 8yew7SZX7k2NTtvwfhrR8Q==
systemFlags: 16
dn: CN=ms-DFS-Short-Name-Link-Path-v2,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Short-Name-Link-Path-v2
attributeID: 1.2.840.113556.1.4.2042
rangeLower: 0
rangeUpper: 32766
adminDisplayName: ms-DFS-Short-Name-Link-Path-v2
adminDescription: Shortname DFS link path relative to the DFS root target share (i.e. without the
server/domain and DFS namespace name components). Use forward slashes (/) instead of backslashes so that
LDAP searches can be done without having to use escapes.
oMSyntax: 64
searchFlags: 0
lDAPDisplayName: msDFS-ShortNameLinkPathv2
schemaIDGUID:: 8CZ4LfdM6UKgOREQ4NnKmQ==
systemFlags: 16
DN:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-DFS-Namespace-Anchor,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Namespace-Anchor
subClassOf: top
governsID: 1.2.840.113556.1.5.257
rDNAttID: cn
adminDisplayName: ms-DFS-Namespace-Anchor
adminDescription: DFS namespace anchor
lDAPDisplayName: msDFS-NamespaceAnchor
schemaIDGUID:: haBz2mRuYU2wZAFdBBZHlQ==
systemOnly: FALSE
systemFlags: 16
objectCategory: CN=Class-Schema,CN=Schema,CN=Configuration,DC=X
defaultObjectCategory: CN=ms-DFS-Namespace-Anchor,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DFS-Namespace-v2,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Namespace-v2
subClassOf: top
governsID: 1.2.840.113556.1.5.258
rDNAttID: cn
adminDisplayName: ms-DFS-Namespace-v2
adminDescription: DFS namespace
lDAPDisplayName: msDFS-Namespacev2
schemaIDGUID:: KIbLIcPzv0u/9gYLLY8pmg==
systemOnly: FALSE
(A;;RPLCLORC;;;AU)
systemFlags: 16
defaultObjectCategory: CN=ms-DFS-Namespace-v2,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DFS-Link-v2,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Link-v2
subClassOf: top
governsID: 1.2.840.113556.1.5.259
rDNAttID: cn
adminDisplayName: ms-DFS-Link-v2
adminDescription: DFS Link in DFS namespace
lDAPDisplayName: msDFS-Linkv2
schemaIDGUID:: evtpd1kRlk6czWi8SHBz6w==
systemOnly: FALSE
(A;;RPLCLORC;;;AU)
systemFlags: 16
defaultObjectCategory: CN=ms-DFS-Link-v2,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DFS-Deleted-Link-v2,CN=Schema,CN=Configuration,DC=X
cn: ms-DFS-Deleted-Link-v2
subClassOf: top
governsID: 1.2.840.113556.1.5.260
rDNAttID: cn
adminDisplayName: ms-DFS-Deleted-Link-v2
adminDescription: Deleted DFS Link in DFS namespace
lDAPDisplayName: msDFS-DeletedLinkv2
schemaIDGUID:: CDQXJcoE6ECGXj+c6b8b0w==
systemOnly: FALSE
(A;;RPLCLORC;;;AU)
systemFlags: 16
defaultObjectCategory: CN=ms-DFS-Deleted-Link-v2,CN=Schema,CN=Configuration,DC=X
dn: CN=Address-Book-Roots2,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: addressBookRoots2
adminDisplayName: Address-Book-Roots2
adminDescription: Used by Exchange. Exchange configures trees of address book containers to show up in the
MAPI address book. This attribute on the Exchange Config object lists the roots of the address book
container trees.
attributeId: 1.2.840.113556.1.4.2046
omSyntax: 127
linkID: 2122
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: dKOMUBGlTk6fT4VvYaa35A==
systemFlags: 16
schemaFlagsEx: 1
dn: CN=Global-Address-List2,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: globalAddressList2
adminDisplayName: Global-Address-List2
adminDescription: This attribute is used on a Microsoft Exchange container to store the distinguished name
of a newly created global address list (GAL). This attribute must have an entry before you can enable
Messaging Application Programming Interface (MAPI) clients to use a GAL.
attributeId: 1.2.840.113556.1.4.2047
omSyntax: 127
linkID: 2124
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: PfaYSBJBfEeIJjygC9gnfQ==
systemFlags: 16
schemaFlagsEx: 1
dn: CN=Template-Roots2,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: templateRoots2
adminDisplayName: Template-Roots2
adminDescription: This attribute is used on the Exchange config container to indicate where the template
containers are stored. This information is used by the Active Directory MAPI provider.
containers are stored. This information is used by the Active Directory MAPI provider.
attributeId: 1.2.840.113556.1.4.2048
omSyntax: 127
linkID: 2126
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: GqnLsYIGYkOmWRU+IB7waQ==
systemFlags: 16
schemaFlagsEx: 1
DN:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-Exch-Configuration-Container,CN=Schema,CN=Configuration,DC=X
-

objectVersion: 43
-
Sch44.ldf
dn: CN=TOP,CN=Schema,CN=Configuration,DC=X
-
replace: showInAdvancedViewOnly
-
dn: CN=ms-PKI-DPAPIMasterKeys,CN=Schema,CN=Configuration,DC=X
searchFlags: 640
-
dn: CN=ms-PKI-AccountCredentials,CN=Schema,CN=Configuration,DC=X
searchFlags: 640
-
dn: CN=ms-PKI-RoamingTimeStamp,CN=Schema,CN=Configuration,DC=X
searchFlags: 640
-
adminDescription: This attribute is used on a Microsoft Exchange container to store the distinguished name
of a newly created global address list (GAL). This attribute must have an entry before you can enable
Messaging Application Programming Interface (MAPI) clients to use a GAL.
-
-
dn: CN=ms-DS-BridgeHead-Servers-Used,CN=Schema,CN=Configuration,DC=X
adminDescription: List of bridge head servers used by KCC in the previous run.
adminDisplayName: ms-DS-BridgeHead-Servers-Used
attributeID: 1.2.840.113556.1.4.2049
cn: ms-DS-BridgeHead-Servers-Used
instanceType: 4
lDAPDisplayName: msDS-BridgeHeadServersUsed
linkID: 2160
oMSyntax: 127
schemaFlagsEx: 1
schemaIDGUID:: ZRTtPHF7QSWHgB4epiQ6gg==
searchFlags: 0
systemFlags: 25
DN:
changetype: modify
schemaUpdateNow: 1
-
-

objectVersion: 44
-
Sch45.ldf
DN: CN=ms-DS-USN-Last-Sync-Success,CN=Schema,CN=Configuration,DC=X
adminDisplayName: ms-DS-USN-Last-Sync-Success
adminDescription: The USN at which the last successful replication synchronization occurred.
attributeID: 1.2.840.113556.1.4.2055
lDAPDisplayName: msDS-USNLastSyncSuccess
oMSyntax: 65
schemaFlagsEx: 1
searchFlags: 0
schemaIDGUID:: trj3MfjJLU+je1ioIwMDMQ==
systemFlags: 25
systemOnly: FALSE
dn: CN=Is-Recycled,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: isRecycled
adminDisplayName: Is-Recycled
adminDescription: Is the object recycled.
attributeId: 1.2.840.113556.1.4.2058
omSyntax: 1
systemOnly: TRUE
schemaFlagsEx: 1
searchFlags: 8
schemaIdGuid:: VpK1j/FVS0Sqy/W0gv40WQ==
systemFlags: 18
dn: CN=ms-DS-Optional-Feature-GUID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-OptionalFeatureGUID
adminDisplayName: ms-DS-Optional-Feature-GUID
adminDescription: GUID of an optional feature.
attributeId: 1.2.840.113556.1.4.2062
omSyntax: 4
schemaFlagsEx: 1
systemOnly: TRUE
searchFlags: 0
rangeLower: 16
rangeUpper: 16
schemaIdGuid:: qL2Im4LdmEmpHV8tK68ZJw==
systemFlags: 16
dn: CN=ms-DS-Enabled-Feature,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-EnabledFeature
adminDisplayName: ms-DS-Enabled-Feature
adminDescription: Enabled optional features.
attributeId: 1.2.840.113556.1.4.2061
omSyntax: 127
schemaFlagsEx: 1
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: r64GV0C5sk+8/FJoaDrZ/g==
linkID: 2168
systemFlags: 16
dn: CN=ms-Imaging-PSP-String,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msImaging-PSPString
ldapDisplayName: msImaging-PSPString
adminDisplayName: ms-Imaging-PSP-String
adminDescription: Schema Attribute that contains the XML sequence for this PostScan Process.
attributeId: 1.2.840.113556.1.4.2054
omSyntax: 64
schemaFlagsEx: 1
searchFlags: 0
rangeUpper: 524288
schemaIdGuid:: rmBne+3WpkS2vp3mLAnsZw==
systemFlags: 16
dn: CN=ms-DS-OIDToGroup-Link,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-OIDToGroupLink
adminDisplayName: ms-DS-OIDToGroup-Link
adminDescription: For an OID, identifies the group object corresponding to the issuance policy represented
by this OID.
attributeId: 1.2.840.113556.1.4.2051
omSyntax: 127
systemOnly: FALSE
schemaFlagsEx: 1
searchFlags: 0
schemaIdGuid:: fKXJ+UE5jUO+vw7a8qyhhw==
linkID: 2164
systemFlags: 16
dn: CN=ms-DS-OIDToGroup-Link-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-OIDToGroupLinkBl
adminDisplayName: ms-DS-OIDToGroup-Link-BL
adminDescription: Backlink for ms-DS-OIDToGroup-Link; identifies the issuance policy, represented by an OID
object, which is mapped to this group.
attributeId: 1.2.840.113556.1.4.2052
omSyntax: 127
systemOnly: TRUE
schemaFlagsEx: 1
searchFlags: 0
schemaIdGuid:: IA09GkRYmUGtJQ9QOadq2g==
linkID: 2165
systemFlags: 17
dn: CN=ms-Imaging-PSP-Identifier,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msImaging-PSPIdentifier
adminDisplayName: ms-Imaging-PSP-Identifier
adminDescription: Schema Attribute that contains the unique identifier for this PostScan Process.
attributeId: 1.2.840.113556.1.4.2053
omSyntax: 4
searchFlags: 0
schemaIdGuid:: 6TxYUfqUEku5kDBMNbGFlQ==
systemFlags: 16
dn: CN=ms-DS-Host-Service-Account,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DS-Host-Service-Account,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-HostServiceAccount
adminDisplayName: ms-DS-Host-Service-Account
adminDescription: Service Accounts configured to run on this computer.
attributeId: 1.2.840.113556.1.4.2056
omSyntax: 127
searchFlags: 0
schemaFlagsEx: 1
schemaIdGuid:: QxBkgKIV4UCSooyoZvcHdg==
linkID: 2166
systemFlags: 16
dn: CN=ms-DS-Host-Service-Account-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-HostServiceAccountBL
adminDisplayName: ms-DS-Host-Service-Account-BL
adminDescription: Service Accounts Back Link for linking machines associated with the service account.
attributeId: 1.2.840.113556.1.4.2057
omSyntax: 127
searchFlags: 0
schemaFlagsEx: 1
schemaIdGuid:: 6+SrefOI50iJ1vS8fpjDMQ==
linkID: 2167
systemFlags: 17
dn: CN=ms-DS-Required-Domain-Behavior-Version,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-RequiredDomainBehaviorVersion
adminDisplayName: ms-DS-Required-Domain-Behavior-Version
adminDescription: Required domain function level for this feature.
attributeId: 1.2.840.113556.1.4.2066
omSyntax: 2
systemOnly: TRUE
searchFlags: 0
schemaFlagsEx: 1
schemaIdGuid:: /j3d6g6uwky5uV/ltu0t0g==
systemFlags: 16
dn: CN=ms-DS-Required-Forest-Behavior-Version,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-RequiredForestBehaviorVersion
adminDisplayName: ms-DS-Required-Forest-Behavior-Version
adminDescription: Required forest function level for this feature.
attributeId: 1.2.840.113556.1.4.2079
omSyntax: 2
systemOnly: TRUE
searchFlags: 0
schemaFlagsEx: 1
schemaIdGuid:: 6KLsS1OmskGP7nIVdUdL7A==
systemFlags: 16
systemFlags: 16
dn: CN=ms-PKI-Credential-Roaming-Tokens,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msPKI-CredentialRoamingTokens
adminDisplayName: ms-PKI-Credential-Roaming-Tokens
adminDescription: Storage of encrypted user credential token blobs for roaming.
attributeId: 1.2.840.113556.1.4.2050
omSyntax: 127
searchFlags: 128
schemaIdGuid:: OFr/txgIsEKBENPRVMl/JA==
linkID: 2162
systemFlags: 16
dn: CN=ms-DS-Local-Effective-Recycle-Time,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-LocalEffectiveRecycleTime
adminDisplayName: ms-DS-Local-Effective-Recycle-Time
adminDescription: Recycle time of the object in the local DIT.
attributeId: 1.2.840.113556.1.4.2060
omSyntax: 24
systemOnly: TRUE
searchFlags: 0
schemaFlagsEx: 1
schemaIdGuid:: awHWStKwm0yTtllksXuWjA==
systemFlags: 20
dn: CN=ms-DS-Local-Effective-Deletion-Time,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-LocalEffectiveDeletionTime
adminDisplayName: ms-DS-Local-Effective-Deletion-Time
adminDescription: Deletion time of the object in the local DIT.
attributeId: 1.2.840.113556.1.4.2059
omSyntax: 24
systemOnly: TRUE
searchFlags: 0
schemaFlagsEx: 1
schemaIdGuid:: DIDylB9T60qXXUisOf2MpA==
systemFlags: 20
dn: CN=ms-DS-Last-Known-RDN,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-LastKnownRDN
adminDisplayName: ms-DS-Last-Known-RDN
adminDescription: Holds original RDN of a deleted object.
attributeId: 1.2.840.113556.1.4.2067
omSyntax: 64
schemaFlagsEx: 1
systemOnly: TRUE
searchFlags: 0
rangeLower: 1
rangeUpper: 255
schemaIdGuid:: WFixij5obUaHf9ZA4fmmEQ==
schemaIdGuid:: WFixij5obUaHf9ZA4fmmEQ==
systemFlags: 16
dn: CN=ms-DS-Enabled-Feature-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-EnabledFeatureBL
adminDisplayName: ms-DS-Enabled-Feature-BL
adminDescription: Scopes where this optional feature is enabled.
attributeId: 1.2.840.113556.1.4.2069
omSyntax: 127
schemaFlagsEx: 1
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: vAFbzsYXuESdwalmiwCQGw==
linkID: 2169
systemFlags: 17
dn: CN=ms-DS-Deleted-Object-Lifetime,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-DeletedObjectLifetime
adminDisplayName: ms-DS-Deleted-Object-Lifetime
adminDescription: Lifetime of a deleted object.
attributeId: 1.2.840.113556.1.4.2068
omSyntax: 10
schemaFlagsEx: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: toyzqZoY702KcA/PoVgUjg==
systemFlags: 16
dn: CN=ms-DS-Optional-Feature-Flags,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-OptionalFeatureFlags
adminDisplayName: ms-DS-Optional-Feature-Flags
adminDescription: An integer value that contains flags that define behavior of an optional feature in Active
Directory.
attributeId: 1.2.840.113556.1.4.2063
omSyntax: 2
schemaFlagsEx: 1
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: wWAFirmXEUidt9wGFZiWWw==
systemFlags: 16
dn: CN=ms-PKI-Enrollment-Servers,CN=Schema,CN=Configuration,DC=X
cn: ms-PKI-Enrollment-Servers
attributeID: 1.2.840.113556.1.4.2076
adminDisplayName: ms-PKI-Enrollment-Servers
adminDescription: Priority, authentication type, and URI of each certificate enrollment web service.
oMSyntax: 64
lDAPDisplayName: msPKI-Enrollment-Servers
name: ms-PKI-Enrollment-Servers
name: ms-PKI-Enrollment-Servers
schemaIDGUID:: j9Mr8tChMkiLKAMxQ4iGpg==
instanceType: 4
rangeUpper: 65536
searchFlags: 0
# System-Flags=FLAG_SCHEMA_BASE_OBJECT
systemFlags: 16
systemOnly: FALSE
dn: CN=ms-PKI-Site-Name,CN=Schema,CN=Configuration,DC=X
cn: ms-PKI-Site-Name
attributeID: 1.2.840.113556.1.4.2077
adminDisplayName: ms-PKI-Site-Name
adminDescription: Active Directory site to which the CA machine belongs.
oMSyntax: 64
lDAPDisplayName: msPKI-Site-Name
name: ms-PKI-Site-Name
schemaIDGUID:: H3HYDPwKJkmksQmwjT1DbA==
instanceType: 4
rangeUpper: 1024
searchFlags: 0
systemOnly: FALSE
# System-Flags=FLAG_SCHEMA_BASE_OBJECT
systemFlags: 16
dn: CN=ms-TS-Endpoint-Data,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSEndpointData
adminDisplayName: ms-TS-Endpoint-Data
adminDescription: This attribute represents the VM Name for machine in TSV deployment.
attributeId: 1.2.840.113556.1.4.2070
schemaIDGUID:: B8ThQERD80CrQzYlo0pjog==
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
systemFlags: 16
dn: CN=ms-TS-Endpoint-Type,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSEndpointType
adminDisplayName: ms-TS-Endpoint-Type
adminDescription: This attribute defines if the machine is a physical machine or a virtual machine.
attributeId: 1.2.840.113556.1.4.2071
schemaIDGUID:: gN56N9jixUabzW2d7JOzXg==
omSyntax: 2
systemOnly: FALSE
searchFlags: 0
systemFlags: 16
dn: CN=ms-TS-Endpoint-Plugin,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSEndpointPlugin
adminDisplayName: ms-TS-Endpoint-Plugin
adminDescription: This attribute represents the name of the plugin which handles the orchestration.
attributeId: 1.2.840.113556.1.4.2072
schemaIDGUID:: abUIPB+AWEGxe+Nj1q5pag==
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 0
rangeUpper: 32767
systemFlags: 16
dn: CN=ms-TS-Primary-Desktop,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSPrimaryDesktop
adminDisplayName: ms-TS-Primary-Desktop
adminDescription: This attribute represents the forward link to user's primary desktop.
attributeId: 1.2.840.113556.1.4.2073
schemaIDGUID:: lJYlKeQJN0KfcpMG6+Y6sg==
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
linkID: 2170
systemFlags: 16
dn: CN=ms-TS-Secondary-Desktops,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSSecondaryDesktops
adminDisplayName: ms-TS-Secondary-Desktops
adminDescription: This attribute represents the array of forward links to user's secondary desktops.
attributeId: 1.2.840.113556.1.4.2075
schemaIDGUID:: mqI69jG74Ui/qwpsWh05wg==
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
linkID: 2172
systemFlags: 16
dn: CN=ms-TS-Primary-Desktop-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSPrimaryDesktopBL
adminDisplayName: ms-TS-Primary-Desktop-BL
adminDescription: This attribute represents the backward link to user.
attributeId: 1.2.840.113556.1.4.2074
schemaIDGUID:: GNyqndFA0U6iv2ub9H09qg==
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
linkID: 2171
systemFlags: 17
dn: CN=ms-TS-Secondary-Desktop-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTSSecondaryDesktopBL
adminDisplayName: ms-TS-Secondary-Desktop-BL
adminDescription: This attribute represents the backward link to user.
attributeId: 1.2.840.113556.1.4.2078
schemaIDGUID:: rwexNAqgWkWxOd0aGxLYrw==
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
linkID: 2173
systemFlags: 17
DN:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=ms-Imaging-PSPs,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msImaging-PSPs
adminDisplayName: ms-Imaging-PSPs
adminDescription: Container for all Enterprise Scan Post Scan Process objects.
governsId: 1.2.840.113556.1.5.262
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.23
schemaIdGuid:: wSrtoAyXd0eEjuxjoOxE/A==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-Imaging-PSPs,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Optional-Feature,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-OptionalFeature
adminDisplayName: ms-DS-Optional-Feature
adminDescription: Configuration for an optional DS feature.
governsId: 1.2.840.113556.1.5.265
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: QQDwRK81i0ayCmzoc3xYCw==
defaultSecurityDescriptor: D:(A;;RPLCLORC;;;AU)(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;EA)
systemOnly: TRUE
defaultObjectCategory: CN=ms-DS-Optional-Feature,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-Imaging-PostScanProcess,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msImaging-PostScanProcess
ldapDisplayName: msImaging-PostScanProcess
adminDisplayName: ms-Imaging-PostScanProcess
adminDescription: Enterprise Scan Post Scan Process object.
governsId: 1.2.840.113556.1.5.263
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: fCV8H6O4JUWC+BHMx77jbg==
(A;;RPLCLORC;;;AU)
systemOnly: FALSE
defaultObjectCategory: CN=ms-Imaging-PostScanProcess,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Managed-Service-Account,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ManagedServiceAccount
adminDisplayName: ms-DS-Managed-Service-Account
adminDescription: Service account class is used to create accounts that are used for running Windows
services.
governsId: 1.2.840.113556.1.5.264
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.30
schemaIdGuid:: RGIgzidYhkq6HBwMOGwbZA==
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;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;;RPWP;bf967a7f-0de6-11d0-a285-
00aa003049e2;;CA)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Managed-Service-Account,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
-
-
dn: CN=domain-DNS,CN=Schema,CN=Configuration,DC=X
-
dn: CN=ms-PKI-Cert-Template-OID,CN=Schema,CN=Configuration,DC=X
searchFlags: 1
-
-
-
-
-
-
-
-
-
-
-
-
-
DN:
changetype: modify
schemaUpdateNow: 1
-
dn: CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=X

systemFlags: -1946157056
dn: CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows

msDS-OptionalFeatureGUID:: 2NxtdtCsXkTzuaf5tnRPKg==
systemFlags: -1946157056
add: appliesTo
appliesTo: ce206244-5827-4a86-ba1c-1c0c386c1b64
-
add: appliesTo
-
add: appliesTo
-
add: appliesTo
-
add: appliesTo
-
-
add: appliesTo
-
add: appliesTo
-
dn: CN=Validated-DNS-Host-Name,CN=Extended-Rights,CN=Configuration,DC=X
add: appliesTo
-
dn: CN=Validated-SPN,CN=Extended-Rights,CN=Configuration,DC=X
add: appliesTo
-
add: appliesTo
-
add: appliesTo
-
add: appliesTo
-
dn: CN=Run-Protect-Admin-Groups-Task,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Run Protect Admin Groups Task
rightsGuid: 7726b9d5-a4b4-4288-a6b2-dce952e80a7f
validAccesses: 256
dn: CN=Manage-Optional-Features,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Manage Optional Features for Active Directory
rightsGuid: 7c0e2a7c-a419-48e4-a995-10180aad54dd
validAccesses: 256
objectVersion: 45
-
Sch46.ldf
-
DN:
changetype: modify
schemaUpdateNow: 1
-

objectVersion: 46
-
Sch47.ldf
-
-
dn:
changetype: modify
schemaUpdateNow: 1
-
#increase object version

objectVersion: 47
-
Next steps
Domain-wide schema update operations
Forest-wide schema update operations
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 .
O P ERAT IO N S N UM B ER A N D GUID DESC RIP T IO N P ERM ISSIO N S
Operation 89 : {A0C238BA-9E30- Delete the ACE granting Full Control Delete

4EE6-80A6-43F731E9A5CD} to Enterprise Key Admins and add an (A;CI;RPWPCRLCLOCCDCRCWDWOSD
ACE granting Enterprise Key Admins DTSW;;;Enterprise Key Admins)
Full 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 .
O P ERAT IO N S N UM B ER A N D
GUID DESC RIP T IO N AT T RIB UT ES P ERM ISSIO N S
Operation 82 : Create CN=Keys container - objectClass: container (A;CI;RPWPCRLCLOCCDCRC

{83C53DA7-427E-47A4- at root of domain - description: Default WDWOSDDTSW;;;EA)
A07A-A324598B88F7} container for key credential (A;CI;RPWPCRLCLOCCDCRC
objects WDWOSDDTSW;;;DA)
- (A;CI;RPWPCRLCLOCCDCRC
ShowInAdvancedViewOnly: WDWOSDDTSW;;;SY)
TRUE (A;CI;RPWPCRLCLOCCDCRC
WDWOSDDTSW;;;DD)
(A;CI;RPWPCRLCLOCCDCRC
WDWOSDDTSW;;;ED)
Operation 83 : Add Full Control allow aces N/A (A;CI;RPWPCRLCLOCCDCRC

{C81FC9CC-0130-4FD1- to CN=Keys container for WDWOSDDTSW;;;Key
B272-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:683A24E2E8164BD3A
D53E1DC439BA} attribute to point to the F86AC3C2CF3F981:CN=Ke
CN=Keys container. ys,%ws
Operation 85 : {e6d5fd00- Modify the domain NC to N/A (OA;CI;RPWP;5b47d60f-

385d-4e65-b02d- permit "domain\Key 6090-40b2-9f37-
9da3493ed850} Admins" and 2a4de88f3063;;Key Admins)
"rootdomain\Enterprise Key (OA;CI;RPWP;5b47d60f-
Admins" to modify the 6090-40b2-9f37-
msds-KeyCredentialLink 2a4de88f3063;;Enterprise
attribute. 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 : Delete the ACE granting N/A Delete

{7F950403-0AB3-47F9- Full Control to the incorrect (A;CI;RPWPCRLCLOCCDCRC
9730-5D7B0269F9BD} domain-relative Enterprise WDWOSDDTSW;;;Enterprise
Key Admins group, and add Key Admins)
an ACE granting Full
Control to Enterprise Key Add
Admins group. (A;CI;RPWPCRLCLOCCDCRC
WDWOSDDTSW;;;Enterprise
Key Admins)
Operation 88 : Add "msDS- N/A N/A

{434bb40d-dbc9-4fe7- ExpirePasswordsOnSmartCa
81d4-d57229f7b080} rdOnlyAccounts" 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 InformationObjectsContain
be8f9b63d991} Domain partition. er
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 4c10-ba82-
274f2ebcf11e} Domain Controllers 4d926db99a3e;;domain
group 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 .
O P ERAT IO N N UM B ER A N D
Operation 136 : Granting the "CN=Send- N/A N/A

{328092FB-16E7-4453- As,CN=Extended-Rights" to
9AB8-7592DB56E9C4} gMSA accounts.
Operation 137 : Granting the "CN=Receive- N/A N/A

{3A1C887F-DF0A-489F- As,CN=Extended-Rights" to
B3F2-2D0409095F6E} gMSA accounts.
Operation 138 : Granting the N/A N/A

{232E831F-F988-4444- "CN=Personal-
8E3E-8A352E2FD411} Information,CN=Extended-
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 N/A N/A

{A0A45AAC-5550-42DF- "CN=Validated-
BB6A-3CC5C46B52F2} SPN,CN=Extended-Rights"
to gMSA accounts.
Operation 141 : Granting the "CN=Allowed- N/A N/A

{3E7645F3-3EA5-4567- To-
B35A-87630449C70C} Authenticate,CN=Extended-
Rights" to gMSA accounts.
Operation 142 : Granting the "CN=MS-TS- N/A N/A

{E634067B-E2C4-4D79- GatewayAccess,CN=Extend
B6E8-73C619324D5E} ed-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 : Created a new - objectClass: container (A;;RPLCLORC;;;AU)

{b83818c1-01a6-4f39- authentication policy - displayName: (A;;RPWPCRLCLOCCRCWD
91b7-a3bb581c3ae3} configuration container Authentication Policy WOSW;;;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 : Created a new - objectClass: msDS- (A;;RPWPCRCCDCLCLOLOR

{bbbb9db0-4009-4368- authentication policies AuthNPolicies CWOWDSDDTDTSW;;;EA)
8c40-6674e980d3c3} object 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
partition. objects.
-
True
Operation 133 : Created a new - objectClass: msDS- (A;;RPWPCRCCDCLCLOLOR

{f754861c-3692-4a7b- authentication policy silos AuthNPolicySilos CWOWDSDDTDTSW;;;EA)
b2c2-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 : Created a new - objectClass: msDS- (A;;RPWPCRCCDCLCLORCW

{d32f499f-3026-4af0- authentication silo claim ClaimType OWDSDDTSW;;;EA)
a5bd-13fe5a331bd2} type object - displayname: (A;;RPWPCRCCDCLCLORCW
CN=ad://ext/Authentication AuthenticationSilo OWDSDDTSW;;;SY)
Silo,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 : Set the msDS- - msDS- N/A

{38618886-98ee-4e42- ClaimIsValueSpaceRestricted ClaimIsValueSpaceRestricted
8cf1-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 : Created a new container - objectClass: container (A;;RPLCLORC;;;AU)

{4664e973-cb20-4def- CN=Claims (A;;RPWPCRLCLOCCRCWD
b3d5-559d6fe123e0} Configuration,CN=Services WOSW;;;EA)
in the Configuration (A;;RPWPCRLCLOCCDCRCW
partition. DWOSDDTSW;;;SY)
Operation 85 : Created a new object - objectClass: msDS- (A;;RPLCLORC;;;AU)

{2972d92d-a07a-44ac- CN=Claim ClaimTypes (A;;RPWPCRLCLOCCDCRCW
9cb0-bf243356f345} Types,CN=Claims - DWOSW;;;EA)
Configuration,CN=Services showInAdvancedViewOnly: (A;;RPWPCRLCLOCCDCRCW
in the Configuration True DWOSDDTSW;;;SY)
partition.
Operation 86 : {09a49cb3- Created a new object - objectClass: msDS- (A;;RPLCLORC;;;AU)

6c54-4b83-ab20- CN=Resource ResourceProperties (A;;RPWPCRLCLOCCDCRCW
8370838ba149} Properties,CN=Claims - DWOSW;;;EA)
Configuration,CN=Services showInAdvancedViewOnly: (A;;RPWPCRLCLOCCDCRCW
in the Configuration True DWOSDDTSW;;;SY)
partition.

{77283e65-ce02-4dc3- CN=Resource Property - (A;;RPWPCRLCLOCCDCRCW
8c1e-bf99b22527c2} Lists,CN=Claims showInAdvancedViewOnly: DWOSW;;;EA)
Configuration,CN=Services True (A;;RPWPCRLCLOCCDCRCW
in the Configuration DWOSDDTSW;;;SY)
partition.
Operation 88 : {0afb7f53- Created a new object N/A Created the following

96bd-404b-a659- CN=Sam-Domain in the access control entry (ACE)
89e65c269420} Schema partition. to grant Write Property to
Principal Self on the object:
(OA;CIIO;WP;ea1b7b93
-5e48-46d5-bc6c-
4df4fda78a35;bf967a8
6-0de6-11d0-a285-
00aa003049e2;PS)
Operation 89 : {c7f717ef- Created a new object N/A Created the following

fdbe-4b4b-8dfc- CN=Domain-DNS in the access control entry (ACE)
fa8b839fbcfa} Schema partition. to grant Write Property to
Principal Self on the object:
(OA;CIIO;WP;ea1b7b93
-5e48-46d5-bc6c-
4df4fda78a35;bf967a8
6-0de6-11d0-a285-
00aa003049e2;PS)
Operation 90 : Call back function to N/A N/A

{00232167-f3a4-43c6- upgrade display specifiers.
b503-9acb7a81b01c}

{73a9515b-511c-44d2- CN=Microsoft - (A;;RPWPCRLCLOCCRCWD
822b-444a33d3bd33} SPP,CN=Services in the showInAdvancedViewOnly: WOSW;;;EA)
Configuration partition. True (A;;RPWPCRLCLOCCDCRCW
DWOSDDTSW;;;SY)
Operation 92 : {e0c60003- Created a new Activation - objectClass: msSPP- (A;;RPLCLORC;;;AU)

2ed7-4fd3-8659- Objects container ActivationObjectsContainer (A;;RPWPCRLCLOCCRCWD
7655a7e79397} CN=Activation - WOSW;;;EA)
Objects,CN=Microsoft showInAdvancedViewOnly: (A;;RPWPCRLCLOCCDCRCW
SPP,CN=Services in the True 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 - DWOSW;;;EA)
Policies,CN=Claims showInAdvancedViewOnly: (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services True 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 - DWOSW;;;EA)
Access Rules,CN=Claims showInAdvancedViewOnly: (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services True 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;;RPWPCRLCLOCCRCWD
aabfb41e9713} container CN=Group Key contains configuration and WOSW;;;EA)
Distribution data for Group Key (A;;RPWPCRLCLOCCDCRCW
Service,CN=Services in the Distribution Service. DWOSDDTSW;;;SY)
Configuration partition. -
True
Operation 96 : Created a new Master Root - objectClass: container (A;;RPLCLORC;;;AU)

{d6bd96d4-e66b-4a38- Keys container CN=Master - description: The container (A;;RPWPCRLCLOCCRCWD
9c6b-e976ff58c56d} Root Keys,CN=Group Key contains master root keys WOSW;;;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;;RPWPCRLCLOCCRCWD
7cd1d380e695} CN=Server contains Group Key WOSW;;;EA)
Configuration,CN=Group Distribution Service (A;;RPWPCRLCLOCCDCRCW
Key Distribution configurations. DWOSDDTSW;;;SY)
Service,CN=Services in the -
Configuration partition. showInAdvancedViewOnly:
True
Operation 98 : Created a new Empty - objectClass: msKds- (A;;RPLCLORC;;;AU)

{2d6abe1b-4326-489e- server configuration objects ProvServerConfiguration (A;;RPWPCRLCLOCCRCWD
920c-76d5337d2dc5} container CN=Group Key - description: The WOSW;;;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 ClaimsTransformationPolicie (A;;RPWPCRLCLOCCDCRCW
0505cea24175} configuration container s DWOSW;;;EA)
CN=Claims Transformation - (A;;RPWPCRLCLOCCDCRCW
Policies,CN=Claims showInAdvancedViewOnly: DWOSDDTSW;;;SY)
Configuration,CN=Services True
partition.
Operation 100 : Created a new Value Types - objectClass: container (A;;RPLCLORC;;;AU)

{92e73422-c68b-46c9- configuration container - (A;;RPWPCRLCLOCCRCWD
b0d5-b55f9c741410} CN=Value Types,CN=Claims showInAdvancedViewOnly: WOSW;;;EA)
Configuration,CN=Services True (A;;RPWPCRLCLOCCDCRCW
in the Configuration DWOSDDTSW;;;SY)
partition.
Operation 101 : Created a new - objectClass: msDS- (D;;SDDT;;;WD)

{c0ad80b4-8e84-4cc4- SinglevaluedChoice value ValueType (A;;RPLCLORC;;;AU)
9163-2f84649bcc42} type configuration object - description: You can use (A;;RPWPCRLCLOCCRCWD
CN=MS-DS- this type to author a WOSW;;;EA)
SinglevaluedChoice,CN=Val resource property. When (A;;RPWPCRLCLOCCDCRCW
ue Types,CN=Claims assigning value to a DWOSDDTSW;;;SY)
Configuration,CN=Services resource property of this
in the Configuration value type, a user can
partition. choose only one entry from
a list of suggested values.
- displayname: Single-
valued Choice
- msDS-
ClaimIsValueSpaceRestricted
: True
- msDS-
- msDS-
IsPossibleValuesPresent:
True
-
True
Operation 102 : Created a new YesNo value - objectClass: msDS- (D;;SDDT;;;WD)

{992fe1d0-6591-4f24- type configuration object ValueType (A;;RPLCLORC;;;AU)
a163-c820fcb7f308} CN=MS-DS- - description: The valid (A;;RPWPCRLCLOCCRCWD
YesNo,CN=Value values for this type are Yes WOSW;;;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
- msDS-
- msDS-
False
-
True
Operation 103 : Created a new Number - objectClass: msDS- (D;;SDDT;;;WD)

{ede85f96-7061-47bf- value type configuration ValueType (A;;RPLCLORC;;;AU)
b11b-0c0d999595b5} object CN=MS-DS- - description: You can use (A;;RPWPCRLCLOCCRCWD
Number,CN=Value this type to author resource WOSW;;;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
- msDS-
- msDS-
False
-
True
Operation 104 : Created a new DateTime - objectClass: msDS- (D;;SDDT;;;WD)

{ee0f3271-eb51-414a- value type configuration ValueType (A;;RPLCLORC;;;AU)
bdac-8f9ba6397a39} object CN=MS-DS- - description: You can use (A;;RPWPCRLCLOCCRCWD
DateTime,CN=Value this type to author resource WOSW;;;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
- msDS-
- msDS-
False
-
True
Operation 105 : Created a new OrderedList - objectClass: msDS- (D;;SDDT;;;WD)

{587d52e0-507e-440e- value type configuration ValueType (A;;RPLCLORC;;;AU)
9d67-e6129f33bb68} object CN=MS-DS- - description: You can use (A;;RPWPCRLCLOCCRCWD
OrderedList,CN=Value this type to author resource WOSW;;;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 resource
properties.
- displayname: Ordered List
- msDS-
: True
- msDS-
- msDS-
True
-
True
Operation 106 : Created a new Text value - objectClass: msDS- (D;;SDDT;;;WD)

{ce24f0f6-237e-43d6- type configuration object ValueType (A;;RPLCLORC;;;AU)
ac04-1e918ab04aac} CN=MS-DS-Text,CN=Value - description: You can use (A;;RPWPCRLCLOCCRCWD
Types,CN=Claims this type to author resource WOSW;;;EA)
Configuration,CN=Services properties that contain a (A;;RPWPCRLCLOCCDCRCW
in the Configuration single text entry. DWOSDDTSW;;;SY)
partition. - displayname: Text
- msDS-
: False
- msDS-
- msDS-
False
-
True

{7f77d431-dd6a-434f- MultivaluedText value type ValueType (A;;RPLCLORC;;;AU)
ae4d-ce82928e498f} configuration object - description: You can use (A;;RPWPCRLCLOCCRCWD
CN=MS-DS- this type to author resource WOSW;;;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
- msDS-
ClaimIsSingleValued: False
- msDS-
False
-
True

{ba14e1f6-7cd1-4739- MultivaluedChoice value ValueType (A;;RPLCLORC;;;AU)
804f-57d0ea74edf4} type configuration object - description: You can use (A;;RPWPCRLCLOCCRCWD
CN=MS-DS- this type to author resource WOSW;;;EA)
MultivaluedChoice,CN=Valu properties that can have (A;;RPWPCRLCLOCCDCRCW
e 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
- msDS-
ClaimIsSingleValued: False
- msDS-
True
-
True
Operation 109 : Created a new Personally - objectClass: msDS- (D;;SDDT;;;WD)

{156ffa2a-e07c-46fb-a5c4- Identifiable Information ResourceProperty (A;;RPLCLORC;;;AU)
fbd84a4e5cce} resource property object - description: The Personally (A;;RPWPCRLCLOCCRCWD
CN=PII_MS,CN=Resource Identifiable Information (PII) WOSW;;;EA)
Properties,CN=Claims property specifies whether (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services the resource contains PII DWOSDDTSW;;;SY)
in the Configuration and if it does, what the
partition. sensitivity level of that
information is.
- displayname: Personally
Identifiable Information
- Enabled: False
- msDS-
IsUsedAsResourceSecurityAt
tribute: True
- msDS-
ValueTypeReference:
CN=MS-DS-
OrderedList,CN=Value
Types,CN=Claims
Configuration,CN=Services,
CN=Configuration,CN=
Operation 110 : Created a new Protected - objectClass: msDS- (D;;SDDT;;;WD)

{7771d7dd-2231-4470- Health Information resource ResourceProperty (A;;RPLCLORC;;;AU)
aa74-84a6f56fc3b6} property object - description: The Protected (A;;RPWPCRLCLOCCRCWD
CN=ProtectedHealthInform Health Information (PHI) WOSW;;;EA)
ation_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
partition. or medical payment history.
- displayname: Protected
Health Information
- Enabled: False
- msDS-
tribute: True
- msDS-
ValueTypeReference:
CN=MS-DS-
YesNo,CN=Value
Types,CN=Claims
Operation 111 : Created a new Required - objectClass: msDS- (D;;SDDT;;;WD)

{49b2ae86-839a-4ea0- Clearance resource ResourceProperty (A;;RPLCLORC;;;AU)
81fe-9171c1b98e83} property object - description: The Required (A;;RPWPCRLCLOCCRCWD
CN=RequiredClearance_MS, Clearance property specifies WOSW;;;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-
tribute: True
- msDS-
ValueTypeReference:
CN=MS-DS-
Types,CN=Claims

{1b1de989-57ec-4e96- Confidentiality resource ResourceProperty (A;;RPLCLORC;;;AU)
b933-8279a8119da4} property object - description: The (A;;RPWPCRLCLOCCRCWD
CN=Confidentiality_MS,CN Confidentiality property WOSW;;;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
partition. access or disclosure.
- displayname:
Confidentiality
- Enabled: False
- msDS-
tribute: True
- msDS-
ValueTypeReference:
CN=MS-DS-
Types,CN=Claims
Operation 113 : Created a new Compliancy - objectClass: msDS- (D;;SDDT;;;WD)

{281c63f0-2c9a-4cce- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
9256-a238c23c0db9} CN=Compliancy_MS,CN=Re - description: The (A;;RPWPCRLCLOCCRCWD
source Compliancy property WOSW;;;EA)
Properties,CN=Claims specifies the compliance (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services frameworks that apply to DWOSDDTSW;;;SY)
in the Configuration the resource.
partition. - displayname: Compliancy
- Enabled: False
- msDS-
tribute: True
- msDS-
ValueTypeReference:
CN=MS-DS-
MultivaluedChoice,CN=Valu
e Types,CN=Claims

{4c47881a-f15a-4f6c-9f49- Discoverability resource ResourceProperty (A;;RPLCLORC;;;AU)
2742f7a11f4b} property object - description: The (A;;RPWPCRLCLOCCRCWD
CN=Discoverability_MS,CN Discoverability property WOSW;;;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-
tribute: True
- msDS-
ValueTypeReference:
CN=MS-DS-
SinglevaluedChoice,CN=Val
ue Types,CN=Claims
Operation 115 : Created a new Immutable - objectClass: msDS- (D;;SDDT;;;WD)

{2aea2dc6-d1d3-4f0c- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
9994-66c1da21de0f} CN=Immutable_MS,CN=Re - description: The (A;;RPWPCRLCLOCCRCWD
source Immutable property WOSW;;;EA)
Properties,CN=Claims specifies whether a user (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services should be allowed to delete DWOSDDTSW;;;SY)
in the Configuration a resource or change its
partition. contents.
- displayname: Immutable
- Enabled: False
- msDS-
tribute: True
- msDS-
ValueTypeReference:
CN=MS-DS-
YesNo,CN=Value
Types,CN=Claims
Operation 116 : Created a new Intellectual - objectClass: msDS- (D;;SDDT;;;WD)

{ae78240c-43b9-499e- Property resource property ResourceProperty (A;;RPLCLORC;;;AU)
ae65-2b6e0f0e202a} object - description: The (A;;RPWPCRLCLOCCRCWD
CN=IntellectualProperty_M Intellectual Property (IP) WOSW;;;EA)
S,CN=Resource property specifies whether (A;;RPWPCRLCLOCCDCRCW
Properties,CN=Claims the resource contains IP, DWOSDDTSW;;;SY)
Configuration,CN=Services and if so, what kind.
in the Configuration - displayname: Intellectual
partition. Property
- Enabled: False
- msDS-
tribute: True
- msDS-
ValueTypeReference:
CN=MS-DS-
ue Types,CN=Claims
Operation 117 : Created a new Department - objectClass: msDS- (D;;SDDT;;;WD)

{261b5bba-3438-4d5c- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
a3e9-7b871e5f57f0} CN=Department_MS,CN=R - description: The (A;;RPWPCRLCLOCCRCWD
esource Department property WOSW;;;EA)
Properties,CN=Claims specifies the name of the (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services department to which the DWOSDDTSW;;;SY)
in the Configuration resource belongs.
partition. - displayname: Department
- Enabled: False
- msDS-
tribute: True
- msDS-
ValueTypeReference:
CN=MS-DS-
ue Types,CN=Claims
Operation 118 : Created a new Impact - objectClass: msDS- (D;;SDDT;;;WD)

{3fb79c05-8ea1-438c- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
8c7a-81f213aa61c2} CN=Impact_MS,CN=Resour - description: The Impact (A;;RPWPCRLCLOCCRCWD
ce Properties,CN=Claims property specifies the WOSW;;;EA)
Configuration,CN=Services degree of organizational (A;;RPWPCRLCLOCCDCRCW
in the Configuration impact from inappropriate DWOSDDTSW;;;SY)
partition. access or loss of the
resource.
- displayname: Impact
- Enabled: False
- msDS-
tribute: True
- msDS-
ValueTypeReference:
CN=MS-DS-
Types,CN=Claims
<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 : Created a new Personal Use - objectClass: msDS- (D;;SDDT;;;WD)

{0b2be39a-d463-4c23- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
8290-32186759d3b1} CN=PersonalUse_MS,CN=R - description: The Personal (A;;RPWPCRLCLOCCRCWD
esource Use property specifies WOSW;;;EA)
Properties,CN=Claims whether the file is for (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services personal use (not business DWOSDDTSW;;;SY)
in the Configuration related).
partition. - displayname: Personal Use
- Enabled: False
- msDS-
tribute: True
- msDS-
ValueTypeReference:
CN=MS-DS-
YesNo,CN=Value
Types,CN=Claims
Operation 120 : Created a new Project - objectClass: msDS- (D;;SDDT;;;WD)

{f0842b44-bc03-46a1- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
a860-006e8527fccd} CN=Project_MS,CN=Resour - description: The Project (A;;RPWPCRLCLOCCRCWD
ce Properties,CN=Claims property specifies the WOSW;;;EA)
Configuration,CN=Services names of one or more (A;;RPWPCRLCLOCCDCRCW
in the Configuration projects that are relevant to DWOSDDTSW;;;SY)
partition. the resource.
- displayname: Project
- Enabled: False
- msDS-
tribute: True
- msDS-
ValueTypeReference:
CN=MS-DS-
e Types,CN=Claims
Operation 121 : Created a new Retention - objectClass: msDS- (D;;SDDT;;;WD)

{93efec15-4dd9-4850- Period resource property ResourceProperty (A;;RPLCLORC;;;AU)
bc86-a1f2c8e2ebb9} object - description: The Retention (A;;RPWPCRLCLOCCRCWD
CN=RetentionPeriod_MS,C Period property specifies WOSW;;;EA)
N=Resource the maximum period for (A;;RPWPCRLCLOCCDCRCW
Properties,CN=Claims which the file should be DWOSDDTSW;;;SY)
Configuration,CN=Services retained.
in the Configuration - displayname: Retention
partition. Period
- Enabled: False
- msDS-
tribute: True
- msDS-
ValueTypeReference:
CN=MS-DS-
ue Types,CN=Claims
Operation 122 : Created a new Retention - objectClass: msDS- (D;;SDDT;;;WD)

{9e108d96-672f-40f0- Start Date resource ResourceProperty (A;;RPLCLORC;;;AU)
b6bd-69ee1f0b7ac4} property object - description: The Retention (A;;RPWPCRLCLOCCRCWD
CN=RetentionStartDate_MS Start Date property defines WOSW;;;EA)
,CN=Resource the starting date for a (A;;RPWPCRLCLOCCDCRCW
Properties,CN=Claims Retention Period. The DWOSDDTSW;;;SY)
Configuration,CN=Services retention period would
in the Configuration begin on the Retention
partition. Start Date.
- displayname: Retention
Start Date
- Enabled: False
- msDS-
tribute: False
- msDS-
ValueTypeReference:
CN=MS-DS-
DateTime,CN=Value
Types,CN=Claims
Operation 123 : Created a new Company - objectClass: msDS- (D;;SDDT;;;WD)

{1e269508-f862-4c4a- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
b01f-420d26c4ff8c} CN=Company_MS,CN=Res - description: The Company (A;;RPWPCRLCLOCCRCWD
ource property specifies which WOSW;;;EA)
Properties,CN=Claims company the resource (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services belongs to. DWOSDDTSW;;;SY)
in the Configuration - displayname: Company
partition. - Enabled: False
- msDS-
tribute: True
- msDS-
ValueTypeReference:
CN=MS-DS-
ue Types,CN=Claims
Operation 125 : Created a new Folder Usage - objectClass: msDS- (D;;SDDT;;;WD)

{e1ab17ed-5efb-4691- resource property object ResourceProperty (A;;RPLCLORC;;;AU)
ad2d-0424592c5755} CN=FolderUsage_MS,CN=R - description: The Folder (A;;RPWPCRLCLOCCRCWD
Note: Operation 124 was esource Usage property specifies WOSW;;;EA)
deleted. Properties,CN=Claims the purpose of the folder (A;;RPWPCRLCLOCCDCRCW
Configuration,CN=Services and the kind of files stored DWOSDDTSW;;;SY)
in the Configuration in it.
partition. - displayname: Folder
Usage
- Enabled: False
- msDS-
tribute: False
- msDS-
AppliestoResourceTypes:
MS-DS-Container
- msDS-
ValueTypeReference:
CN=MS-DS-
e Types,CN=Claims
Operation 126 : Created a new Global - objectClass: msDS- (D;;SDDT;;;WD)

{0e848bd4-7c70-48f2- Resource Property List ResourcePropertyList (A;;RPLCLORC;;;AU)
b8fc-00fbaa82e360} configuration object - description: This is a (A;;RPWPCRLCLOCCRCWD
CN=Global Resource global out of box resource WOSW;;;EA)
Property List,CN=Resource property list that contains (A;;RPWPCRLCLOCCDCRCW
Property Lists,CN=Claims all resource properties that DWOSDDTSW;;;SY)
Configuration,CN=Services can be consumed by
in the Configuration applications.
partition. -
True
- msDS-
MembersOfResourceProper
tyList:
CN=PII_MS,CN=Resource
Properties,CN=Claims
- msDS-
tyList:
CN=ProtectedHealthInform
ation_MS,CN=Resource
- msDS-
tyList:
CN=RequiredClearance_MS,
CN=Resource
- msDS-
tyList:
CN=Confidentiality_MS,CN
GUID DESC RIP T IO N =Resource
AT T RIB UT ES P ERM ISSIO N S
- msDS-
tyList:
CN=Compliancy_MS,CN=Re
source
- msDS-
tyList:
CN=Discoverability_MS,CN
=Resource
- msDS-
tyList:
CN=Immutable_MS,CN=Re
source
- msDS-
tyList:
CN=IntellectualProperty_M
S,CN=Resource
- msDS-
tyList:
CN=Department_MS,CN=R
esource
- msDS-
tyList:
CN=Impact_MS,CN=Resour
ce Properties,CN=Claims
- msDS-
tyList:
CN=PersonalUse_MS,CN=R
esource
- msDS-
tyList:
CN=Project_MS,CN=Resour
ce Properties,CN=Claims
GUID DESC RIP T IO N CN=Configuration,CN=
AT T RIB UT ES P ERM ISSIO N S
- msDS-
tyList:
CN=RetentionPeriod_MS,C
N=Resource
- msDS-
tyList:
CN=RetentionStartDate_MS
,CN=Resource
- msDS-
tyList:
CN=Company_MS,CN=Res
ource
- msDS-
tyList:
CN=FolderUsage_MS,CN=R
esource
Operation 127 : Call back function to N/A N/A
{016f23f7-077d-41fa- upgrade display specifiers.
a356-de7cfdb01797}
Operation 128 : Updated strings for Folder - description: The Folder N/A
{49c140db-2de3-44c2- Usage resource property Usage property specifies
a99a-bab2e6d2ba81} object the purpose of the folder
CN=FolderUsage_MS,CN=R and the kind of files stored
esource in it.
Configuration,CN=Services
partition.
Operation 129 : Added ACE to grant N/A (OA;CIOI;RPWP;3f78c3e5-

{e0b11c80-62c5-47f7- Principal Self Write Property f79a-46bd-a0b8-
ad0d-3734a71b8312} and Read Property on 9d18116ddc79;;PS)
CN=Sam-Domain object.
Operation 130 : Added ACE to grant N/A (OA;CIOI;RPWP;3f78c3e5-

{2ada1a2d-b02f-4731- Principal Self Write Property f79a-46bd-a0b8-
b4fe-59f955e24f71} and Read Property on 9d18116ddc79;;PS)
CN=Domain-DNS object.
This topic covers detailed methodology on troubleshooting domain controller configuration and deployment.
Built-in logs for troubleshooting

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.
P H A SE LO G
Server Manager or ADDSDeployment Windows PowerShell - %systemroot%\debug\dcpromoui.log

operations - %systemroot%\debug\dcpromoui*.log
Installation/Promotion of the domain controller - %systemroot%\debug\dcpromo.log

- %systemroot%\debug\dcpromo*.log
- Event viewer\Windows logs\Application
Service
- Event viewer\Applications and services logs\File
Replication Service
- Event viewer\Applications and services logs\DFS
Replication
P H A SE LO G
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.
Troubleshooting 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 success codes

ERRO R C O DE EXP L A N AT IO N N OT E
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 failure codes

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.
ERRO R C O DE EXP L A N AT IO N SUGGEST ED RESO L UT IO N
11 Domain controller promotion is Do not run than one instance of

already running domain 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
invalid a 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 Provide a password for the local
criteria (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 Choose a different forest root DNS
already exists domain name
46 The specified name for the tree is Specify a valid tree DNS domain name
invalid
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

was detected even though it is not, or Controller in the Domain (-
last domain controller was specified, lastdomaincontrollerindomain )
but 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 Par titions (-
removeapplicationpar titions )
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 Specify that this is the Last DNS
is the last DNS server for one of its Ser ver in the Domain or use -
zones ignorelastdnsser verfordomain
60 A domain controller running Windows Promote at least one Windows Server

Server 2008 or later must be present 2008 or later model writable domain
in the domain in order to promote controller
RODC
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 Raise the forest functional level to at

windows 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 Install the AD DS role

binary detection failed
65 Promo failed because component Install the AD DS role

binary installation failed
66 Promo failed because operating Examine the extended error and logs;
system 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 Use netstat.exe -anob to locate

some 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

account controllers 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 quer y fsmo to
offline. detect 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 quer y 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 Start the AD DS service

running 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
2008 or later domain controller in the before you can demote all Windows
domain where live RODCs exist Server 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 same or higher than the forest
operating 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 Raise the forest functional level to at
is Windows Server 2012 only) least Windows Server 2003 native.
systems
100 Domain functional level is too low Raise the domain functional level to at
(error is Windows Server 2012 only) least Windows Server 2003 native.
systems
Known issues and common 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.
DEM OT IN G A DO M A IN C O N T RO L L ER L EAVES DN S RUN N IN G

ISSUE W IT H N O Z O N ES
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
P RO M OT IN G A W IN DO W S SERVER 2012 IN TO A N EXIST IN G

SIN GL E- L A B EL DO M A IN DO ES N OT C O N F IGURE
UP DAT ETO P L EVEL DO M A IN =1 O R
ISSUE A L LO W SIN GL EL A B EL DN SDO M A IN =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.
DEM OT IO N O F L A ST DO M A IN C O N T RO L L ER IN A DO M A IN
FA IL S IF T H ERE A RE P RE- C REAT ED, UN O C C UP IED RO DC
ISSUE A C C O UN T S
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,D
C=com.
"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 .
A UTO M AT ED F O REST A N D DO M A IN P REPA RAT IO N DO ES

ISSUE N OT RUN GP P REP
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.
IN STA L L F RO M M EDIA FA IL S TO VERIF Y W H EN P O IN T IN G TO

ISSUE A UN C PAT H
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.
DN S DEL EGAT IO N WA RN IN G SH O W N T W IC E DURIN G

ISSUE DO M A IN C O N T RO L L ER P RO M OT IO N
DN S DEL EGAT IO N WA RN IN G SH O W N T W IC E DURIN G
ISSUE DO M A IN C O N T RO L L ER P RO M OT IO N
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
SP EC IF Y IN G UP N O R N O N - DO M A IN C REDEN T IA L S DURIN G
ISSUE C O N F IGURAT IO N RET URN S M ISL EA DIN G ERRO RS
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 .
REM O VIN G T H E DIREC TO RY SERVIC ES- DO M A IN C O N T RO L L ER

ISSUE RO L E USIN G DISM . EXE L EA DS TO UN B O OTA B L E 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.
IN STA L L IN G A N EW F O REST FA IL S W H EN SET T IN G
ISSUE F O REST M O DE TO W IN 2012
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]
C L IC K IN G VERIF Y IN T H E IN STA L L F RO M M EDIA SEL EC T IO N

ISSUE A REA A P P EA RS TO DO N OT H IN G
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.
DEM OT IN G W IT H SERVER M A N A GER DO ES N OT P RO VIDE

ISSUE F EEDB A C K UN T IL C O M P L ET ED.
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
IN STA L L F RO M M EDIA VERIF Y DO ES N OT DET EC T T H AT

RO DC M EDIA P RO VIDED F O R W RITA B L E DO M A IN
ISSUE C O N T RO L L ER, O R VIC E 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.
IN STA L L F RO M M EDIA VERIF Y DO ES N OT DET EC T T H AT
RO DC M EDIA P RO VIDED F O R W RITA B L E DO M A IN
ISSUE C O N T RO L L ER, O R VIC E VERSA .
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.
P RO M OT IN G A N RO DC IN TO A P RE- C REAT ED C O M P UT ER
ISSUE A C C O UN T FA IL S
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.De
ployment.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
DESEL EC T IN G/ SEL EC T IN G " RESTA RT EA C H DEST IN AT IO N

ISSUE SERVER A UTO M AT IC A L LY IF REQ UIRED" DO ES N OT H IN G
Symptoms If selecting (or not selecting) the Server Manager option

Restar t each destination ser ver 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.
DC P RO M O. LO G SH O W S " [ ERRO R] SET T IN G SEC URIT Y O N

ISSUE SERVER F IL ES FA IL ED W IT H 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.
P REREQ UISIT E A DP REP C H EC K FA IL S W IT H ERRO R " UN A B L E

ISSUE TO P ERF O RM EXC H A N GE SC H EM A C O N F L IC T C H EC K "
P REREQ UISIT E A DP REP C H EC K FA IL S W IT H ERRO R " UN A B L E
ISSUE TO P ERF O RM EXC H A N GE SC H EM A C O N F L IC T C H EC K "
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
C REAT IN G A N EW A D DS F O REST A L WAY S SH O W S DN S

ISSUE WA RN IN G
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.
W IN DO W S P O W ERSH EL L - W H AT IF A RGUM EN T RET URN S

ISSUE IN C O RREC T DN S SERVER IN F O RM AT IO N
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.

A F T ER P RO M OT IO N , LO GO N FA IL S W IT H " N OT EN O UGH
ISSUE STO RA GE IS AVA IL A B L E TO P RO C ESS T H IS C O M M A N D"
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.
T H E N EXT B UT TO N IS N OT AVA IL A B L E O N T H E DO M A IN
ISSUE C O N T RO L L ER O P T IO N S PA GE
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
P RO M OT IO N O R DEM OT IO N FA IL S W IT H M ESSA GE " T H E

ISSUE SERVIC E C A N N OT B E STA RT ED"
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.
SERVER M A N A GER ST IL L WA RN S T H AT Y O U N EED TO

ISSUE P RO M OT E 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 ser ver to a
domain controller .
SERVER M A N A GER ST IL L WA RN S T H AT Y O U N EED TO
ISSUE P RO M OT E DC
Resolution and Notes Click the post-deployment warning link and the message will
disappear for good. This behavior is cosmetic and expected.
SERVER M A N A GER DEP LO Y M EN T SC RIP T M ISSIN G RO L E

ISSUE IN STA L L AT IO N
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.
SERVER M A N A GER DEP LO Y M EN T SC RIP T IS N OT N A M ED

ISSUE P S1
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.
DC P RO M O / UN AT T EN D A L LO W S UN SUP P O RT ED
ISSUE F UN C T IO N A L L EVEL S
DC P RO M O / UN AT T EN D A L LO W S UN SUP P O RT ED
ISSUE F UN C T IO N A L L EVEL S
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
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.
P RO M OT IO N " H A N GS" AT C REAT IN G N T DS SET T IN GS

ISSUE O B JEC T, N EVER C O M P L ET ES
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.
P RO M OT IO N " H A N GS" AT C REAT IN G N T DS SET T IN GS
ISSUE O B JEC T, N EVER C O M P L ET ES
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:
Determined 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
Directory Domain Services.
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\Ser vices\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\Ser vices\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 recover y?
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
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 (https://go.microsoft.com/fwlink/?LinkId=70780).
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 recover y 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
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 Star t , 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 Star t 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 Director y Ser vices 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 Star t 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 primar y 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\Ser vices\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 Star t , click Control Panel , and then click Add or Remove Programs .
Click Add/Remove Windows Components .
2. In Components , select the Networking Ser vices check box, and then click Details .
3. In Subcomponents of Networking Ser vices , select the Domain Name System (DNS) check box,
click OK , and then click Next .
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 Star t , 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
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 (https://go.microsoft.com/fwlink/?LinkId=74580).
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 star t 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 Director y 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.
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. Included in this section are the following subjects:
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 Director y - 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 Director y 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 Director y 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.
B EST P RA C T IC E TA C T IC A L O R ST RAT EGIC P REVEN TAT IVE O R DET EC T IVE
Patch applications. Tactical Preventative
Patch operating systems. Tactical Preventative
Deploy and promptly update antivirus Tactical Both

and antimalware software across all
systems and monitor for attempts to
remove or disable it.
Monitor sensitive Active Directory Tactical Detective

objects for modification attempts and
Windows for events that may indicate
attempted compromise.
Protect and monitor accounts for Tactical Both

users who have access to sensitive
data
Prevent powerful accounts from being Tactical Preventative

used on unauthorized systems.
Eliminate permanent membership in Tactical Preventative

highly privileged groups.
Implement controls to grant Tactical Preventative

temporary membership in privileged
groups when needed.
Implement secure administrative Tactical Preventative

hosts.
Use application allowslists on domain Tactical Preventative

controllers, administrative hosts, and
other sensitive systems.
Identify critical assets, and prioritize Tactical Both

their security and monitoring.
Implement least-privilege, role-based Strategic Preventative

access controls for administration of
the directory, its supporting
infrastructure, and domain-joined
systems.
Isolate legacy systems and Tactical Preventative

applications.
Decommission legacy systems and Strategic Preventative

applications.
B EST P RA C T IC E TA C T IC A L O R ST RAT EGIC P REVEN TAT IVE O R DET EC T IVE
Implement secure development Strategic Preventative

lifecycle programs for custom
applications.
Implement configuration Strategic Preventative

management, review compliance
regularly, and evaluate settings with
each new hardware or software
version.
Migrate critical assets to pristine Strategic Both

forests with stringent security and
monitoring requirements.
Simplify security for end users. Strategic Preventative
Use host-based firewalls to control and Tactical Preventative

secure communications.
Patch devices. Tactical Preventative
Implement business-centric lifecycle Strategic N/A

management for IT assets.
Create or update incident recovery Strategic N/A

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.
H O W IT IS REF EREN C ED IN T H IS
A C C O UN T / GRO UP LO C AT IO N N A M E O F A C C O UN T / GRO UP DO C UM EN T
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
H O W IT IS REF EREN C ED IN T H IS
A C C O UN T / GRO UP LO C AT IO N N A M E O F A C C O UN T / GRO UP DO C UM EN T
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.
A P P EN DIX DESC RIP T IO N
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 Contains guidelines to help secure the Administrator
Active Directory account 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
Directory group in each domain in the forest.
Appendix G: Securing Administrators Groups in Active Contains guidelines to help secure the Built-in
Directory Administrators 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
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 Microsoft Endpoint Configuration Manager 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 Director y by Operating System and Ser vice Pack
(SP) Version
W IN DO W S 2000 SP 4 - W IN DO W S SERVER 2003 W IN DO W S SERVER 2008 -

W IN DO W S 2000 <SP 4 W IN DO W S SERVER 2003 SP 1+ W IN DO W S 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 proportion-midsized 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 as 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 Smar t 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 Smar t 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
membership 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 Ser vices 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 Microsoft Endpoint Configuration Manager 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 smar t 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 smar t 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 smar t 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 machines should be configured with script, tool, and application s 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' s.
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 Microsoft Endpoint 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 allowslist 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
Applies To: Windows Server 2022 Preview, Windows Server 2019, Windows Server 2016, Windows Server
2012 R2, Windows Server 2012
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.
NOTE
If you intend to co-locate virtualized domain controllers with other, less sensitive virtual machines on the same physical
virtualization servers (hosts), consider implementing a solution which enforces role-based separation of duties, such as
Shielded VMs in Hyper-V. This technology provides comprehensive protection against malicious or clueless fabric
administrators (including virtualization, network, storage and backup administrators.) It leverages physical root of trust
with remote attestation and secure VM provisioning, and effectively ensures level of security which is on par with a
dedicated physical server.
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. 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.
NOTE
As for any security-sensitive and single-purpose configuration, we recommend that you deploy the operating system in
Server Core installation option. It provides multiple benefits, such as minimizing attack surface, improving performance
and reducing the likelihood of human error. It is recommended that all operations and management are performed
remotely, from dedicated highly secured endpoints such as Privileged access workstations (PAW) or Secure administrative
hosts.
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 in Administer security policy settings section of Microsoft operating systems documentation.
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 Active Directory 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.
Monitoring Active Directory for Signs of
Compromise
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>:<audit category> /<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:<filename> - Used to back up a current local audit policy to a binary file
auditpol /restore /file:<filename> - Used to import a previously saved audit policy file to a local audit policy
auditpol /<get/set> /option:<CrashOnAuditFail> /<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 Over write Events or Over write 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:<AuditBaseObjects> /<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:<AuditBaseDirectories> /<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:<FullPrivilegeAuditing> /<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 subcategories, it cannot be both.
To prevent the legacy traditional category policy from overwriting audit policy subcategories, you must enable
the Force audit policy subcategor y settings(Windows Vista or later) to override audit policy
categor y 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.
Next steps
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
N OTAT IO N REC O M M EN DAT IO N
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
B A SEL IN E ST RO N GER
W IN DO W S DEFA ULT REC O M M EN DAT IO N REC O M M EN DAT IO N
A UDIT P O L IC Y C AT EGO RY SUCCESS \ | FAILURE SUCCESS \ | FAILURE SUCCESS \ | FAILURE
O R SUB C AT EGO RY
Account Logon
Audit Credential Validation No \ | No Yes \ | No Yes \ | Yes
Audit Kerberos Yes \ | Yes

Authentication Service
Audit Kerberos Service Yes \ | Yes

Ticket Operations
Audit Other Account Logon Yes \ | Yes

Events
O R SUB C AT EGO RY
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
A UDIT P O L IC Y C AT EGO RY
O R SUB C AT EGO RY
SUCCESS \ | FAILURE SUCCESS \ | FAILURE SUCCESS \ | FAILURE
Audit User Account Yes \| No Yes \| No Yes \| Yes

Management
O R SUB C AT EGO RY
Detailed Tracking
Audit DPAPI Activity Yes \| Yes
Audit Process Creation Yes \| No Yes \| Yes
Audit Process Termination
Audit RPC Events
O R SUB C AT EGO RY
DS Access
Audit Detailed Directory

Service Replication
Audit Directory Service

Access

Changes

Replication
O R SUB C AT EGO RY
Logon and Logoff
Audit Account Lockout Yes \| No Yes \| No
Audit User/Device Claims
Audit IPsec Extended Mode
Audit IPsec Main Mode IF \| IF

O R SUB C AT EGO RY
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
O R SUB C AT EGO RY
Object Access
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
O R SUB C AT EGO RY
Audit Central Access Policy

Staging
O R SUB C AT EGO RY
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
O R SUB C AT EGO RY
Privilege Use
Audit Non Sensitive

Privilege Use
Audit Other Privilege Use

Events
Audit Sensitive Privilege Use
O R SUB C AT EGO RY
System
Audit IPsec Driver Yes \| Yes Yes \| Yes
Audit Other System Events Yes \| Yes

O R SUB C AT EGO RY
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
O R SUB C AT EGO RY
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 Ser ver 2016, Windows Ser ver 2012 R2, Windows Ser ver 2012, Windows Ser ver 2008
R2, and Windows Ser ver 2008 Audit Settings Recommendations
O R SUB C AT EGO RY
Account Logon
Audit Credential Validation No \| No Yes \| Yes Yes \| Yes
Audit Kerberos Yes \| Yes

Authentication Service
Audit Kerberos Service Yes \| Yes

Ticket Operations
Audit Other Account Logon Yes \| Yes

Events
O R SUB C AT EGO RY
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
O R SUB C AT EGO RY
Detailed Tracking
Audit DPAPI Activity Yes \| Yes
Audit Process Creation Yes \| No Yes \| Yes
Audit Process Termination
Audit RPC Events
O R SUB C AT EGO RY
DS Access
Audit Detailed Directory

Service Replication
Audit Directory Service DC \| DC DC \| DC

Access
Audit Directory Service DC \| DC DC \| DC

Changes
O R SUB C AT EGO RY

Replication
O R SUB C AT EGO RY
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
O R SUB C AT EGO RY
Object Access
Audit Application
Generated
Audit Certification Services
Audit Detailed File Share
Audit File Share
Audit File System

O R SUB C AT EGO RY

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
O R SUB C AT EGO RY
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
O R SUB C AT EGO RY
O R SUB C AT EGO RY
Privilege Use
Audit Non Sensitive

Privilege Use
Audit Other Privilege Use

Events
Audit Sensitive Privilege Use
O R SUB C AT EGO RY
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
O R SUB C AT EGO RY
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 anti-malware 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 is 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 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.
A P P EN DIX DESC RIP T IO N
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 Contains guidelines to help secure the Administrator
Active Directory account 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
Directory group in each domain in the forest.
Appendix G: Securing Administrators Groups in Active Contains guidelines to help secure the Built-in
Directory Administrators 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
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 RIGH T IN GRO UP P O L IC Y N A M E O F C O N STA N T
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
DEFA ULT C O N TA IN ER, GRO UP SC O P E DESC RIP T IO N A N D DEFA ULT USER

A C C O UN T O R GRO UP AND T YPE RIGH T S
Access Control Assistance Operators Built-in container Members of this group can remotely
(Active Directory in Windows Server Domain-local security group query authorization attributes and
2012) permissions for resources on this
computer.
Direct user rights: None
Inherited user rights:
Access this computer from the
network
Add workstations to domain
Bypass traverse checking
Increase a process working set
Account Operators Built-in container Members can administer domain user

Domain-local security group and group accounts.
network
Administrator account Users container Built-in account for administering the

Not a group domain.
network
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
AAdministrators
C C O UN T O R GRO UP
group ABuilt-in
N D T Y container
PE RIGH TS
Administrators have complete and
Domain-local security group unrestricted access to the domain.
Direct user rights:
network
process
Desktop Services
Create a pagefile
Debug programs
delegation
system
authentication
values
station
objects
network
Allowed RODC Password Replication Users container Members in this group can have their
Group Domain-local security group passwords replicated to all read-only
domain controllers in the domain.
network
Backup Operators Built-in container Backup Operators can override

Domain-local security group security restrictions for the sole
purpose of backing up or restoring
files.
Direct user rights:
network
Cert Publishers Users container Members of this group are permitted

Domain-local security group to publish certificates to the directory.
network
Certificate Service DCOM Access Built-in container If Certificate Services is installed on a

Domain-local security group domain controller (not recommended),
this group grants DCOM enrollment
access to Domain Users and Domain
Computers.
network
Cloneable Domain Controllers (AD DS Users container Members of this group that are
in Windows Server 2012AD DS) Global security group domain controllers may be cloned.
network
Cryptographic Operators Built-in container Members are authorized to perform

Domain-local security group cryptographic operations.
network
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 Domain-local security group their passwords replicated to any read-
only domain controllers in the domain.
network
DHCP Administrators Users container Members of this group have

Domain-local security group administrative access to the DHCP
Server service.
network
DHCP Users Users container Members of this group have view-only

Domain-local security group access to the DHCP Server service.
network
Distributed COM Users Built-in container Members of this group are allowed to
Domain-local security group launch, activate, and use distributed
COM objects on this computer.
network
DnsAdmins Users container Members of this group have

Domain-local security group administrative access to the DNS
Server service.
network
DnsUpdateProxy Users container Members of this group are DNS clients

Global security group who are permitted to perform dynamic
updates on behalf of clients that
cannot themselves perform dynamic
updates. Members of this group are
typically DHCP servers.
network
Domain Admins Users container Designated administrators of the

Global security group domain; Domain Admins is a member
of 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.
network
process
Desktop Services
A C C O UN T O R GRO UP AND T YPE RIGH
CreateT Sa pagefile
Debug programs
delegation
system
authentication
values
station
objects
Domain Computers Users container All workstations and servers that are
Global security group joined to the domain are by default
members of this group.
Default direct user rights:
None
network
Domain Controllers Users container All domain controllers in the domain.

Global security group Note: Domain controllers are not a
member of the Domain Computers
group.
network
Domain Guests Users container All guests in the domain

Global security group Direct user rights: None
network
Domain Users Users container All users in the domain

Global security group Direct user rights: None
network
Enterprise Admins (exists only in forest Users container Enterprise Admins have permissions to
root domain) Universal security group change forest-wide configuration
settings; Enterprise Admins is a
member of every domain's
Administrators group and receives
rights and permissions granted to that
group.
network
process
A C C O UN T O R GRO UP AND T YPE Desktop
RIGH T S Services
Create a pagefile
Debug programs
delegation
system
authentication
values
station
objects
Enterprise Read-only Domain Users container This group contains the accounts for
Controllers Universal security group all read-only domain controllers in the
forest.
network
Event Log Readers Built-in container Members of this group in can read the
Domain-local security group event logs on domain controllers.
network
Group Policy Creator Owners Users container Members of this group can create and
Global security group modify Group Policy Objects in the
domain.
network
Guest Users container This is the only account in an AD DS

Not a group domain that does not have the
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.
network
Guests Built-in container Guests have the same access as

Domain-local security group members of the Users group by
default, except for the Guest account,
which is further restricted as described
earlier.
network
Hyper-V Administrators (Windows Built-in container Members of this group have complete
Server 2012) Domain-local security group and unrestricted access to all features
of Hyper-V.
network
IIS_IUSRS Built-in container Built-in group used by Internet

Domain-local security group Information Services.
network
Incoming Forest Trust Builders (exists Built-in container Members of this group can create
only in forest root domain) Domain-local security group incoming, one-way trusts to this
forest. (Creation of outbound forest
trusts is reserved for Enterprise
Admins.)
network
Krbtgt Users container The Krbtgt account is the service

Not a group account for the Kerberos Key
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
Domain-local security group privileges that allow them to manage
configuration of networking features.
network
Performance Log Users Built-in container Members of this group can schedule
Domain-local security group logging of performance counters,
enable trace providers, and collect
event traces locally and via remote
access to the computer.
Direct user rights:
network
Performance Monitor Users Built-in container Members of this group can access
Domain-local security group performance counter data locally and
remotely.
network
Pre-Windows 2000 Compatible Access Built-in container This group exists for backward
Domain-local security group compatibility with operating systems
prior to Windows 2000 Server, and it
provides the ability for members to
read user and group information in the
domain.
Direct user rights:
network
Print Operators Built-in container Members of this group can administer

Domain-local security group domain printers.
Direct user rights:
network
RAS and IAS Servers Users container Servers in this group can read remote
Domain-local security group access properties on user accounts in
the domain.
network
RDS Endpoint Servers (Windows Built-in container Servers in this group run virtual
Server 2012) Domain-local security group machines and host sessions where
users 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.
network
RDS Management Servers (Windows Built-in container Servers in this group can perform
Server 2012) Domain-local security group routine administrative actions on
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.
network
RDS Remote Access Servers (Windows Built-in container Servers in this group enable users of
Server 2012) Domain-local security group RemoteApp programs and personal
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.
network
Read-only Domain Controllers Users container This group contains all read-only
Global security group domain controllers in the domain.
network
Remote Desktop Users Built-in container Members of this group are granted
Domain-local security group the right to log on remotely using RDP.
network
Remote Management Users (Windows Built-in container Members of this group can access
Server 2012) Domain-local security group WMI resources over management
protocols (such as WS-Management
via the Windows Remote Management
service). This applies only to WMI
namespaces that grant access to the
user.
network
Replicator Built-in container Supports legacy file replication in a

Domain-local security group domain.
network
Schema Admins (exists only in forest Users container Schema admins are the only users who
root domain) Universal security group can make modifications to the Active
Directory schema, and only if the
schema is write-enabled.
network
Server Operators Built-in container Members of this group can administer

Domain-local security group domain servers.
Direct user rights:
system
network
Terminal Server License Servers Built-in container Members of this group can update
Domain-local security group user accounts in Active Directory with
information about license issuance, for
the purpose of tracking and reporting
TS Per User CAL usage
Default direct user rights:
None
network
Users Built-in container Users have permissions that allow

Domain-local security group them to read many objects and
attributes in 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:
network
Windows Authorization Access Group Built-in container Members of this group have access to
Domain-local security group the computed
tokenGroupsGlobalAndUniversal
attribute on User objects
network
WinRMRemoteWMIUsers_ (Windows Users container Members of this group can access

Server 2012) Domain-local security group WMI resources over management
protocols (such as WS-Management
via the Windows Remote Management
service). This applies only to WMI
namespaces that grant access to the
user.
network
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
W IN DO W S SERVER 2012,
W IN DO W S SERVER 2003 W IN DO W S SERVER 2003 W IN DO W S SERVER 2008 R2,
RT M SP 1+ W IN DO W S SERVER 2008 W IN DO W S 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
Krbtgt Krbtgt Krbtgt Krbtgt
Print Operators Print Operators Print Operators Print Operators
Read-only Domain Read-only Domain

Controllers Controllers
W IN DO W S SERVER 2012,
W IN DO W S SERVER 2003 W IN DO W S SERVER 2003 W IN DO W S SERVER 2008 R2,
RT M SP 1+ W IN DO W S SERVER 2008 W IN DO W S SERVER 2016
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 Entr y Attribute field, type
FixUpInheritance , and in the Values field, type Yes . Click Enter to populate the Entr y 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 Entr y 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 Smar t 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
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 Ser ver Manager , click Tools , and click Active Director y 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 Proper ties .
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 Smar t card is required for interactive logon flag on the account, perform the
following steps:
a. Right-click the Administrator account and select Proper ties .
b. Click the Account tab.
c. Under Account options, select the Smar t 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 Ser ver 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 ser vice 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 Ser vices 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 \\<Ser ver 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 Star t 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 ser vices , and click Ser vices .
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 ser vice and select Restar t .
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
Assignments :
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
and 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:
policy 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 ser vice 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:
policy 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"),
verify the GPO 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.
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 Star t 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 Restar t .
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.
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 in Computer Configuration\Policies\Windows
Deny log on locally
Deny log on through Remote Desktop Services user rights
membership 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
policy 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:
policy settings .

13. In Group Policy Management, link the GPO to the member server and workstation OUs by doing the
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
verify the GPO 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 Restar t .
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.
2. In GPOs linked to OUs containing member servers and workstations in each domain, the BA group
should 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:
Access this computer from the network
Allow log on through Remote Desktop Services
membership 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
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
policy 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

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 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 Ser vices 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
and 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 is the name of this GPO).

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 Ser vices 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
On computers running Windows 8, in the Search box, type schedule tasks, and click Schedule tasks.

7. In the Program/script field, click Browse , locate and select the batch file created in the Create a Batch
File section, and click Open .
8. Click OK .
11. Type the name of an account that is a member of the Administrators group, click Check Names , and
click OK .
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
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
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 the local Administrator account from accessing members servers
and workstations over the network by doing the following:
policy 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 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.
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:
policy settings .
c. Click OK .
IMPORTANT
following:
a. Navigate to the <Forest>\Domains\<Domain> (where <Forest> is the name of the forest and
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),
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 \\<Server Name>\c$ /user:<Server Name>\Administrator ,
where <Server Name> 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.
5. In the File name box, type <Filename>.bat (where <Filename> is the name of the new batch file).
2. In the Search box, type task scheduler, and click Task Scheduler .
NOTE

4. In the Create Task dialog box, type <Task Name> (where <Task Name> is the name of the new task).
6. In the Action field, click Star t a program .
7. In the Program/script field, click Browse , locate and select the batch file created in the Create a Batch
File section, and click Open .
8. Click OK .
11. Type the name of the system's local Administrator account, click Check Names , and click OK .
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 System Account , 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 Proper ties , and click the Object tab. In the group's Object
proper ty 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 Director y Users and Computers console, click View
and select Advanced Features . Right-click the group you just created, click Proper ties , 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 Conver t 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 Director y 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 Proper ties .
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 suppor ts Kerberos AES 128 bit encr yption and/or the This account suppor ts
Kerberos AES 256 encr yption 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 Encr yption 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 Entr y 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 Entr y 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 proper ties , Read permissions , and Reset password .
26. In the Proper ties 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 Director y 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 Proper ties .
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 Director y 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 Proper ties , 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 Director y Users and Computers and locate the Domain Admins group .
3. Right-click the Domain Admins group and click Proper ties .
4. In the Domain Admins Proper ties , 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 Proper ties 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 Proper ties 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 Proper ties 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.
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.
C URREN T W IN DO W S EVEN T L EGA C Y W IN DO W S EVEN T

ID ID P OT EN T IA L C RIT IC A L IT Y EVEN T SUM M A RY
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

network issue or an
this negotiation.
4978 N/A Medium During Extended Mode

network issue or an
this 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.

Service was unable to parse
the new security policy. The
service will continue with
currently enforced policy.

Service failed to initialize the
driver. The service will
continue to enforce the
current policy.

Service 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.

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.

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.

established. Extended Mode
was not enabled. A
certificate was used for
authentication.

negotiation failed.

negotiation failed.
4654 N/A Low An IPsec Quick Mode

negotiation failed.

security 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
failed to apply locally
cached copy of Active
Directory storage IPsec
policy on the computer.
PAStore Engine failed to
apply Active Directory
failed to apply local registry
failed to apply some rules of
the active IPsec policy on
the computer. PAStore
Engine failed to load
directory storage IPsec
PAStore Engine loaded
PAStore Engine failed to
load local storage IPsec
PAStore Engine loaded local
computer.PAStore Engine
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.

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.

local group.
4734 638 Low A security-enabled local

group was deleted.

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.

global group.

group was deleted.

security-enabled universal
group.

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.

universal group.

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.

a 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.

a 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.

retrieved an archived key.

imported a certificate into
its database.

a certificate request.

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.

imported and archived a
key.

published the CA certificate
to Active Directory Domain
Services.
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.

Service has been stopped.

Service 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.

IPsec settings. A
was modified.

IPsec settings. A
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.FirewallEnable
d(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.

Platform filter has been
changed.

Platform provider has been
changed.

Platform provider context
has been changed.

Platform sublayer has been
changed.

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
IPsec policy on the
computer.

apply locally cached copy of
IPsec policy on the
computer.
5460 N/A Low PAStore Engine applied local

registry storage IPsec policy
on the computer.

apply local registry storage
IPsec policy on the
computer.

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.

load local storage IPsec
5473 N/A Low PAStore Engine loaded


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

stopped

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.
L IN K S URL S
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 https://download.microsoft.com/download/7/7/A/77ABC5BD

Credential 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

L IN K S URL S
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).as

px
Hyper-V Security Guide https://www.microsoft.com/download/details.aspx?id=16650
Ask the Directory Services Team https://blogs.technet.com/b/askds/archive/2011/09/12/man

aging-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/

2009_databreach_rp.pdf
2012 Verizon Data Breach report http://www.verizonbusiness.com/resources/reports/rp_data-

Introducing Auditing Changes in Windows 2008 https://blogs.technet.com/b/askds/archive/2007/10/19/intro

ducing-auditing-changes-in-windows-2008.aspx
Cool Auditing Tricks in Vista and 2008 https://blogs.technet.com/b/askds/archive/2007/11/16/cool-

auditing-tricks-in-vista-and-2008.aspx
Global Object Access Auditing is Magic https://blogs.technet.com/b/askds/archive/2011/03/10/glob

al-object-access-auditing-is-magic.aspx
One-Stop Shop for Auditing in Windows Server 2008 and https://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-

L IN K S URL S
Sample script http://www.verizonbusiness.com/resources/reports/rp_data-

Audit Option Type http://www.verizonbusiness.com/resources/reports/rp_data-

Auditing and Compliance in Windows Server 2008 https://technet.microsoft.com/magazine/2008.03.auditing.as

px
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).as

px
MaxTokenSize and Kerberos Token Bloat https://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).as

px
Microsoft Data Classification Toolkit https://technet.microsoft.com/library/hh204743.aspx
Dynamic Access Control https://blogs.technet.com/b/windowsserver/archive/2012/05

/22/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/Emine
ntWare-WSUS-Extension-Pack-005-Datasheet2.pdf
EminentWare Configuration Manager Extension Pack http://solarwinds-

marketing.s3.amazonaws.com/solarwinds/Datasheets/Emine
ntWare-Extension-Pack-for-CM-Datasheet-006-Revised.pdf
GFI Software http://www.gfi.com/?

adv=952&loc=58&gclid=CLq9y5603rMCFal7QgodMFkAyA
L IN K S URL S
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_e13rMCFal7QgodMFkA
yA
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).as

px
Threats and Vulnerabilities Mitigation https://technet.microsoft.com/library/cc755181(v=ws.10).asp

x
User Rights https://technet.microsoft.com/library/dd349804(v=WS.10).as

px
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
L IN K S URL S
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-

delegation 41b1-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
L IN K S URL S
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
L IN K S URL S
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).asp

x
Windows Configurations for Kerberos Supported Encryption /archive/blogs/openspecification/windows-configurations-

Type for-kerberos-supported-encryption-type
UAC Processes and Interactions https://technet.microsoft.com/library/dd835561(v=WS.10).as

px#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%2Fdomai
n_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 https://www.microsoft.com/download/details.aspx?id=35753

Server 2012 Security Event Details
Georgia Tech's Emerging Cyber Threats for 2013 report http://www.gtsecuritysummit.com/report.html

L IN K S URL S
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.ht

Mitigation Strategies m
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 https://www.microsoft.com/download/details.aspx?id=16755

Installations for Windows Server 2003
Best Practices for Delegating Active Directory Administration https://www.microsoft.com/download/details.aspx?id=21678

for Windows Server 2003
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).asp

x
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.
REC O M M EN DED REA DIN G
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

REC O M M EN DED REA DIN G
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 Director y 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 Ser ver Manager , click Tools and then click Active Director y Sites and Ser vices 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 Director y 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 Director y 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 Ser ver
value refers to the server maintaining the table, in this case DC1 . The Par tner 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 Par tner and Ser ver 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.
C M DL ET EXP L A N AT IO N
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

C M DL ET EXP L A N AT IO N
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
EnumerationSer ver :
Get-ADReplicationFailure
Get-ADReplicationPar tnerMetadata
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 Ser ver , Site , Domain , and Forest . The
EnumerationSer ver specifies the server that enumerates the list of domain controllers specified in Target and
Scope . It operates the same as the Ser ver 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 Entr y Attribute , type:
SidCompatibilityVersion
7. In Values , type:
8. Ensure that Add is selected in Operation and click Enter . This updates the Entr y 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 Entr y 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:
Troubleshooting Options
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.
EVEN T ID 16653
Source Directory-Services-SAM
Severity Warning
EVEN T ID 16653
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.
EVEN T 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.
EVEN T 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.
EVEN T ID 16656
EVEN T 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.
more information.
EVEN T 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.
more 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.
EVEN T 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.
more 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.
A B O UT T H E A UT H O R
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
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:
TPM Key Attestation
CA Backup and Restore Windows PowerShell cmdlets
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
F EAT URE C O M M EN T
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
DEC IM A L H EX SY M B O L IC ST RIN G
8467 21C7 ERROR_DS_SPN_VALUE_NO The operation failed

T_UNIQUE_IN_FOREST because SPN value provided
for addition/modification is
not unique forest-wide.
8648 21C8 ERROR_DS_UPN_VALUE_N The operation failed

OT_UNIQUE_IN_FOREST because 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 Ser ver 2012 R2 while
targeting Windows Ser ver 2012 R2 DC
Figure SEQ Figure \* ARABIC 6 DSAC user modification error on non-Windows Ser ver 2012 R2
while targeting Windows Ser ver 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 Conver t 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 ActiveDirector y_DomainSer vice 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 "Tr y This " activities in the module. There is not a separate lab guide for this module.
The Tr y 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 "Tr y This " activities.
There is not a separate lab guide for this module.
The Tr y 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 Tr y 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)
During a Windows Update, there are user specific processes that must happen for the update to be complete.
These processes require the user to be logged in to their device. On the first login after an update has been
initiated, users must wait until these user specific processes are complete before they can start using their
device.
How does it work?

When Windows Update initiates an automatic reboot, ARSO extracts the currently logged in user's derived
credentials, persists it to disk, and configures Autologon for the user. Windows Update running as system with
TCB privilege will initiate the RPC call to do this.
After the final Windows Update reboot, the user will automatically be logged in via the Autologon mechanism,
and the user's session is rehydrated with the persisted secrets. Additionally, the device is locked to protect the
user's session. The locking will be initiated via Winlogon whereas the credential management is done by the
Local Security Authority (LSA). Upon a successful ARSO configuration and login, the saved credentials are
immediately deleted from disk.
By automatically logging in and locking the user on the console, Windows Update can complete the user specific
processes before the user returns to the device. In this way, the user can immediately start using their device.
ARSO treats unmanaged and managed devices differently. For unmanaged devices, device encryption is used
but not required for the user to get ARSO. For managed devices, TPM 2.0, SecureBoot, and BitLocker are
required for ARSO configuration. IT admins can override this requirement via Group Policy. ARSO for managed
devices is currently only available for devices that are joined to Azure Active Directory.
A P IS W IT H
SH UT DO W N _A RSO /
W IN DO W S UP DAT E SH UT DO W N - G - T 0 USER- IN IT IAT ED REB O OT S EW X_A RSO F L A GS
Managed devices - Yes Managed devices - Yes Managed devices - No Managed devices - Yes
Unmanaged devices - Unmanaged devices - Unmanaged devices - Unmanaged devices -
Yes Yes Yes Yes
NOTE
After a Windows Update induced reboot, the last interactive user is automatically logged in and the session is locked. This
gives the ability for a user's lock screen apps to still run despite the Windows Update reboot.
Policy #1
Sign-in and lock last interactive user automatically after a restart
In Windows 10, ARSO is disabled for Server SKUs and opt out for Client SKUs.
Group policy location: Computer Configuration > Administrative Templates > Windows Components >
Windows Logon Options
Intune policy:
Platform: Windows 10 and later
Profile type: Administrative Templates
Path: \Windows Components\Windows Logon Options
Suppor ted on: At least Windows 10 Version 1903
Description:
This policy setting controls whether a device will automatically sign in and lock the last interactive user after the
system restarts or after a shutdown and cold boot.
This only occurs if the last interactive user didn't sign out before the restart or shutdown.
If the device is joined to Active Directory or Azure Active Directory, this policy only applies to Windows Update
restarts. Otherwise, this will apply to both Windows Update restarts and user-initiated restarts and shutdowns.
If you don't configure this policy setting, it is enabled by default. When the policy is enabled, the user is
automatically signed in and the session is automatically locked with all lock screen apps configured for that user
after the device boots.
After enabling this policy, you can configure its settings through the ConfigAutomaticRestartSignOn policy,
which configures the mode of automatically signing in and locking the last interactive user after a restart or cold
boot.
If you disable this policy setting, the device does not configure automatic sign in. The user's lock screen apps are
not restarted after the system restarts.
Registr y editor :
VA L UE N A M E TYPE DATA
DisableAutomaticRestartSignOn DWORD 0 (Enable ARSO)
1 (Disable ARSO)
Policy registr y location: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Type: DWORD
Policy #2
Configure the mode of automatically signing in and locking last interactive user after a restart or cold boot
Group policy location: Computer Configuration > Administrative Templates > Windows Components >
Windows Logon Options
Intune policy:
Platform: Windows 10 and later
Profile type: Administrative Templates
Path: \Windows Components\Windows Logon Options
Suppor ted on: At least Windows 10 Version 1903
Description:
This policy setting controls the configuration under which an automatic restart and sign on and lock occurs after
a restart or cold boot. If you chose “Disabled” in the “Sign-in and lock last interactive user automatically after a
restart” policy, then automatic sign on will not occur and this policy does not need to be configured.
If you enable this policy setting, you can choose one of the following two options:
1. “Enabled if BitLocker is on and not suspended” specifies that automatic sign on and lock will only occur if
BitLocker is active and not suspended during the reboot or shutdown. Personal data can be accessed on the
device's hard drive at this time if BitLocker is not on or suspended during an update. BitLocker suspension
temporarily removes protection for system components and data but may be needed in certain
circumstances to successfully update boot-critical components.
BitLocker is suspended during updates if:
The device doesn't have TPM 2.0 and PCR7, or
The device doesn't use a TPM-only protector
2. “Always Enabled” specifies that automatic sign on will happen even if BitLocker is off or suspended during
reboot or shutdown. When BitLocker is not enabled, personal data is accessible on the hard drive. Automatic
restart and sign on should only be run under this condition if you are confident that the configured device is
in a secure physical location.
If you disable or don't configure this setting, automatic sign on will default to the “Enabled if BitLocker is on and
not suspended” behavior.
Registr y editor
AutomaticRestartSignOnConfig DWORD 0 (Enable ARSO if secure)
1 (Enable ARSO always)
Policy registr y location: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Type: DWORD
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. The status of an Autologon configuration attempt is logged.
Security details
In environments where the device’s physical security is of concern (for example, the device can be stolen),
Microsoft does not recommend using ARSO. ARSO relies on the integrity of the platform firmware and TPM, an
attacker with physical access maybe able to compromise these and as such access the credentials stored on disk
with ARSO enabled.
In enterprise environments where the security for user data protected by Data Protection API (DPAPI) is of
concern, Microsoft does not recommend using ARSO. ARSO negatively impacts user data protected by DPAPI
because decryption doesn't requires user credentials. Enterprises should test the impact on the security of user
data protected by DPAPI before using ARSO.
Credentials stored
PA SSW O RD H A SH C REDEN T IA L K EY T IC K ET - GRA N T IN G T IC K ET P RIM A RY REF RESH TO K EN
Local account - Yes Local account - Yes Local account - No Local account - No
MSA account - Yes MSA account - Yes MSA account - No MSA account - No
Azure AD joined account - Azure AD joined account - Azure AD joined account - Azure AD joined account -
Yes Yes Yes (if hybrid) Yes
Domain joined account - Domain joined account - Domain joined account - Domain joined account -
Yes Yes Yes Yes (if hybrid)
Credential Guard interaction

ARSO is supported with Credential Guard enabled on devices beginning with Windows 10 version 2004.
Additional resources
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
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. 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.
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
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 EKCer t: 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 cer tificate 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 EKCer t: 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 Ser ver 2012 R2 is selected for the Cer tification Authority .
Ensure Windows 8.1 / Windows Ser ver 2012 R2 is selected for the Cer tificate recipient .
2. Cr yptography tab
Ensure Key Storage Provider is selected for the Provider Categor y and RSA is selected for the
Algorithm name . Ensure Requests must use one of the following providers is selected and the
Microsoft Platform Cr ypto 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 cer tificate: 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
O ID K EY AT T ESTAT IO N T Y P E DESC RIP T IO N A SSURA N C E L EVEL
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
O ID K EY AT T ESTAT IO N T Y P E DESC RIP T IO N A SSURA N C E L EVEL
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 cer tificate stores on an issuing CA
If you chose Endorsement Cer tificate 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 registr y entr y: Use the Certutil command-line
tool to configure the folder locations where trusted EKpubs are defined as described in the
following table.
O P ERAT IO N C O M M A N D SY N TA X
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.
EndorsementKeyListDirectories REG_MULTI_SZ <LOCAL or UNC path to EKPUB

allow list(s)>
Example:
\\blueCA.contoso.com\ekpub
\\bluecluster1.contoso.com\e
kpub
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. Cer tification Authority : Windows Ser ver 2012 R2
b. Cer tificate Recipient : Windows 8.1/Windows Ser ver 2012 R2
2. The cryptography settings are not configured correctly. Make sure that they are configured as follows:
a. Provider Categor y : Key Storage Provider
b. Algorithm Name : RSA
c. Providers : Microsoft Platform Cr ypto 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 expor ted option must not be selected.
b. The Archive subject's encr yption 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 EKCer t 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 EKCer t 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 EKCer t 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
CA Backup and Restore Windows PowerShell
cmdlets
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-CARoleSer vice
A RGUM EN T S - B O L D A RGUM EN T S A RE REQ UIRED DESC RIP T IO N
-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 Conver tTo-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 Conver tTo-SecureString
Backup-CARoleService c:\adcsbackup5 -Password (ConvertTo-SecureString "Pa55w0rd!" -AsPlainText -Force)
Restore-CARoleService
ADCSAdministration Cmdlet: Restore-CARoleSer vice

-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
A C T IO N ERRO R C O M M EN T
Restore-CARoleSer vice Restore-CARoleService : The process Stop the Active Directory Certificate
C:\ADCSBackup cannot access the file because it is Services service prior to running the
being used by another process. Restore-CARoleService cmdlet
(Exception from HRESULT:
0x80070020)
Restore-CARoleSer vice Restore-CARoleService : The directory Use the -Force parameter to overwrite
C:\ADCSBackup is not empty. (Exception from preexisting keys
HRESULT: 0x80070091)
Backup-CARoleSer vice 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
Host -Prompt "Password:" - named parameters. is therefore invalid when you are not
AsSecureString) -DatabaseOnly backing them up
Restore-CARoleSer vice 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
Host -Prompt "Password:" - named parameters. is therefore invalid when you are not
AsSecureString) -DatabaseOnly restoring them
Restore-CARoleSer vice 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
Host -Prompt "Password:" - from HRESULT: 0x80070002) path is invalid or the backup was taken
AsSecureString) with 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.
Applies To: Windows Server 2016, Windows Server 2012 R2
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
Suppor ted 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
P O L IC Y C O N F IGURAT IO N DETA IL S
Path Administrative Templates\System\Audit Process Creation
Setting Include command line in process creation events
Default setting Not Configured (not enabled)
Suppor ted 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 Ser ver 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 Ser ver 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 Ser vice .
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
Guidance about 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 Ser ver 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 Ser vices 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
P O L IC Y REQ UIREM EN T S
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
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 suppor t for Dynamic Access Control
1. In the Default Domain Controllers Policy, click Enabled to enable Key Distribution Center (KDC)
client suppor t 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
Suppor ted 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 suppor t 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
Ser vices 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 Director y 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.
Applies To: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
This section includes troubleshooting recommendations and procedures for diagnosing and fixing problems
that may occur during Active Directory replication. It focuses on how to respond to Directory Service event log
entries and how to interpret messages that tools such as Repadmin.exe and Dcdiag.exe might report.
Repadmin.exe and Dcdiag.exe are available on all domain controllers that run Windows Server 2012 R2 or later
versions. For more information about how to use these tools to troubleshoot problems, see the following
articles.
Configuring a Computer for Troubleshooting Active Directory
Troubleshooting Active Directory Replication Problems
Another useful technology is Event Tracing for Windows (ETW). You can use ETW to troubleshoot LDAP
communications among the domain controllers. For more information, see Using ETW to troubleshoot LDAP
connections.
You can also install Remote Server Administration Tools (RSAT) on a member server that is running Windows
10. For information about how to install RSAT, see Remote Server Administration Tools.
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
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_MACHINE\SYSTEM\CurrentControlSet\Ser vices\NTDS\Diagnostics .
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 Star t > 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 .
Using ETW to troubleshoot LDAP connections
Event Tracing for Windows (ETW) can be a valuable troubleshooting tool for Active Directory Domain Services
(AD DS). You can use ETW to trace the Lightweight Directory Access Protocol (LDAP) communications between
Windows clients and LDAP servers, including AD DS domain controllers.
How to turn on ETW and start a trace

To turn on ETW
1. Open Registry Editor, and create the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Ser vices\ldap\Tracing\ ProcessName
In this subkey, ProcessName is the full name of the process that you want to trace, including its extension
(for example, "Svchost.exe").
2. (Optional ) Under this subkey, create a new entry that is named PID . To use this entry, assign a process ID
as a DWORD value.
If you specify a process ID, ETW traces only the instance of the application that has this process ID.
To star t a tracing session
Open a Command Prompt window, and run the following command:
tracelog.exe -start <SessionName> -guid \#099614a5-5dd7-4788-8bc9-e29f43db28fc -f <FileName> -flag

<TraceFlags>
The placeholders in this command represent the following values.

<SessionName> is an arbitrary identifier that is used to label the tracing session.
NOTE
You will have to refer to this session name later when you stop the tracing session.
<FileName> specifies the log file to which events will be written.

<TraceFlags> should be one or more of the values that are listed in the trace flags table.
How to end a tracing session and turn off Event Tracing

To stop tracing
At the command prompt, run the following command:
tracelog.exe -stop <SessionName>
In this command, <SessionName> is the same name that you used in the tracelog.exe -star t
command.
To turn off ETW
In Registry Editor, delete the
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Ser vices\ldap\Tracing\ ProcessName subkey.
Values for trace flags

To use a flag, substitute the flag value for the <TraceFlags> placeholder in the arguments of the tracelog.exe -
star t command.
NOTE
You can specify multiple flags by using the sum of the appropriate flag values. For example, to specify the
DEBUG_SEARCH (0x00000001) and DEBUG_CACHE (0x00000010) flags, the appropriate <TraceFlags> value is
0x00000011 .
FLAG NAME F L A G VA L UE F L A G DESC RIP T IO N
DEBUG_SEARCH 0x00000001 Logs search requests and the

parameters that are passed to those
requests. Responses are not logged
here. Only the search requests are
logged. (Use DEBUG_SPEWSEARCH
to log the responses to search
requests.)
DEBUG_WRITE 0x00000002 Logs write requests and the

parameters that are passed to those
requests. Write requests include the
add, delete, modify, and extended
operations.
DEBUG_REFCNT 0x00000004 Logs reference counting data and

operations for connections and
requests.
DEBUG_HEAP 0x00000008 Logs all memory allocations and

memory releases.
DEBUG_CACHE 0x00000010 Logs cache activity. This activity

includes adds, removes, hits, misses,
and so on.
DEBUG_SSL 0x00000020 Logs SSL information and errors.
DEBUG_SPEWSEARCH 0x00000040 Logs all server responses to search

requests. These responses include the
attributes that were requested, plus all
data that was received.
DEBUG_SERVERDOWN 0x00000080 Logs server-down and connection

errors.
DEBUG_CONNECT 0x00000100 Logs data that is related to

establishing a connection.
Use DEBUG_CONNECTION to log
other data that is related to
connections.
DEBUG_RECONNECT 0x00000200 Logs automatic reconnect activity. This

activity includes reconnect attempts,
failures, and related errors.
DEBUG_RECEIVEDATA 0x00000400 Logs activity that is related to receiving

messages from the server. This activity
includes events such as "waiting on the
response from the server" and the
response that is received from the
server.
DEBUG_BYTES_SENT 0x00000800 Logs all data sent by the LDAP client

to the server. This function is
essentially packet logging, but it
always logs unencrypted data. (If a
packet is sent over SSL, this function
logs the unencrypted packet.) This
logging can be verbose. This flag is
probably best used on its own or
combined with
DEBUG_BYTES_RECEIVED .
DEBUG_EOM 0x00001000 Logs events that are related to

reaching the end of a message list.
These events include information such
as "message list cleared" and so on.
DEBUG_BER 0x00002000 Logs operations and errors that are

related to Basic Encoding Rules (BER).
These operations and errors include
problems in encoding, buffer size
problems, and so on.
DEBUG_OUTMEMORY 0x00004000 Logs failures to allocate memory. Also

logs any failure to compute the
required memory (for example, an
overflow that occurs when computing
the required buffer size).
DEBUG_CONTROLS 0x00008000 Logs data that relates to controls. This

data includes controls that are
inserted, problems that affect controls,
mandatory controls on a connection,
and so on.
DEBUG_BYTES_RECEIVED 0x00010000 Logs all data that is received by the

LDAP client. This behavior is essentially
packet logging, but it always logs
unencrypted data. (If a packet is sent
over SSL, this option logs the
unencrypted packet.) This type of
logging can be verbose. This flag is
probably best used on its own or
combined with DEBUG_BYTES_SENT .
DEBUG_CLDAP 0x00020000 Logs events that are specific to UDP

and connectionless LDAP.
DEBUG_FILTER 0x00040000 Logs events and errors that are

encountered when you construct a
search filter.
Note This option logs client events
only during filter construction. It does
not log any responses from the server
about a filter.
DEBUG_BIND 0x00080000 Logs bind events and errors. This data

includes negotiation information, bind
success, bind failure, and so on.
DEBUG_NETWORK_ERRORS 0x00100000 Logs general network errors. This data

includes send and receive errors.
Note If a connection is lost or the
server cannot be reached,
DEBUG_SERVERDOWN is the
preferred tag.
DEBUG_VERBOSE 0x00200000 Logs general messages. Use this

option for any messages that tend to
generate a large amount of output.
For example, it logs messages such as
"end of message reached," "server has
not responded yet," and so on. This
option is also useful for generic
messages.
DEBUG_PARSE 0x00400000 Logs general message events and

errors plus packet parsing and
encoding events and errors.
DEBUG_REFERRALS 0x00800000 Logs data about referrals and chasing

referrals.
DEBUG_REQUEST 0x01000000 Logs tracking of requests.
DEBUG_CONNECTION 0x02000000 Logs general connection data and

errors.
DEBUG_INIT_TERM 0x04000000 Logs module initialization and cleanup

(DLL Main, and so on).
DEBUG_API_ERRORS 0x08000000 Supports logging incorrect use of the

API. For example, this option logs data
if the bind operation is called two
times on the same connection.
DEBUG_ERRORS 0x10000000 Logs general errors. Most of these

errors can be categorized as module
initialization errors, SSL errors, or
overflow or underflow errors.
DEBUG_PERFORMANCE 0x20000000 Logs data about process-global LDAP

activity statistics after receiving a
server response for an LDAP request.
Example
Consider an application, App1.exe, that sets passwords for user accounts. Suppose that App1.exe produces an
unexpected error. To use ETW to help diagnose this problem, you follow these steps:
1. In Registry Editor, create the following registry entry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Ser vices\ldap\Tracing\App1.exe
2. To start a tracing session, open a Command Prompt window, and run the following command:
tracelog.exe -start ldaptrace -guid \#099614a5-5dd7-4788-8bc9-e29f43db28fc -f .\ldap.etl -flag

0x80000
After this command starts, DEBUG_BIND makes sure that ETW writes tracing messages to .\ldap.etl.
3. Start App1.exe, and reproduce the unexpected error.
4. To stop the tracing session, run the following command at the command prompt:
tracelog.exe -stop ldaptrace
5. To prevent other users from tracing the application, delete the

HKEY_LOCAL_MACHINE \System \CurrentControlSet \Ser vices \ldap \Tracing \App1.exe registry
entry.
6. To review the information in the trace log, run the following command at the command prompt:
tracerpt.exe .\ldap.etl -o -report
NOTE
In this command, tracerpt.exe is a trace consumer tool.
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, download and run the Microsoft Support
and Recovery Assistant tool, or use the Active Directory Replication Status Tool if you only want to analyze the
replication status.
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.
REPA DM IN ERRO R RO OT C A USE SO L UT IO N
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

Neighbors" section of the output that Problems (Event ID 1925)
is 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
with the "Target account name is connectivity, DNS, or authentication Problems (Event IDs 1925, 2087,
incorrect." issues. If this is a DNS error, the local 2088) Fixing Replication Security
domain controller could not resolve Problems Fixing Replication
the globally unique identifier (GUID)- Connectivity Problems (Event ID 1925)
based 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
host contact AD DS. Problems (Event IDs 1925, 2087,
2088)
Active Directory replication has been The progress of inbound replication Wait for replication to complete. This
preempted. was interrupted by a higher-priority informational message indicates
replication request, such as a request normal 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 informational message indicates
an answer. Replication is in progress normal operation.
from 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.
EVEN T ID A N D SO URC E RO OT C A USE SO L UT IO N
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.
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,
replicated to the domain controller. 2042)
1925 NTDS KCC The attempt to establish a replication Fixing Replication Connectivity
link for a writable directory partition Problems (Event ID 1925) Fixing
failed. This event can have different Replication DNS Lookup Problems
causes, depending on the error. (Event IDs 1925, 2087, 2088)
1988 NTDS Replication The local domain controller has Fixing Replication Lingering Object
attempted to replicate an object from Problems (Event IDs 1388, 1988,
a source domain controller that is not 2042)
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,
replication cannot proceed. 2042)
2087 NTDS Replication AD DS could not resolve the DNS host Fixing Replication DNS Lookup
name of the source domain controller Problems (Event IDs 1925, 2087,
to an IP address, and replication failed. 2088)
2088 NTDS Replication AD DS could not resolve the DNS host Fixing Replication DNS Lookup
name of the source domain controller Problems (Event IDs 1925, 2087,
to an IP address, but replication 2088)
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 Technical Reference
AD FS Overview
Active Directory Federation Service (AD FS) enables Federated Identity and Access Management by securely
sharing digital identity and entitlements rights across security and enterprise boundaries. AD FS extends the
ability to use single sign-on functionality that is available within a single security or enterprise boundary to
Internet-facing applications to enable customers, partners, and suppliers a streamlined user experience while
accessing the web-based applications of an organization.
This document contains a list of all of the documentation overviews for AD FS for Windows Server. This includes
the following:
What's New in AD FS for Windows Server 2019
AD FS Requirements
AD FS FAQ
What's new in Active Directory Federation Services
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 Primar y - 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 external 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 Risk Assessment Module - 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. For more
information see Build Plug-ins with AD FS 2019 Risk Assessment Model
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 PowerShell (PSH) using Smar tCard 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.
For more information see Customize HTTP security response headers with AD FS 2019
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 suppor t - 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.
Support 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 suppor t - 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 (PowerShell)
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.
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.
How to choose additional auth providers in 2019
ADFS already supports triggering additional authentication based on claim rule policy. Those policies can be set
on a particular RP or at global level. Additional auth policy for a particular RP could be set using the cmdlet Set-
AdfsRelyingPartyTrust (ADFS) | Microsoft Docs by passing either AdditionalAuthenticationRules or
AdditionalAuthenticationRulesFile parameter. To set it globally admin can use the cmdlet Set-
AdfsAdditionalAuthenticationRule (ADFS) | Microsoft Docs.
For example, 2012 R2 onwards admin can already write the following rule to prompt additional authentication if
the request comes from extranet.
Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules '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" );'
In 2019, customers can now use claims rules to decide which additional authentication provider to invoke for
additional authentication. This is useful for 2 scenarios:
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 a need for a specific additional authentication provider (e.g. certificate) for certain applications
but different method (AzureMFA) for other applications.
This could be achieved by issuing the claim https://schemas.microsoft.com/claims/authnmethodsproviders from
additional authentication policies. The value of this claim should be the Name of the authentication provider.
Now in 2019 they can modify above claim rule to choose auth providers based on their scenarios.
Transitioning from one additional authentication provider to another: We will modify the above rule to choose
AzureMFA for users which are in group SID S-1-5-21-608905689-872870963-3921916988-12345 (say a
group managed by enterprise which tracks the users which has registered for AzureMFA) and for rest of the
users, admin wants to use certificate auth.
'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] =>

issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value =
"https://schemas.microsoft.com/claims/multipleauthn" );
c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-

608905689-872870963-3921916988-12345"] => issue(Type =
"https://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");
not exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-

608905689-872870963-3921916988-12345"]) => issue(Type =
"https://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");’
Example to set 2 different auth providers for 2 different applications.

Application A to use Azure MFA as additional auth provider:
Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules '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" );
c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value =

"AzureMfaAuthentication");'
Application B to use Certificate as additional auth provider:
Set- Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type ==

"http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type =
"http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value =
"http://schemas.microsoft.com/claims/multipleauthn" );
c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value =

"CertificateAuthentication");'
Admin can also make rules to allow more than one additional authentication provider in which case ADFS will
show all the issued auth methods providers and user can choose any of them. For allowing multiple additional
authentication provider they should issue multiple claim
https://schemas.microsoft.com/claims/authnmethodsproviders
If none of the auth providers are returned by the claim evaluation, ADFS will fall back to show all the additional
auth providers configured by Admin on ADFS and user will need to select the appropriate auth provider.
To get all the additional authentication providers allowed, admin can use the cmdlet (Get-
AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider. The value of
https://schemas.microsoft.com/claims/authnmethodsproviders claim should be one of the provider names
returned by above cmdlet.
There is no support to trigger particular additional auth provider if the RP is using Access Control Policies in AD
FS Windows Server 2016 | Microsoft Docs. While moving an Application away from Access control policy, ADFS
copies the corresponding policy from Access Control Policy to AdditionalAuthenticationRules and
IssuanceAuthorizationRules. So if an admin wants to use particular auth provider, they can moves away from
not using access control policy and then modify AdditionalAuthenticationRules to trigger particular additional
auth provider.
FAQ
NOTE
You may encounter this error in ADFS Admin event logs: Received invalid Oauth request. The client 'NAME' is forbidden to
access the resource with scope 'ugs'. To remediate this error:
1. Launch AD FS management console. Browse to "Services > Scope Descriptions"
2. Right click "Scope Descriptions" and select "Add Scope Description"
3. Under name type "ugs" and Click Apply > OK
4. Launch PowerShell as Administrator
5. Execute the command "Get-AdfsApplicationPermission". Look for the ScopeNames :{openid, aza} that has the
ClientRoleIdentifier. Make a note of the ObjectIdentifier.
6. Execute the command "Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'
7. Restart the ADFS service.
8. On the client: Restart the client. User should be prompted to provision WHFB.
9. If the provisioning window does not pop up then need to collect NGC trace logs and further troubleshoot.
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 < create a valid sample request>
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
Configure AD FS 2016 and Azure MFA
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
NOTE
Currently, Google Chrome and the new Microsoft Edge built on Chromium open source project browsers are not
supported for browser based single-sign on (SSO) with Microsoft Windows Hello for Business. Please use Internet Explorer
or an older version of Microsoft Edge.
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 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 certificate must be the same (use the same key) as the federation server SSL certificate
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:
H A RDWA RE REQ UIREM EN T M IN IM UM REQ UIREM EN T REC O M M EN DED REQ UIREM EN T
RAM 2 GB 4 GB
Disk space 32 GB 100 GB
SQL Ser ver 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).
Ser vice 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.
The User Rights Assignment required for the AD service account is 'Log on as a Service'
The User Rights Assignments required for the 'NT Service\adfssrv' and 'NT Service\drs' are 'Generate
Security Audits' and 'Log on as a Service'.
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.
AD FS farm first node installation depends on having the PDC available.
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 RP T RUST S M O RE T H A N 100 RP T RUST S
1-30 AD FS Nodes: WID supported 1-30 AD FS Nodes: Not supported using WID - SQL
Required
More than 30 AD FS Nodes: Not supported using WID - More than 30 AD FS Nodes: Not supported using WID -
SQL Required SQL Required
SQL Ser ver

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 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 Overview
AD FS Design Guide in Windows Server
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.
SUP P O RT ED B Y SQ L
DESC RIP T IO N F EAT URE SUP P O RT ED B Y W ID? 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).
SUP P O RT ED B Y SQ L
DESC RIP T IO N F EAT URE SUP P O RT ED B Y W ID? 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 ser vers 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
Legacy AD FS Federation Server Farm Using WID
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.
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
Plan Your AD FS Deployment Topology AD FS Design Guide in Windows Server 2012 R2
Legacy AD FS Federation Server Farm Using WID
and Proxies
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
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
Required
More than 30 AD FS Nodes: Not supported using More than 30 AD FS Nodes: Not supported using
WID - SQL Required WID - SQL 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
Legacy AD FS Federation Server Farm Using SQL
Server
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).
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:
Required

Over view
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
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 Ser ver 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
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 for Windows Server
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 ser ver cer tificates
C ERT IF IC AT E T Y P E REQ UIREM EN T S, SUP P O RT & T H IN GS TO K N O W

Secure Sockets Layer (SSL) cer tificate: This is a - This certificate must be a publicly trusted* X509 v3
standard SSL certificate that is used for securing certificate.
communications 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.
- Impor tant: 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.
Ser vice communication cer tificate: This certificate - By default, the SSL certificate is used as the service
enables WCF message security for securing communications communications certificate. But you also have the option to
between federation servers. configure another certificate as the service communication
certificate.
- Impor tant: 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 cer tificate: This is a standard X509 - By default, AD FS creates a self-signed certificate with 2048
certificate that is used for securely signing all tokens that the bit keys.
federation 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-decr yption/encr yption cer tificate: This is a - By default, AD FS creates a self-signed certificate with 2048
standard X509 certificate that is used to decrypt/encrypt bit keys.
any incoming tokens. It is also published in federation - CA issued certificates are also supported and can be
metadata. 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 cer tificates for token
decr yption.
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 cer tificates are used for
token decr yption, AD FS does not perform
automatic cer tificate 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:
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.
NOTE
AD FS requires a full writable Domain Controller to function as opposed to a Read-Only Domain Controller. If a planned
topology includes a Read-Only Domain controller, the Read-Only domain controller can be used for authentication but
LDAP claims processing will require a connection to the writable domain controller.
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 Windows Server 2012 R2.
Ser vice account requirements
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.
Required
SQL Ser ver

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:
B RO W SERS P L AT F O RM S
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).
NOTE
Also make sure that port 49443 is not used by any other services on the AD FS and Web Application Proxy server.
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 Ser ver 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 (Primar y 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
Windows Integrated Authentication.
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:
P ROTO C O L S/ A P P L IC AT IO N S/ C O M M EN
A L GO RIT H M K EY L EN GT H S TS
TripleDES – Default 192 (Supported >= 192 Supported algorithm for Decrypting
192 – 256) - the security token. Encrypting the
http://www.w3.org/2001/04/xmlenc#tr security token with this algorithm is
ipledes-cbc not supported.
AES128 - 128 Supported algorithm for Decrypting

http://www.w3.org/2001/04/xmlenc#a the security token. Encrypting the
es128-cbc security token with this algorithm is
not supported.
AES192 - 192 Supported algorithm for Decrypting

http://www.w3.org/2001/04/xmlenc#a the security token. Encrypting the
es192-cbc security token with this algorithm is
not supported.
P ROTO C O L S/ A P P L IC AT IO N S/ C O M M EN
A L GO RIT H M K EY L EN GT H S TS
AES256 - 256 Default . Supported algorithm for

http://www.w3.org/2001/04/xmlenc#a Encrypting the security token.
es256-cbc
TripleDESKeyWrap - All Key sizes supported by .NET 4.0+ Supported algorithm for Encrypting
http://www.w3.org/2001/04/xmlenc#k the symmetric key that encrypts a
w-tripledes security token.
AES128KeyWrap - 128 Supported algorithm for Encrypting

http://www.w3.org/2001/04/xmlenc#k the symmetric key that encrypts the
w-aes128 security token.


RsaV15KeyWrap - 1024 Supported algorithm for Encrypting

http://www.w3.org/2001/04/xmlenc#rs the symmetric key that encrypts the
a-1_5 security token.
RsaOaepKeyWrap - 1024 Default. Supported algorithm for

http://www.w3.org/2001/04/xmlenc#rs Encrypting the symmetric key that
a-oaep-mgf1p encrypts the security token.
SHA1-http://www.w3.org/PICS/DSig/S N/A Used by AD FS Server in artifact

HA1_1_0.html SourceId generation: In this scenario,
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

http://www.w3.org/PICS/DSig/RSA validates the signature of SAML
-SHA1_1_0.html AuthenticationRequest, sign the
artifact 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
AD FS Legacy Design Guide in Windows Server
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
Mapping Your Deployment Goals to an 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. 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.
TA SK REF EREN C E L IN K S
Evaluate predefined AD FS deployment goals that are - Provide Your Active Directory Users Access to Your Claims-
provided in this section of the guide, and combine one or Aware Applications and Services
more goals to 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 Director y Domain Ser vices (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 par tner federation ser ver : 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
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 par tner federation ser ver 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 Claims-Aware Applications and Services
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 Director y Domain Ser vices (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 Resolution Requirements for Federation Servers.
Resource par tner federation ser ver : 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 ser ver : 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
Mapping Your Deployment Goals to an AD FS
Design
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.
A D F S DEP LO Y M EN T GO A L W EB SSO DESIGN F EDERAT ED W EB 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.
REC O M M EN DED TA SK DESC RIP T IO N REF EREN C E
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 replication methods that can be used Database
in 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
SUP P O RT ED B Y SQ L M O RE IN F O RM AT IO N
F EAT URE SUP P O RT ED B Y W ID? SERVER? A B O UT T H IS F EAT URE
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 Best Practices for
Online Services, Microsoft Secure Planning and
Office 365, Microsoft Deployment of AD FS
Exchange, or Microsoft
Office SharePoint 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
SUP P O RT ED B Y SQ L M O RE IN F O RM AT IO N
F EAT URE SUP P O RT ED B Y W ID? SERVER? A B O UT T H IS F EAT URE
Basic database redundancy Yes No The Role of the AD FS

using pull replication, where Configuration Database
one or more servers
source server that hosts a
database
Database redundancy using No Yes The Role of the AD FS

high-availability solutions, Configuration Database
such as failover clustering High Availability
or mirroring (at the Solutions Overview
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 ser vers 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
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.
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).
federation server proxies, see either Name Resolution Requirements for Federation Servers or Name Resolution
Requirements for Federation Server Proxies.
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:
Secure AD FS as a "Tier 0" system
AD FS is, fundamentally, an authentication system. Thus, it should be treated as a "Tier 0" system like
other identity system on your network. Microsoft Docs has more information on the Active Directory
administrative tier model.
Use the Security Configuration Wizard to apply AD FS-specific security best practices to
federation ser vers and federation ser ver 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.
A D F S C O N F IGURAT IO N DATA B A SE T Y P E T H E F O L LO W IN G C O M M A N D
A D F S SERVER RO L E USED AT A C O M M A N D P RO M P T :
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 ver y impor tant 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 encr yption, especially if you are using suppor ting SAML ar tifact 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
Encr yption 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-RelyingPar tyTrust cmdlets. To set a certificate for the Federation Service
to use when decrypting tokens, use the Set-ADFSCer tificate 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-RelyingPar tyTrust 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-ADFSProper ties cmdlet. Possible values for this setting and the level of security that the values
provide are described in the following table.
PA RA M ET ER VA L UE SEC URIT Y L EVEL P ROT EC T IO N SET T IN G
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 Smar t 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
(https://go.microsoft.com/fwlink/?LinkID=139831).
Always deploy SQL Ser ver 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 Ser ver under a ser vice account instead of using the built-in default system ser vice
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 Ser ver.
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.
N A M E ID F O RM AT C O RRESP O N DIN G 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 par tner discover y : 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
Where to Place a Federation Server
As a security best practice, place Active Directory Federation Services (AD FS)federation servers behind 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 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. 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 ser ver 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.
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.
C ERT IF IC AT E T Y P E DESC RIP T IO N
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.
C ERT IF IC AT E T Y P E DESC RIP T IO N
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-signing 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.
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.
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 Requirements for Federation Server Proxies.
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 ser vers and federation ser ver 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 ser vers, and federation ser ver 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.
Point all proxies in the farm to the same AD FS Federation When you create the federation server proxies, you must
Service name type 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
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
Checklist: Setting Up a Federation Server Proxy.
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 Ser vice , click Edit Federation Ser vice Proper ties , and then find the value in Federation Ser vice
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 software requirements necessary for Requirements
and federation server proxies deploying federation server and
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 AD FS Deployment Topology
configuration database type you will Considerations
deploy, either Windows Internal
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
Understand key AD FS–related Review the definitions of common See the section titled AD FS capacity
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.
P REREQ UISIT E TA SK DESC RIP T IO N REF EREN C E
Download the AD FS Capacity The AD FS Capacity Planning Sizing AD FS Capacity Planning Spreadsheet
Planning 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 This user data you collect will be used Estimate the number of federation
users who will require single sign-on for the input values required within the servers for your organization
(SSO) access to the target claims- context of the AD FS Capacity Planning
aware application and the expected Sizing Spreadsheet.
peak 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.
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.
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
ser vers 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 ser vers 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 Understanding Key AD FS Concepts.
The following minimum and recommended hardware requirements apply to the federation server and
federation server proxy computers.
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.
W H AT Y O U N EED TO K N O W B EF O RE
C ERT IF IC AT E T Y P E DESC RIP T IO N DEP LO Y IN G
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 Default Web Site in Internet
securing communications between Information Services (IIS) for a
federation servers and clients. Federation Server or a 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 The token-signing certificate must
is used for securely signing all tokens contain a private key, and it should
that 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.
Server authentication certificate This is a standard Secure Sockets Layer This certificate must be bound to the
(SSL) certificate that is used for Default Web Site in Internet
securing communications between a Information Services (IIS) before you
federation server proxy and Internet can run the AD FS Federation Server
client computers. 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
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.
B RO W SER W IN DO W S 7 W IN DO W S 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 Resolution Requirements for Federation Servers.
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.
Service account requirements
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 Deployment
This document contains a list of all of the documentation for deploying AD FS for Windows Server 2016. This
includes the following:
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
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
Upgrading to AD FS in Windows Server 2016 using a SQL database
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, 2016, and 2019. 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.
NOTE
AD FS requires a full writable Domain Controller to function as opposed to a Read-Only Domain Controller. If a planned
topology includes a Read-Only Domain controller, the Read-Only domain controller can be used for authentication but
LDAP claims processing will require a connection to the writable domain controller.
Hardening your AD FS servers

The following is a list of best practices and recommendations for hardening and securing your AD FS
deployment.
Ensure only Active Directory Admins and AD FS Admins have admin rights to the AD FS system.
Reduce local Administrators group membership on all AD FS servers.
Require all cloud admins use Multi-Factor Authentication (MFA).
Minimal administration capability via agents.
Limit access on-network via host firewall.
Ensure AD FS Admins use Admin Workstations to protect their credentials.
Place AD FS server computer objects in a top-level OU that doesn’t also host other servers.
All GPOs that apply to AD FS servers should only apply to them and not other servers as well. This limits
potential privilege escalation through GPO modification.
Ensure the installed certificates are protected against theft (don’t store these on a share on the network) and
set a calendar reminder to ensure they get renewed before expiring (expired certificate breaks federation
auth). Additionally, we recommend protecting signing keys/certificates in a hardware security module (HSM)
attached to AD FS.
Set logging to the highest level and send the AD FS (& security) logs to a SIEM to correlate with AD
authentication as well as AzureAD (or similar).
Remove unnecessary protocols & Windows features
Use a long (>25 characters), complex password for the AD FS service account. We recommend using a
Group Managed Service Account (gMSA) as the service account, as it removes the need for managing the
service account password over time by managing it automatically.
Update to the latest AD FS version for security and logging improvements (as always, test first).
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.
NOTE
Port 808 (Windows Server 2012R2) or port 1501 (Windows Server 2016+) is the Net.TCP port AD FS uses for the local
WCF endpoint to transfer configuration data to the service process and PowerShell. This port can be seen by running Get-
AdfsProperties | select NetTcpPort. This is a local port that will not need to be opened in the firewall but will be displayed
in a port scan.
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.
P ROTO C O L P O RT S DESC RIP T IO N
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:
EN DP O IN T P URP O SE
/adfs/ls Browser based authentication flows and current versions of

Microsoft Office use this endpoint for Azure AD and Office
365 authentication
EN DP O IN T P URP O SE
/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
\adfs\ls 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
\adfs\ls endpoint.
/adfs/ls/federationmetadata/2007- Requirement for any passive flows; and used by Office 365 /
06/federationmetadata.xml Azure AD to check AD FS certificates.
AD FS endpoints can be disabled on the proxy using the following PowerShell cmdlet:
Set-AdfsEndpoint -TargetAddressPath <address path> -Proxy $false
For example:
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 cmdlet.
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
<congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" /> .
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.
Best practice for securing and monitoring the AD FS trust with Azure
AD
When you federate your AD FS with Azure AD, it is critical that the federation configuration (trust relationship
configured between AD FS and Azure AD) is monitored closely, and any unusual or suspicious activity is
captured. To do so, we recommend setting up alerts and getting notified whenever any changes are made to the
federation configuration. To learn how to setup alerts, see Monitor changes to federation configuration.
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):
Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow (
new-timespan -Minutes 30 )
For reference, the public documentation of this feature is here.

Disable WS -Trust Windows endpoints on the proxy i.e. from extranet
WS-Trust Windows endpoints (/adfs/services/trust/2005/windowstransport and
/adfs/services/trust/13/windowstransport) are meant only to be intranet facing endpoints that use WIA binding
on HTTPS. Exposing them to extranet could allow requests against these endpoints to bypass lockout
protections. These endpoints should be disabled on the proxy (i.e. disabled from extranet) to protect AD account
lockout by using following PowerShell commands. There is no known end user impact by disabling these
endpoints on the proxy.
Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/2005/windowstransport -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/windowstransport -Proxy $false
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, we recommend protecting these keys in a hardware security module (HSM) 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:
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

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 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.
A DD W O RK O R SC H O O L W IN DO W S 10 DO M A IN
DESC RIP T IO N A C C O UN T A Z URE A D JO IN JO IN
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
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.
A DD W O RK O R SC H O O L W IN DO W S 10 DO M A IN
DESC RIP T IO N A C C O UN T A Z URE A D JO IN JO IN
How devices are managed MDM Policies (with MDM Policies (with Group Policy, Configuration
additional Intune additional Intune Manager
enrollment) enrollment)
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)
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 # DESC RIP T IO N DAT E REL EA SED
4534271 Addresses a potential AD FS chrome January 2020

failure due to support of new SameSite
cookie policies by default for release 80
of Google Chrome. For more
information, please refer here.
CVE-2019-1126 This security update addresses a July 2019

vulnerability in Active Directory
Federation Services (AD FS) which
could allow an attacker to bypass the
extranet lockout policy.
4489889 (OS Build 14393.2879) Addresses an issue in Active Directory March 2019
Federation Services (AD FS) that
causes a duplicate relying party trust
to appear in the AD FS management
console. This occurs when you create
or view relying party trusts using the
AD FS management console.
Addresses a high Active Directory
Federation Services (ADFS) Web
Application Proxy (WAP) latency issue
(over 10,000ms) that occurs while
Extranet Smart Lockout (ESL) is
enabled on AD FS 2016. This security
update addresses the vulnerability
described in CVE-2018-16794.
4487006 (OS Build 14393.2828) Addresses an issue that causes February 2019
updates to a relying party trust to fail
when using PowerShell or the Active
Directory Federation Services (AD FS)
management console. This issue occurs
if you configure a relying party trust to
use an online metadata URL that
publishes more than one
PassiveRequestorEndpoint. The error is,
"MSIS7615: The trusted endpoints
specified in a relying party trust must
be unique for that relying party trust."
Addresses an issue that displays a
specific error message for external
complexity password changes because
of Azure Password Protection policies.
4462928 (OS Build 14393.2580) Addresses interoperation issues October 2018

between Active Directory Federation
Services (ADFS) Extranet Smart
Lockout (ESL) and Alternate Login ID.
When Alternate Login ID is enabled,
calls to AD FS Powershell cmdlets, Get-
AdfsAccountActivity and Reset-
AdfsAccountLockout, return "Account
not found" errors. When Set-
AdfsAccountActivity is called, a new
entry is added instead of editing an
existing one.
4343884 (OS Build 14393.2457) Addresses an Active Directory August 2018

Federation Services (AD FS) issue
where Multi-Factor Authentication
does not work correctly with mobile
devices that use custom culture
definitions.
Addresses an issue in Windows Hello
for Business that causes a significant
delay (15 seconds) in new user
enrollment. This issue occurs when a
hardware security module is used to
store an ADFS Registration Authority
(RA) certificate.
4338822 (OS Build 14393.2395) Addresses an issue in AD FS that July 2018

shows a duplicate Relying Party trust in
the AD FS management console when
creating or viewing Relying Party Trusts
from the console.
Addresses an issue in ADFS that
causes Windows Hello for Business to
fail. The issue occurs when there are
two claim providers. PIN registration
will fail with, "400 Internal Server Error:
Unable to obtain device identifier."
Addresses a WAP issue related to

inactive connections that never end.
This leads to system resource leaks
(e.g., a memory leak) and to a WAP
service that is no longer responsive.
Addresses an AD FS issue that
prevents users from selecting a
different login option. This occurs
when users choose to log in using
Certificate Based Authentication, but it
has not been configured. This also
occurs if users select Certificate Based
Authentication and then try to select
another login option. If this happens,
users will be redirected to the
Certificate Based Authentication page
until they close the browser.
4103720 (OS Build 14393.2273) Addresses an issue with ADFS that May 2018
causes an IdP-initiated login to a
SAML relying party to fail when
PreventTokenReplays is enabled.
Addresses an ADFS issue that occurs
when OAUTH authenticates from a
device or browser application. A user
password change generates a failure
and requires the user to exit the app
or browser to log in.
Addresses an issue where enabling

Extranet Smart Lockout in UTC +1 and
higher (Europe and Asia) did not work.
Additionally, it causes normal Extranet
Lockout to fail with the following error:
Get-AdfsAccountActivity: DateTime
values that are greater than
DateTime.MaxValue or smaller than
DateTime.MinValue when converted to
UTC cannot be serialized to JSON.
Addresses an ADFS Windows Hello for

business issue in which new users are
not able to provision their PIN. This
occurs when no MFA provider is
configured.
4093120 (OS Build 14393.2214) Addresses an unhandled refresh token April 2018
validation issue. It generates the
following error:
"Microsoft.IdentityServer.Web.Protocol
s.OAuth.Exceptions.OAuthInvalidRefres
hTokenException: MSIS9312: Received
invalid OAuth refresh token. The
refresh token was received earlier than
the permitted time in the token."
4077525 (OS Build 14393.2097) Addresses issue where an HTTP 500 February 2018
error occurs when an ADFS farm has at
least two servers using Windows
Internal Database (WID). In this
scenario, HTTP basic pre-
authentication on the Web Application
Proxy (WAP) server fails to
authenticate some users. When the
error occurs, you might also see the
Microsoft Windows Web Application
Proxy warning Event ID 13039 in the
WAP event log. The description reads,
"Web Application Proxy failed to
authenticate the user. Pre-
authentication is 'ADFS For Rich
Clients'. The given user is not
authorized to access the given relying
party. The authorization rules of either
the target relying party or the WAP
relying party are needed to be
modified."
Addresses issue in which AD FS can no
longer ignore prompt=login during
authentication. A Disabled option was
added to support scenarios in which
password authentication is not used.
For more information, see AD FS
ignores the "prompt=login" parameter
during an authentication in Windows
Server 2016 RTM.
Addresses issue in AD FS where

Authorized Customers (and relying
parties) who select Certificate as an
authentication option will fail to
connect. The failure occurs when using
prompt=login if Windows Integrated
Authentication (WIA) is enabled and
the request can do WIA.
Addresses issue where AD FS

incorrectly displays the Home Realm
Discovery (HRD) page when an
identity provider (IDP) is associated
with a relying party (RP) in an OAuth
Group. Unless multiple IDPs are
associated with the RP in the OAuth
Group, the user will not be shown the
HRD page. Instead, the user will go
directly to the associated IDP for
authentication.
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 July 2017
PkeyAuth 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 January 2017

Server 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.
4534309 Addresses a potential AD FS chrome January 2020

failure due to support of new SameSite
cookie policies by default for release 80
of Google Chrome. For more
information, please refer here.
4507448 This security update addresses a July 2019

vulnerability in Active Directory
Federation Services (AD FS) which
could allow an attacker to bypass the
extranet lockout policy.
4041685 Addressed an AD FS issue where October 2017 Preview of Update

MSISConext cookies in request Rollup
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 May 2017 Preview Update Rollup
broker 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 March 2017 Update Rollup

resolves 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, July 2016 Update Rollup

fixed issue with the AD FS
management console and
AlwaysRequireAuthentication setting.
3163306 Active Directory Federation Services June 2016 Update Rollup

(AD 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 Windows Server 2012 R2
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 July 2015

MFA adapter throws an exception in
3075610 Trust relationships are lost on July 2015

secondary 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 May 2015

ID 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 January 2015

in Windows Server 2012 R2
3025080 Operation fails when you try to save January 2015

an 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 # DESC RIP T IO N DAT E REL EA SED A P P L IES TO :

3197878 Authentication through November 2016 Quality AD FS 2.1

proxy fails in Windows Rollup
Server 2012 (this is the
general release of hotfix
3094446)
3197869 Authentication through November 2016 Quality AD FS 2.0

proxy fails in Windows Rollup
Server 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 May 2014 AD FS 2.1

AD 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
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 March 2013 AD FS 2.0

Rollup 3 for Active Directory
Federation Services (AD FS)
2.0
Creating an AD FS Farm without domain admin
privileges
Applies To: Windows Server 2019 and 2016
Overview
Starting with AD FS in Windows Server 2016, you can run the cmdlet Install-AdfsFarm as a local administrator
on your federation server, provided your Domain Administrator has prepared Active Directory. The script below
in this article can be used to prepare AD. The steps are as follows:
1. As Domain Administrator, run the script (or create the Active Directory objects and permissions manually).
2. The script will return an AdminConfiguration object containing the DN of the newly created AD object
3. On the federation server, execute the Install-AdfsFarm cmdlet while logged on as a local administrator,
passing the object from #2 above as the AdminConfiguration parameter
Assumptions
Contoso\localadmin is a non-Domain Admin builtin admin on the federation server
Contoso\FsSvcAcct is a domain account that will be the AD FS service account
Contoso\FsGmsaAcct$ is a gMSA account that will be the AD FS service account
$svcCred is the credentials of the AD FS service account
$localAdminCred is the credentials of the local (non DA) admin account on the federation server
Using a domain account as AD FS Service Account

Prepare AD
Run the following as domain administrator
PS:\>$adminConfig=(.\New-AdfsDkmContainer.ps1 -ServiceAccount contoso\fssvcacct -AdfsAdministratorAccount

contoso\localadmin)
Sample Output
$adminconfig.DkmContainerDN
CN=9530440c-bc84-4fe6-a3f9-8d60162a7bcf,CN=ADFS,CN=Microsoft,CN=Program Data,DC=contoso,DC=com
Create the AD FS Farm

On the federation server as a local admin, execute the following in an elevated PowerShell command window.
First, if the federation server admin is not using the same PowerShell session as the above domain admin, re-
create the adminConfig object using the output from the above.
PS:\>$adminConfig = @{"DKMContainerDn"="CN=9530440c-bc84-4fe6-a3f9-
8d60162a7bcf,CN=ADFS,CN=Microsoft,CN=Program Data,DC=contoso,DC=com"}
Next, create the farm:
PS:\>$svcCred = (get-credential)
PS:\>$localAdminCred = (get-credential)
PS:\>Install-AdfsFarm -CertificateThumbprint 270D041785C579D75C1C981DA0F9C36ECFDB65E0 -FederationServiceName
"fs.contoso.com" -ServiceAccountCredential $svcCred -Credential $localAdminCred -OverwriteConfiguration -
AdminConfiguration $adminConfig -Verbose
Using a gMSA as the AD FS Service Account

Prepare AD
PS:\>$adminConfig=(.\New-AdfsDkmContainer.ps1 -ServiceAccount contoso\FsGmsaAcct$ -AdfsAdministratorAccount

contoso\localadmin)
Sample Output
$adminconfig.DkmContainerDN
CN=8065f653-af9d-42ff-aec8-56e02be4d5f3,CN=ADFS,CN=Microsoft,CN=Program Data,DC=contoso,DC=com
Create the AD FS Farm

On the federation server as a local admin, execute the following in an elevated PowerShell command window.
First, if the federation server admin is not using the same PowerShell session as the above domain admin, re-
create the adminConfig object using the output from the above.
PS:\>$adminConfig = @{"DKMContainerDn"="CN=8065f653-af9d-42ff-aec8-
56e02be4d5f3,CN=ADFS,CN=Microsoft,CN=Program Data,DC=contoso,DC=com"}
Next, create the farm: Note that the local computer account and the ADFS admin account need to be granted
retrieve password and delegate to account rights on the gMSA.
PS:\>$localadminobj = get-aduser "localadmin"

PS:\>$adfsnodecomputeracct = get-adcomputer "contoso_adfs_node"
PS:\>Set-ADServiceAccount -Identity fsgmsaacct -PrincipalsAllowedToRetrieveManagedPassword @(
add=$localadmin.sid.value, $computeracct.sid.value) -PrincipalsAllowedToDelegateToAccount @(
add=$localadmin.sid.value, $computeracct.sid.value)
PS:\>$localAdminCred = (get-credential)
PS:\>Install-AdfsFarm -CertificateThumbprint 270D041785C579D75C1C981DA0F9C36ECFDB65E0 -FederationServiceName
"fs.contoso.com" -Credential $localAdminCred -GroupServiceAccountIdentifier "contoso\fsgmsaacct$" -
OverwriteConfiguration -AdminConfiguration $adminConfig
Script for preparing AD

The following PowerShell script can be used to accomplish the examples above
[CmdletBinding(SupportsShouldProcess=$true)]
param (
[Parameter(Mandatory=$True)]
[string]$ServiceAccount,
[Parameter(Mandatory=$True)]
[string]$AdfsAdministratorAccount
)
$ServiceAccountSplit = $ServiceAccount.Split("\");
if ($ServiceAccountSplit.Length -ne 2)
if ($ServiceAccountSplit.Length -ne 2)
{
Write-error "Specify the ServiceAccount identifier in 'domain\username' format"
exit 1
}
$AdfsAdministratorAccountSplit = $AdfsAdministratorAccount.Split("\");
if ($AdfsAdministratorAccountSplit.Length -ne 2)
{
Write-error "Specify the AdfsAdministratorAccount identifier in 'domain\username' format"
exit 1
}
#######################################
## Verify AD module is installed
#######################################
$m = "ActiveDirectory"
if (Get-Module | Where-Object {$_.Name -eq $m})
{
write-verbose "Module $m is already imported."
}
else
{
if (Get-Module -ListAvailable | Where-Object {$_.Name -eq $m})
{
Import-Module $m -Verbose
}
else
{
write-error "Module $m was not imported, install the Active Directory RSAT package and retry."
exit 1
}
}
push-location ad:
#######################################
## Generate random DKM container name
## The OU Name is a randomly generated Guid
#######################################
[string]$guid = [Guid]::NewGuid()
write-verbose ("OU Name" + $guid)
$ouName = $guid
$initialPath = "CN=Microsoft,CN=Program Data," + (Get-ADDomain).DistinguishedName
$ouPath = "CN=ADFS," + $initialPath
$ou = "CN=" + $ouName + "," + $ouPath
#######################################
## Create DKM container and assign default ACE which allows adfs admin read access
#######################################
if ($pscmdlet.ShouldProcess("$ou", "Creating DKM container and assinging access"))

{
Write-Verbose ("Creating organizational unit with DN: " + $ou)
if ($AdfsAdministratorAccount.EndsWith("$"))
{
write-verbose "ADFS administrator account passed with $ suffix indicating a computer account"
$userNameSplit = $AdfsAdministratorAccount.Split("\");
$strSID = (Get-ADServiceAccount -Identity $userNameSplit[1]).SID
}
else
{
write-verbose "ADFS administrator account is a standard AD user"
$objUser = New-Object System.Security.Principal.NTAccount($AdfsAdministratorAccount)
$strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])
}
if ($null -eq (Get-ADObject -Filter {distinguishedName -eq $ouPath}))

if ($null -eq (Get-ADObject -Filter {distinguishedName -eq $ouPath}))
{
Write-Verbose ("First creating initial path " + $ouPath)
New-ADObject -Name "ADFS" -Type Container -Path $initialPath
}
$acl = get-acl -Path $ouPath

[System.DirectoryServices.ActiveDirectorySecurityInheritance]$adSecInEnum =
[System.DirectoryServices.ActiveDirectorySecurityInheritance]::All
$ace1 = New-Object System.DirectoryServices.ActiveDirectoryAccessRule
$strSID,"GenericRead","Allow",$adSecInEnum
set-acl -Path $ouPath -AclObject $acl
New-ADObject -Name $ouName -Type Container -Path $ouPath

}
#######################################
## Grant the following permission to the service account
# Read
# Create Child
# Write Owner
# Delete Tree
# Write DACL
# Write Property
#######################################
if ($ServiceAccount.EndsWith("$"))
{
write-verbose "service account passed with $ suffix indicating a gMSA"
$userNameSplit = $ServiceAccount.Split("\");
}
else
{
write-verbose "service account is a standard AD user"
$objUser = New-Object System.Security.Principal.NTAccount($ServiceAccount)
}
if ($pscmdlet.ShouldProcess("$strSID", "Granting GenericRead, CreateChild, WriteOwner, DeleteTree, WriteDacl

and WriteProperty"))
{
$strSID,"CreateChild","Allow",$adSecInEnum
$strSID,"WriteOwner","Allow",$adSecInEnum
$strSID,"DeleteTree","Allow",$adSecInEnum
$strSID,"WriteDacl","Allow",$adSecInEnum
$strSID,"WriteProperty","Allow",$adSecInEnum
$acl = get-acl -Path $ou
$acl.SetOwner($strSID)
set-acl -Path $ou -AclObject $acl
}
#######################################
## Grant the following permission to the adfs admin account
# Read
# Create Child
# Write Owner
# Delete Tree
# Write DACL
# Write Property
#######################################
if ($AdfsAdministratorAccount.EndsWith("$"))
{
write-verbose "ADFS administrator account passed with $ suffix indicating a gMSA"
$userNameSplit = $AdfsAdministratorAccount.Split("\");
}
else
{
write-verbose "ADFS administrator account is a standard AD user"
$objUser = New-Object System.Security.Principal.NTAccount($AdfsAdministratorAccount)
}
if ($pscmdlet.ShouldProcess("$strSID", "Granting GenericRead, CreateChild, WriteOwner, DeleteTree, WriteDacl

and WriteProperty"))
{
$strSID,"CreateChild","Allow",$adSecInEnum
$strSID,"WriteOwner","Allow",$adSecInEnum
$strSID,"DeleteTree","Allow",$adSecInEnum
$strSID,"WriteDacl","Allow",$adSecInEnum
$strSID,"WriteProperty","Allow",$adSecInEnum
$acl = get-acl -Path $ou
$acl.SetOwner($strSID)
set-acl -Path $ou -AclObject $acl
$adminConfig = @{"DKMContainerDn"=$ou}
Write-Output $adminConfig
}
pop-location
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 Expor t-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 Ser ver 2008 or later and click Next .
8. On the Ar ticles page select Tables node to select all tables, then un-check SyncProper ties table (this
one should not be replicated)
9. On the Ar ticles page, select User Defined Functions node to select all User Defined Functions and
click Next ..
10. On the Ar ticle 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 Ser ver 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 Histor y 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 AdfsAr tifact 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 ser ver to a federation ser ver farm .
Do NOT select Create the first federation ser ver in a federation ser ver 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: Rober t Hatley with the following credentials: User name: Rober tH 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 Rober t 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 Ser ver Manager on the Windows Star t screen, or
click Ser ver Manager on the Windows taskbar on the Windows desktop. On the Quick Star t 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 ser ver page, click Select a ser ver from the ser ver pool , verify that the
target computer is selected, and then click Next .
6. On the Select ser ver roles page, click Active Director y Federation Ser vices , and then click Next .
8. On the Active Director y Federation Ser vice (AD FS) page, click Next .
9. After you verify the information on the Confirm installation selections page, select the Restar t the
destination ser ver 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 ser vice on the ser ver .
The Active Director y Federation Ser vice Configuration Wizard opens.
2. On the Welcome page, select Create the first federation ser ver in a federation ser ver 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 Ser vice Proper ties 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 Ser vice Account page, select Use an existing domain user account or group
Managed Ser vice 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 ser ver 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 ser vice 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 Ser ver 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 Primar y 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.
EN T RY TYPE A DDRESS
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 For ward 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 Star t 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 .
6. On the Select ser ver roles page, select the check box next to Web Ser ver (IIS) , click Add Features ,
7. On the Select features page, select Windows Identity Foundation 3.5 , and then click Next .
8. On the Web Ser ver Role (IIS) page, click Next .
9. On the Select role ser vices 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, webser v1.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 Ser vices (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://webser v1.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 cer tificate chain validation , and then click Next .
e. Select No encr yption , 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://webser v1.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 Par ty
Trusts , and then click Add Relying Par ty Trust .
2. On the Select Data Source page, select Impor t data about the relying par ty 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://webser v1.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 ,
4. On the Configure Multi-factor Authentication Now? page, select I do not want to specify multi-
factor authentication setting for this relying par ty trust at this time , and then click Next .
5. On the Choose Issuance Authorization Rules page, select Permit all users to access this relying
par ty , and then click Next .
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
NOTE
Only begin an upgrade with a definitive time frame planned for completion. It is not recommended to keep AD FS in a
mixed mode state for an extended period of time, as leaving AD FS in a mixed mode state may cause issues with the farm.
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:
A D F S C O N F IGURAT IO N DATA B A SE
W IN DO W S SERVER VERSIO N FBL 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 to 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 raising
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.
NOTE
If AlwaysOnAvailability groups or merge replication are configured in AD FS, remove all replication of any ADFS databases
prior to upgrade and point all nodes to the Primary SQL database. After performing this, perform the farm upgrade as
documented. After upgrade, add AlwaysOnAvailability groups or merge replication to the new databases.
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
cmdlet:
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 cmdlet:
Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName {FQDN}

6. 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.
7. 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.
8. Now on the Windows Server 2016 Server open PowerShell and run the following cmdlet:
NOTE
All 2012 R2 servers must be removed from the farm before running the next step.
Invoke-AdfsFarmBehaviorLevelRaise
9. When prompted, type Y. This will begin raising the level. Once this completes you have successfully raised the
FBL.
10. Now, if you go to AD FS Management, you will see the new capabilities have been added for the later AD FS
version
11. Likewise, you can use the PowerShell cmdlet: Get-AdfsFarmInformation to show you the current FBL.
12. To upgrade the WAP servers to the latest level, on each Web Application Proxy, re-configure the WAP by
executing the following PowerShell cmdlet in an elevated window:
$trustcred = Get-Credential -Message "Enter Domain Administrator credentials"

Install-WebApplicationProxy -CertificateThumbprint {SSLCert} -fsname fsname -
FederationServiceTrustCredential $trustcred
Remove old servers from the cluster and keep only the WAP servers running the latest server version, which
were reconfigured above, by running the following Powershell cmdlet.
Set-WebApplicationProxyConfiguration -ConnectedServersName WAPServerName1, WAPServerName2
Check the WAP configuration by running the Get-WebApplicationProxyConfiguration cmdlet. The

ConnectedServersName will reflect the server run from the prior command.
Get-WebApplicationProxyConfiguration
NOTE
Skip the next step if the ConfigurationVersion is Windows Server 2016. This is the correct value for Web Application Proxy
on Windows Server 2016 / 2019.
To upgrade the ConfigurationVersion of the WAP servers, run the following Powershell command.
Set-WebApplicationProxyConfiguration -UpgradeConfigurationVersion
This will complete the upgrade of the WAP servers.
NOTE
A known PRT issue exists in AD FS 2019 if Windows Hello for Business with a Hybrid Certificate trust is performed. You
may encounter this error in ADFS Admin event logs: Received invalid Oauth request. The client 'NAME' is forbidden to
access the resource with scope 'ugs'. To remediate this error:
1. Launch AD FS management console. Brose to "Services > Scope Descriptions"
2. Right click "Scope Descriptions" and select "Add Scope Description"
3. Under name type "ugs" and Click Apply > OK
4. Launch Powershell as Administrator
5. Execute the command "Get-AdfsApplicationPermission". Look for the ScopeNames :{openid, aza} that has the
ClientRoleIdentifier. Make a note of the ObjectIdentifier.
6. Execute the command "Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'
7. Restart the ADFS service.
8. On the client: Restart the client. User should be prompted to provision WHFB.
9. If the provisioning window does not pop up then need to collect NGC trace logs and further troubleshoot.
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 Ser vers : 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 Ser ver – 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 vir tual 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
AVA IL A B IL IT Y SET RO L E FA ULT DO M A IN S UP DAT E DO M A IN S
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.
AVA IL A B IL IT Y STO RA GE
M A C H IN E RO L E SUB N ET SET A C C O UN T IP A DDRESS
contosodc1 DC/ADFS INT contosodcset contososac1 Static
contosodc2 DC/ADFS INT contosodcset contososac2 Static

AVA IL A B IL IT Y STO RA GE
M A C H IN E RO L E SUB N ET SET A C C O UN T IP A DDRESS
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.
DO M A IN C O N T RO L L ER RO L E STO RA GE A C C O UN T
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"
Vir tual 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. Por t : 80 (HTTP) d. Path : /adfs/probe e.
Inter val : 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. Por t :
443 d. Backend por t : 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
Using your internal DNS server, create an A record for the ILB. The A record should be for the federation service
with the IP address pointing to the IP address of the ILB. For example, if the ILB IP address is 10.3.0.8 and the
federation service installed is fs.contoso.com, then create an A record for fs.contoso.com pointing to 10.3.0.8.
This will ensure that all data trasmitted to fs.contoso.com end up at the ILB and are appropriately routed.
WARNING
If you are using the WID (Windows Internal Database) for your AD FS database, this value should instead be temporarily
set to point to your primary AD FS server or the Web Application Proxy will fail enrollement. After you have successfully
enrolled all Web Appplication Proxy servers, change this DNS entry to point to the load balancer.
NOTE
If your deployment is also using IPv6, be sure to create a corresponding AAAA record.
7. Configuring the Web Application Proxy server

7.1. Configuring the Web Application Proxy ser vers to reach AD FS ser vers
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).
WARNING
If you are using the WID (Windows Internal Database) for your AD FS database, this value should instead be temporarily
set to point to your primary AD FS server, or the Web Application Proxy will fail enrollement. After you have successfully
enrolled all Web Appplication Proxy servers, change this DNS entry to point to the load balancer.
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)
RUL E DESC RIP T IO N F LO W
AllowHTTPSFromDMZ Allow the HTTPS communication from Inbound

DMZ
DenyInternetOutbound No access to internet Outbound

9.2. Securing the DMZ subnet
RUL E DESC RIP T IO N F LO W
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 X.509 user certificates) is required, then AD FS
requires TCP port 49443 to 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.
PA RA M ET ER DESC RIP T IO N
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 valid ip address within the Internal subnet
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 valid ip address within the Internal subnet
ADFS02NICIPAddress The internal IP address of the second ADFS server, this IP

address will be statically assigned to the ADFS server and
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
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
Vir tual 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 ser vers 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
NOTE
Only begin an upgrade with a definitive time frame planned for completion. It is not recommended to keep AD FS in a
mixed mode state for an extended period of time, as leaving AD FS in a mixed mode state may cause issues with the farm.
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 raising
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 Director y Domain Ser vices 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 Cer tificate screen, specify the certificate and click Next .
6. On the Specify Ser vice 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 Ser ver Selection Screen, click Next .
4. On the Ser ver Roles screen, remove the check next to Active Director y Federation Ser vices 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. Additionally, ensure ADFS service account account has the
administrative permissions on the SQL server and each server in the ADFS farm.
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 cmdlet: Get-AdfsFarmInformation to show you the current FBL.
Upgrade the Configuration Version of existing WAP servers

1. 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
2. Remove old servers from the cluster and keep only the WAP servers running the latest server version, which
were reconfigured above, by running the following PowerShell command.
Set-WebApplicationProxyConfiguration -ConnectedServersName WAPServerName1, WAPServerName2
3. Check the WAP configuration by running the Get-WebApplicationProxyConfiguration commmand. The

ConnectedServersName will reflect the server run from the prior command.
Get-WebApplicationProxyConfiguration
4. To upgrade the ConfigurationVersion of the WAP servers, run the following PowerShell command.
Set-WebApplicationProxyConfiguration -UpgradeConfigurationVersion
5. Verify the ConfigurationVersion has been upgraded with the Get-WebApplicationProxyConfiguration

PowerShell command.
Windows Server 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 Ser ver Farm
TA SK REF EREN C E
Review important concepts and considerations as you AD FS Design Guide in Windows Server 2012 R2
prepare to deploy Active Directory Federation Services Understanding Key AD FS Concepts
(AD FS).
Note: If you decide to use Microsoft SQL Server for your AD

FS configuration store, ensure to deploy a functional
instance of SQL Server
Warning: In Windows Server 2012 R2, 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.
Join your computer to an Active Directory domain. Join a Computer to a Domain
Enroll a Secure Socket Layer (SSL) certificate for AD FS. Enroll an SSL 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 server with Device Configure a federation server with Device Registration
Registration Service (DRS). Service
Add a host (A) and alias (CNAME) resource record to Configure Corporate DNS for the Federation Service and
corporate Domain Name System (DNS) for the federation DRS
service and DRS.
Verify that a federation server is operational. Verify That a Federation Server Is 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 Star t 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
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
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 procedure. Review details about using the appropriate accounts and group memberships at Local and
Domain 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 Ser ver Manager on the Star t screen, or Ser ver
Manager in the taskbar on the desktop. In the Quick Star t 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 .
5. On the Select ser ver roles page, click Active Director y Federation Ser vices , 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.
2. On the Welcome page, select Create the first federation ser ver in a federation ser ver farm , and
then 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 .
4. On the Specify Ser vice Proper ties page, do the following, 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 Impor t , 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 Ser vice 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 Ser vice 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 Ser vice 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
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 ser vice 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 ser ver 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 ser ver 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 <cer tificate_thumbprint> , run dir Cert:\LocalMachine\My , and then
select the thumbprint of your SSL certificate. The value of <federation_ser vice_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
<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
Security=True ".
IMPORTANT
SQL 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 ser ver to a federation ser ver 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 Cer tificate 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 Impor t and
browse to the file's location. Enter the password for the .pfx file when you are prompted.
6. On the Specify Ser vice 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
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 ser vice 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
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
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
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
Security=True ".
IMPORTANT
See Also
AD FS Deployment
Configure a federation server with Device
Registration Service
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:
Initialize-ADDeviceRegistration
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:
Enable-AdfsDeviceRegistration
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.
EN T RY TYPE A DDRESS
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 For ward 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) .
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
federation_ser vice_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/federationser verser vice.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 cer tificate , 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 Star t screen, typeEvent Viewer , and then press ENTER.
3. In the details pane, double-click Applications and Ser vices 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:
The Role of the AD FS Configuration Database
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:
Suppor ted par tners: 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.
Suppor ted application and ser vice 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.
TA SK REF EREN C E
Review important concepts about the Web SSO design and Web SSO Design
determine which AD FS deployment goals you can use to Identifying Your AD FS Deployment Goals
customize this design to meet the needs of your
organization. Note:
Review the hardware, software, certificate, Domain Name Appendix A: Reviewing AD FS Requirements
System (DNS), attribute store, and client requirements for
deploying AD FS in your organization.
According to your design plan, install one or more federation Checklist: Setting Up a Federation Server
servers in the 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 your organization Checklist: Setting Up a Federation Server Proxy
needs a federation server proxy in the perimeter network.
Depending on your Web SSO design plan and how you Checklist: Configuring the Account Partner Organization
intend to use it, add the appropriate attribute store, relying
party trusts, claims, and claim rules to the Federation
Service.
If you are an administrator in the resource partner Windows Identity Foundation

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.
TA SK REF EREN C E
Review important concepts about the Federated Web SSO Federated Web SSO Design
design and determine which AD FS deployment goals you Identifying Your AD FS Deployment Goals
can use to customize this design to meet the needs of your
organization. Planning Your Deployment
Review the hardware, software, certificate, Domain Name Appendix A: Reviewing AD FS Requirements
System (DNS), attribute store, and client requirements for
deploying AD FS in your organization.
Review important concepts about claims, claim rules, Understanding Key AD FS Concepts
attribute stores, and the AD FS configuration database
before deploying AD FS in both partner organizations.
According to your design plan, install one or more federation Checklist: Setting Up a Federation Server
servers in each 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.
(Optional) Determine whether or not your organization Checklist: Setting Up a Federation Server Proxy
needs a federation 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 certificates, configure Checklist: Configuring the Account Partner Organization
clients, and configure the trust relationships in both partner Checklist: Configuring the Resource Partner
organizations so that they can communicate over a Organization
federation trust.
TA SK REF EREN C E
If you are an administrator in the resource partner Windows Identity Foundation

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 partner organization.
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 par tner organization
TA SK REF EREN C E
If you have an existing AD FS 1.0 or 1.1 deployment in your Planning a Migration to AD FS 2.0
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.
Based on your deployment goals, review information about Provide Your Active Directory Users Access to Your
the components that are required to provide users with Claims-Aware Applications and Services
access to the federated applications. Provide Your Active Directory Users Access to the
Provide Users in Another Organization Access to Your
TA SK REF EREN C E
Determine which AD FS design this account partner Web SSO Design

organization will be associated with. Federated Web SSO Design
Before you begin deploying your AD FS servers, review the; Determine Your AD FS Deployment Topology
1.) advantages and disadvantages of choosing either AD FS Deployment Topology Considerations
Windows Internal Database (WID) or SQL Server to store the
AD FS configuration database 2.) AD FS deployment
topology types and their associated server placement and
network layout recommendations.
Review AD FS capacity planning guidance to determine the Planning for AD FS Server Capacity
proper number of federation server and federation server
proxy servers you should use in your production
environment.
To effectively plan and implement the physical topology for Checklist: Setting Up a Federation Server
the account partner deployment, determine whether your Checklist: Setting Up a Federation Server Proxy
AD FS design requires one or more federation servers or
Determine the type of attribute store that you want to add The Role of Attribute Stores
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 consume claims from a Planning for Interoperability with AD FS 1.x
resource 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 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.
After you deploy the first federation server in the account Create a Relying Party Trust Manually
partner organization, create a relying party trust relationship Create a Relying Party Trust Using Federation
using the AD FS Management snap-in. You can create a Metadata
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 organization, create one or Checklist: Creating Claim Rules for a Relying Party Trust
more claim 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 one does not already Add a Claim Description
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.
TA SK REF EREN C E
Determine whether your organization will need to use When to Use Identity Delegation
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 by: Prepare Client Computers in the Account Partner
- Adding the URL for the account partner federation Configure Client Computers to Trust the Account
server to the trusted sites list for the client browser. Federation Server
- Using Group Policy to push the appropriate Secure
Sockets Layer (SSL) certificates to client computers. Distribute Certificates to Client Computers by Using
Group Policy
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 par tner organization
TA SK REF EREN C E
If you have an existing AD FS 1.0 or 1.1 deployment in your Planning a Migration to AD FS

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 resource partner organization.
Based on your deployment goals, review information about Provide Your Active Directory Users Access to Your
the components that are required to provide users with Claims-Aware Applications and Services
access to the federated applications. Provide Your Active Directory Users Access to the
Provide Users in Another Organization Access to Your
TA SK REF EREN C E
Determine which AD FS design this resource partner Web SSO Design

organization will be associated with. Federated Web SSO Design
Review the different application types, and decide which Determine Your Federated Application Strategy in the
application to deploy. Resource Partner
Before you begin deploying your AD FS servers, review the; Determine Your AD FS Deployment Topology
1.) advantages and disadvantages of choosing either AD FS Deployment Topology Considerations
Windows Internal Database (WID) or SQL Server to store the
AD FS configuration database 2.) AD FS deployment
topology types and their associated server placement and
network layout recommendations.
Review AD FS capacity planning guidance to determine the Planning for AD FS Server Capacity
proper number of federation server and federation server
proxy servers you should use in your production
environment.
To effectively plan and implement the physical topology for Checklist: Setting Up a Federation Server
the account partner deployment, determine whether your Checklist: Setting Up a Federation Server Proxy
AD FS design requires one or more federation servers or
Determine the type of attribute store that you want to add The Role of Attribute Stores
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 consume claims from an Planning for Interoperability with AD FS 1.x
account 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 server in the resource Create a Claims Provider Trust Manually
partner organization, create a claims provider trust Create a Claims Provider Trust Using Federation
relationship by using the AD FS Management snap-in. You Metadata
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 organization, create one or Checklist: Creating Claim Rules for a Claims Provider Trust
more claim 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.
TA SK REF EREN C E
(Optional) A claim description may have to be created if one Add a Claim Description
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 .
3. 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 Director y , 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
4. 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.
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 Star t .

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, and then click Next .
8. On the Configure Cer tificates page, click Add to locate a certificate file and add it to the list of
certificates, and then click Next .
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 .


4. On the Select Data Source page, click Impor t 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
provider trust, and then click Next .
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.
2. Under Actions , click Add Relying Par ty Trust .
3. On the Welcome page, choose Claims aware and click Star t .

4. On the Select Data Source page, click Enter data about the relying par ty 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 Cer tificate 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 suppor t for the WS-Federation Passive protocol check box. Under
Relying par ty WS-Federation Passive protocol URL , type the URL for this relying party trust,
Select the Enable suppor t for the SAML 2.0 WebSSO protocol check box. Under Relying
par ty SAML 2.0 SSO ser vice 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
such as https://myserver.contoso.com.
Default Groups.

4. On the Select Data Source page, click Impor t data about the relying par ty published online or
on a local network . In Federation metadata address (host name or URL) , type the federation
5. On the Specify Display Name page type a name in Display name , under Notes type a description for
6. On the Choose Issuance Authorization Rules page, select either Permit all users to access this
relying par ty or Deny all users access to this relying par ty , and then click Next .
7. On the Ready to Add Trust page, review the settings, and then click Next to save your relying party trust
information.
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 Ser vice 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 Shor t 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**.
8. 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 Impor t 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 Cer tification Authorities , and then click
Impor t .
5. On the Welcome to the Cer tificate Impor t Wizard page, click Next .
6. On the File to Impor t page, type the path to the appropriate certificate files (for example,
\\fs1\c$\fs1.cer), and then click Next .
7. On the Cer tificate Store page, click Place all cer tificates in the following store , and then click
Next .
8. On the Completing the Cer tificate Impor t 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
TA SK REF EREN C E
Review concepts about claims, claim rules, claim rule sets, The Role of Claims
and claim rule templates and how they are associated with The Role of Claim Rules
federated trusts.
Review concepts about how a claim flows through all the The Role of the Claims Pipeline
stages in the claims issuance pipeline and how rules are The Role of the Claims Engine
processed by the claims issuance engine.
To effectively plan and implement the output claims that will Determine the Type of Claim Rule Template to Use
be issued over 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 one claim rule over When to Use a Pass Through or Filter Claim Rule
another and how you can use the claim rule language to When to Use a Transform Claim Rule
provide more complex logic than standard rules in order to
provide a desired result in the ideal output claim set. When to Use a Send LDAP Attributes as Claims Rule
When to Use a Send Group Membership as a Claim
Rule
When to Use a Custom Claim Rule
TA SK REF EREN C E
Depending on the needs of your organization, create one or Create a Rule to Pass Through or Filter an Incoming Claim
more claim rules for the acceptance transform rules set that Create a Rule to Send LDAP Attributes as Claims
is associated with this claims provider trust so that claims will
be issued appropriately. Create a Rule to Send Group Membership as a Claim
Create a Rule to Send an Authentication Method
Claim
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 par ty trust
TA SK REF EREN C E
Review concepts about claims, claim rules, claim rule sets, The Role of Claims
and claim rule templates and how they are associated with The Role of Claim Rules
federated trusts.
Review concepts about how a claim flows through all the The Role of the Claims Pipeline
stages in the claims issuance pipeline and how rules are The Role of the Claims Engine
processed by the claims issuance engine.
To effectively plan and implement the output claims that will Determine the Type of Claim Rule Template to Use
be issued over 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.
Review concepts about when to create one claim rule over When to Use a Pass Through or Filter Claim Rule
another and how you can use the claim rule language to When to Use a Transform Claim Rule
provide more complex logic than standard rules in order to
provide a desired result in the ideal output claim set. When to Use a Send LDAP Attributes as Claims Rule
When to Use a Send Group Membership as a Claim
Rule
When to Use an Authorization Claim Rule
When to Use a Custom Claim Rule
TA SK REF EREN C E
Depending on the needs of your organization, create one or Create a Rule to Pass Through or Filter an Incoming Claim
more claim rules for the rule sets that are associated with Create a Rule to Send LDAP Attributes as Claims
this relying party trust so that claims will be issued
appropriately. Create a Rule to Send Group Membership as a Claim
Claim
Depending on the needs of your organization, create one or Create a Rule to Permit All Users
more claim rules for either the issuance authorization rules Create a Rule to Permit or Deny Users Based on an
set or the delegation authorization rules set that is Incoming Claim
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 Par ty 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 star t with a specific value
7. Click the Finish button.
8. In the Edit Claim Rules dialog box, click OK to save the rule.

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

2. In the console tree, under AD FSAD FS\Trust Relationships , click either Claims Provider Trusts or
Relying Par ty 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
Create a Rule to Send an AD FS 1.x Compatible
Claim
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
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 Trust in Windows Server 2016
rule wizard.
list:
UPN
E-Mail
Common Name
To create a rule to transform an incoming claim on a Relying Party


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

rule 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
Par ty 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
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 Par ty Trust that you want to permit access to and select Edit Access Control
Policy .
4. On the Access control policy select Permit ever yone 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 Par ty 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,
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 Ever yone 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 Par ty 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 Par ty 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 Windows Server 2012 R2
2. In the console tree, under AD FS\Trust Relationships\Relying Par ty 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


5. On the Select Rule Template page, under Claim rule template , select Send LDAP Attributes as
Claims from the list, and then click Next .
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

rule 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 Par ty 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
that is associated with that rule set:
6. On the Configure Rule page under Claim rule name type the display name for this rule, under
Attribute store select Active Director y , 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
Create a Rule to Send Group Membership as a
Claim
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

Party Trust in Windows Server 2016

5. On the Select Rule Template page, under Claim rule template , select Send Group Membership as
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

rule wizard.

To create a rule to send group membership as a claim in Windows

Server 2012 R2
a Claim from the list, and then click Next .
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.


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.

rule wizard.
NOTE
To create a rule to transform an incoming claim in Windows Server

2012 R2
NOTE
7. Click Finish .
The Role of Claims
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

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.
A C T UA L A UT H EN T IC AT IO N M ET H O D C O RRESP O N DIN G URI
User name and password authentication https://schemas.microsoft.com/ws/2008/06/identity/authenti

cationmethod/password
Windows authentication https://schemas.microsoft.com/ws/2008/06/identity/authenti

cationmethod/windows
Transport Layer Security (TLS) Mutual authentication that https://schemas.microsoft.com/ws/2008/06/identity/authenti

uses X.509 certificates cationmethod/tlsclient
X.509-based authentication that does not use TLS https://schemas.microsoft.com/ws/2008/06/identity/authenti

cationmethod/x509
To create by using the Send Group Membership as Claims rule
template on a Claims Provider Trust in Windows Server 2016
rule wizard.
then click OK .
save the rule.




cationmethod/x509
To create this rule by using the transform an incoming claim rule
template on a Relying Party Trust in Windows Server 2016

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.


TLS mutual authentication that uses X.509 certificates https://schemas.microsoft.com/ws/2008/06/identity/authenti

cationmethod/tlsclient

cationmethod/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
rule wizard.
following:
rule.
save the rule.




cationmethod/x509
To create this rule by using the Send Group Membership as Claims
rule template in Windows Server 2012 R2
a Claim from the list, and then click Next .

then click OK .
save the rule.




cationmethod/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
To create this rule by using the Transform an Incoming Claim rule

template in Windows Server 2012 R2

following:
rule.
save the rule.




cationmethod/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
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.

Relying Party Trust in Windows Server 2016

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 .

Claims Provider Trust in Windows Server 2016
rule 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 Star t\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 ser ver
TA SK REF EREN C E
Before you begin deploying your AD FS federation servers, Determine Your AD FS Deployment Topology
review the; 1.) advantages and disadvantages of choosing AD FS Deployment Topology Considerations
either Windows Internal Database (WID) or SQL Server to
store the AD FS configuration database 2.) AD FS
deployment topology types and their associated server
placement and network layout recommendations.
Review AD FS capacity planning guidance to determine the Planning for Federation Server Capacity
proper number of federation servers you should use in your
Review information in the AD FS Design Guide about where Planning Federation Server Placement
to place federation servers in your organization Where to Place a Federation Server
Determine whether a stand-alone federation server or a When to Create a Federation Server

federation server farm is better for your deployment. When to Create a Federation Server Farm
Determine whether this new federation server will be created Review the Role of the Federation Server in the Account
in the account partner organization or in the resource Partner
partner organization. Review the Role of the Federation Server in the
Resource Partner
Review information about how federation servers use service Certificate Requirements for 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.
TA SK REF EREN C E
Review information about how to update the corporate Name Resolution Requirements for Federation Servers
network Domain Name System (DNS) so that successful
name resolution to federation servers can occur.
Join the computer that will become the federation server to Join a Computer to a Domain
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 corporate network DNS Add a Host (A) Resource Record to Corporate DNS for a
that points the DNS host name of the federation server to Federation Server
the IP address of the federation server.
(Optional) If you will be adding a federation server to a Export the Private Key Portion of a Server Authentication
federation server farm, you might have to first export the Certificate
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 certificate (or Import a Server Authentication Certificate to the Default
private key) from a certification authority (CA), you must Web Site
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 a server IIS: Create a Self-Signed Server Certificate and then
authentication certificate from a CA, you can use Internet complete the procedure Import a Server Authentication
Information Services (IIS) to create a sample certificate for Certificate to the Default Web Site
your federation server. 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 server farm Manually Configure a Service Account for a Federation
environment in an account partner organization, you must Server Farm
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.
TA SK REF EREN C E
Install the Federation Service role service on the computer Install the Federation Service Role Service
that will become the federation server.
Configure the AD FS software on the computer to act in the Create a Stand-Alone Federation Server
federation server role by using the AD FS Federation Server Create the First Federation Server in a Federation
Configuration Wizard. Server Farm
Follow this procedure when you want to set up a stand-
alone federation server, create the first federation server Add a Federation Server to a Federation Server Farm
in a 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
partner organization.
(Optional) Use the AD FS Management snap-in to add and Add a Token-Signing Certificate
configure the necessary AD FS certificates required to deploy Add a Token-Decrypting Certificate
your design. For more information about when to add or
change certificates using the snap-in, see Certificate Set a Service Communications Certificate
Requirements for Federation Servers.
If this is the first federation server in your organization, Checklist: Configuring the Account Partner Organization
configure the Federation Service so that it conforms to your Checklist: Configuring the Resource Partner
AD FS design. Organization
From a client computer, verify that the federation server is Verify That a 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
Federation Server Farm
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.
IMPORTANT
As of AD FS 3.0 (Windows Server 2012 R2), AD FS supports the use of a Group Managed Service Account (gMSA) as the
service account. This is the recommended option, as it removes the need for managing the service account password over
time. This document covers the alternate case of using a traditional service account, such as in domains still running a
Windows Server 2008 R2 or earlier domain functional level (DFL).
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 Ser vice 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.
To install the Federation Service role service
1. On the Star t screen, typeSer ver 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 .
target computer is highlighted, and then click Next .
6. On the Select ser ver roles page, click Active Director y Federation Ser vices , 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 ser vices page, select the Federation Ser vice check box, and then click Next .
10. On the Web Ser ver Role (IIS) page, click Next .
11. On the Select role ser vices 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 Ser ver Configuration Wizard link on the Over view
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 Ser vice is selected, and then click Next .
3. On the Select Stand-Alone or Farm Deployment page, click New federation ser ver farm , and
then click Next .
4. On the Specify the Federation Ser vice Name page, verify that the SSL cer tificate that is showing is
correct. If this is not the correct certificate, select the appropriate certificate from the SSL cer tificate 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 Ser vice 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
are 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
Configuration Wizard.
NOTE
Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
To create a stand-alone federation server
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 Ser vice is selected, and then click Next .
3. On the Select Stand-Alone or Farm Deployment page, click Stand-alone federation ser ver , 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 Ser vice Name page, verify that the SSL cer tificate that is showing is
correct. If not, select the appropriate certificate from the SSL cer tificate 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
are 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
C:\Windows\ADFS folder, and double-click FsConfigWizard.exe .
2. On the Welcome page, verify that Add a federation ser ver to an existing Federation Ser vice 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 Primar y Federation Ser ver and Ser vice Account page, under Primar y
federation ser ver 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 Star t screen, typeAD FS Management , and then press ENTER.
2. In the console tree, double-click Ser vice , and then click Cer tificates .
3. In the Actions pane, click the Add Token-Signing Cer tificate link.
4. In the Browse for Cer tificate 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-Decr ypting Cer tificate link.
4. In the Browse for Cer tificate 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.
NOTE
The Service Communications Certificate is not the same as an SSL Certificate. To change the AD FS SSL certificate, you will
need to use Powershell. Follow the guidance in this article.
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
To set a service communications certificate
3. In the Actions pane, click the Set Ser vice Communications Cer tificate link.
4. In the Select a ser vice communications cer tificate 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.
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.
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/federationser verser vice.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 cer tificate , 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 Star t screen, type Event Viewer , and then press ENTER.
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.
Deploying Legacy AD FS Federation Server Proxies
To deploy federation server proxies in Active Directory Federation Services (AD FS), complete each of the tasks
in Checklist: Setting Up a Federation Server Proxy.
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 ser ver proxy
TA SK REF EREN C E
Before you begin deploying your AD FS federation server Determine Your AD FS Deployment Topology
proxies, review the AD FS deployment topology types and Planning Federation Server Proxy Placement
their associated server placement and network layout
recommendations. Where to Place a Federation Server Proxy
Review AD FS capacity planning guidance to determine the Planning for Federation Server Proxy Capacity
proper number of federation server proxies you should use
in your production environment.
Determine whether a single federation server proxy or a When to Create a Federation Server Proxy
federation server proxy farm is better for your deployment. When to Create a Federation Server Proxy Farm
Note: Federation servers also perform federation server
proxy responsibilities.
Determine whether this new federation server proxy will be Review the Role of the Federation Server Proxy in the
created in the perimeter network of the account partner Account Partner
organization or the resource partner organization. Review the Role of the Federation Server Proxy in the
Resource Partner
Before you install AD FS on a computer that will become a Certificate Requirements for Federation Server Proxies
federation server 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.
Review information in the AD FS Design Guide about how to Name Resolution Requirements for Federation Server
update Domain Name System (DNS) in the perimeter Proxies
network so that successful name resolution for federation
servers and federation server proxies can occur.
Determine whether the federation server proxy must be Join a Computer to a Domain
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.
TA SK REF EREN C E
Depending on how the DNS infrastructure in your perimeter Configure Name Resolution for a Federation Server Proxy
network is configured, complete one of the procedures in in a DNS Zone That Serves Only the Perimeter Network
the topics on the right before you deploy a federation server Configure Name Resolution for a Federation Server
proxy in your organization. Note: Do not perform both Proxy in a DNS Zone That Serves Both the Perimeter
procedures. Read Name Resolution Requirements for Network and Internet Clients
Federation Server Proxies to determine which procedure
best suits the requirements of your organization.
After you obtain a server authentication certificate, you Import a Server Authentication Certificate to the Default
must install it in Internet Information Services (IIS) on the Web Site
default Web site of the federation server proxy.
(Optional) As an alternative to obtaining a server IIS: Create a Self-Signed Server Certificate

authentication certificate from a certification authority (CA),
you can use IIS to acquire a sample certificate for your
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 service on the Install the Federation Service Proxy Role Service
computer that will become the federation server proxy.
Configure the AD FS software on the computer to act in the Configure a Computer for the Federation Server Proxy
federation server proxy role by using the AD FS Federation Role
Server Proxy Configuration Wizard.
Using Event Viewer, verify that the federation server proxy Verify That a Federation Server Proxy Is Operational
service has started.
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 Star t 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
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
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 Star t , point to Administrative
Tools , and then click DNS .
AAAA) .
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 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
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
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 Star t , point to Administrative
Tools , and then click DNS .
AAAA) .
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 .
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
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 Star t screen, typeInternet Information Ser vices (IIS) Manager , and then press ENTER.
2. In the console tree, click ComputerName .
3. In the center pane, double-click Ser ver Cer tificates .
4. In the center pane, right-click the certificate that you want to export, and then click Expor t .
5. In the Expor t Cer tificate 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
Default Groups.
To import a server authentication certificate to the Default Web Site
1. On the Star t screen, typeInternet Information Ser vices (IIS) Manager , and then press ENTER.
2. In the console tree, click ComputerName .
3. In the center pane, double-click Ser ver Cer tificates .
4. In the Actions pane, click Impor t .
5. In the Impor t Cer tificate 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 Star t screen, typeSer ver 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 .
target computer is highlighted, and then click Next .
6. On the Select ser ver 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 ser vices page, select the Federation Ser vice 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
On the Star t screen, typeAD FS Federation Ser ver 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 Ser vice Name page, under Federation Ser vice 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 ser ver when
sending requests to this Federation Ser vice check box, under HTTP proxy ser ver 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.
to 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-ADFSProper ties 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-ADFSProxyProper ties 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/proxycertificatet
ransport"
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 Ser ver 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
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 Star t screen, typeEvent Viewer , and then press ENTER.
then 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 Star t 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 Star t .
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 Repor t .
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 Repor t\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.
C O UN T ER DESC RIP T IO N C A N B E USED O N :
Token Requests Monitors the number of token Federation Servers

requests sent to the federation server
including SSOAuth token requests.
Token Requests/sec Monitors the number of token Federation Servers

including SSOAuth token requests per
second.
Federation Metadata Requests Monitors the number of incoming Federation Servers

federation metadata requests sent to
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
server.
Artifact Resolution Requests/sec Monitors the number of requests to Federation Servers

the artifact resolution endpoint per
server.
Proxy Requests Monitors the number of incoming Federation Server Proxies

proxy.
Proxy Requests/sec Monitors the number of incoming Federation Server Proxies

requests per second that are sent to
the federation server proxy.
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 Federation Server Proxies
MEX requests per second that are sent
to the federation server proxy.
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 .
EQ UIVA L EN T A D F S F EDERAT IO N SERVIC E IN W IN DO W S

A D F S 1. X F EDERAT IO N SERVIC E SET T IN G SERVER 2012 SET T IN G
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
TA SK REF EREN C E
Plan for interoperability between AD FS in Windows Server Planning for Interoperability with AD FS 1.x
2012 and previous versions of AD FS, and learn more about
the Name ID claim type.
Before you can interoperate with a previous version of Create a Claims Provider Trust Manually
AD FS, you must 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 par ty 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
Ser vice 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
Ser vice URI as defined in the AD FS 1.x Federation
Service of the partner.
TA SK REF EREN C E
On the claims provider trust that you created earlier, you Create a Rule to Send an AD FS 1.x Compatible Claim
must create a 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 1.x Federation N/A

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
(AD 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 Ser vice
TA SK REF EREN C E
2012 and previous versions of AD FS and learn more about
Before you can achieve interoperability with a previous Create a Relying Party Trust Manually
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.
Relying Party Trust Wizard to set up this trust to
interoperate with an AD FS 1.x Federation Service:
1.1 profile .
Federation Passive URL , type the Federation
Ser vice endpoint URL as defined in the AD FS 1.x
Federation Service of the partner.
4. On the Configure Identifiers page, under Relying
par t trust identifier , type the Federation Ser vice
URI as defined in the AD FS 1.x Federation Service of
the partner.
TA SK REF EREN C E
On the relying party trust that you created earlier, you must Create a Rule to Send an AD FS 1.x Compatible Claim
create 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.
Contact the administrator of the AD FS 1.x Federation N/A

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
(AD 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
TA SK REF EREN C E
2012 and previous versions of AD FS and learn more about
If you have not already done so, use the link on the right to Checklist: Configuring AD FS to Send Claims to an AD FS 1.x
first create a relying party trust between the AD FS Federation Service
Federation Service in Windows Server 2012 and the
AD FS 1.x Federation Service.
TA SK REF EREN C E
Before you can achieve interoperation with an application Create a Relying Party Trust Manually
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 Ser vice\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.
Relying Party Trust Wizard to set up this trust to
interoperate with an AD FS 1.x claims-aware Web agent:
1.1 profile .
Federation Passive URL , type the Application URL
as defined in the AD FS 1.x Federation Service of the
partner.
4. On the Configure Identifiers page, under Relying
par t trust identifier , type the Application URL as
defined in the AD FS 1.x claims-aware Web agent
Contact the administrator of the Web server running the N/A

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 .
TA SK REF EREN C E
On the relying party trust that you created earlier, you have Create a Rule to Send an AD FS 1.x Compatible Claim
to create 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.

4. On the Select Data Source page, click Enter data about the relying par ty manually , and then click
Next .
6. On the Configure Cer tificate 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 suppor t for the WS-Federation Passive protocol check box. Under
Relying par ty WS-Federation Passive protocol URL , type the URL for this relying party trust,
Select the Enable suppor t for the SAML 2.0 WebSSO protocol check box. Under Relying
par ty SAML 2.0 SSO ser vice URL , type the Security Assertion Markup Language (SAML)
service endpoint URL for this relying party trust, and then click Next .
trust information.
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
such as https://myserver.contoso.com.
Default Groups.

4. On the Select Data Source page, click Impor t data about the relying par ty published online or
on a local network . In Federation metadata address (host name or URL) , type the federation
5. On the Specify Display Name page type a name in Display name , under Notes type a description for
6. On the Choose Issuance Authorization Rules page, select either Permit all users to access this
relying par ty or Deny all users access to this relying par ty , and then click Next .
7. On the Ready to Add Trust page, review the settings, and then click Next to save your relying party trust
information.
more information about how to proceed with adding claim rules for this relying party trust, see the
Additional references.
See Also
AD FS Operations
organization.


Next .
NOTE


See Also
AD FS Operations
Create a Rule to Send an AD FS 1.x Compatible
Claim
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

list:
UPN
E-Mail
Common Name

Through or Filter an Incoming Claim rule template on a Claims
rule wizard.
list:
UPN
E-Mail
Common Name


list:
UPN
E-Mail
Common Name

rule 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
SO URC E SERVER P RO C ESSO R SO URC E SERVER O P ERAT IN G SY ST EM
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.
F RO M TO A D F S IN STA L L ED W IT H W IN DO W S SERVER 2012 R2
AD FS 2.0 federation server installed on Windows Server Migration on the same server is supported. For more
2008 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:
Preparing to Migrate the AD FS Federation Server
Migrating the AD FS Federation Server
Next Steps
Preparing to Migrate the AD FS Federation Server Migrating the AD FS Federation Server 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.
2. Create a Windows Server 2012 R2 federation server farm.
3. Import the original configuration data into this new Windows Server 2012 R2 AD FS farm.
4. 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.
2. 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.
3. 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
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.
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 Migrating the AD FS
Federation Server Migrating the AD FS Federation Server Proxy Verifying the AD FS Migration 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”
2. 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:
F EDERAT IO N SERVIC E P RO P ERT Y N A M E A S REP O RT ED B Y F EDERAT IO N SERVIC E P RO P ERT Y N A M E IN A D F S

GET - A DF SP RO P ERT IES M A N A GEM EN T C O N SO L E
HostName Federation Service name
Identifier Federation Service identifier
DisplayName Federation Service display name
3. 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" .
4. 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 Ser vice in the Ser vices
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.
5. 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”`.
6. 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”`.

7. 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/ser ver_suppor t/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>]
Export-FederationConfiguration.ps1 -Path <string> [-ComputerName <string>] [-Credential <pscredential>]
[-Force] [-CertificatePassword <securestring>] [-RelyingPartyTrustIdentifier <string[]>] [-
ClaimsProviderTrustIdentifier <string[]>]
Export-FederationConfiguration.ps1 -Path <string> [-ComputerName <string>] [-Credential <pscredential>]
[-Force] [-CertificatePassword <securestring>] [-RelyingPartyTrustName <string[]>] [-ClaimsProviderTrustName
<string[]>]
-RelyingPar tyTrustIdentifier <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.
-RelyingPar tyTrustName <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.
-Cer tificatePassword <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.

2. 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.
2. 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 Cer tificates . 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
2. Configure any custom AD FS service settings such as AutoCertificateRollover or SSO lifetime using the
Set-AdfsProperties cmdlet.
3. 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>]
[-LogPath <string>] [-CertificatePassword <securestring>] [-RelyingPartyTrustIdentifier <string[]>] [-
ClaimsProviderTrustIdentifier <string[]>
[-LogPath <string>] [-CertificatePassword <securestring>] [-RelyingPartyTrustName <string[]>] [-
ClaimsProviderTrustName <string[]>]
-RelyingPar tyTrustIdentifier <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.
-RelyingPar tyTrustName <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.
-Cer tificatePassword <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.IdentitySer ver.Ser vicehost.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.identityser ver.web> section of the
Microsoft.IdentitySer ver.Ser vicehost.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 Active Directory Federation Services Role Services to Windows Server 2012 R2 Preparing to Migrate
the AD FS Federation Server Migrating the AD FS Federation Server Proxy Verifying the AD FS Migration to
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
the AD FS Federation Server Migrating the AD FS Federation Server Verifying the AD FS Migration to Windows
Server 2012 R2
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 federation servers.
computer is 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.
2. 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
the AD FS Federation Server Migrating the AD FS Federation Server Migrating the AD FS Federation Server
Proxy
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 ser ver operating system:
Windows Server 2012 or Windows Server 2008 R2 (Server Core and full installation options)
Destination ser ver 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.
F RO M TO A D F S IN STA L L ED W IT H W IN DO W S 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
2008 or Windows Server 2008 R2
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
Windows Server 2008 or Windows Server 2008 R2 migrated 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:
F RO M TO A D F S IN STA L L ED W IT H W IN DO W S SERVER 2012
AD FS 1.1 claims-aware agent installed with Windows Server Migration on the same server is supported. The migrated
2008 or Windows Server 2008 R2) AD FS 1.1 claims-aware web agent will function with the
following:
AD FS 1.1 federation service installed with Windows
AD FS 2.0 federation service installed on Windows
AD FS federation service installed with Windows Server
2012
For more information, see:
AD FS 2.0 federation server installed on Windows Server Migration on the same server is supported. For more
2008 or Windows Server 2008 R2 information, see:
Migrate the AD FS 2.0 Federation Server
AD FS 2.0 federation server proxy installed on Windows Migration on the same server is supported. For more
Server 2008 or Windows Server 2008 R2 information see:
Proxy
Migrate the AD FS 2.0 Federation Server Proxy
See Also
Prepare to Migrate the AD FS 2.0 Federation Server 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 Federation Server Proxy Migrate the AD FS 1.1
Web Agents
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
Web Agents
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 Web Site in the left pane, click Bindings… in the Action pane, find and select the https binding,
click Edit , and 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.
2. 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.
3. 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.
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" .
5. 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.
6. 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” .
7. 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
Web Agents
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

service. To find the SSL certificate, open the Internet Information Services (IIS) management console, select
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.
2. 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.

directory.
Next Steps
Web Agents
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.

service. To find the SSL certificate, open the Internet Information Services (IIS) management console, select
click Edit , and 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.
2. 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.
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.


directory.
Next Steps
Web Agents
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.
2. 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” .
3. 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
Web Agents
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
Web Agents
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.
3. 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 Ser ver 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:
F EDERAT IO N SERVER C O N F IGURAT IO N W IZ A RD IN P UT

O P T IO N USE T H E F O L LO W IN G VA L UE
SSL Cer tificate on the Specify the Federation Ser vice Select the SSL certificate whose subject name and
Name page thumbprint you recorded while preparing for the AD FS
federation server migration.
Ser vice account and Password on the Specify a Ser vice Enter the service account information that you recorded
Account page while 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
4. 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.
5. 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.
6. 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 Ser vice and click Edit Federation Ser vice… . 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 Cer tificates . 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 Par ty Trusts . You must recreate each Relying Party
trust manually using the Add Relying Par ty 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
Web Agents
-
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
role is 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.
4. Create the original AD FS configuration on this server.

You can create the original AD FS configuration by using the AD FS Federation Ser ver Configuration
Wizard to add a federation server to a WID farm. For more information, see Add a Federation Server to a
NOTE
When you reach the Specify the Primar y Federation Ser ver and a Ser vice Account page in the AD FS
Federation Ser ver 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 Ser vice 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.
5. 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.
6. Add the server that you just upgraded to Windows Server 2012 to the load balancer.
7. Repeat steps 1 through 6 for the remaining secondary servers in your WID farm.
8. 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 .
9. Remove the original primary server of your WID farm from the load balancer.
10. 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>
.
11. 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
server migration.
12. 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 Ser ver Configuration
Wizard to add a federation server to a WID farm. For more information, see Add a Federation Server to a
NOTE
When you reach the Specify the Primar y Federation ser ver and a Ser vice Account page in the AD FS
Federation Ser ver 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 Ser vice Name page, be sure to select the same SSL certificate you
recorded in Prepare to Migrate the AD FS 2.0 Federation Server.
13. 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.
14. Add this last server of your WID farm that you just upgraded to Windows Server 2012 to the load
balancer.
15. Restore any remaining AD FS customizations, such as custom attribute stores.
Next Steps
Web Agents
Migrate an AD FS 2.0 SQL 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
server migration.
4. 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 configuration database.
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:
5. Add the server that you just upgraded to Windows Server 2012 to the load balancer.
6. Repeat steps 2 through 6 for the remaining nodes in your SQL Server farm.
7. 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
Web Agents
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.
4. Create the original AD FS proxy configuration by using the AD FS Federation Ser ver 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:
F EDERAT IO N SERVER P RO XY W IZ A RD IN P UT O P T IO N USE T H E F O L LO W IN G VA L UE
Federation Ser vice Name Enter the BaseHostName value from proxyproperties.txt file
Use an HTTP proxy ser ver 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 ser ver 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.
5. 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.
6. Add this server back to the load balancer.
7. 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
Web Agents
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
Web Agents
AD FS OpenID Connect/OAuth Concepts
Applies to AD FS 2016 and later
Modern Authentication Actors

A C TO R DESC RIP T IO N
End User This is the security principal (users, applications, services and
groups) who needs to access the resource.
Client This is your web application, identified by its client ID. The
client is usually the party that the end user interacts with,
and it requests tokens from the authorization server.
Authorization Server / Identity Provider (IdP) This is your AD FS server. It is responsible for verifying the
identity of security principals that exist in an organization's
directory. It issues security tokens (bearer access token, ID
token, refresh token) upon successful authentication of
those security principals.
Resource Server / Resource Provider / Relying Party This is where the resource or data resides. It trusts the
Authorization Server to securely authenticate and authorize
the Client and uses Bearer access tokens to ensure that
access to a resource can be granted.
Following diagram provides the most basic relationship between the actors:
Application Types
A P P L IC AT IO N T Y P E DESC RIP T IO N RO L E
Native application Sometimes called a public client , this Requests tokens from the
is intended to be a client app that runs authorization server (AD FS) for user
on a pc or device and with which the access to resources. Sends HTTP
user interacts. requests to protected resources, using
the tokens as HTTP headers.
A P P L IC AT IO N T Y P E DESC RIP T IO N RO L E
Server application (Web app) A web application that runs on a Requests tokens from the
server and is generally accessible to authorization server (AD FS) for user
users via a browser. Because it is access to resources. Before requesting
capable of maintaining its own client token, client (Web App) needs to
'secret' or credential, it is sometimes authenticate using its secret.
called a confidential client .
Web API The end resource the user is accessing. Consumes bearer access tokens
Think of these as the new obtained by the clients
representation of "relying parties".
Application Group
Every OAuth client (native or web app) or resource (web api) configured with AD FS needs to be associated with
an application group. The clients in an application group can be configured to access the resources in the same
group. An application group can contain multiple clients and resources.
Security Tokens
Modern authentication uses following token types:
id_token :A JWT token issued by authorization server (AD FS) and consumed by the client. Claims in the ID
token will contain information about the user so that client can use that.
access_token :A JWT token issued by authorization server (AD FS) 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 is token issued by AD FS for client to use when it needs to refresh the id_token and
access_token. The token is opaque to the client and can only be consumed by AD FS.
Scopes
While registering a resource in AD FS, scopes can be configured to allow AD FS to perform specific actions. In
addition to configuring the scope, the scope value is also required to be sent in the request for AD FS to perform
the action. For e.g., Admin needs to configure scope as openid during resource registration and application
(client) needs to send scope = openid in the auth request for AD FS to issue ID Token. Details on the scopes
available in AD FS are provided below
aza - If usingOAuth 2.0 Protocol Extensions for Broker Clientsand if the scope parameter contains the scope
"aza", the server issues a new primary refresh token and sets it in the refresh_token field of the response, as
well as setting the refresh_token_expires_in field to the lifetime of the new primary refresh token if one is
enforced.
openid - Allows application to request use of the OpenID Connect authorization protocol.
logon_cert - The logon_cert scope allows an application to request logon certificates, which can be used to
interactively logon authenticated users. The AD FS server omits the access_token parameter from the
response and instead provides a base64-encoded CMS certificate chain or a CMC full PKI response. More
details availablehere.
user_impersonation - The user_impersonation scope is necessary to successfully request an on-behalf-of
access token from AD FS. For details on how to use this scope referto Build a multi-tiered application using
On-Behalf-Of (OBO) using OAuth with AD FS 2016.
allatclaims – The allatclaims scope allows the application to request claims in access token to be added in the
ID Token as well.
vpn_cert - The vpn_cert scope allows an application to request VPN certificates, which can be used to
establish VPN connections using EAP-TLS authentication. This is not supported anymore.
email - Allows application to request email claim for the signed in user.
profile - Allows application to request profile related claims for the sign-in user.
Claims
Security tokens (access and ID tokens) issued by AD FS contain claims, or assertions of information about the
subject that has been authenticated. Applications can use claims for various tasks, including:
Validate the token
Identify the subject's directory tenant
Display user information
Determine the subject's authorization The claims present in any given security token are dependent upon the
type of token, the type of credential used to authenticate the user, and the application configuration.
High level AD FS authentication flow
1. AD FS receives auth request from the client.

2. AD FS validates the client ID in the auth request with the client ID obtained during client and resource
registration in AD FS. If using confidential client, then AD FS also validates the client secret provided in
the auth request. AD FS also validate the redirect uri of the Client.
3. AD FS identifies the resource which the client wants to access through the resource parameter passed in
the auth request. If using MSAL client library, then resource parameter is not sent. Instead the resource
url is sent as a part of the scope parameter: scope = [resource url]/[scope values e.g., openid].
If resource is not passed using resource or scope parameter, ADFS will use a default resource
urn:microsoft:userinfo whose polices (e.g.,MFA, Issuance or authorization policy) can't be configured.
4. Next AD FS validates whether client has the permissions to access the resource. AD FS also validates
whether the scopes passed in the auth request matches the scopes configured while registering the
resource. If the client doesn't have the permissions or the right scopes are not sent in the auth request the
auth flow is terminated.
5. Once permissions and scopes are validated, AD FS authenticates the user using the configured
authentication method.
6. If additional authentication method is required as per the resource policy or the global auth policy, AD FS
triggers the additional authentication.
7. AD FS uses Azure MFA or 3rd party MFA to perform authentication.
8. Once user is authenticated, AD FS applies the claim rules (determines the claims sent to resource as a
part of the security tokens) and access control polices (determines that user has met the required
conditions to access the resource).
9. Next, AD FS generates the Access and Refresh Tokens..
10. AD FS also generates the ID token.
11. If the scope = allatclaims is included in the auth request, ID token is customized to include claims in the
access token based on the defined claim rules.
12. Once the required tokens are generated and customized, AD FS responds to the client including the
tokens. Only if the auth request includes scope = openid, ID token is included in the response. Client can
always obtain the ID token post authentication using the token endpoint.
Types of libraries
Two types of libraries are used with AD FS:
Client libraries : Native clients and server apps use client libraries to acquire access tokens for calling a
resource such as a Web API. Microsoft Authentication Library (MSAL) is the latest and recommended
client library when using AD FS 2019. Active Directory Authentication Library (ADAL) is recommended
for AD FS 2016.
Ser ver middleware libraries : Web apps use server middleware libraries for user sign in. Web APIs use
server middleware libraries to validate tokens that are sent by native clients or by other servers. OWIN
(Open Web Interface for .NET) is the recommended middleware library.
Customize ID Token (additional claims in ID Token)

In certain scenarios it is possible that the Web app (client) needs additional claims in an ID token to help in the
functionality. This can be achieved by using one of the following options.
Option 1: Should be used when using a public client and web app does not have a resource that it is trying to
access. The option requires
1. response_mode set as form_post
2. Relying party identifier (Web API identifier) is same as client identifier
Option 2: Should be used when web app has a resource that it is trying to access and needs to pass additional
claims through ID token. Both public and confidential clients can be used. The option requires
1. response_mode set as form_post
2. KB4019472 is installed on your AD FS servers
3. Scope allatclaims assigned to the client – RP pair. You can assign the scope by using the Grant-
ADFSApplicationPermission (Use Set-AdfsApplicationPermission if already granted once) PowerShell
cmdlet as indicated in the example below:
Grant-AdfsApplicationPermission -ClientRoleIdentifier "https://my/privateclient" -

ServerRoleIdentifier "https://rp/fedpassive" -ScopeNames "allatclaims","openid"
To better understand how to configure a Web App in ADFS to acquire customized ID token see Customize claims
to be emitted in id_token when using OpenID Connect or OAuth with AD FS 2016 or later.
Single log-out
Single logout results in ending all the client sessions using the session id. AD FS 2016 and later supports single
log-out for OpenID Connect/OAuth. For more details see Single log-out for OpenID Connect with AD FS.
AD FS Endpoints
A D F S EN DP O IN T DESC RIP T IO N
/authorize AD FS returns an authorization code which can be used to

obtain the access token
/token AD FS returns an access token which can be used to access

the resource (Web API)
/userinfo AD FS returns claims about the authenticated user
/devicecode AD FS returns the device code and user code
/logout AD FS logs out the user
/keys AD FS public keys used to sign responses
/.well-known/openid-configuration AD FS returns OAuth/OpenID Connect metadata

AD FS OpenID Connect/OAuth flows and
Application Scenarios
Applies to AD FS 2016 and later
SC EN A RIO WA L K T H RO UGH
SC EN A RIO USIN G SA M P L ES O A UT H 2. 0 F LO W / GRA N T C L IEN T T Y P E
Single-page app • Sample using ADAL Implicit Public
Web App that signs in users • Sample using OWIN Authorization Code Public, Confidential
Native App calls Web API • Sample using MSAL Authorization Code Public
• Sample using ADAL
Web App calls Web API • Sample using MSAL Authorization Code Confidential
• Sample using ADAL
Web API calls another web • Sample using MSAL On-behalf-of Web app acts as
API on behalf of (OBO) the • Sample using ADAL Confidential
user
Daemon App calls Web API Client credentials Confidential
Web App calls Web API Resource owner password Public, Confidential
using user creds credentials
Browserless App calls Web Device code Public, Confidential

API
Implicit grant flow

For single page applications (AngularJS, Ember.js, React.js, and so on), AD FS supports the OAuth 2.0 Implicit
Grant flow. The implicit flow is described in theOAuth 2.0 Specification. Its primary benefit is that it allows the
app to get tokens from AD FS without performing a backend server credential exchange. This allows the app to
sign in the user, maintain session, and get tokens to other web APIs all within the client JavaScript code. There
are a few important security considerations to take into account when using the implicit flow specifically
aroundclient.
If you want to use the implicit flow and AD FS to add authentication to your JavaScript app, follow the general
steps below.
Protocol diagram
The following diagram shows what the entire implicit sign-in flow looks like and the sections that follow
describe each step in more detail.
Request ID Token and Access Token
To initially sign the user into your app, you can send anOpenID Connect authentication request and get
id_tokenand access token from the AD FS endpoint.
// Line breaks for legibility only
https://adfs.contoso.com/adfs/oauth2/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=id_token+token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&scope=openid
&response_mode=fragment
&state=12345
PA RA M ET ER REQ UIRED/ O P T IO N A L DESC RIP T IO N
client_id required The Application (client) ID that theAD

FS assigned to your app.
response_type required Must include id_token for OpenID

Connect sign-in. It may also include
the response_type token .
Usingtokenhere will allow your app to
receive an access token immediately
from the authorize endpoint without
having to make a second request to
the token endpoint.
redirect_uri required The redirect_uri of your app, where

authentication responses can be sent
and received by your app. It must
exactly match one of the redirect_uris
you configured in AD FS.
nonce required A value included in the request,

generated by the app, that will be
included in the resulting id_token as a
claim. The app can then verify this
value to mitigate token replay attacks.
The value is typically a randomized,
unique string that can be used to
identify the origin of the request. Only
required when an id_token is
requested.
scope optional A space-separated list ofscopes. For

OpenID Connect, it must include the
scope openid .
resource optional The url of your Web API.

Note – If using MSAL client library,
then resource parameter is not sent.
Instead the resource url is sent as a
part of the scope parameter:
scope = [resource url]//[scope
values e.g., openid]
If resource is not passed here or in
scope ADFS will use a default resource
urn:microsoft:userinfo. userinfo
resource polices such as MFA, Issuance
or authorization policy, can't be
customized.
response_mode optional Specifies the method that should be

used to send the resulting token back
to your app. Defaults to fragment .
state optional A value included in the request that

will also be returned in the token
response. It can be a string of any
content that you wish. A randomly
generated unique value is typically
used forpreventing cross-site request
forgery attacks. The state is also used
to encode information about the user's
state in the app before the
authentication request occurred, such
as the page or view they were on.
prompt optional Indicates the type of user interaction

that is required. The only valid values
at this time arelogin,and none.
- prompt=login will force the user to
enter their credentials on that request,
negating single-sign on.
- prompt=none is the opposite - it will
ensure that the user isn't presented
with any interactive prompt
whatsoever. If the request can't be
completed silently via single-sign on,
AD FS will return
aninteraction_requirederror.
login_hint optional Can be used to pre-fill the

username/email address field of the
sign in page for the user, if you know
their username ahead of time. Often
apps will use this parameter during re-
authentication, having already
extracted the username from a
previous sign-in using the upn claim
from id_token .
domain_hint optional If included, it will skip the domain-

based discovery process that user
goes through on the sign in page,
leading to a slightly more streamlined
user experience.
At this point, the user will be asked to enter their credentials and complete the authentication. Once the user
authenticates, the AD FS authorize endpoint will return a response to your app at the indicatedredirect_uri, using
the method specified in theresponse_modeparameter.
Successful response
A successful response using response_mode=fragmentandresponse_type=id_token+token looks like the following
GET https://localhost/myapp/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZEstZnl0aEV...
&token_type=Bearer
&expires_in=3599
&scope=openid
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZstZnl0aEV1Q...
&state=12345
access_token Included ifresponse_typeincludes token .
token_type Included ifresponse_typeincludes token . Will always

beBearer.
expires_in Included ifresponse_typeincludes token . Indicates the

number of seconds the token is valid, for caching purposes.
scope Indicates the scope(s) for which the access_token will be

valid.
id_token Included ifresponse_typeincludes id_token . A signed JSON

Web Token (JWT). The app can decode the segments of this
token to request information about the user who signed in.
The app can cache the values and display them, but it
shouldn't rely on them for any authorization or security
boundaries.
state If a state parameter is included in the request, the same

value should appear in the response. The app should verify
that the state values in the request and response are
identical.
Refresh tokens
The implicit grant does not provide refresh tokens. Both id_tokens and access_tokens will expire after a short
period of time, so your app must be prepared to refresh these tokens periodically. To refresh either type of
token, you can perform the same hidden iframe request from above using the prompt=none parameter to control
the identity platform's behavior. If you want to receive a newid_token , be sure to use response_type=id_token .
Authorization code grant flow

The OAuth 2.0 authorization code grant can be used in web apps to gain access to protected resources, such as
web APIs. The OAuth 2.0 authorization code flow is described insection 4.1 of the OAuth 2.0 specification. It's
used to perform authentication and authorization in the majority of app types, includingweb appsandnatively
installed apps. The flow enables apps to securely acquire access_tokens that can be used to access resources
which trust AD FS.
Protocol Diagram
At a high level, the authentication flow for a native application looks a bit like this:
Request an authorization code

The authorization code flow begins with the client directing the user to the/authorizeendpoint. In this request,
the client indicates the permissions it needs to acquire from the user:
https://adfs.contoso.com/adfs/oauth2/authorize?
&response_type=code
&response_mode=query
&resource=https://webapi.com/
&scope=openid
&state=12345

response_type required Must includecodefor the authorization

code flow.
redirect_uri required The redirect_uri of your app,

where authentication responses can be
sent and received by your app. It must
exactly match one of the redirect_uris
you registered in the AD FS for the
client.

customized.
scope optional A space-separated list of scopes.
response_mode optional Specifies the method that should be

used to send the resulting token back
to your app. Can be one of the
following:
- query
- fragment
- form_post
query provides the code as a query
string parameter on your redirect URI.
If you're requesting the code, you can
usequery,fragment, orform_post.
form_post executes a POST
containing the code to your redirect
URI.
state optional A value included in the request that

will also be returned in the token
response. It can be a string of any
content that you wish. A randomly
generated unique value is typically
used forpreventing cross-site request
forgery attacks. The value can also
encode information about the user's
state in the app before the
authentication request occurred, such
as the page or view they were on.
prompt optional Indicates the type of user interaction

that is required. The only valid values
at this time arelogin,and none.
- prompt=login will force the user to
enter their credentials on that request,
negating single-sign on.
- prompt=none is the opposite - it will
ensure that the user isn't presented
with any interactive prompt
whatsoever. If the request can't be
completed silently via single-sign on,
AD FS will return
aninteraction_requirederror.
login_hint optional Can be used to pre-fill the

username/email address field of the
sign-in page for the user, if you know
their username ahead of time. Often
apps will use this parameter during re-
authentication, having already
extracted the username from a
previous sign-in using the upn claim
from id_token .
domain_hint optional If included, it will skip the domain-

based discovery process that user
goes through on the sign in page,
leading to a slightly more streamlined
user experience.
code_challenge_method optional The method used to encode

thecode_verifierfor
thecode_challengeparameter. Can be
one of the following values:
- plain
- S256
If excluded,code_challengeis assumed
to be plaintext if code_challenge is
included. AD FS supports
bothplainandS256. For more
information, see thePKCE RFC.
code_challenge optional Used to secure authorization code

grants via Proof Key for Code
Exchange (PKCE) from a native client.
Required if code_challenge_method is
included. For more information, see
thePKCE RFC
At this point, the user will be asked to enter their credentials and complete the authentication. Once the user
authenticates, the AD FS will return a response to your app at the indicated redirect_uri , using the method
specified in the response_mode parameter.
Successful response
A successful response usingresponse_mode=querylooks like:
GET https://adfs.contoso.com/common/oauth2/nativeclient?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=12345
code The authorization_code that the app requested. The app

can use the authorization code to request an access token
for the target resource. Authorization_codes are short lived,
typically they expire after about 10 minutes.
state If a state parameter is included in the request, the same

value should appear in the response. The app should verify
that the state values in the request and response are
identical.
Request an access token

Now that you've acquired an authorization_code and have been granted permission by the user, you can
redeem thecodefor an access_token to the desired resource. Do this by sending aPOSTrequest to
the/tokenendpoint:
POST /adfs/oauth2/token HTTP/1.1

Host: https://adfs.contoso.com/
Content-Type: application/x-www-form-urlencoded
&code=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq3n8b2JRLk4OxVXr...
&grant_type=authorization_code
&client_secret=JqQX2PNo9bpM0uEihUPzyrh // NOTE: Only required for confidential clients (web apps)

grant_type required Must be authorization_code for the

authorization code flow.
code required The authorization_code that you

acquired in the first leg of the flow.
redirect_uri required The same redirect_uri value that

was used to acquire the
authorization_code .
client_secret required for web apps The application secret that you created
during app registration in AD FS. You
shouldn't use the application secret in
a native app because client_secrets
can't be reliably stored on devices. It's
required for web apps and web APIs,
which have the ability to store the
client_secret securely on the server
side. The client secret must be URL-
encoded before being sent. These apps
can also use a key based
authentication by signing a JWT and
adding that as client_assertion
parameter.
code_verifier optional The same code_verifier that was

used to obtain the authorization_code.
Required if PKCE was used in the
authorization code grant request. For
more information, see thePKCE RFC.
Note – Applies to AD FS 2019 and
later
Successful response
A successful token response will look like:
{
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"token_type": "Bearer",
"expires_in": 3599,
"refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
"refresh_token_expires_in": 28800,
"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}
access_token The requested access token. The app can use this token to
authenticate to the secured resource (Web API).
token_type Indicates the token type value. The only type that AD FS
supports is Bearer.
expires_in How long the access token is valid (in seconds).
refresh_token An OAuth 2.0 refresh token. The app can use this token
acquire additional access tokens after the current access
token expires. Refresh_tokens are long-lived, and can be
used to retain access to resources for extended periods of
time.
refresh_token_expires_in How long the refresh token is valid (in seconds).

id_token A JSON Web Token (JWT). The app can decode the segments
of this token to request information about the user who
signed in. The app can cache the values and display them,
but it should not rely on them for any authorization or
security boundaries.
Use the access token
GET /v1.0/me/messages
Host: https://webapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
Refresh Token Grant Flow

Access_tokens are short lived, and you must refresh them after they expire to continue accessing resources.
You can do so by submitting anotherPOSTrequest to the /token endpoint, this time providing
therefresh_tokeninstead of thecode. Refresh tokens are valid for all permissions that your client has already
received access token for.
Refresh tokens do not have specified lifetimes. Typically, the lifetimes of refresh tokens are relatively long.
However, in some cases, refresh tokens expire, are revoked, or lack sufficient privileges for the desired action.
Your application needs to expect and handleerrors returned by the token issuance endpointcorrectly.
Although refresh tokens aren't revoked when used to acquire new access tokens, you are expected to discard the
old refresh token. As per theOAuth 2.0 specsays: "The authorization server MAY issue a new refresh token, in
which case the client MUST discard the old refresh token and replace it with the new refresh token. The
authorization server MAY revoke the old refresh token after issuing a new refresh token to the client." AD FS
issues refresh token when the new refresh token lifetime is longer than previous refresh token lifetime. To view
additional information on AD FS refresh token lifetimes, visit AD FS Single Sign On Settings.

Host: https://adfs.contoso.com
&refresh_token=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq...
&grant_type=refresh_token
&client_secret=JqQX2PNo9bpM0uEihUPzyrh // NOTE: Only required for confidential clients (web apps)

grant_type required Must be refresh_token for this leg of

the authorization code flow.

customized.
scope optional A space-separated list of scopes.
refresh_token required The refresh_token that you acquired in

the second leg of the flow.
client_secret required for web apps The application secret that you created
in the app registration portal for your
app. It should not be used in a native
app, because client_secrets can't be
reliably stored on devices. It's required
for web apps and web APIs, which
have the ability to store the
client_secret securely on the server
side. These apps can also use a key
based authentication by signing a JWT
and adding that as client_assertion
parameter.
Successful response
{
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"expires_in": 3599,
"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}
access_token The requested access token. The app can use this token to
authenticate to the secured resource, such as a web API.
supports is Bearer
expires_in How long the access token is valid (in seconds).
scope The scopes that the access_token is valid for.

refresh_token An OAuth 2.0 refresh token. The app can use this token
acquire additional access tokens after the current access
token expires. Refresh_tokens are long-lived, and can be
used to retain access to resources for extended periods of
time.
refresh_token_expires_in How long the refresh token is valid (in seconds).
On-Behalf-Of flow
The OAuth 2.0 On-Behalf-Of flow (OBO) serves the use case where an application invokes a service/web API,
which in turn needs to call another service/web API. The idea is to propagate the delegated user identity and
permissions through the request chain. For the middle-tier service to make authenticated requests to the
downstream service, it needs to secure an access token from the AD FS, on behalf of the user.
Protocol diagram
Assume that the user has been authenticated on an application using theOAuth 2.0 authorization code grant
flow described above. At this point, the application has an access tokenfor API A(token A) with the user's claims
and consent to access the middle-tier web API (API A). Make sure the client requests for user_impersonation
scope in the token. Now, API A needs to make an authenticated request to the downstream web API (API B).
The steps that follow constitute the OBO flow and are explained with the help of the following diagram.
1. The client application makes a request to API A with token A. Note: While configuring OBO flow in AD FS
make sure scope user_impersonation is selected and client do request user_impersonation scope in the
request.
2. API A authenticates to the AD FS token issuance endpoint and requests a token to access API B. Note: While
configuring this flow in AD FS make sure API A is also registered as a server application with clientID having
the same value as the resource ID in API A.
3. The AD FS token issuance endpoint validates API A's credentials with token A and issues the access token for
API B (token B).
4. Token B is set in the authorization header of the request to API B.
5. Data from the secured resource is returned by API B.
Service -to -service access token request
To request an access token, make an HTTP POST to the AD FS token endpoint with the following parameters.
First case: Access token request with a shared secret
When using a shared secret, a service-to-service access token request contains the following parameters:
grant_type required The type of token request. For a

request using a JWT, the value must be
urn:ietf:params:oauth:grant-type:jwt-
bearer.
client_id required The Client ID that you configure when

registering your first Web API as a
server app (middle tier app). This
should be the same as the resource ID
used in the 1st leg i.e. url of the first
Web API.
client_secret required The application secret that you created

during sever app registration in AD FS.
assertion required The value of the token used in the

request.
requested_token_use required Specifies how the request should be

processed. In the OBO flow, the value
must be set to on_behalf_of
resource required The resource ID provided while

registering the first Web API as the
server app (middle tier App). The
resource ID should be the url of
second Web API middle tier App will
call on behalf of the client.
scope optional A space separated list of scopes for the

token request.
Example
The following HTTP POST requests an access token and refresh token
//line breaks for legibility only

Host: adfs.contoso.com
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id=https://webapi.com/
&client_secret=BYyVnAt56JpLwUcyo47XODd
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIm…
&resource=https://secondwebapi.com/
&requested_token_use=on_behalf_of
&scope=openid
Second case: Access token request with a certificate
A service-to-service access token request with a certificate contains the following parameters:
grant_type required The type of token request. For a

request using a JWT, the value must be
urn:ietf:params:oauth:grant-type:jwt-
bearer.
client_id required The Client ID that you configure when

registering your first Web API as a
server app (middle tier app). This
should be the same as the resource ID
used in the 1st leg i.e. url of the first
Web API.
client_assertion_type required The value must

beurn:ietf:params:oauth:client-
assertion-type:jwt-bearer.
client_assertion required An assertion (a JSON web token) that

you need to create and sign with the
certificate you registered as credentials
for your application.
assertion required The value of the token used in the

request.
requested_token_use required Specifies how the request should be

processed. In the OBO flow, the value
must be set to on_behalf_of
resource required The resource ID provided while

registering the first Web API as the
server app (middle tier App). The
resource ID should be the url of
second Web API middle tier App will
call on behalf of the client.
scope optional A space separated list of scopes for the

token request.
Notice that the parameters are almost the same as in the case of the request by shared secret except that
theclient_secret parameter is replaced by two parameters: client_assertion_typeandclient_assertion.
Example
The following HTTP POST requests an access token for theWeb API with a certificate.
// line breaks for legibility only

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id= https://webapi.com/
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNS…
&resource=https://secondwebapi.com/
&requested_token_use=on_behalf_of
&scope= openid
Service to service access token response

A success response is a JSON OAuth 2.0 response with the following parameters.
supports isBearer.
scope The scope of access granted in the token.
expires_in The length of time, in seconds, that the access token is valid.
access_token The requested access token. The calling service can use this
token to authenticate to the receiving service.
refresh_token The refresh token for the requested access token. The calling
service can use this token to request another access token
after the current access token expires.
Refresh_token_expires_in The length of time, in seconds, that the refresh token is valid.
Success response example

The following example shows a success response to a request for an access token for the web API.
{
"scope": openid,
"expires_in": 3269,
"access_token": "eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1t"
"id_token": "aWRfdG9rZW49ZXlKMGVYQWlPaUpLVjFRaUxDSmhiR2NpT2lKU1V6STFOa"
"refresh_token": "OAQABAAAAAABnfiG…"
}
Use the access token to access the secured resource Now the middle-tier service can use the token acquired
above to make authenticated requests to the downstream web API, by setting the token in
theAuthorizationheader.
Example
GET /v1.0/me HTTP/1.1

Host: https://secondwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1tQ…
Client credentials grant flow

You can use theOAuth 2.0 client credentials grantspecified in RFC 6749, to access web-hosted resources by
using the identity of an application. This type of grant is commonly used for server-to-server interactions that
must run in the background, without immediate interaction with a user. These types of applications are often
referred to asdaemonsorservice accounts.
The OAuth 2.0 client credentials grant flow permits a web service (confidential client) to use its own credentials,
instead of impersonating a user, to authenticate when calling another web service. In this scenario, the client is
typically a middle-tier web service, a daemon service, or a web site. For a higher level of assurance, the AD FS
also allows the calling service to use a certificate (instead of a shared secret) as a credential.
Protocol diagram
The following diagram shows the client credentials grant flow.
Request a token
To get a token by using the client credentials grant, send a POST request to the /token AD FS endpoint:
First case: Access token request with a shared secret

//Line breaks for clarity
client_id=535fb089-9ff3-47b6-9bfb-4f1264799865
&client_secret=qWgdYAmab0YSkuL1qKv5bPX
&grant_type=client_credentials

scope optional A space-separated list ofscopesthat

you want the user to consent to.
client_secret required The client secret that you generated

for your app in the app registration
portal. The client secret must be URL-
encoded before being sent.
grant_type required Must be set to client_credentials .
Second case: Access token request with a certificate
// Line breaks for clarity
&client_id=97e0a5b7-d745-40b6-94fe-5f77d35c6e05
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of
characters here}M8U3bSUKKJDEg
&grant_type=client_credentials
client_assertion_type required The value must be set

tourn:ietf:params:oauth:client-
assertion-type:jwt-bearer.
client_assertion required An assertion (a JSON web token) that

you need to create and sign with the
certificate you registered as credentials
for your application.
grant_type required Must be set to client_credentials .
client_id optional The Application (client) ID that theAD

FS assigned to your app. This is part of
client_assertion, so it is not required to
be passed in here.
scope optional A space-separated list ofscopesthat

you want the user to consent to.
Use a token
Now that you've acquired a token, use the token to make requests to the resource. When the token expires,
repeat the request to the /token endpoint to acquire a fresh access token.
GET /v1.0/me/messages
Host: https://webapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
Resource owner password credentials grant flow (Not recommended)

Resource owner password credential (ROPC) grant allows an application to sign in the user by directly handling
their password. The ROPC flow requires a high degree of trust and user exposure and you should only use this
flow when other, more secure, flows can't be used.
Protocol diagram
The following diagram shows the ROPC flow.
Authorization request
The ROPC flow is a single request—it sends the client identification and user's credentials to the IDP, and then
receives tokens in return. The client must request the user's email address (UPN) and password before doing so.
Immediately after a successful request, the client should securely release the user's credentials from memory. It
must never save them.
// Line breaks and spaces are for legibility only.

&scope= openid
&username=myusername@contoso.com
&password=SuperS3cret
&grant_type=password
client_id required Client ID
grant_type required Must be set topassword.
username required The user's email address.
password required The user's password.
scope optional A space-separated list ofscopes.
Successful authentication response

The following example shows a successful token response:
{
"scope": "openid",
"expires_in": 3599,
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIn...",
"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDR..."
}
token_type Always set toBearer.
scope If an access token was returned, this parameter lists the

scopes the access token is valid for.
expires_in Number of seconds that the included access token is valid

for.
access_token Issued for thescopesthat were requested.
refresh_token_expires_in Number of seconds that the included refresh token is valid

for.
refresh_token Issued if the originalscopeparameter includedoffline_access.
You can use the refresh token to acquire new access tokens and refresh tokens using the same flow described in
the auth code grant flow section above.
Device code flow

Device code grant allows users to sign in to input-constrained devices such as a smart TV, IoT device, or printer.
To enable this flow, the device has the user visit a webpage in their browser on another device to sign in. Once
the user signs in, the device is able to get access tokens and refresh tokens as needed.
Protocol diagram
The entire device code flow looks similar to the next diagram. We describe each of the steps later in this article.
Device authorization request

The client must first check with the authentication server for a device and user code that's used to initiate
authentication. The client collects this request from the/devicecodeendpoint. In this request, the client should
also include the permissions it needs to acquire from the user. From the moment this request is sent, the user
has only 15 minutes to sign in (the usual value forexpires_in), so only make this request when the user has
indicated they're ready to sign in.
// Line breaks are for legibility only.
POST https://adfs.contoso.com/adfs/oauth2/devicecode
scope=openid
PA RA M ET ER C O N DIT IO N DESC RIP T IO N

scope optional A space-separated list ofscopes.
Device authorization response

A successful response will be a JSON object containing the required information to allow the user to sign in.
device_code A long string used to verify the session between the client
and the authorization server. The client uses this parameter
to request the access token from the authorization server.
user_code A short string shown to the user that's used to identify the
session on a secondary device.
verification_uri The URI the user should go to with theuser_codein order to

sign in.
verification_uri_complete The URI the user should go to with theuser_codein order to

sign in. This is prefilled with user_code so that user doesn't
need to enter user_code
expires_in The number of seconds before

thedevice_codeanduser_codeexpire.
interval The number of seconds the client should wait between

polling requests.
message A human-readable string with instructions for the user. This

can be localized by including aquery parameterin the request
of the form?mkt=xx-XX, filling in the appropriate language
culture code.
Authenticating the user

After receiving theuser_codeandverification_uri, the client displays these to the user, instructing them to sign in
using their mobile phone or PC browser. Additionally, the client can use a QR code or similar mechanism to
display theverfication_uri_complete, which will take the step of entering theuser_codefor the user. While the user
is authenticating at theverification_uri, the client should be polling the/tokenendpoint for the requested token
using thedevice_code.
POST https://adfs.contoso.com /adfs/oauth2/token
grant_type: urn:ietf:params:oauth:grant-type:device_code
client_id: 6731de76-14a6-49ae-97bc-6eba6914391e
device_code: GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8
PA RA M ET ER REQ UIRED DESC RIP T IO N
grant_type required Must beurn:ietf:params:oauth:grant-

type:device_code
client_id required Must match theclient_idused in the

initial request.
code required Thedevice_codereturned in the device

authorization request.
Successful authentication response

token_type Always "Bearer.
scope If an access token was returned, this lists the scopes the
access token is valid for.
expires_in Number of seconds before the included access token is valid

for.
access_token Issued for thescopesthat were requested.
id_token Issued if the originalscopeparameter included

theopenidscope.
refresh_token Issued if the originalscopeparameter includedoffline_access.
refresh_token_expires_in Number of seconds before the included refresh token is valid

for.
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.
Build a Custom Authentication Method for AD FS in
Windows Server
This walkthrough provides instructions for implementing a custom authentication method for AD FS in
Windows Server 2012 R2. For more information, see Additional Authentication Methods.
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. There is no authentication back end,
error processing, or configuration data.
Setting up the development box

This walk-through uses Visual Studio 2012. The project can be built using any development environment that
can create a .NET class for Windows. The project must target .NET 4.5 because the BeginAuthentication and
Tr yEndAuthentication methods use the type System.Security.Claims.Claim , part of .NET Framework
version 4.5.There is one reference required for the project:
REF EREN C E DL L W H ERE TO F IN D IT REQ UIRED F O R
Microsoft.IdentityServer.Web.dll The dll is located in %windir%ADFS on Interface types including

a Windows Server 2012 R2 server on IAuthenticationContext, IProofData
which AD FS has been installed.
This dll must be copied to the
development machine and an
explicit reference created in the
project.
Create the provider

1. In Visual Studio 2012: Choose File->New->Project...
2. Select Class Library and be sure you are targeting .NET 4.5.
3. Make a copy of Microsoft.IdentitySer ver.Web.dll from %windir%ADFS on the Windows Server 2012
R2 server where AD FS has been installed and paste it in your Project folder on your development
machine.
4. In Solution Explorer , right click References and Add Reference...
5. Browse to your local copy of Microsoft.IdentitySer ver.Web.dll and Add...
6. Click OK to confirm the new reference:
You should now be set up to resolve all of the types required for the provider.
7. Add a new class to your project (Right click your project, Add...Class...) and give it a name like
MyAdapter , shown below:
8. In the new file MyAdapter.cs, replace the existing code with the following:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Globalization;
using System.IO;
using System.Net;
using System.Xml.Serialization;
using Microsoft.IdentityServer.Web.Authentication.External;
using Claim = System.Security.Claims.Claim;
namespace MFAadapter
{
class MyAdapter : IAuthenticationAdapter
{
public IAuthenticationAdapterMetadata Metadata
{
//get { return new <instance of IAuthenticationAdapterMetadata derived class>; }
}
public IAdapterPresentation BeginAuthentication(Claim identityClaim, HttpListenerRequest

request, IAuthenticationContext authContext)
{
//return new instance of IAdapterPresentationForm derived class
}
public bool IsAvailableForUser(Claim identityClaim, IAuthenticationContext authContext)

{
return true; //its all available for now
}
public void OnAuthenticationPipelineLoad(IAuthenticationMethodConfigData configData)

{
//this is where AD FS passes us the config data, if such data was supplied at
registration of the adapter
}
public void OnAuthenticationPipelineUnload()

{
public IAdapterPresentation OnError(HttpListenerRequest request,

ExternalAuthenticationException ex)
{
}
public IAdapterPresentation TryEndAuthentication(IAuthenticationContext authContext,

IProofData proofData, HttpListenerRequest request, out Claim[] outgoingClaims)
{
}
}
}
9. We are not ready to build yet... there are two more interfaces to go.
Add two more classes to your project: one is for the metadata, and the other for the presentation form.
You can add these within the same file as the class above.
class MyMetadata : IAuthenticationAdapterMetadata
{
class MyPresentationForm : IAdapterPresentationForm

{
10. Next, you can add the required members for each.First, the metadata (with helpful inline comments)

{
//Returns the name of the provider that will be shown in the AD FS management UI (not visible to
end users)
public string AdminName
{
get { return "My Example MFA Adapter"; }
}
//Returns an array of strings containing URIs indicating the set of authentication methods
implemented by the adapter
/// AD FS requires that, if authentication is successful, the method actually employed will be
returned by the
/// final call to TryEndAuthentication(). If no authentication method is returned, or the method
returned is not
/// one of the methods listed in this property, the authentication attempt will fail.
public virtual string[] AuthenticationMethods
{
get { return new[] { "http://example.com/myauthenticationmethod1",
"http://example.com/myauthenticationmethod2" }; }
}
/// Returns an array indicating which languages are supported by the provider. AD FS uses this
information
/// to determine the best language\locale to display to the user.
public int[] AvailableLcids
{
get
{
return new[] { new CultureInfo("en-us").LCID, new CultureInfo("fr").LCID};
}
}
/// Returns a Dictionary containing the set of localized friendly names of the provider, indexed
by lcid.
/// These Friendly Names are displayed in the "choice page" offered to the user when there is
more than
/// one secondary authentication provider available.
public Dictionary<int, string> FriendlyNames
{
get
{
Dictionary<int, string> _friendlyNames = new Dictionary<int, string>();
_friendlyNames.Add(new CultureInfo("en-us").LCID, "Friendly name of My Example MFA
Adapter for end users (en)");
_friendlyNames.Add(new CultureInfo("fr").LCID, "Friendly name translated to fr locale");
return _friendlyNames;
}
}
/// Returns a Dictionary containing the set of localized descriptions (hover over help) of the
provider, indexed by lcid.
/// These descriptions are displayed in the "choice page" offered to the user when there is more
than one
/// secondary authentication provider available.
public Dictionary<int, string> Descriptions
{
get
{
Dictionary<int, string> _descriptions = new Dictionary<int, string>();
_descriptions.Add(new CultureInfo("en-us").LCID, "Description of My Example MFA Adapter
for end users (en)");
_descriptions.Add(new CultureInfo("fr").LCID, "Description translated to fr locale");
return _descriptions;
}
}
/// Returns an array indicating the type of claim that the adapter uses to identify the user
being authenticated.
/// Note that although the property is an array, only the first element is currently used.
/// MUST BE ONE OF THE FOLLOWING
/// "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"
/// "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"
/// "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
/// "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"
public string[] IdentityClaims
{
get { return new[] { "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" }; }
}
//All external providers must return a value of "true" for this property.
public bool RequiresIdentity
{
get { return true; }
}
}
Now you should be able to F12 (right click – Go To Definition) on IAuthenticationAdapter to see the set of
required interface members.
Next, you can do a simple implementation of these.
11. Replace the entire contents of your class with the following:
namespace MFAadapter
{
{
{
}
public IAdapterPresentation BeginAuthentication(Claim identityClaim, HttpListenerRequest

request, IAuthenticationContext authContext)
{
}

{
}

{
//this is where AD FS passes us the config data, if such data was supplied at
registration of the adapter
}

{
public IAdapterPresentation OnError(HttpListenerRequest request,

ExternalAuthenticationException ex)
{
}
public IAdapterPresentation TryEndAuthentication(IAuthenticationContext authContext,

IProofData proofData, HttpListenerRequest request, out Claim[] outgoingClaims)
{
}
}
}
12. We are not ready to build yet... there are two more interfaces to go.
Add two more classes to your project: one is for the metadata, and the other for the presentation form.
You can add these within the same file as the class above.

{
}
{
}
13. Next, you can add the required members for each.First, the metadata (with helpful inline comments)

{
//Returns the name of the provider that will be shown in the AD FS management UI (not visible to
end users)
{
get { return "My Example MFA Adapter"; }
}
//Returns an array of strings containing URIs indicating the set of authentication methods
implemented by the adapter
/// AD FS requires that, if authentication is successful, the method actually employed will be
returned by the
/// final call to TryEndAuthentication(). If no authentication method is returned, or the method
returned is not
/// one of the methods listed in this property, the authentication attempt will fail.
public virtual string[] AuthenticationMethods
{
get { return new[] { "http://example.com/myauthenticationmethod1",
"http://example.com/myauthenticationmethod2" }; }
}
/// Returns an array indicating which languages are supported by the provider. AD FS uses this
information
/// to determine the best languagelocale to display to the user.
public int[] AvailableLcids
{
get
{
return new[] { new CultureInfo("en-us").LCID, new CultureInfo("fr").LCID};
}
}
/// Returns a Dictionary containing the set of localized friendly names of the provider, indexed
by lcid.
/// These Friendly Names are displayed in the "choice page" offered to the user when there is
more than
/// one secondary authentication provider available.
public Dictionary<int, string> FriendlyNames
{
get
{
Dictionary<int, string> _friendlyNames = new Dictionary<int, string>();
_friendlyNames.Add(new CultureInfo("en-us").LCID, "Friendly name of My Example MFA
Adapter for end users (en)");
_friendlyNames.Add(new CultureInfo("fr").LCID, "Friendly name translated to fr locale");
return _friendlyNames;
}
}
/// Returns a Dictionary containing the set of localized descriptions (hover over help) of the
provider, indexed by lcid.
/// These descriptions are displayed in the "choice page" offered to the user when there is more
than one
/// secondary authentication provider available.
public Dictionary<int, string> Descriptions
{
get
{
Dictionary<int, string> _descriptions = new Dictionary<int, string>();
_descriptions.Add(new CultureInfo("en-us").LCID, "Description of My Example MFA Adapter
for end users (en)");
_descriptions.Add(new CultureInfo("fr").LCID, "Description translated to fr locale");
return _descriptions;
}
}
/// Returns an array indicating the type of claim that the adapter uses to identify the user
being authenticated.
/// Note that although the property is an array, only the first element is currently used.
/// MUST BE ONE OF THE FOLLOWING
/// "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"
/// "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"
/// "https://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"
public string[] IdentityClaims
{
get { return new[] { "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" }; }
}
//All external providers must return a value of "true" for this property.
public bool RequiresIdentity
{
get { return true; }
}
}
Next, the presentation form:

{
/// Returns the HTML Form fragment that contains the adapter user interface. This data will be
included in the web page that is presented
/// to the cient.
public string GetFormHtml(int lcid)
{
string htmlTemplate = Resources.FormPageHtml; //todo we will implement this
return htmlTemplate;
}
/// Return any external resources, ie references to libraries etc., that should be included in
/// the HEAD section of the presentation form html.
public string GetFormPreRenderHtml(int lcid)
{
return null;
}
//returns the title string for the web page which presents the HTML form content to the end user
public string GetPageTitle(int lcid)
{
return "MFA Adapter";
}
}
14. Note the 'todo' for the Resources.FormPageHtml element above. You can fix it in a minute, but first
let's add the final required return statements, based on the newly implemented types, to your initial
MyAdapter class. To do this, add the following to your existing IAuthenticationAdapter implementation:
{
{
get { return new MyMetadata(); }
}
public IAdapterPresentation BeginAuthentication(Claim identityClaim, HttpListenerRequest request,

IAuthenticationContext authContext)
{
return new MyPresentationForm();
}

{
}

{
//this is where AD FS passes us the config data, if such data was supplied at registration of
the adapter
}

{
public IAdapterPresentation OnError(HttpListenerRequest request, ExternalAuthenticationException

ex)
{
}
public IAdapterPresentation TryEndAuthentication(IAuthenticationContext authContext, IProofData

proofData, HttpListenerRequest request, out Claim[] outgoingClaims)
{
outgoingClaims = new Claim[0];
}
15. Now for the resource file containing the html fragment. Create a new text file in your project folder with
the following contents:
<div id="loginArea">
<form method="post" id="loginForm" >

<input id="authMethod" type="hidden" name="AuthMethod" value="%AuthMethod%" />
<input id="context" type="hidden" name="Context" value="%Context%" />

<p id="pageIntroductionText">This content is provided by the MFA sample adapter. Challenge
inputs should be presented below.</p>
<label for="challengeQuestionInput" class="block">Question text</label>
<input id="challengeQuestionInput" name="ChallengeQuestionAnswer" type="text" value=""
class="text" placeholder="Answer placeholder" />
<div id="submissionArea" class="submitMargin">
<input id="submitButton" type="submit" name="Submit" value="Submit" onclick="return
AuthPage.submitAnswer()"/>
</div>
</form>
<div id="intro" class="groupMargin">
<p id="supportEmail">Support information</p>
</div>
<script type="text/javascript" language="JavaScript">
//<![CDATA[
function AuthPage() { }
AuthPage.submitAnswer = function () { return true; };
//]]>
</script>
</div>
16. Then, select Project->Add Component... Resources file and name the file Resources , and click Add:
17. Then, within the Resources.resx file, choose Add Resource...Add existing file . Navigate to the text file
(containing the html fragment) that you saved above.
Ensure your GetFormHtml code resolves the name of the new resource correctly by the resources file
(.resx file) name prefix followed by the name of the resource itself:
public string GetFormHtml(int lcid)
{
string htmlTemplate = Resources.MfaFormHtml; //Resxfilename.resourcename
return htmlTemplate;
}
You should now be able to build.
Build the adapter

The adapter should be built into a strongly named .NET assembly that can be installed into the GAC in Windows.
To achieve this in a Visual Studio project, complete the following steps:
1. Right click your project name in Solution Explorer and click Proper ties .
2. On the Signing tab, check Sign the assembly and choose <New...> under Choose a strong name
key file: Enter a key file name and password and click OK . Then ensure Sign the assembly is checked
and Delay sign only is unchecked. The properties Signing page should look like this:
3. Then build the solution.
Deploy the adapter to your AD FS test machine

Before an external provider can be invoked by AD FS, it must be registered in the system. Adapter providers
must provide an installer which performs the necessary installation actions including installation in the GAC,
and the installer must support registration in AD FS. If that is not done, the administrator needs to execute the
Windows PowerShell steps below. These steps can be used in the lab to enable testing and debugging.
Prepare the test AD FS machine
Copy files and add to GAC.
1. Ensure you have a Windows Server 2012 R2 computer or virtual machine.
2. Install the AD FS role service and configure a farm with at least one node.
For detailed steps to setup a federation server in a lab environment, see the Windows Server 2012 R2 AD
FS Deployment Guide.
3. Copy the Gacutil.exe tools to the server.
Gacutil.exe can be found in %homedrive%Program Files (x86)Microsoft
SDKsWindowsv8.0AbinNETFX 4.0 Tools on a Windows 8 machine. You will need the gacutil.exe file
itself as well as the 1033 , en-US , and the other localized resource folder below the NETFX 4.0 Tools
location.
4. Copy your provider file(s) (one or more strong name signed .dll files) to the same folder location as
gacutil.exe (the location is just for convenience)
5. Add your .dll file(s) to the GAC on each AD FS federation server in the farm:
Example: using command line tool GACutil.exe to add a dll to the GAC:
C:>.gacutil.exe /if .<yourdllname>.dll
To view the resulting entry in the GAC: C:>.gacutil.exe /l <yourassemblyname>
Register your provider in AD FS

Once the above pre-requisites are met, open a Windows PowerShell command window on your federation
server and enter the following commands (note that if you are using federation server farm that uses Windows
Internal Database, you must execute these commands on the primary federation server of the farm):
Register-AdfsAuthenticationProvider –TypeName YourTypeName –Name “AnyNameYouWish” [–
1. ConfigurationFilePath (optional)]
Where YourTypeName is your .NET strong type name:

"YourDefaultNamespace.YourIAuthenticationAdapterImplementationClassName, YourAssemblyName,
Version=YourAssemblyVersion, Culture=neutral, PublicKeyToken=YourPublicKeyTokenValue,
processorArchitecture=MSIL"
This will register your external provider in AD FS, with the Name you provided as AnyNameYouWish
above.
2. Restart the AD FS service (using the Windows Services snap-in, for example).
3. Run the following command: Get-AdfsAuthenticationProvider .
This shows your provider as one of the providers in the system.
Example:
$typeName = "MFAadapter.MyAdapter, MFAadapter, Version=1.0.0.0, Culture=neutral,

PublicKeyToken=e675eb33c62805a0, processorArchitecture=MSIL”
Register-AdfsAuthenticationProvider -TypeName $typeName -Name “MyMFAAdapter”
net stop adfssrv
net start adfssrv
If you have the device registration service enabled in your AD FS environment, also execute the following
PowerShell command: net start drs
To verify the registered provider, use the following PowerShell command: Get-AdfsAuthenticationProvider .
This shows your provider as one of the providers in the system.
Create the AD FS authentication policy that invokes your adapter
Create the authentication policy using the AD FS Management snap-in
1. Open the AD FS Management snap-in (from the Server Manager Tools menu).
2. Click Authentication Policies .
3. In the center pane, under Multi-Factor Authentication , click the Edit link to the right of Global
Settings .
4. Under Select additional authentication methods at the bottom of the page, check the box for your
provider's AdminName. Click Apply .
5. To provide a “trigger” to invoke MFA using your adapter, under Locations check both Extranet and
Intranet , for example. Click OK . (To configure triggers per relying party, see “Create the authentication
policy using Windows PowerShell” below.)
6. Check the results using the following commands:
First use Get-AdfsGlobalAuthenticationPolicy . You should see your provider Name as one of the
AdditionalAuthenticationProvider values.
Then use Get-AdfsAdditionalAuthenticationRule . You should see the rules for Extranet and Intranet
configured as a result of your policy selection in the administrator UI.
Create the authentication policy using Windows PowerShell
1. First, enable the provider in global policy:
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider “YourAuthProviderName”`
NOTE
Note that the value provided for the AdditionalAuthenticationProvider parameter corresponds to the value you
provided for the “Name” parameter in the Register-AdfsAuthenticationProvider cmdlet above and to the “Name”
property from Get-AdfsAuthenticationProvider cmdlet output.
Set-AdfsGlobalAuthenticationPolicy –AdditionalAuthenticationProvider “MyMFAAdapter”`
2. Next, configure global or relying-party-specific rules to trigger MFA:

Example 1: to create global rule to require MFA for External requests:
Set-AdfsAdditionalAuthenticationRule –AdditionalAuthenticationRules 'c:[type ==

"http://schemas.microsoft.com/claims/multipleauthn" );'
Example 2: to create MFA rules to require MFA for external requests to a specific relying party. (Note that
individual providers cannot be connected to individual relying parties in AD FS in Windows Server 2012
R2).
$rp = Get-AdfsRelyingPartyTrust –Name <Relying Party Name>

Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules 'c:[type ==
"http://schemas.microsoft.com/claims/multipleauthn" );'
Authenticate with MFA using your adapter

Finally, perform the steps below to test your adapter:
1. Ensure the AD FS global Primary authentication type is configured as Forms Authentication for both
Extranet and Intranet (this makes your demo easier to authenticate as a specific user)
a. In the AD FS snap-in, under Authentication Policies , in the Primar y Authentication area, click
Edit next to Global Settings .
a. Or just click the Primar y tab from the Multi-factor policy UI.
2. Ensure Forms Authentication is the only option checked for both the Extranet and the Intranet
authentication method. Click OK .
3. Open the IDP initiated sign-on html page (https://<fsname>/adfs/ls/idpinitiatedsignon.htm) and sign in
as a valid AD user in your test environment.
4. Enter credentials for primary authentication.
5. You should see the MFA forms page with example challenge questions appear.
If you have more than one adapter configured, you will see the MFA choice page with your friendly name
from above.
You now have a working implementation of the interface and you have the knowledge of how the model works.
You can try as an extra example to set break points in the BeginAuthentication as well as the
TryEndAuthentication. Notice how BeginAuthentication is executed when the user first enters the MFA form,
whereas TryEndAuthentication is triggered at each Submit of the form.
Update the adapter for successful authentication

But wait – your example adapter will never successfully authenticate! This is because nothing in your code
returns null for TryEndAuthentication.
By completing the procedures above, you created a basic adapter implementation and added it to an AD FS
server. You can get the MFA forms page, but you cannot yet authenticated because you have not yet put the
correct logic in your TryEndAuthentication implementation. So let's add that.
Recall your TryEndAuthentication implementation:
public IAdapterPresentation TryEndAuthentication(IAuthenticationContext authContext, IProofData proofData,
HttpListenerRequest request, out Claim[] outgoingClaims)
{
}
Let's update it so it doesn't always return MyPresentationForm(). For this you can create one simple utility
method within your class:
static bool ValidateProofData(IProofData proofData, IAuthenticationContext authContext)

{
if (proofData == null || proofData.Properties == null ||
!proofData.Properties.ContainsKey("ChallengeQuestionAnswer"))
{
throw new ExternalAuthenticationException("Error - no answer found", authContext);
}
if ((string)proofData.Properties["ChallengeQuestionAnswer"] == "adfabric")
{
return true;
}
else
{
return false;
}
}
Then, update TryEndAuthentication as below:
public IAdapterPresentation TryEndAuthentication(IAuthenticationContext authContext, IProofData proofData,

HttpListenerRequest request, out Claim[] outgoingClaims)
{
if (ValidateProofData(proofData, authContext))
{
//authn complete - return authn method
outgoingClaims = new[]
{
// Return the required authentication method claim, indicating the particulate authentication
method used.
new Claim( "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod",
"http://example.com/myauthenticationmethod1" )
};
return null;
}
else
{
//authentication not complete - return new instance of IAdapterPresentationForm derived class
}
}
Now you have to update the adapter on the test box. You must first undo the AD FS policy, then un-register from
AD FS and restart AD FS, then remove the .dll from the GAC, then add the new .dll to the GAC, then register it in
AD FS, restart AD FS, and re-configure AD FS policy.
Deploy and configure the updated adapter on your test AD FS

machine
Clear AD FS Policy
Clear all MFA related checkboxes in the MFA UI, shown below, then click OK.
Unregister provider (Windows PowerShell)

PS C:> Unregister-AdfsAuthenticationProvider –Name “YourAuthProviderName”
Example: PS C:> Unregister-AdfsAuthenticationProvider –Name “MyMFAAdapter”
Note that the value you pass for “Name” is the same value as “Name” you provided to the Register-
AdfsAuthenticationProvider cmdlet. It is also the “Name” property that is output from Get-
AdfsAuthenticationProvider.
Note that before you unregister a provider, you must remove the provider from the
AdfsGlobalAuthenticationPolicy (either by clearing the checkboxes you checked in AD FS management snap-in
or by using Windows PowerShell.)
Note that the AD FS service must be restarted after this operation.
Remove assembly from GAC
1. First, use the following command to find the fully qualified strong name of the entry:
C:>.gacutil.exe /l <yourAdapterAssemblyName>
Example: C:>.gacutil.exe /l mfaadapter
2. Then, use the following command to remove it from the GAC:

.gacutil /u “<output from the above command>”
Example:
C:>.gacutil /u “mfaadapter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e675eb33c62805a0,
processorArchitecture=MSIL”
Add the updated assembly to GAC

Make sure you paste the updated .dll locally first. C:>.gacutil.exe /if .MFAAdapter.dll
View assembly in the GAC (cmd line )

C:> .gacutil.exe /l mfaadapter
Register your provider in AD FS

PS C:>$typeName = "MFAadapter.MyAdapter, MFAadapter, Version=1.0.0.1, Culture=neutral,
1. PublicKeyToken=e675eb33c62805a0, processorArchitecture=MSIL”
2. PS C:>Register-AdfsAuthenticationProvider -TypeName $typeName -Name “MyMFAAdapter1”
3. Restart the AD FS service.

Create the authentication policy using the AD FS Management snap-in
1. Open the AD FS Management snap-in (from the Server Manager Tools menu).
2. Click Authentication Policies .
3. Under Multi-Factor Authentication , click the Edit link to the right of Global Settings .
4. Under Select additional authentication methods , check the box for your provider's AdminName.
Click Apply .
5. To provide a “trigger” to invoke MFA using your adapter, under Locations check both Extranet and
Intranet , for example. Click OK .
Authenticate with MFA using your adapter
Finally, perform the steps below to test your adapter:
1. Ensure the AD FS global Primary authentication type is configured as Forms Authentication for both
Extranet and Intranet (this makes it easier to authenticate as a specific user).
a. In the AD FS management snap-in, under Authentication Policies , in the Primar y
Authentication area, click Edit next to Global Settings .
a. Or just click the Primar y tab from the Multi-factor policy UI.
2. Ensure Forms Authentication is the only option checked for both the Extranet and the Intranet
authentication method. Click OK .
3. Open the IDP initiated sign-on html page (https://<fsname>/adfs/ls/idpinitiatedsignon.htm) and sign in
as a valid AD user in your test environment.
4. Enter the credentials for primary authentication.
5. You should see the MFA forms page with example challenge text appear.
a. If you have more than one adapter configured, you will see the MFA choice page with your friendly
name.
You should see a successful sign-in when entering adfabric at the MFA authentication page.
See Also
Other Resources
Additional Authentication Methods Manage Risk with Additional Multi-Factor Authentication for Sensitive
Applications
Build Plug-ins with AD FS 2019 Risk Assessment
Model
You can now build your own plug-ins to block or assign a risk score to authentication requests during various
stages – request received, pre-authentication and post-authentication. This can be accomplished using the new
Risk Assessment Model introduced with AD FS 2019.
What is the Risk Assessment Model?

The Risk Assessment Model is a set of interfaces and classes which enable developers to read authentication
request headers and implement their own risk assessment logic. The implemented code (plug-in) then runs in
line with AD FS authentication process. For example, using the interfaces and classes included with the model,
you can implement code to either block or allow authentication request based on the client IP address included
in the request header. AD FS will execute the code for each authentication request and take appropriate action as
per the implemented logic.
The model allows to plug-in code at any of three stages of AD FS authentication pipeline as shown below:
1. Request Received Stage – Enables building plug-ins to allow or block request when AD FS receives the
authentication request i.e. before user enters credentials. You can use the request context (for example:
client IP, Http method, proxy server DNS, etc.) available at this stage to perform the risk assessment. For
example, you can build a plug-in to read the IP from the request context and block the authentication
request if the IP is in the pre-defined list of risky IPs.
2. Pre-Authentication Stage – Enables building plug-ins to allow or block request at the point where user
provides the credentials but before AD FS evaluates them. At this stage, in addition to the request context
you also have information on the security context (for example: user token, user identifier, etc) and the
protocol context (for example: authentication protocol, clientID, resourceID, etc) to use in your risk
assessment logic. For example, you can build a plug-in to prevent password spray attacks by reading the
user password from the user token and blocking the authentication request if the password is in the pre-
defined list of risky passwords.
3. Post-Authentication – Enables building plug-in to assess risk after user has provided credentials and
AD FS has performed authentication. At this stage, in addition to the request context, security context, and
protocol context, you also have information on the authentication result (Success or Failure). The plug-in
can evaluate the risk score based on the available information and pass the risk score to claim and policy
rules for further evaluation.
To better understand how to build a risk assessment plug-in and run it in line with AD FS process, let's build a
sample plug-in that blocks the requests coming from certain extranet IPs identified as risky, register the plug-in
with AD FS and finally test the functionality.
NOTE
Alternatively, you can build Risky User Plug-in, a sample plug-in that leverages user risk level determined by Azure AD
Identity Protection to block authentication or enforce multi-factor authentication (MFA). Steps to build Risky User Plug-in
are available here.
Building a sample plug-in

NOTE
This walkthrough is only to show you how you can create a sample plug-in. The solution we are creating is by no means
an Enterprise-ready solution.
Pre -requisites
Following is the list of pre-requisites required to build this sample plug-in:
AD FS 2019 installed and configured
.NET Framework 4.7 and above
Visual Studio
Build plug-in dll
The following procedure will walk you through building a sample plug-in dll:
1. Download the sample plug-in, use Git Bash and type the following:
git clone https://github.com/Microsoft/adfs-sample-RiskAssessmentModel-RiskyIPBlock
2. Create a .csv file at any location on your AD FS server (in my case, I created the authconfigdb.csv file at
C:\extensions ) and add the IPs you want to block to this file.
The sample plug-in will block any authentication requests coming from the Extranet IPs listed in this file.
NOTE
If you have an AD FS Farm, you can create the file on any or all the AD FS servers. Any of the files can be used to
import the risky IPs into AD FS. We will discuss the import process in detail in the Register the plug-in dll with AD
FS section below.
3. Open the project ThreatDetectionModule.sln using Visual Studio.

4. Remove the Microsoft.IdentityServer.dll from the Solutions Explorer as shown below:
5. Add reference to the Microsoft.IdentityServer.dll of your AD FS as shown below:
a. Right click on References in Solutions Explorer and select Add Reference… .
b. On the Reference Manager window, select Browse . In the Select the files to reference… dialogue,
select Microsoft.IdentityServer.dll from your AD FS installation folder (in my case
C:\Windows\ADFS ) and click Add .
NOTE
In my case, I am building the plug-in on the AD FS server itself. If your development environment is on a different
server, copy the Microsoft.IdentityServer.dll from your AD FS installation folder on AD FS server on to your
development box.
c. Click OK on the Reference Manager window after making sure the Microsoft.IdentityServer.dll
check box is selected.
6. All the classes and references are now in place to do a build. However, since the output of this project is a
dll, it will have to be installed into the Global Assembly Cache , or GAC, of the AD FS server and the dll
needs to be signed first. This can be done as follows:
a. Right-click on the name of the project, ThreatDetectionModule. From the menu, click Proper ties .
b. From the Proper ties page, click Signing , on the left, and then check the check box marked Sign the
assembly . From the Choose a strong name key file: pull down menu, select <New...> .
c. In the Create Strong Name Key dialogue , type a name (you can choose any name) for the key,
uncheck the check box Protect my key file with password . Then, click OK .
d. Save the project as shown below:
7. Build the project by clicking Build and then Rebuild Solution as shown below:
Check the Output window at the bottom of the screen, to see if any errors occurred.
The plug-in (dll) is now ready for use and is in the \bin\Debug folder of the project folder (in my case, that's
C:\extensions\ThreatDetectionModule\bin\Debug\ThreatDetectionModule.dll ).
The next step is to register this dll with AD FS, so it runs in line with the AD FS authentication process.
Register the plug-in dll with AD FS
We need to register the dll in AD FS by using the Register-AdfsThreatDetectionModule PowerShell command on
the AD FS server. However, before we register, we need to get the Public Key Token. This public key token was
created when we created the key and signed the dll using that key. To learn what the Public Key Token for the dll
is, you can use the SN.exe as follows:
1. Copy the dll file from the \bin\Debug folder to another location (in my case, copying it to
C:\extensions ).
2. Start the Developer Command Prompt for Visual Studio and go to the directory containing the sn.exe
(in my case, the directory is C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX
4.7.2 Tools ).
3. Run the SN command with the -T parameter and the location of the file (in my case
SN -T "C:\extensions\ThreatDetectionModule.dll" ).
The command will provide you the public key token (For me, the Public Key Token is
714697626ef96b35 )
4. Add the dll to the Global Assembly Cache of the AD FS server Our best practice would be that you
create a proper installer for your project and use the installer to add the file to the GAC. Another solution
is to use Gacutil.exe (more information on Gacutil.exe available here) on your development machine.
Since I have my visual studio on the same server as AD FS, I will be using Gacutil.exe as follows:
a. On Developer Command Prompt for Visual Studio and go to the directory containing the Gacutil.exe
(in my case, the directory is C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX
4.7.2 Tools ).
b. Run the Gacutil command (in my case Gacutil /IF C:\extensions\ThreatDetectionModule.dll ):
NOTE
If you have an AD FS farm, the above needs to be executed on each AD FS server in the farm.
5. Open Windows PowerShell and run the following command to register the dll:
Register-AdfsThreatDetectionModule -Name "<Add a name>" -TypeName "<class name that implements

interface>, <dll name>, Version=10.0.0.0, Culture=neutral, PublicKeyToken=< Add the Public Key Token
from Step 2. above>" -ConfigurationFilePath "<path of the .csv file>"
In my case, the command is:
Register-AdfsThreatDetectionModule -Name "IPBlockPlugin" -TypeName

"ThreatDetectionModule.UserRiskAnalyzer, ThreatDetectionModule, Version=10.0.0.0, Culture=neutral,
PublicKeyToken=714697626ef96b35" -ConfigurationFilePath "C:\extensions\authconfigdb.csv"
NOTE
You need to register the dll only once, even if you have an AD FS farm.
6. Restart the AD FS service after registering the dll.

That's it, the dll is now registered with AD FS and ready for use!
NOTE
If any changes are made to the plugin and the project is rebuilt, then the updated dll needs to be registered again. Before
registering, you will need to unregister the current dll using the following command:
UnRegister-AdfsThreatDetectionModule -Name "<name used while registering the dll in 5. above>"
UnRegister-AdfsThreatDetectionModule -Name "IPBlockPlugin"
Testing the plug-in

1. Open the authconfig.csv file we created earlier (in my case at location C:\extensions ) and add the
Extranet IPs you want to block. Every IP should be on a separate line and there should be no spaces at
the end.

3. Import the updated file in AD FS by running the following PowerShell command:
Import-AdfsThreatDetectionModuleConfiguration -name "<name given while registering the dll>" -

ConfigurationFilePath "<path of the .csv file>"

Import-AdfsThreatDetectionModuleConfiguration -name "IPBlockPlugin" -ConfigurationFilePath
"C:\extensions\authconfigdb.csv")
4. Initiate authentication request from the server with the same IP you added in authconfig.csv .
For this demonstration, I will be using AD FS Help Claims X-Ray tool to initiate a request. If you would like
to use the X-Ray tool, please follow the instructions
Enter federation server instance and hit Test Authentication button.
5. Authentication is blocked as shown below.
Now that we know how to build and register the plug-in, let's walkthrough the plug-in code to understand the
implementation using the new interfaces and classes introduced with the model.
Plug-in code walkthrough

Open the project ThreatDetectionModule.sln using Visual Studio and then open the main file
UserRiskAnalyzer.cs from the Solutions Explorer on the right of the screen
The file contains the main class UserRiskAnalyzer which implements the abstract class ThreatDetectionModule
and interface IRequestReceivedThreatDetectionModule to read the IP from the request context, compare the
obtained IP with the IPs loaded from AD FS DB, and block request if there is an IP match. Let's go over these
types in more detail
ThreatDetectionModule abstract class
This abstract class loads the plug-in into AD FS pipeline making it possible to run the plug-in code in line with
AD FS process.
public abstract class ThreatDetectionModule

{
protected ThreatDetectionModule();
public abstract string VendorName { get; }

public abstract string ModuleIdentifier { get; }
public abstract void OnAuthenticationPipelineLoad(ThreatDetectionLogger logger,

ThreatDetectionModuleConfiguration configData);
public abstract void OnAuthenticationPipelineUnload(ThreatDetectionLogger logger);
public abstract void OnConfigurationUpdate(ThreatDetectionLogger logger,
ThreatDetectionModuleConfiguration configData);
}
The class includes the following methods and properties:
M ET H O D TYPE DEF IN IT IO N
OnAuthenticationPipelineLoad Void Called by AD FS when the plugin is

loaded into its pipeline
OnAuthenticationPipelineUnload Void Called by AD FS when the plugin is

unloaded from its pipeline
OnConfigurationUpdate Void Called by AD FS on config update
Proper ty Type Definition
VendorName String Gets the name of the vendor owning

the plugin
ModuleIdentifier String Gets the identifier of the plugin
In our sample plugin, we are using OnAuthenticationPipelineLoad and OnConfigurationUpdate methods to read
the pre-defined IPs from AD FS DB. OnAuthenticationPipelineLoad is called when plug-in is registered with AD
FS while OnConfigurationUpdate is called when the .csv is imported using the
Import-AdfsThreatDetectionModuleConfiguration cmdlet.
IRequestReceivedThreatDetectionModule Interface
This interface enables you to implement risk assessment at the point where AD FS receives the authentication
request, but before user enters credentials i.e. at Received Request stage of the authentication process.
public interface IRequestReceivedThreatDetectionModule
{
Task<ThrottleStatus> EvaluateRequest (
ThreatDetectionLogger logger,
RequestContext requestContext );
}
The interface includes EvaluateRequest method which allows you to use the context of the authentication
request passed in the requestContext input parameter to write your risk assessment logic. The requestContext
parameter is of type RequestContext.
The other input parameter passed is logger which is type ThreatDetectionLogger. The parameter can be used to
write the error, audit and/or debug messages to AD FS logs.
The method returns ThrottleStatus (0 if NotEvaluated, 1 to Block, and 2 to Allow) to AD FS which then either
blocks or allows the request.
In our sample plug-in, EvaluateRequest method implementation parses the clientIpAddress from the
requestContext parameter and compares it with all the IPs loaded from the AD FS DB. If a match is found,
method returns 2 for Block , else it returns 1 for Allow . Based on the returned value, AD FS either blocks or
allows the request.
NOTE
The sample plug-in discussed above implements only IRequestReceivedThreatDetectionModule interface. However, the
risk assessment model provides two additional interfaces –IPreAuthenticationThreatDetectionModule (to implement risk
assessment logic duing pre-authentication stage) and IPostAuthenticationThreatDetectionModule (to implement risk
assessment logic during post-authentication stage). The details on the two interfaces are provided below.
IPreAuthenticationThreatDetectionModule Interface
This interface enables you to implement risk assessment logic at the point where user provides the credentials
but before AD FS evaluates them i.e. pre-authentication stage.
public interface IPreAuthenticationThreatDetectionModule

{
Task<ThrottleStatus> EvaluatePreAuthentication (
RequestContext requestContext,
SecurityContext securityContext,
ProtocolContext protocolContext,
IList<Claim> additionalClams
);
}
The interface includes EvaluatePreAuthentication method which allows you to use the information passed in the
RequestContext requestContext, SecurityContext securityContext, ProtocolContext protocolContext, and IList
additionalClams input parameters to write your pre-authentication risk assessment logic.
NOTE
For list of properties passed with each context type, visit RequestContext, SecurityContext, and ProtocolContext class
definitions.
The method returns ThrottleStatus (0 if NotEvaluated, 1 to Block, and 2 to Allow) to AD FS which then either
blocks or allows the request.
IPostAuthenticationThreatDetectionModule Interface
This interface enables you to implement risk assessment logic after user has provided credentials and AD FS has
performed authentication i.e. post-authentication stage.
public interface IPostAuthenticationThreatDetectionModule

{
Task<RiskScore> EvaluatePostAuthentication (
RequestContext requestContext,
SecurityContext securityContext,
ProtocolContext protocolContext,
AuthenticationResult authenticationResult,
IList<Claim> additionalClams
);
}
The interface includes EvaluatePostAuthentication method which allows you to use the information passed in
the RequestContext requestContext, SecurityContext securityContext, ProtocolContext protocolContext, and IList
additionalClams input parameters to write your post-authentication risk assessment logic.
NOTE
For complete list of properties passed with each context type, refer RequestContext, SecurityContext, and ProtocolContext
class definitions.
The method returns the Risk Score which can be used in AD FS policy and claim rules.
NOTE
For plug-in to work, the main class (in this case UserRiskAnalyzer) needs to derive ThreatDetectionModule abstract class
and should implement at least one of the three interfaces described above. Once the dll is registered, AD FS checks which
of the interfaces are implemented and calls them at appropriate stage in the pipeline.
FAQs
Why should I build these plug-ins?
A: These plug-ins not only provide you additional capability to secure your environment from attacks such as
password spray attacks, but also give you the flexibility to build your own risk assessment logic based on your
requirements.
Where are the logs captured?
A: You can write error logs to "AD FS/Admin" event log using WriteAdminLogErrorMessage method, audit logs
to "AD FS Auditing" security log using WriteAuditMessage method and debug logs to "AD FS Tracing" debug log
using WriteDebugMessage method.
Can adding these plug-ins increase AD FS authentication process latency?
A: Latency impact will be determined by the time taken to execute the risk assessment logic you implement. We
recommend evaluating the latency impact before deploying the plug-in in production environment.
Why can't AD FS suggest the list of risky IPs, users, etc.?
A: Though not currently available, we are working on building the intelligence to suggest risky IPs, users, etc. in
the Pluggable Risk Assessment Model. We will share the launch dates soon.
What other sample plug-ins are available?
A: The following sample plug-in(s) are available:
NAME DESC RIP T IO N
Risky User Plug-in Sample plug-in that blocks authentication or enforces MFA
based on user risk level determined by Azure AD Identity
Protection.
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
Customize claims to be emitted in id_token when
using OpenID Connect or OAuth with AD FS 2016
or later
Overview
The article here shows you 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 and later releases have the
capability to customize the id_token in OpenID Connect scenarios.
When are custom ID tokens 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 (Web API identifier) should be the same as the client identifier
Scenario 2
With KB4019472 or later security update installed on your AD FS servers
1. response_mode is set as form_post
2. Both public and confidential clients can get custom claims in ID token
3. 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 and configuring an OAuth application to handle custom

claims in ID token
Follow the steps below to create and configure the application in AD FS for receiving ID token with custom
claims.
Create and configure an Application Group in AD FS 2016 or later
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 Client-Server applications
select the Native application accessing a web application 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 Web API screen, enter the following for Identifier -
https://contoso.com/WebApp . Click Add . Click Next . This value will be used later for ida:ResourceID
in the applications web.config file.
6. On the Choose Access Control Policy screen, select Permit ever yone and click Next .
7. On the Configure Application Permissions screen, make sure openid and allatclaims are selected
and click Next .
8. On the Summar y screen, click Next .
9. On the Complete screen, click Close .

10. In AD FS Management, click on Application Groups to get list of all application groups. Right-click on
ADFSSSO and select Proper ties . Select ADFSSSO - Web API and click Edit...
11. On ADFSSSO - Web API Proper ties screen, select Issuance Transform Rules tab and click Add
Rule...
12. On Add Transform Claim Rule Wizard screen, select Send Claims Using a Custom Rule from the
drop-down and click Next
13. On the Add Transform Claim Rule Wizard screen, enter ForCustomIDToken in the Claim rule
name and the following claim rule in Custom rule . Click Finish
x:[]
=> issue(claim=x);
NOTE
You can also use PowerShell to assign the allatclaims and openid scopes.
Grant-AdfsApplicationPermission -ClientRoleIdentifier "[Client ID from #3 above]" -

ServerRoleIdentifier "[Identifier from #5 above]" -ScopeNames "allatclaims","openid"
Download and modify the sample application to emit custom claims in id_token
This section discusses how to download the sample Web APP and modify it in Visual Studio. We will be using
the Azure AD sample located here.
To download the sample project, use Git Bash and type the following:
git clone https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-

v2/tree/master/1-WebApp-OIDC
To Modify the app

1. Open the sample using Visual Studio.
2. Rebuild the app so that all of the missing NuGet packages are restored.
3. Open the web.config file. Modify the following values so the look like the following:
<add key="ida:ClientId" value="[Replace this Client Id from #3 above under section Create and
configure an Application Group in AD FS 2016 or later]" />
<add key="ida:ResourceID" value="[Replace this with the Web API Identifier from #5 above]" />
<add key="ida:ADFSDiscoveryDoc" value="https://[Your ADFS hostname]/adfs/.well-known/openid-
configuration" />

<add key="ida:PostLogoutRedirectUri" value="[Replace this with the Redirect URI from #4 above]" />
4. Open the Startup.Auth.cs file and make the following changes:
Tweak the OpenId Connect middleware initialization logic with the following changes:
private static string clientId = ConfigurationManager.AppSettings["ida:ClientId"];

//private static string aadInstance = ConfigurationManager.AppSettings["ida:AADInstance"];
//private static string tenant = ConfigurationManager.AppSettings["ida:Tenant"];
private static string metadataAddress =
ConfigurationManager.AppSettings["ida:ADFSDiscoveryDoc"];
private static string resourceId = ConfigurationManager.AppSettings["ida:ResourceID"];
private static string postLogoutRedirectUri =
ConfigurationManager.AppSettings["ida:PostLogoutRedirectUri"];
Comment out the following:
//string Authority = String.Format(CultureInfo.InvariantCulture, aadInstance, tenant);
Further down, modify the OpenId Connect middleware options as in the following:
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions
{
ClientId = clientId,
//Authority = authority,
Resource = resourceId,
MetadataAddress = metadataAddress,
PostLogoutRedirectUri = postLogoutRedirectUri,
RedirectUri = postLogoutRedirectUri
5. Open the HomeController.cs file and make the following changes:

Add the following:
using System.Security.Claims;
Update the About() method as shown below:
[Authorize]
public ActionResult About()
{
ClaimsPrincipal cp = ClaimsPrincipal.Current;
string userName = cp.FindFirst(ClaimTypes.WindowsAccountName).Value;
ViewBag.Message = String.Format("Hello {0}!", userName);
return View();
}
Test the custom claims in ID token
Once the above changes have been made, hit F5. This will bring up the sample page. Click on sign in.
You will be redirected 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.
Click the About link. You will see "Hello [Username]" which is retrieved from the username claim in ID token
Next Steps
AD FS Development
Build a multi-tiered application using On-Behalf-Of
(OBO) using OAuth with AD FS 2016 or later
This walkthrough provides instruction for implementing an on-behalf-of (OBO) authentication using AD FS in
Windows Server 2016 TP5 or later. To learn more about OBO authentication please read AD FS OpenID
Connect/OAuth flows and Application Scenarios
WARNING
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 acting 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
M O DUL E DESC RIP T IO N
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

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 Ser ver : 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
ToDoListSer vice : 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 user_impersonation scope"

=> issue(Type = "http://schemas.microsoft.com/identity/claims/scope", Value = "user_impersonation");
Adding ToDoListSer vice 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

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 the controller an appropriate 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
{
[Authorize]
public class WebAPIOBOController : ApiController
{
public IHttpActionResult Get()
{
return Ok($"WebAPI via OBO (user: {User.Identity.Name}");
}
}
}
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
K EY VA L UE
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 ver y impor tant 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:AdfsMetadataEndpoint 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 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 Name 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 with 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("u
ser_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(OBOWebAPIBase, clientCred, userAssertion);
//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 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 and later
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 and later

The following section describes how to configure the application group in AD FS 2016 and later.
Create Application Group
2. On the Application Group Wizard, for the name enter ADFSSSO and under Client-Ser ver applications
select the Web browser accessing a web application template. Click Next .
web.config file.
4. Enter the following for Redirect URI: - https://localhost:44320/ . Click Add . Click Next .
5. On the Summar y screen, click Next .

Download and modify sample application to authenticate via OpenID
Connect and AD FS
This section discusses how to download the sample Web APP and modify it in Visual Studio. We will be using
the Azure AD sample that is here.
git clone https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect
To Modify the app

1. Open the sample using Visual Studio.
2. Rebuild 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="[Replace this Client Id from #3 in above section]" />

<add key="ida:ADFSDiscoveryDoc" value="https://[Your ADFS hostname]/adfs/.well-known/openid-
configuration" />

<add key="ida:PostLogoutRedirectUri" value="[Replace this with Redirect URI from #4 in the above
section]" />
4. Open the Startup.Auth.cs file and make the following changes:
Comment out the following:
//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"];
Further down, modify the OpenId Connect middleware options as in the following:
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions
{
ClientId = clientId,
//Authority = authority,
MetadataAddress = metadataAddress,
PostLogoutRedirectUri = postLogoutRedirectUri,
RedirectUri = 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 app that uses OAuth confidential
clients by using AD FS 2016 or later
Active Directory Federation Services (AD FS) 2016 and later supports clients that can maintain their own secret,
such as an app or service that runs on a web server. These clients are known as confidential clients.
This article describes a web application running on a web server. The application serves as a confidential client
to AD FS.
Prerequisites
You'll need the following resources:
GitHub client tools.
AD FS in Windows Server 2016 Technical Preview 4 or later. (This article assumes that AD FS has been
installed.)
Visual Studio 2013 or later.
Create an application group

To create an application group in AD FS 2016 or later:
1. In AD FS Management, right-click Application Groups . Then select Add Application Group .
2. In the Add Application Group Wizard :
a. Under Name , enter ADFSOAUTHCC.
b. Under Client-Ser ver applications , select the Ser ver application accessing a Web API template.
c. Select Next .
3. Copy the Client Identifier value. You'll use it later in the application's web.config file. It's the value for
ida:ClientId .
4. For Redirect URI , enter https://localhost:44323. Select Add , and then select Next .
5. On the Configure Application Credentials page:
a. Select Generate a shared secret .
b. Copy the secret. You'll use this secret later in the application's web.config file. It's the value for
ida:ClientSecret .
c. Select Next .
6. On the Configure Web API page:

a. For Identifier , enter https://contoso.com/WebApp. You'll use this value later in the application's
web.config file. It's the value for ida:GraphResourceId .
b. Select Add .
c. Select Next .
7. On the Apply Access Control Policy page, select Permit ever yone . Then select Next .
8. On the Configure Application Permissions page, make sure openid and user_impersonation are
selected. Then select Next .
9. On the Summar y page, select Next .

10. On the Complete page, select Close .
Upgrade the database

This article is based on Visual Studio 2015. To make the example work with Visual Studio 2015, upgrade the
database file by following the instructions in this section.
This section discusses how to download the sample web API and upgrade the database in Visual Studio 2015.
We use the Azure Active Directory sample.
To download the sample project, in Git Bash, enter the following command:
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. In the window that appears, a message explains that the app requires
SQL Server 2012 Express. If you don't have SQL Server 2012 Express, you need to upgrade the database.
Select OK .
2. At the top of the window, compile the application by selecting Build > Build Solution . All of the NuGet
packages will be restored.
3. At the top of the window, select View > Ser ver Explorer . In the pane that opens, under Data
Connections , right-click DefaultConnection and then select Modify Connection .
4. In the Modify Connection window, under Database file name (new or existing) , select Browse .
Enter path\filename.mdf. Then, in the dialog box, select Yes .
5. In the Modify Connection dialog box, select Advanced .
6. In the Advanced Proper ties dialog box, under Data Source , change (LocalDb\v11.0) to
(LocalDB)\MSSQLLocalDB .
7. Select OK > OK . Then select Yes to upgrade the database.
8. After the process finishes, on the right, copy the value in the Connection String field.
9. Open the web.config file and replace the connectionString value with the value you copied earlier. Save
the web.config file.
NOTE
The preceding steps are necessary so you can get the new connection string. Otherwise, you'll get errors when
you run Update-Database later in this article.
10. At the top of the Visual Studio window, select View > Other Windows > Package Manager Console .
11. In the Package Manager Console pane, enter Enable-Migrations .
NOTE
If you get an error that says "Enable-Migrations isn't recognized as a cmdlet," enter Install-Package
EntityFramework to update the entity framework.
12. Enter Add-Migration <AnyNameHere> .

13. Enter Update-Database .
Modify the web API

To modify the sample web API in Visual Studio:
1. In Visual Studio, open the sample.
2. Open the web.config file. Modify the following settings by using the values you copied in the Create an
application group procedure:
ida:ClientId : Enter the client ID.
ida:ClientSecret : Enter the client secret.
ida:GraphResourceId : Enter the graph resource ID.
3. Under App_Star t , open the Startup.Auth.cs file. Make the following changes:
Comment out the following lines:

//public static readonly string Authority = String.Format(CultureInfo.InvariantCulture,
aadInstance, tenant);
In place of the removed lines, add the following line:
public static readonly string Authority = "https://<your_fsname>/adfs";
Here, replace <your_fsname> with the DNS portion of your federation service URL. For example,
enter adfs.contoso.com.
4. Open the UserProfileController.cs file. Make the following changes:

Comment out the following line:
//authContext = new AuthenticationContext(Startup.Authority, new TokenDbCache(userObjectID));

Replace both occurrences with the following code:
authContext = new AuthenticationContext(Startup.Authority, false, new

TokenDbCache(userObjectID));
Comment out the following line:
//authContext = new AuthenticationContext(Startup.Authority);
Replace both occurrences with the following code:
authContext = new AuthenticationContext(Startup.Authority, false);
Comment out all instances of the following line:
Uri redirectUri = new Uri(Request.Url.GetLeftPart(UriPartial.Authority).ToString() +

"/OAuth");
Replace all occurrences with the following code:

Uri redirectUri = new Uri(Request.Url.GetLeftPart(UriPartial.Authority).ToString());
Test the solution

To test the confidential client solution:
1. At the top of the Visual Studio window, make sure Internet Explorer is selected. Then select the green
arrow.
2. On the ASP.NET page that opens:

a. In the upper-right corner, select Register .
b. Enter a username and password.
c. Select Register to create a local account in the SQL database.
3. Notice the message Hello abby@contoso.com! . Select Profile .
4. On the new page, you see a message that prompts you to sign in. Select here .
You're prompted to sign in to AD FS.
Next steps
Learn about AD FS development.
Build a single page web application using OAuth
and ADAL.JS with AD FS 2016 or later
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.
IMPORTANT
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 later
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.

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 which 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.
Star tup.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-Ser ver 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 set to adfs
clientId: '150ab73e-0b05-4b78-9e50-0095a992cca9', // set this to the Client Id generated
during application registration in AD FS
popUp: false,
//cacheLocation: 'localStorage', // enable this for IE, as sessionStorage
does not work for localhost.
},
$httpProvider
);
C O N F IGURAT IO N DESC RIP T IO N
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 Star tup.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 XML 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 (use Chrome 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 or later
Overview
This article shows how to build a native application that interacts with a Web API protected by AD FS 2016 or
later.
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 or later.
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 or later
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.
c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD

AUTHORITY"]
=> issue(store = "Active Directory", types =
("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"), query = ";givenName;{0}", param =
c.Value);
Modify the application code
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.
git clone https://github.com/Azure-Samples/active-directory-dotnet-native-desktop
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. For example,
https://fs.contoso.com/adfs/
Modify ida:ClientId key with the value from Client Identifier in the Native Application page during
the Application Group creation in AD FS. For example, 3f07368b-6efd-4f50-a330-d93853f4c855
Modify the todo:todo:TodoListResourceId with the value from Identifier in the Configure Web API
page during the Application Group creation in AD FS. For example, https://localhost:44321/
Modify the todo:TodoListBaseAddress with the value from Identifier in the Configure Web API
page during the Application Group creation in AD FS. For example, https://localhost:44321/
Set the value of ida:RedirectUri with the value from Redirect URI in the Native application page
during the Application Group creation in AD FS. For example, https://ToDoListClient
For ease of reading you can remove / comment the key for ida:Tenant and ida:AADInstance .
MainWindow.xaml.cs
Comment the line for aadInstance as below
// private static string aadInstance = ConfigurationManager.AppSettings["ida: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 to

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
Comment 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
Star tup.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
3. 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
Scenario: Native App calling Web API
Applies To: AD FS 2019 and later
Learn how to build a native app signing-in users authenticated by AD FS 2019 and acquiring tokens using MSAL
library to call web APIs.
Before reading this article, you should be familiar with the AD FS concepts and Authorization code grant flow
Overview
In this flow you add authentication to your Native App (public client), which can therefore sign in users and calls
a Web API. To call a Web API from a Native App that signs in users, you can use MSAL's AcquireTokenInteractive
token acquisition method. To enable this interaction, MSAL leverages a web browser.
To better understand how to configure a Native App in ADFS to acquire access token interactively, let's use a
sample available here and walkthrough the app registration and code configuration steps.
Pre-requisites
GitHub client tools
AD FS 2019 or later configured and running
App Registration in AD FS
This section shows how to register the Native App as a public client and Web API as a Relying Party (RP) in AD
FS
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 NativeAppToWebApi and under Client-Ser ver
applications select the Native application accessing a Web API template. Click Next .
3. Copy the Client Identifier value. It will be used later as the value for ClientId in the application's
App.config file. Enter the following for Redirect URI: https://ToDoListClient. Click Add . Click Next .
4. On the Configure Web API screen, enter the Identifier : https://localhost:44321/. Click Add . Click Next .
This value will be used later in the application's App.config and Web.config files.
5. On the Apply Access Control Policy screen, select Permit ever yone and click Next .
6. On the Configure Application Permissions screen, make sure openid is selected and click Next .
7. On the Summary screen, click Next .
9. In AD FS Management, click on Application Groups and select NativeAppToWebApi application
group. Right-click and select Proper ties .
10. On NativeAppToWebApi properties screen, select NativeAppToWebApi – Web API under Web API
and click Edit…
11. On NativeAppToWebApi – Web API Properties screen, select Issuance Transform Rules tab and click
Add Rule…
12. On Add Transform Claim Rule Wizard, select Transform an Incoming Claim from the Claim rule
template: dropdown and click Next .
13. Enter NameID in Claim rule name: field. Select Name for Incoming claim type:, Name ID for
Outgoing claim type: and Common Name for Outgoing name ID format:. click Finish .
14. Click OK on NativeAppToWebApi – Web API Properties screen and then NativeAppToWebApi Properties
screen.
Code Configuration
This section shows how to configure a Native App to sign-in user and retrieve token to call the Web API
1. Download the sample from here
2. Open the sample using Visual Studio
3. Open the App.config file. Modify the following:
ida:Authority - enter h ttps://[your AD FS hostname]/adfs
ida:ClientId - enter the Client Identifier value from #3 in App Registration in AD FS section
above.
ida:RedirectUri - enter the Redirect URI value from #3 in App Registration in AD FS section above.
todo:TodoListResourceId – enter the Identifier value from #4 in App Registration in AD FS section
above
ida: todo:TodoListBaseAddress - enter the Identifier value from #4 in App Registration in AD FS
section above.
4. Open the Web.config file. Modify the following:

ida:Audience - enter the Identifier value from #4 in App Registration in AD FS section above
ida: AdfsMetadataEndpoint - enter
https://[your AD FS hostname]/federationmetadata/2007-06/federationmetadata.xml
Test the sample

This section shows how to test the sample configured above.
1. Once the code changes are made rebuild the solution
2. On Visual Studio, right click on solution and select Set Star tUp Projects…
3. On the Properties pages make sure Action is set to Star t for each of the Projects
4. At the top of Visual Studio, click the green arrow.
5. On the Native App's Main screen, click on Sign In .

If you don't see the native app screen, search and remove *msalcache.bin files from the folder where project
repo is saved on your system.
1. You will be re-directed to the AD FS sign-in page. Go ahead and sign in.
2. Once signed-in, enter text Build Native App to Web Api in the Create a To Do item . Click Add item .
This will call the To Do List Ser vice (Web API) and add the item in the cache.
Next Steps
Scenario: Web API calling Web API (On Behalf Of
Scenario)
Learn how to build a Web API calling another Web API On Behalf Of the user.
Before reading this article, you should be familiar with the AD FS concepts and On-Behalf_Of flow
Overview
A client (Web App) - not represented on the diagram below - calls a protected Web API and provides a
JWT bearer token in its "Authorization" Http header.
The protected Web API validates the token and uses the MSALAcquireTokenOnBehalfOfmethod to
request (from AD FS) another token so that it can, itself, call a second web API (named the downstream
web API) on behalf of the user.
The protected web API uses this token to call a downstream API. It can also callAcquireTokenSilentlater to
request tokens for other downstream APIs (but still on behalf of the same
user).AcquireTokenSilentrefreshes the token when needed.
To better understand how to configure on behalf of auth scenario in ADFS, let's use a sample available here and
walkthrough the app registration and code configuration steps.
Pre-requisites
GitHub client tools
This section shows how to register the Native App as a public client and Web APIs as Relying Parties (RP) in AD
FS
2. On the Application Group Wizard, for the Name enter WebApiToWebApi and under Client-Ser ver
applications select the Native application accessing a Web API template. Click Next .
3. Copy the Client Identifier value. It will be used later as the value for ClientId in the application's
App.config file. Enter the following for Redirect URI: - https://ToDoListClient. Click Add . Click Next .
4. On the Configure Web API screen, enter the Identifier : https://localhost:44321/. Click Add . Click Next .
This value will be used later in the application's App.config and Web.Config files.
6. On the Configure Application Permissions screen, select openid and user_impersonation . Click Next .
9. In AD FS Management, click on Application Groups and select WebApiToWebApi application group.
Right-click and select Proper ties .
10. On WebApiToWebApi properties screen, click Add application… .

11. Under Standalone applications, select Ser ver application .
12. On Server Application screen, add https://localhost:44321/ as the Client Identifier and Redirect URI .
13. On Configure Application Credentials screen, select Generate a shared secret . Copy the secret for later
use.

16. In AD FS Management, click on Application Groups and select WebApiToWebApi application group.
Right-click and select Proper ties .
17. On WebApiToWebApi properties screen, click Add application… .
18. Under Standalone applications, select Web API .

19. On Configure Web API, add https://localhost:44300 as the Identifier .
21. On the Configure Application Permissions screen, click Next .

24. Click OK on WebApiToWebApi – Web API 2 Properties screen
25. On WebApiToWebApi Properties screen, select WebApiToWebApi – Web API and click Edit… .
26. On WebApiToWebApi – Web API Properties screen, select Issuance Transform Rules tab and click Add
Rule… .
27. On Add Transform Claim Rule Wizard, select Send Claims Using a Custom Rule from dropdown and
click Next .
28. Enter PassAllClaims in Claim rule name: field and x:[] => issue(claim=x); claim rule in Custom rule:
field and click Finish.
29. Click OK on WebApiToWebApi – Web API Properties screen

30. On WebApiToWebApi Properties screen, select select WebApiToWebApi – Web API 2 and click Edit…
31. On WebApiToWebApi – Web API 2 Properties screen, select Issuance Transform Rules tab and click Add
Rule…
32. On Add Transform Claim Rule Wizard, select Send Claims Using a Custom Rule from dropdown and click
Next
33. Enter PassAllClaims in Claim rule name: field and x:[] => issue(claim=x); claim rule in Custom rule:
field and click Finish .
34. Click OK on WebApiToWebApi – Web API 2 Properties screen and then on WebApiToWebApi Properties
screen.
Code Configuration
This section shows how to configure a Web API to call another Web API
3. Open the App.config file. Modify the following:
ida:Authority - enter https://[your AD FS hostname]/adfs/
ida:ClientId - enter the value from #3 in App Registration in AD FS section above.
ida:RedirectUri - enter the value from #3 in App Registration in AD FS section above.
todo:TodoListResourceId – enter the Identifier value from #4 in App Registration in AD FS section
above
ida: todo:TodoListBaseAddress - enter the Identifier value from #4 in App Registration in AD FS
section above.
4. Open the Web.config file under ToDoListService. Modify the following:
ida:Audience - enter the Client Identifier value from #12 in App Registration in AD FS section
above
ida:ClientId - enter the Client Identifier value from #12 in App Registration in AD FS section above.
Ida: ClientSecret - enter the shared secret copied from #13 in App Registration in AD FS section
above.
ida:RedirectUri - enter the RedirectUri value from #12 in App Registration in AD FS section above.
ida: AdfsMetadataEndpoint - enter https://[your AD FS hostname]/federationmetadata/2007-
ida:OBOWebAPIBase - enter the Identifier value from #19 in App Registration in AD FS section
above.
ida:Authority - enter https://[your AD FS hostname]/adfs
5. Open the Web.config file under WebAPIOBO. Modify the following:

ida: AdfsMetadataEndpoint - enter https://[your AD FS hostname]/federationmetadata/2007-
ida:Audience - enter the Client Identifier value from #12 in App Registration in AD FS section
above
Test the sample
Once the code changes are made rebuild the solution
1. On Visual Studio, right click on solution and select Set Star tUp Projects…
2. On the Properties pages make sure Action is set to Star t for each of the Projects, except TodoListSPA.
3. At the top of Visual Studio, click the green arrow.
4. On the Native App's Main Screen, click on Sign In .
If you don't see the native app screen, search and remove *msalcache.bin files from the folder where
project repo is saved on your system.
6. Once signed-in, enter text Web Api to Web Api Call in the Create a To Do item . Click Add item . This
will call the Web API (To Do List Service) which then calls Web API 2 (WebAPIOBO) and adds the item in
the cache.
Next Steps
Scenario: Web App (Server App) calling Web API
Learn how to build a web app signing-in users authenticated by AD FS 2019 and acquiring tokens using MSAL
library to call web APIs.
Before reading this article, you should be familiar with the AD FS concepts and Authorization code grant flow
Overview
In this flow you add authentication to your Web App (Server App), which can therefore sign in users and calls a
web API. From the Web App, to call the Web API, use MSAL's AcquireTokenByAuthorizationCode token
acquisition method. You'll use the Authorization code flow, storing the acquired token in the token cache. Then
the controller will acquire tokens silently from the cache when needed. MSAL refreshes the token if needed.
Web Apps that calls Web APIs:
are confidential client applications.
that's why they've registered a secret (application shared secret, certificate or AD account) with AD FS. This
secret is passed-in during the call to AD FS to get a token.
To better understand how to register a Web App in ADFS and to configure it to acquire tokens to call a Web API,
let's use a sample available here and walkthrough the app registration and code configuration steps.
Pre-requisites
GitHub client tools
This section shows how to register the Web App as a confidential client and Web API as a Relying Party (RP) in
AD FS.
2. On the Application Group Wizard, for the Name enter WebAppToWebApi and under Client-Ser ver
applications select the Ser ver application accessing a Web API template. Click Next .
Web.config file. Enter the following for Redirect URI: - https://localhost:44326. Click Add. Click Next .
4. On the Configure Application Credentials screen, place a check in Generate a shared secret and copy
the secret. This will be used later as the value for ida:ClientSecret in the applications Web.config file.
Click Next .
5. On the Configure Web API screen, enter the Identifier : https://webapi. Click Add . Click Next . This value
will be used later for ida:GraphResourceId in the applications Web.config file.
6. On the Apply Access Control Policy screen, select Permit everyone and click Next .
7. On the Configure Application Permissions screen, make sure openid and user_impersonation are
selected and click Next .

Code Configuration
This section shows how to configure a ASP.NET Web App to sign-in user and retrieve token to call the Web API
3. Open the web.config file. Modify the following:
ida:ClientId - enter the Client Identifier value from #3 in App Registration in AD FS section
above.
ida:ClientSecret - enter the Secret value from #4 in App Registration in AD FS section above.
ida:RedirectUri - enter the Redirect URI value from #3 in App Registration in AD FS section above.
ida:Authority - enter https://[your AD FS hostname]/adfs. E.g., https://adfs.contoso.com/adfs
ida:Resource - enter the Identifier value from #5 in App Registration in AD FS section above.
Test the sample

1. Once the code changes are made rebuild the solution
2. At the top of Visual Studio, make sure Internet Explorer is selected and click the green arrow.
3. On Home Page, click on Sign-in.

5. Once signed-in, click on Access Token.
6. Clicking on Access Token will get the access token info by calling the Web API
Next Steps
AD FS Operations
This document contains a list of all of the documentation operations for AD FS.
Service Configuration
Update SSL Certificates in AD FS and WAP 2016
Configure alternate hostname binding for certificate authentication in AD FS
Customize HTTP security response headers with AD FS 2019
Fine tune SQL and address latency
Authentication Configuration
Strong Authentication (MFA ) & Password-less
Configure External Authentication providers as primary in AD FS (2019 or later)
Configure AD FS (2016 or later) and Azure MFA
Configure Additional Authentication Methods for AD FS
Lockout protection
Configure AD FS Extranet Soft Lockout Protection
Configure AD FS Extranet Smart Lockout Protection
Configure AD FS Extranet Banned IPs
Policy Configuration
Configure Azure AD Prompt login behavior to work with AD FS policy
Kerberos & Certificate authentication
Enable AD DS claims & kerberos compound authentication in AD FS
Configure AD FS for User Certificate Authentication
Configure alternate hostname binding for certificate authentication in AD FS
Device
Device Authentication Controls in AD FS
Authorization Configuration
Configure Access Control Policies in AD FS
Configure Device-based Conditional Access on-Premises
RPT & CPT configuration

Configure AD FS to authenticate users stored in LDAP directories
Create a Non-Claims Aware Relying Party Trust
Configure AD FS to work with Aggregated federation provider (e.g. InCommon)
Sign-in Experience Configuration

Configure AD FS 2016 Single Sign On Settings
Configure AD FS Paginated sign-in
Configure AD FS user sign-in customization
Configure intranet forms-based authentication for devices that do not support WIA
Other
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
Set up an AD FS lab environment
Walkthrough Guide: Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications
Controlling Access to Organizational Data with
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.
P ERM IT USERS EXC EP T
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

P ERM IT USERS EXC EP T
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:
P O L IC Y P O L IC Y RUL ES
Extranet access requires MFA Rule #1

All users are permitted from extranet
and with MFA
Permit
Rule#2
from intranet
Permit
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
P O L IC Y P O L IC Y RUL ES
Extranet access requires MFA except "service admin" Rule #1

All users are permitted to access from extranet
and with MFA
Permit
Except ser vice admin group
Rule #2
always
Permit
non-work place joined device accessing from extranet Rule #1

requires 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
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
Impor tant : 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
Impor tant : /adfs/services/trust/2005/windowstransport and /adfs/services/trust/13/windowstransport

endpoints should only be enabled for intranet access as they are meant to be intranet facing endpoints that
use WIA binding on HTTPS. Exposing them to extranet could allow requests against these endpoints to
bypass lockout protections. These endpoints should be disabled on the proxy (i.e. disabled from extranet) to
protect AD account lockout.
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 ==
"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 = "
DenyUsersWithClaim");
would be updated to:

"https://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 =
"https://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

SC EN A RIO DESC RIP T IO N
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 Ser ver Manager , click Tools , then click AD FS Management .

2. In the console tree, under AD FS\Trust Relationships , click Relying Par ty 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.
Custom 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 == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] &&
c2:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip",
Value =~ "^(?!192\.168\.1\.77|10\.83\.118\.23)"] => issue(Type =
"https://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 = "https://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

“If 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 == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] &&
c2:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip",
Value =~ "^(?!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.
“If 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:
"https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value !=
"Microsoft.Exchange.ActiveSync"] => issue(Type =
"https://schemas.microsoft.com/authorization/claims/deny", Value = "DenyUsersWithClaim");
12. On the Select Rule Template page, under Claim rule template, select Send Claims Using a
“check if application claim exists”. Under Custom rule , type or paste the following claim rule language
syntax:
NOT EXISTS([Type == "https://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:

"http://custom/xmsapplication", Value == "fail"] => issue(Type =
"https://schemas.microsoft.com/authorization/claims/deny", Value = "DenyUsersWithClaim");
18. 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:
19. To save the new rules, in the Edit Claim Rules dialog box, click OK. The resulting list should look like the
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

“If 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”
c1:[Type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && c2:[Type

== "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~
"^(?!192\.168\.1\.77|10\.83\.118\.23)"] => issue(Type = "http://custom/ipoutsiderange", Value = "true");
“If 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:

"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 = "
DenyUsersWithClaim");`
5. 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:
11. To save the new rules, in the Edit Claim Rules dialog box, click OK . The resulting list should look like the
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

“If 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”
`c1:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip",
Value =~ "^(?!192\.168\.1\.77|10\.83\.118\.23)"] && c2:[Type ==
"https://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 == "https://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 = "https://schemas.microsoft.com/authorization/claims/deny", Value =
"DenyUsersWithClaim");
14. 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:
15. To save the new rules, in the Edit Claim Rules dialog box, click OK. The resulting list should look like the
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.
2. 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: https://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: https://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: https://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: https://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: https://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: https://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 from the list, and then click Next.
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
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.
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,
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
DESC RIP T IO N C L A IM RUL E L A N GUA GE SY N TA X
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/clai
ms/x-ms-proxy"])
Used to establish that the request is from a client with an IP NOT exists([Type ==
in the defined acceptable range. "https://schemas.microsoft.com/2012/01/requestcontext/clai
ms/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/clai
should be denied. ms/x-ms-client-application",
Value=="Microsoft.Exchange.ActiveSync"])
This rule allows you to determine whether the call was NOT exists([Type ==
through a Web browser, and will not be denied. "https://schemas.microsoft.com/2012/01/requestcontext/clai
ms/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"])
DESC RIP T IO N C L A IM RUL E L A N GUA GE SY N TA X
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/
Adding NOT to this statement means a group of users will groupsid", Value =~ "{Group SID value of allowed AD
be allowed, regardless of location. group}"])
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.
Configure 3rd party authentication providers as
primary authentication 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 (available in AD FS 2016 onwards) 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 primar y 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 Ser vice -> Authentication Methods , under Primar y
Authentication Methods , click Edit
Click the checkbox for Allow additional authentication providers as primar y .
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 Ser vice -> Authentication Methods , under Additional
Authentication Methods , click Edit
Click the checkbox for Forms Authentication to enable username and password as additional authentication.
Setting up an AD FS Deployment with AlwaysOn
Availability Groups
A highly available geo-distributed topology provides:

Elimination of a single point of failure: With failover capabilities, you can achieve a highly available ADFS
infrastructure even if one of the data centers in a part of a globe goes down.
Improved performance: You can use the suggested deployment to provide a high-performance ADFS
infrastructure
AD FS can be configured for a highly available geo-distributed scenario. The following guide will walk through
an overview of AD FS with SQL Always on Availability Groups and provide deployment considerations and
guidance.
Overview - AlwaysOn Availability Groups

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.
An Always OnAvailability Group(AG) is a one or more user databases that fail over together. An availability
group consists of a primaryavailability replicaand one to four secondary replicas that are maintained through
SQL Server log-based data movement for data protection without the need for shared storage. Each replica is
hosted by an instance of SQL Server on a different node of the WSFC. The availability group and a
corresponding virtual network name are registered as resources in the WSFC cluster.
Anavailability group listeneron the primary replica's node responds to incoming client requests to connect to
the virtual network name, and based on attributes in the connection string, it redirects each request to the
appropriate SQL Server instance. In the event of a failover, instead of transferring ownership of shared physical
resources to another node, WSFC is leveraged to reconfigure a secondary replica on another SQL Server
instance to become the availability group's primary replica. The availability group's virtual network name
resource is then transferred to that instance. At any given moment, only a single SQL Server instance may host
the primary replica of an availability group's databases, all associated secondary replicas must each reside on a
separate instance, and each instance must reside on separate physical nodes.
NOTE
If machines are running on Azure, set up the Azure virtual machines to enable the listener configuration to communicate
with AlwaysOn Availability groups. For more information, Virtual Machines: SQL Always On Listener.
For additional overview of AlwaysOn Availability Groups, see Overview of Always On Availability Groups (SQL
Server).
NOTE
If the organization requires failover across multiple datacenters, it is recommended to create an artifact database in each
datacenter as well as enabling a background cache which reduces latency during request processing. Follow the
instructions to do so in Fine Tuning SQL and Reducing Latency.
Deployment Guidance
1. Consider the correct database for the goals of the AD FS deployment. AD FS uses a database to
store configuration and in some cases transactional data related to the Federation Service. You can use AD FS
software to select either the build-in Windows Internal Database (WID) or Microsoft SQL Server 2008 or
newer to store the data in the federation service. The following table describes the differences in supported
features between a WID and SQL database.
C AT EGO RY F EAT URE SUP P O RT ED B Y W ID SUP P O RT ED B Y SQ L
AD FS Features Federation server farm Yes Yes

deployment
AD FS Features SAML artifact resolution. No Yes

Note: This is not common
for SAML applications
AD FS Features SAML/WS-Federation token No Yes

replay detection. Note: only
required when AD FS
receives tokens from
external IDPs. This is not
required if AD FS is not
acting as a federation
partner.
Database Features Basic database redundancy No No

using pull replication, where
one or more servers
source server host a
database
C AT EGO RY F EAT URE SUP P O RT ED B Y W ID SUP P O RT ED B Y SQ L
Database Features Database redundancy using No Yes

high Availability solutions,
such as clustering or
mirroring (at the database
layer)
Additional Features OAuth Authcode Scenario Yes Yes
If you are a large organization with more than 100 trust relationships that need to provide both their internal
users and external users with single-sign on access to federation applications or services, SQL is the
recommended option.
If you are an organization with 100 or fewer configured trust relationships, WID provides data and federation
service redundancy (where each federation server replicates changes to other federation servers in the same
farm). WID does not support token replay detection or artifact resolution and has a limit of 30 federation
servers. For more information on planning your deployment, visit here.
SQL Server High Availability Solutions

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. If SQL is the appropriate database for your
deployment goals, proceed with this deployment guide.
This guide will walk through the following
Deploy AD FS
Configure AD FS to use an AlwaysOn Availability Groups
Install the Failover Clustering Role
Run Cluster Validation Tests
Enable Always On Availability groups
Back Up AD FS databases
Create AlwaysOn Availability groups
Add Databases on Second node
Join an Availability Replica to an Availability Groups
Update the SQL Connection string
Deploy AD FS
NOTE
If machines are running on Azure, the Virtual Machines must be configured in a specific way to allow for the listener to
communicate with the Always On Availabililty group. For information on configuration, view Configure a load balancer for
an availability group on Azure SQL Server VMs
This deployment guide will show a two node farm with two SQL servers as an example. To deploy AD FS follow
the initial links below to install the AD FS Role Service. To configure for an AoA group, there will be additional
steps for the role.
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. Ensure that each server instance is running the same version of SQL. To view the full list
of prerequisites, restrictions, and recommendations for Always On availability groups, read here.
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. Specify the database host name for the existing farm using
SQL server. As part of the AD FS configuration, you must specify a SQL connection string, so you will have to
configure the first AD FS farm 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. Verify connectivity to the database using SSMS and then connect to the targeted database host name. If
adding another node to the federation farm, connect to the targeted database.
3. Specify the SSL certificate for the AD FS farm.
4. Connect the farm to a service account or gMSA.
5. Complete the AD FS farm configuration and installation.
NOTE
SQL Server must be run under a domain account for installation of Always On Availability groups. By default, it is run as a
local system.
Install the Failover Clustering Role

The Windows Server Failover Cluster role provides the For more information on Windows Server Failover
Clusters,
1. Start Server Manager.
2. On the Manage menu, select Add Roles and Features.
3. On the Before you begin page, select Next.
4. On the Select installation type page, select Role-based or feature-based installation, and then select Next.
5. On the Select destination server page, select the SQL server where you want to install the feature, and then
select Next.
6. On the Select server roles page, select Next.

7. On the Select features page, select the Failover Clustering check box.
8. On the Confirm installation selections page, select Install. A server restart is not required for the Failover
Clustering feature.
9. When the installation is completed, select Close.
10. Repeat this procedure on every server that you want to add as a failover cluster node.
Run Cluster Validation Tests
1. On a computer that has the Failover Cluster Management Tools installed from the Remote Server
Administration Tools, or on a server where you installed the Failover Clustering feature, start Failover Cluster
Manager. To do this on a server, start Server Manager, and then on the Tools menu, select Failover Cluster
Manager.
2. In the Failover Cluster Manager pane, under Management, select Validate Configuration.
3. On the Before You Begin page, select Next.
4. On the Select Servers or a Cluster page, in the Enter name box, enter the NetBIOS name or the fully qualified
domain name of a server that you plan to add as a failover cluster node, and then select Add. Repeat this step
for each server that you want to add. To add multiple servers at the same time, separate the names by a
comma or by a semicolon. For example, enter the names in the format server1.contoso.com,
server2.contoso.com. When you are finished, select Next.
5. On the Testing Options page, select Run all tests (recommended), and then select Next.
6. On the Confirmation page, select Next. The Validating page displays the status of the running tests.
7. On the Summary page, do either of the following:
If the results indicate that the tests completed successfully and the configuration is suited for clustering, and
you want to create the cluster immediately, make sure that the Create the cluster now using the validated
nodes check box is selected, and then select Finish. Then, continue to step 4 of the Create the failover cluster
procedure.
If the results indicate that there were warnings or failures, select View Report to view the details and
determine which issues must be corrected. Realize that a warning for a particular validation test indicates
that this aspect of the failover cluster can be supported, but might not meet the recommended best practices.
NOTE
If you receive a warning for the Validate Storage Spaces Persistent Reservation test, see the blog post Windows Failover
Cluster validation warning indicates your disks don't support the persistent reservations for Storage Spaces for more
information. For more information about hardware validation tests, see Validate Hardware for a Failover Cluster.
Create the Failover Cluster

To complete this step, make sure that the user account that you log on as meets the requirements that are
outlined in the Verify the prerequisites section of this topic.
1. Start Server Manager.
2. On the Tools menu, select Failover Cluster Manager.
3. In the Failover Cluster Manager pane, under Management, select Create Cluster. The Create Cluster Wizard
opens.
4. On the Before You Begin page, select Next.
5. If the Select Servers page appears, in the Enter name box, enter the NetBIOS name or the fully qualified
domain name of a server that you plan to add as a failover cluster node, and then select Add. Repeat this step
for each server that you want to add. To add multiple servers at the same time, separate the names by a
comma or a semicolon. For example, enter the names in the format server1.contoso.com;
server2.contoso.com. When you are finished, select Next.
NOTE
If you chose to create the cluster immediately after running validation in the configuration validating procedure, you will
not see the Select Servers page. The nodes that were validated are automatically added to the Create Cluster Wizard so
that you do not have to enter them again.
6. If you skipped validation earlier, the Validation Warning page appears. We strongly recommend that you run
cluster validation. Only clusters that pass all validation tests are supported by Microsoft. To run the validation
tests, select Yes, and then select Next. Complete the Validate a Configuration Wizard as described in Validate
the configuration.
7. On the Access Point for Administering the Cluster page, do the following:
In the Cluster Name box, enter the name that you want to use to administer the cluster. Before you do, review
the following information:
During cluster creation, this name is registered as the cluster computer object (also known as the cluster
name object or CNO) in AD DS. If you specify a NetBIOS name for the cluster, the CNO is created in the same
location where the computer objects for the cluster nodes reside. This can be either the default Computers
container or an OU.
To specify a different location for the CNO, you can enter the distinguished name of an OU in the Cluster
Name box. For example: CN=ClusterName, OU=Clusters, DC=Contoso, DC=com.
If a domain administrator has prestaged the CNO in a different OU than where the cluster nodes reside,
specify the distinguished name that the domain administrator provides.
If the server does not have a network adapter that is configured to use DHCP, you must configure one or
more static IP addresses for the failover cluster. Select the check box next to each network that you want to
use for cluster management. Select the Address field next to a selected network, and then enter the IP
address that you want to assign to the cluster. This IP address (or addresses) will be associated with the
cluster name in Domain Name System (DNS).
When you are finished, select Next.
8. On the Confirmation page, review the settings. By default, the Add all eligible storage to the cluster check box
is selected. Clear this check box if you want to do either of the following:
You want to configure storage later.
You plan to create clustered storage spaces through Failover Cluster Manager or through the Failover
Clustering Windows PowerShell cmdlets, and have not yet created storage spaces in File and Storage
Services. For more information, see Deploy Clustered Storage Spaces.
9. Select Next to create the failover cluster.
10. On the Summary page, confirm that the failover cluster was successfully created. If there were any warnings
or errors, view the summary output or select View Report to view the full report. Select Finish.
11. To confirm that the cluster was created, verify that the cluster name is listed under Failover Cluster Manager
in the navigation tree. You can expand the cluster name, and then select items under Nodes, Storage or
Networks to view the associated resources. Realize that it may take some time for the cluster name to
successfully replicate in DNS. After successful DNS registration and replication, if you select All Servers in
Server Manager, the cluster name should be listed as a server with a Manageability status of Online.
Enable Always on Availability Groups with SQL Server Configuration

Manager
1. Connect to the Windows Server Failover Cluster (WSFC) node that hosts the SQL Server instance where you
want to enable Always On Availability Groups.
2. On the Start menu, point to All Programs, point to Microsoft SQL Server, point to Configuration Tools, and
click SQL Server Configuration Manager.
3. In SQL Server Configuration Manager, click SQL Server Services, right-click SQL Server (), where is the name
of a local server instance for which you want to enable Always On Availability Groups, and click Properties.
4. Select the Always On High Availability tab.
5. Verify that Windows failover cluster name field contains the name of the local failover cluster. If this field is
blank, this server instance currently does not support Always On availability groups. Either the local
computer is not a cluster node, the WSFC cluster has been shut down, or this edition of SQL Server that does
not support Always On availability groups.
6. Select the Enable Always On Availability Groups check box, and click OK. SQL Server Configuration Manager
saves your change. Then, you must manually restart the SQL Server service. This enables you to choose a
restart time that is best for your business requirements. When the SQL Server service restarts, Always On
will be enabled, and the IsHadrEnabled server property will be set to 1.
Back up AD FS Databases
Back up the AD FS configuration and artifact databases with the full transaction logs. Place the back up in the
chosen destination. Back up the ADFS Artifact and Configuration databases.
Tasks > Backup > Full > Add to a backup file > ok to create
Create New Availability Group

1. In Object Explorer, connect to the server instance that hosts the primary replica.
2. Expand the Always On High Availability node and the Availability Groups node.
3. To launch the New Availability Group Wizard, select the New Availability Group Wizard command.
4. The first time you run this wizard, an Introduction page appears. To bypass this page in the future, you can
click Do not show this page again. After reading this page, click Next.
5. On the Specify Availability Group Options page, enter the name of the new availability group in the
Availability group name field. This name must be a valid SQL Server identifier that is unique on the cluster
and in your domain as a whole. The maximum length for an availability group name is 128 characters. e
6. Next, specify the cluster type. The possible cluster types depend on the SQL Server version and operating
system. Choose either WSFC, EXTERNAL, or NONE. For details see Specify Availability Group Name Page
7. On the Select Databases page, the grid lists user databases on the connected server instance that are eligible
to become the availability databases. Select one or more of the listed databases to participate in the new
availability group. These databases will initially be the initial primary databases. For each listed database, the
Size column displays the database size, if known. The Status column indicates whether a given database
meets the prerequisites for availability databases. It the prerequisites are not met, a brief status description
indicates the reason that the database is ineligible; for example, if it does not use the full recovery model. For
more information, click the status description. If you change a database to make it eligible, click Refresh to
update the databases grid. If the database contains a database master key, enter the password for the
database master key in the Password column.
8.On the Specify Replicas page, specify and configure one or more replicas for the new availability group. This
page contains four tabs. The following table introduces these tabs. For more information, see the Specify
Replicas Page (New Availability Group Wizard: Add Replica Wizard) topic.
TA B B RIEF DESC RIP T IO N
Replicas Use this tab to specify each instance of SQL Server that will
host a secondary replica. Note that the server instance to
which you are currently connected must host the primary
replica.
Endpoints Use this tab to verify any existing database mirroring

endpoints and also, if this endpoint is lacking on a server
instance whose service accounts use Windows
Authentication, to create the endpoint automatically.
Backup Preferences Use this tab to specify your backup preference for the
availability group as a whole and your backup priorities for
the individual availability replicas.
Listener Use this tab to create an availability group listener. By

default, the wizard does not create a listener.
9. On the Select Initial Data Synchronization page, choose how you want your new secondary databases to be
created and joined to the availability group. Choose one of the following options:
Automatic seeding
SQL Server automatically creates the secondary replicas for every database in the group. Automatic seeding
requires that the data and log file paths are the same on every SQL Server instance participating in the
group. Available on SQL Server 2016 (13.x) and later. See Automatically initialize Always On Availability
groups.
Full database and log backup
Select this option if your environment meets the requirements for automatically starting initial data
synchronization (for more information, see Prerequisites, Restrictions, and Recommendations, earlier in this
topic). If you select Full, after creating the availability group, the wizard will back up every primary database
and its transaction log to a network share and restore the backups on every server instance that hosts an
secondary replica. The wizard will then join every secondary database to the availability group. In the Specify
a shared network location accessible by all replicas: field, specify a backup share to which all of the server
instance that host replicas have read-write access. For more information, see Prerequisites, earlier in this
topic. In the validation step, the wizard will perform a test to make sure the provided network location is
valid, the test will create a database on the primary replica named "BackupLocDb_" followed by a Guid and
perform backup to the provided network location, then restore it on the secondary replicas. It is safe to delete
this database along with its backup history and backup file in case the wizard failed to delete them.
Join only
If you have manually prepared secondary databases on the server instances that will host the secondary
replicas, you can select this option. The wizard will join the existing secondary databases to the availability
group.
Skip initial data synchronization
Select this option if you want to use your own database and log backups of your primary databases. For
more information, see Start Data Movement on an Always On Secondary Database (SQL Server).
9. The Validation page verifies whether the values you specified in this Wizard meet the requirements of the
New Availability Group Wizard. To make a change, click Previous to return to an earlier wizard page to
change one or more values. The click Next to return to the Validation page, and click Re-run Validation.
10. On the Summary page, review your choices for the new availability group. To make a change, click
Previous to return to the relevant page. After making the change, click Next to return to the Summary
page.
NOTE
When the SQL Server service account of a server instance that will host a new availability replica does not already exist as
a login, the New Availability Group Wizard needs to create the login. On the Summary page, the wizard displays the
information for the login that is to be created. If you click Finish, the wizard creates this login for the SQL Server service
account and grants the login CONNECT permission. If you are satisfied with your selections, optionally click Script to
create a script of the steps the wizard will execute. Then, to create and configure the new availability group, click Finish.
11. The Progress page displays the progress of the steps for creating the availability group (configuring
endpoints, creating the availability group, and joining the secondary replica to the group).
12. When these steps complete, the Results page displays the result of each step. If all these steps succeed, the
new availability group is completely configured. If any of the steps result in an error, you might need to
manually complete the configuration or use a wizard for the failed step. For information about the cause of a
given error, click the associated "Error" link in the Result column. When the wizard completes, click Close to
exit.
Add Databases on Secondary Node
1. Restore the artifact database through the UI on the secondary node using the backup files created.
2. Restore the database in a NON-RECOVERY state.

3. Repeat process to restore the configuration database.
Join Availability Replica to an Availability Group

1. In Object Explorer, connect to the server instance that hosts the secondary replica, and click the server name
to expand the server tree.
2. Expand the Always On High Availability node and the Availability Groups node.
3. Select the availability group of the secondary replica to which you are connected.
4. Right-click the secondary replica, and click Join to Availability Group.
5. This opens the Join Replica to Availability Group dialog box.
6. To join the secondary replica to the availability group, click OK.
Update the SQL Connection String
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. Run the configuration database change on each node and restart
the ADFS service on all the ADFS nodes. The initial catalog value changes based on the farm version.
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()
PS:\> Set-AdfsProperties –artifactdbconnection ”Data source=<SQLCluster\SQLInstance >;Initial
Catalog=AdfsArtifactStore;Integrated Security=True”
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?
When applications need to request fresh authentication from Azure AD, meaning that they need Azure AD to re-
authenticate the user even if the user has already been authenticated, they can send the prompt=login
parameter to Azure AD as part of the authentication request.
When this request is for a federated user, Azure AD needs to inform the IdP, like AD FS, that the request is for
fresh authentication.
By default, Azure AD translates prompt=login to wfresh=0 and
wauth=https://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password when sending this type
of authentication requests to the federated IdP.
These parameters mean:
wfresh=0 : do fresh authentication
wauth=https://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password : use
username/password for the fresh authentication request
This can cause problems with corporate intranet and multi-factor authentication scenarios in which an
authentication type other than username and password, as requested by the wauth parameter, 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 that now Azure AD can send this parameter as-is to 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 to configure a federated domain 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 of the 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' of the Azure AD PowerShell module, whose
cmdlets have names like “Set-AzureAD*”.
1. First obtain the current values of PreferredAuthenticationProtocol , SupportsMfa , and PromptLoginBehavior

for the federated domain by running the following PowerShell command:
Get-MsolDomainFederationSettings -DomainName <your_domain_name> | Format-List *
NOTE
The output of Get-MsolDomainFederationSettings by default does not display certain properties in the console. To
view all the properties you should pipe ( | ) its output to Format-List * to force the output of all the properties of the
object.
NOTE
If the value of the property PromptLoginBehavior is empty ( $null ) the behavior of TranslateToFreshPasswordAuth
is used.
2. Configure the desired value of PromptLoginBehavior by running the following command:
Set-MsolDomainFederationSettings –DomainName <your_domain_name> -PreferredAuthenticationProtocol

<current_value_from_step1> -SupportsMfa <current_value_from_step1> -PromptLoginBehavior
<TranslateToFreshPasswordAuth|NativeSupport|Disabled>
Following are the possible values of PromptLoginBehavior parameter and their meaning:
TranslateToFreshPasswordAuth : means the default Azure AD behavior of translating to prompt=login
wauth=https://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password and wfresh=0 .
NativeSuppor t : means that the prompt=login parameter will be sent as is to AD FS. This is the
recommended value if AD FS is in Windows Server 2012 R2 with the July 2016 update rollup or higher.
Disabled : means that only wfresh=0 is sent to AD FS.
AD FS paginated sign-in
For AD FS in Windows Server 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 in Windows Server 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 in Windows Server 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

New installation of AD FS
If you are a new customer to AD FS, you'll receive the new design by default.
Upgrading a farm
If you are an existing customer AD FS 2012 R2 or 2016, there are two ways to receive the new design after
upgrading servers to AD FS 2019 and enabling the FBL to 2019.
Allow the new sign-in via Powershell. Run the following command to enable pagination:
Set-AdfsGlobalAuthenticationPolicy -EnablePaginatedAuthenticationPages $true
Enable external authentication as primary, either via Powershell or through the AD FS Server Manager.
The new paginated sign in pages will be enabled when this feature is enabled. 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:
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 for AD FS 2012R2 and up to a
maximum of 90 days with AD FS 2016 if they use their device to access AD FS resources within a 14 day
window.
If the device is not registered but 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 Windows
Server 2012 R2.
TA SK P O W ERSH EL L DESC RIP T IO N
Enable/disable persistent SSO Set-AdfsProperties – Persistent SSO is enabled by default. If

EnablePersistentSso <Boolean> it is disabled, no PSSO cookie will be
written.
"Enable/disable “keep me signed in" Set-AdfsProperties –EnableKmsi "Keep me signed in" feature is disabled
<Boolean> by default. If it is enabled, end user will
see a “keep me signed in” choice on
AD FS sign-in page
AD FS 2016 - Single Sign-On and authenticated devices

AD FS 2016 changes the PSSO when requestor is authenticating from a registered device increasing to max 90
Days but requiring an authentication within a 14 days period (device usage window). 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 Windows Server 2012 R2.
An Issuance Transform rule to pass through the InsideCorporateNetwork claim
@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through claim - InsideCorporateNetwork"
c:[Type == "https://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 == "https://schemas.microsoft.com/2014/03/psso"]
To Summarize:
SIN GL E A DF S 2012 R2 A DF S 2016

SIGN O N IS DEVIC E REGIST ERED? IS DEVIC E REGIST ERED?
EXP ERIEN C E
NO N O B UT Y ES NO N O B UT Y ES
K M SI K M SI
SSO=>set 8 Hrs N/A N/A 8 Hrs N/A N/A

Refresh
Token=>
PSSO=>set N/A 24 Hrs 7 Days N/A 24 Hrs Max 90

Refresh Days with
Token=> 14 Days
Window
Token 1 Hrs 1 Hrs 1 Hrs 1 Hrs 1 Hrs 1 Hrs

Lifetime
Registered Device? You get a PSSO / Persistent SSO

Not Registered Device? You get a SSO
Not Registered Device but KMSI? You get a PSSO/ Persistent SSO
IF:
[x] Admin has enabled the KMSI feature [AND]
[x] User clicks the KMSI check box on the forms login page
ADFS issues a new refresh token only if the validity of the newer refresh token is longer than the previous
token. The maximum lifetime of a token is is 84 days, but AD FS keeps the token valid on a 14 day sliding
window. If the refresh token is valid for 8 hours, which is the regular SSO time, a new refresh token will not be
issued.
Good to Know:
Federated users who do not have the LastPasswordChangeTimestamp attribute synced are issued session
cookies and refresh tokens that have a Max Age value of 12 hours .
This occurs because Azure AD cannot determine when to revoke tokens that are related to an old credential
(such as a password that has been changed). Therefore, Azure AD must check more frequently to make sure that
the user and associated tokens are still in good standing.
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
3. Migrate from a SQL based configuration to WID and vice versa
Use the tool to move from a SQL based farm configuration to WID or vice versa.
NOTE
If you are using SQL Merge Replication or Always on Availablity Groups, the Rapid Restore tool is not supported. We
recommend using SQL based backups and a backup of the SSL certificate as an alternative.
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.
Encr yptionPassword <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
Ser viceAccountCredential <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
Decr yptionPassword <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.
Ser viceAccountCredential < pscredential > - specifies the service account that will be used for the
new AD FS Service being restored
GroupSer viceAccountIdentifier <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:
%LOCAL APPDATA%\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.82.3
Release: April 2020
Fixed issues:
Added support for CNG based certificates
Version 1.0.82.0
Release: July 2019
Fixed issues:
Bug fix for AD FS service account names that contain LDAP escape characters
Version: 1.0.81.0
Release: April 2019
Fixed issues:
Bug fixes for certificate backup and restore
Additional trace information to the log file
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 ADFS1.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 user sign-in customization
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.
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

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 .
3. 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 Director y , 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
4. Click OK .
AD FS Operations
The Role of Attribute Stores
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 suppor t 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 suppor t 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 suppor t for claims, compound authentication, and Kerberos
armoring .
5. In the new dialog window, set KDC support for claims to Enabled .
6. Under Options, select Suppor ted 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 suppor t
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.
UP DAT E DESC RIP T IO N
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 Primar y 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
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 Ser vice , 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 .
6. Using PowerShell you can use the Add-AdfsClaimDescription cmdlet.
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-ADSer viceAccount PowerShell cmdlet.
NOTE
If you change the service account, then you must manually enable compound authentication by running the Set-
ADUser -compoundIdentitySuppor ted:$true Windows PowerShell cmdlets.
Set-ADServiceAccount -Identity “ADFS Service Account” -CompoundIdentitySupported:$true
2. 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-ADSer viceAccount : Cannot install ser vice 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, right-click Active Director y
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.
2. In AD FS Management , click Relying Par ty Trusts and in the right pane, right-click your RP and select
Edit Claim Rules .
3. 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 suppor t for claims, compound authentication, and Kerberos
armoring .
5. In the new dialog window, set KDC support for claims to Enabled .
6. Under Options, select Suppor ted 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 suppor t
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 Primar y 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-ADSer viceAccount PowerShell cmdlet.
NOTE
If you change the service account, then you must manually enable compound authentication by running the Set-
ADUser -compoundIdentitySuppor ted:$true Windows PowerShell cmdlets.
Set-ADServiceAccount -Identity “ADFS Service Account” -CompoundIdentitySupported:$true
2. 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-ADSer viceAccount : Cannot install ser vice 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, right-click Active Director y
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.
2. In AD FS Management , click Relying Par ty Trusts and in the right pane, right-click your RP and select
Edit Claim Rules .
3. 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 created.
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
User Certificate authentication is used mainly in 2 use cases

Users are using smart cards to sign-in against their AD FS system
Users are using certificates provisioned to mobile devices
Prerequisites
1. Determine the mode of AD FS user certificate authentication you want to enable using one of the modes
described in this article
2. Ensure that your user certificate trust chain is installed & trusted by all AD FS and WAP servers including any
intermediate certificate authorities. Usually this is done via GPO on AD FS / WAP servers
3. Ensure that the root certificate of the chain of trust for your user certificates is in the NTAuth store in Active
Directory
4. 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
5. 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.
6. 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.)
7. AD FS does not support Username Hints with SmartCard/Certificate based authentication.
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 .
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
Additionally, there some optional aspects.
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.
If you need to restrict access based on the type of cert, you can use the additional properties on the
certificate in AD FS issuance authorization rules for the application. Common scenarios are "only allow
certificates provisioned by an MDM provider" or "only allow smart card certificates"
IMPORTANT
Customers using device code flow for authentication and performing device authentication using an IDP other than Azure
AD (e.g AD FS) will not be able to enforce device based access (e.g. only allow managed devices using a 3rd party MDM
service) for Azure AD resources. To protect access to your corporate resources in Azure AD and prevent any data leakage,
customers should configure Azure AD device based Conditional Access (i.e. “Require device to be marked complaint” grant
control in Azure AD Conditional Access).
Configure allowed issuing certification authorities for client certificates using the guidance under
"Management of trusted issuers for client authentication" in this article.
You may want to consider modifying the sign-in pages to suit the needs of your end users when doing
certificate authentication. Common cases are to (a) Change 'Sign-in with your X509 certificate' to something
more end user friendly
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.
Troubleshoot Certificate Authentication

This document focuses on trouble shooting common issues when AD FS is configured for certificate
authentication for users.
Check if Certificate Trusted issuers is configured properly in all the AD FS/WAP servers
Common Symptom: HTTP 204 “No content from https://certauth.adfs.contoso.com”
AD FS uses the underlying windows operation system to prove possession of the user certificate and ensure
that it matches a trusted issuer by doing certificate trust chain validation. To match the trusted issuer, you will
need to ensure that all root and intermediate authorities are configured as trusted issuers in the local computer
certification authorities store. To validate this automatically, please use the AD FS Diagnostic Analyzer tool. The
tool queries all the servers and ensures that the right certificates are provisioned correctly.
1. Download and run the tool as per the instructions provided in the link above
2. Upload the results and review for any failures
Check if Certificate Authentication is enabled in the AD FS authentication policy
AD FS does not enable certificate authentication by default. Refer to the beginning of this document on how to
enable certificate authentication.
Check if Certificate Authentication is enabled in the AD FS authentication policy
AD FS does user certificate authentication by default on port 49443 with the same host name as AD FS (e.g.
adfs.contoso.com ). You can also configure AD FS to use port 443 (default HTTPS port) using the alternate SSL
binding. However, the URL used in this configuration is certauth.<adfs-farm-name> (e.g. certauth.contoso.com ).
See this link for more information. The most common case of network connectivity is that a firewall has been
incorrectly configured and blocks or interferes user certificate authentication traffic. Usually, you will see a blank
screen or a 500 server error when this issue occurs.
1. Note the hostname and port that you have configured in AD FS
2. Ensure that any firewall in front of AD FS or Web Application Proxy (WAP) is configured to allow the
hostname:port combination for your AD FS farm. You will have to refer to your network engineer to perform
this step.
Check Certificate Revocation List Connectivity
Certificate Revocation Lists (CRL) are endpoints that are encoded into the user certificate to perform runtime
revocation checks. For example, if a device that contained a certificate is stolen, an administrator can add the
certificate to the revoked certificates list. Any endpoint that accepted this certificate earlier would now fail the
authentication.
Every AD FS and WAP server will need to reach the CRL endpoint to validate if the cert that was presented to it
is still valid and has not been revoked. CRL validation can occur over HTTPS, HTTP, LDAP or via OCSP (Online
Certificate Status Protocol). If AD FS/WAP servers cannot reach the endpoint, the authentication will fail. Follow
the steps below to troubleshoot it.
1. Consult with your PKI engineer to determine the CRL endpoints used to revoke user certificates from your
PKI system.
2. On each AD FS/WAP server ensure that the CRL endpoints are reachable via the protocol used (typically
HTTPS or HTTP)
3. For advanced validation, enable CAPI2 event logging on each AD FS/WAP server
4. Check for Event ID 41 (Verify Revocation) in the CAPI2 operational logs
5. Check for
‘\<Result value="80092013"\>The revocation function was unable to check revocation because the revocation
server was offline.\</Result\>'
Tip : You can target a single AD FS or WAP server for easier troubleshooting by configuring DNS resolution
(HOSTS file on Windows) to point to a specific server. This allows you to enable tracing targeting a server.
Check if this is a Server Name Indication (SNI ) issue
AD FS requires the client device (or browsers) and the load balancers to support SNI. Some client devices
(usually older versions of Android) may not support SNI. Additionally, load balancers may not support SNI or
have not been configured for SNI. In these instances you are likely to see user certification failures.
1. Work with your network engineer to ensure that the Load Balancer for AD FS/WAP supports SNI
2. In the event that SNI can't be supported AD FS has a work around by following the below steps
Open an elevated command prompt window on the primary AD FS server
Type in Netsh http show sslcert
Copy the ‘application GUID' and ‘certificate hash' of the federation service
Type in
netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid=
{your_applicaitonGUID}
Check if the client device has been provisioned with the certificate correctly
You may notice that some devices are working correctly but other devices are not. In this case, it is usually a
result of the user certificate not being provisioned correctly on the client device. Follow the steps below.
1. If the issue is specific to an Android device, the most common issue is that the certificate chain is not fully
trusted on the Android device. Refer to your MDM vendor to ensure that the certificate has been provisioned
correctly and the entire chain is fully trusted on the Android device.
2. If the issue is specific to a Windows device, check if the certificate is provisioned correctly by checking the
Windows Cert Store for the logged in user (not system/computer).
3. Export the client user certificate to .cer file and run the command ‘certutil -f -urlfetch -verify
certificatefilename.cer'
Check if the TLS version is compatible between AD FS/WAP servers and the client device
In rare cases, a client device (typically mobile devices) are updated to only support a higher version of TLS (say
1.3) or you may have the reverse problem where AD FS/WAP servers were updated to only use a higher TLS
version and the client device does not support it. You can use online SSL tools to check your AD FS/WAP servers
and see if it is compatible with the device. For more information on how to control the TLS versions, see this link.
Check if Azure AD PromptLoginBehavior is configured correctly on your federated domain settings
Many Office 365 applications send prompt=login to Azure AD. Azure AD, by default, converts it to a fresh
password login to AD FS. As a result, even if you have configured certificate authentication in AD FS, your end
users will only see a password login.
1. Get the federated domain settings using the ‘Get-MsolDomainFederationSettings' command let
2. Ensure that PromptLoginBehavior parameter is set to one of ‘Disabled' or ‘NativeSupport'
For more information see this link.
Additional Troubleshooting
These are rare occurrences
1. If your CRL lists are very long, it may hit a time out when attempting to download. In that case you need to
update the ‘MaxFieldLength' and ‘MaxRequestByte' as per https://support.microsoft.com/help/820129/http-
sys-registry-settings-for-windows
Reference: Complete list of user certificate claim types and example

values
C L A IM T Y P E EXA M P L E VA L UE
https://schemas.microsoft.com/2012/12/certificatecontext/fie 3
ld/x509version
https://schemas.microsoft.com/2012/12/certificatecontext/fie sha256RSA
ld/signaturealgorithm
https://schemas.microsoft.com/2012/12/certificatecontext/fie CN=entca, DC=domain, DC=contoso, DC=com

ld/issuer
https://schemas.microsoft.com/2012/12/certificatecontext/fie CN=entca, DC=domain, DC=contoso, DC=com

ld/issuername
https://schemas.microsoft.com/2012/12/certificatecontext/fie 12/05/2016 20:50:18

ld/notbefore
https://schemas.microsoft.com/2012/12/certificatecontext/fie 12/05/2017 20:50:18

ld/notafter
https://schemas.microsoft.com/2012/12/certificatecontext/fie E=user@contoso.com, CN=user, CN=Users, DC=domain,

ld/subject DC=contoso, DC=com
https://schemas.microsoft.com/2012/12/certificatecontext/fie E=user@contoso.com, CN=user, CN=Users, DC=domain,

ld/subjectname DC=contoso, DC=com
C L A IM T Y P E EXA M P L E VA L UE
https://schemas.microsoft.com/2012/12/certificatecontext/fie {Base64 encoded digital certificate data}

ld/rawdata
https://schemas.microsoft.com/2012/12/certificatecontext/ex DigitalSignature
tension/keyusage
https://schemas.microsoft.com/2012/12/certificatecontext/ex KeyEncipherment
tension/keyusage
https://schemas.microsoft.com/2012/12/certificatecontext/ex 9D11941EC06FACCCCB1B116B56AA97F3987D620A
tension/subjectkeyidentifier
https://schemas.microsoft.com/2012/12/certificatecontext/ex KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd 36 6a d5 0b 51 f3
tension/authoritykeyidentifier 0b 25 7f
https://schemas.microsoft.com/2012/12/certificatecontext/ex User
tension/certificatetemplatename
https://schemas.microsoft.com/2012/12/certificatecontext/ex Other Name:Principal Name=user@contoso.com, RFC822

tension/san Name=user@contoso.com
https://schemas.microsoft.com/2012/12/certificatecontext/ex 1.3.6.1.4.1.311.10.3.4
tension/eku
Related Links
Configure alternate hostname binding for AD FS certificate authentication
Configure certificate authorities in Azure AD
Configure Azure MFA as authentication provider
with AD FS
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 or use it as an additional authentication provider.
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

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.
NOTE
With ADFS 2019, you are required to make a modification to the anchor claim type for the Active Directory Claims
Provider trust and modify this from the windowsaccountname to UPN. Execute the PowerShell cmdlet provided below.
This has no impact on the internal functioning of the AD FS farm. You may notice a few users may be re-prompted for
credentials once this change is made. After logging in again, end users will see no difference.
Set-AdfsClaimsProviderTrust -AnchorClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -

TargetName "Active Directory"
Azure MFA as Additional authentication to Office 365

Azure MFA adapter for AD FS enables your users to do MFA on AD FS. To secure your Azure AD resource, it is
recommended to require MFA through a Conditional Access policy, set the domain setting SupportsMfa to $True
and emit the multipleauthn claim when a user performs two-step verification successfully.
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
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 port 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 the Azure Multi-Factor Auth Client Service Principal
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 Service Principal 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 Service Principal.
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 cer tificate 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, set the Azure tenant information using the
Set-AdfsAzureMfaTenant cmdlet. This cmdlet needs to be executed only once for an AD FS farm.
Open a PowerShell prompt and enter your own tenantId with the Set-AdfsAzureMfaTenant cmdlet. For
customers that use Microsoft Azure Government cloud, add the -Environment USGov parameter:
NOTE
You need to restart the AD FS service on each server in the farm before these changes take affect. For minimal impact,
take each AD FS server out of the NLB rotation one at a time and wait for all connections to drain.
Set-AdfsAzureMfaTenant -TenantId <tenant ID> -ClientId 981f26a1-7f43-403b-a875-f8b09b8cd720
Windows Server without the latest service pack doesn't support the -Environment parameter for the Set-
AdfsAzureMfaTenant cmdlet. If you use Azure Government cloud and the previous steps failed to configure your
Azure tenant due to the missing -Environment parameter, complete the following steps to manually create the
registry entries. Skip these steps if the previous cmdlet correctly registered your tenant information or you
aren't in the Azure Government cloud:
1. Open Registr y Editor on the AD FS server.
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADFS . Create the following registry key values:
REGIST RY K EY VA L UE
SasUrl https://adnotifications.windowsazure.us/StrongAuthentic
ationService.svc/Connector
StsUrl https://login.microsoftonline.us
ResourceUri https://adnotifications.windowsazure.us/StrongAuthentic
ationService.svc/Connector
3. Restart the AD FS service on each server in the farm before these changes take affect. For minimal
impact, take each AD FS server out of the NLB rotation one at a time and wait for all connections to drain.
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:
Cau t i on
If your certificate has already expired, don't add the -Renew $true parameter to the following command. In this
scenario, the existing expired certificate is replaced with a new one instead of being left in place and an
additional certificate created.
PS C:\> $newcert = New-AdfsAzureMfaTenantCertificate -TenantId <tenant id such as contoso.onmicrosoft.com> -

Renew $true
If the certificate hasn't already expired, a new certificate that is valid from 2 days in the future to 2 days + 2
years is generated. AD FS and Azure MFA operations aren't 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
If your previous certificate had already expired, restart the AD FS service to pick up the new certificate. You don't
need to restart the AD FS service if you renewed a certificate before it expired.
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.
NOTE
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, create the folder and export the default AD FS Web Theme:
New-Item -Path 'c:\Theme' -ItemType Directory;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) {
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 "ProofUp"
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.
ExtranetObser vationWindow <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:

(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, ExtranetObser vationWindow > Reset Account Lockout Counter After . In example #2,
ExtranetObser vationWindow < 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 <
ExtranetObser vationWindow , an account does not have any risk of being locked out by AD. However, if
Reset Account Lockout Counter After > ExtranetObser vationWindow , 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 +
ExtranetObser vationWindow < Current time, AD FS will reject authentication requests from extranet
To avoid malicious account lockout, you should make sure ExtranetLockoutThreshold < Account
Lockout Threshold AND ExtranetObser vationWindow > Reset Account Lockout Counter
Best practices for securing Active Directory Federation Services
Set-AdfsProperties
AD FS Operations
AD FS Extranet Lockout and Extranet Smart
Lockout
Overview
Extranet Smart Lockout (ESL) protects your users from experiencing extranet account lockout from malicious
activity.
ESL enables AD FS to differentiate between sign-in attempts from a familiar location for a user and sign-in
attempts from what may be an attacker. AD FS can lock out attackers while letting valid users continue to use
their accounts. This prevents and protects against denial-of-service and certain classes of password spray
attacks on the user. ESL is available for AD FS in Windows Server 2016 and is built into AD FS in Windows
Server 2019.
ESL is only available for the username and password authentication requests which come through the extranet
with the Web Application Proxy or a 3rd party proxy. Any 3rd party proxy must support the MS-ADFSPIP
protocol to be used in place of the Web Application Proxy, such as F5 BIG-IP Access Policy Manager. Consult the
3rd party proxy documentation to determine if the proxy supports the MS-ADFSPIP protocol.
Additional Features 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. This allows
you to learn about user familiar locations and still be protected by the extranet lockout feature that is
available from AD FS 2012R2.
How It Works
Configuration information
When ESL is enabled, a new table in the Artifact database, AdfsArtifactStore.AccountActivity, is created and a
node is selected in the AD FS farm as the “User Activity” master. In a WID configuration, this node is always the
primary node. In a SQL configuration, one node is selected to be the User Activity master.
To view the node selected as the User Activity master. (Get-AdfsFarmInformation).FarmRoles
All secondary nodes will contact the master node on each fresh login through Port 80 to learn the latest value of
the bad password counts and new familiar location values, and update that node after the login is processed.
If the secondary node cannot contact the master, it will write error events into the AD FS admin log.
Authentications will continue to be processed, but AD FS will only write the updated state locally. AD FS will
retry contacting the master every 10 minutes and will switch back to the master once the master is available.
Terminology
FamiliarLocation : During an authentication request, ESL checks all presented IPs. These IPs will be a
combination of network IP, forwarded IP, and the optional x-forwarded-for IP. If the request is successful, all of
the IPs are added to the Account Activity table as “familiar IPs”. If the request has all the IPs present in the
“familiar IPs”, the request will be treated as a “Familiar” location.
UnknownLocation : If a request that comes in has at least one IP not present in the existing
“FamiliarLocation” list, then the request will be treated as an “Unknown” location. This is to handle proxying
scenarios such as Exchange Online legacy authentication where Exchange Online addresses handle both
successful and failed requests.
badPwdCount : A value representing the number of times an incorrect password was submitted and the
authentication was unsuccessful. For each user, separate counters are kept for Familiar Locations and
Unknown Locations.
UnknownLockout : A boolean value per user if the user is locked out from accessing from unknown
locations. This value is calculated based on the badPwdCountUnfamiliar and ExtranetLockoutThreshold
values.
ExtranetLockoutThreshold : This value determines the maximum number of bad password attempts. When
the threshold is reached, ADFS will reject requests from the extranet until the observation window has
passed.
ExtranetObser vationWindow : This value determines the duration that username and password requests
from unknown locations are locked out. When the window has passed, ADFS will start to perform username
and password authentication from unknown locations again.
ExtranetLockoutRequirePDC : 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.
ExtranetLockoutMode : Controls log only vs enforced mode of Extranet Smart Lockout
ADFSSmar tLockoutLogOnly : Extranet Smart Lockout is enabled, but AD FS will only write admin
and audit events, but will not reject authentication requests. This mode is intended to initially be
enabled for FamiliarLocation to be populated before ‘ADFSSmartLockoutEnforce' is enabled.
ADFSSmar tLockoutEnforce : Full support for blocking unfamiliar authentication requests when
thresholds are reached.
IPv4 and IPv6 addresses are supported.
Anatomy of a transaction
Pre-Auth Check : During an authentication request, ESL checks all presented IPs. These IPs will be a
combination of network IP, forwarded IP, and the optional x-forwarded-for IP. In the audit logs, these IPs
are listed in the field in the order of x-ms-forwarded-client-ip, x-forwarded-for, x-ms-proxy-client-ip.
Based on these IPs, ADFS determines if the request is from a familiar or unfamiliar location and then
checks if the respective badPwdCount is less than the set threshold limit OR if the last failed attempt is
happened longer than the observation window time frame. If one of these conditions is true, ADFS allows
this transaction for further processing and credential validation. If both conditions are false, the account is
already in a locked out state until the observation window passes. After the observation window passes,
the user is allowed one attempt to authenticate. Note that in 2019, ADFS will check against the
appropriate threshold limit based on if the IP address matches a familiar location or not.
Successful Login : If the log-in succeeds, then the IPs from the request are added to the user's familiar
location IP list.
Failed Login : If the log-in fails the badPwdCount is increased. The user will go into a lockout state if the
attacker sends more bad passwords to the system than the threshold allows. (badPwdCount >
ExtranetLockoutThreshold)
The “UnknownLockout” value will equal to true when the account is locked out. This means that the user's
badPwdCount is over than the threshold i.e. someone attempted more passwords than were allowed by the
system. In this state, there are 2 ways that a valid user can login.
The user must wait for the ObservationWindow time to elapse or
In order to reset the Lockout state, reset the badPwdCount back to zero with ‘Reset-ADFSAccountLockout'.
If no resets occur, the account will be allowed a single password attempt against AD for each observation
window. The account will return to the locked out state after that attempt and the observation window will
restart. The badPwdCount value will only reset automatically after a successful password login.
Log-Only mode versus ‘Enforce' mode
The AccountActivity table is populated both during ‘Log-Only' mode and ‘Enforce' mode. If ‘Log-Only' mode is
bypassed and ESL is moved directly into ‘Enforce' mode without the recommended waiting period, the familiar
IPs of the users will not be known to ADFS. In this case, ESL would behave like ‘ADBadPasswordCounter',
potentially blocking legitimate user traffic if the user account is under an active brute force attack. If the ‘Log-
Only' mode is bypassed and the user enters a locked out state with “UnknownLockout” = TRUE and attempts to
sign in with a good password from an IP that is not in the “familiar” IP list, then they will not be able to sign in.
Log-Only mode is recommended for 3-7 days to avoid this scenario. If accounts are actively under attack, a
minimum of 24 hours of ‘Log-Only' mode is necessary to prevent lockouts to legitimate users.
Extranet Smart Lockout Configuration

Prerequisites for AD FS 2016
1. 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.
2. Verify Permissions
Extranet Smart Lockout requires that Windows Remote management be enabled on every AD FS server.
3. Update ar tifact database permissions
Extranet smart lockout requires the AD FS service account to have permissions tocreate a new table in
the AD FS artifact database. Log in to any AD FS server as an AD FS admin, and then grant this
permission by executing the following commands in a PowerShell Command Prompt window:
PS C:\>$cred = Get-Credential
PS C:\>Update-AdfsArtifactDatabasePermission -Credential $cred
NOTE
The $cred placeholder is an account that has AD FS administrator permissions. This should provide the write
permissions to create the table.
The commands above may fail due to lack of sufficient permission because your AD FS farm is using SQL
Server, and the credentialprovided above does not have admin permission on your SQL server. In this
case, you can configure database permissions manually in SQL Server Database by running the following
command when you're connected to the AdfsArtifactStore database.
# when prompted with “Are you sure you want to perform this action?”, enter Y.
[CmdletBinding(SupportsShouldProcess=$true,ConfirmImpact = 'High')]
Param()
$fileLocation = "$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config"
if (-not [System.IO.File]::Exists($fileLocation))
{
write-error "Unable to open ADFS configuration file."
return
}
$doc = new-object Xml

$doc.Load($fileLocation)
$connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString
$connString = $connString -replace "Initial Catalog=AdfsConfigurationV[0-9]*", "Initial
Catalog=AdfsArtifactStore"
if ($PSCmdlet.ShouldProcess($connString, "Executing SQL command sp_addrolemember 'db_owner',

'db_genevaservice' "))
{
$cli = new-object System.Data.SqlClient.SqlConnection
$cli.ConnectionString = $connString
$cli.Open()
try
{
$cmd = new-object System.Data.SqlClient.SqlCommand

$cmd.CommandText = "sp_addrolemember 'db_owner', 'db_genevaservice'"
$cmd.Connection = $cli
$rowsAffected = $cmd.ExecuteNonQuery()
if ( -1 -eq $rowsAffected )
{
write-host "Success"
}
}
finally
{
$cli.CLose()
}
}
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.
Configuration Instructions
Extranet Smart Lockout uses the ADFS property ExtranetLockoutEnabled . This property was previously used
to control “Extranet Soft Lockout” in Server 2012R2. If Extranet Soft Lockout was enabled, to view the current
property configuration, run Get-AdfsProperties .
Configuration Recommendations
When configuring the Extranet Smart Lockout, follow best practices for setting thresholds:
ExtranetObservationWindow (new-timespan -Minutes 30)
ExtranetLockoutThreshold: Half of AD Threshold Value
AD value: 20, ExtranetLockoutThreshold: 10

Active Directory lockout works independently from Extranet Smart lockout. However, if Active Directory lockout
is enabled, ExtranetLockoutThreshold in AD FS < Account Lockout Threshold in AD
ExtranetLockoutRequirePDC - $false
When enabled, extranet lockout requires a primary domain controller (PDC). When disabled and configured as
false, extranet lockout will fallback to another domain controller in case the PDC is unavailable.
To set this property run:

(new-timespan -Minutes 30) -ExtranetLockoutRequirePDC $false
Enable Log-Only Mode

In log only 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). Set the lockout behavior to log only by running the following
commandlet.
Set-AdfsProperties -ExtranetLockoutMode AdfsSmartlockoutLogOnly
Log only mode is intended to be a temporary state so that the system can learn login behavior prior to
introducing lockout enforcement with the smart lockout behavior. The recommended duration for log-only
mode is 3-7 days. If accounts are actively under attack, log-only mode must be run for a minimum of 24 hours.
On AD FS 2016, if 2012R2 ‘Extranet Soft Lockout' behavior is enabled prior to enabling Extranet Smart Lockout,
Log-Only mode will disable the ‘Extranet Soft Lockout' behavior. AD FS Smart Lockout will not lock out users in
Log-Only mode. However, on-premises AD may lock out the user based on the AD configuration. Please review
AD Lockout policies to learn how on-prem AD can lockout users.
On AD FS 2019, an additional advantage is to be able to enable log-only mode for smart lockout while
continuing to enforce the previous soft lockout behavior using the below Powershell.
Set-AdfsProperties -ExtranetLockoutMode 3
For the new mode to take effect, restart the AD FS service on all nodes in the farm
Restart-service adfssrv
Once the mode is configured, you can enable smart lockout using the EnableExtranetLockout parameter
Set-AdfsProperties -EnableExtranetLockout $true
Enable Enforce Mode

After you're comfortable with the lockout threshold and observation window, ESL can be moved to “enforce”
mode by using the following PSH cmdlet:
Set-AdfsProperties -ExtranetLockoutMode AdfsSmartLockoutEnforce
For the new mode to take effect, restart the AD FS service on all nodes in the farm by using the following
command.
Restart-service adfssrv
Manage user account activity

AD FS provides three cmdlets to manage account activity data. These cmdlets automatically connect to the node
in the farm that holds the master role.
NOTE
Just Enough Administration (JEA) can be used to delegate AD FS commandlets to reset account lockouts. For example,
Help Desk personnel can be delegated permissions to use ESL commandlets. For information on delegating permissions
for using these cmdlets, see Delegate AD FS Powershell Commandlet Access to Non-Admin Users
This behavior can be overridden by passing the -Server parameter.

Get-ADFSAccountActivity -UserPrincipalName
Read the current account activity for a user account. The cmdlet always automatically connects to the
farm master by using the Account Activity REST endpoint. Therefore, all data should always be consistent.
Get-ADFSAccountActivity user@contoso.com
Properties: - BadPwdCountFamiliar: Incremented when an authentication is unsuccessful from a known location.

- BadPwdCountUnknown: Incremented when an authentication is unsuccessful from an unknown location -
LastFailedAuthFamiliar: If authentication was unsuccessful from a familiar location, LastFailedAuthFamiliar is set
to time of unsuccessful authentication - LastFailedAuthUnknown: If authentication was unsuccessful from an
unknown location, LastFailedAuthUnknown is set to time of unsuccessful authentication - FamiliarLockout:
Boolean value which will be “True” if the “BadPwdCountFamiliar” > ExtranetLockoutThreshold -
UnknownLockout: Boolean value which will be “True” if the “BadPwdCountUnknown” >
ExtranetLockoutThreshold - FamiliarIPs: maximum of 20 IPs which are familiar for the user. When this is
exceeded the oldest IP in the list will be removed.
Set-ADFSAccountActivity
Adds new familiar locations. The familiar IP list has a maximum of 20 entries, if this is exceeded, the
oldest IP in the list will be removed.
Set-ADFSAccountActivity user@contoso.com -AdditionalFamiliarIps “1.2.3.4”
Reset-ADFSAccountLockout
Resets the lockout counter for a user account for each Familiar location (badPwdCountFamiliar) or
Unfamiliar Location counters (badPwdCountUnfamiliar). By resetting a counter, the “FamiliarLockout” or
“UnfamiliarLockout” value will update, as the reset counter will be less than the threshold.
Reset-ADFSAccountLockout user@contoso.com -Location Familiar
Reset-ADFSAccountLockout user@contoso.com -Location Unknown
Event Logging & User Activity Information for AD FS Extranet Lockout

Connect Health
The recommended way to monitor user account activity is through Connect Health. Connect Health generates
downloadable reporting on Risky IPs and bad password attempts. Each item in the Risky IP report shows
aggregated information about failed AD FS sign-in activities which exceed designated threshold. Email
notifications can be set to alert administrators as soon as this occurs with customizable email settings. For
additional information and setup instructions, visit the Connect Health documentation.
AD FS Extranet Smart Lockout events.
NOTE
Troubleshoot Extranet Smart lockout with the AD FS Help Extranet Lockout troubleshooting guide
For Extranet Smart Lockout events to be written, ESL must be enabled in ‘log-only' or ‘enforce' mode and ADFS
security auditing is enabled. 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.
EVEN T ID DESC RIP T IO N
1203 This event is written for each bad password attempt. As

soon as the badPwdCount reaches the value specified in
ExtranetLockoutThreshold, the account will be locked out on
ADFS for the duration specified in
ExtranetObservationWindow.
Activity ID: %1
XML: %2
1201 This event is written each time a user is locked out.

Activity ID: %1
XML: %2
557 (ADFS 2019) An error occurred while trying to communicate with the
account store rest service on node %1. If this is a WID farm
the primary node may be offline. If this is a SQL farm ADFS
will automatically select a new node to host the User store
master role.
562 (ADFS 2019) An error occurred when communicating with the account
store endpoint on server %1.
Exception Message: %2
563 (ADFS 2019) An error occurred while calculating extranet lockout status.
Due to the value of the %1 setting authentication will be
allowed for this user and token issuance will continue. If this
is a WID farm the primary node may be offline. If this is a
SQL farm ADFS will automatically select a new node to host
the User store master role.
Account store server name: %2
User Id: %3
Exception Message: %4
512 The account for the following user is locked out. A login
attempt is being allowed due to the system configuration.
Activity ID: %1
User: %2
Client IP: %3
Bad Password Count: %4
Last Bad Password Attempt: %5
515 The following user account was in a locked out state and the
correct password was just provided. This account may be
compromised.
Additional Data
Activity ID: %1
User: %2
Client IP: %3
EVEN T ID DESC RIP T IO N
516 The following user account has been locked out due to too
many bad password attempts.
Activity ID: %1
User: %2
Client IP: %3
Bad Password Count: %4
Last Bad Password Attempt: %5
ESL Frequently Asked Questions

Will an ADFS farm using Extranet Smar t Lockout in enforce mode ever see malicious user
lockouts?
A: If ADFS Smart Lockout is set to ‘enforce' mode then you will never see the legitimate user's account locked
out by brute force or denial of service. The only way a malicious account lockout can prevent a user sign in is if
the bad actor has the user password or can send requests from a known good (familiar) IP address for that user.
What happens ESL is enabled and the bad actor has a user password?
A: The typical goal of the brute force attack scenario is to guess a password and successfully sign in. If a user is
phished or if a password is guessed then the ESL feature will not block the access since the sign in will meet
“successful” criteria of correct password plus new IP. The bad actors IP would then appear as a “familiar” one.The
best mitigation in this scenario is to clear the user's activity in ADFS and to require Multi Factor Authentication
for the users. We strongly recommend installing AAD Password Protection that ensures guessable passwords do
not get into the system.
If my user has never signed in successfully from an IP and then tries with wrong password a few
times will they be able to login once they finally type their password correctly?
A: If a user submits multiple bad passwords (i.e. legitimately mis-typing) and on the following attempt gets the
password correct, then the user will immediately succeed to sign in. This will clear the bad password count and
add that IP to the FamiliarIPs list.However, if they go above the threshold of failed logins from the unknown
location, they will enter into lockout state and they will require to wait past the observation window and sign-in
with a valid password or require admin intervention to reset their account.
Does ESL work on intranet too?
A: If the clients connect directly to the ADFS servers and not via Web Application Proxy servers then the ESL
behavior will not apply.
I am seeing Microsoft IP addresses in the Client IP field. Does ESL block EXO proxied brute force
attacks?
A: ESL will work well to prevent Exchange Online or other legacy authentication brute force attack scenarios. A
legacy authentication has an “Activity ID” of 00000000-0000-0000-0000-000000000000.In these attacks, the
bad actor is taking advantage of Exchange Online basic authentication (also known as legacy authentication) so
that the client IP address appears as a Microsoft one. The Exchange online servers in the cloud proxy the
authentication verification on behalf of the Outlook client. In these scenarios, the IP address of the malicious
submitter will be in the x-ms-forwarded-client-ip and the Microsoft Exchange Online server IP will be in the x-
ms-client-ip value. Extranet Smart Lockout checks network IPs, forwarded IPs, the x-forwarded-client-IP, and the
x-ms-client-ip value. If the request is successful, all the IPs are added to the familiar list. If a request comes in and
any of the presented IPs are not in the familiar list then the request will be marked as unfamiliar. The familiar
user will be able to sign in successfully while requests from the unfamiliar locations will be blocked.
Can I estimate the size of the ADFSAr tifactStore before enabling ESL?
A: With ESL enabled, AD FS tracks the account activity and known locations for users in the ADFSArtifactStore
database. This database scales in size relative to the number of users and known locations tracked. When
planning to enable ESL, you can estimate the size for the ADFSArtifactStore database to grow at a rate of up to
1GB per 100,000 users. If the AD FS farm is using the Windows Internal Database (WID), the default location for
the database files is C:\Windows\WID\Data. To prevent filling this drive, ensure you have a minimum of 5GB of
free storage before enabling ESL. In addition to disk storage, plan for total process memory to grow after
enabling ESL by up to an additional 1GB of RAM for user populations of 500,000 or less.
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-for warded-for or x-ms-for warded-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
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 in Windows Server 2016 or later
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-AdfsLdapSer verConnection
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 -LdapSer verConnection 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 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.
P RO VIDER O F F ERIN G L IN K TO L EA RN M O RE
aPersona aPersona Adaptive Multi-Factor aPersona ASM ADFS Adapter

Authentication for Microsoft ADFS SSO
Cyphercor Inc. LoginTC Multi-Factor Authentication LoginTC AD FS Connector

for AD FS
Duo Security Duo MFA Adapter for AD FS Duo Authentication for AD FS
Futurae Futurae Authentication Suite for AD FS Futurae Strong Authentication
Gemalto Gemalto Identity & Security Services http://www.gemalto.com/identity
inWebo Technologies inWebo Enterprise Authentication inWebo Enterprise Authentication

service
P RO VIDER O F F ERIN G L IN K TO L EA RN M O RE
Login People Login People MFA API connector for https://www.loginpeople.com

AD 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)
Mideye Mideye Authentication Provider for Mideye two-factor authentication with

ADFS Microsoft Active Directory Federation
Service
Okta Okta MFA for Active Directory Okta MFA for Active Directory
Federation Services Federation Services (ADFS)
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
SecureMFA SecureMFA OTP Provider ADFS Multi Factor Authentication

Providers
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:
Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company
Applications
Configure authentication policies via the AD FS Management snap-in

these procedures. Review details about using the appropriate accounts and group memberships at Local and
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 Primar y Authentication section, click Edit next to Global Settings . You can also right-click
Authentication Policies , and select Edit Global Primar y Authentication , or, under the Actions
pane, select Edit Global Primar y Authentication .
4. In the Edit Global Authentication Policy window, on the Primar y 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 Par ty 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 Primar y Authentication , or, under the Actions pane, select Edit Custom
Primar y Authentication .
4. In the Edit Authentication Policy for <relying_par ty_trust_name> window, under the Primar y
tab, you can configure the following setting as part of the Per Relying Par ty 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. Cer tificate 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 Par ty 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_par ty_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
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

command.
$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 =
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

command.
$MfaClaimRule = "c:[Type == '" https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork'", Value ==

'"true_or_false'"]
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

command.
$MfaClaimRule = "c:[Type == '"

https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser'", Value == '"true_or_false"']
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
command.
`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
command.
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

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
command.
`$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
command.
`$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
command.
`$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
Configure Claim Rules in AD FS for Windows Server
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.
REQ UIREM EN T DESC RIP T IO N
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.
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
REQ UIREM EN T DESC RIP T IO N
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. Replace
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 Ser ver Administration Tools -> Role
Administration Tools -> AD DS and AD LDS Tools -> Choose both the Active Director y module for
Windows PowerShell and the AD DS Tools .
2. 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>"
3. 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
4. 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
2. Provide your Azure AD global administrator credentials
PS C:>$aadAdminCred = Get-Credential
3. 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=Ser vices,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 WIASuppor tedUserAgentStrings property of the Set-ADFSProperties commandlet
The WindowsIntegratedFallbackEnabled property of the Set-AdfsGlobalAuthenticationPolicy
commandlet
The WIASuppor tedUserAgentStrings 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
WIASuppor tedUserAgentStrings 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 A GEN T S USE C A SES
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 A GEN T S USE C A SES
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:
In AD FS configuration, add a user agent string for Chrome on Windows-based platforms:
Set-AdfsProperties -WIASupportedUserAgents ((Get-ADFSProperties | Select -ExpandProperty

WIASupportedUserAgents) + "Mozilla/5.0 (Windows NT)")
And similarly for Chrome on Apple macOS, add the following user agent string to the AD FS configuration:
Set-AdfsProperties -WIASupportedUserAgents ((Get-ADFSProperties | Select -ExpandProperty

WIASupportedUserAgents) + "Mozilla/5.0 (Macintosh; Intel Mac OS X)")
Confirm that the user agent string for Chrome is now set in the AD FS properties:
Get-AdfsProperties | Select -ExpandProperty WIASupportedUserAgents
(You would need a new screen shot here)
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 WIASuppor tedUserAgents setting in AD FS
when adding a new device or browser type to your support matrix for WIA.
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 created 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.
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
3. 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 . U p d a t e t o r e q u i r e d W i n d o w s v e r si o n
Windows version 1709 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 Windows version 1709 and above.
St e p 3 . 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
REGK EY DATA N A M E,
REGK EY TO A DD T Y P E, A N D VA L UE W IN DO W S 7/ 8 W IN DO W S 10 DESC RIP T IO N
REGK EY DATA N A M E,
REGK EY TO A DD T Y P E, A N D VA L UE W IN DO W S 7/ 8 W IN DO W S 10 DESC RIP T IO N
HKEY_CURRENT_USE DomainHint Required Required The value of this

R\Software\Microsoft REG_SZ regkey is a verified
\AuthN 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.
com.
HKEY_CURRENT_USE EnableAlternateIdSup Required for Outlook Required for Outlook The value of this
R\Software\Microsoft port 2016 ProPlus 2016 ProPlus regkey can be 1 / 0
\Office\16.0\Commo REG_DWORD to indicate to
n\Identity 1 Outlook application
whether it should
engage the improved
alternate-id
authentication logic.
HKEY_CURRENT_USE * Required Required This regkey can be

R\Software\Microsoft REG_DWORD used to set the STS
\Windows\CurrentVe 1 as a trusted Zone in
rsion\Internet the internet settings.
Settings\ZoneMap\D Standard ADFS
omains\contoso.com\ deployment
sts 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
C L IEN T SUP P O RT STAT EM EN T REM A RK S
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

C L IEN T SUP P O RT STAT EM EN T REM A RK S
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

SUP P O RT STAT EM EN T - W IT H O UT
C L IEN T SUP P O RT STAT EM EN T - W IT H H M A 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
premises - archive in the cloud) prompt for credentials when accessing
the archive, they have to provide their
alternate ID when prompted.
Outlook Web Access Supported Supported

SUP P O RT STAT EM EN T - W IT H O UT
C L IEN T SUP P O RT STAT EM EN T - W IT H H M A 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 is used 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:
ERRO R C A SES IM PA C T O N SIGN - IN EXP ERIEN C E EVEN T
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}
ERRO R C A SES IM PA C T O N SIGN - IN EXP ERIEN C E EVEN T
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
organization.


Next .
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 Star t .
trust information.
See Also
AD FS Operations
metadata.

Membership in Administrators , or equivalent, on the local computer is the minimum required to complete

Everything About Active Directory

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Everything About Active Directory

Uploaded by

Copyright:

Available Formats

Contents

Identity and Access

Dynamic Access Control Content Roadmap

Scenario: Access- Scenario: Access- Plan for Access- Deploy Access-

Scenario: Scenario: Plan to deploy for Deploy Encryption of

Scenario: Get Insight Plan for Automatic Deploy Automatic

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

RO L E/ F EAT URE H O W IT SUP P O RT S T H IS SC EN A RIO

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.2 Express the access policy Finance documents should only be

1.3 Express the access policy in Windows Targeting:

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 -

Windows PowerShell equivalent commands

$countryClaimType = Get-ADClaimType country

Windows PowerShell equivalent commands

New-ADCentralAccessPolicy "Finance Policy" Add-ADCentralAccessPolicyMember

Maintain: Change and stage the policy

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

RO L E/ F EAT URE H O W IT SUP P O RT S T H IS SC EN A RIO

Configure global object access policy

Update Group Policy settings

3. Type gpupdate /force and then press ENTER.

Features included in this scenario

F EAT URE H O W IT SUP P O RT S T H IS SC EN A RIO

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

Figure 6 Classification-based RMS protection

Roles and features included in this scenario

RO L E/ F EAT URE H O W IT SUP P O RT S T H IS SC EN A RIO

Enable resource properties Enable the Impact and Personally Identifiable

Step 1: Enable resource properties

Windows PowerShell equivalent commands

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

Step 2: Create classification rules